Arch Linux User Repository

• Find answers - FAQ, Help Center
• Ask questions - Community
• Report bugs - GitHub
• Request features - GitHub

Hi, thank you for maintaining. I just wanted to let you know that the validity check failed today for "brave-browser-beta_1.50.100_amd64.deb".

Should be all set

Can you add these lines to brave-beta-bin.sh so that it will read user flags form file, like how it works on both brave-nightly-bin and brave-bin in aur, thx

diff --git a/brave-beta-bin.sh b/brave-beta-bin.sh
index bd4c5d3..63ae45e 100644
--- a/brave-beta-bin.sh
+++ b/brave-beta-bin.sh
@@ -1,6 +1,13 @@
 #!/usr/bin/env bash
+XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
+
+# Allow users to override command-line options
+USER_FLAGS_FILE="$XDG_CONFIG_HOME/brave-beta-flags.conf"
+if [[ -f $USER_FLAGS_FILE ]]; then
+   USER_FLAGS="$(cat $USER_FLAGS_FILE | sed 's/#.*//')"
+fi

 if [[ -z "${CHROME_USER_DATA_DIR}" ]]; then
     export CHROME_USER_DATA_DIR=~/.config/BraveSoftware/Brave-Browser-Beta
 fi
-exec "/opt/brave.com/brave-beta/brave-browser" "$BRAVE_FLAGS" "$FLAG" "$@"
+exec "/opt/brave.com/brave-beta/brave-browser" "$USER_FLAGS" "$BRAVE_FLAGS" "$FLAG" "$@"

@gregbunk I rolled back to normal Mesa v22 and all is fine. Also I was using a AUR Mesa-git which is newer then the default AUR version I think.

Mesa-git looks OK here (AMD RX6400xt) - maybe it's the card?

In any case, please report this to Brave directly. This is simply a repackage of what they produce.

The last update corrupted Brave title bar etc on Mesa drivers (6800xt).

Not sure if same on NVIDIA. Probable Mesa-Git to blame. (confirmed, normal mesa22 is fine)

Ok, I finally noticed the "something else" from "fails to open a window". I'm running LXQt over openbox with multiple "desktops". When brave "fails to open a window", actually, it did open a window, but not on the active desktop, and then, the panel, in this case, also fails to recognize that brave has opened a window on an inactive desktop and display a new tab in the panel for this new window. brave is the only app that I've seen do this with LXQt, but probably cannot blame brave.

Sorry about the noise.

Thanks for your note. Sorry about the time delay.

$ glxinfo
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig

Umph. After reading-up on this, and noting that I'm running two different Xorg servers simultaneously, one on an Nvidia, one on a Radeon, I see in the Xorg log for the Radeon device "Loading /usr/lib/nvidia/xorg/libglx.so", even though ServerLayout and Screen sections have been explicitly configured to select only the Radeon device. That seems like an Xorg bug to me, and nothing to do with brave-beta-bin, of course.

Explicitly setting "-modulepath /usr/lib/xorg/modules" on the Xorg command line solves the problem, and no more complaints from brave-beta.

Apparently, some versions of brave-beta - for instance brave-beta-bin 1.37.84-1 - again work despite the libglx issue. And, at the moment, and after fixing the libglx problem, for instance brave-nightly-bin 1.38.29-1 will run but now fails to open a window. But that is brave-nightly. Still, there may be something else going on here. For the moment, brave-beta is behaving as expected.

I doubt it. I'm not seeing that.

Try a glxinfo and see if your glx is working.

After a recent system upgrade, when starting brave-beta, lots of messages:

ERROR:gl_surface_egl.cc(808)] EGL Driver message (Critical) eglInitialize: GLX is not present.

and

ERROR:angle_platform_impl.cc(44)] Display.cpp:940 (initialize): ANGLE Display::initialize error 12289: GLX is not present.

and the browser window never opens.

From brave-beta support, I see:

"I maintain that aur. It turns out that chromium now ships their own libEGL and libGLES. ... I’ve updated the AUR to pull those files from chromium."

But, brave-nightly works normally.

Is there some problem again with these libraries?