On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt <[EMAIL PROTECTED]> wrote: [snip] > As Steve mentioned in another mail[1], one of the points where arches offload > work onto the release team is > > "3) chasing down, or just waiting on (which means, taking time to poll the > package's status to find out why a bug tagged 'testing' is still open), > missing builds or fixes for build failures on individual architectures that > are blocking RC bugfixes from reaching testing"
And it's not just the number of arches. Slow arches really do make more work, and it's not just about migrations to testing. There's a concrete example right now that shows why a large number of slow autobuilders, working in parallel, isn't a great solution. (Although distcc is another story, if its results are truly reproducible.) The latest uim FTBFS twice on ARM because of the removal of howl dependencies from gnome packages. The rebuilt gnome-vfs2 still hadn't made it to unstable as of the second try, so the archive wasn't in a state that any package dependent on one of its binary packages could be autobuilt. It would probably build now, but Steve doesn't want to submit it a third time until the build-depends have actually been inspected for stray libhowl.la files -- and I can't really blame him. We are not swimming in arm buildd cycles. The inspection will be a painful process for anyone who doesn't have an otherwise idle ARM handy. Sure, he (or I) can massage the build log to construct URLs for files in pool, and pull them to $fast_box, unpack, and inspect. But an arm porter is in a better position to do this inspection, since apt-get build-dep will work without a bunch of script-fu. Of course, that's going to pollute the box; so do it in a nice new chroot. Better have a mirror of a sane snapshot of unstable handy. There are things that can be done to make this easier, starting with better facilities for snapshotting chroots and overlaying them using device-mapper or unionfs. But it does take some commitment by people who have (access to) boxes they can experiment on -- and preferably also skills in many programming languages and laboratory-scale systems administration. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
