Last Comment Bug 713442 - Separate compare-locales tag for 1.9.2
: Separate compare-locales tag for 1.9.2
Status: RESOLVED FIXED
:
Product: Release Engineering
Classification: Other
Component: General Automation (show other bugs)
: other
: All All
: P5 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Chris AtLee [:catlee]
Mentors:
Depends on: 713440 713441 713515
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-25 07:01 PST by Bill Gianopoulos [:WG9s]
Modified: 2013-08-12 21:54 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Point to RELEASE_0_8_2 for 1.9.2 release compare-locales (2.00 KB, patch)
2012-01-10 17:29 PST, Aki Sasaki [:aki]
coop: review+
aki: checked‑in+
Details | Diff | Splinter Review

Description Bill Gianopoulos [:WG9s] 2011-12-25 07:01:18 PST
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.
Comment 1 Bill Gianopoulos [:WG9s] 2011-12-25 11:29:04 PST
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.
Comment 2 Axel Hecht [pto-Aug-30][:Pike] 2011-12-25 14:22:55 PST
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 Aki Sasaki [:aki] 2011-12-25 23:07:24 PST
(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 Axel Hecht [pto-Aug-30][:Pike] 2011-12-26 09:51:56 PST
(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?
Comment 5 Bill Gianopoulos [:WG9s] 2011-12-26 10:13:53 PST
Not to bring up a politically bad issue, but should not support for 3.6 been long since dropped?  Just Sayin'.
Comment 6 Brad Lassey [:blassey] (use needinfo?) 2011-12-29 12:13:43 PST
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?
Comment 7 Bill Gianopoulos [:WG9s] 2011-12-29 12:31:37 PST
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.
Comment 8 Bill Gianopoulos [:WG9s] 2011-12-29 12:38:17 PST
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?
Comment 9 Axel Hecht [pto-Aug-30][:Pike] 2011-12-29 17:16:47 PST
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.
Comment 10 Aki Sasaki [:aki] 2012-01-10 17:29:34 PST
Created attachment 587554 [details] [diff] [review]
Point to RELEASE_0_8_2 for 1.9.2 release compare-locales

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.
Comment 11 Aki Sasaki [:aki] 2012-01-12 10:37:01 PST
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
Comment 12 Axel Hecht [pto-Aug-30][:Pike] 2012-01-12 10:43:56 PST
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 Aki Sasaki [:aki] 2012-01-12 11:10:16 PST
(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.
Comment 14 Aki Sasaki [:aki] 2012-02-27 15:34:10 PST
(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 Axel Hecht [pto-Aug-30][:Pike] 2012-02-28 02:43:36 PST
Yeah, the command line didn't change, just merging and updating the tags will be fine.
Comment 16 Aki Sasaki [:aki] 2012-02-28 15:51:26 PST
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 Aki Sasaki [:aki] 2012-03-27 18:00:41 PDT
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?
Comment 18 Axel Hecht [pto-Aug-30][:Pike] 2012-03-28 04:48:10 PDT
That should work, at least from my side.
Comment 19 Aki Sasaki [:aki] 2012-03-28 11:51:08 PDT
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 Aki Sasaki [:aki] 2012-03-28 12:47:37 PDT
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 Aki Sasaki [:aki] 2012-03-28 12:48:31 PDT
Looks like we've been getting that for a few days now, before the tag bump.
Comment 22 Aki Sasaki [:aki] 2012-03-28 14:32:43 PDT
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 Aki Sasaki [:aki] 2012-03-28 15:41:37 PDT
(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 Aki Sasaki [:aki] 2012-03-28 17:40:20 PDT
Other than the m-c Android single locale issue, this seems to have gone well.

Resolving.
Comment 25 Axel Hecht [pto-Aug-30][:Pike] 2012-03-29 02:56:45 PDT
Filed bug 740291 on the repack issue. There are more once that's fixed, though.

Note You need to log in before you can comment on or make changes to this bug.