LLVM 12 is required but the build still fails due to other changes that
where introduced in the meantime (and Chromium 90.0.4430.51 introduced
another LLVM failure).
The builds currently fail with (should work with LLVM 12 [0]):
../../base/check.h:88:3: error: 'nomerge' attribute cannot be applied to a declaration
NOMERGE ~CheckError();
^ ~
../../base/compiler_specific.h:344:19: note: expanded from macro 'NOMERGE'
#define NOMERGE [[clang::nomerge]]
^
1 error generated.
[0]: fb0f728805
This also adds a dedicated channel for ungoogled-chromium that enables
us to update ungoogled-chromium independently of chromium.
TODO: Automate ungoogled-chromium updates via update.py (currently it
needs to be updated manually).
Note: Unfortunately this changes the ungoogled-chromium derivation
because common.nix passes the channel as an argument to
stdenv.mkDerivation (this makes it more difficult to verify this commit
but the result should remain the same).
I used nix-instantiate to verify that the derivations for chromium and
ungoogled-chromium remain unchanged (only the meta attributes change
slightly as I added myself as ungoogled-chromium to receive
notifications for PRs/issues).
Wanted to do this for a long time to collect important knowledge and
make it easier to pass maintainership.
Only time will tell if this'll be useful or become outdated instead.
This will additionally install the following files:
libEGL.so libGLESv2.so
libVkICD_mock_icd.so libvk_swiftshader.so libvulkan.so
libEGL.so and libGLESv2.so are required to fix our ANGLE support.
The rest should help with the Vulkan support (currently an experimental
feature that is disabled by default).
Mark chromiumDev as broken since the build requires LLVM 11 which is not
yet in Nixpkgs (due to the lack of an RC, see #93324). Build error:
clang (LLVM option parsing): Unknown command line argument '-basic-aa-recphi=0'. Try: 'clang (LLVM option parsing) --help'
clang (LLVM option parsing): Did you mean '--basicaa-recphi=0'?
ninja: build stopped: subcommand failed.
This makes it possible to use chromium headless with WebGL
(e.g. for webdriver tests) without having to rebuild from source.
The upstram default is to enable, thus simply removing our disabling switch.
Also fixes#41918.
I don't really have the hardware resources nor time to do this properly,
but I'll try to keep a watch on Chromium (updates, PRs, and issues)
until we've found a new team [0].
Testing will be performed on a best effort basis (no guarantees :o).
I've also briefly documented the current maintainer
roles/responsibilities and added `meta.longDescription`.
[0]: https://github.com/NixOS/nixpkgs/issues/78450
This change allows widevine to work in chromium (it was previously
broken due to a segfault). Newer versions of chromium do not use the
libwidevinecdmadapter.so. Instead, libwidevinecdm.so should be installed
in the chromium libExec directory.
Upstream provides a much more featureful desktop entry file. If we use
that we take advantage of all of those features and don't have to maintain it
ourselves.
The following errors occur when you start Chromium prior to this commit:
[2534:2534:0625/202928.673160:ERROR:gl_implementation.cc(246)] Failed to
load .../libexec/chromium/swiftshader/libGLESv2.so:
../libexec/chromium/swiftshader/libGLESv2.so: cannot open shared object
file: No such file or directory
[2534:2534:0625/202928.674434:ERROR:gpu_child_thread.cc(174)] Exiting
GPU process due to errors during initialization
While in theory we do not strictly need libGLESv2.so, in practice this
means that the GPU process isn't starting up at all which in turn leads
to crawling rendering performance on some sites.
So let's install all shared libraries in swiftshader.
I've tested this with the chromium.stable NixOS VM test and also locally
on my machine and the errors as well as the performance issues are gone.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
requiredSystemFeatures is not a meta attribute but a derivation
attribute. So "big-parallel" was being ignored on e.g. chromium,
causing it to be built (and timing out) on slow machines.
http://hydra.nixos.org/build/45819778#tabs-buildsteps
Before version 54, the WideVine CDM plugin was built unconditionally and
it seems since version 54 this now is dependent upon a GYP/GN flag on
whether to include the CDM shared library or not.
Also, we now use a patch from Gentoo which should hopefully get the CDM
plugin to work properly, at least according to their bugtracker:
https://bugs.gentoo.org/show_bug.cgi?id=547630
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not the job of Nixpkgs to distribute beta versions of upstream
packages. More importantly, building these delays channel updates by
several hours, which is bad for our security fix turnaround time.
This reverts commit 5979946c41.
I have tested this by building against the stable version of Chromium
and it seems to compile just fine, so it doesn't seem to be needed
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Working on Chromium really drives me nuts due to its build time, also I
really don't have quite a lot of time these days to properly maintain it
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Built and run Beta and Stable locally. Dev is surrently superseded by Stable so
it doesn't matter much.
- Dev: 47.0.2508.0 -> 48.0.2564.22
- Beta: 46.0.2490.64 -> 48.0.2564.23
- Stable: 45.0.2454.101 -> 47.0.2526.73
Changed the SSL dependencies to the supported configuration on Linux (according
to Torne @Freenode/#chromium-support).
- NSS is a dependency since it is used to access the ceritiface store.
- Dropped system OpenSSL support, the bundled BoringSSL is used.
This probably fixes issue #10555. Note that without this adjustment the build
fails even.
Dropped uneeded old patches.
Overview of the updated versions:
stable: 43.0.2357.125 -> 43.0.2357.130
beta: 44.0.2403.52 -> 44.0.2403.61
For the beta channel the following changes were necessary:
* Drop all patches which were added in c290595 because they apply to
44.0.2403.52 only. The shipped version of Blink was older than the
one used for Chromium itself and thus contained just the
cherry-picked patches from upstream Blink.
* The ffmpegsumo library is now statically linked the same way as in
the dev version, so let's not try to put it into the output store
path.
All channels were built successfully on my Hydra at:
https://headcounter.org/hydra/eval/187176
VM tests did also pass and can be found at:
x86: https://headcounter.org/hydra/build/707636
x86_64: https://headcounter.org/hydra/build/707637
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just silencing the error will not prevent Chromium from trying to start
up the SUID sandbox anyway, thus flooding stderr with:
LaunchProcess: failed to execvp:
After digging a bit in the source code I found out that the SUID sandbox
binary is indeed used, but only for setting oom_score_adj within the
user namespace (as "root"). So let's build the sandbox binary and of
course don't set setuid bit.
These annoying error messages were originally introduced by 0aad4b7 and
I'm deeply sorry for annoying you guys out there with them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of the updated versions:
stable: 40.0.2214.91 -> 40.0.2214.115
beta: 41.0.2272.16 -> 41.0.2272.64
dev: 41.0.2272.16 -> 42.0.2305.3
Introduces 42.0.2305.3 as the new dev version, which no longer requires
our user namespaces sandbox patch. Thanks to everyone participating in
https://crbug.com/312380 for finally having this upstream.
In the course of supporting the official namespace sandbox (that's what
the user namespace sandbox is called), a few things needed to be fixed
for version 42:
* Add an updated nix_plugin_paths.patch, because the old
one tries to patch the path for libpdf, which is now natively included
in Chromium.
* Don't copy libpdf.so to libexec path for version 42, it's no longer
needed as it's completely built-in now.
* Disable SUID sandbox directly in the source instead of going the easy
route of passing --disable-setuid-sandbox. The reason is that with
the command line flag a nasty nagbar will appear.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
