While preparing this change, I read the git blame on all of the files I
touched. I saw a working lifetime of building this system which we use
every day and love dearly and keep maintained ourselves. I saw commits
from a 14 year range between 2003 to 2017!! I could not be more thankful
for Eelco's work on building large parts of the foundation of nixpkgs
that all of us rely on now.
However, the end date of that range of the files I looked at the blame
on was 2017. I did not see surviving code from any newer date than that.
Looking at the Git logs, Eelco has been working on other things, and
that's totally fine.
However, it means that our maintenance metadata is out of date on a lot
of packages, and *that*'s the reason I am submitting this change. There
are a lot of packages that don't have anyone with their name on them to
be pinged if they need attention, even if they have had recent activity
(although it is never clear if recent activity was just someone fixing
it because ZHF or because the package actually matters to them).
There are a lot of packages with storied history that maybe don't need
to be in the set anymore at all since they have not been touched in
years; or maybe they are simply finished.
Empty maintainer lists should be a sign that we need to figure out who
maintains it or potentially remove it if it has rotted, and allowing the
maintainer list to be empty if it is already not maintained is part of a
healthy repository ecology.
Either way, I would like to have the maintenance metadata not mislead
anyone into sending Eelco emails about packages he doesn't, in practice,
work on anymore. I have not removed his name from everything; there are
some things that he is the upstream for or has worked on more recently,
for instance, like Nix, which I have left alone.
Given that we were overriding qemu_test to enable this anyway,
enabling this by default saves Hydra a QEMU build.
There's also clear demand from users[1] for this feature, so our
alternatives are:
- Offer a qemu-canokey attribute. I don't want to do this, because I
don't think there's any reason to make Hydra build an extra QEMU.
- Enable it only for qemu_test. I don't want to do this, because it
will lead to users using qemu_test without understanding its
subtleties.
- Force users to build from source. I don't think there's any reason
to do this when it's unlikely to hurt anybody having it enabled by
default. There's no reason to single out canokey to be disabled by
default in spite of users' needs given that we enable so many other
optional QEMU features.
[1]: https://github.com/canokeys/canokey-qemu/issues/6
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
Makes sure that the qemu-utils build succeeds when qemu-utils is
about to be updated. It's a bit of an odd build perhaps, so it's
good to check that it still builds.
Benefits
- Reduce the derivation closure.
- This reduces rebuilds and makes derivations that use
qemu-utils less susceptible to build errors.
- Includes extra qemu tools that weren't included before.
- Removes fragile binary copying (old qemu-utils impl).
- Can't forget to copy somethat that a binary needs.
- Less custom packaging is better.
Cost
- Adds an 80 second build, but the time is offset by rebuilding
its dependents less.
- The output of qemu-utils goes from ~7 MB to ~40 MB, but it
provides more functionality.
qemu_kvm is a much smaller build, so it's nicer if you're building
qemu-utils specifically. None of the tools depend on the emulation
targets disabled in qemu_kvm.
The tools are copied, not linked, so we don't have to worry about
potentially depending on both qemu_kvm and qemu in a bigger
derivation, and qemu_kvm is already built by Hydra, so there's no
increase in Hydra workload by using the variant.
This makes qemu_kvm.tests do the right thing — building qemu_kvm with
tests enabled. Previously, it would always build qemu, so all targets
would be enabled, even if accessed through qemu_kvm.tests.
I've been having trouble with some qemu builds since the v8.0.0 bump
failing with:
```
kernel-doc 'perl /build/qemu/docs/../scripts/kernel-doc -rst -enable-lineno -sphinx-version 5.3.0 -Werror /build/qemu/docs/../include/qemu/bitops.h' processing failed with: [Errno 2] No such file or directory: 'perl'
```
... this happens despite `perl` being part of `stdenv`. Adding
`perl` to `nativeBuildInputs` doesn't seem to fix it. It is handy
to be able to simply skip the docs in situations like this in order
to maintain forward progress, so this commit adds `enableDocs?true`
to allow that.
