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.
Now that shaderinclude is Python, I don't think we need Perl any more.
virtiofsd has been removed in favor of the standalone virtiofsd package.
Co-authored-by: Will Cohen <willcohen@users.noreply.github.com>
'./configure --cpu=$(uname -m)' (essentially) breaks the case of riscv,
where the configure script expects '--cpu=riscv', but 'uname -m' gives
'riscv{32,64}'. This eventually leads to user-mode emulation being
disabled.
Since the configure script can auto-detect the parameter based on
compilers, remove this flag.
Originally added in #147692, but apparently it's not needed and @NickCao
couldn't remember why it was added. See also mailing list discussion at
https://lore.kernel.org/qemu-devel/20230204112502.2558739-1-mjt@msgid.tls.msk.ru/T/
The python dependencies were fixed for cross in #147692, but the changes
are reversed #190560 due to concerns of accidentally mixing python
versions. Compromise by using python3Packages.python.
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
This patch fixes issues with error codes on Darwin host and Linux guest.
It has landed in QEMU master, so should be included in the next release.
Related to #108984.
qemu-utils was pulling qemu which is a 900MB dependency. By removing
reference to it (unneeded), we're saving space on our deployments.
qemu-utils is a dependency of cloud-utils
The guest agent now refuses to build unless being built for one of a
list of specific supported operating systems.
Co-authored-by: Will Cohen <willcohen@users.noreply.github.com>
There's no reason to have one copy of qemu-ga in $out and another in
$ga, and because we only applied remove-references-to to one of the
copies, it caused a collision when QEMU was used in a buildEnv.
This is redundant with QEMU commit a5804fcf7b ("9pfs: local: ignore
O_NOATIME if we don't have permissions"), included in QEMU since
5.1.0, which will retry opens without O_NOATIME if they fail with it.
According to the QEMU documentation, virtiofsd is supposed to be run
directly by users. It therefore makes sense to have it in bin/, so it
will be in PATH. Such a change wouldn't make sense upstream, because
it would then conflict with the virtiofsd package, which is generally
preferred if available. But in Nixpkgs, we don't have to worry about
that and can just make QEMU's virtiofsd a lower priority than the one
from the dedicated package.
[1]: https://qemu.readthedocs.io/en/latest/tools/virtiofsd.html
Fixes: https://github.com/NixOS/nixpkgs/issues/113172 ("QEmu: virtiofsd prone to be garbage collected.")
Fixes: https://github.com/NixOS/nixpkgs/pull/153007 ("nixos/libvirtd: add ${cfg.qemu.package}/libexec to PATH")
The qemu-ga binary is already moved to a separate
output but still depends on qemu, adding about
600MiB to it's closure.
The command "strings qemu-ga" reveals that something
like
/nix/store/bqgpvv5qrpb741swczqk3lrdm5gzaqx2-qemu-host-cpu-only-6.2.0/bin
is contained, causing this false positive. So use
remove-references-to to reduce the closure to about
600KiB.
these may not be reliable enough to enable by default, but enabling
them as a passthru may allow us to get a feel for which platforms
have trouble with them
QEMU now supports automatically detecting which audio drivers to
build, so we don't need to pass --audio-drv-list anymore.
pkgsMusl.qemu* doesn't build at the moment because of dependency
issues, but with a lot of hacks I was able to do enough of a build to
be confident the changes to patches etc. are correct for Musl.
