Aurora win32 L10N builds broken by bug 823218

VERIFIED FIXED

Status

()

Core
Build Config
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: glandium, Assigned: Callek)

Tracking

Trunk
All
Windows 7
Points:
---

Firefox Tracking Flags

(firefox21+ verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Blocks: 823218
No longer blocks: 786520
Summary: Aurora win32 L10N builds broken by bug 786520 → Aurora win32 L10N builds broken by bug 823218

Updated

5 years ago
tracking-firefox21: --- → ?
I can check this once it's fixed.
QA Contact: anthony.s.hughes
(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

5 years ago
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)

Updated

5 years ago
Assignee: nobody → bugspam.Callek
(Assignee)

Comment 4

5 years ago
Created attachment 717401 [details] [diff] [review]
[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"
Attachment #717401 - Flags: review?(ted)
Attachment #717401 - Flags: review?(mh+mozilla)
Attachment #717401 - Flags: review?(khuey)
Attachment #717401 - Flags: approval-mozilla-aurora?

Updated

5 years ago
Attachment #717401 - Flags: review?(ted)
Attachment #717401 - Flags: review?(mh+mozilla)
Attachment #717401 - Flags: approval-mozilla-aurora?
Attachment #717401 - Flags: approval-mozilla-aurora+
(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.
(Assignee)

Comment 7

5 years ago
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
(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
(Assignee)

Comment 9

5 years ago
(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.
(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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Callek, , ashughes : thanks a lot for getting this resolved over weekend :)

Updated

5 years ago
status-firefox21: --- → fixed
tracking-firefox21: ? → +
I think it's safe to call this verified fixed at this point.
Status: RESOLVED → VERIFIED
status-firefox21: fixed → verified
You need to log in before you can comment on or make changes to this bug.