[FFe] Updates to enable us to drop xulrunner from main

Bug #740815 reported by Chris Coulson on 2011-03-23
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
couchdb (Ubuntu)
Undecided
Chris Coulson
gluezilla (Ubuntu)
Undecided
Unassigned
gnome-python-extras (Ubuntu)
Undecided
Martin Pitt
gtk-vnc (Ubuntu)
Undecided
Martin Pitt
gwt (Ubuntu)
Undecided
Chris Coulson
icedtea-web (Ubuntu)
Undecided
Chris Coulson
libreoffice (Ubuntu)
Undecided
Björn Michaelsen
libreoffice-l10n (Ubuntu)
Undecided
Björn Michaelsen
mono (Ubuntu)
High
Chris Halse Rogers
mozvoikko (Ubuntu)
Undecided
Martin Pitt
packagekit (Ubuntu)
Undecided
Matthias Klumpp
swt-gtk (Ubuntu)
Undecided
Chris Coulson
xulrunner-1.9.2 (Ubuntu)
High
Unassigned
xulrunner-2.0 (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: xulrunner-2.0

Based on the new Firefox release schedule (http://people.mozilla.com/~sayrer/2011/temp/process.html), we need to drop xulrunner from main as unsupportable, else I'm going to risk spending nearly 100% of my time continually providing support for this across up to 5 stable releases, when most applications using it are in universe and probably aren't interesting to much more than 1% of our users.

This is a catch-all-bug driving that work.

The plan of action is:

couchdb - We will introduce a libmozjs source package for main, totally decoupled from the Firefox release process. This will be used by couchdb (and possibly other spidermonkey embedders in univese in the future)

icedtea-web - Firefox already provides an SDK now. We will build icedtea-web against Firefox rather than xulrunner. It seems that icedtea-web only really needs Firefox or xulrunner to do a version check in order to decide whether to turn on some XPCOM bits (which are turned off when built against newer Firefox builds). We should consider making this a pure NPAPI plugin and drop the mozilla dependency entirely (but perhaps not Natty timeframe)

swt-gtk - We will update swt-gtk to the stable 3.6 2 release, turning on webkit support and turning off mozilla support. This requires some updates to applications in universe which hardcode SWT.MOZILLA.

libreoffice-l10n/libreoffice - declares a build-depend on xulrunner-dev, so we need to investigate why and see if we can remove that.

gtk-vnc - has a xulrunner-dev build-depend purely for the NPAPI headers. We can build this against firefox-dev, but it really should just ship its own headers (NPAPI is cross-browser anyway)

gnome-python-extras - this is a tricky one. The only thing I can think of now is to turn of python-gtkmozembed and drop everything which uses it (not sure how popular that would make me)

mozvoikko - this is a firefox extension with binary components anyway, so must be built against firefox (xulrunner and firefox versions won't be kept in sync in the future anyway)

packagekit - has a build-depend for the NPAPI browser plugin. Same as above really - either ship its own headers or build against firefox-dev.

I would like to release a JS 1.8.5 tar ball ~ concurrently with Firefox 4.

Here is a sample tar-ball and browseable tree based on a snapshot of today's tracemonkey repo: http://www.page.ca/~wes/js-releng/

Some notes where I've differed from the existing release process at http://www.mozilla.org/js/spidermonkey/release-notes/spidermonkey-releases.html:

 - run autoconf213 in js/src so that we ship a working "configure"
 - steps related to Makefile.ref, js.mak, etc elided
 - I have not updated the change log. Is this really necessary? Is there a non-manual way to do this? There were ... several ... changes made between 1.7.0 and 1.8.5
 - Obviously, CVS tagging no longer applies. How about we tag the hg rev we push with bug 586016?
 - Tar now has one more top-level directory -- this is to allow us to ship things like NSPR and jemalloc later if we want to in the same tar ball
 - README moved to higher level dir

Also.... Can I please, please change "libmozjs.so" to a better name in the tar release? How about libmozjs185.so.1.0.0? I think this would help the distro use-case, and make it possible to ship bug fixes on top of JS-1.8.5-the-language -- while properly advertising API/ABI compatibility. And, of course, making room for JS-1.8.6-the-language.

(In reply to comment #0)
> Also.... Can I please, please change "libmozjs.so" to a better name in the tar
> release? How about libmozjs185.so.1.0.0? I think this would help the distro
> use-case, and make it possible to ship bug fixes on top of
> JS-1.8.5-the-language -- while properly advertising API/ABI compatibility. And,
> of course, making room for JS-1.8.6-the-language.

Bug 618631 does this, sort of. It hasn't had any action lately, so you may have to pick up the pieces.

With regard to the actual number, what version was the last beta we put out? Should we not be changing major numbers (is that the 1 or the 8?) since we've broken everything since our last release? I think we previously were somehow tied to Gecko version numbers (?); are you proposing breaking away from this?

(In reply to comment #1)
> Bug 618631 does this, sort of. It hasn't had any action lately, so you may have
> to pick up the pieces.

I meant 618381, my apologies.

I suppose I should chime in here and say that a new official release is really important for those of us who are working with CouchDB on Android. Newer versions of libmozjs are absolutely essential for Android and there is (not unwarranted) hesitation amongst the CouchDB folks to use an unofficial release of Spidermonkey.

In short, a new release is something that I would REALLY like to see.

For what it's worth -- Chris Coulson (copied on this bug already) from Ubuntu is maintaining a CouchDB fork which compiles on tracemonkey tip.

Hopefully a JS 185 source release will be adopted quickly by Ubuntu and spur Couch into taking Chris' patches.

Once Firefox 4 ships, I'll take a stab another release candidate and hopefully Boss@Moz will bless it.

A few points:

- I think this is a great idea and I'm thrilled that Wes is taking the job.

- Let's call it 1.8.5 and libmozjs185. SpiderMonkey version numbers have
  historically tracked the language version, not the Gecko version.

- We will not take any patches (in the tracemonkey repo or mozilla-central)
  before Firefox 4 ships for this purpose.

- We will not take any patches in the stable Firefox 4 release branch
  for this purpose either.

- Wes's plan, as I understand it, is to wait for Firefox 4 to ship, take
  that revision (the one we ship), make minimal changes to it (which will not
  land upstream, at least not instantly), *maybe* throw in NSPR or something,
  and tar it up. Sounds good to me.

> - run autoconf213 in js/src so that we ship a working "configure"
> - steps related to Makefile.ref, js.mak, etc elided
> - I have not updated the change log. Is this really necessary? Is there a
> non-manual way to do this? There were ... several ... changes made between
> 1.7.0 and 1.8.5

Skip the changelog. Point to http://hg.mozilla.org/tracemonkey if you think anybody cares.

> - Obviously, CVS tagging no longer applies. How about we tag the hg rev we
> push with bug 586016?

If you intend to base the source release off Firefox 4 final, that will already have a tag. There's no point tagging it more. The source release's README that explains what revision it's based on and what changes you made.

> - Tar now has one more top-level directory -- this is to allow us to ship
> things like NSPR and jemalloc later if we want to in the same tar ball
> - README moved to higher level dir

Great.

> Also.... Can I please, please change "libmozjs.so" to a better name in the tar
> release? How about libmozjs185.so.1.0.0? I think this would help the distro
> use-case, and make it possible to ship bug fixes on top of
> JS-1.8.5-the-language -- while properly advertising API/ABI compatibility. And,
> of course, making room for JS-1.8.6-the-language.

Wes clarified on IRC that he means a one-line change. The Makefile.in in the source distribution would have a different LIBRARY_NAME= than trunk. I think this is a good idea. It is definitely better than stopping right now to figure out an ideal versioning story.

Delivering something called "libmozjs185" makes it easy for us to adopt a completely different and superior versioning scheme later with no risk of breaking people who adopt this release.

(In reply to comment #5)
> - I think this is a great idea and I'm thrilled that Wes is taking the job.

Agreed, great job Wes.

> > - Tar now has one more top-level directory -- this is to allow us to ship
> > things like NSPR and jemalloc later if we want to in the same tar ball
> > - README moved to higher level dir

This is pretty non-standard for unix source packages, is it possible to put NSPR/jemalloc into the JS directory?

I think we want to stick with the directory structure current present in the hg repo.

Altering it for source releases means further modifications to the build system, and potential future-compatibilty gotchas; I think we really want to keep the source release story as simple as possible, and to make it as easy as possible for source-release users to become hg-clone users.

If you want to get technical about what's normal for a unix source package - NSPR and jemalloc would normally be completely separate packages, and at least NSPR probably will be distributed separately by Ubuntu et al. Jemalloc is less likely to be distributed separately, as it is radically different from upstream and has only one customer. Well, maybe two if XULRunner uses it.

Including NSPR with the shell is primarily to ease building - particularly for win32 - when JS_THREADSAFE goes away.

I'd just like to add that the CouchDB team would be extremely appreciative of a new source release. Once its released we'll move pretty quickly to pull in the downstream changes from Ubuntu and drop support for the 1.7 release.

I'd also like to specifically voice support for shipping the working configure script with the source release as that'd prevent us from requiring two versions of autoconf when building from a vcs checkout.

Jason, what do you think about taking bug 630209 (Igor's changes to JS_Compile*Script et al) for the the JS 1.8.5 source release?

It seems to be embedder-friendly, ready, and already landed in tracemonkey.

I have created an hg repo at https://bitbucket.org/wesgarland/js-1.8.5/ to track my work on this bug.

The repository currently contains SpiderMonkey based on Mozilla-2.0 rev 5f8f494a4c29 (FIREFOX_4_0rc1_BUILD1), minor standalone-oriented tweaks to Makefile.in, corresponding changes to the README, and the patch for bug 630209 discussed above.

I don't have a Windows platform on which to do a test build. Any volunteers?

http://www.page.ca/~wes/js-releng/js-1.8.5-rc1/js-1.8.5.tar.gz

As an embedder, this is pretty much what I'd want to see in a JS 1.8.5 source release. What do you think?

Works for me,
both "make" and "make install". Got a working shell in dist/bin, and the dll.

Thanks, Tom.

This means we have passed "yes, it compiles" tests on Windows, Leopard/x86, Debian Linux/x86 and Solaris 10/sparc.

> This means we have passed "yes, it compiles" tests on Windows, Leopard/x86,
> Debian Linux/x86 and Solaris 10/sparc.

I suggest pushing to TryServer. That would build a shell with lots of options on those platforms.

 - try server does not do shell-only builds AFAIK
 - try server expects repositories related (in the DAG sense) to mozilla-central

(Unless you know something I don't)

Wes

37 comments hidden view all 115 comments
Chris Coulson (chrisccoulson) wrote :

Note, I'm struggling with swt-gtk at the moment. I've got it built, but everything using webkit crashes inside soup_session_get_feature. I've islolated it down to a pointer returned from webkit_get_default_session losing its upper 32-bits somewhere (I'm testing this on a 64-bit machine).

This is happening here inside libswt-webkit-gtk.so:

0000000000006791 <Java_org_eclipse_swt_internal_webkit_WebKitGTK__1webkit_1get_1default_1session>:
    6791: 55 push %rbp
    6792: 48 89 e5 mov %rsp,%rbp
    6795: 48 83 ec 20 sub $0x20,%rsp
    6799: 48 89 7d e8 mov %rdi,-0x18(%rbp)
    679d: 48 89 75 e0 mov %rsi,-0x20(%rbp)
    67a1: 48 c7 45 f8 00 00 00 movq $0x0,-0x8(%rbp)
    67a8: 00
    67a9: b8 00 00 00 00 mov $0x0,%eax
    67ae: e8 ed e3 ff ff callq 4ba0 <webkit_get_default_session@plt>
    67b3: 48 98 cltq
    67b5: 48 89 45 f8 mov %rax,-0x8(%rbp)
    67b9: 48 8b 45 f8 mov -0x8(%rbp),%rax
    67bd: c9 leaveq
    67be: c3 retq

Note that there is a cltq instruction after returning from webkit_get_default_session which sign expands %eax -> %rax, and seems wrong to me. I can't work out why it ends up there (it doesn't get added to the return of any other function, and I can't spot anything obvously different at the source level). I've confirmed that if I hack the binary and replace the cltq with 2 nop's, then the problem goes away and everything using webkit works properly.

Matthias - any ideas about this?

Chris Coulson (chrisccoulson) wrote :

Note, the only thing keeping gnome-python-extras in main is gwibber, which uses python-gtkspell

Martin Pitt (pitti) wrote :

As for g-p-e: It's obsolete anyway, as next cycle when we switch to GTK3, stuff needs to be ported to PyGI. The gtkspell API is tiny, so building a gir for that should be easy. However, as it is tightly integrated into Gtk.TextView, we can't mix it with gwibber as long as that isn't ported to PyGI. So for natty we should go with dropping g-p-e to universe and cloning a python-gtkspell source package from it for main.

Martin Pitt (pitti) wrote :

First, thanks for the analysis. With Firefox' even more rapid release cycles I agree that it is worthwhile minimizing the xulrunner dependencies. I'll comment about/review the tasks individually.

Splitting the gnome-python-extras package is fine for natty. It will not effectively change any code (the alternative would be to port gwibber to GI, and build a gir from gtkspell, which is prohibitively intrusive at this point; needs to be done next cycle, though). Also, upstream development for this ceased, as it's obsolete (in favor of using GTK3 and PyGI), so we won't have to do much effort of keeping the two sources in sync.

FFE approved for this.

Changed in gnome-python-extras (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

gtk-vnc and packagekit are unintrusive as well, they just need to switch to firefox-dev for getting the NPAPI headers (which sounds better than having to copy them around). This is a very stable API, so shouldn't cause any porting issues (and if it ever breaks, we would have the same issue with xulrunner anyway). Approved these two.

Changed in gtk-vnc (Ubuntu):
status: New → Confirmed
Changed in swt-gtk (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
status: New → In Progress
Martin Pitt (pitti) wrote :

swt-gtk is already well underway, it's only one bug which keeps us from switching as far as I understood. This is a hugely complex package which is basically impossible for us to port to various xulrunner versions, so we don't have much of a choice here anyway in terms of manpower and knowledge. Having it use webkit will help a lot here. Approved.

Changed in packagekit (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

Switching mozvoikko to firefox-dev is actually the correct thing to do indeed, so it's a bug fix to move it from xulrunner-dev.

Changed in mozvoikko (Ubuntu):
status: New → Confirmed
32 comments hidden view all 115 comments

Excellent, thanks. I'm going to push this to Ubuntu ASAP

31 comments hidden view all 115 comments
Martin Pitt (pitti) wrote :

Dropping xulrunner-1.9.2 from main trivially approved. I'd even go as far as calling this a release blocker, as this is obsolete and unmaintained code with known open security issues.

Changed in xulrunner-1.9.2 (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Martin Pitt (pitti) wrote :

Once the rdepends are fixed, dropping xulrunner-2.0 is fine. This will even happen automatically as part of regular archive admin cleanup, and it doesn't need an explicit FFE.

Changed in xulrunner-2.0 (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Dave Walker (davewalker) wrote :

@Chris: Do you have an updated swt-gtk in a PPA or branch, that you commented above you are testing?

Chris Coulson (chrisccoulson) wrote :

Dave - not just yet, I'm trying to figure out the issue in comment #1 (which I think I've nailed now). I'll create a PPA for us to handle the transition in and test everything. I guess you'll want to test gwt/euca too?

Chris Coulson (chrisccoulson) wrote :

Note that turning on -Wall in swt-gtk exposed the error causing my problem in comment #1:

cc -Wall -DSWT_VERSION=3659 -DLINUX -DGTK -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux -fPIC -DJNI64 `pkg-config --cflags gtk+-2.0 webkit-1.0` -c webkitgtk.c -o webkit.o
webkitgtk.c: In function ‘Java_org_eclipse_swt_internal_webkit_WebKitGTK__1webkit_1get_1default_1session’:
webkitgtk.c:775:2: warning: implicit declaration of function ‘webkit_get_default_session’

The compiler is just assuming that an int is being returned. I guess I should have tried that before

Dave Walker (davewalker) wrote :

@Chris, Yes... would like to test it against eucalyptus - but the reason this area hasn't had as much progress as i had hoped is eucalyptus is /still/ non-functional on Natty. I'm going to raise comment #12 with James Page, as he might have a good idea. If you have a branch or patch with the changes you have already made; it would make it easier to contribute. Thanks.

Chris Coulson (chrisccoulson) wrote :

Ok, I'm going to stage everything in https://launchpad.net/~chrisccoulson/+archive/xulrunner-universe-transition. I will upload swt-gtk to there shortly

Chris Coulson (chrisccoulson) wrote :

eclipse-rcp depends on libswt-gtk-3.5-jni, but isn't eclipse shipping its own copy of swt? Benjamin?

I've uploaded the new swt-gtk to my PPA now, and just working through its rdepends

Benjamin Drung (bdrung) wrote :

eclipse-rcp ships its own copy of swt and doesn't depend on libswt-gtk-3.5-jni (just contains a replaces).

Chris Coulson (chrisccoulson) wrote :

Ah, excellent. Thanks! (I was mislead by the output of apt-cache rdepends)

Ok, I've completed the swt-gtk transition in my PPA now

Changed in swt-gtk (Ubuntu):
status: In Progress → Triaged

> Ok, I've completed the swt-gtk transition in my PPA now

How about dropping it completely? Community support of Mozilla products
always seems problematic and so if we can get rid of it completely, that would
be super useful.

Matthias Klumpp (ximion) on 2011-03-23
Changed in packagekit (Ubuntu):
assignee: nobody → Matthias Klumpp (ximion)
Chris Coulson (chrisccoulson) wrote :

Scott - the swt-gtk transition drops the mozilla support entirely (it enables the webkit backend instead)

Changed in couchdb (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
status: New → In Progress
Scott Kitterman (kitterman) wrote :

On Wednesday, March 23, 2011 09:00:00 am you wrote:
> Scott - the swt-gtk transition drops the mozilla support entirely (it
> enables the webkit backend instead)

That's good, but what about the other xulrunner rdepends?

Chris Coulson (chrisccoulson) wrote :

That's a different story altogether. I wouldn't object to dropping xulrunner from the archive (and other consumers of it too), but I wouldn't want to be the person that made that decision :)

Scott Kitterman (kitterman) wrote :

Chris: Would you be up for doing the analysis to see what packages would need
to be ported or dropped?

Chris Coulson (chrisccoulson) wrote :

Scott - sure, no problem. A good starting point is https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition , which I've been using to track some of this work in natty

Changed in firefox:
importance: Unknown → Medium
status: Unknown → In Progress
Martin Pitt (pitti) on 2011-03-23
Changed in gnome-python-extras (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Confirmed → In Progress
Martin Pitt (pitti) on 2011-03-23
Changed in gtk-vnc (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Confirmed → In Progress
Changed in gnome-python-extras (Ubuntu):
status: In Progress → Fix Committed
Matthias Klumpp (ximion) on 2011-03-23
Changed in packagekit (Ubuntu):
status: Confirmed → In Progress
Changed in swt-gtk (Ubuntu):
status: Triaged → Fix Released
Changed in xulrunner-1.9.2 (Ubuntu):
status: Confirmed → Fix Released
Changed in gwt (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
status: New → Fix Released
Martin Pitt (pitti) on 2011-03-23
Changed in gnome-python-extras (Ubuntu):
status: Fix Committed → Fix Released
Changed in xulrunner-1.9.2 (Ubuntu):
status: Fix Released → Fix Committed
Changed in gtk-vnc (Ubuntu):
status: In Progress → Fix Released
Martin Pitt (pitti) on 2011-03-23
Changed in mozvoikko (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Confirmed → In Progress
Changed in mozvoikko (Ubuntu):
status: In Progress → Fix Released
Changed in couchdb (Ubuntu):
status: In Progress → Triaged
Changed in couchdb (Ubuntu):
status: Triaged → Fix Released
52 comments hidden view all 115 comments

I've actually packaged this in Ubuntu now, but I hit a couple of unexpected issues:

1) js-config --libs doesn't return the right linker flags (-lmozjs)

2) Even though it builds an ABI versioned so, the soname of the resulting ELF binary is still unversioned (ie, libmozjs185.so rather than libmozjs185.so.1.0). This would mean we couldn't support multiple ABI's, which would make it difficult to do an ABI transition in the future.

I have patches for both of these problems, although the patch for 2) is a bit hacky.

Created attachment 521592
Fix js-config --libs

This makes js-config --libs return the right linker flags

Created attachment 521593
Fix SONAME

This ensures that the resulting binary has the right soname (libmozjs185.so.1.0). tbh, I couldn't figure out a better way of doing this, so I'm not sure if anyone else has any better ideas

If you're doing official releases, you also want to address bug 554088 at some point.

(In reply to comment #26)
> Created attachment 521593 [details]
> Fix SONAME
>
> This ensures that the resulting binary has the right soname
> (libmozjs185.so.1.0). tbh, I couldn't figure out a better way of doing this, so
> I'm not sure if anyone else has any better ideas

Why does it need to be libmozjs185.so.something instead of libmozjs.so.something?

Chris -- argh, thanks for catching the js-config bug. I'll be cutting a new release to address that specific issue RSN.

Thanks also for your SONAME patch: that's something I don't have a lot of experience with.

Mike -- I named the library libmozjs185.so rather than libmozjs.so specifically because it doesn't work as a drop-in for any previously-released libmozjs.so (not even close -- see the release notes).

Versioning the spidermonkey library based on the JavaScript version it implements (1.8.5) doesn't make much sense to me; I prefer to think of this as version 1.0.0 of the library which implements JavaScript 1.8.5. Trying to connect solib versioning with language versioning has, at least in the past, been completely and utterly futile.

Thanks for pointing out the header bug, BTW. I agree that it should be fixed, and in fact tried to fix it in the past. Maybe now that I know my way around better I can try again.

Martin Pitt (pitti) on 2011-03-24
Changed in gluezilla (Ubuntu):
status: New → Confirmed
Changed in xulrunner-1.9.2 (Ubuntu):
status: Fix Committed → In Progress
Martin Pitt (pitti) on 2011-03-24
Changed in mono (Ubuntu):
status: New → Confirmed

(Apologies if this is bikeshedding or a repeat of previous discussion)

(In reply to comment #29)
> Mike -- I named the library libmozjs185.so rather than libmozjs.so specifically
> because it doesn't work as a drop-in for any previously-released libmozjs.so
> (not even close -- see the release notes).

Since we're deliberately changing the name, maybe libspidermonkey is a better name? I agree that putting 185 in the name isn't good. When we change to 1.9.0, would we have to change the SO name? That can't be right.

> Versioning the spidermonkey library based on the JavaScript version it
> implements (1.8.5) doesn't make much sense to me; I prefer to think of this as
> version 1.0.0 of the library which implements JavaScript 1.8.5. Trying to
> connect solib versioning with language versioning has, at least in the past,
> been completely and utterly futile.

I believe that the 1.8.5 numbering scheme is a pretty bad one, and is only there because of history. Perhaps we should change it; maybe to the Firefox version number or the Gecko one.

Matthias Klumpp (ximion) on 2011-03-24
Changed in packagekit (Ubuntu):
status: In Progress → Fix Committed

Created attachment 521641
add pkg-config file

(In reply to comment #30)
>
> Since we're deliberately changing the name, maybe libspidermonkey is a better
> name? I agree that putting 185 in the name isn't good. When we change to 1.9.0,
> would we have to change the SO name? That can't be right.

I don't think it matters a lot, honestly. I really would rather we ship. libspidermonkey does make more sense to me though if someone cares to rework the tree though, so we're *very* clearly distinguished from --enable-shared-js from mozilla-central.

> I believe that the 1.8.5 numbering scheme is a pretty bad one, and is only
> there because of history. Perhaps we should change it; maybe to the Firefox
> version number or the Gecko one.

So combining, you're proposing libspidermonkey-4.so ?

(In reply to comment #31)
> Created attachment 521641 [details]
> add pkg-config file

We probably don't care, but you can make the pkg-config file relative/relocatable by using the ${pcfiledir} expansion: see https://github.com/Flusspferd/flusspferd/blob/master/libflusspferd/flusspferd.pc.in (@ REL_PC_PATH_TO_ROOT@ is replaced in this case by CMake to be something like '/../..' or similar)

>
> > I believe that the 1.8.5 numbering scheme is a pretty bad one, and is only
> > there because of history. Perhaps we should change it; maybe to the Firefox
> > version number or the Gecko one.
>
> So combining, you're proposing libspidermonkey-4.so ?

As someone else mentioned, there is also the version numbers from the moz central tree - for instance FF4 was 2.0: http://hg.mozilla.org/releases/mozilla-2.0/tags

But i would also rather we ship with what we have now than get bogged down in deciding something else if there isn't a clear consensus.

Personally the 'JS version' has always seemed fairly arbitrary, and also I don't imagine there will change very fast - so using FF or moz versions would be far superior.

> (In reply to comment #30)
> (Apologies if this is bikeshedding or a repeat of previous discussion)

(Well-aimed kick to the shins)

I don't think anything has changed since comment 5. See the last three paragraphs there.

> Since we're deliberately changing the name, maybe libspidermonkey is a better
> name? I agree that putting 185 in the name isn't good. When we change to 1.9.0,
> would we have to change the SO name? That can't be right.

It isn't ideal, but it reflects reality. I would be thrilled to ship a SM with no stupid version number in its name. We should totally do that, as soon as have a sane upgrade story. First things first.

Fixing SM versioning was a non-goal for this release. Help us get it right in the next one.

(In reply to comment #32)
> I don't think it matters a lot, honestly. I really would rather we ship.

This, with a bullet.

1 comments hidden view all 115 comments

Interested in this aswell for OpenBSD, i was planning to do an update to our old spidermonkey 1.7.0 port from firefox 4 source tarball until i saw that bug report.

(In reply to comment #23)
> Normal practice is to only ship generated files in the foo.tar.gz, not in
> revision control. In the same way that firefox-4.0.source.tar.bz2 includes
> configure, but mozilla-central doesn't.

We used to have it in the tree when we were in CVS, and it's only the more complex merge mechanics of hg that made us turn it off. We'd like to have it back, because it obviates the need to have autoconf-2.13 installed for the vast majority of developers.

2 comments hidden view all 115 comments
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package packagekit - 0.6.11-2ubuntu3

---------------
packagekit (0.6.11-2ubuntu3) natty; urgency=low

  * Build-depend on xulrunner-dev or firefox-dev, which makes it
    possible to compile PK without xulrunner as the
    latter should go away. (LP: #740815)
 -- Matthias Klumpp <email address hidden> Thu, 24 Mar 2011 14:47:04 +0100

Changed in packagekit (Ubuntu):
status: Fix Committed → Fix Released
Changed in firefox:
status: In Progress → Fix Released
Changed in icedtea-web (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
3 comments hidden view all 115 comments
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package icedtea-web - 1.1~20110320-0ubuntu2

---------------
icedtea-web (1.1~20110320-0ubuntu2) natty; urgency=low

  * Switch build-depends to firefox-dev for natty. xulrunner is
    being demoted from main (LP: #740815)
    - update debian/rules
    - update debian/control
 -- Chris Coulson <email address hidden> Mon, 04 Apr 2011 11:07:15 +0100

Changed in icedtea-web (Ubuntu):
status: New → Fix Released
Martin Pitt (pitti) on 2011-04-05
Changed in libreoffice-l10n (Ubuntu):
status: New → Confirmed
Changed in libreoffice (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti) wrote :

Just discussed on IRC, we'll drop the webbrowser package from mono for now, and will reintroduce it once the webkit port is ready.

Changed in mono (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)
importance: Undecided → High
status: Confirmed → In Progress
Changed in libreoffice (Ubuntu):
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)
status: Confirmed → Fix Committed
Changed in libreoffice-l10n (Ubuntu):
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)
status: Confirmed → Fix Committed

@Wesley the symlinks are created in the wrong way.

lrwxrwxrwx root/root 0 2011-04-09 10:55 usr/lib/libmozjs185.so.1.0 -> /build/pkg//usr/lib/libmozjs185.so.1.0.0
lrwxrwxrwx root/root 0 2011-04-09 10:55 usr/lib/libmozjs185.so -> /build/pkg//usr/lib/libmozjs185.so.1.0
-rwxr-xr-x root/root 5694336 2011-04-09 10:55 usr/lib/libmozjs185-1.0.a
-rwxr-xr-x root/root 3499992 2011-04-09 10:55 usr/lib/libmozjs185.so.1.0.0

this happens mostly for those who wants to package it and DESTDIR is used and the resulted package doesn't have that target.

Ionut;

I think you did
# ./configure --prefix=/build/pkg/usr/
# make && make install

and then wanted to move/copy the links that were made, but they were absolute rather than relative links, so this did not work?

If I understand correctly, I can fix this in the next release, or perhaps a point release.

Wesley:

i did ./configure --prefix=/usr && make && make DESTDIR=/build/pkg install

in Makefile.in you have on line:

891 ln -s $(SHLIB_EXACT_VER) $(SHLIB_ABI_VER)
892 ln -s $(SHLIB_ABI_VER) $(SHLIB_ANY_VER)

where:

870 # Generic Unix / Linux
871 SHLIB_ANY_VER := $(DESTDIR)$(libdir)/$(SHARED_LIBRARY)
872 SHLIB_ABI_VER := $(DESTDIR)$(libdir)/$(SHARED_LIBRARY).$(SRCREL_ABI_VERSION)
873 SHLIB_EXACT_VER := $(DESTDIR)$(libdir)/$(SHARED_LIBRARY).$(SRCREL_VERSION)

Interesting, that is not a configuration I've tested but I will add it to my (very short) list for the next release.

In the meantime, I think you can change 891 and 892 of Makefile.in like this to achieve the desired outcome:

891 ln -s $(notdir $(SHLIB_EXACT_VER)) $(SHLIB_ABI_VER)
892 ln -s $(notdir $(SHLIB_ABI_VER)) $(SHLIB_ANY_VER)

This would give relative links instead of absolute links, which is the correct behaviour, right?

Wes

yes. that works fine

Thanks - I'll be sure to roll that into the next release.

Martin Pitt (pitti) wrote :

The only gluezilla reverse dependency is a recommends from libmono-webbrowser0.5-cil, which will be dropped to a suggests.

I demoted gluezilla.

Changed in gluezilla (Ubuntu):
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

Now that gluezilla is in universe, I demoted xulrunner-1.9.2 as the last remaining rdepends.

Changed in xulrunner-1.9.2 (Ubuntu):
status: In Progress → Fix Released
Changed in libreoffice (Ubuntu):
milestone: none → ubuntu-11.04
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mono - 2.6.7-5ubuntu3

---------------
mono (2.6.7-5ubuntu3) natty; urgency=low

  * Drop gluezilla Recommends to Suggests for libmono-webbrowser0.5-cil.
    xulrunner, and hence gluezilla, is dropping out of main for Natty.
    (LP: #740815)
 -- Christopher James Halse Rogers <email address hidden> Tue, 12 Apr 2011 11:23:54 +1000

Changed in mono (Ubuntu):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libreoffice - 1:3.3.2-1ubuntu3

---------------
libreoffice (1:3.3.2-1ubuntu3) natty; urgency=low

  * make build dep on xulrunner-dev alternatively depend on firefox-dep (LP: #740815)
  * cherry-pick from debian:
     - enable is (icelandic) l10n (LP: #751746)
  * add unity quicklist support (LP: #720716)
  * workaround for unity icon issue (LP: #732412)
  * regenerated control file and refresh patch queue
 -- Bjoern Michaelsen <email address hidden> Fri, 15 Apr 2011 10:01:19 +0200

Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libreoffice-l10n - 1:3.3.2-1ubuntu3

---------------
libreoffice-l10n (1:3.3.2-1ubuntu3) natty; urgency=low

  * merged all changes from ubuntu-natty-3.3.1 up to 3.3.2-1ubuntu3

libreoffice (1:3.3.2-1ubuntu3) natty; urgency=low

  * make build dep on xulrunner-dev alternatively depend on firefox-dep (LP: #740815)
  * cherry-pick from debian:
     - enable is (icelandic) l10n (LP: #751746)
  * add unity quicklist support (LP: #720716)
  * workaround for unity icon issue (LP: #732412)
  * regenerated control file and refresh patch queue
 -- Bjoern Michaelsen <email address hidden> Mon, 18 Apr 2011 11:55:37 +0200

Changed in libreoffice-l10n (Ubuntu):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

I reapplied the icedtea-web fix this morning, Bjoern uploaded libo-l10n, so we should be all set now. I demoted xulrunner-2.0 to universe.

Changed in xulrunner-2.0 (Ubuntu):
status: Confirmed → Fix Released
Colin Watson (cjwatson) wrote :

<cjwatson> pitti: you demoted xulrunner-2.0 yesterday morning, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is showing it as a promotion candidate due to a build-dependency from packagekit
<chrisccoulson> cjwatson, it's an alternative build-depend
<chrisccoulson> (ie, firefox-dev | xulrunner-dev)
<chrisccoulson> oh, actually, it is "xulrunner-dev | firefox-dev"
<cjwatson> chrisccoulson: hmm, germinate wouldn't normally pick it up in that case, and yet it is ...
<cjwatson> chrisccoulson: OK. Can we flip that?
<cjwatson> or is that ordering appropriate?
<chrisccoulson> cjwatson, it's like that to keep the packaging in sync with debian, i think
<chrisccoulson> the debian build uses xulrunner-dev
<cjwatson> it's possible that we could fix it up with an explicit seed
<cjwatson> if you'd rather keep it that way, I can experiment ...
<chrisccoulson> cjwatson, i don't mind really. comments 43 - 46 in bug 740815 explain the current implementation though

I'm investigating a seed workaround.

Colin Watson (cjwatson) wrote :

I've tried, and I don't think I can fix this in a seed. Either we have to ignore the noise from component-mismatches until such time as xulrunner-dev is removed entirely (which is error-prone), or we need to flip round the build-depends ordering as an Ubuntu-specific patch to packagekit.

FWIW, libreoffice and libreoffice-l10n also have "xulrunner-dev | firefox-dev". I wonder why they do not show up in the component-mismatches.

i'm sorry for posting this issue in here but i don't know where to do it.

mongodb needs utf8 support in js and i had to add -DJS_C_STRINGS_ARE_UTF8 to CXXFLAGS. Can you enable this default or add an option in configure, like --enable-utf8 in the next release?

Ionut, you can get this added to SpiderMonkey for the next release by filing a bug for it in the Core/Javascript component (that same component as this). If you have a patch, mark it for review by setting r? to '<email address hidden>' and I can review it for you.

Ionut, -DJS_C_STRINGS_ARE_UTF8 is not the best way to access that feature, it is deprecated (but still functional) after JS 1.7.0.

Instead please invoke JS_SetCStringsAreUTF8() before your first call to JS_InitRuntime().

https://developer.mozilla.org/en/JS_CStringsAreUTF8

Wes

Sorry to revive an old thread, but I wanted to voice my thoughts for posterity. Right now the embedder's story is something like:

1) Look for js-config. If found, use it to find the sdkdir, then do feature detection to figure out what JSAPI version it is.
2) Otherwise, look for libmozjs185
3) ... or for libmozjs
4) ... or for libjs

I'm glad to see that the mozilla-central repository has not taken the versioning used here into the library name upstream. I encourage everyone involved in releases not to worry about getting the JS language version involved in the library naming at all. It may often be of much less importance to an embedder whether the language changed slightly as whether the embedding ABI changed, so please stick to ABI compatibility when deciding version numbering for the library and keep one library name. I suspect backward-incompatible language changes are less frequent than ABI changes and much of the JS world is used to feature-testing for language compatibility anyway due to the variety of language versions and features supported by browsers. Furthermore, embedders who _do_ care about the language version can look at the define in jsversion.h. Changing library names just complicates things needlessly.

Thanks for all your hard work.

(In reply to Randall Leeds from comment #49)
> Sorry to revive an old thread, but I wanted to voice my thoughts for
> posterity.

Thanks for the input. I don't think we're planning changing much right now, but at some point I think we'll want to do a new source release and it will be good to keep this in mind. I think the point about version numbering going with ABI rather than language features makes sense.

Displaying first 40 and last 40 comments. View all 115 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.