- include
- share/idl
- lib/palemoon-devel-$VERSION
Link to relevant discussion (GitHub).
Moderator: trava90
How exactly are you building?
Code: Select all
# Configuring
export MOZCONFIG=$PWD/mozconfig
export MOZ_NOSPAM=1
echo > $MOZCONFIG '(mozconfig contents here)'
# Building
./mach build
# Installing
./mach install
substituteInPlace ./palemoon/branding/official/palemoon.desktop \
--replace 'StartupWMClass="pale moon"' 'StartupWMClass=Pale moon'
desktop-file-install --dir=$out/share/applications \
./palemoon/branding/official/palemoon.desktop
# Install official branding icons
for iconname in default{16,22,24,32,48,256} mozicon128; do
n=''${iconname//[^0-9]/}
size=$n"x"$n
install -Dm644 ./palemoon/branding/official/$iconname.png $out/share/icons/hicolor/$size/apps/palemoon.png
done
# Remove unneeded SDK data from installation
# TODO: move to a separate output?
rm -rf $out/{include,share/idl,lib/palemoon-devel-${version}}
what is your mozconfig?
Code: Select all
# Clear this if not a 64bit build
_BUILD_64=${lib.optionalString stdenv.hostPlatform.is64bit "1"}
# Set GTK Version to 2 or 3
_GTK_VERSION=${gtkVersion} # Input to build process, 3 by default
# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --enable-optimize="-O2 -w"
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --disable-eme
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --with-pthreads
# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
ac_add_options --x-libraries=${lib.makeLibraryPath [ xorg.libX11 ]}
export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION
#
# NixOS-specific adjustments
#
ac_add_options --prefix=$out
mk_add_options MOZ_MAKE_FLAGS="-j${if enableParallelBuilding then "$NIX_BUILD_CORES" else "1"}"
mk_add_options AUTOCONF=${autoconf213}/bin/autoconf
Our build system automatically strips the build results too, but only if the user doesn't request a debugging-capable result. If we switch to mach package, would there be an environment variable / argument to tell it to not strip its results or would users be SOL?strip
I'm sorry but in what way is that wasting more time and resources than "installing" it to a temporary location?
You are already stripping as-you-build removing debugging bloat (since you're using --enable-strip) and unless you want positively huge binaries that is what you want. Basic debugging symbols are still included in the binaries; they aren't "bare".
We thought it's wasting time and space on paper since we're not interested in a tarball to distribute, we want everything unpacked to the output prefix. We do our own compressing from there if the build is running on a distribution server, to replicate the prefix 1:1 on the user's machine. The XZ archive way means we're going from build -> move to prefix (-> compress) to build -> compress to archive -> decompress to prefix (-> compress).I'm sorry but in what way is that wasting more time and resources than "installing" it to a temporary location?
The main point is though: The packaging stage is simply an integral part of release engineering here. You should not skip it for any build. Period. You'd be hurting not only end user resources but also end-user performance. To understand why, have a look at the packaging stage in our tree and what all it does (I really don't feel like listing everything, sorry.)
Code: Select all
[19449s] make -j1 -C /usr/src/packages/BUILD/obj-x86_64-pc-linux-gnu install
[19449s] make[3]: Entering directory '/usr/src/packages/BUILD/obj-x86_64-pc-linux-gnu'
[19449s] make[4]: Entering directory '/usr/src/packages/BUILD/obj-x86_64-pc-linux-gnu/palemoon/installer'
…
[19689s] rm -rf $(pwd)/debian/palemoon/usr/share/idl
[19689s] rm -rf $(pwd)/debian/palemoon/usr/lib/palemoon-devel
[19689s] rm -rf $(pwd)/debian/palemoon/usr/include
Code: Select all
0:01.36(B /nix/store/chy0dyh9imv0qj4x3xd1a2w4rw9v77pj-gnumake-4.3/bin/make -C . -j5 -s -w install
0:01.36(B make: Entering directory '/build/source/obj-x86_64-pc-linux-gnu'
0:01.40(B make[1]: Entering directory '/build/source/obj-x86_64-pc-linux-gnu/palemoon/installer'
Code: Select all
0:00.45(B /nix/store/y8i1aq9v5ibdg8lv6x370wc94p4hwq26-gnumake-4.3/bin/make -C . -j3 -s -w package
0:00.46(B make: Entering directory '/build/source/obj-x86_64-pc-linux-gnu'
0:00.51(B make[1]: Entering directory '/build/source/obj-x86_64-pc-linux-gnu/palemoon/installer'
…
2:04.80(B make[2]: Leaving directory '/build/source/obj-x86_64-pc-linux-gnu/palemoon/installer'
2:04.80(B Compressing...
2:04.83(B palemoon/
…
I see, apologies for the confusion. I wasn't thinking of file exclusion from a package, I'd usually associate that term more with binary symbols.You are already stripping as-you-build removing debugging bloat (since you're using --enable-strip) and unless you want positively huge binaries that is what you want. Basic debugging symbols are still included in the binaries; they aren't "bare".
What I meant with stripping in that context is excluding unnecessary files (strip the application/package) not related to debugging info.
I've never been hostile about the branding. The person you're talking about hasn't contributed to Nixpkgs in a long while AFAICT. I took over the packaging for Pale Moon more than a year ago, I verified with you that our mozconfig is fine for official branding, we kept the branding enabled and afaik it's been peaceful since :/…One thing I don't understand is why we are helping a hostile distro that has been mutually decided to not be official.
What are you talking about?New Tobin Paradigm wrote: ↑2021-05-03, 14:34One thing I don't understand is why we are helping a hostile distro that has been mutually decided to not be official.
AFAIK we're not hacking any build steps in the build process.New Tobin Paradigm wrote: ↑2021-05-03, 14:34mach install WILL pass through mach stage step though if they are bypassing THAT with a hack then yeah they are still doing it wrong
I'll remove it if you say it's not required for us, I stuck to your build instructions for the most part.New Tobin Paradigm wrote: ↑2021-05-03, 14:58As an aside it makes no sense to export MOZ_PKG_SPECIAL outside of our generic binary with AUS production. This is something we use for distinction for our infra. It is in the DPMO linux and sunos mozconfigs for our common reference as much as the build instructions are for everyone else's.