Closed Bug 588224 Opened 11 years ago Closed 11 years ago

Tracking bug for build and release of Fennec 2.0a1

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aki, Assigned: aki)

Details

Attachments

(10 files, 3 obsolete files)

1.63 KB, patch
jhford
: review+
Details | Diff | Splinter Review
5.06 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
15.08 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
6.64 KB, patch
jhford
: review+
Details | Diff | Splinter Review
2.40 KB, patch
jhford
: review+
Details | Diff | Splinter Review
1.98 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
2.06 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
2.58 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
5.70 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
3.06 KB, patch
lsblakk
: review+
Details | Diff | Splinter Review
No description provided.
Not sure about branding etc., but at least copying the nightly mozconfig gives us something to work with.
Attachment #466853 - Flags: review?(jhford)
Attachment #466853 - Flags: feedback?(blassey.bugs)
Attachment #466853 - Attachment is obsolete: true
Attachment #466854 - Flags: review?(jhford)
Attachment #466854 - Flags: feedback?(blassey.bugs)
Attachment #466853 - Flags: review?(jhford)
Attachment #466853 - Flags: feedback?(blassey.bugs)
Attachment #466854 - Flags: feedback?(blassey.bugs) → feedback+
Testing a build with --enable-official-branding in the android release mozconfig.
Summary: Tracking bug for Fennec 2.0a1 → Tracking bug for build and release of Fennec 2.0a1
Is this an official branding error?

/tools/python/bin/python2.5 /builds/slave/android-r7_build/build-release/mozilla-central/config/Preprocessor.py \
	  -I /builds/slave/android-r7_build/build-release/mozilla-central/mobile/locales/en-US/profile/bookmarks.inc \
	  -DAB_CD=en-US \
	  /builds/slave/android-r7_build/build-release/mozilla-central/mobile/locales/generic/profile/bookmarks.json.in \
	  > bookmarks.json
make[5]: Leaving directory `/builds/slave/android-r7_build/build-release/mozilla-central/objdir/mobile/locales'
make[5]: Entering directory `/builds/slave/android-r7_build/build-release/mozilla-central/objdir/mobile/components'
/builds/slave/android-r7_build/build-release/mozilla-central/config/rules.mk:1877: *** .js component without matching .manifest.  Stop.
was that a clobber build?
Yes.
Looks like the Maemo builds are dying at the same spot, I'm guessing due to official branding as well.
Hang on, this might be my snafu.
Yup. Details in bug 588229 comment 1. Sorry for the scare + noise.
Comment on attachment 466854 [details] [diff] [review]
copy nightly android mozconfig to release/, with staging

Do we want --enable-official-branding for this?
Attachment #466854 - Attachment is obsolete: true
Attachment #467934 - Flags: review?(jhford)
Attachment #466854 - Flags: review?(jhford)
Attachment #467934 - Flags: review?(jhford) → review+
This is the patch for the fennec 2.0 configs + l10n changesets json files, pre-changeset.

I'm making the following assumptions:

1) I'm copying l10n-changesets_mobile-2.0.json from l10n-changesets_mobile-1.1.json, which will probably break. We'll need Axel to update these, or set these to default, or something.

1a) the staging version is a limited set of locales for ease of testing.

2) I'm putting all of our platforms in here. It's sounding more and more like we won't be building Maemo4 here, but unless I hear that officially I'll keep it in.  Also unsure about Maemo5-QT.

3) Adding a relbranch override for m-c since it's already branched.  This will probably mean we're going to have differently-named branches for m-b and l10n, but they'll all start with GECKO20b5pre. Alternately I can branch m-b manually at build-time, and just let the l10n branch be named differently (I can do this, and no one uses that relbranch except our release automation).
Attachment #467977 - Flags: review?(joduinn)
Attachment #467977 - Flags: review?(joduinn) → review?(lsblakk)
Attachment #467977 - Flags: review?(lsblakk) → review+
Comment on attachment 467934 [details] [diff] [review]
copy nightly android mozconfig to release/, with staging, with official branding

http://hg.mozilla.org/build/buildbot-configs/rev/7f0aa5d07b2c
Attachment #467934 - Flags: checked-in+
Comment on attachment 467977 [details] [diff] [review]
2.0a1 pre-changeset config changes

http://hg.mozilla.org/build/buildbot-configs/rev/153864d1507e

We need Axel to land l10n-changesets_mobile-2.0.json, and I need to remember to update the softlinks when I do the changeset patch.
Attachment #467977 - Flags: checked-in+
Axel says that the localizers need lead time to have strings for a release, so this is probably a non-localized release.

In theory I can turn off the l10n repacks easily. I'm not entirely sure what this means for the multi-locale deb(s).

So:

- I need to investigate that and possibly do a staging release with an empty l10n-changesets
- Need to update softlinks when I do the changeset patch
- Should ask if we're building Maemo4 + Maemo5-Qt for this
Running a staging release. The empty l10n-changesets seems to be causing issues with the multilocale Maemo build; tracking that down.
This patch:

- clears out the l10n-changesets_mobile-2.0.json per Axel
- disables l10n repacks for 2.0a1
- disables partner repacks for 2.0a1 (we only send non-alpha/beta releases out)
- adds a disableMultiLocale option to override the mobile_config setting
- fixes the release_mobile_config?.py softlinks

I tested a similar patch (but with the multilocale setting hardcoded to False in release_mobile_master.py) and it seems to be working properly.

I still want to verify that we are going non-localized and whether we want to build Maemo4 + Maemo5-Qt or not.
Also, milestone: the branch's milestone is currently 2.0b4pre because we branched from Tuesday, which [codewise] is before we branched for 4.0b5.  So chronologically 2.0b5pre works, but codewise 2.0b4pre makes more sense.

However, I'm not sure anyone cares, really.  Noted that the automation will bump this to 2.0b5pre automatically as the configs stand currently.
Attachment #468123 - Attachment is obsolete: true
Attachment #468350 - Flags: review?(lsblakk)
I've never tested this with an empty l10n-changesets json (should have this weekend). Assuming that works, this should do it.
Attachment #468357 - Flags: review?(jhford)
Attachment #468350 - Flags: review?(lsblakk) → review+
Attachment #468357 - Flags: review?(jhford) → review+
Attachment #468361 - Flags: review?(jhford)
Attachment #468361 - Flags: review?(jhford) → review+
Attachment #468380 - Flags: review?(lsblakk) → review+
Attached patch build 2 configsSplinter Review
Attachment #468422 - Flags: review?(lsblakk)
Attachment #468422 - Flags: review?(lsblakk) → review+
This is needed for the deb signing to work properly.
Attachment #468529 - Flags: review?(lsblakk)
Attachment #468529 - Flags: review?(lsblakk) → review+
Attachment #469082 - Flags: review?(lsblakk) → review+
- Bumps build2->build3
- Adds |"locales": ["en-US"],| which keeps the script from looking for multi and single locale repack debs.
- Changes the debNameUrl for fremantle to look at the en-US directory, rather than the non-existent multi directory.
Attachment #469085 - Flags: review?(lsblakk)
Attachment #469085 - Flags: review?(lsblakk) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.