Closed
Bug 713442
Opened 12 years ago
Closed 12 years ago
Separate compare-locales tag for 1.9.2
Categories
(Release Engineering :: General, defect, P5)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: wgianopoulos, Unassigned)
References
Details
Attachments
(1 file)
2.00 KB,
patch
|
coop
:
review+
mozilla
:
checked-in+
|
Details | Diff | Splinter Review |
The 20111225 Android native nightly build failed to complete because of l10n parsing issues in the fr and it localizations. I filed separate bugs on each of these and have added those a dependencies on this bug.
Reporter | ||
Updated•12 years ago
|
Summary: Android native 200111225 nightly failed with l10n parse errors → Android native 20111225 nightly failed with l10n parse errors
Reporter | ||
Comment 1•12 years ago
|
||
OK after the 2 dependent bugs were resolved in l10n-central, I got Callek to retrigger the build and it was successful, so I am lowering the severity here, but keeping this bug open. It would seem that there should be some better way to handle a string error for a single locale rather than not doing a nightly at all.
Severity: blocker → normal
Comment 2•12 years ago
|
||
This is sadly a rather complicated problem. We *can* fix this, and we should. The code that does that is stuck in compare-locales, which needs another update. That is one side, and the easy one. Once that's fixed, I can deploy it on the l10n dashboard and localizers get notified. The really complex one is to get that version of compare-locales deployed in our build system. Mostly, deploying this as is changes how we do the 3.6 releases, and last time I raised this, that met resistance.
Comment 3•12 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #2) > This is sadly a rather complicated problem. > > We *can* fix this, and we should. The code that does that is stuck in > compare-locales, which needs another update. > > That is one side, and the easy one. Once that's fixed, I can deploy it on > the l10n dashboard and localizers get notified. > > The really complex one is to get that version of compare-locales deployed in > our build system. Mostly, deploying this as is changes how we do the 3.6 > releases, and last time I raised this, that met resistance. Can't we use a separate compare-locales tag for 3.6 as opposed to non-3.6?
Comment 4•12 years ago
|
||
(In reply to Aki Sasaki [:aki] (back jan 9) from comment #3) > > Can't we use a separate compare-locales tag for 3.6 as opposed to non-3.6? I'm fine with whatever tags work for you, basically. Most of what's in /build/compare-locales these days is releng tags anyway. Could you come up with a proposal that works for the upcoming ESR etc as well, and feels right with how you'd want to deploy a new version of compare-locales through the channels?
Reporter | ||
Comment 5•12 years ago
|
||
Not to bring up a politically bad issue, but should not support for 3.6 been long since dropped? Just Sayin'.
Comment 6•12 years ago
|
||
Axel, Aki this seems to have morphed into something other than a Fennec bug. Can you please change the product and component to reflect that?
Reporter | ||
Comment 7•12 years ago
|
||
Well, the fennec-native nightly build is the only one that became red because of this issue. SO, I would think that changing product and component might make it less likely for anyone to be able to find this bug the next time this happens.
Reporter | ||
Comment 8•12 years ago
|
||
I was thinking to keep this bug open here as long as there is an issue that a single locale file can screw up the whole build for all locales, and then do the real work in dependent bugs filed on the correct components. So, perhaps it would be better to make this a meta bug and make the summary be less specific to that particular day?
Updated•12 years ago
|
Priority: -- → P5
Comment 9•12 years ago
|
||
Coop, can you help out with comments 3, 4, aka, fork which version of compare-locales we use for which release? I can't really advise on what to do here specificly.
Updated•12 years ago
|
Component: General → Release Engineering
Product: Fennec Native → mozilla.org
QA Contact: general → release
Summary: Android native 20111225 nightly failed with l10n parse errors → Separate compare-locales tag for 1.9.2
Version: Trunk → other
Comment 10•12 years ago
|
||
Once this lands, we can move the RELEASE_AUTOMATION tag in hg.m.o/build/compare-locales without affecting 1.9.2 releases. 1.9.2 nightly and depend l10n jobs will still use RELEASE_AUTOMATION. I'm not sure if that's currently a concern. I recommend we test that new revision of compare-locales in a staging release before moving the RELEASE_AUTOMATION tag in production, since that has the potential to affect all l10n jobs negatively. However, this patch should unblock us.
Attachment #587554 -
Flags: review?(coop)
Updated•12 years ago
|
Attachment #587554 -
Flags: review?(coop) → review+
Comment 11•12 years ago
|
||
Comment on attachment 587554 [details] [diff] [review] Point to RELEASE_0_8_2 for 1.9.2 release compare-locales http://hg.mozilla.org/build/buildbot-configs/rev/83f09b0a240e
Attachment #587554 -
Flags: checked-in+
Comment 12•12 years ago
|
||
Are you releng guys fine with moving all but 3.6 to a different version of compare-locales in one go? Seems like ESR and release chemspills could fall into the same bucket that 3.6 is in now?
Comment 13•12 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #12) > Are you releng guys fine with moving all but 3.6 to a different version of > compare-locales in one go? Seems like ESR and release chemspills could fall > into the same bucket that 3.6 is in now? ESR hasn't built yet; nor do we have release config files for ESR yet. We will be building it shortly (with Fx10 ?) and will have config files for ESR at that point. We can point those at RELEASE_0_8_2 or RELEASE_AUTOMATION or some other tag based on our level of comfort there. I'm not familiar with what will change between our current RELEASE_AUTOMATION tag point (RELEASE_0_8_2) and the new one. I did note caveats in comment 10 (1.9.2 nightlies as currently configured will use the new compare-locales RELEASE_AUTOMATION tag; we need to test the new compare locales version before moving the RELEASE_AUTOMATION tag). Assuming the change in compare-locales is good/safe/well-tested, I'm comfortable.
Updated•12 years ago
|
Assignee: nobody → aki
Comment 14•12 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #2) > The really complex one is to get that version of compare-locales deployed in > our build system. Mostly, deploying this as is changes how we do the 3.6 > releases, and last time I raised this, that met resistance. Hey Axel, I'm doublechecking: if I merge l10n/compare-locales' latest code into build/compare-locales and move the RELEASE_AUTOMATION tag, is that sufficient? I'm assuming we don't have to change how we call the compare-locales script, but the "deploying this as is changes how we do the 3.6 releases" is something I wanted to clarify. In the meantime I can do some testing via user repo.
Comment 15•12 years ago
|
||
Yeah, the command line didn't change, just merging and updating the tags will be fine.
Comment 16•12 years ago
|
||
Merged l10n/compare-locales into build/compare-locales : http://hg.mozilla.org/build/compare-locales/rev/d72caa859d1b The RELEASE_AUTOMATION and RELEASE_0_8_2 tags are unchanged, so this should have no effect.
Comment 17•12 years ago
|
||
I'm currently planning on bumping the RELEASE_AUTOMATION tag to RELEASE_0_9_5 tag tomorrow afternoon after beta 3, then kicking off some nightlies to verify. Does that work?
Assignee: aki → nobody
Component: Release Engineering → Release Engineering: Developer Tools
OS: Android → MeeGo
QA Contact: release → lsblakk
Updated•12 years ago
|
Component: Release Engineering: Developer Tools → Release Engineering: Automation (General)
OS: MeeGo → All
QA Contact: lsblakk → catlee
Hardware: ARM → All
Comment 18•12 years ago
|
||
That should work, at least from my side.
Comment 19•12 years ago
|
||
http://hg.mozilla.org/build/compare-locales/rev/1cb0dd989d14 RELEASE_AUTOMATION is now pointing at http://hg.mozilla.org/build/compare-locales/rev/1fc4e9bc8287 (RELEASE_0_9_5). If we want to revert, we can back out that revision, or hg tag -f -r fa9a45675863 RELEASE_AUTOMATION hg push I'm going to kick off some nightlies for verification.
Comment 20•12 years ago
|
||
On m-c android, we're getting a lot of the below traceback. Not sure if this is expected. 12:41:03 INFO - /tools/python/bin/python2.5 /builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py -DAB_CD=da -DXPI_NAME=locale-da -DOSTYPE=\"Linux\" -DOSARCH=Linux \ 12:41:03 INFO - -DBRANDPATH="/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/obj-l10n/mobile/android/base/locales/../../../../dist/xpi-stage/locale-da/chrome/da/locale/branding/brand.dtd" \ 12:41:03 INFO - -DSTRINGSPATH="/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/mobile/android/base/locales/en-US/android_strings.dtd" \ 12:41:03 INFO - -DSYNCSTRINGSPATH="/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/mobile/android/base/locales/en-US/sync_strings.dtd" \ 12:41:03 INFO - -DBOOKMARKSPATH="/builds/slave/m-cen-andrd-l10n-1/build/l10n-central/da/mobile/profile/bookmarks.inc)" \ 12:41:03 INFO - /builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/mobile/android/base/locales/../strings.xml.in \ 12:41:03 INFO - > ../res/values/strings.xml 12:41:03 INFO - Traceback (most recent call last): 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 477, in <module> 12:41:03 INFO - main() 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 462, in main 12:41:03 INFO - pp.handleCommandLine(None, True) 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 168, in handleCommandLine 12:41:03 INFO - self.do_include(f) 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 447, in do_include 12:41:03 INFO - self.handleLine(l) 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 230, in handleLine 12:41:03 INFO - cmd(args) 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 456, in do_includesubst 12:41:03 INFO - self.do_include(args) 12:41:03 INFO - File "/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/config/Preprocessor.py", line 430, in do_include 12:41:03 INFO - raise Preprocessor.Error(self, 'FILE_NOT_FOUND', str(args)) 12:41:03 INFO - __main__.Error: ('/builds/slave/m-cen-andrd-l10n-1/build/mozilla-central/mobile/android/base/strings.xml.in', 8, 'FILE_NOT_FOUND', '/builds/slave/m-cen-andrd-l10n-1/build/l10n-central/da/mobile/profile/bookmarks.inc)')
Comment 21•12 years ago
|
||
Looks like we've been getting that for a few days now, before the tag bump.
Comment 22•12 years ago
|
||
Android single locale is ok on Aurora -- I've got snippet issues there (my bug) but it repacks and uploads ok. http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-aurora-android-l10n/
Comment 23•12 years ago
|
||
(In reply to Aki Sasaki [:aki] from comment #21) > Looks like we've been getting that for a few days now, before the tag bump. This probably broke sometime on March 24. A lot of b2g stuff landed that day, which could have affected Android. http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-03-24-03-11-00-mozilla-central-android-l10n/
Comment 24•12 years ago
|
||
Other than the m-c Android single locale issue, this seems to have gone well. Resolving.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 25•12 years ago
|
||
Filed bug 740291 on the repack issue. There are more once that's fixed, though.
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•