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
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).
In the install log I can see some "Access denied" errors. Could you report the permissions set for the chrome/ and defaults/profile/ folders ?
*** This bug has been marked as a duplicate of 109044 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
hang on, made a mistake here, repoening
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.0
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)
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...
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.
Changing the resolution as FIXED. Please add your comment here if you think this is not the case.
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.