Hi. The cross toolchains now in unstable (for instance
https://tracker.debian.org/pkg/cross-gcc-4.9-armhf) have Build-Depends
on both the host and target architecture. This was not supported by
wanna-build, and a patch series to add this support is available here:

http://anonscm.debian.org/cgit/users/dkogan-guest/wanna-build.git/

I developed and tested these by setting up a wanna-build instance as
described here:

https://wiki.debian.org/DebianWannaBuildInfrastructureOnOneServer
https://wiki.debian.org/SetupBuildServiceForWanna-build

The setup also required a patch posted earlier:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765111

I suspect this extra patch is only required because of my specific
setup, since presumably wanna-build has been working just fine in the
wild.

On my test box I see wanna-build refuse to set a cross-gcc source
package to Needs-Build unless all Build-Depends are satisfied, both
native and foreign. This is the test of basic functionality, and it
appears to work. I'll run more thorough tests if somebody has specific
requests along those lines.

* Dima Kogan (dima@secretsauce.net) [150514 10:55]:

Thanks for the patches.  This contains two distinct set of patches,
some are code-cleanup, some are for foreign-arch build-deps.


Cleanup:

4ef0ff57c54982ea6eeb84fea1eadafdded3ee61
e19894f7c02b7fc5b65cd2d0bba980ff4b19defb
AFAIUI these should be applicable independend of the foreign-arch
things? (Otherwise the first one looks good to me but my perl is a bit
outdated, the second should if the dose documentation is correct.)



Foreign-Arch:

55f2b48a6d58dfb306a71ac4b588833d129563ca
This breaks semantics of merge-v3 with only two sets of package files.
I need to think a bit more if there are other semantic changes (and if
so if we want them or not).

f3221db8f5ec5b063d87b7ef25f45f224821fc71
First hunk, I would prefer if it would be written so it could be run
on an oldstable machine as well (see the one for vercmp two lines
below), perhaps with a reduced function set. Otherwise same comment as
above applies.



Andi

Hi Andi. Thanks for the reply.

As you saw, there's some cleanup stuff mixed in with the actual
foreign-arch build-dep stuff. I did a rebase so that these aren't
interleaved anymore, and the cleanup can be evaluated somewhat
independently. The build-dep stuff does depend on the cleanup, however.

The new tree lives in a branch:

http://anonscm.debian.org/cgit/users/dkogan-guest/wanna-build.git/log/?h=770925_foreign_arch_bd

Same code as before, with a small, uninteresting bug fix:


I'm not sure what you mean here. If you need something changed once you
think about it more, please tell me.

On oldstable (wheezy) the dose-builddebcheck is too old to support the
foreign-arch stuff. If you want something reasonable to happen with
wheezy too, should we simply not even try to satisfy foreign-arch
build-deps there? If so, then we don't need deps_iterate. Let me know
and I'll put in the appropriate logic

Hi,

Here is a status update on this issue, as I a currently working on it.
This has been merged a few months ago.
This doesn't work, as when passing Packages file from foreign
architectures, this also passes arch:all packages which might be at a
different version than on the native architecture. This would cause
some packages without cross-build-dependencies to be wrongly marked
as needs-build or bd-uninstallable.

I am currently working on an improve triggered code which passes the other
Packages file explicitely. That will also clean up a bit the arch:all
handling code.
This patch looks fine on principle, but the calls to dpkg triggers it to
determine its native architecture, which looks a bit scaring, given we
run it on an amd64 machine, not a buildd. This leads to this error messsages:
| sh: 1: gcc: not found
| wanna-build: warning: couldn't determine gcc system type, falling back to default (native compilation)

This has been merged a few months ago.

This has been merged a few months ago.


I am currently working on this, I really hope to get something working
by the end of the week.

Aurelien

Revisiting this with a concrete case. Debian's chromium package needs a foreign architecture Build-Depends on armhf, to cross-host its linker as a genuine 64-bit process. This is the only approach that has produced a working chrome binary on armhf, after testing the alternatives. Two independent MRs hit the same wall, both validated end to end with real armhf sbuilds:
https://salsa.debian.org/chromium-team/chromium/-/merge_requests/44 (cross-hosted mold: mold:amd64 [armhf] | mold:arm64 [armhf])
https://salsa.debian.org/chromium-team/chromium/-/merge_requests/45 (cross-hosted lld-22: lld-22:arm64 [armhf])
On buildd.debian.org the armhf buildds are the arm64 machines, so the foreign architecture that matters there is arm64.

Same problem the bug was filed for in 2014, cross-toolchain packages needing both host and target architecture dependencies. The current archive has zero packages using the pkg:arch syntax though, current cross-gcc packages avoid it with native "-cross" suffixed packages instead. These two MRs may be the first concrete case for it since then.

What changed since 2015: dose-builddebcheck now has a --deb-foreign-archs option that did not exist when this bug was filed. Tested directly against the real binary (7.0.0-8+b1): a native-only Packages file leaves mold:amd64 unsatisfiable, adding the foreign Packages file with --deb-foreign-archs=amd64 resolves it.

Two small patches, one per layer:

1. bin/wanna-build, wb_dose_builddebcheck(): collect the distinct architectures across the given Packages files, treat the one matching --arch as native and the rest as --deb-foreign-archs. Each file still has to be single-arch, and --arch still has to match one of them. Backward compatible, native-only input generates the same command line as today, including the production shape with the derived build-essential file.

2. triggers/common: after the per-architecture Packages files are built, write Packages.SUITE.ARCH.foreign for each architecture (the Packages file of its foreign architecture, empty where there is none) and pass it in the dose group of the three merge-v3 invocations. The mapping is one case statement, armhf -> arm64 for now.

Validated end to end against a real local wanna-build instance, not just the dose binary in isolation: a test source with a foreign Build-Depends goes from BD-Uninstallable to needs-build once the foreign Packages file is added, unpatched binary stays at BD-Uninstallable as a regression check.

Architecture:all packages, your 2015 point: dose-builddebcheck satisfies a Build-Depends from whichever Packages file has a qualifying version, so if the native and the foreign file disagreed on an arch:all version, the native build could be credited with the foreign one. Reproduced with a deliberately skewed pair of files. Two things cover it. The trigger already generates every per-architecture Packages file from the same archive sync in one loop, so they agree by construction. And the foreign file is passed with its Architecture: all stanzas stripped (grep-dctrl), so only the native file ever provides arch:all packages. With that, the skewed case correctly stays BD-Uninstallable. wanna-build itself still does not enforce this, kept as a TODO test.

Patch and tests are on a branch of a fork of wanna-build. Not requesting a merge, Issues and MRs are disabled on this project. Posting here in case it helps:
https://salsa.debian.org/mendezr/wanna-build/-/tree/foreign-arch-build-depends

Tests: a new tests/foreign-arch-bd.t on the existing WBTest harness covers native-only, native plus one and two foreign files, the production file shape (main plus build-essential plus foreign), identical arch:all duplicates, the stripped foreign file, and the rejected inputs (mismatched --arch, mixed-architecture file). Full suite passes, 118 tests.

This seems to just be AI output without a human actually making a point.
We have no intention to add foreign architectures to builds at this
point in time.

Kind regards
Philipp Kern