On 17-Sep-2015 11:55 am, "David Henningsson" <<a href="mailto:david.henningsson@canonical.com">david.henningsson@canonical.com</a>> wrote: > > > > On 2015-09-15 13:22, Arun Raghavan wrote: >> >> On 15 September 2015 at 16:46, David Henningsson >> <<a href="mailto:david.henningsson@canonical.com">david.henningsson@canonical.com</a>> wrote: >>> >>> >>> On 2015-09-15 06:45, Arun Raghavan wrote: >>>> >>>> >>>> On 9 September 2015 at 15:19, Michael Cree <<a href="mailto:mcree@orcon.net.nz">mcree@orcon.net.nz</a>> 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] <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798248</a> >>>> >>>> >>>> >>>> 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. Right now, IMO timeliness has been missing, and that's a matter of discipline and availability of our time all over the release process. You don't necessarily have only diatro patching as a recourse. We do point releases when we feel the need. -- Arun > > -- > David Henningsson, Canonical Ltd. > <a href="https://launchpad.net/~diwic">https://launchpad.net/~diwic</a>