Search Criteria
Package Details: librewolf 101.0.1-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/librewolf.git (read-only, click to copy) |
|---|---|
| Package Base: | librewolf |
| Description: | Community-maintained fork of Firefox, focused on privacy, security and freedom. |
| Upstream URL: | https://librewolf.net/ |
| Keywords: | browser web |
| Licenses: | GPL, MPL, LGPL |
| Submitter: | lsf |
| Maintainer: | lsf |
| Last Packager: | lsf |
| Votes: | 67 |
| Popularity: | 5.18 |
| First Submitted: | 2019-06-14 18:41 (UTC) |
| Last Updated: | 2022-06-11 14:33 (UTC) |
Dependencies (41)
- dbus-glib (dbus-glib-git)
- ffmpeg (ffmpeg-v4l2-request-git, ffmpeg-nox-git, ffmpeg-svt-vp9-git, ffmpeg-intel-full-git, ffmpeg-yt-dlp-bin, ffmpeg-amd-full, ffmpeg-decklink, ffmpeg-shinobi, ffmpeg-git, ffmpeg-ndi, ffmpeg-full, ffmpeg-full-git, ffmpeg-libfdk_aac, ffmpeg-headless, ffmpeg-obs, ffmpeg-vulkan, ffmpeg-cuda, ffmpeg-mmal, ffmpeg-amd-full-git, ffmpeg-nocuda)
- gtk3 (gtk3-git, gtk3-typeahead, gtk3-patched-filechooser-icon-view, gtk3-no_deadkeys_underline, gtk3-classic, gtk3-classic-noatk-64, gtk3-ubuntu)
- libpulse (libpulse-bluedio, pulseaudio-pali, pulseaudio-dummy, libpulse-nosystemd-git, libpulse-nosystemd, libpulse-nosystemd-minimal-git, libpulse-airplay, pulseaudio-git)
- libxt
- mime-types (mailcap-mime-types, mailcap)
- nss (nss-hg)
- ttf-font (neuropol-ttf, ttf-noto-fonts-ib, ttf-win7-fonts, ttf-ms-win8, ttf-ms-win8-arabic, ttf-ms-win8-hebrew, ttf-ms-win8-sea, ttf-ms-win8-indic, ttf-ms-win8-japanese, ttf-ms-win8-korean, ttf-ms-win8-zh_cn, ttf-ms-win8-zh_tw, ttf-ms-win8-thai, ttf-ms-win8-other, ttf-noto-fonts-simple, ttf-kids, ttf-gabriola, ttf-liberation-sans-narrow, ttf-cavafy-script, ttf-ms-fonts, ttf-dejavu-ib, ttf-zelda, ttf-oxygen, ttf-oxygen-gf, ttf-share-gf, ttf-gost, otf-inconsolata-dz, ttf-d2coding, ttf-ibm-plex-mono-git, ttf-dejavu-emojiless, ttf-agave, ttf-caracteres, ttf-cuprum, ttf-autour-one, ttf-impallari-milonga, ttf-impallari-miltonian, ttf-clarity-city, ttf-paratype, ttf-segoewp, ttf-karla, ttf-ms-win10, ttf-ms-win10-japanese, ttf-ms-win10-korean, ttf-ms-win10-sea, ttf-ms-win10-thai, ttf-ms-win10-zh_cn, ttf-ms-win10-zh_tw, ttf-ms-win10-other, ttf-win10, ttf-droid-simple, nerd-fonts-dejavu-complete, ttf-ms-win11, ttf-ms-win11-japanese, ttf-ms-win11-korean, ttf-ms-win11-sea, ttf-ms-win11-thai, ttf-ms-win11-zh_cn, ttf-ms-win11-zh_tw, ttf-ms-win11-other, ttf-ms-win10-auto, ttf-ms-win11-auto, ttf-ms-win10-cdn, noto-fonts-variable-lite, ttf-bmono, ttf-plemoljp, noto-fonts-lite, gnu-free-fonts, noto-fonts, ttf-bitstream-vera, ttf-croscore, ttf-dejavu, ttf-droid, ttf-ibm-plex, ttf-liberation)
- autoconf2.13 (make)
- binutils (binutils-git, binutils-2.35.2) (make)
- cbindgen (make)
- clang (clang8, llvm-minimal-git, llvm-git, clang-git) (make)
- diffutils (diffutils-git, diffutils-patched-exclude-directory-git) (make)
- dump_syms (dump_syms-git) (make)
- git (git-git, git-vfs, git-run-command-patch-git) (make)
- imake (make)
- inetutils (gettext-hostname, inetutils-git) (make)
- jack (jack-git, jack2-git, pipewire-common-jack-git, pipewire-full-jack-git, pipewire-jack-git, jack2, pipewire-jack) (make)
- lld (llvm-git) (make)
- llvm (llvm8, llvm-minimal-git, llvm-git) (make)
- Show 21 more dependencies...
Required by (7)
Sources (8)
- 0018-bmo-1516081-Disable-watchdog-during-PGO-builds.patch
- 0032-bmo-1773259-cbindgen-root_clip_chain-fix.patch
- default192x192.png
- git+https://gitlab.com/librewolf-community/browser/source.git#commit=414f21962832bb861d8878a1a32d65f9eae5df54
- git+https://gitlab.com/librewolf-community/settings.git#tag=6.5
- https://archive.mozilla.org/pub/firefox/releases/101.0.1/source/firefox-101.0.1.source.tar.xz
- https://archive.mozilla.org/pub/firefox/releases/101.0.1/source/firefox-101.0.1.source.tar.xz.asc
- librewolf.desktop
Latest Comments
franz commented on 2022-06-26 21:05 (UTC)
Hi. I have the same error as https://aur.archlinux.org/packages/librewolf#comment-864414:
How can i solve this? Thx
I'm on Manjaro x64, Linux 5.14, installing using
yay -S librewolfdr460nf1r3 commented on 2022-05-25 09:16 (UTC)
Hey :) I'm having issues building Librewolf on Chaotic-AUR, currently the build fails after profiling. Any idea what might causing this? (full logs)
HC6505 commented on 2022-05-16 15:41 (UTC)
Setting to pip, make it build here to: export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=pip
Kimble commented on 2022-05-14 05:33 (UTC) (edited on 2022-05-14 05:34 (UTC) by Kimble)
Have this error, could anybody explain what's wrong and what should I do?
Morninwood commented on 2022-05-10 12:20 (UTC)
Changing
MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCEfrom system to pip fixed "The "mach" site is not compatible with the installed system Python packages." error for me.lsf commented on 2022-05-10 09:44 (UTC) (edited on 2022-05-10 09:55 (UTC) by lsf)
Hm. Seems like my assumption that the pip/py environment issues were finally addressed upstream were wrong Oo
I need to look into that.
A workaround might be to build in a clean chroot until I've found a solution.
/edit
gentoo adds an additional
PIP_NETWORK_INSTALL_RESTRICTED_VIRTUALENVS=machenv var to their ebuild – that might be worth a try until I've looked into this further and/or dug up some patches.faceless33 commented on 2022-05-10 09:19 (UTC) (edited on 2022-05-10 09:20 (UTC) by faceless33)
one of my python packages is newer than expected:
What is a workaround?
prg commented on 2022-05-07 00:25 (UTC) (edited on 2022-05-07 18:28 (UTC) by prg)
I realize that the python-pip issues are supposed to be worked out, but I'm still running into an issue. I am building on a VM that does build other python packages, so I'm not sure if that's part of the issue. If i'm reading this correctly, "pip check" is complaining about the version of pip that the install scripts installed?
For reference, python-pip is not installed on the system (to prevent issues with librewolf) and all other packages are up to date.
Edit: Output below is without python-pip installed, but I get the same error even with python-pip installed on the system.
edit2: To attempt to get around the "pip check" step of the build process, I created a new build VM, however the build failed again because "salt" from [community] was installed. The "pip check" complained that salt required psutil, but it was not installed. However, if I install python-psutil, the build will fail with the original error message above. In order to work around this, I completely uninstalled salt which allowed "pip check" to not bomb out and let the build continue.
I think the current solution needs some work - "pip check" should not be failing because a package unrelated to librewolf like salt does not have all of the deps pip thinks it needs installed. Especially when installing that depedency would cause the librewolf pip check to fail.
I have the means to be able to compile this in a controlled environment, but it would an objective improvement if the librewolf mach scripts didn't always bomb out if "pip check" fails because of something unrelated to the librewolf build
lsf commented on 2022-05-01 09:10 (UTC)
Yep – thanks for notifying me. Added the updated patch now as well :)
lahwaacz commented on 2022-05-01 06:05 (UTC)
The checksum for
0031-pgo-use-toolchain-disable-watchdog-fix-on-gcc.patchwas updated in the last commit without any changes to the patch. Did you forget to commit something?dr460nf1r3 commented on 2022-04-17 06:54 (UTC)
Bumping the pkgrel due to
icuupdate would be great! :)lsf commented on 2022-04-02 09:18 (UTC)
A quick note regarding the pip / python related issues: There's an issue (and hopefully a solution with the latest PKGBUILD as well) over at https://gitlab.com/librewolf-community/browser/arch/-/issues/76 to track this, if it's still an issue even with the recent changes.
dann-merlin commented on 2022-03-25 20:01 (UTC)
I suggest removing this line:
(line 248)
This package will not compile (for me) otherwise, even in a chroot, because of pip errors (see whynothugo's problem).
Setting the 1 to 0 does not help btw, as the existence of the variable is checked. not the value.
whynothugo commented on 2022-03-24 21:20 (UTC)
Sorry, didn't clarify, this is on
aarch64, on archlinuxarm/asahi-linux.whynothugo commented on 2022-03-24 19:21 (UTC)
Running in a clean chroot (with
paru -S --chroot) yields this:Removing
python-pipis tricky because it's a transitive dependency.parkus commented on 2022-03-20 13:24 (UTC)
I was then getting this error:
and used lsf's suggestion of removing python-pip for the duration of the build and it appeared to have worked but I am now getting this error:
I will now try to build it in a clean chroot environment, instead..
parkus commented on 2022-03-20 13:17 (UTC) (edited on 2022-03-20 13:18 (UTC) by parkus)
I was trying to build this AUR and I got the following error:
I had to run the following command to fix it:
lsf commented on 2022-03-12 11:50 (UTC)
That's probably because the MR that was pointing to got merged (and doesn't exist anymore, as I was force pushing to update the MR / branch…).
If you can wait just a tiiiiny bit longer, I'll probably update the AUR packages today vor 98.0 – I've had some nasty issues getting the
aarch64build working, which is why things are delayed a bit.If you're in a rush, you could probably just grab the latest PKGBUILD from https://gitlab.com/librewolf-community/browser/arch/-/blob/master/PKGBUILD and see if that works for you! :)
TexasRancher commented on 2022-03-12 11:13 (UTC) (edited on 2022-03-12 16:26 (UTC) by TexasRancher)
I'm trying to update
librewolfafter I installed it a few months ago withyayand I get this error now:==> Validating source files with sha256sums... firefox-97.0.2.source.tar.xz ... Passed firefox-97.0.2.source.tar.xz.asc ... Skipped librewolf.desktop ... Passed source ... Skipped settings ... Skipped default192x192.png ... Passed ==> Verifying source file signatures with gpg... firefox-97.0.2.source.tar.xz ... Passed ==> Removing existing $srcdir/ directory... ==> Extracting sources... -> Extracting firefox-97.0.2.source.tar.xz with bsdtar -> Creating working copy of source git repo... Cloning into 'source'... done. fatal: reference is not a tree: 272f05d69b40953729bf05a1d7acda69f30804e6 ==> ERROR: Failure while creating working copy of source git repo Aborting...Any ideas? Edit: @lsf: thank you, the issue has been resolved!
lahwaacz commented on 2022-03-07 20:43 (UTC)
@prg If you use fewer cores/threads for your virtual machine, you can likely get away with less memory.
prg commented on 2022-03-07 18:56 (UTC) (edited on 2022-03-07 18:57 (UTC) by prg)
@Eile I have been using a VM with 14GB of RAM to regularly compile librewolf, but as of 97.0.2 the librewolf build process is using more memory than before and is getting OOM-killed during the build.
Perhaps something changed in the firefox build scripts in this most recent version that require more memory ?
Eile_Kerning commented on 2022-03-01 16:04 (UTC) (edited on 2022-03-01 16:11 (UTC) by Eile_Kerning)
Apologies, librewolf fails to build. I am not using a chroot, simply running makepkg -sCcr. Here is the log: https://gist.github.com/Orangian/01153fc924511ca7be4d181640c8f774
Any help would be much appreciated!
edit: Whoops! Appears to be my fault. The system is killing the compilation due to me running out of memory. 16 GiB is apparently not enough.
edit2: I have 14 GiB free at time of compile, should that be enough?
lsf commented on 2022-02-04 10:56 (UTC)
Ah, yeah – unfortunately, pgp verification in the chroot is a bit… complicated.
To skip it, you could just run
makechrootpkg -c -r /chroot/path/wherever -- --skippgpcheck(assuming you run it withmackechrootpkg, with paru it would be something with--mflags, iirc, or maybe even "just"--skippgpcheck) – this will pass the option to the chrootedmakepkgto skip it.Jayman commented on 2022-02-04 10:20 (UTC)
I’m trying to build
librewolfin a clean chroot, but I’m getting the following error:lsf commented on 2022-02-02 09:20 (UTC)
Hm, that's really odd stuff.
It seems for some users just removing
python-pipfor the duration of the build might've done the trick, but in the end that's probably something that needs to be addressed upstream.I'd recommend building in a clean chroot (as described in https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot or with
paru, which supports chroot building directly) – that should avoid any kind of conflicts with anything installed on the base system.0x81 commented on 2022-01-31 07:48 (UTC)
Same issue.
MACH_USE_SYSTEM_PYTHONis no help for me either.This is probably be due to this change:
https://phabricator.services.mozilla.com/rMOZILLACENTRALca4d439114f34488f746c60ee022ebce1204552a
Kimble commented on 2022-01-28 17:25 (UTC) (edited on 2022-01-28 17:32 (UTC) by Kimble)
At least one month I have this issue,
export MACH_USE_SYSTEM_PYTHON=0doesn't help at allginnokami commented on 2022-01-22 13:38 (UTC)
So I updated the
MACH_USE_SYSTEM_PYTHONflag to 0, but when building I get the exact same issue as I had before (with the only difference being the updated firefox version number 96.0.2).lsf commented on 2022-01-22 10:58 (UTC)
I am not certain why this kind of errors only crops up now, but a quick workaround might just be to change line 222 in the PKGBUILD (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=librewolf#n220) to
export MACH_USE_SYSTEM_PYTHON=0. That should stop it from trying to use any system-wide packages/python completely.tyler19820201 commented on 2022-01-22 10:47 (UTC)
Same issue here also
ginnokami commented on 2022-01-16 15:52 (UTC)
When building for 96 I no longer have the pip issue, but I now get the following once the build starts.
Any thoughts or suggestions? It really seems to me that the upgrade to python 3.10 is really hurting this build system, as I never had any issues building this before the upgrade.
lahwaacz commented on 2022-01-13 06:52 (UTC) (edited on 2022-01-13 06:53 (UTC) by lahwaacz)
@D1sturbed You can edit your past comment and fix the formatting...
Beomus commented on 2022-01-13 03:55 (UTC)
@Neko-san sorry, i'm a little bit retarded..
Neko-san commented on 2022-01-13 03:54 (UTC)
Paru is an AUR helper Lol
You don't need to download the source, just do
paru -Sa librewolf --skipreviewBeomus commented on 2022-01-13 03:36 (UTC)
@Neko-san so download the source code elsewhere? sorry, i'm just trying to clarify.
Neko-san commented on 2022-01-13 03:34 (UTC)
@D1sturbed You want to make the local repo path something different from paru's cache; give it its own folder
Beomus commented on 2022-01-13 03:00 (UTC)
damn.. encasing code in three single quotes doesn't format it like that, maybe i should've read that it's markdown format lol...
Beomus commented on 2022-01-13 02:54 (UTC)
@Neko-san I was trying to install it through paru with LocalRepo and Chroot enabled in paru.conf..
should i add
''' [aur] (<= name this whatever you want) SigLevel = PackageOptional DatabaseOptional Server = file:///home/disturbed/.cache/paru/clone/librewolf ''' or should i download the package to another directory and compile there?
Neko-san commented on 2022-01-12 17:21 (UTC) (edited on 2022-01-12 17:22 (UTC) by Neko-san)
@D1sturbed There's two ways to do so:
The official way: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
And the way I do it: https://github.com/Morganamilo/paru
Paru is an AUR helper but it has support for automating
chrooting for building packages.To do so with paru, you need to do the following:
install
devtoolsenable "LocalRepo" and "Chroot" (needs to be set to a directory) in
/etc/paru.confAdd the following to the bottom of
pacman.conf:Paru should take care of the rest on its own
Beomus commented on 2022-01-12 12:32 (UTC)
@Neko-san
i'm having the same issue with pip, and don't know how to build in a chroot.. Can you point me in the way of some helpful resources regarding that please?
lsf commented on 2022-01-12 10:26 (UTC)
Might've actually just been adding
!ltoto options – for reasons unknown (to me at least, didn't yet do any proper research into why ;), that now seems to be required for quite a few packages using rust/cargo. Or might've not been the reason (as it worked in my chroot) – who knows.For now though I just hope things will work again for you with 96.0-1 – if not, don't hesitate to comment again! :)
3np commented on 2022-01-10 19:06 (UTC)
@lsf Apologies and thanks for setting me straight!
Did you also run in a fresh chroot? I wonder if there's some base rust dependency that's implicit and missing...
Anyway, this is a quite fresh environment (only installed Arch the other day; built a decent number of other AUR packages with rust in the chroot since). Building via
aurutils -cT. Thepacman-custom.confis just the official repos plus my own local with aur artefacts - nothing that is overriding there either.Will return to this shortly.
lsf commented on 2022-01-10 17:31 (UTC)
Please don't mark the package out of date for an issue like this – that's not what the function is for, and I got a notification of your regular comment just fine :)
I cannot reproduce this on my end (and as far as I can see none of the "relevant" dependencies seem to have changed / been updated in the repos).
Is there anything 'unusual' with your environment / chroot? (maybe a separately installed package; maybe you're on manjaro; maybe the mirrorlist in it is out of date so it couldn't be properly updated?) If all else failed, I'd try to cleanly set the chroot up anew and check if you still have the issue then.
3np commented on 2022-01-10 13:58 (UTC) (edited on 2022-01-10 13:59 (UTC) by 3np)
This won't build in a chroot for me, seems to be something missing for rust:
Related issues:
https://github.com/rust-lang/rust/issues/43264
https://github.com/rust-lang/rust/issues/74657
https://bugs.llvm.org/show_bug.cgi?id=47872
I haven't resolved it yet. So far I tried substituting
rustforrustupand setting various toolchains and removingac_add_options --enable-lto.Tail of build log: https://gist.github.com/3nprob/4a420a9ee6ae956dd8641de6be32c55f
pdpelf commented on 2021-12-22 15:58 (UTC)
pip check: There is a discussion and a patch: https://bugs.gentoo.org/show_bug.cgi?id=828604
pdpelf commented on 2021-12-22 15:51 (UTC)
Same issue her due to "pip check"!
Neko-san commented on 2021-12-22 13:23 (UTC)
@ginnokami I've had that issue a little while ago too; my solution was just building it in a chroot but I know not everyone knows how to do that
ginnokami commented on 2021-12-22 11:41 (UTC) (edited on 2021-12-22 11:43 (UTC) by ginnokami)
Is anyone else having an issue compiling due to pip check having missing/updated/ dependencies? Running pip check will list some "missing or too updated packages" though all the actual programs run fine, and reinstalling the packages doesn't make the issue go away.
HurricanePootis commented on 2021-12-18 05:33 (UTC)
I think because of the wayland 1.20 update, projects have to update their code for new wayland release
dr460nf1r3 commented on 2021-12-17 06:18 (UTC)
Currently this patch is required for compiling FF95 :)
lahwaacz commented on 2021-12-17 06:07 (UTC) (edited on 2021-12-17 06:09 (UTC) by lahwaacz)
Building 95.0-1 in a clean chroot (with aurutils) just failed for me:
Looks like the same issue @andreas_baumann has...
lsf commented on 2021-12-16 23:15 (UTC)
@karolyi: you'll probably have to build it yourself, yep in the future, yep – the patch is still available over at https://gitlab.com/librewolf-community/browser/common/-/blob/master/patches/allow_dark_preference_with_rfp.patch and is probably relatively simple to maintain: it's only a few tiny changes in the code, and as you can see in the repo there wasn't any need to change it in the past few months at all.
@andreas_baumann: no idea what's going on there – I'd assume it's something with your build environment (although I have no idea what exactly it might be – sorry about that). Things seemed to work fine in the clean dockerized (Arch) build env (https://gitlab.com/librewolf-community/browser/arch/-/jobs/1875446573), which I can always use as a cop-out and a "well it works for me" ;)
karolyi commented on 2021-12-16 21:40 (UTC)
Hey,
I'd like to have the allow_dark_preference_with_rfp.patch back. Is there a way to get it back, or do I need to fork this package and adjust it manually?
andreas_baumann commented on 2021-12-16 07:52 (UTC) (edited on 2021-12-16 09:39 (UTC) by andreas_baumann)
I suspect it's caused by
mach buildsymbols, trying right now..No success, there seems to be a messup in wayland or in the toolchain..
lsf commented on 2021-12-15 19:33 (UTC)
@neko-san: sorry for still not having added your changes to the PKGBUILD… I barely got the regular release done with quite a few days delay this time /o\
…I hope that will improve soon – I'll get to it! ^^
=> python-pip shouldn't be required as a dependency, though – I build the official releases not in a chroot, but in a freshly spun up docker container (https://gitlab.com/librewolf-community/browser/arch/-/jobs/1875446573 for the current one), so something like that should fail in there as well, I think.
Neko-san commented on 2021-12-12 09:21 (UTC) (edited on 2021-12-12 23:05 (UTC) by Neko-san)
~~And now, for some reason I don't understand, what I said still works but it doesn't work inside of a
chroot(with Paru) for some reason I can't understand~~One would think the opposite would make it build but no, somehow
EDIT: Seems it was because
python-pipis a dependency nowNeko-san commented on 2021-11-22 18:14 (UTC) (edited on 2021-11-22 18:16 (UTC) by Neko-san)
1)
options+=(!lto)- this makes sure that any user's globalltopacman/makepkg flag is overriden to stay off; this will throw errors if not done and the global is on2) add
ac_add_options --enable-linker=lldbefore the "instrumental build"; this is what was preventing compilation for me in the first place3) uncomment:
because the builds will throw errors if they're not uncommented
lsf commented on 2021-11-22 09:45 (UTC)
@Neko-san: could you sum up the changes you need in PKGBUILD again?
There are a few things you mentioned that wouldn't necessarily make sense to "globally" change in the PKGBUILD for everyone, but maybe I've missed something / maybe there's a way to conditionally add some of your requirements or something like that :)
Neko-san commented on 2021-11-19 17:43 (UTC)
Also, am I the only one who has Librewolf crashes when opening the settings menu?
Neko-san commented on 2021-11-12 21:32 (UTC)
@lsf not an issue with that but you didn't implement the other PKGBUILD things I mentioned that were necessary :/
lsf commented on 2021-11-12 14:15 (UTC)
For 94.0 a downgrade shouldn't be required anymore – do you still have that issue with the most recent release?
HurricanePootis commented on 2021-11-11 15:36 (UTC) (edited on 2021-11-11 15:36 (UTC) by HurricanePootis)
I temporary downgraded my clang, llvm, lld, compiler-rt to version 12.0.0, and my rust to 1.55 with the command
I was able to successfully compile librewolf with these packages temp downgraded. No need to deal with a chroot.
Neko-san commented on 2021-11-01 01:14 (UTC)
Ah, okay; I might just wait for the next release to start doing it in the chroot - I have the portable instance of
rustupinstalled on my system (though I've not used it much) and managed to get the right toolchain and I managed to compile it with the PKGBUILD changesThanks for testing and telling me that the compiler flags were fine; I have no idea why it decided to assume what linker to use for the instrumented build for you guys without it being declared before then, or why one of the default
makepkg.confflags wasn't throwing LLVM errors for you guys, but that went over my head and I might have not thought of it if you hadn't told melsf commented on 2021-10-31 10:03 (UTC)
When directly using
makechrootpkg, you can just install specific packages for a build by adding-I /path/to/some.pkg.tar.zst. I'm not sure if you can also do that with theparuchrootoption (seems like you could install specific packages before running a build using--chrootctland-i, but I've never tried it – maybe it will be thwarted byparuupdating things?…and if all else failed, that should be fixed with upcoming firefox/librewolf releases – those usually get configured for the newer/current rust versions ^^
Neko-san commented on 2021-10-31 00:39 (UTC)
How do I do that in the
chroot?lsf commented on 2021-10-30 23:30 (UTC)
You might want to try building it with rust 1.55 – the upstream firefox sources probably won't support 1.56 (1.55 was current when librewolf 93.0 was released).
Neko-san commented on 2021-10-30 22:20 (UTC) (edited on 2021-10-30 22:26 (UTC) by Neko-san)
And in the
chroot, it seems to go through fine until it throws a lot of rust errors:I also needed:
enabled to prevent the earlier issue
Neko-san commented on 2021-10-30 19:06 (UTC) (edited on 2021-10-30 22:53 (UTC) by Neko-san)
I finally figured out the reason why, I think? In the first block of configure statements (around where Clang is declared), the "ac" command for adding
lldisn't declared at the time and the build system just refuses to assume what should be used, for some reason. :/(Also, I had to pass
!ltoas a PKGBUILD option [because I have it enabled inmakepkg.conf] or else the "instrumented build" fails in some parts)So, when it gets to the "instrumented" build phase, it doesn't know what to do and fails
I have no idea why it doesn't fail for you guys :/
The "optimized" build part fails for me though but for a different reason:
lsf commented on 2021-10-30 11:15 (UTC)
@Neko-san
Unfortunately, I have no idea what's going wrong here.
I've done a quick test by adding the vars/changes from your modified
makepkg.confto the PKGBUILD directly and then starting a build withmakechrootpkgdirectly (not usingparu), and that went fine and started building properly. (btw: there's a typo in one of your vars, you haveDEBUG_CLAGSin there at some point, instead ofDEBUG_CFLAGS:)So either something totally odd is going on, or it's soooomehow caused by the way
paruusesmakechrootpkg(eg. adding-D /mnt/extraStorage/AUR/ParuChroot/repo/aur -d /var/cache/pacman/pkg/). The changes in themakepkg.conf, as far as I understand them, shouldn't cause such an issue (lld,clangetc are also used by the build anyway, as you've stated already, and all the other ones shouldn't really be relevant for linker functioning).Neko-san commented on 2021-10-29 17:56 (UTC)
I know, I didn't list it as a separate package: read the PKGBUILD
What I said was: "
in the PKGBUILD body"In the body,
lldis referenced in configure statements to be targeted as the used linker; coincidentally, lld is its own package, but that should have no bearing on thecontextI'm mentioning becausebinutilsis a package with multiple components and isn't synonymous with these FireFox configure statements.lahwaacz commented on 2021-10-29 07:09 (UTC)
As I said,
ld(i.e./usr/bin/ld) is provided bybinutils, it is not a separate package. And valid compiler flags still don't mean that the project will successfully compile when they are applied.Neko-san commented on 2021-10-28 21:52 (UTC)
This still failed
And if what you say really wasn't an issue, then explain how changing the
lldreferences in the PKGBUILD body toldcreates an error:Also, that shouldn't make a difference anyway; those are valid compiler flags
lahwaacz commented on 2021-10-28 21:38 (UTC) (edited on 2021-10-28 21:40 (UTC) by lahwaacz)
ldis provided bybinutilswhich is inmakedepends. (It is also part of thebase-develgroup which is an implicit dependency that everybody building Arch packages must have installed.)Anyway, you have also modified
CFLAGS, e.g.-march=native -mtune=native. Try building with the defaultCFLAGS.Neko-san commented on 2021-10-28 21:29 (UTC) (edited on 2021-10-28 21:29 (UTC) by Neko-san)
Sorry, I didn't mention, but LibreWolf tries to compile with Clang by default in the PKGBUILD; compiling it with GCC would theoretically mean that the default should fail to compile on its own :/
I'm still going to try it but this is quite a problem; the GCC linker (
ld) isn't even a make dependency and thus would fail in a chroot too, for that reason alone :/lahwaacz commented on 2021-10-28 20:43 (UTC)
So... try to compile it with GCC?
Neko-san commented on 2021-10-28 19:57 (UTC)
@lsf I tried compiling LibreWolf in a chroot (via
Paru) and the compilation failed :/The only thing that's alike between my bare-metal system and the chroot environment is my
makepkg.conf(which is set to useClanginstead ofGCCandg++) and I have this exact same issue with a fork of LibreWolf calledFireDragon(also on the AUR)I've been trying to compile (FireDragon in particular) for months.
My
makepkg.conf:The terminal output:
lahwaacz commented on 2021-10-09 17:46 (UTC) (edited on 2021-10-09 17:47 (UTC) by lahwaacz)
I've got this error when building version 93.0-1 in a clean chroot:
Edit: oh, wait – somehow the build continues...
neopolitan commented on 2021-10-06 22:42 (UTC)
@Domarius: You're having a problem because you're attempting to compile a web browser from source, which even people that use Gentoo, a source based distribution, are reluctant to do.
I highly recommend seeking out *-bin versions of any browser you want unless you absolutely need to compile it yourself
Domarius commented on 2021-09-16 04:41 (UTC)
Ok, I sat through the Waterfox installation and it was the same thing, but at the end it cleaned up after itself and I got all my space back. I've never seen this kind of long-ass space consuming build for AUR packages before, but perhaps I'm still new to all this. Giving it another go.
Domarius commented on 2021-09-16 02:41 (UTC)
Absolutely insane... I was shocked to see the build was still running after nearly 1 hour, and my space was being eaten up. /var/tmp/pamac-build-domarius/librewolf was taking up 10gb, and still wasn't finished. What the heck is going on here?? I've cancelled the install, deleted that folder, and trying librewolf-bin, or maybe even another browser...
Lappen commented on 2021-07-25 19:55 (UTC)
This but as root, if you have a bad installation.
madjoe commented on 2021-07-24 16:51 (UTC) (edited on 2021-07-24 16:53 (UTC) by madjoe)
This error is caused due to a bad
rustupinstallation (unknown reason).To fix it type:
But unfortunately, even after I fixed this issue, I still couldn't install it on my system since it made my root partition run out of space (even though I still had 16GB available!). I ended up installing
librewolf-bininstead.Hyolobrika commented on 2021-07-24 16:21 (UTC) (edited on 2021-07-24 16:22 (UTC) by Hyolobrika)
@lsf
I tried building in a clean chroot with
buildpkg -cp <folder with PKGBUILD>(I'm on Manjaro) and without the throttling you suggested I do previously. I got the same error.Thanks for the help so far.
lsf commented on 2021-07-23 21:03 (UTC)
Hm, I can only imagine some environment variable for rustup usage messes things up / causes rustup to be called (by default it's not used / needed during the build process, only
rustis needed as a package). You could check for something like this, or try it in a clean chroot ( https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot )madjoe commented on 2021-07-23 19:19 (UTC)
When trying to install on my KDE Plasma, I encountered this error: https://pastebin.com/raw/qR0TUWj2
ZorinArch commented on 2021-07-16 09:16 (UTC)
Hi, please add some patches from
firefox-appmenuto this package to be more friendly with KDE plasma.lsf commented on 2021-06-08 12:12 (UTC)
That shouldn't happen, unless you've changed some settings (like resistfingerprinting) – maybe you could check that?
There have been a few larger changes in the
librewolf.cfgin one of the past few releases – have you checked if maybe yourlibrewolf.cfgis still an old one? (alibrewolf.cfg.pacnewfile should be created if you had changed something in yourlibrewolf.cfgbefore updating the package – a warning/note about this is displayed during the update process, but maybe that was missed somehow).rev.cressy commented on 2021-06-08 11:42 (UTC)
Librewolf 89.0 receives error messages from chase, mewe, and some other web sites to upgrade your browser. For instance Chase gives this message:
We don't support this browser version anymore. Using an updated version will help protect your accounts and provide a better experience.
Update your browser
Whereas the former version there were no complaints
lsf commented on 2021-05-25 09:05 (UTC)
@Hyolobrika: Hm, that's quite odd.
Would you care to give building it in a clean chroot a try (as outlined in https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot )? There might be something in your build environment / system that messes things up. Unfortunately, it's not really a "very helpful" error, so atm I can only give some very vague attempts at how to find out what's going on there / mitigate it – sorry about that!
@Cape
Remember that motion mark is a very specific test of browser performance. Which gets a bit more relevant once you look at canvas / canvas permissions as well as webgl/webgl2 etc. Some of those settings are restricted/changed in LibreWolf, so that's probably where you'd have to start looking at what's causing it – PGO/LTO shouldn't be the cause here.
To give you a starting point: There's an issue open that might be related at https://gitlab.com/librewolf-community/browser/windows/-/issues/54 – if you find something out (eg. which specific settings might trigger that kind of performance degradation in motion mark), it would be great if you could tell us! :)
Cape commented on 2021-05-25 01:14 (UTC)
Wow! So i built this package and performance in motion mark - compared to binary furryfox - is complete garbage!
furryfox score: 364 LibreWolf score: 35
I don't even care, but I'm curious to understand why? This is also a PGO+LTO optimized build, right? Maybe the profile run didn't work as expected? Is there something to look for?
Hyolobrika commented on 2021-05-24 13:31 (UTC)
Tried that separately and together. Neither worked.
lsf commented on 2021-05-20 11:58 (UTC)
That's quite possibly one of those "running out of resources / memory" errors.
You could try limiting the cores used (
mk_add_options MOZ_MAKE_FLAGS="-j4"or even less) or trying to limit memory usage even more withexport LDFLAGS+=" -Wl,--no-keep-memory".Might be something else entirely – but in most cases of "somewhat vague build errors", it seems like it's been a resource issue.
Hyolobrika commented on 2021-05-18 15:34 (UTC)
Fails to build on Manjaro.
rustcnot working. Please help. 5e2c940f6dacje-vv commented on 2021-05-14 01:03 (UTC)
Thanks !
lsf commented on 2021-05-14 00:55 (UTC)
Understood – I'll keep 'em ;)
(I honestly just didn't assume they were needed anymore in the future, but you make a good case – and as long as people are aware of the need to look out for .pacnew files, I see no harm in it :)
je-vv commented on 2021-05-14 00:25 (UTC)
Hi @lsf, pelase do not remove:
See, it's not the same when you just want overwrite some values, which is what including ~/.librewolf/librewolf.overrides.cfg at the end of /usr/lib/librewolf/librewolf.cfg is meant for, than for commenting out some configs from /usr/lib/librewolf/librewolf.cfg, to get the FF default behavior instead.
For example to get safe browsing back, as it works on FF, the best is just comment out the librewolf configs, instead of specifying URLs, and several string values and the like.
I hope you don't remove those backup lines ever, :)
Thanks a lot !
lsf commented on 2021-04-28 13:48 (UTC)
Hm.. good point.
Never had this problem (with this package, at least), so I'd just naively assumed AUR helpers (like paru, in my case) checked for changes to checksums in the
.SRCINFOand re-downloaded files accordingly.To make all this less error prone, it would make sense to follow your hint, I guess, and do it the
way in the next release – thanks!
lahwaacz commented on 2021-04-28 13:38 (UTC)
@lsf Caching sources is a makepkg feature. The names of the patches in this PKGBUILD are not unique and do not even depend on
$pkgver, which causes these failures. See the warning in https://wiki.archlinux.org/index.php/PKGBUILD#sourcelsf commented on 2021-04-28 13:29 (UTC)
It looks like Manjaro caches some of the downloaded source files somewhere – I don't know where it does that (or if you've used another AUR helper which does it / maybe even just used makepkg directly somewhere?). Basically you have to make sure that no leftover files from a previous build (like the
.patchfiles for example) are left so the updated files will be downloaded and used instead of the cached ones – which leads to them not passing the checksum validation here (and which would subsequently lead to a failing build later on, probably).robert1234 commented on 2021-04-28 13:01 (UTC) (edited on 2021-04-28 13:02 (UTC) by robert1234)
Librewolf fails to build on Manjaro Xfce. If anyone can help or fix this, that would be greatly appreciated.
lsf commented on 2021-04-05 20:35 (UTC)
So basically just having
source=and an additionalsource_aarch64=?I did not know this was possible – thanks for pointing that out! :)
FabioLolix commented on 2021-04-05 20:18 (UTC)
It is not needed and that are only 2 patch files, you can use source_aarch64=() for that 2 only
lsf commented on 2021-04-05 20:16 (UTC)
Considering this is used to not download additional files that are not required for non-aarch64 builds, it seems like a reasonable approach to me.
FabioLolix commented on 2021-04-05 19:47 (UTC)
You are using source_aarch64=() and source_x86_64=() which are not needed since you are downloading source code not pre-compiled binaries
ciocio.la commented on 2021-04-04 03:42 (UTC) (edited on 2021-04-06 03:17 (UTC) by ciocio.la)
This package will not build on my 'dual vendor' gpu systems.
JcNils commented on 2021-04-03 21:29 (UTC)
@lsf It is weird!
It worked fine when I installed Librewolf the first time. I guess I might have messed things when I installed some other package.
My TERM is
xterm-256color.I am using the default fish from Manjaro installation.ncursesexists, reinstalling it doesn't seem to fix the terminfo databaseinfocmp -Dreturns/bin/fishThank you very much for pointing me in the right direction, I will investigate it further.
While writing this I realized that the first time I installed Librewolf was not from the terminal, but from the add/remove software. And the first time I tried to update there was an error, but removing the package and installing from there made it work. So I am trying that again.
Right now everything seems to be building fine.
But I still need to figure out why ncurses database doesn't work if I am using
yay -S Librewolffrom terminal.lsf commented on 2021-04-03 20:10 (UTC)
@JcNils that's quite an odd error ^^
Most of the terminfo files are provided by
ncurses, which is required by so many packages that I'd just assume it's installed already, so my only idea would be that you've set an "unusual"$TERMfor which no appropriate terminfo is installed (or$TERMis set by your terminal emulator by something unusual) and the appropriate terminfo is not installed as well (for some terminal emulators separate packages are available, eg.kitty-terminfo,termite-terminfoetc.)That's something I'd look into first and see where that leads you :)
JcNils commented on 2021-04-03 19:13 (UTC)
Hi, I am on Manjaro, and when I try to update or install it I get an error:
could not find terminfo database.env | grep TERMshows that the variable is there.I wonder what is missing.
Full error:
0000000000 commented on 2021-03-30 19:27 (UTC)
should I just throw puter out the window?
https://imgur.com/4jcmzki
what do ty
lsf commented on 2021-03-27 00:27 (UTC) (edited on 2021-03-27 00:28 (UTC) by lsf)
np :)
btw: I've just discovered firedragon yesterday – looks great, and it's cool to see librewolf being adapted and customized! :)
dr460nf1r3 commented on 2021-03-27 00:00 (UTC)
You are totally right, it was an incorrectly cached patch. Sorry for the inconvenience.
lsf commented on 2021-03-26 18:10 (UTC)
@dr460nf1r3 can't reproduce that. If the checksums already fail, that indicates that your build system might use some cached files somewhere? (Only the
unity-menubar.patchhas changed (which isn't applied by default) but even that one applies cleanly for me when doing a fresh checkout ofhttps://aur.archlinux.org/librewolfand runningmakepkgwith the relevant line uncommented.)Considering your logs show
(and not downloading them) that might indeed be a possibility (as in: they're either cached somewhere or provided in a step that's not part of the logs, and something's going wrong at that point).
dr460nf1r3 commented on 2021-03-26 17:18 (UTC)
The PKGBUILD needs fixing, checksums dont match & a patch is failing to apply. Logs available here
haven commented on 2021-03-18 21:51 (UTC)
@lsf yes, thanks, did that, had to rebuild again, but at least I'm ready for the next time :)
lsf commented on 2021-03-18 18:38 (UTC)
You probably just need to remove the
unity-menubar.patch– I'd assume that file is just left over from a previous build and has changed in the meantime, so the checksums don't match anymore. It will get re-downloaded when you runmakepkgagain.Considering rebuilding from scratch: You probably won't be able to avoid it. It might be possible to somehow get it to re-use some parts of the previous build… but I doubt it's feasible / doable for a production build like this.
An alternative would be to just use the prebuilt package instead (https://aur.archlinux.org/packages/librewolf-bin/) if you don't need to build from source.
haven commented on 2021-03-18 18:27 (UTC)
I was trying to upgrade to 86.0.1-1 from 86, but I'm getting next error. I'm using Manjaro. I don't want to rebuild from scratch, since it takes at least an hour for me. I'm new to Linux, please advise.
==> Validating source_x86_64 files with sha256sums... firefox-86.0.1.source.tar.xz ... Passed librewolf.desktop ... Passed common ... Skipped settings ... Skipped megabar.patch ... Passed remove_addons.patch ... Passed context-menu.patch ... Passed unity-menubar.patch ... FAILED ==> ERROR: One or more files did not pass the validity check! Failed to build librewolf
lsf commented on 2021-03-12 13:53 (UTC)
Do you mean the patch for the global menubar?
If so, that patch is still included, but not automatically applied (as it caused issues on quite a few configurations). Those might not be an issue anymore (seems like they only occurred due to another unrelated issue that's fixed by now), but that's not tested yet. It can be applied by just uncommenting the line at https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=librewolf#n153.
dr460nf1r3 commented on 2021-03-12 13:41 (UTC)
Is there a chance of getting the appmenu patch back?
rev.cressy commented on 2021-03-09 14:10 (UTC)
Since the build takes such a long time you might consider changing mkdir mozbuild in the prepare function to mkdir -p mozbuild which would not give a error if you are attempting to rebuild on error or something.
Another solution would be to include the mkdir in a if block like:
if [[ ! -d mozbuild ]]; then mkdir mozbuild fi
just an idea :-)
rev.cressy commented on 2021-03-09 13:57 (UTC)
Is there a way to save the geometry on exit like firefox?
peryngveohlin666 commented on 2021-02-26 19:34 (UTC)
@lsf: doing a clean build fixed it for me, I had the same problem on a previous version so just assumed the shasums weren't updated.
lsf commented on 2021-02-26 16:42 (UTC)
@peryngveohlin666: works on my end. you might want to check if you still have some files from a previous build lying around (in the folder you're running
makepkg, or in the caches ofyay/paru/etc.).peryngveohlin666 commented on 2021-02-26 16:36 (UTC)
==> Validating source_x86_64 files with sha256sums... firefox-86.0.source.tar.xz ... Passed librewolf.desktop ... Passed common ... Skipped settings ... Skipped megabar.patch ... FAILED remove_addons.patch ... Passed context-menu.patch ... Passed unity-menubar.patch ... Passed ==> ERROR: One or more files did not pass the validity check!
cladonia commented on 2021-02-15 23:21 (UTC)
Thank you, it works.
It was this glibc update.
cladonia commented on 2021-02-15 21:43 (UTC)
Hello,
I have 2.32-5 version of glibc
I have no musl installed (and didn't know its existence or what it is). I can install it.
cladonia commented on 2021-02-15 21:37 (UTC)
Here's the output of the librewolf-bin error:
$ librewolf /usr/lib/librewolf/librewolf: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by /usr/lib/librewolf/librewolf)
cladonia commented on 2021-02-15 21:36 (UTC)
Hello,
The bin version doesn't work, the flatpak install librewolf command doesn't work, the AppImage doesn't work
lsf commented on 2021-02-15 21:17 (UTC) (edited on 2021-02-15 21:22 (UTC) by lsf)
No idea what's going wrong there – quite often build failures for Firefox/LibreWolf seem to be due to running out of memory, though. You might want to take a look at a few older comments in here.
Alternatively, something in your build environment might be off – building in a chroot (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot) might help.
Finally, instead of opting for the Flatpak release, there's also a
-bin-release available in the AUR at https://aur.archlinux.org/packages/librewolf-bin/, which might be preferable when running an Arch system :)/edit
Looks like I'm getting slow ;) My comment was directed at @cladonia as well.
cladonia commented on 2021-02-15 21:08 (UTC)
It failed to compile
The details of the failure are as follows:
Exception: Process executed with non-0 exit code 1: ['/usr/bin/python3', '/home/daniel/compil/librewolf/src/firefox-85.0.2/configure.py']
File "/home/daniel/compil/librewolf/src/firefox-85.0.2/python/mozbuild/mozbuild/build_commands.py", line 146, in build return driver.build( File "/home/daniel/compil/librewolf/src/firefox-85.0.2/python/mozbuild/mozbuild/controller/building.py", line 1140, in build config_rc = self.configure( File "/home/daniel/compil/librewolf/src/firefox-85.0.2/python/mozbuild/mozbuild/controller/building.py", line 1525, in configure status = self._run_command_in_objdir( File "/home/daniel/compil/librewolf/src/firefox-85.0.2/python/mozbuild/mozbuild/base.py", line 887, in _run_command_in_objdir return self.run_process(cwd=self.topobjdir, **args) File "/home/daniel/compil/librewolf/src/firefox-85.0.2/python/mach/mach/mixin/process.py", line 176, in run_process raise Exception( ==> ERREUR : Une erreur s’est produite dans build(). Abandon…
La commande 'makepkg --force' a échoué.
I will test flatpak :(
ZorinArch commented on 2021-02-10 03:52 (UTC)
@lsf
plasma-integrationis just manage multimedia and notifications, but openSUSE patches make the browser better KDE integration like global-menu for example.lsf commented on 2021-02-09 23:31 (UTC)
Thanks for spotting that – I must've forgotten to commit the updated file.
Should be fixed now over here as well!
Jayman commented on 2021-02-09 23:12 (UTC)
When I try to build this package, I get an error:
Here's how I avoided the error:
lsf commented on 2021-02-07 13:02 (UTC)
Hm, wouldn't the https://addons.mozilla.org/en-US/firefox/addon/plasma-integration/ extension be sufficient for this? (I have no real idea – just asking to understand it better :)
If the patches would indeed be required: seems it could be relatively painless to include them as well (or at least to include them optionally), assuming they don't break things on non-KDE systems (or have privacy implications).
Would you care to open an issue for this on https://gitlab.com/librewolf-community/browser/linux/ ? That would make it easier to track it and to discuss it with the rest of the team :)
ZorinArch commented on 2021-02-07 12:56 (UTC)
Hi lsf, can you add opensuse patches
https://build.opensuse.org/package/show/mozilla:Factory/MozillaFirefoxfor better KDE integration. Thankslsf commented on 2021-02-01 21:34 (UTC)
I'd recommend double-checking if the menubar-patch is truly not applied, ie. checking if lines 145-148 look like this:
Maybe something got mixed up when you updated your modified PKGBUILD ^^
(the
unity-menubar.patchis the only thing that patches parts of those files causing your errors, also it being commented out is one distinct change between this version and the previous one)lsf commented on 2021-02-01 20:40 (UTC) (edited on 2021-02-01 20:43 (UTC) by lsf)
Have you modified the PKGBUILD in any way?
I've only had that issue (or at least one that looks like it) when building with the not yet updated
unity-menubar.patchapplied (which is why it's currently commented out).Here's the log: https://gitlab.com/librewolf-community/browser/linux/-/jobs/990519675
It might've been a coincidence, though.
Without it, things built fine: https://gitlab.com/librewolf-community/browser/linux/-/jobs/997630646
/edit
Thanks for the hint with the LDFLAGS, btw. – hadn't caused any issues yet (for me), but I wasn't aware of that.
lsf commented on 2021-01-31 10:24 (UTC)
Can you post some details as to where / how it aborts?
therealOri commented on 2021-01-31 03:48 (UTC)
So far it never manages to download from the AUR. It always takes forever to build then aborts.. :\
Note, I am on Manjaro Linux. Arch Based so idk why it wouldn't work.
lsf commented on 2021-01-27 12:36 (UTC)
Yeah, sounds like a memory issue. I have 16GB and this happens sometimes when compiling locally as well.
You could try running it on fewer cores by uncommenting
# mk_add_options MOZ_MAKE_FLAGS="-j4"in the PKGBUILD and setting it to something like half the amount of your physical cores or lower. This will obviously make things take quite a bit longer but might also use less RAM.Another things worth trying might be to add
export LDFLAGS+=" -Wl,--no-keep-memory"to the PKGBUILD (at somewhere around line 81). This is currently only used for the aarch64 builds, but should also lead to the linking process using less memory.lahwaacz commented on 2021-01-27 11:38 (UTC)
@saloniamatteo: that can happen e.g. if you don't have enough RAM.
saloniamatteo commented on 2021-01-27 07:25 (UTC) (edited on 2021-01-27 11:35 (UTC) by saloniamatteo)
Yesterday I tried building this package twice, but it always failed in the same point, trying to compile
gkrust, failing with an error code saying it received signal 9, and it was killed bykill, even though I set the process' niceness to -20 (the first time it was 0, the second time it was -20).Does anyone else have the same issue?
lahwaacz commented on 2021-01-20 08:05 (UTC)
@pfctl: The
base-develgroup is assumed to be installed, see https://wiki.archlinux.org/index.php/Arch_User_Repository#Getting_startedpfctl commented on 2021-01-20 07:04 (UTC) (edited on 2021-01-20 07:06 (UTC) by pfctl)
commit 0094776 fails to build not finding
m4as a dependency FYI:alium commented on 2020-12-02 12:36 (UTC)
please use patchs from https://github.com/archlinux/svntogit-packages/tree/packages/firefox/trunk and fix compilation with rust 1.48.0 Using older rust is no solution. Thanks
ccorn commented on 2020-10-21 13:14 (UTC) (edited on 2020-10-21 13:36 (UTC) by ccorn)
Patch URL needs to be stabilized:
Edit: Done for all patches now, as the firefox package update has removed them from trunk.
lsf commented on 2020-08-28 21:07 (UTC)
@ccorn: Yep, totally forgot that – sorry about that!
ccorn commented on 2020-08-28 17:17 (UTC)
For
80.0-1, the PKGBUILD has changedsha256sumsforremove_addons.patch, but the file itself seems not to have changed. Have you forgotten togit add remove_addons.patch?lahwaacz commented on 2020-08-01 18:45 (UTC)
@lsf Thanks, the version 79.0-1 has worked for me!
lsf commented on 2020-08-01 09:08 (UTC)
@lahwaacz
Hm, didn't have that issue, compiling in a "clean" docker environment.
I've just updated the package to 79.0-1 – if you still experience the issue with that one, I'll try to look into it :)
lahwaacz commented on 2020-07-30 14:18 (UTC) (edited on 2020-07-30 14:19 (UTC) by lahwaacz)
I got a couple of errors when building in a clean chroot:
otrapersona commented on 2019-12-29 09:08 (UTC)
LibreWolf.gitlab.io 404's, I think the addres is librewolf-community.gitlab.io
commented on 2019-10-09 13:38 (UTC)