Bug#1040530: libzmq-ffi-perl: FTBFS with Perl 5.38: when is deprecated
Source: libzmq-ffi-perl Version: 1.18-2 Severity: important Tags: ftbfs trixie sid upstream Forwarded: https://github.com/zeromq/perlzmq/issues/51 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build with Perl 5.38 (currently in experimental). make -j4 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 345. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 386. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 399. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 412. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 446. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 459. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 471. when is deprecated at /<>/blib/lib/ZMQ/FFI/ZMQ4_1/Socket.pm line 483. # Failed test 'no (unexpected) warnings (via done_testing)' # at t/close.t line 31. # Looks like you failed 1 test of 2. t/close.t .. # Subtest: close with unsent messages ok 1 - implicit Socket close done correctly (ctx destruction does not hang) 1..1 ok 1 - close with unsent messages not ok 2 - no (unexpected) warnings (via done_testing) 1..2 Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests [...] --- t/close.t(Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/closed_socket.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 1 Non-zero exit status: 1 t/curve_keypair.t (Wstat: 256 (exited 1) Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 t/device.t (Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/errors.t (Wstat: 256 (exited 1) Tests: 8 Failed: 1) Failed test: 8 Non-zero exit status: 1 t/fd.t (Wstat: 256 (exited 1) Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 t/fork-01.t (Wstat: 256 (exited 1) Tests: 6 Failed: 1) Failed test: 6 Non-zero exit status: 1 t/fork-02.t (Wstat: 256 (exited 1) Tests: 6 Failed: 1) Failed test: 6 Non-zero exit status: 1 t/gc.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/linger.t (Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/monitor.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/multipart.t(Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/options.t (Wstat: 256 (exited 1) Tests: 8 Failed: 1) Failed test: 8 Non-zero exit status: 1 t/proxy.t(Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/pubsub.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/router-req.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/send_recv.t(Wstat: 256 (exited 1) Tests: 5 Failed: 1) Failed test: 5 Non-zero exit status: 1 t/threads.t (Wstat: 256 (exited 1) Tests: 31 Failed: 1) Failed test: 31 Non-zero exit status: 1 t/unbind.t (Wstat: 256 (exited 1) Tests: 5 Failed: 1) Failed test: 5 Non-zero exit status: 1 t/unicode.t (Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/z85_encoding.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=21, Tests=105, 6 wallclock secs ( 0.07 usr 0.03 sys + 4.20 cusr 0.82 csys = 5.12 CPU) Result: FAIL Failed 21/21 test programs. 21/105 subtests failed. make[1]: *** [Makefile:979: test_dynamic] Error 1 Full build log at http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libzmq-ffi-perl_1.18-2/libzmq-ffi-perl_1.18-2_amd64-2023-07-06T13:54:28Z.build -- Niko Tyni nt...@debian.org
Bug#1040491: libhtml-mason-perl: FTBFS with Perl 5.38: t/13-errors.t failure
Source: libhtml-mason-perl Version: 1:1.59-2 Severity: important Tags: ftbfs sid trixie fixed-upstream Forwarded: https://github.com/houseabsolute/HTML-Mason/issues/33 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build with Perl 5.38 (currently in experimental). # Running top_level_compilation_error (#20): Make sure top-level compiler errors work in output mode # Got ... # - # Error during compilation of /<>/mason_tests/3797995/comps/errors/top_level_compilation_error: # syntax error at /<>/mason_tests/3797995/comps/errors/top_level_compilation_error line 2, near ";" # Execution of /<>/mason_tests/3797995/comps/errors/top_level_compilation_error aborted due to compilation errors. # # Stack: # [/<>/mason_tests/3797995/comps/errors/top_level_compilation_error:2] # [/<>/blib/lib/HTML/Mason/Interp.pm:817] # [/<>/blib/lib/HTML/Mason/Interp.pm:445] # [/<>/blib/lib/HTML/Mason/Request.pm:250] # [/<>/blib/lib/HTML/Mason/Request.pm:212] # [/usr/share/perl5/Class/Container.pm:275] # [/usr/share/perl5/Class/Container.pm:353] # [/<>/blib/lib/HTML/Mason/Interp.pm:348] # [/<>/blib/lib/HTML/Mason/Interp.pm:342] # [/<>/blib/lib/HTML/Mason/Tests.pm:528] # [/<>/blib/lib/HTML/Mason/Tests.pm:515] # [/<>/blib/lib/HTML/Mason/Tests.pm:456] # [/<>/blib/lib/HTML/Mason/Tests.pm:263] # [t/13-errors.t:12] # # # Stack: # [/<>/blib/lib/HTML/Mason/Interp.pm:450] # [/<>/blib/lib/HTML/Mason/Request.pm:250] # [/<>/blib/lib/HTML/Mason/Request.pm:212] # [/usr/share/perl5/Class/Container.pm:275] # [/usr/share/perl5/Class/Container.pm:353] # [/<>/blib/lib/HTML/Mason/Interp.pm:348] # [/<>/blib/lib/HTML/Mason/Interp.pm:342] # [/<>/blib/lib/HTML/Mason/Tests.pm:528] # [/<>/blib/lib/HTML/Mason/Tests.pm:515] # [/<>/blib/lib/HTML/Mason/Tests.pm:456] # [/<>/blib/lib/HTML/Mason/Tests.pm:263] # [t/13-errors.t:12] # # - #... but expected ... # - # (?^s:Error during compilation((?!Stack:).)*Stack:((?!Stack:).)*$) # - # Failed test 'top_level_compilation_error' # at /<>/blib/lib/HTML/Mason/Tests.pm line 593. # Running component_error_handler_false (#21): Test error-handling with component_error_handler set to false # Running component_error_Handler_no_upgrade (#22): Test that errors do not become object with component_error_handler set to false # Running component_error_handler_false_fatal_mode (#23): Test error-handling with component_error_handler set to false and error_mode set to fatal # Running component_error_handler_uc_message (#24): Test error-handling with component_error_handler set to a subroutine that upper-cases all text # Running use_bad_module (#25): Use a module with an error # Running require_bad_module_in_once (#26): Require a module with an error in a once block # Looks like you failed 1 test of 26. t/13-errors.t . [...] Test Summary Report --- t/13-errors.t (Wstat: 256 (exited 1) Tests: 26 Failed: 1) Failed test: 20 Non-zero exit status: 1 Files=36, Tests=543, 36 wallclock secs ( 0.13 usr 0.08 sys + 5.50 cusr 1.04 csys = 6.75 CPU) Result: FAIL Failed 1/36 test programs. 1/543 subtests failed. make[1]: *** [Makefile:1017: test_dynamic] Error 255 Looks like it's fixed upstream in 1.60: 1.60 2023-02-11 - Fixed a test failure with Perl blead (5.37.x). Reported by Jim Keenan and diagnosed by Yves Orton. GH #33. -- Niko Tyni nt...@debian.org
Bug#1040396: libapache-db-perl: FTBFS with Perl 5.38: hidden symbol `Perl_init_debugger' isn't defined
Source: libapache-db-perl Version: 0.18-2 Severity: important Tags: ftbfs trixie sid Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148727 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental): x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib -fstack-protector-strong DB.o -o blib/arch/auto/Apache/DB/DB.so \ \ /usr/bin/ld: DB.o: in function `my_init_debugger': ././DB.xs:12: undefined reference to `Perl_init_debugger' /usr/bin/ld: blib/arch/auto/Apache/DB/DB.so: hidden symbol `Perl_init_debugger' isn't defined /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status Full build log at http://perl.debian.net/rebuild-logs/perl-5.38/libapache-db-perl_0.18-2/libapache-db-perl_0.18-2+b1_amd64-2023-06-28T20:12:55Z.build -- Niko Tyni nt...@debian.org
Bug#1040388: libsdl-perl: FTBFS with Perl 5.38: undefined symbol: sv_nv
Source: libsdl-perl Version: 2.548-3 Severity: important Tags: ftbfs trixie sid Forwarded: https://github.com/PerlGameDev/SDL/issues/303 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental): # Failed test 'use SDLx::App;' # at t/00-load.t line 88. # Tried to use 'SDLx::App'. # Error: Can't load '/<>/blib/arch/auto/SDLx/Controller/Interface/Interface.so' for module SDLx::Controller::Interface: /<>/blib/arch/auto/SDLx/Controller/Interface/Interface.so: undefined symbol: sv_nv at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 201. # � at /<>/blib/lib/SDLx/Controller.pm line 10. # Compilation failed in require at /<>/blib/lib/SDLx/Controller.pm line 10. # BEGIN failed--compilation aborted at /<>/blib/lib/SDLx/Controller.pm line 10. # Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl-base/base.pm line 135. #...propagated at /usr/lib/x86_64-linux-gnu/perl-base/base.pm line 157. # BEGIN failed--compilation aborted at /<>/blib/lib/SDLx/App.pm line 23. # Compilation failed in require at t/00-load.t line 88. # BEGIN failed--compilation aborted at t/00-load.t line 88. Bailout called. Further testing stopped: Test failed. BAIL OUT!. In the upstream ticket Jitka Plesníková says using SvNVX instead of sv_nv works for them. Full build log at http://perl.debian.net/rebuild-logs/perl-5.38/libsdl-perl_2.548-3/libsdl-perl_2.548-3+b2_amd64-2023-06-29T01:50:30Z.build -- Niko Tyni nt...@debian.org
Bug#1040387: libb-perlreq-perl: FTBFS with Perl 5.38: t/01-B-PerlReq.t failure
Source: libb-perlreq-perl Version: 0.82-7 Severity: important Tags: ftbfs trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental): # Failed test at t/01-B-PerlReq.t line 93. # got: 'perl(Try/Tiny.pm) # perl(Bar.pm)' # expected: 'perl(Try/Tiny.pm) # perl(Foo.pm) # perl(Bar.pm)' # Failed test at t/01-B-PerlReq.t line 94. # got: 'perl(Try/Tiny.pm) # perl(Bar.pm)' # expected: 'perl(Try/Tiny.pm) # perl(Foo.pm) # perl(Bar.pm)' # Failed test at t/01-B-PerlReq.t line 95. # got: 'perl(Try/Tiny.pm) # perl(Baz.pm)' # expected: 'perl(Try/Tiny.pm) # perl(Foo.pm) # perl(Bar.pm) # perl(Baz.pm)' # Looks like you failed 3 tests of 79. t/01-B-PerlReq.t .. [...] Test Summary Report --- t/01-B-PerlReq.t (Wstat: 768 (exited 3) Tests: 79 Failed: 3) Failed tests: 46-48 Non-zero exit status: 3 Files=3, Tests=113, 3 wallclock secs ( 0.04 usr 0.00 sys + 2.23 cusr 0.50 csys = 2.77 CPU) Result: FAIL Failed 1/3 test programs. 3/113 subtests failed. make[1]: *** [Makefile:957: test_dynamic] Error 255 Full build log at http://perl.debian.net/rebuild-logs/perl-5.38/libb-perlreq-perl_0.82-7/libb-perlreq-perl_0.82-7%2Bb2_amd64-2023-07-05T10%3A24%3A03Z.build -- Niko Tyni nt...@debian.org
Bug#1040386: libdata-swap-perl: FTBFS with Perl 5.38: undefined reference to `Perl_hv_backreferences_p'
Source: libdata-swap-perl Version: 0.08-2 Severity: important Tags: ftbfs trixie sid Forwarded: https://rt.cpan.org/Ticket/Display.html?id=144619 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental): x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib -fstack-protector-strong Swap.o -o blib/arch/auto/Data/Swap/Swap.so \ \ /usr/bin/ld: Swap.o: in function `extract_backrefs': ././Swap.c:63: undefined reference to `Perl_hv_backreferences_p' /usr/bin/ld: Swap.o: in function `install_backrefs': ././Swap.c:88: undefined reference to `Perl_hv_backreferences_p' /usr/bin/ld: blib/arch/auto/Data/Swap/Swap.so: hidden symbol `Perl_hv_backreferences_p' isn't defined /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[1]: *** [Makefile:474: blib/arch/auto/Data/Swap/Swap.so] Error 1 Full build log at http://perl.debian.net/rebuild-logs/perl-5.38/libdata-swap-perl_0.08-2/libdata-swap-perl_0.08-2+b2_amd64-2023-06-28T20:28:45Z.build -- Niko Tyni nt...@debian.org
Bug#1040384: libapache2-mod-perl2: FTBFS with Perl 5.38: undefined symbol: do_open9
Source: libapache2-mod-perl2 Version: 2.0.12-1 Severity: important Tags: ftbfs trixie sid fixed-upstream patch User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental): waiting 300 seconds for server to start: .apache2: Syntax error on line 79 of /<>/t/conf/httpd.conf: Cannot load /<>/src/modules/perl/mod_perl.so into server: /<>/src/modules/perl/mod_perl.so: undefined symbol: do_open9 [ error] server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) Terminated make[2]: *** [Makefile:1054: run_tests] Error 143 make[2]: Leaving directory '/<>' dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2 make[1]: *** [debian/rules:31: override_dh_auto_test] Error 25 This is fixed upstream with https://github.com/apache/mod_perl/commit/991cfeca9bac185f191510e0064f174d45718e6a Full build log at http://perl.debian.net/rebuild-logs/perl-5.38/libapache2-mod-perl2_2.0.12-1/libapache2-mod-perl2_2.0.12-1+b3_amd64-2023-06-29T03:47:12Z.build -- Niko Tyni nt...@debian.org
Bug#1040377: libmime-tools-perl: spurious warning with Perl 5.38
Package: libmime-tools-perl
Version: 5.510-1
Severity: normal
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
The MIME::Decoder::QuotedPrint module throws a warning on usage
with Perl 5.38 (currently in experimental):
$ perl -w -e 'use MIME::Decoder::QuotedPrint'
Argument "3.16_01" isn't numeric in numeric ge (>=) at
/usr/share/perl5/MIME/Decoder/QuotedPrint.pm line 76.
This is because Perl core includes MIME::QuotedPrint at version 3.16_01,
and MIME::Decoder::QuotedPrint has this:
# The following code is horrible. I know. Beat me up. --dfs
BEGIN {
if (!defined(&encode_qp_threearg)) {
if ($::MIME::QuotedPrint::VERSION >= 3.03) {
eval 'sub encode_qp_threearg ( $$$ ) { encode_qp(shift, shift,
shift); }';
} else {
eval 'sub encode_qp_threearg ( $$$ ) { encode_qp(shift); }';
}
}
}
Looks like the version check needs to be changed to handle non-numeric
version strings.
This is breaking the test suites of (at least) request-tracker4 and
request-tracker5, which check for warnings.
--
Niko Tyni nt...@debian.org
Bug#1040376: libnumber-format-perl: broken with Perl 5.38: mon_thousands_sep and mon_decimal_point may not be equal
Package: libnumber-format-perl Version: 1.75-3 Severity: important Tags: trixie sid fixed-upstream Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148432 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package is unusable with Perl 5.38 (currently in experimental). $ perl -MNumber::Format -E 'say Number::Format->new->format_number(1)' mon_thousands_sep and mon_decimal_point may not be equal at -e line 1. It also fails its test suite, making it fail to build. This is fixed upstream in 1.76 (not noted on the upstream ticket though.) I'm adding Breaks: libnumber-format-perl (<< 1.76) on the perl side in the next upload. -- Niko Tyni nt...@debian.org
Bug#1040244: librdf-ldf-perl: FTBFS: cannot remove : No such file or directory
Source: librdf-ldf-perl Version: 0.25.1-1 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. debian/rules execute_after_dh_installman make[1]: Entering directory '/<>' rm debian/*/usr/share/man/man3/RDF::LDF::Error.3pm* rm: cannot remove 'debian/*/usr/share/man/man3/RDF::LDF::Error.3pm*': No such file or directory make[1]: *** [debian/rules:8: execute_after_dh_installman] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040242: libdist-zilla-plugin-run-perl: FTBFS: cannot remove : No such file or directory
Source: libdist-zilla-plugin-run-perl Version: 0.048-1 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::BeforeBuild.3pm rm --verbose /<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::Role::Runner.3pm rm: cannot remove '/<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::Role::Runner.3pm': No such file or directory make[1]: *** [debian/rules:11: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040220: libsyntax-keyword-match-perl: circular build dependencies with libfuture-asyncawait-perl
Source: libsyntax-keyword-match-perl Version: 0.12-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package cannot be rebuilt for the next Perl transition because of circular build dependencies. Package: libsyntax-keyword-match-perl Architecture: any Build-Depends: [...], libfuture-asyncawait-perl , [...] Package: libfuture-asyncawait-perl Architecture: any Build-Depends: [...], libsyntax-keyword-match-perl , [...] So when the new perl makes the binaries uninstallable, they both need each other to be rebuilt first. Building with the 'nocheck' build profile would solve the issue, but I don't think the Debian binNMU machinery supports this. Filing against libsyntax-keyword-match-perl but this could be fixed in either package. -- Niko Tyni nt...@debian.org
Bug#1040219: libsyntax-keyword-dynamically-perl: circular build dependencies with libobject-pad-perl
Source: libsyntax-keyword-dynamically-perl Version: 0.12-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package cannot be rebuilt for the next Perl transition because of circular build dependencies. Package: libsyntax-keyword-dynamically-perl Architecture: any Build-Depends: [...], libobject-pad-perl , [...] Package: libobject-pad-perl Architecture: any Build-Depends: [...], libsyntax-keyword-dynamically-perl , [...] So when the new perl makes the binaries uninstallable, they both need each other to be rebuilt first. Building with the 'nocheck' build profile would solve the issue, but I don't think the Debian binNMU machinery supports this. Filing against libsyntax-keyword-dynamically-perl but this could be fixed in either package. -- Niko Tyni nt...@debian.org
Bug#1039907: apt-cacher-cleanup.pl clears/removes all cached packages on trixie
On Sun, Jul 02, 2023 at 03:40:45PM +0100, Mark Hindley wrote: > Installing libio-compress-lzma-perl pulls in libio-compress-perl and normal > apt-cacher decompression is restored. > > I suppose the apt-cacher Recommends will need to become a Depends. Hi, glad you found a working solution. Thanks to Gregor for investigating. Like Gregor I'm not aware of recent changes around these things. Please provide more information if you still think it's a regression on the perl side. -- Niko Tyni nt...@debian.org
Bug#1040134: libaspect-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libaspect-perl Version: 1.04-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040030: libcpandb-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libcpandb-perl Version: 0.18-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040029: libfile-localizenewlines-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libfile-localizenewlines-perl Version: 1.12-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:7: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040028: liboauth-lite2-perl: FTBFS: cannot remove : No such file or directory
Source: liboauth-lite2-perl Version: 0.11-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/liboauth-lite2-perl/usr/bin/token.psgi # delete token.psgi, as it's moved to examples dir rm -f -v /<>/debian/liboauth-lite2-perl/usr/bin/token.psgi removed '/<>/debian/liboauth-lite2-perl/usr/bin/token.psgi' rm -f -v /<>/debian/liboauth-lite2-perl/usr/share/man/man1/token.psgi.1p rmdir --ignore-fail-on-non-empty --parents --verbose /<>/debian/liboauth-lite2-perl/usr/bin rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr/bin' rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr' rmdir --ignore-fail-on-non-empty --parents --verbose /<>/debian/liboauth-lite2-perl/usr/share/man/man1/ rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr/share/man/man1/' rmdir: failed to remove '/<>/debian/liboauth-lite2-perl/usr/share/man/man1/': No such file or directory make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040027: liborlite-migrate-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-migrate-perl Version: 1.10-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040026: liborlite-mirror-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-mirror-perl Version: 1.24-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040025: liborlite-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-perl Version: 1.98-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040024: liborlite-statistics-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-statistics-perl Version: 0.03-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040023: libsms-send-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libsms-send-perl Version: 1.06-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040022: libtest-deep-fuzzy-perl: FTBFS: cannot remove : No such file or directory
Source: libtest-deep-fuzzy-perl Version: 0.01-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy.3pm # remove empty manpage rm --verbose /<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy::Number.3pm rm: cannot remove '/<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy::Number.3pm': No such file or directory make[1]: *** [debian/rules:12: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts Example log at https://tests.reproducible-builds.org/debian/rbuild/trixie/amd64/libtest-deep-fuzzy-perl_0.01-2.rbuild.log.gz -- Niko Tyni nt...@debian.org
Bug#1040021: libtext-findindent-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libtext-findindent-perl Version: 0.11-4 Severity: serious Tags: ftbfs sid trixie Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148296 This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040020: libtoml-parser-perl: FTBFS: cannot remove : No such file or directory
Source: libtoml-parser-perl Version: 0.91-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser.3pm rm --verbose /<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser::Tokenizer.3pm rm: cannot remove '/<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser::Tokenizer.3pm': No such file or directory make[1]: *** [debian/rules:11: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts Example log at https://tests.reproducible-builds.org/debian/rbuild/trixie/arm64/libtoml-parser-perl_0.91-2.rbuild.log.gz -- Niko Tyni nt...@debian.org
Bug#997994: CPAN release
Control: close -1 5.36.0-1 Control: tag -1 bullseye On Fri, Jun 24, 2022 at 09:50:19AM -0400, Bill Blough wrote: > According to the last comment on PR41 [0] this has been released to > CPAN as v3.14 [1]. > > If it could be put into a point release or backported, that would be > super helpful for those of us affected. > [0] https://github.com/steve-m-hay/perl-libnet/pull/41#issuecomment-1133863080 > [1] https://metacpan.org/pod/Net::FTP Umph, looks like this didn't happen. The fix is in Perl 5.36 though, which is now in the latest Debian stable release (bookworm). Closing the bug accordingly (but leaving the bullseye tag so it won't get archived.) TBH I doubt I'll be preparing an update for bullseye just for this at this point. Can't speak for Dominic of course. Thanks for the report and sorry things didn't work out quite as well as they could have. -- Niko Tyni nt...@debian.org
Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns
reassign 1037063 libxml2 2.9.10+dfsg-6.7
found 1037063 2.9.10+dfsg-6.7+deb11u4
close 1037063 2.9.12+dfsg-1
forwarded 1037063 https://gitlab.gnome.org/GNOME/libxml2/-/issues/188
thanks
Hi, thanks for the report. See below for some analysis.
(TL;DR: It's a bug in libxml2 that was fixed upstream after the version
in bullseye, and the fix will be in the upcoming bookworm release.)
On Fri, Jun 02, 2023 at 10:38:02PM -0500, Xan Charbonnet wrote:
> Package: libxml-libxml-perl
> Version: 2.0134+dfsg-2+b1
> Severity: normal
>
> Dear Maintainer,
>
> I use XML::LibXML::Reader to work with files that validate against the Library
> of Congress's MARCXML Schema, available here:
> https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
>
> That schema includes a pattern:
> [\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
> or, with the XML escaping processed:
> [\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
>
> That regex requires a single character, any one of a long list of allowable
> characters. Note how three of the characters require escaping because they
> would have meaning in the regex itself: the two square brackets [ and ], and
> the backslash \.
>
> An online XML Schema validator that I found with a quick search:
> https://www.liquid-technologies.com/online-xsd-validator
> shows that those three characters are valid. The problem is that
> XML::LibXML::Reader seems to believe that they are not.
[...]
> test.xml:1: Schemas validity error : Element 'root', attribute 'code': [facet
> 'pattern'] The value '[' is not accepted by the pattern
> '[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}'.
>
> I believe that value in fact should match that pattern. The online schema
> validator from earlier validates this pair of files. If you replace the data
> in the "code" attribute with any of the other characters, validation passes.
> It only fails for the three characters that are escaped.
This last part is not quite correct: validation also fails for the
backtick (`) and the tilde (~) characters. It's not about quoting,
it's about mistreating the caret (^) in the middle of the pattern.
The fault actually lies is in libxml2 which libxml-libxml-perl uses,
as seen with `xmllint --schema test.xsd test.xml` (xmllint is in
the libxml2-utils package).
It looks like it was fixed upstream in libxml2 2.9.11 with
https://gitlab.gnome.org/GNOME/libxml2/-/commit/7d6837ba0e282e94eb8630ad791f427e44a57491
and the fix entered Debian with 2.9.12.
I'm reassigning and closing the bug as it's fixed in current versions
in unstable and testing. Not sure if it's something that should be
backported to current Debian stable (bullseye). Feel free to discuss
that with the libxml2 maintainers (cc'd) if you like.
--
Niko Tyni nt...@debian.org
Bug#1033649: perlretut lines with only NO-BREAK SPACE look bad in some readers
Control: tag -1 upstream On Wed, Mar 29, 2023 at 08:19:54AM +0800, Dan Jacobson wrote: > Package: perl-doc > Version: 5.36.0-7 > Severity: minor > File: /usr/share/man/man1/perlretut.1.gz > > These lines with only a NO-BREAK SPACE on them serve no purpose, and > just look funny in e.g., emacs. Also they only occur on this man page. > $ for i in perl perlre perlretut; do man -w $i | > xargs zcat|uni2ascii -q|grep -c ^0x00A0$; done > 0 > 0 > 15 > Emacs should be thanked for detecting it. These were explicitly added in the source pod file as E entities in https://github.com/Perl/perl5/commit/15776bb0ab4 It looks like the reasoning was that this "fixes some numbered lists to display not so uglily". -- Niko Tyni nt...@debian.org
Bug#1030827: FTBFS on armhf
Control: severity -1 serious Justification: fails to build from source On Tue, Feb 07, 2023 at 03:47:46PM -0500, Sergio Durigan Junior wrote: > Source: pspp > Severity: important > Version: 1.6.2-1 > pspp is currently FTBFSing on armhf due to several Perl-related tests > failing with: > > --8<---cut here---start->8--- > +PSPP.c: loadable library and perl binaries are mismatched (got first > handshake key 0xa500080, needed 0xa400080) > --8<---cut here---end--->8--- > > You can see the build log by inspecting reproducible-build's page: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pspp.html Hi, this is about 64-bit time_t, which became supported in glibc 2.34. https://sources.debian.org/src/glibc/2.34-7/NEWS/#L171 * Add support for 64-bit time_t on configurations like x86 where time_t is traditionally 32-bit. Although time_t still defaults to 32-bit on these configurations, this default may change in future versions. This is enabled with the _TIME_BITS preprocessor macro set to 64 and is only supported when LFS (_FILE_OFFSET_BITS=64) is also enabled. It is only enabled for Linux and the full support requires a minimum kernel version of 5.1. Perl itself is built with 32-bit time_t on Debian 32-bit architectures (like armhf and i386), but the pspp configure script probes and enables 64-bit time_t: checking for 64-bit time_t with _TIME_BITS=64... yes This ends up in config.h and changes the size of the Perl interpreter structure around for example https://sources.debian.org/src/perl/5.36.0-7/intrpvar.h/#L506 making the resulting compiled Perl module binary incompatible with /usr/bin/perl . I expect that configuring explicitly with --disable-year2038 would be a quick fix. Longer term, we might want to start building Perl with a 64-bit time_t, but that's clearly stuff for the next development cycle (bookworm + 1). BTW, would it make sense to install the PSPP Perl module in the pspp binary package (or a separate libpspp-perl or whatever?) Currently it looks like you're building it just for running the tests but then throwing the result away. Hope this helps, and thanks for your work on Debian. -- Niko Tyni nt...@debian.org
Bug#1029753: perl: build-depend on libcrypt-dev explicitly
On Fri, Jan 27, 2023 at 08:03:12AM +0100, Helmut Grohne wrote: > Source: perl > Version: 5.36.0-7 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > perl uses -lcrypt without depending on libcrypt-dev. This used to be ok, > but we split libcrypt to src:libxcrypt and now libc6-dev has a > transitional dependency on libcrypt-dev. So while libcrypt-dev still is > build-essential, it no longer is in a bootstrap setting (in order to > solve dependency cycles) and given that so few packages actually need > libcrypt-dev, we want to remove it from build-essential in the long > term. As such there is no urgency to adding it right now, it also > doesn't hurt. I'm attaching the obvious patch for your convenience. Thanks. Just for the record, we're frozen now and based on the above I assume there's no benefit in pushing this to bookworm. So I'll wait until trixie development opens before including it. Let me know if you'd prefer otherwise of course. -- Niko
Bug#1026669: [request-tracker-maintainers] Bug#1026669: request-tracker5: FTBFS: can't locate java: No such file or directory
Control: clone -1 -2
Control: retitle -2 jexec: can't locate java: No such file or directory
Control: reassign -2 openjdk-17-jre-headless 17.0.5+8-2
On Wed, Jan 18, 2023 at 04:10:02AM +0100, Ángel wrote:
> The error here is that ./debian/build-final-ckeditor.sh fails with
> « can't locate java: No such file or directory »
>
> This script is actually calling ckbuilder ( jexec /usr/bin/ckbuilder --
> build ... )
>
> However, the package correctly lists ckbuilder as a build-dep, and
> ckbuilder itself depends on java ( default-jre | java{7..11}-runtime)
> > update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> > amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Yeah, it looks to me like jexec from openjdk-17-jre-headless
is just broken on sid?
% jexec
can't locate java: No such file or directory
% ls -l /usr/bin/jexec /etc/alternatives/jexec
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
lrwxrwxrwx 1 root root44 Oct 19 14:23 /etc/alternatives/jexec ->
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
lrwxrwxrwx 1 root root23 Oct 19 14:23 /usr/bin/jexec ->
/etc/alternatives/jexec
-rwxr-xr-x 1 root root 14416 Oct 19 14:23
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
% ls -l /usr/bin/java /etc/alternatives/java
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root43 Oct 19 14:23 /etc/alternatives/java ->
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root22 Oct 19 14:23 /usr/bin/java ->
/etc/alternatives/java
-rwxr-xr-x 1 root root 14424 Oct 19 14:23
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
% java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-Debian-2)
OpenJDK 64-Bit Server VM (build 17.0.5+8-Debian-2, mixed mode, sharing)
I'm cloning a separate bug about this.
Not sure why jexec is used here though. Just running /usr/bin/ckbuilder
works for me (but the request-tracker5 build fails later, presumably
due to a different bug.)
--
Niko Tyni nt...@debian.org
Bug#1026501: [request-tracker-maintainers] Bug#1026501: request-tracker4: FTBFS: make[1]: *** [Makefile:381: test-parallel] Error 1
Control: tag -1 upstream fixed-upstream patch
On Tue, Dec 20, 2022 at 05:54:40PM +0100, Lucas Nussbaum wrote:
> Source: request-tracker4
> Version: 4.4.6+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> > # Failed test 'LocalizedDateTime format with defaults'
> > # at t/api/date.t line 100.
> > # got: 'Thu, Jan 1, 1970 12:00:00 AM'
> > # expected: 'Thu, Jan 1, 1970 12:00:00 AM'
This is fixed upstream in the 'maint' branch with
https://github.com/bestpractical/rt/commit/03868c7eaeea38cd9f9ebe588ee52df355b029cc
Update tests for EN datetime locale change to space
DateTime::Locale version 1.58 published CLDR 42.0.0 which changed
the space character in times before the AM and PM to be
U+202F NARROW NO-BREAK SPACE (aka NNBSP) from the previous
space (U+0020). This broke tests looking for a space character
for localized datetimes with an AM/PM.
Update to a like test to work for older versions of DateTime::Locale
and for new ones from 1.58 forward.
though I believe the breaking change was in DateTime-Locale version 1.37
and not 1.58 (which does not exist yet AFAICS.)
Attached as well for convenience.
--
Niko
>From 03868c7eaeea38cd9f9ebe588ee52df355b029cc Mon Sep 17 00:00:00 2001
From: Jim Brandt
Date: Mon, 7 Nov 2022 17:18:48 -0500
Subject: [PATCH] Update tests for EN datetime locale change to space
DateTime::Locale version 1.58 published CLDR 42.0.0 which changed
the space character in times before the AM and PM to be
U+202F NARROW NO-BREAK SPACE (aka NNBSP) from the previous
space (U+0020). This broke tests looking for a space character
for localized datetimes with an AM/PM.
Update to a like test to work for older versions of DateTime::Locale
and for new ones from 1.58 forward.
---
t/api/date.t | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/t/api/date.t b/t/api/date.t
index 19a0a0153..aee517d9c 100644
--- a/t/api/date.t
+++ b/t/api/date.t
@@ -81,6 +81,11 @@ my $current_user;
RT->Config->Set( Timezone => 'UTC' );
}
+# Note, starting with DateTime::Locale version 1.58,
+# RT::Date::LocalizedDateTime returns AM/PM with a
+# U+202F NARROW NO-BREAK SPACE (aka NNBSP) before them rather than
+# a plain space, thus the "like" tests below.
+
{
my $date = RT::Date->new(RT->SystemUser);
is($date->IsSet,0, "new date isn't set");
@@ -97,8 +102,8 @@ my $current_user;
is($date->Get(Format =>'RFC2822'),
'Thu, 01 Jan 1970 00:00:00 +',
"RFC2822 format with defaults");
-is($date->Get(Format =>'LocalizedDateTime'),
- 'Thu, Jan 1, 1970 12:00:00 AM',
+like($date->Get(Format =>'LocalizedDateTime'),
+ qr/Thu\, Jan 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format with defaults");
is($date->ISO(Time => 0),
@@ -123,8 +128,8 @@ my $current_user;
is($date->RFC2822(Date => 0),
'00:00:00 +',
"RFC2822 format without date part");
-is($date->LocalizedDateTime(Date => 0),
- '12:00:00 AM',
+like($date->LocalizedDateTime(Date => 0),
+ qr/12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without date part");
is($date->ISO(Date => 0, Seconds => 0),
@@ -144,17 +149,17 @@ my $current_user;
'00:00:00 +',
"RFC2822 format without 'day of week' and date parts(corner case test)");
-is($date->LocalizedDateTime(AbbrDay => 0),
- 'Thursday, Jan 1, 1970 12:00:00 AM',
+like($date->LocalizedDateTime(AbbrDay => 0),
+ qr/Thursday\, Jan 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without abbreviation of day");
-is($date->LocalizedDateTime(AbbrMonth => 0),
- 'Thu, January 1, 1970 12:00:00 AM',
+like($date->LocalizedDateTime(AbbrMonth => 0),
+ qr/Thu\, January 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without abbreviation of month");
-is($date->LocalizedDateTime(DateFormat => 'date_format_short'),
- '1/1/70 12:00:00 AM',
+like($date->LocalizedDateTime(DateFormat => 'date_format_short'),
+ qr/1\/1\/70 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format with non default DateFormat");
-is($date->LocalizedDateTime(TimeFormat => 'time_format_short'),
- 'Thu, Jan 1, 1970 12:00 AM',
+like($date->LocalizedDateTime(TimeFormat => 'time_format_short'),
+ qr/Thu\, Jan 1\, 1970 12:00( |\x{202F})AM/,
"LocalizedDateTime format with non default TimeFormat");
is($date->Date,
@@ -212,7 +217,7 @@ my $current_user;
is($date->ISO( Timezone => 'user' ), '2005-01-01 18:10:00', "ISO");
is($date->W3CDTF( Timezone => 'user' ), '2005-01-01T18:10:00+03:00', "W3C DTF");
is($date->RFC2822( Timezone => 'user' ), 'Sat, 01 Jan 2005 18:10:00 +0300', "RFC2822");
-is($date->LocalizedDateTime( Timezone => 'user' ), 'Sat, Jan 1, 2005 6:10:00 PM', "Lo
Bug#1028275: perl: Return value of system()
Control: forwarded -1 https://github.com/Perl/perl5/issues/19020 Control: block -1 with 436466 On Sun, Jan 08, 2023 at 08:49:49PM -0800, David Christensen wrote: > Package: perl > Version: 5.32.1-4+deb11u2 > Severity: normal > X-Debbugs-Cc: dpchr...@holgerdanske.com > not ok 4 - signal-child_error-system.t 24 $?(33024) == SIGHUP(1) > # Failed test 'signal-child_error-system.t 24 $?(33024) == SIGHUP(1)' > # at signal-child_error-system.t line 24. > # got: '33024' > # expected: '1' Hi, this is about a difference in bash vs. dash as /bin/sh. Perl runs the single arg form of system() through /bin/sh, and when that shell is dash (as it is by default on Debian), the child perl gets forked rather than execed in the shell process (like bash does.) The signal information is then consumed by dash and never reaches the parent perl process. There's a Perl upstream discussion about this in https://github.com/Perl/perl5/issues/19020 and it looks like dash upstream is nowadays doing the exec() thing but Debian dash is carrying a patch to disable that. See #436466. Not much we can do about this on the perl side apart from configuring perl to always use /bin/bash as the intermediate shell. I'm not thrilled about that option and would much rather see the dash behaviour changed. Workarounds I can see are calling system() in list form so the shell doesn't get invoked, or locally changing /bin/sh to point to bash. -- Niko Tyni nt...@debian.org
Bug#1025722: duck fails with 'Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at /usr/share/duck/lib/checks/patch_files.pm line 101'
On Thu, Dec 08, 2022 at 12:45:29AM +0100, gregor herrmann wrote:
> Package: duck
> Version: 0.14.0
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: p...@packages.debian.org
> As of today, duck (called in any source package directory) fails with
>
> Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at
> /usr/share/duck/lib/checks/patch_files.pm line 101'
>
> 92# iterate over all patchdirs, process all files found
> 93foreach my $patchdir (@patchdirs) {
> 94my $dirhandle = dir($patchdir)->open;
> 95
> 96while (my $patchfile = $dirhandle->read) {
> 97open my $pf, "<", $patchdir . "/" . $patchfile;
> 98
> 99my @pf_raw = <$pf>;
>100
>101close($pf);
>
> This may or may not be caused by a recent change in src:perl [0], hence
> cc'in the perl maintainers
Thanks. It's definitely that change, but I think the bug is in duck.
The above code is treating directories as plain files under autodie,
so bailing out seems warranted. Earlier it just failed silently.
A straightforward fix would be inserting something like
next if -d $patchdir . "/" . $patchfile;
on line 97 or so (but using File::Spec->catfile() would feel cleaner
to me.)
Baptiste: please let us know if/when duck is fixed so we can add a
suitable Breaks entry on the perl side. (And obviously let us also know
if you disagree about the bug :)
BTW it seems like duck could use an autopkgtest test suite so things
like this would be detected automatically.
--
Niko Tyni nt...@debian.org
Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett
On Fri, Nov 25, 2022 at 03:39:12PM -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Matthew Garrett be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Matthew Garrett > F: Further Discussion > ===END I vote: H > F -- Niko signature.asc Description: PGP signature
Bug#1024636: perl: add cross build support files for loongarch64
On Tue, Nov 22, 2022 at 10:08:39PM +0800, zhangdandan wrote: > Package: perl > Version: 5.36.0-4 > Severity: wishlist > Tags: patch > User: debian-de...@lists.debian.org > Usertags: loongarch64 > > Hi perl maintainers, > > I have added cross build support files for loongarch64 in perl package, to > ensure perl can cross buildable on loongarch64 architecture. Hmm. I see the corresponding MR [1] mentions that this was made with a straightforward sed invocation from the riscv64 config. I'd very much prefer to incorporate results from real native builds. How do you know if the resulting binaries work at all? I can see that architecture bootstrapping needs something like this for starters, though I wonder why not mips64el as I understand it's more similar hardware. But that seems like something you could/should do in a private repository to get a working build environment together, and then do native builds with that. Also it looks like not even dpkg has loongarch64 support yet so this seems rather early. [1] https://salsa.debian.org/perl-team/interpreter/perl/-/merge_requests/3 Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1022858: perl-base: lots of duplicate files between perl-modules-5.32 and perl-base
On Thu, Oct 27, 2022 at 03:27:35AM +0200, Marc Lehmann wrote: > Package: perl-base > Version: 5.32.1-4+deb11u2 > Severity: minor > X-Debbugs-Cc: report...@plan9.de > > Dear Maintainer, > > I recently installed a fresh bullseye and ran jdupes to deduplicate files. > > To my surprise, this reduced the installed size (on a zstd-compressed btrfs > filesystem) > from 2GB to 1.3GB. > > This was rather unexpected and I investigated. > > One of the larger reasons for this size reduction is a large number of > relatively large files > that are identical in perl-modules-5.32 and perl-base, random example: > > -rw-r--r-- 1 root root 1466 Sep 24 2021 > /usr/lib/x86_64-linux-gnu/perl-base/unicore/lib/Lb/CL.pl > -rw-r--r-- 1 root root 1466 Sep 24 2021 > /usr/share/perl/5.32.1/unicore/lib/Lb/CL.pl > > I wonder if thid duplication is intended, and if yes, maybe hardlinks should > be used to save space. It's intentional and has been the case since the stretch release. The libperl5.xx + perl-modules-5.xx set of packages can be coinstalled between different major versions and architectures, so they need to pull in the full standard library. OTOH a limited part of the standard library needs to be available for perl-base at all times. The duplication could be solved with a small extra package like perl-base-modules-5.xx that both could depend on, but the savings would be just 5.5MB as of bullseye/amd64. And having the separate copies inside perl-base (which is Essential:yes) makes it more robust during upgrades. I can't think of a way to use hard links here. -- Niko Tyni nt...@debian.org
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
On Wed, Nov 16, 2022 at 10:44:33PM +0100, gregor herrmann wrote: > On Wed, 16 Nov 2022 21:56:31 +0200, Niko Tyni wrote: > > > From the log: > > > >not ok 2 - ZLIB_VERSION (1.2.11) matches > > Compress::Raw::Zlib::zlib_version > ># Failed test (t/compress/CompTestUtils.pm at line 61) > ># got: '1.2.11' > ># expected: '1.2.13' > ># > ># The version of zlib.h does not match the version of libz > ># > ># You have zlib.h version 1.2.11 > ># and libz version 1.2.13 > ># > ># You probably have two versions of zlib installed on your system. > ># Try removing the one you don't want to use and rebuild. > > Hu? Uh, I was debugging this manually with 'perl t/02zlib.t' and must have mixed up the logs. Sorry! > Some quick thoughts: > - we could play with zlib_version vs. ZLIB_VERSION (1.2.13 vs. > 1.2.11, according to t/000prereq.t) in t/02zlib.t Yeah I guess that's the way to go if we want to allow the version skew. I think I have a slight preference for this over the rebuild solution. > Assuming this is not a recurring pattern, a one-time binNMU might be > not so bad … If this is for safety rather than just fixing the failing test, we'd want to do that for src:perl as well. -- Niko
Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails
Control: reassign -1 libcompress-raw-zlib-perl 2.202-1 On Tue, Nov 15, 2022 at 09:56:57PM +0100, Paul Gevers wrote: > Source: zlib, libcompress-raw-zlib-perl > Control: found -1 zlib/1:1.2.13.dfsg-1 > Control: found -1 libcompress-raw-zlib-perl/2.202-1 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update Thanks for the report. > # Failed test (t/02zlib.t at line 532) > # got: 1 > # expected: -3 It looks like this is a (possibly test-only) problem in libcompress-raw-zlib-perl. >From the log: not ok 2 - ZLIB_VERSION (1.2.11) matches Compress::Raw::Zlib::zlib_version # Failed test (t/compress/CompTestUtils.pm at line 61) # got: '1.2.11' # expected: '1.2.13' # # The version of zlib.h does not match the version of libz # # You have zlib.h version 1.2.11 # and libz version 1.2.13 # # You probably have two versions of zlib installed on your system. # Try removing the one you don't want to use and rebuild. This is failing just because the runtime zlib version is not the same that the package was built with. not ok 126 # Failed test (t/02zlib.t at line 498) # got: 1 # expected: -3 [...] not ok 134 # Failed test (t/02zlib.t at line 532) # got: 1 # expected: -3 These two trip on the same thing: apparently there's been a behaviour change in zlib 1.2.12. The test file has been adjusted for the change and has this comment: # Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib but it's choosing the expected behaviour based on the build time zlib version rather than the runtime one. Not sure how to fix these issues best. Ideally the package would not bake the build time zlib version in the binary, but it's probably part of the interface now . The documentation says all the zlib constants are automatically imported and I suppose that includes ZLIB_VERSION. I doubt the version skew causes any real problems but we can't really be sure about that. Applications could be choosing their behaviour based on ZLIB_VERSION. So just disarming the failing tests during autopkgtest and allowing version skew runs seems a bit risky. The obvious alternative is to play it safe and add tight versioned dependencies on the zlib1g package, requiring rebuilds whenever there's a new zlib upstream version. That seems overkill to me. Note that if we do introduce the tight dependencies, src:perl has a separate copy of Compress-Raw-Zlib which should probably get the same treatment. -- Niko Tyni nt...@debian.org
Bug#1023689: minilla: FTBFS: test failures with git 1:2.38.1-1 : transport 'file' not allowed
Source: minilla Version: 3.1.18-1 Severity: serious Tags: ftbfs This package fails to build from source on current sid. Test Summary Report --- t/filegatherer.t (Wstat: 65280 (exited 255) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 255 Parse errors: No plan found in TAP output t/filegatherer/submodules-recursive.t (Wstat: 65280 (exited 255) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 255 Parse errors: No plan found in TAP output t/project/in_submodule.t (Wstat: 65280 (exited 255) Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=62, Tests=170, 105 wallclock secs ( 0.42 usr 0.08 sys + 44.82 cusr 11.18 csys = 56.50 CPU) Result: FAIL The build log is rather hard to read as there are intentional test failures sprayed all over, but I think the main thing that is new is messages like this: Cloning into '/tmp/uGVjCBrSr3/libfoo'... fatal: transport 'file' not allowed fatal: clone of 'file:///tmp/hhqN4NFWJc' into submodule path '/tmp/uGVjCBrSr3/libfoo' failed I've tested that building in bookworm succeeds, but injecting git_1%3a2.38.1-1_amd64.deb (and git-man_1%3a2.38.1-1_all.deb) makes it fail. I assume this is about https://security-tracker.debian.org/tracker/CVE-2022-39253 which was fixed in git 1:2.38.1-1. -- Niko Tyni nt...@debian.org
Bug#1023685: libdancer-perl: FTBFS: 10_error_dumper_without_clone.t failure
Source: libdancer-perl Version: 1.3513+dfsg-1 Severity: serious Tags: ftbfs sid bookworm Control: affects -1 libhttp-message-perl This package fails to build from source on current sid. t/12_response/10_error_dumper.t . 1..5 ok 1 - An object of class 'Dancer::Error' isa 'Dancer::Error' ok 2 - Data was censored in the output ok 3 - Original data was not overwritten ok 4 - Censoring of complex data structures works fine ok 5 - recursive censored hash ok Devel::Hide hides Clone.pm Can't locate Clone.pm in @INC (hidden) BEGIN failed--compilation aborted at /usr/share/perl5/HTTP/Headers.pm line 8. Compilation failed in require at /<>/blib/lib/Dancer/Response.pm line 14. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/Response.pm line 14. Compilation failed in require at /<>/blib/lib/Dancer/SharedData.pm line 8. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/SharedData.pm line 8. Compilation failed in require at /<>/blib/lib/Dancer/Request.pm line 13. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/Request.pm line 13. Compilation failed in require at /<>/blib/lib/Dancer/Route.pm line 13. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/Route.pm line 13. Compilation failed in require at /<>/blib/lib/Dancer/Route/Registry.pm line 8. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/Route/Registry.pm line 8. Compilation failed in require at /<>/blib/lib/Dancer/App.pm line 12. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/App.pm line 12. Compilation failed in require at /<>/blib/lib/Dancer.pm line 10. BEGIN failed--compilation aborted at /<>/blib/lib/Dancer.pm line 10. Compilation failed in require at t/12_response/10_error_dumper_without_clone.t line 17. BEGIN failed--compilation aborted at t/12_response/10_error_dumper_without_clone.t line 17. t/12_response/10_error_dumper_without_clone.t ... Dubious, test returned 255 (wstat 65280, 0xff00) No subtests run I assume this broke with libhttp-message-perl 6.44-1, which is currently blocked from migrating to testing due to a similar autopkgtest regression. >From the upstream HTTP-Message changelog: Changes for version 6.44 - 2022-10-26 - Made the Clone module a hard requirement, so we don't have to provide a fallback function for HTTP::Headers::clone(). We require at least Clone 0.46, as that release now supports Perl back to 5.8.1, just like us. (GH#184) (Neil Bowers) - Import clone from Clone rather than inheriting (GH#189) (Graham Knop) Looking at the above, my guess is that the Dancer test which "hides Clone.pm" needs to be updated, as it uses HTTP::Headers which now requires Clone. -- Niko Tyni nt...@debian.org
Bug#1022780: libobject-remote-perl: FTBFS on various architectures: test failures
hind the scenes, which needs
XSLoader.pm, which now needs strict.pm.
So when strict.pm is "fatpacked" we now have a loop that Perl barfs over
somehow. I'm a bit hazy on the further details, but a minimal if silly
test case is
unshift @INC, sub { if ($_[1] eq "strict.pm") { my $a = "1;"; open my $fh,
'<', \$a }; return undef};
require strict;
require XSLoader;
print "ok\n";
which fails on 5.36 (regardless of the architecture) but not on 5.34.
If I manually remove 'use strict' from XSLoader, it starts to pass
on 5.36 as well.
As for fixing this:
I can't see a portable solution for filtering away the perl-base include path.
It's a Debian specific modification and there is no Config entry to match
against [4]. Even doing it as a Debian specific patch is a bit hard to do
properly. I guess we could look up the multiarch triplet and construct
the perl-base path manually, or do some mangling on $Config{archlib},
or just look for 'perl-base' in @INC and hope nobody uses that for local
include directories.
We could also try to do better in filtering away arch specific modules
by matching for the multiarch triplet, with many of the same caveats
as above. This might be made into something acceptable for upstream,
though I suspect $Config{myarch} is only intended to match the EU::MM
subdirectories.
Lastly, a minimal change that keeps the unwanted bundling of perl-base
modules but fixes this specific regression is to load strict.pm or
preferrably all of PerlIO::Scalar before starting to evaluate the
bundled code. This could be as easy as making a throwaway in-memory
file handle before touching @INC. I've verified that it makes the test
suite pass again on i386 without breaking it on amd64. I'm attaching
such a change but I hesitate to call it a proper patch. Possibly we
should still apply it for the time being, at least it shouldn't make
things worse. (If somebody does, please make sure to fill in the bug
number in the commit message.)
I'm loath to pushing any of this upstream, though I suppose we should
inform them that we have a mess here. It's really pretty much our (my)
own fault. There's a reason for every Debian change that leads into this,
but obviously it's something a systemic failure that we're hacking these
perl-base specific things in without pushing for a generic solution
upstream. If only perl-base wasn't Essential:yes we could get rid of
most of the stuff.
(Congratulations to everybody who managed to read this far!)
[1] This has been the case since 5.22 Debian packaging in 2015 or so, and
is done so that we can ship a full standard library for each major
Perl version in libperl5.X and its dependencies for use with embedded
Perl interpreters, but keep the perl-base package with /usr/bin/perl
self contained and robust.
[2] quoting dpkg-architecture(1) for DEB_HOST_MULTIARCH:
The clarified GNU system type, used for filesystem paths.
This triplet does not change even when the baseline ISA gets bumped,
so that the resulting paths are stable over time. The only current
difference with the GNU system type is that the CPU part for
i386 based systems is always i386. Examples: i386-linux-gnu,
x86_64-linux-gnu. Example paths: /lib/powerpc64le-linux-gnu/,
/usr/lib/i386-kfreebsd-gnu/.
[3] as in 'open my $fh, "<", \$scalar;'
[4] it's not even in $Config{ccflags} because we ship a Config.pm from
the shared build without it, see #798626 et al.
--
Niko Tyni nt...@debian.org
>From 9b014783658e3023ed4ce75a5b679161784638ab Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Tue, 25 Oct 2022 18:27:05 +0100
Subject: [PATCH] Pre-load PerlIO::scalar before loading fatpacked modules
This is just for robustness in case PerlIO::scalar or its dependencies
somehow get included in the fatpacked bundle. See the Debian bug for a
full story of how this could happen.
Bug-Debian: https://bugs.debian.org/xxx
---
lib/Object/Remote/FatNode.pm | 4
1 file changed, 4 insertions(+)
diff --git a/lib/Object/Remote/FatNode.pm b/lib/Object/Remote/FatNode.pm
index cafc47e..fbc0c21 100644
--- a/lib/Object/Remote/FatNode.pm
+++ b/lib/Object/Remote/FatNode.pm
@@ -111,6 +111,10 @@ my $end = stripspace <<'END_END';
return;
}
+ # pre-load PerlIO::scalar which we need for loading the fatpacked code
+ # just in case it or its dependencies got inadvertently bundled
+ open(my $fh, '<', \"1");
+
unshift @INC, sub { load_from_hash(\%fatpacked, $_[1]) };
push @INC, sub { load_from_hash(\%fatpacked_extra, $_[1]) };
--
2.37.2
Bug#1022133: libdevel-bt-perl: FTBFS on armel: t/basic.t failure
Source: libdevel-bt-perl Version: 0.06-5 Severity: serious Tags: ftbfs Control: block 1019353 with -1 This package failed to build against Perl 5.36. https://buildd.debian.org/status/package.php?p=libdevel-bt-perl # Failed test 'perl backtrace for SIGABRT' # at t/basic.t line 26. # '#0 0xf780bc88 in __wait4_time64 () from /lib/arm-linux-gnueabi/libc.so.6 # #1 0x01a063d0 in ?? () # ' # doesn't match '(?^:\bperl_run\b)' [...] Test Summary Report --- t/basic.t (Wstat: 1792 (exited 7) Tests: 7 Failed: 7) Failed tests: 1-7 Non-zero exit status: 7 Files=4, Tests=7, 21 wallclock secs ( 0.04 usr 0.02 sys + 0.94 cusr 0.20 csys = 1.20 CPU) Result: FAIL We've had trouble with arm* before, see #824846 . -- Niko Tyni nt...@debian.org
Bug#1022132: gnumeric: FTBFS on ppc64el: error: initializer element is not constant
Source: gnumeric Version: 1.12.53-1 Severity: serious Tags: ftbfs Control: block 1019353 with -1 This package currently fails to build on the ppc64el architecture. https://buildd.debian.org/status/logs.php?pkg=gnumeric&arch=ppc64el I'm guessing the long double change (#1016388) in 1.12.53-1 broke it, powerpc long doubles are special iirc. Excerpt from a build log: In file included from ./mathfunc.h:4, from mathfunc.c:38: mathfunc.c: At top level: ./mathfunc.h:21:31: error: initializer element is not constant 21 | #define M_LN2gnum GNM_const(0.693147180559945309417232121458176568075500134360255254120680009493393621969694715605863326996419) | ^~~~~~ -- Niko Tyni nt...@debian.org
Bug#1022031: perl: FTBFS on sparc64: test failures in t/re
On Wed, Oct 19, 2022 at 11:15:35AM +0200, John Paul Adrian Glaubitz wrote: > On 10/19/22 11:06, Niko Tyni wrote: > > The perl package currently fails to build on sparc64 due > > to two failing tests: > >Failed 2 tests out of 2622, 99.92% okay. > > re/reg_mesg.t > > re/regex_sets.t > > > > The 5.36 transition is already ongoing > > (see https://lists.debian.org/debian-devel-announce/2022/10/msg5.html > > ) > > so you might want to upload a nocheck build or something to catch > > the train. > > Already working on it. Are you going to file a bug report upstream or shall I? Great. Happy if you file it, thanks. -- Niko
Bug#1022031: perl: FTBFS on sparc64: test failures in t/re
Source: perl Version: 5.36.0-4 Tags: ftbfs X-Debbugs-Cc: debian-sp...@lists.debian.org The perl package currently fails to build on sparc64 due to two failing tests: t/re/reg_fold ok t/re/reg_mesg FAILED--no leader found t/re/reg_namedcapture ok t/re/reg_nc_tie .. ok t/re/reg_nocapture ... ok t/re/reg_pmod ok t/re/reg_posixcc . ok t/re/regex_sets .. FAILED--no leader found [...] Failed 2 tests out of 2622, 99.92% okay. re/reg_mesg.t re/regex_sets.t The 5.36 transition is already ongoing (see https://lists.debian.org/debian-devel-announce/2022/10/msg5.html ) so you might want to upload a nocheck build or something to catch the train. Apologies for the late notice, -- Niko Tyni nt...@debian.org
Bug#1019353: transition: perl 5.36
On Tue, Oct 18, 2022 at 03:05:59PM +0200, Emilio Pozuelo Monfort wrote: > > On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote: > > > We'd like to get Perl 5.36 in bookworm. Filing this to get it on the > > > radar properly, but I'd like to do a few more checks first. So tagging > > > 'moreinfo' for now. I'll remove that when I'm done with the checks, > > > hopefully in a couple of weeks at the latest. > That looks good. Please go ahead. Thanks! perl_5.36.0-4 uploaded to unstable. -- Niko
Bug#1019757: perl: Subroutine JSON::PP::Boolean::(-- redefined with 5.36
Control: tag -1 patch fixed-upstream Control: forwarded -1 https://github.com/makamaka/JSON-PP/pull/79 On Thu, Sep 29, 2022 at 10:35:29PM +0300, Niko Tyni wrote: > On Wed, Sep 14, 2022 at 07:57:01PM +0100, Niko Tyni wrote: > > Package: perl > > Version: 5.36.0-2 > > User: debian-p...@lists.debian.org > > Usertags: perl-5.36-transition > > Forwarded: https://github.com/Perl/perl5/issues/20246 > > X-Debbugs-Cc: libmetacpan-client-p...@packages.debian.org > > Control: affects -1 libmetacpan-client-perl > > Control: block 1019353 with -1 > > > > This warns with Perl >= 5.36: > > > > % perl -we 'use Cpanel::JSON::XS (); use JSON::PP' > > Subroutine JSON::PP::Boolean::(0+ redefined at > > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > > Subroutine JSON::PP::Boolean::(++ redefined at > > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > > Subroutine JSON::PP::Boolean::(-- redefined at > > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > > > > I have filed https://github.com/makamaka/JSON-PP/issues/76 against > > JSON::PP about this, but it's currently unclear if it should rather be > > "fixed" on the Perl side ( https://github.com/Perl/perl5/issues/20246 ). > I've also prodded the upstream ticket a bit, hoping that somebody would > determine if it needs to be fixed in Perl or JSON::PP. JSON::PP got fixed upstream in 4.12 with https://github.com/makamaka/JSON-PP/pull/79 The fix is already in the separate libjson-pp-perl package (thanks Gregor!) I think I'll cherry-pick the patch for the version in 5.36 core as well. Probably not worth fiddling with the Breaks version though. -- Niko
Bug#1019353: transition: perl 5.36
Control: tag -1 - moreinfo Control: block -1 with 1021324 On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Tags: moreinfo > X-Debbugs-Cc: p...@packages.debian.org > Control: block -1 with 1016761 > > We'd like to get Perl 5.36 in bookworm. Filing this to get it on the > radar properly, but I'd like to do a few more checks first. So tagging > 'moreinfo' for now. I'll remove that when I'm done with the checks, > hopefully in a couple of weeks at the latest. That was a bit optimistic (no real problems, I just couldn't find the time), but I think we're ready now. I've just test rebuilt the packages needing a binNMU one more time, and the only one failing in testing is redland-bindings (#1021324, should be trivial to fix.) I'm marking that as a blocker, but I haven't checked if it could be removed easily if necessary. #1019757 is still open but I've worked around the one autopkgtest regression that it triggered. I don't think it should be a blocker for the transition. I'm not aware of any other autopkgtest regressions (but I've only tested on amd64.) Hope this addresses any concerns you might have. Please let us know when there is a free transition window. An advance notice of a few days would be appreciated. Thanks for your work as always, -- Niko
Bug#1021324: redland-bindings: FTBFS: missing build dependency on pkg-config
Source: redland-bindings Version: 1.0.17.1+dfsg-2 Severity: serious Tags: ftbfs This package fails to build from source on current sid. Log excerpt: checking for swig... swig checking for pkg-config... no checking SWIG support... 4.0.2 - OK [...] checking Enable PHP API... no checking Enable Ruby API... no checking for redland... ./configure: line 13855: --exists: command not found not found configure: error: Redland is not installed - see http://librdf.org/ to get a version 1.0.17 or newer The (regenerated) configure script has this around line 13855: printf %s "checking for redland... " >&6; } if $PKG_CONFIG --exists redland; then REDLAND_CONFIG="$PKG_CONFIG redland" Clearly the problem is that pkg-config no longer gets pulled in. It looks like this regressed with libraptor2-dev 2.0.15-3, which dropped its dependency on pkg-config, triggering a latent bug in redland-bindings of a missing a build dependency. A full build log is available at http://perl.debian.net/rebuild-logs/sid/redland-bindings_1.0.17.1+dfsg-2/redland-bindings_1.0.17.1+dfsg-2.buildlog -- Niko Tyni nt...@debian.org
Bug#1019757: perl: Subroutine JSON::PP::Boolean::(-- redefined with 5.36
Control: unblock 1019353 with -1 On Wed, Sep 14, 2022 at 07:57:01PM +0100, Niko Tyni wrote: > Package: perl > Version: 5.36.0-2 > User: debian-p...@lists.debian.org > Usertags: perl-5.36-transition > Forwarded: https://github.com/Perl/perl5/issues/20246 > X-Debbugs-Cc: libmetacpan-client-p...@packages.debian.org > Control: affects -1 libmetacpan-client-perl > Control: block 1019353 with -1 > > This warns with Perl >= 5.36: > > % perl -we 'use Cpanel::JSON::XS (); use JSON::PP' > Subroutine JSON::PP::Boolean::(0+ redefined at > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > Subroutine JSON::PP::Boolean::(++ redefined at > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > Subroutine JSON::PP::Boolean::(-- redefined at > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. > > I have filed https://github.com/makamaka/JSON-PP/issues/76 against > JSON::PP about this, but it's currently unclear if it should rather be > "fixed" on the Perl side ( https://github.com/Perl/perl5/issues/20246 ). > > The immediate impact is that (at least) libmetacpan-client-perl now > fails its autopkgtest checks because of the warning, as seen at [...] > Not sure yet what to do about this but it doesn't feel like it should > be a hard blocker for the Perl 5.36 transition. Adding the metadata for > now anyway so we don't forget about it. I think we still want to release with Perl 5.36 even if this isn't fixed in time for bookworm. I've just uploaded libmetacpan-client-perl 2.03-2 with the warnings whitelisted so the autopkgtest checks won't block the 5.36 transition. I've also prodded the upstream ticket a bit, hoping that somebody would determine if it needs to be fixed in Perl or JSON::PP. -- Niko Tyni nt...@debian.org
Bug#1012704: libmath-bigint-perl: busy loop with bignum bitwise operations
retitle 1012704 libmath-bigint-perl: busy loop with bignum bitwise operations severity 1012704 serious reassign 1012704 libmath-bigint-perl 1.999835-1 found 1012704 1.999837-1 tag 1012704 upstream thanks On Sun, Sep 18, 2022 at 12:14:06PM +0100, Klaus Ethgen wrote: > I was able to fix that bug by taking Math::BigInt and Math::BigFloat > from perl 5.36. They work seamless. > > I will reassign the bug to perl-modules. Thanks for the report. This boils down to % perl -Mbignum -e '1 | (1 >> 1)' Deep recursion on subroutine "Math::BigInt::bior" at /usr/share/perl5/Math/BigFloat.pm line 3883. Deep recursion on subroutine "Math::BigFloat::bior" at /usr/share/perl5/Math/BigInt.pm line 3513. Also happens with other bitwise operations like & and ^ . The bug is not specific to any Perl versions but seems to be fully contained in Math::BigInt / Math::BigFloat. The versions of those modules that ship with Perl 5.34.0 (Math::BigInt 1.999818) and Perl 5.36.0 (Math::BigInt 1.999830) are not affected by the bug, but you have the newer separate libmath-bigint-perl package installed where the bug triggers. It seems to have regressed upstream around 1.999832 (where it started to spit errors) and 1.999834 (where the errors became infinite recursion.) The first version in Debian that had the bug was 1.999835-1, which fits your upgrade timeline. So I'm reassigning this once more. Also raising the severity as this looks rather Bad. Would be great if (other) pkg-perl maintainers can pick this up from here and forward upstream etc. Otherwise I'll get to it eventually :) -- Niko Tyni nt...@debian.org
Bug#1019757: perl: Subroutine JSON::PP::Boolean::(-- redefined with 5.36
Package: perl Version: 5.36.0-2 User: debian-p...@lists.debian.org Usertags: perl-5.36-transition Forwarded: https://github.com/Perl/perl5/issues/20246 X-Debbugs-Cc: libmetacpan-client-p...@packages.debian.org Control: affects -1 libmetacpan-client-perl Control: block 1019353 with -1 This warns with Perl >= 5.36: % perl -we 'use Cpanel::JSON::XS (); use JSON::PP' Subroutine JSON::PP::Boolean::(0+ redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. Subroutine JSON::PP::Boolean::(++ redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. Subroutine JSON::PP::Boolean::(-- redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. I have filed https://github.com/makamaka/JSON-PP/issues/76 against JSON::PP about this, but it's currently unclear if it should rather be "fixed" on the Perl side ( https://github.com/Perl/perl5/issues/20246 ). The immediate impact is that (at least) libmetacpan-client-perl now fails its autopkgtest checks because of the warning, as seen at https://ci.debian.net/data/autopkgtest/unstable/amd64/libm/libmetacpan-client-perl/26050668/log.gz # Failed test ' /usr/bin/perl -w -M"MetaCPAN::Client" -e 1 2>&1 produced no (non-whitelisted) output' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. # Structures begin differing at: # $got->[0] = 'Subroutine JSON::PP::Boolean::(-- redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. # ' # $expected->[0] = Does not exist and verified manually: % perl -we 'use MetaCPAN::Client' Subroutine JSON::PP::Boolean::(0+ redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. Subroutine JSON::PP::Boolean::(-- redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. Subroutine JSON::PP::Boolean::(++ redefined at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52. This didn't happen in my earlier tests with 5.36 so the failure is probably rather sensitive to changes in the dependency chain. Not sure yet what to do about this but it doesn't feel like it should be a hard blocker for the Perl 5.36 transition. Adding the metadata for now anyway so we don't forget about it. -- Niko Tyni nt...@debian.org
Bug#1018289: perl: FTBFS on hurd-i386: NDBM not getting linked against libgdbm-compat
Control: tag -1 patch
Control: forwarded -1 https://github.com/Perl/perl5/pull/20267
On Tue, Aug 30, 2022 at 11:54:25PM +0300, Niko Tyni wrote:
> On Sun, Aug 28, 2022 at 01:41:48PM +0200, Samuel Thibault wrote:
> > Package: perl
> > Version: 5.34.0-5
> > Severity: important
>
> > perl currently FTBFS on hurd-i386:
>
> > # Error: Can't load '../../lib/auto/NDBM_File/NDBM_File.so' for module
> > NDBM_File: ../../lib/auto/NDBM_File/NDBM_File.so: undefined symbol:
> > dbm_nextkey at ../../lib/XSLoader.pm line 93.
> > # at ../../lib/NDBM_File.pm line 12.
>
> I think this broke with
>
> https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367
>
> but nobody noticed until now.
> Something like this works but seems rather wordy and
> silly to repeat in all of those:
>
> --
> my $hint_file = 'hints/linux.pl';
> open(my $fh, '<', $hint_file)
> or die "Could not open $hint_file for read: $!";
> eval join('', <$fh>);
> die "Failed to load hint file $hint_file: $@" if $@;
> --
>
> Guess I'll sleep on this and try to come up with something better.
Ended up proposing upstream just
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
Patch attached. We'll see how it goes.
--
Niko
>From 59cd40b841cc91dd8306ca9abcb3e7f5fafa50bd Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Wed, 31 Aug 2022 21:41:14 +0300
Subject: [PATCH] Fix GNU/{Hurd,kFreeBSD,kNetBSD} hint files in several modules
The idiom of
do './hints/linux.pl' or die $@;
broke with https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367
which made $self a lexical variable so it is no longer visible in a file
loaded with 'do'.
This silently makes the loaded Linux hints a no-op, leading to missing
symbols, broken modules and test failures in at least NDBM_File
and ODBM_File on GNU/Hurd, as reported by Samuel Thibault in
https://bugs.debian.org/1018289 .
The replacement of eval `cat hints/linux.pl` is not very sophisticated
but should be enough for this, and alternatives seem overly verbose.
Bug-Debian: https://bugs.debian.org/1018289
---
dist/Storable/hints/gnukfreebsd.pl | 2 +-
dist/Storable/hints/gnuknetbsd.pl | 2 +-
ext/DynaLoader/hints/gnukfreebsd.pl | 2 +-
ext/DynaLoader/hints/gnuknetbsd.pl | 2 +-
ext/NDBM_File/hints/gnu.pl | 2 +-
ext/NDBM_File/hints/gnukfreebsd.pl | 2 +-
ext/NDBM_File/hints/gnuknetbsd.pl | 2 +-
ext/ODBM_File/hints/gnu.pl | 2 +-
ext/ODBM_File/hints/gnukfreebsd.pl | 2 +-
ext/ODBM_File/hints/gnuknetbsd.pl | 2 +-
ext/POSIX/hints/gnukfreebsd.pl | 2 +-
ext/POSIX/hints/gnuknetbsd.pl | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/dist/Storable/hints/gnukfreebsd.pl b/dist/Storable/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/dist/Storable/hints/gnukfreebsd.pl
+++ b/dist/Storable/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/dist/Storable/hints/gnuknetbsd.pl b/dist/Storable/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/dist/Storable/hints/gnuknetbsd.pl
+++ b/dist/Storable/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/DynaLoader/hints/gnukfreebsd.pl b/ext/DynaLoader/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/ext/DynaLoader/hints/gnukfreebsd.pl
+++ b/ext/DynaLoader/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/DynaLoader/hints/gnuknetbsd.pl b/ext/DynaLoader/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/ext/DynaLoader/hints/gnuknetbsd.pl
+++ b/ext/DynaLoader/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnu.pl b/ext/NDBM_File/hints/gnu.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnu.pl
+++ b/ext/NDBM_File/hints/gnu.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnukfreebsd.pl b/ext/NDBM_File/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnukfreebsd.pl
+++ b/ext/NDBM_File/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnuknetbsd.pl b/ext/NDBM_File/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnuknetbsd.pl
+++ b/ext/NDBM_File/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl'
Bug#1019353: transition: perl 5.36
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Tags: moreinfo X-Debbugs-Cc: p...@packages.debian.org Control: block -1 with 1016761 We'd like to get Perl 5.36 in bookworm. Filing this to get it on the radar properly, but I'd like to do a few more checks first. So tagging 'moreinfo' for now. I'll remove that when I'm done with the checks, hopefully in a couple of weeks at the latest. The package in experimental is in good shape. We've been continuously rebuilding perl reverse dependencies (currently 4507 packages) since June or so on http://perl.debian.net/ , and tracking regressions at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.36-transition;users=debian-p...@lists.debian.org The only remaining regression in testing that I'm aware of is #1016761 which should be easy to fix by dropping the problematic test case that uses HTTP::Tiny internals in a not forward compatible way. I ran autopkgtest checks of 3847 packages that have Testsuite-Triggers: perl or Testsuite: autopkgtest-pkg-perl locally in July and did not find any regressions from sid. I intend to recheck this on ci.debian.net soon now that we have support for external repositories there (thanks, Paul et al.!) The recent egrep deprecation (#1019335) in sid may be a blocker for this though. I also intend to test rebuild the ~500 packages in sid that will need a binNMU one more time to catch any non-perl-related new build failures. I don't have a good way to spot non-amd64 architecture specific issues or unrelated version skew between unstable and testing, so those can still yield surprises for the transition. title = "perl"; is_affected = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ "libperl5.34|perlapi-5.34"; is_good = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ "libperl5.36|perlapi-5.36"; is_bad = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ "libperl5.34|perlapi-5.34"; Thanks for your work on the release, -- Niko Tyni nt...@debiar.org
Bug#1018687: override: perl-modules-5.34:libs/optional perl-modules-5.36:libs/optional
On Sat, Sep 03, 2022 at 11:00:31PM -0700, Russ Allbery wrote: > > On Sun 28 Aug 2022 at 09:28PM -05, Daniel Lewart wrote: > >> Please change perl-modules-5.34 and perl-modules-5.36 from: > >> * Priority: standard > >> to: > >> * Priority: optional > >> > >> perl 5.34.0 is Priority:standard" and Depends on perl-modules-5.34. > >> perl 5.36.0 is Priority:standard" and Depends on perl-modules-5.36. > >> Therefore, perl-modules-5.xx will still be pulled into Standard systems. > > I think the stronger argument here is basically that the perl-modules > package is an internal implementation detail of the perl package, and > therefore only the perl package should have the higher standard priority. > > I'm not sure it makes much difference in practice, and I'm curious what > problem Daniel ran into that motivated filing a bug report, but I think > that logic might make sense? But I'm also not sure we should make changes > here just for the sake of making changes, so I'm curious about the > motivation and what problem this change would fix. Yeah, thanks. I agree on all this. My first thought was that the requested change would be just cosmetic with no effect in practice. However, there's one thing that occurs to me in favour of the change: perl-modules-5.xx will currently stay installed after an upgrade to 5.yy, but is probably not useful anymore on most systems [1]. I'm not sure if the priority affects apt's inclination to remove orphan packages, but it does seem like a possibly useful hint. FWIW libperl5.xx is already Priority: optional and Depends on perl-modules-5.xx. Making their priorities match does feel right to me. [1] Coinstallability between Perl versions was requested so that packages embedding a Perl interpreter (by linking against libperl5.xx) would not be quite as tightly coupled during upgrades as they used to be. The package doing the embedding can now be upgraded separately later, and still has the Perl standard library available in the meantime because the older versions of libperl5.xx and perl-modules-5.xx stay installed. -- Niko Tyni nt...@debian.org
Bug#1018289: perl: FTBFS on hurd-i386: NDBM not getting linked against libgdbm-compat
Control: tag -1 confirmed upstream
On Sun, Aug 28, 2022 at 01:41:48PM +0200, Samuel Thibault wrote:
> Package: perl
> Version: 5.34.0-5
> Severity: important
> perl currently FTBFS on hurd-i386:
> # Error: Can't load '../../lib/auto/NDBM_File/NDBM_File.so' for module
> NDBM_File: ../../lib/auto/NDBM_File/NDBM_File.so: undefined symbol:
> dbm_nextkey at ../../lib/XSLoader.pm line 93.
> # at ../../lib/NDBM_File.pm line 12.
> Notably on hurd there aren't the "harmless" messages about -ldbm ; it's
> supposed to use -lgdbm_compat, as hinted from hints/linux.pl, sourced
> from hints/gnu.pl, but for some reason this isn't working any more?
I think this broke with
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367
but nobody noticed until now.
All the hints files used to get loaded with 'do', which limits scope so
that local variables ("my $var") aren't visible. The $self hash that the
hints usually modify was a local variable ("our $self") to overcome this.
The commit above changed the normal loading to use 'eval', which removed
the visibility problem, and changed the $self variable to a local
variable, presumably to make things cleaner now that it was possible.
Unfortunately hints/gnu.pl is still loading linux.pl with 'do', so $self
isn't visible anymore and the resulting hints have no effect.
A simple 'grep -w do' indicates there's a dozen affected files with the
same pattern (and a couple of false positives removed manually):
ext/NDBM_File/hints/gnu.pl
ext/NDBM_File/hints/gnukfreebsd.pl
ext/NDBM_File/hints/gnuknetbsd.pl
ext/ODBM_File/hints/gnu.pl
ext/ODBM_File/hints/gnukfreebsd.pl
ext/ODBM_File/hints/gnuknetbsd.pl
ext/POSIX/hints/gnukfreebsd.pl
ext/POSIX/hints/gnuknetbsd.pl
ext/DynaLoader/hints/gnukfreebsd.pl
ext/DynaLoader/hints/gnuknetbsd.pl
dist/Storable/hints/gnukfreebsd.pl
dist/Storable/hints/gnuknetbsd.pl
Something like this works but seems rather wordy and
silly to repeat in all of those:
--
my $hint_file = 'hints/linux.pl';
open(my $fh, '<', $hint_file)
or die "Could not open $hint_file for read: $!";
eval join('', <$fh>);
die "Failed to load hint file $hint_file: $@" if $@;
--
Guess I'll sleep on this and try to come up with something better.
--
Niko
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
Control: forwarded -1 https://github.com/libwww-perl/HTTP-Daemon/issues/57 On Sat, Aug 06, 2022 at 11:17:13PM +, Thorsten Alteholz wrote: > > > On Sat, 6 Aug 2022, gregor herrmann wrote: > > > On Sat, 06 Aug 2022 21:24:08 +0300, Niko Tyni wrote: > > > > > It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1 > > > (or at least the associated test case) has issues with newer versions > > > of the HTTP::Tiny module. > > […] > > > From my build log: > > >Subroutine HTTP::Tiny::Handle::write_content_body redefined at > > > t/content_length.t line 277. > > Oh, that is bad, shall these new tests better be disabled than? The upstream bug at https://github.com/libwww-perl/HTTP-Daemon/issues/57 is unfortunately quiet. FWIW https://github.com/NixOS/nixpkgs/pull/181632 looks like at least NixOS just dropped the test. Guess we should do the same for now but I didn't really look into the actual issue. -- Niko
Bug#1018243: libhash-sharedmem-perl: FTBFS on mipsel: undefined symbol: __sync_bool_compare_and_swap_8
Source: libhash-sharedmem-perl Version: 0.005-1 Severity: important Tags: ftbfs x-debbugs-cc: debian-m...@lists.debian.org This package failed to build on mipsel (and has never built there). >From the build log: # Failed test 'use Hash::SharedMem;' # at t/bad_dir.t line 8. # Tried to use 'Hash::SharedMem'. # Error: Can't load '/<>/blib/arch/auto/Hash/SharedMem/SharedMem.so' for module Hash::SharedMem: /<>/blib/arch/auto/Hash/SharedMem/SharedMem.so: undefined symbol: __sync_bool_compare_and_swap_8 at /usr/lib/mipsel-linux-gnu/perl-base/DynaLoader.pm line 187. # at t/bad_dir.t line 8. # Compilation failed in require at t/bad_dir.t line 8. # BEGIN failed--compilation aborted at t/bad_dir.t line 8. [...] Result: FAIL Failed 29/31 test programs. 607/619 subtests failed. dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 3 I see the source uses __sync_bool_compare_and_swap in lib/Hash/SharedMem.xs:470 . Apparently this is not available on 32-bit MIPS architectures (or 32-bit PPC either for that matter.) I'm copying the MIPS porters. Is there a known workaround for this? -- Niko Tyni nt...@debian.org
Bug#1017092: ITP: libprometheus-tiny-shared-perl -- tiny Prometheus client with a shared database behind it
Package: wnpp Owner: Niko Tyni Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libprometheus-tiny-shared-perl Version : 0.026 Upstream Author : Rob N ★ * URL : https://metacpan.org/release/Prometheus-Tiny-Shared * License : Artistic or GPL-1+ Programming Lang: Perl Description : tiny Prometheus client with a shared database behind it Prometheus::Tiny::Shared is a wrapper around Prometheus::Tiny that instead of storing metrics data in a hashtable, stores them in a shared datastore (provided by Hash::SharedMem, though this may change in the future). This lets you keep a single set of metrics in a multithreaded app. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1017091: ITP: libhash-sharedmem-perl -- efficient shared mutable hash
Package: wnpp Owner: Niko Tyni Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libhash-sharedmem-perl Version : 0.005 Upstream Author : Andrew Main (Zefram) * URL : https://metacpan.org/release/Hash-SharedMem * License : Artistic or GPL-1+ Programming Lang: Perl Description : efficient shared mutable hash Hash::SharedMem provides a facility for efficiently sharing mutable data between processes on one host. Data is organised as a key/value store, resembling a Perl hash. The keys and values are restricted to octet (Latin-1) strings. Structured objects may be stored by serialising them using a mechanism such as Sereal. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1016806: closed by Debian FTP Masters (reply to gregor herrmann ) (Bug#1016806: fixed in libcpanel-json-xs-perl 4.31-1)
Control: found -1 4.31-1 Control: forwarded -1 https://github.com/rurban/Cpanel-JSON-XS/issues/200 On Wed, Aug 10, 2022 at 03:09:05PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the libcpanel-json-xs-perl package: > > #1016806: request-tracker5: FTBFS with Perl 5.36: Subroutine > JSON::PP::Boolean::(0+ redefined > > It has been closed by Debian FTP Masters > (reply to gregor herrmann ). >* Import upstream version 4.31. > Fixes "FTBFS with Perl 5.36: Subroutine JSON::PP::Boolean::(0+ redefined" > (Closes: #1016806) Unfortunately this did not fix the issue. I've now filed https://github.com/rurban/Cpanel-JSON-XS/issues/200 about this. -- Niko
Bug#1016806: request-tracker5: FTBFS with Perl 5.36: Subroutine JSON::PP::Boolean::(0+ redefined
Control: reassign -1 libcpanel-json-xs-perl 4.30-1
Control: affects -1 request-tracker5
On Mon, Aug 08, 2022 at 12:21:17AM +0200, gregor herrmann wrote:
> On Sun, 07 Aug 2022 21:09:49 +0300, Niko Tyni wrote:
> ># Subroutine JSON::PP::Boolean::(++ redefined at
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> ># at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> >#overload::OVERLOAD("JSON::PP::Boolean", "0+",
> > CODE(0x561a9651eee0), "++", CODE(0x561a9651ef40), "--",
> > CODE(0x561a9651efd0), "\"\"", ...) called at
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 61
> >#overload::import("overload", "0+", CODE(0x561a9651eee0), "++",
> > CODE(0x561a9651ef40), "--", CODE(0x561a9651efd0), "\"\"", ...) called at
> > /usr/lib/x86_64-linux-gnu/perl5/5.36/Cpanel/JSON/XS.pm line 2365
> >#Cpanel::JSON::XS::BEGIN() called at
> > /usr/lib/x86_64-linux-gnu/perl5/5.36/Cpanel/JSON/XS.pm line 2366
>
> Could this be https://github.com/rurban/Cpanel-JSON-XS/issues/198 in
> libcpanel-json-xs-perl?
Thanks! That bug didn't exist when I last looked :)
It's not quite the same thing but certainly looks related. I get the
overload warnings even with the older libjson-pp-perl bundled with
Perl 5.36:
% perl -we 'use Cpanel::JSON::XS (); use JSON::PP ()'
Subroutine JSON::PP::Boolean::(-- redefined at
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
Subroutine JSON::PP::Boolean::(0+ redefined at
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
Subroutine JSON::PP::Boolean::(++ redefined at
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
Reassigning. I assume Cpanel-JSON-XS is the place that needs a fix.
--
Niko
Bug#1016806: request-tracker5: FTBFS with Perl 5.36: Subroutine JSON::PP::Boolean::(0+ redefined
148 Non-zero exit status: 1 t/rest2/search-simple.t (Wstat: 256 (exited 1) Tests: 22 Failed: 1) Failed test: 22 Non-zero exit status: 1 t/rest2/search-json.t(Wstat: 256 (exited 1) Tests: 133 Failed: 1) Failed test: 133 Non-zero exit status: 1 t/rest2/searches.t (Wstat: 256 (exited 1) Tests: 134 Failed: 1) Failed test: 134 Non-zero exit status: 1 t/rest2/ticket-correspond-customroles.t (Wstat: 256 (exited 1) Tests: 74 Failed: 1) Failed test: 74 Non-zero exit status: 1 t/rest2/ticket-links.t (Wstat: 256 (exited 1) Tests: 32 Failed: 1) Failed test: 32 Non-zero exit status: 1 t/rest2/ticket-customroles.t (Wstat: 256 (exited 1) Tests: 185 Failed: 1) Failed test: 185 Non-zero exit status: 1 t/rest2/ticket-watchers.t(Wstat: 256 (exited 1) Tests: 134 Failed: 1) Failed test: 134 Non-zero exit status: 1 t/rest2/ticket-customfields.t(Wstat: 256 (exited 1) Tests: 345 Failed: 1) Failed test: 345 Non-zero exit status: 1 t/rest2/transaction-customfields.t (Wstat: 256 (exited 1) Tests: 43 Failed: 1) Failed test: 41 Non-zero exit status: 1 t/rest2/tickets-bulk.t (Wstat: 256 (exited 1) Tests: 53 Failed: 1) Failed test: 53 Non-zero exit status: 1 t/rest2/transactions.t (Wstat: 256 (exited 1) Tests: 82 Failed: 1) Failed test: 82 Non-zero exit status: 1 t/rest2/user-customfields.t (Wstat: 256 (exited 1) Tests: 81 Failed: 1) Failed test: 81 Non-zero exit status: 1 t/rest2/user-memberships.t (Wstat: 256 (exited 1) Tests: 31 Failed: 1) Failed test: 31 Non-zero exit status: 1 t/rest2/tickets.t(Wstat: 256 (exited 1) Tests: 371 Failed: 1) Failed test: 371 Non-zero exit status: 1 t/rest2/users.t (Wstat: 256 (exited 1) Tests: 47 Failed: 1) Failed test: 47 Non-zero exit status: 1 Files=510, Tests=39839, 747 wallclock secs ( 5.34 usr 0.67 sys + 1849.19 cusr 148.68 csys = 2003.88 CPU) Result: FAIL Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1016369: IO::Handle ->error does not work, always saying "fine"
On Sat, Aug 06, 2022 at 08:44:18PM +0100, Ian Jackson wrote:
> > The second issue (writing to /dev/full) is indeed fixed in sid / Perl
> > 5.34. It was https://github.com/Perl/perl5/issues/6799 and reportedly
> > only affects things like character devices (including /dev/full) and
> > sockets. I've verified that trying to write to a normal file on a full
> > filesystem does set the error() flag on stable / Perl 5.32.
>
> I wonder what is different about plain files. I suspect the fact that
> it "works" (correctly returning errors) for you in this case may be
> due to luck (the precise series of calls).
You might want to read the bug then, particularly Tony Cook's comment at
https://github.com/Perl/perl5/issues/6799#issuecomment-626511037
Quoting:
Perl's I/O objects (that is the IO SV , not PerlIO) can have both an
input (PerlIO) file handle and an output file handle. For files that
output handle is the same as the input handle [...] For a character
device (like /dev/full) or a socket, perl creates a second PerlIO
object on the same fd to use as the output handle, and that causes
the behaviour this ticket documents.
So I don't think luck has anything to do with it.
> > Downgrading the severity, but let me know what you think based on the above.
>
> I still think this is a data loss bug. (Two bugs.)
I think it's at most one but whatever.
I've just reported https://github.com/Perl/perl5/issues/20060 about the
read errors. You might want to do your convincing there if needed :)
Obviously it's not going to be fixed on Debian side without upstream
involvement, whatever the severity.
> > while ( ! eof($fh) ) {
> > defined( $_ = readline $fh ) or die "readline failed: $!";
> > ...
> > }
>
> I don't find this particularly convincing. This argument seems to be
> saying "never use <> to read lines" which is pretty strange. Surely
> it should be possible to use "<>" in its line-reading mode, without
> data loss.
Yeah, I agree.
--
Niko
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
Source: libhttp-daemon-perl Version: 6.14-1.1 Severity: important Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition X-Debbugs-Cc: Thorsten Alteholz It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1 (or at least the associated test case) has issues with newer versions of the HTTP::Tiny module. This includes the separately packaged one in sid (libhttp-tiny-perl_0.082-1) and the one bundled with Perl 5.36 (currently in experimental). Reproducible in current sid by passing something like --add-depends='libhttp-tiny-perl (>= 0.080)' to sbuild, triggering the installation of the separate package. >From my build log: Subroutine HTTP::Tiny::Handle::write_content_body redefined at t/content_length.t line 277. # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Looks like you failed 6 tests of 30. t/content_length.t . ok 1 - Hello World Request ... it works as expected ok 2 - ... and has expected status ok 3 - ... and body does match ok 4 - Positive Content Length not ok 5 - ... and has expected status not ok 6 - ... and body does match ok 7 - Negative Content Length not ok 8 - ... and has expected status not ok 9 - ... and body does match ok 10 - Non Integer Content Length not ok 11 - ... and has expected status not ok 12 - ... and body does match ok 13 - Explicit Content Length ... with exact length ok 14 - ... and has expected status ok 15 - ... and body does match ok 16 - Implicit Content Length ... will always pass ok 17 - ... and has expected status ok 18 - ... and body does match ok 19 - Shorter Content Length ... gets truncated ok 20 - ... and has expected status ok 21 - ... and body does match ok 22 - Different Content Length ... must fail ok 23 - ... and has expected status ok 24 - ... and body does match ok 25 - Underscore Content Length ... must match ok 26 - ... and has expected status ok 27 - ... and body does match ok 28 - Longer Content Length ... gets timeout ok 29 - ... and has expected status ok 30 - ... and body does match 1..30 Dubious, test returned 6 (wstat 1536, 0x600) Failed 6/30 subtests -- Niko Tyni nt...@debian.org
Bug#1016369: IO::Handle ->error does not work, always saying "fine"
Control: severity -1 normal Hi, thanks Ian for the report and Damyan for looking into the issues. On Sun, Jul 31, 2022 at 11:37:09AM +0300, Damyan Ivanov wrote: > -=| Ian Jackson, 30.07.2022 13:42:05 +0100 |=- > > Package: perl > > Version: 5.34.0-4 > > Severity: grave > > > > To reproduce > > > > perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = ; printf "%s > > %s %s\n", X->error(), $!;' > > perl -MIO::Handle -e 'open X, ">", "/dev/full" or die $!; print X 1; > > flush X; printf "%s %s %s\n", X->error(), $!; close X' > > > > Expected output > > > > -1 Bad file descriptor > > -1 No space left on device > > > > Actual output > > > > 0 Bad file descriptor > > 0 No space left on device FWIW I get 0 Is a directory 1 No space left on device on sid (perl_5.34.0-5). I'm not sure why you'd expect -1. The documentation for IO::Handle::error() only mentions it reporting a true value. The first issue (reading a directory as a plain file) seems to be about the error flag getting cleared when reading past EOF or something like that. According to my meager debugger skills, the clearing happens around https://sources.debian.org/src/perl/5.34.0-5/pp_hot.c/#L3278 As Damyan notes, you can detect this by checking for EOF before reading, although perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = if !X->eof(); printf "%s %s\n", X->error(), $!;' 1 Inappropriate ioctl for device is not quite what I'd expect either. Anyway, the data loss argument seems misplaced given we've read all the data there is when we are at EOF? I can see there is probably a bug around here, but it would be good to have an example test case that doesn't involve treating a directory as a plain file (which can have very varying results between different platforms) before taking this upstream. Particularly so if you want to argue it's as serious as claimed here. See also https://github.com/Perl/perl5/issues/12782 which has not received attention in almost ten years. The second issue (writing to /dev/full) is indeed fixed in sid / Perl 5.34. It was https://github.com/Perl/perl5/issues/6799 and reportedly only affects things like character devices (including /dev/full) and sockets. I've verified that trying to write to a normal file on a full filesystem does set the error() flag on stable / Perl 5.32. I think that makes the issue less severe, and I'm not very inclined to fix it in stable. But in case we end up doing that anyway, these would be the commits needed: https://github.com/Perl/perl5/commit/89341f87f9fc65c4d7133e497bb04586e86b8052 https://github.com/Perl/perl5/commit/8a2562bec7cd9f8eff6812f340f99028bb33 Downgrading the severity, but let me know what you think based on the above. -- Niko
Bug#1015014: libgrokj2k: FTBFS on many architectures
On Sun, Jul 17, 2022 at 01:31:00AM +, Aaron Boxer wrote: > Thanks for you bug update. I am guessing that the reason why > Grok no longer builds on these architectures is due to inclusion > of a library, Highway, for handling SIMD instructions. I don't believe > Highway supports the archs you mentioned. Can you elaborate on what you mean > by removing old binaries? As seen in on tracker.debian.org the testing migration of 9.7.5-1 is blocked because the binary packages from the last successful builds (version 7.6.6-3) are still around on the failing architectures. The package won't migrate until it either builds on those architectures again, or the old packages are removed from unstable. For more information on removal requests see https://wiki.debian.org/ftpmaster_Removals Hope this helps, -- Niko Tyni nt...@debian.org
Bug#1015014: libgrokj2k: FTBFS on many architectures
Source: libgrokj2k Version: 9.7.5-1 Severity: serious This package failed to build on armel, mips64el, mipsel, ppc64el and s390x, but built successfully on them in the past. In case these architectures are not supported, the old binaries should be removed. -- Niko Tyni nt...@debian.org
Bug#1015013: polymake: missing dependency on perlapi
Package: polymake
Version: 4.6-4
Severity: serious
This package ships a binary Perl module but does not depend on
perlapi-5.xx.
polymake:
/usr/lib/polymake/perlx/5.34.0/x86_64-linux-gnu-thread-multi/auto/Polymake/Ext/Ext.so
Probably the polymake package just needs a ${perl:Depends} entry rather
than / in addition to polymake-common.
--
Niko Tyni nt...@debian.org
Bug#1014930: irssi: FTBFS with Perl 5.36: ISO C90 forbids mixed declarations and code
Source: irssi Version: 1.4.1-1 Severity: normal Tags: ftbfs patch fixed-upstream Forwarded: https://github.com/irssi/irssi/issues/1381 User: debian-p...@lists.debian.org Usertags: perl-5.36-transition Hi, irssi_1.4.1-1 started building with -Werror=declaration-after-statement, which broke the build with Perl 5.36 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.36/irssi_1.4.1-1/irssi_1.4.1-1+b1_amd64-2022-07-11T15:30:44Z.build FAILED: src/perl/libperl_core.so.p/perl-signals.c.o cc -Isrc/perl/libperl_core.so.p -I. -I.. -Isrc/perl -I../src/perl -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/local/include -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -fdiagnostics-color=always -Wall -Winvalid-pch -O0 -Werror=declaration-after-statement -fno-strict-aliasing -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -pthread '-DSCRIPTDIR="/usr/share/irssi/scripts"' '-DPERL_USE_LIB=""' -DPERL_STATIC_LIBS=0 -MD -MQ src/perl/libperl_core.so.p/perl-signals.c.o -MF src/perl/libperl_core.so.p/perl-signals.c.o.d -o src/perl/libperl_core.so.p/perl-signals.c.o -c ../src/perl/perl-signals.c In file included from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/perl.h:7242, from ../src/perl/module.h:8, from ../src/perl/perl-signals.c:23: /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/inline.h: In function ‘Perl_cop_file_avn’: /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/inline.h:3489:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 3489 | const char *file = CopFILE(cop); | ^ cc1: some warnings being treated as errors ninja: build stopped: subcommand failed. dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v returned exit code 1 make: *** [debian/rules:12: binary-arch] Error 25 Dropping C89 support seems to be a conscious choice on the perl side with 5.36, see https://github.com/Perl/perl5/issues/19382 https://github.com/Perl/perl5/pull/19384 Reported on the irssi upstream side as https://github.com/irssi/irssi/issues/1381 and supposedly fixed with https://github.com/irssi/irssi/pull/1384 though I haven't verified that. Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1013526: libtickit-widget-scrollbox-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255
On Sun, Jul 03, 2022 at 05:20:17PM +0300, Niko Tyni wrote: > On Sat, Jun 25, 2022 at 10:09:46AM +0300, Damyan Ivanov wrote: > > Control: retitle -1 libtickit-widget-scrollbox-perl: intermittent memory > > corruption in t/02input-key.t and t/03input-mouse.t > > > > I can reproduce this when running 02input-key.t and 03input-key.t in > > a loop. The symptom is the same - "malloc_consolidate(): unaligned > > fastbin chunk detected" error message and the tests exits with Wstat > > 134 after saying "All 14 subtests passed". > > > > Wstat 134 is SIGABRT. Looks like a memory corruption of some sort. > > We're seeing this too in Perl 5.36 test rebuilds. Possibly it's even > more reproducible there, seems to always fail for us. > > > http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libtickit-widget-scrollbox-perl_0.11-1/libtickit-widget-scrollbox-perl_0.11-1_amd64-2022-06-14T06:54:08Z.build Update: I was able to build it on perl_5.36.0-2 / amd64, so apparently no real Perl 5.36 relation after all. -- Niko
Bug#1014286: perl/experimental: FTBFS on mips64el: test failures
Control: severity -1 normal On Sun, Jul 03, 2022 at 10:41:16PM +0300, Niko Tyni wrote: > On Sun, Jul 03, 2022 at 04:29:22PM +0300, Niko Tyni wrote: > > Source: perl > > Version: 5.36.0-1 > > Severity: serious > > Tags: ftbfs > > User: debian-p...@lists.debian.org > > Usertags: perl-5.36-transition > > X-Debbugs-Cc: debian-m...@lists.debian.org > > > > The perl package in experimental fails to build from source > > on mips64el. > > > > https://buildd.debian.org/status/package.php?p=perl&suite=experimental > > > > It looks like the perl binary dies with SIGSEGV in thread related tests > > during the test suite. This happened twice on different buildds. > > > > I'm running a test build now on eller.d.o to see if it's reproducible. > > The package builds fine for me on eller, though it failed twice in the > same way on the buildds (mipsel-osuosl-0[13]). > > @debian-mips: any ideas? Could somebody please check if the package > builds for you? We now have two successful builds on mips64el buildds, so presumably this is not a regression in perl. Lowering the severity for now. -- Niko Tyni nt...@debian.org
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
[apt-cacher maintainers: the context here is that URI.pm introduced an
optional dependency on Regexp::IPv6 by requiring it in an eval block,
but the apt-cacher __DIE__ handler exits when the require fails.]
On Mon, Jul 11, 2022 at 05:35:17PM +0200, gregor herrmann wrote:
> So we have:
> - do nothing
> - patch URI to restart the default signal handler in the eval
> - (reassign? and) do something in apt-cacher
I'm not really sure if there's a consensus on best practices around
$SIG{__DIE__}. IMO apt-cacher is the one that should be fixed, rather
than demanding that all the modules it uses need to reset and restore
$SIG{__DIE__} before catching exceptions.
>From 'perldoc -f die' :
You can arrange for a callback to be run just before the "die"
does its deed, by setting the $SIG{__DIE__} hook. The associated
handler is called with the exception as an argument, and can
change the exception, if it sees fit, by calling "die" again.
See "%SIG" in perlvar for details on setting %SIG entries, and
"eval" for some examples. Although this feature was to be run only
right before your program was to exit, this is not currently so:
the $SIG{__DIE__} hook is currently called even inside "eval"ed
blocks/strings! If one wants the hook to do nothing in such
situations, put
die @_ if $^S;
as the first line of the handler (see "$^S" in perlvar). Because
this promotes strange action at a distance, this counterintuitive
behavior may be fixed in a future release.
Corresponding untested patch against apt-cacher attached.
--
Niko Tyni nt...@debian.org
>From 33013c19088fa3a43e468ef41aa0d1298e63d233 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Mon, 11 Jul 2022 21:18:43 +0300
Subject: [PATCH] Handle eval blocks in unsuspecting libraries
$SIG{__DIE__} can get called from eval blocks - don't bail out if so.
Bug-Debian: https://bugs.debian.org/1014730
---
apt-cacher | 1 +
1 file changed, 1 insertion(+)
diff --git a/apt-cacher b/apt-cacher
index a8c00cb..8c1fe88 100755
--- a/apt-cacher
+++ b/apt-cacher
@@ -1253,6 +1253,7 @@ sub write_error_log {
}
sub die_handler {
+die @_ if $^S; # called from an eval block
my ($msg) = @_;
write_error_log("error [$$]: $msg");
sendrsp(HTTP::Response->new(502, 'apt-cacher internal error (died)', ['Connection' => 'close'])) if $con;
--
2.30.2
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
On Mon, Jul 11, 2022 at 10:36:30AM +0200, gregor herrmann wrote:
> On Mon, 11 Jul 2022 00:12:11 +0200, Robert Luberda wrote:
> > The following information is printed into apt-cacher.log:
> > Mon Jul 11 00:02:52 2022|error [18513]: Can't locate Regexp/IPv6.pm in @INC
> > (you may need to install the Regexp::
> > IPv6 module)
>
> Thanks for your bug report.
>
> I'm a bit surprised, because the new code in 5.11 should behave
> better if Regexp::IPv6 is not available:
apt-cacher is using $SIG{__DIE__}, which triggers even in eval blocks,
and doing an exit(1) from there.
https://sources.debian.org/src/apt-cacher/1.7.26/apt-cacher/#L2251
https://sources.debian.org/src/apt-cacher/1.7.26/apt-cacher/#L1259
I'd say this is not a bug in liburi-perl.
--
Niko Tyni nt...@debian.org
Bug#1014295: libwx-perl-processstream-perl: FTBFS with Perl 5.36: build hangs
Control: reassign -1 libwx-perl 1:0.9932-6
Control: retitle -1 libxwx-perl: Wx::InputStream::READLINE returns non-string
value
Control: tag -1 patch
Control: affects -1 libwx-perl-processstream-perl
(Full quote for context, see below for discussion.)
On Sun, Jul 03, 2022 at 05:29:36PM +0300, Niko Tyni wrote:
> Source: libwx-perl-processstream-perl
> Version: 0.32-1.1
> Tags: ftbfs
> User: debian-p...@lists.debian.org
> Usertags: perl-5.36-transition
>
> This package fails to build from source with Perl 5.36 (currently in
> experimental.)
>
> Build log at
>
>
> http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libwx-perl-processstream-perl_0.32-1.1/libwx-perl-processstream-perl_0.32-1.1_amd64-2022-06-13T09:38:04Z.build
>
> Excerpt:
>
> t/00-load.t
> 1..1
> ok 1 - use Wx::Perl::ProcessStream;
> ok
>
> # Failed test at t/01-events.t line 59.
> # got: undef
> # expected: '0'
>
> # Failed test at t/01-events.t line 80.
> # got: undef
> # expected: 'HELLO WORLD'
>
> # Failed test at t/01-events.t line 94.
> # got: undef
> # expected: 'HELLO WORLD'
>
> # Failed test at t/01-events.t line 117.
> # got: undef
> # expected: 'HELLO WORLD'
>
> # Failed test at t/01-events.t line 131.
> # got: undef
> # expected: 'HELLO WORLD'
>
> # Failed test at t/01-events.t line 152.
> # got: ''
> # expected: anything else
>
> # Failed test at t/01-events.t line 170.
> # got: ''
> # expected: 'ONE-TWO-THREE'
>
> # Failed test at t/01-events.t line 174.
> # got: ''
> # expected: 'FOUR'
>
> # Failed test at t/01-events.t line 192.
> # got: ''
> # expected: 'ECHO:TEST STDIN 1-TEST STDIN 2'
> E: Build killed with signal TERM after 150 minutes of inactivity
This seems to be a bug in libwx-perl, triggered by changes in
Perl 5.35.9 or so.
>From https://metacpan.org/dist/perl/view/pod/perldelta.pod#Internal-Changes :
Reading the string form of an integer value no longer sets the flag SVf_POK.
[...]
Here's a snippet that shows the changed behaviour:
#!/usr/bin/perl -w
use Test::More tests => 3;
use Devel::Peek;
use Inline C => <<'EOC';
SV * myString() {
SV *ret;
ret = newSViv(0);
char *buf = SvPV_nolen(ret);
buf[0] = '1';
return ret;
}
EOC
my $val = myString();
is($val, "1", "XS return value equals the string 1");
is($val, 1, "XS return value equals numeric 1");
ok($val, "XS return value is true");
Dump $val;
__END__
The return value is created as the integer zero, then its string buffer
is changed but the corresponding SvPOK flag is not set. This passes all
the three tests on sid / Perl 5.34 fails the last one with Perl 5.36.
The Dump output shows
- FLAGS = (IOK,POK,pIOK,pPOK)
+ FLAGS = (IOK,pIOK,pPOK)
and explicitly declaring the variable a valid string by adding an
SvPOK_on(ret) call fixes the tests.
The above snippet was adapted from the Wx::InputStream::READLINE() method
in libwx-perl, which has the same issue. The Wx::Perl::ProcessStream
test suite tests if the return value is set, but sees it evaluate to
false and assumes an early EOF, breaking the tests.
Proposed patch attached. I've tested that it fixes the test suite with
Perl 5.36 without breaking it on sid / 5.34.
--
Niko Tyni nt...@debian.org
>From 41bcb4f309b5a8f13dfa9c6d417369938cbe6060 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sun, 10 Jul 2022 16:53:10 +0100
Subject: [PATCH] Explicitly return a string SV from Wx::InputStream::READLINE
Perl 5.35.9 changed SV integer / string handling slightly, resulting in
the return value from READLINE() to evaluate as false regardless of its
string contents, because it is initially created as the integer 0 and no
longer gets marked as a valid string. This broke the Wx-Perl-ProcessStream
distribution test suite.
Fix the regression by explicitly setting SvPOK on the return value,
mirroring the sibling READ() method.
Bug-Debian: https://bugs.debian.org/1014295
---
XS/Stream.xs | 1 +
1 file changed, 1 insertion(+)
diff --git a/XS/Stream.xs b/XS/Stream.xs
index b6ef184..f680394 100644
--- a/XS/Stream.xs
+++ b/XS/Stream.xs
@@ -97,6 +97,7 @@ Wx_InputStream::READLINE()
if( THIS->Eof() ) { XSRETURN_UNDEF; }
RETVAL = newSViv( 0 );
buff = SvPV_nolen( RETVAL );
+SvPOK_on( RETVAL );
while( THIS->CanRead() && THIS->Read( &c, 1 ).LastRead() != 0 )
{
--
2.35.2
Bug#1014286: perl/experimental: FTBFS on mips64el: test failures
On Sun, Jul 03, 2022 at 04:29:22PM +0300, Niko Tyni wrote: > Source: perl > Version: 5.36.0-1 > Severity: serious > Tags: ftbfs > User: debian-p...@lists.debian.org > Usertags: perl-5.36-transition > X-Debbugs-Cc: debian-m...@lists.debian.org > > The perl package in experimental fails to build from source > on mips64el. > > https://buildd.debian.org/status/package.php?p=perl&suite=experimental > > It looks like the perl binary dies with SIGSEGV in thread related tests > during the test suite. This happened twice on different buildds. > > I'm running a test build now on eller.d.o to see if it's reproducible. The package builds fine for me on eller, though it failed twice in the same way on the buildds (mipsel-osuosl-0[13]). @debian-mips: any ideas? Could somebody please check if the package builds for you? -- Niko Tyni nt...@debian.org
Bug#1014296: polymake: FTBFS with Perl 5.36: HVhek_UNSHARED’ was not declared in this scope
Source: polymake
Version: 4.6-3
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition
This package fails to build from source with Perl 5.36 (currently in
experimental.)
Build log at
http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/polymake_4.6-3/polymake_4.6-3_amd64-2022-06-09T09:42:58Z.build
Excerpt:
FAILED:
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o
g++ -c -o
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o
-MMD -MT
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o
-MF
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.o.d
-fPIC -pipe -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow
-Wno-array-bounds -Wno-maybe-uninitialized -Wno-free-nonheap-object
-DPOLYMAKE_WITH_FLINT -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DPerlVersion=5360 -Wno-nonnull
-I/<>/include/core-wrappers -I/<>/include/core
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RefHash.cc &&
: 'COMPILER_USED=11.3.0'
/<>/lib/core/src/perl/RefHash.xxs: In member function ‘SV*
pm::perl::glue::{anonymous}::tmp_keysv::set(SV*)’:
/<>/lib/core/src/perl/RefHash.xxs:74:22: error: ‘HVhek_UNSHARED’
was not declared in this scope; did you mean ‘HVhek_NOTSHARED’?
74 |HEK_FLAGS(hekp) = HVhek_UNSHARED;
| ^~
| HVhek_NOTSHARED
[954/965] g++ -c -o
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o
-MMD -MT
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o
-MF
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.o.d
-fPIC -pipe -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow
-Wno-array-bounds -Wno-maybe-uninitialized -Wno-free-nonheap-object
-DPOLYMAKE_WITH_FLINT -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DPerlVersion=5360 -Wno-nonnull
-I/<>/include/core-wrappers -I/<>/include/core
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/Poly.cc && :
'COMPILER_USED=11.3.0'
[955/965] g++ -c -o
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o
-MMD -MT
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o
-MF
/<>/build/Opt/lib/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.o.d
-fPIC -pipe -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow
-Wno-array-bounds -Wno-maybe-uninitialized -Wno-free-nonheap-object
-DPOLYMAKE_WITH_FLINT -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2
-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DPerlVersion=5360 -Wno-nonnull
-I/<>/include/core-wrappers -I/<>/include/core
/<>/build/perlx/5.36.0/x86_64-linux-gnu-thread-multi/RuleGraph.cc
&& : 'COMPILER_USED=11.3.0'
ninja: build stopped: subcommand failed.
make[1]: *** [debian/rules:56: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:35: build] Error 2
--
Niko Tyni nt...@debian.org
Bug#1014295: libwx-perl-processstream-perl: FTBFS with Perl 5.36: build hangs
Source: libwx-perl-processstream-perl Version: 0.32-1.1 Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition This package fails to build from source with Perl 5.36 (currently in experimental.) Build log at http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libwx-perl-processstream-perl_0.32-1.1/libwx-perl-processstream-perl_0.32-1.1_amd64-2022-06-13T09:38:04Z.build Excerpt: t/00-load.t 1..1 ok 1 - use Wx::Perl::ProcessStream; ok # Failed test at t/01-events.t line 59. # got: undef # expected: '0' # Failed test at t/01-events.t line 80. # got: undef # expected: 'HELLO WORLD' # Failed test at t/01-events.t line 94. # got: undef # expected: 'HELLO WORLD' # Failed test at t/01-events.t line 117. # got: undef # expected: 'HELLO WORLD' # Failed test at t/01-events.t line 131. # got: undef # expected: 'HELLO WORLD' # Failed test at t/01-events.t line 152. # got: '' # expected: anything else # Failed test at t/01-events.t line 170. # got: '' # expected: 'ONE-TWO-THREE' # Failed test at t/01-events.t line 174. # got: '' # expected: 'FOUR' # Failed test at t/01-events.t line 192. # got: '' # expected: 'ECHO:TEST STDIN 1-TEST STDIN 2' E: Build killed with signal TERM after 150 minutes of inactivity -- Niko Tyni nt...@debian.org
Bug#1014294: libtap-formatter-junit-perl: FTBFS with Perl 5.36: Failed test 't/data/tests/bailout'
Source: libtap-formatter-junit-perl Version: 0.11-1.1 Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition This package fails to build from source with Perl 5.36 (currently in experimental.) Build log at http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libtap-formatter-junit-perl_0.11-1.1/libtap-formatter-junit-perl_0.11-1.1_amd64-2022-06-09T01:27:50Z.build Excerpt: Building TAP-Formatter-JUnit dh_auto_test dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 in use) /usr/bin/perl Build test --verbose 1 # Failed test 't/data/tests/bailout' # at t/formatter.t line 40. # During compare: # no element found at line 1, column 0, byte -1 # Looks like you failed 1 test of 22. t/formatter.t . 1..22 ok 1 - t/data/tests/bad_chars not ok 2 - t/data/tests/bailout ok 3 - t/data/tests/descriptive ok 4 - t/data/tests/descriptive_trailing ok 5 - t/data/tests/die ok 6 - t/data/tests/die_head_end ok 7 - t/data/tests/die_last_minute ok 8 - t/data/tests/die_unfinished ok 9 - t/data/tests/empty ok 10 - t/data/tests/no_nums ok 11 - t/data/tests/simple ok 12 - t/data/tests/simple_fail ok 13 - t/data/tests/simple_yaml ok 14 - t/data/tests/skip ok 15 - t/data/tests/skip_nomsg ok 16 - t/data/tests/skipall ok 17 - t/data/tests/skipall_nomsg ok 18 - t/data/tests/stdout_stderr ok 19 - t/data/tests/todo ok 20 - t/data/tests/todo_inline ok 21 - t/data/tests/todo_misparse ok 22 - t/data/tests/too_many Dubious, test returned 1 (wstat 256, 0x100) Failed 1/22 subtests -- Niko Tyni nt...@debian.org
Bug#1013526: libtickit-widget-scrollbox-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255
Control: user debian-p...@lists.debian.org Control: usertag -1 perl-5.36-transition On Sat, Jun 25, 2022 at 10:09:46AM +0300, Damyan Ivanov wrote: > Control: retitle -1 libtickit-widget-scrollbox-perl: intermittent memory > corruption in t/02input-key.t and t/03input-mouse.t > > I can reproduce this when running 02input-key.t and 03input-key.t in > a loop. The symptom is the same - "malloc_consolidate(): unaligned > fastbin chunk detected" error message and the tests exits with Wstat > 134 after saying "All 14 subtests passed". > > Wstat 134 is SIGABRT. Looks like a memory corruption of some sort. We're seeing this too in Perl 5.36 test rebuilds. Possibly it's even more reproducible there, seems to always fail for us. http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libtickit-widget-scrollbox-perl_0.11-1/libtickit-widget-scrollbox-perl_0.11-1_amd64-2022-06-14T06:54:08Z.build -- Niko Tyni nt...@debian.org
Bug#1014293: libcpan-reporter-smoker-perl: FTBFS with Perl 5.36: tries to smoke the whole CPAN during build
Source: libcpan-reporter-smoker-perl Version: 0.29-2 Tags: ftbfs upstream User: debian-p...@lists.debian.org Usertags: perl-5.36-transition This package fails to build from source with Perl 5.36 (currently in experimental.) Build log at http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libcpan-reporter-smoker-perl_0.29-2/libcpan-reporter-smoker-perl_0.29-2_amd64-2022-06-13T03:37:58Z.build It looks like the build times out because the test suite tries to test the whole CPAN. I believe this is because of the recent mitigations for CPAN checksums vulnerabilities. http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html [CPAN.pm 2.29] now ignores any previously configured urllist and only uses cpan.org. If you want it to honour the urllist parameter instead, you must set the new pushy_https parameter to false. I assume but haven't tested that setting pushy_https => 0 in t/data/MyConfig.pm will fix this. Upstream is most probably affected similarly as there are no test reports for CPAN-Reporter-Smoker since Perl 5.35.6. -- Niko Tyni nt...@debian.org
Bug#1014291: libaudio-ecasound-perl: FTBFS with Perl 5.36: test failure
Source: libaudio-ecasound-perl Version: 1.01-4 Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition This package fails to build from source with Perl 5.36 (currently in experimental.) Build log at http://perl.debian.net/rebuild-logs/perl-5.36/libaudio-ecasound-perl_1.01-4/libaudio-ecasound-perl_1.01-4+b5_amd64-2022-06-10T00:27:14Z.build Excerpt: t/ecasound.t .. 1..46 # Running under perl version 5.036000 for linux # Current time local: Fri Jun 10 00:27:31 2022 # Current time GMT: Fri Jun 10 00:27:31 2022 # Using Test.pm version 1.31 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 not ok 15 ok 16 ok 17 ok 18 ok 19 ok 20 ok 21 ok 22 ok 23 ok 24 ok 25 ok 26 ok 27 ok 28 ok 29 ok 30 ok 31 ok 32 ok 33 ok 34 ok 35 ok 36 ok 37 ok 38 ok 39 ok 40 ok 41 ok 42 ok 43 ok 44 ok 45 ok 46 Failed 1/46 subtests -- Niko Tyni nt...@debian.org
Bug#1014292: cyrus-imapd: FTBFS with Perl 5.36: expected expression before ‘{’ token
Source: cyrus-imapd
Version: 3.6.0~beta2-3
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition
This package fails to build from source with Perl 5.36 (currently in
experimental.)
Build log at
http://perl.debian.net/rebuild-logs/perl-5.36/cyrus-imapd_3.6.0~beta2-3/cyrus-imapd_3.6.0~beta2-3+b2_amd64-2022-06-09T23:06:23Z.build
Excerpt:
x86_64-linux-gnu-gcc -c -I../../../lib -I../../../perl/sieve
-I../../../perl/sieve/lib -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC
"-I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE" -DPERL_POLLUTE managesieve.c
In file included from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/perl.h:3855,
from managesieve.xs:46:
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/sv_inline.h: In function
‘Perl_newSV_type’:
../../../lib/assert.h:47:25: error: expected expression before ‘{’ token
47 | #define assert(ex) {if (!(ex))assertionfailed(__FILE__,
__LINE__, #ex);}
| ^
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/handy.h:2787:28: note: in expansion
of macro ‘assert’
2787 | #define perl_assert_ptr(p) assert( ((void*)(p)) != 0 )
|^~
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/handy.h:2792:47: note: in expansion
of macro ‘perl_assert_ptr’
2792 | #define Zero(d,n,t) (MEM_WRAP_CHECK_(n,t) perl_assert_ptr(d),
(void)memzero((char*)(d), (n) * sizeof(t)))
| ^~~
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/sv_inline.h:468:13: note: in
expansion of macro ‘Zero’
468 | Zero(new_body, type_details->body_size, char);
| ^~~~
make[4]: *** [Makefile:346: managesieve.o] Error 1
--
Niko Tyni nt...@debian.org
Bug#1014290: libgrokj2k: FTBFS with Perl 5.36: macro "utf8_to_utf16" requires 4 arguments, but only 1 given
Source: libgrokj2k Version: 9.7.5-1 Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition This package fails to build from source with Perl 5.36 (currently in experimental). Build log at http://perl.debian.net/rebuild-logs/perl-5.36/libgrokj2k_9.7.5-1/libgrokj2k_9.7.5-1+b1_amd64-2022-06-10T01:11:12Z.build Excerpt: [ 68%] Building CXX object src/bin/jp2/CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o cd /<>/obj-x86_64-linux-gnu/src/bin/jp2 && /usr/bin/c++ -DSPDLOG_COMPILED_LIB -I/<>/obj-x86_64-linux-gnu/src/lib/jp2 -I/<>/obj-x86_64-linux-gnu/src/bin/common -I/<>/src/lib/jp2 -I/<>/src/bin/common -I/<>/src/bin/image_format -I/<>/src/bin/jp2 -I/<>/src/include -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wconversion -Wsign-conversion -Wunused-parameter -std=gnu++20 -MD -MT src/bin/jp2/CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o -MF CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o.d -o CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o -c /<>/src/bin/common/exif.cpp In file included from /<>/src/include/spdlog/fmt/fmt.h:25, from /<>/src/include/spdlog/common.h:45, from /<>/src/include/spdlog/spdlog.h:12, from /<>/src/bin/common/exif.cpp:38: /<>/src/include/spdlog/fmt/bundled/format.h:1193:47: error: macro "utf8_to_utf16" requires 4 arguments, but only 1 given 1193 | FMT_API explicit utf8_to_utf16(string_view s); | ^ In file included from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/regexp.h:21, from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/perl.h:4156, from /<>/src/bin/common/exif.cpp:31: /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/utf8.h:89: note: macro "utf8_to_utf16" defined here 89 | #define utf8_to_utf16(p, d, bytelen, newlen) \ | In file included from /<>/src/include/spdlog/fmt/fmt.h:25, from /<>/src/include/spdlog/common.h:45, from /<>/src/include/spdlog/spdlog.h:12, from /<>/src/bin/common/exif.cpp:38: /<>/src/include/spdlog/fmt/bundled/format.h:1193:20: error: declaration does not declare anything [-fpermissive] 1193 | FMT_API explicit utf8_to_utf16(string_view s); |^~~~~ make[3]: *** [src/bin/jp2/CMakeFiles/grk_decompress.dir/build.make:247: src/bin/jp2/CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o] Error 1 -- Niko Tyni nt...@debian.org
Bug#1014289: vile: FTBFS with Perl 5.36: ‘regexp_aligned’ undeclared here
Source: vile
Version: 9.8v-2
Severity: normal
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.36-transition
This package fails to build from source with Perl 5.36 (currently in
experimental).
Build log at
http://perl.debian.net/rebuild-logs/perl-5.36/vile_9.8v-2/vile_9.8v-2+b1_amd64-2022-06-10T06:32:17Z.build
Excerpt:
gcc -c -I. -I../.. -DHAVE_CONFIG_H -I../../filters -Wdate-time
-D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=500 -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/lib/x86_64-linux-gnu/perl/5.36/CORE
-DPROGRAM_NAME=\"vile\" -DVILE_ICON=\"icons/\"
-DVILE_LIBDIR_PATH=\"/usr/lib/x86_64-linux-gnu/vile\"
-DVILE_STARTUP_PATH=\"/usr/share/vile\" -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -fwrapv
-fno-strict-aliasing -pipe -rdynamic -Werror=format-security
-DHELP_LOC=\"/usr/share/vile\" perl.c
../../perl.xs:24:32: warning: unknown option after ‘#pragma GCC diagnostic’
kind [-Wpragmas]
24 | #pragma GCC diagnostic ignored "-Wcompound-token-split-by-macro"
|^
In file included from /usr/lib/x86_64-linux-gnu/perl/5.36/CORE/perl.h:7243,
from ../../perl.xs:132:
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/sv_inline.h:241:32: error:
‘regexp_aligned’ undeclared here (not in a function); did you mean
‘regexp_engine’?
241 | { sizeof(ALIGNED_TYPE_NAME(regexp)),
|^~
/usr/lib/x86_64-linux-gnu/perl/5.36/CORE/sv_inline.h:135:33: note: in
definition of macro ‘ALIGNED_TYPE_NAME’
135 | #define ALIGNED_TYPE_NAME(name) name##_aligned
| ^~~~
make[1]: *** [makefile:135: perl.o] Error 1
make[1]: Leaving directory '/<>/t/vile'
make: *** [debian/rules:36: build-stamp] Error 2
--
Niko Tyni nt...@debian.org
Bug#1014286: perl/experimental: FTBFS on mips64el: test failures
Source: perl Version: 5.36.0-1 Severity: serious Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition X-Debbugs-Cc: debian-m...@lists.debian.org The perl package in experimental fails to build from source on mips64el. https://buildd.debian.org/status/package.php?p=perl&suite=experimental It looks like the perl binary dies with SIGSEGV in thread related tests during the test suite. This happened twice on different buildds. I'm running a test build now on eller.d.o to see if it's reproducible. Copying the debian-mips list. Help from porters would be welcome. -- Niko Tyni nt...@debian.org
Bug#1014282: perl: autopkgtest failure: needs Provides/Replaces/Breaks for libtext-balanced-perl
Source: perl Version: 5.34.0-4 Severity: serious Control: block -1 by 1014280 The perl package recently started failing its autopkgtest checks in testing. # Failed test 'no potential packages for new Provides/Replaces/Breaks found in the archive' # at debian/t/control.t line 303. # got: 'libtext-balanced-perl' # expected: '' # Looks like you failed 1 test of 590. debian/t/control.t .. This is because libtext-balanced-perl got introduced in the archive and we need to add corresponding metadata for it in the perl package. A complication is that pdl has added an unversioned dependency on libtext-balanced-perl while it really needs a newer one. So making the perl core packages Provide libtext-balanced-perl will break pdl. I've filed a separate bug about this, and would prefer to have pdl changed first. -- Niko Tyni nt...@debian.org
Bug#1014280: pdl: please make the libtext-balanced-perl dependency versioned
Package: pdl Version: 1:2.080-2 The recent addition of libtext-balanced-perl in the archive has broken the src:perl autopkgtest checks, because perl doesn't currently have the Breaks/Replaces/Provides entries for libtext-balanced-perl and the autopkgtest checks notice that. These entries are long established practice for dual life modules, primarily making sure that outdated versions of separate packages can not override newer versions in the core packages. This is not a concern currently, given Text::Balanced 2.06 is not in core yet, but it would be good to add the metadata in advance for consistency. However, pdl currently has an unversioned dependency on libtext-balanced-perl, so if I make perl Provide libtext-balanced-perl (= 2.04), that will satisfy the pdl dependency even though pdl actually needs the newer version (I understand this was the main reason for introducing the separate package in the first place.) So, please make the pdl dependency (both build and run time if applicable) versioned so I can add the metadata on the perl side after that. This has some urgency as perl is currently failing its autopkgtest checks in testing. I'll file a separate bug about that and mark it as blocked by this one. The autopkgtest issue could also be worked around by whitelisting libtext-balanced-perl temporarily, but I'd prefer a long term fix if possible. Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#1007717: Ballot and call for votes
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote: > BEGIN BALLOT > > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: > > 1. It is not a bug of any severity for a package with a non-native > version number to use a native source package format. > > 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise > complain, when a non-native version number is used w/ 3.0 (native). > > 3. We suggest that the wontfix tag on #737634 be reconsidered. > > 4a. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > > This is because there is currently no other source format which is > such that avoid both (i) uploading the whole source, including > upstream, for every upload; and (ii) having to maintain > debian/patches/ inside the package tree. > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances, to simplify the contents of the archive. > > This is because ... [second paragraph as in 4a]. > > 5. We decline to comment on the recent source package format MBF. > > Option A -- issue items 1-3, 4a and 5 > > Option C -- issue items 1-3, 4c and 5 > > Option X -- issue only items 1, 2, 3 and 5 > > Option N -- none of the above. > > END BALLOT I vote: C > A > X > N -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#1012073: perl: restoring default signal handler may warn with 'SIGTERM handler "DEFAULT" not defined'
On Sun, May 29, 2022 at 05:38:40PM +, Damyan Ivanov wrote:
> Package: perl
> Version: 5.34.0-4
> Severity: normal
> While infestigating a random FTBFS in starlet (#923829), it appeared to me
> that
> the problem is actually in perl.
> # Failed test 'No warnings'
> # at t/12bad_request_line.t line 24.
> # SIGTERM handler "DEFAULT" not defined.
> # at /usr/share/perl5/Parallel/Prefork.pm line 71.
> # Parallel::Prefork::start(Parallel::Prefork=HASH(0x55cd856355b8)) called
> at .../lib/Plack/Handler/Starlet.pm line 78
> #
> Plack::Handler::Starlet::run(Plack::Handler::Starlet=HASH(0x55cd849b0ad8),
> CODE(0x55cd8562ac98)) called at t/12bad_request_line.t line 28
> # main::__ANON__(33415) called at /usr/share/perl5/Test/TCP.pm line 100
> # Test::TCP::start(Test::TCP=HASH(0x55cd8562aed8)) called at
> /usr/share/perl5/Test/TCP.pm line 82
> # Test::TCP::new("Test::TCP", "code", CODE(0x55cd8562aab8)) called at
> /usr/share/perl5/Test/TCP.pm line 28
> # Test::TCP::test_tcp("client", CODE(0x55cd854306b0), "server",
> CODE(0x55cd8562aab8)) called at t/12bad_request_line.t line 31
> # Looks like you failed 1 test of 2.
> t/12bad_request_line.t .. Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/2 subtests
Just a quick reply that a smaller reproducer would obviously help.
FWIW this looks somewhat similar to
https://github.com/perl/perl5/issues/10913
but I assume the 'prefork' references mean threads are not involved
here. So perhaps unrelated after all.
--
Niko
Bug#1010287: libnet-ssleay-perl: FTBFS: bad line in substvars file debian/libnet-ssleay-perl.substvars at line 2
Control: reassign -1 perl-openssl-defaults 5 Control: tag -1 sid bookworm Control: retitle -1 perl-openssl-defaults: generated substvar should not end in a newline Control: affects -1 src:libnet-ssleay-perl On Wed, Apr 27, 2022 at 03:28:06PM -0700, Daniel Schepler wrote: > Source: libnet-ssleay-perl > Version: 1.92-1 > Severity: serious > dpkg-shlibdeps: error: bad line in substvars file > debian/libnet-ssleay-perl.substvars at line 2 > dh_shlibdeps: error: dpkg-shlibdeps > -Tdebian/libnet-ssleay-perl.substvars > debian/libnet-ssleay-perl/usr/lib/x86_64-linux-gnu/perl5/5.34/auto/Net/SSLeay/SSLeay.so > returned exit code 255 > Looking at the file it's complaining about, > debian/libnet-ssleay-perl.substvars contains: > > perl:Depends=perl, perl-openssl-abi-1.1 > , perlapi-5.34.0 > > (My best guess would be that this is a bug in perl-openssl-defaults / > dh_perl_openssl, but it's just a guess...) Thanks. Looks like Debian::Debhelper::Dh_Lib::addsubstvar no longer strips newlines from substvar values. I think it regressed with debhelper 13.7, probably https://salsa.debian.org/debian/debhelper/-/commit/99892be481c1dd06d9866854a2c14e6a70ae12b7 That said, I think this should be fixed in perl-openssl-defaults by not putting the newline there in the first place. Copying Niels; you might want to restore the newline handling if there are other affected addsubstvar users. If not, I wonder if debhelper should Break perl-openssl-defaults (<= 5) once we have fixed this. -- Niko Tyni nt...@debian.org
Bug#1003653: Revision of removal of rename.ul from package util-linux
On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote: > ===Begin Resolution A > The Technical Committee overrides the util-linux maintainer, and requires > that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary > package built from src:util-linux. The package containing rename.ul must not > conflict with the rename package nor divert /usr/bin/rename. > ===End Resolution A > > ===Begin Resolution B > The Technical Committee overrides the util-linux maintainer, and requires > that util-linux's rename should be shipped in a binary package built from > src:util-linux. If this package Conflicts with the rename package, then it > must not contain any other binaries. > ===End Resolution B > > ===Begin Resolution N > None of the above > ===End Resolution N Sorry for the delay. I vote: A > N > B -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#1008939: use.t: allow empty lines in debian/tests/pkg-perl/use-name? (also use-whitelist)
On Mon, Apr 04, 2022 at 08:07:37PM +0200, gregor herrmann wrote:
> Package: pkg-perl-autopkgtest
> Version: 0.66
> Severity: important
> Tags: patch
> X-Debbugs-Cc: nt...@debian.org
> This is a kind of followup for #1008267:
> not ok 5 - /usr/bin/perl -w -M"" -e 1 2>&1 exited successfully
> not ok 6 - /usr/bin/perl -w -M"" -e 1 2>&1 produced no (non-whitelisted)
> output
> % cat debian/tests/pkg-perl/use-name
> # Chart.pm is only documentation. Let's check Chart::Base.
> Chart::Base
>
> # other options
> # Chart::Bars
> # Chart::Composite
> For now I've removed the empty line in libchart-perl's
> debian/tests/pkg-perl/use-name but as this has potential for breaking
> other packages' autopkgtests and is also counter-intuitive, I suggest
> we accept and ignore empty lines in debian/tests/pkg-perl/use-name
> (and also debian/tests/pkg-perl/use-whitelist).
Yeah, absolutely. Thanks for noticing this.
> Proposed patch:
>
> #v+
> - --- /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t.packaged
> 2022-04-04 17:48:42.204873999 +
> +++ /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t2022-04-04
> 17:51:26.125604484 +
> @@ -39,7 +39,7 @@
> or BAIL_OUT("$conffile exists but can't be read");
> while () {
> chomp;
> - -next if /^\s*#/;
> +next if /^\s*(#|$)/;
> push @ret, $_;
> }
> close M;
> #v-
I'd phrase this as an additional 'next if !/\S/;' myself but whatever
works is fine by me :)
--
Niko
Bug#1008267: pkg-perl-autopkgtest: use.t: reading debian/tests/pkg-perl/use-whitelist too restrained?
On Fri, Mar 25, 2022 at 06:25:16PM +0100, gregor herrmann wrote: > Package: pkg-perl-autopkgtest > Version: 0.34 > Severity: normal > I just had an issue with our use.t and > debian/tests/pkg-perl/use-whitelist, and after reading the code, it > seems to me that there is a bug (since forever). What I did was to > add a second warning I wanted to ignore to use-whitelist, and > autopkgtest still failed, so I added a few print statements to use.t > and found that it only had one word from the whitelist file. Thanks for catching this. Reading #845771 I think it was intentionally just one line. OTOH the documentation in autopkgtest.pod has always said "expected warnings can be listed as regular expressions", where the plural does not correspond to reality. So there is a bug, we just need to decide where :) I suppose all use cases could be expressed in one regexp with '|' alternation, but allowing multiple lines with separate comments gives a much cleaner and self documenting file. So I'm all for that. > Now even if only reading one line is ok, as this is used as a regexp > in line 106, /(\S+)/ seems a bit, hm, minimalistic. I assume you're referring to not allowing whitespace in the pattern? Yeah I think that's a bug. I think I'd prefer to keep all whitespace and any other words on the same line. Not sure how much we need to worry about compatibility with existing files with currently ignored whitespace or multiple words. Also, while looking at the code, I can't see any reason for limiting use-name to just one name either. The main test already handles multiple modules if they come from @ARGV. Similarly for whitespace in use-name. The name is interpolated into a shell command, but \S doesn't protect from anything and the source package can run arbitrary code inside the testbed by design. I've filed MR !16 with a lightly tested fix. Please review and feel free to merge if it looks good. https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/-/merge_requests/16 -- Niko
Bug#996953: perl: make -j72 failing with a text file busy error
Control: tag -1 patch confirmed On Wed, Feb 16, 2022 at 12:57:11PM +0100, gypt...@gyptazy.ch wrote: > I can confirm this issue when rebuilding Perl on powerful systems. Multiple > builds of ‚generate_uudmap.o‘ are > created during the compile time and at some point it fails with: > > make -j88 […] > ./generate_uudmap uudmap.h bitcount.h mg_data.h > 6584make[3]: ./generate_uudmap: Text file busy > 6585make[3]: *** [Makefile:329: bitcount.h] Error 127 > > As a result, I patched the ‚rules‘ file to run ‚dh_auto_build‘ with > ‚--no-parallel‘ option. Thanks. This seems to be a build system corner case that only happens when the Configure run is split in two with -E and -S, which we do for the benefit of cross builds. I think it can be fixed by injecting a 'make depend' call at the end of debian/config.debian, mimicking what Configure does when run "normally" with -e. That would be preferrable to the dh --no-parallel workaround as it would not slow the builds. Could you please try if the attached patch fixes it? -- Niko Tyni nt...@debian.org >From 26b11231d66447ae0ed0d3ba032ae1b0523a26c0 Mon Sep 17 00:00:00 2001 From: Niko Tyni Date: Tue, 1 Mar 2022 21:17:00 +0200 Subject: [PATCH] Fix massively parallel builds by first making depend This is what Configure does at the end when run "normally" with -e. The Makefile dependencies are not quite robust for parallel builds if generate_uudmap is not pre-built (which happens during the 'make depend' phase.) Closes: #996953 --- debian/config.debian | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/config.debian b/debian/config.debian index e27858c07..7afc379e7 100644 --- a/debian/config.debian +++ b/debian/config.debian @@ -242,6 +242,9 @@ fi # now continue with extracting Makefile et al. /bin/bash ./Configure -S $crossargs +# mimic what 'Configure -e' does, unbreaking parallel builds (#996953) +make depend + # append PERL_BUILD_DATE before the last #endif in config.h # massive quoting problems prevent passing this to Configure sed -i "\$i #define PERL_BUILD_DATE \"$PERL_BUILD_DATE\"" config.h -- 2.30.2
Bug#1006280: perl: panic on s///gre with tainted utf8 strings
Control: forwarded -1 https://github.com/Perl/perl5/issues/19478 On Tue, Feb 22, 2022 at 06:37:48PM +0100, Kacper Gutowski wrote: > Package: perl > Version: 5.34.0-3 > Severity: normal > > Sometimes when doing s///gre on tainted utf8 string, perl warns about > malformed UTF-8 characters or outright panics. Hi, thanks for the report. I've just forwarded this upstream. -- Niko Tyni nt...@debian.org
Bug#1002541: libio-async-perl: autopkgtest regression on ppc64el: Parse errors: No plan found in TAP output
(Paul: this is just FYI for now; tested patches will follow eventually
in a proper bug report.
See https://bugs.debian.org/1002541 for more context.)
On Fri, Jan 21, 2022 at 06:12:51PM +0100, gregor herrmann wrote:
> > So t/70future-io.t fails consistently since it is run (0.800-2 and
> > 0.801-1). But only on ppc64el.
>
> And libfuture-io-perl has the same problem: The tests fail on
> ppc64el:
Both of these issues are a test-only wrong expectation on stdio buffer
sizes, which seem to differ on the ppc64el architecture.
The attached test program (pardon my C) makes a pair of nonblocking
pipes, writes to one end until it's full and then reads from the other
end until writes don't block anymore.
The output (see below) indicates that on my amd64 host it takes 64kB
to fill the pipe, and reading 4kB out is enough to unblock it. This
(particularly the 4kB part) is what the tests in libio-async-perl and
libfuture-io-perl are expecting.
However, on ppc64el it takes 1MB to fill the pipe, and 64kB to unblock it.
The tests fail because they only read 4kB out and expect writes to
work again.
Patches need to go around
https://sources.debian.org/src/libfuture-io-perl/0.11-1/lib/Test/Future/IO/Impl.pm/#L302
https://sources.debian.org/src/libio-async-perl/0.801-1/t/70future-io.t/#L59
but I don't have anything finished atm and I'm out of time for now.
Note that the test in libio-async-perl also uses the one in
Test::Future::IO::Impl,
so both fixes are needed to make libio-async-perl pass.
amd64:
PIPE_BUF: 4096
making nonblocking pipes
writing until it blocks
wrote 16 * 4096 bytes
reading out until write no longer blocks
read 1 * 4096 bytes
ppc64el (plummer.debian.org):
PIPE_BUF: 4096
making nonblocking pipes
writing until it blocks
wrote 256 * 4096 bytes
reading out until write no longer blocks
read 16 * 4096 bytes
--
Niko Tyni nt...@debian.org
#include
#include
#include
#include
#include
#include
int main(void) {
int fds[2];
int i;
char r_buf[PIPE_BUF];
char w_buf[PIPE_BUF];
memset(w_buf, 'X', PIPE_BUF);
printf("PIPE_BUF: %d\n", PIPE_BUF);
printf("making nonblocking pipes\n");
if (pipe(fds)) {
perror("pipe");
}
if (fcntl(fds[0], F_SETFL, O_NONBLOCK))
perror("fcntl for read handle");
if (fcntl(fds[1], F_SETFL, O_NONBLOCK))
perror("fcntl for write handle");
printf("writing until it blocks\n");
i = 0;
while (write(fds[1], w_buf, PIPE_BUF) > 0) {
i++;
}
if (errno != EAGAIN)
perror("unexpected write error");
printf("wrote %d * %d bytes\n", i, PIPE_BUF);
printf("reading out until write no longer blocks\n");
i = 0;
while (write(fds[1], w_buf, PIPE_BUF) < 0) {
read(fds[0], r_buf, PIPE_BUF);
i++;
}
printf("read %d * %d bytes\n", i, PIPE_BUF);
}
Bug#1005298: libdevel-nytprof-perl: autopkgtest failure with Perl 5.34: t/test62-subcaller1-b.t
Package: libdevel-nytprof-perl Version: 6.11+dfsg-2 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest This package fails its autopkgtest checks on current sid, triggered by Perl 5.34. # Failed test 'test62-subcaller1-b.calls match generated calls data for blocks=1 calls=1 compress=1 leave=1 savesrc=0 slowops=2 start=init use_db_sub=0' # at t/lib/NYTProfTest.pm line 468. The test suite passes at build time, so this wasn't caught in our pre-transition testing. The failing tests have pregenerated traces of expected execution details. These traces changed during the 5.34 cycle, so there are two versions of this test: test62-subcaller1-a.t for < 5.34 and test62-subcaller1-b.t for 5.34 onwards. The new execution trace is unfortunately sensitive to the test environment: if the binary plugin (NYTProf.so ) gets loaded by Devel::NYTProf::Core from a relative filesystem path (like during the build, from under blib/), the execution trace is different than when NYTProf.so gets loaded from an absolute path (like during autopkgtest checks, from the system directory.) The specific difference seems to be that XSLoader.pm will fall back to DynaLoader for relative paths around https://sources.debian.org/src/perl/5.34.0-3/dist/XSLoader/XSLoader_pm.PL/#L128 I haven't investigated this further. So nothing is broken here, the test just works only during build. I can't see a clean fix, and I don't think we should bother upstream with these details. I suggest just skipping this test during autopkgtest. (Testing against installed versions is a Debian-specific thing that CPAN distributions aren't designed for, it just happens to work almost always.) (Since this is a test-only thing, we probably shouldn't make the new perl Break unfixed versions.) See also https://github.com/timbunce/devel-nytprof/issues/143 about the fragility of the tests. -- Niko Tyni nt...@debian.org
