[bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> test_ssl does sometimes hang (at least when executed under faketime).  It is
> somewhat unlikely to happen, and (on my machine) required a build with
> --rounds=32 to reproduce it.

It'd be nice if upstream was made aware of this problem.  Perhaps they
could come up with a fix for good.

> The workaround is to set somewhat lower timeout of 240s (expected test
> duration * 5 rounded up to whole minutes) and retry few times on failure.  In
> this way, --rounds=64 finished successfully (on my machine).
>
> At the same time remove the timeout from the other tests, since it is not
> necessary (they do not hang), and one of them runs for ~270s (almost half the
> original timeout), so it could pose a problem on slow/overloaded machine.

This means the tests may take up to 20 minutes, which is a bit too much
to my taste.

[...]

> -                  ;; Note: The test_ssl test times out in the ci.
> -                  ;; Temporarily disable it until that is resolved.
> -                  ;; (invoke "faketime" "2022-10-24"
> -                  ;;         "ctest"
> -                  ;;         "-R" "^test_ssl$"
> -                  ;;         "-j" jobs
> -                  ;;         "--timeout" timeout
> -                  ;;         "--output-on-failure")
> -                  )))))))
> +                  (invoke "faketime" "2022-10-24"
> +                          "ctest"
> +                          "-R" "^test_ssl$"
> +                          "-j" jobs
> +                          ;; test_ssl sometimes hangs (at least when run under
> +                          ;; faketime), therefore set a time limit and retry
> +                          ;; few times on failure.
> +                          "--timeout" "240"
> +                          "--repeat" "until-pass:5"
> +                          "--output-on-failure"))))))))

I think that a test sometimes hang is a good reason to leave it
disabled, report it to upstream, and reference the issue.  The test can
be re-enabled when the issue is resolved and part of a new release.

So in concrete terms, what I'd rather see here is a report of the
problems (requirement on faketime + propension to hang) to upstream, the
and an updated comment cross-referencing it (with the test kept
commented-out/disabled in the mean time).

Does that make sense?

-- 
Thanks,
Maxim