Bug#750732: libanyevent-perl: Intermittent build failures on various architectures

[Niko Tyni]

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&ver=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   ntyni at debian.org