+++ This bug was initially created as a clone of Bug #1669078 +++

This is a tracking bug for Build and Release of SeaMonkey 2.53.6 beta(s).

Change mozilla version to .6 r/a=me

Change SeaMonkey version to 2.53..6b1pre and mail to 56.6 for Lightning r/a=me

Update SeaMonkey version to 2.53.6b1 r/a=me

gcc 11 issue. Not really worth to do a separate bug because mini fix and we want to get rid of this code anyway. But maybe should be done because might be needed for 2.57?

There is no similar changes in Fx code yet. Either Fx still not use gcc-11/clang-11, or the change is not needed because of reorganized code.

If there is no plan to compile 2.57 by any of 11 for now, then it could be delayed there.

For WEBRENDER stderr reports:

It seems that gitlab commit 17e3dabc is a bit incomplete. One thing was initially missed:

--- mozilla/widget/GfxInfoBase.cpp	2020-02-18 02:39:44.000000000 +0300
+++ mozilla/widget/GfxInfoBase.cpp-OK	2020-12-15 20:31:58.641005716 +0300
@@ -382,8 +382,11 @@ BlacklistFeatureToGfxFeature(const nsASt
   else if (aFeature.EqualsLiteral("D3D11_KEYED_MUTEX"))
     return nsIGfxInfo::FEATURE_D3D11_KEYED_MUTEX;
   else if (aFeature.EqualsLiteral("DX_NV12"))
     return nsIGfxInfo::FEATURE_DX_NV12;
+  else if (aFeature.EqualsLiteral("WEBRENDER"))
+    return nsIGfxInfo::FEATURE_WEBRENDER;
+
   // We do not support FEATURE_VP8_HW_DECODE and FEATURE_VP9_HW_DECODE
   // in downloadable blocklist.
 
   // If we don't recognize the feature, it may be new, and something

it should solve the issue with "unrecognized feature critical error report" due to yet unknown feature WEBRENDER in the runtime downloaded blocklists.

Proper webrender support was add in bug #1455696 .

Just tested -- the proposed patch above works as expected...

Comment on attachment 9193152 [details] [diff] [review]
1682424-fixgcc11-2536.patch

Moving to a separate bug.

Missing comm/ following topsrcdir change

Comment on attachment 9194414 [details] [diff] [review]
Fix locale distribution

LGTM

Windows configs for 2.53.6 beta 1

Comment on attachment 9193150 [details] [diff] [review]
1682424-versiondisplay-2536b1pre.patch

https://gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/commit/f390ad0ad9d5c0d219db227bf264f9482a3af033
SeaMonkey 2.53.6 beta 1 release. r=IanN a=IanN

Comment on attachment 9193151 [details] [diff] [review]
1682424-versiondisplay-2536b1.patch

https://gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/commit/7390e7ffb67d59848f83940ff0c18f366c179ac5
SeaMonkey 2.53.6 beta 1 release. r=IanN a=IanN

Comment on attachment 9194414 [details] [diff] [review]
Fix locale distribution

https://gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/commit/d0b5c7cfb82fce2897f525fa3e7069b59a396d5d
Fix locales distribution for mozilla as topsrcdir. r=frg a=frg

Comment on attachment 9193149 [details] [diff] [review]
1682424-version-mr-2536.patch

https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla/-/commit/501740bfa0bbdc330e866d3cf5078fa480377a04
SeaMonkey 2.53.6 beta 1 release. r=IanN a=IanN

It is still possible to use "make -f client.mk ..something...", but now with mozilla's client.mk. Just one little patch is neeeded, see below.

Note, that currently all the Linux distribution who provide SM, use "make -f client.mk" to build their packages. This way is in use for years. It is also more familiar to "UNIX way" people, while the transition to "mach build" will be quite painful for them.

It is quite preferrable to preserve the possibility of the old build way for such users -- for the same reasons why we try to preserve the old good Firefox things, as long as possible.

The problem with mozilla's client.mk is that it has (an ugly) hack, which causes it to create $(OBJDIR)/.mozconfig.json each time. They already have implemented a way to switch this off, by CREATE_MOZCONFIG_JSON variable (which is used inside for any recursive calls).

The .mozconfig.json file is created by "mach environment", which is very sensitive to the changes in the environment, and just recreate the file in such a case. The new file will have a more recent modification time, which causes "make" to recreate initial configure stuff etc.etc.etc.

Thus the first "make -f client.mk" runs fine, but following -- either at the another build stage of the package (ie. install), or just some attempts to do an incremental build manually (to discover a bug) -- very likely leads to re-creation of .mozconfig.json, and then all tries to run from the scratch again...

To avoid this, either use make -f client.mk ...something... CREATE_MOZCONFIG_JSON= in cmdline for each run but the first, or apply the patch:

--- a/client.mk	2020-12-22 05:23:56.000000000 +0300
+++ a/client.mk-OK	2020-12-24 19:54:52.834091571 +0300
@@ -281,17 +281,25 @@
 configure-preqs = \
   $(OBJDIR)/CLOBBER \
   configure-files \
   $(call mkdir_deps,$(OBJDIR)) \
   save-mozconfig \
   $(OBJDIR)/.mozconfig.json \
   $(NULL)
 
-CREATE_MOZCONFIG_JSON = $(shell $(TOPSRCDIR)/mach environment --format=json -o $(OBJDIR)/.mozconfig.json)
+# Do not try to re-create .mozconfig.json when running
+# directly under `make -f client.mk' 
+ifndef MACH
+ifneq (,$(wildcard $(OBJDIR)/.mozconfig.json))
+CREATE_MOZCONFIG_JSON =
+endif
+endif
+
+CREATE_MOZCONFIG_JSON ?= $(shell $(TOPSRCDIR)/mach environment --format=json -o $(OBJDIR)/.mozconfig.json)
 # Force CREATE_MOZCONFIG_JSON above to be resolved, without side effects in
 # case the result is non empty, and allowing an override on the make command
 # line not running the command (using := $(shell) still runs the shell command).
 ifneq (,$(CREATE_MOZCONFIG_JSON))
 endif
 
 $(OBJDIR)/.mozconfig.json: $(call mkdir_deps,$(OBJDIR)) ;
 

The patch "automates" an "adding" of the switch cmdline variable in the case .mozconfig.json already exists, as well as avoids this change if client.mk is used (if any) under true mach invocation. Thus the "mach" builds are not affected at all, whereas "make -f client.mk" is still possible as before.

With the patch applied, the only change for distros seems to be "suite" --> "comm/suite" in --enable-application= argument.

The patch above in an attached form.

Well mach is the future and I lost too many hours already chasing build breakage with mozilla stuff in already so nothing I would want.

Updated README.txt for release directory.

Comment on attachment 9194876 [details]
README.txt

lgtm

(In reply to Frank-Rainer Grahl (:frg) from comment #20)

Well mach is the future and I lost too many hours already chasing build breakage with mozilla stuff in already so nothing I would want.

I'm also a distribution packager of SeaMonkey. I've got nothing in principle against learning and applying the new build system for SeaMonkey, but the problem is that this system isn't correctly, completely, and consistently documented—see Bug 1684460 for a list of all the errors, omissions, and inconsistencies that I could find.

Currently openSUSE, like Fedora, uses make -f client.mk to build SeaMonkey, but this no longer works as of 2.53.6b1. Either I try using Dmitry's patch, or else someone needs to provide working instructions for checking out and compiling SeaMonkey that are comprehensive enough to allow me to convert our existing scripts and RPM spec files. If providing this documentation is not possible in the near future, then please consider reviewing and accepting the patch for the time being. I was lucky enough to discover it here, but other distribution packagers might not, and so they might not be able to provide packages for 2.53.6+ in a timely manner (or at all).

(In reply to Tristan Miller from comment #23)

(In reply to Frank-Rainer Grahl (:frg) from comment #20)

Well mach is the future and I lost too many hours already chasing build breakage with mozilla stuff in already so nothing I would want.

I'm also a distribution packager of SeaMonkey. I've got nothing in principle against learning and applying the new build system for SeaMonkey, but the problem is that this system isn't correctly, completely, and consistently documented—see Bug 1684460 for a list of all the errors, omissions, and inconsistencies that I could find.

mach isn't particularly new, it has been in use a number of years for building Mozilla based products. Yes, how it is used for SeaMonkey needs to be better documented - see the responses in Bug 1684460 and also the work going on in Bug 1620789. If there is an issue with the documentation being provided in Bug 1620789 then please let us know what needs adding / clarifying over in that bug.

As mach does make use of client.mk, we do have to be careful about patching that file so as to not break building using mach or other patches being applied to it.

Comment on attachment 9194685 [details] [diff] [review]
seamonkey-2.53.6-client_mk.patch

Do the patches on Bug 1412932 and from Bug 1417264:
https://hg.mozilla.org/releases/mozilla-esr60/rev/249a8177ad915734b83c357d49213e26d889b377
also fix the issue?

If not, this particular patch does seem to be fairly harmless so f+ from me

(In reply to Ian Neal from comment #25)

Do the patches on Bug 1412932 and from Bug 1417264:
https://hg.mozilla.org/releases/mozilla-esr60/rev/249a8177ad915734b83c357d49213e26d889b377
also fix the issue?

No. It just moves the code to python, without changing its logic. It remains sensible to the changes of environment variables, which makes it very inconvenient for the established practice of resolving code issues in UNIX (aka incremental running make with, say, different CFLAGS etc.)

Let the patch be yet another temporary plaster (without official support, of course). By the time the code goes further, either everyone will switch to mach, or I'll come up with something else.

Well, there is ./GNUmakefile , which seems most suitable place to handle such use cases. And it is unchanged in Fx upstream, and highly likely remains unchanged there forever. So it is a safe place for patches.

Certainly finding a way without touching client.mk can take a time, so it is better to apply the existing patch at least for 2.53.6

Does anybody hint me how to friendly print variable values (CC=something etc.) from the objdir/.mozconfig.json? Fe. some python magic cmdline...

...no hint needed, things appear simpler.

GNUmakefile way seems can satisfy most downstream distributions' requirements (regarding standart ways of running build, install etc. using distro-specific macros over make etc.)

Thus, first apply the patch to preserve "make -f client.mk" for a while (probably add menton in release notes that it is no more official supported and might gone in the near future).

Second, provide the new GNUmakefile . This way Linux/UNIX people will have freedom of choice -- either switch to mach, or use the traditional ways of building/installing with the classic "make" front-end.

Overall working one, version 0. Not fully tested yet.

Just not to postpone everything for the next year. :)

GNUmakewfile version1, tested, working, to replace the old one in topsrcdir as ./GNUmakefile .
See comment inside for more info.

Provides more convenient way for distributions (just "make", "make install" etc.), an ability to practice-reliable incremental run, an easy way to install (ie. just "make install" instead of "make -C objdir install" when mach etc.).

Better to put this upstream (since it spoils nothing in general here), rather than to have some separate Linux/UNIX FAQ and stuff anywhere outside.

Comment on attachment 9194996 [details]
GNUmakefile_v1

Seems reasonable

I think we are done here. The proposed changes and addtions for makefile support need to be converted to patches/new bugs and block 2.53.6 or 2.53.7 if not ready. I won't do it.