On 2015-09-15 13:22, Arun Raghavan wrote:
On 15 September 2015 at 16:46, David Henningsson
<[email protected]> wrote:
On 2015-09-15 06:45, Arun Raghavan wrote:
On 9 September 2015 at 15:19, Michael Cree <[email protected]> wrote:
Pulseaudio fails to build on the Alpha architecture due to a failure
in the volume-test of the test suite. I had reported this to the
Debian bug tracker [1] but the maintainer has asked that I forward the
patch to this mail list. The failure in volume-test occurs because it
is compiled with -ffast-math which implies -ffinite-math-only of which
the gcc manual states that it optimizes for floating-point arithmetic
with the assumption that arguments and results are not NaNs or
+/-infinity, and futher notes that it may result in incorrect output.
On the Alpha platform that is somewhat an understatement as the use of
non-finite floating-point arithmetic with -ffinite-math-only results in
a floating-point exception and the termination of the program.
The volume-test converts volumes into decibels (so a zero volume
becomes a negative infinity) and proceeds to add two volumes (in
decibels), thus does arithmetic with non-finite floating point numbers
despite being compiled with -ffast-math!
I attach a patch that protects against the arithmetic with non-finite
numbers for your consideration. With that patch the test-suite passes
on Alpha.
Cheers
Michael.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248
Thanks for the fix! I've pushed this out to our next branch (since
we're frozen for the 7.0 release, it'll only make it out in 8.0).
Hi Arun,
Thanks for picking it up, but I think this is a typical example of a bug fix
that should go in 7.0 even though we're frozen. Not merging it only leads to
more buggy 7.0 release, and more distro patching for downstreams.
Since this patch is for a test, and is rather trivial, I don't
particularly mind either way.
Ok, I've now pushed it to master too.
In general, though, I view each extra patch as a risk of regression
when we are frozen, and as they add up, you start to need to do
another RC, delaying the release. This is why I advocate a stricter
(and thus, imo shorter) freeze period.
Every bug-fix patch is also a chance to get a less buggy release. It's
all about the trade-off. For simple fixes like this one, the regression
risk is low and the chance to get a less buggy release high.
A stricter freeze period would prohibit us from making that judgement on
a patch-by-patch basis.
In general, I believe having a good quality release is more important
than having a timely release (but that is also a trade-off - we'll never
get to a 100% bug free program). Because if we let something buggy out,
then I'll just have to distro patch it instead, and so must other
distros, which means more work in total.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
