Arch Linux User Repository

@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.

There is an issue with version 1.43.88 if using Wayland where the menu is displayed on the top left corner. This is an upstream Chromium issue that can be followed here: https://bugs.chromium.org/p/chromium/issues/detail?id=1358794&q=wayland&can=2

@Adramyttium It's something related to your AUR helper / Connection- I can download from that URL just fine.

I'm getting this error:

curl: (22) The requested URL returned error: 416 ==> ERROR: Failure while downloading https://github.com/brave/brave-browser/releases/download/v1.41.99/brave-browser-1.41.99-linux-amd64.zip Aborting... Failed to build brave-bin

Hi, receiving an error while updating:

brave-archlinux.db failed to download error: failed retrieving file 'brave-archlinux.db' from mirror.lnx.im : SSL certificate problem: certificate has expired

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

@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

See: https://github.com/Manjaro-Sway/desktop-settings/tree/sway/community/sway/etc/skel/.config

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: https://gitlab.manjaro.org/packages/community/brave - 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.

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.

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.

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 https://mywiki.wooledge.org/BashGuide/SpecialCharacters

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.

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:

https://www.chromium.org/developers/how-tos/run-chromium-with-flags/

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