Closed Bug 1346939 (SeaMonkey2.49ESR) Opened 7 years ago Closed 6 years ago

Tracking bug for build and release of SeaMonkey 2.49.1 from ESR branch

Categories

(SeaMonkey :: Release Engineering, defect, P1)

SeaMonkey 2.49 Branch
defect

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.49

People

(Reporter: frg, Unassigned)

References

(Depends on 1 open bug, )

Details

User Story

Patches to uplift. 

Fresh out of the oven:
Bug 1388166 - Bug 1266836 introduced toolkit/browser dependency (breaks http auth on XUL apps) - follow up

Needed bugfixes:
Bug 546387 - Don't try to set the GTK clipboard with null items
Bug 1350152 - Don't rely on gBrowser in nsLoginManagerPrompter.js.
Bug 1368150 - Add functions to WindowsVersion for Windows 10 update
Bug 1361132 - TSFTextStore::GetSelection() shouldn't return if it runs on Win10 Anniversary Update or later.

Optional but without it you can't build 2.49.1/ESR52 with newer rust versions:
Bug 1338655 - mp4parse rust bindings no longer compile with cargo from Rust Nightly 2017-02-10

Uplisfts which were done in 2.48 and are also needed in 2.49.1:
Bug 1343781 - Ensure MozconfigLoader uses the right topsrcdir.
Bug 1345781 - Add quotes around the PACKAGE name in case there are spaces.

Taken from the TB 52 release branch. This takes care of the 2.48 OSX 10.12 crashes:

Bug 1322027 - Update jemalloc 4 to version 4.4.0.
Bug 1322027 - Don't disable hugepage support since it no longer causes PGO issues.
Bug 1311039 - Properly detect the default malloc zone on OSX 10.12.
Bug 1275204 - mozjemalloc: Use better pre-processor defines for sparc64.
Bug 1275204 - mozjemalloc: Use the JS arm64 allocator on Linux/sparc64.
Bug 1286613 - Properly call mozjemalloc pre/post fork hooks on OSX when replace-malloc is enabled.
Bug 1286613 - Move replace-malloc zone allocator to a separate file.
Bug 1286613 - Use the same zone allocator implementation as replace-malloc for mozjemalloc.
Bug 1286613 - Don't rely on OSX SDK malloc/malloc.h for malloc_zone struct definitions.
Bug 1286613 - Add dummy implementations for most remaining OSX zone allocator functions.
Bug 1286613 - Update jemalloc 4 to c6943ac.
Bug 1332508 - Reinitialize allocator mutexes in fork() child processes.

Attachments

(16 files, 3 obsolete files)

345 bytes, patch
iannbugzilla
: review+
ewong
: feedback-
Details | Diff | Splinter Review
89.40 KB, application/x-zip-compressed
iannbugzilla
: review+
iannbugzilla
: approval-comm-esr52+
Details
29.99 KB, patch
iannbugzilla
: review+
ewong
: review+
iannbugzilla
: approval-comm-esr52+
Details | Diff | Splinter Review
9.91 KB, patch
ewong
: review+
iannbugzilla
: approval-comm-esr52+
Details | Diff | Splinter Review
5.02 KB, patch
Details | Diff | Splinter Review
1.51 KB, patch
Details | Diff | Splinter Review
27.22 KB, patch
frg
: review+
Details | Diff | Splinter Review
5.70 KB, patch
Details | Diff | Splinter Review
1.83 KB, text/plain
Details
4.46 KB, patch
frg
: review+
Details | Diff | Splinter Review
1.32 KB, patch
Details | Diff | Splinter Review
2.65 KB, patch
frg
: review+
Details | Diff | Splinter Review
2.22 KB, patch
frg
: review+
Details | Diff | Splinter Review
1.03 KB, patch
frg
: review+
Details | Diff | Splinter Review
2.22 KB, patch
frg
: review+
Details | Diff | Splinter Review
349 bytes, patch
iannbugzilla
: review+
iannbugzilla
: approval-comm-esr52+
Details | Diff | Splinter Review
This bug tracks the needed changes to build SeaMonkey 2.49 from the ESR branch.
What I think is needed:

Adding tracking-seamonkey_2.49esr and status-seamonkey_2.49esr to bugzilla
Adding tracking-seamonkey_2.49esr and status-seamonkey_2.49esr to bugzilla
Adding approval‑comm‑esr52 to patch details

push doesn't work without closed tree in the push comment:

remote: ************************** ERROR ****************************
remote: Error accessing https://api.pub.build.mozilla.org/treestatus/trees/comm-esr52-seamonkey :
remote: HTTP Error 404: NOT FOUND
remote: Unable to check if the tree is open - treating as if CLOSED.
remote: To push regardless, include "CLOSED TREE" in your push comment.
remote: *************************************************************
Bug 1345661 is about disabled ALSA in FF 52 and is causing quite a ruckus. It should still be safe to enable it for SeaMonkey 2.49. I am not using Linux much currently and Pulseaudio basically works for me in a vm. Should we follow or enable ALSA in our build configs?
(In reply to Frank-Rainer Grahl from comment #2)
>I am not using
> Linux much currently and Pulseaudio basically works for me in a vm. Should
> we follow or enable ALSA in our build configs?
I do use Linux all the time and indeed use Pulseaudio, but dropping ALSA is a needless move that limits user choice and is not we're about. +1 to retain/enable.
As was stated yesterday in the Status Meeting, OpenSUSE builds with ALSA enabled. Thus, I've looked what their most recent build does, and it was indeed built with --enable-alsa. Since I have both PulseAudio and ALSA installed, it defaulted to "pulse" according to about:support, thus "alsa" is likely used as a fallback if "pulse" doesn't work (i.e., exactly what we want).

So yes, "enable ALSA in our build configs" please.
I checked this with ewong against the latest 2.48 candidate a few hours ago and default for pre 2.49 was to enable both according to config.status. The Firefox bug which disabled it changed Decoder Doctor for Firefox but I didn't see any changes in the functionality.

So --enable-alsa is indeed all what is needed for now. Tested with a local linux 2.52a1 build and the config.status entries with the enable option matched the ones form 2.48. Will put up a bug in the next days. Should be a simple mozconfig change for linux32 and linux64.
Depends on: 1345584
Depends on: 1358148
(In reply to Frank-Rainer Grahl from comment #1)
> What I think is needed:
> 
> Adding tracking-seamonkey_2.49esr and status-seamonkey_2.49esr to bugzilla
> Adding tracking-seamonkey_2.49esr and status-seamonkey_2.49esr to bugzilla
> Adding approval‑comm‑esr52 to patch details

I've filed that as bug 1358148 as we start needing at least the approval flag for landing patches already.
Firefox is now on version 52.1.1 in the second esr cycle. If we build SeaMonkey we should have the cycle in the version number and not just count the minor version up with every release. In theory it should be 2.49.1.0 for the first release in case an emergency release during the esr cycle is needed but I am not sure SeaMonkey ever used such a version number and not sure what it would mean for compatibility. So lets start small :)

[Approval Request Comment]
Regression caused by (bug #): --
User impact if declined: ramdom version
Testing completed (on m-c, etc.): comm-esr52
Risk to taking this patch (and alternatives if risky): none
String changes made by this patch: none
Attachment #8860601 - Flags: review?(iann_bugzilla)
Attachment #8860601 - Flags: feedback?(ewong)
Attachment #8860601 - Flags: approval-comm-release?
Comment on attachment 8860601 [details] [diff] [review]
1346939-esrversion.patch

r=me and a=me for esr
Attachment #8860601 - Flags: review?(iann_bugzilla)
Attachment #8860601 - Flags: review+
Attachment #8860601 - Flags: approval-comm-release?
Attachment #8860601 - Flags: approval-comm-release+
Depends on: 1353765
(In reply to rsx11m from comment #6)
> I've filed that as bug 1358148 as we start needing at least the approval
> flag for landing patches already.

Note that we have tracking-seamonkey2.49esr and status-seamonkey2.49esr now, which were moved over from tracking-seamonkey2.49 and status-seamonkey2.49 (thus retaining any pending requests).

Also, approval-comm-esr52 is now available on SeaMonkey bugs to request landing for 2.49.x.
Comment on attachment 8860601 [details] [diff] [review]
1346939-esrversion.patch

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

could we not include the security patches that firefox's .1 introduced to 2.49?   

Devil's advocate: sure, though it'll be confusing as to whether 2.49 is equivalent to Firefox's 52.0.1

::: suite/config/version.txt
@@ +1,1 @@
> +2.49.1

If we haven't actually released a 2.49,  I'm not sure there's
any reason in actually adding a .1 to the version #.  We can
still just use 2.49 for whatever csets we use, even if
TB and/or Firefox has a .1 which is only because they've
released the equivalent version and need a .1 to differentiate
the old version  (as well as to update the old version).

And since our update situation is so screwed up, I'm a bit 
hesitant in introducing an extra thing (though theoretically
speaking, it shouldn't matter..i.e. 2.46 ->  2.49esr shouldn't
be a problem).
> could we not include the security patches that firefox's .1 introduced to 2.49?   

If we start building we should build from comm-esr52 and mozilla-esr52 tip. Building might take longer anyway and it would to be great to at least have a really current release again. l10n should be static anyway.

> If we haven't actually released a 2.49,  I'm not sure there's
any reason in actually adding a .1 to the version #.

I would like to start with .1 Adrian released a community build of the regular 2.49 and it would show that this one is the latest version and also from esr.
Attached patch 1346939-l10n.patch (obsolete) — Splinter Review
Patch for comm-esr52 release branch only.
Attachment #8867527 - Flags: review?(iann_bugzilla)
Attachment #8867527 - Flags: review?(ewong)
Attachment #8867527 - Flags: approval-comm-esr52?
Comment on attachment 8867527 [details] [diff] [review]
1346939-l10n.patch

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

lgtm.
Attachment #8867527 - Flags: review?(ewong) → review+
Depends on: 1368277, 1364977
Comment on attachment 8867527 [details] [diff] [review]
1346939-l10n.patch

r/a=me
Attachment #8867527 - Flags: review?(iann_bugzilla)
Attachment #8867527 - Flags: review+
Attachment #8867527 - Flags: approval-comm-esr52?
Attachment #8867527 - Flags: approval-comm-esr52+
Comment on attachment 8860601 [details] [diff] [review]
1346939-esrversion.patch

On the record, I am not comfortable with giving it a .1 release
because in the past, we'd do a .1 release for chemspills and since
we haven't done a 2.49 release yet, it makes little sense in doing
2.49.1.

That said, I'm not blocking this.
Attachment #8860601 - Flags: feedback?(ewong) → feedback-
Bug 1361132 might need a release branch if uplift not granted.
Attached file 2491.zip (obsolete) —
Patches to uplift part 1. I put them into the user story to change them a little easier.
User Story: (updated)
User Story: (updated)
Summary: Tracking bug for build and release of SeaMonkey 2.49 from ESR branch → Tracking bug for build and release of SeaMonkey 2.49.1 from ESR branch
All the patches which need uplifting. Rebased and tested. This needs to go into a mozilla-esr52 SeaMonkey release branch.

The 3x.patches are from the TB release branch and need to be applied in the order of a to l.

There are no 1 and 2 because they are no longer needed (different bugs which were resolved in the meantime).
Attachment #8894208 - Attachment is obsolete: true
Attachment #8894216 - Flags: review?(iann_bugzilla)
Attachment #8894216 - Flags: approval-comm-esr52?
Yes, I recognise the 3x patches.

Does TB need bug 546387, bug 1338655, bug 1361132 or bug 1368150? I know we need bug 1350152.

Why don't we use a common release branch? Do you already have one?
> bug 546387

Won't hurt. Problems with clipboard.

> bug 1338655

No, only for local complies with enable-rust and MOZ_RUST_MP4PARSE=1

> bug 1361132 or bug 1368150?

Seems to cause crashes in Fx with Windows 10 Creators update. Might be touch related. I am better safe than sorry for SeaMonkey. Maybe you can look at the TB 52 crash stats.

> Why don't we use a common release branch?

Nothing against it at least for mozilla-esr52. Would avoid duplicate work. I am not seeing an Fx 52.3 release tag yet. Current cset is 92fc2e2c0d7 but we should probably wait. Will ask IanN during the status meeting.
Depends on: 1352820
Depends on: SM2491-RELNOTE
1.) General Config patch. Minor cleanups

2.) Fx enabled the Rust components for ESR 52. mp4parse is no longer valid and default in c-c. urlparse is fenced now behind nightly because of some additional changes but tthe changes here are exactly the same as in ESR 52. 

3.) api key enablement for 2.49.1

Let me know if you prefere separate changes.

If approved I will rebase the l10n removal patch which should go into the build branch and not default branch only.
Attachment #8894527 - Flags: review?(iann_bugzilla)
Attachment #8894527 - Flags: review?(ewong)
Comment on attachment 8894527 [details] [diff] [review]
1346939-configs.patch

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

lgtm..

just wondering about rustc 1.19.0 vs. 1.13.0

::: suite/config/tooltool-manifests/linux32/releng.manifest
@@ +15,5 @@
>  "setup": "setup.sh",
>  "unpack": true
>  },
>  {
> +"version": "rustc 1.13.0 (2c6933acc 2016-11-07) repack x86_64+i586",

ditto

::: suite/config/tooltool-manifests/linux64/releng.manifest
@@ +15,5 @@
>  "setup": "setup.sh",
>  "unpack": true
>  },
>  {
> +"version": "rustc 1.13.0 (2c6933acc 2016-11-07) repack",

I haven't build from 2.49.1; but, would using 1.19.0 work? 
If so, I would suggest just using 1.19.0 since this is what 
we're using on trunk.

::: suite/config/tooltool-manifests/macosx64/releng.manifest
@@ +7,5 @@
>  "filename": "clang.tar.bz2",
>  "unpack": true
>  },
>  {
> +"version": "rustc 1.13.0 (2c6933acc 2016-11-07) repack",

ditto

::: suite/config/tooltool-manifests/win32/releng.manifest
@@ +5,5 @@
>  "algorithm": "sha512",
>  "filename": "mozmake.exe"
>  },
>  {
> +"version": "rustc 1.13.0 (2c6933acc 2016-11-07) repack",

ditto
Attachment #8894527 - Flags: review?(ewong) → review+
> just wondering about rustc 1.19.0 vs. 1.13.0

That version is what Mozilla currently uses for ESR52. See
\mozilla\browser\config\tooltool-manifests\linux32\releng.manifest
for an example.

We could probably use 1.19 but then we would need the fix for Bug 1338655 from my release branch patches zip for sure. While my local build done with 1.19 works great I would personally stick with the Mozilla version for official releases.
User Story: (updated)
User Story: (updated)
(In reply to Jorg K (GMT+2) from comment #20)
> I know we need bug 1350152.
... and also follow-up bug 1388166.
> ... and also follow-up bug 1388166.

See user story. Updated yesterday :)

Did put it in my local 2.49.1 and works fine.
Comment on attachment 8894527 [details] [diff] [review]
1346939-configs.patch

LGTM r=me
Attachment #8894527 - Flags: review?(iann_bugzilla) → review+
Comment on attachment 8894216 [details]
zip of mc-bugs which needs uplifting

Not sure if an r/a=me is still needed
I think it was agreed to have a common m-esr52 branch with TB
Attachment #8894216 - Flags: review?(iann_bugzilla)
Attachment #8894216 - Flags: review+
Attachment #8894216 - Flags: approval-comm-esr52?
Attachment #8894216 - Flags: approval-comm-esr52+
Landed on THUNDERBIRD_52_VERBRANCH:

https://hg.mozilla.org/releases/mozilla-esr52/rev/d13e3fefb76ea8a030579965d3c84e04649226fc
https://hg.mozilla.org/releases/mozilla-esr52/rev/f822bda79c28da0ad93b67d46abcb66f6d5c8c92
https://hg.mozilla.org/releases/mozilla-esr52/rev/fbb0bdb191d5e2d044ca00615d8c3ad3af7a0ab6
https://hg.mozilla.org/releases/mozilla-esr52/rev/fdbd6734448b56e8fec5917cfae3bb1c45342aa2
https://hg.mozilla.org/releases/mozilla-esr52/rev/459150ea79f6be75c0228450b2ae15c28b5fbe1b
https://hg.mozilla.org/releases/mozilla-esr52/rev/21af4e17cbf9f225e99c4103ac73a72311a702d1

21af4e17cbf9 Ralph Giles — Bug 1338655 - Don't try to build mp4parse bindings. r=froydnj a=jorgk DONTBUILD 
459150ea79f6 Masayuki Nakano — Bug 1361132 - TSFTextStore::GetSelection() shouldn't return ...
fdbd6734448b Aaron Klotz — Bug 1368150: Add IsWindows10BuildOrNewer to MFBT; r=froydnj a=jorgk 
fbb0bdb191d5 Jorg K — Bug 1388166 - Handle case where chromeWin.getBrowser() doesn't exist. r=johannh a=jorgk 
f822bda79c28 Johann Hofmann — Bug 1350152 - Don't rely on gBrowser in nsLoginManagerPrompter.js. r=mkaply a=jorgk 
d13e3fefb76e Chris H-C — bug 546387 - Don't try to set the GTK clipboard with null items r=karlt a=jorgk
Comment on attachment 8894527 [details] [diff] [review]
1346939-configs.patch

Upps forgot to formally ask for approval. But its a config patch only for 2.49.1 so I assume IanN is ok with it :)
Attachment #8894527 - Flags: approval-comm-esr52?
Comment on attachment 8867527 [details] [diff] [review]
1346939-l10n.patch

ewong,

I was just about to create a release branch and push this patch when I noticed an 

+ac_add_options --enable-alsa in the linux32/release-l10n.

Is the compile environment enabled for l10n builds? TB disables it. If yes, the base l10n configs would also need the api key included.
Flags: needinfo?(ewong)
Comment on attachment 8894527 [details] [diff] [review]
1346939-configs.patch

a=me
Attachment #8894527 - Flags: approval-comm-esr52? → approval-comm-esr52+
Comment on attachment 8867527 [details] [diff] [review]
1346939-l10n.patch

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

lgtm.

::: suite/config/mozconfigs/linux32/release-l10n
@@ +1,1 @@
>  no_tooltool=1

this line needs to go.
Another round of config patches for l10n. Minor reshuffling of options to align them too.

I am not so sure about some changes and if including rust is even needed. The current configs are inconsistent. Sometimes the compile environment is pulled in for l10n and sometimes not. Win64 could never have worked without l10n base but this is only used for reference here becaause we are not building it for 2.49.1

I will rebase the l10n calendar removal patch for the release branch after this one gets approved.

comm-central is probably also affected but l10n there needs an overhaul anyway so only for esr52.
Flags: needinfo?(ewong)
Attachment #8898730 - Flags: review?(ewong)
Attachment #8898730 - Flags: approval-comm-esr52?
I just triggered a normal ESR Linux32 build and hit a snag with the regular mozconfig line:

. "$topsrcdir/suite/config/mozconfigs/mozconfig.linux.commmon

The problem I found was that $topsrcdir referred to <main builddir>/mozilla, which
would make <main builddir>/mozilla/suite/config/mozconfigs/mozconfig.linux.common
to be a bad path.

I am getting the idea that in order to avoid this topsrcdir mess, I'm suggesting we
we replace all $topsrcdir with $TOOLTOOL_DIR.  (Apparently this is a change
in mozconfig.rust and it was the same thing with the GTK mozconfig as well).
This way, we can set up TOOLTOOL_DIR in the env. to point to our topsrcdir.

IanN, frg, sound good?
Flags: needinfo?(iann_bugzilla)
Flags: needinfo?(frgrahl)
Sounds like Bug 1343781. Can this be?
Flags: needinfo?(frgrahl)
Not in the release branch so this is where my money would be.
Bug 1345781 may apply too.
(In reply to Frank-Rainer Grahl (:frg) from comment #37)
> Sounds like Bug 1343781. Can this be?

That looks like a possible candidate.
User Story: (updated)
Jorg, could Bug 1343781 and Bug 1345781 go into the TB release branch or should we spilt our own from it?
Flags: needinfo?(jorgk)
Flags: needinfo?(iann_bugzilla)
This one had approval for release but never made it into comm-esr52:

https://hg.mozilla.org/releases/comm-esr52/rev/9548c12d6c7e6f13ffb7dc9fa14f927364f44f2e
(In reply to Frank-Rainer Grahl (:frg) from comment #41)
> Jorg, could Bug 1343781 and Bug 1345781 go into the TB release branch or
> should we spilt our own from it?
We can do that. I looked at bug 1345781 and according to the comments, nothing ever got landed there.
You promise that those patches won't break out builds? Who does the landing? You want me to do it?

(In reply to Frank-Rainer Grahl (:frg) from comment #43)
> This one had approval for release but never made it into comm-esr52:
> https://hg.mozilla.org/releases/comm-esr52/rev/
> 9548c12d6c7e6f13ffb7dc9fa14f927364f44f2e
Not my fault, or did you expect me to push it? It's a suite/ patch in a SM bug.
Flags: needinfo?(jorgk)
> You promise that those patches won't break out builds? Who does the landing? You want me to do it?

They were in the 2.48 release branch. Bug 1343781 should not break TB because it is in 55+

Not so sure about the other one but if it breaks something it can and should just be backed out no questions asked. ewong what do you think about bug 1345781?

> Not my fault, or did you expect me to push it? It's a suite/ patch in a SM bug.

No. Just noticed it when checking the 2.48 comm-central and mozilla-central release branches for other missing patches.
Flags: needinfo?(ewong)
How did you manage to get two bug numbers that differ by a digit :-(
> How did you manage to get two bug numbers that differ by a digit :-(

magic (which got me very very confused first too till I looked closer)
Translations for nb-NO have been updated for 2.49.1 in bug 1391174. We need to put them into an l10n release branch.
Depends on: 1391174
(In reply to Frank-Rainer Grahl (:frg) from comment #45)
> > You promise that those patches won't break out builds? Who does the landing? You want me to do it?
> 
> They were in the 2.48 release branch. Bug 1343781 should not break TB
> because it is in 55+
> 
> Not so sure about the other one but if it breaks something it can and should
> just be backed out no questions asked. ewong what do you think about bug
> 1345781?
> 
> > Not my fault, or did you expect me to push it? It's a suite/ patch in a SM bug.
> 
> No. Just noticed it when checking the 2.48 comm-central and mozilla-central
> release branches for other missing patches.

ftr,  the patches mentioned in those bugs were not pushed to m-b/r proper.  They
were pushed to a SeaMonkey release relbranch and so will need to be transplanted
to the relbranch for 2.49.1
Flags: needinfo?(ewong)
Comment on attachment 8899840 [details] [diff] [review]
Bug 1343781 rebased for mozilla-esr52

Jorg,

I think the risk for TB is low. If you think too could you check Bug 1343781 and Bug 1345781 in. If it breaks something just back it out and as stated we will put it in a relbranch. 

If you won't want to risk it I am fine with it too and will just do a relbranch now.

Thanks
Attachment #8899840 - Flags: feedback?(jorgk)
Comment on attachment 8899840 [details] [diff] [review]
Bug 1343781 rebased for mozilla-esr52

I'll land those two patches tonight. We have daily builds on comm-esr52, so we can see if things don't work.
Attachment #8899840 - Flags: feedback?(jorgk)
(In reply to Jorg K (GMT+2) from comment #52)
> https://hg.mozilla.org/releases/mozilla-esr52/rev/
> 1573a67310ccd1082e7dec4fe50c2c639b00aca3
> https://hg.mozilla.org/releases/mozilla-esr52/rev/
> d148777380bddd8965a19204fa0b83ecfc89f3d5
> Fingers crossed ;-)

I just realized that while release can be made to use the relbranch, what about mozilla-esr52 proper?
In order for SM to build, these two patches also need to be pushed to mozilla-esr52 proper since
regular esr52 builds are done with the default tree.
Comment on attachment 8899841 [details] [diff] [review]
Bug 1345781 rebased for mozilla-esr52

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  without this and the other esr52 rebased patch, SM-esr won't be able to build 
  on default tree.   While we've rebased and transplanted to the mozilla-esr52
  relbranch (for release), for normal esr builds, this is needed.
User impact if declined: no normal esr52 builds that depend on the 
 mozilla-esr52 default tree
Fix Landed on Version: 51 relbranch on mozilla-release
Risk to taking this patch (and alternatives if risky): none that is known.
String or UUID changes made by this patch:  None

:Sylvestre, any chance this can be pushed to ESR52 default tree?

Thanks


See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Flags: needinfo?(sledru)
Attachment #8899841 - Flags: approval-mozilla-esr52?
(In reply to Edmund Wong (:ewong) from comment #53)
> In order for SM to build, these two patches also need to be pushed to
> mozilla-esr52 proper since
> regular esr52 builds are done with the default tree.
Really? We always build against the release branch:
https://hg.mozilla.org/releases/comm-esr52/rev/e11dc97f123715331dfabc3338ee9a0b8750a0ac
Comment on attachment 8898730 [details] [diff] [review]
1346939-configs2.patch

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

I just triggered a normal ESR Linux32 build and hit a snag with the regular mozconfig line:

. "$topsrcdir/suite/config/mozconfigs/mozconfig.linux.commmon

The problem I found was that $topsrcdir referred to <main builddir>/mozilla, which
would make <main builddir>/mozilla/suite/config/mozconfigs/mozconfig.linux.common
to be a bad path.

::: suite/config/mozconfigs/win32/release
@@ +1,3 @@
>  . "$topsrcdir/build/mozconfig.win-common"
>  . "$topsrcdir/build/mozconfig.common"
>  . "$topsrcdir/suite/config/mozconfigs/mozconfig.win.common"

assuming we can push the mozilla-esr52 patches to the default tree (as opposed to the relbranch, which are already there),
this will work regardless of whether we use default/relbranch
to build our normal ESR52 builds.

If we can't push those, then we'll need to either:

1) change these topsrcdir mentions to using the following:
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}

  and replace the $topsrcdir  with $TOOLTOOL_DIR.

2) change client.py to use the relbranch for mozilla-esr52
instead of default.

Since keeping ourselves appraised of the status of ESR52
proper, having the two patches pushed to the default
branch would be preferential.  If not approved, we'll need
to 'fudge' it to enable us to use the default branch
for normal builds.
What will be the impact for firefox build?
Flags: needinfo?(sledru)
Can someone please answer my question from comment #55:
Why does SM not always build against the release branch like Thunderbird?
ewong. They are marked as fixed for Fx 55+. I see no need to push them to the default branch for esr52. We need to build all 2.49.x releases from the shared TB branch because of other fixes which will not be uplifted too. It is kept up to date by merging the default branch for a release.
ewong or do you mean bug 1345781 which as far as I see it hasn't been checked into mozilla-central? If yes would need to discuss it in this bug.
Flags: needinfo?(ewong)
Comment on attachment 8899841 [details] [diff] [review]
Bug 1345781 rebased for mozilla-esr52

sounds like this change should be kept on the SM relbranch unless/until it's needed for firefox
Attachment #8899841 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
(In reply to Frank-Rainer Grahl (:frg) from comment #60)
> ewong or do you mean bug 1345781 which as far as I see it hasn't been
> checked into mozilla-central? If yes would need to discuss it in this bug.

I was talking about bug 1345781 and the other one.

Since this is all moot, I'll just figure a way to build ESR52 off the relbranch.
Flags: needinfo?(ewong)
(In reply to Jorg K (GMT+2) from comment #55)
> (In reply to Edmund Wong (:ewong) from comment #53)
> > In order for SM to build, these two patches also need to be pushed to
> > mozilla-esr52 proper since
> > regular esr52 builds are done with the default tree.
> Really? We always build against the release branch:
> https://hg.mozilla.org/releases/comm-esr52/rev/
> e11dc97f123715331dfabc3338ee9a0b8750a0ac

SM doesn't use the client.py-args file.
Comment on attachment 8898730 [details] [diff] [review]
1346939-configs2.patch

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

I just triggered a normal ESR Linux32 build and hit a snag with the regular mozconfig line:

. "$topsrcdir/suite/config/mozconfigs/mozconfig.linux.commmon

The problem I found was that $topsrcdir referred to <main builddir>/mozilla, which
would make <main builddir>/mozilla/suite/config/mozconfigs/mozconfig.linux.common
to be a bad path.

::: suite/config/mozconfigs/win32/release
@@ +1,3 @@
>  . "$topsrcdir/build/mozconfig.win-common"
>  . "$topsrcdir/build/mozconfig.common"
>  . "$topsrcdir/suite/config/mozconfigs/mozconfig.win.common"

assuming we can push the mozilla-esr52 patches to the default tree (as opposed to the relbranch, which are already there),
this will work regardless of whether we use default/relbranch
to build our normal ESR52 builds.

If we can't push those, then we'll need to either:

1) change these topsrcdir mentions to using the following:
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}

  and replace the $topsrcdir  with $TOOLTOOL_DIR.

2) change client.py to use the relbranch for mozilla-esr52
instead of default.

Since keeping ourselves appraised of the status of ESR52
proper, having the two patches pushed to the default
branch would be preferential.  If not approved, we'll need
to 'fudge' it to enable us to use the default branch
for normal builds.
Attachment #8898730 - Flags: review?(ewong) → review+
(In reply to Edmund Wong (:ewong) from comment #64)
> Comment on attachment 8898730 [details] [diff] [review]
> 1346939-configs2.patch
> 
> Review of attachment 8898730 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I just triggered a normal ESR Linux32 build and hit a snag with the regular
> mozconfig line:
> 
> . "$topsrcdir/suite/config/mozconfigs/mozconfig.linux.commmon
> 
> The problem I found was that $topsrcdir referred to <main builddir>/mozilla,
> which
> would make <main
> builddir>/mozilla/suite/config/mozconfigs/mozconfig.linux.common
> to be a bad path.
> 
> ::: suite/config/mozconfigs/win32/release
> @@ +1,3 @@
> >  . "$topsrcdir/build/mozconfig.win-common"
> >  . "$topsrcdir/build/mozconfig.common"
> >  . "$topsrcdir/suite/config/mozconfigs/mozconfig.win.common"
> 
> assuming we can push the mozilla-esr52 patches to the default tree (as
> opposed to the relbranch, which are already there),
> this will work regardless of whether we use default/relbranch
> to build our normal ESR52 builds.
> 
> If we can't push those, then we'll need to either:
> 
> 1) change these topsrcdir mentions to using the following:
> TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
> 
>   and replace the $topsrcdir  with $TOOLTOOL_DIR.
> 
> 2) change client.py to use the relbranch for mozilla-esr52
> instead of default.
> 
> Since keeping ourselves appraised of the status of ESR52
> proper, having the two patches pushed to the default
> branch would be preferential.  If not approved, we'll need
> to 'fudge' it to enable us to use the default branch
> for normal builds.

please ignore the above..  it saved the stuff before ..  ;/
Comment on attachment 8898730 [details] [diff] [review]
1346939-configs2.patch

a=me
Attachment #8898730 - Flags: approval-comm-esr52? → approval-comm-esr52+
Created SEAMONKEY_2_49_ESR_RELBRANCH in comm-esr52. 

Checked nb-NO locale enable into comm-esr52 SEAMONKEY_2_49_ESR_RELBRANCH only:

https://hg.mozilla.org/releases/comm-esr52/rev/595a41106f75d9e2950efd0d2c83de191cfb4665

See bug 1391174
Rebased l10n-config change. Checked into SEAMONKEY_2_49_ESR_RELBRANCH only:

https://hg.mozilla.org/releases/comm-esr52/rev/6348c46e3613a99b8cf555eeef8229e19d19d8f7

r+ a+ from IanN retained.
Attachment #8867527 - Attachment is obsolete: true
Attachment #8903210 - Flags: review+
Attached patch 1320570-pl.patchSplinter Review
Could someone check this into l10n pl. I don't have the rights. The patch is currently in an obsolete TB branch and need to go into a new SEAMONKEY_2_49_ESR_RELBRANCH branch. The branch needs to be created on top of changeset 9659 (42ea1da43a3b) "Migrating aurora to beta for Firefox 52".
Attached file changeset.txt (obsolete) —
Changesets for building. l10n nb-NO and pl not final yet.
(In reply to Frank-Rainer Grahl (:frg) from comment #70)
> Created attachment 8903219 [details] [diff] [review]
> 1320570-pl.patch
> 
> Could someone check this into l10n pl. I don't have the rights. The patch is
> currently in an obsolete TB branch and need to go into a new
> SEAMONKEY_2_49_ESR_RELBRANCH branch. The branch needs to be created on top
> of changeset 9659 (42ea1da43a3b) "Migrating aurora to beta for Firefox 52".

https://hg.mozilla.org/releases/l10n/mozilla-release/pl/rev/4ae63b7fd7bc4b777aea266c8bb98716b67c959b
Attached file changeset.txt
ewong the final csets for 2.49.1
Attachment #8903225 - Attachment is obsolete: true
Flags: needinfo?(ewong)
(In reply to Frank-Rainer Grahl (:frg) from comment #73)
> Created attachment 8906362 [details]
> changeset.txt
> 
> ewong the final csets for 2.49.1

lgtm..  will set up the configs.
Flags: needinfo?(ewong)
IanN,  all those other locales also need the SEAMONKEY_2_49_ESR_RELBRANCH done as it's an all-or-nothing
type of deal with the relbranch (iow: either all of them have relbranches, or they all don't.)

I can figure out how to get it such that they use different relbranch names, but I'll need to
go through the custom code and change it to allow us to specify relbranches.
Flags: needinfo?(iann_bugzilla)
Comment on attachment 8909210 [details] [diff] [review]
[configs] update configs for 2.49.1 ESR

Great let the fun begin :)

NIT:

+release-comm-esr.py
\ No newline at end of file

Shouldn't this one get an LF finally?
Attachment #8909210 - Flags: review?(frgrahl) → review+
(In reply to Frank-Rainer Grahl (:frg) from comment #77)
> Comment on attachment 8909210 [details] [diff] [review]
> [configs] update configs for 2.49.1 ESR
> 
> Great let the fun begin :)
> 
> NIT:
> 
> +release-comm-esr.py
> \ No newline at end of file
> 
> Shouldn't this one get an LF finally?

no.. because it's supposed to be a linked file.. having a LF will screw things up.
Depends on: 1400790
(In reply to Edmund Wong (:ewong) from comment #75)
> IanN,  all those other locales also need the SEAMONKEY_2_49_ESR_RELBRANCH
> done as it's an all-or-nothing
> type of deal with the relbranch (iow: either all of them have relbranches,
> or they all don't.)
> 
> I can figure out how to get it such that they use different relbranch names,
> but I'll need to
> go through the custom code and change it to allow us to specify relbranches.

Cancelling NI as you appear to have a solution.
Flags: needinfo?(iann_bugzilla)
releases/l10n/mozilla-esr52 doesn't exist.
I or better Mc checked the first candidate build and it looks like we have a problem with Lightning. 5.4 does not work and falls apart pretty fast when you install it. Bug 1318258 linked the backend into libxul and without enable-calendar this isn't done. Lets continue with the build but it will need a new source change for sure. I have an idea :) 

Also I can reproduce the missing dropmarker with gtk3 now with the default theme. It still seems to be there but is 1 pixel wide. Mc still has it so it is sitll system/theme/distribution dependent.

Btw. the tinderbox builds work here because they still enable-calendar.
(In reply to Frank-Rainer Grahl (:frg) from comment #81)
> I or better Mc checked the first candidate build and it looks like we have a
> problem with Lightning. 5.4 does not work and falls apart pretty fast when
> you install it. Bug 1318258 linked the backend into libxul and without
> enable-calendar this isn't done. Lets continue with the build but it will
> need a new source change for sure. I have an idea :) 
> 
> Also I can reproduce the missing dropmarker with gtk3 now with the default
> theme. It still seems to be there but is 1 pixel wide. Mc still has it so it
> is sitll system/theme/distribution dependent.
> 
> Btw. the tinderbox builds work here because they still enable-calendar.

well the first candidate, while building on Linux, isn't building on OSX64.
I have no clue as to why the same step works on Linux but fails with the
following error:

/usr/local/bin/hg update --clean --repository build --rev default
 in dir /builds/slave/rel-c-esr-osx64-bld (timeout 3600 secs)
 watching logfiles {}
 argv: ['/usr/local/bin/hg', 'update', '--clean', '--repository', 'build', '--rev', 'default']
 environment:
  Apple_PubSub_Socket_Render=/tmp/launch-OreJEj/Render
  Apple_Ubiquity_Message=/tmp/launch-1yWJHi/Apple_Ubiquity_Message
  CVS_RSH=ssh
  DISPLAY=/tmp/launch-YdrmXS/org.x:0
  HOME=/Users/seabld
  LOGNAME=seabld
  PATH=/tools/buildbot/bin:/tools/python/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
  PWD=/builds/slave/rel-c-esr-osx64-bld
  PYTHONPATH=/tools/buildbot/lib/python2.7/site-packages
  SHELL=/bin/bash
  SSH_AUTH_SOCK=/tmp/launch-zRAmzQ/Listeners
  TMPDIR=/var/folders/bm/kc_3cyjj2v15yn2741pj8s6r0000gn/T/
  USER=seabld
  VERSIONER_PYTHON_PREFER_32_BIT=no
  VERSIONER_PYTHON_VERSION=2.7
  __CF_USER_TEXT_ENCODING=0x1F5:0:0
 using PTY: False
abort: Invalid argument: '/builds/slave/rel-c-esr-osx64-bld/build/mail/themes/windows/mail/addrbook/addrbook-XP.png'
elapsedTime=4.060505
program finished with exit code 255
Depends on: 1401452
Depends on: 1402645
comm-esr52 releasebranch merged with default for next build:

https://hg.mozilla.org/releases/comm-esr52/rev/a673ebc149c595eaaa1eb24f85d6bce401cbce99
ewong, 2.49.1 building can continue. The new tags are:

comm-esr52 SEAMONKEY_2_49_ESR_RELBRANCH
a673ebc149c5 merge default to SEAMONKEY_2_49_ESR_RELBRANCH.

mozilla THUNDERBIRD_52_VERBRANCH 
cce71d51e710 Merge .hgtags file manually to include SM tags.

knock on wood.
Flags: needinfo?(ewong)
Flags: needinfo?(ewong)
Attachment #8914606 - Flags: review?(frgrahl)
Comment on attachment 8914606 [details] [diff] [review]
[configs] update configs for 2.49.1. ESR build 2

thanks
Attachment #8914606 - Flags: review?(frgrahl) → review+
Depends on: 1406246
Depends on: 1406250
going to go for a post-land-review
Attachment #8916466 - Flags: review?(frgrahl)
Comment on attachment 8916466 [details] [diff] [review]
[configs] update configs for build 3

Looks good thanks
Attachment #8916466 - Flags: review?(frgrahl) → review+
Depends on: 1407907
this patch will also need to be modified for the c-b part as well.
Attachment #8918070 - Flags: review?(frgrahl)
Comment on attachment 8918070 [details] [diff] [review]
patch to fix the update channel info

r+. I think the other products do this dynamically at build time or we would need to do this during/after each merge. Will look if I find something.
Attachment #8918070 - Flags: review?(frgrahl) → review+
Attachment #8918717 - Flags: review?(frgrahl)
Comment on attachment 8918717 [details] [diff] [review]
[configs] build 4 configs.

looks good
Attachment #8918717 - Flags: review?(frgrahl) → review+
ftr, I had to push a bunch of patches (well...  two really):

https://hg.mozilla.org/users/Callek_gmail.com/tools/rev/953920480530
https://hg.mozilla.org/users/Callek_gmail.com/tools/rev/30ab40b6fcca

The last one is what probably fixed it.  The first one was to unhork whatever
future c-r release we do.
Depends on: 1385794
And the hopfully final 2.49.1 piece. Upgrade version number for the next version.
Attachment #8920860 - Flags: review?(iann_bugzilla)
Attachment #8920860 - Flags: approval-comm-esr52?
Comment on attachment 8920860 [details] [diff] [review]
1346939-2492.patch

r/a=me for when required
Attachment #8920860 - Flags: review?(iann_bugzilla)
Attachment #8920860 - Flags: review+
Attachment #8920860 - Flags: approval-comm-esr52?
Attachment #8920860 - Flags: approval-comm-esr52+
Current final verification bustage:

 Connection: close
  Content-Type: text/xml;
Length: 861 [text/xml]
Saving to: ‘update.xml’

     0K                                                       100% 31.5M=0s

2017-11-01 02:04:10 (31.5 MB/s) - ‘update.xml’ saved [861/861]

Got this response:
<?xml version="1.0"?>
<updates>
    <update type="minor" version="2.49.1" extensionVersion="2.49.1" buildID="20171015235838" detailsURL="http://www.seamonkey-project.org/releases/seamonkey2.49.1/">
        <patch type="complete" URL="http://download.mozilla.org/?product=seamonkey-2.49.1-complete&amp;os=linux&amp;lang=cs&amp;force=1" hashFunction="SHA512" hashValue="f8d0a29f0994517f498dbd15c6c3b09c1d1bbdef92049f9cd09067b239958d453c110e9ea91136d895f3b6f8b7924b6d2a0e91c9c85bc1e0cf32bc38a2634b99" size="51996560"/>
        <patch type="partial" URL="http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&amp;os=linux&amp;lang=cs&amp;force=1" hashFunction="SHA512" hashValue="93bef372ba315e8e10328432cee82a2067b60d19f25d1d055c37bf6b729a72f96df50dc01c474f44f98d4733d248cece9756356663cb859246aaeece81555aab" size="28106882"/>
    </update>
</updates>

Testing http://download.mozilla.org/?product=seamonkey-2.49.1-partial-2.48&os=linux&lang=cs&force=1
HTTP/1.1 404 Not Found
Content-Length: 19
Content-Type: text/plain; charset=utf-8
Date: Wed, 01 Nov 2017 08:51:30 GMT
X-Content-Type-Options: nosniff
Connection: keep-alive
Depends on: 1414601
Closed as agreed in todays meeting.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.49
Blocks: 1389181
You need to log in before you can comment on or make changes to this bug.