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.
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>IIUC, this is a summary:
>make source, build package, upload i386 deb to incomming, tell wanna-build,=
> [build
>on buildd, upload non-i386 deb to incomming] repeat for all archs
>Is the issue:=20
>1) buildd availability (network or amount)
sometimes
>2) buildd admin responcivness,
sometimes. The buildd maintainer needs to manually put packages in
dep-wait or requeue the build when the problem is a build dependency
issue.
>3) arch-specific issues that cause build problems for non-i386 not getting =
>fixed?
sometimes
>(would that be the 'porters' job?)
Depends on the cause. In the most common case of broken packages, it
is primarily the package maintainer's job, but the porters should be
willing to help.
>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.
>5) something else?
occasional.
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
