Package: firefox
Version: 81.0-2
Severity: wishlist
It would be useful if firefox (but not -esr) ran the upstream test suite
for SpiderMonkey (js) on buildds, ideally with failures causing FTBFS.
Otherwise, the GNOME team (which needs to repackage -esr versions of
mozjs for gjs, on a cycle that is driven by GNOME rather than Mozilla)
gets this anti-pattern:
* mozjs does low-level things that frequently introduce portability
regressions
* upstream only tests and supports non-exotic architectures
* each new -esr release of mozjs breaks ABI, which means we have to give
it a new SONAME, which means it has to go through NEW
* until it has left NEW, it isn't routinely built on the full zoo of
exotic architectures
* architecture porters have no idea anything is wrong, because from their
perspective, everything is building successfully
* this means we can only start fixing regressions when it leaves NEW, by
which time it's holding up new versions of GNOME
In the mozjs* family of packages, we run build-time tests and consider
most failures to be fatal, because we've found that if we don't, in
practice mozjs won't actually work, causing FTBFS further down the line
in gjs or in packages that happen to use gjs.
If firefox runs the tests, the cost is that it will take longer for new
versions to become available, particularly on slow architectures. However,
firefox (non-esr) is only in unstable and deliberately kept out of testing
anyway, so that seems maybe not so bad?
We've found that it's necessary to skip a few tests where Mozilla
upstream makes assumptions that are not true in Debian. Some notable
examples:
* Mozilla specifically does not support non-SSE x86 CPUs, but Debian's
i386 architecture baseline demands that we must, so some tests fail as
a result of i387's excess precision and need to be skipped
* Mozilla specifically does not support ARM softfloat, but Debian armel
does, so again we have to skip a few tests that make assertions about
the finer points of floating-point behaviour
* Debian has some 64-bit architectures that Mozilla hasn't heard of, so
tests that take an arbitrarily long time on 64-bit need to be skipped
on more architectures
To support that, I've added some infrastructure in mozjs78's
debian/patches/ to be able to skip tests selectively according to facts
about dpkg-architecture - for example to be able to skip a test on all
the big-endian architectures.
The GNOME team are not Mozilla ecosystem specialists, and I definitely
don't know what I'm doing (I'm only working on mozjs because someone
has to and nobody else did), so some of our patches are definitely just
hacks - if anyone with a better grasp of the Mozilla ecosystem can replace
our hacks with something better they are more than welcome to do so!
Thanks,
smcv
