Skip Menu |
 

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

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

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-epoll-perl: FTBFS: tests failed
Download (untitled) / with headers
text/plain 2.1k
This bug has been forwarded from http://bugs.debian.org/680790 --->---> Source: libio-async-loop-epoll-perl Version: 0.12-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
> debian/rules build > dh build > dh_testdir > dh_auto_configure > Created MYMETA.yml and MYMETA.json > Creating new 'Build' script for 'IO-Async-Loop-Epoll' version '0.12' > dh_auto_build > Building IO-Async-Loop-Epoll > dh_auto_test > t/00use.t ........... ok > t/01loop-io.t ....... ok > > # Failed test 'One ->loop_once(1) sufficient for a single 0.1 second timer' > # at /usr/share/perl5/IO/Async/LoopTests.pm line 481. > # got: '2' > # expected: '1' > # Looks like you failed 1 test of 26. > t/02loop-timer.t .... > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/26 subtests > t/03loop-signal.t ... ok > t/04loop-idle.t ..... ok > t/05loop-child.t .... ok > t/06loop-control.t .. ok > t/99pod.t ........... ok > > Test Summary Report > ------------------- > t/02loop-timer.t (Wstat: 256 Tests: 26 Failed: 1) > Failed test: 20 > Non-zero exit status: 1 > Files=8, Tests=105, 15 wallclock secs ( 0.04 usr 0.06 sys + 0.49 cusr 0.13 csys = 0.72 CPU) > Result: FAIL > Failed 1/8 test programs. 1/105 subtests failed. > dh_auto_test: perl Build test returned exit code 255 > make: *** [build] Error 255
The full build log is available from: http://people.debian.org/~lucas/logs/2012/07/08/libio-async-loop-epoll-perl_0.12-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. <--<-- Note that - this is 0.12; 0.13 needs Linux::Epoll which isn't packaged in Debian yet - I can't reproduce the bug but Lucas could (cf. the original bug report) Thanks in advance, gregor herrmann, Debian Perl Group
Download (untitled) / with headers
text/plain 675b
On Fri Aug 10 11:42:05 2012, GREGOA wrote: Show quoted text
> > # Failed test 'One ->loop_once(1) sufficient for a single 0.1
> second timer'
> > # at /usr/share/perl5/IO/Async/LoopTests.pm line 481. > > # got: '2' > > # expected: '1' > > # Looks like you failed 1 test of 26.
Yeah; this is an awkward timing-related failure. IO::Async sortof-relies on the fact that epoll_pwait() on 100msec will definitely observe at least a 100msec difference in gettimeofday() calls. Sometimes this doesn't actually hold; it's more of a rounding error. I've been wondering lately if the test should just be relaxed a bit, to always allow one more call just in case. -- Paul Evans
Subject: Re: [rt.cpan.org #78892] libio-async-loop-epoll-perl: FTBFS: tests failed
Date: Tue, 14 Aug 2012 19:23:09 +0200
To: Paul Evans via RT <bug-IO-Async-Loop-Epoll [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
Download (untitled) / with headers
text/plain 1.4k
On Mon, 13 Aug 2012 10:01:40 -0400, Paul Evans via RT wrote: Show quoted text
> On Fri Aug 10 11:42:05 2012, GREGOA wrote:
> > > # Failed test 'One ->loop_once(1) sufficient for a single 0.1
> > second timer'
> > > # at /usr/share/perl5/IO/Async/LoopTests.pm line 481. > > > # got: '2' > > > # expected: '1' > > > # Looks like you failed 1 test of 26.
> > Yeah; this is an awkward timing-related failure. IO::Async sortof-relies > on the fact that epoll_pwait() on 100msec will definitely observe at > least a 100msec difference in gettimeofday() calls. Sometimes this > doesn't actually hold; it's more of a rounding error.
I see. This might happen here, the rebuilds were done on an Amazon virtual machine which might be different than the average desktop machine :) Show quoted text
> I've been wondering lately if the test should just be relaxed a bit, to > always allow one more call just in case.
Does this mean this change has to happen in IO::Async and not in I::A::Loop::Epoll? In any case, if we want to have libio-async-loop-epoll-perl in the next Debian release, we should find a (preferrably minimal, since we are in the freeze already) fix somewhere soon. Thanks! 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: Funny van Dannen: Freundinnen
Download signature.asc
application/pgp-signature 836b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #78892] libio-async-loop-epoll-perl: FTBFS: tests failed
Date: Wed, 15 Aug 2012 07:51:25 +0100
To: gregor herrmann via RT <bug-IO-Async-Loop-Epoll [...] rt.cpan.org>
From: Paul LeoNerd Evans <leonerd [...] leonerd.org.uk>
Download (untitled) / with headers
text/plain 1.7k
On Tue, Aug 14, 2012 at 01:23:23PM -0400, gregor herrmann via RT wrote: Show quoted text
> > Yeah; this is an awkward timing-related failure. IO::Async sortof-relies > > on the fact that epoll_pwait() on 100msec will definitely observe at > > least a 100msec difference in gettimeofday() calls. Sometimes this > > doesn't actually hold; it's more of a rounding error.
> > I see. This might happen here, the rebuilds were done on an Amazon > virtual machine which might be different than the average desktop > machine :)
It's possible that explains it, yes. Show quoted text
> > I've been wondering lately if the test should just be relaxed a bit, to > > always allow one more call just in case.
> > Does this mean this change has to happen in IO::Async and not in > I::A::Loop::Epoll?
Sortof. The tests in latest IO::Async::LoopTests are already aware of this possibility, and test whether the $loop declares _CAN_SUBSECOND_ACCURATELY or not. It may just be that actually none of the loops can really declare that one any more. :/ This feature went into IO::Async at 1044: Paul "LeoNerd" Evans 2012-06-26 Allow Loops to declare for unit-test purposes that they can't handle subsecond timers accurately, so skip the counter tests That was first released at 0.51_001, and then for real at 0.52. Show quoted text
> In any case, if we want to have libio-async-loop-epoll-perl in the > next Debian release, we should find a (preferrably minimal, since we > are in the freeze already) fix somewhere soon.
If you update libio-async-perl to 0.52, you should find that the Epoll loop now skips those tests, because it doesn't declare _CAN_SUBSECOND_ACCURATELY. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Download signature.asc
application/pgp-signature 190b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #78892] libio-async-loop-epoll-perl: FTBFS: tests failed
Date: Wed, 15 Aug 2012 16:29:06 +0200
To: Paul LeoNerd Evans via RT <bug-IO-Async-Loop-Epoll [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
Download (untitled) / with headers
text/plain 1.7k
On Wed, 15 Aug 2012 02:51:38 -0400, Paul LeoNerd Evans via RT wrote: Show quoted text
> > I see. This might happen here, the rebuilds were done on an Amazon > > virtual machine which might be different than the average desktop > > machine :)
> It's possible that explains it, yes.
Ok, thanks. Show quoted text
> > Does this mean this change has to happen in IO::Async and not in > > I::A::Loop::Epoll?
> Sortof. The tests in latest IO::Async::LoopTests are already aware of > this possibility, and test whether the $loop declares > _CAN_SUBSECOND_ACCURATELY or not. It may just be that actually none of > the loops can really declare that one any more. :/ > > This feature went into IO::Async at > > 1044: Paul "LeoNerd" Evans 2012-06-26 Allow Loops to declare for > unit-test purposes that they can't handle subsecond timers > accurately, so skip the counter tests
Is this a commit in some VCS? I didn't find a repo in a quick search. Show quoted text
> That was first released at 0.51_001, and then for real at 0.52.
[..] Show quoted text
> If you update libio-async-perl to 0.52, you should find that the Epoll > loop now skips those tests, because it doesn't declare > _CAN_SUBSECOND_ACCURATELY.
Since we are in the freeze we can't upload new packages, especially if the diff is rather huge, like here with 0.52. That means we have to try to backport the fix in a minimal patch; I've now tried to extract the relevant parts from the 0.51/0.52 diff. Could you please take a look at the attached patch and tell me if this is enough / matches the change mentioned above? Thanks again, 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: Paul Mc Cartney: Singing The Blues
Download subsecond.patch
text/x-diff 1.6k

Message body is not shown because sender requested not to inline it.

Download signature.asc
application/pgp-signature 836b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 860b
On Wed Aug 15 10:29:20 2012, gregoa@debian.org wrote: Show quoted text
> > This feature went into IO::Async at > > > > 1044: Paul "LeoNerd" Evans 2012-06-26 Allow Loops to declare for > > unit-test purposes that they can't handle subsecond timers > > accurately, so skip the counter tests
> > Is this a commit in some VCS? I didn't find a repo in a quick search.
$ bzr log -r1044 http://bazaar.leonerd.org.uk/perl/IO-Async/ Show quoted text
> That means we have to try to backport the fix in a minimal patch; > I've now tried to extract the relevant parts from the 0.51/0.52 diff. > > Could you please take a look at the attached patch and tell me if > this is enough / matches the change mentioned above?
That looks OK, though you possibly want to include the ones from the in- dist Select and Poll loops as well, in case those also cause you build failures. -- Paul Evans
Subject: Re: [rt.cpan.org #78892] libio-async-loop-epoll-perl: FTBFS: tests failed
Date: Wed, 15 Aug 2012 18:16:38 +0200
To: Paul Evans via RT <bug-IO-Async-Loop-Epoll [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
Download (untitled) / with headers
text/plain 1.1k
On Wed, 15 Aug 2012 10:36:06 -0400, Paul Evans via RT wrote: Show quoted text
> > > 1044: Paul "LeoNerd" Evans 2012-06-26 Allow Loops to declare for > > > unit-test purposes that they can't handle subsecond timers > > > accurately, so skip the counter tests
> > Is this a commit in some VCS? I didn't find a repo in a quick search.
> $ bzr log -r1044 http://bazaar.leonerd.org.uk/perl/IO-Async/
Thank you! This looks suspiciously like what I've extracted manually from the diff :) Show quoted text
> > Could you please take a look at the attached patch and tell me if > > this is enough / matches the change mentioned above?
> That looks OK, though you possibly want to include the ones from the in- > dist Select and Poll loops as well, in case those also cause you build > failures.
Since we haven't seen any other problems so far, I'll stick with the minimal patch for the time being. Thanks again for all your help! 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: Robert Plant: In The Mood
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.