Bug#795079: stretch-pu: package iceweasel/38.1.1esr-1~deb9u1

[Simon McVittie]

On 12/08/15 10:40, Julien Cristau wrote:
> sadly the tpu build on armhf failed, log at
> https://people.debian.org/~jcristau/iceweasel_38.1.1est-1~deb9u1_armhf.log.txt

It looks as though this is the logic in debian/upstream.mk (to deal with
backports in an automated way), combined with the fact that the
Mozilla-provided replacement build system for the bundled libvpx doesn't
actually compile on armhf due to an assumption made in
media/libvpx/moz.build.

I compared your build log with a successful build in sid,
<https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=armhf&ver=38.1.1esr-1&stamp=1438939440>.
Both have libvpx-dev_1.4.0-4 installed.

In the successful build, the system libvpx is selected
(-DMOZ_NATIVE_LIBVPX=1).

In the failing build, the bundled libvpx is selected instead
(-DMOZ_NATIVE_LIBVPX=) resulting in compilation of the bundled
bilinearpredict_neon.c, which for some reason is explicitly compiled
with -mfloat-abi=softfp in media/libvpx/moz.build. That won't work on a
pure armhf system because it tries to include <gnu/stubs-soft.h>, which
only exists on softfloat (armel).

This seems to be because debian/upstream.mk sets BACKPORT to 1 based on
my choice of version number, and debian/rules responds by setting
LESS_SYSTEM_LIBS to 1, resulting in the use of a bundled nspr, nss,
sqlite and vpx.

The shortest path to a working t-p-u build is probably to version it
38.2.0esr-1~stretch (or something) instead of ~deb9u1. Does that make sense?

    S