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
Description: OpenPGP digital signature
