Package Details: librewolf 89.0-1

Git Clone URL: (read-only, click to copy)
Package Base: librewolf
Description: Community-maintained fork of Firefox, focused on privacy, security and freedom.
Upstream URL:
Licenses: GPL, MPL, LGPL
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 27
Popularity: 4.28
First Submitted: 2019-06-14 18:41
Last Updated: 2021-06-04 10:41

Dependencies (38)

Sources (5)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

ZorinArch commented on 2021-02-07 12:56

Hi lsf, can you add opensuse patches for better KDE integration. Thanks

saloniamatteo commented on 2021-02-02 08:08

@lsf: OK, I have commented the line containing unity-menubar.patch, I'll see if LibreWolf compiles correctly this time.

lsf commented on 2021-02-01 21:34

I'd recommend double-checking if the menubar-patch is truly not applied, ie. checking if lines 145-148 look like this:

# Debian patch to enable global menubar
# disabled until it's updated upstream
# also disabled for the default build, as it seems to cause issues in some configurations
# patch -p1 -i ../unity-menubar.patch

Maybe something got mixed up when you updated your modified PKGBUILD ^^

(the unity-menubar.patch is 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)

saloniamatteo commented on 2021-02-01 20:58

@lsf: Yes, I have modified the PKGBUILD by settings MAKEFLAGS=-j2, and I have written sed commands to modify settings/librewolf.cfg (enable stuff required to make Google Meet work, otherwise I cannot use it for school-related purposes). As I've written earlier, this worked for me with LibreWolf/FF v84.0.2. I'm only getting this error now, even after commenting the line that sets the linker to gold.

lsf commented on 2021-02-01 20:40

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.patch applied (which is why it's currently commented out).

Here's the log:

It might've been a coincidence, though.

Without it, things built fine:


Thanks for the hint with the LDFLAGS, btw. – hadn't caused any issues yet (for me), but I wasn't aware of that.

saloniamatteo commented on 2021-02-01 20:33

@lsf: I had succesfully built LibreWolf 84.0.2, and I had just rebuilt it this morning (> ~12 hours ago). Now, I have upgraded the PKGBUILD to 85.0, and the compiler throws out this error, then aborts:

173:50.81 /var/git/aur/librewolf/src/firefox-85.0/widget/gtk/nsNativeMenuService.cpp:433:21: error: member access into incomplete type 'mozilla::dom::Element'
173:50.81     if (aMenuBarNode->AttrValueIs(kNameSpaceID_None,
173:50.81                     ^
173:50.81 /var/git/aur/librewolf/src/firefox-85.0/obj/dist/include/nsINode.h:87:7: note: forward declaration of 'mozilla::dom::Element'
173:50.81 class Element;
173:50.82       ^
173:50.82 /var/git/aur/librewolf/src/firefox-85.0/widget/gtk/nsNativeMenuService.cpp:440:61: error: cannot initialize a parameter of type 'nsIContent *' with an lvalue of type 'mozilla::dom::Element *'
173:50.82     UniquePtr<nsMenuBar> menubar(nsMenuBar::Create(aParent, aMenuBarNode));
173:50.82                                                             ^~~~~~~~~~~~
173:50.82 /var/git/aur/librewolf/src/firefox-85.0/widget/gtk/nsMenuBar.h:46:61: note: passing argument to parameter 'aMenuBarNode' here
173:50.82                                                 nsIContent *aMenuBarNode);
173:50.82                                                             ^
173:50.82 2 errors generated.
173:50.82 make[4]: *** [/var/git/aur/librewolf/src/firefox-85.0/config/ nsNativeMenuService.o] Error 1
173:50.82 make[3]: *** [/var/git/aur/librewolf/src/firefox-85.0/config/ widget/gtk/target-objects] Error 2
173:50.82 make[3]: *** Waiting for unfinished jobs....
174:48.63 make[2]: *** [/var/git/aur/librewolf/src/firefox-85.0/config/ compile] Error 2
174:48.63 make[1]: *** [/var/git/aur/librewolf/src/firefox-85.0/config/ default] Error 2
174:48.64 make: *** [ build] Error 2
174:48.66 211 compiler warnings present.
174:49.21 Failed to parse ccache stats output: secondary config (readonly)         /etc/ccache.conf
==> ERROR: A failure occurred in build().

This seems to be an error in firefox-85.0/widget/gtk/nsNativeMenuService.cpp at line 433, and line 440.

Is this just an issue on my side? I have already tried clearing the cache (ccache -Cz), and removing every directory in the build directory (pkg, src, etc.), yet the same error occurs.

Also, in the LDFLAGS section, please add a comma before the custom arguments!! (A stock /etc/makepkg.conf will not provide a comma after the last LDFLAGS argument)

export LDFLAGS+=" ,-Wl,--no-keep-memory"

If needed, here's my /etc/ccache.conf:

# Set max cache size to 15 GB
max_size = 15.0G

# Preserve cache across GCC rebuilds and
# introspect GCC changes through GCC wrapper.
compiler_check = %compiler% -v

# I expect 1.5M files. 300 files per directory.
cache_dir_levels = 3

# Compress cache
compression = true
compression_level = 1

lsf commented on 2021-01-31 10:24

Can you post some details as to where / how it aborts?

therealOri commented on 2021-01-31 03:48

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.

saloniamatteo commented on 2021-01-27 14:33

@lsf: OK, I have set it to "-j2" (I have an i5-4340M in a ThinkPad T440p, 2C4T), and I've found out that, since my CPU has a 3MB last-level cache, using 2 cores will provide more performance, especially when mining.

So far so good, hope it compiles correctly now. Just in case, I've created a temporary 10GB swap partition in my other SSD, so memory should not be an issue anymore.

lsf commented on 2021-01-27 12:36

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.