#917497 libanyevent-termkey-perl: FTBFS with STDIN as a readable non-tty

#917497#5
Date:
2018-12-27 23:54:04 UTC
From:
To:
Dear maintainer:

I tried to build this package in buster but it failed:
--------------------------------------------------------------------------------
[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_auto_configure -i
	perl -I. Build.PL --installdirs vendor --config "optimize=-g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config "ld=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'AnyEvent-TermKey' version '0.02'
   dh_auto_build -i
	perl Build
Building AnyEvent-TermKey
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<<PKGBUILDDIR>>'
TERM=vt100 dh_auto_test
	perl Build test --verbose 1
t/00use.t ..........
1..1
ok 1 - use AnyEvent::TermKey;
ok
t/01passthrough.t ..
1..7
Failed 7/7 subtests
t/02on_key.t .......
1..6
ok 1 - $key->termkey after h
ok 2 - $key->type_is_unicode after h
ok 3 - $key->codepoint after h
ok 4 - $key->modifiers after h
ok 5 - $key->utf8 after h
ok 6 - $key->format after h
ok
t/03timeout.t ......
1..4
ok 1 - $key still not defined after 1/2 waittime
ok 2 - $key->type_is_keysym after Escape timeout
ok 3 - $key->keysym after Escape timeout
ok 4 - $key->modifiers after Escape timeout
ok
t/99pod.t .......... skipped: Test::Pod 1.00 required for testing POD

Test Summary Report
-------------------
t/01passthrough.t (Wstat: 11 Tests: 0 Failed: 0)
  Non-zero wait status: 11
  Parse errors: Bad plan.  You planned 7 tests but ran 0.
Files=5, Tests=11,  1 wallclock secs ( 0.07 usr  0.01 sys +  0.73 cusr  0.12 csys =  0.93 CPU)
Result: FAIL
Failed 1/5 test programs. 0/11 subtests failed.
dh_auto_test: perl Build test --verbose 1 returned exit code 255
make[1]: *** [debian/rules:7: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:4: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2
--------------------------------------------------------------------------------

The build was made in my autobuilder with "dpkg-buildpackage -A"
but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libanyevent-termkey-perl.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and affects,
so that this is still visible in the BTS web page for this package.

Thanks.

#917497#10
Date:
2018-12-29 02:28:25 UTC
From:
To:
Same in #917497.

Both tests fail during build and not during autopkgtests (locally and
on r-b/ci.debian.net).

After thinking a bit I tried:

#v+
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@
        dh $@

 override_dh_auto_test:
-       TERM=vt100 dh_auto_test
+       TERM=vt100 prove --blib --verbose t/*.t
#v-

(which happens during autopkgtest), and, tataa!, the tests also pass
during build.

So the question is why dh_auto_test fails.


For dh_auto_test we have:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/libterm-termkey-perl-0.16'
TERM=vt100 dh_auto_test
	perl Build test --verbose 1


Sticking `TERM=vt100 perl Build test --verbose 1' into debian/rules
also makes the test pass. -- Ok …


So why does dh_auto_test fail? What has changed here? perl?
debhelper? Something else?


From the debhelper changelog:

debhelper (11.5.4) unstable; urgency=medium

  [ Niels Thykier ]
  * Dh_Lib.pm: Reopen stdin to read from /dev/null in doit (and its sibling
    functions) to prevent issues when stdin is open in write-only mode
    (which is what nohup(1) does).  Thanks to Julian Gilbey for reporting
    the issue and providing a sample patch for it as well.
    (Closes: #913663)


Can this be related? (The failing test operate on \*STDIN.)
Cc'ing the debhelper bug and debhelper maintainers …


Cheers,
gregor