Bug#897960: libconfig-model-tkui-perl: FTBFS: Can't call method "exists" on an undefined value
Package: libconfig-model-tkui-perl Version: 1.365-1 Severity: serious User debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net, this package has started failing its test suite on current sid, probably because of -libconfig-model-perl 2.122-1 +libconfig-model-perl 2.123-1 This also makes the package fail to build from source. https://ci.debian.net/packages/libc/libconfig-model-tkui-perl/unstable/amd64/ Backend error: Can't call method "exists" on an undefined value at /usr/share/perl5/Config/Model/Backend/CdsFile.pm line 37. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 2 just after 3. t/config-model-ui.t .. You can play with the widget if you run the test with 's' argument ok 1 - Compilation done ok 2 - created dummy instance ok 3 - Config root created Dubious, test returned 2 (wstat 512, 0x200) All 3 subtests passed 2018/05/05 07:47:12 Model Master: write_config specification is deprecated, please merge with read_config and move in rw_config Backend error: Can't call method "exists" on an undefined value at /usr/share/perl5/Config/Model/Backend/CdsFile.pm line 37. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 2 just after 3. t/config-model-wizard.t .. You can play with the widget if you run the test with 's' argument ok 1 - Compilation done ok 2 - created dummy instance ok 3 - Config root created Dubious, test returned 2 (wstat 512, 0x200) All 3 subtests passed [...] Test Summary Report --- t/config-model-ui.t(Wstat: 512 Tests: 3 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/config-model-wizard.t (Wstat: 512 Tests: 3 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output -- Niko Tyni nt...@debian.org
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
On Thu, Apr 26, 2018 at 09:09:27AM +0200, Manuel A. Fernandez Montecelo wrote: > > But since longer builds are not a problem for us, as long as it > doesn't affect other architectures, it'll be better to increase the > factor for this arch, to be on the safe side. Thanks. I did this in 5.26.2-3, we'll see how it goes. -- Niko
Bug#896121: pgbackrest: package files are not on @INC anymore with perl 5.26.2
On Wed, Apr 25, 2018 at 11:30:11AM +0200, Christoph Berg wrote: > Re: Niko Tyni 2018-04-20 <20180420174614.GA6944@estella.local.invalid> > > When you fix this, please file a bug against perl to add a Breaks entry > > for the older pgbackrest versions so that partial upgrades can't end up > > with a broken combination of packages. > > The C module was introduced in pgbackrest 1.15-1. Stable has only > 1.12-1, i.e. the problem will vanish for new installations as soon as > the fixed pgbackrest package enters testing. Does that still warrant a > Breaks: in perl? Oh. I guess not in that case then. It would just create unnecessary restrictions for apt during stretch->buster upgrades. I note that Ubuntu has released with affected versions, but that's not really our problem of course. I'm a bit surprised that this went unnoticed for a year in sid, even through a major Perl transition (5.24 -> 5.26). A lintian check for catching such bugs would be nice for the future. -- Niko
Bug#896828: perl: FTBFS on ia64: t/op/sprintf2.t failure
Package: perl Version: 5.26.2-2 X-Debbugs-Cc: debian-i...@lists.debian.org This package failed to build on ia64. t/op/sprintf2 .. # Failed test 1492 - subnormal 0x1.fp-1022 %a 0x1.fp-1022 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.fp-1022" # Failed test 1493 - subnormal 0x0.fp-1022 %a 0x1.ep-1023 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.ep-1023" # Failed test 1494 - subnormal 0x0.7p-1022 %a 0x1.cp-1024 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.cp-1024" # Failed test 1495 - subnormal 0x0.3p-1022 %a 0x1.8p-1025 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.8p-1025" # Failed test 1496 - subnormal 0x0.1p-1022 %a 0x1.p-1026 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.p-1026" # Failed test 1497 - subnormal 0x0.0p-1022 %a 0x1.fffep-1027 got 0x0p+0 at op/sprintf2.t line 812 # got "0x0p+0" # expected "0x1.fffep-1027" FAILED at test 1492 [...] Failed 1 test out of 2455, 99.96% okay. op/sprintf2.t This regressed between 5.26.1-5 and 5.26.1-6, but I doubt the source changes between those caused it. A toolchain regression seems more likely, but I haven't tested this in any way. @debian-ia64: would you please look into it? -- Niko Tyni nt...@debian.org
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
Package: perl
Version: 5.26.2-2
X-Debbugs-Cc: debian-ri...@lists.debian.org
This package failed to build on riscv64.
t/re/fold_grind # Test
process timed out - terminating
FAILED--no leader found
[...]
Failed 1 test out of 2457, 99.96% okay.
re/fold_grind.t
[...]
Build needed 05:11:45, 350184k disk space
It looks to me like the buildd host is just too slow for this test.
>From the test:
my $time_out_factor = $ENV{PERL_TEST_TIME_OUT_FACTOR} || 1;
$time_out_factor = 1 if $time_out_factor < 1;
watchdog(5 * 60 * $time_out_factor);
so the default timeout is five minutes but can be multiplied with
PERL_TEST_TIME_OUT_FACTOR in the environment.
AFAICS the build time of five hours is well above all the other
architectures, even m68k and sh4, and it's still less than half of
a successful build (we have to build perl three times with different
options, and run the test suite for two of those builds.)
@debian-riscv: I guess I can set PERL_TEST_TIME_OUT_FACTOR=2 for riscv64
in debian/rules or something like that, do you think that's sensible or
are the current riscv64 buildds going to get faster any time soon?
--
Niko Tyni nt...@debian.org
Bug#896822: sqitch: new upstream release 0.998 available
On Tue, Apr 24, 2018 at 06:07:41PM +0200, gregor herrmann wrote: > On Tue, 24 Apr 2018 18:38:21 +0300, Niko Tyni wrote: > > > Package: sqitch > > Version: 0.9996-1 > > Severity: wishlist > > > > I got a private request for packaging upstream version 0.9998. > > > > Filing this publicly. I'm happy if somebody else in the team wants to > > handle it. > > 0.9997-1 prepared in git; I don't see 0.9998 on github or CPAN ?! Oh. The upstream master branch on github does refer to 0.9998 but I guess it's just not released yet. Please let's keep this open until 0.9998 actual; the fixes there were specifically requested. Thanks, -- Niko
Bug#896822: sqitch: new upstream release 0.998 available
Package: sqitch Version: 0.9996-1 Severity: wishlist I got a private request for packaging upstream version 0.9998. Filing this publicly. I'm happy if somebody else in the team wants to handle it. -- Niko Tyni nt...@debian.org
Bug#896556: libdata-format-html-perl: warns on usage
Package: libdata-format-html-perl Version: 0.5.1-1 Tags: upstream User: debian-p...@lists.debian.org Usertags: autopkgtest This module warns on usage: # perl -e 'use Data::Format::HTML' given is experimental at /usr/share/perl5/Data/Format/HTML.pm line 193. when is experimental at /usr/share/perl5/Data/Format/HTML.pm line 194. when is experimental at /usr/share/perl5/Data/Format/HTML.pm line 195. when is experimental at /usr/share/perl5/Data/Format/HTML.pm line 196. when is experimental at /usr/share/perl5/Data/Format/HTML.pm line 197. when is experimental at /usr/share/perl5/Data/Format/HTML.pm line 199. -- Niko Tyni nt...@debian.org
Bug#896555: libcgi-application-plugin-messagestack-perl: missing dependency on libcgi-application-perl
Package: libcgi-application-plugin-messagestack-perl Version: 0.34-3 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libcgi-application-perl: # perl -e 'use CGI::Application::Plugin::MessageStack' Can't locate CGI/Application.pm in @INC (you may need to install the CGI::Application module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/CGI/Application/Plugin/MessageStack.pm line 3. BEGIN failed--compilation aborted at /usr/share/perl5/CGI/Application/Plugin/MessageStack.pm line 3. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896554: libdata-format-html-perl: missing dependency on libhtml-parser-perl
Package: libdata-format-html-perl Version: 0.5.1-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libhtml-parser-perl: # perl -e 'use Data::Format::HTML' Can't locate HTML/Entities.pm in @INC (you may need to install the HTML::Entities module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Data/Format/HTML.pm line 165. BEGIN failed--compilation aborted at /usr/share/perl5/Data/Format/HTML.pm line 165. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896553: libgeo-shapelib-perl: missing dependency on libtree-r-perl
Package: libgeo-shapelib-perl Version: 0.22-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libtree-r-perl: # perl -e 'use Geo::Shapelib' Can't locate Tree/R.pm in @INC (you may need to install the Tree::R module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/lib/x86_64-linux-gnu/perl5/5.26/Geo/Shapelib.pm line 5. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.26/Geo/Shapelib.pm line 5. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896551: libgstreamer1-perl: Typelib file for namespace 'Gst', version '1.0' not found
Package: libgstreamer1-perl Version: 0.003-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency that would pull in gir1.2-gstreamer-1.0 (for Gst-1.0.typelib) and gir1.2-gst-plugins-base-1.0 (for GstApp-1.0.typelib). No idea if they should be depended on directly or through some other package. # perl -e 'use GStreamer1' Typelib file for namespace 'Gst', version '1.0' not found at /usr/lib/x86_64-linux-gnu/perl5/5.26/Glib/Object/Introspection.pm line 108. BEGIN failed--compilation aborted at /usr/share/perl5/GStreamer1.pm line 62. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896549: libhtml-popuptreeselect-perl: missing dependency on libhtml-template-perl
Package: libhtml-popuptreeselect-perl Version: 1.6-7 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libhtml-template-perl: # perl -e 'use HTML::PopupTreeSelect' Can't locate HTML/Template.pm in @INC (you may need to install the HTML::Template module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/HTML/PopupTreeSelect.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/HTML/PopupTreeSelect.pm line 7. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896547: libhtml-wikiconverter-markdown-perl: missing dependency on libparams-validate-perl
Package: libhtml-wikiconverter-markdown-perl Version: 0.06-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libparams-validate-perl: # perl -e 'use HTML::WikiConverter::Markdown' Can't locate Params/Validate.pm in @INC (you may need to install the Params::Validate module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/HTML/WikiConverter/Markdown.pm line 9. BEGIN failed--compilation aborted at /usr/share/perl5/HTML/WikiConverter/Markdown.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896546: liblog-dispatch-filerotate-perl: missing dependency on libparams-validate-perl
Package: liblog-dispatch-filerotate-perl Version: 1.19-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libparams-validate-perl: # perl -e 'use Log::Dispatch::FileRotate' Can't locate Params/Validate.pm in @INC (you may need to install the Params::Validate module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Log/Dispatch/FileRotate.pm line 15. BEGIN failed--compilation aborted at /usr/share/perl5/Log/Dispatch/FileRotate.pm line 15. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896544: liblemonldap-ng-handler-perl: missing dependency on libcgi-pm-perl
Package: liblemonldap-ng-handler-perl Version: 1.9.16-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libcgi-pm-perl: # perl -e 'use Lemonldap::NG::Handler' Can't locate CGI/Util.pm in @INC (you may need to install the CGI::Util module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Lemonldap/NG/Handler/Main.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/Lemonldap/NG/Handler/Main.pm line 8. Compilation failed in require at /usr/share/perl5/Lemonldap/NG/Handler/SharedConf.pm line 20. BEGIN failed--compilation aborted at /usr/share/perl5/Lemonldap/NG/Handler/SharedConf.pm line 20. Compilation failed in require at /usr/share/perl5/Lemonldap/NG/Handler.pm line 10. BEGIN failed--compilation aborted at /usr/share/perl5/Lemonldap/NG/Handler.pm line 10. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I know this is already fixed in git (thanks Xavier!), still filing a bug for tracking purposes. Will add the Closes entry to the changelog in git myself as soon as I get the BTS ack. -- Niko Tyni nt...@debian.org
Bug#896543: liblwp-authen-negotiate-perl: missing dependency on libwww-perl
Package: liblwp-authen-negotiate-perl Version: 0.08-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libwww-perl: # perl -e 'use LWP::Authen::Negotiate' Can't locate LWP/Debug.pm in @INC (you may need to install the LWP::Debug module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/LWP/Authen/Negotiate.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/LWP/Authen/Negotiate.pm line 6. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896541: libmodule-install-automanifest-perl: missing dependency on libmodule-install-perl
Package: libmodule-install-automanifest-perl Version: 0.003-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libmodule-install-perl: # perl -e 'use Module::Install::AutoManifest' Can't locate Module/Install/Base.pm in @INC (you may need to install the Module::Install::Base module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Module/Install/AutoManifest.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/Module/Install/AutoManifest.pm line 6. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896542: libmarc-transform-perl: missing dependency on libyaml-perl
Package: libmarc-transform-perl Version: 0.003006-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libyaml-perl: # perl -e 'use MARC::Transform' Can't locate YAML.pm in @INC (you may need to install the YAML module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/MARC/Transform.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/MARC/Transform.pm line 8. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896539: libmodule-install-trustmetayml-perl: missing dependency on libmodule-install-perl
Package: libmodule-install-trustmetayml-perl Version: 0.003-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libmodule-install-perl: # perl -e 'use Module::Install::TrustMetaYml' Base class package "Module::Install::Base" is empty. (Perhaps you need to 'use' the module which defines that package first, or make that module available in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base). at /usr/share/perl5/Module/Install/TrustMetaYml.pm line 11. BEGIN failed--compilation aborted at /usr/share/perl5/Module/Install/TrustMetaYml.pm line 11. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896540: libmodule-install-extratests-perl: missing dependency on libmodule-install-perl
Package: libmodule-install-extratests-perl Version: 0.008-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libmodule-install-perl: # perl -e 'use Module::Install::ExtraTests' Can't locate Module/Install/Base.pm in @INC (you may need to install the Module::Install::Base module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Module/Install/ExtraTests.pm line 5. BEGIN failed--compilation aborted at /usr/share/perl5/Module/Install/ExtraTests.pm line 5. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896538: libmonitoring-livestatus-class-perl: missing dependency on libmodule-find-perl
Package: libmonitoring-livestatus-class-perl Version: 0.06-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libmodule-find-perl: # perl -e 'use Monitoring::Livestatus::Class' Can't locate Module/Find.pm in @INC (you may need to install the Module::Find module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Monitoring/Livestatus/Class.pm line 4. BEGIN failed--compilation aborted at /usr/share/perl5/Monitoring/Livestatus/Class.pm line 4. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896537: libmoosex-mungehas-perl: missing dependency on libtype-tiny-perl | libeval-closure-perl
Package: libmoosex-mungehas-perl
Version: 0.007-2
Severity: serious
User: debian-p...@lists.debian.org
Usertags: use-failure
This package is missing a dependency on libtype-tiny-perl:
# perl -e 'use MooseX::MungeHas'
Could not load Eval::TypeTiny at /usr/share/perl5/MooseX/MungeHas.pm line 24.
BEGIN failed--compilation aborted at /usr/share/perl5/MooseX/MungeHas.pm line
24.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
Looking at the code, libeval-closure should also do as an alternative:
for my $backend (qw/ Eval::TypeTiny Eval::Closure /)
{
last if eval(
"require $backend; *eval_closure =
\\&$backend\::eval_closure;"
);
}
exists(_closure)
or croak "Could not load Eval::TypeTiny";
--
Niko Tyni nt...@debian.org
Bug#896535: libnet-dns-zonefile-fast-perl: missing dependency on libnet-dns-perl
Package: libnet-dns-zonefile-fast-perl Version: 1.24-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libnet-dns-perl: # perl -e 'use Net::DNS::ZoneFile::Fast' Can't locate Net/DNS.pm in @INC (you may need to install the Net::DNS module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Net/DNS/ZoneFile/Fast.pm line 74. BEGIN failed--compilation aborted at /usr/share/perl5/Net/DNS/ZoneFile/Fast.pm line 74. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896534: libnetapp-perl: missing dependency on libnet-telnet-perl
Package: libnetapp-perl Version: 500.002-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libnet-telnet-perl: # perl -e 'use NetApp' Can't locate Net/Telnet.pm in @INC (you may need to install the Net::Telnet module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/NetApp/Filer.pm line 16. BEGIN failed--compilation aborted at /usr/share/perl5/NetApp/Filer.pm line 16. Compilation failed in require at /usr/share/perl5/NetApp.pm line 12. BEGIN failed--compilation aborted at /usr/share/perl5/NetApp.pm line 12. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I see that ssh is (rightly!) the preferred way to use this module, and libnet-telnet-perl is an alternative secondary dependency, but NetApp::Filer unconditionally uses Net::Telnet so it looks like the package is unusable without that... -- Niko Tyni nt...@debian.org
Bug#896533: libplack-middleware-cache-perl: missing dependency on libplack-middleware-perl
Package: libplack-middleware-cache-perl Version: 0.14-1 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libplack-middleware-perl: # perl -e 'use Plack::Middleware::Cache' Can't locate Plack/Middleware.pm in @INC (you may need to install the Plack::Middleware module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl/5.26/parent.pm line 16. BEGIN failed--compilation aborted at /usr/share/perl5/Plack/Middleware/Cache.pm line 5. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896531: libsbml5-perl: Can't locate loadable object for module LibSBML
Package: libsbml5-perl Version: 5.16.0+dfsg-2 Severity: grave User: debian-p...@lists.debian.org Usertags: use-failure This package seems unusable: # perl -e 'use LibSBML' Can't locate loadable object for module LibSBML in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/lib/x86_64-linux-gnu/perl5/5.26/LibSBML.pm line 11. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. This is also the case on stretch and jessie. -- Niko Tyni nt...@debian.org
Bug#896532: libqtcore4-perl: missing dependency on liblist-moreutils-perl
Package: libqtcore4-perl Version: 4.8.4-1.3 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on liblist-moreutils-perl: # perl -e 'use QtCore4' Can't locate List/MoreUtils.pm in @INC (you may need to install the List::MoreUtils module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/lib/x86_64-linux-gnu/perl5/5.26/QtCore4.pm line 799. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.26/QtCore4.pm line 799. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896503: libx2go-server-db-perl: missing dependency on libx2go-server-perl
Package: libx2go-server-db-perl Version: 4.1.0.0-3 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libx2go-server-perl: # perl -e 'use X2Go::Server::DB' Can't locate X2Go/Config.pm in @INC (you may need to install the X2Go::Config module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/X2Go/Server/DB.pm line 38. BEGIN failed--compilation aborted at /usr/share/perl5/X2Go/Server/DB.pm line 38. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896504: libx2go-log-perl: missing dependency on libx2go-server-perl
Package: libx2go-log-perl Version: 4.1.0.0-3 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libx2go-server-perl: # perl -e 'use X2Go::Log' Can't locate X2Go/Config.pm in @INC (you may need to install the X2Go::Config module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/X2Go/Log.pm line 37. BEGIN failed--compilation aborted at /usr/share/perl5/X2Go/Log.pm line 37. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896502: libxml-structured-perl: missing dependency on libxml-parser-perl
Package: libxml-structured-perl Version: 1.01-2 Severity: serious User: debian-p...@lists.debian.org Usertags: use-failure This package is missing a dependency on libxml-parser-perl: # perl -e 'use XML::Structured' Can't locate XML/Parser.pm in @INC (you may need to install the XML::Parser module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/XML/Structured.pm line 11. BEGIN failed--compilation aborted at /usr/share/perl5/XML/Structured.pm line 11. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896500: libnet-whois-ripe-perl: Can't use 'defined(@array)'
Package: libnet-whois-ripe-perl Version: 1.23-2 Severity: grave Justification: renders package unusable User: debian-p...@lists.debian.org Usertags: use-failure perl-5.22-transition This Perl module seems to be unusable: # perl -e 'use Net::Whois::RIPE' Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/share/perl5/Net/Whois/RIPE/Object.pm line 196. Compilation failed in require at /usr/share/perl5/Net/Whois/RIPE.pm line 12. BEGIN failed--compilation aborted at /usr/share/perl5/Net/Whois/RIPE.pm line 12. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. This has been fatal since Perl 5.22, so stretch is affected too. -- Niko Tyni nt...@debian.org
Bug#896499: libopenscap-perl: Can't locate loadable object for module openscap_pm
Package: libopenscap-perl Version: 1.2.15-1 Severity: grave Justification: renders package unusable User: debian-p...@lists.debian.org Usertags: use-failure The Perl module in this package seems to be unusable: # perl -e 'use openscap' Can't locate loadable object for module openscap_pm in @INC (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/openscap.pm line 11. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#896121: pgbackrest: package files are not on @INC anymore with perl 5.26.2
On Thu, Apr 19, 2018 at 09:09:24PM +0200, Paul Gevers wrote:
> Source: pgbackrest
> Version: 2.01-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: needs-update
>
> Your autopkgtest¹ of version 2.01-1 started to fail when perl 5.26.2 hit
> the archive with the error copied below. It seems the package installs
> files in /usr/lib//perl/5.26.1/. That path is not on @INC
> with perl 5.26.2, so either you need to put the files somewhere else, or
> you need a hard Depends on perl 5.26.1.
>
> I think the issue is much more severe than just the autopkgtest failing,
> I think the package stopped working with the default perl and INC.
Yes. We discussed this on IRC with Myon, and I believe the result was
that something like
sed -i 's!PREFIX=/usr!INSTALLDIRS=vendor!' debian/rules
fixes it.
The modules are supposed to end up in /usr/lib//perl5/5.26
($Config{vendorarch}), as per the Debian Perl Policy. The normal way to
achieve that is to pass INSTALLDIRS=vendor to Makefile.PL as suggested
by the policy.
The package used to work because the files were installed to Perl's
private library directory /usr/lib//perl/5.26.1 (note /perl/
not /perl5/). This private directory changed with the upgrade of Perl.
When you fix this, please file a bug against perl to add a Breaks entry
for the older pgbackrest versions so that partial upgrades can't end up
with a broken combination of packages.
Thanks for your work on Debian,
--
Niko Tyni nt...@debian.org
Bug#895992: perl FTCBFS: config.sh.static for cross build but it needs refreshing from 5.26.1 to 5.26.2
On Wed, Apr 18, 2018 at 02:30:58PM +0200, Helmut Grohne wrote: > Source: perl > Version: 5.26.2-2 > User: helm...@debian.org > Usertags: rebootstrap > in #893469, you said that you intended to update configs from > experimental build logs. I guess that part got lost somehow. Now the > package moved to unstable and #893469 is marked as fixed in unstable, > but perl still doesn't cross build. Thus I am filing this bug both as a > reminder and as a tracking number to figure out when perl is cross > buildable again. Thanks. The experimental buildd coverage for 5.26.2-1 was somewhat lousy and I didn't want to postpone the upload to unstable waiting for more builds. -- Niko
Bug#895943: transition: perl 5.26.2
On Tue, Apr 17, 2018 at 06:44:50PM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 17/04/18 18:38, Niko Tyni wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > perl 5.26.2-1 in experimental. It is binary compatible with 5.26.0 and > > 5.26.1 and therefore Provides all of perlapi-5.26.0, perlapi-5.26.1 > > and perlapi-5.26.2. However, as usual, four packages will need binNMUs > > once it enters unstable due to their strict versioned dependencies on > > the current perl version: > > > > libpar-packer-perl > > libdevel-cover-perl > > libclass-xsaccessor-perl > > libcommon-sense-perl > > > > These binNMUs will need the 'extra-depends' wanna-build feature to make > > sure the new perl is pulled in. > > > > Please let us know if/when it's OK to upload. > > Please go ahead. Thanks, uploaded last night. -- Niko
Bug#895943: transition: perl 5.26.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, perl 5.26.2-1 in experimental. It is binary compatible with 5.26.0 and 5.26.1 and therefore Provides all of perlapi-5.26.0, perlapi-5.26.1 and perlapi-5.26.2. However, as usual, four packages will need binNMUs once it enters unstable due to their strict versioned dependencies on the current perl version: libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl These binNMUs will need the 'extra-depends' wanna-build feature to make sure the new perl is pulled in. Please let us know if/when it's OK to upload. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#895705: missing ";" passed syntax checks
On Sun, Apr 15, 2018 at 05:57:01AM +0800, 積丹尼 Dan Jacobson wrote: > Package: perl > Version: 5.26.1-5 > Severity: wishlist > > This missing ";" passed syntax checks: > > use Data::Dumper; > use Time::Piece > $Data::Dumper::Indent = $Data::Dumper::Sortkeys = 1; > my $doc; That's because it is valid syntax: the assignments get evaluated and return the assigned value, so the effect is 'use Time::Piece 1;', Had you assigned 2 to the variables you'd have gotten an import error: Time::Piece version 2 required--this is only version 1.31 at /usr/share/perl/5.26/Exporter/Heavy.pm line 111. BEGIN failed--compilation aborted at t.pl line 3. -- Niko Tyni nt...@debian.org
Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?
On Mon, Apr 09, 2018 at 09:37:54PM +0100, Olly Betts wrote: > I've read that ticket already, but I'm not really clear on why it > requires the exact wxWidgets version. If you built against wxWidgets > 3.0.3.1 then the real requirement is $upstream_version >= 3.0.3.1 not > $upstream_version == 3.0.3.1 (or perhaps >= some lower version if there > were no ABI additions since that version). > > Is there something more subtle here, or is this effectively an > Alien::wxWidgets upstream design flaw which it's hard for distros to > diverge from? The latter I think. Upstream has decided to embed the wxWidgets version (though with three digits not four, so 3.0.3) in the key used at runtime to look up the build time configuration, creating a (possibly artificial) requirement that they must match. I guess we could patch it and/or file a wishlist bug upstream, but it hasn't felt like a huge burden so far... > > Another approach would be to consider this a one time glitch (how often > > are we going to change toolkits anyway?), make libwx-perl Break older > > (gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions, > > and have those packages in turn depend on newer (gtk3 based) libwx-perl > > versions. That should handle it afaics. > > If this is only because of the gtk2 to gtk3 switch, then this makes > sense to me. It's the first time this will have happened since we've > had these two packages, and only the second time in 18 years we've > changed toolkit in the default wxwidgets packages (previously gtk1 to > gtk2). Right. I think we can quite reasonably assume it's the toolkit switch. We can revisit this if we run into other incompabilities in the future. -- Niko
Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?
On Sun, Apr 08, 2018 at 11:42:47AM +0300, Niko Tyni wrote: > Another approach would be to consider this a one time glitch (how often > are we going to change toolkits anyway?), make libwx-perl Break older > (gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions, > and have those packages in turn depend on newer (gtk3 based) libwx-perl > versions. That should handle it afaics. I'm inclined to do this unless I hear objections in the next few days. -- Niko
Bug#895191: pkg-perl-autopkgtest: run syntax.t and use.t with xvfb-run
On Sun, Apr 08, 2018 at 01:45:28PM +0200, gregor herrmann wrote: > On Sun, 08 Apr 2018 12:29:05 +0300, Niko Tyni wrote: > > > The test dependencies come from /usr/share/autodep8/support/perl/generate, > > so that would need an update. I wonder if that's overkill for a handful > > of packages. Thoughts? > > I tend to think it's overkill. Yeah. I can imagine some more generic hooks in autodep8 that would allow configurable test dependencies, but I'm not terribly excited about adding such complexity. I've disabled the syntax.t and use.t checks in libwx-glcanvas-perl.git for now, mirroring what libwx-perl does. Not closing this bug outright in case somebody has more ideas. -- Niko
Bug#895191: pkg-perl-autopkgtest: run syntax.t and use.t with xvfb-run
On Sun, Apr 08, 2018 at 12:01:11PM +0300, Niko Tyni wrote: > Package: pkg-perl-autopkgtest > Version: 0.43 > Severity: wishlist > > We're currently disabling syntax.t and use.t in libwx-perl because they > need a $DISPLAY, and libwx-glcanvas-perl is similarly affected. I expect > there are more. I don't see any downside to running these checks under > xvfb-run, so we should probably just do that for all packages. Hm. I now realize smoke.t is relying on xvfb getting pulled in via the build dependencies, and using it only when it's available. This approach does not work for syntax.t and use.t, where xvfb-run is almost always not going to be available. The test dependencies come from /usr/share/autodep8/support/perl/generate, so that would need an update. I wonder if that's overkill for a handful of packages. Thoughts? > I guess any configurability should be common with smoke.t, so #895190 > is related. Not sure if configurability is necessary for these tests. #895190 is easily solvable with existing infrastructure (smoke-env), and I'd like to avoid making this stuff even more complex. So I'm inclined to start small here (if at all). -- Niko
Bug#895191: pkg-perl-autopkgtest: run syntax.t and use.t with xvfb-run
Package: pkg-perl-autopkgtest Version: 0.43 Severity: wishlist We're currently disabling syntax.t and use.t in libwx-perl because they need a $DISPLAY, and libwx-glcanvas-perl is similarly affected. I expect there are more. I don't see any downside to running these checks under xvfb-run, so we should probably just do that for all packages. I guess any configurability should be common with smoke.t, so #895190 is related. -- Niko Tyni nt...@debian.org
Bug#895189: libwx-perl: autopkgtest failures due to xvfb-run
Package: libwx-perl Version: 1:0.9932-3 Severity: important User: debian-p...@lists.debian.org Usertags: autopkgtest Control: clone -1 -2 Control: reassign -2 pkg-perl-autopkgtest Control: retitle -2 pkg-perl-autopkgtest: allow configurable xvfb-run invocation Control: severity -2 wishlist Control: block -1 with -2 The autopkgtest checks of this package regressed with 1:0.9932-3. https://ci.debian.net/packages/libw/libwx-perl/unstable/amd64/ This is because the pkg-perl-autopkgtest scripts run the test suite with 'xvfb-run' defaults, but this package now needs 16-bit colour depth, as provided at build time by debian/rules: # xvfb-run defaults to 8-bit colour depth, which causes some tests to fail. override_dh_auto_test: xvfb-run -s '-screen 0 640x480x16' -a dh_auto_test --max-parallel=1 Unfortunately it's not currently possible to supply xvfb arguments in pkg-perl-autopkgtest, so cloning a separate bug for that and blocking. -- Niko Tyni nt...@debian.org
Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?
On Sat, Apr 07, 2018 at 09:57:15PM +0100, Olly Betts wrote:
> On Sat, Apr 07, 2018 at 04:20:48PM +0300, Niko Tyni wrote:
> > So to do this properly it looks like we need something to make
> > sure the Perl Wx related packages are upgraded in sync. The
> > virtual package provided by libalien-wxwidgets-perl (currently
> > wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have
> > a ready recipe for injecting that.
>
> I'd guess that makes sense, but I don't entirely understand how the
> libalien-wxwidgets-perl <-> libwx-perl connection works, or why we need
> a chain of binNMUs after each new upstream wxwidgets3.0 release.
AIUI Alien::wxWidgets provides information about a wxwidgets installation,
and libwx-perl uses that to offer machinery for building wxwidgets
related Perl packages (the Wx::build namespace.) This build machinery
embeds the exact wxwidgets version/configuration from Alien::wxWidgets,
and breaks if those get out of sync. Hence the binNMU requirement. See
#757855 for the full story.
So the tight coupling is only for the Wx::build machinery. As we see in
this bug, no such extra provisions currently exist for keeping Wx based
binary Perl code (lke libwx-scintilla-perl) in sync with the Wx bindings
(libwx-perl).
> Presumably just copying libwx-perl's dependencies related to this
> across would work?
Yeah, if we accept the burden of rebuilding libwx-scintilla-perl and
libwx-glcanvas-perl too on every wxwidgets3.0 upstream release.
Alternatively I guess either libwx-perl or libalien-wxwidgets-perl
could Provide another less finely grained virtual package that
only encodes those parts that are expected to be incompatible at
run time, like wxperl-gtk3 or something like that. But that feels
overkill.
Another approach would be to consider this a one time glitch (how often
are we going to change toolkits anyway?), make libwx-perl Break older
(gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions,
and have those packages in turn depend on newer (gtk3 based) libwx-perl
versions. That should handle it afaics.
> > It seems probable that other packages (libwx-glcanvas-perl?) are
> > similarly affected, but I haven't looked into that.
>
> I'd expect so. There don't seem to be any others - at least I don't see
> any other -perl packages in the transition tracker:
I think those are the only two Wx perl packages we have with compiled
C extensions ("XS").
> I didn't try to handle preventing combinations of new libwx-perl with
> older libwx-scintilla-perl or libwx-glcanvas-perl though since there was
> no evidence that such handling was attempted for previous transitions.
Either they haven't broken partial upgrades earlier, or we just haven't
noticed that.
> > Setting severity to RC initially and marking as a transition blocker,
> > but others should feel free to adjust as appropriate.
>
> It would certainly be good to address this somehow, but mostly because
> it will ease future transitions. I'm not sure this really deserves to
> block this one as the libwx*-perl collection is now back in step across
> all release archs:
>
> https://buildd.debian.org/status/package.php?p=libalien-wxwidgets-perl+libwx-perl+libwx-scintilla-perl+libwx-glcanvas-perl
>
> Also blocking the transition really just means that the wx gtk2 packages
> can't be removed, yet doing that if anything improves the situation.
>
> But that's mostly a theoretical point right now as the full transition
> is going to take months.
Yeah. FWIW I don't think the transition blocker metadata technically
affects testing migration or wx gtk2 binary removal. I intended it just
as a note for humans that these issues are linked. Naturally I'm fine
with removing it if it gets in the way for anybody.
As for whether this needs to be fixed or not: I think the minimum
requirement in the release criticality sense is that partial upgrades
between stable releases stay working. I expect we'll be rebuilding
libwx-scintilla-perl and libwx-glcanvas-perl for at least Perl 5.28
before the buster release anyway, so that will probably take care of it
(because both libwx-perl and libwx-scintilla-perl will then be necessarily
upgraded in lockstep with Perl itself.)
Of course, keeping partial upgrades working for users of testing and
Debian derivatives is a worthy goal too.
--
Niko
Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?
Package: libwx-scintilla-perl Version: 0.39-3 Severity: serious Tags: sid buster User: debian-p...@lists.debian.org Usertags: autopkgtest X-Debbugs-Cc: Olly Betts <o...@survex.com> Control: block 894663 with -1 We're in the middle of wxwidgets3.0 related packages transitioning from gtk2 to gtk3 (see #894663), and it looks like the current dependency metadata doesn't prevent some problematic combinations of partial upgrades on the Perl bindings (libwx-perl rdeps) side. As seen at https://ci.debian.net/packages/libw/libwx-scintilla-perl/unstable/amd64/, libwx-scintilla-perl_0.39-3+b2 (old binary built against wxwidgets / gtk2) breaks when libwx-perl is a gtk3 build (currently at 1:0.9932-3). Manually running t/03_editor_child.t in libwx-scintilla-perl shows some GTK warnings and a hang: # xvfb-run prove t/03_editor_child.t t/03_editor_child.t .. (03_editor_child.t:3955): GLib-GObject-WARNING **: 13:02:34.625: cannot register existing type 'GtkWidget' (03_editor_child.t:3955): GLib-GObject-CRITICAL **: 13:02:34.625: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (03_editor_child.t:3955): GLib-GObject-WARNING **: 13:02:34.625: cannot register existing type 'GtkBuildable' (03_editor_child.t:3955): GLib-GObject-CRITICAL **: 13:02:34.625: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (03_editor_child.t:3955): GLib-CRITICAL **: 13:02:34.625: g_once_init_leave: assertion 'result != 0' failed (03_editor_child.t:3955): GLib-GObject-CRITICAL **: 13:02:34.625: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (03_editor_child.t:3955): GLib-GObject-WARNING **: 13:02:34.625: cannot register existing type 'GtkWidget' (03_editor_child.t:3955): GLib-GObject-CRITICAL **: 13:02:34.625: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed This works fine again with libwx-scintilla-perl_0.39-4, which is built against GTK3. So to do this properly it looks like we need something to make sure the Perl Wx related packages are upgraded in sync. The virtual package provided by libalien-wxwidgets-perl (currently wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have a ready recipe for injecting that. It seems probable that other packages (libwx-glcanvas-perl?) are similarly affected, but I haven't looked into that. Olly, explicitly copying you as you're handling this transition (thanks for that!). Any thoughts on this? Setting severity to RC initially and marking as a transition blocker, but others should feel free to adjust as appropriate. -- Niko Tyni nt...@debian.org
Bug#894626: tagging 894626 (libsnmp-perl: undefined symbol: netsnmp_ds_toggle_boolean)
On Sat, Apr 07, 2018 at 03:35:22PM +0300, Niko Tyni wrote: > On Tue, Apr 03, 2018 at 08:39:34PM +1000, Craig Small wrote: > > tags 894626 + help > > Hi Craig, thanks for looking into the this net-snmp issue. Could you > elaborate a bit on what you want help for? Gregor already provided a > patch, do you want testing for that or another patch with a different > approach or something else? Oh, I now see the control message spent three days on its way to the BTS. I guess the tag isn't relevant any more then :) In any case, please let us know if we can help more. -- Niko
Bug#894626: tagging 894626 (libsnmp-perl: undefined symbol: netsnmp_ds_toggle_boolean)
On Tue, Apr 03, 2018 at 08:39:34PM +1000, Craig Small wrote: > tags 894626 + help Hi Craig, thanks for looking into the this net-snmp issue. Could you elaborate a bit on what you want help for? Gregor already provided a patch, do you want testing for that or another patch with a different approach or something else? -- Niko
Bug#894727: libgit-repository-perl: FTBFS: t/10-new_fail.t broke with new git
Package: libgit-repository-perl Version: 1.321-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net, this package fails its test suite on current sid, making it fail to build from source. https://ci.debian.net/packages/libg/libgit-repository-perl/unstable/amd64/ It looks like git has slightly changed its output, probably with 1:2.17.0-1. # Failed test '... expected error message' # at t/10-new_fail.t line 51. # 'fatal: not a git repository (or any parent up to mount point /) # Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). at t/10-new_fail.t line 48. # ' # doesn't match '(?^:^fatal: Not a git repository)' # Looks like you failed 1 test of 12. [...] Test Summary Report --- t/10-new_fail.t (Wstat: 256 Tests: 12 Failed: 1) Failed test: 8 Non-zero exit status: 1 -- Niko Tyni nt...@debian.org
Bug#894626: libsnmp-info-perl: FTBFS against libsnmp-perl (src:net-snmp) 5.7.3+dfsg-2
Control: reassign -1 libsnmp-perl 5.7.3+dfsg-2 Control: retitle -1 libsnmp-perl: undefined symbol: netsnmp_ds_toggle_boolean Control: affects -1 libsnmp-info-perl On Mon, Apr 02, 2018 at 05:49:48PM +0200, gregor herrmann wrote: > Source: libsnmp-info-perl > Version: 3.53-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > As first noticed by ci.debian.net, libsnmp-info-perl fails to build, > aka has testsuite failures, since the upload of net-snmp > 5.7.3+dfsg-2. > >dh_auto_test > perl Build test --verbose 1 > > # Failed test 'use SNMP::Info;' > # at t/00_load.t line 10. > # Tried to use 'SNMP::Info'. > # Error: Can't load > '/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/NetSNMP/default_store/default_store.so' > for module NetSNMP::default_store: > /usr/lib/x86_64-linux-gnu/perl5/5.26/auto/NetSNMP/default_store/default_store.so: > undefined symbol: netsnmp_ds_toggle_boolean at > /usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187. > # at /usr/lib/x86_64-linux-gnu/perl5/5.26/SNMP.pm line 19. This is clearly a bug in the new libsnmp-perl version, which seems altogether unusable. # perl -e 'use SNMP' Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/NetSNMP/default_store/default_store.so' for module NetSNMP::default_store: /usr/lib/x86_64-linux-gnu/perl5/5.26/auto/NetSNMP/default_store/default_store.so: undefined symbol: netsnmp_ds_toggle_boolean at /usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187. at /usr/lib/x86_64-linux-gnu/perl5/5.26/SNMP.pm line 19. Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.26/SNMP.pm line 19. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.26/SNMP.pm line 19. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. Reassigning. -- Niko Tyni nt...@debian.org
Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2
On Wed, Mar 28, 2018 at 08:29:38PM +0300, Niko Tyni wrote: > So the rebuilt libalien-wxwidgets-perl has picked up wxwidgets 3.0.4 > and embedded that in the virtual package name that libwx-perl depends on. And just in case somebody wonders why: the whole story is in #757855. -- Niko
Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2
Control: reopen -1 On Wed, Mar 28, 2018 at 12:08:26AM +0200, Emilio Pozuelo Monfort wrote: > On 23/03/18 20:26, Niko Tyni wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > These are uninstallable in sid since the latest wxwidgets3.0 upload. > > Could you please binNMU them? > > > > nmu libalien-wxwidgets-perl_0.69+dfsg-1 . ANY . unstable . -m "Rebuild for > > wxwidgets3.0 3.0.4" > > Scheduled. Thanks! > > nmu libwx-perl_1:0.9932-2 . ANY . unstable . -m "Rebuild for wxwidgets3.0 > > 3.0.4" > > I don't see libwx-perl having a strict dependency on wxwidgets. I suspect this > will be fixed once libalien-wxwidgets-perl is rebuilt, please reopen and shout > if not. It's a chain via libalien-wxwidgets-perl. Package: libwx-perl Version: 1:0.9932-2 Depends: [...], wxperl-gtk2-3-0-3-uni-gcc-3-4 Package: libalien-wxwidgets-perl Version: 0.69+dfsg-1 Provides: wxperl-gtk2-3-0-3-uni-gcc-3-4 Package: libalien-wxwidgets-perl Version: 0.69+dfsg-1+b1 Provides: wxperl-gtk2-3-0-4-uni-gcc-3-4 So the rebuilt libalien-wxwidgets-perl has picked up wxwidgets 3.0.4 and embedded that in the virtual package name that libwx-perl depends on. Sorry for not being explicit about this in my original request. Reopening. -- Niko
Bug#887557: www.debian.org: tech-ctte membership updates
On Wed, Mar 28, 2018 at 01:47:03AM +0900, Osamu Aoki wrote: > On Mon, Mar 26, 2018 at 06:22:00PM +0300, Niko Tyni wrote: > > -Didier Raboud > > +Didier Raboud > > Philip Hands > > Tollef Fog Heen > > -Margarita Manterola > > +Margarita Manterola > > Can't we use neutral term "chairperson" as a tag even though we will > never see it. I'm all for that, but in this bug I'm trying to bring the actual web content up to date (including but not limited to the above changes.) Tag changes are IMO a separate matter. Could you please file another bug about that? I assume there are translations somewhere that will need updating if the tag name changes. -- Niko Tyni nt...@debian.org
Bug#887557: www.debian.org: tech-ctte membership updates
On Mon, Mar 26, 2018 at 04:10:33PM +0100, Simon McVittie wrote: > On Mon, 26 Mar 2018 at 17:33:15 +0300, Niko Tyni wrote: > > > > - > domain="organization">chairman > > + > domain="organization">chair > ... > > -Didier Raboud > ... > > +Margarita Manterola > > I don't really speak WML, but I think you probably need to > instead of if you want to > use further down the document. The alternative would be to leave the > machine-readable tag as but make it produce the human-readable > text "chair", as in a previous patch. The version in this patch looks > like a middle ground between the two that isn't going to work as intended. Oh right, thanks for noticing! I had that right earlier but goofed it up this time. New version attached... -- Niko Index: english/devel/tech-ctte.wml === RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v retrieving revision 1.71 diff -u -r1.71 tech-ctte.wml --- english/devel/tech-ctte.wml 29 Jan 2017 03:32:44 - 1.71 +++ english/devel/tech-ctte.wml 26 Mar 2018 15:20:57 - @@ -316,6 +316,12 @@ Thanks to the following people who have served on the committee: +Keith Packard (2013-11-29 - 2017-12-31) +Sam Hartman (2015-03-08 - 2017-11-09) +Don Armstrong (2009-09-11 - 2016-12-31) +Andreas Barth (2006-01-04 - 2016-12-31) +Steve Langasek (2006-01-04 - 2015-12-31) +Bdale Garbee (2001-04-17 - 2015-12-31) Colin Watson (2011-08-24 - 2015-03-05) Ian Jackson (to 2014-11-19) Russ Allbery (2009-01-11 - 2014-11-16) Index: english/intro/organization.data === RCS file: /cvs/webwml/webwml/english/intro/organization.data,v retrieving revision 1.574 diff -u -r1.574 organization.data --- english/intro/organization.data 20 Mar 2018 05:49:08 - 1.574 +++ english/intro/organization.data 26 Mar 2018 15:20:57 - @@ -36,7 +36,7 @@ wizard # we only use the chairman tag once, for techctte, I wonder why it's here. -chairman +chair # assistant tag added for DPL "second in command" assistant @@ -71,10 +71,10 @@ -Didier Raboud +Didier Raboud Philip Hands Tollef Fog Heen -Margarita Manterola +Margarita Manterola David Bremner Niko Tyni Gunnar Wolf
Bug#887557: www.debian.org: tech-ctte membership updates
On Sun, Mar 25, 2018 at 04:12:18PM +0300, Niko Tyni wrote:
> On Fri, Mar 16, 2018 at 08:40:14PM +0200, Niko Tyni wrote:
> > On Wed, Jan 17, 2018 at 11:07:41PM +0200, Niko Tyni wrote:
> >
> > > Hi, please find attached a patch to update
> > > https://www.debian.org/intro/organization
> > > for the recent tech-ctte membership changes.
> > >
> > > It also updates the rather outdated list of past members on
> > > https://www.debian.org/devel/tech-ctte
> >
> > Updated patch attached after today's nomination.
>
> Updated patch attached after today's chair election (#893200).
> I don't think this needs a separate 'appointment email' link as the
> chair is elected by the committee itself.
>
> I also changed the 'chairman' tag to output 'chair' as per
> https://www.debian.org/vote/2016/vote_003 but didn't dare to rename the
> tag itself in case that would break translations or something.
I see Laura recently updated the organization page, thanks!
That mostly covered (and invalidated) my patch; updated once more.
The remaining changes are documenting Marga as tech-ctte chair, and
updating the historical list of members in /devel/tech-ctte.
--
Niko Tyni nt...@debian.org
Index: english/devel/tech-ctte.wml
===
RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v
retrieving revision 1.71
diff -u -r1.71 tech-ctte.wml
--- english/devel/tech-ctte.wml 29 Jan 2017 03:32:44 - 1.71
+++ english/devel/tech-ctte.wml 26 Mar 2018 14:26:16 -
@@ -316,6 +316,12 @@
Thanks to the following people who have served on the committee:
+Keith Packard (2013-11-29 - 2017-12-31)
+Sam Hartman (2015-03-08 - 2017-11-09)
+Don Armstrong (2009-09-11 - 2016-12-31)
+Andreas Barth (2006-01-04 - 2016-12-31)
+Steve Langasek (2006-01-04 - 2015-12-31)
+Bdale Garbee (2001-04-17 - 2015-12-31)
Colin Watson (2011-08-24 - 2015-03-05)
Ian Jackson (to 2014-11-19)
Russ Allbery (2009-01-11 - 2014-11-16)
Index: english/intro/organization.data
===
RCS file: /cvs/webwml/webwml/english/intro/organization.data,v
retrieving revision 1.574
diff -u -r1.574 organization.data
--- english/intro/organization.data 20 Mar 2018 05:49:08 - 1.574
+++ english/intro/organization.data 26 Mar 2018 14:26:16 -
@@ -36,7 +36,7 @@
wizard
# we only use the chairman tag once, for techctte, I wonder why it's here.
-chairman
+chair
# assistant tag added for DPL "second in command"
assistant
@@ -71,10 +71,10 @@
-Didier Raboud
+Didier Raboud
Philip Hands
Tollef Fog Heen
-Margarita Manterola
+Margarita Manterola
David Bremner
Niko Tyni
Gunnar Wolf
Bug#887557: www.debian.org: tech-ctte membership updates
On Fri, Mar 16, 2018 at 08:40:14PM +0200, Niko Tyni wrote: > On Wed, Jan 17, 2018 at 11:07:41PM +0200, Niko Tyni wrote: > > > Hi, please find attached a patch to update > > https://www.debian.org/intro/organization > > for the recent tech-ctte membership changes. > > > > It also updates the rather outdated list of past members on > > https://www.debian.org/devel/tech-ctte > > Updated patch attached after today's nomination. Updated patch attached after today's chair election (#893200). I don't think this needs a separate 'appointment email' link as the chair is elected by the committee itself. I also changed the 'chairman' tag to output 'chair' as per https://www.debian.org/vote/2016/vote_003 but didn't dare to rename the tag itself in case that would break translations or something. -- Niko Tyni nt...@debian.org Index: english/devel/tech-ctte.wml === RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v retrieving revision 1.71 diff -u -r1.71 tech-ctte.wml --- english/devel/tech-ctte.wml 29 Jan 2017 03:32:44 - 1.71 +++ english/devel/tech-ctte.wml 25 Mar 2018 13:02:02 - @@ -316,6 +316,12 @@ Thanks to the following people who have served on the committee: +Keith Packard (2013-11-29 - 2017-12-31) +Sam Hartman (2015-03-08 - 2017-11-09) +Don Armstrong (2009-09-11 - 2016-12-31) +Andreas Barth (2006-01-04 - 2016-12-31) +Steve Langasek (2006-01-04 - 2015-12-31) +Bdale Garbee (2001-04-17 - 2015-12-31) Colin Watson (2011-08-24 - 2015-03-05) Ian Jackson (to 2014-11-19) Russ Allbery (2009-01-11 - 2014-11-16) Index: english/intro/organization.data === RCS file: /cvs/webwml/webwml/english/intro/organization.data,v retrieving revision 1.564 diff -u -r1.564 organization.data --- english/intro/organization.data 21 Dec 2017 06:52:58 - 1.564 +++ english/intro/organization.data 25 Mar 2018 13:02:02 - @@ -36,7 +36,7 @@ wizard # we only use the chairman tag once, for techctte, I wonder why it's here. -chairman +chair # assistant tag added for DPL "second in command" assistant @@ -65,15 +65,15 @@ Leader> - Technical Committee> -Didier Raboud + Technical Committee> +Didier Raboud Philip Hands -Sam Hartman Tollef Fog Heen -Keith Packard -Margarita Manterola +Margarita Manterola David Bremner Niko Tyni +Gunnar Wolf +Simon McVittie Secretary> Kurt Roeckx
Bug#893601: libperl5.26: printf_format_null Configure test is broken on 64-bits
Control: forwarded -1 https://github.com/perl5-metaconfig/metaconfig/pull/53
On Tue, Mar 20, 2018 at 10:23:32AM +, James Cowgill wrote:
> Package: libperl5.26
> Version: 5.26.1-5
> Severity: normal
> Tags: patch
> int null_printf (char* pat,...) { return (int)pat; }
>
> GCC complains about the pointer to integer cast of the wrong size but
> only on 64-bits. I've attached a patch to fix this by casting through
> intptr_t first.
Many thanks for catching this and providing a patch!
I've forwarded it upstream, will apply with the next upload.
--
Niko Tyni nt...@debian.org
Bug#893923: nmu: libalien-wxwidgets-perl_0.69+dfsg-1 libwx-perl_1:0.9932-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu These are uninstallable in sid since the latest wxwidgets3.0 upload. Could you please binNMU them? nmu libalien-wxwidgets-perl_0.69+dfsg-1 . ANY . unstable . -m "Rebuild for wxwidgets3.0 3.0.4" nmu libwx-perl_1:0.9932-2 . ANY . unstable . -m "Rebuild for wxwidgets3.0 3.0.4" -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#893200: TC Chair election
On Fri, Mar 23, 2018 at 05:59:47PM +0200, Niko Tyni wrote: > On Sat, Mar 17, 2018 at 10:25:28AM +0100, Didier 'OdyX' Raboud wrote: > > > ===BEGIN=== > > > > The chair of the Debian Technical Committee will be: > > > > A : Didier Raboud > > B : Tollef Fog Heen > > C : Phil Hands > > D : Margarita Manterola > > E : David Bremner > > F : Niko Tyni > > G : Gunnar Wolf > > H : Simon McVittie > > ===END=== > > I vote: C = D > E = F = G > A = B > H Argh, signed with a wrong key. Sorry about that. This one is (hopefully) better. -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#893200: TC Chair election
On Sat, Mar 17, 2018 at 10:25:28AM +0100, Didier 'OdyX' Raboud wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Didier Raboud > B : Tollef Fog Heen > C : Phil Hands > D : Margarita Manterola > E : David Bremner > F : Niko Tyni > G : Gunnar Wolf > H : Simon McVittie > ===END=== I vote: C = D > E = F = G > A = B > H -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#893472: libfurl-perl: broken on s390x?
On Tue, Mar 20, 2018 at 10:02:34AM +0100, Jonas Smedegaard wrote: > I believe circular build-dependencies for testsuite needs can - and > should be addressed by marking such build-dependencies appropriately, > rather than skipping them - for exactly situations like this. Sure. > Question then what the appropriate way to express cycle-breaking > hints... :-) I believe the way to express this is to annotate the build dependency with . (Though build cycles are probably not much of a deal with arch:all packages in the first place.) -- Niko
Bug#893472: libfurl-perl: broken on s390x?
Control: retitle -1 libplack-middleware-deflater-perl: broken on big endian
hosts
Control: reassign -1 libplack-middleware-deflater-perl 0.12-1
Control: tag -1 patch
Control: affects -1 libfurl-perl
On Mon, Mar 19, 2018 at 09:35:03PM +0200, Niko Tyni wrote:
> I got as far as seeing that removing line 144 in Deflater.pm
>
>
> https://sources.debian.org/src/libplack-middleware-deflater-perl/0.12-1/lib/Plack/Middleware/Deflater.pm/#L144
>
> - $buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding}
> eq 'gzip';
>
> makes both test suites pass, but that doesn't seem like a fully
> satisfactory patch. (And no, s/LL/NN/ doesn't fix it.)
Hum, this is somewhat embarrassing. s/LL/VV/ does seem to fix it, which
makes sense as L and N are equivalent on big-endian while L and V are
equivalent on little-endian. I blame lack of sleep.
Also, RFC 1952 says
All multi-byte numbers in the format described here are stored
with the least-significant byte first (at the lower memory address).
so little endian seems to be correct.
Lightly tested patch attached; reassigning.
--
Niko
>From 480e68c781ddad1e5a19446c13134c8fde2a34e8 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Tue, 20 Mar 2018 21:51:49 +0200
Subject: [PATCH] Fix gzip trailer on big endian hosts
These values need to be stored as little endian regardless
of the host endianness.
Bug-Debian: https://bugs.debian.org/893472
---
lib/Plack/Middleware/Deflater.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Plack/Middleware/Deflater.pm b/lib/Plack/Middleware/Deflater.pm
index 4cb0b03..c823c38 100644
--- a/lib/Plack/Middleware/Deflater.pm
+++ b/lib/Plack/Middleware/Deflater.pm
@@ -141,7 +141,7 @@ sub print : method {
if ( !$self->{header} && $self->{encoding} eq 'gzip' ) {
$buf = pack("nccVcc",GZIP_MAGIC,Z_DEFLATED,0,time(),0,$Compress::Raw::Zlib::gzip_os_code) . $buf
}
-$buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
+$buf .= pack("VV", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
$self->{closed} = 1;
return $buf;
}
--
2.16.2
Bug#893472: libfurl-perl: broken on s390x?
On Mon, Mar 19, 2018 at 01:03:12AM -0700, Steve Langasek wrote:
> Source: libfurl-perl
> Version: 3.13-1
> Severity: grave
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu bionic autopkgtest
> t/100_low/13_deflate.t ..
> # normal 1 gzip
> Uncompress error: data error at /usr/share/perl5/Furl/HTTP.pm line 845.
> From what I'm able to tell, this test failure points to the library actually
> being broken on s390x, as it fails to decompress data sent back by the
> test server which is implemented using libplack-middleware-deflater-perl.
> But it's also possible that it's libplack-middleware-deflater-perl which is
> broken on s390x, in which case this bug should be certainly reassigned.
Thanks for the report. Testing on zelenka.d.o, I see the same behaviour.
I suspect the real culprit is libplack-middleware-deflater-perl; it uses
pack() in suspicious ways that might break on big vs. little endian.
Its own t/furl.t is failing similarly, but gets skipped on Debian
build+autopkgtest because libfurl-perl is not a build dependency of
libplack-middleware-deflater-perl (possibly due to build cycle reasons.)
I got as far as seeing that removing line 144 in Deflater.pm
https://sources.debian.org/src/libplack-middleware-deflater-perl/0.12-1/lib/Plack/Middleware/Deflater.pm/#L144
- $buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding}
eq 'gzip';
makes both test suites pass, but that doesn't seem like a fully
satisfactory patch. (And no, s/LL/NN/ doesn't fix it.)
There's some probably related upstream discussion in
https://github.com/miyagawa/Plack-Middleware-Deflater/issues/11
https://github.com/miyagawa/Plack-Middleware-Deflater/commit/02db7d339af94c9013a81f17189fccf082cfe3a9
No tuits to actually dig into gzip streams at least tonight...
--
Niko Tyni nt...@debian.org
Bug#893469: perl FTCBFS: error: unknown type name '_LIB_VERSION_TYPE'
On Mon, Mar 19, 2018 at 08:41:10AM +0100, Helmut Grohne wrote: > Source: perl > Version: 5.26.1-5 > User: helm...@debian.org > Usertags: rebootstrap > > Hi perl maintainers, > > I see that you keep updating those cross files in the debian folder. > Thus it seems like you would still be interested in learning when cross > building perl stops working even when I tell you without attaching a > patch. (Sorry) That's absolutely fine, thanks for the report! > | powerpc-linux-gnu-gcc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/build/perl-NAqo_f/perl-5.26.1=. -fstack-protector-strong > -Wformat -Werror=format-security -fwrapv -fno-strict-aliasing -pipe > -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 > -g -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat > -Wwrite-strings pp.c > | pp.c:47:5: error: unknown type name '_LIB_VERSION_TYPE'; did you mean > '__VERSION__'? > | _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_; > The host architecture being used seems to be irrelevant. I looked and > couldn't figure out what is wrong here. Could it be that some configure > result is cached wrongly somehow? Yeah, pretty much that. Quoting Aurelien in #890242 : Starting with glibc 2.27, support for the "ieee" library (part of SVID specification) has been removed. The libieee.a library is therefore not shipped anymore. perl correctly detects that it is not available and build fine, but it introduces a small symbol change, as _LIB_VERSION is provided by libieee.a. Looks like regen-configure/U/perl/d_libm_lib_version.U probes for _LIB_VERSION and stores the result in config.sh as 'd_libm_lib_version'. Now that it's gone from libm and math.h, the stored config.sh files need to be updated. I'll do that for the next upload; should be just a matter of sed -i "s/d_libm_lib_version='define'/d_libm_lib_version='undef'/" debian/cross/*/config.sh.static -- Niko
Bug#887557: www.debian.org: tech-ctte membership updates
On Wed, Jan 17, 2018 at 11:07:41PM +0200, Niko Tyni wrote:
> Hi, please find attached a patch to update
> https://www.debian.org/intro/organization
> for the recent tech-ctte membership changes.
>
> It also updates the rather outdated list of past members on
> https://www.debian.org/devel/tech-ctte
Updated patch attached after today's nomination.
--
Niko
Index: english/devel/tech-ctte.wml
===
RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v
retrieving revision 1.71
diff -u -r1.71 tech-ctte.wml
--- english/devel/tech-ctte.wml 29 Jan 2017 03:32:44 - 1.71
+++ english/devel/tech-ctte.wml 16 Mar 2018 18:31:13 -
@@ -316,6 +316,12 @@
Thanks to the following people who have served on the committee:
+Keith Packard (2013-11-29 - 2017-12-31)
+Sam Hartman (2015-03-08 - 2017-11-09)
+Don Armstrong (2009-09-11 - 2016-12-31)
+Andreas Barth (2006-01-04 - 2016-12-31)
+Steve Langasek (2006-01-04 - 2015-12-31)
+Bdale Garbee (2001-04-17 - 2015-12-31)
Colin Watson (2011-08-24 - 2015-03-05)
Ian Jackson (to 2014-11-19)
Russ Allbery (2009-01-11 - 2014-11-16)
Index: english/intro/organization.data
===
RCS file: /cvs/webwml/webwml/english/intro/organization.data,v
retrieving revision 1.564
diff -u -r1.564 organization.data
--- english/intro/organization.data 21 Dec 2017 06:52:58 - 1.564
+++ english/intro/organization.data 16 Mar 2018 18:31:13 -
@@ -65,15 +65,15 @@
Leader>
- Technical Committee>
+ Technical Committee>
Didier Raboud
Philip Hands
-Sam Hartman
Tollef Fog Heen
-Keith Packard
Margarita Manterola
David Bremner
Niko Tyni
+Gunnar Wolf
+Simon McVittie
Secretary>
Kurt Roeckx
Bug#880014: Call for Votes for new TC member
On Sun, Mar 04, 2018 at 11:44:45AM +0100, Didier 'OdyX' Raboud wrote: > ===BEGIN > The Technical Committee recommends that Simon McVittie be > appointed by the Debian Project Leader to the Technical Committee. > > S: Recommend to Appoint Simon McVittie <s...@debian.org> > F: Further Discussion > ===END I vote: S > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#891440: libatteanx-compatibility-trine-perl: missing dependency on libattean-perl
Package: libatteanx-compatibility-trine-perl Version: 0.001-1 Severity: serious This package is missing a dependency on libattean-perl. # perl -e 'use AtteanX::Compatibility::Trine' Can't locate Attean.pm in @INC (you may need to install the Attean module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/AtteanX/Compatibility/Trine.pm line 10. BEGIN failed--compilation aborted at /usr/share/perl5/AtteanX/Compatibility/Trine.pm line 10. It looks like debian/control has cdbs based substvars but the package doesn't actually use cdbs. Plug: declaring "Testsuite: autopkgtest-pkg-perl" would have caught this... -- Niko Tyni nt...@debian.org
Bug#891431: libatteanx-compatibility-trine-perl FTBFS: t/literal.t failure
Control: tag -1 fixed-upstream On Sun, Feb 25, 2018 at 04:47:19PM +0200, Adrian Bunk wrote: > Source: libatteanx-compatibility-trine-perl > Version: 0.001-1 > Severity: serious > > Some recent change in unstable makes libatteanx-compatibility-trine-perl > FTBFS: > > https://tests.reproducible-builds.org/debian/history/libatteanx-compatibility-trine-perl.html > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libatteanx-compatibility-trine-perl.html > > ... > # Failed test 'Got langString data type' This seems to be fixed in 0.002 (which CPAN marks as UNAUTHORIZED for some reason). From Changes: 0.002 2018-02-05 [ Bug Fixes ] - Fix the langString error coded to Attean. -- Niko Tyni nt...@debian.org
Bug#889471: libcairo-perl: FTBFS: t/CairoSurface.t failure
Control: reassign -1 libcairo2 1.15.10-1 Control: retitle -1 cairo: PNG handling regression in 1.15.10 Control: tag -1 patch fixed-upstream Control: affects -1 libcairo-perl On Sat, Feb 03, 2018 at 07:55:23PM +0200, Niko Tyni wrote: > On Sat, Feb 03, 2018 at 07:19:24PM +0200, Niko Tyni wrote: > > Package: libcairo-perl > > Version: 1.106-2 > > Severity: serious > > User: debian-p...@lists.debian.org > > Usertags: autopkgtest > > > > As noticed by ci.debian.net, the test suite of this package > > recently started failing. > > > > Test Summary Report > > --- > > t/CairoSurface.t (Wstat: 139 Tests: 41 Failed: 0) > > Non-zero wait status: 139 > > Parse errors: Bad plan. You planned 88 tests but ran 41. > > Files=9, Tests=256, 0 wallclock secs ( 0.08 usr 0.00 sys + 0.58 cusr > > 0.05 csys = 0.71 CPU) > > Result: FAIL > > > > Timing suggests src:cairo (1.15.8-3 -> 1.15.10-1) as the probable cause > > for this regression. > > Confirmed by downgrading libcairo2; that makes the test suite pass again. This seems to be similar to https://bugs.freedesktop.org/show_bug.cgi?id=104325 as my tests indicate that the corresponding fix https://cgit.freedesktop.org/cairo/commit/?id=82f4028532c11152a0110f1b277e3358dfca6545 also fixes the libcairo-perl test suite crash. Reassigning accordingly. -- Niko Tyni nt...@debian.org
Bug#891304: libconfig-model-backend-augeas-perl: FTBFS: test failures
Package: libconfig-model-backend-augeas-perl Version: 0.123-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net, this package fails its test suite on current sid, making it also fail to build from source. This regressed around 2018-02-19, probably with -libconfig-model-perl 2.116-1 +libconfig-model-perl 2.117-1 See https://ci.debian.net/packages/libc/libconfig-model-backend-augeas-perl/unstable/amd64/ # Failed test 'check dump of augeas data' # at t/augeas_backend.t line 93. # got: ' # ' # expected: 'record:0 # ipaddr=127.0.0.1 # canonical=localhost # alias=localhost - # record:1 # ipaddr=192.168.0.1 # canonical=bilbo - - # ' [...] Test Summary Report --- t/augeas_backend.t (Wstat: 3072 Tests: 18 Failed: 12) Failed tests: 3, 5-7, 9-10, 13-18 Non-zero exit status: 12 t/augeas_from_scratch.t (Wstat: 512 Tests: 3 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 4 tests but ran 3. Files=4, Tests=26, 3 wallclock secs ( 0.05 usr 0.00 sys + 2.81 cusr 0.15 csys = 3.01 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#891229: perl: missing NDBM_File and ODBM_File due to the libgdbm5 transition
Package: perl Version: 5.26.1-4 It looks like the rebuilds against libgdbm5 (perl_5.26.1-4+b1) lost the NDBM_File and ODBM_File modules. The relevant headers have been moved to libgdbm-compat-dev, so a build dependency on that should fix this. -- Niko Tyni nt...@debian.org
Bug#891196: perl: memory leak in S_concat_pat()
Package: perl
Version: 5.26.1-4
Severity: important
Tags: patch fixed-upstream
Forwarded: https://rt.perl.org/Public/Bug/Display.html?id=132892
As reported by 郭樂聰 in the upstream bug, this leaks memory:
% perl -e 'my %h=(qr/a/ => 1); while (1) { /$_/ for keys %h}'
This regressed in 5.25.5 with
https://perl5.git.perl.org/perl.git/commit/b10cb25a6c86fd96fff8f2dfa6d8df3e6b51a451
and was fixed recently in blead by
https://perl5.git.perl.org/perl.git/commit/910a6a8be166fb3780dcd2520e3526e537383ef2
which I'm attaching as well.
--
Niko Tyni nt...@debian.org
>From 910a6a8be166fb3780dcd2520e3526e537383ef2 Mon Sep 17 00:00:00 2001
From: Yves Orton <demer...@gmail.com>
Date: Fri, 23 Feb 2018 04:13:49 +0100
Subject: [PATCH] perl #132892: avoid leak by mortalizing temporary copy of
pattern
---
regcomp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/regcomp.c b/regcomp.c
index 34ac9169f2..446f0bf839 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -6515,8 +6515,8 @@ S_concat_pat(pTHX_ RExC_state_t * const pRExC_state,
pat = msv;
} else {
/* a string with no trailing null, we need to copy it
- * so it we have a trailing null */
-pat = newSVsv(msv);
+ * so it has a trailing null */
+pat = sv_2mortal(newSVsv(msv));
}
}
--
2.16.1
Bug#864875: debconf: frontend exits with status 10 after last upgrade when /var/cache is tmpfs
On Thu, Feb 15, 2018 at 09:08:23PM +, Colin Watson wrote: > On Thu, Feb 15, 2018 at 08:58:29PM +0200, Niko Tyni wrote: > > I'm a bit surprised by #247134. Doesn't the "debconf is not a registry" > > mantra imply that all data in /var/cache/debconf should be possible to > > regenerate from config files in /etc/ and the like? > > Well, that's the noble intent, but (even aside from debconf not quite > recreating the bits it needs for itself) I'm not aware that anyone tests > it and it's probably never been true in reality. Heh, I guess I've just revealed how gullible I really am. Thanks for the reality check. -- Niko
Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse
Control: close -1 On Thu, Feb 15, 2018 at 05:21:17PM +0100, gregor herrmann wrote: > On Fri, 04 Aug 2017 16:52:21 -0400, Alex Muntada wrote: > > > Niko Tyni: > > > I think I'm leaving this for now. We can see if it becomes a problem > > > later, and if not, just close this. > > Agreed. > > I think we can close this bug now. At least I don't remember seeing > any problems with the recursive tests since August. Sure, fine by me so closing. -- Niko
Bug#864875: debconf: frontend exits with status 10 after last upgrade when /var/cache is tmpfs
On Thu, Feb 15, 2018 at 03:26:50PM +, Colin Watson wrote: > On Thu, Feb 15, 2018 at 10:39:15AM +, Dominic Hargreaves wrote: > > The debconf database *is* in /var/cache so I don't know how anything > > can be expected to work after it's wiped. But according to the FHS > > what Franz is doing is completely allowable... > > > > CCing the Debconf developers in case they can shed any light on this. > > Sounds like the long-known https://bugs.debian.org/247134. It probably > needs to be dealt with at some point, but oh goodness the anticipated > migration pain ... I'm a bit surprised by #247134. Doesn't the "debconf is not a registry" mantra imply that all data in /var/cache/debconf should be possible to regenerate from config files in /etc/ and the like? To elaborate, I always thought that debconf based maintainer scripts need to store all configuration information somewhere else in the file system, and read those files back in for default values when re-asking the questions (possibly overriding whatever is in the debconf database in case the system administrator has changed the external configuration in between.) In the context of this bug, I'd expect dbconfig-common to read in /etc/dbconfig-common/request-tracker4.conf and fill in the empty (nuked) debconf database based on that. -- Niko Tyni nt...@debian.org
Bug#864875: request-tracker4: frontend exists with status 10 after last upgrade
On Tue, Feb 13, 2018 at 11:54:33PM +, Dominic Hargreaves wrote: > Apologies for the delay in responding. I recall testing this > at the time and not being able to reproduce - however perhaps you could > let us know whether changing /var/cache to not be a tmpfs makes a > difference? If so, I would think that would be a bug either in > debconf or dbconfig-common. FWIW it looks to me like the 'set -e' command at https://sources.debian.org/src/request-tracker4/4.4.2-1/debian/config/#L252 is the immediate problem. I see dbconfig-common writes out /etc/dbconfig-common/request-tracker4.conf when request-tracker4 first gets configured, with variables like dbc_install defined there. I'm somewhat surprised if those do not end up in the debconf database after calling dbc_go even if the debconf database in /var/cache got nuked in between, but I haven't really looked into this (and can't really promise to do that soon.) So it could really be a bug in either dbconfig-common or in the config script or both :) Digging into the old SVN history, that 'set -e' has been there from the start (= 2007). This certainly seems to be a corner case... -- Niko Tyni nt...@debian.org
Bug#890242: perl: FTBFS with glibc-2.27: some symbols or patterns disappeared in the symbols file
On Mon, Feb 12, 2018 at 12:53:12PM +0100, Aurelien Jarno wrote: > Package: perl > Version: 5.26.1-4 > Severity: important > Tags: patch > User: debian-gl...@lists.debian.org > Usertags: 2.27 > > perl 5.26.1-4 fails to build with glibc 2.27 (2.27-0experimental0 from > experimental): > | - _LIB_VERSION@Base 5.26.0~rc1 > | +#MISSING: 5.26.1-4# _LIB_VERSION@Base 5.26.0~rc1 > The solution for it to work with both glibc 2.27 and older version is to > mark the symbol as optional. This should not be a problem, as a package > which needs the "ieee" library has to link against libieee.a which will > then provide the symbols. In addition no such package perl package has > been found during the archive rebuild. > > Therefore the following simple patch should be enough to fix the issue: Many thanks! Will fix once the gdbm transition is over. -- Niko
Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering
On Fri, Feb 09, 2018 at 09:14:49AM +0100, Didier 'OdyX' Raboud wrote: > === Resolution === > > In 2014, it was resolved in #746578 that the libpam-systemd binary package > alternative dependency on systemd-shim and systemd-sysv shall be set in that > order, in order to avoid unwanted init system changes accross upgrades. > Debian > Stretch has since been released. > > The Committee therefore resolves that: > > 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed. > > This means Debian's normal policies and practices take over and the > libpam-systemd package's dependencies are set free from specific ordering > constraints. The migration should be managed according to Debian's usual > backwards-compatibility arrangements. > > === End Resolution === > > R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578. > F: Further Discussion I vote: R > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#889471: libcairo-perl: FTBFS: t/CairoSurface.t failure
On Sat, Feb 03, 2018 at 07:19:24PM +0200, Niko Tyni wrote: > Package: libcairo-perl > Version: 1.106-2 > Severity: serious > User: debian-p...@lists.debian.org > Usertags: autopkgtest > > As noticed by ci.debian.net, the test suite of this package > recently started failing. > > Test Summary Report > --- > t/CairoSurface.t (Wstat: 139 Tests: 41 Failed: 0) > Non-zero wait status: 139 > Parse errors: Bad plan. You planned 88 tests but ran 41. > Files=9, Tests=256, 0 wallclock secs ( 0.08 usr 0.00 sys + 0.58 cusr > 0.05 csys = 0.71 CPU) > Result: FAIL > > Timing suggests src:cairo (1.15.8-3 -> 1.15.10-1) as the probable cause > for this regression. Confirmed by downgrading libcairo2; that makes the test suite pass again. Copying the cairo maintainers FYI. With libcairo2 1.15.10-1, t/CairoSurface.t the libcairo-perl test suite segfaults: ok 36 - An object of class 'Cairo::ImageSurface' isa 'Cairo::ImageSurface' ok 37 - An object of class 'Cairo::ImageSurface' isa 'Cairo::Surface' ok 38 - An object of class 'Cairo::ImageSurface' isa 'Cairo::ImageSurface' ok 39 - An object of class 'Cairo::ImageSurface' isa 'Cairo::Surface' ok 40 ok 41 Segmentation fault Backtrace with -O0: Core was generated by `perl -Iblib/lib -Iblib/arch t/CairoSurface.t'. Program terminated with signal SIGSEGV, Segmentation fault. #0 png_get_IHDR (png_ptr=0x55bf0389cdd0, info_ptr=0x55bf035c6480, width=width@entry=0x7ffcbf7e50c0, height=height@entry=0x55bf0328eb01, bit_depth=bit_depth@entry=0x8, color_type=color_type@entry=0x, interlace_type=0x7ffcbf7e4fb0, compression_type=0x0, filter_type=0x0) at pngget.c:841 841 pngget.c: No such file or directory. (gdb) bt #0 png_get_IHDR (png_ptr=0x55bf0389cdd0, info_ptr=0x55bf035c6480, width=width@entry=0x7ffcbf7e50c0, height=height@entry=0x55bf0328eb01, bit_depth=bit_depth@entry=0x8, color_type=color_type@entry=0x, interlace_type=0x7ffcbf7e4fb0, compression_type=0x0, filter_type=0x0) at pngget.c:841 #1 0x7f1876db570f in read_png (png_closure=png_closure@entry=0x7ffcbf7e5020) at ../../../../src/cairo-png.c:595 #2 0x7f1876db5e65 in cairo_image_surface_create_from_png_stream (read_func=, closure=) at ../../../../src/cairo-png.c:837 #3 0x7f1877050809 in XS_Cairo__ImageSurface_create_from_png_stream (my_perl=0x55bf03289260, cv=0x55bf037f8a28) at CairoSurface.xs:494 #4 0x55bf01174121 in Perl_pp_entersub (my_perl=0x55bf03289260) at pp_hot.c:4231 #5 0x55bf0116bf46 in Perl_runops_standard (my_perl=0x55bf03289260) at run.c:41 #6 0x55bf010ed08f in S_run_body (oldscope=, my_perl=) at perl.c:2519 #7 perl_run (my_perl=0x55bf03289260) at perl.c:2447 #8 0x55bf010c43a2 in main (argc=, argv=, env=) at perlmain.c:123 -- Niko Tyni nt...@debian.org
Bug#889471: libcairo-perl: FTBFS: t/CairoSurface.t failure
Package: libcairo-perl Version: 1.106-2 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net, the test suite of this package recently started failing. Test Summary Report --- t/CairoSurface.t (Wstat: 139 Tests: 41 Failed: 0) Non-zero wait status: 139 Parse errors: Bad plan. You planned 88 tests but ran 41. Files=9, Tests=256, 0 wallclock secs ( 0.08 usr 0.00 sys + 0.58 cusr 0.05 csys = 0.71 CPU) Result: FAIL Timing suggests src:cairo (1.15.8-3 -> 1.15.10-1) as the probable cause for this regression. -- Niko Tyni nt...@debian.org
Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked
On Sun, Jan 21, 2018 at 05:32:01AM +0100, Guillem Jover wrote: > On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote: > > Control: clone -1 -2 > > Control: retitle -2 libglib2.0-dev: needs dummy empty prerm > > Control: reassign -2 libglib2.0-dev 2.54.2-1 > > > > >> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For > > >> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this > > Even if python is going to get fixed, this probably won't help > > libglib2.0-dev (which drops the python dependency in buster), therefore > > it will need to add the dummy empty prerm to mitigate this issue. > > I don't see why this would be needed. If python gets fixed to use > Pre-Depends, then it does not matter whether libglib2.0-dev stops > depending on it, as python should then be always usable even when > just unpacked. stretch# apt --no-install-recommends install glib2.0-dev [...] stretch# dpkg --unpack libexpat1_2.2.5-3_amd64.deb # from sid [...] stretch# dpkg --unpack libglib2.0-dev_2.54.3-1_amd64.deb # from sid /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1) dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... dpkg: error processing archive libglib2.0-dev_2.54.3-1_amd64.deb (--unpack): there is no script in the new version of the package - giving up /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1) dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 No python3 change in sid/buster is going to prevent this afaics? -- Niko Tyni nt...@debian.org
Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked
On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote: > For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this > error starts to show up elsewhere (e.g. in a package where both old and > new prerm use python3), probably adding the Pre-Depends to libexpat1 > would be the general solution. FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would be a wrong place to fix this longer-term, though it might be a viable workaround for now. I fear that this will pop up with zlib1g (another dependency of python3.5-minimal in stretch) next as soon as it gets built against a newer glibc version. And having special handling in libexpat1 and zlib1g because they happen to be dependencies of python3.x-minimal seems wrong. The core problem here is python3 usage in 'prerm upgrade'. Non-essential packages are not generally safe to use at that point. AFAICS, if python3.x-minimal is intended to be usable in 'prerm upgrade', it needs to follow the same rules as essential packages: "must supply all of their core functionality even when unconfigured" (policy 3.8). In practice I think that means it must Pre-Depend on all the libraries it links against, (so libexpat1 and zlib1g in addition to the current pre-dependency on libc.) [I don't know if even that is enough or if apt/dpkg give special treatment to packages tagged Essential:yes in this context.] Now, as we can't change python3 in stretch anymore, we can either push this down the chain in sid/buster and modify new libexpat1 and zlib1g to pre-depend on libc as a workaround, or we have to add fallback 'new-prerm failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch is using python3. I see the py3clean invocation is generated by dh_python3 so this is probably going to be much wider issue than just libglib2.0-dev... Just my two cents, -- Niko Tyni nt...@debian.org
Bug#887557: www.debian.org: tech-ctte membership updates
Package: www.debian.org Tags: patch X-Debbugs-Cc: debian-c...@lists.debian.org Hi, please find attached a patch to update https://www.debian.org/intro/organization for the recent tech-ctte membership changes. It also updates the rather outdated list of past members on https://www.debian.org/devel/tech-ctte I'm copying the tech-ctte list; eyeballs would be welcome. Please speak up if you spot an error or omission. Thanks for your work on Debian, -- Niko Tyni nt...@debian.org Index: english/intro/organization.data === RCS file: /cvs/webwml/webwml/english/intro/organization.data,v retrieving revision 1.564 diff -u -r1.564 organization.data --- english/intro/organization.data 21 Dec 2017 06:52:58 - 1.564 +++ english/intro/organization.data 17 Jan 2018 21:00:23 - @@ -65,15 +65,14 @@ Leader> - Technical Committee> + Technical Committee> Didier Raboud Philip Hands -Sam Hartman Tollef Fog Heen -Keith Packard Margarita Manterola David Bremner Niko Tyni +Gunnar Wolf Secretary> Kurt Roeckx Index: english/devel/tech-ctte.wml === RCS file: /cvs/webwml/webwml/english/devel/tech-ctte.wml,v retrieving revision 1.71 diff -u -r1.71 tech-ctte.wml --- english/devel/tech-ctte.wml 29 Jan 2017 03:32:44 - 1.71 +++ english/devel/tech-ctte.wml 17 Jan 2018 21:00:23 - @@ -316,6 +316,12 @@ Thanks to the following people who have served on the committee: +Keith Packard (2013-11-29 - 2017-12-31) +Sam Hartman (2015-03-08 - 2017-11-09) +Don Armstrong (2009-09-11 - 2016-12-31) +Andreas Barth (2006-01-04 - 2016-12-31) +Steve Langasek (2006-01-04 - 2015-12-31) +Bdale Garbee (2001-04-17 - 2015-12-31) Colin Watson (2011-08-24 - 2015-03-05) Ian Jackson (to 2014-11-19) Russ Allbery (2009-01-11 - 2014-11-16)
Bug#887084: libmoosex-xsaccessor-perl: FTBFS: t/moose_accessor_overwrite_warning.t broken by new libmoose-perl
Package: libmoosex-xsaccessor-perl Version: 0.007-1 Severity: serious Tags: fixed-upstream Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=120155 This package fails its test suite on current sid, apparently due to a libmoose-perl update. The problem should be fixed in 0.008 as seen in the upstream bug. -- Niko Tyni nt...@debian.org
Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC
Control: reassign -1 perl Control: affects -1 polymake Control: severity -1 important On Tue, Jan 09, 2018 at 04:55:26PM +, Dominic Hargreaves wrote: > On Mon, Jan 08, 2018 at 10:40:19PM +0200, Niko Tyni wrote: > > A test build fixes the polymake issue and doesn't seem to break anything > > major. > > > > I'm inclined to reassign this bug to perl and close it with the above > > change unless I hear arguments to the contrary. > > This all looks well reasoned and sensible, thanks for digging into > that! Thanks everybody, reassigning now and fixing shortly (assuming no last minute surprises.) -- Niko Tyni nt...@debian.org
Bug#873006: libgtk3-webkit2-perl: missing dependency on gir1.2-webkit2-4.0
On Thu, Jan 11, 2018 at 11:44:58PM -0500, Jeremy Bicha wrote: > If perl works like all the other languages that use GObject > Introspection, then libgtk3-webkit2-perl should depend on > gir1.2-webkit2-4.0 instead of depending on the -dev package. > > Please fix this unless you have a good reason why you think this > package needs the -dev package. Thanks, will fix. -- Niko
Bug#886267: Voting for TC Chair
On Wed, Jan 03, 2018 at 05:38:56PM +0100, Didier 'OdyX' Raboud wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Didier Raboud > B: Tollef Fog Heen > C: Phil Hands > D: Margarita Manterola > E: David Bremner > F: Niko Tyni > G: Gunnar Wolf > ===END=== I vote: A > B = C = D = E > F > G Thanks for volunteering to serve as the chair. -- Niko signature.asc Description: PGP signature
Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC
On Sun, Jan 07, 2018 at 05:04:17PM +0200, Niko Tyni wrote: > The wasted stats could certainly be fixed by modifying our relevant > changes to perl.c > > https://sources.debian.org/src/perl/5.26.1-3/debian/patches/debian/mod_paths.diff/ > but I haven't looked into that properly yet. I did this now and pushed to the 'ntyni/inc-version-list' branch of the Debian perl git repository. The relevant changes are https://anonscm.debian.org/cgit/perl/perl.git/diff/debian/patches/debian/mod_paths.diff?h=ntyni/inc-version-list=3885251398d6e2897fa57cafe61134e4e14593ac https://anonscm.debian.org/cgit/perl/perl.git/commit/?h=ntyni/inc-version-list=f8e4ea6058a58019e78a5c3225a6ab4a3d0c6700 A test build fixes the polymake issue and doesn't seem to break anything major. I'm inclined to reassign this bug to perl and close it with the above change unless I hear arguments to the contrary. Thanks, -- Niko Tyni nt...@debian.org
Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC
Thanks for your reply, Benjamin! I'm copying p...@packages.debian.org
again and looking for input from my comaintainer Dominic. See below.
On Sat, Jan 06, 2018 at 10:07:47PM +0100, Benjamin Lorenz wrote:
> On 01/06/2018 08:08 PM, Niko Tyni wrote:
> > Running polymake currently fails with
> >
> > $ polymake
> > Can't locate loadable object for module Polymake::Ext in @INC
> >
> > Apparently this is because it was built with Perl 5.26.0, but
> > we've since moved to 5.26.1.
> >
> > I see two better alternatives:
> >
> > 1) [preferrable] fix polymake not to install its extensions in a
> > versioned directory (currently /usr/lib/polymake/perlx/5.26.0).
>
> This would work for minor updates (5.26.0 -> 5.26.1 seems to work) but
> the extension does depend heavily on the major version, so I dont think
> this is a good idea.
I was looking at the Debian packaging point of view, where it would be
fine, as there's no expectation of multiple versions being installed at
the same time, and package dependencies ensure binary compatibility with
/usr/bin/perl. But yeah, I can see that it's problematic upstream. It
seems that it would be possible to make that configurable, though.
> > I note that the confusing @INC list above (it has
> > /usr/lib/polymake/perlx/5.26.0 so it looks like it should work) is
> > because "use lib" will add versioned subdirectories to @INC if it
> > finds any, but will apparently *not* add arch-specific subdirectories
> > (like /usr/lib/polymake/perlx/5.26.0/x86_64-linux-gnu-thread-multi)
> > under those, and that's what would be needed here. I'm not quite sure
> > if this is a glitch in lib.pm's handling of binary-compatible versions
> > ($Config{inc_version_list}).
>
> This is a good point, it looks like the Config.pm contains:
> inc_version_list => '5.26.0',
>
> but the perl INSTALL file states:
>
> > If you do want to use modules from some previous perl versions, the
> > variable must contain a space separated list of directories under the
> > site_perl directory, and has to include architecture-dependent
> > directories separately, eg.
> >
> > sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...
Thanks, I had not noticed this! So it's not a glitch in lib.pm
but expected behaviour.
> It seems the perl Configure script tries to generate this list
> automatically (probably from $sitelib=/usr/local/share/perl/5.26.1) but
> failed to pick up the arch-specific directory because it might not exist?
We already disable the autogeneration and pass inc_version_list to
Configure manually when building the perl package.
> I dont have such an installation at hand but this could be tested by
> adding the arch-specific path for inc_version_list in
> '/usr/lib/x86_64-linux-gnu/perl/5.26.1/Config.pm' manually first. If
> this helps, the Configure command for perl should probably get an extra
> -Dinc_version_list=.
I tried it out locally with
inc_version_list='5.26.0 5.26.0/x86_64-linux-gnu-thread-multi'
and it indeed fixes this issue, at the cost of three useless stat()
calls on every perl invocation.
stat("/usr/local/lib/site_perl/x86_64-linux-gnu-thread-multi", ) = -1 ENOENT
(No such file or directory)
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.26.0", ) = -1 ENOENT (No such
file or directory)
stat("/usr/local/share/perl/5.26.0", ) = -1 ENOENT (No such file or directory)
+stat("/usr/local/lib/x86_64-linux-gnu/perl/5.26.0/x86_64-linux-gnu-thread-multi",
) = -1 ENOENT (No such file or directory)
+stat("/usr/local/share/perl/5.26.0/x86_64-linux-gnu-thread-multi", ) = -1
ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/perl-base/5.26.0", ) = -1 ENOENT (No such file
or directory)
+stat("/usr/lib/x86_64-linux-gnu/perl-base/5.26.0/x86_64-linux-gnu-thread-multi",
) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/perl-base/x86_64-linux-gnu-thread-multi", ) =
-1 ENOENT (No such file or directory)
Unlike the others, these new directories are never going to exist on
Debian systems, because our sitelib and sitearch are separated between
/usr/local/share and /usr/local/lib, as opposed to the upstream structure
of sitearch being a subdirectory of sitelib.
The wasted stats could certainly be fixed by modifying our relevant
changes to perl.c
https://sources.debian.org/src/perl/5.26.1-3/debian/patches/debian/mod_paths.diff/
but I haven't looked into that properly yet.
I'm rather undecided here. This is the first time that not having the
arch-specific subdirectories on inc_version_list has been a problem.
It seems to require a specific set of conditions to become one:
- the software has their own versioned i
Bug#883933: nmu: polymake_3.1-5
On Sat, Dec 09, 2017 at 11:32:12AM -0400, David Bremner wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > The following crash seems cured by a rebuild: > > Can't locate loadable object for module Polymake::Ext in @INC (@INC contains: > /usr/share/polymake/perllib /usr/lib/polymake/perlx/5.26.0 > /usr/lib/polymake/perlx /home/bremner/.config/perl /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 > /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 > /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at > /usr/share/polymake/perllib/Polymake/Namespaces.pm line 17. > > nmu polymake_3.1-5 . ANY . unstable . -m "rebuild for perl 5.26" FWIW I don't think this is the correct way to fix this because it doesn't take partial upgrades into account at all. I've filed #886494 with some suggestions on better fixes. OTOH a binNMU doesn't hurt of course... -- Niko Tyni nt...@debian.org
Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC
Package: polymake
Version: 3.1-5
Severity: grave
X-Debbugs-Cc: p...@packages.debian.org
Running polymake currently fails with
$ polymake
Can't locate loadable object for module Polymake::Ext in @INC (@INC contains:
/usr/share/polymake/perllib /usr/lib/polymake/perlx/5.26.0
/usr/lib/polymake/perlx /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1
/usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/share/polymake/perllib/Polymake/Namespaces.pm line 17.
Compilation failed in require at
/usr/share/polymake/perllib/Polymake/Namespaces.pm line 17.
BEGIN failed--compilation aborted at
/usr/share/polymake/perllib/Polymake/Namespaces.pm line 17.
Compilation failed in require at /usr/share/polymake/perllib/Polymake.pm line
27.
BEGIN failed--compilation aborted at /usr/share/polymake/perllib/Polymake.pm
line 27.
Compilation failed in require at /usr/bin/polymake line 162.
BEGIN failed--compilation aborted at /usr/bin/polymake line 162.
Apparently this is because it was built with Perl 5.26.0, but
we've since moved to 5.26.1.
There's an open binnmu request at #883933 but I don't think that's the
correct way to fix this as it makes no provisions for partial upgrades.
I see two better alternatives:
1) [preferrable] fix polymake not to install its extensions in a
versioned directory (currently /usr/lib/polymake/perlx/5.26.0).
This may be as simple as
--- a/lib/core/src/perl/Makefile.PL
+++ b/lib/core/src/perl/Makefile.PL
@@ -140,7 +140,7 @@ WriteMakefile(
LIBS=> "$libpaths $AddLibs",
DEFINE => "-DPerlVersion=$numvers -Wno-nonnull".($coverage && '
-DPMCollectCoverage=1'),
INC => "-I$TOP/include/core",
-LIB => "\$(InstallDir)/perlx/$Config::Config{version}",
+LIB => "\$(InstallDir)/perlx",
MAN3PODS=> { },
@optimize,
);
but I haven't tested that (the package is huge...)
2) [less preferrable] add binnmu-safe strict dependencies on the current
Perl version. See for instance libdevel-cover-perl for an example of
how to do this. If you do this, please let p...@packages.debian.org know
so we can update
https://wiki.debian.org/PerlMaintenance#New_upstream_release_checklist
(and/or feel free to add to it yourself.)
I note that the confusing @INC list above (it has
/usr/lib/polymake/perlx/5.26.0 so it looks like it should work) is
because "use lib" will add versioned subdirectories to @INC if it
finds any, but will apparently *not* add arch-specific subdirectories
(like /usr/lib/polymake/perlx/5.26.0/x86_64-linux-gnu-thread-multi)
under those, and that's what would be needed here. I'm not quite sure
if this is a glitch in lib.pm's handling of binary-compatible versions
($Config{inc_version_list}).
Hope this helps a bit,
--
Niko
Bug#880085: perl: deep recursion in Encode::find_encoding when decoding MIME header
Control: forwarded -1 https://github.com/dankogai/p5-encode/issues/127
Control: clone -1 -2
Control: reassign -2 libencode-perl 2.93-1
Control: block -1 with -2
On Sun, Oct 29, 2017 at 12:36:27PM +0100, Jakub Wilk wrote:
> Package: perl
> Version: 5.26.1-2
>
> $ piconv -f MIME-Header -t UTF-8 < bad-mime > /dev/null
> Deep recursion on subroutine "Encode::find_encoding" at
> /usr/lib/i386-linux-gnu/perl/5.26/Encode/Alias.pm line 46, line 1.
Thanks for the report and sorry for the delay.
I've forwarded this upstream as
https://github.com/dankogai/p5-encode/issues/127 and I'm cloning a
separate bug against the separate libencode-perl package, which is where
this needs to be fixed first.
A test case without piconv in the mix would be
perl -MEncode -e 'Encode::decode("MIME-Header", "=?U".("_"x200)."?Q??=")'
--
Niko Tyni nt...@debian.org
Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)
On Sat, Jan 06, 2018 at 02:03:21PM +0100, Axel Beckert wrote: > Yes, indeed, that looks much more sane now. Might be related to this > bug fix in expat 2.2.5: > >#137 #138 Fix a case of mistakenly reported parsing success where > XML_StopParser was called from an element handler Yes. The relevant change seems to be https://github.com/libexpat/libexpat/commit/718d51a66b0d69f3b8c5ff63d044c36dd5314232 as reverting that made the error go away for me. Changing the libnih test suite to accomodate the expat fix seems correct to me too fwiw. Thanks for your work on this! -- Niko Tyni nt...@debian.org
Bug#750732: libanyevent-perl: Intermittent build failures on various architectures
On Fri, Jan 05, 2018 at 02:35:38AM +0100, gregor herrmann wrote: > On Mon, 01 Jan 2018 18:56:52 +0200, Niko Tyni wrote: > > Disregarding hurd-i386, the problematic test seems to be > > t/66_ioasync_03_signals.t, > > t/66_ioasync_02_signals.t or t/66_ioasync_03_child.t? t/66_ioasync_03_child.t, I think. See below. > Anyway, IIRC we've seen failures in different tests over time. That's what I thought too but didn't find much at least in the buildd logs. > > I'm not sure what to make of this. Maybe disarm this particular test somehow > > for now and see how it fares otherwise? > On > https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.140-1=1505267718=0 > Bailout called. Further testing stopped: No child exit detected. This is > either a bug in AnyEvent or a bug in your Perl (mostly some windows > distributions suffer from that): child watchers might not work properly on > this platform. You can force installation of this module if you do not rely > on child watchers, or you could upgrade to a working version of Perl for your > platform. > > (Does this mean that t/66_ioasync_02_signals.t failed or the > following t/66_ioasync_03_child.t ?) I think it comes from the 'Bail out! No child exit detected' part in t/66_ioasync_03_child.t. Presumably the test libraries are buffering parts of the output. > Looks like t/66_ioasync_03_child.t is our candidate, if I'm > interpreting this correctly. Agreed. > Oh, and I have another hang on my Raspi: Awesome, thanks for testing. So I guess this all boils down to the (sort of documented) "issues with IO::Async", at least until we see other failures. > Commit pushed to alioth, feedback welcome before I upload. LGTM, thanks! -- Niko
Bug#750732: libanyevent-perl: Intermittent build failures on various architectures
On Wed, Sep 13, 2017 at 04:45:39PM +0200, gregor herrmann wrote: > On Sun, 17 Aug 2014 00:10:04 -0700, gregor herrmann wrote: > > On Fri, 06 Jun 2014 12:42:08 +0200, gregor herrmann wrote: > > > > > libanyevent-perl sometimes has test failures in different tests on > > > different architectures. > > > I also had one locally (on amd64) once which went away in later > > > rebuilds ... > > > > > > Looks quite random :/ > On Ubuntu, the build failed everywhere: > https://launchpad.net/ubuntu/+source/libanyevent-perl/7.140-1 > > On Debian only on armel (and hurd): > https://buildd.debian.org/status/logs.php?pkg=libanyevent-perl=7.140-1 > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libanyevent-perl.html > (amd64 only so far) and https://ci.debian.net/packages/liba/libanyevent-perl/ > (amd64 only so far) look good. > > This looks all quite random. CPAN RT and cpantesters also don't show > anything obvious … The failing tests are conditional on the PERL_ANYEVENT_LOOP_TESTS environmental variable, so it's no wonder cpantesters doesn't help. The issue seems mostly specific to armel and hurd, although tests.reproducible-builds.org does have some failures on i386 (but no logs so those could be just testbed glitches or transient sid issues.) I don't know what happened in Ubuntu but it clearly built later. Currently we have a build failure on armel that's blocking testing migration of this package. Given the number of reverse dependencies, I suppose we need to solve this one way or other. Disregarding hurd-i386, the problematic test seems to be t/66_ioasync_03_signals.t, which is using AnyEvent::Impl::IOAsync which uses IO::Async. I see the AnyEvent::Impl::IOAsync docs have some reservations about IO::Async, this in particular: When you develop your program on FreeBSD and run it on GNU/Linux, you might have unpleasant surprises, as IO::Async::Loop will by default use IO::Async::Loop::Epoll, which is incompatible with "fork", so your network server will run into spurious and very hard to debug problems under heavy load, as IO::Async forks a lot of processes, e.g. for DNS resolution. It would be better if IO::Async would only load "safe" backends by default (or fix the epoll backend to work in the presence of fork, which admittedly is hard - EV does it for you, and also does not use unsafe backends by default). I'm not sure what to make of this. Maybe disarm this particular test somehow for now and see how it fares otherwise? -- Niko Tyni nt...@debian.org
Bug#873006: libgtk3-webkit2-perl: autopkgtest failures
Control: retitle -1 libgtk3-webkit2-perl: missing dependency on
gir1.2-webkit2-4.0
Control: severity -1 serious
On Wed, Aug 23, 2017 at 06:05:55PM +0200, gregor herrmann wrote:
> Package: libgtk3-webkit2-perl
> Version: 0.06-1
> Severity: important
> libgtk3-webkit2-perl fails autopkgtest-pkg-perl's use.t:
> # Typelib file for namespace 'WebKit2', version '4.0' not found at
> /usr/lib/x86_64-linux-gnu/perl5/5.26/Glib/Object/Introspection.pm line 108.
> # BEGIN failed--compilation aborted.
> not ok 1 - /usr/bin/perl -w -M"Gtk3::WebKit2" -e 1 2>&1 exited successfully
> Not sure if this is an indication of an even more serious (sic!)
> problem in the package ...
strace shows
7243 open("/usr/lib/girepository-1.0/WebKit2-4.0.typelib", O_RDONLY) = -1
ENOENT (No such file or directory)
The file is found in the gir1.2-webkit2-4.0 package. Looks like the
module is unusable without that, so raising the severity.
The build time tests pass because of the build-dep on
libwebkit2gtk-4.0-dev (which pulls in gir1.2-webkit2-4.0); perhaps that's
the right thing to do for runtime as well?
--
Niko Tyni nt...@debian.org
Bug#885541: libtest2-suite-perl: file conflicts with libtest2-asyncsubtest-perl and libtest2-workflow-perl
Package: libtest2-suite-perl Version: 0.97-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest Affects: libtest2-asyncsubtest-perl libtest2-workflow-perl As noticed by ci.debian.net, the new libtest2-suite-perl introduced file conflicts with libtest2-asyncsubtest-perl and libtest2-workflow-perl, rendering those packages uninstallable in sid. It looks like Test2-Suite merged them in, so presumably some Replaces (and possibly Breaks / Provides) are needed. http://ci.debian.net/packages/libt/libtest2-workflow-perl/unstable/amd64/ http://ci.debian.net/packages/libt/libtest2-asyncsubtest-perl/unstable/amd64/ -libtest2-suite-perl 0.84-1 +libtest2-suite-perl 0.97-1 Unpacking libtest2-asyncsubtest-perl (0.20-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-XLqRLl/09-libtest2-asyncsubtest-perl_0.20-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man3/Test2::AsyncSubtest.3pm.gz', which is also in package libtest2-suite-perl 0.97-1 Selecting previously unselected package libtest2-workflow-perl. Preparing to unpack .../10-libtest2-workflow-perl_0.18-1_all.deb ... Unpacking libtest2-workflow-perl (0.18-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-XLqRLl/10-libtest2-workflow-perl_0.18-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man3/Test2::Tools::Spec.3pm.gz', which is also in package libtest2-suite-perl 0.97-1 -- Niko Tyni nt...@debian.org
Bug#880014: #880014: Call for Votes for new TC member
On Tue, Dec 26, 2017 at 05:52:09PM +0100, Didier 'OdyX' Raboud wrote: > I call for votes on the following ballot to fill a vacant seat in the TC. The > voting period starts immediately and lasts for up to one week, or until the > outcome is no longer in doubt (§6.3.1). > > ===BEGIN > The Technical Committee recommends that Gunnar Wolf <gw...@debian.org> be > appointed by the Debian Project Leader to the Technical Committee. > > G: Recommend to Appoint Gunnar Wolf <gw...@debian.org> > F: Further Discussion > ===END I vote: G > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#882618: libdbix-class-schema-loader-perl: Test failures
Control: tag -1 patch
On Fri, Nov 24, 2017 at 10:56:44PM +0100, gregor herrmann wrote:
> Package: libdbix-class-schema-loader-perl
> Version: 0.07047-1
> Severity: serious
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=123681
> As first seen on ci.debian.net [0], libdbix-class-schema-loader-perl's
> test suite fails since recent changes in prerequsites. The same
> happens during build which leads to a FTBFS bug:
>
> DBIx::Class::ResultSource::schema(): Unable to perform storage-dependent
> operations with a detached result source (source 'Bar' is not associated with
> a schema). You need to use $schema->thaw() or manually set
> $DBIx::Class::ResultSourceHandle::thaw_schema while thawing. at
> t/20invocations.t line 18
As discussed in the upstream bug, this is an intentional change in
Hash::Merge behaviour wrt. cloning. The attached patch seems to make it
work again by disabling the cloning, but Ilmari (the upstream author)
said a month ago he's unsure if it's the right thing to do.
Copying Ilmari: any news here? There's some pressure to fix this on the
Debian side, do you think the fix/workaround (->set_clone_behaviour(0))
is at least an acceptable temporary solution?
Thanks for your work,
--
Niko
>From 421f0c87f50862786b98934575d3f73a02119181 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Fri, 22 Dec 2017 19:40:14 +0200
Subject: [PATCH] Disable cloning when merging hashes
Newer versions of Hash::Merge changed their cloning
behaviour, causing corruption of DBI handles.
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=123681
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882618
---
lib/DBIx/Class/Schema/Loader.pm | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/DBIx/Class/Schema/Loader.pm b/lib/DBIx/Class/Schema/Loader.pm
index d100408..1f879cf 100644
--- a/lib/DBIx/Class/Schema/Loader.pm
+++ b/lib/DBIx/Class/Schema/Loader.pm
@@ -10,7 +10,7 @@ use Scalar::Util 'weaken';
use Sub::Util 'set_subname';
use DBIx::Class::Schema::Loader::Utils 'array_eq';
use Try::Tiny;
-use Hash::Merge 'merge';
+use Hash::Merge;
use namespace::clean;
# Always remember to do all digits for the version even if they're 0
@@ -232,10 +232,13 @@ sub _merge_state_from {
$self->_copy_state_from($from);
-$self->class_mappings(merge($orig_class_mappings, $self->class_mappings))
+my $merger = Hash::Merge->new;
+$merger->set_clone_behavior(0);
+
+$self->class_mappings($merger->merge($orig_class_mappings, $self->class_mappings))
if $orig_class_mappings;
-$self->source_registrations(merge($orig_source_registrations, $self->source_registrations))
+$self->source_registrations($merger->merge($orig_source_registrations, $self->source_registrations))
if $orig_source_registrations;
}
--
2.15.1
Bug#884924: perl: include dpkg-vendor information in 'Configured by'
Package: perl Version: 5.26.1-3 Severity: wishlist Looking at https://rt.perl.org/Public/Bug/Display.html?id=132631 it would be clearer if downstream distributions didn't claim their perl is 'Configured by Debian Project', particularly if they have done source changes to our package. My best idea so far is to put the output of 'dpkg-vendor --query Vendor' in cf_by. . Not sure if we need to (try to) spot unmodified source packages: technically if there are no source differences, I suppose it's configured by Debian not downstream... -- Niko Tyni nt...@debian.org
