Control: tag -1 + moreinfo unreproducible Hi,
On Sun, 06 Jan 2013 20:03:32 +0000 Ian Campbell <[email protected]> wrote: > I'm using sbuild with foreign chroots via qemu-*-static as described in[0]. > I've noticed that in my armel and armhf chroots amd64 is present as a foreign > arch within the chroot. > > This means that when sbuild does the apt update/upgrade dance it is > downloading/uncompressing/processing a second set of architecture package > lists > using the emulated binaries. It would be better to avoid such unnecessary work > in this case because of the emulation overheads. I've also got amd64 as a > foreign arch in my i386 chroot but that is less of a worry. > > The foreign arch configuration doesn't appear to be added (i.e. it is already > there) when I run "sbuild --arch=armel" and I've found that it is present in > the source chroots too. I logged into the source chroot and "dpkg > --remove-architecture amd64" and it is not added back by sbuild. I think that > sbuild-createchroot must have added it. > > sbuild-createchroot uses Sbuild::AptResolver, I wonder if it could be that via > an interaction with c89125965a15 "Sbuild::ResolverBase: Configure dpkg > foreign-architecture"? sbuild-createchroot seems to set HOST_ARCH but not > TARGET_ARCH and the distinction between the two is is used in that changeset. > > I'm running 0.63.2-1 but I can't see any change in the git tree which seems > relevant. > > I've been round all my chroots and run dpkg --remove-architecture and AFAICT > things seem OK (although I've only tried one or two builds). I'm unable to reproduce your findings: $ sudo sbuild-createchroot --arch=i386 unstable tmp http://httpredir.debian.org/debian $ sudo chroot tmp dpkg --print-architecture i386 $ sudo chroot tmp dpkg --print-foreign-architectures $ Can you confirm that the problem doesn't exist anymore? Thanks! cheers, josch
signature.asc
Description: signature
