Bug#982740: pulseaudio: FTBFS on ppc64el
On Fri, 26 Feb 2021 03:21:36 +0200
Faidon Liambotis wrote:
[...]
>
> pa_cpu_init_orc() returns true only if cpu_info.cpu_type ==
> PA_CPU_X86. This should not be the case here, but cpu_info is being
> passed to the function uninitialized, and... as luck would have it,
> cpu_info.cpu_type's "random" contents are set to PA_CPU_X86.
>
> So at minimum, the test is broken; initializing cpu_info as is done on
> other tests is enough to fix this:
>
> --- pulseaudio-14.2.orig/src/tests/cpu-volume-test.c
> +++ pulseaudio-14.2/src/tests/cpu-volume-test.c
> @@ -187,7 +187,7 @@ END_TEST
>
> START_TEST (svolume_orc_test) {
> pa_do_volume_func_t orig_func, orc_func;
> -pa_cpu_info cpu_info;
> +pa_cpu_info cpu_info = { PA_CPU_UNDEFINED, {}, false };
> int i, j;
>
> #if defined (__i386__) || defined (__amd64__)
>
> I've tested this fix on plummer, and it seems to work as expected.
Thank you! Your explanation and patch looks correct, this is most
certainly the correct fix.
Processed: Re: Bug#982740: pulseaudio: FTBFS on ppc64el
Processing commands for cont...@bugs.debian.org: > forwarded 982740 > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/511 Bug #982740 [pulseaudio] pulseaudio: FTBFS on ppc64el Set Bug forwarded-to-address to 'https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/511'. > End of message, stopping processing here. Please contact me if you need assistance. -- 982740: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#982740: pulseaudio: FTBFS on ppc64el
Processing control commands: > tags -1 patch Bug #982740 [pulseaudio] pulseaudio: FTBFS on ppc64el Added tag(s) patch. -- 982740: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982740: pulseaudio: FTBFS on ppc64el
Control: tags -1 patch
On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> which should arguably be a higher severity, but let's focus on getting
> 14.2-1 built properly.
>
> https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
>
> Here's where the ppc64el build fails:
>
>
> FAIL: cpu-volume-test
> =
>
> Running suite(s): CPU
> 0%: Checks: 1, Failures: 1, Errors: 0
> tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> FAIL cpu-volume-test (exit status: 1)
The output of the check (src/cpu-volume-test) is:
Running suite(s): CPU
Initialising ORC optimized volume functions.
Checking Orc svolume
Correctness test failed: align=1, channels=2
1: 3303 != d317 (a1ed * 7a36)
0%: Checks: 1, Failures: 1, Errors: 0
tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
Looking at the code of the test, that seems... not the intention:
pa_cpu_info cpu_info;
[...]
#if defined (__i386__) || defined (__amd64__)
pa_zero(cpu_info);
cpu_info.cpu_type = PA_CPU_X86;
pa_cpu_get_x86_flags(_info.flags.x86);
#endif
[...]
if (!pa_cpu_init_orc(cpu_info)) {
pa_log_info("Orc not supported. Skipping");
return;
}
[...]
pa_log_debug("Checking Orc svolume");
pa_cpu_init_orc() returns true only if cpu_info.cpu_type == PA_CPU_X86.
This should not be the case here, but cpu_info is being passed to the
function uninitialized, and... as luck would have it,
cpu_info.cpu_type's "random" contents are set to PA_CPU_X86.
So at minimum, the test is broken; initializing cpu_info as is done on
other tests is enough to fix this:
--- pulseaudio-14.2.orig/src/tests/cpu-volume-test.c
+++ pulseaudio-14.2/src/tests/cpu-volume-test.c
@@ -187,7 +187,7 @@ END_TEST
START_TEST (svolume_orc_test) {
pa_do_volume_func_t orig_func, orc_func;
-pa_cpu_info cpu_info;
+pa_cpu_info cpu_info = { PA_CPU_UNDEFINED, {}, false };
int i, j;
#if defined (__i386__) || defined (__amd64__)
I've tested this fix on plummer, and it seems to work as expected.
src/pulsecore/cpu.c has the only other invocation of pa_cpu_init_orc(),
and this seems to be initializing cpu_info properly, so this failure is
limited to the test suite and does not affect any runtime operation.
(This of course does not explain why the Orc code is broken on ppc64el.
It does not look to have been written with anything but i386/amd64 in
mind and the codepath is not meant to be running anywhere else, so
that's probably more in the "feature request" category.)
HTH!
Faidon
Bug#982740: pulseaudio: FTBFS on ppc64el
On Sun, 14 Feb 2021 19:27:03 +0200 Adrian Bunk wrote: > > > > FAIL: cpu-volume-test > > = > > > > Running suite(s): CPU > > 0%: Checks: 1, Failures: 1, Errors: 0 > > tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed > > FAIL cpu-volume-test (exit status: 1) > > > > > > > > It's worth noting that 14.1-1 built just fine on ppc64el, and the > > only non-debian change between 14.1 and 14.2 is this: > >... > > Both versions fail for me the same way on plummer. > > Adding debian-powerpc so that a porter can check. > > cu > Adrian Thanks for verifying. Building (either version) with an older version of the 'check' package would be the next step, so we can narrow down what's breaking it.
Processed: Re: Bug#982740: pulseaudio: FTBFS on ppc64el
Processing control commands: > found -1 14.1-1 Bug #982740 [pulseaudio] pulseaudio: FTBFS on ppc64el Marked as found in versions pulseaudio/14.1-1. -- 982740: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982740: pulseaudio: FTBFS on ppc64el
Control: found -1 14.1-1 On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote: > Package: pulseaudio > Version: 14.2-1 > Severity: serious > > Pulseaudio is failing to build on ppc64el. The version of pulseaudio in > bullseye suffers from a pretty serious usability bug (see #980836) > which should arguably be a higher severity, but let's focus on getting > 14.2-1 built properly. > > https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el > > Here's where the ppc64el build fails: > > > FAIL: cpu-volume-test > = > > Running suite(s): CPU > 0%: Checks: 1, Failures: 1, Errors: 0 > tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed > FAIL cpu-volume-test (exit status: 1) > > > > It's worth noting that 14.1-1 built just fine on ppc64el, and the only > non-debian change between 14.1 and 14.2 is this: >... Both versions fail for me the same way on plummer. Adding debian-powerpc so that a porter can check. cu Adrian
Bug#982740: pulseaudio: FTBFS on ppc64el
Package: pulseaudio
Version: 14.2-1
Severity: serious
Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
bullseye suffers from a pretty serious usability bug (see #980836)
which should arguably be a higher severity, but let's focus on getting
14.2-1 built properly.
https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
Here's where the ppc64el build fails:
FAIL: cpu-volume-test
=
Running suite(s): CPU
0%: Checks: 1, Failures: 1, Errors: 0
tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
FAIL cpu-volume-test (exit status: 1)
It's worth noting that 14.1-1 built just fine on ppc64el, and the only
non-debian change between 14.1 and 14.2 is this:
dilinger@e7470:/home/dev/pulseaudio$ git diff v14.1..v14.2
diff --git a/NEWS b/NEWS
index 308eedb17..72dd76fda 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+PulseAudio 14.2
+
+A bug fix release.
+
+ * Fix port switching when unplugging headphones
+
+Contributors
+
+ Tanu Kaskinen
+
+
PulseAudio 14.1
A bug fix release.
diff --git a/src/modules/module-switch-on-port-available.c
b/src/modules/module-switch-on-port-available.c
index f450004ca..99d61a4b8 100644
--- a/src/modules/module-switch-on-port-available.c
+++ b/src/modules/module-switch-on-port-available.c
@@ -278,8 +278,10 @@ static void switch_from_port(pa_device_port *port, struct
port_pointers pp) {
* profile is still available in the
* PA_CORE_HOOK_CARD_PROFILE_AVAILABLE_CHANGED callback, as at this point
* the profile availability hasn't been updated yet. */
-if (best_port)
-switch_to_port(best_port, pp);
+if (best_port) {
+struct port_pointers best_pp = find_port_pointers(best_port);
+switch_to_port(best_port, best_pp);
+}
}
It doesn't appear to be a temporary thing, as there were multiple
build attempts that all fail in the same spot.
It's likely something that changed in the build environment. For
example, there were some major changes with the check package
between the version that PA 14.1-1 built with (check 0.12.0-0.2)
and the version that PA 14.2-1 built with (check 0.15.2-2). And in
particular, #961781 looks very suspect as a difference in
precision between ppc64el and other architectures, but we also don't
appear to be using long doubles in that specific liborc test. So
¯\_(ツ)_/¯
The version of liborc didn't change between the two builds. There
was only 5 days between the successful and failed builds, so it's
pretty easy to see which packages changed. The check package
seems the most suspect, so it might be worth someone getting on a
ppc64el porter box and trying to build PA 14.2-1 with the older
version of the check package.
