Closed Bug 419771 Opened 13 years ago Closed 13 years ago

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

Categories

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

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla3 beta4

People

(Reporter: chofmann, Assigned: chofmann)

References

Details

Attachments

(3 files, 1 obsolete file)

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.
Component: Other → Build Config
Flags: blocking-firefox3?
OS: Mac OS X → All
Priority: -- → P1
Product: Mozilla Localizations → Firefox
QA Contact: build.config
Hardware: PC → All
Target Milestone: --- → Firefox 3 beta4
Version: unspecified → Trunk
Flags: blocking-firefox3? → blocking-firefox3+
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)
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.
unless we get more opt-in's I think this is what we need right now for beta4
Attachment #306040 - Attachment is patch: true
Attachment #306040 - Attachment mime type: application/octet-stream → text/plain
oops, last patch got picked up as binary.  this is the one we want.
Attachment #306040 - Attachment is obsolete: true
Attachment #306045 - Flags: approval1.9b4?
Attachment #306045 - Attachment is patch: true
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.
Assignee: nobody → chofmann
Attachment #306045 - Flags: review?(mic)
the patch appears to be missing these locales:
hu
it
ja
ja-jp-mac
ka
ko
lt
(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
Here's a patch with all the context - shows added locales (prefixed with +) and existing locales.
thanks, that looks like what we're expecting at this point
Attachment #306045 - Flags: review?(mic) → review+
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)
(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 on attachment 306045 [details] [diff] [review]
same patch with better file name extension

a1.9b4=beltzner
Attachment #306045 - Flags: approval1.9b4? → approval1.9b4+
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.
Keywords: checkin-needed
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
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.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
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 :)
Serbian will not make Beta 4, we will aim for next milestone 
Resolving this as fixed then. Great job getting this done early!
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: blocking-firefox3- → blocking-firefox3?
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
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.
(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.
sorry to ask here, but pa_IN is missing while I replied in mailing to include:-(
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

Reopen to take the very last opt-ins. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch Add da and mkSplinter Review
These two are both green.
Attachment #307064 - Flags: review?(gavin.sharp)
Comment on attachment 307064 [details] [diff] [review]
Add da and mk

a=chofmann
Attachment #307064 - Flags: review?(gavin.sharp) → review+
Attachment #307064 - Flags: approval1.9b4?
Comment on attachment 307064 [details] [diff] [review]
Add da and mk

a1.9b4=beltzner
Attachment #307064 - Flags: approval1.9b4? → approval1.9b4+
Checking in shipped-locales;
/cvsroot/mozilla/browser/locales/shipped-locales,v  <--  shipped-locales
new revision: 1.7; previous revision: 1.6
done
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 :)
(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.
(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!
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?
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.
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.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 3 beta4 → mozilla3 beta4
You need to log in before you can comment on or make changes to this bug.