Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 361433 - www-client/firefox-bin-4.0 fails when setting locale
Summary: www-client/firefox-bin-4.0 fails when setting locale
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 7 votes (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
: 364777 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-31 09:38 UTC by Marco Leogrande
Modified: 2011-05-11 20:55 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
firefox-bin-4.0.ebuild patch (firefox-bin-4.0.patch,633 bytes, patch)
2011-04-02 13:11 UTC, Vasiliy Olekhov
Details | Diff
Patch to the current ebuild to make it work (firefox-4-locale.ebuild.patch,674 bytes, patch)
2011-04-02 13:23 UTC, Marco Leogrande
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Leogrande 2011-03-31 09:38:11 UTC
The install phase of www-client/firefox-bin-4.0 fails when trying to set the default locale preference.

 * Setting default locale to it
sed: impossibile leggere /var/tmp/portage/www-client/firefox-bin-4.0/image//opt/firefox/defaults/pref/firefox.js: No such file or directory
sed: impossibile leggere /var/tmp/portage/www-client/firefox-bin-4.0/image//opt/firefox/defaults/pref/firefox-l10n.js: No such file or directory
 * ERROR: www-client/firefox-bin-4.0 failed (install phase):
 *   sed failed to change locale

In particular, the sed line fails because the files "${D}${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}.js and  "${D}${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}-l10n.js are just not there. That directory is actually pretty empty (I see only a single file with two lines).
Online resources point out that those two files were moved inside a compressed file, omni.jar, that is present in "${D}${MOZILLA_FIVE_HOME}". I have uncompressed it and I can confirm that this is the case.

I have not tried to mangle with the jar file, but if that sed command is commented out and a firefox.js is *created* in "${D}${MOZILLA_FIVE_HOME}/defaults/pref/" with content:

pref("general.useragent.locale", "it");

Firefox 4 starts with my locale.
Comment 1 Maxim Vorontsov 2011-03-31 18:01:55 UTC
I also have this bug.
Comment 2 Paweł Rumian 2011-03-31 19:45:16 UTC
same here - x86 with 'linguas_pl'.
Comment 3 svenvermant 2011-04-01 07:17:16 UTC
same on x86 with 'linguas_de'
Comment 4 Vasiliy Olekhov 2011-04-02 12:52:32 UTC
same on x86, with linguas_ru
Comment 5 Vasiliy Olekhov 2011-04-02 13:11:31 UTC
Created attachment 268203 [details, diff]
firefox-bin-4.0.ebuild patch

to apply patch:

mkdir -p /usr/local/portage/www-client
cp -rv /usr/portage/www-client/firefox-bin /usr/local/portage/www-client
cd /usr/local/portage/www-client/firefox-bin
patch < firefox-bin-4.0.patch
Comment 6 Vasiliy Olekhov 2011-04-02 13:12:36 UTC
(In reply to comment #4)
> same on x86, with linguas_ru

ok, seems there is typo.

lines 135-136 or so in file /usr/portage/www-client/firefox-bin/firefox-bin-4.0.ebuild:

       sed -e "s:general.useragent.locale\", \"en-US\":general.useragent.locale\", \"${LANG}\":" \
            -i "${D}${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}.js \
            -i "${D}${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}-l10n.js || \

the ${D}'s are superflous.

here is workaround:
1. make a local copy for ebuild:
mkdir -p /usr/local/portage/www-client
cp -rv /usr/portage/www-client/firefox-bin /usr/local/portage/www-client
2. patch /usr/local/portage/www-client/firefox-bin/firefox-bin-4.0.ebuild with supplied patch:

cd /usr/local/portage/www-client/firefox-bin
patch <firefox-4.0.patch

or just remove ${D} from sed args. should looks like this:

       sed -e "s:general.useragent.locale\", \"en-US\":general.useragent.locale\", \"${LANG}\":" \
            -i "${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}.js \
            -i "${MOZILLA_FIVE_HOME}"/defaults/pref/${MY_PN}-l10n.js || \

3. update manifest:

ebuild firefox-bin-4.0.ebuild manifest

4. check you have your local portage tree in path, your /etc/make.conf should contain something like
PORTDIR_OVERLAY="/usr/local/portage"

5. emerge firefox-bin
Comment 7 Marco Leogrande 2011-04-02 13:21:37 UTC
(In reply to comment #6)
> the ${D}'s are superflous.

Hmm, not quite. Removing the ${D} you edit the files on the live filesystem, breaking sandboxing.

I'll attach the patch that I've been using locally, that substitutes the sed in the ebuild with an "echo" that works.
Comment 8 Marco Leogrande 2011-04-02 13:23:40 UTC
Created attachment 268209 [details, diff]
Patch to the current ebuild to make it work

The sed line is changed with a redirected echo, that creates the (now missing) preference file.
Comment 9 Felix Leimbach 2011-04-07 20:50:55 UTC
Patch from comment #8 works fine on ~amd64
Comment 10 zlm 2011-04-08 20:35:01 UTC
Works fine on x86 too.
Comment 11 Michael Skiba 2011-04-10 15:44:03 UTC
(In reply to comment #9)
> Patch from comment #8 works fine on ~amd64
I second that
Comment 12 Hek Mek 2011-04-14 08:41:39 UTC
This seems to have been fixed with the patch submitted by comment #8, i.e. almost two weeks ago. Is there a reason this has not been merged into portage, yet?
Comment 13 Tiger 2011-04-20 20:21:58 UTC
Mozilla Gentoo Team in hollidays ? :)
Comment 14 Jory A. Pratt gentoo-dev 2011-04-21 01:21:20 UTC
(In reply to comment #13)
> Mozilla Gentoo Team in hollidays ? :)

As the main active developer for all mozilla ( minus seamonkey ) -bin packages fall into the class of when I get to them. As it stands I will be sending out an email announcing that if we do not find someone to maintain -bin packages we will p.mask and remove from tree.
Comment 15 Thomas Scheller 2011-04-29 10:47:29 UTC
*** Bug 364777 has been marked as a duplicate of this bug. ***
Comment 16 Marco Leogrande 2011-05-02 12:31:28 UTC
FYI, the patched ebuild seems to work also if bumped to firefox-bin-4.0.1.ebuild
Comment 17 Jory A. Pratt gentoo-dev 2011-05-11 20:55:53 UTC
Fixed in CVS thanks for providing the patch :)