Re: package building problems (was Re: Canonical and Debian)
On Tue, Jun 07, 2005 at 09:37:15PM -0400, Stephen Frost wrote:
> * Blars Blarson (blarson@blars.org) wrote:
> > I've been watching the sparc buildd queues for the past 9 months or
> > so, filing most of the ftbfs bugs for sparc, and prodding the buildd
> > maintainer when a package needs a simple build requeue or the sbuild
> > chroot is broken.
>
> Great! What mechanisms have you been using to do that, and what could
> we do to make it easier for other people to do that? Is there a way to
> get the sparc buildd queues and associated information to be more
> pro-actively sent to people? I know that, at least for myself, I'm much
> more inclined to do things or at least try to help with things when an
> email about a problem shows up in my email client than if I have to
> periodically check a website, etc.
I've been planning on automating more of what I'm doing, but it is
done after a mirror pusle:
Update build machine (to get current unstable source package file).
pbuilder update
Check http://buildd.debian.org/stats/?arche=sparc&state=Building
Look for packages that have been in state "building" for more than 40 hours.
apt-get -d source $PACKAGE
pbuilder build --binary-arch $PACKAGE_$VERSION.dsc </dev/null >$LOG 2>&1
(two at a time, since I've got a dual-processor box)
Check pbuilder build log. If it isn't an obvious build-dependancy or
not-for-us error, check packages.qa.debian.org for already filed bugs
and compare the buildd's build log to mine. File bugs and mail the
buildd maintainer as needed. dep-wait and obvious ftbfs issues are
most common. Sometimes sbuild finds a package error pbuilder doesn't.
Occasionally an sbuild chroot is broken. Sometimes packages build on
my pbuilder because it has more up-to-date packages. (The package
needed versioned build dependancies.)
All of the first paragraph could be automated, including local
dep-wait and not-for-us.
> > >4) buildd software issues(pbuild,sbuild,wanna-build,etc)
> > It looks like this software could use some redesign to put less work
> > on the buildd maintainers and scale better to more buildds.
> Do you have some specific insights into this? This certainly sounds
> like a good area for us to work on..
Almost all of the dep-wait and many of the not-for-us errors could be
detected by the software.
wanna-build could probably be turned into a distributed process if it
can't be handled on a single box, as could buildd logs.
I'm not sure how the buildd maintainer interface works now, but it may
be able to be improved. (Based mainly on the reluctance of some buildd
maintainers to use existing features.)
--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
Reply to: