Last Comment Bug 307225 - Language packs for Firefox 1.5 Beta need chrome.manifest files in order to install
: Language packs for Firefox 1.5 Beta need chrome.manifest files in order to in...
Status: RESOLVED FIXED
: fixed1.8
Product: Core
Classification: Components
Component: Localization (show other bugs)
: 1.8 Branch
: All All
: -- major (vote)
: ---
Assigned To: Axel Hecht [:Pike]
:
:
Mentors:
http://ftp.mozilla.org/pub/mozilla.or...
: 309716 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-06 08:33 PDT by Teune van Steeg
Modified: 2005-10-02 04:45 PDT (History)
5 users (show)
mtschrep: blocking1.8b5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
chrome.manifest file I created for fr (french) language pack (647 bytes, text/plain)
2005-09-06 08:50 PDT, Teune van Steeg
no flags Details
modified install.rdf for fr (French) language pack (1.60 KB, text/plain)
2005-09-06 08:56 PDT, Teune van Steeg
no flags Details
fix language pack building (2.99 KB, patch)
2005-09-16 03:51 PDT, Axel Hecht [:Pike]
gandalf: review+
coop: review+
asa: approval1.8b5+
Details | Diff | Splinter Review
build and ship chrome.manifest for all but macs (1.37 KB, patch)
2005-09-23 05:12 PDT, Axel Hecht [:Pike]
benjamin: review-
Details | Diff | Splinter Review
Process the "-e" option to make-jars.pl correctly [checked in on 1.8 branch] (575 bytes, patch)
2005-09-28 08:30 PDT, Benjamin Smedberg [:bsmedberg]
l10n: review+
mtschrep: approval1.8b5+
Details | Diff | Splinter Review
... same fix for mail (2.24 KB, patch)
2005-09-30 09:57 PDT, Axel Hecht [:Pike]
benjamin: review+
mscott: superreview+
mscott: approval1.8b5+
Details | Diff | Splinter Review

Description Teune van Steeg 2005-09-06 08:33:56 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050905 Firefox/1.0+

Currently language packs won't install in recent 1.0+ branch builds, because of
a failed chrome registration. This is because the language packs don't contain
contents.rdf files anymore. 

When I manually add a chrome.manifest file based on the install.rdf file (and
raise the em maxVersion to 1.0+), the language packs install without any problem.

Further more, according to the install.rdf specs at
http://www.mozilla.org/projects/firefox/extensions/packaging/extensions.html an
em:type entry has to be specified in the install.rdf file (type=8 for
localizations), but I don't think leaving that out will not install the language
pack

Reproducible: Always

Steps to Reproduce:
1. download language pack from given url
2. manually raise the maxVersion to 1.0+ in install.rdf so it will install in
recent 1.0+ nightly
3. drag and drop modified xpi in browser, so it will install
4. restart Firefox 
5. Notice chrome registration failed error

Actual Results:  
Language pack will not install with error dialog saying that chrome registration
failed

Expected Results:  
chrome registration should be succesfull

When a chrome.manifest file is added to the language pack, the em:file
information in install.rdf could be removed, because that is not necessary anymore.

BTW: I use the language packs to test localizations of my extensions, so I don't
have to download several different localized builds.
Comment 1 Teune van Steeg 2005-09-06 08:50:04 PDT
Created attachment 195014 [details]
chrome.manifest file I created for fr (french) language pack

With this chrome.manifest file added to the French (fr) language pack, and a
modified install.rdf (which I will attach next), the language pack installed
without a problem
Comment 2 Teune van Steeg 2005-09-06 08:56:35 PDT
Created attachment 195015 [details]
modified install.rdf for fr (French) language pack

In this file I commented out the em:file declaration, because with a
chrome.manifest file this is not necessary anymore.

I also added this line <em:type>8</em:type> to show it is a localization.

And I raised the maxVersion to 1.4 (so it will work when the version of Firefox
is raised to 1.4). Apart from the last step, these modifications are not
necessary to install the language pack correctly in the latest
mozilla1.8-branch Firefox nightly
Comment 3 Teune van Steeg 2005-09-06 09:25:50 PDT
changing from Product: Mozilla Localizations, Component: Other to Product: Core,
Component: Localization, because I think it's better off here.

And asking blocking 1.8b5, as I think this should be fixed before Firefox 1.5
comes out and I can't ask for blocking-aviary1.5 here.
Comment 4 Axel Hecht [:Pike] 2005-09-16 03:41:52 PDT
I'll be driving this, patch coming up. It'd be good to have this on the branch,
too.
This is merely l10n language packaging build foo, so no l10n impact per-se.
Comment 5 Axel Hecht [:Pike] 2005-09-16 03:43:38 PDT
CCing localizers, though there is no l10n impact codewise, this is still 
interesting.
Comment 6 Axel Hecht [:Pike] 2005-09-16 03:51:57 PDT
Created attachment 196307 [details] [diff] [review]
fix language pack building

This patch does the following fixes to the generic install.rdf:
It removes the obsolete em:file stuff, add em:type and uses @MOZ_APP_VERSION@
for
em:minVersion and maxVersion, as the build is checking for compatibility
anyway.

In addition, I added a USE_EXTENSION_MANIFEST=1 to the phase that builds the
langpacks, so that chrome.manifest is generated (it looks like the one
attached),
and pack that generated file, those are the changes to Makefile.in.
Comment 7 Zibi Braniecki [:gandalf][:zibi] 2005-09-16 04:00:47 PDT
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

r+
Comment 8 Axel Hecht [:Pike] 2005-09-16 07:54:52 PDT
fix landed on the trunk, letting it smoke for a bit.
Comment 9 Axel Hecht [:Pike] 2005-09-16 12:24:27 PDT
Backed out the Makefile.in part, as that busted macs.

I'd be thankful if someone could run make -n with the modified makefile and 
compare that to http://www.math.hu-berlin.de/~hecht/build.log, as that
does give -c l10n-source, which the macs complain about.

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-da/1126875840.20470.gz
is an example build log of the bustage (not special to da, other builds at
the time are busted the same way).
Comment 10 Asa Dotzler [:asa] 2005-09-22 12:16:33 PDT
Axel, we need to get this in the branch ASAP. Is it ready to go?
Comment 11 Axel Hecht [:Pike] 2005-09-22 14:36:43 PDT
macs refused to give a profound reason for the error message so far, I'll provide
a patch that just disables the chrome.manifest building for the mac, unless
bsmedberg has a cycle to investigate. I looked at a log of make -n, and even on
a mac, the locale dir argument is given. May be escaping or file path fun or
whatever, I'll need a mac to do some perl -d.

Anyway, if the locale xpis built on mac don't make nice langpacks, that's not too
bad.
Comment 12 Axel Hecht [:Pike] 2005-09-23 04:52:03 PDT
*** Bug 309716 has been marked as a duplicate of this bug. ***
Comment 13 Axel Hecht [:Pike] 2005-09-23 05:12:02 PDT
Created attachment 197170 [details] [diff] [review]
build and ship chrome.manifest for all but macs

I want benjamin to review this, this is his baby and I hack it.
Comment 14 AlexIhrig 2005-09-24 15:11:39 PDT
Not sure, if it is related to this bug:

<maxversion> is still set to 1.1 in latest langpacks.

This should be the coresponding version (1.4 at this time) to the relating binaries.
Comment 15 Benjamin Smedberg [:bsmedberg] 2005-09-25 09:59:26 PDT
Comment on attachment 197170 [details] [diff] [review]
build and ship chrome.manifest for all but macs

Well, that's more than a little weird, and it should probably be investigated.
But the hack-solution ought to be to ifdef
http://lxr.mozilla.org/mozilla/source/browser/locales/Makefile.in#252 so that
we don't try to make the langpack at all on mac.
Comment 16 Axel Hecht [:Pike] 2005-09-25 10:36:01 PDT
Re #14, this bug isn't fixed for mail at all, 
http://lxr.mozilla.org/mozilla/source/mail/locales/generic/install.rdf.

Benjamin, I need someone with a mac and perl debugger time to solve this right
for 1.5.
Hacking the langpack out of there is more intrusive than justified, IMHO,
as we call the libs phase there. I do expect to have a mac at my disposal post
1.5, too, and I plan to pick this up then.

As we're talking, I would like to set max and minor version of the langpack to
the branch base version and the branch head version, respectively. Something
equivalent to 1.0 and 1.0.7. Any idea for that?
Comment 17 Benjamin Smedberg [:bsmedberg] 2005-09-28 08:30:29 PDT
Created attachment 197705 [details] [diff] [review]
Process the "-e" option to make-jars.pl correctly [checked in on 1.8 branch]
Comment 18 Benjamin Smedberg [:bsmedberg] 2005-09-28 08:51:37 PDT
Attachment 197705 [details] [diff] checked in on trunk.
Comment 19 Mike Schroepfer 2005-09-28 11:15:39 PDT
Comment on attachment 197705 [details] [diff] [review]
Process the "-e" option to make-jars.pl correctly [checked in on 1.8 branch]

Approved for 1.8b5.
Comment 20 Axel Hecht [:Pike] 2005-09-28 13:59:17 PDT
Relanded the backed out part of attachement 196307, thanks to bsmedberg for 
finding the bug in make-js.pl.

Leaving open for the mail part of this.
Comment 21 Axel Hecht [:Pike] 2005-09-28 14:16:00 PDT
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

Requesting approval, this is a l10n langpack-only change that does not require
interaction from l10n owners.

Now that the trunk and the branch have the required fix, this is low risk.
Comment 22 Asa Dotzler [:asa] 2005-09-29 11:19:33 PDT
Comment on attachment 196307 [details] [diff] [review]
fix language pack building

do we need to make these same changes to Thunderbird? If so, can we get a patch
here or in a new bug please? thanks.
Comment 23 Axel Hecht [:Pike] 2005-09-30 09:57:05 PDT
Created attachment 198010 [details] [diff] [review]
... same fix for mail
Comment 24 Axel Hecht [:Pike] 2005-10-02 04:45:14 PDT
Fixed for both thunderbird and firefox on both trunk and 1.5 branch.

Note You need to log in before you can comment on or make changes to this bug.