776440 - Use NSIS 2.46 for l10n repacks

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Robert Strong (they/them - no direct email)]

I just checked the version of NSIS running on the l10n build systems and it is still 2.33 whereas m-c has 2.46. NSIS 2.46 is available from the latest Mozilla Build. We are going to need this for the stub installer which is now considered a priority.

Comment 1

[Justin Wood (:Callek)]

When you say "l10n build systems" do you mean the "l10n repack jobs" we run, or do you mean the l10n compare-local jobs pike runs for l10n.mozilla.org ?

Comment 2

[Robert Strong (they/them - no direct email)]

I believe it is the repack and that the installer is rebuilt during that phase. When looking at the Win logs on
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n

"MakeNSIS v2.33-Unicode" is in the log.

Comment 3

[Justin Wood (:Callek)]

Morphing Summary to reflect the real todo here.

See Bug 762218 which actually deployed this NSIS version to our slaves.

And Bug 765777 which talks about Thunderbirds Need for NSIS 2.46

Comment 4

[Justin Wood (:Callek)]

To be extra clear robert, is this something we need to ride the trains with, or is there no downside at all about having all jobs, even esr use the newer NSIS?

Comment 5

[Robert Strong (they/them - no direct email)]

There should be no downside including with esr and we already have the newer NSIS on m-c. I added the capability to configure, etc. to use NSIS 2.46 in Mozilla Build 1.6 and bug 569058 which landed on 2010-06-21.

Comment 6

[Chris Cooper [:coop] (he/him)]

cc-ing nthomas who is helping with the work for Thunderbird over in bug 765777. Would be nice to make these changes to both products at once and not be out of sync.

Comment 7

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

Mapping out our configuration space, for 32bit Windows builds (not necessarily a 32bit build machine):

                      Firefox       Thunderbird
en-US nightly        2.46  [1]        2.46  [2]
l10n  nightly        2.33  [3]        2.33  [4]
en-US release        2.33  [5]        2.46  [6]
l10n  release        2.33  [7]        2.46  [8]


[1] https://tbpl.mozilla.org/php/getParsedLog.php?id=13771156&tree=Firefox&full=1
checking for makensisu-2.46... /c/mozilla-build/nsis-2.46u/makensisu-2.46
[2] https://tbpl.mozilla.org/php/getParsedLog.php?id=13769341&tree=Thunderbird-Trunk&full=1
[3] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/mozilla-central-win32-l10n-nightly-de-bm32-build1-build203.txt.gz
[4] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-l10n/comm-central-win32-l10n-nightly-de-bm32-build1-build144.txt.gz
[5] http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/14.0.1-candidates/build1/logs/release-mozilla-release-win32_build-bm12-build1-build3.txt.gz
[6] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/candidates/14.0-candidates/build1/logs/release-comm-release-win32_build-bm34-build1-build8.txt.gz
[7] http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/14.0.1-candidates/build1/logs/release-mozilla-release-win32_repack_1-bm12-build1-build3.txt.gz
[8] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/candidates/14.0-candidates/build1/logs/release-comm-release-win32_repack_1-bm34-build1-build5.txt.gz

Comment 8

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

Expanding a little more:
                      Firefox       Thunderbird
m-c and m-a:
en-US nightlies         2.46             2.46
l10n  nightlies         2.33             2.33

m-b (15.0b1):
en-US dep build         2.46             2.46
en-US release auto.     2.46             2.46
l10n  release auto.     2.33             2.46

m-r (14.0.1):
en-US dep build         2.33             ??
en-US release auto.     2.33             2.46
l10n  release auto.     2.33             2.46

How did does that work then ?
* Firefox uses 2.46 where it has swapped to a Win64 builder, because those have 2.46 in the path somewhere before buildbot launches. It uses 2.33 uses a Win32 builder, which have 2.46 installed but not in the path
* Same for Thunderbird except that it also prepends 2.46 to the start of the path via the env in thunderbird_config.py:
 http://hg.mozilla.org/build/buildbot-configs/file/68c191f31d39/mozilla/thunderbird_config.py#l278
Strangely, this the path is modified for all steps in a SigningScriptFactory (eg the l10n release auto) without an explicit env=env in the addStep calls.

So how can we fill in the gaps
* AFAICT we can move l10n jobs to win64 slaves if we fix bug 774947, obsoleting bug id=765777
* m-r will swap to Win64 builders at the next merge, m-b made that change recently

Comment 9

[Robert Strong (they/them - no direct email)]

All I know about is the way that Mozilla Build / configure handles this which should just work by having the main binary named specifically for the NSIS build in Mozilla Build and configure looking for the latest and using it when found... it is my understanding that the build systems are customized.

Do these systems use Mozilla Build along with its setup scripts?

Comment 10

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

We have an older MozillaBuild, with NSIS 2.46 retro-installed, and custom scripts to launch buildbot which differ a little from the ones a developer would use. At some point in the glorious future we may start from scratch with a fresh copy of MozillaBuild, but in the mean time we incrementally bring the machines up to date.

Comment 11

[Robert Strong (they/them - no direct email)]

The changes to MozillaBuild were made in bug 569534.

Basically, the path to NSIS 2.46 (in the nsis-2.46u directory in MozillaBuild) was added so it can be found during configure and the makensis.exe binary is copied to makensisu-2.46.exe so it can differentiate from the other makensis.exe's.

Comment 12

[[e-mail] (:bhearsum)]

Not sure if anyone was using it still, but I had to rename the nsis-2.46 install on mw32-ix-slave19 in order to do some tests of release automation. Before I renamed it, I was hitting issues with l10n repacks. I intend to put it back when I'm done.

Comment 13

[Johnathan Nightingale [:johnath]]

This is one of the bugs that will block roll out of the stub installer. Can someone help me understand where it sits in the priority queue?

Comment 14

[Damon Sicore (:damons)]

Who owns this?  As Johnath says, this blocks the stub installer, and it's a big priority this quarter.  Need an update ASAP.

Comment 15

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

This happens for free once the l10n repacks move from being run on win2003 (32bit) builders to being run on win2008 (64bit) builders. (details above in comment#8). That work to do this is already in progress and being tracked in bug#774947 and bug#784848. 

I'll get a more accurate ETA posted to this bug tmrw.

(as a nice side effect, this will allow us convert more win2003 build machines to win2008 build machines, to speed up wait times for windows builds)

Comment 16

[Aki Sasaki (not active)]

Attachment: (configs) update win32 env

This updates win32, win32 debug, and win32-metro to have nsis 2.46u first in PATH.
It doesn't touch esr10.

I'd like to run some tests to verify we call the right nsis in l10n repacks.

Comment 17

[Aki Sasaki (not active)]

Attachment: (custom) use self.env for BaseRepackFactory configure step

Without this, configure runs without the env set properly, and we end up with the wrong nsis again.

With it, we use the right nsis.

I was a bit worried that MOZ_OBJDIR would break things, but it appears to not have any effect here.

Side note: we will probably need to clobber all existing l10n dirs when this lands, to clear config.cache.

Comment 18

[Aki Sasaki (not active)]

Comment on attachment 656298 [details] [diff] [review]
(configs) update win32 env

I'd like to double check that linux and osx repacks are fine with the buildbotcustom configure tweak, but otherwise I think this is ready for review.

Comment 19

[Aki Sasaki (not active)]

Comment on attachment 656298 [details] [diff] [review]
(configs) update win32 env

Went green on linux and macosx64 repacks.
I was going to re-test win32 due to pymake changes, but those got backed out (twice).

This should clear the blocking issue from stub installers once we reconfig.
Win32 l10n repacks on win64 slaves is still on my plate, but now I have less time pressure.

Comment 20

[Aki Sasaki (not active)]

Comment on attachment 656325 [details] [diff] [review]
(custom) use self.env for BaseRepackFactory configure step

http://hg.mozilla.org/build/buildbotcustom/rev/3add56b1f225

Comment 21

[Aki Sasaki (not active)]

Oh, per comment 17 we'll have to reconfig, then clobber all win32 l10n builders.

Comment 22

[Justin Wood (:Callek)]

(In reply to Aki Sasaki [:aki] from comment #21)
> Oh, per comment 17 we'll have to reconfig, then clobber all win32 l10n
> builders.

To be clear after brief chat with aki on IRC, this *should* only be needed to clobber for w32 l10n builders, but this does change the environment for *all* l10n builders, so it does not hurt to clobber those as well, in fact I at least would recommend it - incase something really odd shows up.

Comment 23

[[e-mail] (:bhearsum)]

Made it to production today.

Comment 24

[Aki Sasaki (not active)]

Clobbered all desktop l10n on m-c and m-a for Firefox and Thunderbird.
Running a win32 nightly repack to verify.

Comment 25

[Aki Sasaki (not active)]

The win32 nightly repack is using nsis 2.46.