Separate compare-locales tag for 1.9.2

RESOLVED FIXED

Status

Release Engineering
General Automation
P5
normal
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: WG9s, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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

6 years ago
Summary: Android native 200111225 nightly failed with l10n parse errors → Android native 20111225 nightly failed with l10n parse errors
(Reporter)

Comment 1

6 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

6 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

6 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?

Updated

6 years ago
Depends on: 713515

Comment 4

6 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

6 years ago
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?
(Reporter)

Comment 7

6 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

6 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?
Priority: -- → P5

Comment 9

6 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

6 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

6 years ago
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.
Attachment #587554 - Flags: review?(coop)

Updated

6 years ago
Attachment #587554 - Flags: review?(coop) → review+

Comment 11

6 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

6 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

6 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

6 years ago
Assignee: nobody → aki

Comment 14

6 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

6 years ago
Yeah, the command line didn't change, just merging and updating the tags will be fine.

Comment 16

6 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

5 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

5 years ago
Component: Release Engineering: Developer Tools → Release Engineering: Automation (General)
OS: MeeGo → All
QA Contact: lsblakk → catlee
Hardware: ARM → All

Comment 18

5 years ago
That should work, at least from my side.

Comment 19

5 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

5 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

5 years ago
Looks like we've been getting that for a few days now, before the tag bump.

Comment 22

5 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

5 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

5 years ago
Other than the m-c Android single locale issue, this seems to have gone well.

Resolving.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 25

5 years ago
Filed bug 740291 on the repack issue. There are more once that's fixed, though.
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.