Launchpad has imported 51 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=735599.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-03-14T08:53:42+00:00 Drago01 wrote: The current spidermonkey package as shipped https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which is what got into Firefox 4. There have been a lot of improvements to the javascript engine since then which warrants release a new version. So can we have a new standalone js release? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/0 ------------------------------------------------------------------------ On 2012-03-16T00:07:29+00:00 Dmandelin wrote: (In reply to drago01 from comment #0) > The current spidermonkey package as shipped > https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which > is what got into Firefox 4. > > There have been a lot of improvements to the javascript engine since then > which warrants release a new version. > > So can we have a new standalone js release? Wes and I were talking about it recently, but I can't remember where we left it. I think we talked about using the version that went into Firefox 10 ESR. Would that have the new features you want? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/1 ------------------------------------------------------------------------ On 2012-03-16T08:32:29+00:00 Drago01 wrote: (In reply to David Mandelin from comment #1) > (In reply to drago01 from comment #0) > > The current spidermonkey package as shipped > > https://developer.mozilla.org/en/SpiderMonkey here is at Version 1.8.5 which > > is what got into Firefox 4. > > > > There have been a lot of improvements to the javascript engine since then > > which warrants release a new version. > > > > So can we have a new standalone js release? > > Wes and I were talking about it recently, but I can't remember where we left > it. I think we talked about using the version that went into Firefox 10 ESR. Yeah having it based on an ESR make sense. > Would that have the new features you want? Yes that should be fine. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/2 ------------------------------------------------------------------------ On 2012-03-16T18:22:47+00:00 Dmandelin wrote: OK, it might take a while to spin this up, but it's on my list. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/3 ------------------------------------------------------------------------ On 2012-03-16T18:29:15+00:00 Drago01 wrote: (In reply to David Mandelin from comment #3) > OK, it might take a while to spin this up, but it's on my list. OK, thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/4 ------------------------------------------------------------------------ On 2012-04-04T01:08:56+00:00 Dmandelin wrote: Getting ready to work on this. First tiny step: updating title to match what was used last time around in bug 628723. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/5 ------------------------------------------------------------------------ On 2012-04-04T01:18:45+00:00 Dmandelin wrote: Wes gave me his procedure from last time around. It went something like this: 1. Snapshot the source code. I'll use ESR10. 2. Handpick other patches to land. I'm not sure what we need--ESR10 tends to pick up the security bugs. I could audit them, which might be useful anyway. Otherwise I'll probably just go according to suggestions from embedders. So: 2.1. Audit security fixes looking for anything that didn't land in ESR10. Land anything that looks like it can land there. 2.2. Apply Wes's patch for library names. 3. Build and run the test scripts to make sure everything works 4. Make a tar file and put it out for testing. 5. Wait for feedback and apply it to the result. Keep track of problems people run into upgrading. 6. Make a tar file and put it out as a release. (these can start as the above are ongoing) 7. Update the release notes: 7.1. Find new, changed, and deleted APIs and list them. 7.2. Find important types that change and document them. 7.3. Document any breakage users found in upgrading 7.4. Document major new engine/language features Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/6 ------------------------------------------------------------------------ On 2012-04-06T21:41:20+00:00 Dmandelin wrote: http://people.mozilla.com/~dmandelin/sm187.tar.gz Here's a first try. It's very close to the rev named in the README. All I did in addition was: - apply a fix for a failing test reress-422269 - remove a failing test for findReferences-01. This is a test for a "find the GC path to this object" shell function that fails just because of some small formatting differences, and where the bug fix doesn't apply cleanly to ESR10. - marked a test regress-80981 as slow, because it is - applied Wes's libname-changes.patch (with s/5/7) Is anyone ready to test it? I haven't updated the release notes yet. I'll be working on that next. I have some other things going on too, so I'll try to keep it moving, but might get interrupted for a while. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/7 ------------------------------------------------------------------------ On 2012-04-07T12:25:21+00:00 Landry-openbsd wrote: Some notes packaging-wise : - 1.8.5 tarball was named js185-1.0.0.tar.gz - all was in js-1.8.5/js/src, not directly js/src - there's no mozjs187.pc.in file, similar to mosjs185.pc.in in 1.8.5 (which is still referred as-is in Makefile.in) - build fails with gmake[1]: *** No rule to make target `RangedPtr.h', needed by `export'. Stop. -> RangedPtr.h should be removed from EXPORTS_mozilla ? Same for RefPtr.h ? It also fails for Types.h, and i dont know how to workaround it, since that header is needed to build/included in various places. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/8 ------------------------------------------------------------------------ On 2012-04-07T12:53:34+00:00 Mh+mozilla wrote: mfbt/ needs to be in the tarball. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/9 ------------------------------------------------------------------------ On 2012-04-18T00:51:27+00:00 Dmandelin wrote: Getting back to this. New version up at: http://people.mozilla.com/~dmandelin/js187-1.0.0.tar.gz changes: - changed name per comment 8 - changed root dir per comment 8 - added mozjs187.pc.in per comment 8 - added mfbt/ per comment 9 Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/10 ------------------------------------------------------------------------ On 2012-04-18T09:06:28+00:00 Landry-openbsd wrote: Builds fine here, on;y had to backport https://hg.mozilla.org/mozilla- central/rev/9cfdb612a026 to get correct endianess detection on OpenBSD. For some reason make install fails, mv gets passsed too much arguments: mv -f /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libjs_static.a libjs_static.a.desc /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libmozjs187-1.0.a libmozjs187-1.0.a.desc usage: mv [-fi] source target mv [-fi] source ... directory but since it's the same chunk in 1.8.5 i guess that's a local issue (dunno where that libjs_static.a.desc comes from) Regress tests are running fine, the only failing one is jit- test/tests/sunspider/check-date-format-tofte.js but i've always seeing it failing on OpenBSD, didnt look much further into it. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/11 ------------------------------------------------------------------------ On 2012-04-24T18:21:15+00:00 Dmandelin wrote: (In reply to Landry Breuil from comment #11) > Builds fine here, on;y had to backport > https://hg.mozilla.org/mozilla-central/rev/9cfdb612a026 to get correct > endianess detection on OpenBSD. Can you give me the backported patch so I can include it in the 1.8.7 release? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/12 ------------------------------------------------------------------------ On 2012-04-26T10:45:23+00:00 Landry-openbsd wrote: Created attachment 618606 backport bug 714312 Here you are.. i had to use AC_TRY_COMPILE as MOZ_CHECK_HEADERS wasnt available yet and the available macros dont permit to specify a second include. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/13 ------------------------------------------------------------------------ On 2012-04-27T19:56:41+00:00 Dmandelin wrote: (In reply to Landry Breuil from comment #13) > Created attachment 618606 > backport bug 714312 > > Here you are.. i had to use AC_TRY_COMPILE as MOZ_CHECK_HEADERS wasnt > available yet and the available macros dont permit to specify a second > include. Thanks. I just updated the people.mozilla.com copy with your patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/14 ------------------------------------------------------------------------ On 2012-04-28T18:31:46+00:00 Jwalden+bmo wrote: I just copied the 1.8.5 notes to https://developer.mozilla.org/en/SpiderMonkey/1.8.7 to start the documentation process. Right now most of the content is just a copy of 1.8.5, so it obviously needs a *lot* of work to come close to being done. :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/15 ------------------------------------------------------------------------ On 2012-06-18T00:26:04+00:00 Anarchy wrote: (In reply to Landry Breuil (:gaston) from comment #11) > Builds fine here, on;y had to backport > https://hg.mozilla.org/mozilla-central/rev/9cfdb612a026 to get correct > endianess detection on OpenBSD. > > For some reason make install fails, mv gets passsed too much arguments: > > mv -f > /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libjs_static.a > libjs_static.a.desc > /usr/ports/pobj/spidermonkey-1.8.7/fake-amd64/usr/local/lib/libmozjs187-1.0. > a libmozjs187-1.0.a.desc > usage: mv [-fi] source target > mv [-fi] source ... directory > > but since it's the same chunk in 1.8.5 i guess that's a local issue (dunno > where that libjs_static.a.desc comes from) > > Regress tests are running fine, the only failing one is > jit-test/tests/sunspider/check-date-format-tofte.js but i've always seeing > it failing on OpenBSD, didnt look much further into it. I am seeing the same failure in Gentoo. I double checked that 1.8.5 compiled and installed fine, makes no sense why it would fail using same toolchain with 1.8.7. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/16 ------------------------------------------------------------------------ On 2012-06-18T01:20:43+00:00 Anarchy wrote: mv -f /home/anarchy/spidermonkey///usr/lib/libjs_static.a libjs_static.a.desc /home/anarchy/spidermonkey///usr/lib/libmozjs187-1.0.a libmozjs187-1.0.a.desc As we can see here, we are failing to run mv source target, this should be a loop to ensure we are meeting the correct useage of mv. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/17 ------------------------------------------------------------------------ On 2012-06-18T17:17:17+00:00 Anarchy wrote: The issues is in config/rules.mk ifndef LIBRARY ifdef STATIC_LIBRARY_NAME REAL_LIBRARY := $(LIB_PREFIX)$(STATIC_LIBRARY_NAME).$(LIB_SUFFIX) # Only build actual library if it is installed in DIST/lib or SDK ifeq (,$(SDK_LIBRARY)$(DIST_INSTALL)$(NO_EXPAND_LIBS)) LIBRARY := $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX) else LIBRARY := $(REAL_LIBRARY) $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX) endif endif # STATIC_LIBRARY_NAME endif # LIBRARY Do we really need to have $(REAL_LIBRARY).$(LIBS_DESC_SUFFIX)? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/18 ------------------------------------------------------------------------ On 2012-06-18T18:23:00+00:00 Anarchy wrote: Created attachment 634119 filter-out %.$(LIBS_DESC_SUFFIX) basic patch I am using in gentoo. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/19 ------------------------------------------------------------------------ On 2012-06-18T18:30:37+00:00 Anarchy wrote: As another team member has pointed out, we will need to ensure the public headers are installed with make install due to {jsapi,jsutil,jsval}.h needing the headers. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/20 ------------------------------------------------------------------------ On 2012-09-15T23:27:19+00:00 Jasper St. Pierre wrote: Has there been any progress on this? Our users are seeing a lot of leaks in SpiderMonkey 1.8.5 that have been fixed in later versions. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/21 ------------------------------------------------------------------------ On 2012-09-27T12:51:22+00:00 Drago01 wrote: (In reply to Jasper St. Pierre from comment #21) > Has there been any progress on this? Our users are seeing a lot of leaks in > SpiderMonkey 1.8.5 that have been fixed in later versions. Yeah good question ... looks like that we could as well base it on FX17 ESR if it takes that much time. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/22 ------------------------------------------------------------------------ On 2012-09-27T17:55:18+00:00 Jwalden+bmo wrote: Yeah, I think 17 is the time for this to happen. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/23 ------------------------------------------------------------------------ On 2012-11-10T16:49:53+00:00 Drago01 wrote: Any news / progress on this? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/24 ------------------------------------------------------------------------ On 2012-11-13T01:19:57+00:00 Andre Klapper wrote: David: So will this definitely happen for 17 and have resources been assigned to this? Could a priority be set? I more and more get the feeling that usage of standalone js and braodening its developer and feedback base is not interesting for Mozilla - in that case it would be only fair to communicate that. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/25 ------------------------------------------------------------------------ On 2012-11-13T23:36:24+00:00 Dmandelin wrote: (In reply to Andre Klapper from comment #25) > David: So will this definitely happen for 17 and have resources been > assigned to this? > Could a priority be set? > > I more and more get the feeling that usage of standalone js and braodening > its developer and feedback base is not interesting for Mozilla - in that > case it would be only fair to communicate that. Fair points and questions. I don't have time to work on this now. I got as far as putting together a tarball that I think is about right (based entirely on Wes's prior work), which is still on my people page (http://people.mozilla.org/~dmandelin/js187-1.0.0.tar.gz). I can't see myself setting aside the time to put together great release notes like Wes has. We are indeed these days tightly focused on building the best SpiderMonkey specifically for Firefox products. I do wonder if we can put together a lightweight process that would allow us to put out some kind of usable source release periodically. I'll post to the list. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/26 ------------------------------------------------------------------------ On 2012-12-08T09:09:46+00:00 Jasper St. Pierre wrote: This tarball does not work: /home/jstpierre/Source/gnome3/install/include/js/jsval.h:45:24: fatal error: js/Utility.h: No such file or directory It seems that jsapi/jsval refer to an internal Utility.h header that is not installed. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/27 ------------------------------------------------------------------------ On 2013-01-02T15:07:06+00:00 Drago01 wrote: Rico Tzschichholz has created some patches and scripts to build tarballs for both 187 (10ESR) and 188 (17ESR): http://people.ubuntu.com/~ricotz/mozjs/ Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/28 ------------------------------------------------------------------------ On 2013-01-14T02:45:34+00:00 Darkxst-k wrote: I have gnome-shell/gjs running on js188(esr17 snapsnot) and it fixes most of the issues we have been having with js185/js187, such as GC deadlocks and leaks. Any chance of getting a release based on esr17? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/29 ------------------------------------------------------------------------ On 2013-01-17T00:58:50+00:00 Kieran776 wrote: Hello. My name is Kieran. I'm part of an open source RTS game called 0 A.D. (http://play0ad.com). We embed SpiderMonkey engine into the game to allow a big part of the game to be written in Javascript. With the many optimisations and improvements to the engine over the last few months, we'd really like to take advantage of them within the game (specifically IonMonkey) to help improve the games performance. However, this does require the source for SpiderMonkey which can be built independently from Firefox. Has there been any progress on creating an archive of the latest SpiderMonkey engine found in Firefox 18? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/30 ------------------------------------------------------------------------ On 2013-02-10T17:07:56+00:00 Drago01 wrote: (In reply to darkxst from comment #29) > I have gnome-shell/gjs running on js188(esr17 snapsnot) and it fixes most of > the issues we have been having with js185/js187, such as GC deadlocks and > leaks. > > Any chance of getting a release based on esr17? Any chance to get this release out at all? The bug has been filed almost a year ago. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/33 ------------------------------------------------------------------------ On 2013-02-11T22:05:10+00:00 Sstangl wrote: (In reply to drago01 from comment #31) > Any chance to get this release out at all? The bug has been filed almost a > year ago. Yes. There will be a js-1.8.8 release based on esr17 asap. (In reply to Kieran P from comment #30) > Has there been any progress on creating an archive of the latest > SpiderMonkey engine found in Firefox 18? We'll focus on an esr17 (pre-IonMonkey) release first. Although esr17 doesn't include IonMonkey, it does have JaegerMonkey with TypeInference, which should still be a huge speedup over 1.8.5. If we track JS source releases to ESR releases, the first JS release that would include IonMonkey would be based off esr24 around November 2013. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/34 ------------------------------------------------------------------------ On 2013-02-12T02:03:58+00:00 Sstangl wrote: I created a public repository to work on JS packaging so that the process is more visible, and so that it's easier for embedders to assist in the process (or even just track it): https://github.com/sstangl/js-packaging The scripts are pulled from http://people.ubuntu.com/~ricotz/mozjs/ via Comment 28 with some fixes and selective rebased changesets from Bug 839727. Current items of action include a broken 'make install' and lack of NSPR for --enable-threadsafe. We will also need to resolve naming, because this release will not be API-compatible with 1.8.5, so calling it 1.8.8 is improper. Perhaps "1.9.0", with "/usr/include/js1.9" ala Python to permit multiple incompatible versions to coexist on a single distribution? Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/35 ------------------------------------------------------------------------ On 2013-02-12T02:19:17+00:00 Jwalden+bmo wrote: The naming thing should be handled by bug 812265, no? We'd just name it js17, js24, etc. with include files in /usr/include/js17/ and so on. Maybe with minor and patchlevel components in it, too, although I'm not sure -- presumably we want 17.0.3 or whatever to be compatible with 17.0.0, but you never know what a security bug might require. So I could see us doing patchlevel releases concurrent with ESR security/stability point releases at some point. (Although I don't think we should set that as a hard requirement now -- we should release, then we should regroup and see about making that next step then.) Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/36 ------------------------------------------------------------------------ On 2013-02-12T02:59:20+00:00 Darkxst-k wrote: yes, we should go with the patches in bug 812265, rather than the old libname patch. I have tested those and they work well, there is just a couple of minor fixes required. I will upload a fixed patch based of esr17 a bit later. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/37 ------------------------------------------------------------------------ On 2013-02-12T06:29:26+00:00 Darkxst-k wrote: This is the patchset I have been testing based off the versioning patches in bug 812265. It also contains most of the patches linked from bug 837921 (it does not however have the 'symbol conflicts' patch or 'make source package' patch). https://github.com/darkxst/js17/commits/mozjs17-rebase package naming is 'mozjs-17.0' and includes '/usr/include/mozjs-17.0' This should not have have any issues with broken install, and I havent seen any nspr issues, but havent specifically looked. Also I have been building with "--enable-threadsafe --with-system-nspr" If we end up doing point release of the esr17 series we can use the patch version in the soname suffix to handle that. (windows might need to include patch level in library name though) Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/38 ------------------------------------------------------------------------ On 2013-02-14T23:16:43+00:00 Sstangl wrote: Status update for anyone watching: mostly thanks to darkxst, the js- packaging repository from Comment 33 creates a tarball that builds on linux and installs properly. The tarball creator bears a number of patches with tracking information in "package.sh". I have put up the most recent tarball here, for early comments: http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.1.tar.gz The following items of work remain: - Bug 835551 needs landing on esr17 - Bug 831552 needs landing on esr17 - Bug 812265 needs cleanup (working patch series already in js-packaging repo) and review, with possible splinter bugs. - A leftover timestamp is installed in $(libdir)/pkgconfig/.mkdir.done. Those are all the items on the radar at the moment. Testing on Windows and OSX would be especially appreciated. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/39 ------------------------------------------------------------------------ On 2013-02-21T00:32:58+00:00 Sstangl wrote: Status update: all known issues are resolved, and darkxst's patches are awaiting final review after some iteration. Judging by the length of time required to get approval for esr17, it looks like we'll be carrying a number of patches outside of the main repo, but that isn't a barrier to shipping. Builds and installs fine on OSX. Latest version (built from https://github.com/sstangl/js-packaging): http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.2.tar.gz Once glandium approves the remaining patches, we can post a release candidate. Release won't block on notes. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/40 ------------------------------------------------------------------------ On 2013-02-21T10:12:11+00:00 Oibaf wrote: Maybe someone should update the web page: https://developer.mozilla.org/en-US/docs/SpiderMonkey with info on this upcoming release, and remove old pages: https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.7 https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8 Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/41 ------------------------------------------------------------------------ On 2013-02-21T10:23:26+00:00 Sstangl wrote: (In reply to Fabio from comment #39) > Maybe someone should update... Yes, it's on the radar. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/42 ------------------------------------------------------------------------ On 2013-02-21T14:31:37+00:00 Jasper St. Pierre wrote: Release notes aren't priority. I'd like to get the tarball out first. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/43 ------------------------------------------------------------------------ On 2013-02-24T18:29:39+00:00 Landry-openbsd wrote: (In reply to Sean Stangl from comment #38) > Status update: all known issues are resolved, and darkxst's patches are > awaiting final review after some iteration. Judging by the length of time > required to get approval for esr17, it looks like we'll be carrying a number > of patches outside of the main repo, but that isn't a barrier to shipping. > Builds and installs fine on OSX. > > Latest version (built from https://github.com/sstangl/js-packaging): > http://www.contrib.andrew.cmu.edu/user/sstangl/mozjs17-0.0.2.tar.gz Fwiw i've tried that tarball on OpenBSD, all regress tests pass fine and i'm really happy with the changes made to packaging/versionning of include dir/binaries.. less local patches! - one for Makefile.in to disable yarr jit on sparc64 (which is broken anyway, but if it builds it allows some depending pkgs to build) -ifneq (,$(filter arm% sparc %86 x86_64 mips%,$(TARGET_CPU))) +ifneq (,$(filter arm% sparc* %86 x86_64 mips%,$(TARGET_CPU))) - one for configure.in setting our SO_VERSION from env (need to file it to get that commited, its a followup from #648721) - DLL_SUFFIX=".so.1.0" + DLL_SUFFIX=".so.${SO_VERSION}" - http://hg.mozilla.org/tracemonkey/rev/68203913d04c backported to esr17 for sparc64, i realized bug #618485 was only commited to tracemonkey repo, and didnt made it to m-c or esr17. Will file that one too. Only one nit : 17.0 or mozjs17 is really confusing, given that we come from 1.8.5.. it almost looks that we downgrade the version. For 1.8.5 it matched the version of the JavaScript Language.. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/45 ------------------------------------------------------------------------ On 2013-02-27T04:09:27+00:00 Darkxst-k wrote: (In reply to Landry Breuil (:gaston) from comment #42) > > Only one nit : 17.0 or mozjs17 is really confusing, given that we come from > 1.8.5.. it almost looks that we downgrade the version. For 1.8.5 it matched > the version of the JavaScript Language.. Maybe it made sense back then, but now if we continue to use the same versioning scheme, any version numbers are just going to be arbitrary numbers. Right now the major changes are in the C API and not so much the javascript version (which has moved to the ES standards as far as I can tell.), so really it makes more sense to version the library after Firefox version than the Javascript version. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/46 ------------------------------------------------------------------------ On 2013-02-27T22:36:08+00:00 Sstangl wrote: I am pleased to finally announce a release candidate for the standalone JS 17 release: http://people.mozilla.org/~sstangl/mozjs17.0.0.rc0.tar.gz Differences between the previous version from Comment 38 and the release candidate include the reviewed versions of darkxst's patches in Bug 812265 and the OpenBSD-specific changes from Comment 42. Release notes were also given a placeholder on MDN, currently in template form with no useful information: https://developer.mozilla.org/en-US/docs/SpiderMonkey/17 The plan is to wait roughly a week to gather feedback, with a final release planned for Thursday, March 7th if feedback is positive. I will also announce the release candidate on mozilla.dev.tech.js-engine: please give feedback either there or in this bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/47 ------------------------------------------------------------------------ On 2013-02-27T23:50:39+00:00 Darkxst-k wrote: (In reply to Sean Stangl from comment #44) > > Release notes were also given a placeholder on MDN, currently in template > form with no useful information: > > https://developer.mozilla.org/en-US/docs/SpiderMonkey/17 Thats not entirely true, much of that information is very relevant to spidermonkey 17. In particular, typedef changes, deleted API and changed API sections. Cover most of the changes (atleast the ones I hit, in porting Gjs) in migrating from esr10 (the unreleased 1.8.7 tarball) -> 17 Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/48 ------------------------------------------------------------------------ On 2013-02-27T23:55:19+00:00 Sstangl wrote: (In reply to darkxst from comment #45) > (In reply to Sean Stangl from comment #44) > Thats not entirely true, much of that information is very relevant to > spidermonkey 17. The page is a blind import of the old 1.8.8 page, and I haven't checked the relevant sections for accuracy. I hope to update/check the page before final release, but it's a good sign that it was useful for Gjs porting. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/49 ------------------------------------------------------------------------ On 2013-03-05T01:27:03+00:00 Sstangl wrote: RC1: http://people.mozilla.org/~sstangl/mozjs17.0.0.rc1.tar.gz Fixes two classes of clang warnings, and carries fewer patches as Bug 838915 and Bug 831552 were merged onto upstream ESR17. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/51 ------------------------------------------------------------------------ On 2013-03-08T16:16:19+00:00 Landry-openbsd wrote: Still works fine on openbsd, i have two minor nits : - i was wrong in comment 42, yarr jit doesnt work on sparc64 and i got the logic reversed (at some point it was the list of archs to exclude, now it's the list of archs where yarr is available) - so please just put 'sparc' in the list of archs, not 'sparc*' - the construct you use for DLL_SUFFIX doesnt work, here with SO_VERSION set in the env it still uses 1.0. Can you use such construct as seen in m-c/configure.in ? See https://bugzilla.mozilla.org/show_bug.cgi?id=648721 for the background. 2307 if test "$SO_VERSION"; then 2308 DLL_SUFFIX=".so.$SO_VERSION" 2309 else 2310 DLL_SUFFIX=".so.1.0" 2311 fi Here it does weird stuff such as ./js/src/config/autoconf.mk:DLL_SUFFIX = .so.$(if $(SO_VERSION),$(SO_VERSION),1.0) ./js/src/config/expandlibs_config.py:DLL_SUFFIX = normalize_suffix(".so.$(if $(SO_VERSION),$(SO_VERSION),1.0)") ./js/src/config.log:configure:14534: cc -shared -fPIC -pthread -o libconftest.so.$(if $(SO_VERSION),$(SO_VERSION),1.0) -Wl ./js/src/config.log:cc: $(SO_VERSION),$(SO_VERSION),1.0): No such file or directory ./js/src/js-confdefs.h:#define MOZ_DLL_SUFFIX ".so.$(if $(SO_VERSION),$(SO_VERSION),1.0)" Tested on amd64, will test it on other exotic archs i have around. spidermonkey currently builds on amd64/ppc/i386/alpha/mips64{,el}/sparc64/hppa, i'd like to get the same coverage..it only badly fails at runtime on mips64/sparc64 & hppa. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/54 ------------------------------------------------------------------------ On 2013-03-10T20:33:13+00:00 Darkxst-k wrote: --- Comment #9 from Colin Walters <[email protected]> 2013-03-10 20:06:54 UTC --- One thing we need to get fixed upstream is to honor --disable-static. -rwxr-xr-x. 1 walters walters 248M Mar 10 12:53 /src/build/jhbuild/lib64/libmozjs-17.0.a No one should be linking the static library, and 248M is enormous! We don't want downstreams to be redistributing that. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/55 ------------------------------------------------------------------------ On 2013-03-10T22:36:38+00:00 Sstangl wrote: (In reply to darkxst from comment #49) > No one should be linking the static library, and 248M is enormous! We don't > want downstreams to be redistributing that. Running "strip" drastically decreases filesizes of the static and dynamic libraries. Reply at: https://bugs.launchpad.net/ubuntu/+source/mozjs/+bug/1113166/comments/56 ** Changed in: mozjs Status: Unknown => Confirmed ** Changed in: mozjs Importance: Unknown => Medium ** Bug watch added: Mozilla Bugzilla #648721 https://bugzilla.mozilla.org/show_bug.cgi?id=648721 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1113166 Title: update to new mozjs-17 library To manage notifications about this bug go to: https://bugs.launchpad.net/mozjs/+bug/1113166/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
