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"
```
Just like with Firefox, we need to make sure there's only a single
version of LLVM involved in building Chromium, or we get errors like
this:
ld.lld: error: Invalid record (Producer: 'LLVM18.1.7' Reader: 'LLVM 17.0.6')
Fixes: 23d4f83453 ("cargo,clippy,rustc,rustfmt: 1.77.2 -> 1.78.0")
This gets rid of a lot of redundant logic that is already present in the
`widevine-cdm` package :)
The resulting directory structure is the same and works just as well.
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").
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`.
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.
Sometimes we access `llvmPackages` via `pkgs`, and other times via
`pkgsFooBar`, so unfortunately a string (attrname) is the only way
to have a single point of control over the LLVM version used for
both buildPlatform and hostPlatform.
ungoogled-chromium is, contrary to its name, not a build of
chromium. It is a patched copy of chromium's *source
code*. Therefore, it needs to come from pkgsBuildBuild, because it
contains python scripts which get /nix/store/.../bin/python3 patched
into their shebangs.
`llvmPackages.clang` is used in the `gnFlags` attrset, so we need to
indicate explicitly which "on" platform (the build) and which "for"
platform (the host) we want. This commit does that.
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.
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/
This fixes the following build error:
[24751/48400] ACTION //components/url_formatter/spoof_checks/top_domains:generate_top_domain_list_variables_file(//build/toolchain/linux/unbundle:default)d_tmp/browser_command.mojom-webui.js.mojom-webui.jsui.js
FAILED: gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
python3 ../../build/gn_run_binary.py make_top_domain_list_variables ../../components/url_formatter/spoof_checks/top_domains/domains.list top500_domains gen/components/url_formatter/spoof_checks/top_domains/top500-domains-inc.cc
make_top_domain_list_variables failed with exit code -4
The "make_top_domain_list_variables" program fails due to a SIGILL error
(illegal instruction). See:
- https://bugs.chromium.org/p/chromium/issues/detail?id=1273966
- https://reviews.llvm.org/D115015
- https://bugs.chromium.org/p/chromium/issues/detail?id=1269407
This is important so that users can choose to use other implementations
(e.g., self-written Bash scripts).
We only provide xdg-utils as a fallback in case the system isn't
properly configured.
Chrome, Chromium, VSCode, Slack, Signal, Discord, element-desktop,
schildichat.
For the latter two, the feature flag useWayland was removed and a
wrapper script was provided.
Those functions can be required anywhere in the Nix expressions for
Chromium and therefore they should be defined in default.nix and
inherited where necessary.
This fixes the chromiumBeta build which failed because I forgot to
update the channel conditional when the beta channel advanced to M94.
This is exactly why the version based conditionals should be used
everywhere.
Note: I've only tested this with llvmPackages_git but it should work
with llvmPackages_13 as well.
fieldtrial_testing_like_official_build was renamed to
disable_fieldtrial_testing_config:
486e9d58c0
The stable channel update to M92 (97570d30c7) broke the Wayland support:
$ chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
[31712:31712:0721/114725.940557:ERROR:wayland_connection.cc(137)] Failed to load wayland client libraries.
[31712:31712:0721/114725.940641:FATAL:ozone_platform_wayland.cc(177)] Failed to initialize Wayland platform
[0721/114725.947566:ERROR:process_memory_range.cc(75)] read out of range
Trace/breakpoint trap (core dumped)
https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop_20.html
This update includes 35 security fixes.
CVEs:
CVE-2021-30565 CVE-2021-30566 CVE-2021-30567 CVE-2021-30568
CVE-2021-30569 CVE-2021-30571 CVE-2021-30572 CVE-2021-30573
CVE-2021-30574 CVE-2021-30575 CVE-2021-30576 CVE-2021-30577
CVE-2021-30578 CVE-2021-30579 CVE-2021-30580 CVE-2021-30581
CVE-2021-30582 CVE-2021-30583 CVE-2021-30584 CVE-2021-30585
CVE-2021-30586 CVE-2021-30587 CVE-2021-30588 CVE-2021-30589
Note: This won't be the smoothest update. Chromium seems to be fine but
requires gtk3 in $LD_LIBRARY_PATH to find libgtk-3.so.0 (otherwise it
crashes during startup) but Google Chrome fails to initialize
("GPU process exited unexpectedly: exit_code=132") and requires
"--use-gl=angle --use-angle=swiftshader" for hardware(?) acceleration
(which seems to work work fine and performant but SwiftShader should
actually use the CPU instead of the GPU).
