GNU bug report logs - #73664
libtorrent-rasterbar@1.2: failure in test_ssl

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73664 in the body.
You can then email your comments to 73664 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: guix-patches <at> gnu.org
Cc: Tomas Volf <~@wolfsden.cz>
Subject: [PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.
Date: Sun,  6 Oct 2024 18:11:49 +0200

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

Message #8 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Tue, 17 Dec 2024 10:20:30 +0900

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

Message #11 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Tue, 17 Dec 2024 14:08:22 +0900

Hello!

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.

Also worth adding on top of my previous reply, when trying this out, I
got a failure:

--8<---------------cut here---------------start------------->8---
[...]

MALICIOUS PEER TEST: valid-certificate valid-SNI-hash invalid-bittorrent-hash  port: 35161
set_password_callback
use_certificate_file "../ssl/peer_certificate.pem"
use_private_key_file "../ssl/peer_private_key.pem"
use_tmp_dh_file "../ssl/dhparams.pem"
connecting 127.0.0.1:35161
SNI: e300afcc0aa67a459ec14862a4d0bf930060167a
SSL handshake
bittorrent handshake
00:00:00.010: ses1: [log]  *** peer SSL handshake done [ ip: 127.0.0.1:44976 ec: certificate verify failed (SSL routines) socket: SSL/TCP ]
read bittorrent handshake
00:00:00.010: ses1: [peer_error]  -  peer [ 127.0.0.1:44976 client: Unknown ] peer error [ssl_handshake] [asio.ssl]: certificate verify failed (SSL routines)
--- peer_errors: 6 ssl_disconnects: 6
failed to read bittorrent handshake: sslv3 alert bad certificate (SSL routines)


0% tests passed, 1 tests failed out of 1

Total Test time (real) = 405.71 sec

The following tests FAILED:
	 75 - test_ssl (Failed)
Errors while running CTest
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "faketime" arguments: ("2022-10-24" "ctest" "-R" "^test_ssl$" "-j" "1" "--timeout" "240" "--repeat" "until-pass:5" "--output-on-failure") exit-status: 8 term-signal: #f stop-signal: #f> 
phase `check' failed after 1154.0 seconds
command "faketime" "2022-10-24" "ctest" "-R" "^test_ssl$" "-j" "1" "--timeout" "240" "--repeat" "until-pass:5" "--output-on-failure" failed with status 8
build process 18 exited with status 256
builder for `/gnu/store/hkji5nzsa32jngg7kii9bg9ch9kdvs84-libtorrent-rasterbar-2.0.10.drv' failed with exit code 1
build of /gnu/store/hkji5nzsa32jngg7kii9bg9ch9kdvs84-libtorrent-rasterbar-2.0.10.drv failed
View build log at '/var/log/guix/drvs/hk/ji5nzsa32jngg7kii9bg9ch9kdvs84-libtorrent-rasterbar-2.0.10.drv'.
--8<---------------cut here---------------end--------------->8---

-- 
Thanks,
Maxim

Message #14 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: 73664 <at> debbugs.gnu.org
Cc: Tomas Volf <~@wolfsden.cz>
Subject: [PATCH v2 1/2] gnu: libtorrent-rasterbar: Update to 2.0.11.
Date: Tue, 28 Jan 2025 20:50:00 +0100

* gnu/packages/bittorrent.scm (libtorrent-rasterbar): Update to 2.0.11.

Change-Id: Ib6fb2676f6b6773690473e63276574abaebcac0a
---
 gnu/packages/bittorrent.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index 0d52d25e08..d12493c269 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -424,7 +424,7 @@ (define-public mktorrent
 (define-public libtorrent-rasterbar
   (package
     (name "libtorrent-rasterbar")
-    (version "2.0.10")
+    (version "2.0.11")
     (source
      (origin
        (method url-fetch)
@@ -433,7 +433,7 @@ (define-public libtorrent-rasterbar
                        "releases/download/v" version "/"
                        "libtorrent-rasterbar-" version ".tar.gz"))
        (sha256
-        (base32 "0pc8rbcp7njbx8m02z47pcbbwcp5cjggbgq4sfjc19dc3n65p4zw"))))
+        (base32 "0v8yrxzc7piw5lrpgkb50b4p16ic1sl4pyj0rkkasaag1xc5inzh"))))
     (build-system cmake-build-system)
     (arguments
      (list
-- 
2.47.1

Message #17 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: 73664 <at> debbugs.gnu.org
Cc: Tomas Volf <~@wolfsden.cz>
Subject: [PATCH v2 2/2] gnu: libtorrent-rasterbar: Remove special case for
 test_ssl.
Date: Tue, 28 Jan 2025 20:50:01 +0100

With the release of 2.0.11, the SSL certificates used for tests are valid for
long enough time (~end of year 2297) to no longer require faketime.  With the
removal of faketime, the explicit timeout is also no longer required, since it
does not hang anymore.

This gives us back the validation that SSL works.

* gnu/packages/bittorrent.scm
(libtorrent-rasterbar)[arguments]<#:phases>['check]: Remove test timeout.  Do
not special case test_ssl.

Change-Id: I535c72fec24658a4b2151d2e8794319055c9a278
---
 gnu/packages/bittorrent.scm | 26 ++------------------------
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index d12493c269..667350ad9c 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -448,13 +448,10 @@ (define-public libtorrent-rasterbar
             (lambda* (#:key tests? parallel-tests? #:allow-other-keys)
               (let* ((disabled-tests
                       '(;; Requires a non-localhost IPv4 interface.
-                        "test_upnp"
-                        ;; test_ssl needs to be run separately.
-                        "test_ssl"))
+                        "test_upnp"))
                      (exclude-regex (string-append "^("
                                                    (string-join disabled-tests "|")
                                                    ")$"))
-                     (timeout "600")
                      (jobs (if parallel-tests?
                                (number->string (parallel-job-count))
                                "1")))
@@ -462,26 +459,7 @@ (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,
-                  ;; fake the time to be roughly that of the release.
-                  ;;
-                  ;; At the same time, faketime happens to cause
-                  ;; 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")
-                  )))))))
+                          "--output-on-failure"))))))))
     (inputs (list boost openssl))
     (native-inputs
      (list libfaketime
-- 
2.47.1

Message #20 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Tue, 28 Jan 2025 21:01:43 +0100

[Message part 1 (text/plain, inline)]

Hi Maxim,

thank you very much for the review and apologies for the late response,
I have kept postponing it.

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> 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.

My experience with reporting bugs to this specific upstream is not the
best, and I admit I expect the answer to "it hangs under faketime" would
be "do not run it under faketime".

>
>> 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.

During validation of the v2, the run-time of the check phase is:

--8<---------------cut here---------------start------------->8---
phase `check' succeeded after 811.0 seconds
--8<---------------cut here---------------end--------------->8---

That seems fine?  We have software already that takes similar time (or
even longer) to build.

>
> [...]
>
>> -                  ;; 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?

As mentioned above, I do not expect upstream to care about this specific
issue (faketime).  However what I was successful in was convincing
upstream to vastly increase the lifetime of the bundled SSL certificates
used for testing.  That means that the new version (2.0.11) will run the
tests fine until ~end of the year 2297.  Honestly I consider that to be
an acceptable deadline to find a better long term solution (for example
we could explore the use of time namespace for build environment).

So I have submitted v2 which updates to the new version and removes all
special casing for test_ssl, since it should not be required for more
than quarter of a millennium.

I hope this approach is acceptable.

Have a nice day,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Wed, 29 Jan 2025 11:00:45 +0900

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> Hi Maxim,
>
> thank you very much for the review and apologies for the late response,
> I have kept postponing it.
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> 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.
>
> My experience with reporting bugs to this specific upstream is not the
> best, and I admit I expect the answer to "it hangs under faketime" would
> be "do not run it under faketime".

Some upstream takes patience to work with, but I still think it's useful
to put out a report of this problem, would it only be for other
downstreams trying to find a solution.

In this case, I'd tell them the goal is to have the tests work reliably
in time, even in 2 or 5 years, and this is not possible currently
because of expiry on the certs they use in the test suite (right?).

Possible options:

1. Remove expiry on certs used.
2. Use faketime, as attempted here; if this is chosen we need to figure
out why it hangs.

Obviously 1 is the easier/better option (if it's possible).

>>
>>> 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.
>
> During validation of the v2, the run-time of the check phase is:
>
> phase `check' succeeded after 811.0 seconds
>
> That seems fine?  We have software already that takes similar time (or
> even longer) to build.

That's still too long to my taste, but if it succeeds reliably at least,
then so be it.

>> 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?
>
> As mentioned above, I do not expect upstream to care about this specific
> issue (faketime).  However what I was successful in was convincing
> upstream to vastly increase the lifetime of the bundled SSL certificates
> used for testing.  That means that the new version (2.0.11) will run the
> tests fine until ~end of the year 2297.  Honestly I consider that to be
> an acceptable deadline to find a better long term solution (for example
> we could explore the use of time namespace for build environment).

That's good!  That's practically the #1 option I hinted at earlier
(didn't know they already did that).

> So I have submitted v2 which updates to the new version and removes all
> special casing for test_ssl, since it should not be required for more
> than quarter of a millennium.
>
> I hope this approach is acceptable.

Great!  Thanks for engaging with upstream and sending a v2.  I'll apply
it shortly if everything looks good.

-- 
Thanks,
Maxim

Message #28 received at 73664-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664-done <at> debbugs.gnu.org
Subject: Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Wed, 29 Jan 2025 22:19:30 +0900

Hi Tomas,

Finally pushed.  Thanks for the good work!

-- 
Maxim

Message #31 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: bug#73664: [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Sat, 01 Feb 2025 16:19:37 +0900

reopen 73664
retitle 73664 libtorrent-rasterbar: non-deterministic failures in test_ssl
quit

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> With the release of 2.0.11, the SSL certificates used for tests are valid for
> long enough time (~end of year 2297) to no longer require faketime.  With the
> removal of faketime, the explicit timeout is also no longer required, since it
> does not hang anymore.
>
> This gives us back the validation that SSL works.

It builds for me locally, but the CI encountered problems:

https://ci.guix.gnu.org/build/8981901/details

I'm not sure there seems to be a substitute available for it, but this
is worrying.  I think I'll revert, or leave it disabled with a note of
potential non-determistic failures with it.

-- 
Thanks,
Maxim

Message #34 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: bug#73664: [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Sat, 01 Feb 2025 12:10:03 +0100

[Message part 1 (text/plain, inline)]

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> reopen 73664
> retitle 73664 libtorrent-rasterbar: non-deterministic failures in test_ssl
> quit
>
> Hi Tomas,
>
> Tomas Volf <~@wolfsden.cz> writes:
>
>> With the release of 2.0.11, the SSL certificates used for tests are valid for
>> long enough time (~end of year 2297) to no longer require faketime.  With the
>> removal of faketime, the explicit timeout is also no longer required, since it
>> does not hang anymore.
>>
>> This gives us back the validation that SSL works.
>
> It builds for me locally, but the CI encountered problems:
>
> https://ci.guix.gnu.org/build/8981901/details
>
> I'm not sure there seems to be a substitute available for it, but this
> is worrying.  I think I'll revert, or leave it disabled with a note of
> potential non-determistic failures with it.

Notice the build failure is for libtorrent-rasterbar <at> 1.2 (the
libtorrent-rasterbar-1.2 variable).  My patch updated
libtorrent-rasterbar <at> 2 to 2.0.11 (the libtorrent-rasterbar variable).

So this is my fault, I did not realize that libtorrent-rasterbar-1.2
inherits from libtorrent-rasterbar, so the change in check phase will
affect both.  Sorry about that.

Luckily there is a new release (1.2.20) which seems to contain the
extension of certificate expiry.  After breakfast I will do the update,
test it and send a patch here.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

Message #41 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: 73664 <at> debbugs.gnu.org
Cc: Tomas Volf <~@wolfsden.cz>, maxim.cournoyer <at> gmail.com
Subject: [PATCH] gnu: libtorrent-rasterbar-1.2: Update to 1.2.20.
Date: Sat,  1 Feb 2025 13:16:25 +0100

* gnu/packages/bittorrent.scm (libtorrent-rasterbar-1.2): Update to 1.2.20.

Change-Id: I18208b5609e8362576986c894bb2fc143d52093f
---
I have tested the build locally and seems to work fine:

$ ./pre-inst-env guix build libtorrent-rasterbar <at> 1.2
[..]
/gnu/store/dqs18nzd8pxacb0bkkqzbb3q6w5fyz66-libtorrent-rasterbar-1.2.20

 gnu/packages/bittorrent.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index 667350ad9c..34c2141db7 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -476,7 +476,7 @@ (define-public libtorrent-rasterbar
 (define-public libtorrent-rasterbar-1.2
   (package
     (inherit libtorrent-rasterbar)
-    (version "1.2.19")
+    (version "1.2.20")
     (source
      (origin
        (method url-fetch)
@@ -485,7 +485,7 @@ (define-public libtorrent-rasterbar-1.2
                        "releases/download/v" version "/"
                        "libtorrent-rasterbar-" version ".tar.gz"))
        (sha256
-        (base32 "03p4nvsll568zlyqifid0cn135sg5whbk7g48gkbapnw92ayks7f"))))))
+        (base32 "1z5rdynzxcm6wb7v48ssfbwjairbjacb8rjix5fn70fw4668xgyc"))))))

 (define-public qbittorrent
   (package
--
2.47.1

Message #44 received at 73664 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664 <at> debbugs.gnu.org
Subject: Re: bug#73664: [PATCH] gnu: libtorrent-rasterbar: Work around hang
 in test_ssl.
Date: Sun, 02 Feb 2025 00:40:32 +0900

Hi Tomas,

[...]

> Notice the build failure is for libtorrent-rasterbar <at> 1.2 (the
> libtorrent-rasterbar-1.2 variable).  My patch updated
> libtorrent-rasterbar <at> 2 to 2.0.11 (the libtorrent-rasterbar variable).
>
> So this is my fault, I did not realize that libtorrent-rasterbar-1.2
> inherits from libtorrent-rasterbar, so the change in check phase will
> affect both.  Sorry about that.

I did miss it too when reviewing/applying!  Thanks for your keen
observation, I missed the version difference.

> Luckily there is a new release (1.2.20) which seems to contain the
> extension of certificate expiry.  After breakfast I will do the update,
> test it and send a patch here.

Sounds good, thanks for the prompt reply!

-- 
Thanks,
Maxim

Message #49 received at 73664-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73664-done <at> debbugs.gnu.org
Subject: Re: [PATCH] gnu: libtorrent-rasterbar-1.2: Update to 1.2.20.
Date: Sun, 02 Feb 2025 01:17:01 +0900

Hi,

Tomas Volf <~@wolfsden.cz> writes:

> * gnu/packages/bittorrent.scm (libtorrent-rasterbar-1.2): Update to 1.2.20.

Pushed, let's see what CI says!

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.