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)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wgianopoulos, Unassigned)

References

Details

Attachments

(1 file)

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.
Summary: Android native 200111225 nightly failed with l10n parse errors → Android native 20111225 nightly failed with l10n parse errors
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
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.
(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?
Depends on: 713515
(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?
Not to bring up a politically bad issue, but should not support for 3.6 been long since dropped?  Just Sayin'.
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?
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.
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?
Priority: -- → P5
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.
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
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)
Attachment #587554 - Flags: review?(coop) → review+
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+
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?
(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.
Assignee: nobody → aki
(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.
Yeah, the command line didn't change, just merging and updating the tags will be fine.
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.
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
Component: Release Engineering: Developer Tools → Release Engineering: Automation (General)
OS: MeeGo → All
QA Contact: lsblakk → catlee
Hardware: ARM → All
That should work, at least from my side.
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.
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)')
Looks like we've been getting that for a few days now, before the tag bump.
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/
(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/
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
Filed bug 740291 on the repack issue. There are more once that's fixed, though.
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.