437441 - Finalize calendar-timezones.xpi

Status: VERIFIED FIXED

(Calendar :: Build Config, defect)

Description

[Daniel Boelzle [:dbo]]

This includes
- doing multi-l10n builds of the xpi:
<http://mxr.mozilla.org/seamonkey/source/calendar/timezones/locales/Makefile.in#43>
- adding proper icon and update-url to install.rdf
<http://mxr.mozilla.org/seamonkey/source/calendar/timezones/install.rdf#68>
- investigating into making sunbird lightning xpi stub dependent on calendar-timezones.xpi. An em:require hinders Sunbird from preinstalling any xpi (including DOM inspector)
<http://mxr.mozilla.org/seamonkey/source/calendar/sunbird/app/profile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/install.rdf.in#63>

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: [checked in] Allow all locales for calendar-timezones.xpi

Similar to lightning's Makefile.in

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

The only blocking part of this bug is adding the proper update-url, everything else is optional.

Comment 3

[Atsushi Sakai]

(In reply to comment #0)
> This includes
> - doing multi-l10n builds of the xpi:

Does this bug include doing l10n of calendar-timezones (not xpi, but extension)
which is shipped with Sunbird?

Comment 4

[Daniel Boelzle [:dbo]]

No, the preinstalled calendar-timezones.xpi (in Sunbird) does not need to include all locales other than Sunbird's. But once we release a calendar-timezones.xpi via AMO, that one should include all locales, to fit into every localized Sunbird or Thunderbird/Lightning.

Comment 5

[Daniel Boelzle [:dbo]]

Stefan mentioned on IRC that we could leave the updateURL blank, which will lead the update pings to AMO by default. However it makes sense to push the calendar-timezones.xpi to AMO for testing purposes, e.g. whether an older Sunbird nightly (having a preinstalled 0.1.2007b) properly updates to our current 0.1.2008d (from AMO). IMO we should do that when l10n is ready.

Comment 6

[Atsushi Sakai]

(In reply to comment #4)
> No, the preinstalled calendar-timezones.xpi (in Sunbird) does not need to
> include all locales other than Sunbird's.

The preinstalled calendar-timezones should include at least a locale which is same as Sunbird, but current nightly l10n Sunbird's calendar-timezones includes only en-US.

The reason is:
The en-US Sunbird is built first, and then l10n Sunbird is made from en-US Sunbird by repackaging.
The repackaging process is repackaging application's locale, but not repackaging extension's locale.

As for DOMi which is shipped with Fx2, multi-l10n is done because of this.

Comment 7

[Stefan Sitter [:ssitter]]

Currently only en-US timezone names are shipped with Sunbird/Lightning nightly builds. This also applies to localized Sunbird nightly builds.

Therefore localized Sunbird nightly builds are not usable because the properties can't be found. The visible error is the same as in Bug 437692. As mentioned in that bug I suggest to use a save fallback, e.g. by displaying the raw timezone property name instead of throwing hundreds of errors.

The calendar-timezones.xpi included in Sunbird must include all locales that are available for Sunbird. Or the calendar-timezones.xpi must be repackaged for each Sunbird locale to contain the correct files.

Comment 8

[Daniel Boelzle [:dbo]]

Even if we would fall back showing the plain TZID, the localizers can't test whether translation has been correct, right?

(In reply to comment #7)
> The calendar-timezones.xpi included in Sunbird must include all locales that
I think that's hardly doable in the nightlies, IIRC from lightning.

> are available for Sunbird. Or the calendar-timezones.xpi must be repackaged for
> each Sunbird locale to contain the correct files.
I think so.

Comment 9

[Daniel Boelzle [:dbo]]

(In reply to comment #7)
> Currently only en-US timezone names are shipped with Sunbird/Lightning nightly
> builds. This also applies to localized Sunbird nightly builds.
> 
> Therefore localized Sunbird nightly builds are not usable because the
> properties can't be found. The visible error is the same as in Bug 437692. As
> mentioned in that bug I suggest to use a save fallback, e.g. by displaying the
> raw timezone property name instead of throwing hundreds of errors.
Stefan, I cannot see "hundreds of errors" using e.g. a recent german Sunbird nightly, though the timezone names are not localized.

Comment 10

[Stefan Sitter [:ssitter]]

(In reply to comment #9)
There is no recent German Sunbird nightly build. The last one available is from 07-May-2008. If you pick an up-to-date build (e.g. the Polish one) and open one of the timezone pickers you'll see the errors.

Comment 11

[Daniel Boelzle [:dbo]]

I'll try that.

Comment 12

[Daniel Boelzle [:dbo]]

Used the polish one from july 17: WFM without errors, but un-l10ned timezones. Anything I am missing?

Comment 13

[ause]

Attachment: try to have single timezone locale matching sb locale

Comment 14

[ause]

Comment on attachment 328744 [details] [diff] [review]
[checked in] Allow all locales for calendar-timezones.xpi

this patch will help to build multi locale timezone extensions once we enable that on the lightning tinderboxes again.
won't help for sunbird

Comment 15

[ause]

Attachment: matching timezone locale for sunbird

might need some more testing...

Comment 16

[ause]

Attachment: matching timezone locale for sunbird

this one looks good on windows and linux. no idea about mac yet.

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 328744 [details] [diff] [review]
[checked in] Allow all locales for calendar-timezones.xpi

Having troubles checking in...

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 328744 [details] [diff] [review]
[checked in] Allow all locales for calendar-timezones.xpi

there we go...

Comment 19

[ause]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird

seems to work on mac too

Comment 20

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird


>+bin\extensions\[e-mail]\chrome\calendar-timezones-@AB_CD@.jar
>+bin\extensions\[e-mail]\chrome\chromelist.txt
Do we really need to ship the chromelist?


r=philipp

Comment 21

[Martin Schröder [:mschroeder]]

Summary (for status meeting):
- Ause's patch waits for checkin!
- I don't know what the status for (multi-)l10n builds is after both build system patches. Philipp, Daniel?
- Adding update-url to install.rdf not needed according to comment#5.
- We need to test the timezone update via AMO before release.
- Adding proper icon to install.rdf does not block the release.
- I don't know much about 'investigating into making sunbird lightning xpi stub dependent on calendar-timezones.xpi'. Does this block the release at all? Daniel?

Comment 22

[Daniel Boelzle [:dbo]]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird

Since ause is on vacation, I'll check this in; chromelist question still pending.

Comment 23

[Daniel Boelzle [:dbo]]

(In reply to comment #21)
> Summary (for status meeting):
> - Ause's patch waits for checkin!
done

> - I don't know what the status for (multi-)l10n builds is after both build
> system patches. Philipp, Daniel?
Reading comment #14, we need to build multi-l10n lightning before (Stefan has filed bug 449180 for this).

> - I don't know much about 'investigating into making sunbird lightning xpi stub
> dependent on calendar-timezones.xpi'. Does this block the release at all?
> Daniel?
I don't think this part blocks, because it's rather meant to protect users against deinstalling calendar-timezones.xpi, which shouldn't be possible then.

Comment 24

[Vlado Valastiak [:wladow]]

(In reply to comment #22)
> (From update of attachment 330262 [details] [diff] [review])
> Since ause is on vacation, I'll check this in; chromelist question still
> pending.
> 

http://ssitter.googlepages.com/tinderbox-l10n-branch
Did this checkin cause busted l10n tboxen?

Comment 25

[Daniel Boelzle [:dbo]]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird

Seems to be the case -- I've backed the changes out again.

Comment 26

[Stefan Sitter [:ssitter]]

The tinderbox error (example from de tinderbox):

make[4]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'

make[3]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'

/usr/bin/make -C ../timezones libs-de

make[3]: Entering directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones'

make[3]: *** No rule to make target `libs-de'.  Stop.

make[3]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones'

make[2]: *** [repackage-win32-installer] Error 2

make[2]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'

make[1]: *** [repackage-win32-installer-de] Error 2

make[1]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'

make: *** [installers-de] Error 2

Comment 27

[ause]

i get the same error here if calendar/timezone/Makefile doesn't exist. looks like it isn't generated from Makefile.in at all.
there are probably two ways to fix that:
- add the according line to allmakefiles.sh in the source root
- add a DIRS=../timezone to calendar/locales/Makefile.in
or both...

i'm not sure if we would get a patch for allmakefiles.sh accepted nor do i know what what side effects a DIRS line may have on a l10n build. also DIRS=../something looks somehow dirty to me...

suggestions?

Comment 28

[Daniel Boelzle [:dbo]]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird

Talking to Ause, we opted to go with dirty DIRS.
When moving over to trunk/hg, we have better options to clean this up.

Comment 29

[Daniel Boelzle [:dbo]]

Comment on attachment 330262 [details] [diff] [review]
matching timezone locale for sunbird

backed out, boxes broken again:

gmake: *** ../timezones: No such file or directory.  Stop.
gmake[5]: *** [export] Error 2

Comment 30

[ause]

argl! the position of the DIRS line _must_ be before including config.mk. had it that way here by luck.

Comment 31

[ause]

Attachment: [checked in] matching timezone locale for sunbird - now with changed DIRS lines

Comment 32

[Daniel Boelzle [:dbo]]

Comment on attachment 336072 [details] [diff] [review]
[checked in] matching timezone locale for sunbird - now with changed DIRS lines

finally seems to build

Comment 33

[Atsushi Sakai]

L10n tinderbixen are burning.

creating calendar/locales/../timezones/Makefile
make[4]: Entering directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones'
/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/build/cygwin-wrapper /cygdrive/c/moztools/bin/nsinstall /cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales/../timezones/timezones.sqlite ../../dist/xpi-stage/locale-ca
- locales to build -- ca cs da de es-AR es-ES eu fr ga-IE hu is it ja-JP-mac ja ka ko lt nb-NO nl nn-NO pl pt-BR pt-PT ro ru sk sl sv-SE uk zh-CN zh-TW
/usr/bin/make -C locales libs AB_CD=ca XPI_NAME=calendar-timezones USE_EXTENSION_MANIFEST=1 NO_JAR_AUTO_REG=1
make[5]: Entering directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones/locales'
make[5]: *** No rule to make target `libs'.  Stop.
make[5]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones/locales'
make[4]: *** [libs-ca] Error 2
make[4]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/timezones'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'
make[2]: *** [libs-ca] Error 2
make[2]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'
make[1]: *** [langpack-ca] Error 2
make[1]: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'
make: *** [installers-ca] Error 2
make: Leaving directory `/cygdrive/c/builds/tinderbox/Sb-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/calendar/locales'

Comment 34

[Simon Paquet [:sipaq]]

Can someone please back this out or fix the underlying issue. Burning l10n tinderboxen are bad.

Comment 35

[Daniel Boelzle [:dbo]]

Calm down, Ause is working on it.

Comment 36

[ause]

Attachment: [checked in] two more calendar directories to generate makefiles

Comment 37

[ause]

Comment on attachment 336330 [details] [diff] [review]
[checked in] two more calendar directories to generate makefiles

what additional approval do i need for MOZILLA_1_8_BRANCH ?

Comment 38

[Simon Paquet [:sipaq]]

Comment on attachment 336330 [details] [diff] [review]
[checked in] two more calendar directories to generate makefiles

I heard that the time for 1.8.1.17 approvals has already run out.

Therefore I'm requesting approval1.8.1.18 and ask for a timely reaction as we are in the process of pushing out a Calendar release.

Comment 39

[Stefan Sitter [:ssitter]]

How about reverting the patch until the additional patch gets review and approval? This way the l10n teams and testing community would have nightly builds back for testing.

Comment 40

[ause]

Attachment: [checked in] after fixing the breakage, fix duplicat packing...

Comment 41

[Daniel Veditz [:dveditz]]

Comment on attachment 336330 [details] [diff] [review]
[checked in] two more calendar directories to generate makefiles

1.8.1.17 is cut already, too late for that. 

Approved for 1.8.1.18 landing on the MOZILLA_1_8_BRANCH, a=dveditz

Comment 42

[ause]

Attachment: add to makefile generation on trunk

Comment 43

[Berend Cornelius]

checked in patch "after fixing the breakage, fix duplicat packing..." on trunk and  Mozilla_1_8_BRANCH

Comment 44

[Daniel Boelzle [:dbo]]

I think this bug can be marked FIXED; the outstanding dependency will be resolved (or not) with bug 437692.

Comment 45

[Martin Schröder [:mschroeder]]

Comment on attachment 336637 [details] [diff] [review]
add to makefile generation on trunk

What about this patch? Is it needed on trunk (or better comm-central)?