140949 - install of italian language pack succeeds but says chrome registration failure and language is not available after restart

Status: RESOLVED FIXED

(Mozilla Localizations :: it / Italian, defect)

Description

[mrgrimm]

upon installing italian language pack, after directions come up (in italian) for
setting the language to italian, a box says chrome registration failed and
italian is not available language pack after restart

Comment 1

[Andrea]

Sorry, can't reproduce.
Are you sure having done a _clean_ Mozilla installation? I mean, have you
deleted the .mozilla folder on your profile before using the new version?

Please try to clean everything, reinstall and try again.

I'd also like some more info like the distribution you're running Mozilla on,
the kernel version, if you installed the lang pack logged as user or super-user,
from where did you installed the lang pack.. and anything else you think it
might be worth to mention.

If you can, please attach the install.log file you should find either on your
mozilla folder or in your profile .mozilla/ folder (this folder is hidden).

Comment 2

[Andrea]

Attachment: Reperte's install log

Comment 3

[Andrea]

In the install log I can see some "Access denied" errors.
Could you report the permissions set for the chrome/ and defaults/profile/ 
folders ?

Comment 4

[Michael Hendy (Hendikins)]

*** This bug has been marked as a duplicate of 109044 ***

Comment 5

[Michael Hendy (Hendikins)]

hang on, made a mistake here, repoening

Comment 6

[Andrea]

The bug is on the lang pack install script.
It needs to fail gracefully if the user can't access the bin/defaults/ folder in
a multi user enviroment.

Comment 7

[Andrea]

Resuming what's going on:

The user uses a build owned by root, with no access to the folders under
usr/lib/mozilla/.

The Italian lang pack normally detects the inability to write in these folders (
-202 = access denied). Then install script reset the error condition, and it try
to install inside the user profile. There, the files are normally copied.

Somehow then then the copied components fail to register ( -239 = registry error).
I could suspect this is due the inability for the mozilla process - now owned by
user (right?) - to write access the registry files, root owned.

Looking through the attached user's install.log, it seems the Asturian language
pack, and then the Asturies contents pack, after going through basically the
same steps, *succeeds* on registering the components copied in the profile folders.

I have no clue the reasons why :\\

I really think there might be a link between this bug and bug 109044. (But pls
don't resolve it as a dupe if don't have a clue about the causes)

Comment 8

[Robert Kaiser]

Andrea:
In the attached install.log file, you see the installation of my German pack as
the last entry. The default XPI of MT5beta8 should look simialr, and the user
gets an alert telling him that he needs write permissions to the mozilla main
directory.

The real problem is that we need to install with DELAYED_CHROME (via
installed-chrome.txt) on unix due to bug 109044 and DELAYED_CHROME does not work
with an install in the profile directory.
So we only can install in the profile directory on win and mac platforms (the
MT5beta8 script checks for this and does it), but not on unix where we would
potentially need that most :(

Due to that reasons, I'd think it will be best to mark this one dependent on bug
109044 - but it's your bug, so you should do/decide that...

Comment 9

[Andrea]

Yes. I'm marking this bug as fixed.
I'm removing the completely the DELAYED_CHROME switch from my RC2 and RC3 lang
packs, waiting in bug 109044 for someone else confirming the bug is still valid.

Comment 10

[Andrea]

Changing the resolution as FIXED.
Please add your comment here if you think this is not the case.