Bug#873778: Fix for the mozjs52 build on armel

Sun Oct 1 21:36:52 UTC 2017

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20171001/4ea5a524/attachment.sig>