On Thu, Jan 31, 2013 at 10:37:54AM +0100, Thorsten Glaser wrote:
> Source: snappy
> Version: 1.0.5-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
What platform is this? I've never changed the behavior here, so RC on the
grounds of regression (“built successfully in the past”) sounds a bit odd.
> make[2]: Entering directory `/tmp/buildd/snappy-1.0.5'
> Running microbenchmarks.
> Benchmark Time(ns) CPU(ns) Iterations
> ---------------------------------------------------
> BM_UFlat/0 22000400 5900000 100 16.6MB/s html
> BM_UFlat/1 207002850 27800000 100 24.1MB/s urls
> /bin/bash: line 5: 12339 Floating point exception${dir}$tst
FWIW, the only way I know this can happen is if your gettimeofday() has very
poor timing resolution. This bug has been fixed in the forthcoming Snappy
1.1.0; I can cherry-pick the patch in question if the release team feels this
is worthy of a freeze exception. It only affects the benchmark, not the
library itself.
This is the patch from upstream (which I wrote myself):
https://code.google.com/p/snappy/source/detail?r=65
debian-release, do you want to have a point fix for this? I'll be happy
either way.
> Do *not* run benchmarks on buildds! Especially not if nocheck
> is set! Even more especially not if nobench is set! Do not
> assume the buildd machine is otherwise idle, that is, your
> benchmark results will not be reliable even one minute later!
I must admit I never became comfortable with DEB_BUILD_OPTIONS, but I'll give
it a shot. For a variety of boring reasons, you can't run the Snappy unit
tests without also running the benchmarks; what do you suggest the priority
should be here if nocheck is set but not nobench?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
