Bug#780151: debian-installer: Buggy Built-Using generation on an arch-dep manner
On Mon, Mar 23, 2015 at 09:50:43PM +0100, Cyril Brulebois wrote:
> Cyril Brulebois <kibi@debian.org> (2015-03-09):
> > Source: debian-installer
> > Severity: important
> >
> > Built-Using was missing some items, see #696418 & #700026, so a patch
> > was pushed to try and deal with it:
> >
> > commit b4411bfb56601cf6a7366a1bec065b56b91f1a42
> > Author: Cyril Brulebois <kibi@debian.org>
> > Date: Mon Mar 3 00:00:46 2014 +0100
> >
> > Extend write-built-using to also generate the ${extra:Built-Using} substvar.
> >
> > This makes it possible to track packages mentioned in the EXTRA_PACKAGES
> > variable (currently set to "bf-utf-source syslinux"). Thanks to Ansgar
> > Burchardt for the reports (Closes: #696418, #700026).
> >
> > Note: Unknown packages are ignored, so architecture-specific packages
> > shouldn't be a problem.
> >
> > Acked-by: Ian Campbell <ijc@debian.org>
> > Signed-off-by: Cyril Brulebois <kibi@debian.org>
> >
> > I lost track of Karsten's objection here:
> > https://lists.debian.org/debian-boot/2015/02/msg00012.html
> >
> > so here's a bug report to try and get that fixed instead of just
> > reverting the said commit. (Funny how things that shouldn't be an issue
> > turn out to be one…)
> >
> > It's indeed sad that I only tested the case of an entirely inexistent
> > package and didn't think about the funny not-available-on-all-archs
> > packages…
> >
> > Maybe we could iterate over the packages mentioned there, calling
> > dpkg-checkbuilddeps with its -d flag to see if the relevant packages are
> > relevant? Another idea might be to use Dpkg::Deps to figure out whether
> > some package is relevant for the current architecture? Any other ideas?
> >
> > I'd happily take patches here, as I'm busy with other bugs.
>
> Karsten, I can't seem able to reproduce that in an armhf sid chroot on
> harris.debian.org… Any clues? I'd like to upload src:debian-installer
> really soon, and that's the only thing remaining for now.
I have run some further tests in the meantime. Those have shown
that the effect happens on my local armhf build box when I build
"by hand", but not when I use pbuilder.
The significant difference between both is that I have arch:all
packages built by the syslinux source package (isolinux and
syslinux-common) installed on my system, but not in the chroot
used by pbuilder. If I uninstall those arch:all packages, the
effect does not occur anymore. This means that building on a
buildd will probably be safe for now, but if one architecture
should in the future add a built-using for an arch-specific
package, whose source also builds some arch:all package that is a
build-dependency of the installer on another platform, the
problem would probably crop up on the buildds as well. With the
current setup, I think the chance that this will actually happen
in the forseeable future is rather low, but it would of course be
better to find a "proper" solution for the issue.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: