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 nt...@debian.org