Re: gnome-spidermonkey?
On Sat, 2010-12-11 at 11:23 +, Maciej Piechotka wrote: On Sat, 2010-12-11 at 08:33 +0100, Frederic Crozat wrote: 2010/12/11 Maciej Piechotka uzytkown...@gmail.com: On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. This is already possible for xulrunner in most distributions. Then probably the problem is Fedora itself then coupling. Since otherwise the gnome-shell/gjs are coupled to particular branch of xulrunner if I understand correctly. Can't really follow this. There are two different strategies I know of for building other packages against Firefox: Use rpaths in the binaries. GNOME Shell needs to be rebuilt for every minor release of Firefox whether the ABI changes or not. Put the libmozjs.so in the system linker paths using /etc/ld.so.conf.d/ Fedora takes the second approach. Neither approach gives you transparent parallel installs of different ABI-guaranteed versions of Spidermonkey and: I guess update xulrunner 1.9.x - xulrunner 1.9.(x+1) does not require code changes Upstream doesn't make this guarantee as far as I know. (Yes, changes within 1.9.x have been small compared to the difference between 1.9.x and 2.0) so the problem can be derefered to distributions (updates, updating fx/gjs/gnome-shell when ABI changes for example due to inlining etc.). While certainly the fact that security updates for Firefox could require code changes to GNOME Shell is a problem, and yes, parallel installation can get around that at the expense of extra disk space usage and packaging complexity, it's not the only point. We need a smallish amount of code. The complete Firefox build in the jhbuild takes a long time. We want to have a common version of Spidermonkey for all distributions shipping GNOME rather than wildly divergent versions. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
2010/12/13 Owen Taylor otay...@redhat.com: On Sat, 2010-12-11 at 11:23 +, Maciej Piechotka wrote: On Sat, 2010-12-11 at 08:33 +0100, Frederic Crozat wrote: 2010/12/11 Maciej Piechotka uzytkown...@gmail.com: On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. This is already possible for xulrunner in most distributions. Then probably the problem is Fedora itself then coupling. Since otherwise the gnome-shell/gjs are coupled to particular branch of xulrunner if I understand correctly. Can't really follow this. There are two different strategies I know of for building other packages against Firefox: Use rpaths in the binaries. GNOME Shell needs to be rebuilt for every minor release of Firefox whether the ABI changes or not. Unless you ensure rpath are done to a stable path (for instance /usr/lib/xulrunner-1.9.2 which is a symlink to latest installed release of 1.9.2.x). so the problem can be derefered to distributions (updates, updating fx/gjs/gnome-shell when ABI changes for example due to inlining etc.). While certainly the fact that security updates for Firefox could require code changes to GNOME Shell is a problem, and yes, parallel installation can get around that at the expense of extra disk space usage and packaging complexity, it's not the only point. We need a smallish amount of code. The complete Firefox build in the jhbuild takes a long time. Don't build FF in jhbuild, use the one provided by your distribution. -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, Dec 10, 2010 at 7:01 PM, Colin Walters walt...@verbum.org wrote: Hey, Comments from people creating operating systems derived from GNOME would be appreciated here: https://bugzilla.gnome.org/show_bug.cgi?id=636977 Basically, I'd like a gnome-spidermonkey package which uses *exactly* the same sources as upstream, just with a renamed .pc file etc., for the reasons listed in the bug. If you object or have comments, let me know. Maybe we could re-evaluate using libv8? *hides* -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Mon, 2010-12-13 at 16:20 +0100, Frederic Crozat wrote: We need a smallish amount of code. The complete Firefox build in the jhbuild takes a long time. Don't build FF in jhbuild, use the one provided by your distribution. A) FF in your distribution might provide one of two very different APIs at this point. We support both but at a considerable cost in developer time,. B) It really sucks if we have something in the moduleset that takes forever to build, clogs up build.gnome.org, fails frequently, and that the experts know that they should be adding to skip_modules. In many cases, the solution here is to make jhbuild smarter about when a system package provides what we need, but not sure that's the solution here. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
El lun, 13-12-2010 a las 16:25 +0100, Patryk Zawadzki escribió: On Fri, Dec 10, 2010 at 7:01 PM, Colin Walters walt...@verbum.org wrote: Hey, Comments from people creating operating systems derived from GNOME would be appreciated here: https://bugzilla.gnome.org/show_bug.cgi?id=636977 Basically, I'd like a gnome-spidermonkey package which uses *exactly* the same sources as upstream, just with a renamed .pc file etc., for the reasons listed in the bug. If you object or have comments, let me know. Maybe we could re-evaluate using libv8? *hides* Or JavaScriptCore? *ducks* ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Sat, 2010-12-11 at 08:33 +0100, Frederic Crozat wrote: 2010/12/11 Maciej Piechotka uzytkown...@gmail.com: On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. This is already possible for xulrunner in most distributions. Then probably the problem is Fedora itself then coupling. Since otherwise the gnome-shell/gjs are coupled to particular branch of xulrunner if I understand correctly. I guess update xulrunner 1.9.x - xulrunner 1.9.(x+1) does not require code changes so the problem can be derefered to distributions (updates, updating fx/gjs/gnome-shell when ABI changes for example due to inlining etc.). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, Dec 10, 2010 at 1:08 PM, Frederic Crozat f...@crozat.net wrote: Isn't that what xulrunner package is for ? xulrunner *is* firefox, literally; the sources are identical. On Fedora at least, Firefox is built using it, which means that if there's say a security update for Firefox (which almost certainly is really in xulrunner), then xulrunner needs to be updated, which could possibly include JSAPI changes. Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
2010/12/10 Colin Walters walt...@verbum.org: On Fri, Dec 10, 2010 at 1:08 PM, Frederic Crozat f...@crozat.net wrote: Isn't that what xulrunner package is for ? xulrunner *is* firefox, literally; the sources are identical. On Fedora at least, Firefox is built using it, which means that if there's say a security update for Firefox (which almost certainly is really in xulrunner), then xulrunner needs to be updated, which could possibly include JSAPI changes. Which means less maintenance work for distributions. Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Except almost nobody ship spidermonkey that way (I used to package it separately years ago in Mandrake) but it didn't last long and there was very few (ie one or two) using it and no maintenance on it by upstream. Forking spidermonkey would mean code duplication in distributions and moreover, library code would not be shared in memory between firefox and gjs (but I might be wrong on this). Using xulrunner as a basis, providing libmozjs.so isn't sufficient ? -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, Dec 10, 2010 at 2:59 PM, Frederic Crozat f...@crozat.net wrote: Except almost nobody ship spidermonkey that way (I used to package it separately years ago in Mandrake) but it didn't last long and there was very few (ie one or two) using it and no maintenance on it by upstream. Actually we're discussing this upstream again very productively; there's renewed interest in supporting embedders, and I'm in the process of getting some patches in to help here. Forking spidermonkey would mean code duplication in distributions and moreover, library code would not be shared in memory between firefox and gjs (but I might be wrong on this). True. Using xulrunner as a basis, providing libmozjs.so isn't sufficient ? No, because it couples gnome-shell to tightly to firefox basically. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
2010/12/10 Colin Walters walt...@verbum.org: On Fri, Dec 10, 2010 at 2:59 PM, Frederic Crozat f...@crozat.net wrote: Except almost nobody ship spidermonkey that way (I used to package it separately years ago in Mandrake) but it didn't last long and there was very few (ie one or two) using it and no maintenance on it by upstream. Actually we're discussing this upstream again very productively; there's renewed interest in supporting embedders, and I'm in the process of getting some patches in to help here. Excellent (but it would also require regular releases and in the best of worlds, firefox could be built against it..) Using xulrunner as a basis, providing libmozjs.so isn't sufficient ? No, because it couples gnome-shell to tightly to firefox basically. If you don't want to decouple it from xulrunner package, you could also use static linking (I'm not a fan of it). And no relying on xulrunner / firefox would be being vulnerable to JS vulnerability and not getting regular bugfixes (unless upstream do regular releases). Other possibility (I don't know if it can be done, I'm just guessing) : use firefox source tarball and package its spidermonkey as a separate package (just like xulrunner is done ATM, since upstream doesn't do regular releases :( But it would mean again code duplication on the distro side.. -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
2010/12/11 Maciej Piechotka uzytkown...@gmail.com: On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. This is already possible for xulrunner in most distributions. -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
