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

Re: Sparc build failure analysis (was Re: StrongARM tactics)

On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote:
> >I said that deciding which packages should belong in P-a-s is porter work;
> >as is filing bugs on failed packages that shouldn't, providing patches, and
> >doing porter NMUs if necessary.

> Again: what can I do with such a list?  See the list below.

Changes to the P-a-s list should be sent to the contacts listed at the top
of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific).

> >If the porters do this effectively, there's really not much need at all for
> >telling the buildd maintainers about transient build failures, because
> >they'll be pretty obvious (and account for the majority of failures, as it
> >should be).

> Just because it is obvious does not mean that the buildd adminstrator
> does the correct thing.  kq was "uploaded" 51 days ago, trustedqsl was
> "uploaded" 25 days ago, neither is in the archive.

Well, release-wise, the practical impact here is quite small; for packages
that aren't needed in order to fix RC bugs, for my part I'm quite content to
have the buildd admins manage such give-backs on their own schedule.  Being
more responsive to give-back requests may generally make people happier, but
there's also a context-switch cost associated with such status polling; in
the non-RC cases, does it really hurt anything to *not* have these packages
given back quickly?  If not, isn't a better solution for people to be
understanding of this?

kq and pointless given back now, btw (not trustedqsl, which is "Failed"
rather than "Uploaded").

> openoffice.org has been "building" for 8 days, it only took 57 hours
> on my slower than any current sparc buildd pbuilder.  kexi has been
> "building" for 6 days, it took less than 2 hours.

openoffice.org is listed as "building" because the buildd crashed mid-build.
Ryan Murray and the package maintainer discussed this on IRC when it
happened; it was not immediately given back because of concerns over whether
the build might take down a *second* buildd while there was still a
significant backlog due to the c2a transition.  No, this isn't perfectly
transparent; but yes, it should be acceptable.  There's almost never a
reason to fret over builds-gone-missing for at least, say, a week and a
half, which is about how long it would take for the package to be eligible
for testing.  In OOo's case, try adding another couple of weeks to that for
the current c2a transition that it blocks on...

> The sparc buildd mainainter has in the past left transient build
> failures lie for over 6 months.  For the past year he's been requeuing
> all maybe-failed packages every 1-3 months.

Well, a) we now have auto-dep-wait, so this is even less of a problem now
than it might have been before; b) in the general case, it's not much of a

> qterm           0.4.0pre3-2+b1  342381

Consider that this was a bug in a *toolchain* package, so more than a simple
give-back is required:  gcc-4.0 needs to be upgraded on the buildds for this
to work.  Given that this was caused by a stray \ in the source that didn't
belong, it would be advisable for the package maintainer to defensively
correct this as well.

> galago-sharp		libmono-dev
> dmraid			libklibc-dev
> motv			ibzvbi0 (= 0.2.17-3.0.1)
> qmailadmin		vpopmail-bin
> wvstreams		libxplc0.3.13-dev
> sylpheed-claws-gtk2	libclamv-dev
> digikam			libartsl-dev (>=1.4.2)
> tulip			mesa-common-dev (= 6.2.1-7)
> liferea			libdbus-glib-1-dev
> kwave			kdemultimedia-dev
> ivtools			libace-dev
> fwbuilder		libfwbuilder-dev
> gtksharp2		libmono-dev
> libavg			libavcodeccvs-dev
> gnucash			slib
> memepack		r-base-dev
> r-cran-bayesm		r-base-dev

Um, at least some of these dep-waits are completely wrong; r-base-dev and
slib are arch: all packages, and it's not useful to set a dep-wait on a
package that *is* available.  Could you please revise this list accordingly?

Also, setting an (= $version) dep-wait isn't particularly helpful, sometimes
newer source versions will be uploaded before binaries are uploaded for the
current version.  So please clarify whether these are meant to be >= or
something else.


But FAILED is an advisory state anyway; it doesn't directly benefit the
port, at all, to have the package listed as "Failed", this is just a
convenience for folks sifting through the build failures (like the rarely
used "confirmed" BTS tag is for maintainers).  In the long-term, one of two
things needs to happen with each of these build failures: the package needs
to be added to P-a-s so the arch no longer tries to build it, or the package
needs to be fixed -- via porter NMU if necessary.

So as you have the list of these packages, as a porter you can proceed with
figuring out which of the two categories each falls into, and take the
necessary action without worrying about the "Failed" state, yes?

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: