Bug 1181525

*** Bug 1165427 has been marked as a duplicate of this bug. ***

Wolfgang, is there any chance that you could have a look at this?  Basically I think that the SeaMonkey spec file needs to be adapted so that it handles things in much the same way that the MozillaFirefox spec file does.  I tried doing this myself but haven't been successful (largely because I don't have a lot of time at the moment).  But I think you're the one who has been writing and maintaining the MozillaFirefox spec file, so perhaps it will be easier for you to make the necessary revisions.

Created attachment 845880 [details]
Replacement Makefile for SeaMonkey 2.53.6

The following message is reposted here with permission from Dmitry:

-------- Forwarded Message --------
Subject: SeaMonkey: new makefile instead of client.mk plus locales support
Date: Sun, 7 Feb 2021 00:22:06 +0300
From: Dmitry Butskoy <buc@buc.me>
To: psychonaut@nothingisreal.com

Hi Tristan,

I would like to share with you some solutions, inspired by the recent SM build system issues. I believe it is useful for any distro, especially when providing all the locales.

Since 2.53.6, SM's own client.mk file is gone. The file mozilla/client.mk belongs to Firefox internal things. Traditional for years "make -f client.mk something" has issues now (for its use "as before" the patch is needed: https://bugzilla.mozilla.org/show_bug.cgi?id=1682424#c19 ) .

Officially, Mozilla uses its own ./mach command to do anything build-related. But in context of Linux/UNIX distros, this command just acts as a front-end to the underlying GNU make. (All the things are actually done by the usual "make", except something at config stage).

I've prepared an alternate front-end -- a gnu makefile, which uses ./mach when it is necessary only (some configure things). It should be placed as "mozilla/GNUmakefile" (instead the stub already present). Being named GNUmakefile, it takes precedence over all other names ([Mm]akefile) and avoids any unneeded influence with existing Mozilla code.

This way it is possible now to "make %{?_smp_mflags}" and "make install DESTDIR=wherever_needed". It follows most distros policies, allows incremental builds (for discovering issues) etc.


Additionally, this GNUmakefile supports build of locales, including providing langpacks (rebuilt from l10n source) and repacking calendar and chatzilla extensions with all the needed languages. All the things are done automatically, and can be invoked as "make %{?_smp_mflags}; make -j1 locales; make install DESTDIR=...", or even "./mach build; make locales; ./mach package".

See more info in the file attached (or at https://src.fedoraproject.org/rpms/seamonkey/blob/rawhide/f/seamonkey-2.53.6-GNUmakefile ).


I would like to take this opportunity to thank you and OpenSUSE for efforts in maintaining rebuilt langpacks for SeaMonkey, which served as a useful example for me when I had adding a similar support in Fedora.

I believe I should note now that the external "compare-locales" no more needed. Moreover, it seems that it produces broken things now. Thus, it puts identical hyphenation stuff for all the locales, whereas it is now provided just by omni.ja . Second, it puts dictionaries into the langpacks generated (but it is not mentioned in manifests), instead to be placed just under /usr/lib64/seamonkey/dictrionaries/ subdir. But in general, such dictionaries are unneeded, since all the Linux/UNIX distros have its own system ones (and then either "spellchecker.dictionary_path" pref or just symlink).
In general, separating locales into the optional subpackages for preserving disk space seems no more actual nowadays. Moreover it could be strange when provided calendar and chatzilla have all languages anyway, whereas the main SM not.


It could be fine to receive some feedback from you about new GNUmakefile.


Best regards,
Dmitry Butskoy
https://fedoraproject.org/wiki/User:Buc

Fixed via <https://build.opensuse.org/request/show/885878>, though this has unfortunately introduced a new problem regarding debugsource builds: Bug 1184851