Package Details: brave-bin 1:1.40.107-1

Git Clone URL: (read-only, click to copy)
Package Base: brave-bin
Description: Web browser that blocks ads and trackers by default (binary release)
Upstream URL:
Keywords: brave browser
Licenses: BSD, MPL2, custom:chromium
Conflicts: brave
Provides: brave, brave-browser
Submitter: toropisco
Maintainer: alerque (alosarjos)
Last Packager: alosarjos
Votes: 609
Popularity: 18.78
First Submitted: 2016-04-06 13:16 (UTC)
Last Updated: 2022-06-26 18:34 (UTC)

Dependencies (8)

Required by (3)

Sources (3)

Pinned Comments

alerque commented on 2021-11-27 03:11 (UTC)

@ant0n et all, lets keep the comments here about packaging issues, general Brave usage issues should go in another forum to not clutter up this comment space. I'm deleting comments that have no relation to packaging. Grey areas like crashes that could be blamed on Arch can stay until proven otherwise, but things like how to configure Brave to handle popups or site X or whatever just don't belong here. Thanks for understanding.

Latest Comments

alosarjos commented on 2022-06-07 19:53 (UTC)

@heapifyman For what I see they have their own brave-bin package with their own So changes here shouldn't affect those users.

heapifyman commented on 2022-06-07 13:14 (UTC) (edited on 2022-06-07 13:16 (UTC) by heapifyman)

@alosarjos as far as I know brave-flags.conf comes pre-installed with Manjaro Sway. It also brings chromium-flags.conf and chrome-flags.conf with identical content:

--enable-features=UseOzonePlatform --ozone-platform=wayland


I had installed this package without any modifications.

But it seems that Manjaro provides its own build of Brave in its own community package repository: - not sure how it is related to this package.

I used this package because it seemed to receive updates faster than the one provided by Manjaro.

finoderi commented on 2022-06-04 14:56 (UTC)

I agree with wknapik. You are trying to fix a non-existent issue and really don't need to do that. It's enough for anybody to pay enough attention what they are adding to brave-flags. It's impossible to specify every single mistake idiots are capable of. There are legion of them and they are very inventive.

alosarjos commented on 2022-06-03 19:10 (UTC)

For now, I will be reverting the changes. I get the point that these can help in some situations. But right now, since nobody complained about not being able to use special chars like * on their flags, is not fixing anything and only giving some problems to other users.

I'm think I can (But have to check) if a message can be printed when updating the package warning users of the changes and what needs to be done.

Also I'm curious about @heapifyman and the Manjaro Sway. Is the brave-bin package there this one + preconfigured config file for Wayland? Is it written on some wiki? If I understood correctly there the config file is provided by the distro flavor devs, so I might be braking things for users without them knowing, looks like the patches are good, but maybe I need a way to communicate breaking changes specially regarding people where the config file is preconfigured.

wknapik commented on 2022-06-02 17:40 (UTC) (edited on 2022-06-02 17:48 (UTC) by wknapik)

I don't like the fact that we are breaking previously running configs for others.

In chromium/chrome, this feature is a part of the browser. Here, it's implemented in 7 lines of code, so there will be limitations.

My regex skills are not at the point where I can understand that last sed, to be honest.

There you go:
- s/\s*#.*//g - remove comments and whitespace before them
- s/^\s*//g - remove whitespace at the beginning of each line
- s/\s*$//g - remove whitespace at the end of each line
- /\S/p (with -n) - print only lines that contain at least one non-whitespace character (equivalent to grep '\S')

are there chrome flags that accept * or white spaces to begin with or are we fixing imaginary issues?

There are many special characters in bash

Allowing the shell to expand them in this case is a bad idea IMO.

Up to you @alosarjos. Either revert my patch and accept the shell expansion, or apply my second patch and accept the limitations in format (each option on a new line and no quotes). There's also a third option of implementing this properly, which would take more code than those 7 lines.

alosarjos commented on 2022-06-02 16:41 (UTC)

Hi everyone, sorry for the late response.

I usually test all this on my PC to check everything keeps working, but turns out that, since I have a bunch of flags I already have them all in separate lines, so I didn't see any breaking changes.

I don't like the fact that we are breaking previously running configs for others. My regex skills are not at the point where I can understand that last sed, to be honest.

I don't see harm on the new changes though, but are there chrome flags that accept * or white spaces to begin with or are we fixing imaginary issues?

AFAIK, spaces must be escaped regarding the docs:

So I'm not sure at all if these patches are actually necessary, @wknapik, can you tell me what was failing to you before?

wknapik commented on 2022-06-02 15:25 (UTC) (edited on 2022-06-02 16:35 (UTC) by wknapik)

@alosarjos please apply also this patch to improve handling of comments and whitespace:

diff --git a/ b/
index 0e657ed..30940d1 100644
--- a/
+++ b/
@@ -4,7 +4,7 @@ XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
 # Allow users to override command-line options
 if [[ -f "$USER_FLAGS_FILE" ]]; then
-   mapfile -t USER_FLAGS < <(sed 's/#.*//g' "$USER_FLAGS_FILE")
+   mapfile -t USER_FLAGS < <(sed -e 's/\s*#.*//g' -e 's/^\s*//g' -e 's/\s*$//g' "$USER_FLAGS_FILE"|sed -n '/\S/p')

 export CHROME_VERSION_EXTRA="stable"

This takes care of trimming whitespace around options and dropping lines that contain no options, which is relevant when you quote everything you pass on the command line.

PS. The approach you took to removing comments (which I haven't changed) would be problematic if a browser option was used with an argument containing the # character, like --some-option=foo#bar, but that seems like an unlikely edge case, so I think it's fine to favor simplicity of implementation here.

wknapik commented on 2022-06-02 15:02 (UTC) (edited on 2022-06-02 16:00 (UTC) by wknapik)

@heapifyman each option should be on a separate line (and should not be quoted, as the script takes care of that), instead of having multiple options on one line.

So this is bad

--enable-features=UseOzonePlatform --ozone-platform=wayland
--foo="bar baz"

This is good

--foo=bar baz

Some browser options may accept arguments containing spaces, so breaking up arguments on spaces is tricky. Doable, but the code would have to be aware of the context the space occurs in, so would be considerably more complex.

heapifyman commented on 2022-06-02 07:39 (UTC)

The latest version 1:1.39.111-2 with the patch by @wknampik does not seem to work with the default brave-flags.conf that is installed by Manjaro Sway.

brave-flags.conf has the following content, a single line:

--enable-features=UseOzonePlatform --ozone-platform=wayland

That should make brave run on wayland natively.

With the latest version of these settings seem to be ignored. Starting brave and then running xlsclient -a returns brave, meaning it runs on Xwayland, not native wayland, as far as I understand. Running xeyes confirms that - eyes are following mouse cursor when brave is focused.

If I revert the changes to the script then xlsclient -a does not return brave, anymore.

Question: is that an issue with the script or do I (and the Manjaro Sway developers) need to adjust anything in brave-flags.conf?

Spixmaster commented on 2022-05-31 16:00 (UTC) (edited on 2022-05-31 16:00 (UTC) by Spixmaster)

@wknampik is right, @alosarjos. Shebangs exist exactly for this reason to specify the needed shell interpreter. Besides, Bash is a dependency of base. Everybody has Bash.

wknapik commented on 2022-05-30 18:08 (UTC)

@alosarjos bash is a dependency of multiple packages in base-devel, so it's guaranteed to be available. The shebang at the top of selects bash as the interpreter, so we're all set. I use zsh myself and this works fine for me.

alosarjos commented on 2022-05-30 14:21 (UTC)

@wknapik I see... The problem there is that bash is not mandatory as default shell, people may be using ZSH, so i tried there the mapfile, and doesn't recognize it, so I can't put that on the AUR script...

wknapik commented on 2022-05-30 10:45 (UTC)

@alosarjos mapfile is a bash builtin that reads lines into an indexed array (see: man bash).

Quotes around a regular variable prevent expansion, but also make the whole value a single commandline argument. Quotes around an array prevent expansion, but each element is quoted separately, which is what we want here.

Please run shellcheck against before and after applying the patch to see that this fixes a generic problem.

alosarjos commented on 2022-05-30 09:57 (UTC)

@PQCraft This is the pre-built binaries by Brave. If you think there is an issue with build options I suggest you ask them on their Github repository.

PQCraft commented on 2022-05-30 08:02 (UTC) (edited on 2022-05-30 08:03 (UTC) by PQCraft)

Hi, I have been experiencing a lot of issues where tabs randomly crash with SIGILL. I wonder if this has to do with the build options. Is this being built for generic x86_64?

alosarjos commented on 2022-05-30 06:52 (UTC)

@wknapik Thanks for the patch. But I'm not sure it's correct? What is this mapfile you are adding to it?

wknapik commented on 2022-05-28 00:35 (UTC)

The script that gets installed as /usr/bin/brave ( doesn't quote the extra arguments from brave-flags.conf, which means they get expanded by the shell. So, for instance, if you put "*" in your brave-flags.conf, it will cause all files from the working directory to be opened when brave is started.

Here's a patch to address this:

diff --git a/ b/
index 293a314..0e657ed 100644
--- a/
+++ b/
@@ -3,10 +3,10 @@ XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"

 # Allow users to override command-line options
-if [[ -f $USER_FLAGS_FILE ]]; then
-   USER_FLAGS="$(cat $USER_FLAGS_FILE | sed 's/#.*//')"
+if [[ -f "$USER_FLAGS_FILE" ]]; then
+   mapfile -t USER_FLAGS < <(sed 's/#.*//g' "$USER_FLAGS_FILE")

 export CHROME_VERSION_EXTRA="stable"

-exec /usr/lib/brave-bin/brave "$@" $USER_FLAGS
+exec /usr/lib/brave-bin/brave "$@" "${USER_FLAGS[@]}"

WhiteFang1319 commented on 2022-05-13 16:17 (UTC) (edited on 2022-05-14 04:13 (UTC) by WhiteFang1319)

Brave keeps freezing the whole system, it's random and I don't think its due to high cpu usage or RAM either. Sometimes I'm able to use terminal to end it or go to TTY, otherwise I need to do a full reboot because it's fully frozen.

Seems like it's happening due to having hardware-acceleration enabled. Disabling it fixed for me.

alosarjos commented on 2022-05-11 19:50 (UTC)

@itsKia2 No problem. I appreciate people notifying me about the package being outdated. But lately I've been getting multiple false reports.

You can try the Curl method, or check if they updated the CHANGELOG file. Or check the status on the release checklist:

itsKia2 commented on 2022-05-11 19:47 (UTC)

@alosarjos sincerely sorry for flagging the package. i was not aware that was the method used to check the latest version. will not be making the same mistake again.

alosarjos commented on 2022-05-11 14:52 (UTC)

Please, don't mark as outdated if the new version is not showing up in

Someone flagged the package saying Latest version es 1.38.113, but that version is discarded and the next release will probably be Release v1.38.115

alosarjos commented on 2022-04-24 17:26 (UTC)

@ijann That looks like you are searing on the same window where you should rename. I see a search text box with the fdg... and then the name file being field-...

You sure are using fine? Anyway, if this kind of bugs are for the Brave Github, not a packaging issue.

finoderi commented on 2022-04-20 13:37 (UTC) (edited on 2022-04-21 03:49 (UTC) by finoderi)

Is there any way to stop people from flagging this package for arbitrary reasons?

duhdugg commented on 2022-04-13 02:38 (UTC)

The flathub package is an unofficial package, not supported upstream.

alosarjos commented on 2022-04-12 19:31 (UTC)

Just a quick notice: Brave is now available as a Flatpak!

While not related directly to this I think this are fantastic news and specially should help on checking if an issue is only happening on this package or on brave upstream by giving a quick test on the flatpak version

osimarr commented on 2022-04-02 15:23 (UTC)

I think the person who flagged out-of-date didn't realize the stable version changed from 1.36 to 1.37 and checked only the minor .109 version

jorgicio commented on 2022-04-02 13:45 (UTC)

Also, the 1.37.110 is a prerelease, not a stable release.

alosarjos commented on 2022-04-01 17:03 (UTC)

So... for some reason someone flagged the package as outdated without even checking that we are already on the latest stable version I I can't unflag it...

@alerque can you unflag it?

josete commented on 2022-03-15 14:35 (UTC) (edited on 2022-03-15 15:16 (UTC) by josete)

Hi! I have a lot of problems with drop-down menus on every website. Sometimes they work, and sometimes they don't. I have tried enabling and disabling all the addons I use. The result is the same. When I click on a menu, I can see all the options but nothing happens when I click on one of them. After a while, the menus work again. I've seen several comments of people with the same problems but no solutions. All of them talked about the AUR version. My system is Manjaro KDE. Any ideas? Thanks in advance!

alosarjos commented on 2022-03-06 12:55 (UTC) (edited on 2022-03-06 12:56 (UTC) by alosarjos)

@urbenlegend It is installed with the package as /usr/bin/brave. It's a wrapper that allows setting custom flags on $HOME/.config/brave-flags.conf over the real brave binary located at /usr/lib/brave-bin/brave

urbenlegend commented on 2022-03-06 12:46 (UTC)

Apologies if this question has already been asked, but what's the purpose for the file included in this package? It doesn't seem to get installed onto the system. Is this file there just for reference or should it be removed?

alosarjos commented on 2022-02-27 10:57 (UTC)

@zerophase @Archanfel80HUN If the issues you are having are not related to packaging I would prefer if you can move the discussion to the Brave Github since it will probably be a Brave issue (Not a packaging issue) and the reporting it to the Brave developers will be more usefull.

Archanfel80HUN commented on 2022-02-25 11:10 (UTC) (edited on 2022-02-25 14:50 (UTC) by Archanfel80HUN)

@zerophase i have 32Gig ram, its not a ram issue, its a brave issue. Workaround, run brave in a terminal or from a terminal window. It will not crash. Really strange.

update: brave nightly, current version 1.38.1 does not have any crash issue.

zerophase commented on 2022-02-24 03:15 (UTC)

@archanfel80HUN Have you found a stable version? I've gone back to 1.33 and the behavior persists. There definitely might be an issue with Brave. But, me having ram instability complicates it with how heavy Chromium is on ram.

Archanfel80HUN commented on 2022-02-23 21:12 (UTC)

@zerophase Same issue here, crashing after start, restart for a second or third time its fine.

alosarjos commented on 2022-02-23 20:32 (UTC)

@zerophase Hmm, all I do for now at least is keep updating the version to help @alerque. If it's crashing it sounds more like a Brave issue rather than a packaging itself. I would try reporting it on their GitHub.

zerophase commented on 2022-02-22 18:23 (UTC)

@alosarjos believe my crashes are from having a stick of ram or two go bad. Going to be a bit before I can test, as my current water cooling setup prevents me from removing all of the ram for testing. I do have crash dumps that might help, if this is not from ram.

zerophase commented on 2022-02-21 02:45 (UTC) (edited on 2022-02-21 02:48 (UTC) by zerophase)

@alosarjos I'm using Cinnamon. Don't believe I have any custom flags, and on X11. I do have a coredump in journalctl. This eventually goes away after restarting the browser a bunch.

alosarjos commented on 2022-02-18 15:13 (UTC)

@zerophase @txhx38 I haven't noticed any issue on my install. Can you provide more info on you config? (Desktop Environment, Custom Flags, X11/Wayland, Ozone...)

txhx38 commented on 2022-02-18 05:19 (UTC)

@zerophase Yes. For me it's not crashing but freezing sometimes since a week.

zerophase commented on 2022-02-18 00:17 (UTC)

Anyone else having issues with the browser crashing frequently?

Started approximately a week ago for me.

a821 commented on 2022-01-25 11:37 (UTC)

@gr523 that sounds like a bug in you AUR helper, not a packaging issue. makepkg does not clean the sources.

gr523 commented on 2022-01-25 11:21 (UTC)

The package file along with the zip file is deleted on sudo time out, so the same zip needs to be downloaded again and makepkg again Cleanup should be made only after successful install

jordangarrison commented on 2022-01-10 21:00 (UTC)

@alosarjos thanks for the response! I'm using X11 for my setup for stability reasons and have already installed the previous version. I wanted to share this issue on here since it was breaking some expected browser functionality. Unfortunately, this appears to also affect the Beta and Nightly builds of the browser as well.

Y'all are doing great with this, thanks for supporting this browser's availability on Arch! I'll look forward to the patch update!

alosarjos commented on 2022-01-10 20:39 (UTC)

@jordangarrison I saw recently that Arch chromium package got rebuilt with some patch to fix it.

In my case is working without any issue. The patches mention X11, so maybe it's working for me because I'm using Ozone/Wayland. Anyways, seems to be an upstream chromium issue.

Thanks for posting the issue on GitHub, sadly it looks like it hasn't been backported to current Chromium version and I don't think Brave will apply it. So you can either:

  1. Enable Ozone Wayland
  2. Install the previous version (If you don't know how I can help you with that)
  3. Install maybe the nightly or brave (Not -bin) version with the patches applied I would say.

Anyways, the users of this package are awesome and they usually notify me really quick of new updates in case I miss them, so if Chromium fixes it, and Brave releases a new update based on fixed Chromium I will update the package ASAP.

jordangarrison commented on 2022-01-10 20:30 (UTC) (edited on 2022-01-10 20:31 (UTC) by jordangarrison)

There is a functionality-breaking issue with the current version of the package which prevents the user from being able to drag and drop into the browser window or rearrange tabs with the mouse. You can follow this issue here (GitHub brave/brave-browser issue #20386).

The previous version of the package does not contain this issue.

Th30 commented on 2022-01-10 00:53 (UTC)

@jemadux: Yes, if you activate them.

jemadux commented on 2021-12-18 14:22 (UTC)

does brave-bin provide brave ads ?

alerque commented on 2021-11-27 03:11 (UTC)

@ant0n et all, lets keep the comments here about packaging issues, general Brave usage issues should go in another forum to not clutter up this comment space. I'm deleting comments that have no relation to packaging. Grey areas like crashes that could be blamed on Arch can stay until proven otherwise, but things like how to configure Brave to handle popups or site X or whatever just don't belong here. Thanks for understanding.

Nu4425 commented on 2021-11-10 18:05 (UTC) (edited on 2021-11-10 18:08 (UTC) by Nu4425)

@alosarjos Thank you. Also, if I am not mistaken, the Brave's pgp fingerprint can be listed from their official public key with gpg by:

gpg --show-keys BRAVE_PGP_PUBLIC_KEY

If that is the case, then according to the wiki the fingerprint can be supplied to validpgpkeys in PKGBUILD...

alosarjos commented on 2021-11-10 05:27 (UTC)

@Nu4425 I will try to give it a look on how all that works when I get some more free time, for now I just updated the packag :P

Nu4425 commented on 2021-11-08 21:58 (UTC)

Hi @alosarjos, the package builds fine but as an improvement can you verify the authenticity/integrity of the release using brave's official signing key during the build process? This would be great, as Brave provides official signing keys in their website at "".

mdedetrich commented on 2021-10-30 09:40 (UTC)

So I just fixed it, read the archwiki for chromium and updating the flags to brave --use-gl=desktop --enable-features=VaapiVideoDecoder --disable-features=UseOzonePlatform %U seems to have worked (using X11 not Wayland).

mdedetrich commented on 2021-10-30 09:35 (UTC)

Actually ignore my last message, removing --use-gl=egl --enable-features=VaapiVideoDecoder %U did end up working (of course the issue is that I now don't have video video acceleration).

alosarjos commented on 2021-10-30 09:33 (UTC)

Can't help you there more. I'm on Wayland, so no Video Acceleration for me, I'm using EGL flag too though, but it's working fine on my end. AMDGPU here.

If Chromium has the issue closed, maybe it's something on the mesa side for your hardware?

mdedetrich commented on 2021-10-30 09:29 (UTC)

Still get the same issue, I am pretty sure I am hitting

alosarjos commented on 2021-10-30 05:08 (UTC)

Could you try removing them?

mdedetrich commented on 2021-10-28 09:11 (UTC)

I am using the following flags (for video acceleration) brave --use-gl=egl --enable-features=VaapiVideoDecoder %U

alosarjos commented on 2021-10-22 17:48 (UTC)

@mdedetrich Google Maps is working fine here. Are you using any custom flags?

mdedetrich commented on 2021-10-21 09:41 (UTC)

Has anyone experienced the issue where anything being painted inside a canvas (i.e. Google maps) is upside down?

alosarjos commented on 2021-10-18 15:45 (UTC)

@vonbloom Can you try removing your user brave config and cache files and retrying?

vonbloom commented on 2021-10-13 18:18 (UTC)

I get a segmentation fault (core dumped) after upgrading to 1:1.30.89-1

alerque commented on 2021-09-27 10:11 (UTC)

@von Please see previous comments. v1.30.84 is still marked on GitHub as pre-release and is not in the official release manifest yet. You can check with:

$ curl

alerque commented on 2021-09-24 07:55 (UTC)

@aafsmarak Please don't flag this as OOD for beta / nightly / other pre-release builds. This in only tracking officially built binaries in the stable channel.

alosarjos commented on 2021-09-24 05:15 (UTC) (edited on 2021-09-24 05:18 (UTC) by alosarjos)

1.30.84 is still a pre-release. Check

before flagging as out of date.

I will leave it marked because it will surely come out in a few hours and someone would probably re-mark it as absolete...

zerophase commented on 2021-09-20 19:56 (UTC) (edited on 2021-09-20 20:04 (UTC) by zerophase)

Has anyone else had right clicking / ctrl + v into Brave's search bar stop working recently?

UPDATE: Fixed itself after I caused Brave to crash, and restore itself.

Figured out how I broke the copying and pasting. I copied a link from a download box. Closed the box, and tried pasting it. Believe this is an upstream issue.

alosarjos commented on 2021-09-20 17:27 (UTC)

Just in case someone wants to fill a bug here. I'm testing 1.30.81 (Which is based on Chromium 94, which finally has the CSD fixed for Linux) but sadly this Brave version is still using an outdated UI component. But it's fixed on Nightly.

alosarjos commented on 2021-09-15 04:36 (UTC)

@jb.1234abcd I would suggest opening an issue on the Brave Github

jb.1234abcd commented on 2021-09-14 14:09 (UTC) (edited on 2021-09-14 14:14 (UTC) by jb.1234abcd)



On Brave open these errors are logged (journalctl):

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension eoceebklhjepohnakemchinmkdpbolgh installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirtVb0bH, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension bpkoijdaibakhfgahdfknbdcankhidoa installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirglbwx9, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension ldopphkgfhfchjcgfilekhkifaodmegm installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirWcPPFX, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension gajhkmnhhoadjcfchafgbekhgigglnkp installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirB3yGbZ, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension mjkjompjknhcipamakpfliebpggggpga installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirUjC7FV, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

Sep 14 15:29:04 r61i chrome[40650]: [40650:40650:0914/] Corruption detected in extension feipjgjfhmnfhhmbkclfopokbcgnpnnd installed at: /home/jb/.config/BraveSoftware/Brave-Browser/Greaselion/Temp/scoped_dirKf5TAc, from webstore: 0, corruption reason: 1, should be repaired: 1, extension location: kComponent

duhdugg commented on 2021-09-03 13:27 (UTC)

Is anyone else having issues where Google sheets is rendering transparent font colors? It seems specific to this latest version, but I'm having trouble narrowing down exactly where this is happening in styling.

alosarjos commented on 2021-09-01 15:23 (UTC)

@alerque, I agree on you on this being more the second case than the first, but I guess following the chromium package should be the way (And thus, add them)?

Also, I see that the Chromium package has org.freedesktop.secrets as dependency which includes gnome-keyring, but being a freedesktop standard I'm not sure why it's not including the KDE variant (Looks to me to be that the optdepends that should be added)

alerque commented on 2021-09-01 15:04 (UTC)

@blennow Thanks for the further explanation. I get what you're talking about now.

Unfortunately I don't think this falls under a very good use for optdepends. It is kind of on the fuzzy boarder, but there is a difference between things that directly add additional functionality and things that just play nice together if they happen to both exist. I think this falls into the latter case.

blennow commented on 2021-09-01 14:39 (UTC)

@alosarjos I can confirm that when using XDG_CURRENT_DESKTOP=KDE brave will use kdialog and XDG_CURRENT_DESKTOP=GNOME will use GTK based dialogs.

This is further confirmed by brave support with the command line flag --password-store that supports kwallet. It will also automatically choose the best fitting package for the current environment.

I still really think these should be dependecies of the plasma-browser-integration package too but the maintainer did not.

alosarjos commented on 2021-09-01 11:15 (UTC) (edited on 2021-09-01 12:48 (UTC) by alosarjos)

I just checked the generated .deb brave provided on GitHub, and it does not have any optional dependencies on gnome-keyring or anything related. Are we sure these Gnome and KDE packages have any effect on Brave?

PD: Probably they are as dependencies of dependencies. But there is a brave-keyring package to installed. Anyway, if you say that installing those packages have some effects, I don't see why not update them.

@alerque If you don't see any issue too I could update them once I get home

blennow commented on 2021-08-31 21:33 (UTC) (edited on 2021-08-31 22:09 (UTC) by blennow)

@aleque Hi, I realize now what I wrote was very cryptic, sorry about that. I'm suggesting that kdialog and kwallet be added as optional dependencies like chromium has.

I previously opened a bug at plasma-browser-integration but it got closed as not a bug and the maintainer referred to the chromium package. I think this change would help discoverability to get integrated dialogs with KDE (I don't think there are integrations for other DE).

@Iwirada Yes that is what I have done and it works. Thanks for the suggestion.

Also, great job on getting the package updated so fast!

Iwirada commented on 2021-08-31 20:00 (UTC)

@blennow not everyone is using Plasma. E.g. I am a dwm user. Maybe you can install those packages by hand?

alerque commented on 2021-08-31 19:48 (UTC)

@blennow Add what exactly? This package is just a repackage of a binary build released upstream, modified only enough to fit in a PKGBUILD according to Arch packaging.

blennow commented on 2021-08-31 19:35 (UTC)

Hi, is it possible to add kdialog and kwallet to integrate with Plasma better? Maybe add plasma-browser-integration also.

francoism90 commented on 2021-08-19 07:57 (UTC)

Anyone else having these issues:

gnome-shell[7018]: [7018:7018:0819/] Skia shader compilation error

Think it's caused by the VA-API enabled flag. :/

alerque commented on 2021-08-13 09:24 (UTC)

@zerophase You can't get fresh adblock lists for one. Please take that conversation to the relevant package though, it isn't an issue with this -bin package.

zerophase commented on 2021-08-13 03:11 (UTC) (edited on 2021-08-13 03:13 (UTC) by zerophase)

@alerque What extensions can't run in unofficial builds? Couldn't we just fork the extensions, and enable them?

alerque commented on 2021-08-12 19:02 (UTC)

@srebre It's not an easy as just getting votes. This package is just the upstream binary, for the repos we'd really want to build it ourselves. The brave PKGBUILD does that, but there are other complications (see comments there): Brave Inc. is not letting some extensions run in unofficial builds, plus building it is quite a procedure. That brings us into needing to negotiate license/distribution issues.

I am a TU and have my eye already on moving this to [community] if we can navigate all those dealt with, but don't expect it any time soon. In the mean time using this is your best bet for a working browser (but be aware you're trusting a binary blob built by a for-profit Browser vendor).

srebre commented on 2021-08-12 18:01 (UTC) (edited on 2021-08-12 18:04 (UTC) by srebre)

Since this package has 400+ votes, can we integrate it into the official repositories and who should we reach out to? It's the third most popular package by votes in AUR at the time of writing.

alerque commented on 2021-08-06 17:36 (UTC)

@alosarjos Yes, if it's deprecated we should be pointing the current dependency, optional if it is so. I don't let my browsers or DE session handle secrets, so I'm a little out of that loop. Feel free..

alosarjos commented on 2021-08-06 16:42 (UTC)

@alerque, now that the update thing is gone, the package has libgnome-keyring as optional depdency, which is deprecated for libsecret I think. Should that dedepency be changed?

alosarjos commented on 2021-08-05 20:47 (UTC)

The release of 1.27.111 is inminent. I have the PKGBUILD ready in case alerque can't upload it.

I can confirm that:

  1. The systemd-resolved issues are fixed
  2. Printer preview is working fine (But I didn't test it on the previous version)

alerque commented on 2021-08-05 12:02 (UTC)

@the-k Yes at this point I'm sticking to my original position. You can take it up on the aur-general list or something if you want to make a scene, but to consider yourself warned. @mixedCase already outlined some of the issues with your position. Yes, practically EVERY browser update these days include security fixes of various grades and people should be running the absolute latest where possible.

The checksum in this packaging is basically only protecting you from not noticing a corrupted download file. Since it's not being published and signed upstream when this gets bumped it's basically just a blind download by me or somebody else and we slap the checksum we got on it. This is true of most AUR packages. It's basically just the maintainer saying "this is the one that worked for me". If you think that is a safeguard against browser security issues then, respectfully, you're guilty of security theater. At best it tells you your browser downloads are only being MITMed by the same party mine are and not some nefarious clown at your ISP.

To you are anyone else that wants a new version sooner than we push a bump here, download this repo, edit the pkgver to the one you want, and makepkg -sif --skipinteg it.

zerophase commented on 2021-08-04 18:00 (UTC)

Isn't systemd-resolved not the default DNS setup? I thought the arch install has something else for getting DNS working. By the very definition of it not being default Arch wouldn't an Arch user* have enough skills to fix the problem themselves?

*Distros based on Arch are not supported by the AUR as a best practice. They have their own forums for these issues.

CReimer commented on 2021-08-04 17:07 (UTC)

@duhdugg: Tried it again on my computer at home. Same as on my office computer. Opening the print preview in 1.27.109 segfaults for me

duhdugg commented on 2021-08-04 14:33 (UTC)

leaving security to the user by default is a recipe for disaster

@the-k the AUR exists on the premise that the user has the necessary technical acumen to mitigate the risks of installing user-submitted packages. People using AUR helpers (and "friendly" derivatives) to upgrade packages without review is the much larger risk here.

That said, my argument could also be applied as a reason for bumping the version and telling the user to just reconfigure DNS (the user is just as capable of maintaining their system config for the packages they have installed). Either way, you decide whether to pull the latest changes from AUR and build your package from that. You are always free to fork the package or start your own repo. You may disagree with the maintainer's decision here, but he still doesn't owe you anything.

duhdugg commented on 2021-08-04 14:00 (UTC)

@CReimer no segfaults here on 1.27.109. here is my PKGBUILD

alosarjos commented on 2021-08-04 12:03 (UTC)

I can't believe how people has reacted to having a single -bin package that has no dependants outdated for a few days.

There is a new 1.27 release being due for today or tomorrow which should fix all this.

I still can't believe the behaviour that some package managers have to handle for their work during their free time.

I hope I could help a bit providing as much info as I could on the bug and it's resolution upstream. Thanks a lot to mixedCase and now alerque for their time and effort.

Hoping we can see this package on the community repo at some point too.

the-k commented on 2021-08-04 07:31 (UTC)

@alerque So, are you sticking to your original position or are you gonna take an action? I see some input from other users, yet nobody's really weighing on the security aspect and the fact that leaving security to the user by default is a recipe for disaster.

CReimer commented on 2021-08-04 06:15 (UTC)

I think there's another huge problem with the newer versions of Brave. Anyone else seeing segfaults in print preview?

warwickmm commented on 2021-08-04 02:39 (UTC) (edited on 2021-08-04 02:40 (UTC) by warwickmm)

The update to 1.27.108 is in the package history, so the following works for me (I'm using openresolv instead of systemd-resolved). No need to skip checksums.

$ git checkout 7339c3c && makepkg -sri

Many thanks to @mixedCase and @alerque for all their time and work.

mixedCase commented on 2021-08-04 01:09 (UTC)

@the-k I wasn't even involved on this discussion, I just disowned this package and the new maintainer has immediately been on the receiving end of a rain of caca for differences on how to handle upstream's fuck-ups by people who think it's okay to break a large userbase as long as they get their update early without having to move out of their precious AUR helper, even after the maintainer has already communicated his intention. There's a perfectly good mechanism for handling the issue differently on your system and it takes all of 2 minutes: Clone the repo, bump the version, makepkg -sif. Want to be helpful? Explain your reasoning nicely (good start there by linking to the actual problems) and move on.

Responding with "Duh" to being politely pointed out a solution to your problem, or language like "Are you serious?! Looks like you generally don't take security seriously enough (even though the bar is pretty low)", is clearly past the threshold of constructive criticism, and living in a glass house you better not be throwing stones. Your take on a "realistic" threat model is someone else's joke.

I'm unsubscribing from this feed since I'm no longer using let alone maintaining this package and I've said enough. Hope you find your peace upgrading to 1.27.108 on your machine. Cheers.

danh337 commented on 2021-08-04 00:41 (UTC)

@alerque @mixedCase I appreciate the decision to not force me to change my system config to install a new version of Brave. I hope the Arch community is strong enough to get this browser in the official repos. Thanks for your hard work.

the-k commented on 2021-08-04 00:23 (UTC)

@mixedCase See and Many of those fixes appeared first in M92, Brave 1.26.77 uses M91 (see

I'd like to kindly ask you to tone down on the rhetoric. Being critical isn't intimidation. I've made constructive arguments, I've outlined two possible solutions and I'd welcome a constructive feedback from you, which would help us to fix the issues at hand. Baseless allegations, name-calling and suggestions disregarding the more realistic threat models certainly aren't helpful. Please, let's get back to discussing the real issues.

mixedCase commented on 2021-08-03 22:19 (UTC)

@alerque First off, sorry I left you this shitshow. I hope I'm not overstepping here.

@the-k Feel free to actually point out the security patches to make an argument. I've grepped through the patchset notes and found nothing under a few common security keywords.

But most important of all: If you care about security to the degree you're trying to intimidate a voluntary maintainer into following your own judgment of what's right, then I must suggest you stop making a public clown out of yourself and your own security practices and stop using a release maintained by a third party of a binary someone else compiled, and compile your own damned browser. I'm not even going to suggest you to read the code, let alone audit it, but at least compile it yourself instead of making nonconstructive comments on someone else's release.

the-k commented on 2021-08-03 21:55 (UTC) (edited on 2021-08-03 21:59 (UTC) by the-k)

skip the checksum on build

Are you serious?! Looks like you generally don't take security seriously enough (even though the bar is pretty low).

My not posting that bump here is not depriving you of being able to use the browser.

Duh, I'm talking about this package, not the browser itself. I can still go grab brave package, which includes the relevant patch.

Pushing something known to be broken on at least a large chuck of systems would.

If this wasn't a security upgrade, I'd agree with you 100%. My suggested solution is far from ideal, but it's temporary and it'd make things work while preserving security, which is of the utmost importance. It's also not the only possible solution. You could have made pacman print a short message explaining the situation and describing the workarounds. That way, no downgrade would be forced, and even though the browser would be broken by default on the affected systems, the users would be made aware of the workarounds, which are trivial. Please, keep in mind that we're talking about a security upgrade here.

alerque commented on 2021-08-03 20:01 (UTC)

@the-k I'm sorry, but no, holding back systemd for some -bin package is not a solution I'll be posting here. You are welcome to bump the version number yourself (all it needs in the version number changed and skip the checksum on build). My not posting that bump here is not depriving you of being able to use the browser. Pushing something known to be broken on at least a large chuck of systems would.

the-k commented on 2021-08-03 19:51 (UTC)

@alerque The latest version contains important Chromium security fixes. The correct solution would have been to require systemd-libs<249. The current state prevents me from using this package and deprives the existing users of security.

alosarjos commented on 2021-08-03 10:23 (UTC)

The Chromium team has released the new version with the corrections. I'm not sure if Brave will make a new 1.27 rebased release or if they will wait until 1.28 which is due for next week.

chandradeepdey commented on 2021-08-02 17:19 (UTC)

@francoism90 assuming you are talking about Arch Linux only and not other distributions whose users use AUR for some reason.

It is impossible to say which systems/users are using systemd-resolved.

Still a fraction of users, Arch offers a variety of ways to set up name resolution.

can't assume that they want to adjust their system

Why not? I don't see anything wrong with "if there is a regression, either hold the package yourself or apply the available workarounds"

francoism90 commented on 2021-08-01 07:43 (UTC)

@chandradeepdey It is impossible to say which systems/users are using systemd-resolved. I think there are many, and you can't assume that they want to adjust their system (resolve) settings just for Brave.

duhdugg commented on 2021-07-31 16:10 (UTC)

Fair points, @alosarjos. The package is appropriately flagged as out-of-date currently. I think most types of AUR users are covered.

chandradeepdey commented on 2021-07-31 16:09 (UTC) (edited on 2021-07-31 16:10 (UTC) by chandradeepdey)

@duhdugg oh lol. the workaround was known for 10 days and I found out today. @alosarjos ¯\_(ツ)_/¯

alosarjos commented on 2021-07-31 14:48 (UTC)

I'm not sure it's a good idea to update the package and then show a message telling users to review/alter their system settings to keep Brave working.

We are taking for granted that all Brave-bin users should know how to:

  1. Review their system settings to know if they are or not affected
  2. In case they are, modify those settings that have been working perfectly and still do for everything else
  3. Not only modify, but understand what those modifications mean

Asking people to change their working system settings because of a single package that will be fixed in a matter of days, doesn't sound good to me.

Instead asking the people with the technical skills to know if they can upgrade the package to simply use the provided PKGBUILD in the comments, is by far a safer solution.

Let's remember that there are a lot of user-friendly arch based distros out there where people is using AUR, without knowing even what DNS resolver they are using, and the probably don't even care as long as it works.

duhdugg commented on 2021-07-31 14:20 (UTC)

I confirmed the solution provided by @chandradeepdey on a fresh VM install with the archinstall script's default networking option selected (this is as close to a "default" configuration as possible, although most users are probably still used to configuring their network manually during install). Removing resolve [!UNAVAIL=return] from /etc/nsswitch.conf fixes the issue even with systemd-resolved running (no restart required). Someone in the chromium thread also pointed out that this is specific to a combination of systemd-resolved and libnss_resolve.

@chandradeepdey also brings up a good point regarding security. Given everything we know about this issue right now, I don't think the update should continue to be blocked. There should be a post_install function in this package which notifies users of the problem with resolved+libnss in the current version.

chandradeepdey commented on 2021-07-31 12:28 (UTC) (edited on 2021-07-31 12:29 (UTC) by chandradeepdey)

I think something as adversary facing as Chromium should not be blocked like this. Chromium 92 has multiple security issues fixed.

  1. As acknowledged here already, systemd-resolved is only used by a fraction of the userbase.
  2. The issue can be easily worked around by removing systemd-resolved from /etc/nsswitch.conf and setting it to something like hosts: mymachines files myhostname dns*.

*DNS resolution still happens via resolved, dns uses /etc/resolv.conf which (if symlinked correctly) contains the address of the systemd-resolved stub resolver. I had this idea because Ubuntu does not use the nss module by default and there is no issue there.

alosarjos commented on 2021-07-30 13:44 (UTC)

This is the issue I'm following at least:

Fix is merged into Chromium, but now we have to wait until next Chromium release (Which sould be next week), and then for a new Brave release based on this Chromium release. Which I hope we can get soon after.

For example the official Arch Chromium package has a couple of patches applied that can't be applied here.

Until that the update is frozen. You can update manually if you don't want to wait by using @duhdugg PKGBUILD:

francoism90 commented on 2021-07-30 10:37 (UTC)

Could you guys please link to these issues? :)

Th30 commented on 2021-07-29 15:04 (UTC)

@alerque: Indeed, I do not use systemd-resolved but Unbound.

alosarjos commented on 2021-07-29 09:53 (UTC)

Looks like the fix could arrive at Chrome next week. If that happens let's hope Brave makes a new release rebased on it.

alerque commented on 2021-07-29 08:57 (UTC)

I've just tested 1.27.109 and the situation has not improved. With systemd-resolved in the mix it freezes up hard on startup with an error about not being able to reach the update check site. If I disable systemd-resolved and just use the glibc resolver it works fine.

I'm on the fence as to whether to bump this or not until that is fixed. It's clearly an upstream bug and only affects a subset of users, but I think given how common it is its probably not a good idea to force this through yet. Users that want it can bump the version easily enough themselves since no packaging changes are require other than a version bump and skipping the checksum.

alerque commented on 2021-07-29 07:03 (UTC)

@Th30 What DNS resolver is your system using?

Th30 commented on 2021-07-29 01:44 (UTC)

No problems either in my case using v1.27.109

duhdugg commented on 2021-07-28 20:48 (UTC)

@alosarjos No issues with font rendering.

alosarjos commented on 2021-07-28 15:45 (UTC) (edited on 2021-07-28 16:03 (UTC) by alosarjos)

@duhdugg You don't have any problems with text rendering neither? there is an issue with glibc:

Witch the patches applied to the Arch Chromium build (I think these have not been merged yet and then backported to M92)

PD: Latest version is also available on flathub-beta and work nicely with resolved

alosarjos commented on 2021-07-28 06:39 (UTC)

There seems to be a new release based on a new Chromium version but I can't test it right now. I would wait for the regular chromium update to see if it's still requiring the workarounds

duhdugg commented on 2021-07-28 05:32 (UTC)

The pinned comment is inaccurate. The affected chromium code is broken only on systems using systemd-resolved for name resolution. You can use NetworkManager, dhclient, or dhcpcd with systemd-resolved disabled and not be affected by this bug.

Here's a PKGBUILD for the recently-released v1.27.109 if anyone not using systemd-resolved wants to stay updated until this is sorted out:

alerque commented on 2021-07-26 08:51 (UTC) (edited on 2021-07-29 08:57 (UTC) by alerque)

1.27.108 is known to be broken on Linux for all users using systemd-resolved. Since this is the default on Arch that would make this broken by default, so we won't be pushing it up here until there is another release that addresses the issue. Those wishing to run a newer release using a different resolver can easily do so by bumping the version to 1.27.109 themselves (see other comments).

alerque commented on 2021-07-24 21:31 (UTC) (edited on 2021-07-30 14:54 (UTC) by alerque)

@jorgicio @francoism90 @CReimer @HOuadhour Please see comments below, comments in the PKGBUILD, and commit history. 1.27.108 is known to be broken on Linux, we won't be pushing it up here until there is a fix.

francoism90 commented on 2021-07-24 16:17 (UTC) (edited on 2021-07-24 16:17 (UTC) by francoism90)

1.27.108 is available, however it seems this has been reverted?

alerque commented on 2021-07-24 08:17 (UTC)

@Th30 Thanks for the link to that issue, but that's not actually the blocker we're seeing that has to do with DNS resolution.

Th30 commented on 2021-07-24 02:38 (UTC) ?

D3SOX commented on 2021-07-23 23:05 (UTC)

Sorry for the flag, I have now seen in the changes that you reverted it because it broke.

alerque commented on 2021-07-23 18:56 (UTC)

@mixedCase Best of luck. NixOS is awesome by the way. If Arch were to loose me entirely to something at this point that is the most tempting alternative.

@alosarjos Thanks for that info, that's super helpful. Please do keep us posted here.

I'll probably push out a pkgrel bump to fix some packaging issues (e.g. the license file is not ending up in the right place and there are some other coding style cleanups I'd like to see) but I'll hold off pushing 1.27 until I get word or see it working better.

alosarjos commented on 2021-07-23 18:32 (UTC)

The chromium package in which Brave 1.27 is based has some issues on Linux with rendering and navigation if using systemd-resolved

I'm not sure if pushin 1.27 is a good idea until these are fixed upstream. If I'm not mistaken the Arch Chromium package has added the upstream patches to fix them , but those are not available yet on a Chromium release and thus, are not available on the Brave release and would require a patched Chromium and rebuilidng brave.

mixedCase commented on 2021-07-23 17:59 (UTC)

@alerque TL;DR: I'm disowning this package and there's an update pending.

I pushed an update to version 1.27.108 after successfully checking brave://version and brave://gpu, and after I pushed I found out I was actually unable to load pages. I reverted the commit without pushing epoch since it was only 5 minutes, ran pacman -Syu just in case, rebooted and my system is now unbootable, failing to load kernel modules for whatever reason in both my lts and zen kernels. No will to debug this right now so I'm just going to nuke my Arch partition and move full time to NixOS.

I've unpinned the pinned comment since it's going to be out of date. Here's the one-liner for checking latest version in case it's useful:


Thank you for offering to help!

mostafaroshdy1 commented on 2021-07-17 02:04 (UTC)

Thanks so much , keep it up

mixedCase commented on 2021-07-12 18:31 (UTC)

@alerque Added as co-maintainer, thanks!. Keeping it up to date is not a problem for me, but I'd rather not have a package with many users just left to luck of the draw if I'm no longer able to update it without testing it.

alerque commented on 2021-07-12 18:25 (UTC)

@mixedCase Yes I've had a look at the brave PKGBUILD already. It will need a bit of an overhaul before it's ready for [community]. Since I'm a pretty new TU I'm putting off that project until I know the ropes a bit better.

In the mean time feel free to add me as a co-maintainer if you want less pressure to update this one. I see folks are pretty demanding about it being fresh (to the point of obnoxious). But at least with a couple people ready to poke it you won't feel like you have to fire up another distro just for that. Also if you do disown it that will leave me as the maintainer by inheritance and I'll either run with it or help find a good home.

spsf64 commented on 2021-07-12 18:25 (UTC)

@alerque, thanks for the feedback! @mixedCase, agreed, brave is the one to be merged into community.

mixedCase commented on 2021-07-12 18:19 (UTC)

@alerque AUR package brave does just that with some manual patching, might be worth looking into. On an unrelated topic I'm doing some distrohopping and I may end up disowning this package. In case it comes to that if you'd rather have me notify you or some other TU in advance instead of doing it out of the blue, lmk.

alerque commented on 2021-07-12 18:06 (UTC) (edited on 2021-07-12 18:06 (UTC) by alerque)

@mgdobachesky @spsf64 I have an eye on it. Bringing it to [community] involves building Chromium though which is not trivial. You can't just cram an upstream binary from a -bin package in [community].

spsf64 commented on 2021-07-12 17:53 (UTC)

@mgdobachesky I agree 100%! Can't understand why Brave is not there yet... I'd rather have Brave instead of Vivaldi or Opera (found in std repos).

mgdobachesky commented on 2021-07-12 17:40 (UTC)

We should find a TU to bring this to the community repo :)

mixedCase commented on 2021-06-23 14:45 (UTC)

@The_GodfatherX Cannot reproduce. Sounds like a problem with the AUR helper you're using, try using makepkg.

@maverick1 The package name "brave-deb" is available for the taking in the AUR if you want to try that approach.

maverick1 commented on 2021-06-23 07:27 (UTC)

I really feel like these small issues will be fixed if we go with deb or rpm build.

The_GodfatherX commented on 2021-06-23 06:46 (UTC) is failing the "Validating source files with sha512sums...", all the other files ... Passed
browser.desktop ... Passed
logo.png ... Passed

ive used "pamac build brave-bin"

mixedCase commented on 2021-06-22 17:37 (UTC)

@maxpayne3 Removed x-scheme-handler/ftp from both MimeType declarations.

maxpayne3 commented on 2021-06-22 17:19 (UTC)

Please, reupdate the desktop entry from deb/rmp package, the support for ftp has been removed on Linux. See changelog and #15812.

mixedCase commented on 2021-06-17 14:47 (UTC)


maxpayne3 commented on 2021-06-17 06:44 (UTC)

Please update the desktop entry since the one contained in rpm/deb release has more mimetypes and translations for new window and private window actions.

mixedCase commented on 2021-06-15 15:20 (UTC)

@maxpayne3 Well if you want the details of my reasoning:

Linux is the kernel, yes, that doesn't matter; it's the potential for package-specific hacks that only concern itself with the userspace of Debian-derivatives that I'm concerned about. I don't want to maintain patches for those as a matter of principle, no matter how small, and even if there's none needed now, those packages are meant for Debian derivatives, meaning that upstream is free to break compat with us at any time for they don't officially support running the Debian package in a non-Debian system, and they very explicitly ship a tarball for non-Debian systems. Does this mean they'll add such hacks that break .deb's contents for Arch? Unlikely, but I'd rather stick to reasonable expectations for upstream: *.deb meant for Debian-based distros, Tarball is generic.

But even more important to me is the first thing I mentioned: I don't want to make a big packaging change for so small a gain, it's not worth my time. If your network constraints means that those 33MB are a big difference for you, I'd suggest forking the Google Chrome AUR and adapting it for Brave's deb release, and you can even publish it as a brave-deb AUR package for other people who share the same needs.

Hope that makes sense, sorry I didn't explain myself earlier. Cheers.

maxpayne3 commented on 2021-06-15 12:20 (UTC)

Sorry, but I don't think it's worth reworking the PKGBUILD and adding unnecessary risk using a release not meant for us for 33MB.

Not meant for us? Fedora and Ubuntu are Linux distributions, just like Arch. Those packages include even the desktop entry and logos, so you don't have to provide yours outside. Maybe it's worth give them a try. Google Chrome on AUR is made from the official deb package.

Parintachin commented on 2021-06-14 05:40 (UTC)

The scaling problem appears to have been fixed with the newest release. Thanks for the help again mixedCase (o:

longstation commented on 2021-06-12 15:14 (UTC) (edited on 2021-06-12 15:49 (UTC) by longstation)

@mixedCase Simply adding that flag does show video hardware acceleration on paper. But looking at any videos I found it's using ""Dav1dVideoDecoder" and looking at the CPU usage, I think it's not using GPU for video decoding.

I believe it used to have a build parameter that allows GPU video decoding. Can we get it back?

[update] Just checked the official deb packages. It seems they have switched to compile with vaapi off. I guess unless we compile it ourselves, there's nothing we can do.

[update] OK, filed an issue:

[update] My bad. I probably just played a video that's encoded using AV1. But most of other videos are indeed decoded using GPU. Confirmed by using the media tab of the inspector. Sorry for the confusion.

francoism90 commented on 2021-06-07 10:22 (UTC)

@mixedCase Thanks, that seems to work :)

Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

mixedCase commented on 2021-06-06 14:21 (UTC)

@maverick1 Sorry, but I don't think it's worth reworking the PKGBUILD and adding unnecessary risk using a release not meant for us for 33MB.

@francoism90 That feature moved to a command line parameter when the rebase to Chromium 91 occurred:


You can add it to your .config/brave-flags.conf for convenience.

francoism90 commented on 2021-06-06 11:25 (UTC)

Seems hardware video decoding support has been removed, is it possible to enable the video_decode flag again?

maverick1 commented on 2021-06-05 09:24 (UTC)

Can you switch to the .deb package instead of the .zip one? Its saves 33 MB of download.

Parintachin commented on 2021-05-28 05:53 (UTC)

@mixedCase Yup; running it with --force-device-scale-factor=2 fixes the problem for now.

Parintachin commented on 2021-05-28 04:38 (UTC)

@mixedCase Thanks; I'll have a look at it. And thank you for maintaining the package.

mixedCase commented on 2021-05-28 04:19 (UTC)

@Parintachin I don't support Manjaro. Regardless, sounds like a Google-upstream problem, but I suggest looking at this to see if it helps you override whatever the browser's doing:

Parintachin commented on 2021-05-28 02:51 (UTC)

Manjaro KDE. This package, like the Chrome package that dropped a few days ago, does not play well with high-dpi screens when scaling is chosen. It looks like the scaling factor is applied twice - everything is huge.

chandradeepdey commented on 2021-05-15 08:32 (UTC)

thanks :D

mixedCase commented on 2021-05-14 20:07 (UTC)

@chandradeepdey Patch applied to latest revision. Cheers

chandradeepdey commented on 2021-05-14 14:59 (UTC)

@mixedCase This is perfect. Thanks.

mixedCase commented on 2021-05-12 18:38 (UTC)

@chandradeepdey I don't have a desktop to test icons. Does this patch work for you without breaking the regular shortcut?

chandradeepdey commented on 2021-05-12 09:02 (UTC)

When you install a web app, the following is added to $XDG_DATA_HOME/desktop-directories/

[Desktop Entry]
Name=Brave Browser Apps

Brave expects the icon to be named brave-desktop. This package puts it as brave, can this be changed?

a821 commented on 2021-05-10 07:39 (UTC)

@zerophase the --reflink option was used to speed up the packaging phase by doing a lightweight copy of the package contents to $pkgdir. It had no effect whatsoever on brave-bin performance. See cp(1) manual.

I have had no issues with brave lately, but I do not use it that much.

zerophase commented on 2021-05-10 06:13 (UTC)

For anyone having issues with the browser loading the 1.25 brave-beta-bin browser fixes the problem. If we all of that issue it might be worth updating to the beta here anyways.

zerophase commented on 2021-05-10 05:46 (UTC)

Having issues with Brave refusing to load pages. Seems to have gotten worse with the latest update.

@mixedCase Could removing that reflink=auto flag break GNU releases? Can't we just add a flag or detection method for using a version of those lines with and without it? Isn't it pretty easy to detect if someone does not have cp? I think it's like 4 lines of a script.

Some of those optimizations definitely impact performance depending on how the code is written in certain use cases.

mixedCase commented on 2021-05-02 19:16 (UTC)

@Th30 I don't use Brave rewards, but I've seen people complaining about the same thing in the Brave subreddit. Seems like a cross-platform issue.

Th30 commented on 2021-05-02 06:07 (UTC)

I haven't had any 'brave rewards' ads in about two months. Is it the same for you?

mixedCase commented on 2021-04-30 21:08 (UTC)

@konicks Arch is a GNU system, GNU cp being part of the base package and therefore expected. And reflink=auto is a behavior that should be the default in coreutils to make use of CoW where possible.

But... honestly this is such a pointless optimization and you went through the trouble of asking so giving you the benefit of the doubt that you actually have a usecase for it, I went ahead and removed it.


konicks commented on 2021-04-29 10:43 (UTC) (edited on 2021-04-29 14:56 (UTC) by konicks)

@mixedCase sorry to bother but would you please remove the GNU only flag in the first cp command of the package function (--reflink=auto)? It's better to only use POSIX compliant flags in scripts and packages (man 1p command for posix man page of that command) and because of that flag the package doesn't build on systems with different userland coreutils (BSD, Plan9, BusyBox, ToyBox, UNIX v5, etc). Also, the flag is pretty weirdly placed and doesn't seem to serve a concrete role in significantly improving build speed or build quality, it's just kinda...there, and it means the package requires modifications on non GNU systems

I made a modified PKGBUILD file:

Cheers, Nick

danh337 commented on 2021-04-19 20:13 (UTC)

What are the "rules" for votes? As in, who actually looks at them? Should we be voting for the source "brave" package instead? Thanks for your work on this!

mixedCase commented on 2021-03-29 00:37 (UTC)

@ThePierrezou I don't know of any place where Brave uploads signatures (if they even make one) for the files we build upon. Patches welcome if there's actually such a place.

ThePierrezou commented on 2021-03-28 21:35 (UTC)

Is it possible to get the PKGBUILD to verify the signature of the package please ?

WFV commented on 2021-03-27 05:32 (UTC)

Thanks for the bin package! Compiling brave takes over 6hr on this machine so really appreciate your contribution! Last time updated brave it timed out on a chromium request (continued to build) as I was asleep.

mixedCase commented on 2021-02-22 14:59 (UTC)

@laba I have not, this script pretty much just repackages upstream binaries as you can check yourself. Also AFAIK all Chromium derived browsers use system DNS on Linux and, well, I'm getting with DNS over TLS for I have that set up in systemd-resolved.

I can't find anyone mentioning this in the issue tracker either so it sounds like it's just your system's DNS configured to do that as well.

laba commented on 2021-02-22 10:45 (UTC)

@mixedCase Hi, I noticed a strange think in that brave version. It uses cloudflare dns server with dns over tls enabled even if brave doesn't support neither dns server changing nor enabling dns over tls or https on GNU/Linux. So, have you added it to brave or they have enabled it and haven't said anything ? It's really strange.

mixedCase commented on 2021-02-15 00:24 (UTC)

@anjanik012 @Takuya For an AUR package to go into [community] it requires adoption by a trusted user, which I'm not, don't want to be, and I haven't received word from one interested in adopting the package.

Additionally, this is the binary distribution from upstream, I'm almost certain TUs would rather adopt the package that is built from source, which is

The person who maintains that package keeps a binary repo for it. If you're comfortable with using third party repos and your goal is just to not have to deal with the AUR for updating your browser, might want to look into it.

Takuya commented on 2021-02-14 11:22 (UTC)

@anjanik012 I'm hoping that will change in the near future, Vivaldi already did it, a few months ago, hoping more users will vote this package so we could have it on the official repos :). So the answer to your question, I suppose that will be when this package receives much more votes from the AUR community :D.

anjanik012 commented on 2021-02-14 05:44 (UTC)

Why is this package not in the official repos?

mixedCase commented on 2021-02-05 20:30 (UTC)

@kiankasad I had forgotten to remove it after Brave fixed the SUID sandboxing fallback not working on their side and I was reminded of it by e-mail, mentioned in commit description.

Comment unpinned, thanks for the reminder.

kiankasad commented on 2021-02-05 20:18 (UTC)

I noticed that with the update to 1.19.92-1, the check for user namespaces is removed from Why exactly is this?

Also, with this change in effect, @simonorono's comment can be un-pinned, since the kernel.unprivileged_userns_clone sysctl no longer affects anything.

mixedCase commented on 2021-01-29 20:26 (UTC)

@nowy Thanks for the reminder! That had slipped up my mind. Removed.

nowy commented on 2021-01-28 23:46 (UTC)

I think pepper-flash is no longer needed for brave since it's chromium version upgraded to 88.

gameslayer commented on 2021-01-20 06:53 (UTC)

It's ok, I cleared my AUR cache and re did it and it worked fine

mixedCase commented on 2021-01-20 05:14 (UTC)

@gameslayer Which one? I just redownloaded everything and it checksums.

gameslayer commented on 2021-01-20 03:33 (UTC) (edited on 2021-01-20 04:19 (UTC) by gameslayer)

ERROR: One or more files did not pass the validity check!

mixedCase commented on 2021-01-03 15:43 (UTC)

@maxpayne3 Sorry if that came across as a discussion on the merits/demerits of Nautilus, give me a chance to state the problem in simpler, unbiased terms:

This is a Nautilus bug in their handling of FTP.

There is no browser or app producing an issue, Nautilus just has a bug where it doesn't open FTP files properly if there's an FTP client in the system. The only situation where it's not a bug is if, by design, Nautilus expects the user to never have an app with FTP support installed.

maxpayne3 commented on 2021-01-03 09:39 (UTC) (edited on 2021-01-03 10:27 (UTC) by maxpayne3)

@mixedCase I'm not interested in opening a discussion on how Nautilus is bad.

My only knowledge is that the browsers which produce this issue are Brave and Google Chrome, both not officially supported on upstream and hosted on AUR. No other browser in upstream I use, I have installed some, Firefox, Otter, Gnome Web, throw this issue since they don't have ftp mimetype in their desktop entry.

Maybe guys on upstream are wrong? Who knows? If you don't want to modify it, it's not a big deal, I already have a custom entry in local folder, but I suggested it to avoid users who use ftp share to blame Brave or going to Nautilus bug report to hear that it's a packaging problem.

mixedCase commented on 2021-01-01 21:29 (UTC) (edited on 2021-01-01 21:29 (UTC) by mixedCase)

@maxpayne3 I want to give Mr. Holy the benefit of the doubt but what he said on that issue there makes no sense, even after reading the linked issue. It's a terrible workaround as Brave (or Firefox, in that case, at that time) does support FTP and correctly advertises it according to the XDG MIME Spec.

I'm open to being completely wrong, but from the info I have it's pretty obvious that Nautilus' networked share implementation is just bad UX and it's pretending to the user that it's working in "just another folder" while not hiding properly the fact that the file is remote by passing the URI instead of a file to their file opener. They should either make something like a FUSE filesystem that mounts on the fly if they want to make good UX for their facade, or have GIO have a special way deal with their incorrect behavior.

In the meantime the most user-friendly solution I would recommend is using a dedicated FTP client like FileZilla. If you really want to use Nautilus for accessing FTP, you can manually do what Nautilus should be doing for you and mount your remote FTP server in a folder of your convenience using a FUSE filesystem for FTP like curlftps.

maxpayne3 commented on 2021-01-01 10:58 (UTC)

@mixedCase please, modify the desktop entry removing x-scheme-handler/ftp in MimeType lines.

This will fix this issue. Thanks.

Netboy3 commented on 2020-12-03 14:50 (UTC)

@mixedCase, thanks for the quick response. I know that the sandbox binary is not used unless userns is not available. My issue is dropping a 3rd party prebuilt binary that is SUID root into my machine in the 1st place. I would prefer having as few SUID root executables as possible. Though I don't favor with the decision, I now understand your reasoning behind making this change. Sorry if I came out too harsh previously.

mixedCase commented on 2020-12-02 23:32 (UTC)

@Netboy3 Under a normal Arch install the SUID sandbox is not used. User namespaces are used. Check brave://sandbox/ before getting your panties in a twist again. If it's not the case then it is indeed a bug and you can report it accordingly like an adult.

The reason I fixed it is because some security-minded people think that running Arch with third-party packages is super-fine security wise but user namespaces is a bit too much for their threat model and trust the SUID sandbox more than unprivileged user namespaces. Well they're big boys, Brave officially supports their usecase ( and I'm not going to make a stand just because I personally think it's pointless; that's why I set the right perms needed for it instead of letting it be copied over for no reason with the generic perms it had before.

As a downstream packager I try to keep Brave's intentions for the release intact, in that same vein I will not be restoring it if Brave changes their mind and/or Google finishes removing it upstream. Firebird wants to use SUID sandbox, Brave supports it, it takes me no effort to do so so I will support it too, and if you don't like it then go file an issue to Brave or do maintain your own package.

Netboy3 commented on 2020-12-02 22:52 (UTC)

@mixedCase, I don't understand the logic of your last change (commented on 2020-11-24 17:42). You admit that the SUID method is deprecated, and users should use unprivileged namespaces, yet you modify the install to set a third party binary installed with SUID root. I'm sorry but this is illogical and irresponsible, especially considering the number of votes and the popularity of this package. And there's a big difference between the need to use QubesOS and setting an unverified binary SUID root. Hopefully, enough folks will read this comment and either move away from this package, or package it by themselves (like I will from now on).

mixedCase commented on 2020-11-24 22:42 (UTC) (edited on 2020-11-24 22:43 (UTC) by mixedCase)

@rageltman It's trying to get Brave to run with the upstream-deprecated SUID sandbox instead of the officially supported user namespaces sandbox.

Just added it since it seems inoffensive for userns users but I won't be doing anything weirder than that for supporting the SUID sandbox.

Some unsolicited advice: I would recommend QubesOS and not trusting guys like me to do your packaging if you have that level of concern.

rageltman commented on 2020-11-24 17:57 (UTC)

The sandbox binary doesn't have the correct permissions set. Need to chmod 4755 $pkgdir/usr/lib/brave-bin/chrome-sandbox in the package() call or the bug prevents launching the browser at all (at least under firejail):

[6:6:1124/] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib/brave-bin/chrome-sandbox is owned by root and has mode 4755.

mixedCase commented on 2020-11-18 18:14 (UTC)

@kiankasad Applied. Thanks

kiankasad commented on 2020-11-18 18:06 (UTC)

@mixedCase I figured out why. makepkg doesn't put the extracted files in a subdirectory. Anyways, here's a patch to remove the useless cat:

diff --git a/PKGBUILD b/PKGBUILD
index 429d407..3f76b95 100644
@@ -35,7 +35,7 @@ noextract=("$pkgname-$")

 prepare() {
   mkdir -p brave
-  cat $pkgname-$ | bsdtar -xf- -C brave
+  bsdtar -xf $pkgname-$ -C brave
   chmod +x brave/brave

mixedCase commented on 2020-11-18 17:42 (UTC)

@kiankasad original maintainer set it up that way and it works. Changing it means changing directory structure and me having to lookup manpages, but it isn't an issue so I don't care about it.

Patches welcome if it bothers you enough.

kiankasad commented on 2020-11-18 17:35 (UTC)

The prepare function is slightly confusing:

prepare() {
  mkdir -p brave
  cat $pkgname-$ | bsdtar -xf- -C brave
  chmod +x brave/brave

Why cat the archive into bsdtar instead of using bsdtar -xf $pkgname-$ -C brave? Why extract the archive this way at all? Can't makepkg do that automatically after downloading?

mixedCase commented on 2020-11-18 14:43 (UTC)

@eronis55 libnotify integration is working fine here. Just added it to optdepends to make it clear that you need to have libnotify.

Other than that, I don't use Brave rewards so I need feedback by users who do to see what kind of errors they're seeing in their terminal when running Brave from it.

eronis55 commented on 2020-11-18 13:17 (UTC)

Brave Rewards function has a problem with your package. It may be that you need to add some new dependencies or something like that.

mixedCase commented on 2020-10-13 00:03 (UTC)

@kiankasad Pushed a fix for this and removing an obsolete workaround. Thanks for the report and collaboration! Please let me know if you have any issues.

kiankasad commented on 2020-10-12 23:51 (UTC)

@mixedCase I think that'll work. As far as I can tell, this pseudocode covers all use cases:

   if kernel.unprivileged_userns_clone=0:

mixedCase commented on 2020-10-12 23:46 (UTC)

@kiankasad Well what I'm seeing is that user namespaces do seem to be enabled by default on Arch. But the kernel parameter is still a thing and it seems to be a way to disable them, which linux-hardened uses and I imagine some users do as well.

Can you confirm you're using a kernel without Arch patches? I can change the script to simply run --no-sandbox if the kernel param exists and is set to 0, I gather that should do it without breaking users of the kernel param.

kiankasad commented on 2020-10-12 22:24 (UTC) (edited on 2021-01-18 20:03 (UTC) by kiankasad)

@mixedCase I linked an image to brave://sandbox results in my previous comment.

mixedCase commented on 2020-10-12 22:21 (UTC)

@kiankasad I think you misread the wiki article, it mentions that the feature is enabled only for root in linux-hardened, while in every other kernel enabling the feature does it for all users. Relevant section:

Firstly, a kernel is required that has support for User Namespaces (a kernel with CONFIG_USER_NS). All Arch Linux kernels have support for CONFIG_USER_NS. However, due to more general security concerns, the linux-hardened kernel does ship with User Namespaces enabled only for the root user. There are two options to create unprivileged containers there:

Start the unprivileged containers only as root. Enable the sysctl setting kernel.unprivileged_userns_clone to allow normal users to run unprivileged containers. This can be done for the current session with sysctl kernel.unprivileged_userns_clone=1 and can be made permanent with sysctl.d(5).

If this is not upstream behavior, then this is patched downstream in the same manner by Arch as well. Just to make sure, I downloaded latest ISO and booted a virtual machine and sure enough, its kernel recognizes it, and I also added some nonsense to corroborate my knowledge that sysctl fails on a nonexistent parameter:

Can you share what brave://sandbox returns for you? Perhaps they've reenabled the deprecated setuid sandbox for some reason; in which case I'd still rather just point users to use the one that actually has been maintained upstream by Google for the past few years.

kiankasad commented on 2020-10-12 21:30 (UTC) (edited on 2021-01-18 20:04 (UTC) by kiankasad)

@mixedCase It's provided by a Debian kernel patch:
Grepping in the Linux source code returns nothing. I'm not sure why the file exists on your machine, but with the stock Arch kernel, it isn't there:

$ sudo ls /proc/sys/kernel/unprivileged_userns_clone
ls: cannot access '/proc/sys/kernel/unprivileged_userns_clone': No such file or directory

User namespaces will work with the default Arch kernel, even if the kernel.unprivileged_userns_clone option does not exist (as long as CONFIG_USER_NS=y). I've removed the check from the launcher script and sandboxing works fine: (The yama support is unrelated)

This fix has already made it into brave-nightly-bin

EDIT: that ArchWiki page specifically states that that sysctl option is for the linux-hardened kernel, and it does not say to do anything to enable unprivileged user namespaces on the default kernel.

mixedCase commented on 2020-10-12 20:42 (UTC)

@kiankasad Not sure what gave you that idea, are you using linux-hardened perchance?

kiankasad commented on 2020-10-12 18:08 (UTC) (edited on 2020-10-12 21:38 (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

I know there's a pinned comment describing how to fix this, however that fix does not work, since that kernel option is nonexistent on Arch.

mixedCase commented on 2020-10-07 21:29 (UTC)

Thank you @urbenlegend, the script has been updated to the latest version and to no longer use the .deb workaround.

urbenlegend commented on 2020-10-07 20:40 (UTC)

According to the latest release notes, Brave zip should have the OpenGL files included now, so the deb is no longer needed.

mixedCase commented on 2020-09-29 13:20 (UTC)

@numToStr It's a temporary workaround for an upstream packaging issue which has been supposedly fixed in Brave master already but will take a little while to trickle down into stable.

numToStr commented on 2020-09-29 10:03 (UTC)

Why is there .zip and .deb packages?

mixedCase commented on 2020-09-18 13:45 (UTC)

@francoism90 No I'm not getting that, with or without Vulkan. I don't have that file either but the browser doesn't seem to complain about it.

francoism90 commented on 2020-09-18 11:28 (UTC)

@mixedCase Thanks, hope it can be solved soon.

Is this normal:

$ brave
[775988:775988:0918/] Device registration failed with fatal error
[775988:775988:0918/132645.654279:ERROR:CONSOLE(1)] "[Shields]: Can't request shields panel data. Error: No tab url specified", source: chrome-extension://.../out/brave_extension_background.bundle.js (1)
Failed to parse JSON adblock resources: EOF while parsing a value at line 1 column 0
[776256:776256:0918/] Failed to load /usr/lib/brave-bin/swiftshader/ /usr/lib/brave-bin/swiftshader/ cannot open shared object file: No such file or directory
[776256:776256:0918/] Exiting GPU process due to errors during initialization

mixedCase commented on 2020-09-14 13:23 (UTC)

@francoism90 Yup I found one already there after my last comment and indeed it seems to be at least AMD specific:

According to that thread there are a few more usable workarounds if the Vulkan renderer gives any trouble.

francoism90 commented on 2020-09-14 13:12 (UTC)

@mixedCase I'm using amdgpu (no navi). Do you have a bug report? :)

mixedCase commented on 2020-09-14 12:43 (UTC)

@francoism90 It's an upstream bug, it happens to me with Google Chrome as well. Are you perhaps also using amdgpu with a Navi card?

francoism90 commented on 2020-09-14 05:59 (UTC)

After the latest upgrade, I'm having graphical corruption issues. Could the latest WebGL patches have something to do with this? After switching to Vulkan as backend, the issues seem to be gone, but it's weird as they one appeared on Brave.

My reported GPU settings:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated on all pages
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Enabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

If I disable Vulkan, the GPU issues start popping up. If this is an upstream bug, please let me know, just checking if I'm the only one. :)

mixedCase commented on 2020-09-11 05:40 (UTC)

@maverick1 The .deb uses a completely different structure and a PR is already open upstream to fix the WebGL issue for the .zip; so I'd rather not rework the PKGBUILD specially when the .zip is the official non-Debian distribution of Brave.

This nuisance too, shall pass.

maverick1 commented on 2020-09-11 03:50 (UTC)

This PKGBUILD downloads both .zip and .deb files. But I have seen people in Solus just packaging it with .deb. I know that you included the .deb package to fix WEBGL stuff. So is there a chance to completely switch to .deb only.

mixedCase commented on 2020-09-08 14:39 (UTC)

@TripleSpeeder Thanks for the heads up, I just pushed the workaround to do so.

Meaning that IN THE MEANTIME until Brave unfucks their shit in that particular area, everyone will have to download the browser twice on install. Please report in case this workaround works for you, or breaks things even more.

TripleSpeeder commented on 2020-09-08 09:52 (UTC)

Upstream version 1.13.82 broke webGL (and probably all hardware acceleration). The upstream zip release is missing some libraries.

This bug is tracked at

@mixedCase, maybe you can release an interim version that includes the missing libs? See for instructions :-)

mixedCase commented on 2020-07-21 21:02 (UTC)

@cikisir Alright, then you can go complain on upstream about the issues you're having or ask for browser recommendations in the forums, IRC, subreddit. This is not the place for it.

mixedCase commented on 2020-07-21 20:36 (UTC)

@cikisir This is not the brave package, this is the brave-bin package. This is a binary package, if you see anything compiling then you're probably installing the other package.

Try installing this package and see if your issues persist.

mixedCase commented on 2020-07-16 18:47 (UTC)

Thanks for the reports everyone, package has been updated to tolerate yet another of Brave team's fuck-ups where they remove the LICENSE files for whatever reason.

diomekes commented on 2020-07-16 18:32 (UTC) (edited on 2020-07-16 18:34 (UTC) by diomekes)

Yes, it is messed up at the moment. But, all you have to do is remove the last line in the PKGBUILD because it's looking for license files that don't exist. (This does need to be fixed in the package of course, but if you just want it to install...)

Skaper commented on 2020-07-16 18:17 (UTC)

@mixedCase I did try cloning using the link above and run makepkg -si. I still got the same error as @ragouel What other ways are there to update an AUR package? I used YAY.

FredBezies commented on 2020-07-16 18:16 (UTC)

@mixedcase: Done a yay -G brave-bin.

Entered brave-bin directory. Entered makepkg -s. Broken. Full log:

$ makepkg -s
==> Making package: brave-bin 1:1.11.97-1 (Thu Jul 16 20:15:25 2020)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found
  -> Found
  -> Found brave-browser.desktop
  -> Found logo.png
==> Validating source files with sha512sums... ... Passed ... Passed
    brave-browser.desktop ... Passed
    logo.png ... Passed
==> Extracting sources...
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
mv: cannot stat '/home/fred/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSE': No such file or directory
mv: cannot stat '/home/fred/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSES.chromium.html': No such file or directory
==> ERROR: A failure occurred in package().

Your PKBGUILD is broken.

mixedCase commented on 2020-07-16 18:06 (UTC)

@ragouel Try not using an AUR helper and post again if you have issues.

ragouel commented on 2020-07-16 18:01 (UTC)

mv: cannot stat '/home/crow/.cache/yay/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSE': No such file or directory
mv: cannot stat '/home/crow/.cache/yay/brave-bin/pkg/brave-bin/usr/lib/brave-bin/LICENSES.chromium.html': No such file or directory

mixedCase commented on 2020-06-24 23:42 (UTC) (edited on 2020-06-24 23:42 (UTC) by mixedCase)

@Serial I just tried redownloading again and the checksum checks out fine. Looking at your screen it appears that you're dealing with a bad internet connection and the file ends up being corrupted.

I'd suggest trying two things:

a) Don't use an AUR helper. Clone this package's git repo and run makepkg -si on it.

b) If the problem persists, attempt to download the upstream .zip file from a web browser.

Serial commented on 2020-06-24 23:35 (UTC)


Preparing... Cloning brave-bin files to compile ... Checking 1brave-bin dependencies ... Synchronizing package database ... Updating community.db ... Solving dependencies ... Checking package conflict ... Dtkgui (5.2.2-1) download started Checking keyring ... Checking package integrity ... Loading package files ... Checking file conflict ... Updating dtkgui ( -> 5.2.2-1) ... Running post-transactional hooks ... Arming ConditionNeedsUpdate ... Reloading system bus configuration ...

Building brave-bin ... ==> Creating the package: brave-bin 1: 1.10.97-1 (Wed 24 Jun 2020 20:28:06) ==> Checking runtime dependencies ... ==> Checking build time dependencies ... ==> Getting fonts ... -> Found -> Found -> Found brave-browser.desktop -> Found logo.png ==> Validating source files with sha512sums ... ... FAILED ... passed brave-browser.desktop ... passed logo.png ... Passed ==> ERROR: One or more files have not passed the validity check! Failed to compile brave-bin

View image: ( )

mixedCase commented on 2020-06-24 02:35 (UTC)

@Serial Cannot reproduce, was just able to redownload.

Serial commented on 2020-06-24 00:45 (UTC)

==> ERROR: Failed to download Aborting ... Failed to compile brave-bin

mixedCase commented on 2020-04-28 01:18 (UTC)

@genelocated Sorry I'm answering late, e-mail got lost in a mountain of crap.

A new version has been pushed. Please let me know if this is now behaving correctly and on what desktop you've observed the behavior whether correct or not.

Thanks for the report and patch!

chuangzhu commented on 2020-04-21 03:52 (UTC)

@mixedCase Please add Actions property under the [Desktop Entry] section:


 [Desktop Action new-window]
 Name=New Window

kronikpillow commented on 2020-04-15 21:52 (UTC)

solved ... seems that the brave update domain was blocked in my hosts file facepalm I'm embarrassed

mixedCase commented on 2020-04-15 14:30 (UTC)

@kronikpillow Yes, this was a new random extension by Google that I had never used before. I did not reinstall the entire OS to test it, however I just tried testing again by deleting the Brave configuration folder and using a fresh profile with a new add-on. Works just fine.

Try to open Brave in a terminal to get console output and also keep the developer tools open (in network tab, and press escape to open console at the bottom as well) while using the Chrome web store to see if any failures are apparent.

kronikpillow commented on 2020-04-15 14:22 (UTC)

@mixedCase are you sure? have you tried installing a extension or are you using previously installed ones? I'v been having this problem for quite some time now, first I thought it was a error from upstream, reported it there, and they claim its not a upstream issue ... Im on a freshly reinstalled system, with a fresh install of Brave, when i go to the chrome webstore and click add to brave, the download interupts, and when I try to download an extension with a extension downloader service, it downloads, and when i drag and drop it to brave it restarts the propmt for download, and just redownloads it again, meaning it doesn't give me a option to install it

mixedCase commented on 2020-04-15 13:01 (UTC)

@kronikpillow Working fine here. Months ago I had a similar issue and I think it solved itself after a reboot.

kronikpillow commented on 2020-04-15 11:26 (UTC)

after fresh system reinstallation, I can't install chrome extensions anymore, download interrupts ... reported to mainstream they claim that it works for them, is anyone experiencing similar issues?

core_contingency commented on 2020-04-03 01:04 (UTC)

Thank you for maintaining this! I am always surprised by how quickly you update this package, and it is really nice to have an Arch package for Brave.

francoism90 commented on 2020-04-02 07:30 (UTC)

@mixedCase I don't think upstream will solve this as it depends on mesa and other stuff as well.

mixedCase commented on 2020-04-01 20:24 (UTC)

@francoism90 This PKGBUILD packages the official Brave release. Let upstream know about this in either an existing GitHub issue or a new one.

@monson This PGKBUILD makes a system package owned by Pacman, matching Arch's official Chromium distribution and compliant to FHS 3.0, it's funny you ask because I actually got an e-mail about this around a couple of weeks ago.

Anyway my interpretation of the FHS and what Arch does is that /opt is more for the sysadmin dumping programs that don't follow the system hierarchy and the files aren't owned by the package manager. Although sometimes packagers can't (or can't be arsed to) reorganize everything so they make packages that dump everything to /opt.

monson commented on 2020-04-01 07:44 (UTC)

Since it is a stand-alone binary application provided by commercial company, would it be better if put into /opt/brave instead of /usr/lib/brave-bin?

francoism90 commented on 2020-04-01 07:30 (UTC) (edited on 2020-04-01 07:31 (UTC) by francoism90)

@mixedCase Could you please add the following patch from chromium-vaapi but based on Brave?

It is possible to enable VA-API in Brave, but the color corruptions keep happening.

AlphaPepe commented on 2020-02-26 05:08 (UTC)

Thanks for this. The community package is always out of date. Works great!

mixedCase commented on 2020-02-10 22:40 (UTC)

For those who were having issues: Brave has released version 1.3.115 with sync disabled, which apparently was the cause of the crashes.

Krzychu commented on 2020-02-09 10:10 (UTC) (edited on 2020-02-09 10:11 (UTC) by Krzychu)

@mixedCase on 1.3.113 I got similar errors to those reported by Philotomy.

Here's terminal output:

[9789:9789:0209/] InitializeSandbox() called with multiple threads in process gpu-process.

9794:9806:0209/] Recvmsg error: Connection reset by peer (104)

/usr/bin/brave: line 27: 9766 trace/breakpoint trap (core dumped) usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS

The very first error line can be safely ignored - it's also thrown on 1.3.114. The next two are specific to 1.3.113 and probably are the cause of problems.

I don't think there is much to play with. Especially since it worked perfectly before - since like 1.0.X. It also works great with 1.3.114. Due to this I'm going with 1.3.114 for the moment.

Out of curiosity, I just took a look at brave community - the issues is reported by various Linux and Mac users. Brave recommends to give 1.3.114 a try (they called it a test version). So indeed 1.3.114 is some kind of pre-release. According to this topic 1.3.114 helps for some, but not all. Link:

I have noticed one thing though. On my other device with Windows 10, the installed version of brave is still 1.2.43. Brave auto-updater doesn't find new version. I think it's more of fun fact and it will update to 1.3.X at some point.

Philotomy commented on 2020-02-09 04:15 (UTC)

I'm also seeing the behavior Krzychu reported with 1.3.113 (crash upon launch). Messages are:

error: package 'pepper-flash' was not found mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! [2841:2841:0208/] InitializeSandbox() called with multiple threads in process gpu-process. [2847:2851:0208/] Recvmsg error: Connection reset by peer (104) /usr/bin/brave: line 27: 2816 Trace/breakpoint trap (core dumped) /usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS

mixedCase commented on 2020-02-08 22:31 (UTC)

1.3.113 is currently working fine here on a couple of machines.

1.3.114 is still marked as pre-release (now almost 24 hours after first tagging it) and this package strictly follows upstream so I can't switch to that.

@Krzychu if you could go into detail about the kind of error you see on the terminal when launching Brave 1.3.113 maybe we know if there's something else at play.

Krzychu commented on 2020-02-08 10:06 (UTC)

In my case update to 1.3.113 broke brave - it would crash before letting me open any page. There is already newer version - 1.3.114. I have manually updated brave and it seems like the issue is fixed.

Hope this helps some folks that will also encounter similar problem. Or if you haven't updated yet you might want to wait till maintainer updates package to 1.3.114.

commented on 2020-02-03 18:11 (UTC)

You are quite right. I was building the brave build by mistake ... wow never again I will build that - sorry for the confusion and thanks for maintaining the bin version

spsf64 commented on 2020-02-03 11:20 (UTC)

@erikdubois, I believe you are talking about package "brave", not brave-bin??

commented on 2020-02-03 09:45 (UTC)

I am currently building brave-bin and it takes as super long time. What I am worried about is the message It is downloading at 90% finished and I have 18GB downloaded - can this be correct?

mixedCase commented on 2020-01-08 19:26 (UTC)

@Yazarai Yeah not sure what that was all about but I was able to reproduce that it will not run after disabling user namespaces.

Honestly? The setuid sandbox will be deprecated upstream and the Brave team seems to want to support it even less so I suggest to just enable them, it's not like no-sandbox will be secure. But I will leave the workaround at least not to annoy current users.

Yazarai commented on 2020-01-08 19:02 (UTC) (edited on 2020-01-08 19:05 (UTC) by Yazarai)

@mixedCase Hey again! Apparently I missed something in my report, as now Brave won't even open. I then tried to open from the terminal and this was the output:

[16186:16186:0108/] No usable sandbox! You probably need to enable user namespaces in your kernel. See <> for more information.

/usr/bin/brave: line 22: 16186 Trace/breakpoint trap (core dumped) /usr/lib/brave-bin/brave "$@" $PEPPER_FLASH_FLAG $USER_FLAGS

Really weird considering what upstream said and showed. Could the problem be anything aside from the zip?

mixedCase commented on 2020-01-08 18:23 (UTC)

@Yazarai Thanks for the great report! 1.2.42 was just released so I just removed the --no-sandbox workaround. Please let me know if any issues arise in systems without user namespaces.

Yazarai commented on 2020-01-08 18:12 (UTC)

Dear maintainer,

With the 1.2.41 release, Brave has begun to allow the use of Chromium's sandbox when user namespaces are disabled: This was done partially out of security concerns about user namespaces as a sandbox - see for details.

However, still contains a command that makes the browser run with the --no-sandbox flag when namespaces are disabled, which is no longer necessary and makes it impossible to run the other sandbox. Please fix this.

romero commented on 2019-11-20 11:30 (UTC) (edited on 2019-11-20 11:31 (UTC) by romero)

@mixedCase - thanks; that did the trick! I just pulled and did 'pacman -Scc'. (PS AUR helpers are an abomination ;)

igvalor commented on 2019-11-20 11:29 (UTC) (edited on 2019-11-20 11:30 (UTC) by igvalor)

==> Validating source files with sha512sums... ... Passed
    MPL2 ... FAILED ... Passed
    brave-browser.desktop ... Passed
    logo.png ... Passed

mixedCase commented on 2019-11-20 04:43 (UTC)

Cache was certainly not cleared if that's the case. Just delete the MPL2 file from the root directory of the AUR repo and run makepkg -si again. If you're using an AUR helper check its documentation on how to properly clear cache.

romero commented on 2019-11-20 04:22 (UTC)

@cubic - cache cleared and still get error about validity check (MPL2 ... FAILED)

cubic commented on 2019-11-19 11:59 (UTC)

@TeaKov clear cache

TeaKov commented on 2019-11-19 11:25 (UTC)

The MPL2 license checksum still fails over here

mixedCase commented on 2019-11-19 01:23 (UTC)

License checksum is now fixed, thanks for reporting.

trevdev commented on 2019-11-19 01:19 (UTC)

==> Validating source files with sha512sums... ... Passed MPL2 ... FAILED <==== Uh-oh! ... Passed brave-browser.desktop ... Passed logo.png ... Passed ==> ERROR: One or more files did not pass the validity check!

commented on 2019-11-15 17:16 (UTC)

Brave is finally 1.0!

I think its time to switch Brave Browser to Community repo!

commented on 2019-11-04 17:49 (UTC)

@nuc you have installed brave instead of brave-bin. its a big difference. Thats why Arch Linux doesn't recommend AUR helper. I actually clone the package with git and install it.

If you use yay you must be careful with package's name

nuc commented on 2019-11-04 16:54 (UTC)

Upon updating Brave wants to download around 17GB of files, I dont even have that much space on my disk so I am unable to update:

Syncing Gclient (with reset)
/home/nuc/.cache/yay/brave/src/brave-browser: gclient sync --force --nohooks --with_branch_heads --with_tags --upstream
WARNING: Your metrics.cfg file was invalid or nonexistent. A new one will be created.
1>________ running 'git -c core.deltaBaseCacheLimit=2g clone --no-checkout --progress /home/nuc/.cache/yay/brave/src/brave-browser/_gclient_src_OBT96Y' in '/home/nuc/.cache/yay/brave/src/brave-browser'
1>Cloning into '/home/nuc/.cache/yay/brave/src/brave-browser/_gclient_src_OBT96Y'...
1>remote: Sending approximately 17.37 GiB ...        
1>remote: Counting objects: 230269, done        
1>remote: Finding sources: 100% (319/319)           
^CReceiving objects:  68% (9106301/13229268), 9.70 GiB | 12.13 MiB/s

Anyone knows whats going on?

commented on 2019-10-20 09:10 (UTC)

brave browser can't be set as default browser by clicking on set default button.

I made a work around solution for it (I use KDE plasma):

1- create an empty html file (file.html)

2- Right click -> Open with -> Other Application... -> chose brave & tick remember application -> Ok

mixedCase commented on 2019-10-16 15:55 (UTC)

I just noticed I missed your last message arcomus. This package does not build Brave. This just extracts and uses the official binary. Please make sure you're trying to install brave-bin and not some other package and if it's the case please post the makepkg output.

arcomus commented on 2019-10-16 15:52 (UTC)

Thanks for the report. Soon check.

mixedCase commented on 2019-10-16 14:23 (UTC)

Thanks for the report JantarMantar! Fixed.

JantarMantar commented on 2019-10-16 01:11 (UTC) (edited on 2019-10-16 01:14 (UTC) by JantarMantar)

There is a bug in shell script. One can't open a local file that has spaces in its name. To fix this, the last line must have double quotes around $@. That is, it should be:

/usr/lib/brave-bin/brave "$@" $SANDBOX_FLAG $PEPPER_FLASH_FLAG $USER_FLAGS || true

arcomus commented on 2019-10-15 09:08 (UTC)

Hello Brave builder,

I have a question. Yesterday i tried to install brave on a arcolinux i3 xfce system. I stopped the install after 3 < hours. It also put 30 gig of data on my disk.

At the end not installed and it took a long time to delete brave components.

Strange situation for me.

Pepito commented on 2019-10-10 11:01 (UTC)

I just installed the package and it works perfect. Very grateful for your work

spsf64 commented on 2019-09-10 15:10 (UTC)

@mixedcase, ops, sorry... did not see that orange "pre-release" tag

Deleting the comment...

mixedCase commented on 2019-09-10 15:03 (UTC)

@spsf64 That one is marked as prerelease.

mixedCase commented on 2019-09-10 14:43 (UTC)

Noting here in case anybody wonders: Package was just rolled back because a GitHub release was incorrectly marked as stable for some period of time by the Brave team, forcing an epoch increase.

mixedCase commented on 2019-08-11 20:01 (UTC)

@cg505 You are right, I didn't think that one through and in retrospect it should've been obvious, mb. Fixed.

cg505 commented on 2019-08-08 22:54 (UTC) (edited on 2019-08-09 17:43 (UTC) by cg505)

Thank you @mixedCase! As for L21/22, I'm still not entirely sure how it's supposed to work. Doesn't ${pkgname%} just expand to brave-bin, like plain old ${pkgname}? I assumed the intent of these lines was to strip the -bin so that this package conflicts with/provides brave.

mixedCase commented on 2019-08-08 20:39 (UTC)

Thanks for the report @cg505! Can't test actully setting the default browser here but the detection is working with that change.

As for L21 and L22 fixed it because it was technically working but the code was misleading. Great catch.

cg505 commented on 2019-08-08 20:12 (UTC)

@mixedCase Could you rename brave.desktop to brave-browser.desktop? This will resolve the issue where you can't use the button in Brave to set it as the default browser. See for the relevant code.

Also, I may be mistaken but I think on lines 21 and 22 of the PKGBUILD you want ${pkgname%-bin} instead of ${pkgname-bin}.

mixedCase commented on 2019-07-16 16:58 (UTC)

@maximbaz Sure, it has a few things hardcoded and storage relies on Google cloud but the querying mechanism should be straightforward enough:

maximbaz commented on 2019-07-16 10:06 (UTC)

@mixedCase: could you please share your script that checks for availability of a new stable release? I wanted to setup an urlwatch rule, but the query is not very obvious...

digitalone commented on 2019-07-10 12:10 (UTC)

Thank you @maximbaz, very appreciated!

maximbaz commented on 2019-07-10 11:29 (UTC) (edited on 2019-07-10 11:30 (UTC) by maximbaz)

I'm experimenting with Brave and I have pushed PKGBUILD to AUR/brave to compile the browser on our own, it also includes VA-API patch to enable hardware video acceleration just like chromium-vaapi does.

I have the compiled version in my repo as well, if you are interested to play around.

@mixedCase: this package should conflict with brave.

maximbaz commented on 2019-06-24 08:13 (UTC)

After I posted I thought maybe even inline comments can be supported as well, tested with | sed 's/#.*//', seems to work well :)

mixedCase commented on 2019-06-24 08:10 (UTC)

Oof nice catch, I forgot to retest that after some var renames. And great suggestion, included as well. Thanks maximbaz!

maximbaz commented on 2019-06-24 07:56 (UTC) (edited on 2019-06-24 08:09 (UTC) by maximbaz)

Perhaps also support comments in the conf file by replacing $(cat FILE) with $(cat FILE | sed 's/#.*//'), it can be useful.

maximbaz commented on 2019-06-24 07:53 (UTC)

Beautiful work @mixedCase, thanks a lot! You have a typo in BRAVE_USER_FLAGS_FILE, you use USER_FLAGS_FILE variable instead when trying to actually read the file. Otherwise works great!

mixedCase commented on 2019-06-23 23:34 (UTC)

Hey guys, just pushed an update to solve some of Brave's annoyances, thanks to all the users who reported them and sorry for taking so long.

navarroaxel: Didn't have that so I just added it. It will look in $XDG_CONFIG_DATA/brave-flags.conf (or ~/.config/brave-flags.conf) for your custom flags.

Smit_17: From what I can tell it helped the old Brave codebase (Muon) locate Pepper Flash. Now that's gone and replaced with a new hack for enabling it manually when the pepper-flash package is installed.

maximbaz: Thanks for the tip, added it as well.

And finally, please let me know if this broke anything since there are a few ugly changes.

maximbaz commented on 2019-06-23 11:48 (UTC)

FYI if you are struggling with making xdg-open use Brave as default browser, the workaround is to update /usr/bin/brave to always return 0 exit code - I updated it like the following:

#!/usr/bin/env bash

if [[ ! (-r /proc/sys/kernel/unprivileged_userns_clone && $(< /proc/sys/kernel/unprivileged_userns_clone) == 1 && -n $(zcat /proc/config.gz | grep CONFIG_USER_NS=y) ) ]]; then
    >&2 echo "User namespaces are not detected as enabled on your system, brave will run with the sandbox disabled"

/usr/lib/brave-bin/brave "$@" "$FLAG" || true

navarroaxel commented on 2019-06-16 04:52 (UTC)

@aramirez, the ArchWiki says that the base-devel package group is required to install packages from AUR: So is not required add those packages on makedepends.

aramirez commented on 2019-06-15 23:15 (UTC)

Hi. I believe this package requires 'fakeroot' and 'm4' in order to build. They should be added to the makedepends.

Smit_17 commented on 2019-06-08 07:59 (UTC)

Whats the point of line

ln -s /usr/lib/PepperFlash "$pkgdir/usr/lib/pepperflashplugin-nonfree" ??

Its creating false symlink as /usr/lib/pepperflashplugin-nonfree doesn't exists. It also prevents one from installing brave-bin and brave-dev-bin at the same time

JSE commented on 2019-06-08 04:47 (UTC)

@navarroaxel If that flag doesn't work (I've never used it so can't say) (I don't see why you couldn't try, just in your .desktop or from terminal even), you do realise there is an option built directly into Brave's Browser Settings which lets you set it to Dark mode? It's way easier than messing around with flags :)

navarroaxel commented on 2019-06-02 17:51 (UTC) (edited on 2019-06-02 19:16 (UTC) by navarroaxel)

How I can add this flags automatically when I open brave? --enable-features=WebUIDarkMode --force-dark-mode

In the google-chrome AUR package I can edit the ~/.config/chrome-flags.conf to force the dark mode

mixedCase commented on 2019-04-26 15:17 (UTC)

@digitalone Thanks for the heads up, just uploaded the PKGBUILD without the .deb code.

As for Widevine support, Brave manages its own version and thus doesn't need the chromium-widevine package to work.

digitalone commented on 2019-04-26 08:49 (UTC) (edited on 2019-04-26 08:50 (UTC) by digitalone)

Generic Linux zip package has now resources folder included, so we can skip deb package downloading.

Besides, I made a new PKGBUILD with optional chromium-widevine support. Note that you don't have to install chromium to get chromium-widevine.

Installed and tested with a streaming service I use in my country: playback works smoothly (obviously you have to disable brave shield for that specific page). Should also work for Netflix, Amazon Prime and other streaming services.

digitalone commented on 2019-04-09 05:56 (UTC) (edited on 2019-04-09 13:32 (UTC) by digitalone)

I think it's because those files were copied manually before and pacman detects a conflict.

cssanchez commented on 2019-04-09 05:27 (UTC)

The last build failed for me because it didn't remove the old locale files at: /usr/lib/brave-bin/resources/brave_rewards/_locales/ and /usr/lib/brave-bin/resources/brave_extension/_locales/

run sudo rm -rf for each of them.

digitalone commented on 2019-04-08 18:13 (UTC) (edited on 2019-04-08 18:14 (UTC) by digitalone)

Thanks. Anyway, deb package uses Ubuntu directory schema that seems a little bit different from Arch's one. Brave primary folder is in /opt/ rather than /usr/lib/brave-bin. I don't know if this can cause any issue on Arch.

mixedCase commented on 2019-04-08 17:50 (UTC)

Hey guys, sorry I didn't respond earlier just saw the comments today and re-enabled notifications. So:

afontenot: Removed gconf from depends and moved libgnome-keyring to optional dependencies.

digitalone: Thanks for the reminder on pkgrel, I made the change on a machine without my usual pre-commit hook and didn't notice. Regarding the extension bug, I was looking into avoiding a second download of the browser just because of an upstream packaging issue; but since a lot of people use Brave solely for the crypto stuff I'll just merge those changes until I have more time to look into using the deb alone. Thank you for the patchset, just merged.

digitalone commented on 2019-04-08 16:27 (UTC) (edited on 2019-04-08 16:29 (UTC) by digitalone)

When you modify the PKGBUILD, you should also increase pkgrel number otherwise users that already installed the package won't get any change.

And, please, merge my modification reported here to include resources directory from deb release so Brave Shield issue can be fixed until developers will make a fully working linux zip package.

digitalone commented on 2019-04-08 15:24 (UTC) (edited on 2019-04-08 15:25 (UTC) by digitalone)

This PKGBUILD modified by me fixes Brave Shield issue. Please update.

afontenot commented on 2019-04-08 00:23 (UTC)

Following up: I've been running an edited version of this PKGBUILD with libgnome-keyring and gconf removed from depends for a while with no problems under KDE. As I said in a previous comment, they're not required by the Debian brave package. Can you move them to optdepends please?

neontiger26 commented on 2019-03-29 23:59 (UTC)

@vith If you're referring to the Brave Shield and Brave Rewards, use the fix Cpt_Pi brought up in a prior comment that states,

"The no text in Shield and missing translation in Rewards are due to how Brave have been packaging the .tar.gz.

To fix the "No text in Shield and no translation in Rewards" - you have to download the .deb and extract the Resources directory into /usr/lib/brave-bin"

vith commented on 2019-03-29 21:27 (UTC)

There seems to be some problem with some (localized?) strings in Brave's customizations. Their added icons in the right side of the address bar have missing and/or placeholder text in their popups.

afontenot commented on 2019-03-29 06:35 (UTC)

@mixedCase: Several issues / questions.

  1. Can you add yourself as the maintainer to the PKGBUILD? Currently now-im is listed as the maintainer.

  2. I haven't flagged it, since you say you have a script, but is this not a more recent release from 8 days ago? (I'll flag to get your attention if you don't respond within a day or two.)

  3. Can you please check to see whether moving libgnome-keyring and gconf to optdepends (or removing them entirely) is possible. The official debian package of the most recent release does not have these listed as dependencies. In particular removing the latter would eliminate the dependency on Python 2, which I do not have installed.


mixedCase commented on 2019-03-11 13:52 (UTC) (edited on 2020-09-01 20:39 (UTC) by mixedCase)


Before making your report, please note that the newer GitHub release you're looking at belongs to the "Release Channel" and --isn't marked as prerelease--.

I have a cron running that's checking every 30 minutes if there's a new release and sends me an email if so. If you see the release was tagged in the last couple of hours please give it some time before flagging.

Also please take into account a stable version may be "released" on GitHub but not marked as ready (read, NOT PRELEASE) for a long time.

Another handy tool to check latest OFFICIALLY MARKED AS STABLE version of Brave is to run:


Cpt_Pi commented on 2019-03-11 12:26 (UTC)

@miomio, this is fixed with PR-3446 which should be in a release soon.

neontiger26 commented on 2019-03-10 19:15 (UTC)

@miomio No, one should have too. Unfortunately, that's the reality of not having an official Arch build and having to rely on a user repository to use a preferred piece of software.

If the Brave team could include the resource directory in the official zip file, then it's my understanding that you wouldn't have to go through this extra step. The best thing to do would be to let Brave developers know of this problem so it can be included in future releases.

miomio commented on 2019-03-10 19:03 (UTC)

@neontiger26 - should anybody really be having to do this.

neontiger26 commented on 2019-03-09 23:51 (UTC)

@miomio I downloaded it from Brave's GitHub account.

miomio commented on 2019-03-09 16:00 (UTC) (edited on 2019-03-09 16:01 (UTC) by miomio)

@Cpt_Pi / @neontiger26 - where is the deb package?

neontiger26 commented on 2019-03-06 01:20 (UTC)

Just wanted to confirm that the latest update by mixedCase installed properly.

I also wanted to confirm that the fix Cpt_Pi mentioned to get text in the Brave shield works.

mixedCase commented on 2019-03-05 14:07 (UTC)

Hi now-im, if you're having trouble fixing the build I'm willing to take maintainership of this package since I depend on it. Thanks.

kseistrup commented on 2019-03-05 12:28 (UTC)

The PKGBUILD file doesn't work in its current incarnation:

==> Removing existing $srcdir/ directory...
==> Extracting sources...
==> Starting prepare()...
chmod: cannot access 'brave/brave': No such file or directory
==> ERROR: A failure occurred in prepare().
Error making: brave-bin

neontiger26 commented on 2019-03-05 10:17 (UTC)

I'm getting this error when trying to install the latest update

chmod: cannot access 'brave/brave': No such file or directory ==> ERROR: A failure occurred in prepare(). Aborting...

Cpt_Pi commented on 2019-03-04 07:45 (UTC) (edited on 2019-03-04 07:46 (UTC) by Cpt_Pi)

@miomio - these are issues with Brave.
The no text in Shield and missing translation in Rewards are due to how Brave have been packaging the .tar.gz.
The widevine support is due to Brave currently not supporting Widevine on Linux.

To fix the "No text in Shield and no translation in Rewards" - you have to download the .deb and extract the Resources directory into /usr/lib/brave-bin

miomio commented on 2019-02-28 20:39 (UTC)

The issues I commented about on the 4th are still present: text in the shield missing, and no widevine.

miomio commented on 2019-02-04 02:20 (UTC) (edited on 2019-02-09 23:29 (UTC) by miomio)

UI bug as described here: & .

Widevine support issue:

zerophase commented on 2019-02-02 19:24 (UTC)

Anyone else having issues with Brave refusing to load web pages, while all other browsers and web services work fine?

simonorono commented on 2019-01-24 14:07 (UTC)

@Martian According to a Brave employee, this will be fixed soon.

Martian commented on 2019-01-24 10:09 (UTC)

Please have a look at this in regards to the UI bug:

The bug itself :

cg505 commented on 2018-12-28 21:55 (UTC)

Note that sh might not be bash. I use dash, and so will not work. You could just change the shebang to #!/usr/bin/env bash.

zerophase commented on 2018-12-27 07:11 (UTC)

gnome-keyring is required for the password saving feature to work.

I also noticed password generation is not working. Is there a package that's needed to bring that feature over from Chrome to Chromium based browsers?

jamesmurray commented on 2018-12-10 09:43 (UTC)

It shows that it is not set to the default browser, even when it actually is.

joschi127 commented on 2018-12-01 18:23 (UTC) (edited on 2018-12-01 18:25 (UTC) by joschi127)

To fix default browser under chrome and to avoid showing the icon two times in the gnome dock, you can create a file ~/.local/share/applications/brave-browser.desktop with the following content:

(the most important line here is the StartupWMClass=brave-browser pointing to the correct window manager class name)

[Desktop Entry]
Name=Brave Browser
# Only KDE 4 seems to use GenericName, so we reuse the KDE strings.
# From Ubuntu's language-pack-kde-XX-base packages, version 9.04-20090413.
GenericName=Web Browser
# Not translated in KDE, from Epiphany 2.26.1-0ubuntu1.
# Gnome and KDE 3 uses Comment.
Comment=Access the Internet
Exec=/usr/bin/brave %U
Name[de_DE]=Brave Browser

[Desktop Action new-window]
Name=New Window
Name[de]=Neues Fenster

[Desktop Action new-private-window]
Name=New Incognito Window
Name[de]=Neues Inkognito-Fenster
Exec=/usr/bin/brave --incognito

And as suggested by @whezzel update ~/.config/mimeapps.list to use brave-browser.desktop for all browser related entries.

rEnr3n commented on 2018-11-29 02:07 (UTC)

@dencrypt Regarding brave shield settings:

dencrypt commented on 2018-11-28 14:02 (UTC) (edited on 2018-11-29 15:20 (UTC) by dencrypt)

As @asynec I also have the problem with browser always telling me to set default browser. Tried the Suggestions from @whezzel but no avail unfortunately.

<s>Also the Brave Shield settings (in the address bar) has a UI that lacks any icons or text. It's just the sliders and the name of the page. Hard to set anything when I don't know what it is :) However great work anyway. These are just small complaints tbh and it works otherwise fine!</s>
This is an upstream bug.

whezzel commented on 2018-11-24 08:44 (UTC)

I use Cinnamon DE and had similar issues. I was able to fix it by editing ~/.config/mimeapps.list and changing all occurrences of chromium.desktop (my previous browser) to brave-bin.desktop, and deleting all the BraveBrowser data stored in ~/.cache and ~/.config.

I'm not sure why, but brave bugged me, for several days, about setting it to default, but a friend of mine said he only clicked 'Set as Default' once and it stopped asking him.

async commented on 2018-11-24 00:48 (UTC)

Any idea why this package always complains that it is not set to the default browser, even when it actually is? Using Gnome, fwiw.

whezzel commented on 2018-11-23 23:58 (UTC)

@simonorono Awesome. Thanks for such a quick fix

simonorono commented on 2018-11-23 16:57 (UTC)

I just solved that issue on version 0.56.15 @whezzel

whezzel commented on 2018-11-23 12:14 (UTC)

I understand the reason for the script, is to notify the user that the browser is not running in a sandbox which can be insecure. I have applied the fix listed in the 'pinned' comment so that my browser runs in a sandbox.

My question is, would it be possible to modify to pass additional flags to /usr/lib/brave-bin/brave?

For example:

brave --incognito     # opens a new brave window with a url of --incognito
/usr/lib/brave-bin/brave --incognito     # opens a new window in incognito mode.

Unfortunately, I'm not that great with scripting yet, otherwise I would try to make this modification on my own.

simonorono commented on 2018-11-17 19:41 (UTC) (edited on 2018-11-17 19:42 (UTC) by simonorono)

@Vrakfall the main Brave executable gets installed at /usr/lib/brave-bin/brave and will not run unless:

1) it finds a way of sandboxing the processes or 2) it's run with the --no-sandbox flag (very insecure)

The checks if you have user namespaces enabled; if not then it will run Brave with the --no-sandbox flag.

This is a known issue:

If you try to run the main Brave executable with no flags you get this:

[23868:23868:1117/] No usable sandbox! Update your kernel or see <> for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
Trace/breakpoint trap (core dumped)

Vrakfall commented on 2018-11-17 14:34 (UTC)

I can't find which command this flag is from. What is it linked to? I find it weird you advice using a kernel feature that weakens it.

async commented on 2018-11-16 05:56 (UTC)

Looks like there is an error in the desktop file... in Gnome, the desktop file opens a duplicate icon in the dock when added to favorites.

simonorono commented on 2018-11-15 03:35 (UTC) (edited on 2018-11-15 03:35 (UTC) by simonorono)

To disable the message telling "that you're using an unsupported command-line flag --no-sandbox" you must enable user namespaces with sysctl:

sudo sysctl kernel.unprivileged_userns_clone=1

To make it persist after reboot:

echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf

alerque commented on 2018-11-14 16:18 (UTC)

Sorry I've been traveling and out of date on upstream changes. I'll take a look at this over the coming week.

If anybody can confirm @mariow's comments below and that Gist building I might expedite putting that in here.

mariow commented on 2018-11-10 20:35 (UTC)

This PKGBUILD works to update brave-bin to the currently latest 0.56.12 for me: For full disclosure: that version either isn't as stable as one would like or there are open issues with dependencies, some UI elements look a bit unfinished.

ronaldscott commented on 2018-11-01 20:25 (UTC)

@veox The old Muon-based Brave browser in the browser-laptop repo that this package sources is no longer considered the mainline Brave browser product and I don't think it qualifies for the 'stable' label. They've created a new Chromium-based browser, available at the brave-browser repo. See for more info.


The Muon-based Brave browser is no longer available for download on our site, but users who currently browse with it (latest version is 0.25.2) will continue to receive necessary updates until they are fully upgraded to this new release in the near future.

veox commented on 2018-11-01 20:16 (UTC)

Merely bumping pkgver to 0.25.2 (as well as updating the hash-sums) should be enough for those still wishing to use the "stable" channel.

No need to switch to the beta repo.

tve commented on 2018-11-01 04:15 (UTC)

Thanks for the tip, ronaldscott!

ronaldscott commented on 2018-10-31 17:22 (UTC) is already updated to point at the brave-browser repo. I got the latest version by using that PKGBUILD and bumping the pkgver to 0.55.20.

That PKGBUILD could easily be adapted to work for this package.

tve commented on 2018-10-31 16:25 (UTC)

As mentioned by others, this needs to be updated to the brave-browser repo. However, looking at it, the install is completely different, so it's a good amount of work...

async commented on 2018-10-28 02:09 (UTC)

Can we please get an update to the new source, per tuckerboniface ? This package has been out of date for a long time.

tuckerboniface commented on 2018-10-21 02:16 (UTC)

Please use the new location

alerque commented on 2018-09-24 22:31 (UTC)

@Kabir Please ask that on a Brave related forum, or check the issue tracker. This is only the comment section for the AUR package, and we just wrap up what the upstream project produces in a way that can be easily installed on Archlinux. Your question is about the upstream project, not this package.

Kabir commented on 2018-09-12 22:26 (UTC)

Has the feature to edit browser / website fonts and themes been implemented yet? Thanks!

mischka commented on 2018-09-02 04:18 (UTC)

@caleb Awesome, great work. Wish I'd added you weeks ago, sorry again!

jeancf commented on 2018-09-01 08:25 (UTC)

(1/2) Arming ConditionNeedsUpdate... (2/2) Updating the desktop file MIME type cache... fatal: repository '' not found

alerque commented on 2018-09-01 07:12 (UTC)

Thanks @mischka. I'll work on these two first and then maybe approach the -git package owner about normalizing these three again.

I did a whole bunch of cleanup to the packaging, mostly to closer match current AUR packaging guidelines, but also to simply the scripting, make it easier to track changes to the files being injected by this package separate from the PKGBUILD, and generally clean things up. You might have a look at the git log to see what I did. Notably only the change to the wrapper script (moving the warning message from build()) bumped the pkgver, everything else in the installed should end up being identical, it just gets there in a safer way.

mischka commented on 2018-08-31 12:23 (UTC)

@caleb Great thanks! Except I forgot that I already orphaned the -git one a while ago for similar reasons so I can no longer add you to that one, ha. Thanks again!

alerque commented on 2018-08-31 07:18 (UTC)

@mischka Sure you can add me on those too.

mischka commented on 2018-08-30 12:14 (UTC)

Oh great apologies, I really wish I saw your offer to be co-maintainer earlier. I'd been on vacation and sort of unplugged for a while, apologies, and I don't use Brave myself any longer so I don't really prioritize updates. Sorry about that.

Thanks for offering, I've added you as a co-maintainer! Would you be willing to do the same for the other two brave packages?

alerque commented on 2018-08-13 13:12 (UTC) (edited on 2018-08-17 16:11 (UTC) by alerque)

Can we maybe get some co-maintainers on this package? The upstream project moves very fast and releases frequently and it seems there is frequently a week or two lag in this package. With very little changing between most releases, maybe with a few more people with push access we can keep it more up to date.

Edit: 2018-08-13 — I'm willing to help update as a co-maintainer if you add me.

farfa123 commented on 2018-08-06 16:26 (UTC)

Please do me a favour and do not ever use Brave.

It is a browser specifically designed to allow fingerprinting for advertisers and I am not even kidding. Go compare how much entropy stock Brave provides compared to stock Firefox.

Landslide_2020 commented on 2018-08-01 23:57 (UTC)

Nothing destructive about it. It's a wiki, after all. Duh. Stop whining about the inevitable and update the build more often.

shillshocked commented on 2018-07-16 06:02 (UTC)

This build has a backdoor, I believe.

mischka commented on 2018-07-09 12:17 (UTC)

Git gave me some weird errors when I committed this last time, it seems to have gone through alright but if anyone experiences issues please post a comment.

9grPPT3yBewMM635 commented on 2018-04-30 18:59 (UTC)

Permissions for this packages are now 700. Which means you cannot run the browser if you're not root. Am I missing something here?

mischka commented on 2018-04-29 22:05 (UTC)

This is not the place to advertise destructive alt-right websites.

shillshocked commented on 2018-04-29 14:52 (UTC) (edited on 2018-04-29 14:53 (UTC) by shillshocked)

Thanks for the tip, Xeno_Idaltu. I'll make sure to install the latest version of this browser now. Great search engine, an unbiased, censorship-free, untrolled equivalent of Wikipedia!

Xeno_Idaltu commented on 2017-12-20 10:29 (UTC)

It came with "infogalactic" as a preinstalled search engine.

If this Alt-Right idiocy keeps going on people in the year 2100 will actually believe dinosaurs lived along Jesus and that White Supremacists were riding Sauropods to work.


FabioLolix commented on 2017-11-03 22:41 (UTC)

With the last update of the licenses package MPL2 is now included (also Boost)

mischka commented on 2017-10-07 16:36 (UTC) (edited on 2017-10-07 16:38 (UTC) by mischka)

This package is not out of date, the latest non-beta release is v0.18.36. Please feel free to fork this PKGBUILD and create a beta channel package if you wish.

CurtisLeeBolin commented on 2017-09-27 14:06 (UTC)

My instructions were to minimize the time needed for you or anyone else wanting to test it. I made the namespaces change on another computer for a quick test. 0.18.36-3 ran before and after the namespace change. Before: $ cat /proc/753/cmdline /usr/lib/brave-bin/brave --no-sandbox -- After: $ cat /proc/5155/cmdline /usr/lib/brave-bin/brave -- It seems to be working well. Thank you.

mischka commented on 2017-09-26 21:54 (UTC)

I mainly meant to test the check I added to the launcher. It's been updated now, please install the new version and let me know if it doesn't work out of the box. Thanks!

CurtisLeeBolin commented on 2017-09-26 21:40 (UTC)

In case you want to test it quickly: For CONFIG_USER_NS=y : I just installed linux-hardened, regenerated my grub.cfg, and rebooted with the linux-hardened kernel. For kernel.unprivileged_userns_clone=1 : I just ran the following after booting the new kernel. # sysctl -w kernel.unprivileged_userns_clone=1 Then I edited /usr/bin/brave to run brave without --no-sandbox: - exec /usr/lib/brave-bin/brave --no-sandbox -- "$@" + exec /usr/lib/brave-bin/brave -- "$@"

mischka commented on 2017-09-26 14:48 (UTC)

Interesting, thanks for pointing that out. I don't have them enabled and admittedly I don't have time at the moment to spin up a VM to test them, but let me know if you still run into issues. Arch's decision to not enable user namespaces by default make me wary to try to persuade people to enable it, so the message about it if it's disabled is relatively benign. Also, build doesn't really feel like the right place to do that check and echo that warning message, but I'm not aware of a better one (except maybe an .install script, but if it's all the same I'd like to avoid that).

CurtisLeeBolin commented on 2017-09-26 13:27 (UTC) Can you please correct the launcher to only run with --no-sandbox if CONFIG_USER_NS=y and kernel.unprivileged_userns_clone=1 are not set?

fireglow commented on 2017-09-07 15:32 (UTC)

Thanks for the quick fix :)

mischka commented on 2017-09-07 15:13 (UTC)

Sorry about that. I forgot that updpkgsums doesn't download a source by default if it already exists in the current directory.

fireglow commented on 2017-09-07 14:39 (UTC)

MPL2 checksum is off again.

mischka commented on 2017-08-21 09:47 (UTC) (edited on 2017-08-21 09:48 (UTC) by mischka)

Sorry about that, I'm in a hotel with flaky wifi and looks like there was some network problems downloading it the first time, not sure. If it's a problem again I'll consider SKIPing the license, thanks.

viq commented on 2017-08-21 08:04 (UTC)

Like FabioLolix, I'm getting a different checksum for MPL2, b8823586fead21247c8208bd842fb5cd32d4cb3ca2a02339ce2baf2c9cb938dfcb8eb7b24c95225ae625cd0ee59fbbd8293393f3ed1a4b45d13ba3f9f62a791f

FabioLolix commented on 2017-08-21 07:28 (UTC)

The license file have an outdated checksum, maybe use 'SKIP' for the license?

mischka commented on 2017-08-11 21:57 (UTC)

Ah, apologies. The primary maintainer to this point seems to have abandoned and I didn't realize. Thanks for flagging.

Chiruno commented on 2017-08-11 21:36 (UTC)

This package seems to be outdated.

toropisco commented on 2017-07-17 12:36 (UTC)

No pre-releases. Unless you want a three-time a week update deluge that adds more bugs than fixes.

toropisco commented on 2017-07-17 12:31 (UTC)

@5chdn, it is just you. Clean up your directory. If the newly downloaded MPL2 file doesn't pass checksum check, it is a real bug and worth reporting.

5chdn commented on 2017-07-17 06:18 (UTC)

I keep getting this for several weeks now. Is it just me? ==> Making package: brave-bin 0.17.16-1 (Mon Jul 17 08:17:13 CEST 2017) ==> Retrieving sources... -> Found brave-bin-0.17.16.tar.bz2 -> Found MPL2 ==> Validating source files with sha512sums... brave-bin-0.17.16.tar.bz2 ... Passed MPL2 ... FAILED ==> ERROR: One or more files did not pass the validity check!

toropisco commented on 2017-06-05 14:34 (UTC)

Utterly broken and it can't be helped. It is a perfect storm of upstream changing library requirements to versions incompatible with npm 4.6.x. Thus, we need newer tools in Arch (will require a staging transition I think) and upstream to straighten out its act. Patience. As you should be aware, brave is a browser in development and code quality is poor, not even alpha at some release milestones. That is, when it breaks you get to keep the pieces. Being brutally honest, if you are depending on it for something more than playing around at this stage, you are in trouble. In the meantime, I'll fake the version to push the last working version.

toropisco commented on 2017-05-30 12:37 (UTC)

Use brave or brave-git (I package this binary but that's what I use).

arjan5 commented on 2017-05-30 07:05 (UTC)

Current version (0.16.0-1) is broken upstream. For details see upstream ticket:

sredna commented on 2017-05-04 19:09 (UTC)

Optional dependency: gnome-keyring, for support to built-in password manager

corvinusz commented on 2017-03-30 23:47 (UTC) (edited on 2017-03-30 23:59 (UTC) by corvinusz)

/* --- cut --- */ ==> Starting package()... mv: cannot stat 'brave-bin/pkg/brave-bin/usr/lib/brave/LICENSE': No such file or directory mv: cannot stat 'brave-bin/pkg/brave-bin/usr/lib/brave/LICENSES.chromium.html': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... /* solution */ @@ -160,7 +160,7 @@ - mv "$pkgdir"/usr/lib/brave/{LICENSE,LICENSES.chromium.html} "$pkgdir/usr/share/licenses/$pkgname/" + mv "$pkgdir"/usr/lib/brave-bin/{LICENSE,LICENSES.chromium.html} "$pkgdir/usr/share/licenses/$pkgname/"

ConorIA commented on 2017-02-21 23:27 (UTC)

Please add ' -- ' before "$@" in /bin/brave. This fixes the "can't open a URL directly" issue. See here:

toropisco commented on 2017-02-16 16:11 (UTC)

Nobabs27, never run makepkg as root, never try to run it in a directory you don't have permissions to write on. Use cower and your mind instead of yaourt.

Nobabs27 commented on 2017-02-16 03:01 (UTC)

Does not work? ==> Extracting sources... -> Extracting brave-bin-0.13.2.tar.bz2 with bsdtar ./Brave-linux-x64/brave: Write failed ./Brave-linux-x64/ Write failed ./Brave-linux-x64/version: Write failed bsdtar: Error exit delayed from previous errors.

zerophase commented on 2017-02-01 00:04 (UTC)

The brave file fails the validity check.

arjan5 commented on 2017-01-31 11:47 (UTC)

With the newest version (0.13.0-1) of this package, it is no longer possible to open a url with a command. For instance: brave '' used to work, but now just opens or puts focus on Brave.

z751 commented on 2016-12-18 17:52 (UTC)

@buttcake The package must have at least 100 votes first.

buttcake commented on 2016-10-31 12:18 (UTC)

Any chance this is going to land in the repos soon ? min's already there.

dmp1ce commented on 2016-10-24 05:07 (UTC)

I don't know what 'Delete directory *completely*' means. I'm getting: $ pacaur -S brave-bin :: Package(s) brave-bin not found in repositories, trying AUR... :: resolving dependencies... :: looking for inter-conflicts... AUR Packages (1) brave-bin-0.12.5-2 :: Proceed with installation? [Y/n] Y :: Retrieving package(s)... :: brave-bin build files are up-to-date -- skipping :: Checking brave-bin integrity... ==> Making package: brave-bin 0.12.5-2 (Mon Oct 24 01:04:29 EDT 2016) ==> Retrieving sources... -> Found brave-bin-0.12.5.tar.bz2 -> Found brave.png -> Found MPL2 -> Found brave.desktop ==> Validating source files with sha512sums... brave-bin-0.12.5.tar.bz2 ... Passed brave.png ... FAILED MPL2 ... Passed brave.desktop ... Passed ==> ERROR: One or more files did not pass the validity check! :: failed to verify brave-bin integrity

toropisco commented on 2016-10-21 14:55 (UTC)

jnzik. Delete directory *completely* and download again.

jozik commented on 2016-10-20 17:19 (UTC)

==> Validating source files with sha512sums... brave-bin-0.12.5.tar.bz2 ... Passed brave.png ... FAILED MPL2 ... Passed brave.desktop ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build brave-bin.

caevaroy commented on 2016-09-11 19:35 (UTC)

Error: cannot open shared object file: No such file or directory

utzig commented on 2016-09-06 16:20 (UTC)

This package also needs `gconf` as dependency.

aurelieng commented on 2016-05-21 04:04 (UTC)

@vorbote Thanks, I deleted my profile, and it now works again :)

toropisco commented on 2016-05-20 21:06 (UTC)

@aurelieng try deleting the browser profile ($HOME/.config/brave). It works for me, but I know version 0.9.4 had profile corruption problems.

aurelieng commented on 2016-05-20 06:38 (UTC)

Since a few days, Brave starts with a blank window with the following content instead of its UI: document.getElementsByTagName('head')[0].appendChild(baseNode) const createScript = function (scriptPath) { return new Promise(function (resolve, reject) { var script = document.createElement('script') script.type = 'text/javascript' script.src = scriptPath script.async = true script.onload = resolve script.onerror = reject document.body.appendChild(script) }) } document.querySelector('#webpackLoading').style.display = 'block' createScript(appEntry).catch(function () { document.querySelector('#webpackLoading').style.display = 'none' document.querySelector('#setupError').style.display = 'block' }) Any idea what could be wrong?

toropisco commented on 2016-04-21 19:43 (UTC) (edited on 2017-02-17 15:12 (UTC) by toropisco)

Official releases only. NO RC candidates here! Feel free to report a formal release but do not report a "PRE (DO NOT DOWNLOAD UNLESS YOU ARE TESTING THIS RELEASE CANDIDATE)" if I've missed it somehow. Very unlikely, as I receive the notifications in almost realtime. Do consider that if I don't update when you want is because I have a life and also need to sleep, in my timezone, not yours.

ondoho commented on 2016-04-05 06:34 (UTC)

the line ln -s /usr/lib/brave-browser/Brave "$pkgdir"/usr/bin/brave in PKBUILD should read ln -s /usr/lib/brave-browser/brave "$pkgdir"/usr/bin/brave it's a small, but elusive error. caused me much confusion (bave: command not found).

kozaki commented on 2016-03-31 12:26 (UTC)

Latest release builds fine. Whether me commenting out 'SRCPKGDEST=' in this system makepkg.conf or the '$srcdir/brave.png' new syntax in the PKGBUILD most probably allowing for that. Be sure I'd review my BUILD environement thoroughly if any other PKGBUILD failed to build, which isn't the case atm (60 packages in two architectures).

toropisco commented on 2016-03-25 01:02 (UTC)

@shuu, I must apologize. Earlier today I was very short on time when I read your email (already leaving for church) and did a very cursory check. Somehow I forgot to update the checksums array. That is fixed now.

toropisco commented on 2016-03-24 22:18 (UTC)

@shuu, that's the correct sha384 checksum against my local git repo, synced with AUR. Try downloading again the pkgbuild files and copying over the upstream binary (no need to waste bandwith if you already have the upstream bundle). And sorry all for the short list revision dance. fd.o bit me hard this time.

shuu commented on 2016-03-24 19:09 (UTC)

I got '43d5244a193bb093972c070fbc8f79cc59a3b46a034cb028edd2f645437633fd91226c6c36b713d1f387fbc377714f9d' for the sum on brave.desktop. Is this a problem with my package or a mistake?

toropisco commented on 2016-03-14 16:12 (UTC) (edited on 2016-03-14 16:18 (UTC) by toropisco)

@kozaki I do not take it personally but your insistence is obsesive compulsive. I only stated the facts. "Loosing time", by the way? Read <>. Your claims about a defective PKGBUILD are simply not true. I concede I noticed a couple of stylistic inconsistencies last night and they will be in the next package. But none of those fixes will make an impact in your problem, which apparently is far greater than you suppose. I would presume your system is borked, back up everything, wipe the disk and start over. As there is a new release, I'll upload it later when I have the time, the new version works great, btw. I've already taken measures to minimized the impact of sysem libraries on the binary package. Cheers, V.

kozaki commented on 2016-03-14 12:08 (UTC)

@vorbote, I reported trying to be usefull; no need to make it personal. My "limited command of the English language" as you wrote doesn't impede me to confirm the PKGBUILD I have to correct the path to 'app.png' or it fails is this package's that can be found here: <> (tried to make it clear by quoting it on 2016-03-11 20:30 btw). I'm glad it builds elsewehre without changing the path; no big deal. I'm interested understanding where this PKGBUILD issue comes from, != "loosing time" IMHO.

toropisco commented on 2016-03-12 22:53 (UTC)

@soimort Yes, that is correct. Apparently they are building binaries in Ubuntu with outdated nodejs, npm and, worse, g++/libstdc++ versions. As Arch uses, in general, the latest upstream releases there are unavoidable compatibility problems. Building from source does not help either due to the same ABI differences between the upstream electron and Arch's g++. One of he joys of C++ libraries.

soimort commented on 2016-03-12 22:47 (UTC)

It's certainly an upstream issue though, the binary release throws a lot of segfaults on my Arch machine (freetype2 2.6.3-1). [431811.937668] Brave[1039]: segfault at 7fff964542d0 ip 00007fcb4209ee67 sp 00007fff96451710 error 6 in[7fcb4203a000+b9000] [431903.283281] Brave[1275]: segfault at 7ffda34dfd08 ip 0000000000b66b5a sp 00007ffda34dfd10 error 6 in Brave[400000+369e000] [431993.854196] Brave[1398]: segfault at 7ffdf9403fb8 ip 00007fdaede9a7cd sp 00007ffdf9403f80 error 6 in[7fdaede38000+b9000] [432243.487119] Brave[1824]: segfault at 7fff8023a708 ip 00007fe051eed7cd sp 00007fff8023a6d0 error 6 in[7fe051e8b000+b9000] [432253.123910] Brave[1895]: segfault at 7ffd8f9457c8 ip 00007fe96acdf7cd sp 00007ffd8f945790 error 6 in[7fe96ac7d000+b9000]

toropisco commented on 2016-03-12 19:20 (UTC)

@kozaki, I can understand that your command of the English language be limited, as it is apparently the case; I'm not a native speaker myself. Please stop wasting my time and yours. You have spent three weeks reporting a bug that doesn't exit in this package. As I wrote on 2016-03-11 20:07 UTC, if you are trying to report a bug with the git version, please do so in the appropirate place. The fact that I maintain both packages is irrelevant. Thank you.

kozaki commented on 2016-03-11 20:30 (UTC)

Edited my last post with correct paths. Yes I think so: PKGBUILD: # Maintainer: Please see AUR package page for current maintainer(s) and contact information. pkgname=brave-browser-bin pkgver=0.8.0 pkgrel=1 ... install -D -m0644 "$startdir"/app.png "$pkgdir"/usr/share/pixmaps/brave-browser-bin.png Path to app.png : (/makepkg/brave-browser-bin)─ (6 files, 44Kb)─> [1][0]$ find . -name app.png ./src/app.png

toropisco commented on 2016-03-11 20:07 (UTC) (edited on 2016-03-11 21:04 (UTC) by toropisco)

@kozaki Are you sure you are reporting the bug to the correct package? The PKGBUILD for this particular package is correct and works as intended. If you have problems with the *git* package report your problems there, but for your information, it works *fine*. It may be unbuildable at the moment but that is out of our hands as far as we know. I always build the three brave packages presently in AUR, using clean chroots created with devtools both in EXT4 and BTRFS. I encourage you to do the same before reporting back.

kozaki commented on 2016-03-11 19:31 (UTC) (edited on 2016-03-11 20:21 (UTC) by kozaki)

Excuse the delay to answer. It isn't double quotes or else but app.png standing in: $startdir"/src/app.png not in: $startdir"/app.png in your PKGBUILD. fs = ext4.

toropisco commented on 2016-03-03 15:17 (UTC)

I don't either.

mischka commented on 2016-03-03 15:04 (UTC)

Brave works fine for me, I'm not sure what you guys are talking about

toropisco commented on 2016-03-03 11:28 (UTC)

@kozaki And the full path? Not that it should matter, $srcdir is double-quoted for a reason.

toropisco commented on 2016-03-03 11:24 (UTC)

@kozaki that makes no difference. What filesystem are you using?

kozaki commented on 2016-03-03 10:00 (UTC)

In vorbote PKGBUILD line 33: (-) install -D -m0644 "$startdir"/app.png "$pkgdir"/usr/share/pixmaps/brave-browser-bin.png (+) install -D -m0644 "$startdir"/src/app.png "$pkgdir"/usr/share/pixmaps/brave-browser-bin.png Allows me to build brave-browser-bin. @vorbote yeap, Brave since v0.15 isn't usable but it was before.

toropisco commented on 2016-02-25 23:58 (UTC)

@kozaki that's a weird one! I just cleaned up my build dir, redownloaded everything and I got an installable package without errors. (Now, if only brave worked! It's nice in my tablet. Soon, I hope.)

kozaki commented on 2016-02-25 23:32 (UTC)

Nice news! Though there's something missing here: builds/brave-browser-bin $ makepkg -sr ... ==> Retrieving sources... -> Found brave-browser-bin-0.7.16.tar.bz2 -> Found app.png ==> Validating source files with md5sums... brave-browser-bin-0.7.16.tar.bz2 ... Passed app.png ... Passed ==> Extracting sources... -> Extracting brave-browser-bin-0.7.16.tar.bz2 with bsdtar ==> Removing existing $pkgdir/ directory... ==> Entering fakeroot environment... ==> Starting package()... install: cannot stat '/data/system/builds/brave-browser-bin/app.png': No such file or directory ==> ERROR: A failure occurred in package(). Aborting...