Bug#908540: redis: FTBFS randomly (failing tests)
tags 908540 + pending thanks Dear Santiago, > I've just noticed that the package FTBFS in experimental in > reproducible builds [..] > Would that be enough to consider that the problem is most probably not > fixed in experimental? Indeed. I'm really tired of playing whack-a-mole with the testsuite (4+ patches and counting at this point...) so until upstream get their act together I will simplify everything and run with "|| true" for now. (We were doing this already on mipsel, so this isn't too crazy...) Thanks; pending upload. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#908540: redis: FTBFS randomly (failing tests)
On Tue, Sep 11, 2018 at 08:54:49AM +0100, Chris Lamb wrote: > I would be curious to know whether you can reproduce there as > I am likely to merge that into unstable soon. I've just noticed that the package FTBFS in experimental in reproducible builds: https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/redis.html in four different architectures. Would that be enough to consider that the problem is most probably not fixed in experimental? Thanks.
Bug#908540: redis: FTBFS randomly (failing tests)
On Thu, Sep 13, 2018 at 08:39:09AM +0100, Chris Lamb wrote: > Chris Lamb wrote: > > > First, are you aware that the experimental packages are much more up- > > to-date? I would be curious to know whether you can reproduce there > > Gentle ping on this? Sorry, I don't have chroots for experimental in my autobuilders. If you can't reproduce the current failures in unstable, let's wait until the new packages are available in unstabale then. Thanks.
Bug#908540: redis: FTBFS randomly (failing tests)
Chris Lamb wrote: > First, are you aware that the experimental packages are much more up- > to-date? I would be curious to know whether you can reproduce there Gentle ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#908540: redis: FTBFS randomly (failing tests)
Hi Santiago, > Version: 5:4.0.11-2 First, are you aware that the experimental packages are much more up- to-date? I would be curious to know whether you can reproduce there as I am likely to merge that into unstable soon. > The failures happen randomly. Sometimes it fails, sometimes it does not. Indeed. I have also disabled further tests in experimental. However, upstream keep regrettably introducing non-deterministic tests; see the changelog for a bit of whack-a-mole over the years. > Note: I'm deliberately not using a severity here. Let's hope you see > this as a special case of non-reproducibility :-) Hah, but this has nothing to do with Reproducible Builds really… I would probably file this myself as RC but no real need for that here. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#908540: redis: FTBFS randomly (failing tests)
Package: src:redis
Version: 5:4.0.11-2
Tags: ftbfs
Hello Chris.
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh build-indep
dh_update_autotools_config -i
dh_autoreconf -i
dh_auto_configure -i
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build --parallel -- V=1
make -j1 "INSTALL=install --strip-program=true" V=1
make[2]: Entering directory '/<>'
cd src && make all
make[3]: Entering directory '/<>/src'
cc -std=c99 -pedantic -DREDIS_STATIC='' -Wall -W
-Wno-missing-field-initializers -O2 -g -ggdb -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -I../deps/hiredis -I../deps/linenoise
-I../deps/lua/src -DUSE_JEMALLOC -I/usr/include/jemalloc/include -Wdate-time
-D_FORTIFY_SOURCE=2 -MM *.c > Makefile.dep 2> /dev/null || true
rm -rf redis-server redis-sentinel redis-cli redis-benchmark redis-check-rdb
redis-check-aof *.o *.gcda *.gcno *.gcov redis.info lcov-html Makefile.dep
dict-benchmark
[... snipped ...]
"start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Current master
set start_time [clock seconds] ; # T..."
("uplevel" body line 2)
invoked from within
"uplevel 1 $code "
(procedure "start_server" line 3)
invoked from within
"start_server {} {
start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Current master
set start_time [clo..."
("uplevel" body line 2)
invoked from within
"uplevel 1 $code "
(procedure "start_server" line 3)
invoked from within
"start_server {tags {"psync2"}} {
start_server {} {
start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Curre..."
(file "tests/integration/psync2.tcl" line 1)
invoked from within
"source $path"
(procedure "execute_tests" line 4)
invoked from within
"execute_tests $data"
(procedure "test_client_main" line 10)
invoked from within
"test_client_main $::test_server_port "
Killing still running Redis server 27611
Killing still running Redis server 27619
Killing still running Redis server 27627
Killing still running Redis server 27805
Killing still running Redis server 27813
make[1]: *** [debian/rules:27: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit
status 2
That's just how the build ends and not necessarily the relevant part,
so I've put a bunch of failed build logs here:
https://people.debian.org/~sanvila/build-logs/redis/
The failures happen randomly. Sometimes it fails, sometimes it does not.
Some of above logs were build attempts on n1-standard-1 machines from GCE.
If you have access to such machines, that would be a good way to
trigger the failures. In either case, if you need help to reproduce
the randomness, please say so and I could give you access to a test
machine where this happens.
Note: I'm deliberately not using a severity here. Let's hope you see
this as a special case of non-reproducibility :-)
Thanks.
