unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Tomas Volf <~@wolfsden.cz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 67722@debbugs.gnu.org
Subject: [bug#67722] [PATCH v2] gnu: libtorrent-rasterbar: Remove timeout for tests.
Date: Wed, 13 Dec 2023 00:03:05 +0100	[thread overview]
Message-ID: <ZXjmqSjfm_ScMjuj@ws> (raw)
In-Reply-To: <87fs07263o.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On 2023-12-12 09:11:07 +0100, Ludovic Courtès wrote:
> What’s the rationale though?
>
> If we know that tests, individually, are meant to take less than 10mn,
> it still seems nicer to stop at 10mn rather than wait for the 1h
> max-silent timeout, no?

Originally the rationale was to just try it out and see if it works in the CI or
not.  The timeout was not originally there, I added it during fixing of the
tests so I wondered if it was a mistake.  Since the QA is still in "Pending",
jury is still out on that one.

I do not know enough about the architecture and utilization of the build
machines to be sure, so one of my hypotheses was that the machine might have
been overloaded during the test run causing the timeout.  So I wanted to test
it.  (I sent this as #67693 at first, but I think the CI got confused by the WIP
prefix.  I am not sure what is a way to mark patches intended to check the CI,
but not necessarily intended to be merged.  Sorry you wasted the time reviewing
this, I did not expect anyone to look until the CI passes.)

In the mean time I was running the build locally to see if I can reproduce the
hang and I can.  After running for couple of hours in a loop the build failed
with the timeout (not sure on what round, guix build --rounds does not tell
that).

So it seems like the test_ssl is just prone to sporadic failures.  Since we both
succeeded in building locally, I assume we just got unlucky (or lucky?) in the
CI.

I am currently testing a v3, and once it passes --rounds=64 (which will take a
while) I will sent it as an updated patch.

Tomas

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-12-12 23:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-09  0:31 [bug#67722] [PATCH] gnu: libtorrent-rasterbar: Remove timeout for tests Tomas Volf
2023-12-09 19:34 ` [bug#67722] [PATCH v2] " Tomas Volf
2023-12-12  8:11   ` Ludovic Courtès
2023-12-12 23:03     ` Tomas Volf [this message]
2023-12-13 16:38 ` [bug#67722] [PATCH v3] gnu: libtorrent-rasterbar: Work around hang in test_ssl Tomas Volf
2023-12-15 11:32 ` [bug#67722] [PATCH v4] " Tomas Volf
2024-01-16 13:27   ` Tomas Volf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXjmqSjfm_ScMjuj@ws \
    --to=~@wolfsden.cz \
    --cc=67722@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).