This allows us to match the version the binaries use more closely.
For example, chromedriver darwin (binary) reports the following:
~~~bash
chromedriver --version
ChromeDriver 131.0.6778.85 (3d81e41b6f3ac8bcae63b32e8145c9eb0cd60a2d-refs/branch-heads/6778@{#2285})
~~~
while on Linux, where we build chromedriver based on the chromium
derivation from source and control the string ourselves:
~~~bash
chromedriver --version
ChromeDriver 131.0.6778.85 (131.0.6778.85-refs/heads/master@{#0})
~~~
With this commit, the version string now reports:
~~~bash
chromedriver --version
ChromeDriver 131.0.6778.85 (3d81e41b6f3ac8bcae63b32e8145c9eb0cd60a2d-refs/tags/131.0.6778.85@{#0})
~~~
This may seem like a small and unimportant detail, but turns out an
internal function within chromedriver depends on the git hash.
See https://chromium.googlesource.com/chromium/src/+/131.0.6778.85/chrome/test/chromedriver/chrome/browser_info.cc#172
This caused the tests of one package (single-file-cli) that use
selenium with chromium and chromedriver to fail in 24.05.
Only in 24.05, because 24.11 and unstable removed their test dependency
on chromedriver because it wasn't available for aarch64-linux at that
time.
~~~
Running phase: checkPhase
Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...
session not created
from unknown error: unrecognized Blink revision: 131.0.6778.85 URL: http://127.0.0.1:8000
Stack: SessionNotCreatedError: session not created
from unknown error: unrecognized Blink revision: 131.0.6778.85
at Object.throwDecodedError (/build/source/node_modules/selenium-webdriver/lib/error.js:524:15)
at parseHttpResponse (/build/source/node_modules/selenium-webdriver/lib/http.js:601:13)
at Executor.execute (/build/source/node_modules/selenium-webdriver/lib/http.js:529:28)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
~~~
This patch extends the caching mechanism of the chromium
update scripts to use cached dependencies of all attributes
in the lockfile.
When updating ungoogled-chromium for example, the update script
will now use cached dependencies from vanilla chromium, usually
meaning that no additional fetching has to be done.
This builds upon Yureka's work to build electron from source.
A lot of the newly introduced changes to the chromium derivation and
update script are 1-to-1 copies or slight derivates of that work.
Especially the newly added depot_tools.py to resolve the DEPS files does
most of the heavy lifting and is an ever so slightly modified version of
that section Yureka implemented in electron's update.py.
Some coordination between the chromium and electron maintainers should
allow us to deduplicate a lot of the duplicated code fairly easily in
the future.
That just wasn't a goal with this commit, due to time constraints and
the urgency to switch away from the release tarballs.
Instead of taking just a few hours for a tarball to be available for
download after a release, it now takes multiple days at least.
At the time of writing, roughly a week after M131 was released, the
tarball is still not available. It's unclear if it will ever be.
Reason for this are CI issues on Google's side.
Note that virtually every release contains some security critical fixes.
Also note that this commit is written with a lot of conditionals so the
electron derivation doesn't change (just yet).
The new update.mjs update script is still very much work-in-progress but
gets the job done.
Co-Authored-By: Yureka <yuka@yuka.dev>
This is no longer used as we only differentiate between stable and
ungoogled-chromium, which we already track in the "ungoogled" boolean.
Beta and dev channels are gone for good.
It's been a year since their removal in 59719f787e.
There is, however, an additional channel mapping in nixos/tests/chromium
but that one is independent from this one here.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
https://chromereleases.googleblog.com/2024/08/stable-channel-update-for-desktop_21.html
This update includes 38 security fixes. Google is aware that an exploit
for CVE-2024-7971 exists in the wild.
CVEs:
CVE-2024-7964 CVE-2024-7965 CVE-2024-7966 CVE-2024-7967 CVE-2024-7968
CVE-2024-7969 CVE-2024-7971 CVE-2024-7972 CVE-2024-7973 CVE-2024-7974
CVE-2024-7975 CVE-2024-7976 CVE-2024-7977 CVE-2024-7978 CVE-2024-7979
CVE-2024-7980 CVE-2024-7981 CVE-2024-8033 CVE-2024-8034 CVE-2024-8035
https://chromereleases.googleblog.com/2024/08/stable-channel-update-for-desktop_21.html
This update includes 38 security fixes. Google is aware that an exploit
for CVE-2024-7971 exists in the wild.
CVEs:
CVE-2024-7964 CVE-2024-7965 CVE-2024-7966 CVE-2024-7967 CVE-2024-7968
CVE-2024-7969 CVE-2024-7971 CVE-2024-7972 CVE-2024-7973 CVE-2024-7974
CVE-2024-7975 CVE-2024-7976 CVE-2024-7977 CVE-2024-7978 CVE-2024-7979
CVE-2024-7980 CVE-2024-7981 CVE-2024-8033 CVE-2024-8034 CVE-2024-8035