On Tue, Jan 29, 2008 at 02:36:07AM +0100, Michael Schmitz wrote:
> > Having a smarter buildd queue is a long term goal and something that I
> > wouldn't burden on the shoulders of the m68k porters. I already made some
> > proposals to enhance the build process long ago. For example to not remove
> > all installed packages, just to install most of them right again, as it is
> > often the case for kde builds or such where many packages are
> > build-depending on the same packages.
> That really needs to be considered carefully, seeing as that keeping a
> chroot as clean as possible has gone a long way to prevent install
> dependency trouble in the past..
Another proposed solution would be the use of lvm snapshots to build the
packages in. Just lvremoving the snapshot would give you a clean chroot
again.
I guess, install troubles are mostly caught on faster archs these days. The
very few cases were those are m68k specific need to be tracked down in a
different way then.
> > Building the packages in the right build-dep order is another goal for an
> > improved buildd queue.
> That's the key thing - OTOH if a build dependency is not installable that
> gets caught rather soon.
IMHO it is possible to check the build dependency and if it's installable
not by the buildd itself, but with a different approach, say on another host
with some scripts. This should be doable on a centralized host or database.
> > Adding packages to N-F-U is a quick and maybe short-term solution, though...
> I'd rather have a centrally maintained weak-no-auto to hack that. We can
> advertise the number of packages currently on that list on the buildd
> status page (or just reduce the needs-build number by the number of
> packages in needs-build that are on the list instead). If a package turns
> out to be of higher priority we can just manually schedule it.
Adding some additional stuff to the buildd.net status pages is quite easy,
modifying the way how the current information is presented is difficult,
though... it's a rather complex setup that allows addition of other stuff
failry easily whereas it's quite dependent on the output of the other
scripts. Uhm, well... ;)
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: [EMAIL PROTECTED]
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
