844336 - Aurora win32 L10N builds broken by bug 823218

Status: VERIFIED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-af/1361470833.1361471087.18997.gz&fulltext=1

IOError: [Errno 2] No such file or directory: u'e:\\builds\\moz2_slave\\m-aurora-w32-l10n-ntly-0000000\\build\\mozilla-aurora\\dist\\branding\\branding.nsi'

This is because the new rules in branding copy branding.nsi during the libs:: rules, but browser/installer/windows/Makefile.in expects it in dist/branding during export::.

Adding BRANDING_TARGET = export to the branding Makefiles should fix it.

Comment 1

[u279076]

I can check this once it's fixed.

Comment 2

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #1)
> I can check this once it's fixed.

Note that once builds appear on FTP our automation will run automatically, so I can check to make sure the automation succeeds and then spotcheck a few updates. Please let me know if there are locales that are a priority because we won't be able to reasonably check *all* locales. Two or three locales seems reasonable.

Comment 3

[Axel Hecht [:Pike]]

ashuges: Italien, French, Russian are good candidates once we have builds. Hover over the left-most column in https://l10n.mozilla.org/dashboard/tree-status/fx_aurora?starttime=2013-2-20 will give you good locales. (french is red, but only for having killed metro already)

Comment 4

[Justin Wood (:Callek)]

Attachment: [aurora] v1

For the reasons in c#0 I believe this is the correct patch.

Written against aurora, but I expect it to apply clean to central.

Accepting whomever gets to it first.

Approval-request-in-advance of review, for "no windows l10n on aurora"

Comment 5

[Justin Wood (:Callek)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/22923addc512

Comment 6

[u279076]

(In reply to Justin Wood (:Callek) from comment #5)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/22923addc512

When can I expect to see builds? I thought they'd be available by now.

Comment 7

[Justin Wood (:Callek)]

The ones I triggered last night failed, due to cset being 'nightly' from the trigger :(

And the auto-scheduled ones were from the cset before my push :(

I triggered new nightlies as soon as I got up today, on the correct CSET at about 7:30am ET, so I'd expect in the next hour or two to see the l10n rolling in

Comment 8

[bhavana bajaj [:bajaj]]

(In reply to Justin Wood (:Callek) from comment #7)
> The ones I triggered last night failed, due to cset being 'nightly' from the
> trigger :(
> 
> And the auto-scheduled ones were from the cset before my push :(
> 
> I triggered new nightlies as soon as I got up today, on the correct CSET at
> about 7:30am ET, so I'd expect in the next hour or two to see the l10n
> rolling in

 Callek any update if the builds rolled out as expected ? I had checked ~10am PT and did not find them on ftp

Comment 9

[Justin Wood (:Callek)]

(In reply to bhavana bajaj [:bajaj] from comment #8)
>  Callek any update if the builds rolled out as expected ? I had checked
> ~10am PT and did not find them on ftp

We have a small pool of win32 machines that do these builds at the moment so my ETA was a bit overeager. We're more than 3/4's of the way through the list of windows l10n repacks now though, spot checks show green builds.

Will just need QA to checkin soon to verify from their end.

Comment 10

[Justin Wood (:Callek)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bb9e9d8b1d2f

Comment 11

[u279076]

(In reply to Justin Wood (:Callek) from comment #10)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/bb9e9d8b1d2f

Thanks Justin. I've confirmed the win32 l10n builds are now working based on the following criteria:
* functional automation testing against the fr builds
* update automation testing against the fr builds
* manual functional and update spotchecks against de, it, and ja-JP builds
* all download links verified on http://www.mozilla.org/en-US/firefox/all-aurora.html

Marking this bug resolved fixed based on these results. I've also added a QA sign-off checklist item so we catch l10n issues like this earlier in the future.

Comment 12

[bhavana bajaj [:bajaj]]

Callek, , ashughes : thanks a lot for getting this resolved over weekend :)

Comment 13

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/bb9e9d8b1d2f

Comment 14

[u279076]

I think it's safe to call this verified fixed at this point.