Closed Bug 537628 Opened 10 years ago Closed 10 years ago
Building localized Sunbird l10n nightly builds fail since 02-Dec-2009
There are no current localized Sunbird l10n nightly builds available at <http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-comm-1.9.1-l10n/>. The most recent builds are dated 02-Dec-2009. Logfiles of today show the following error message for all platforms: > make: Leaving directory `/e/buildbot/comm-1.9.1-sunbird-win32-l10n-full/ > build/comm-1.9.1/calendar/sunbird/branding/nightly/locales' > > make: *** No targets specified and no makefile found. Stop. > > make: *** [libs-fy-NL] Error 2 http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n/1262549493.1262549652.5586.gz#err0
Last successful build: Sunbird WINNT 5.2 comm-1.9.1 sunbird l10n Started 2009/12/02 13:29, finished 2009/12/02 13:35 First failing build: Sunbird WINNT 5.2 comm-1.9.1 sunbird l10n Started 2009/12/03 10:18, finished 2009/12/03 10:47 Checkins during regression range: https://hg.mozilla.org/releases/comm-1.9.1/pushloghtml?startdate=2009-12-02+13:29&enddate=2009-12-03+10:18 Seems to be regressed by the checkin for Bug 532656 too. First it showed the same error message as in Bug 533070. With the fox from Bug 533070 the en-Us nightly builds were restored but the l10n packaging still fails.
Severity: critical → blocker
I've not tested this, though I have just thrown it at try server to make sure it doesn't break en-US. From looking at the logs, the issue is that when doing the locale repacks, the code is expecting to build the locale related branding files from $MOZ_BRANDING_DIRECTORY/locales not $MOZ_BRANDING_DIRECTORY which is where they currently need to be built from. I expect this was as a result of me telling Fallen to remove the sub-directory makefiles. Now I realise this is the problem, I think its probably going to be better if locale repacks don't create calendar.jar and AB-CD.jar and so having the locales generated in locales sub-directory (as happens on Thunderbird) is a good idea. So this basically just moves the AB-CD.jar part of the jar.mn into the locales/ sub-directory for both branding directories, and changes the support build config structure to match it. I'll take the first review that comes along ;-)
Comment on attachment 420605 [details] [diff] [review] Untested Patch From looking at the code, this seems fine. Given the size of my review queue I'll leave the testing to you though :-)
I'm fairly sure this will work, so I've pushed it to comm-1.9.1 and we'll see what effect it has on the builds. http://hg.mozilla.org/releases/comm-1.9.1/rev/327100b2d777 If it works, then I'll push it to comm-central as well.
I backed out yesterday due to en-US build bustage: http://hg.mozilla.org/releases/comm-1.9.1/rev/1d012af43fc7 I've now re-landed it after having made the following changes: - other-licenses/branding/sunbird/locales/Makefile.in added (previously forgot to hg add it). - the locales/jar.mn files now reference the correct files (e.g. en-US/brand.dtd versus incorrect locales/en-US/brand.dtd). Hopefully this will work (I'll abort today's linux nightly and re-start it).
(In reply to comment #6) > I've now re-landed it after having made the following changes: http://hg.mozilla.org/releases/comm-1.9.1/rev/0051c8707dbb This has stuck and there's now Linux builds appearing in: http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-comm-1.9.1-l10n/ Mac and Windows builds will probably start appearing tomorrow. Leaving open for now as this still needs landing on trunk.
Trunk check in: http://hg.mozilla.org/comm-central/rev/3063edeacd0c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
You need to log in before you can comment on or make changes to this bug.