AOSC-OS builds of Pale Moon use wrong configuration. #1558

The AOSC-OS builds use official branding and a not-sane mozconfig for it, as well as changing preferences unnecessary for producing a build, including a setup to allow package-bundled extensions (unknown if anything is actually bundled at this time).

See https://github.com/AOSC-Dev/aosc-os-abbs/tree/staging/extra-web/palemoon/autobuild
@MingcongBai This is a critical issue in violation of the redist/official branding license. please work with us to resolve ASAP.

Main issues:

jemalloc config is not sane
insane amount of --with-system-* libraries
mixing system NSPR with in-tree NSS (!)
obsolete switches/non-existent switches

included vendor.js with pref overrides:

// Use LANG environment variable to choose locale.
pref("intl.locale.matchOS",			true);

// Disable install warning for bundled extension in the application directory
pref("extensions.autoDisableScopes", 11);
pref("extensions.shownSelectionUI", true);

The AOSC-OS builds use official branding and a not-sane mozconfig for it, as well as changing preferences unnecessary for producing a build, including a setup to allow package-bundled extensions (unknown if anything is actually bundled at this time). See https://github.com/AOSC-Dev/aosc-os-abbs/tree/staging/extra-web/palemoon/autobuild @MingcongBai This is a critical issue in violation of the redist/official branding license. please work with us to resolve ASAP. Main issues: - jemalloc config is not sane - insane amount of `--with-system-*` libraries - mixing system NSPR with in-tree NSS (!) - obsolete switches/non-existent switches - included vendor.js with pref overrides: ``` javascript // Use LANG environment variable to choose locale. pref("intl.locale.matchOS", true); // Disable install warning for bundled extension in the application directory pref("extensions.autoDisableScopes", 11); pref("extensions.shownSelectionUI", true); ```

For points 1-4 I could work with you, and I could say I'm 90% willing to comply with your 5th point. As a multilingual Linux Distribution, it works against our design to require manual intervention to change application language settings.

To be fair, it's you guys' rule here so I have no intention on breaking them. However, I do want to sound my disagreement with this incredibly strict rule to limit what a packager could choose to do to redistribute such binaries. While I understand that certain vendor rules - like the last two we have, could be risky - I should argue that bundling of dependencies would have worked against packaging guidelines of most Linux distributions anyways, I guess that's a reason to the lacking of distribution packaging.

No offence, just my two cents here. I'll get the rest changed right away, however, the line regarding intl.locale.matchOS I do refuse to change - if you choose to keep pressing on that, I would just drop the package.

For points 1-4 I could work with you, and I could say I'm 90% willing to comply with your 5th point. As a multilingual Linux Distribution, it works against our design to require manual intervention to change application language settings. To be fair, it's you guys' rule here so I have no intention on breaking them. However, I do want to sound my disagreement with this incredibly strict rule to limit what a packager could choose to do to redistribute such binaries. While I understand that certain vendor rules - like the last two we have, could be risky - I should argue that bundling of dependencies would have worked against packaging guidelines of most Linux distributions anyways, I guess that's a reason to the lacking of distribution packaging. No offence, just my two cents here. I'll get the rest changed right away, however, the line regarding intl.locale.matchOS I do refuse to change - if you choose to keep pressing on that, I would just drop the package.

Also, could you clarify what you mean by "sane" Jemalloc configuration? For the meanwhile I'll take it as it is and remove it.

To add onto all that, do you want us to remove "Distribution ID" and all compiler flag configuration? We ourselves have a binary hardening standard, which we do not bypass unless the binary would fail to build with these flags.

ac_add_options --disable-webrtc
ac_add_options --disable-installer
ac_add_options --disable-mobile-optimize
ac_add_options --disable-metro
ac_add_options --disable-maintenance-service
ac_add_options --disable-updater
ac_add_options --disable-windows-mobile-components

Am I free do disable anything here? For example, it is common practice to encourage users to update via our package manager, not yours.

``` ac_add_options --disable-webrtc ac_add_options --disable-installer ac_add_options --disable-mobile-optimize ac_add_options --disable-metro ac_add_options --disable-maintenance-service ac_add_options --disable-updater ac_add_options --disable-windows-mobile-components ``` Am I free do disable anything here? For example, it is common practice to encourage users to update via *our* package manager, not yours.

I guess I'll wait for your response on these questions, with your logic it seems like every line in the currrent .mozconfig could be problematic - you see, if you could do an audit line-by-line it would help - or just start to help with the situation...

We are currently talking about dropping the package in question, as many of us feel quite strongly against bundling libraries (as you may have stability concerns, we have it too, just on a different direction). Palemoon currently serves as a sole option of a usable browser on our PowerPC big-endian architectures, so me personally wouldn't want it to happen. I would suggest that you guys (while I work on complying with your rules) reconsider your license as it really sounded quite reasonable at this point...

Not to mention Mozilla who recently lifted similar restrictions on distribution packaging and redistribution - see Debian, Fedora, Ubuntu, etc. You don't see vanilla builds with fully bundled libraries there, do you? Alas, at the end of the day, you guys are not Mozilla.

While I'm personally thankful that you guys made such a great browser, the community developers and myself couldn't feel the same for your licensing restrictions.

I guess I'll wait for your response on these questions, with your logic it seems like every line in the currrent .mozconfig could be problematic - you see, if you could do an audit line-by-line it would help - or just start to help with the situation... We are currently talking about dropping the package in question, as many of us feel quite strongly against bundling libraries (as you may have stability concerns, we have it too, just on a different direction). Palemoon currently serves as a sole option of a usable browser on our PowerPC big-endian architectures, so me personally wouldn't want it to happen. I would suggest that you guys (while I work on complying with your rules) reconsider your license as it really sounded quite reasonable at this point... Not to mention Mozilla who recently lifted similar restrictions on distribution packaging and redistribution - see Debian, Fedora, Ubuntu, etc. You don't see vanilla builds with fully bundled libraries there, do you? Alas, at the end of the day, you guys are not Mozilla. While I'm personally thankful that you guys made such a great browser, the community developers and myself couldn't feel the same for your licensing restrictions.

Many of those configure options have been flipped around and defaults are changed from what Firefox or what we used years ago..

In general you should stick as CLOSE as possible to our official mozconfig:
http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux#head:Mozconfig_Files

Many of those configure options have been flipped around and defaults are changed from what Firefox or what we used years ago.. In general you should stick as CLOSE as possible to our official mozconfig: http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux#head:Mozconfig_Files

Okay that helps, but it also seemed quite ambiguous regarding what you mean by "as close as possible", exactly how far could we deviate from it without being called out like this again?

Alright sir, @wolfbeast 2e9573f6c8 Here's what I have in mind so far - reasonable enough?

Alright sir, @wolfbeast https://github.com/AOSC-Dev/aosc-os-abbs/commit/2e9573f6c89a83c77673cbd62accda4bf2d5195b Here's what I have in mind so far - reasonable enough?

Mozconfig looks good except please define what these variables actually are:
ac_add_options --enable-optimize="${CPPFLAGS} ${CFLAGS}"

Mozconfig looks good except please define what these variables actually are: `ac_add_options --enable-optimize="${CPPFLAGS} ${CFLAGS}"`

Please refer to here as these compiler flags are assembled from the configuration scripts here: https://github.com/AOSC-Dev/autobuild3/tree/master/arch.

Can you please give me the assembled variables for your targets please? Some may not be sane..

It varies between architectures, that's why it's a set of scripts, not a file with defined and static flags... But yes I could assemble one for AMD64 if you are interested...

Here you go. Here's a rudimentary Autobuild configuration to build a dummy package, where the "prepare" script, running before the "build" script, prints out a series of flags as defined internally. The "defines" file defines package name "foo", version "0", section "foo", description "Foo for Palemoon", as seen below:

root@bugfix [ tmp ] # pwd
/tmp
root@bugfix [ tmp ] # cat autobuild/prepare 
echo "CFLAGS:"
echo "${CFLAGS}"
echo "CPPFLAGS:"
echo "${CPPFLAGS}"
echo "CXXFLAGS:"
echo "${CXXFLAGS}"
echo "LDFLAGS:"
echo "${LDFLAGS}"
root@bugfix [ tmp ] # cat autobuild/build 
mkdir "$PKGDIR"
root@bugfix [ tmp ] # cat autobuild/defines 
PKGNAME=foo
PKGVER=0
PKGSEC=foo
PKGDES="Foo for Palemoon"
root@bugfix [ tmp ] #

And here's the build output, with the flags you requested...

root@bugfix [ tmp ] # autobuild
[INFO]: Loaded library pm
[INFO]: Loaded library arch
[ERROR]: QA: foo not in sets/section.
[WARN]: . /usr/lib/autobuild3/proc/10-qa_sections.sh returned 1.
[INFO]: Pre-build clean up...
[INFO]: Parallel build ENABLED
[ERROR]: Executable ‘runhaskell’ not found; returned value: 1. Expect failures.
[ERROR]: Executable ‘ghc’ not found; returned value: 1. Expect failures.
[WARN]: /usr/lib/autobuild3/build/15-haskell.sh loading skipped.
CFLAGS:
 -pipe -Wno-error  -fstack-protector-strong --param=ssp-buffer-size=4    -fomit-frame-pointer -O2    -march=x86-64 -mtune=core2 -msse -msse2 -msse3       -fira-loop-pressure -fira-hoist-pressure -ftree-vectorize  -specs=/usr/lib/gcc/specs/hardened-cc1  -flto=jobserver           
CPPFLAGS:
   -D_FORTIFY_SOURCE=2                        
CXXFLAGS:
 -pipe -Wno-error  -fstack-protector-strong --param=ssp-buffer-size=4    -fomit-frame-pointer -O2    -march=x86-64 -mtune=core2 -msse -msse2 -msse3       -fira-loop-pressure -fira-hoist-pressure -ftree-vectorize  -specs=/usr/lib/gcc/specs/hardened-cc1  -flto=jobserver         -fpermissive           -fdeclone-ctor-dtor -ftree-vectorize            
LDFLAGS:
 -Wl,-O1,--sort-common,--as-needed  -Wl,-z,relro  -Wl,-z,now  -specs=/usr/lib/gcc/specs/hardened-ld     -flto -fuse-linker-plugin                    
/usr/lib/autobuild3/build/00-self.sh: line 11: BUILD_START: command not found
[WARN]: . /usr/lib/autobuild3/proc/50-build_exec.sh returned 1.
[WARN]: Invaild memory nullglob: ''
[WARN]: detailed license processing skipped due to missing files.
[WARN]: . /usr/lib/autobuild3/proc/51-licenses.sh returned 1.
[INFO]: Loaded library elf
[INFO]: Loaded library depset
[INFO]: Purging libtool archives from build tree.
[INFO]: Purging static libraries from build tree.
[WARN]: . /usr/lib/autobuild3/filter/mancompress.sh returned 1.
[WARN]: Invaild memory nullglob: ''
[INFO]: Removed perllocal.pod.
[INFO]: Removed .packlist.
[INFO]: Creating empty postinst.
[INFO]: Creating empty prerm.
[INFO]: Creating empty postrm.
[INFO]: Creating empty preinst.
dpkg-deb: building package 'foo' in 'foo_0-0_amd64.deb'.
autobuild/
autobuild/build
autobuild/prepare
autobuild/defines
[INFO]: Using autobuild-aoscarchive as autobuild archiver.
[INFO]: Loaded library pm
[INFO]: abRepoArchive done.
Selecting previously unselected package foo.
(Reading database ... 209728 files and directories currently installed.)
Preparing to unpack foo_0-0_amd64.deb ...
Unpacking foo (0) ...
Setting up foo (0) ...
root@bugfix [ tmp ] #

You're welcome.

It varies between architectures, that's why it's a set of scripts, not a file with defined and static flags... But yes I could assemble one for AMD64 if you are interested... Here you go. Here's a rudimentary Autobuild configuration to build a dummy package, where the "prepare" script, running before the "build" script, prints out a series of flags as defined internally. The "defines" file defines package name "foo", version "0", section "foo", description "Foo for Palemoon", as seen below: ``` root@bugfix [ tmp ] # pwd /tmp root@bugfix [ tmp ] # cat autobuild/prepare echo "CFLAGS:" echo "${CFLAGS}" echo "CPPFLAGS:" echo "${CPPFLAGS}" echo "CXXFLAGS:" echo "${CXXFLAGS}" echo "LDFLAGS:" echo "${LDFLAGS}" root@bugfix [ tmp ] # cat autobuild/build mkdir "$PKGDIR" root@bugfix [ tmp ] # cat autobuild/defines PKGNAME=foo PKGVER=0 PKGSEC=foo PKGDES="Foo for Palemoon" root@bugfix [ tmp ] # ``` And here's the build output, with the flags you requested... ``` root@bugfix [ tmp ] # autobuild [INFO]: Loaded library pm [INFO]: Loaded library arch [ERROR]: QA: foo not in sets/section. [WARN]: . /usr/lib/autobuild3/proc/10-qa_sections.sh returned 1. [INFO]: Pre-build clean up... [INFO]: Parallel build ENABLED [ERROR]: Executable ‘runhaskell’ not found; returned value: 1. Expect failures. [ERROR]: Executable ‘ghc’ not found; returned value: 1. Expect failures. [WARN]: /usr/lib/autobuild3/build/15-haskell.sh loading skipped. CFLAGS: -pipe -Wno-error -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -O2 -march=x86-64 -mtune=core2 -msse -msse2 -msse3 -fira-loop-pressure -fira-hoist-pressure -ftree-vectorize -specs=/usr/lib/gcc/specs/hardened-cc1 -flto=jobserver CPPFLAGS: -D_FORTIFY_SOURCE=2 CXXFLAGS: -pipe -Wno-error -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -O2 -march=x86-64 -mtune=core2 -msse -msse2 -msse3 -fira-loop-pressure -fira-hoist-pressure -ftree-vectorize -specs=/usr/lib/gcc/specs/hardened-cc1 -flto=jobserver -fpermissive -fdeclone-ctor-dtor -ftree-vectorize LDFLAGS: -Wl,-O1,--sort-common,--as-needed -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/gcc/specs/hardened-ld -flto -fuse-linker-plugin /usr/lib/autobuild3/build/00-self.sh: line 11: BUILD_START: command not found [WARN]: . /usr/lib/autobuild3/proc/50-build_exec.sh returned 1. [WARN]: Invaild memory nullglob: '' [WARN]: detailed license processing skipped due to missing files. [WARN]: . /usr/lib/autobuild3/proc/51-licenses.sh returned 1. [INFO]: Loaded library elf [INFO]: Loaded library depset [INFO]: Purging libtool archives from build tree. [INFO]: Purging static libraries from build tree. [WARN]: . /usr/lib/autobuild3/filter/mancompress.sh returned 1. [WARN]: Invaild memory nullglob: '' [INFO]: Removed perllocal.pod. [INFO]: Removed .packlist. [INFO]: Creating empty postinst. [INFO]: Creating empty prerm. [INFO]: Creating empty postrm. [INFO]: Creating empty preinst. dpkg-deb: building package 'foo' in 'foo_0-0_amd64.deb'. autobuild/ autobuild/build autobuild/prepare autobuild/defines [INFO]: Using autobuild-aoscarchive as autobuild archiver. [INFO]: Loaded library pm [INFO]: abRepoArchive done. Selecting previously unselected package foo. (Reading database ... 209728 files and directories currently installed.) Preparing to unpack foo_0-0_amd64.deb ... Unpacking foo (0) ... Setting up foo (0) ... root@bugfix [ tmp ] # ``` You're welcome.

Have you simply tried to build it the conventional way as a test? All this package producing noise doesn't tell us anything because we do not use any of this.

Write the mozconfig
./mach build

Have you simply tried to build it the conventional way as a test? All this package producing noise doesn't tell us anything because we do not use any of this. - Write the mozconfig - ./mach build

Have you simply tried to build it the conventional way as a test? All this package producing noise doesn't tell us anything because we do not use any of this.

Well you did ask for a flag reproduction didn't you... But yes, I did. And as indicated in the issue I referenced to this issue, the problem could be with Glibc.

> Have you simply tried to build it the conventional way as a test? All this package producing noise doesn't tell us anything because we do not use any of this. Well you did ask for a flag reproduction didn't you... But yes, I did. And as indicated in the issue I referenced to this issue, the problem could be with Glibc.

The intl line is actually not a big problem, although it does make behavior of the browser different than what we release. It may also interfere with people who want to install a different language than the OS -- but I'm willing to let that go as long as you make sure to clearly mention that any app interface language issues are your responsibility to solve or answer questions about.

The other two prefs are more of a problem because it disables a security measure to have extensions be slipped in by third parties or a packager without user confirmation (which would go right against your "hardening" approach?).

Also, normally, you don't want to add CFLAGS and CXXFLAGS to --enable-optimize; the configure of the build system should pick up existing CFLAGS exports and use those as a base.

The intl line is actually not a big problem, although it does make behavior of the browser different than what we release. It may also interfere with people who want to install a different language than the OS -- but I'm willing to let that go as long as you make sure to clearly mention that any app interface language issues are your responsibility to solve or answer questions about. The other two prefs are more of a problem because it disables a security measure to have extensions be slipped in by third parties or a packager without user confirmation (which would go right against your "hardening" approach?). Also, normally, you don't want to add CFLAGS and CXXFLAGS to `--enable-optimize`; the configure of the build system should pick up existing CFLAGS exports and use those as a base.

All right, I'll do a revision on our flags. However, the build still fails at the moment.

Also do you want me to remove all Palemoon binaries from our repositories since none of them complied to your licensing requirements?

All right, I'll do a revision on our flags. However, the build still fails at the moment. Also do you want me to remove all Palemoon binaries from our repositories since none of them complied to your licensing requirements?

Please remove officially-branded binaries that don't comply, yes. I'd prefer not having them float around unnecessarily.

Can i safely assume all concerns have been addressed?

I have just removed the packages, however please allow for several days until all our mirrors were sync'd. As for the build, we are currently in the middle of dealing with Spectre - we'll get back to it.

How are things going with Spectre? What's the status of the mirrors and/or build? Anything to report?

I have just made another build, having updated Glibc to the "HEAD" of the 2.26 branch, and with GCC rebuilt against the new Glibc. I'm getting a different error now, however it seems to be related to LTO - trying another build with LTO disabled now.

Build does pass with a disabled LTO... However, failed at the last stage:

Traceback (most recent call last):
  File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 405, in <module>
    main()
  File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 399, in main
    args.source, gre_path, base)
  File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 157, in precompile_cache
    errors.fatal('Error while running startup cache precompilation')
  File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/python/mozbuild/mozpack/errors.py", line 101, in fatal
    self._handle(self.FATAL, msg)
  File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/python/mozbuild/mozpack/errors.py", line 96, in _handle
    raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation
make[3]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.mk:37: stage-package] Error 1
make[3]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer'
make[2]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.mk:81: make-package] Error 2
make[2]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer'
make[1]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/config/rules.mk:541: default] Error 2
make[1]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer'
make: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/browser/build.mk:9: package] Error 2
make: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild'

I'll probably try and perform a build with disabled startup cache generation.

Build does pass with a disabled LTO... However, failed at the last stage: ``` Traceback (most recent call last): File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 405, in <module> main() File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 399, in main args.source, gre_path, base) File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.py", line 157, in precompile_cache errors.fatal('Error while running startup cache precompilation') File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/python/mozbuild/mozpack/errors.py", line 101, in fatal self._handle(self.FATAL, msg) File "/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/python/mozbuild/mozpack/errors.py", line 96, in _handle raise ErrorMessage(msg) mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation make[3]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.mk:37: stage-package] Error 1 make[3]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer' make[2]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/toolkit/mozapps/installer/packager.mk:81: make-package] Error 2 make[2]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer' make[1]: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/config/rules.mk:541: default] Error 2 make[1]: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild/browser/installer' make: *** [/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/browser/build.mk:9: package] Error 2 make: Leaving directory '/var/cache/acbs/build/acbs.c9yg7m_o/palemoon/pmbuild' ``` I'll probably try and perform a build with disabled startup cache generation.

But yes, it seems like the bug lies in Glibc - and that issue in question is resolved with a HEAD build.

Startup cache generation is fragile -- it works on some distributions but not others, and it's still unclear exactly why. The only drawback is that the first start of the browser after installation or upgrade is slow, but once it's run once, performance is normal.

Considering this closed; thanks for working through this to be compliant! 👍

Startup cache generation is fragile -- it works on some distributions but not others, and it's still unclear exactly why. The only drawback is that the first start of the browser after installation or upgrade is slow, but once it's run once, performance is normal. Considering this closed; thanks for working through this to be compliant! :+1:

Labels Milestones

AOSC-OS builds of Pale Moon use wrong configuration. #1558