NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.23k stars 14.22k forks source link

pipewire tests failing due to lack of ALSA plugin configuration #357004

Open benaryorg opened 1 day ago

benaryorg commented 1 day ago

Describe the bug

The nixos.tests.installed-tests.pipewire.x86_64-linux test currently fails on master. After some debugging I think the ALSA plugins are probably be missing.

way of reproducing the environment with strace Grab the *nixos-test-driver* (in my case `/nix/store/z0w2d8cqjgg8fkcwad40midd3qx7fh12-nixos-test-driver-pipewire-1.2.5/bin/nixos-test-driver`) and run it with `--interactive`, then use `machine.shell_interact()` for a shell, and wait for everything to be up. Then hit Enter once for a proper prompt and run this (with appropriate paths for *strace* and the *installed-tests* of course): ```bash mkdir -p /tmp/foo/installed-tests/pipewire && sed -E "s#Exec=#Exec=/nix/store/f7fx11v29srmyzqyyj3zwsmv8k4szfm7-strace-6.11/bin/strace -fftts 8192 #" /nix/store/5g49ip9d87gb7kybaf8860va0zyv3lwy-pipewire-1.2.5-installedTests/share/installed-tests/pipewire-0.3/pw-test-pipewire-alsa-stress.test > /tmp/foo/installed-tests/pipewire/foo.test && gnome-desktop-testing-runner -d /tmp/foo ``` For me this yields *Unknown PCM pipewire*, and looking at the *open()* calls also does not include anything that looks even vaguely like [the pipewire ALSA plugin configuration](https://github.com/NixOS/nixpkgs/blob/dcccac396c976154f2e4e6e149ff7b79fc6a54f3/nixos/modules/services/desktops/pipewire/pipewire.nix#L382-L396). Said configuration also does not seem to be linked into */etc* on the test VM either.

Steps To Reproduce

# with the referenced nixpkgs being current *master*
nix build --log-format multiline --no-link --print-out-paths --print-build-logs -v -f /path/to/nixpkgs pipewire.tests.installed-tests

You will see something like this before the stacktrace:

vm-test-run-pipewire> FAIL: pipewire-0.3/pw-test-pipewire-alsa-stress.test (Child process exited with code 1)
vm-test-run-pipewire> SUMMARY: total=22; passed=21; skipped=0; failed=1; user=3.9s; system=5.5s; maxrss=4700

Expected behavior

All tests pass.

This can either be solved by providing the ALSA plugin configuration, or by removing the test. Since people use those ALSA plugins I think it would be good to have them tested.

Metadata

Notify maintainers


Note for maintainers: Please tag this issue in your PR.


Add a :+1: reaction to issues you find important.

K900 commented 1 day ago

Known issue, the test really doesn't like running in a VM, and we currently don't have a good way to skip it, because the test runner doesn't provide one.

benaryorg commented 1 day ago

Known issue

Ah, sorry if I just opened a duplicate, I just haven't found any info on that (may not have used the right keywords).

we currently don't have a good way to skip it

Wouldn't it be pretty easy (and not too hacky IMHO) to rm the offending test in preInstallPhase or something?

Alternatively, providing the testConfig parameter in the test definition to set services.pipewire.alsa.enable = true might work (currently testing that).

benaryorg commented 1 day ago

Yeah, this here gets the plugins to load but then it still fails with audio open error: Host is down:

diff --git a/nixos/tests/installed-tests/pipewire.nix b/nixos/tests/installed-tests/pipewire.nix
index 6e69ada8612f..287d5ce86765 100644
--- a/nixos/tests/installed-tests/pipewire.nix
+++ b/nixos/tests/installed-tests/pipewire.nix
@@ -1,5 +1,14 @@
 { pkgs, makeInstalledTest, ... }:

-makeInstalledTest {
+makeInstalledTest rec {
   tested = pkgs.pipewire;
+  # required for the pipewire alsa plugins
+  testConfig = {
+    virtualisation.qemu.options = [ "-audio driver=none,model=virtio" ];
+    services.pipewire = {
+      enable = true;
+      package = tested;
+      alsa.enable = true;
+    };
+  };
 }

(note: given that it always uses the pkgs.pipewire for tested anyway I don't think that tests would've worked with override anyway, so the test always tests the default pipewire provided by nixpkgs I think, which makes the package definition woefully redundant)

Looking at aplay -l I can definitely see an audio device, which means something else is going wrong here, so at least this isn't a simple fix, explaining why it's a known issue. Just leaving this here so that someone in the future might use this to get the tests working, but I'm a bit lost here so it's probably not me who's gonna do that.