On Thu, Oct 20, 2005 at 07:53:39AM -0700, Thomas Bushnell BSG wrote: > Steve Langasek <vorlon@debian.org> writes: > > But there seems to be a *huge* pile-up of libraries preventing that from > > happening today. I didn't realize how big it was until I looked at > > gnucash's status just now. > The autobuilders are puttering along. Hence my email recently to > debian-devel about just that subject! > We MUST find a way to fix this problem. It's a major drag on Debian. > It could be *easily* solved, because the problem is *not* the time it > takes to compile the package, and the problem is *not* the expense of > hardware. > Something about our buildd methodology forces this pain. One example > is that with a chain of dependent packages, each package gets built, > then in a day or so the buildd admin signs it and uploads it, and the > next day it is added to the archive, and the next day it hits the > mirror, and the next day the next build in the sequence can start. So, for reference, there was an error in my previous email; the full dep-wait chain was: gnome-print -> bonobo -> libglade -> gal0.x -> guppi -> gnucash because gal0.x needs libglade to build, not just gnome-print. Current status visible at <http://people.debian.org/~igloo/status.php?email=&packages=gnome-print+bonobo+libglade+gal0.x+guppi+gnucash>. You're right that when uploading a deep chain of packages like this one, this pain is a natural consequence of our buildd methodology. This doesn't mean our buildd methodology is wrong; we're not going to stop requiring that uploads be signed by humans, and adding more buildds doesn't do anything to help a chain of dependencies that must be dealt with serially as in this case. And as already noted, there is no full-day delay for build dependencies. So the only way to improve this is by taking care to *not* upload packages in a manner that results in deep dep-wait chains. As you and I have already discussed, the gdk-imlib transition as it was implemented was largely unneccessary, and could have instead been done as a gradual rebuild against gdk-imlib11. The only GNOME1 packages that really needed to be uploaded for the libpng change were imlib itself, gdk-pixbuf, and gtkxmhtml. But because this wasn't noticed until late, because the library uploads had already happened, the builds now have to be serialized because the buildds will balk at using libraries too old to satisfy the most recent -dev dependencies they know about, even if the new -dev is not yet built for the architecture. (On this, you may have a point regarding buildd methodology; I don't know know the exact rationale for sbuild to behave this way, though I can think of some pretty good reasons why we would want to avoid building packages against known-stale libs.) > Meanwhile, fifteen builds are tying up the buildd's with attempts to > build that fail because the dependencies are not available--which > could be checked perhaps before queuing the build etc etc. There have been updates recently to wanna-build such that it now does auto-dep-wait, so that if a package's build-dependencies are not satisfiable the package is automatically set into a corresponding state. But there's no good way for w-b to automatically check whether the build-dependencies are *installable*, since installability can fail for any number of reasons. The current round of GNOME1 build failures are all caused by uninstallable build-dependencies, not by build-dependencies that aren't satisfied. > If an arch cannot keep up, it needs more buildds. Period. Geez. We > already know this. When are we going to actually implement it? No, in fact, we don't know this. For instance, the gnome-print upload for sparc was delayed because we have one (wrong) buildd too many. > > gnomeprint isn't uploaded yet. > Huh? Say more; AFAICT all the necessary packages have been uploaded. Check the timestamps on the arch-specific packages in question. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature