On Tue, Jun 07, 2005 at 09:37:15PM -0400, Stephen Frost wrote: > * Blars Blarson ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
