[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ofx and png transition

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

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

Reply to: