Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 218147
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Mozilla Gentoo Team <mozilla@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Martin von Gagern <Martin.vGagern@gmx.net>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 218147 depends on: Show dependency tree
Bug 218147 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2008-04-17 18:51 0000
I have LINGUAS="en de en_US en_GB" in my /etc/make.conf, and suddenly the
latest Thunderbird runs with German UI by default. Some investigation showed a
missing IUSE to be the reason. The order of LINGUAS is taken from the LINGUAS
variable, but it is filtered with the IUSE settings of the ebuild. Therefore,
the ebuild sees LINGUAS="de en_GB" and consequently sets de to be the default
UI language.

Simply adding linguas_en (and probably linguas_en_US as well) to the IUSE seems
to be the easiest workaround, as there are already some places in the ebuild
doing special handling for en.

My system is portage 2.1.5_rc3, LINGUAS="en de en_US en_GB". I guess the rest
of emerge --info should be unimportant.

Workaround for users hit by this bug: start with "thunderbird -UILocale en" or
change general.useragent.locale in your config editor or prefs.js

------- Comment #1 From Koy Rehme 2008-04-18 15:54:55 0000 -------
This bug seems to be hitting mozilla-firefox-2.0.0.14 for me as well.  Adding 
linguas_en fixes it there, too.

------- Comment #2 From Raúl Porcel 2008-04-18 16:29:46 0000 -------
And why don't you set en_US before de?

------- Comment #3 From Koy Rehme 2008-04-18 16:47:36 0000 -------
Confirmed that I have the problem for mozilla-thunderbird as well.  Also, I
forgot to post my LINGUAS:

LINGUAS="en_US en pt_BR"

(Notice that I do have both en and en_US before pt_BR.)

------- Comment #4 From Raúl Porcel 2008-04-18 17:35:58 0000 -------
Can you guys test with =portage-2.1.4*, in case its a portage regression?

------- Comment #5 From Martin von Gagern 2008-04-18 17:55:57 0000 -------
(In reply to comment #2)
> And why don't you set en_US before de?

Wouldn't help, as en_US gets filtered due to missing IUSE as well, as seen from
the shortened LINGUAS in comment #0 or the case from comment #3.

Generally I'd expect every ebuild that understands en_US and also cares for
order to understand en as well, as there are probably many more people out
there giving only short language codes without country codes. I agree, though,
that putting all en_* before de would be more appropriate. Doesn't mater here,
though.

(In reply to comment #4)
> Can you guys test with =portage-2.1.4*, in case its a portage regression?

Yes, indeed portage 2.1.4 doesn't filter en.

From the portage-2.1.5_rc3.diff ChangeLog entry concerning pym/portage.py:
+  9853 zmedico  Bug #215016 - When transforming of USE flags to USE_EXPAND
+                variables, filter out flags that aren't considered to be part
+                of IUSE or implicit IUSE. This patch moves all IUSE dependent
+                code from config.regenerate() to config.setcpv(). (trunk
+                r9852)

There is also a large hunk on this in the diff.

------- Comment #6 From Raúl Porcel 2008-04-19 16:27:47 0000 -------
Should be fixed now

------- Comment #7 From Raúl Porcel 2008-04-21 06:30:00 0000 -------
*** Bug 218685 has been marked as a duplicate of this bug. ***

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug