298672 - Tinderbox TB L10n trunk is not getting updated

Status: RESOLVED FIXED

(Thunderbird :: Build Config, defect)

Description

[Tim Maks van den Broek [:mad_maks]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; nl-NL; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; nl-NL; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Properties in ./chrome/mozapps/update/updates.properties don't match:
  In
/builds/tinderbox/Tb-Trunk-l10n/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/locales/en-US:
    IDoNotAgreeLabel

This string is updated in my cvs a few days ago (Fx builds after that update
without problems)

2  other l10n teams has confirmed this problem in #l10n

Reproducible: Always

Comment 1

[Benjamin Smedberg]

Is MOZ_CO_LOCALES getting set in mozconfig? And does this same bug appear on all
three tinderboxen?

Comment 2

[Benoit]

Just to confirm that we have the same problem with the fr builds. 

A change in the toolkit that was made on june 22 to make Firefox green again[1]
is still not visible in the Thunderbird build log[2]. 

Thunderbird-specific changes that were made yesterday are not visible as well.

[1] Firefox before the fix (june 22)
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-fr/1119444060.17178.gz
Firefox after the fix (june 22)
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-fr/1119460800.2205.gz
[2] Thunderbird today (june 24)
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-fr/1119589380.32532.gz

Comment 3

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #1)
> Is MOZ_CO_LOCALES getting set in mozconfig? And does this same bug appear on all
> three tinderboxen?

It looks like that changes made after 22-06 in the l10n trunks are not used in
the build. I look in the log of pl and see the same problem (they checked in
some changed entities on the 23-06, Fx is going green and Tb still say they are
missing)

Comment 4

[Chase Phillips]

(In reply to comment #1)
> Is MOZ_CO_LOCALES getting set in mozconfig?

Yes.  On karma (the system referenced by this problem) MOZ_CO_LOCALES is set to
'all'.

I logged into karma earlier, ran 'cvs log' in Tb-Trunk-l10n/Linux*/l10n/fr, and
found revisions that were dated 2005/06/23, the latest being stamped as
2005/06/23 22:43:28.  From this it's obvious the l10n/ working copy is getting
updated.

Does the build process copy these files into mozilla/?  Or perhaps this is some
clobber issue.  I've made no modifications to the build scripts to clobber the
l10n/ directory when mozilla/ gets clobbered.  I wouldn't want to, either, until
bsmedberg let me know that's the right thing to do.

Comment 5

[Chase Phillips]

(In reply to comment #4)
> I logged into karma earlier, ran 'cvs log' in Tb-Trunk-l10n/Linux*/l10n/fr, and
> found revisions that were dated 2005/06/23, the latest being stamped as
> 2005/06/23 22:43:28.  From this it's obvious the l10n/ working copy is getting
> updated.

I reread my own comment and thought "that's not right, 'cvs log' operates on the
repository, not the working copy." :)

At least the following files are at revision 1.1 when from what I can tell they
should be at revision 1.2:

  l10n/fr/editor/ui/chrome/composer/editor.properties
  l10n/fr/editor/ui/chrome/composer/editorOverlay.dtd

Probably others but I'm out of time as I have a meeting I must get ready for
now.  I and bsmedberg will look into this soon to find out what needs to be
fixed for this to work as expected.  Thanks for the heads up.

Comment 6

[Chase Phillips]

Yes, this is because each build cycle should be clobbering the l10n checkout. 
The reason this is a "new" bug is that in the old world l10n files were placed
in mozilla/, already being clobbered when the checkout was removed.  When the
trunk l10n work went down, this wasn't noticed.  Happy you guys found it, though.

I'm adding 'rm -rf l10n/' to post-mozilla-rel.pl on maya, chroma, karma.

I don't have time to take on considerations for what changes checking out l10n/
into a directory outside of mozilla/ requires us to make.  There could be other
"gotchas" that we haven't planned for.  Can someone please adopt this task?

Comment 7

[Chase Phillips]

(In reply to comment #6)
> I'm adding 'rm -rf l10n/' to post-mozilla-rel.pl on maya, chroma, karma.

Just finished.  The line was added to the section of code for when a release
build occurs on the system.  The 'clobbering' that happens throughout the day
requires more fixes which I (or gandalf/bsmedberg) can look into later.

Comment 8

[Benjamin Smedberg]

This was because zh-TW was added to the all-locales list but it did not have a
l10n/zh-TW/other-licenses/branding/thunderbird directory, so the checkout
command failed. This is now fixed.