Bug 1171347

Summary: Re-enable SeaMonkey builds
Product: [openSUSE] openSUSE Tumbleweed Reporter: Tristan Miller <psychonaut>
Component: FirefoxAssignee: Wolfgang Rosenauer <wolfgang>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: wolfgang
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://build.opensuse.org/package/show/mozilla/seamonkey
See Also: http://bugzilla.opensuse.org/show_bug.cgi?id=1171414
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: SeaMonkey 2.53.1 build log from build.opensuse.org

Description Tristan Miller 2020-05-07 09:46:56 UTC
Recent versions of SeaMonkey are not available for Leap and Tumbleweed because the project at <https://build.opensuse.org/package/show/mozilla/seamonkey> has its builds disabled.  Per my request at <https://build.opensuse.org/request/show/788220#comment-1190164>, could the builds please be re-enabled?  I've been using 2.53.1 for about a month now and haven't encountered any problems.
Comment 1 Wolfgang Rosenauer 2020-05-07 09:58:21 UTC
The builds were enabled for some time.
I disable the huge builds for Firefox, Thunderbird, SeaMonkey in general to not build and provide updates when some underlying dependency changed (to save OBS resources and avoid unneeded updates).

The problem is that Seamonkey does not build correctly for Tumbleweed and that is the reason why this repo still has the old version.
You mention that Leap packages are not available. I just checked and this is not true. Just 42.3 and TW are missing the latest version because both do not build ATM.

I've reenabled just Tumbleweed now but do not expect any change.

So the subject "Re-enable Seamonkey builds" is invalid because I will keep them disabled until something changes always.

The report that 2.53.1 is not available for TW: That is true but enabling the build will not change it.
Comment 2 Tristan Miller 2020-05-07 10:17:02 UTC
That is strange; 2.53.1 for both Leap and Tumbleweed were building on x86_64 at the time I submitted (and at the time you accepted) the merge from my home project.  I've rebranched the project and will investigate.
Comment 3 Tristan Miller 2020-05-07 11:16:33 UTC
Created attachment 837533 [details]
SeaMonkey 2.53.1 build log from build.opensuse.org

I've verified that the Tumbleweed x86_64 build on the openSUSE Build Service now fails when building on the server.  However, when I use osc to build it on my local machine, everything works fine.

I am attaching the server build log.  The part where it fails is probably this line near the end:

[  778s] lto1: fatal error: streaming subprocess was killed by signal

Is it possible that the server is killing this process for maxing out the CPU for too long?  (My own machine grinds to a halt for nearly a minute near the end of the build; even my mouse and keyboard stop responding.)  Is there anything we can do about this?
Comment 4 Wolfgang Rosenauer 2020-05-07 11:34:15 UTC
Good question. I am also struggling with Firefox builds once in a while because of the huge resources required. (I even typically cannot even build FF locally anymore as it's kills my machine until unrecoverable.)

So to summarize: I have no idea :-( Obviously TW changes and builds might start failing for whatever reason. But if it works for you locally that is again a different thing.
Wondering if disabling LTO would change anything since it seems to fail somewhere around this?
Comment 5 Tristan Miller 2020-05-07 13:57:03 UTC
(In reply to Wolfgang Rosenauer from comment #4)
> Wondering if disabling LTO would change anything since it seems to fail
> somewhere around this?

I'm not aware of any easy way of disabling LTO -- are you?  There doesn't seem to be a --disable-lto option to take care of everything.  Building with --disable-optimize doesn't get very far.  And using --disable-release (which is supposed to disable all optimizations) just throws up errors about MOZILLA_OFFICIAL being enabled, even if I comment it out of the mozconfig.
Comment 6 Wolfgang Rosenauer 2020-05-08 08:31:17 UTC
In Firefox we explicitely have:
# LTO needs newer toolchain stack only (at least GCC 8.2.1 (r268506)
%if 0%{?suse_version} > 1500
ac_add_options --enable-lto
%if 0%{?do_profiling}
ac_add_options MOZ_PGO=1
%endif
%endif
Comment 7 Tristan Miller 2020-05-10 20:28:39 UTC
I've discovered that the proper way to disable LTO is via

%define _lto_cflags %{nil}

Adding this to the .spec file allows the Tumbleweed package for SeaMonkey to build on the OBS server (and also on my local machine).  I've committed this change to my branch and will submit a merge request soon.

In the meantime, I opened Bug 1171414 for the issue of LTO builds failing on the OBS server (but not locally).