Your message dated Mon, 13 Jan 2025 19:34:08 -0800 with message-id <rbm3hqlfpxtfbzxstkkx6i7bn5hm3i5jcpipwhhqrsqzxzitdx@3d327nws5egr> and subject line Select blocking on some archs Fixed in 2.1.4-1 has caused the Debian Bug report #1082555, regarding sslh blocks when reading data in some systems to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1082555: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082555 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: src:sslh Version: 1.18-1 Severity: important Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -B" but it failed: -------------------------------------------------------------------------------- [...] debian/rules build-arch dh build-arch --with systemd dh_testdir -a dh_update_autotools_config -a dh_auto_configure -a debian/rules override_dh_auto_build make[1]: Entering directory '/<<PKGBUILDDIR>>' dh_auto_build -- USELIBWRAP=1 USELIBCAP=1 make -j1 USELIBWRAP=1 USELIBCAP=1 make[2]: Entering directory '/<<PKGBUILDDIR>>' ./genver.sh >version.h cc -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBWRAP -DENABLE_REGEX -DLIBCONFIG -DLIBCAP -c common.c common.c: In function 'bind_peer': common.c:183:49: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] [... snipped ...] cc -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o echosrv echosrv.o probe.o common.o tls.o -lwrap -lconfig -lcap make[2]: Leaving directory '/<<PKGBUILDDIR>>' make[1]: Leaving directory '/<<PKGBUILDDIR>>' dh_auto_test -a make -j1 test make[1]: Entering directory '/<<PKGBUILDDIR>>' ./t Deleting all .da files in . and subdirectories Done. Testing sslh-select spawned 22493 ./sslh-select -v -f -u buildd --listen localhost:9002 --ssh ::1:9000 --ssl ::1:9001 -P /tmp/sslh_test.pid ssh addr: localhost:9000. libwrap service: sshd log_level: 1 family 10 10 [] ssl addr: localhost:9001. libwrap service: (null) log_level: 1 family 10 10 [] listening on: localhost:9002 [] localhost:9002 [] timeout: 2 on-timeout: ssh listening to 2 addresses localhost:9002:bind: Address already in use ***Test: SSL connection Connection refused ***Test: Shy SSH connection Connection refused ***Test: Bold SSH connection Connection refused ***Test: incomplete SSH first frame Connection refused ***Test: One SSL half-started then one SSH Connection refused ***Test: One SSH half-started then one SSL Connection refused cat: /tmp/sslh_test.pid: No such file or directory killing Can't kill a non-numeric process ID at ./t line 221. # Looks like your test exited with 1 before it could output anything. Makefile:123: recipe for target 'test' failed make[1]: *** [test] Error 1 make[1]: Leaving directory '/<<PKGBUILDDIR>>' dh_auto_test: make -j1 test returned exit code 2 debian/rules:26: recipe for target 'build-arch' failed make: *** [build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 E: Build killed with signal TERM after 60 minutes of inactivity -------------------------------------------------------------------------------- This is just how the build ends, not necessarily the relevant part. I've put several build logs here: https://people.debian.org/~sanvila/build-logs/sslh/ When this happens, dpkg-buildpackage seems to die and "ps ax" shows processes like these: 9429 ? S 0:00 ./echosrv --listen ::1 9001 --prefix ssl: 9430 ? S 0:00 ./echosrv --listen ::1 9000 --prefix ssh: 9431 ? S 0:00 ./echosrv --listen ::1 9000 --prefix ssh: 9432 ? S 0:00 ./echosrv --listen ::1 9001 --prefix ssl: Then, after a while, sbuild finally decides to abort the build because of inactivity in the build log. The bug should be reproducible with sbuild on a single CPU virtual machine, provided you try enough times (as the failure happens randomly). Thanks.
--- End Message ---
--- Begin Message ---Version: 2.1.4-1 I'm pretty sure sslh fixed this in 2.1.2, but the most recent upload is 2.1.4-1. As evidence, the builds no longer fail, even on architectures with single CPU buildds. [The tests now have significantly more robustness to them and no longer block, so if the tests fail, they will no longer block a buildd slot.] -- Don Armstrong https://www.donarmstrong.com If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche
--- End Message ---
