Package Details: brave-nightly-bin 1.67.66-1

Git Clone URL: https://aur.archlinux.org/brave-nightly-bin.git (read-only, click to copy)
Package Base: brave-nightly-bin
Description: Web browser that blocks ads and trackers by default (nightly binary release).
Upstream URL: https://brave.com/download-nightly
Licenses: MPL2
Provides: brave-nightly-bin, brave-nightly-browser
Submitter: gregbunk
Maintainer: gregbunk
Last Packager: gregbunk
Votes: 25
Popularity: 0.074361
First Submitted: 2019-03-28 14:18 (UTC)
Last Updated: 2024-05-04 09:19 (UTC)

Dependencies (9)

Required by (0)

Sources (3)

Latest Comments

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

oidualc commented on 2020-09-30 20:46 (UTC)

The issue I was mentioning some months ago where when clicking on the icon it generates a second icon to hold the windows (incorrect StartupWMClass) is back with this new version. I made a new patch to add back the StartupWMClass in the .desktop file, could you apply it? https://pastebin.com/dYYSn51d

kiankasad commented on 2020-09-23 00:44 (UTC) (edited on 2020-09-23 01:03 (UTC) by kiankasad)

The file /proc/sys/kernel/unprivileged_userns_clone is provided by a kernel patch that exists in Debian. On Arch Linux, the file should never exist. This means that even when user namespaces are enabled, Brave will run with the sandbox disabled (which is not good).

This can be fixed by removing the check for /proc/sys/kernel/unprivileged_userns_clone in brave-nightly-bin.sh

EDIT: I've applied this suggestion, as well as made the script work in POSIX-compliant shells (sh). It can be found here: https://files.kasad.com/brave-nightly-bin.sh

LongerHV commented on 2020-09-17 15:30 (UTC)

On latest update (1.16.23-4) configuration was moved from ~/.config/Brave-Software/Brave-Browser to ~/.config/Brave-Software/Brave-Browser-Nightly, so it appeared as all configuration was reset (at least on my system). I have removed Brave-Browser-Nightly directory, made a symlink to Brave-Browser and all my settings are back.

gregbunk commented on 2020-09-03 15:51 (UTC)

@scootz That did it! Thanks! Now if I can manage to check in my changes (AUR is timing out) we'd be good to go.

scootz commented on 2020-09-03 11:03 (UTC)

According to AUR/brave comment (https://aur.archlinux.org/packages/brave/#comment-763448), adding '--use-gl=desktop' to ~/.config/brave-flags.conf will make it work. It works for me (tested by going to https://get.webgl.org). Maybe modifying brave-nightly-bin.sh to include this user flag might be an idea but forcing it on for everyone might not be the way to do it.

gregbunk commented on 2020-09-03 08:26 (UTC)

@scootz Before I started pulling the files from Chrome, I tried making the system libEGL/libGLES (either libglvnd or just straight up mesa) libraries work and couldn't. I could get Chrome to load them, but it would then fail. It looked to me like ANGLE is not a straight up replacement for libEGL/libGLES but rather does some translation that the Chrome engine in Brave depends on.

scootz commented on 2020-09-03 00:19 (UTC) (edited on 2020-09-03 00:25 (UTC) by scootz)

about the libEGL/GLES, would adding a package requirement for "libglvnd" work to avoid pulling in google chrome's version?

0000000011111111 commented on 2020-08-16 10:12 (UTC)

Thank you gregbunk, I appreciate it! Let's hope they include the missing files soon.

gregbunk commented on 2020-08-13 08:27 (UTC)

I've reported these missing files to Brave so the inclusion of these two files is hopefully very temporary. I've taken a look at building the ANGLE GL libraries (which is what these seem to be), but even that would be - hopefully - a very temporary fix.

See here:

https://github.com/google/angle

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