Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout

[Manuel A. Fernandez Montecelo]

Hi Niko,

2018-04-24 18:55 GMT+02:00 Niko Tyni <ntyni at debian.org>:
> Package: perl
> Version: 5.26.2-2
> X-Debbugs-Cc: debian-riscv at lists.debian.org
>
> This package failed to build on riscv64.
>
>   t/re/fold_grind ................................................ # Test process timed out - terminating
>   FAILED--no leader found
>
>   [...]
>
>   Failed 1 test out of 2457, 99.96% okay.
>         re/fold_grind.t
>
>   [...]
>
>   Build needed 05:11:45, 350184k disk space

Thanks for taking care :)


> It looks to me like the buildd host is just too slow for this test.
> >From the test:
>
>     my $time_out_factor = $ENV{PERL_TEST_TIME_OUT_FACTOR} || 1;
>     $time_out_factor = 1 if $time_out_factor < 1;
>
>     watchdog(5 * 60 * $time_out_factor);
>
> so the default timeout is five minutes but can be multiplied with
> PERL_TEST_TIME_OUT_FACTOR in the environment.
>
> AFAICS the build time of five hours is well above all the other
> architectures, even m68k and sh4, and it's still less than half of
> a successful build (we have to build perl three times with different
> options, and run the test suite for two of those builds.)

At the moment, these builds are using qemu-system emulation (not even
qemu-user, as --some, or all?-- of the m68k/sh4 buildds).  And a new
implementation at that, not very streamlined or tuned for performance.

So yes, they are slower than any other arch at the moment.

It could also happen that the test is stuck due to bugs in qemu, the
toolchain, etc, we already found similar problems in other packages.


> @debian-riscv: I guess I can set PERL_TEST_TIME_OUT_FACTOR=2 for riscv64
> in debian/rules or something like that, do you think that's sensible or
> are the current riscv64 buildds going to get faster any time soon?

We hope to get (donations of) proper hardware at some point, but at
the moment there's only a very limited run of hardware in the world,
and the only one that I got so far is being used for testing and not
for building (not as part of the buildd network, at any rate).

The timeline for getting more hardware is unknown, but I cannot see us
getting faster buildds at least until July, even in the best scenario,
so it's better if you increase the time out factor by two, if not
more.

I'm just firing up a build in the board to see if it passes the tests,
I will report when it finishes, if everything goes all right.

-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>