1236624 - Please add NSIS 3 release to the Windows build slaves

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Ryan VanderMeulen [:RyanVM]]

I'm adding it to Mozillabuild 2.2 and Rob will be landing configure.in support for it in Fx45+ shortly.

Comment 1

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

Bug 1238034 has a patch that adds the path to the testharness python scripts.

Comment 2

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

Here is a MozillaBuild with NSIS 3.0b3 that can be used for deployment
https://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.2.0pre2.exe

Comment 3

[Ryan VanderMeulen [:RyanVM]]

I'm going to take a crack at this using tooltool. My understanding from talking to RelEng folks is that bug 1238034 may not be necessary if done right.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

I've uploaded the zip packages for 3.0b3, 3.0b1, and 3.0a2 to tooltool. Apparently we don't yet have Windows support for unpacking zip archives, however :(

Julien, I hear that may something you know about?

Comment 5

[Julien Pagès (:parkouss)]

Well, not sure that will help much, but here is what I know:

So yeah tooltool installed on windows slaves is not up to date, and so it can't unzip windows file.

I thought about multiple solutions (for my use case), https://bugzilla.mozilla.org/show_bug.cgi?id=1234500#c13.

Then we finally opted for a tar.gz archive instead of a .zip, that should be supported with old versions. The best solution (for me) was to update the installed tooltool version on windows slaves. I had a discusssion with :dustin and :Callek about that. Dusting thought it was possible to update the machines quite easily, while :Callek thought we would possibly have issues - and so spend some time into this.

I would ask in #releng again: since at least you and me are requiring up to date tooltool, I believe there will be more in the future. And instead of finding workaround everywhere, we should probably just tackle the root bug now;

Comment 6

[ISHIKAWA, Chiaki]

Please do not forget to update try-comm-central build machines, too.
Bug 1248963 - try-comm-central cannot build windows optimized binary (see the error in the comment) there are couple of configure script problems.
Basically, configure failed due to unfound NSIS binary.
(Not sure why, then, debug version build succeeded, to be honest.)

TIA

Comment 7

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

Firefox Windows build on try also aren't using NSIS 3.0b3, but will at least fall back to 3.0b1:

04:39:50     INFO -  checking for makensis-3.0b3.exe... no
04:39:50     INFO -  checking for makensis-3.0b1.exe... /c/mozilla-build/nsis-3.0b1/makensis-3.0b1.exe

(taken from http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-8352f3ee456a6714c7adbc85910755bd7dcbbc0e/try-win32/try-win32-bm79-try1-build3533.txt.gz)

Part of the discrepancy is that Firefox is using in-tree mozharness scripts + configs to build, making it really easy to change things like the PATH:

https://hg.mozilla.org/mozilla-central/file/fcd35e10fa17/testing/mozharness/configs/builds/releng_base_windows_32_builds.py#l77

Thunderbird is still using buildbot factories. I see the PATH being set properly in the base configs:

https://hg.mozilla.org/build/buildbot-configs/file/42035e52d1fc/mozilla/thunderbird_config.py#l366

...but then we override PATH for try:

https://hg.mozilla.org/build/buildbot-configs/file/42035e52d1fc/mozilla/thunderbird_production_config.py#l77

If we fix that PATH for try to match the base configs, it should start working.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Given that bug 1240814 is now fixed, I *think* that all that remains to be done here is unpacking NSIS 3.0b3 from tooltool (it's already uploaded there) and adding it to the PATH, however that's supposed to be done these days.

If someone's feeling extra motivated, they could also remove whatever we have in place for 3.0b1 as well and install that from tooltool as well. Unfortunately, I don't have the time to see this through to completion at this point, so I'm regretfully throwing this back into the RelEng pile.

Comment 9

[Liz Henry (:lizzard)]

Ben, who from releng would be right to look at this? We want to follow up with this and bug 1215648.

Comment 10

[Amy Rich [:arr] [:arich]]

I've cced :markco on this to help take a look at the puppet config for the windows builders and see how much effort and risk this would entail. I've also NI :grenade in case there are any changes that need to be made to the tc client.

Comment 11

[Rob Thijssen [:grenade (EET/UTC+0300)]]

On TC builds we use mozilla-build 2.2 which includes NSIS both 3.0b1 and 3.0b3. The only change required to start using b3 was to update the system PATH environment variable to point to the b3 folder instead of b1 which I have now done here:
https://github.com/MozRelOps/OpenCloudConfig/commit/8813df6d553a0feb4af683bb924d1d70edd81204.

If tooltool and in-tree config is also updated to use a tooltool artifact and PATH, the builds will pick that up too.

Comment 12

[Mark Cornmesser [:markco]]

It will be relatively easy to remove with minimum risk from the current builders. Do we want to remove all previous version as well, 2.46u and 3.0a2?

Comment 13

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

ESR38 isn't updated to use a newer version of NSIS so as long as we don't need to build another ESR38 we should be fine.

Note: if the different versions of NSIS are in the path configure will find the latest version supported by the branch.

All Firefox branches except ESR38 should be fine to use NSIS 3.0b3 and removing 2.46u and 3.0a2 should also be fine. The test harness may need to be updated per bug 1238034 though comment #3 states this might not be necessary.

Comment 14

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

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #13)
> ESR38 isn't updated to use a newer version of NSIS so as long as we don't
> need to build another ESR38 we should be fine.
> 
> Note: if the different versions of NSIS are in the path configure will find
> the latest version supported by the branch.
> 
> All Firefox branches except ESR38 should be fine to use NSIS 3.0b3 and
> removing 2.46u and 3.0a2 should also be fine.

We're done with ESR38, so this isn't an issue.

Comment 15

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

Rob and Mark, any updates as to when this will be fixed?

Comment 16

[Mark Cornmesser [:markco]]

I will take a look at this this week or early next week.

I just want to verify; we want to remove all version of nsis from puppet, so what is available is what we get from tooltool?

Comment 17

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

Not sure if you are asking me since I have no knowledge of tooltol but afaic what I am looking for is for the NSIS version to be 3.0b3, it is the one from Mozilla Build so it has the expected binary name, etc.

Comment 18

[Mark Cornmesser [:markco]]

I forgot that I am out on PTO this coming week. Grenade, if this needs to be addressed before i get back could you take a look at it, please?

Comment 19

[Rob Thijssen [:grenade (EET/UTC+0300)]]

Attachment: https://github.com/mozilla/build-cloud-tools/pull/236

This PR addresses the requirement to use nsis 3.0b3 instead of 3.0b1 on Windows buildbot builders. It does this by:
- moving the current mozilla-build folder from c:\mozilla-build to c:\mozilla-build-1.9.0
- creating a symlink at c:\mozilla-build pointing to c:\mozilla-build-1.9.0
- installing mozilla-build 2.2.0 to c:\mozilla-build-2.2.0
- creating a symlink at c:\mozilla-build\nsis-3.0b3 pointing to c:\mozilla-build-2.2.0\nsis-3.0b3
- replacing the env PATH entry for nsis-3.0b1 with one for nsis-3.0b3

This approach has several extra advantages:
- Future requests for access to mozilla-build components newer than 1.9.0 are easy to accommodate.
- Installation of future versions of mozilla-build can be achieved by changing the -version parameter to the installation method.
- It leaves the current mozilla-build installation intact, limiting exposure to breakages

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Just of curiosity, the necessary NSIS packages have been uploaded to tooltool already. Why can't we just use those?

Comment 21

[Rob Thijssen [:grenade (EET/UTC+0300)]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)
> Just of curiosity, the necessary NSIS packages have been uploaded to
> tooltool already. Why can't we just use those?

you can. the pr i attached just means that it would also be available from mozilla-build and that the currently set system PATH var would no longer point to the old version from old mozilla-build.
which one get's used is down to what is in the PATH environment variable at build time and that varies depending on mozconfigs, etc.

Comment 22

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

Comment on attachment 8771945 [details] [review]
https://github.com/mozilla/build-cloud-tools/pull/236

Looks fine but I have very little knowledge of this code.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8771945 [details] [review]
https://github.com/mozilla/build-cloud-tools/pull/236

Sounds OK in principle

Comment 24

[Q]

Waiting on confirmation that userdata is working in current production to see if any tweaks will be neded here.

Comment 25

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

Comment on attachment 8771945 [details] [review]
https://github.com/mozilla/build-cloud-tools/pull/236

My PowerShell skills are non-existent, but the approach looks good.

Comment 26

[Rob Thijssen [:grenade (EET/UTC+0300)]]

I've updated the PR to work against latest updates to cloud-tools but don't really want to merge before I take off for two weeks of PTO.

https://github.com/mozilla-releng/build-cloud-tools/pull/236/commits/0c950ded7bf468c3a3d0a0c9fa28a91e21f5dc46

If someone wants to merge, it should be fine, just be prepared to revert if we see adverse effects. You'll need to keep an eye on 2008 builders (and win7 testers that use userdata in ec2) for a few days.

Also, worth noting that the Windows TC builds now showing in treeherder (https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=win) prefixed with "TC[tier 2]" already use NSIS 3.0b3 in case that's useful.

You can also make use of the tooltool nsis artifact by prepending its path to the env PATH in mozconfig or otherwise.

If this hasn't moved when I get back from PTO, I'll merge then.

Comment 27

[Rob Thijssen [:grenade (EET/UTC+0300)]]

merged: https://github.com/mozilla-releng/build-cloud-tools/commit/3871f564012598fce3761a37fc54b649e7cb3ada
monitoring for issues...

Comment 28

[Rob Thijssen [:grenade (EET/UTC+0300)]]

reverted due to build failures relating to installer: https://github.com/mozilla-releng/build-cloud-tools/commit/6c4d07b39d075ee781e8fe31efc92ac46ce136c6

see #build @ 11:39: http://logs.glob.uno/?c=mozilla%23build&s=17+Aug+2016&e=17+Aug+2016

Comment 29

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

Looks like NSIS compiled the installer, the installer was signed, the installer was copied to installer-stage, and it failed when creating the 7-Zip archive which contains the build and the installer.

04:20:17     INFO -  cd ../../../installer-stage &&  7z a -r -t7z c:/builds/moz2_slave/m-in-w64-000000000000000000000/build/src/obj-firefox/browser/installer/windows/instgen/app.7z -mx -m0=BCJ2 -m1=LZMA:d25 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1 -mb0s1:2 -mb0s2:3
04:20:17     INFO -  7-Zip [32] 15.14 : Copyright (c) 1999-2015 Igor Pavlov : 2015-12-31
04:20:17     INFO -  System ERROR:
04:20:17     INFO -  Unspecified error
04:20:17     INFO -  c:/builds/moz2_slave/m-in-w64-000000000000000000000/build/src/toolkit/mozapps/installer/windows/nsis/makensis.mk:72: recipe for target 'installer' failed

Comment 30

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

NSIS 3 was release a short while ago and since this bug isn't fixed yet it would be better to go with it instead.

Comment 32

[Romain Testard [:RT]]

Per bug 1319871, this bug also prevents Win10 users break-down when analyzing the stub installer ping data (Win10 users counted as Windows 8.1 users).

Comment 33

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

(In reply to Romain Testard [:RT] from comment #32)
> Per bug 1319871, this bug also prevents Win10 users break-down when
> analyzing the stub installer ping data (Win10 users counted as Windows 8.1
> users).
We've added code to handle this in the past when we've had trouble getting NSIS deployed to build systems. I filed bug 1322331 to do exactly that,

Comment 34

[Andrew McCreight [:mccr8]]

Any updates here? This has stalled out for around five months, and is blocking a security issue we should fix. Thanks.

Comment 35

[Rob Thijssen [:grenade (EET/UTC+0300)]]

- The effort (several months ago) to introduce newer nsis on buildbot Windows slaves resulted in build bustage.
- On TaskCluster Windows workers nsis is currently version 3.0.b3 (https://github.com/mozilla-releng/OpenCloudConfig/blob/8641b8b2d4cba5fed3f2feec99b9982a2ce8ccf3/userdata/Manifest/gecko-1-b-win2012.json#L915)

I have updated the TaskCluster Windows Try builders to version 3.01 today (https://github.com/mozilla-releng/OpenCloudConfig/commit/2417179e71de6018e30989d8f122030d50585d1e). I will update the non-try builders in a day or two if the try builds still look good. I don't know what to say about BuildBot slaves though.

Also there are paths hardcoded into tree that will continue to use old versions of nsis until someone updates them:
- https://dxr.mozilla.org/mozilla-central/search?q=nsis-2&redirect=false
- https://dxr.mozilla.org/mozilla-central/search?q=nsis-3&redirect=false

Comment 36

[Rob Thijssen [:grenade (EET/UTC+0300)]]

try didn't blow up so i added 3.01 to level 2 and 3 builders as well.
https://github.com/mozilla-releng/OpenCloudConfig/commit/8b5d7665cd820874201b0022f5e0483d66418a1c

Comment 37

[Mark Cornmesser [:markco]]

I can deploy NSIS 3.01 through puppet to the buildbot Windows Builders next week. 

I just want to verify first that we are not deploying this through tooltool? And has 3.01 been tested at all with buildbot?

Comment 38

[Mark Cornmesser [:markco]]

Attachment: BUG1236624-NSIS.patch

Comment 39

[Mark Cornmesser [:markco]]

I am assuming we are not using tooltool to deploy nsis.

Before I land the above patch, what is the context in which we use nsis? The reason for asking is because I would like to test before landing it. This version was a slightly different file structure then the previous version we have deployed. Also do we want to remove the previous versions?

Comment 40

[Molly Howell (she/her) (mostly inactive)]

(In reply to Mark Cornmesser [:markco] from comment #39)
> Before I land the above patch, what is the context in which we use nsis?

NSIS is an installer generator; it creates our Windows installer executables based on scripts that we maintain.

> The reason for asking is because I would like to test before landing it. This
> version was a slightly different file structure then the previous version we
> have deployed.

Unfortunately we don't have any automated test coverage for the installers, but just making sure that they get generated and run successfully (i.e., actually install the browser) should be enough of a test. I've used the new version for a few local builds and haven't been able to find any problems. Unsurprisingly, the changes from 3.0 beta 3 to 3.01 are just minor additions and bug fixes (although that includes at least one important security fix). I'm not sure what the specific file structure differences are, but they don't seem to have broken anything we depend on.

> Also do we want to remove the previous versions?

I would recommend it; don't want to risk the build process deciding to pick up an older version.

I am the person currently responsible for the installer, so I can take any other questions.

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Right now, we're using 3.0b1 across all branches. We'll need to keep that around so that we're not breaking older release branches at a minimum.

It's also worth pointing out that at the moment, moz.configure isn't even setup to look for newer versions than 3.0b3:
https://dxr.mozilla.org/mozilla-central/source/moz.configure#281

Though I guess we'd in theory fallback to makensis.exe if neither 3.0b3 or 3.0b1 were found in the path. That said, we should get a patch landed ASAP that makes 3.01 an acceptable option for moz.configure. Also, it would be good to backport that to 52 so we're not stuck supporting an older NSIS release for the duration of the next ESR cycle.

Comment 42

[Mark Cornmesser [:markco]]

Attachment: BUG1236624-NSIS.patch

Comment 43

[Jake Watkins [:dividehex]]

Comment on attachment 8828569 [details] [diff] [review]
BUG1236624-NSIS.patch

Review of attachment 8828569 [details] [diff] [review]:
-----------------------------------------------------------------

I assume the each zip will unpack into a folder unique to that version eg. nsis-3.01\ and nsis-3.0b1\ . If not, then we risk them over writing each other.  Please verify how each zip unpacks since the puppet packages::pkgzip defined resource will happily clobber existing files.

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Mark, can you please confirm that the 3.01 zip package you're creating renames makensis.exe to makensis-3.01.exe similar to what's done during the MozillaBuild packaging step?
https://hg.mozilla.org/mozilla-build/file/tip/packageit.sh#l118

Comment 45

[Mark Cornmesser [:markco]]

(In reply to Jake Watkins [:dividehex] from comment #43)
> Comment on attachment 8828569 [details] [diff] [review]
> BUG1236624-NSIS.patch
> 
> Review of attachment 8828569 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I assume the each zip will unpack into a folder unique to that version eg.
> nsis-3.01\ and nsis-3.0b1\ . If not, then we risk them over writing each
> other.  Please verify how each zip unpacks since the puppet packages::pkgzip
> defined resource will happily clobber existing files.

The functionality there is based off of the behavior of 7zip. It will extract the files to a directory with the same name as the zip file. 

(In reply to Ryan VanderMeulen [:RyanVM] from comment #44)
> Mark, can you please confirm that the 3.01 zip package you're creating
> renames makensis.exe to makensis-3.01.exe similar to what's done during the
> MozillaBuild packaging step?
> https://hg.mozilla.org/mozilla-build/file/tip/packageit.sh#l118

Currently it does not. I will correct that. Should the same thing be done for the 3.0b1 version?

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Yeah, probably. We're likely getting away with it currently because 3.0b1 ships with MozillaBuild where that renaming was done already during packaging.

Comment 47

[Mark Cornmesser [:markco]]

I have the corrected the zip file. As for the 3.0bl the current exe is already named makensis-3.0b1.exe.


I am going to land the Puppet changes and update the base AMI removing older versions of the nsis from the base AMI Monday.

Comment 48

[Mark Cornmesser [:markco]]

Comment on attachment 8828569 [details] [diff] [review]
BUG1236624-NSIS.patch

https://hg.mozilla.org/build/puppet/rev/f7f7218471ae6a03c2ab350ee364be3657d0d571
https://hg.mozilla.org/build/puppet/rev/539cd7c8dc35d1b36763bf053df4f8efb89099da

Comment 49

[Mark Cornmesser [:markco]]

Attachment: Remove old versions of NSIS from base AMIs

grenade: If R+ could you please merge?

Tested and verified that both AMIs will go through the golden process without error.

Comment 50

[Rob Thijssen [:grenade (EET/UTC+0300)]]

Comment on attachment 8829632 [details] [review]
Remove old versions of NSIS from base AMIs

merged: https://github.com/mozilla-releng/build-cloud-tools/commit/641683f88ad277e0ec860cc89fff3457f56c1548

Comment 51

[Molly Howell (she/her) (mostly inactive)]

It looks like something still needs to be done to make this work. I wrote a patch to moz.configure [1] to replace 3.0b1 with 3.01, and when I pushed that to try it failed to find any supported version [2]. Any ideas about what's missing?

[1] https://hg.mozilla.org/try/rev/b43e2224402ca5e5487ac6b965959bb03691491e
[2] https://treeherder.mozilla.org/logviewer.html#?job_id=76086564&repo=try&lineNumber=2009

Comment 52

[Mark Cornmesser [:markco]]

It looks like "C:\mozilla-build\nsis-3.01" is not in the path variable that is set at line 1942. I am not sure what sets that variable.

Comment 53

[Molly Howell (she/her) (mostly inactive)]

I finally figured out where to change the PATH to include the 3.01 directory and sent that off in this try push:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c56c7fd8a28d4965898958e331b93667470540d8&selectedJob=82588100

... which also failed to build. But it failed differently! Progress!

The error this time is 

https://treeherder.mozilla.org/logviewer.html#?job_id=82588100&repo=try&lineNumber=1930

and I believe that message comes from makensis when it can't find Bin/makensis-3.01.exe. The makensis.exe in the root of the NSIS distribution is just a launcher for the one in the Bin directory, and the launcher expects that file to have the same name as it does.

Mark, can you double-check the ZIP file to make sure that *both* makensis.exe and Bin/makensis.exe got renamed?

Comment 54

[Rob Thijssen [:grenade (EET/UTC+0300)]]

taskcluster win builders updated (we weren't making any rename attempt there): https://github.com/mozilla-releng/OpenCloudConfig/commit/fa5ba8c54fcf3d72a26088f48ffd87472903ed84

Comment 55

[Rob Thijssen [:grenade (EET/UTC+0300)]]

had to revert the change above as it managed to break the windows builds and close the trees (see bug 1345837).
https://github.com/mozilla-releng/OpenCloudConfig/commit/87cb67fa3a6ceb6a4d4188bd4447a364c978998a

it seems that the change made the builds start using nsis 3.01 when they had previously been using an older version and this had knock on effects that break things.

Comment 56

[Molly Howell (she/her) (mostly inactive)]

NSIS has nothing to do with pdbstr.exe, that comes from the Windows SDK.

Also, that change did not actually cause the build to start using NSIS 3.01, it still picked up 3.0b3 as expected without the PATH change discussed above:
https://treeherder.mozilla.org/logviewer.html#?job_id=82754773&repo=mozilla-inbound&lineNumber=1079

Comment 57

[Rob Thijssen [:grenade (EET/UTC+0300)]]

ok. apologies if i'm off the mark. the builds broke immediately after i made the change, which is why i made a correlation.

Comment 58

[Molly Howell (she/her) (mostly inactive)]

Well, nothing's impossible, but I don't know how it could be related.

If having symlinks is somehow the problem, we don't actually need them; just renaming the files is enough.

Comment 59

[Rob Thijssen [:grenade (EET/UTC+0300)]]

it's worth noting that on taskcluster builds, C:\mozilla-build\nsis-3.01 has had precedence in the system PATH variable (rather than PATH changes during the build) since comment 36 above (not true on buildbot slaves, tc only). my assumptions were based on having corrected the filenames (with symlinks) the system path would have made 3.01 available.

Comment 60

[Molly Howell (she/her) (mostly inactive)]

Oh, you're right, 3.01 is the first one on the PATH for tc jobs. I do usually get confused when buildbot vs. tc comes into play, I don't really understand most of the differences, so I'm not surprised I had that wrong; sorry about that.

3.01 still won't be used in the build though without a change to moz.configure, which is where the renamed files are required.

Comment 61

[Rob Thijssen [:grenade (EET/UTC+0300)]]

Matt, just to follow up from yesterday, you were of course correct that the build problems around pdbstr were completely unrelated to nsis. Those problems occurred because of a mistake I made in an earlier change to occ ci which was propagated to the builders when I deployed the nsis change. Apologies for creating confusion there. I will  re-attempt the nsis patch when I've finished cleaning up the other mess I made.

Comment 62

[Molly Howell (she/her) (mostly inactive)]

Okay, I understand. Thanks for the follow-up, and for helping out with this.

Comment 63

[Mark Cornmesser [:markco]]

(In reply to Matt Howell [:mhowell] from comment #53)
> I finally figured out where to change the PATH to include the 3.01 directory
> and sent that off in this try push:
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=c56c7fd8a28d4965898958e331b93667470540d8&selectedJob=8
> 2588100
> 
> ... which also failed to build. But it failed differently! Progress!
> 
> The error this time is 
> 
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=82588100&repo=try&lineNumber=1930
> 
> and I believe that message comes from makensis when it can't find
> Bin/makensis-3.01.exe. The makensis.exe in the root of the NSIS distribution
> is just a launcher for the one in the Bin directory, and the launcher
> expects that file to have the same name as it does.
> 
> Mark, can you double-check the ZIP file to make sure that *both*
> makensis.exe and Bin/makensis.exe got renamed?

The bin/makensis.exe was not renamed. I have updated the zip file with the file renamed. It will go out on the next golden image generation.

Comment 64

[Molly Howell (she/her) (mostly inactive)]

Something still isn't quite right here. Check out this log:
https://treeherder.mozilla.org/logviewer.html#?job_id=84141985&repo=try&lineNumber=18311

We found 3.01 and were able to call it, but makensis failed because it couldn't load any of the default plugins. The directory that was searched for the plugins is the correct one, there really should be 16 DLL files in c:\mozilla-build\nsis-3.01\Plugins\x86-ansi, but either they're not there or makensis wasn't able to open them for some reason that isn't clear to me. Line 18315 should be followed by a list of all the plugin functions that were found. Here's the expected output taken from a local build: https://pastebin.mozilla.org/8982250

Everything else in the log looks correct, so I think we're close. But at this point I am starting to feel like just waiting for the new MozillaBuild release and using that might be a better option than trying to sort all this out manually.

Comment 65

[Mark Cornmesser [:markco]]

I am taking a look into this today.

Comment 66

[Mark Cornmesser [:markco]]

For some reason the plugins directory is not extracting correctly during deployment. If i can't find a reason why, I will capture new base AMIs with NSIS 3.01 hand installed.

Comment 67

[Mark Cornmesser [:markco]]

I have updated the zip package. The plugin directory now extracts out to x86-ansi and x86-unicode directories which contain several DLLs. 

This will go out for the next golden AMI generations.

Comment 68

[Molly Howell (she/her) (mostly inactive)]

Still not quite there. :(

Ran a new try push [0] and now the configure script's call out to makensis just hangs forever. I'm not sure what could be causing that, never seen anything like it before.

[0] https://treeherder.mozilla.org/#/jobs?repo=try&revision=bbdc5b3a0cccb50bedbde3525b1a65a4cf8c3260&selectedJob=85439535

Comment 69

[Mark Cornmesser [:markco]]

My bad. The last zip package had a small issue.
 
I have updated it. It will be picked up in the next golden AMI creation. Is there way I could test it independent of a build?

Comment 70

[Molly Howell (she/her) (mostly inactive)]

Thanks!

You could run makensis on one of the .nsi files in the Examples directory, those are self-contained. Maybe LogicLib.nsi, it just runs some unit tests and doesn't try to do anything to the system.

Comment 71

[Mark Cornmesser [:markco]]

It seem to have worked:


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\mozilla-build\nsis-3.01>makensis-3.01.exe C:\mozilla-build\nsis-3.01\Examples
\Library.nsi
Processing config: C:\mozilla-build\nsis-3.01\nsisconf.nsh
Processing script file: "C:\mozilla-build\nsis-3.01\Examples\Library.nsi" (ACP)

Processed 1 file, writing output (x86-ansi):

Output: "C:\mozilla-build\nsis-3.01\Examples\Library Test.exe"
Install: 2 pages (128 bytes), 1 section (2072 bytes), 1914 instructions (53592 b
ytes), 93 strings (1631 bytes), 1 language table (234 bytes).
Uninstall: 1 page (128 bytes), 1 section (2072 bytes), 1224 instructions (34272
bytes), 72 strings (1133 bytes), 1 language table (202 bytes).
Datablock optimizer saved 109988 bytes (~64.3%).

Using zlib compression.

EXE header size:               36352 / 37376 bytes
Install code:                   3509 / 57025 bytes
Install data:                  14021 / 312040 bytes
Uninstall code+data:           10427 / 10928 bytes
CRC (0x5F8CB489):                  4 / 4 bytes

Total size:                    64313 / 417373 bytes (15.4%)

C:\mozilla-build\nsis-3.01>

Comment 72

[Molly Howell (she/her) (mostly inactive)]

Bug 1347191 is now resolved; it modifies moz.configure to start looking for 3.01 if available. This seems to have worked on TaskCluster builds, they actually pick up and use 3.01 successfully (yay!). BuildBot does not pick up 3.01; the only reason seems to be that it's not on the PATH that gets set up there. I think I have a patch that takes care of that, which I'll try to get landed.

Comment 73

[Molly Howell (she/her) (mostly inactive)]

Filed bug 1351482 a while back in regards to the above buildbot issue. This bug can be resolved when that one is.

Comment 74

[Molly Howell (she/her) (mostly inactive)]

Today's nightly installers are running NSIS 3.01! I think we are actually finally done here.

Comment 75

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

Should this be rolled out to level 2 and level 3 workers too? I think at the moment it is only on level 1.

Comment 76

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

(In reply to Pete Moore [:pmoore][:pete] from comment #75)
> Should this be rolled out to level 2 and level 3 workers too? I think at the
> moment it is only on level 1.

My mistake - the difference between level 1 and level 2/3 builders is the version of MozillaBuild.