On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote: > Colin Watson wrote... > > On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote: > > > That's a good theoretical argument. But in practice, I think the subset > > > of architectures for which bar works correctly will always include > > > amd64, and John D. Rebuilder will have access to such a box for sure. > > > > We know this not to have been the case in the past. > > https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of > > palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).
I see two problems in that code: * it's Launchpad-specific * it supports only a single build-indep architecture rather than a list The latter has next to no practical effect, but I still feel it wrong to knowingly write incomplete metadata when it'd be trivial to do it right. As the code has to be rewritten for DAK/w-b/etc anyway, and the XS- prefix can't be used because it's officially "unofficial", I propose the new field to be a list per the usual architecture syntax. > > (People often suggest cross-compiling for this, and that can certainly > > be a good solution in some cases, but please bear in mind that in the > > general case that still only reduces the problem to "can only build on > > architectures where somebody's uploaded the necessary cross tools".) > > That's a slightly different scenario since I'm just about to rebuild > arch:all packages, so there's no need for cross tools. Any arch:all package that ships some kind of BIOS/etc does require either specific-native or cross tools. Having qemu and co depend on ten or so foreign arch packages, some from second-class archs, is not a good idea. > > There is currently one package in the Debian archive (pixfrogger) that > > declares "Build-Indep-Architecture: i386" in its .dsc because, even > > though it builds an architecture-independent binary package, building it > > requires a package that's only available on 32-bit architectures. Isn't this what dose3 is employed for? I'd expect it to notice the build-deps are uninstallable on amd64, and move it to a (non-existant) i386/armhf/... arch:all buildd. If manually specifying that is needed, pixfrogger is another case that should declare a list rather than a single arch: i386 is basically gone other than hardware emulation on amd64, armhf is a better supported 32-bit arch these days (at least counting porters and new gear). > *That* is really helpful as it provides a generic solution for my > problem: The maintainer can provide an architecture hint for any > rebuilder. Is there a more formal specification around? I understand > the comment in the diff[0] the header may carry a list of > architectures, not just just a single one. That's the right thing. > > [0] > http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py My cursory reading of code that deals with the actual field disagrees, but that's moot as the code can't be applied to Debian without a rewrite. > > As I allude to in > > https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the > > best answer is for Debian's buildd infrastructure to follow through on > > implementing Build-Indep-Architecture. > > Seems reasonable. My intention is rather to make the life easier for > folks downstream, like rebuilding and backports. And derivatives, most of which build only a subset of architectures, sometimes just one, like Rasbian (armhf only). > As there's a workaround available now, I feel less reluctant to reveal > the real packages: "foo" is 3270font, "bar" is fontforge | > fontforge-nox. The bugreport for the latter is #831425. With my 3270font maintainer hat on: I wouldn't even know of this if not for the reproducible builds project, despite doing lots of rebuilds on various architectures (albeit not really for this package). I guess there's a lot of other arch-dependant failures for arch:all packages. -- A true bird-watcher waves his tail while doing so.
