libtorrent-rasterbar@1.2: failure in test_ssl

  • Done
  • quality assurance status badge
Details
2 participants
  • Maxim Cournoyer
  • Tomas Volf
Owner
unassigned
Submitted by
Tomas Volf
Severity
normal

Debbugs page

Tomas Volf wrote 5 months ago
[PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.
(address . guix-patches@gnu.org)(name . Tomas Volf)(address . ~@wolfsden.cz)
b318e317dab97a658b90669a49edc79247716c87.1728231109.git.~@wolfsden.cz
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(-)

Toggle diff (49 lines)
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
Maxim Cournoyer wrote 3 months ago
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664@debbugs.gnu.org)
87r067rtpd.fsf@gmail.com
Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (4 lines)
> 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.

Toggle quote (8 lines)
> 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.

[...]

Toggle quote (20 lines)
> - ;; 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
Maxim Cournoyer wrote 3 months ago
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664@debbugs.gnu.org)
87a5cusxq1.fsf@gmail.com
Hello!

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (4 lines)
> 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:

Toggle snippet (35 lines)
[...]

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

--
Thanks,
Maxim
Tomas Volf wrote 1 months ago
[PATCH v2 1/2] gnu: libtorrent-rasterbar: Update to 2.0.11.
(address . 73664@debbugs.gnu.org)(name . Tomas Volf)(address . ~@wolfsden.cz)
88c8b5101c2d7addb17e55bfe044bb1600478329.1738093801.git.~@wolfsden.cz
* 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(-)

Toggle diff (24 lines)
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
Tomas Volf wrote 1 months ago
[PATCH v2 2/2] gnu: libtorrent-rasterbar: Remove special case for test_ssl.
(address . 73664@debbugs.gnu.org)(name . Tomas Volf)(address . ~@wolfsden.cz)
f2f2eb72ee9378d99160293e8ee2e2aa5df10cd7.1738093801.git.~@wolfsden.cz
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(-)

Toggle diff (49 lines)
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
Tomas Volf wrote 1 months ago
Re: [bug#73664] [PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 73664@debbugs.gnu.org)
877c6ehfmg.fsf@wolfsden.cz
Hi Maxim,

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

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

Toggle quote (11 lines)
> 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".

Toggle quote (12 lines)
>
>> 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:

Toggle snippet (3 lines)
phase `check' succeeded after 811.0 seconds

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

Toggle quote (34 lines)
>
> [...]
>
>> - ;; 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.
-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeZN6cOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wamrtBAAm2u/IPdp+KuvJ9fGxaTfOOcHab3odk49tP3i
cGHgZiwgAde5XVYWKbB7iLaGmm4uAvI1j2k3j1Zw/F00loeyizuiFvewUQo4mxv8
E5kgXl6x5MzfTLubuvwRBeCo09szOHpC6J7pzzI7wvPTX+OpjYSdvHk+0odOSHrT
q4ef8FiA2zu/qH8etTcaXfUY4Ev9DNHeWKbe6f1w9XdY+RWJZBhelTTY6Bt3M45B
2NQcu2hniFQoNoykDgljprmVkwElaKU1w0BTnfUD3SC8veImNlbD/6CU81CqGyFa
UvsWFEFGrY7gOBa2INCe4eXFSaliSkF6TcfBsdfT1dQPl9XfaUA/SemVcq5nNpi4
Y6j5HRwfPIRVITbX6HH+HLr6UfK4Gfd98EU2/xidgRlTdds8p7uZHCiDlqnDt+Xn
XSgBlHjXCWiSAcVNhMt+7zqgFJvj5kBmQxhwZttJzGiWA7Bt8lWv/TfdIh64kbGL
D9kMxv8oddADL37xBZfMTBPMVQl/zYhsNEmg35W5EtrwTL3uKIAiD3/kl3uq+h1A
LAi0Vr6ypMLMDxSQNuXHIcf757HwYZOLm8eJgDxOBEI22E2WUUX0YUFwKv7HRmdY
q4/5PlZNuCQGW1zyFmyXIXPOAfqWvWQBLUY/CC7SeDauss4/zfr9a6zRsOA/lAaA
ayN0v1I=
=1ZC+
-----END PGP SIGNATURE-----

Maxim Cournoyer wrote 1 months ago
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664@debbugs.gnu.org)
87o6zqqsz6.fsf@gmail.com
Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (22 lines)
> Hi Maxim,
>
> thank you very much for the review and apologies for the late response,
> I have kept postponing it.
>
> Maxim Cournoyer <maxim.cournoyer@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).

Toggle quote (19 lines)
>>
>>> 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.

Toggle quote (19 lines)
>> 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).

Toggle quote (6 lines)
> 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
Maxim Cournoyer wrote 1 months ago
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664-done@debbugs.gnu.org)
87ldutpxjx.fsf@gmail.com
Hi Tomas,

Finally pushed. Thanks for the good work!

--
Maxim
Closed
Maxim Cournoyer wrote 1 months ago
Re: bug#73664: [PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664@debbugs.gnu.org)
871pwim8s6.fsf_-_@gmail.com
reopen 73664
retitle 73664 libtorrent-rasterbar: non-deterministic failures in test_ssl
quit

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (7 lines)
> 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:


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
Tomas Volf wrote 1 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 73664@debbugs.gnu.org)
87seoxapkk.fsf@wolfsden.cz
Hi,

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

Toggle quote (23 lines)
> 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@1.2 (the
libtorrent-rasterbar-1.2 variable). My patch updated
libtorrent-rasterbar@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.
-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmeeAQsOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/walFTg/9G37Rrmkz4dZfPi634+OkmlDPlYtqObZX9KaA
XnpbCgNR0doXy83PO6wws5lhby74+IUxrvTVjZ6BfkL5ND4xX9pZmRDeH4ved6yS
1gzaiQJklLqog9yd2WDs+VYi6upjFnDrrnvTSBYdMxknmWnKN5Mjv4tAgy9NEpI5
ZEXy2PgjuaS0Zhcd5H/S43yWwiBZbbgtqBqNmWTvf2jnfnvz6y26d0goldKUD9LT
PZWXaVoA59MDkQiw7BVOW6ER6cxeAFZAkSCP9AKlwVgPVQy8G6j4oTDm5mvoifIS
nw6X8kw/scQ4EYzcDS0zp1rHCvebJfPrpQDVrYB04EV6fSwcEUzmf0PvLFDlqCU6
lE9MHP1CLk1G8O5P92hmqGj5o8FAiXyWq+TtvDM9Czf+XVi/fQAMTa42PTKK4rSl
06q0Tflwnm1eKIX3oDGcKaoW7sQARxiLqktUp0dz5vO9aXUqCOpxVj8/WTO8zEBL
aQQ3vJsNcNWjVRNWYYvbx6dzTIfV0dqfrFVRaPYDbxCdM/jUkUQ0QQ1SfwxDmlya
FmRvEu1sEBx1HaCK9QgFajZMyZ9UBueZ0llPW/PVfYu8SzdWSgvnrQmq+fRLiT3h
/lLCb7247O+oNuy8rIeecvRfvhdwg7DWo8l6TeJmpL5OkHzUQZO1HKO6tZPNIQKz
wjOPtoE=
=5kmr
-----END PGP SIGNATURE-----

Tomas Volf wrote 1 months ago
control message for bug #73664
(address . control@debbugs.gnu.org)
87plk1api8.fsf@wolfsden.cz
reopen 73664
retitle 73664 libtorrent-rasterbar@1.2: failure in test_ssl
quit
Tomas Volf wrote 1 months ago
[PATCH] gnu: libtorrent-rasterbar-1.2: Update to 1.2.20.
(address . 73664@debbugs.gnu.org)
ece05ac5ed8b07aead8ace18d6ee27fbdb45d853.1738412185.git.~@wolfsden.cz
* 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@1.2
[..]
/gnu/store/dqs18nzd8pxacb0bkkqzbb3q6w5fyz66-libtorrent-rasterbar-1.2.20

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

Toggle diff (22 lines)
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
Maxim Cournoyer wrote 1 months ago
Re: bug#73664: [PATCH] gnu: libtorrent-rasterbar: Work around hang in test_ssl.
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664@debbugs.gnu.org)
87bjvllllb.fsf@gmail.com
Hi Tomas,

[...]

Toggle quote (8 lines)
> Notice the build failure is for libtorrent-rasterbar@1.2 (the
> libtorrent-rasterbar-1.2 variable). My patch updated
> libtorrent-rasterbar@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.

Toggle quote (4 lines)
> 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
Maxim Cournoyer wrote 1 months ago
Re: [PATCH] gnu: libtorrent-rasterbar-1.2: Update to 1.2.20.
(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 73664-done@debbugs.gnu.org)
8734gxljwi.fsf@gmail.com
Hi,

Tomas Volf <~@wolfsden.cz> writes:

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

Pushed, let's see what CI says!

--
Thanks,
Maxim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 73664@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 73664
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help