On 2015-09-15 13:22, Arun Raghavan wrote: > On 15 September 2015 at 16:46, David Henningsson > <david.henningsson at canonical.com> wrote: >> >> On 2015-09-15 06:45, Arun Raghavan wrote: >>> >>> On 9 September 2015 at 15:19, Michael Cree <mcree at orcon.net.nz> 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
