Closed Bug 1441685 Opened 6 years ago Closed 6 years ago

Thunderbird 59.0b2 build1: build step failed on win32 - Error in macro InstallOnInitCommon on macroline 157

Categories

(Thunderbird :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 59.0

People

(Reporter: wsmwk, Unassigned)

References

Details

https://archive.mozilla.org/pub/thunderbird/candidates/59.0b2-candidates/build1/logs/release-comm-beta-win32_build-bm72-build1-build14.txt.gz

========= Started 'python c:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/build/pymake/make.py ...' failed (results: 2, elapsed: 56 secs) (at 2018-02-27 14:00:39.502994) =========
'python' 'c:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/build/pymake/make.py' 'installer'
 in dir c:\builds\moz2_slave\tb-rel-c-beta-w32_bld-00000000\build/objdir-tb (timeout 1200 secs)
 watching logfiles {}
 argv: ['python', 'c:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/build/pymake/make.py', 'installer']
 environment:
  ALLUSERSPROFILE=C:\ProgramData
...
...
WARNING: Found 35 duplicated files taking 73048 bytes (uncompressed)
...
...
cd instgen && c:/mozilla-build/nsis-3.0b1/makensis-3.0b1.exe  installer.nsi
Processing config: c:\mozilla-build\nsis-3.0b1\nsisconf.nsh
Processing script file: "installer.nsi" (ACP)
Usage: StrCpy $(user_var: output) str [maxlen] [startoffset]
Error in macro InstallOnInitCommon on macroline 157
Error in script "installer.nsi" on line 113 -- aborting creation process
c:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mozilla/toolkit/mozapps/installer/windows/nsis/makensis.mk:45: recipe for target 'instgen/setup.exe' failed
Looks like fallout from bug 1427712 to me.
See Also: → 1427712
Right, this is what the log says:
Processing script file: "installer.nsi" (ACP)
Usage: StrCpy $(user_var: output) str [maxlen] [startoffset]
Error in macro InstallOnInitCommon on macroline 157
Error in script "installer.nsi" on line 113 -- aborting creation process

I saw the failure on the tree but didn't look further than
  "CalledProcessError: Command '['hg', 'path', 'default']' returned non-zero exit status 1"
:-(
I've done the following backout to solve this problem:
https://hg.mozilla.org/releases/mozilla-beta/rev/6429339f38d8b985891c97f5c09580bfb846dddd
Bug 1441685 - Backed out changeset ab285921713c from bug 1427712 [Integrate Beijing office's customizations into the full installer] to build Thunderbird 59 beta. a=jorgk DONTBUILD
I'm thinking it might be sufficient to wrap the toolkit changes with !ifdef MOZ_OPTIONAL_EXTENSIONS, but I don't have a windows machine set up to validate that. The other option would be to port the optional extensions changes to Thunderbird, which seems to be fairly straightforward.

I don't really understand nsis errors yet (nor the langauge), I'm having trouble determining the actual error line that is failing. Line 113 is "!insertmacro CheckCustomCommon" and line 157 is a comment.

Matt, would you be willing to give us some insight here?
Flags: needinfo?(mhowell)
This looks like the same error with bug 1433519?
(In reply to Hector Zhao [:hectorz] from comment #6)
> This looks like the same error with bug 1433519?

Jorg, want to go this route instead?
Flags: needinfo?(jorgk)
Thanks Hector! Personally I think we should still consider adding the ifdef to the m-c nevertheless, as the optional extensions code is not in toolkit.
Damn, it would have been easier to uplift bug 1433519 :-(
Either way will do, for now we can go with the backout.

We can unless Philipp wants to follow up with what he said in comment #8.
Flags: needinfo?(jorgk)
The error message is just trying to say that the variable InstallOptionalExtensions is undefined, but it's saying it in the most roundabout way possible. By "Error in macro InstallOnInitCommon on macroline 157" it means the error is at the 157th line of the definition of the macro InstallOnInitCommon, which is actually line 5104 in a completely different file, /mozilla/toolkit/mozapps/installer/windows/nsis/common.nsh. And it thinks the StrCpy instruction doesn't have enough arguments because the first argument, the variable, doesn't exist; use of an undefined variable is normally a warning in NSIS unless it leads to a syntax error like this, so that's why the error itself doesn't mention that. It's... not a great language.

I agree that what was done in bug 1433519 would be a good solution, the backout shouldn't hurt anything either.

Sorry about all this, by the way; you'd think that by now I've broken Thunderbird enough times that I should know what to look for in advance.
Flags: needinfo?(mhowell)
(In reply to Matt Howell [:mhowell] from comment #10)
> I agree that what was done in bug 1433519 would be a good solution, the
> backout shouldn't hurt anything either.

I'd suggest to go with the uplift then, since it seems to be the easiest solution. Jörg, can you do this for posterity on comm-beta, even if we aren't spinning another beta?
 

> Sorry about all this, by the way; you'd think that by now I've broken
> Thunderbird enough times that I should know what to look for in advance.

Oh no worries! We of course appreciate you looking in advance, but as we are not a Tier 1 project there is no such expectation. 


Matt, what do you think about adding !ifdef MOZ_OPTIONAL_EXTENSIONS to the toolkit code? It seems to me like this would also get rid of the error, and more importantly is a cleaner solution than relying on the interaction between browser/ and toolkit/ nsis code?
Flags: needinfo?(mhowell)
(In reply to Philipp Kewisch [:Fallen]  from comment #11)
> Matt, what do you think about adding !ifdef MOZ_OPTIONAL_EXTENSIONS to the
> toolkit code? It seems to me like this would also get rid of the error, and
> more importantly is a cleaner solution than relying on the interaction
> between browser/ and toolkit/ nsis code?

Yeah, I would definitely be okay with this.
Flags: needinfo?(mhowell)
(In reply to Matt Howell [:mhowell] from comment #12)
> Yeah, I would definitely be okay with this.

Doing this in bug 1443682.
OK, we're done here then. Summary:
This bug could/should have been fixed by uplifting the port in bug 1433519 to TB 59. Instead it was fixed by backing out the bug that was ported (comment #4).

Let's call it fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 59.0
You need to log in before you can comment on or make changes to this bug.