Re: Where to start hacking unstable on Alpha?
2011/7/13 Michael Cree <mcree@orcon.net.nz>:
> Well, at the moment we have nothing building so getting an autobuilder
> network up and going is the most pressing issue. Without it we are dead
> in the water.
>
> I'll will check with Aurelien about part time buildds. Given that it is
> up to the buildd to check for packages that need building and take one
> for building I suspect it won't be a problem.
Ok, I think I could setup my DS20 for this task in a short time.
I have a spare 250GB sata drive, but no PCI or PCI-X controller, I am
sure that on ebay I will find one.
> I am now installing a new chroot and have upgraded it to debian-ports
> only. I can build the packages that are listed on
> buildd.debian-ports.org as needs-build (i.e. their build dependencies
> are satisfied). Stuff such as 'rm' is working correctly. I haven't
> tried to build coreutils in the chroot but I would expect it to fail as
> coreutils is in the bd-uninstallable list (i.e. its build dependencies
> cannot be satisfied until some other packages are built.)
I am quite sure that I will also fine the bug in coreutils when using
the debian-ports packages.
That is a bug to solve soon, because it breaks compiling packages in the chroot.
If a package needs to do, for example "make clean", that would fail
(because of even a simple "rm -rf targetdir").
> I have a PCI-X SATA controller in my XP1000 with a large SATA drive.
> Works very nicely.
Since I need to buy one, which chipset has it?
VIA or Silicon Image?
Seems that these two chipsets are used on boards available on ebay.
>> Could you provide somewhere the .deb for coreutils you are using?
>
> Yeah, I could do that, but there will be other dependencies that you
> would need too, such as a new eglibc. It could be quite a thorny package
> resolution issue. I suspect getting buildds going with debian-ports is
> the best solution.
Please excuse me, if I am dumb... :D
I think that for buildd environment, we need an unstable chroot.
If in the unstable chroot, coreutils are bugged, so we will face many
build fails because of that.
Also, starting for an old point, catching up with eglibc and binutils
would be very difficult.
>> I am already doing some tests on my own domain hosting with different
>> CMS solutions, I will let you know.
>
> OK, also note Matt's response about the wiki at alphalinux.org. How
> does your CMS thingy compare to a wiki?
Given that the wiki at alphalinux.org has a lot of coding resources, a
wiki is, by design, a document driven CMS, supporting at max more
document revisions.
It lacks user forums, bug tracking system (or "case tracking"), and
maybe also uploading of attachments to the document/case (like
patches, code snippets, ecc...)
That is why sites like sf.net, alioth.debian.org, java.net and others
use a cooperation specific CMS.
There are also some wikis that have been extended up to collaboration,
or developed for that task.
Crawling on sf.net I found Twiki and MindTouch, for example.
Mediawiki has a collaboration extension
(http://www.mediawiki.org/wiki/Extension:CCM) but it is experimental,
old and maybe not mantained any more.
I am nobody to tell you all what to do, so I put myself in the queue
and do my best with tools provided now.
> I know practically nothing about the Debian supplied resources in this
> regard and are happy to be educated.
Don't know much more than you.
I know that alioth.debian.org is a collaboration portal running on
FusionForge collaboration CMS.
Anyone could ask for opening a project page on alioth.debian.org and
every developer could join in asking for an account.
It has all the features required for teamwork (forum, case tracking,
bug request, even GIT source repository)
Give a look to one project, for example Snort packaging project
http://alioth.debian.org/projects/pkg-snort/
My only concern is that projects on alioth are dedicated to one
package or a suite of packages, not a whole operating system and I
don't know if it can scale up to that, while a dedicated portal would
do.
Ciao
gl
Reply to: