ungoogled-chromium releases generally follow the chromium stable channel,
however as the patchset targets Linux, macOS and Windows, a release might
not always be intended for being packaged in nix. This patch patches the
update script to filter ungoogled-chromium releases by them being available
as stable releases for Linux.
Not required yet but we should always use the latest LLVM version that
is available in Nixpkgs as Google builds Chromium against commits from
the main branch.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
libvulkan is dlopen'd but is missing from the linker search path.
We probably should be using the libvulkan (and libGLESv2) provided by
chromium, but using vulkan-loader's libvulkan.so.1 is a tried-and-true
workaround.
Fixes#150398.
This change (dynamically linking against libffi from Nixpkgs) is
required since we switched to third_party/wayland instead of linking
against Wayland from Nixpkgs (26aadca7c6). See also f9d9864cb6 and
d932886d6e for more details.
We could alternatively provide libffi_pic.a for static linking but due
to our immutable dependency model / pure builds the dynamic linking
shouldn't cause any issues.
This fixes the build error shown in [0].
[0]: https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1412519998
Many packages have some kind of flag indicating whether or not to build with
systemd support. Most of these default to `stdenv.isLinux`, but systemd does
not build on (and is marked `broken` for) `isStatic`. Only a few packages have
the needed `&& !isStatic` in the default value for their parameter.
This commit moves the logic for the default value of these flags into
`systemd.meta.{platforms,badPlatforms}` and evaluates those conditions using
`lib.meta.availableOn`.
This provides three benefits:
1. The default values are set correctly (i.e. including `&& isStatic`)
2. The default values are set consistently
3. The way is paved for any future non-Linux systemd platforms (FreeBSD is
reported to have experimental systemd support)
Currently Chromium will generate its Web App shortcuts by pointing to
the current unwrapped executable of itself. This leads to all Web App
shortcuts failing to launch as it is not launched trough nixpkgs's
wrapper.
This fix will set the `CHROME_WRAPPER` environment variable to point
to a valid wrapper script, allowing chromium based browsers to generate
valid `.desktop` files.
NOTE: As these files are only set once by the browser inside of
`~/.local/share/applications` and not updated, this fix will only work
for generating new shortcuts, and only work as long as the relevant
binary is available in `$PATH` for that user.
INFO: While generic sounding, `CHROME_WRAPPER` is only invoked inside of
`web_app_shortcut_linux.cc`[^1], so it should only affect the generation
of web app shortcut files.
INFO: There is a similar patch for google-chrome itself in nixpkgs.[^2]
[^1]: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/shell_integration_linux.cc;l=405;drc=b8f43a4e55639b03f76eccc6f6b951f2d06b8833
[^2]: https://github.com/NixOS/nixpkgs/pull/155430/
We do already set `system_wayland_scanner_path` to
`"${wayland}/bin/wayland-scanner"` but apparently wayland-scanner wasn't
required (anymore?) as wayland-scanner is only in the `bin` output (I have a
few ideas what could've changed but didn't bother to check as it isn't worth
the time as long as it works now).
This fixes the following build error:
```
ninja: error: '../../../../../../../../nix/store/l3y9k2x7cqzcjj9s18z7la9xqsjq6r52-wayland-1.21.0/bin/wayland-scanner', needed by 'gen/components/exo/wayland/protocol/aura-shell-protocol.c', missing and no known rule to make it
```
Upstream switched use_system_libwayland to false [0] and
system_wayland_scanner_path will now only be declared if
use_system_wayland_scanner is set to true (it defaults to
use_system_libwayland) [1].
In Nixpkgs, we usually try to set use_system_* to true (i.e., we favor
system libraries over bundled/vendored ones) but in the case of Chromium
this can become difficult to maintain so we might eventually drop
`use_system_libwayland = true` again (IIRC this only caused one
incompatibility in the past though: b6b51374fc7; and f9d9864cb6 will
become relevant again when we build with the bundled libwayland).
[0]: b33bdfe265
[1]: 272220cefa
The build argument `use_system_libwayland_server` was set to `false`
since M107 [0]. This will cause `libwayland` to be built which does in
turn pull in `libffi` ("//build/config/linux/libffi") [1].
Alternatively, we should be able to fix the libffi dependency by setting
`use_system_libffi = true` (recently added, see [2]) and adding `libffi`
to the build inputs.
[0]: b9cd6d6767
[1]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:third_party/wayland/BUILD.gn
[2]: cf3ee09f08
Setting `clang_base_path` [0] does skip [1] a clang version check [2]
that would fail in our case:
```
configuring
ERROR at //build/config/compiler/BUILD.gn:1314:22: Script returned non-zero exit code.
clang_revision = exec_script("//tools/clang/scripts/update.py",
^----------
Current dir: /tmp/nix-build-chromium-unwrapped-107.0.5304.29.drv-0/chromium-107.0.5304.29/out/Release/
Command: python3 /tmp/nix-build-chromium-unwrapped-107.0.5304.29.drv-0/chromium-107.0.5304.29/tools/clang/scripts/update.py --print-revision --verify-version=16.0.0
Returned 1 and printed out:
The expected clang version is llvmorg-16-init-4609-g025a5b22-2 but the actual version is
Did you run "gclient sync"?
See //build/config/BUILDCONFIG.gn:329:3: which caused the file to be included.
"//build/config/compiler:afdo",
^-----------------------------
error: builder for '/nix/store/02riyhzvrgn2vaab29d3gipxzkx6nb44-chromium-unwrapped-107.0.5304.29.drv' failed with exit code 1
```
I also chose to disable the Qt support for now. The Qt support is
enabled by default on Linux [3] but we need to add the required
dependencies first to fix the build (and my current priority is to get a
basic build working for the security critical stable channel update):
```
configuring
ERROR at //build/config/linux/pkg_config.gni:104:17: Script returned non-zero exit code.
pkgresult = exec_script(pkg_config_script, args, "value")
^----------
Current dir: /tmp/nix-build-chromium-unwrapped-107.0.5304.62.drv-0/chromium-107.0.5304.62/out/Release/
Command: python3 /tmp/nix-build-chromium-unwrapped-107.0.5304.62.drv-0/chromium-107.0.5304.62/build/config/linux/pkg-config.py Qt5Core Qt5Widgets
Returned 1.
stderr:
Package Qt5Core was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Core.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Core' found
Package Qt5Widgets was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Widgets.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Widgets' found
Could not run pkg-config.
See //ui/qt/BUILD.gn:13:1: whence it was called.
pkg_config("qt5_config") {
^-------------------------
See //ui/linux/BUILD.gn:54:15: which caused the file to be included.
deps += [ "//ui/qt" ]
^--------
error: builder for '/nix/store/3zzddkh74cnhvq6nql32y9pnbvzf2jv9-chromium-unwrapped-107.0.5304.62.drv' failed with exit code 1
```
[0]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:docs/clang.md
[1]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:build/config/compiler/BUILD.gn;l=1306
[2]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:tools/clang/scripts/update.py;l=358
[3]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/107.0.5304.62:ui/qt/qt.gni;l=8
Passing `-l$NIX_BUILD_CORES` improperly limits the overall system load.
For a build machine which is configured to run `$B` builds where each
build gets `total cores / B` cores (`$C`), passing `-l $C` to make will
improperly limit the load to `$C` instead of `$B * $C`.
This effect becomes quite pronounced on machines with 80 cores, with
40 simultaneous builds and a cores limit of 2. On a machine with this
configuration, Nix will run 40 builds and make will limit the overall
system load to approximately 2. A build machine with this many cores
can happily run with a load approaching 80.
A non-solution is to oversubscribe the machine, by picking a larger
`$C`. However, there is no way to divide the number of cores in a way
which fairly subdivides the available cores when `$B` is greater than
1.
There has been exploration of passing a jobserver in to the sandbox,
or sharing a jobserver between all the builds. This is one option, but
relatively complicated and only supports make. Lots of other software
uses its own implementation of `-j` and doesn't support either `-l` or
the Make jobserver.
For the case of an interactive user machine, the user should limit
overall system load using `$B`, `$C`, and optionally systemd's
cpu/network/io limiting features.
Making this change should significantly improve the utilization of our
build farm, and improve the throughput of Hydra.
The build was failing with the following error:
```
[18950/51180] SOLINK ./libvk_swiftshader.sotls_transport_interface/dtls_transport_interface.omputils.o[K.otch.oos.oKx/unbundle:default)fault)ault)
FAILED: libvk_swiftshader.so libvk_swiftshader.so.TOC
python3 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=all -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=30 -fwhole-program-vtables -Wl,--no-call-graph-profile-sort -m64 -no-canonical-prefixes -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,--lto-O0 -fsanitize=cfi-vcall -fsanitize=cfi-icall -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp"
ld.lld: error: unable to find library -l:libffi_pic.a
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
This turned out to be a regression from b6b51374fc. That change was
bad/undesirable in the first place and I only applied it to quickly fix
another build error caused by incompatible wayland-protocols header
files from a newer system version (Chromium bundles version 1.21 while
we already package 1.26).
The better fix for that wayland-protocols build issue is to pull in a
patch that is already used/tested by the Arch package [0] and seems to
originate from [1] (not sure if that patch was formally submitted yet).
Alternatives to that patch would be to (we should probably first try the
first approach if need be):
1) Build with wayland-protocols 1.21 from the system (by overriding the
Nixpkgs package).
2) Dynamically link against libffi by patching [2] to use the other
branch (`default_toolchain == "//build/toolchain/cros:target"`).
Some additional details can be found in the GitHub PR [3].
Huge thanks to Lorenz Brun for his great analysis that enabled me to fix
the build so that we can finally merge the update to Chromium M105
(which contains many important security fixes!).
[0]: a353833a5a
[1]: https://bugs.chromium.org/p/angleproject/issues/detail?id=7582#c1
[2]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/105.0.5195.52:build/config/linux/libffi/BUILD.gn
[3]: https://github.com/NixOS/nixpkgs/pull/189033
Co-Authored-By: Lorenz Brun <lorenz@brun.one>
This "fixes" errors like these:
```
FAILED: obj/third_party/angle/angle_gpu_info_util/SystemInfo_vulkan.o
[...]
In file included from ../../third_party/wayland/src/src/wayland-client.h:40:
/nix/store/an42rhwn6ck2nix6caikrr4rvizknjhh-wayland-1.21.0-dev/include/wayland-client-protocol.h:1040:13: error: use of undeclared identifier 'wl_proxy_marshal_flags'
callback = wl_proxy_marshal_flags((struct wl_proxy *) wl_display,
^
[...]
/nix/store/an42rhwn6ck2nix6caikrr4rvizknjhh-wayland-1.21.0-dev/include/wayland-client-protocol.h:1392:87: error: use of undeclared identifier 'WL_MARSHAL_FLAG_DESTROY'
WL_SHM_POOL_DESTROY, NULL, wl_proxy_get_version((struct wl_proxy *) wl_shm_pool), WL_MARSHAL_FLAG_DESTROY);
^
[...]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
```
At least for now (until Chromium updates their bundled Wayland version) it
seems best to use the bundled headers/versions to avoid version incompatibility
issues (we should hopefully be able to drop use_system_wayland_scanner though).
