https://artixlinux.org/news.php#Repository_structure_changes_%28updates%29
Is it possible to have it back someday?
If someone sponsors an 128GB memory build server; with that it does build. ;)
Or until librewolf gets back to normal as in build requirements.
artist
Sorry to see this package go, but it's understandable considering the constraints of consistently compiling and packaging a browser. For anyone with a similar issue. I simply uninstalled librewolf and reinstalled the librewolf-bin from the AUR using paru. All my configs, bookmarks, extensions, settings, etc. remained unchanged.
trizen librewolf
2 galaxy/librewolf 115.0.2-2
Community-maintained fork of Firefox, focused on privacy, security and freedom.
3 chaotic-aur/firedragon 117.0-1
Librewolf fork build using custom branding, settings & KDE patches by OpenSUSE
4 chaotic-aur/librewolf 117.0-1
Community-maintained fork of Firefox, focused on privacy, security and freedom.
/code]
Not sure what's wrong lately with Librewolf/maybe something in mozilla upstream, cause it also was on the cachyos-v3 repo and they probably hit the same issues and removed it from there too.
Interesting how chaotic-aur also has it's firedragon fork-ception up to date, that must've built somehow or they messed with the patches. I still won't use that repo for my own reasons :-) For the time being i replaced with librewolf-bin too.
Today I tried 2 rebuilds of librewolf to get confirmation if the build problems are related to librewolf itself or to the build process. One build was with a heavily stripped and modified pkgbuild, and one with a pkgbuild created almost from scratch. Both failed due to an abnormally high requirement for memory. This confirms one report I received earlier; librewolf only builds on servers with 128Gb or more.
Because firefox still builds normally, the problems must be caused by librewolf itself.
And while librewolf earlier - as in the past 1.5 years - built successfully in maximum 1 attempt out of 2, firedragon built in 1 out of 5 on average...
Therefore the sad conclusion is that the deterioration of quality of both privacy enhanced firefox derivatives has made them unusable.
artist
I built it on my laptop with 8GB RAM and 16GB swap in this thread:
https://forum.artixlinux.org/index.php/topic,5926 (https://forum.artixlinux.org/index.php/topic,5926)
I'd thought it might be helpful for you to try and do this, and it came up in that discussion too so I gave it a go and it worked on the second attempt with the aid of some helpful hints and a couple of small changes to the basic AUR PKGBUILD.
For a distro repo build you probably wouldn't want to use swap so would need a bit more than 16GB RAM restricting threads to 4, if you could upgrade to 32GB it should be ample and you could probably increase the thread count with that too.
The pkgbuild used can build firefox on a system with 16 GB. But it cannot build librewolf on a 64GB server; linking requires at least 128GB. Also the AUR pkgbuild for versions 116 and 117 has the same problem during linking. The problem is not related to rust; with 4 or 6 jobs all compiling works without errors, but the linking is the part that requires 128GB.
artist
It could be this as mentioned in the other thread:
This changed in the librewolf PKGBUILD when 116 was introduced:
-ac_add_options --enable-lto=cross
+ac_add_options --enable-lto=cross,full
https://aur.archlinux.org/cgit/aur.git/commit/?h=librewolf&id=3a2f93dbb9f8628b651edb2665690cd5918405fa (https://aur.archlinux.org/cgit/aur.git/commit/?h=librewolf&id=3a2f93dbb9f8628b651edb2665690cd5918405fa)
That's the only significant change during that period, and lto = LINK time optimisation which is going to affect linking. If you look at the AUR page then on the right there is a link View Changes which will show you this - there has actually been another change now since I built it.
If that doesn't work, if you post more details people might be able to help more, ie your PKGBUILD, system spec, build failure messages, how many threads you are using - this could be configured in various places, /etc/makepkg.conf, the PKGBUILD, or a custom .mozconfig. You could even be experiencing a bug from something else related to the build process, no 128GB was required here.
Builds were tried with lto disabled, lto=cross and lto=cross,full
The nr of threads is not relevant here - used between 4 and 12 in mozconfig, as it's only the linking that fails to complete.
This with ld and with ld.gold.
I also removed LDFLAGS+=" -Wl,--no-keep-memory"
One machine machine had 16gb mem and 12gb swap, the other one has 32gb mem and 80gb swap.
The linker will take up between 21 and 42GB of memory, run forever and not procude any executable, nor an error message.
Are you building on a fully updated system, and in a clean chroot?
Can you provide a PKGBUILD that worked for your build?
artist
There must be some other variable at play here ?
For science I just built the AUR librewolf with 32GB of ram and 32GB swap. While the swap was needed the highest swap usage ever got was 24GB during linking. No modification to the PKGBUILD
From my /etc/makepkg.conf
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=znver2 -mtune=znver2 -O2 -pipe -fno-plt"
CXXFLAGS="-march=znver2 -mtune=znver2 -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
This was the PKGBUILD I used, and I updated just before building, because it needed to install clang and llvm. It built using clang, I think it is possible to build with gcc as an alternative but that is what it did by default. I was just building on my regular OpenRC install on my Dell E7470, not in a clean chroot, which has a 4th generation I7 CPU, a low power consumption type so only 4 threads available as this is a lightweight portable laptop. I built on the HDD not in /tmp and RAM, after building I only have about 16GB free space on the partition, there was less than 64GB even adding free HDD space when I started, swap and RAM together.
I forgot I'd done this, but before the second attempt I downgraded rust to rust-1 1.71.0-1-x86_64.pkg.tar.zst from the Artix archive, as this predates the problem versions and my first try failed during a rustc bit. My /etc/makepkg.conf is unmodified.
The other slightly non-standard thing was just making clean copies for comparison and further attempts without redownloading.
$ git clone https://aur.archlinux.org/librewolf.git
$ cp -a librewolf/ vanillalibrewolf/
$ cd librewolf
$ makepkg -so
$ cd ..
$ sudo cp -a librewolf/ makepkg-o-librewolf/
$ cd librewolf/
$ makepkg -e
# Maintainer: ohfp/lsf <lsf at pfho dot net>
pkgname=librewolf
_pkgname=LibreWolf
pkgver=117.0
pkgrel=1
pkgdesc="Community-maintained fork of Firefox, focused on privacy, security and freedom."
url="https://librewolf.net/"
arch=(x86_64 aarch64)
license=(
GPL
LGPL
MPL
)
depends=(
dbus-glib
ffmpeg
gtk3
libpulse
libxss
libxt
mime-types
nss
ttf-font
)
makedepends=(
binutils
cbindgen
clang
diffutils
dump_syms
git
imake
inetutils
jack
lld
llvm
mesa
nasm
nodejs
pciutils
python
rust
unzip
'wasi-compiler-rt>15'
'wasi-libc++>15'
'wasi-libc++abi>15'
'wasi-libc>=1:0+314+a1c7c2c'
xorg-server-xvfb
yasm
zip
) # pciutils: only to avoid some PGO warning
optdepends=(
'hunspell-en_US: Spell checking, American English'
'libnotify: Notification integration'
'networkmanager: Location detection via available WiFi networks'
'pulseaudio: Audio support'
'speech-dispatcher: Text-to-Speech'
'xdg-desktop-portal: Screensharing with Wayland'
)
backup=('usr/lib/librewolf/librewolf.cfg'
'usr/lib/librewolf/distribution/policies.json')
options=(
!debug
!emptydirs
!lto
!makeflags
!strip
)
_arch_git=https://raw.githubusercontent.com/archlinux/svntogit-packages/packages/firefox/trunk
_arch_git_blob=https://raw.githubusercontent.com/archlinux/svntogit-packages
install='librewolf.install'
source=(
https://gitlab.com/api/v4/projects/32320088/packages/generic/librewolf-source/${pkgver}-${pkgrel}/librewolf-${pkgver}-${pkgrel}.source.tar.gz # {,.sig} sig files are currently broken, it seems
$pkgname.desktop
"default192x192.png"
"0018-bmo-1516081-Disable-watchdog-during-PGO-builds.patch"
)
sha256sums=('446e9479547dceda58cbcdc2f9f503539086ddb193c8b1206b7c736cd56e44c3'
'7d01d317b7db7416783febc18ee1237ade2ec86c1567e2c2dd628a94cbf2f25d'
'959c94c68cab8d5a8cff185ddf4dca92e84c18dccc6dc7c8fe11c78549cdc2f1'
'1d713370fe5a8788aa1723ca291ae2f96635b92bc3cb80aea85d21847c59ed6d')
validpgpkeys=('034F7776EF5E0C613D2F7934D29FBD5F93C0CFC3') # maltej(?)
# change this to false if you do not want to run a PGO build for aarch64 or x86_64
_build_profiled_aarch64=false
_build_profiled_x86_64=false
prepare() {
mkdir -p mozbuild
cd librewolf-$pkgver-$pkgrel
mv mozconfig ../mozconfig
cat >>../mozconfig <<END
# TODO: check things here one after another if (still) required
ac_add_options --enable-linker=lld
ac_add_options --prefix=/usr
ac_add_options --disable-bootstrap
export CC='clang'
export CXX='clang++'
# Branding
ac_add_options --with-app-name=${pkgname}
# is this one required? upstream lw doesn't use it
ac_add_options --enable-update-channel=release
# unlear?
# ac_add_options --with-app-basename=${_pkgname}
# needed? yep.
export MOZ_APP_REMOTINGNAME=${_pkgname}
# System libraries
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
# Features
# keep alsa option in here until merged upstream
ac_add_options --enable-alsa
ac_add_options --enable-jack
# options for ci / weaker build systems
# mk_add_options MOZ_MAKE_FLAGS="-j4"
# ac_add_options --enable-linker=gold
# wasi
ac_add_options --with-wasi-sysroot=/usr/share/wasi-sysroot
END
if [[ $CARCH == 'aarch64' ]]; then
cat >>../mozconfig <<END
# taken from manjaro build:
ac_add_options --enable-optimize="-g0 -O2"
END
export MOZ_DEBUG_FLAGS=" "
export CFLAGS+=" -g0"
export CXXFLAGS+=" -g0"
export RUSTFLAGS="-Cdebuginfo=0"
# we should have more than enough RAM on the CI spot instances.
# ...or maybe not?
export LDFLAGS+=" -Wl,--no-keep-memory"
else
cat >>../mozconfig <<END
# Arch upstream has it in their PKGBUILD, ALARM does not for aarch64:
ac_add_options --disable-elf-hack
# might help with failing x86_64 builds?
export LDFLAGS+=" -Wl,--no-keep-memory"
END
fi
# upstream Arch fixes
# pgo improvements
# TODO: test if still required
# patch -Np1 -i ../0018-bmo-1516081-Disable-watchdog-during-PGO-builds.patch
}
build() {
cd librewolf-$pkgver-$pkgrel
export MOZ_NOSPAM=1
export MOZBUILD_STATE_PATH="$srcdir/mozbuild"
export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=pip
# export PIP_NETWORK_INSTALL_RESTRICTED_VIRTUALENVS=mach # let us hope this is a working _new_ workaround for the pip env issues?
# LTO needs more open files
ulimit -n 4096
# Do 3-tier PGO
echo "Building instrumented browser..."
if [[ $CARCH == 'aarch64' && $_build_profiled_aarch64 == true ]]; then
cat >.mozconfig ../mozconfig - <<END
ac_add_options --enable-profile-generate
END
elif [[ $CARCH == 'x86_64' && $_build_profiled_x86_64 == true ]]; then
cat >.mozconfig ../mozconfig - <<END
ac_add_options --enable-profile-generate=cross
END
fi
if [[ $CARCH == 'aarch64' && $_build_profiled_aarch64 == true || $CARCH == 'x86_64' && $_build_profiled_x86_64 == true ]]; then
./mach build
echo "Profiling instrumented browser..."
./mach package
LLVM_PROFDATA=llvm-profdata \
JARLOG_FILE="$PWD/jarlog" \
xvfb-run -s "-screen 0 1920x1080x24 -nolisten local" \
./mach python build/pgo/profileserver.py
stat -c "Profile data found (%s bytes)" merged.profdata
test -s merged.profdata
stat -c "Jar log found (%s bytes)" jarlog
test -s jarlog
echo "Removing instrumented browser..."
./mach clobber
echo "Building optimized browser..."
if [[ $CARCH == 'aarch64' ]]; then
cat >.mozconfig ../mozconfig - <<END
ac_add_options --enable-lto
ac_add_options --enable-profile-use
ac_add_options --with-pgo-profile-path=${PWD@Q}/merged.profdata
ac_add_options --with-pgo-jarlog=${PWD@Q}/jarlog
END
else
cat >.mozconfig ../mozconfig - <<END
ac_add_options --enable-lto=cross
ac_add_options --enable-profile-use=cross
ac_add_options --with-pgo-profile-path=${PWD@Q}/merged.profdata
ac_add_options --with-pgo-jarlog=${PWD@Q}/jarlog
END
fi
fi
if [[ $CARCH == 'aarch64' && $_build_profiled_aarch64 == false || $CARCH == 'x86_64' && $_build_profiled_x86_64 == false ]]; then
cat >.mozconfig ../mozconfig
fi
./mach build
echo "Building symbol archive..."
./mach buildsymbols
}
package() {
cd librewolf-$pkgver-$pkgrel
DESTDIR="$pkgdir" ./mach install
# mv ${pkgdir}/usr/local/lib ${pkgdir}/usr/lib/
# mv ${pkgdir}/usr/local/bin ${pkgdir}/usr/bin/
# rm -r ${pkgdir}/usr/local
local vendorjs="$pkgdir/usr/lib/$pkgname/browser/defaults/preferences/vendor.js"
install -Dvm644 /dev/stdin "$vendorjs" <<END
// Use system-provided dictionaries
pref("spellchecker.dictionary_path", "/usr/share/hunspell");
// Don't disable extensions in the application directory
// done in librewolf.cfg
// pref("extensions.autoDisableScopes", 11);
END
local distini="$pkgdir/usr/lib/$pkgname/distribution/distribution.ini"
install -Dvm644 /dev/stdin "$distini" <<END
[Global]
id=io.gitlab.${pkgname}-community
version=1.0
about=LibreWolf
[Preferences]
app.distributor="LibreWolf Community"
app.distributor.channel=$pkgname
app.partner.librewolf=$pkgname
END
for i in 16 32 48 64 128; do
install -Dvm644 browser/branding/${pkgname}/default$i.png \
"$pkgdir/usr/share/icons/hicolor/${i}x${i}/apps/$pkgname.png"
done
# install -Dvm644 browser/branding/librewolf/content/about-logo.png \
# "$pkgdir/usr/share/icons/hicolor/192x192/apps/$pkgname.png"
install -Dvm644 ${srcdir}/default192x192.png \
"$pkgdir/usr/share/icons/hicolor/192x192/apps/$pkgname.png"
# arch upstream provides a separate svg for this. we don't have that, so let's re-use 16.png
install -Dvm644 browser/branding/${pkgname}/default16.png \
"$pkgdir/usr/share/icons/hicolor/symbolic/apps/$pkgname-symbolic.png"
install -Dvm644 ../$pkgname.desktop \
"$pkgdir/usr/share/applications/$pkgname.desktop"
# Install a wrapper to avoid confusion about binary path
install -Dvm755 /dev/stdin "$pkgdir/usr/bin/$pkgname" <<END
#!/bin/sh
exec /usr/lib/$pkgname/librewolf "\$@"
END
# Replace duplicate binary with wrapper
# https://bugzilla.mozilla.org/show_bug.cgi?id=658850
ln -srfv "$pkgdir/usr/bin/$pkgname" "$pkgdir/usr/lib/$pkgname/librewolf-bin"
# Use system certificates
local nssckbi="$pkgdir/usr/lib/$pkgname/libnssckbi.so"
if [[ -e $nssckbi ]]; then
ln -srfv "$pkgdir/usr/lib/libnssckbi.so" "$nssckbi"
fi
}
I updated and tried again, with the latest Rust and using the standard --enable-lto=cross,full this time, although still not the PGO bit and using the existing src and PKGBUILD I'd downloaded before to save a bit of time, and it built fine again. At various points in the build, including near the start, it has a message like this which could be worth checking if it gives the right result for your system:
Parallelism determined by memory: using 4 jobs for 4 cores based on 7.7 GiB RAM and estimated job size of 1.0 GiB
0:27.40 /usr/bin/make -f client.mk -j4 -s
The build clearly detects and adapts itself to the hardware, so that is something to consider, whether that is going wrong. Possibly it could be some complication from chroots, containers, vm's or something? Or some hardware specific memory management issue, perhaps try different kernel versions? I used the linux-zen kernel, 6.5.2-zen1-1-zen.
Building librewolf seems jinxed somehow; now the error is:
Site not up-to-date reason: "/build/librewolf/src/mozbuild/srcdirs/librewolf-117.0.1-1-cfe13ca7d490/_virtualenvs/common" does not exist
AFTER MACH PACKAGE
Firefox exited with code -4 during profile initialization
The mentioned directory does exist prior to the time of the error, and is owned and accessible by the build user.
Tried with 1 job and with 12 jobs, tried version 117.0 and version 117.0.1, also tried with gcc.
Even replaced the complete build code block with that from firefox.
There are many bugs and reports related to this error, but alas no clear fix.
artist
There doesn't seem to be much noise over on Librewolf's Arch Issues Page regarding failures to build:
https://codeberg.org/librewolf/issues/issues.
I did find one issue made regarding a build attempt for Endeavor OS:
https://codeberg.org/librewolf/issues/issues/1597
But am unsure if that even remotely helps as the issue poster just dumped the compile logs...
I mean, I'm happy to just grab it from the AUR, and worse case scenario I can simply heavily configure Vanilla Firefox, I just liked having some of the work done for me out of the box.
My sincere thanks go out to the Artix devs for the extensive work and explanations though. Always appreciate the insights and hard work.
If it needs 128GB of ram maybe adding 128GB of swap?
Trouble with AUR:
trizen -S librewolf-bin
[...]
==> Verifying source file signatures with gpg...
librewolf-117.0.1-1-linux-x86_64-package.tar.bz2 ... FAILED (unknown public key 8A74EAAF89C17944)
==> ERROR: One or more PGP signatures could not be verified!
:: Unable to build librewolf-bin - makepkg exited with code: 1
=>> Try again? [y/N]:
I'd like to use the one made by Garuda anyway: https://archlinux.pkgs.org/rolling/chaotic-aur-x86_64/librewolf-117.0.1-1-x86_64.pkg.tar.zst.html.
Linking attemtps to allocate ram, and only a limited amount of swap helps.
Garuda also creates firedragon iirc, which builds fail even more often than librewolf; hence firedragon was already dropped earlier.
We would need to file a bug against librewolf to get this - the build now works in 32GB of ram, but the mach package inside librewolf's build errors out - fixed properly, which I might do when I have no other priorities.
artist
Try with Chaotic-AUR :
https://aur.chaotic.cx/
trizen librewolf
1 chaotic-aur/firedragon 117.0.1-1.1
Librewolf fork build using custom branding, settings & KDE patches by OpenSUSE
2 chaotic-aur/librewolf 117.0.1-1
Community-maintained fork of Firefox, focused on privacy, security and freedom.
3 chaotic-aur/librewolf-extension-gnome-shell-integration 10.1-1.3
GNOME shell integration addon for Librewolf
4 chaotic-aur/librewolf-extension-plasma-integration 1.8.1-2.4
Package firedragon 118.0 is now in the omniverse repository.
Its build quality improved over the past two months and if this continues - and does not hamper our build system like librewolf - it might be moved to galaxy at some time.
artist
Can I fetch LW x86_64 and aarch64 from garuda repo?
Found this only https://repo.garudalinux.org/.
Chaotic-AUR is mabe by them so?
Can I fetch it from there? Without adding the repo.
it' possible to install it wihout adding the repo. look at wiki (https://wiki.archlinux.org/title/Pacman#Additional_commands)
Yes but I didn't know what path use.
I now found it: https://builds.garudalinux.org/repos/chaotic-aur/x86_64/#librewolf.
Only x86_64.
I installed librewolf-bin from AUR, and it seems to have worked.
--makepkg returned "unknown gpg key" error so I had to run gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 8A74EAAF89C17944
--makepkg took a little over 1 minute. (4-core 1.6GHz processor, 4G memory, 4G swap)
--pacman -U librewolf-bin-118.0.2-1-x86_64.pkg.tar.zst produced ":: librewolf-bin and librewolf are in conflict. Remove librewolf? [y/N]" I said "y" and my links and profiles still work, I'm in librewolf 118.0.2-1
Please let me know if I've done something stupid. ::)
AUR packages are made by LW dev right?
Can this help maybe https://github.com/rui314/mold/issues/1085 ?
About that somebody said:
Tried that already, without success.
artist
I see that it is back in omniverse repo since some time already.
Will it make it to galaxy someday?
Librewolf at current moment is in galaxy.
Nice.
I do not see it in ARMtix but at least it's back for Artix.