Skip Menu |
 

This queue is for tickets about the IO-Async-Loop-Glib CPAN distribution.

Report information
The Basics
Id: 78891
Status: open
Priority: 0/
Queue: IO-Async-Loop-Glib

People
Owner: Nobody in particular
Requestors: gregoa [...] debian.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



From: gregoa [...] cpan.org
Subject: libio-async-loop-glib-perl: FTBFS: tests failed
This bug has been forwarded from http://bugs.debian.org/680806 --->---> Source: libio-async-loop-glib-perl Version: 0.20-1 Severity: serious Tags: wheezy sid User: debian-qa@lists.debian.org Usertags: qa-ftbfs-20120708 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: Show quoted text
> make[1]: Entering directory `/«PKGBUILDDIR»' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/00use.t ........... ok > > # Failed test '$hangup after pipe close for writing' > # at /usr/share/perl5/IO/Async/LoopTests.pm line 291. > # got: '0' > # expected: '1' > # Looks like you failed 1 test of 20. > t/01loop-io.t ....... > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/20 subtests > t/02loop-timer.t .... ok > t/03loop-signal.t ... ok > t/04loop-idle.t ..... ok > t/05loop-child.t .... ok > t/06loop-control.t .. ok > t/11share-io.t ...... ok > t/12share-timer.t ... ok > t/15share-child.t ... ok > t/99pod.t ........... ok > > Test Summary Report > ------------------- > t/01loop-io.t (Wstat: 256 Tests: 20 Failed: 1) > Failed test: 15 > Non-zero exit status: 1 > Files=11, Tests=111, 19 wallclock secs ( 0.06 usr 0.04 sys + 0.63 cusr 0.22 csys = 0.95 CPU) > Result: FAIL > Failed 1/11 test programs. 1/111 subtests failed. > make[1]: *** [test_dynamic] Error 255
The full build log is available from: http://people.debian.org/~lucas/logs/2012/07/08/libio-async-loop-glib-perl_0.20-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. <---<--- I can reproduce the test failure both in a chroot and on my "normal" system. Thanks in advance, gregor herrmann, Debian Perl Group
Download (untitled) / with headers
text/plain 1.5k
On Fri Aug 10 11:36:38 2012, GREGOA wrote: Show quoted text
> > # Failed test '$hangup after pipe close for writing' > > # at /usr/share/perl5/IO/Async/LoopTests.pm line 291. > > # got: '0' > > # expected: '1' > > # Looks like you failed 1 test of 20. > > t/01loop-io.t .......
Yeah... Hrmmm.. :( This comes from an expectation on my part hat POLLHUP was actually reliable across operating systems, to detect that the reader has closed their end of a pipe. Turns out this really isn't the case at all. I've been researching the effects of select/poll/etc... on a variety of types of filehandle in an EOF state, across a variety of OSes, and in summary: they all suck. There's no consistency anywhere, and nothing can reliably detect this condition. I think I might have to alter the code somewhat, turning it back to just two callbacks, each that might optionally be passed a flag to indicate the EOF condition. $on_read_ready->( $eof ) $on_write_ready->( $eof ) but accept that it will always be optional. As for how you can resolve this issue, easiest might be just to remove IaLoop::Glib's declaration that it can handle on_hangup: === modified file 'lib/IO/Async/Loop/Glib.pm' --- lib/IO/Async/Loop/Glib.pm 2012-05-21 17:13:44 +0000 +++ lib/IO/Async/Loop/Glib.pm 2012-08-15 06:57:11 +0000 @@ -13,7 +13,7 @@ # Only Linux is known always to be able to report EOF conditions on # filehandles using POLLHUP -use constant _CAN_ON_HANGUP => ( $^O eq "linux" ); +#use constant _CAN_ON_HANGUP => ( $^O eq "linux" ); use base qw( IO::Async::Loop ); IO::Async::Loop->VERSION( '0.49' ); -- Paul Evans
Subject: Re: [rt.cpan.org #78891] libio-async-loop-glib-perl: FTBFS: tests failed
Date: Wed, 15 Aug 2012 15:23:35 +0200
To: Paul Evans via RT <bug-IO-Async-Loop-Glib [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
Download (untitled) / with headers
text/plain 1.4k
On Wed, 15 Aug 2012 02:58:03 -0400, Paul Evans via RT wrote: Show quoted text
> > > # Failed test '$hangup after pipe close for writing' > > > # at /usr/share/perl5/IO/Async/LoopTests.pm line 291. > > > # got: '0' > > > # expected: '1' > > > # Looks like you failed 1 test of 20. > > > t/01loop-io.t .......
> > This comes from an expectation on my part hat POLLHUP was actually > reliable across operating systems, to detect that the reader has closed > their end of a pipe. Turns out this really isn't the case at all.
I see :) Show quoted text
> As for how you can resolve this issue, easiest might be just to remove > IaLoop::Glib's declaration that it can handle on_hangup: > > === modified file 'lib/IO/Async/Loop/Glib.pm' > --- lib/IO/Async/Loop/Glib.pm 2012-05-21 17:13:44 +0000 > +++ lib/IO/Async/Loop/Glib.pm 2012-08-15 06:57:11 +0000 > @@ -13,7 +13,7 @@ > > # Only Linux is known always to be able to report EOF conditions on > # filehandles using POLLHUP > -use constant _CAN_ON_HANGUP => ( $^O eq "linux" ); > +#use constant _CAN_ON_HANGUP => ( $^O eq "linux" ); > > use base qw( IO::Async::Loop ); > IO::Async::Loop->VERSION( '0.49' ); >
Thank you, applied to our package in Debian for now. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: The Eagles: Hotel california
Download signature.asc
application/pgp-signature 836b

Message body not shown because it is not plain text.



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.