INNER_UNMAKE_PACKAGE doesn't work with omnijar

VERIFIED FIXED in Firefox 11

Status

()

Firefox for Android
General
P3
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Pike, Unassigned)

Tracking

unspecified
Firefox 12
Points:
---

Firefox Tracking Flags

(firefox11 fixed, fennec11+)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
omnijar unpackaging requires the INNER_UNMAKE_PACKAGE macro to end up in the same directory as before, which it currently does not.

At least I think so.

Addresses bug 698425 comment 27
(Reporter)

Comment 1

6 years ago
Created attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

Aki, does this patch help?

I'm totally confused for the signing stuff, if you could give this patch a spin with having the keys and stuff, that'd be great.
Attachment #581092 - Flags: feedback?(aki)

Comment 2

6 years ago
Comment on attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

This works! Also, I'm able to create what looks like a nightly-signed apk when I set the JARSIGNER env var appropriately.

I'm not able to test since my tablet is in the office and I'm at home, but I uploaded the nightly-signed German apk here:

  http://people.mozilla.org/~asasaki/fennec-11.0a1.de.android-arm.apk

I can test that tomorrow, or you or someone else can.

My only concern here, other than needing a quick install-and-run test:
lib.id seems to be missing its checksums; not sure if this matters:

< libfreebl3.so:FB77C0B2658DB678F47829FFA87A10BE0
< libmozalloc.so:5876F8A6F09E91C3C6F141A0F86ADABF0
< libmozsqlite3.so:E6D92BF363D7415A324744800AA3FF2D0
< libnspr4.so:BA6B76174980613F1F46981368489C820
< libnss3.so:94D6339E0AE1BD4A40AB2EE89A48F3040
< libnssckbi.so:ABD8FCB925F762BF7C2853BD489A5C720
< libnssutil3.so:B76362981BC41EE4917A2C2A4C9011CF0
< libplc4.so:845274FE43FF588A5D5E2036B5412F2D0
< libplds4.so:2DB5763233835C474CCFA09D5AE7FA7F0
< libsmime3.so:DF365E3B98F806091D362E8458C228450
< libsoftokn3.so:64420758328EAAC0919F4EF65D9B47760
< libssl3.so:DB9A7317A7B7CAD695C465F8D56DD49D0
< libxpcom.so:DE3D7B6DD0A4C52288C482AC93B095BC0
< libxul.so:C3E954AEF4A4215AED562D19172A4BE30
---
> libfreebl3.so:
> libmozalloc.so:
> libmozsqlite3.so:
> libnspr4.so:
> libnss3.so:
> libnssckbi.so:
> libnssutil3.so:
> libplc4.so:
> libplds4.so:
> libsmime3.so:
> libsoftokn3.so:
> libssl3.so:
> libxpcom.so:
> libxul.so:
Attachment #581092 - Flags: feedback?(aki) → feedback+

Comment 3

6 years ago
Created attachment 581138 [details] [diff] [review]
omni.ja diff en-US vs. de

So I extracted the en-US and de zips and recursive binary diffed; everything looked normal except the below lib.id.

I then extracted the en-US and de omni.ja's and recursive binary diffed; these files seem to only exist in the de omni.ja's.  Not sure if that's expected or not.

Comment 4

6 years ago
Why can't you install your apk?

* Every apk needs to be signed before it can be installed.
** This can be a debug/developer key that generally expires in a year, or a self-signed "official" key that expires in 20+? years.
* If an app is already installed (in this case org.mozilla.fennec), any new apk with that appname needs to be signed with the same key.
** You can get around this by uninstalling that app first.

The way we sign our nightly apk's is via the JARSIGNER environment variable.  If you set this to $JAVA_HOME/bin/jarsigner, I think you get a developer-signed apk.

mbrubeck pointed us to a way to re-sign an apk: first delete the contents of META-INF/ from your apk, and then sign via jarsigner.

Hopefully the nightly-signed German apk I posted works and we don't have to worry about this any more :)
I tested the apk from comment 2 on my galaxy s2 with German set as the system locale, and the build came up in English.  In addition, browsing didn't work.

I tried Axel patch myself and was able to get an apk that shows up in Polish on my device.  However, the Preferences menu item was disabled.  Also, browsing didn't work and the browser was very crashy.  (I got the same with en-US though, so maybe I just built when mozilla-central was broken.)

I'll try again later today.
(Reporter)

Comment 6

6 years ago
Comment on attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

Trying ted for a real review.

I'm unable to get the signing stuff figured out. There's a whole shebang about shared keys with aurora and releng using a python script to pick up secret params and whatnot.

That's all out of scope for this bug, for now, let's be happy that one can get repacks of self-built packages, and figure out signing later. I'll probably need aki for a few testdrives, too, as anything I can try is only valid up to the point where it hits the real signing process that releng does.
Attachment #581092 - Flags: review?(ted.mielczarek)
(In reply to Staś Małolepszy :stas from comment #5)
> I tested the apk from comment 2 on my galaxy s2 with German set as the
> system locale, and the build came up in English.  In addition, browsing
> didn't work.
> 
> I tried Axel patch myself and was able to get an apk that shows up in Polish
> on my device.  However, the Preferences menu item was disabled.  Also,
> browsing didn't work and the browser was very crashy.  (I got the same with
> en-US though, so maybe I just built when mozilla-central was broken.)

I figured it out.  I was using NDK r7 instead of r6... :/  

With r6, I'm getting usable localized builds using Axel's patch.

Updated

6 years ago
Priority: -- → P3
Comment on attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

Review of attachment 581092 [details] [diff] [review]:
-----------------------------------------------------------------

Is the stuff about lib.id that Aki noted above still broken? We use that for crash reporting.
Attachment #581092 - Flags: review?(ted.mielczarek) → review+
(Reporter)

Comment 9

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/caf52bced4d3, landed on inbound.

We should verify lib.id when we get upstream single-locale repacks.

When this makes it to central, we'll want this on aurora, too.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 12
https://hg.mozilla.org/mozilla-central/rev/caf52bced4d3

Bugs landed to inbound should not be marked fixed (they could still be backed out and not make the release channel), whoever merges to central will mark them as fixed.
(Reporter)

Comment 11

6 years ago
Comment on attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

Requesting approval for aurora, another landing needed for shipping single-locale fennec 11 builds.

mak, sorry for the wrong bug foo.
Attachment #581092 - Flags: approval-mozilla-aurora?

Comment 12

6 years ago
Comment on attachment 581092 [details] [diff] [review]
make INNER_UNMAKE_PACKAGE stay in the same dir

[triage comment]
Approved for aurora. We'll take this to try to support single-locale builds on mobile.
Attachment #581092 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Reporter)

Comment 13

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/b20416bedcfc, landed on aurora.
status-firefox11: --- → fixed
tracking-fennec: --- → 11+
Verified fixed on:

Mozilla/5.0 (Android;Linux armv7l;rv:11.0a2)Gecko/20120130
Firefox/11.0a2 Fennec/11.0a2
Device: Samsung Galaxy S
OS: Android 2.2

Mozilla/5.0 (Android;Linux armv7l;rv:12.0a1)Gecko/20120130
Firefox/12.0a1 Fennec/12.0a1
Device: Samsung Galaxy S
OS: Android 2.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.