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

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

[Tomas Volf]

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.

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.

* gnu/packages/bittorrent.scm
(libtorrent-rasterbar)[arguments]<#:phases>['check]: Remote test timeout for
most tests.  Lower the timeout for test_ssl.  Retry test_ssl on failure.

Change-Id: I535c72fec24658a4b2151d2e8794319055c9a278
---
 gnu/packages/bittorrent.scm | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index 2b38c7cb65..1a0735d928 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -452,7 +452,6 @@ (define-public libtorrent-rasterbar
                      (exclude-regex (string-append "^("
                                                    (string-join disabled-tests "|")
                                                    ")$"))
-                     (timeout "600")
                      (jobs (if parallel-tests?
                                (number->string (parallel-job-count))
                                "1")))
@@ -460,7 +459,6 @@ (define-public libtorrent-rasterbar
                   (invoke "ctest"
                           "-E" exclude-regex
                           "-j" jobs
-                          "--timeout" timeout
                           "--output-on-failure")
                   ;; test_ssl relies on bundled TLS certificates with a fixed
                   ;; expiry date.  To ensure succesful builds in the future,
@@ -470,16 +468,16 @@ (define-public libtorrent-rasterbar
                   ;; test_fast_extension, test_privacy and test_resolve_links
                   ;; to hang, even with FAKETIME_ONLY_CMDS.  Not sure why.  So
                   ;; execute only test_ssl under faketime.
-                  ;;
-                  ;; 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"))))))))
     (inputs (list boost openssl))
     (native-inputs
      (list libfaketime
-- 
2.46.0

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

[Maxim Cournoyer]

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