Hide Forgot
I just updated from F14, where I was using packaged Firefox 3 with the Sync extension installed from upstream, to Rawhide, which has Firefox 4 with Sync built-in. Unfortunately, Sync has stopped working. I tried removing the Sync plugin (which was still listed as installed) and re-configuring Sync, but it still fails. The configuration process works and it can connect to the Sync server, but actually syncing always fails immediately. I get the 'Error While Syncing' message in Firefox's status bar, and on the Error Console I have an error: couldn't open library file:///usr/lib64/xulrunner-2/components/WeaveCrypto.js Line: 137 I've verified that file exists and is part of the xulrunner package. Permissions: [root@adam adamw]# ls -lZ /usr/lib64/xulrunner-2/components/WeaveCrypto.js -rw-r--r--. root root system_u:object_r:lib_t:s0 /usr/lib64/xulrunner-2/components/WeaveCrypto.js SELinux is currently in Permissive mode, and I don't see any obvious errors in /var/log/messages . Line 137 of the file seems to be trying to open libnss. There's what looks like a useful logging reference above, but I don't know where Sync logs to.
ah. found it. about:sync-log URI. Neat. That gives: 2010-11-09 09:32:00 Service.Main DEBUG Crypto check failed: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://services-sync/util.js :: anonymous :: line 365" data: no] 2010-11-09 09:32:00 Service.Main INFO Could not load the Weave crypto component. Disabling Weave, since it will not work correctly. 2010-11-09 09:32:00 Service.Main INFO Weave Sync disabled -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
tried a quick-n-dirty 'ln -s /usr/lib64/libnss3.so /usr/lib' and that didn't help, FWIW. attaching the .js file as requested by mcepl. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 459221 [details] WeaveCrypto.js file
The code in question is this: // Open the NSS library. let nssfile = Services.dirsvc.get("GreD", Ci.nsILocalFile); let os = Services.appinfo.OS; switch (os) { case "WINNT": case "WINMO": case "WINCE": nssfile.append("nss3.dll"); break; case "Darwin": nssfile.append("libnss3.dylib"); break; case "Linux": case "SunOS": case "WebOS": // Palm Pre nssfile.append("libnss3.so"); break; case "Android": // Android uses a $GREDIR/lib/ subdir. nssfile.append("lib"); nssfile.append("libnss3.so"); break; default: throw Components.Exception("unsupported platform: " + os, Cr.NS_ERROR_UNEXPECTED); } this.log("Using NSS library " + nssfile.path); // XXX really want to be able to pass specific dlopen flags here. let nsslib = ctypes.open(nssfile.path); Seems to me like it is looking for libnss3.so in the XULRunner's directory, but not for the system library we link XULRunner against.
And of course, this bug is triaged as I can fully reproduce it even on i686 system.
as a random side note, I've run upstream Firefox 4 beta tarballs on F14 and not seen this (sync works if you run an upstream Beta tarball on top of Fedora, in all my attempts). lots of variables there, though. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #6) > as a random side note, I've run upstream Firefox 4 beta tarballs on F14 and not > seen this (sync works if you run an upstream Beta tarball on top of Fedora, in > all my attempts). lots of variables there, though. That would agree with my theory in the comment 4 ... upstream Firefox obviously finds libnss3.so in the Firefox directory.
I think this may be: https://bugzilla.mozilla.org/show_bug.cgi?id=583209 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yep, applying the patch from upstream for that bug fixes the problem. Then you hit a *different* problem - http://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/3371cdef2ff5fb55?tvc=2&fwc=1 - which will be fixed when we push beta 7. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #9) > Yep, applying the patch from upstream for that bug fixes the problem. Then you > hit a *different* problem - > http://groups.google.com/group/mozilla-labs-weave/browse_thread/thread/3371cdef2ff5fb55?tvc=2&fwc=1 > - which will be fixed when we push beta 7. If I understand that http://snarkfest.net/blog/2010/09/28/using-sync-on-the-bleeding-edge/ correctly you may be saved even in the current situation by uninstalling addon and removing manually Sync store (no idea where it is; don't forget to backup your profile) and resyncing from the server your data to built-in old Sync. Otherwise, yes, releasing addon incompatible with the main Firefox ... oh well :(
Concerning FF4b7 the only thing I see is https://wiki.mozilla.org/Releases Firefox 4.0 Beta 7 | 2nd Half of September (tentative - behind schedule) :( https://wiki.mozilla.org/Releases/Firefox_4.0b7 has a bit more details, but nothing more certain.
I saw a news story yesterday saying it was coming out today. We'll see. I went with the easy fix the to FF4b6's-sync-is-too-old problem - just install the Sync plugin v1.5. It works fine that way. You would think they'd fight or something, but apparently not. I can't just revert to the older Sync, because my other systems run F14 with its packaged FF3, so no in-built Sync, so they have to use the plugin - and it's hard to run Firefox with an out of date plugin. It reeaaalllly wants them to be up to date. :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
it'd be trivial to patch this until the beta comes out, btw, but since you still need to manually work around the 'sync-is-too-old' bug and the beta's supposed to come soon, it may not be worth it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
ff4b7 came out today, I believe that both issues would be solved with an update to that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Beta 7 should be in rawhide now.
nope, the xulrunner and firefox builds both failed :) I emailed you fixes for xulrunner build (just need to drop a patch and rediff another, IIRC). firefox needs a trivial rediff to one patch, not sure beyond that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
actually, i didn't send the fix to you, but to dan and jan. I can forward to you if you like. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
jon, I see you CCed yourself - if you want to fix this for yourself while we wait for the ff4b7 build to go through (I'd have fixed it up but I don't have access to firefox build), then all you need to do is patch the installed file manually with the changes from https://bugzilla.mozilla.org/show_bug.cgi?id=583209 , and then install the Sync 1.5.1 plugin, and it'll start working. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam, did the new build and patch work for you? I'm using Tom's Firefox 4 build for F14 that includes the fixes, but Sync still fails for me (same error as you). Tried SELinux in permissive mode, too.
(In reply to comment #20) > Adam, did the new build and patch work for you? I'm using Tom's Firefox 4 build > for F14 that includes the fixes, but Sync still fails for me (same error as > you). Tried SELinux in permissive mode, too. Making a symbolic link in /usr/lib64/xulrunner-2.0b7 to /usr/lib64/libnss3.so fixes it. I'll note this to Tom.
yes, it works fine for me. didn't have to add any symbolic links. if you added the extension to make it work in b6, you have to remove the extension for b7 to be happy, though.
I still had the extension installed... shame on me. Symbolic link no longer required.
Okay, closing.