517544 - Win32 L10n repackages do not pass "make nsprpub" in the 3.6b1 release

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P1)

Description

[Armen [:armenzg]]

Attachment: [log] "make nsprpub" for repackages does not work for windows on the fake 3.6b1 release

In the log attached you can see that we are trying to build nspr, and link it with jemalloc, but you we didn't build the CRT:

link -nologo -DLL -SUBSYSTEM:WINDOWS -MANIFEST:NO -LIBPATH:"e:/builds/moz2_slave/win32_repack/build/mozilla-1.9.2/memory/jemalloc/crtsrc/build/intel" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -DEFAULTLIB:mozcrt19

This problem is not hit with nightly runs because we do not use mozconfig files.

This seems to affect mozilla-1.9.2 and maybe m-c.

Comment 1

[[e-mail] (:bhearsum)]

Apparently we can fix this by building memory/jemalloc before we build anything else. This would allow us to continue sharing the en-US mozconfig file, which seems better than maintaining a whole other set.

Comment 2

[Armen [:armenzg]]

Is there a good compiling reason that we even use a mozconfig for L10n release repackages? 
Making memory/jemalloc seemed to me that it takes some time to be build (maybe because I am doing it with an open VNC session) and I don't know why we would want to add more compiling time to not just win32 but all other platforms.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to comment #2)
> Is there a good compiling reason that we even use a mozconfig for L10n release
> repackages? 
> Making memory/jemalloc seemed to me that it takes some time to be build (maybe
> because I am doing it with an open VNC session) and I don't know why we would
> want to add more compiling time to not just win32 but all other platforms.

Yes. The mozconfig is where we set the update channel. This is required for releases. How long does it take to build?

Comment 4

[Armen [:armenzg]]

Attachment: [WIP] add jemmalloc to the release path for win32 to be able to run "make nsprpub"

This is my WIP which has been able to do release (to retest after today's development) and nightly runs.

These are the changes done:
* left "make config" on BaseRepackFactory
* added "make memory/jemalloc" in doRepack for ReleaseRepackFactory
* removed "make config" from doRepack of ReleaseRepackFactory
* move "make nsprpub" to doRepack of NightlyRepackFactory

Aside of what I was fixing I have removed self.createSnippet since the logic was incorrect. It makes no sense to create snippets if we are not caring about updates.

Some more testing in the morning and this should be soon be done.

Comment 5

[Armen [:armenzg]]

Attachment: add jemmalloc to the release path for win32 to be able to run "make nsprpub"

This has run correctly for nightly runs on all 3 branches and the release execution paths.

Comment 6

[Axel Hecht [:Pike]]

Hrm. Why do we need that? Can't we just disable jemalloc via configure or something for l10n repacks?

Did we figure out yet why this is hitting us on the release testing and not on nightlies?

Comment 7

[Armen [:armenzg]]

We are making it because it is enabled in the mozconfig which is used for win32 (we don't use mozconfigs for nightly runs). The only reason that we use a mozconfig for l10n releases is mentioned by bhearsum in comment 3.

What do we think of changing it to pass the update-channel as parameter rather than requiring to use the mozconfig? I get the feeling that we will have more situations like this if we keep on using the mozconfig. The problem would be to to retest the beta and release channels for both 1.9.1 and 1.9.2. Ben, is this right?

Comment 8

[Axel Hecht [:Pike]]

I personally think that using a mozconfig in general wouldn't be a bad idea for l10n builds. Could we make the release factory try to copy self.mozconfig + "-l10n" first and then mozconfig as fallback? Then we could just add a mozconfig-l10n to buildbot-configs for win32 and make it not use jemalloc.

Comment 9

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

Comment on attachment 402085 [details] [diff] [review]
add jemmalloc to the release path for win32 to be able to run "make nsprpub"

Discussed this with releng today. 

I agree with Axel that switching to mozconfigs is a better long-term solution, but this patch is less invasive in the interim.

Armen has filed bug 518359 to cover the switch to l10n mozconfigs. He'll be tackling after 3.6b1 is out the door.

Comment 10

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

Comment on attachment 402085 [details] [diff] [review]
add jemmalloc to the release path for win32 to be able to run "make nsprpub"

http://hg.mozilla.org/build/buildbotcustom/rev/defac78a8079

Comment 11

[Armen [:armenzg]]

The changes have worked correctly on the manually triggered l10n builds.
I will verify this on staging later today that the win32 repackages happen correctly.

Comment 12

[Armen [:armenzg]]

This has worked on the release runs I just did. Resolving FIXED.