On Tue, Aug 23, 2005 at 09:54:20PM +0200, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > Then you'd have to keep the master chroot image up-to-date. If you don't > > do that, after a while the master image will digress too much from the > > actual Debian archive, and you end up with spending loads of cpu time > > upgrading the same packages over and over again after each build. > > You have to keep the chroot up-to-date manualy anyway as sbuild does > not upgrade unless a Build-Depends requires a newer version > specificaly.
In my experience, it's not that bad. Last time I manually upgraded anything inside the chroot must have been about two or three months ago. Yet it failed a number of packages due to a bug in glibc 2.3.5-3 which made libraries break on kernels without NPTL support (such as the 2.2 kernel which is running on that system). This particular bug also hit q950 and tanda, two of our other buildd systems. Considering glibc was uploaded to the archive on August 5th (or at least, the katie mail was sent out at that time), that I started noticing this bug about a week ago, and that it probably took about a day for the new glibc to be built on m68k and uploaded by the buildd (but I can't check that, debian-devel-m68k-changes doesn't appear to have worked since 2003), that leaves about ten days for the package to be installed after it was available. Manual maintenance wouldn't have made that go much faster, if at all; and the way glibc got upgraded in this particular occasion is far from exceptional. Anyway, this is of course all moot for me particularly since LVM doesn't work on 2.2, and 2.6 doesn't work reliably on all m68k macs yet either. But at least we're getting places in that area already :-) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
