Bug #130885 for Object-Remote: libobject-remote-perl: test failure with Moo 2.003006

Sat Nov 02 13:33:31 2019 gregoa [...] cpan.org - Ticket created

From:	gregoa [...] cpan.org
Subject:	libobject-remote-perl: test failure with Moo 2.003006

We have the following bug reported to the Debian package of Object-Remote, c.f. https://bugs.debian.org/944007 It doesn't seem to be a bug in the packaging, so you may want to take a look. Thanks! ------8<-----------8<-----------8<-----------8<-----------8<----- Source: libobject-remote-perl Version: 0.004000-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source As first seen on ci.debian.net, libobject-remote-perl's test fail: https://ci.debian.net/packages/libo/libobject-remote-perl/unstable/amd64/ https://ci.debian.net/data/autopkgtest/unstable/amd64/libo/libobject-remote-perl/3296702/log.gz Test Summary Report - ------------------- t/await.t (Wstat: 65280 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 255 Parse errors: No plan found in TAP output t/basic.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/basic_data.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/bridged.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 t/chained.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/fatnode.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 1 tests but ran 0. t/not_found.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/objects.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/sender.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/tied.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/timeout.t (Wstat: 256 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 t/transfer.t (Wstat: 1536 Tests: 6 Failed: 6) Failed tests: 1-6 Non-zero exit status: 6 t/watchdog.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/watchdog_fatnode.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=19, Tests=76, 9 wallclock secs ( 0.06 usr 0.02 sys + 4.98 cusr 0.55 csys = 5.61 CPU) Result: FAIL The same happens during a local build. The same can be seen on cpantesters (for perl 5.13.6): http://matrix.cpantesters.org/?dist=Object-Remote%200.004000;os=linux;perl=5.31.6;reports=1 Looking at the logs both from ci.debian.net and cpantesters.org indicates that to upgrade of Moo / libmoo-perl from 2.003004 to 2.003006 caused the breakage; so this may well be a bug in Moo. Cheers, gregor ------8<-----------8<-----------8<-----------8<-----------8<----- Thanks for considering, gregor herrmann, Debian Perl Group

Mon Nov 04 07:16:37 2019 haarg [...] haarg.org - Correspondence added

I have a fix for this. Object::Remote is currently expecting Moo to load Devel::GlobalDestruction, but that is no longer the case in the latest Moo. Having Object::Remote be explicit about loading Devel::GlobalDestruction fixes the problem.

Mon Nov 04 07:16:37 2019 The RT System itself - Status changed from 'new' to 'open'

Thu Nov 21 02:38:41 2019 intrigeri [...] boum.org - Correspondence added

Hi! On Mon Nov 04 07:16:37 2019, haarg wrote: Show quoted text

> I have a fix for this. Object::Remote is currently expecting Moo to > load Devel::GlobalDestruction, but that is no longer the case in the > latest Moo. Having Object::Remote be explicit about loading > Devel::GlobalDestruction fixes the problem.

Excellent! Do you have plans to release this fix soonish? Otherwise, could you please make this fix available, e.g. in your Git repo, so downstreams like Debian can apply it? (This regression blocks recent Moo from migrating to Debian testing.) Thanks in advance :)

Tue Nov 26 05:03:10 2019 ppisar [...] redhat.com - Correspondence added

Dne Čt 21.lis.2019 02:38:41, intrigeri@boum.org napsal(a): Show quoted text

> On Mon Nov 04 07:16:37 2019, haarg wrote:

> > I have a fix for this. Object::Remote is currently expecting Moo to > > load Devel::GlobalDestruction, but that is no longer the case in the > > latest Moo. Having Object::Remote be explicit about loading > > Devel::GlobalDestruction fixes the problem.

> > Excellent! Do you have plans to release this fix soonish?

An attached patch fixes this isue for me.

Subject:

Object-Remote-0.004000-Adapt-to-Moo-2.003006-that-does-not-load-Devel-Globa.patch

From 2a843fe62d990851cf544214ace1be8e0c51e851 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar@redhat.com> Date: Tue, 26 Nov 2019 10:52:50 +0100 Subject: [PATCH] Adapt to Moo-2.003006 that does not load Devel::GlobalDestruction MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moo-2.003006 stopped loading Devel::GlobalDestruction on recent Perls. As a result Object-Remote tests failed because: $ perl -Ilib -e 'require Object::Remote::FatNode' Use of uninitialized value $_ in hash element at lib/Object/Remote/FatNode.pm line 127. Compilation failed in require at -e line 1. Object::Remote::FatNode expected that Devel/GlobalDestruction.pm was always presented in @INC and created an undefined entry in @non_core_non_arch since Moo-2.003006. This patch fixes it. CPAN RT#130885 Signed-off-by: Petr PÃsaÅ <ppisar@redhat.com> --- lib/Object/Remote/FatNode.pm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/Object/Remote/FatNode.pm b/lib/Object/Remote/FatNode.pm index 8b143b8..d0cf133 100644 --- a/lib/Object/Remote/FatNode.pm +++ b/lib/Object/Remote/FatNode.pm @@ -63,7 +63,8 @@ foreach(keys(%mods)) { } } -my @non_core_non_arch = ( $file_names{'Devel/GlobalDestruction.pm'} ); +my @non_core_non_arch = exists $file_names{'Devel/GlobalDestruction.pm'} ? + ($file_names{'Devel/GlobalDestruction.pm'}) : (); push @non_core_non_arch, grep +( not ( #some of the config variables can be empty which will eval as a matching regex -- 2.21.0

Fri Nov 29 06:04:55 2019 haarg [...] haarg.org - Correspondence added

Should be fixed in 0.004001.

Fri Nov 29 06:04:56 2019 haarg [...] haarg.org - Status changed from 'open' to 'resolved'

Fri Nov 29 06:04:56 2019 haarg [...] haarg.org - Fixed in 0.004001 added