* alfis: migrate to the new fetcher
* workstyle: migrate to the new fetcher
* mullvad: migrate to the new fetcher
* chiptrack: migrate to the new fetcher
* conduwuit: migrate to the new fetcher
* xdg-desktop-portal-cosmic: migrate to the new rust fetcher
* cloud-hypervisor: migrate to the new fetcher
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"
```
This may fix the build on Darwin (the `xvfb-run` package, which is
required only to run the testsuite, is Linux-only since #123097, and the
“proper solution” mentioned in that PR was not implemented). Apparently
someone cared about building `i3` on Darwin at the time of #6135.
The testsuite can run only on Linux, because it requires `xvfb-run`,
which is not available on non-Linux platforms; however, it should not be
limited just to `x86_64-linux`.
The conditional setting of `checkPhase` was introduced in #6135, because
at that time the `checkPhase` script referred to `${xdummy}`, and that
kind of reference would break evaluation if the specified package was
not available; the current version of the `checkPhase` script does not
refer to any package paths directly, therefore the condition is no
longer needed and can be removed.
The `i3-rounded` package is derived from `i3`, but uses some old fork of
`i3` which does not have the `318-i3-dmenu-desktop.t` testcase. Make
the code in `postPatch` check whether that testcase is actually present,
so that the build of `i3-rounded` does not fail.
Some tests in the i3 testsuite are silently skipped if the dependencies
required to run those tests are missing. The problematic dependencies
turned out to be `xdotool`, `xorg.setxkbmap`, `xorg.xrandr`, `which`
(the latter is used to verify the presence of some tools). Add those
dependencies to `buildInputs`, so that all tests would be run.
Ideally such missing dependencies should be detected as test failures,
but it's hard to implement, because missing tools result just in `skip`
marks in the test log, and there are some tests which are skipped for
other reasons (e.g., tests which were written before the expected
behavior is actually implemented in i3).
The `checkPhase` script was stale and needed to be rewritten for the new
version of i3 (paths are different now, and `complete-run.pl` now
invokes `xvfb-run` internally). The code to check the log file for
errors might be unneeded for the new version (`complete-run.pl` seems to
return a non-zero exit code correctly on errors), but is left to catch
any possible regressions in the test runner behavior.
Also the `318-i3-dmenu-desktop.t` testcase was failing, because that
testcase was creating a temporary Perl script intended to shadow the
real `i3-msg` executable, but the `#!/usr/bin/env perl` shebang in that
script did not work in the build environment; this problem was not
really obvious, because `system('i3-msg', $cmd)` silently continued to
search for the `i3-msg` executable further in `$PATH` and launched the
real binary instead of the replacement script. The problematic shebang
needed to be replaced manually, because `patchShebangs` handles only
real shebangs on the first line of each executable file.
This is done with the following bash script:
```
#!/usr/bin/env bash
process_line() {
local filename=${1%:}
if [[ $4 =~ \"(.*)\"\; ]]; then
local sha256="${BASH_REMATCH[1]}"
fi
[[ -z $sha256 ]] && return 0
local hash=$(nix hash to-sri --type sha256 $sha256)
echo "Processing: $filename"
echo " $sha256 => $hash"
sed -i "s|cargoSha256 = \"$sha256\"|cargoHash = \"$hash\"|"
$filename
}
# split output by line
grep -r 'cargoSha256 = ' . | while IFS= read -r line; do
# split them further by space
read -r -a parts <<< "$line"
process_line "${parts[@]}"
done
```
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
