Recap: We need that (arguably stupid) helper function/drv because the
chromium tarball is big -- and is likely to increase even more in the
future. So big, that we eventually exceeded hydra.nixos.org's
max-output-limit (3G). Instead of raising global hydra's limit, it was
decided that we recompress the tarball after deleting unused vendored
files from it.
I spent a lot of time on a version/prototype that does everything
(downloading, decompression, tar extraction, deleting unused files,
reproducible tar recreation and finally recompression) via stdin but
eventually had to scratch that.
GNU tar does not allow to create a tarball just from stdin, nixpkgs'
stdenv isn't built with stdin/stdout/pipes in mind, and things a lot of
other things I probably already forgot.
Nonetheless, this version improves multiple things:
- No more `mv` (used to be multiple, not just ours, since fetchzip had
some as well)
- No more `rm` to get rid of the extracted files before recompressing.
Instead, we simply don't extract them in the first place (thanks to
tar's --exlude).
- No more "no space left" that happened due to `downloadToTemp = true;`.
- Multithreaded xz decompression, since that commit is still in
staging-next.
We cannot use stdenv's unpackFile() because that does not allow us to
specify the needed --exclude (and --strip-components=1 if we don't want
to rely on glob matching).
The hash changed because we now have a static base directory ("source")
in the tarball, instead of whatever upstream provided us with (e.g.
"chromium-120.0.6099.129").
Specifically the maintainers section is quite outdated and prone to get
out of sync with whatever primary data we have (mostly meta.maintainers)
in each derivation.
In an attempt to lower the risk of ending up out of sync again, we
simply remove the maintainer handles.
Also adds a mention for the newly from source built electron variant, as
almost everything except `upstream-info.nix` bumps will trigger electron
rebuilds as well.
And lastly, removes mentions of `chromium{Beta,Dev}` and the
accompanying `google-chrome-{beta,dev}, that have been removed a few
months ago.
I might look into reworking bigger parts of the README.md in the future,
but this honestly isn't that high of a priority for me for now.
Our ./maintainers/README.md has a section titled "How to lose maintainer
status", which describes an "inactivity measure":
Maintainers how haven't reacted to "package-related notifications" for
more than 3 months can be removed.
All those 4 maintainers that are getting dropped as part of this commit
haven't responded to any such notifications (mostly review pings) for at
least 3 months.
Having
```nix
host_toolchain = "//build/toolchain/linux/unbundle:host";
v8_snapshot_toolchain = "//build/toolchain/linux/unbundle:host";
```
on native, non-cross-compilation builds roughly doubles the build steps
and, by proxy, compute and time needed to build.
So to resolve this, we conditionally change those values depending on
whether we are cross-compiling or not.
Co-authored-by: Adam Joseph <adam@westernsemico.com>
this patch adds a new subcommand to the update script
```
update.py ungoogled-rev <rev>
```
to update to an unreleased version of ungoogled-chromium by referencing
a git ref from the ungoogled-chromium repository (like a commit hash in an
update pull request).
Chromium libANGLE-based GL loading was working by accident before, because the cairo lib pulled in libEGL previously (so dlopen didn't need to search rpath when called in libGLESv2) but no longer does and the rpath needs to be added on both the chromium binary and the libGLESv2.so (and yes both even expect to have pciutils available it seems)
Fixes#268490#269104
This is mainly due to the lack of maintenance in nixpkgs.
`google-chrome-{beta,dev}` depend on `chromium{Beta,Dev}`'s version
info.
`chromium{Beta,Dev}` are rarely updated and explicitly blocklisted by
`hydra.nixos.org`, meaning they are almost always outdated and not
cached in `cache.nixos.org`.
`chromium{Beta,Dev}` were intended to fix the build derivation of each
new major release (if something broke) *before* stable reached that
new major release.
Allowing for fast bumps in nixpkgs, especially if the stable bump
contains very important critical security fixes.
Something that can easily be replicated by using an early-stable release
or by manually entering a dev/beta version string in stable's
`upstream-info.nix`.
This resolves exposing end-users to outdated and vulnerable
`google-chrome-{beta,dev}` and `chromium{Beta,Dev}` versions.
this patch updates the packaging of chromium and chromedriver to use
sri hashes in `upstream-info.nix` instead of sha256 as well as
the packaging of electron to use sri hashes in `info.json` instead
of sha256 (just gn).
this patch also updates the previous `sha256` values in
`upstream-info.nix` and `info.json` to sri hashes in `hash`.
this patch changes the update script to always output sri hashes
for all hashes written to chromium's `upstream-info.nix` and
electron's `info.json`. the keys have also been renamed from `sha256`
to `hash`.
Chromium has blocklists that workaround various GPU driver bugs, either
by forcing software rendering [1] or by disabling use of certain GPU
features [2].
These blocklists can only be applied successfully if the GPU vendor and
device is detected correctly. One of the methods used for GPU detection
is to load libpci.so via dlopen() at runtime to read the PCI vendor and
device ID.
The current derivation already contains a sed command to rewrite the
dlopen() to the absolute path of libpci.so in the Nix store, namely
sed -i -e '/libpci_loader.*Load/s!"\(libpci\.so\)!"${pciutils}/lib/\1!' \
gpu/config/gpu_info_collector_linux.cc
However, in Chromium 59 (6 years ago), this code was moved into the
ANGLE library used by Chromium [3]. This sed command no longer works.
There is similar code in ANGLE now [4] that must be similarly patched to
ensure the GPU vendor and device is always detected correctly.
Without libpci some GPUs are not detected correctly. For example, in a
VMWare virtual machine opening chrome://gpu in the browser shows:
VENDOR= 0x0000 [Google Inc. (VMware, Inc.)], DEVICE=0x0000 [ANGLE
(VMware Inc., SVGA3D; build: RELEASE; LLVM;, OpenGL 4.1 (Core Profile)
Mesa 23.0.3)], DRIVER_VENDOR=Mesa, DRIVER_VERSION=23.0.3 *ACTIVE*
Note the VENDOR=0x0000 and DEVICE=0x0000. Adding libpci.so to the
library path fixes this:
VENDOR= 0x15ad [Google Inc. (VMware, Inc.)], DEVICE=0x0405 [ANGLE
(VMware Inc., SVGA3D; build: RELEASE; LLVM;, OpenGL 4.1 (Core Profile)
Mesa 23.0.3)], DRIVER_VENDOR=Mesa, DRIVER_VERSION=23.0.3 *ACTIVE*
Note the VENDOR=0x15ad and DEVICE=0x0405. Also now the blocklist entries
are applied correctly, fixing some graphical issues.
Fix this by adding pciutils to the rpath set with patchelf. This avoids
having to patch lines in the source code that might get moved around.
[1]: e52f33f30b/gpu/config/software_rendering_list.json
[2]: e52f33f30b/gpu/config/gpu_driver_bug_list.json
[3]: 873b27d518
[4]: 05f45adc14/src/gpu_info_util/SystemInfo_libpci.cpp (L41)
to stay below hydra limit.
At the time of writing, the hydra.nixos.org's output limit is 3 GB.
The latest chromium tarball, however, is slightly above that.
To work around this, recompress the original `tar.xz` into a `tar.zstd`
and delete two unreasonably big and unused directories.
Bringing it down to roughtly 2.2 GB.
Unfortunately, this change breaks the `update.py` script.
Resolves the current channel-blocker.
ofborg uses `builtins.unsafeGetAttrPos` internally, to figure out which
maintainers need to be pinged.
e.g:
`builtins.unsafeGetAttrPos "version" drv`
When using a `.json` file containing the version via `lib.importJSON`,
this will always return `null` and thus leading to no pings at all.
This commit works around this, resulting in properly working pings
for any changes to the upstream-info file.
A similar thing has been done for element-{web,desktop} in the past.
