The Chromium and Google Chrome packages are desperately in need of a new maintainer (since updates are very security critical in both cases).
Ideally we'd have a team of multiple maintainers or at least multiple testers to test on multiple architectures and multiple channels.
The testing should cover the following cases:
| platform | attribute | status | tester |
| --- | --- | --- | --- |
| x86_64 | chromium | - | @danielfullmer |
| x86_64 | nixosTests.chromium | - | @danielfullmer |
| x86_64 | google-chrome | - | - |
| aarch64 | chromium | - | @thefloweringash |
Related: ungoogled-chromium
maintainer: @squalus (x86_64
)
| platform | attribute | status | tester |
| --- | --- | --- | --- |
| x86_64 | chromium | - | @Frostman |
| x86_64 | nixosTests.chromium | - | @Frostman |
| x86_64 | google-chrome | - | - |
| aarch64 | chromium | - | - |
And optionally (Hydra only builds the stable channel!) also the beta channels: chromiumBeta
and google-chrome-beta
.
The dev
channel should not delay updates IMO and should probably be used for testing only (can be useful to test and fix build failures in advance).
Tests (should cover the essential functionality, minor regressions can also be fixed later):
Browser startup + version matches, Random Browsing, Video+Audio (YouTube), WebGL, and JS + WASM.
(Optional: Widevine CDM (proprietary), VA-API (requires a rebuild), Octane 2.0 JavaScript Benchmark, X11/XWayland + different GPUs (GPU acceleration)).
Unfortunately the build requirements for Chromium are quite demanding (source):
Which means this requires some dedication and/or hardware.
Notifications of new updates can be acquired via the following RSS feed:
https://chromereleases.googleblog.com/feeds/posts/default (filter for Stable Channel Update for Desktop
).
Typically, within a few hours of an upstream release being available, a source tarball is also available and pkgs/applications/networking/browsers/chromium/update.sh
can be used to update upstream-info.nix
. Note that when upstream does not have a tarball yet, update.sh
may silently fail to update a hash in upstream-info.nix
, making it look like the version was updated while retaining the old hash.
All updates are considered security-critical need to be backported to the stable channel (i.e. open a separate PR).
In upcoming releases, I expect WebGL to break again because of a libGLESv2.so loading issue that this patch is working around, watch out for that.
Unverified: Use the --cores
option to build with ~2x the numbers of threads/cores to avoid only 50% CPU utilization/load.
TODO: Add more relevant information (feel free to ask questions).
TODO: Need to package 79.0.3945.130 (released 2020-01-16).
Credits: @ivan (Workflow & Hints), @thefloweringash (Table for the "Testing-Matrix")
cc: @bendlas @thefloweringash @msteen
Ideally the testing should cover at least the following:
Just a quick clarification here. There's no google-chrome
for aarch64.
Unfortunately the build requirements for Chromium are quite demanding (source):
- A 64-bit Intel machine with at least 8GB of RAM. More than 16GB is highly recommended.
- At least 100GB of free disk space.
Which means this requires some dedication and hardware.
The 100GiB bit, fortunately, seems to be «we have no idea and you cannot make us care» — Chromium seems to build fine (in a day or so) on my 30GiB /tmp (which is not completely empty).
@thefloweringash @7c6f434c thanks for the clarifications, I've updated the content accordingly.
@thefloweringash I've missed the fact that you're the AArch64 maintainer, can I add you as AArch64 tester to the table above? And if so, which channels and nixos-releases would you like to test (simply testing chromium
on nixos-unstable
would already be enough, additional tests would be nice to have but not essential and probably not worth the build times, depending on how long it takes)?
I see myself mentioned because I am listed as the maintainer for Google Chrome, but after my initial commit I have not done any maintenance nor testing (other than using it), so if there is someone out there willing to maintain the Google Chrome package, please do not hesitate to replace my name for yours in the list of maintainers.
can I add you as AArch64 tester to the table above
Sure thing.
which channels and nixos-releases would you like to test
My main motivation is a laptop running nixos-unstable that I want to be able to run chromium on, so the chromium
on nixos-unstable
case at least. On my builder chromium takes about 5 hours to build. It shouldn't be unreasonable for me to build all three chromiums on each PR, I guess I'll try to test everything and see if it becomes too much.
I don't know what this would look like yet, but I think we could provide access to a big machine for testing from time to time. How often would this be needed, and what would be the most convenient (for maintainers) way to do it?
@grahamc that sounds like a good idea, I was already wondering if something like this would be possible (especially if we have some underused resources to spare). From my RSS log there are usually 2 (sometimes 3) stable channel updates per month (not counting PRs for fixes, configuration changes, etc.). I'm not sure what the most convenient way would look like (or what options are available) but I guess it wouldn't matter that much.
Maybe also interesting in this regard: @GrahamcOfBorg
doesn't blacklist Chromium and manages to build ~57% (x86_64) / ~73% (aarch64) during the one hour limit (IIRC the build rate decreases a bit towards the end, but even for x86_64 a complete build should then be possible withing ~2.5h). If there would be a way to fetch the build results form @GrahamcOfBorg
(which I'm not aware of, but I'm not really familiar with the implementation or possible hacks (e.g. a hook to push the result to another server)), this might actually also be a good option.
The following notes are based on my limited experience as provisional maintainer (I only handled one update so far):
With the minimal testing approach (which should be sufficient) we'd need to build Chromium at least twice (for nixos-unstable and the stable channel) and I would try to build chromiumBeta and chromiumDev at least if the major version changes to catch bugs, incompatible patches, etc. in advance (so that stable channel updates are usually trivial and can be merged fast).
Currently I have only my old desktop PC (takes ~6h to build Chromium) and a spare VPS (only dual-core, takes ~24h to build Chromium) available, which is a bit limiting (and a reason why I'd like to avoid having to permanently maintain Chromium), especially since using my desktop PC for this is problematic/annoying. I think it would work for now (mainly takes a bit longer to test) and I should still have a few unused AWS credits that I could probably use for this. But if builds would sometimes fail towards the end (or actually even anywhere during the actual build phase) this could quickly become problematic (I did build Chromium with --keep-failed
but haven't tested yet how easy it would be to iteratively fix and resume the build after errors)
I also assume that the build for the stable channel should be fine if Chromium builds on nixos-unstable, but I don't trust that assumption enough to merge the backport without testing (after all there could still be problems like too old dependencies, missing backports of some patches, different abstractions, etc.).
As a result I was wondering if it could make sense to add a Hydra job for a branch like chromium-stable
which we would push to after the build is fine on master (but I haven't really thought this trough yet). The advantage would be that the result would already be in the official binary cache, which might simplify testing a bit (especially if we had multiple testers) and we could check if the aarch64 builds on nixos-stable succeed. But Hydra builds do also take ~24h IIRC (and there might be additional drawbacks like evaluation overhead, management, etc.).
Anyway, these are my (a bit longer than expected - sorry :o) thoughts on this matter. I hope they do make some sense and are somewhat ordered. If there is an option that we could setup and maintain without much effort that'd be awesome, if not I'll try to optimize my current workflow and we could also revisit this topic later if problems/complications occur. And this is also only my opinion as a provisional maintainer, maybe we find another maintainer soon who has e.g. more resources available.
@primeos as discussed in #79242 you can put me for chromium testing on unstable. Just to clarify, the machine I can run tests on is headless, so, I'll not be able to really manually do any checks on the browser. And to confirm is that enough to run (for example) nixpkgs-review pr 79458 -p nixosTests.chromium
?
P.S. If you need the same testing for stable, I can run it as well.
As a result I was wondering if it could make sense to add a Hydra job for a branch like chromium-stable which we would push to after the build is fine on master (but I haven't really thought this trough yet). The advantage would be that the result would already be in the official binary cache, which might simplify testing a bit (especially if we had multiple testers) and we could check if the aarch64 builds on nixos-stable succeed. But Hydra builds do also take ~24h IIRC (and there might be additional drawbacks like evaluation overhead, management, etc.).
This should definitely be fine. We have this also for other things, like Python and Haskell packages set. We would need then a pkgs/top-level/release-chromium.nix
and a Hydra job. I can't create the Hydra job though. Those with write privileges can then (force-)push to that branch.
P.S. If you need the same testing for stable, I can run it as well.
@Frostman if that wouldn't be a problem for you this would be awesome and very helpful (I didn't mention nixos-stable
right away as I was afraid of asking for too much :D). Anyway, thanks for your great help and sorry for the delayed reply.
@primeos yes, sure, I'll run nixosTests.chromium
for stable as well.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/go-no-go-meeting-nixos-20-03-markhor/6495/16
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Most helpful comment
I don't know what this would look like yet, but I think we could provide access to a big machine for testing from time to time. How often would this be needed, and what would be the most convenient (for maintainers) way to do it?