Debian Bug report logs - #848063
ri-li: FTBFS randomly (Impossible d'initialiser SDL:Couldn't open X11 display)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@debian.org>

To: Debian BTS <submit@bugs.debian.org>

Subject: ri-li: FTBFS randomly (Impossible d'initialiser SDL:Couldn't open X11 display)

Date: Tue, 13 Dec 2016 17:08:02 +0000

Package: src:ri-li
Version: 2.0.1+ds-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:

--------------------------------------------------------------------------------
[...]
 debian/rules build-indep
I: ri-li_2.0.1+ds
dh build-indep --with autoreconf
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:5: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.in:5: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.in:13: installing './compile'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<<BUILDDIR>>/ri-li-2.0.1+ds'
I: ri-li_2.0.1+ds
dh_auto_configure -- \
	--datadir=/usr/share/games/ri-li \
	--bindir=/usr/games
	./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --datadir=/usr/share/games/ri-li --bindir=/usr/games
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... none
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for SDL_Init in -lSDL... yes
checking for Mix_OpenAudio in -lSDL_mixer... yes
checking for pthread_create in -lpthread... yes
checking for sqrt in -lm... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking SDL/SDL.h usability... yes
checking SDL/SDL.h presence... yes
checking for SDL/SDL.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking SDL/SDL_mixer.h usability... yes
checking SDL/SDL_mixer.h presence... yes
checking for SDL/SDL_mixer.h... yes
checking for sqrt... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating data/Makefile
config.status: creating Sounds/Makefile
config.status: creating gentoo/Makefile
config.status: creating config.h
config.status: executing depfiles commands
configure: WARNING: unrecognized options: --disable-maintainer-mode
make[1]: Leaving directory '/<<BUILDDIR>>/ri-li-2.0.1+ds'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<<BUILDDIR>>/ri-li-2.0.1+ds'
I: ri-li_2.0.1+ds
dh_auto_build -Ddata-src
	make -j1
make[2]: Entering directory '/<<BUILDDIR>>/ri-li-2.0.1+ds/data-src'
c++ -c -O3 -Wall -Wno-switch -Wno-deprecated -ffast-math -I/usr/X11R6/include -I/usr/include -DLINUX `sdl-config --cflags` -o sprite.o sprite.cc
sprite.cc: In member function 'bool Sprite::Load(char*, char*, int)':
sprite.cc:74:18: warning: variable 'VideoInfo' set but not used [-Wunused-but-set-variable]
   SDL_VideoInfo *VideoInfo;
                  ^~~~~~~~~
sprite.cc: In member function 'bool Sprite::LoadCaractaire(char*)':
sprite.cc:273:18: warning: variable 'VideoInfo' set but not used [-Wunused-but-set-variable]
   SDL_VideoInfo *VideoInfo;
                  ^~~~~~~~~
c++ -c -O3 -Wall -Wno-switch -Wno-deprecated -ffast-math -I/usr/X11R6/include -I/usr/include -DLINUX `sdl-config --cflags` -o main.o main.cc
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 };
 ^
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:91:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:96:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 };
 ^
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 };
 ^
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
main.cc:180:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
c++ -O3 -Wall -Wno-switch -Wno-deprecated -ffast-math -I/usr/X11R6/include -I/usr/include -DLINUX `sdl-config --cflags` main.o sprite.o -o MakeDat -L/usr/lib `sdl-config --libs` -lSDL_image -I./
make[2]: Leaving directory '/<<BUILDDIR>>/ri-li-2.0.1+ds/data-src'
cd data-src && xvfb-run --server-args="-screen 0 1024x768x24" ./MakeDat
Impossible d'initialiser SDL:Couldn't open X11 display
debian/rules:20: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 255
make[1]: Leaving directory '/<<BUILDDIR>>/ri-li-2.0.1+ds'
debian/rules:12: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
--------------------------------------------------------------------------------

It does not always fail, but it fails often enough that it also fails here:

https://buildd.debian.org/status/package.php?p=ri-li

If you need a full build log, just say so, but the failure rate
observed here is around 93%. I guess some build-dependency changed
behaviour since this package was uploaded for the last time 376 days ago.

Thanks.

Message #10 received at 848063-close@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 848063-close@bugs.debian.org

Subject: Bug#848063: fixed in ri-li 2.0.1+ds-4

Date: Tue, 13 Dec 2016 19:34:08 +0000

Source: ri-li
Source-Version: 2.0.1+ds-4

We believe that the bug you reported is fixed in the latest version of
ri-li, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 848063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Markus Koschany <apo@debian.org> (supplier of updated ri-li package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Tue, 13 Dec 2016 19:59:25 +0100
Source: ri-li
Binary: ri-li ri-li-data
Architecture: source
Version: 2.0.1+ds-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Markus Koschany <apo@debian.org>
Description:
 ri-li      - toy train simulation game
 ri-li-data - toy train simulation game - data files
Closes: 848063
Changes:
 ri-li (2.0.1+ds-4) unstable; urgency=medium
 .
   * Switch to compat level 10.
   * Declare compliance with Debian Policy 3.9.8.
   * Vcs-Git: Use https.
   * Run xvfb-run with the -a option and try to get a free DISPLAY server
     automatically. (Closes: #848063)
Checksums-Sha1:
 fb93bf9840e43fbc57909a4d2a8980c534b2711d 2263 ri-li_2.0.1+ds-4.dsc
 80643480a508b7849f93b37ea7a26acc46ce8f49 7740 ri-li_2.0.1+ds-4.debian.tar.xz
Checksums-Sha256:
 4061fd9427eb078cf1dedb5b17255ddb6bcbc6b0a011ad33a29933223d6bfb2d 2263 ri-li_2.0.1+ds-4.dsc
 d3be392d67a2cb28152252313dacf1b1ee984c130e5b4a4979b42c97cc69d8af 7740 ri-li_2.0.1+ds-4.debian.tar.xz
Files:
 9285011c3a97a797831eee9a2a708e22 2263 games optional ri-li_2.0.1+ds-4.dsc
 aae4cce9dfe9b8a045389ea6a41e7b24 7740 games optional ri-li_2.0.1+ds-4.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlhQRxBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
YW4ub3JnAAoJENmtFLlRO1HkD3YP/2NpFZDT77yLCzb6+AC1vOrQlypnqVFRGUDg
0UIo+oglh1cb3leSXDeAWcUHR6X+AauRbcZ2dV1xEbR+logUMkf9gRKZZ3wOfnhz
8ucRySo3sOvdXIsHgmQLnrMcPsq++eTDc0K7b13XPUrlFpzV2ecqVG00PSQ5HzIc
EdEZMm05gHInR5xgbhMgCzqFwO51Dbrt51z1ROnjLQv3DWY53nQ09zhQSoCDcoO3
El20H+WwNvNhbe0Fz2nW816NGiPv08eyOYCAclV31QiJ3WLpdGlO+b3ZXnyUFSAj
H+Jm/y/i0WuVXisNyHVzDXrl3ueJMRv0KfBHHwmJTkv/QWwhP7CQ7OGaho1bLD8S
p9VZkF4AMXO7jB8SUrN4RdbhPrVBA618PJNrhO7R23fGOZl8SGZOP1jL5hCbG5n/
K0oxvP1KsGMQeO9WnIDSlUGRe9t5VwYrLaBz+Ds7iZp7hzrst1J7b4quHGQ94FYL
1ByNywTDWOQhhVkWdQ9i6GoU8DmJ9QL4DfOVHJUsNIjNoKw2zsETtGj7aZtyhPSa
XMWwBtPUxcEWFDfVgggQmRg/W0F0zB2SxwIToswYMUWVrwDU1Pz8lXVXVtWz2gWq
lq2Cdq7IhBaLnmU++jWHG2WXkfVkhBtze00pPpao64C5hbr5K+U5eRkW1v6BsXzJ
AhkvaZhf
=L4pV
-----END PGP SIGNATURE-----

Message #15 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: fixed in ri-li 2.0.1+ds-4

Date: Sat, 24 Dec 2016 11:50:29 +0100 (CET)

[Message part 1 (text/plain, inline)]

found 848063 2.0.1+ds-4
thanks

Hello. Sorry for the reopening but this issue is still happening in
this version.

(Also, sorry for not noticing it before, I usually build packages in
testing because there are too many broken packages in unstable).

This time I only built it once, and it failed. Build log attached.

Thanks.

[ri-li_2.0.1+ds-4_amd64-20161224T061519Z.gz (application/gzip, attachment)]

Message #22 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Santiago Vila <sanvila@unex.es>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: fixed in ri-li 2.0.1+ds-4

Date: Sat, 24 Dec 2016 15:05:54 +0100

[Message part 1 (text/plain, inline)]

Control: severity -1 important

On 24.12.2016 11:50, Santiago Vila wrote:
> found 848063 2.0.1+ds-4
> thanks
> 
> Hello. Sorry for the reopening but this issue is still happening in
> this version.
> 
> (Also, sorry for not noticing it before, I usually build packages in
> testing because there are too many broken packages in unstable).
> 
> This time I only built it once, and it failed. Build log attached.

Thanks for working on the reproducible build project. However this is
not a release critical issue because the last version builds fine on all
release architectures. [1]

It would be useful to know in which way the reproducible builds
environments differs from the official buildd servers. Apparently the
build cannot open a display server but xvfb-run should ensure that they
are automatically found and used. So this is probably a regression in
xvfb-run or some kind of race condition because nothing has changed in
ri-li for a long time.

[1] https://buildd.debian.org/status/package.php?p=ri-li&suite=unstable

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: fixed in ri-li 2.0.1+ds-4

Date: Sat, 24 Dec 2016 18:33:44 +0100

On Sat, Dec 24, 2016 at 03:05:54PM +0100, Markus Koschany wrote:

> Thanks for working on the reproducible build project.

Please note that I'm not filing this bug in the name of
the reproducible builds project.

The build log I attached was created with sbuild in my own
autobuilder. Autobuilders in the reproducible builds project
use pbuilder.

> However this is
> not a release critical issue because the last version builds fine on all
> release architectures. [1]

Sorry, but the theory that a bug is "not RC if it didn't happen in
buildd.debian.org" may simply not be true.

We have already discussed about this in the past. As an example,
packages which rely on gnupg or tzdata being present during the build
must declare them in the build-depends. Failure to do so is RC even if
those packages are installed by default in the official buildds.

So please stop saying that a bug needs to happen in buildd.debian.org
to be RC. This example clearly invalidates such theory.

In this case, the failure happens in the reproducible builds
autobuilders:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ri-li.html

but also (randomly) in my own autobuilders, which are completely independent.

> It would be useful to know in which way the reproducible builds
> environments differs from the official buildd servers. Apparently the
> build cannot open a display server but xvfb-run should ensure that they
> are automatically found and used. So this is probably a regression in
> xvfb-run or some kind of race condition because nothing has changed in
> ri-li for a long time.

Yes, it would be indeed useful to know how my building environment
differs from yours. I was asked about this in another bug report so I
wrote this:

https://people.debian.org/~sanvila/my-building-environment.txt

Please try to use sbuild in a single-CPU virtual machine as I do.
Maybe then this package will FTBFS (randomly) for you as well.

Thanks.

Message #34 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: fixed in ri-li 2.0.1+ds-4

Date: Sat, 24 Dec 2016 19:24:19 +0100

I have now built the package 99 more times and this has been the result:

Tried 100 times. Failed 97 times.
Approximate failure rate: 97%.

I've put the 100 build logs here for you to see:

https://people.debian.org/~sanvila/ri-li/

The builds were made on different autobuilders.

The Release Managers are considering a threshold for FTBFS
which happen randomly. Where would you put the threshold
in your opinion? Do we need a failure rate of 98% to be RC,
so that this package is still under the threshold?

IMO, any such threshold over 10% would be too high.

Thanks.

Message #39 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 846116@bugs.debian.org, 680038@bugs.debian.org, 828929@bugs.debian.org, 834686@bugs.debian.org, 834962@bugs.debian.org, 842836@bugs.debian.org, 844083@bugs.debian.org, 844088@bugs.debian.org, 844571@bugs.debian.org, 845164@bugs.debian.org, 846021@bugs.debian.org, 846115@bugs.debian.org, 846300@bugs.debian.org, 846318@bugs.debian.org, 848054@bugs.debian.org, 848055@bugs.debian.org, 848403@bugs.debian.org, 849775@bugs.debian.org, 849217@bugs.debian.org, 832865@bugs.debian.org, 837067@bugs.debian.org, 848063@bugs.debian.org, 849363@bugs.debian.org, 846026@bugs.debian.org, 841904@bugs.debian.org, 847288@bugs.debian.org, 848859@bugs.debian.org, 841098@bugs.debian.org, 843038@bugs.debian.org, 848409@bugs.debian.org, 710696@bugs.debian.org

Date: Wed, 4 Jan 2017 02:03:49 +0100 (CET)

severity 846116 important
severity 680038 important
severity 828929 important
severity 834686 important
severity 834962 important
severity 842836 important
severity 844083 important
severity 844088 important
severity 844571 important
severity 845164 important
severity 846021 important
severity 846115 important
severity 846300 important
severity 846318 important
severity 848054 important
severity 848055 important
severity 848403 important
severity 849775 important
severity 849217 important
severity 832865 important
severity 837067 important
severity 848063 important
severity 849363 important
severity 846026 important
severity 841904 important
severity 847288 important
severity 848859 important
severity 841098 important
severity 843038 important
severity 848409 important
severity 710696 important
thanks

Hello.

I'm setting the severity of this bug to "important" not because
I don't think it is not RC (as Release Policy still says that
packages must autobuild *without* failure), but because the
Release Managers are considering to decide about RC-ness
of this kind of bugs based on the probability of failure.

We don't know what kind of threshold there will be for stretch, so I
strongly recommend that you act as if this bug was serious and RC,
especially if the failures happen very often on any kind of
autobuilder which is not misconfigured.

Thanks.

Message #44 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 848063@bugs.debian.org

Cc: Markus Koschany <apo@debian.org>

Subject: Re: ri-li: FTBFS randomly (Impossible d'initialiser SDL:Couldn't open X11 display)

Date: Tue, 17 Jan 2017 13:46:53 +0100 (CET)

Dear Debian Games Team:

I reported this based on my own autobuilders, which are different and
independent from the reproducible builds autobuilders.

It seems Markus somehow believed those to be the same, but they are not.

In either case, please take a look at the build history in
reproducible builds:

https://tests.reproducible-builds.org/debian/history/ri-li.html

It may be easily seen that things started to go wrong at some time
between 2016-12-06 and 2016-12-11 (not necessarily because of the
package itself, it could be because some of its build-depends).

Please also note that I'm using sbuild and reproducible builds
autobuilders use pbuilder, and also I can reproduce this on
several different machines, not just one.

Based on those simple facts, the likelihood of this being simultaneosly
a problem in both my own autobuilders and the reproducible builds
autobuilders is very low, and the likelihood of this being a real
problem in the package is very high, and this is why I still believe
that the serious severity is more than justified for this bug.

I'm not changing the severity, but please keep trying to reproduce
this. I've described my building environment here:

https://people.debian.org/~sanvila/my-building-environment.txt

but as a last resort I could offer access to a machine where this
happens (please contact me privately for details).

Thanks.

Message #49 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 848063@bugs.debian.org

Subject: Bug#848063: ri-li: FTBFS 99% of the time outside buildd.debian.org

Date: Fri, 17 Feb 2017 13:13:46 +0100 (CET)

On Sat, 24 Dec 2016, Markus Koschany wrote:

> Control: severity -1 important

Dear Debian Games Team:

Please provide an explanation for this downgrade, preferably one that
shows clearly where exactly the technical disagreement lies, as I'm
required to provide such a summary when appealing to the T.C.

We all know that bugs which happen in buildd.debian.org are RC, but
the opposite is not true. Bugs which do not happen in
buildd.debian.org are not automatically not RC, so please don't use
this as a rationale because it's a bogus one (A => B is not the same
as B => A).

Last time I tried to build this package (one month ago), I used nine
different autobuilders. I've put all the build logs here for everybody
to see:

https://people.debian.org/~sanvila/build-logs/ri-li/

Summary: Tried 200 times. Failed 198 times.

Please also do not forget that this also fails in the reproducible
builds autobuilders, which, I repeat, are different and independent
from my own autobuilders:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ri-li.html

Thanks.

Message #54 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Steve Cotton <steve@s.cotton.clara.co.uk>

To: Santiago Vila <sanvila@unex.es>, 848063@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Help requested: Packages which FTBFS randomly

Date: Sun, 19 Feb 2017 16:09:56 +0100

On Wed, Feb 15, 2017 at 06:26:51PM +0100, Santiago Vila wrote:
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
> 
> https://people.debian.org/~sanvila/my-building-environment.txt

Hi Santiago and everyone trying to debug these FTBFSes,

For ri-li, and hopefully many of the other bugs on the list, there's a much
simpler way to replicate the bug in developers' normal dev environments, using
the taskset command from package util-linux to run the build on CPU #0 only:

$ taskset --cpu-list 0 dpkg-buildpackage -A

For ri-li, the failure can be isolated from the build:
ri-li/data-src$ taskset --cpu-list 0 xvfb-run -a --server-args="-screen 0 1024x768x24" ./MakeDat
Impossible d'initialiser SDL:Couldn't open X11 display

Thanks,
Steve

Message #59 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <fabian@debian.org>

To: Steve Cotton <steve@s.cotton.clara.co.uk>, 848063@bugs.debian.org, Santiago Vila <sanvila@unex.es>

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#848063: Help requested: Packages which FTBFS randomly

Date: Sun, 19 Feb 2017 17:01:12 +0100

[Message part 1 (text/plain, inline)]

Am Sonntag, den 19.02.2017, 16:09 +0100 schrieb Steve Cotton:
> Impossible d'initialiser SDL:Couldn't open X11 display

Why does the package require an X11 display to build?

 - Fabian

[signature.asc (application/pgp-signature, inline)]

Message #64 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Steve Cotton <steve@s.cotton.clara.co.uk>

To: 848063@bugs.debian.org, control@bugs.debian.org

Cc: Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 18:18:16 +0100

[Message part 1 (text/plain, inline)]

package ri-li
tags 848063 +patch
thanks

On Sun, Feb 19, 2017 at 04:09:56PM +0100, Steve Cotton wrote:
> On Wed, Feb 15, 2017 at 06:26:51PM +0100, Santiago Vila wrote:
> > The following packages FTBFS for me randomly. First column is the bug
> > number, second column is the estimated probability of failure in my
> > build environment, which is described here:
> > 
> > https://people.debian.org/~sanvila/my-building-environment.txt
> 
> For ri-li, and hopefully many of the other bugs on the list, there's a much
> simpler way to replicate the bug in developers' normal dev environments, using
> the taskset command from package util-linux to run the build on CPU #0 only:
> 
> $ taskset --cpu-list 0 dpkg-buildpackage -A

Hi,

The attached patch solves this with taskset, although I haven't tried with a
real single-CPU'd buildd.

It's a one-liner at the start of a resource-generator tool that's only run
during the build, and isn't included in the actual packages.  There are no
calls to SDL_AddTimer, so I think there's no need for SDL_INIT_TIMER, and
removing it avoids some interaction between SDL, xvfb and only having one CPU.

-  if( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER|SDL_INIT_AUDIO|SDL_INIT_NOPARACHUTE) < 0 ) {
+  if( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO|SDL_INIT_NOPARACHUTE) < 0 ) {
     cerr <<"Impossible d'initialiser SDL:"<<SDL_GetError()<<endl;
     exit(-1);

BR,
Steve

[no-sdl-timers-for-makedat.patch (text/x-diff, attachment)]

Message #69 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Steve Cotton <steve@s.cotton.clara.co.uk>

Cc: 848063@bugs.debian.org, Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 19:00:41 +0100

[Message part 1 (text/plain, inline)]

Control: tags -1 pending

On 19.02.2017 18:18, Steve Cotton wrote:
> package ri-li
> tags 848063 +patch
> thanks
> 
[...]
> Hi,
> 
> The attached patch solves this with taskset, although I haven't tried with a
> real single-CPU'd buildd.
> 
> It's a one-liner at the start of a resource-generator tool that's only run
> during the build, and isn't included in the actual packages.  There are no
> calls to SDL_AddTimer, so I think there's no need for SDL_INIT_TIMER, and
> removing it avoids some interaction between SDL, xvfb and only having one CPU.
> 
> -  if( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER|SDL_INIT_AUDIO|SDL_INIT_NOPARACHUTE) < 0 ) {
> +  if( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO|SDL_INIT_NOPARACHUTE) < 0 ) {
>      cerr <<"Impossible d'initialiser SDL:"<<SDL_GetError()<<endl;
>      exit(-1);
> 

Thank you for the patch. I will apply this one today. Please note that
this is simply a workaround for a limitation of Santiago's build
environment. This kind of error won't occur for the vast majority of the
package's target audience.

The claim that the build fails 99% all the time is wrong. If you try to
argue with mathematics you must take _all possible outcomes_ into
account not only the outcomes for your sample set. Then it becomes
obvious that this issue is negligible and definitely not release critical.

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #76 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: Steve Cotton <steve@s.cotton.clara.co.uk>, 848063@bugs.debian.org

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 19:31:38 +0100

On Sun, Feb 19, 2017 at 07:00:41PM +0100, Markus Koschany wrote:

> Thank you for the patch. I will apply this one today. Please note that
> this is simply a workaround for a limitation of Santiago's build
> environment.

Absolutely not.

This is basic Computer Science: Everything that you can do with
several CPU may be done with a single CPU as well (even if it's slower).

So having a single CPU is never to be considered a "limitation" in the
build environment (except by you, of course).

> This kind of error won't occur for the vast majority of the
> package's target audience.

We don't have "target audiences" to consider here. Packages *must* build
from source when the build-dependencies are met.

Your package had an undeclared "Build-CPU: 2", the problem is that
we don't have a Build-CPU control field, and you want to make
multi-core to be build-essential, bypassing all the decision-making
procedures in Debian.

You should really stop doing that. Multi-core is not part of
build-essential, and the standard to build packages is defined by the
build-essential definition and the build-depends.

Whatever the official build daemon of the day has (a single CPU or several,
a slow or a fast CPU), is *not* to be considered build-essential.

Thanks.

Message #81 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Santiago Vila <sanvila@unex.es>, 848063@bugs.debian.org

Cc: Steve Cotton <steve@s.cotton.clara.co.uk>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 20:03:37 +0100

[Message part 1 (text/plain, inline)]

On 19.02.2017 19:31, Santiago Vila wrote:
> On Sun, Feb 19, 2017 at 07:00:41PM +0100, Markus Koschany wrote:
> 
>> Thank you for the patch. I will apply this one today. Please note that
>> this is simply a workaround for a limitation of Santiago's build
>> environment.
> 
> Absolutely not.
> 
> This is basic Computer Science: Everything that you can do with
> several CPU may be done with a single CPU as well (even if it's slower).
> 
> So having a single CPU is never to be considered a "limitation" in the
> build environment (except by you, of course).
> 
>> This kind of error won't occur for the vast majority of the
>> package's target audience.
> 
> We don't have "target audiences" to consider here. Packages *must* build
> from source when the build-dependencies are met.

Of course we have target audiences, that is if you actually interact
with those people and think outside of your technical box. It is also
not true that the package fails 99 % all the time, it's basic math
Santiago, all possible outcomes, not just the ones in your custom
limited build environment.

You constantly ignore different views and arguments and I am not the
only one who questions your approach and your aggressive behaviour,
claiming your are the only one who is right. There is no point in making
a virtual environment the benchmark for the whole archive. You don't
solve any real life issues but you are wasting countless hours of
developer time for pushing your agenda on other people. Send in patches
like Steve did for a change if you really think this is "critcal" but
stop telling people how serious this bug is when you don't know nothing
about the package and its users.

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #86 received at 848063-close@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 848063-close@bugs.debian.org

Subject: Bug#848063: fixed in ri-li 2.0.1+ds-5

Date: Sun, 19 Feb 2017 19:35:47 +0000

Source: ri-li
Source-Version: 2.0.1+ds-5

We believe that the bug you reported is fixed in the latest version of
ri-li, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 848063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Markus Koschany <apo@debian.org> (supplier of updated ri-li package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 19 Feb 2017 19:28:23 +0100
Source: ri-li
Binary: ri-li ri-li-data
Architecture: source
Version: 2.0.1+ds-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Markus Koschany <apo@debian.org>
Description:
 ri-li      - toy train simulation game
 ri-li-data - toy train simulation game - data files
Closes: 848063
Changes:
 ri-li (2.0.1+ds-5) unstable; urgency=medium
 .
   * Add no-sdl-timers-for-makedat.patch and work around a build environment
     limitation. Thanks to Steve Cotton for the patch. (Closes: #848063)
Checksums-Sha1:
 05e5f1160bddb31ad90770af5f87862839802023 2263 ri-li_2.0.1+ds-5.dsc
 5badebc927a08e20faa9ddaa35490132e8b7d00c 8240 ri-li_2.0.1+ds-5.debian.tar.xz
 3a144917b4386492ef469b10a2344e059f1b37d9 10157 ri-li_2.0.1+ds-5_amd64.buildinfo
Checksums-Sha256:
 b838cd6c5c47241cdf62407c0377189761c35100fe4523382434b548a92cb2ad 2263 ri-li_2.0.1+ds-5.dsc
 73f9a7bd312d8e6ed22b4b89e40edb48a250c97a24213aa96a7c024ecae71cc9 8240 ri-li_2.0.1+ds-5.debian.tar.xz
 808eb40b51941ccb0bc8c41b08337984ecbc8d9741e95e42400fb0e9e3a482d2 10157 ri-li_2.0.1+ds-5_amd64.buildinfo
Files:
 7d7b89246cdce32fb18839e3db20f977 2263 games optional ri-li_2.0.1+ds-5.dsc
 006509ff0f4c89a5950b16524f315c6f 8240 games optional ri-li_2.0.1+ds-5.debian.tar.xz
 7ba21f2f9b32fd766ff4b82d684e1af5 10157 games optional ri-li_2.0.1+ds-5_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlip7WJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
YW4ub3JnAAoJENmtFLlRO1Hkzd4P/iJw4uDMLJDIr0tFsMSelsRAa3L7xSXzLgyk
MpyQBg521VRSqAHTgRJbVEh8JWLW+D68yn99dx+Gk9zODV9K0585r3qDh2//sxQT
HAR9IkfO+/nH5XlekNpTsaM6uGpN7Y61EnN5eDtsmW4lto754w5c7tY/IJ540zDk
oNVodzVKHyusUVS59eTOYmZGWXCmQ2VANa0jcOUgZE0PaGbfltg37e3Oh6kephur
f+s4njfWIL9h78gsCfLRSnfzhN5T6pJY1Td9Q3krKI2AJWXDgiaEUvgVXrz720M9
u3HLC8dkCQndM+OBX8SZYGI7cUGtrX1aMJlC9f8dxtrPqGHMSLMM9zfGSu2/pNqj
OU3DOacH5lmK59qfw0smrXlIpgcIbPjYxDKuoJz24J2hiNolOlII0pBn4MJIrX7y
XWBdhdoVeyaG25ob9aQ6zNv1tyUp670JZNbth7KfgE/d733tDXODsM2hclafg+bc
1pMARnv99EUxeLYPOb75PY/VrsiENynHhfaDsrmQmGgqpM6x6x59hO04BfvtAdTR
z/0IlajbgwQe3hj90806BOXz9Lxho5VCDBNNoXUMbugohfbKwgT1bLzRz8JAw0/1
6tlJCljZoERTNJ2k8X8XRt0A5lCkN4kH5o4AjQX3ldiwYyJAWhwMk/eSdDj8uQHE
cFgftto9
=U3YS
-----END PGP SIGNATURE-----

Message #91 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 21:05:07 +0100

On Sun, Feb 19, 2017 at 08:03:37PM +0100, Markus Koschany wrote:

> You constantly ignore different views and arguments and I am not the
> only one who questions your approach and your aggressive behaviour,

Please stop the name-calling.

> [...]
> for pushing your agenda on other people. [...]

Sorry, but this is not "my" agenda, it's Release Policy and
Debian Policy: Packages *must* build from source provided the
build-dependencies are installed.

Even if I had not the technical skills to find a fix for this bug, I
explained clearly how to reproduce it, and I even offered a machine
for you to reproduce it.

Next time please be more collaborative and accept the offer before
gratuitously downgrading the bug. Even if it was me who reported the
bug and it was my machines where the failed builds happened, the build
failure was never my fault, it was a bug in the package.

Thanks.

Message #96 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Santiago Vila <sanvila@unex.es>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 21:28:32 +0100

[Message part 1 (text/plain, inline)]

On 19.02.2017 21:05, Santiago Vila wrote:
> On Sun, Feb 19, 2017 at 08:03:37PM +0100, Markus Koschany wrote:
> 
>> You constantly ignore different views and arguments and I am not the
>> only one who questions your approach and your aggressive behaviour,
> 
> Please stop the name-calling.

No, I won't stop stating the truth.

>> [...]
>> for pushing your agenda on other people. [...]
> 
> Sorry, but this is not "my" agenda, it's Release Policy and
> Debian Policy: Packages *must* build from source provided the
> build-dependencies are installed.

This is _your_ interpretation of Debian Policy and there are people who
disagree with it. Not every build failure is automatically release
critical because we can't support all setups in existence hence the
separation between release architectures and ports. The same goes for
every custom build environment. You are trying hard to push this agenda
on -devel but maybe you should also read when other people disagree with
your agenda or refute your 99 % build failure claim e.g. [1] [2]

> Even if I had not the technical skills to find a fix for this bug, I
> explained clearly how to reproduce it, and I even offered a machine
> for you to reproduce it.

You are expecting other people sharing your opinion and doing the work
for you. This is antisocial.

> Next time please be more collaborative and accept the offer before
> gratuitously downgrading the bug. Even if it was me who reported the
> bug and it was my machines where the failed builds happened, the build
> failure was never my fault, it was a bug in the package.

You don't know if the root cause was in the package. The package simply
tries to initialize SDL on the host system. This has always worked in
the past, so there is certainly the possibility that the bug is not in
ri-li which might be only _affected_ by it.


[1] https://lists.debian.org/debian-devel/2017/02/msg00345.html
[2] https://lists.debian.org/debian-devel/2017/02/msg00293.html

[signature.asc (application/pgp-signature, attachment)]

Message #101 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Steve Cotton <steve@s.cotton.clara.co.uk>

To: Santiago Vila <sanvila@unex.es>, 848063@bugs.debian.org, Markus Koschany <apo@debian.org>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Sun, 19 Feb 2017 21:38:12 +0100

Hi Markus and Santiago,

Sorry, but it's turned out that my patch either doesn't completely
avoid the bug, or doesn't avoid another bug which gives the same error
message.  The build has failed on arm64.

On Sun, Feb 19, 2017 at 09:05:07PM +0100, Santiago Vila wrote:
> Even if I had not the technical skills to find a fix for this bug, I
> explained clearly how to reproduce it, and I even offered a machine
> for you to reproduce it.

There's a difference between being able to reproduce a bug, and being
able to debug it.  Giving an entire VM setup and saying that that is
enough to reproduce it doesn't start to cut it down to the minimal
test case in which a developer could debug it.

It was only Jonathan Dowland's response to debian-devel, saying that
the main difference in your buildd was the single CPU, that made me
realise there was a simple way to reproduce it in a debugging
environment.  Or not, as the arm64 failure shows.

BR,
Steve

Message #106 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Steve Cotton <steve@s.cotton.clara.co.uk>

To: 848063@bugs.debian.org, Markus Koschany <apo@debian.org>

Cc: Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Mon, 20 Feb 2017 01:56:54 +0100

On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
> Sorry, but it's turned out that my patch either doesn't completely
> avoid the bug, or doesn't avoid another bug which gives the same error
> message.  The build has failed on arm64.

I've tried to reproduce this locally (on amd64, not arm64).  With my
patch, I can't replicate the failure. Santiago, please would you test
how it fares on your autobuilders?

Testing by removing my patch and trying to debug the root cause, I
haven't found the cause yet.  But I think it will need a complex patch
to either libsdl1.2 or xvfb, and I don't think this bug justifies any
complex patch during the freeze.

It seems that one of the XOpenDisplay calls in SDL's X11VideoInit fails.
Having a GCC breakpoint at the start of X11VideoInit, or running MakeDat
under strace, makes the bug unreproducible.  Adding a long sleep to the
last point in the ri-li package's code before SDL_Init doesn't help.
Running another SDL programe first in the same xvfb server doesn't
change anything, so it seems that the server can't be primed in advance.

Markus, I'm really sorry that what looked like a risk-free patch has
caused a failed rebuild.  Depending on the TC's ruling, does it sound
sensible to say that 2.0.1+ds-4 is in Stretch, and -5 doesn't affect -4?

Steve

Message #111 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Steve Cotton <steve@s.cotton.clara.co.uk>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Mon, 20 Feb 2017 02:17:22 +0100

[Message part 1 (text/plain, inline)]

On 20.02.2017 01:56, Steve Cotton wrote:
> On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
>> Sorry, but it's turned out that my patch either doesn't completely
>> avoid the bug, or doesn't avoid another bug which gives the same error
>> message.  The build has failed on arm64.
> 
> I've tried to reproduce this locally (on amd64, not arm64).  With my
> patch, I can't replicate the failure. Santiago, please would you test
> how it fares on your autobuilders?
> 
> Testing by removing my patch and trying to debug the root cause, I
> haven't found the cause yet.  But I think it will need a complex patch
> to either libsdl1.2 or xvfb, and I don't think this bug justifies any
> complex patch during the freeze.
> 
> It seems that one of the XOpenDisplay calls in SDL's X11VideoInit fails.
> Having a GCC breakpoint at the start of X11VideoInit, or running MakeDat
> under strace, makes the bug unreproducible.  Adding a long sleep to the
> last point in the ri-li package's code before SDL_Init doesn't help.
> Running another SDL programe first in the same xvfb server doesn't
> change anything, so it seems that the server can't be primed in advance.
> 
> Markus, I'm really sorry that what looked like a risk-free patch has
> caused a failed rebuild.  Depending on the TC's ruling, does it sound
> sensible to say that 2.0.1+ds-4 is in Stretch, and -5 doesn't affect -4?

Hi Steve,

no worries and thanks for providing a helping hand here. I've also tried
a couple of different options in the past hours. I think your initial
patch wasn't completely wrong and the underlying issue has something to
do how SDL initializes its subsystems but I have reverted it for now.

I have read about issues when using SDL in virtual machines but I have
found only one clue namely to manually link with -lX11 to avoid this
kind of error. I have tried this solution at least 20 times on
asachi.debian.org (arm64 porterbox) and couldn't reproduce the build
failure anymore.

I have uploaded another revision a few minutes ago. -5 and -6 don't
affect Stretch. I don't know about a TC ruling but since it is obvious
that the claim of "99 %" build failures is not true I stand by my
opinion that this is not release critical.

We could also stop building the data from source but this isn't
something I would call an improvement over the current situation.

Regards,

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #120 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Steve Cotton <steve@s.cotton.clara.co.uk>

Cc: 848063@bugs.debian.org, Markus Koschany <apo@debian.org>

Subject: Re: Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

Date: Mon, 20 Feb 2017 11:27:25 +0100

On Mon, Feb 20, 2017 at 01:56:54AM +0100, Steve Cotton wrote:
> On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
> > Sorry, but it's turned out that my patch either doesn't completely
> > avoid the bug, or doesn't avoid another bug which gives the same error
> > message.  The build has failed on arm64.
> 
> I've tried to reproduce this locally (on amd64, not arm64).  With my
> patch, I can't replicate the failure. Santiago, please would you test
> how it fares on your autobuilders?

Version -5 builds ok in my single-cpu autobuilders (tried 100 times),
but Markus has just uploaded version -6 which has a different fix.

I can't tell if the bug in -4 that made it to fail on single-cpu
systems and on reproducible builds autobuilders (which are not
single-cpu) was the same as the bug in -5 that made arm64 to fail.

I'll try version -6 anyway.

Thanks.

Message #125 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Steve Cotton <steve@s.cotton.clara.co.uk>

Cc: 848063@bugs.debian.org, Markus Koschany <apo@debian.org>

Subject: Re: Bug#848063: ri-li: FTBFS for unknown reasons

Date: Mon, 20 Feb 2017 12:29:26 +0100 (CET)

found 848063 2.0.1+ds-6
thanks

I tried to build this version 100 times, and it failed 94 times.
All build logs (both failed and successful) are available here:

https://people.debian.org/~sanvila/build-logs/ri-li/

This also fails in the reproducible builds autobuilders, which AFAIK
are not single-CPU:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ri-li.html

Thanks.

Message #132 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Santiago Vila <sanvila@unex.es>, Steve Cotton <steve@s.cotton.clara.co.uk>

Cc: 848063@bugs.debian.org

Subject: Re: Bug#848063: ri-li: FTBFS for unknown reasons

Date: Mon, 20 Feb 2017 22:05:52 +0100

[Message part 1 (text/plain, inline)]

I have uploaded another revision this time with both patches applied. I
don't think we are dealing with a single-cpu versus multi-cpu issue
because SDL 1.2 was developed during a time when the former was still
common and I'm quite sure, due to the popularity of the library, this
would have been detected much earlier.

[signature.asc (application/pgp-signature, attachment)]

Message #137 received at 848063@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Markus Koschany <apo@debian.org>

Cc: Steve Cotton <steve@s.cotton.clara.co.uk>, 848063@bugs.debian.org

Subject: Re: Bug#848063: ri-li: FTBFS for unknown reasons

Date: Mon, 20 Feb 2017 22:17:06 +0100

On Mon, Feb 20, 2017 at 10:05:52PM +0100, Markus Koschany wrote:
> I have uploaded another revision this time with both patches applied. I
> don't think we are dealing with a single-cpu versus multi-cpu issue
> because SDL 1.2 was developed during a time when the former was still
> common and I'm quite sure, due to the popularity of the library, this
> would have been detected much earlier.

Indeed. Holger has just confirmed that the reproducible builds
autobuilders are multi-core. If this were just a single-cpu / multi-cpu
issue, it would not fail to build in reproducible builds autobuilders.

Thanks.

Message #142 received at 848063-close@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 848063-close@bugs.debian.org

Subject: Bug#848063: fixed in ri-li 2.0.1+ds-7

Date: Mon, 20 Feb 2017 21:19:07 +0000

Source: ri-li
Source-Version: 2.0.1+ds-7

We believe that the bug you reported is fixed in the latest version of
ri-li, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 848063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Markus Koschany <apo@debian.org> (supplier of updated ri-li package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 20 Feb 2017 21:43:00 +0100
Source: ri-li
Binary: ri-li ri-li-data
Architecture: source
Version: 2.0.1+ds-7
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Markus Koschany <apo@debian.org>
Description:
 ri-li      - toy train simulation game
 ri-li-data - toy train simulation game - data files
Closes: 848063
Changes:
 ri-li (2.0.1+ds-7) unstable; urgency=medium
 .
   * Revert "Drop no-sdl-timers-for-makedat.patch again."
     (Closes: #848063)
Checksums-Sha1:
 26f40419460c3d17b681addc246dcc26063054ac 2263 ri-li_2.0.1+ds-7.dsc
 1efc05cc9ee9bf51da17674e40e13ab6f146b0cd 8636 ri-li_2.0.1+ds-7.debian.tar.xz
 4daddb5afac608a0bf46b810f61f7c94cb5c88d6 10157 ri-li_2.0.1+ds-7_amd64.buildinfo
Checksums-Sha256:
 6c0b1b2c518d46f4c3f761178459d8b98d27883f1aa19dc3bd1f1d7d95989b19 2263 ri-li_2.0.1+ds-7.dsc
 4039a3c57ae186ff985f4f7a53aa2c9578e003e41b5db25aac75300fc21d227d 8636 ri-li_2.0.1+ds-7.debian.tar.xz
 aee7c25937a02c4f4816c0306ad382977f4582d7616e31250095403d587ffe2a 10157 ri-li_2.0.1+ds-7_amd64.buildinfo
Files:
 e7f60851a486942b5f8545434a463fad 2263 games optional ri-li_2.0.1+ds-7.dsc
 1878f1861725f19e5d67438b301b79fa 8636 games optional ri-li_2.0.1+ds-7.debian.tar.xz
 4063a3098de47a8456dfb2c848e49cbc 10157 games optional ri-li_2.0.1+ds-7_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlirV/1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
YW4ub3JnAAoJENmtFLlRO1Hk91QP/RyDVutQQKOtHeunG1uIV4wcZqthrhve7nrF
mDXJ/2j3xqm2ADh2gxKVUQwX2c5qdxGpgW0UtlMqeA9A0pizezCdEHh2BPE0NQme
Vans82GeqURlRffoda8VaPVHWN0ka5ESRDewgYT7zm8xz7E6L25sE40JNCRBg+sM
B30mKZtGvankkdhYxTC+/34C6zCe4KPn6BP+C6kid9FwYRqwDUZGqqF9DB9OrPM1
Fh8J6lPA6es0njW7VlMJ2a4JjVt09CbX7SlXf6nnLAw07ovcS9Now0P6TGq7EX5j
YqFdJMTHIOZh5SoAAueyAuJjfa9zMaM/y29FDyem/CaQmdDUJkE8IMb9OqoI1kFC
yQy1w9DLn31RJ5yly/qMrVJTECVlyl5FFGoR2BdquCkPZexQROhQYmJlCZw68jWy
bqSXFVZkS5geFE4sLCrx1yEufD7LZ2FpmqThqwe5eXXOWrOvtGSvCGlGOYfI9uhc
3tCbXvtB2ZDAQv94QwbFnbw6QugJVzQaPZ7yFC6LWXuxh134ZbShOA/n1Y+YKs1m
aVTU+ofeLawFM8w4k4bAbFAxAcGjWVF25dZ2K0hPML0K3t8tjgCKwxYsiOd1PL2X
Z1bRTNSrUFweRIFzTTfn1PFx6ghubMS4492PX11G3pydCsD+DeaAgcPOiVskP4qc
CH1s7com
=pgR3
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.