Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
On Sat, Feb 2, 2013 at 22:18:28 +, Thorsten Glaser wrote: Julien Cristau dixit: Once again, please stop filing m68k bugs at RC severity. I wrote into the bugreport that this *may* affect more than m68k due to the nature of the failure as much as I looked at it already, and that you’re of course still free to downgrade it if needed. That's not how it works. Unless you actually reproduce a FTBFS on a release arch (and without fiddling with options), don't file it as RC. Cheers, Julien signature.asc Description: Digital signature
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
Julien Cristau dixit: That's not how it works. Unless you actually reproduce a FTBFS on a release arch (and without fiddling with options), don't file it as RC. *sigh* Isn’t that something the maintainer can do? I know, you as RT member have even more work to do, but the amount of effort I put into Debian-Ports is absolutely not neglegible either. Also, I do not have any fast enough release architecture hardware to do so reasonably, and porterboxen require too much roundtrips for B-Ds. Maybe I should just not care about bugs in Debian and just mark the packages as Failed… not sure if that is what you (and others citing “debian-ports spam”) want… EOT //mirabilos -- „nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist eine Plattform für Einzelkämpfer“ -- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
On Sun, Feb 03, 2013 at 10:35:21PM +, Thorsten Glaser wrote: That's not how it works. Unless you actually reproduce a FTBFS on a release arch (and without fiddling with options), don't file it as RC. *sigh* Isn’t that something the maintainer can do? snappy has already built fine several times on release architectures. I have seen this on GNU/Hurd, but never on any Linux architecture before this report. I know, you as RT member have even more work to do, but the amount of effort I put into Debian-Ports is absolutely not neglegible either. Also, I do not have any fast enough release architecture hardware to do so reasonably, and porterboxen require too much roundtrips for B-Ds. FWIW, I will fix this bug -- like I said, there will be a new upload when the upstream release fixing this appears. But I will _not_ try to push this through to wheezy unless the RT says this is something that should be fixed. (We are already late in the freeze, as I understand it.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
On Sun, Feb 3, 2013 at 22:35:21 +, Thorsten Glaser wrote: Julien Cristau dixit: That's not how it works. Unless you actually reproduce a FTBFS on a release arch (and without fiddling with options), don't file it as RC. *sigh* Isn’t that something the maintainer can do? I'm not saying you ought to do that work, I'm saying if you don't do it you should not use RC severities. Cheers, Julien signature.asc Description: Digital signature
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
Julien Cristau dixit: I'm not saying you ought to do that work, I'm saying if you don't do it you should not use RC severities. Hm, okay. That is actually reasonable, sorry for over-reacting. So an RC severity is only to be used when proven to be RC. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
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.
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_UFlat/0 22000400590100 16.6MB/s html
BM_UFlat/1 207002850 2780100 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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
Control: severity -1 normal On Thu, Jan 31, 2013 at 10:37:54 +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) Once again, please stop filing m68k bugs at RC severity. Cheers, Julien signature.asc Description: Digital signature
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
Julien Cristau dixit: Once again, please stop filing m68k bugs at RC severity. I wrote into the bugreport that this *may* affect more than m68k due to the nature of the failure as much as I looked at it already, and that you’re of course still free to downgrade it if needed. If something is clearly m68k specific, or debian-ports specific, I’ll sure downgrade it myself. But I think I mentioned this in this bugreport explicitly enough, did I not? bye, //mirabilos -- „nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist eine Plattform für Einzelkämpfer“ -- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699419: snappy: FTBFS because it insists on doing benchmarks despite nocheck/nobench DEB_BUILD_OTPS
Source: snappy
Version: 1.0.5-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
despite “export DEB_BUILD_OPTIONS='nobench nocheck'” your
package insists on running benchmarks during the package
build and then fails due to a bug in the benchmark script
and/or GNU bash:
make[2]: Entering directory `/tmp/buildd/snappy-1.0.5'
Running microbenchmarks.
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_UFlat/0 22000400590100 16.6MB/s html
BM_UFlat/1 207002850 2780100 24.1MB/s urls
/bin/bash: line 5: 12339 Floating point exception${dir}$tst
FAIL: snappy_unittest
==
1 of 1 test failed
==
make[2]: *** [check-TESTS] Error 1
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!
Full build log attached. Keeping severity as-is because this
problem is not necessarily restricted to m68k (I assume this
happens on slowish machines or buildds doing more than one
build in parallel as well), but the release team is free to
lower to “important” or tag it as ignore.
-- System Information:
Debian Release: 7.0
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k
Kernel: Linux 3.2.0-4-atari
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh-static
I: Using pkgname logfile
I: Current time: Thu Jan 31 04:14:30 CET 2013
I: pbuilder-time-stamp: 1359602070
I: Obtaining the cached apt archive contents
I: Installing the build-deps
W: no hooks of type D found -- ignoring
- Attempting to satisfy build-dependencies
- Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: m68k
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (= 7), autotools-dev, dpkg-dev (= 1.16.1~)
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 12287 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on autotools-dev; however:
Package autotools-dev is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
autotools-dev{a}
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/73.0 kB of archives. After unpacking 186 kB will be used.
Writing extended state information...
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package autotools-dev.
(Reading database ... 12287 files and directories currently installed.)
Unpacking autotools-dev (from .../autotools-dev_20120608.1_all.deb) ...
Processing triggers for man-db ...
Setting up autotools-dev (20120608.1) ...
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Writing extended state information...
- Finished parsing the build-deps
Reading package lists...
Building dependency tree...
Reading state information...
Starting
Starting 2
Done
debhelper is already the newest version.
debian-ports-archive-keyring is already the newest version.
file-rc is already the newest version.
apt is already the newest version.
eatmydata is already the newest version.
fakeroot is already the newest version.
wtf-debian-keyring is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I: Copying back the cached apt archive contents
I: Copying source file
I: copying [/root/snappy_1.0.5-2.dsc]
I: copying [/root/snappy_1.0.5.orig.tar.gz]
I: copying [/root/snappy_1.0.5-2.diff.gz]
I: Extracting source
gpgv: keyblock resource `/tmp/buildd/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Mon Jul 2 18:56:38 2012 UTC using DSA key ID 52B7487E
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./snappy_1.0.5-2.dsc
dpkg-source: info: extracting snappy in snappy-1.0.5
dpkg-source: info:
