Closed Bug 609430 Opened 11 years ago Closed 11 years ago

Fx 4 Beta 2 build 2 builds have a borked chrome.manifest

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set
blocker

Tracking

(fennec2.0b3+)

RESOLVED DUPLICATE of bug 605411
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: aakashd, Assigned: mwu)

References

Details

Attachments

(1 file)

Attached image bug screenshot
Build Id:
Mozilla/5.0 (maemol Linux armv7l; rv:2.0b7pre) Gecko/20101103 Firefox/4.0b8pre Fennec/4.0b2

Note: This may be related to bug 575751

Steps to Reproduce:
1. Go to http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/4.0b2-candidates/repos/lt/
2. Install the .install within the directory
3. Install the candidate build
4. Start it up

Actual Results:
XML error on start-up "<window id=main-window"" (See attachment)

Expected Results:
The build should start-up.
tracking-fennec: --- → ?
AFAICT, it is a broken manifest, I unpacked the polish deb, 

wokbok:fennec-4.0b2 axelhecht$ cat chrome.manifest 
manifest components/interfaces.manifest
manifest components/nsINIProcessor.manifest
manifest components/nsProxyAutoConfig.manifest
manifest chrome/en-US.manifest
...
tracking-fennec: ? → 2.0b3+
Where is this broken? Repack code?
Assignee: nobody → l10n
I really don't know why you guys are so keen on assigning bugs to me that I'm not going to fix. I don't do builds nor packaging nor manifests.

And yes, that the chrome.manifest still points to en-US.manifest is a strong indication that repackaging doesn't work. Smells like a problem close to the one we have with the desktop builds.
Assignee: l10n → nobody
Chances are this will magically get fixed when bug 575751 lands, but assigning myself to this anyway.
Assignee: nobody → mwu
(In reply to comment #3)
> I really don't know why you guys are so keen on assigning bugs to me that I'm
> not going to fix. I don't do builds nor packaging nor manifests.
> 
> And yes, that the chrome.manifest still points to en-US.manifest is a strong
> indication that repackaging doesn't work. Smells like a problem close to the
> one we have with the desktop builds.

Where is the repacking code? And what drives it? If I can't get the code and try to run the repack locally, there is no way we can fix these kind of bugs.
It's in mobile-browser/locales/Makefile.in and parent makefiles, mostly.

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-es-ES and other locale tinderboxen have the logs, like http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-es-ES/1288861030.1288861090.14955.gz&fulltext=1

I can give you a nicer step-by-step how to repack for now, or you can look at the log.  In the future we're looking at having repack scripts that we'll use in automation, but developers can leverage as well.
(In reply to comment #6)
> It's in mobile-browser/locales/Makefile.in and parent makefiles, mostly.
> 
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-es-ES and other
> locale tinderboxen have the logs, like
> http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-es-ES/1288861030.1288861090.14955.gz&fulltext=1
> 
> I can give you a nicer step-by-step how to repack for now, or you can look at
> the log.  In the future we're looking at having repack scripts that we'll use
> in automation, but developers can leverage as well.

I think we're going to need some step by step how to for repacks if any progress is going to be made here.
http://l10n.mozilla.org/bounty/build/1895091 is step by step what the multi-locale builds do, i.e., they do an l10n-merge and then a make chrome-%.

Single-locale repack example step by step would be at http://l10n.mozilla.org/bounty/build/1895095, which doesn't have a useful stepname, but ends up doing a make installers-es-ES LOCALE_MERGEDIR=$PWD/merged
within "repack deb".
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 605411
You need to log in before you can comment on or make changes to this bug.