We need to make the GNOME 3 stack stop depending on Firefox. See bug 676437 for full rationale. We'd like to have GNOME 3 depend on the js package instead, but I'm told that in order to do that, we need to drop -DJS_C_STRINGS_ARE_UTF8.
Hm, it is very-very interesting, but to opposite your request it not so in the past was added due to the requirements f.e. for MongoDB - https://bugzilla.redhat.com/show_bug.cgi?id=576585 Also, not so long I have been asked to do this also for EPEL for some erlang package dependencies. I think now it is not impossible if we will not find way to keep both variants or some kind of compromise. So, now I close it as CANTFIX, but feel free to write or even reopen it if you have idea how it may be accompleashed.
Well, the compile time option has gone away in JS 1.8+ so this will not exist in the next update. Other programs should not be relying on it anyway. However, things that need UTF8 support in 1.8+ can turn it on at runtime. See https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8 I'd recommend updating to at the very least the 1.8.0 rc from here http://ftp.mozilla.org/pub/mozilla.org/js/ Or better yet, grab the mozilla/js source bit from Firefox 3.6.x (which would be JS 1.8.2.x). Debian builds MongoDB against one of the newer Firefox JSAPIs, and I see no reason we shouldn't either especially since it's much faster.
See also https://developer.mozilla.org/En/SpiderMonkey/1.8
May be then there have worth build js 1.8.5? https://developer.mozilla.org/en/javascript From mercurial repository http://hg.mozilla.org/mozilla-central/ ?
Yeah, to be honest, I think building a 1.8.5 snapshot would actually be a great idea. Though I'd suggest either waiting until a final FF 4.0 release, or building a snap now and then updating it when FF 4.0 is released.
Actually, since we just branched F-15 off of rawhide, maybe it makes sense to update to a recent snapshot in rawhide first, let consumers such as mongodb, etc verify everything's fine, and then push it to F-15.
Off course I prepare now all changes and then make announce in devel ML for dependent package maintiners. And off course It will in rawhide only first.
I have compleated built it in rawhide (in scratch now) - http://koji.fedoraproject.org/koji/taskinfo?taskID=2841219 But I also have several issues there: Bundled software (libs): 1) They can be deleted in %prep: src/ctypes/libffi src/t src/tests/src/jstests.jar src/tracevis src/v8 2) But that: src/assembler src/yarr/yarr src/yarr/pcre src/yarr/wtf src/v8-dtoa can not be deleted - build failed. In most cases it is BSD license wich is compatable with GPL, but in our license page nothing say also about compatability with LGPL and others... I don't know what to do now.
It think I can't make decision about licensing now. Please, Spot can you solve it? Can we use such files in build and what license should be for package?
https://developer.mozilla.org/en/SpiderMonkey/1.8.5
I'he build it in scratch mode: http://koji.fedoraproject.org/koji/taskinfo?taskID=2978943 But we still have the same licensing question to Spot.
Can you make it clearer what the license question is, and why you think it applies to this package but not Firefox, which presumably has the same sources?
https://bugzilla.redhat.com/show_bug.cgi?id=676441#c8 I'm not maintainer of Firefox.
BSD (without advertising) is considered compatible with both GPL and LGPL, so I don't see an issue here.
Can we safely bundle these files? Should it change package license on any manner like "GPLv2+ and BSD"?
As there no answer I think it is not problem with licence (but It very strange for me meantime). So all commited and built. http://koji.fedoraproject.org/koji/taskinfo?taskID=2983697
I think we also need this in F15. See bug 676437.
js-1.8.5-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/js-1.8.5-3.fc15
Ok. Please test. For dependencies on it be careful - epoch 1 used.
Created attachment 491531 [details] devel subpackage needs to ask for the newly added epoch (In reply to comment #19) > Ok. Please test. > > For dependencies on it be careful - epoch 1 used. You too :-) js-devel won't install since it requires the main package without the epoch. I intentionally left the virtual provides of libjs{,-devel} alone. Patch attached. Please apply with git am 0001-devel-subpackage-needs-to-ask-for-the-newly-added-ep.patch
Since I want to play with getting gjs built against this package, I just went ahead and committed the above change and built it in rawhide and f15. At least now -devel can be installed. I wasn't sure if you wanted the virtual provides to be just an API level provide in which case the epoch isn't needed, or if you actually want it to get an epoch bump, so I'll leave that up to you.
Ok, thanks for help.
And epoch was added only to allow transition update 1.70 to 1.8.5, as 1.70 treated as greater version then 1.8.5, and I do not willing mangle upstream version enumeration to anything like 1.85 or so on...
Oh, Christopher, why you do not push update for 1.8.5-4 to Fedora 15?? Is it intensionally, or I could do that??
But kdudka in update reported that there no enough symbols present (https://admin.fedoraproject.org/updates/js-1.8.5-3.fc15). So, we can't update this update to do not provide some capability layer or keep 2 versions of library stimulation.
(In reply to comment #24) > Oh, Christopher, why you do not push update for 1.8.5-4 to Fedora 15?? Is it > intensionally, or I could do that?? Because I expected we'd need to do rebuilds. In fact, I didn't notice that you pushed an update, I would have expected things to fail since they'd need to be rebuilt at the very least for the change in UTF8 foo. I already sent mail to you privately that we're going to do those rebuilds. When they are done, we'll submit the update.
Rebuilds is not single what necessary there. As we have fully incompatible stack. It is my mistake, I had not read mozilla page carefully (really I had not read at at all, just grab url of new sources). Sorry to all. So, now we have one chance got it In Fedora - add as separate library which does not conflict with old one. There two options: 1) Add to package 2 sources and build and install both versions. 2) Make separate RPM package and name it something like js185, or js18, or may be mozjs (most preferable in on my choose). In this case separate review needed. I think second is most correct way, and previous builds even in rawhide must be reverted. If you want, I ready make such package and submit it on review.
I know that we need code updates, not just rebuilds. We have patches for couchdb and elinks already. Working on the others.
*** Bug 696673 has been marked as a duplicate of this bug. ***
You plan patch all dependencies?
(In reply to comment #30) > You plan patch all dependencies? I really wish you'd have read the email I sent you two days ago... :-( Yes. The full list is not that big, we'll patch them all and submit the update afterward.
*** Bug 696825 has been marked as a duplicate of this bug. ***
Sorry, I found it. I answer you by mail.
An upstream patch for elinks has just appeared in their git repo: http://repo.or.cz/w/elinks.git/commitdiff/2844f8b What is the current state of this bug?
Cool. I know there are patches for erlang-js and callweaver already in Fedora. And I think jhorak has a patch floating around for couchdb, and stransky's working on another package. Not too many more packages left, so I'd say let's get elinks built with that patch!
Well - upstream comment about elinks patch is "It compiles, but not tested" ... I really don't like this API breakage so late in release cycle. If spidermonkey > 1.8 will be used in f15 (and it really seems so), maybe better way would be to disable js-devel buildrequires in elinks - at least for a while ... and to try get it stable before pushing f15 update with reenabled js support.
I have cloned this bug for elinks - bug 698679 - and prepared a rawhide build of elinks against js-1.8.5. I am not sure how to test that it works properly, tried to enable ECMASCript, which is disabled by default, and went though some web pages. It did not crash.
Is js-1.8.5 still going to appear in f15? I am able to build elinks against it using the upstream patches, but such a build will not be installable against the old version of js.
mongodb-1.8.0-3.fc15, mediatomb-0.12.1-10.fc15, gxine-0.5.905-6.fc15, erlang-js-0.5.0-4.fc15, couchdb-1.0.2-2.fc15, callweaver-1.2.1-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/mongodb-1.8.0-3.fc15,mediatomb-0.12.1-10.fc15,gxine-0.5.905-6.fc15,erlang-js-0.5.0-4.fc15,couchdb-1.0.2-2.fc15,callweaver-1.2.1-9.fc15
Package mongodb-1.8.0-3.fc15, mediatomb-0.12.1-10.fc15, gxine-0.5.905-6.fc15, erlang-js-0.5.0-4.fc15, couchdb-1.0.2-2.fc15, callweaver-1.2.1-9.fc15, elinks-0.12-0.25.pre5.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mongodb-1.8.0-3.fc15 mediatomb-0.12.1-10.fc15 gxine-0.5.905-6.fc15 erlang-js-0.5.0-4.fc15 couchdb-1.0.2-2.fc15 callweaver-1.2.1-9.fc15 elinks-0.12-0.25.pre5.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/elinks-0.12-0.25.pre5.fc15,mongodb-1.8.0-3.fc15,mediatomb-0.12.1-10.fc15,gxine-0.5.905-6.fc15,erlang-js-0.5.0-4.fc15,couchdb-1.0.2-2.fc15,callweaver-1.2.1-9.fc15 then log in and leave karma (feedback).
(In reply to comment #40) > Package mongodb-1.8.0-3.fc15, mediatomb-0.12.1-10.fc15, gxine-0.5.905-6.fc15, > erlang-js-0.5.0-4.fc15, couchdb-1.0.2-2.fc15, callweaver-1.2.1-9.fc15, > elinks-0.12-0.25.pre5.fc15: > * should fix your issue, No js package here ^^^. Switching back to MODIFIED.
Package mongodb-1.8.0-3.fc15, mediatomb-0.12.1-10.fc15, gxine-0.5.905-6.fc15, erlang-js-0.5.0-4.fc15, couchdb-1.0.2-2.fc15, callweaver-1.2.1-9.fc15, elinks-0.12-0.25.pre5.fc15, js-1.8.5-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mongodb-1.8.0-3.fc15 mediatomb-0.12.1-10.fc15 gxine-0.5.905-6.fc15 erlang-js-0.5.0-4.fc15 couchdb-1.0.2-2.fc15 callweaver-1.2.1-9.fc15 elinks-0.12-0.25.pre5.fc15 js-1.8.5-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/js-1.8.5-4.fc15,elinks-0.12-0.25.pre5.fc15,mongodb-1.8.0-3.fc15,mediatomb-0.12.1-10.fc15,gxine-0.5.905-6.fc15,erlang-js-0.5.0-4.fc15,couchdb-1.0.2-2.fc15,callweaver-1.2.1-9.fc15 then log in and leave karma (feedback).
I just filed https://bugzilla.redhat.com/show_bug.cgi?id=705816 which is a segfault that seems the consequence of the js update to 1.8.5 it works against the previous couchdb/js package.
*** Bug 707544 has been marked as a duplicate of this bug. ***
*** Bug 708720 has been marked as a duplicate of this bug. ***
mongodb-1.8.0-3.fc15, mediatomb-0.12.1-10.fc15, gxine-0.5.905-6.fc15, erlang-js-0.5.0-4.fc15, callweaver-1.2.1-9.fc15, elinks-0.12-0.25.pre5.fc15, js-1.8.5-4.fc15, couchdb-1.0.2-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.