Fix wrong-arch issues in crossbuild of libnih

[Wookey]

libnih1.0.3-4ubuntu15 gained cross-build support which is great, but it has a couple of things wrong.

The first is simple and trivial to fix. A BUILD/HOST typo in configure. Which causes it to fail to find dbus-1, because it used the build-arch pkgconfig. This probably wasn't previously noticed due to the work-around decribed of installing both build-arch and host-arch build-deps.

The second is trickier. It tries to run tests using nih-dbus-tool, even is DEB_BUILD_OPTIONS=nocheck is set. These fail because nih-dbus-tool is the wrong arch. Oddly the rules file contains NIH_DBUS_TOOL=$(CURDIR)/build-dbus-tool/nih-dbus-tool/nih-dbus-tool, when cross-building, to carefully set this to use the version which has been built. This will of course not run unless qemu is available for the host arch (it isn't for arm64). It maybe that the above plus the dh_auto_configure -B build-dbus-tool/ --host=$(DEB_BUILD_GNU_TYPE) was intended to build this too for the build arch, but then the wrong-arch nih-dbus-tool file ends up in the nih-dbus-tool package, does it not? It would need to be built twice, once for each arch for this to work.

Ideally DEB_BUILD_OPTIONS=nocheck would simply stop these targets being run, and 'make all-am' instead of 'make all' seems to do this. I suspect that the tests aren't being run in fact, just built, but that fails because it uses this tool - not sure. I failed to discern exactly what the right rune for 'don't try to build/run the tests' is in dh_foo-speak, so instead elected to set NIH_DBUS_TOOL to use the build-arch tool. This works fine. Enforcing this build-dep needs a :native so can't be done for the time being, but I see the package already has some of those pending.

Finding the right rune to make DEB_BUILD_OPTIONS=nocheck skip this might be a better fix.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "libnih-1.0.3-4ubuntu15-crossbuild.patch" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Dimitri John Ledkov (xnox)]

I disagree with this fix.

cjwatson, infinity and I have extensively discussed this.

We do not want to introduce circular build-dependency in the libnih package. (e.g. we do not want libnih source package depend on binary packages that it builds, even with :native suffix).

There is no typo, with respect to host/build arches.

In the first configure & build call we build nih-dbus-tool for the current architecture where the build is happenning (build-arch & native compilation).
In the second call, we cross-compile libnih using the nih-dbus-tool we just build for the native compilation in step one.

So in actual fact we do compile twice (native & cross). And the documented build-dependencies is not a "work-around", but are intended to be there, once there is support for :any and :native in sbuild/wanna-build.

The remaining bit is to check, whether the package as currently packaged as of -4ubuntu15 correctly honours nocheck.

Review: Disapprove.

[Dimitri John Ledkov (xnox)]

Verified that package correctly cross-builds, if all build-dependencies are installed (Build-Depends + libdbus-1-dev:native (>= 1.4), libexpat1-dev:native (>= 2.0.0)). Even without nocheck set.

[Wookey (wookey)]

OK. confirmed that this does indeed work for me too on arm64. However in order to make this automatable, we need dpkg checkbuilddeps to understand :any/:native. (apt already understands and does the hard bit of installing the right packages, but then dpkg complains that build-deps are not satisfied and spoils things).