This is on x86 stable: ipacl-test: tests/ipacl-test.c:49: main: Assertion `r >= 0' failed. /bin/sh: line 5: 20032 Aborted ${dir}$tst FAIL: ipacl-test Will attach the full build log.
Created attachment 221525 [details] build.log
I can reproduce the error. ipacl-test tries to connect to port 22 on 127.0.0.1 and that will normally yield "connection refused" unless sshd is running. Starting the sshd deamon solves this particular failing assert on line 49 for me, but I still get a failed assert on line 89, so ipacl-test still fails.
I'll see to find a workaround for this.
I also get permission issues as another failure. Separate bug? PASS: proplist-test 1, Trying to acquire lock. 3, Trying to acquire lock. 2, Trying to acquire lock. 4, Trying to acquire lock. Home directory /var/tmp/portage/media-sound/pulseaudio-0.9.22/homedir not ours. Assertion 'pa_autospawn_lock_acquire(TRUE) > 0' failed at tests/lock-autospawn-test.c:39, function thread_func(). Aborting. /bin/sh: line 5: 1880 Aborted ${dir}$tst FAIL: lock-autospawn-test
Do you see this with 0.9.22?
Created attachment 277133 [details] build.log.gz (In reply to comment #5) > Do you see this with 0.9.22? Yes, attaching full log for reference.
(In reply to comment #5) > Do you see this with 0.9.22? Still here with 0.9.22-r2, over a year after the original report. Please consider disabling the test, this really slows down my arch testing.
Is still present in pulseaudio 1.1-r1
Try starting up sshd. This test needs to connect to something to set up a TCP socket, and it picks port 22.
That works fine as a workaround, but I'd be in favor of disabling the test or finding some alternative to it (or, at the very least, print a message for people with FEATURES="test" saying that you need an ssh server running)
This test was removed from the defaul test set upstream.
