419771 - update ship locales to reflect the set ready for fx3 beta 4

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P1)

Description

[chris hofmann]

still working on sorting out the final details but it looks something like we might be picking up

diff -r1.5 shipped-locales
> el
> es-AR
> sq

and possible remove "he" from the list used for beta 3.

patch coming up maybe tomorrow after the some more checking has been finished.

Comment 1

[Mic Berman]

diff from beta 3, here's what I have
picking up:
en-GB
el
es-AR
es-ES
sq

seems, we lost he and pt-PT from list, was in b3, doesn't appear to have opted in to b4. I will confirm after I reach both localizers (need a few hours to reach then due to time difference)

Comment 2

[Mic Berman]

he and pt-PT are in, tinderboxes green. 

I will be chasing down a few other locales this morning. Please advise when my cut off is. I'd like to get as many locales in as possible.

Comment 3

[chris hofmann]

Attachment: ship locales update with additions for el en-GB es-AR sq

unless we get more opt-in's I think this is what we need right now for beta4

Comment 4

[chris hofmann]

Attachment: same patch with better file name extension

oops, last patch got picked up as binary.  this is the one we want.

Comment 5

[chris hofmann]

I'd propose that someone take a quick look at this patch, then lets get it approved and checked in, then we can update the list if we get any more locales opting in late in the game before beta4, but before the release candidate builds are started.

Comment 6

[Mic Berman]

the patch appears to be missing these locales:
hu
it
ja
ja-jp-mac
ka
ko
lt

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> the patch appears to be missing these locales:

Those are just cut out because the patch only shows 8 lines surrounding changed lines. The existing file already includes those:

http://lxr.mozilla.org/seamonkey/source/browser/locales/shipped-locales

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: full context patch

Here's a patch with all the context - shows added locales (prefixed with +) and existing locales.

Comment 9

[Mic Berman]

thanks, that looks like what we're expecting at this point

Comment 10

[Mic Berman]

got word from Serbian in L10n group: they would like to opt in for B4 release. 
need to double check their tinderbox is green (but I assume so at this point)

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #10)
> got word from Serbian in L10n group: they would like to opt in for B4 release. 
> need to double check their tinderbox is green (but I assume so at this point)

Any ETA on that? I'm going to approve the above shipped-locales patch, if you get the Serbian locale confirmed by tomorrow simply add & request approval on another patch.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 306045 [details] [diff] [review]
same patch with better file name extension

a1.9b4=beltzner

Comment 13

[Reed Loden [:reed]]

Checking in browser/locales/shipped-locales;
/cvsroot/mozilla/browser/locales/shipped-locales,v  <--  shipped-locales
new revision: 1.6; previous revision: 1.5
done

Leaving open until confirmation that all locales have been added.

Comment 14

[Mic Berman]

comment #11, eta should be today/tomorrow (at last check with localizer - but he hasn't checked in his build to cvs so..). I am trying to reach localizer to confirm. I will post back at end of today with an update. thanks

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Serbian is a target of opportunity. When it's ready, put the new patch up for approval1.9b4? and if we can, we'll take it.

Comment 16

[Mic Berman]

thanks, will do 
fyi - have spoken with localizer, this is his first build for Firefox so we're learning together how to get his build checked in :)

Comment 17

[Mic Berman]

Serbian will not make Beta 4, we will aim for next milestone 

Comment 18

[Reed Loden [:reed]]

Resolving this as fixed then. Great job getting this done early!

Comment 19

[Nick Thomas [:nthomas] (UTC+12)]

The following locales are currently not green according to the more rigorous tests at http://l10n.mozilla.org/dashboard/ > Builds.

fi, fr
 missing entries in $locale/browser/chrome/browser-region/region.properties
   gecko.handlerService.defaultHandlersVersion
   gecko.handlerService.schemes.webcal.0.name
   gecko.handlerService.schemes.webcal.0.uriTemplate

All the other locales to be shipped seem to set
   gecko.handlerService.defaultHandlersVersion=0
   gecko.handlerService.schemes.webcal.0.name=30 Boxes
   gecko.handlerService.schemes.webcal.0.uriTemplate=http://30boxes.com/external/widget?refer=ff&url=%s

Perhaps this is just that l10n.m.o needs to be taught the same trick as bug 418682. Locales might have been pushed into making the definition above to stay green.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #19)
> Perhaps this is just that l10n.m.o needs to be taught the same trick as bug
> 418682.

Yeah, I wasn't aware that many localizers paid attention to the buildbot rather than tinderbox, otherwise I would have tried fixing it there too. The missing prefs are not a problem, though, since the code is that reads them handles them not being present correctly.

Comment 21

[A S Alam]

sorry to ask here, but pa_IN is missing while I replied in mailing to include:-(

Comment 22

[chris hofmann]

pa-IN is part of the current list which is checked in and ready to go to beta.  http://lxr.mozilla.org/seamonkey/source/browser/locales/shipped-locales

Comment 23

[Nick Thomas [:nthomas] (UTC+12)]

Reopen to take the very last opt-ins. 

Comment 24

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Add da and mk

These two are both green.

Comment 25

[chris hofmann]

Comment on attachment 307064 [details] [diff] [review]
Add da and mk

a=chofmann

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 307064 [details] [diff] [review]
Add da and mk

a1.9b4=beltzner

Comment 27

[Nick Thomas [:nthomas] (UTC+12)]

Checking in shipped-locales;
/cvsroot/mozilla/browser/locales/shipped-locales,v  <--  shipped-locales
new revision: 1.7; previous revision: 1.6
done

Comment 28

[Robert Helmer [:rhelmer]]

Linux uk, zh-CN, zh-TW failed to build, with variations of:

make[1]: Leaving directory `/builds/tinderbox/Fx-Mozilla1.9-l10n-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/locales'
gmake[1]: Entering directory `/builds/tinderbox/Fx-Mozilla1.9-l10n-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/locales'
gmake[1]: *** No rule to make target `repackage-zip-zh-CN'.  Stop.
gmake[1]: Leaving directory `/builds/tinderbox/Fx-Mozilla1.9-l10n-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/locales'
gmake: *** [installers-zh-CN] Error 2

Comment 29

[Robert Helmer [:rhelmer]]

Here is the full log (note - includes both en-US and l10n build):
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaRelease/1204613548.1204617333.30430.gz&fulltext=1

This is better than the Tinderbox log because it actually catches STDERR reliably :)

Comment 30

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #28)
> Linux uk, zh-CN, zh-TW failed to build, with variations of:

FYI: mac versions of those locales built fine. win32 still in progress so
we dont know that yet.

Comment 31

[Robert Helmer [:rhelmer]]

(In reply to comment #29)
> Here is the full log (note - includes both en-US and l10n build):
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaRelease/1204613548.1204617333.30430.gz&fulltext=1 

Oops, sorry for the noise, this one only includes the l10n repack log, *not* en-US.

> This is better than the Tinderbox log because it actually catches STDERR
> reliably :)

Still true!

Comment 32

[Axel Hecht [:Pike]]

This smells like a build problem, not an l10n problem.

I'm somewhat puzzled why we would see that error message in the first place, any idea how that could happen for a pattern rule?

Comment 33

[Axel Hecht [:Pike]]

So, at least one way to get a pattern rule to not exist is that a dependency is broken.

Which would mean that for repackage-zip-uk to fail, ZIP_IN had disappeared somewhere during the build process.

CCing :bs as he knows make a tad better than I and might have more ideas.

Comment 34

[Robert Helmer [:rhelmer]]

Sorry, this is a build problem; we upgraded the kernel on these machines but didn't change the configs to match, and then removed an old build dir (which is derived from the kernel version) while it was running.

Sorry for the noise.