Arch Linux User Repository

If somebody wants to try my prebuilt package can add this repo:

[brave-archlinux]
Server = https://mirror.lnx.im/archlinux/brave
SigLevel = Never

Compilation is using ccm64 and default makepkg.conf, only tuned the PACKAGER and MAKEFLAGS="-j5".

I'm experimenting with Brave, this PKGBUILD also adds hardware video acceleration support via VA-API (you need to pass --ignore-gpu-blacklist if you want to enable hardware video acceleration using VA-API).

Thanks again mk-fg

COMPONENT variable added in last release.

In next will push your launcher code:

[[
  ( -r $(echo /proc/config.*)
    && -z $(bsdcat /proc/config.* | grep CONFIG_USER_NS=y) )
  || ( -r /proc/sys/kernel/unprivileged_userns_clone
    && $(< /proc/sys/kernel/unprivileged_userns_clone) != 1 )
]] && SANDBOX_FLAG="--no-sandbox" && echo "User namespaces are not detected as enabled on your system, Brave will run with the sandbox disabled"

Indeed Arch default kernel has that patch.

One problem I found after install is that Brave refuses to enable user namespace sandboxing mode, ... will need to look into it separately.

This seem to be a simple bug in brave-launcher script bundled here, this bit specifically:

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"
    SANDBOX_FLAG="--no-sandbox"
fi

There is no "/proc/sys/kernel/unprivileged_userns_clone" in regular linux kernels (from kernel.org), as this is added by a debian patch which was explicitly rejected upstream. (see https://lwn.net/Articles/673597/ )

Not sure if Arch kernel also includes this patch (check suggests that it likely does), but I think check should be more along these lines:

[[ 
  ( -r $(echo /proc/config.*)
    && -z $(bsdcat /proc/config.* | grep CONFIG_USER_NS=y) )
  || ( -r /proc/sys/kernel/unprivileged_userns_clone
    && $(< /proc/sys/kernel/unprivileged_userns_clone) != 1 )
]] && SANDBOX_FLAG="--no-sandbox"

Reasoning:

• Always default to enabling sandboxing to err on the secure side, even if it would crash the browser.

• /proc/config.* might be missing entirely (module not loaded, disabled, etc).

• bsdcat (part of libarchive pacman dependency) - because in modern kernels config can be compressed as .xz/.zst and such, not just .gz.

• If unprivileged_userns_clone sysctl is missing (e.g. with regular vanilla linux), it is enabled as per that kernel option.

EDIT: added "-r $(echo /proc/config.*)" to check above.

Can confirm that component build finishes faster - something like 10 hours here, which is at least 4x faster (or maybe more) than release build.

But I think you were right in your earlier statement that it seem to be debug build not intended for regular users (though looking at both chromium and brave wikis, couldn't find it to be stated explicitly there), as after building it with just "npm run build --official_build=false", .so files in out/Component (should be copied to /usr/lib/brave) didn't get stripped by build system and had debug symbols in them.

Didn't notice anything slower about resulting browser in general, comparing to statically-linked chromium here, but didn't look too hard either, and it's also possible that these two shouldn't be comparable.

One problem I found after install is that Brave refuses to enable user namespace sandboxing mode, but that seem to be common issue that's mentioned a dozen times on Brave issue tracker, probably unrelated to build type and just due to my kernel/system configuration, will need to look into it separately.

yeah... in official wiki is not mentioned that:

https://github.com/brave/brave-browser/wiki

Well I think I'll change that variable for the next release. It's a shame that build can not be incremental... gclient reset all compiled stuff everytime you want to compile a new release.

If you’re going to contribute to Brave browser open source project, you should know that npm run build (without Release parameter) will provide a debug build.

That's actually what I'd expect to happen with BUILD=debug parameter - i.e. have component build split into .so files, so that e.g. gdb can work with these separately.

(well, that + passing flags to not strip binaries)

Currently it seem to be also building Release bundle, which looks weird to me, but then again, no idea if maybe right thing to do here anyway.

COMPONENT seems fine... I've an old Intel i5, with 16GB RAM and build is slow too (~16 hours)

I think this is the tutorial where I read about build release:

https://www.unixtutorial.org/projects-compiling-brave-browser-on-linux-mint/

Here we go! Let’s build this thing. Should take an hour or two on a fast PC:

greys@xps:~/proj/brave-browser$ npm run build Release

This is a release build, meaning this is a fully performance and release-grade build of the source code. If you’re going to contribute to Brave browser open source project, you should know that npm run build (without Release parameter) will provide a debug build.

So I can make a generic BUILD variable, for instance: default BUILD=0: npm run build

Might also make sense to call this one "component", as that's how docs seem to refer to it.

I don't know about other types though, and whether it makes sense to use for e.g. debug build as well or not. Don't know pretty much anything about Google's build system, unfortunately.

Only noticed that default component build wasn't used when looking into why thing been building here for two days now as mentioned (and might've been for couple more at this rate).

I thought that the best build was release, according to last time I read the documentation. What do you think?

I think if component build works and takes significantly less time, it would make sense to use it as a default option, as it also seem to be default on its wiki here - https://github.com/brave/brave-browser/wiki#build-brave

But again, don't really know all pros and cons, I think it should result in slower initial startup due to dynamic linking and load a dozen .so files instead of just one binary (which can be bad thing on e.g. android).

I'm reading the documentation... So I can make a generic BUILD variable, for instance:

• default BUILD=0: npm run build
• if BUILD=1 or BUILD=release: npm run build Release
• if BUILD=2 or BUILD=static: npm run build -- Static
• if BUILD=3 or BUILD=debug: npm run build -- Release --debug_build=true --official_build=false

Has this any sense?

I thought that the best build was release, according to last time I read the documentation. What do you think?

@figue Looking into why my Brave build here seem to be surprisingly slow, I found that regardless of whether BUILD_RELEASE is 0 or 1, PKGBUILD runs "npm run build Release" (but with extra options in case of 0).

This is explicitly documented as:

Running a release build with npm run build Release can be very slow and use a lot of RAM especially on Linux with the Gold LLVM plugin.

So I wonder, is there a reason why PKGBUILD can't do component build (.so files, not linked into one humongous blob) when asked to build non-release version?

It'd seem to be a logical and expected thing to do for BUILD_RELEASE=0, but not sure if maybe causes any kind of issues, so thought to ask (and if so, maybe worth adding a comment or link to PKGBUILD as well).

@mk-fg see 9ecc75b2d88f

Ah, nice, thanks.

I've reported some time ago the support to build brave with directly the chromium tarball ... but the request was rejected

Right, guess I won't waste time reporting it again, as they should be aware of the issue.

Wanted to wait until after thing finishes building here, make sure it does work afterwards, but looks like linker memory requirements got bumped up significantly again, and my 12G of RAM no longer enough for the build (still linking via swap, and guess might be for days) :(