Bug 1165414

Summary:	Update SeaMonkey packages to version 2.53.1
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Tristan Miller <psychonaut>
Component:	Firefox	Assignee:	Tristan Miller <psychonaut>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	wolfgang
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:	1165597
Bug Blocks:

Description Tristan Miller 2020-03-02 10:14:36 UTC

SeaMonkey 2.53.1 was released on 28 February 2020.  We need to produce Leap and Tumbleweed packages.

This involves fixing at least the following issues:

1) Currently SeaMonkey is reported as building OK with Rust 1.37 but not with Rust >= 1.40.  Tumbleweed is currently using Rust 1.40 and Leap uses 1.36.  To get SeaMonkey to build on Tumbleweed, we need to apply the upstream patches from <https://bugzilla.mozilla.org/show_bug.cgi?id=1617782>.  However, these patches might not work for Leap.

2) The existing patches that we are applying (for proxies, NTLM, etc.) no longer apply cleanly.  These need to be checked on a case-by-case basis to see if they are still necessary, and if so, to adapt them.

I have solved #1 with respect to Tumbleweed in a branch at <https://build.opensuse.org/package/show/home:psych0naut:branches:mozilla/seamonkey>.

I'm currently working on #2 in the same branch.  The following openSUSE patches have been successfully adapted:

patch501 - fix declaration of gittid()
patch502 - fix LTO compilation flag

Comment 1 Tristan Miller 2020-03-02 11:21:56 UTC

The build is currently failing with the error "NSModules are not ordered appropriately".  This is triggered by the script mozilla/python/mozbuild/mozbuild/action/check_binary.py, which checks that symbols have a certain ordering (with start_kPStaticModules_NSModule at the beginning and end_kPStaticModules_NSModule at the end).  See below for the relevant part of the build output.

This same problem was previously reported upstream at <https://bugzilla.mozilla.org/show_bug.cgi?id=1054034> but seems to have been solved there long ago.  Web searches indicate that the problem is/was related to the use of LTO to compile libxul.so, though I'm not sure if that's the case here.  In theory SeaMonkey itself is now set up to disable LTO when building libxul.so, though maybe that workaround isn't getting properly applied in our build?

Wolfgang, any chance you could take a look at this?

[ 3531s] TEST-UNEXPECTED-FAIL | check_nsmodules | libxul.so | NSModules are not ordered appropriately
[ 3531s] 5c6df50 8 start_kPStaticModules_NSModule
[ 3531s] 5c6df58 8 end_kPStaticModules_NSModule
[ 3531s] 5c6df60 8 nsLDAPProtocolModule_NSModule
[ 3531s] 5c6df68 8 nsMorkModule_NSModule
[ 3531s] 5c6df70 8 nsMailModule_NSModule
[ 3531s] 5c6df78 8 nsImportServiceModule_NSModule
[ 3531s] 5c6df80 8 _ZN7mozilla30SandboxSettingsModule_NSModuleE
[ 3531s] 5c6df88 8 _ZN7mozilla30SandboxReporterModule_NSModuleE
[ 3531s] 5c6df90 8 nsPrefModule_NSModule
[ 3531s] 5c6df98 8 nsUConvModule_NSModule
[ 3531s] 5c6dfa0 8 nsI18nModule_NSModule
[ 3531s] 5c6dfa8 8 nsDNSServiceDiscoveryModule_NSModule
[ 3531s] 5c6dfb0 8 nsGIOModule_NSModule
[ 3531s] 5c6dfb8 8 necko_NSModule
[ 3531s] 5c6dfc0 8 nsAuthModule_NSModule
[ 3531s] 5c6dfc8 8 nsChardetModule_NSModule
[ 3531s] 5c6dfd0 8 nsJarModule_NSModule
[ 3531s] 5c6dfd8 8 ZipWriterModule_NSModule
[ 3531s] 5c6dfe0 8 mozStorageModule_NSModule
[ 3531s] 5c6dfe8 8 nsCookieModule_NSModule
[ 3531s] 5c6dff0 8 nsPermissionsModule_NSModule
[ 3531s] 5c6dff8 8 nsRDFModule_NSModule
[ 3531s] 5c6e000 8 nsParserModule_NSModule
[ 3531s] 5c6e008 8 nsGfxModule_NSModule
[ 3531s] 5c6e010 8 nsImageLib2Module_NSModule
[ 3531s] 5c6e018 8 nsIconDecoderModule_NSModule
[ 3531s] 5c6e020 8 HostObjectProtocolHandler_NSModule
[ 3531s] 5c6e028 8 fakesynth_NSModule
[ 3531s] 5c6e030 8 synthspeechdispatcher_NSModule
[ 3531s] 5c6e038 8 peerconnection_NSModule
[ 3531s] 5c6e040 8 nsPluginModule_NSModule
[ 3531s] 5c6e048 8 PaymentRequestModule_NSModule
[ 3531s] 5c6e050 8 PresentationDeviceProviderModule_NSModule
[ 3531s] 5c6e058 8 nsContentProcessWidgetModule_NSModule
[ 3531s] 5c6e060 8 nsWidgetGtk2Module_NSModule
[ 3531s] 5c6e068 8 nsTransactionManagerModule_NSModule
[ 3531s] 5c6e070 8 nsComposerModule_NSModule
[ 3531s] 5c6e078 8 nsLayoutModule_NSModule
[ 3531s] 5c6e080 8 docshell_provider_NSModule
[ 3531s] 5c6e088 8 appshell_NSModule
[ 3531s] 5c6e090 8 nsUniversalCharDetModule_NSModule
[ 3531s] 5c6e098 8 nsProfilerModule_NSModule
[ 3531s] 5c6e0a0 8 nsWindowDataSourceModule_NSModule
[ 3531s] 5c6e0a8 8 application_NSModule
[ 3531s] 5c6e0b0 8 mozSpellCheckerModule_NSModule
[ 3531s] 5c6e0b8 8 _ZN7mozilla31LocalCertServiceModule_NSModuleE
[ 3531s] 5c6e0c0 8 NSS_NSModule
[ 3531s] 5c6e0c8 8 PKI_NSModule
[ 3531s] 5c6e0d0 8 RemoteServiceModule_NSModule
[ 3531s] 5c6e0d8 8 Browser_Embedding_Module_NSModule
[ 3531s] 5c6e0e0 8 CommandLineModule_NSModule
[ 3531s] 5c6e0e8 8 nsMediaSnifferModule_NSModule
[ 3531s] 5c6e0f0 8 jsperf_NSModule
[ 3531s] 5c6e0f8 8 nsPlacesModule_NSModule
[ 3531s] 5c6e100 8 jsreflect_NSModule
[ 3531s] 5c6e108 8 nsTelemetryModule_NSModule
[ 3531s] 5c6e110 8 mozMozIntlHelperModule_NSModule
[ 3531s] 5c6e118 8 jsctypes_NSModule
[ 3531s] 5c6e120 8 tkAutoCompleteModule_NSModule
[ 3531s] 5c6e128 8 satchel_NSModule
[ 3531s] 5c6e130 8 nsFileViewModule_NSModule
[ 3531s] 5c6e138 8 nsToolkitCompsModule_NSModule
[ 3531s] 5c6e140 8 Apprunner_NSModule
[ 3531s] 5c6e148 8 embedcomponents_NSModule
[ 3531s] 5c6e150 8 nsUnixProxyModule_NSModule
[ 3531s] 5c6e158 8 nsAutoConfigModule_NSModule
[ 3531s] 5c6e160 8 jsinspector_NSModule
[ 3531s] 5c6e168 8 identity_NSModule
[ 3531s] 5c6e170 8 StartupCacheModule_NSModule
[ 3531s] 5c6e178 8 jsdebugger_NSModule
[ 3531s] 5c6e180 8 mozgnome_NSModule
[ 3531s] 5c6e188 8 calBaseModule_NSModule
[ 3531s] 5c6e190 8 SuiteModule_NSModule

Comment 2 Tristan Miller 2020-03-02 12:30:58 UTC

All remaining patches have been adapted to the new codebase, or else removed if they are no longer applicable.

One of the patches that I removed was mozilla-no-stdcxx-check.patch as it referenced binary checks that no longer exist in the source tree -- I believe that these have been superseded by the check_binary.py script I mentioned in Comment #1.  Perhaps this has something to do with the build problem.

Comment 3 Tristan Miller 2020-03-03 20:31:53 UTC

(In reply to Tristan Miller from comment #1)
> The build is currently failing with the error "NSModules are not ordered
> appropriately".

I've just fixed this by applying an upstream patch: https://bugzilla.mozilla.org/show_bug.cgi?id=1594933

Unfortunately, the build ends up failing later for a different reason.  I'm continuing to work on this.

Comment 4 Tristan Miller 2020-03-04 10:57:58 UTC

(In reply to Tristan Miller from comment #3)
> Unfortunately, the build ends up failing later for a different reason.  I'm
> continuing to work on this.

All outstanding build issues (except Bug 1165427, which can be fixed later) have been solved.  I need to install and try out the new packages and if everything is OK I will submit the changes to the parent project on build.opensuse.org.

Comment 5 Tristan Miller 2020-07-16 07:30:31 UTC

Notwithstanding Bug 1165427 I am marking this issue as closed, since 2.53.1 (and 2.53.2 and 2.53.3) have been successfully packaged using the old compare-locales code.  But in the near future we will need to use the new method.