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.
http://buildd.debian.org/~jeroen/status/architecture.php?a=sparc (etc)
is an attempt at getting per-architecture status information in a
porter-oriented way (rather than maintainer oriented). The most
interesting part is the "Maybe-Failed" section. It links to a package
page which shows the last 30 lines of build logs on the failing
architectures for a package, and is a good starting point.
Note that the webpage is still a bit rough and in alpha stage,
suggestions and patches are welcome.
Composing a list of status changes to make is I guess a good way to
really be useful to the buildd admin -- per-package hints about that do
not scale well enough normally to be bothered with, but coming up with a
list of a few dozen looked-into packages and a suggestion what to do
with them (mark failed, retry it, add to Packages-arch-specific, ...).
Generally being proactive about the failures there and simply getting
them fixed is most productive.
> > >4) buildd software issues(pbuild,sbuild,wanna-build,etc)
> >
> > occasionally. sbuild is vulnerable to broken packages breaking it's
> > chroot, sometimes in ways that only effect a few packages and may not
> > be quickly noticed.
> >
> > wanna-build has scalability issues, but it can be bypassed for unstable
> > if the buildd maintainer doesn't interfere. (Just build and upload
> > all the new packages.)
> >
> > 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..
As far as I know, the most time-consuming task is seeing why a certain
build failed, and filing an appropriate bug about that on the
appropriate package. The above-mentioned web interface could be enhanced
to list filed FTBFS source bugs if they follow a certain naming
convention, and then it's really easy for buildd admins to process the
lot that's in maybe-failed state.
Then, when the porting-bugs are filed, the other side of the medal is
being proactive about solving porting bugs. The whole reason behind
the Vancouver proposal is that the onus on solving a porting bug is too
much on the maintainer now, and not on the porting teams. Solving
porting issues requires generally more knowledge of the architecture in
question rather than knowledge of the package, and for maintainers it's
often really unmotivating to (need to) hunt down porting issues on
architectures they might never even have seen hardware of, rather than
fixing for example usability issues that are of much more relevance to
the big majority of a package's user base.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: