Debian Bug report logs - #873778
mozjs52: FTBFS on big-endian: interpreter silently exits 1 ("Failed to test XUL condition")

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Aaron M. Ucko" <ucko@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: mozjs52: FTBFS: Failed to test XUL condition

Date: Wed, 30 Aug 2017 22:30:14 -0400

Source: mozjs52
Version: 52.3.1-3
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of mozjs52 for several platforms failed with similar errors, as
detailed at
https://buildd.debian.org/status/logs.php?pkg=mozjs52&ver=52.3.1-3 and
excerpted below.

Could you please take a look?

Thanks!

On armel:

    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 143, in _parse_one
      if xul_tester.test(cond):
    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 110, in test
      cond, out, err))
  Exception: Failed to test XUL condition 'Android'; output was '', stderr was 'Assertion failure: !joinable(), at /<<PKGBUILDDIR>>/js/src/threading/Thread.h:122\n'

On mips, s390x, and the non-release architectures powerpc and sparc64:

    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 143, in _parse_one
      if xul_tester.test(cond):
    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 110, in test
      cond, out, err))
  Exception: Failed to test XUL condition 'Android'; output was '', stderr was ''

On the non-release architecture ppc64:

    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 134, in _parse_one
      if xul_tester.test(cond):
    File "/<<PKGBUILDDIR>>/js/src/tests/lib/manifest.py", line 110, in test
      cond, out, err))
  Exception: Failed to test XUL condition '!xulRuntime.shell'; output was '', stderr was ''

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #10 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: 873778@bugs.debian.org

Subject: Fix for the mozjs52 build on armel

Date: Mon, 4 Sep 2017 14:45:51 +0300

Changes in this patch:

1. Remove --disable-methodjit, option is no longer available.

Sync compiler flags from firefox-esr:

2. Use -fno-schedule-insns also on armel.

3. Use "-fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks"
   on all architectures.


--- debian/rules.old	2017-08-31 18:18:31.094300763 +0000
+++ debian/rules	2017-09-04 09:31:01.891585720 +0000
@@ -12,22 +12,19 @@
 
 SRCDIR = $(CURDIR)/js/src
 
-ifeq ($(VENDOR), Debian)
-ifneq (,$(findstring $(DEB_BUILD_ARCH),armel))
-        CONFIGURE_FLAGS += --disable-methodjit
-endif
-endif
-
 ifeq ($(VENDOR), Ubuntu)
 ifneq (,$(findstring $(DEB_BUILD_ARCH),armel armhf))
         CONFIGURE_FLAGS += --enable-thumb2
 endif
 endif
 
-ifneq (,$(findstring $(DEB_BUILD_ARCH),armhf))
-        export DEB_CFLAGS_MAINT_APPEND = -fno-schedule-insns
-        export DEB_CXXFLAGS_MAINT_APPEND = -fno-schedule-insns
+DEB_CFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks
+DEB_CXXFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks
+ifneq (,$(findstring $(DEB_BUILD_ARCH),armel armhf))
+        DEB_CFLAGS_MAINT_APPEND += -fno-schedule-insns
+        DEB_CXXFLAGS_MAINT_APPEND += -fno-schedule-insns
 endif
+export DEB_CFLAGS_MAINT_APPEND DEB_CXXFLAGS_MAINT_APPEND
 
 %:
 	dh $@ --sourcedirectory=$(SRCDIR) --with gnome,pkgkde-symbolshelper --without autoreconf


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #15 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Jeremy Bicha <jbicha@ubuntu.com>

To: Adrian Bunk <bunk@debian.org>, 873778@bugs.debian.org

Subject: Re: Bug#873778: Fix for the mozjs52 build on armel

Date: Tue, 5 Sep 2017 04:15:29 -0400

On Mon, Sep 4, 2017 at 7:45 AM, Adrian Bunk <bunk@debian.org> wrote:
> Changes in this patch:

Thanks. Uploading that patch now with 52.3.1-4 but not closing this
bug since there are other issues remaining here.

Jeremy Bicha

Message #20 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: 873778@bugs.debian.org, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: Fix for the mozjs52 build on armel

Date: Sat, 23 Sep 2017 12:29:08 +0200

Control: retitle -1 mozjs52: FTBFS on big-endian: Exception: Failed to test XUL condition 'Android'; output was '', stderr was ''

On Tue, 5 Sep 2017 04:15:29 -0400 Jeremy Bicha <jbicha@ubuntu.com> wrote:
> On Mon, Sep 4, 2017 at 7:45 AM, Adrian Bunk <bunk@debian.org> wrote:
> > Changes in this patch:
> 
> Thanks. Uploading that patch now with 52.3.1-4 but not closing this
> bug since there are other issues remaining here.

The remaining problem seems to be a big-endian issue (mips, s390x,
hppa, powerpc, sparc64). ppc64 fails in a slightly different manner,
might just be it's failing earlier for a different reason but would
also suffer from this bug.

Let's track the mips64el failure in a different bug, as it's
completely different from this.

Cheers,
Emilio

Message #27 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 873778@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>, Laszlo Boszormenyi <gcs@debian.org>

Subject: Re: Bug#873778: Fix for the mozjs52 build on armel

Date: Sun, 1 Oct 2017 19:03:46 +0100

Control: clone -1 -2
Control: retitle -2 FTBFS on mips64el: various test failures

On Sat, 23 Sep 2017 at 12:29:08 +0200, Emilio Pozuelo Monfort wrote:
> Let's track the mips64el failure in a different bug, as it's
> completely different from this.

Cloned away. I haven't investigated those failures at all.

> The remaining problem seems to be a big-endian issue (mips, s390x,
> hppa, powerpc, sparc64). ppc64 fails in a slightly different manner,
> might just be it's failing earlier for a different reason but would
> also suffer from this bug.

I traced into this a bit and came to the same conclusion. It turns out
the failure mode is that the embedded code copy of libicu v58 fails
to initialize, because the embedded binary copy of the ICU data is
hard-coded to be the little-endian one by the build system (also it's
bundled in the source package rather than being built from source),
and at runtime libicu insists on its data files being of equal endianness.

This results in ./js/src/js/src/shell/js silently exiting 1 because
it makes no attempt at error reporting during initialization (insert
table flip here). ./js/src/js/src/shell/js is the standalone JavaScript
shell, similar to /usr/bin/js24 and analogous to /usr/bin/gjs-console - it
isn't installed any more in mozjs52 (I don't think) but it's still built
and used for build-time testing.

It is correct that this is release-critical, because it makes mozjs
completely useless on the affected architectures, as far as I can see.

To be less nasty to debug, I suspect the dh_auto_test override should
do something like this:

	./js/src/js/src/shell/js -e 'print("hello, world") || { \
		echo "js shell doesn't appear to work"; \
		exit 1; \
	}

before it even attempts to run upstream tests - and it should probably
try this even on architectures where the full test suite is skipped or
known-broken, because, again, if this fails then mozjs being available
is just a trap for the unwary.

These Firefox changes look promising:
https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/patches/debian-hacks/Allow-to-override-ICU_DATA_FILE-from-the-environment.patch
https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/log/?qt=grep&q=endian
although unfortunately the standalone mozjs doesn't have this:
https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/intl/icu_sources_data.py
so we would need to insert a copy.

If libicu v59 (currently in experimental) is going to be uploaded to
unstable soon, then we might be able to reduce the level of wtf by using
the system libicu instead. Laszlo, what are your plans for icu v59?

Regards,
    smcv

Message #34 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Simon McVittie <smcv@debian.org>, 873778@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>

Cc: Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: Fix for the mozjs52 build on armel

Date: Sun, 1 Oct 2017 23:36:52 +0200

[Message part 1 (text/plain, inline)]

Am 01.10.2017 um 20:03 schrieb Simon McVittie:
> Control: clone -1 -2 Control: retitle -2 FTBFS on mips64el: various
> test failures
> 
> On Sat, 23 Sep 2017 at 12:29:08 +0200, Emilio Pozuelo Monfort wrote:
>> Let's track the mips64el failure in a different bug, as it's 
>> completely different from this.
> 
> Cloned away. I haven't investigated those failures at all.
> 
>> The remaining problem seems to be a big-endian issue (mips, s390x, 
>> hppa, powerpc, sparc64). ppc64 fails in a slightly different
>> manner, might just be it's failing earlier for a different reason
>> but would also suffer from this bug.

[..]

Fwiw, we had on #debian-gnome the other
day, where we also identified the icu data file as a culprit.
Unfortunately that alone doesn't fix the s390x build. Pulling the
patches from firefox-esr (especially the s390x atomics patch), get's us
down to 10 unexpected test-suite failures on s390x.
As you already found out though is, that generating the icu data file is
not easily possible, as the mozjs package seems to miss the
tools/scripts to do so.

Anyway, copying the full IRC log for completeness sake


> [00:09:22] <mbiebl_> so, what's going to happen with mozjs? Any progress on that front?
> [00:39:02] <jbicha> get permission to ignore the build failures on mips & s390x?
> [01:03:37] <mbiebl_> has firefox/mozja or mhommey been notified about this?
> [01:15:40] <jbicha> I haven't talked to mhomney about mozjs
> [01:16:31] <jbicha> I believe ptomato (the gjs maintainer) knows about our build issues on others arches
> [01:34:20] <mbiebl_> jbicha: I see that the firefox-esr package as specific rules for big/little endian
> [01:35:36] <mbiebl_> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n142 ff
> [01:35:49] <mbiebl_> pochu suspected an endian issue, right?
> [01:36:46] <mbiebl_> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n285
> [01:38:02] <mbiebl_> I wonder if we shouldn't simply use firefox-esr as basis for building the mozjs library
> [01:38:28] <mbiebl_> maybe we could convince mike to provide a bit of debian/rules magic which would disable the non-mozjs parts
> [01:39:02] <mbiebl_> and we simply reupload src:firefox-esr with a different source name
> [01:40:11] <mbiebl_> building libmozjs directly from src:firefox-esr is probably not a good idea, given that stable get's new major updates of it
> [01:41:24] <mbiebl_> somehow it would be awesome though to benefit from mike's experience and knowledge with the firefox package
> [01:41:29] <jbicha> Ubuntu 17.04's mozjs38 actually uses the final Firefox 38 ESR tarball because Mozilla has so far been pretty bad about making mozjs releases
> [01:41:38] <bunk> mbiebl_: The architectures with the "Exception: Failed to test XUL condition" error are the big endian architectures except m68k/powerpcspe (build with nocheck).
> [01:42:01] <jbicha> I stripped the tarball down because the full tarball is very slow to work with
> [01:42:02] <bunk> mips64el looks unrelated.
> [01:42:35] <jbicha> I believe mips64el is a minor issue we can easily work around
> [01:45:38] <mbiebl_> jbicha: I suppose that 17.04 does not directly build the libmozjs binary packages from src:firefox-esr but uses a different src package name?
> [01:46:35] <jbicha> yes, it uses a slightly different version of https://anonscm.debian.org/git/pkg-gnome/mozjs38.git which is just an older version of our mozjs52 packaging
> [01:46:45] <jbicha> Ubuntu does not offer firefox-esr
> [02:10:36] <bunk> the be icu from firefox-esr seems to be a bingo
> [02:10:52] <bunk> I'm now getting further with mozjs52 on s390x
> [02:12:58] <mbiebl_> further as in the test-suite passes and you get a .deb or the test-suite fails at a later point?
> [02:14:31] <bunk> the test suite starts (I have to double-check the unexpected failures with a clean build)
> [02:22:33] <mbiebl_> bunk: glandium also pointed me to https://sources.debian.net/patches/firefox-esr/52.3.0esr-2/porting/Fix-crashes-in-AtomicOperations-none-on-s390x.patch/
> [02:24:06] <jbicha> that patch alone didn't help on Ubuntu but maybe in combination with other stuff…
> [02:26:10] <jbicha> Ubuntu hasn't been able to build Firefox on s390x in like a year
> [02:27:39] <mbiebl_> glandium also suggests to disable jit on mips*
> [02:30:37] <mbiebl_> he advises against using src:firefox-esr as a basis to build the libmozjs libraries
> [02:31:05] <mbiebl_> but we should have a look at the patches he ships in firefox-esr which touch src/js
> [02:31:17] <mbiebl_> js/src, I mean
> [02:58:58] <bunk> counting TEST-UNEXPECTED-FAIL:
> [02:59:04] <bunk> ppc64el: 2
> [02:59:08] <bunk> mips64el: 3
> [02:59:14] <bunk> s390x (icu): 104
> [02:59:19] <bunk> s390x (icu+atomic): 10
> [02:59:24] <bunk> s390x (icu+atomic+gcc-6): 10
> [03:07:18] <jbicha_> there's an unofficial 52.4 release we could grab too
> [10:31:31] <bunk> FTR, what I used for "the be icu" was cp firefox-esr-52.4.0esr/config/external/icu/data/icudt58b.dat ./mozjs52-52.3.1/config/external/icu/data/icudt58l.dat
> [10:34:48] <bunk> adding s390x to the list of architectures where test results are ignored gives me a successful build with debs
> [12:19:40] <bunk> --with-system-icu works (requires libicu-dev from experimental), increases TEST-UNEXPECTED-FAIL to 11
> [12:23:21] <bunk> --with-system-icu plus build-dependency on libicu-dev (>= 58.1-1) might be worth an upload to experimental for getting the data how good or bad that looks on all architectures?
> [12:59:04] <mbiebl> bunk: we should get mozjs to unstable as fast as possible
> [12:59:24] <mbiebl> waiting for libicu doesn't really help there
> [14:22:48] <mbiebl> jbicha: where can I find the tarball for the 52.4.0 release?
> [14:23:12] <jbicha> https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52&filter-searchStr=sm-tc
> [14:23:25] <jbicha> click 'pkg' next to SM-tc
> [14:23:43] <jbicha> and there is a pop-up thing that shows a .tar.bz2
> [14:24:18] <jbicha> when they make an official release, it should show up at https://archive.mozilla.org/pub/spidermonkey/releases/
> [14:25:15] <jbicha> but it's unclear to me what they're waiting on, I think mozjs52 is already better than 38 or 45 would have been
> [14:25:17] <jbicha> https://bugzilla.mozilla.org/show_bug.cgi?id=1379541
> [14:25:50] <mbiebl> https://queue.taskcluster.net/v1/task/KTEaR3U6T5a0X6O5swInPw/runs/0/artifacts/public/build/mozjs-52.4.1.tar.bz2 ?
> [14:26:11] <jbicha> yes
> [14:30:50] <jbicha> it'll be nice to have an official release, there are several tarballs on different dates on treeherder that claim to be 52.3.1
> [14:43:24] <jbicha> mbiebl: here's a git mirror if you wanted to see what commits were happening for mozjs52
> [14:43:26] <jbicha> https://github.com/mozilla/gecko-dev/commits/esr52/js/src
> [14:53:56] <mbiebl> jbicha: it seems with the be/le fix the builds get significantly further, down to a few unexpected test failures
> [14:54:18] <mbiebl> (including the js/src patches from firefox)
> [14:54:33] <jbicha> mbiebl: great, do we want to just ignore the tests on those architectures for now?
> [14:54:37] <mbiebl> my proposal would be to update to 52.4.1 (as you suggested)
> [14:54:49] <mbiebl> pull all firefox patches touching js/src
> [14:55:00] <mbiebl> apply the be/le fix from firefox
> [14:55:08] <mbiebl> upload that again
> [14:55:36] <mbiebl> see how it goes and if it confirms bunks results
> [14:55:57] <mbiebl> we ignore the test results for those archs
> [14:56:04] <mbiebl> but we file bug reports tracking that
> [14:56:21] <mbiebl> do you have access to the upstream bug tracker / know who to contact?
> [14:56:33] <mbiebl> I have to say the mozilla infra is kinda a maze
> [14:56:40] <mbiebl> finding stuff there is ... hard
> [14:58:05] <jbicha> you can talk to ptomato in #javascript on irc.gnome. I think the dev channel is #js on irc.mozilla.org
> [14:58:37] <jbicha> https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Core|JavaScript%20Engine
> [15:00:01] <jbicha> ptomato also referred me to https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial
> [15:00:52] <jbicha> but that seems a bunch of work to set all that up
> [15:01:10] <jbicha> but maybe the "I'm all used to git" section isn't too bad
> [15:03:47] <jbicha> 2 of the 3 mips64el test failures should be fixed with sfink's patch at https://bugzilla.mozilla.org/show_bug.cgi?id=1401319
> [15:09:08] <jbicha> mbiebl: that plan sounds great to me
> [15:12:50] <mbiebl> hm, unfortunately mozjs doesn't ship the icu_sources_data.py script
> [15:23:32] <mbiebl> jbicha: he, we could build-depend on firefox-esr and copy the file from there: /usr/lib/firefox-esr/icudt58l.dat
> [15:24:43] <jbicha> if you do, add an alternate build-depends on Firefox since Ubuntu doesn't have firefox-esr
> [15:25:30] <mbiebl> that's only half serious
> [15:26:06] <mbiebl> what a f* mess
> [15:26:21] <jbicha> the number keeps changing too, it's icudt59l.dat with my Firefox 57 Beta
> [15:28:37] <mbiebl> mozjs has been a pile of problems from day 1
> [16:13:55] <bunk> jbicha: that's the ICU version number (see the version of libicu-dev)
> [16:58:32] <mbiebl> bunk: the only idea I have atm is to ship a copy of /usr/lib/firefox-esr/icudt58b.dat in src:mozjs and use that to replace icudt58l.dat during build
> [16:58:40] <mbiebl> (which is basically what you did afaics)
> [16:59:23] <bunk> mbiebl: that would be a DFSG-violation
> [16:59:40] <mbiebl> not really
> [16:59:48] <mbiebl> and I don't really care, tbh
> [17:00:06] <bunk> mbiebl: What's wrong with using libicu-dev?
> [17:03:13] <mbiebl> not having a recent enough version in unstable for example?
> [17:09:54] <mbiebl> bunk: btw, I don't care because the existing ./config/external/icu/data/icudt58l.dat would be a DFSG violation as well then
> [17:11:23] <jbicha> (Ubuntu 17.10 won't have a new enough version of icu either)
> [17:13:37] <bunk> jbicha: Does anyone care about mozjs52 on s390x in Ubuntu 17.10 ?
> [17:15:21] <jbicha> no, but if we can get gjs to compile there, it would be a bit nicer
> [17:15:49] <bunk> Another related question: Will mozjs in stable be supported by following upstream like firefox-esr, or is this NSA-enablement?
> [17:16:23] <jbicha> nsa?
> [17:17:16] <bunk> National Security Agency
> [17:17:28] <bunk> see: Snowden, Edward
> [17:17:31] <jbicha> GNOME has been using mozjs since 3.0 years ago
> [17:17:52] <jbicha> but there were 2 sessions at GUADEC discussing this issue
> [17:18:15] <mbiebl> a local js engine does not have the same attach vector as a browser
> [17:18:30] <jbicha> Ubuntu is going to try to update to newer mozjs versions for 18.04 LTS
> [17:18:52] <bunk> So passing untrusted contents to mozjs will be a CVE in GNOME?
> [17:19:14] <jbicha> RHEL is now shipping full GNOME stack upgrades in its point releases so they've fixed the problem more or less for themselves
> [17:20:05] <bunk> What does Ubuntu plan for its default desktop?
> [17:20:09] <jbicha> RHEL 7.4 uses GNOME 3.22 (7.0 used GNOME 3.8)
> [17:21:01] <jbicha> I believe the current plan is that we're going to try to update gjs/mozjs for 18.04 LTS without updating all of GNOME
> [17:21:42] <bunk> so following firefox-esr
> [17:22:10] <bunk> ok, in that case libicu-dev is not an option


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #39 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Michael Biebl <biebl@debian.org>, 873778@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: mozjs52 on s390x and other big-endian machines

Date: Mon, 9 Oct 2017 10:36:52 +0100

On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
> >> The remaining problem seems to be a big-endian issue (mips, s390x, 
> >> hppa, powerpc, sparc64). ppc64 fails in a slightly different
> >> manner, might just be it's failing earlier for a different reason
> >> but would also suffer from this bug.

Here is some work-in-progress on this:

https://anonscm.debian.org/git/users/smcv/mozjs52.git

I've made it regenerate the data file on both endiannesses in the hope
that this will make us more likely to catch errors. The generated file
on little-endian is not the same as the pregenerated one :-(

This is only build-tested on x86_64 at this point, not runtime-tested.

I'm a little concerned that when mips(el) are dropped from Debian in
favour of mips64el (which I believe is the mips porters' long term plan?),
s390x will be the only big-endian release architecture, which doesn't
seem particularly sustainable - few DDs understand that architecture,
and given its category of hardware, probably none will ever own one.

> > [17:18:15] <mbiebl> a local js engine does not have the same attach vector as a browser
> > [17:18:52] <bunk> So passing untrusted contents to mozjs will be a CVE in GNOME?

GNOME applications that want a web engine capable of interpreting normal
HTML/CSS/JS from the Internet use WebKit, not mozjs52.

The major user of mozjs52 is gjs. Passing untrusted JavaScript to gjs
would definitely be CVE-worthy, regardless of mozjs' code quality, because
gjs has full user privileges and can call arbitrary GObject-Introspection
APIs: passing untrusted JavaScript to it would be equivalent to passing
untrusted Python, Perl, Ruby or shell script to their respective
interpreters. gjs is used by GNOME Shell (and its extensions), GNOME
Sushi and Polari, which are all trusted apps that happen to be partially
or entirely written in JS: JS as programming language, rather than JS
as web content.

polkit (PolicyKit) in experimental currently uses mozjs 1.8.5, but should
eventually move to mozjs52. Again, this is entirely trusted: the ability
to install polkit rules is equivalent to the ability to install sudoers.d
fragments, and it would already be a serious security vulnerability if
a non-root-equivalent user could edit or install those rules.

libproxy has a plugin to interpret PAC (proxy auto-config) using mozjs,
currently mozjs 1.8.5. This is at a security boundary, so it might well
be relying on mozjs to be able to interpret untrusted JS safely; but
mozjs52 presumably can't be any worse than mozjs 1.8.5 in that respect?

gxine, mediatomb and oolite also use mozjs 1.8.5 and should probably
move to a newer version eventually. I don't know what they use it for,
but again, mozjs52 surely can't be any worse than mozjs 1.8.5...

    smcv

Message #44 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Michael Biebl <biebl@debian.org>, 873778@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: mozjs52 on s390x and other big-endian machines

Date: Thu, 12 Oct 2017 00:16:32 +0100

On Mon, 09 Oct 2017 at 10:36:52 +0100, Simon McVittie wrote:
> On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
> > >> The remaining problem seems to be a big-endian issue (mips, s390x, 
> > >> hppa, powerpc, sparc64). ppc64 fails in a slightly different
> > >> manner, might just be it's failing earlier for a different reason
> > >> but would also suffer from this bug.
> 
> Here is some work-in-progress on this:
> 
> https://anonscm.debian.org/git/users/smcv/mozjs52.git
> 
> I've made it regenerate the data file on both endiannesses in the hope
> that this will make us more likely to catch errors. The generated file
> on little-endian is not the same as the pregenerated one :-(
> 
> This is only build-tested on x86_64 at this point, not runtime-tested.

The unit tests all pass or are skipped on x86_64 (on barriere).

On s390x (zelenka), I now see meaningful test results, with the unexpected
failures listed below. So something is wrong on s390x in at least a
few cases, but it's basically a functional JavaScript interpreter,
and a lot of the tests pass. That seems a lot better than the current
situation. Good enough for experimental, at least?

-------8<--------

## ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js: rc = 3, run time = 0.025008
ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9 Error: Assertion failed: got 3, expected 0
Stack:
  @ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js | (args: "")

## ecma_6/TypedArray/set-same-buffer-different-source-target-types.js: rc = 3, run time = 0.022477
896116: When setting a typed array from an overlapping typed array of different element type, copy the source elements into properly-sized temporary memory, and properly copy them into the target without overflow (of either source *or* target) when finished
ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11 RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
Stack:
  @ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/set-same-buffer-different-source-target-types.js | (args: "")

## ecma_6/TypedArray/subarray.js: rc = 3, run time = 0.021673
ecma_6/TypedArray/subarray.js:8:26 RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
Stack:
  @ecma_6/TypedArray/subarray.js:8:26
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/subarray.js | (args: "")

## ecma_6/TypedArray/indexOf-and-lastIndexOf.js: rc = 3, run time = 0.023659
ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9 Error: Assertion failed: got 0, expected 8
Stack:
  @ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/indexOf-and-lastIndexOf.js | (args: "")

## ecma_6/TypedArray/sort_snans.js: rc = 3, run time = 0.055719
ecma_6/shell.js:93:23 Error: Assertion failed: got -1.8938930325389462e+304, expected NaN at _[0]
Stack:
  assertSameValue@ecma_6/shell.js:93:23
  check@ecma_6/shell.js:198:21
  assertSameProps@ecma_6/shell.js:162:25
  check@ecma_6/shell.js:213:25
  assertDeepEq@ecma_6/shell.js:221:13
  testFloat64NaNRanges@ecma_6/TypedArray/sort_snans.js:60:5
  @ecma_6/TypedArray/sort_snans.js:68:1
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/sort_snans.js | (args: "")

## ecma_6/ArrayBuffer/CloneArrayBuffer.js: rc = 3, run time = 0.021813
1264941: CloneArrayBuffer should be called with byteLength of source typedArray
ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7 Error: Assertion failed: got 8, expected 0
Stack:
  test@ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7
  @ecma_6/ArrayBuffer/CloneArrayBuffer.js:27:1
TEST-UNEXPECTED-FAIL | ecma_6/ArrayBuffer/CloneArrayBuffer.js | (args: "")

## js1_8_5/extensions/clone-transferables.js: rc = 3, run time = 0.022512
js1_8_5/extensions/clone-transferables.js:42:17 Error: Assertion failed: got 0, expected NaN
Stack:
  test@js1_8_5/extensions/clone-transferables.js:42:17
  @js1_8_5/extensions/clone-transferables.js:111:1
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-transferables.js | (args: "")

## js1_8_5/extensions/clone-many-transferables.js: rc = -11, run time = 0.783352
 PASSED! ok
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-many-transferables.js | (args: "")
## js1_8_5/extensions/clone-errors.js: rc = -11, run time = 0.03348
 PASSED! ok
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-errors.js | (args: "")

## js1_8_5/extensions/typedarray.js: rc = 0, run time = 0.167332
BUGNUMBER: 532774
STATUS: js typed arrays (webgl arrays)
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:488:5
@js1_8_5/extensions/typedarray.js:17:1

==============
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:489:5
@js1_8_5/extensions/typedarray.js:17:1

==============
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:490:5
@js1_8_5/extensions/typedarray.js:17:1

==============
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:491:5
@js1_8_5/extensions/typedarray.js:17:1

==============
done
 FAILED! [reported from test()] typed array tests : Expected value '0', Actual value '4'

-------8<--------

I think this is probably at a point where it would benefit from someone
who actually knows about JavaScript and/or s390x taking over.

Regards,
    smcv

Message #49 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 873778@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>, Laszlo Boszormenyi <gcs@debian.org>

Subject: Re: Bug#877428: FTBFS on mips64el: regress-157652.js timeout; regress-422348.js timeout; ecma_6/Array/for_of_1.js got 150, expected 300

Date: Thu, 12 Oct 2017 01:19:43 +0100

On Sun, 01 Oct 2017 at 19:03:46 +0100, Simon McVittie wrote:
> On Sat, 23 Sep 2017 at 12:29:08 +0200, Emilio Pozuelo Monfort wrote:
> > Let's track the mips64el failure in a different bug, as it's
> > completely different from this.
> 
> Cloned away. I haven't investigated those failures at all.

On mips64el there are a couple of timeouts (knowing mips*, probably
an arbitrary timeout is just too short):

TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "") | (TIMEOUT)
TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "") | (TIMEOUT)

and one more interesting-looking failure:

## ecma_6/Array/for_of_1.js: rc = 3, run time = 0.483245
ecma_6/Array/for_of_1.js:100:5 Error: Assertion failed: got 150, expected 300
Stack:
  TestChangeArrayPrototype@ecma_6/Array/for_of_1.js:100:5
  @ecma_6/Array/for_of_1.js:102:1
TEST-UNEXPECTED-FAIL | ecma_6/Array/for_of_1.js | (args: "")

These don't match the failures I see on s390x, powerpc or powerpc64
porterboxes with
<https://anonscm.debian.org/cgit/users/smcv/mozjs52.git/log/?h=wip/s390x>.

Regards,
    smcv

Message #54 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Michael Biebl <biebl@debian.org>, 873778@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: mozjs52: FTBFS on s390x and other big-endian machines

Date: Thu, 12 Oct 2017 01:31:08 +0100

powerpc64 (pizzetti) gets the same test failures as s390x (zelenka),
suggesting that they are something that happens on big-endian 64-bit.
hppa doesn't seem to have a porterbox and sparc64's (notker) was
unresponsive, so I can't confirm that theory.

powerpc (partch) only gets one of those failures. I've left mozjs52
compiling on mips (minkus) overnight to see whether both big-endian
32-bit architectures behave the same.

On Thu, 12 Oct 2017 at 00:16:32 +0100, Simon McVittie wrote:
> ## ecma_6/TypedArray/sort_snans.js: rc = 3, run time = 0.055719
> ecma_6/shell.js:93:23 Error: Assertion failed: got -1.8938930325389462e+304, expected NaN at _[0]
> Stack:
>   assertSameValue@ecma_6/shell.js:93:23
>   check@ecma_6/shell.js:198:21
>   assertSameProps@ecma_6/shell.js:162:25
>   check@ecma_6/shell.js:213:25
>   assertDeepEq@ecma_6/shell.js:221:13
>   testFloat64NaNRanges@ecma_6/TypedArray/sort_snans.js:60:5
>   @ecma_6/TypedArray/sort_snans.js:68:1
> TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/sort_snans.js | (args: "")

Also seen on powerpc (where it is the only failure) and on powerpc64

> ## ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js: rc = 3, run time = 0.025008
> ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9 Error: Assertion failed: got 3, expected 0
> Stack:
>   @ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9
> TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js | (args: "")

Also seen on powerpc64

> ## ecma_6/TypedArray/subarray.js: rc = 3, run time = 0.021673
> ecma_6/TypedArray/subarray.js:8:26 RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
> Stack:
>   @ecma_6/TypedArray/subarray.js:8:26
> TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/subarray.js | (args: "")

Also seen on powerpc64

> ## ecma_6/TypedArray/indexOf-and-lastIndexOf.js: rc = 3, run time = 0.023659
> ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9 Error: Assertion failed: got 0, expected 8
> Stack:
>   @ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9
> TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/indexOf-and-lastIndexOf.js | (args: "")

Also seen on powerpc64

> ## ecma_6/TypedArray/set-same-buffer-different-source-target-types.js: rc = 3, run time = 0.022477
> 896116: When setting a typed array from an overlapping typed array of different element type, copy the source elements into properly-sized temporary memory, and properly copy them into the target without overflow (of either source *or* target) when finished
> ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11 RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
> Stack:
>   @ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11
> TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/set-same-buffer-different-source-target-types.js | (args: "")

Also seen on powerpc64

> ## ecma_6/ArrayBuffer/CloneArrayBuffer.js: rc = 3, run time = 0.021813
> 1264941: CloneArrayBuffer should be called with byteLength of source typedArray
> ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7 Error: Assertion failed: got 8, expected 0
> Stack:
>   test@ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7
>   @ecma_6/ArrayBuffer/CloneArrayBuffer.js:27:1
> TEST-UNEXPECTED-FAIL | ecma_6/ArrayBuffer/CloneArrayBuffer.js | (args: "")

Also seen on powerpc64

> ## js1_8_5/extensions/clone-errors.js: rc = -11, run time = 0.03348
>  PASSED! ok
> TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-errors.js | (args: "")

Also seen on powerpc64

> ## js1_8_5/extensions/typedarray.js: rc = 0, run time = 0.167332
> BUGNUMBER: 532774
> STATUS: js typed arrays (webgl arrays)
> === FAILED ===
> check@js1_8_5/extensions/typedarray.js:62:22
> test@js1_8_5/extensions/typedarray.js:488:5
> @js1_8_5/extensions/typedarray.js:17:1
> 
> ==============
> === FAILED ===
> check@js1_8_5/extensions/typedarray.js:62:22
> test@js1_8_5/extensions/typedarray.js:489:5
> @js1_8_5/extensions/typedarray.js:17:1
> 
> ==============
> === FAILED ===
> check@js1_8_5/extensions/typedarray.js:62:22
> test@js1_8_5/extensions/typedarray.js:490:5
> @js1_8_5/extensions/typedarray.js:17:1
> 
> ==============
> === FAILED ===
> check@js1_8_5/extensions/typedarray.js:62:22
> test@js1_8_5/extensions/typedarray.js:491:5
> @js1_8_5/extensions/typedarray.js:17:1
> 
> ==============
> done
>  FAILED! [reported from test()] typed array tests : Expected value '0', Actual value '4'

Also seen on powerpc64

> ## js1_8_5/extensions/clone-transferables.js: rc = 3, run time = 0.022512
> js1_8_5/extensions/clone-transferables.js:42:17 Error: Assertion failed: got 0, expected NaN
> Stack:
>   test@js1_8_5/extensions/clone-transferables.js:42:17
>   @js1_8_5/extensions/clone-transferables.js:111:1
> TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-transferables.js | (args: "")

Also seen on powerpc64

> ## js1_8_5/extensions/clone-many-transferables.js: rc = -11, run time = 0.783352
>  PASSED! ok
> TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-many-transferables.js | (args: "")

Also seen on powerpc64

Message #59 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Michael Biebl <biebl@debian.org>, 873778@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: mozjs52: FTBFS on s390x and other big-endian machines

Date: Thu, 12 Oct 2017 08:08:42 +0100

Control: clone 873778 -2 -3 -4
Control: retitle 873778 mozjs52: FTBFS on big-endian: interpreter silently exits 1 ("Failed to test XUL condition")
Control: retitle -2 mozjs52: FTBFS on mips: thousands of TEST-UNEXPECTED-FAIL
Control: retitle -3 mozjs52: FTBFS on powerpc, s390x, powerpc64: ecma_6/TypedArray/sort_snans.js: got -1.8938930325389462e+304, expected NaN
Control: retitle -4 mozjs52: FTBFS on s390x, powerpc64 (64-bit BE) with same tests failing

On Thu, 12 Oct 2017 at 01:31:08 +0100, Simon McVittie wrote:
> I've left mozjs52
> compiling on mips (minkus) overnight to see whether both big-endian
> 32-bit architectures behave the same.

Unfortunately mips has new and exciting failures, and lots of them:

% grep -c UNEXPECTED-FAIL ../mozjs52.log
4913

so is in a considerably worse state than s390x or the powerpc family.

Cloning the bug to divide up the equivalence classes of architectures.

    smcv

Message #68 received at 873778@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Simon McVittie <smcv@debian.org>, Michael Biebl <biebl@debian.org>, 873778@bugs.debian.org

Cc: Laszlo Boszormenyi <gcs@debian.org>, Adrian Bunk <bunk@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#873778: mozjs52 on s390x and other big-endian machines

Date: Thu, 12 Oct 2017 11:29:09 +0200

On 12/10/17 01:16, Simon McVittie wrote:
> On Mon, 09 Oct 2017 at 10:36:52 +0100, Simon McVittie wrote:
>> On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
>>>>> The remaining problem seems to be a big-endian issue (mips, s390x, 
>>>>> hppa, powerpc, sparc64). ppc64 fails in a slightly different
>>>>> manner, might just be it's failing earlier for a different reason
>>>>> but would also suffer from this bug.
>>
>> Here is some work-in-progress on this:
>>
>> https://anonscm.debian.org/git/users/smcv/mozjs52.git
>>
>> I've made it regenerate the data file on both endiannesses in the hope
>> that this will make us more likely to catch errors. The generated file
>> on little-endian is not the same as the pregenerated one :-(
>>
>> This is only build-tested on x86_64 at this point, not runtime-tested.
> 
> The unit tests all pass or are skipped on x86_64 (on barriere).
> 
> On s390x (zelenka), I now see meaningful test results, with the unexpected
> failures listed below. So something is wrong on s390x in at least a
> few cases, but it's basically a functional JavaScript interpreter,
> and a lot of the tests pass. That seems a lot better than the current
> situation. Good enough for experimental, at least?

Agreed. I'd say let's get this uploaded, and then if we can't fix the test suite
even further, disable it (it was already disabled on older mozjs and on firefox
as you pointed out so no regression here...) and call for help to interested
parties.

Thanks!
Emilio

Message #73 received at 873778-submitter@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 873778-submitter@bugs.debian.org

Subject: Bug#873778 marked as pending

Date: Thu, 12 Oct 2017 21:49:58 +0000

tag 873778 pending
thanks

Hello,

Bug #873778 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    https://anonscm.debian.org/cgit/pkg-gnome/mozjs52.git/commit/?id=d2b4568

---
commit d2b4568abf4b43a26c8c1033295d8e40e56408ba
Author: Simon McVittie <smcv@debian.org>
Date:   Thu Oct 12 20:20:56 2017 +0100

    Close #873778 now that I've cloned away the test failures

diff --git a/debian/changelog b/debian/changelog
index cd8a0ed..763be40 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,7 +13,9 @@ mozjs52 (52.3.1-5) UNRELEASED; urgency=medium
   * d/p/Add-intl-icu_sources_data.py-from-firefox-esr.patch:
     Add patch importing intl/icu_sources_data.py from firefox-esr_52.4.0esr-2
     so we can regenerate the ICU_DATA_FILE
-  * d/rules: Regenerate the ICU_DATA_FILE
+  * d/rules: Regenerate the ICU_DATA_FILE (with the correct endianness)
+    so the interpreter doesn't fail to initialize on big-endian
+    architectures (Closes: #873778)
   * d/p/icu_sources_data.py-Decouple-from-Mozilla-build-system.patch:
     Avoid needing the mozpack module to generate the ICU_DATA_FILE
   * d/p/Fix-crashes-in-AtomicOperations-none-on-s390x.patch:

Message #78 received at 873778-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 873778-close@bugs.debian.org

Subject: Bug#873778: fixed in mozjs52 52.3.1-5

Date: Fri, 13 Oct 2017 09:04:47 +0000

Source: mozjs52
Source-Version: 52.3.1-5

We believe that the bug you reported is fixed in the latest version of
mozjs52, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 873778@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated mozjs52 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 13 Oct 2017 00:24:00 +0100
Source: mozjs52
Binary: libmozjs-52-0 libmozjs-52-dev
Architecture: source
Version: 52.3.1-5
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description:
 libmozjs-52-0 - SpiderMonkey JavaScript library
 libmozjs-52-dev - SpiderMonkey JavaScript library - development headers
Closes: 873778 876354
Changes:
 mozjs52 (52.3.1-5) unstable; urgency=medium
 .
   * Team upload
 .
   [ Simon McVittie ]
   * Regenerate patches
   * Export SHELL and PYTHON for all stages of the build process
     (Closes: #876354)
   * d/p/Allow-to-override-ICU_DATA_FILE-from-the-environment.patch:
     Add patch from firefox-esr to allow ICU_DATA_FILE to be forced in
     the environment. We need to use a big-endian version on BE
     architectures.
   * d/p/Patch-pregenerated-old-configure-to-match-build-autoconf-.patch:
     Apply the equivalent of that patch to the pregenerated old-configure
     script
   * d/p/Add-intl-icu_sources_data.py-from-firefox-esr.patch:
     Add patch importing intl/icu_sources_data.py from firefox-esr_52.4.0esr-2
     so we can regenerate the ICU_DATA_FILE
   * d/rules: Regenerate the ICU_DATA_FILE (with the correct endianness)
     so the interpreter doesn't fail to initialize on big-endian
     architectures (Closes: #873778)
   * d/p/icu_sources_data.py-Decouple-from-Mozilla-build-system.patch:
     Avoid needing the mozpack module to generate the ICU_DATA_FILE
   * d/p/Fix-crashes-in-AtomicOperations-none-on-s390x.patch:
     Add patch from firefox-esr to fix atomic operations crashes on s390x
   * d/p/icu_sources_data-Write-command-output-to-our-stderr.patch:
     Make sure output from icu_sources_data.py ends up in buildd logs
   * d/p/tests-For-tests-that-are-skipped-on-64-bit-mips64-is-also.patch:
     Count mips64 as a 64-bit architecture for the purposes of skipping
     tests
   * d/rules: Run a "hello, world" program before running the test suite.
     If mozjs fails to initialize on a platform, the diagnostics given
     are fairly useless; try something much simpler before we go to the
     effort of running the full test suite. Failure to run this program
     causes FTBFS, to make sure we won't ship completely useless builds.
   * d/test.sh: Wrap build-time tests, making test-suite failures
     non-fatal on architectures with known issues (downgrades severity
     of: #877428, #878284, #878285, #878286)
   * d/rules: Skip build-time tests if cross-compiling
   * d/rules: Run icu build with VERBOSE=1 to see compilation commands
 .
   [ Jeremy Bicha ]
   * Add Don-t-include-xlocale.patch: Fix build with glibc >= 2.26
Checksums-Sha1:
 9c503cc35159f4ffe0299180e6df9ec6cd4309fd 2200 mozjs52_52.3.1-5.dsc
 5537d316f10fe5ec73f579e637d13621d0cc453e 70060 mozjs52_52.3.1-5.debian.tar.xz
 7e350568e2206d0ac73b023c208848c0bc3f31f1 6073 mozjs52_52.3.1-5_source.buildinfo
Checksums-Sha256:
 6f33a01d3c2ce9685fef4a17eab57efb01c9d3f8f31efc8fec1a4b9374129156 2200 mozjs52_52.3.1-5.dsc
 60ef140120366be14ae26143167e02d12b4c88e21a2bf8b6a36ddf42937d321b 70060 mozjs52_52.3.1-5.debian.tar.xz
 033fc78fb0e37641c37e1d7e9501f6be38a5ec3c9993189815517e444853347a 6073 mozjs52_52.3.1-5_source.buildinfo
Files:
 d416ae475ef8714490060f32fe667572 2200 libs optional mozjs52_52.3.1-5.dsc
 83c6fc4cca5582a90004de38c88d201a 70060 libs optional mozjs52_52.3.1-5.debian.tar.xz
 a81fd9cc0f9ce244d61eea4446da6037 6073 libs optional mozjs52_52.3.1-5_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAlngfZcACgkQ4FrhR4+B
TE+mEA//d5ZMLOYh0g4N2CQhYokRChBYDpYBxy2Zhf76cHgbWwkknrAvsLtG1+VM
AUrJWdEIwaGKb6jz/dg1NO6B6vJ9yLxa90gEA0p9N5m8p/i8wGfUI+loJAWPsz07
K4lb+vLHC6dGRterd96Z/tilREP4kdX9h7fA2BDIRoAhELIn9stKlMT6qiujj97r
KdzA/1H8MuWis8H9sH3+5jPG4tlpCUnzbD0dFc+xc548XO6MwXp/cG8EKT8G9H8M
5H31CNgLfaQ1fWfBuiKnukWmNl0mySbKiipoJVozbNFIy8/lCL8zXqRyye+MRmGy
H1vNx7fO16nes0rZsmK7Ljpxlo04XlYSYENLs3h4ylGm92fmwykUkb7374Y72+hy
mu7bkOXxCBabRw8KTiTa0TzVxgCfrL4BbnjPkBoKcdItWWxDOf0rM+ImUXnm896k
pEfq6r4khl2h+YeJhi7U1W15Y8B5Hrj5N2k3AXh310F0rHWV+UD50YJ039UIXI+W
IjbLNZmkCeF04J6eFIOd2qCk9hYpkq/QaTVU2vZMqKQFpptGhJBjS32S6vxTQCeG
Z8pn3p84xcXHl5NpK/zpxxU8DbgjKYNlM6Pv221KMq/5gT6irsk8ciXs6rsHhzH2
96rElSkMtPPIoWD7frYTfQH6w75jNs1BxoA4yeazf6/Nw5erFuA=
=JLPe
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.