Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 04:58:33 -0800, Steve Langasek <vorlon@debian.org> wrote:
> Eh, not particularly. This inspection can be done on any machine, and
> there's no reason not to just use the fastest one available to you (whether
> that's by CPU, or network); what's needed here is to first identify which
> packages that were used in the build were broken, which can't be done with
> apt-get build-dep even on arm; and then verify whether the packages in
> question have been fixed in a newer version. In general, just looking at
> apt-get build-dep doesn't guarantee that you haven't overlooked the problem
> that caused the build failure in the first place, and it isn't even
> guaranteed to install the same *packages* (let alone package *versions*) as
> sbuild.
Diffing the logs against a successful build on powerpc caught the
libpanel-applet2-dev (source gnome-vfs2) version skew immediately, and
looking at the changelog confirmed that the version arm pulled in was
built against libhowl and was enough to cause the failure. But if you
want to be certain that there isn't additional breakage hiding behind
that, you need to inspect the actual packages.
Here's what I had in mind:
apt-get --download-only build-dep uim
on a clean chroot, arm host, against snapshot.debian.net for the
appropriate date gets you 95% of the way to a matching build system.
Match
(cd /var/cache/apt/archives && ls *.deb)
against
perl -ane 'print "$1\n" if m#^Unpacking.*/([^/]*\.deb)\)#' <arm.log
and you find a couple of packages for which you need to fetch the
precise version from snapshot.
dpkg --contents gets you enough information for this particular case,
but in general you want to actually install them and at least run
configure to verify, say, that autoreconf did the right thing -- and
that requires $arch. Doesn't necessarily have to be your own, if
you're a DD and have access to developer boxes; but it helps to have a
quick way to bypass debootstrap, and that takes a little planning
ahead.
I'd be interested in seeing something equally simple that follows the
same logic as the apt-get step but doesn't have to be done from $arch.
Bonus points if it monitors buildd failures and pulls packages to a
local mirror promptly so one doesn't have to go fishing around on
snapshot.
Cheers,
- Michael
Reply to: