From: Csepp <raingloom@riseup.net>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, guix-devel@gnu.org
Subject: Re: collection of “guix pull“ bug reports
Date: Wed, 30 Aug 2023 04:15:00 +0200 [thread overview]
Message-ID: <87ledtjmup.fsf@riseup.net> (raw)
In-Reply-To: <874jkjsheb.fsf@gmail.com>
Simon Tournier <zimon.toutoune@gmail.com> writes:
> Hi Maxim,
>
> On Sat, 26 Aug 2023 at 22:34, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>> https://issues.guix.gnu.org/issue/62830
>>> https://issues.guix.gnu.org/issue/63451
>>> https://issues.guix.gnu.org/issue/63830
>>> https://issues.guix.gnu.org/issue/64489
>>> https://issues.guix.gnu.org/issue/64659
>>> https://issues.guix.gnu.org/issue/64753
>>> https://issues.guix.gnu.org/issue/64963
>
> [...]
>
>>> Any idea about what could be unexpected or what needs some love?
>>
>> I haven't checked the above links, but I think something that would help
>> in this regard is better handling of network issues. E.g, don't print a
>> backtrace on the first connection failure; retry maybe 3 times then
>> print a helpful error mentioning the network appears unreliable.
>
> IMHO, this collection raises two questions:
>
> 1. Why does it happen? To say it explicitly, I am almost sure that
> something is not smoothly working as expected on server side. For
> instance, I had ‘guix pull’ troubles with a machine and I am doubtful
> that this machine has network issue (this machine is using the fast
> network link of my Univ. employer :-))
>
> 2. What could be done on client side for reducing the annoyance? I
> agree that substitute failures should be better handled. For example,
> retry 3 times then display an error message. Etc.
>
>
> Cheers,
> simon
>
> PS: About #2, please give a look at these annoyances:
>
> + Issue 1 and 2: Options --fallabck and --no-substitutes
> + Issue 3: Non consistent message for substitutes and/or fallback
>
> from <https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html>.
There also needs to be an option to just retry forever IMHO. On my
netbook it is very costly to re-run guix pull's non-substitutable parts
so I'd rather Guix just kept trying in case of network errors.
next prev parent reply other threads:[~2023-08-30 2:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 16:17 collection of “guix pull“ bug reports Simon Tournier
2023-08-27 2:34 ` Maxim Cournoyer
2023-08-28 8:25 ` Simon Tournier
2023-08-28 22:42 ` Kierin Bell
2023-08-30 2:15 ` Csepp [this message]
2023-11-16 8:32 ` Simon Tournier
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=87ledtjmup.fsf@riseup.net \
--to=raingloom@riseup.net \
--cc=guix-devel@gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=zimon.toutoune@gmail.com \
/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).