Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt
<david@schmitt.edv-bus.at> 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
Reply to: