Package Details: librewolf 1:137.0.0_3-1

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: MPL-2.0
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 172
Popularity: 15.79
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-04-06 11:35 (UTC)

Sources (3)

Pinned Comments

lsf commented on 2025-01-01 21:28 (UTC)

Please refrain from abusing the flagging of a package as out of date for build issues. This is not what it is supposed to be used for.

I automatically get notified of comments to this package. I do not need to be notified of whatever build problems occur (whether they are an individual's problems or the actual package's problems) twice, and not via flagging it out of date.

Issues with this package can also be reported at https://codeberg.org/librewolf/issues/issues (as it is also maintained there, at https://codeberg.org/librewolf/arch, too).

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 33 Next › Last »

alexmurkoff commented on 2024-04-28 08:15 (UTC)

doesn't build?

0:47.64   800 | G_CONST_RETURN gchar* atk_role_get_name(AtkRole role);
 0:47.64       | ^
 0:47.64 /usr/include/glib-2.0/glib/gmacros.h:1046:30: note: expanded from macro 'G_CONST_RETURN'
 0:47.64  1046 | #define G_CONST_RETURN const GLIB_DEPRECATED_MACRO_IN_2_30_FOR(const)
 0:47.65       |                              ^
 0:47.65 /usr/include/glib-2.0/glib/glib-visibility.h:108:46: note: expanded from macro 'GLIB_DEPRECATED_MACRO_IN_2_30_FOR'
 0:47.65   108 | #define GLIB_DEPRECATED_MACRO_IN_2_30_FOR(f) GLIB_DEPRECATED_MACRO_FOR (f)
 0:47.65       |                                              ^
 0:47.65 /usr/include/glib-2.0/glib/gmacros.h:1300:3: note: expanded from macro 'GLIB_DEPRECATED_MACRO_FOR'
 0:47.65  1300 |   _GLIB_GNUC_DO_PRAGMA(GCC warning G_STRINGIFY (Deprecated pre-processor symbol: replace with #f))
 0:47.65       |   ^
 0:47.65 /usr/include/glib-2.0/glib/gmacros.h:1297:33: note: expanded from macro '_GLIB_GNUC_DO_PRAGMA'
 0:47.65  1297 | #define _GLIB_GNUC_DO_PRAGMA(x) _Pragma(G_STRINGIFY (x))
 0:47.65       |                                 ^
 0:47.65 <scratch space>:40:6: note: expanded from here
 0:47.65    40 |  GCC warning "Deprecated pre-processor symbol: replace with \"const\""
 0:47.65       |      ^

karolyi commented on 2024-04-25 15:24 (UTC)

My build bails out with an error (Package 'nss' has version '3.98', required version is '>= 3.99') which is valid since Manjaro only has 3.98 atm.

I guess I'll have to wait a bit until that gets updated.

Bitals commented on 2024-04-25 14:12 (UTC)

@tyress you probably just don't have enough RAM. Try with less threads, might help, but will obviously take longer.

tyress commented on 2024-04-25 13:05 (UTC)

Compiling this crashes my compositor, not sure why (is this a known issue?). Moved to tty and I'm getting a could not compile gkrust error.

Derson5 commented on 2024-04-22 15:31 (UTC)

There was new release https://codeberg.org/librewolf/source/releases/tag/125.0.1-1

lahwaacz commented on 2024-03-17 14:16 (UTC)

@OdinVex Then build in a chroot rather than building directly in your environment: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

OdinVex commented on 2024-03-17 13:25 (UTC)

Anyone else getting popup windows of a non-install template LibreWolf while compiling? Obviously a part of the "testing" of stuff, but I'd like to avoid that and assume tests are fine.

xiota commented on 2024-03-02 15:04 (UTC) (edited on 2024-03-02 15:07 (UTC) by xiota)

After the initial instrumented build, a python script is launched inside a nested X (or wayland) server (xvfb or xwayland-run) to run and profile the browser. If anything goes wrong, like the x server crashing, the profiling stage fails. Then the entire PGO process has to start over with the instrumented build.

The DRI/Zink problem is probably caused by missing access to acceleration hardware. LIBGL_ALWAYS_SOFTWARE=true forces software rendering. Since multiple people across multiple Firefox forks have been affected, forcing software rendering by default is worthwhile to prevent people from losing hours of time and wasted resources.

Also, pkgrel shouldn't be bumped for changes that don't affect the final package because people who already successfully built the package don't need to rebuild.

lsf commented on 2024-03-02 13:59 (UTC)

@lahwaacz: thanks. will fix it. sorry.

@xiota: do you have some good explanation / some more info about the background of this option and why it causes issues? (or if you felt like it, you could open an issue / PR on https://codeberg.org/librewolf/ right away, of course ;)

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 33 Next › Last »