Seamonkey comes without chatzilla, as stated during merge: * Messages for package www-client/seamonkey-2.53.20: * chatzilla is now an extension which can be en-/disabled and configured via * the Add-on manager. however, this appears not to be true. Reproducible: Always Steps to Reproduce: Install http://chatzilla.hacksrus.com/revisions 0.9.3 gets installed and see that it does not work. Actual Results: NS_ERROR_XPC_BAD_CONVERT_JS: Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface] @ <chrome://chatzilla/content/lib/js/pref-manager.js> 52 PrefManager@chrome://chatzilla/content/lib/js/pref-manager.js:52:25 initPrefs@chrome://chatzilla/content/prefs.js:16:26 init@chrome://chatzilla/content/static.js:126:5 onLoad@chrome://chatzilla/content/handlers.js:56:9 onload@chrome://chatzilla/content/chatzilla.xul:1:1 + toString (function) 3 lines + name (string) 'NS_ERROR_XPC_BAD_CONVERT_JS' + message (string) 'Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]' + result (number) 2153185289 + filename (string) 'chrome://chatzilla/content/lib/js/pref-manager.js' + lineNumber (number) 52 + columnNumber (number) 0 + data (object) null + stack (string) 271 chars + location (object) * Expected Results: Bundled version that works. Respect the chatzilla If I build and install seamonkey from sources (did that myself on another ssystem) it comes with a bundled ChatZilla 0.20 that just works. Why can't that be done from the ebuild with the "chatzilla" USE flag? Possibly SM keeps an update version shipped?
(In reply to Riccardo from comment #0) > Seamonkey comes without chatzilla, as stated during merge: > > * Messages for package www-client/seamonkey-2.53.20: > > * chatzilla is now an extension which can be en-/disabled and configured via > * the Add-on manager. > > however, this appears not to be true. I think the interpretation of this is different - in the sense that chatzilla is not an integral part of the suite, rather a separable extension. Ancient versions are likely not going to work due to intenal API changes. > Expected Results: > Bundled version that works. Respect the chatzilla > > If I build and install seamonkey from sources (did that myself on another > ssystem) it comes with a bundled ChatZilla 0.20 that just works. > > Why can't that be done from the ebuild with the "chatzilla" USE flag? > Possibly SM keeps an update version shipped? Looks like a glitch in the build somewhere - the +chatzilla used to work (i.e. bundle the extension). For 2.53.20 it doesn't seem to be the case any more, only the localization gets packaged. Bisecting the tree to localize when it stopped working might reveal some hints.
Maybe it has to do with the way it is built on gentoo. I did a build from Sources on FreeBSD and I got a working version of ChatZilla (it reports a newer version than the one downloaded as extension though, so perhaps in-tree changes).
Looking at line 484 and further in the 2.53.20 ebuild, it seems to do some locales-handling magic there. I wonder if that's causing this. What locales are you using?
I'm using the bin version 2.53.20 (outside of portage) and it has a working chatzilla binary.
I think gentoo should just the bundled chatzilla (again). My /etc/locale.gen has: en_US ISO-8859-1 en_US.UTF-8 UTF-8 it_IT ISO-8859-1 no explicit locale set. I tried setting LANG to en_US.UTF-8 but the error still happens.
extensions directory from builds with the same flags: seamonkey-2.53.7.1: /usr/lib64/seamonkey/extensions/inspector@mozilla.org.xpi /usr/lib64/seamonkey/extensions/langpack-cs@seamonkey.mozilla.org /usr/lib64/seamonkey/extensions/langpack-en-GB@seamonkey.mozilla.org /usr/lib64/seamonkey/extensions/modern@themes.mozilla.org.xpi /usr/lib64/seamonkey/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2} /usr/lib64/seamonkey/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi /usr/lib64/seamonkey/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi seamonkey-2.53.18.2-r2 /usr/lib64/seamonkey/extensions/inspector@mozilla.org.xpi /usr/lib64/seamonkey/extensions/langpack-cs@seamonkey.mozilla.org /usr/lib64/seamonkey/extensions/langpack-en-GB@seamonkey.mozilla.org /usr/lib64/seamonkey/extensions/modern@themes.mozilla.org.xpi /usr/lib64/seamonkey/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi /usr/lib64/seamonkey/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi /usr/lib64/seamonkey/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2} is the system (bundled) chatzilla built from source. For seamonkey-2.53.20 is the same as seamonkey-2.53.18.2-r2. I'm trying to build older ones, but it's a bit tricky, since it requires older python versions etc (and I don't want to downgrade whole build environment unless strictly necessary).
(In reply to Petr Cerny [:hrosik] from comment #6) > extensions directory from builds with the same flags: > > seamonkey-2.53.7.1: > /usr/lib64/seamonkey/extensions/inspector@mozilla.org.xpi > /usr/lib64/seamonkey/extensions/langpack-cs@seamonkey.mozilla.org > /usr/lib64/seamonkey/extensions/langpack-en-GB@seamonkey.mozilla.org > /usr/lib64/seamonkey/extensions/modern@themes.mozilla.org.xpi > /usr/lib64/seamonkey/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2} > /usr/lib64/seamonkey/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi > /usr/lib64/seamonkey/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi > Is that filename correct? Missing the .xpi extention? I've done some tests on my side and found a way to fix the issue, so no further testing would be needed.
yes, I think the extension is not installed and xpi missing is also fishy. this is mine: inspector@mozilla.org.xpi modern@themes.mozilla.org.xpi {972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi {e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi nothing of {59c81df5-4b7a-477b-912d-4e0fdf64e5f2} with or without xpi extension, even if I build with chatzilla useflag.
(In reply to Myckel Habets from comment #7) > (In reply to Petr Cerny [:hrosik] from comment #6) > > extensions directory from builds with the same flags: > > > > seamonkey-2.53.7.1: > > ... > > /usr/lib64/seamonkey/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2} > > ... > > > > Is that filename correct? Missing the .xpi extention? Sorry, that was redacted for brevity - it actually is a directory with the extension content. But both should work IIUC: either unpacked extension tree or just the .xpi archive.
(In reply to Riccardo from comment #8) > yes, I think the extension is not installed and xpi missing is also fishy. > > nothing of {59c81df5-4b7a-477b-912d-4e0fdf64e5f2} with or without xpi > extension, even if I build with chatzilla useflag. What about your FreeBSD build? The extension should be there (one way or another) I suppose.
On FreeBSD my extensions are: -rw-r--r-- 1 multix staff 347127 Jan 30 20:46 inspector@mozilla.org.xpi -rw-r--r-- 1 multix staff 1053404 Jan 30 20:46 modern@themes.mozilla.org.xpi -rw-r--r-- 1 multix staff 343144 Jan 30 20:46 {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi -rw-r--r-- 1 multix staff 25703 Jan 30 20:46 {972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi -rw-r--r-- 1 multix staff 1250549 Jan 30 20:46 {e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi so it is there and, note, with xpi extension. This is a "build from source tarball" directly with ac_add_options --enable-irc
Looks like the extension is build but not packaged - splitting the emerge into individual steps and supplying the missing action produces desired output: $ cd $PORTDIR/www-client/seamonkey $ ebuild seamonkey-2.53.20.ebuild unpack prepare configure compile install $ cd PORTAGE_TMPDIR/portage/www-client/seamonkey-2.53.20 $ cp "work/seamonkey-2.53.20/seamonk/dist/bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi" "image/usr/lib64/seamonkey/extensions" $ cd $PORTDIR/www-client/seamonkey $ ebuild seamonkey-2.53.20.ebuild package Since I don't understand the eclasses magic I'm only guessing, that upstream changed from unpacked extension to packaged format and thus lines 488-499 in seamonkey-2.53.20.ebuild are no longer producing the desired result. A quickfix might be commenting out 488-490, but it may break locales (I would argue that temporarily this may be a solution, given the general user group of chatzilla).
(In reply to Petr Cerny [:hrosik] from comment #12) > > Since I don't understand the eclasses magic I'm only guessing, that upstream > changed from unpacked extension to packaged format and thus lines 488-499 in > seamonkey-2.53.20.ebuild are no longer producing the desired result. > > A quickfix might be commenting out 488-490, but it may break locales (I > would argue that temporarily this may be a solution, given the general user > group of chatzilla). My guess is that this got broken somewhere and upstream fixed it, yet the eclasses magic broke somehow. Commenting out lines 488-490 AND 493 will solve the issue. Locales seem to be fine in my case (NL_nl), although they aren't packed within the .xpi, what this code tried to do. I'll leave this bug open for now, people who care about this can use the workaround mentioned above. When the next version comes around, I'll fix it in the ebuild.
