Bug 1346939 (SeaMonkey2.49ESR)

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

NEW
Unassigned

Status

SeaMonkey
Release Engineering
P1
blocker
3 months ago
7 hours ago

People

(Reporter: frg, Unassigned)

Tracking

(Depends on: 2 bugs)

SeaMonkey 2.49 Branch
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.49esr?)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

3 months ago
This bug tracks the needed changes to build SeaMonkey 2.49 from the ESR branch.
(Reporter)

Comment 1

3 months ago
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: *************************************************************
(Reporter)

Comment 2

3 months ago
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?

Comment 3

2 months ago
(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.

Comment 4

2 months ago
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.
(Reporter)

Comment 5

2 months ago
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.
(Reporter)

Updated

2 months ago
Depends on: 1345584

Updated

a month ago
Depends on: 1358148

Comment 6

a month ago
(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.
(Reporter)

Comment 7

a month ago
Created attachment 8860601 [details] [diff] [review]
1346939-esrversion.patch

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 8

a month ago
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+
(Reporter)

Updated

a month ago
Depends on: 1353765
(Reporter)

Comment 9

a month ago
1346939-esrversion.patch:
https://hg.mozilla.org/releases/comm-esr52/rev/2704ca6d39279a0f844e7f17df7c6276f1b3a5b3

Comment 10

26 days ago
(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).
(Reporter)

Comment 12

19 days ago
> 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.
(Reporter)

Comment 13

14 days ago
Created attachment 8867527 [details] [diff] [review]
1346939-l10n.patch

Patch for comm-esr52 release branch only.
Attachment #8867527 - Flags: review?(iann_bugzilla)
Attachment #8867527 - Flags: review?(ewong)
(Reporter)

Updated

14 days ago
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+
(Reporter)

Updated

13 hours ago
Depends on: 1368277, 1364977
You need to log in before you can comment on or make changes to this bug.