If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

Release Engineering
General
P1
blocker
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: armenzg, Assigned: armenzg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [l10n])

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

8 years ago
Created attachment 401504 [details]
[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.
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.
(Assignee)

Updated

8 years ago
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Priority: -- → P1
(Assignee)

Comment 2

8 years ago
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.
(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?
(Assignee)

Comment 4

8 years ago
Created attachment 401948 [details] [diff] [review]
[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.
(Assignee)

Comment 5

8 years ago
Created attachment 402085 [details] [diff] [review]
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.
Attachment #401948 - Attachment is obsolete: true
Attachment #402085 - Flags: review?(ccooper)
(Assignee)

Updated

8 years ago
Whiteboard: [l10n]

Comment 6

8 years ago
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?
(Assignee)

Comment 7

8 years ago
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

8 years ago
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.
(Assignee)

Updated

8 years ago
Blocks: 518359

Comment 9

8 years ago
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.
Attachment #402085 - Flags: review?(ccooper) → review+
(Assignee)

Updated

8 years ago
Attachment #402085 - Flags: checked-in?

Updated

8 years ago
Blocks: 518495
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
Attachment #402085 - Flags: checked-in? → checked-in+
(Assignee)

Comment 11

8 years ago
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.
(Assignee)

Comment 12

8 years ago
This has worked on the release runs I just did. Resolving FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.