guix pull does not handle url lists and unreachable requests

  • Open
  • quality assurance status badge
Details
3 participants
  • ng0
  • Maxim Cournoyer
  • zimoun
Owner
unassigned
Submitted by
ng0
Severity
normal
Merged with

Debbugs page

N
N
ng0 wrote on 9 Mar 2017 06:51
(address . bug-guix@gnu.org)
20170309145105.snpnroqjm35omgow@abyayala
efficient enough and sets the times out much too high
Reply-To:
In-Reply-To:
When you configure a system to use bayfront, for example with these
lines included in cons* of (services):
(modify-services
%base-services
(guix-service-type
config =>
(guix-configuration
(inherit config)
(substitute-urls
(cons* "https://bayfront.guixsd.org"
%default-substitute-urls))
(authorized-keys
(cons*
(plain-file "bayfront.guixsd.org.pub"
(string-append "(public-key (ecc curve
Ed25519) "
"(q
#8D156F295D24B0D9A86FA5741A840FF2"

"D24F60F7B6C4134814AD55625971B394#)))"))
%default-authorized-guix-keys))))))))

please consider that this does not reflect the actual indent and that I
can't paste all of the config here, but those are the relevant parts,
you will experience that: "guix package", and "guix system" (or guix
buld?) query all listed subsitute urls, while "guix pull" only queries
the first one. If the first one is experiencing issues (for example
server is offline or can't handle requests for whatever reasons), the
timeout is much too high. I had to cancel guix pull processes which
tried to request from bayfront.guixsd.org for 9, 12, and 3 hours.

As bayfront wasn't the only server, a switch should occur even with the
guix pull part where substitute servers are queried before the build of
the fetched master tarball starts.
N
N
ng0 wrote on 9 Mar 2017 07:02
(address . 26035@debbugs.gnu.org)
20170309150223.ol47nwzjr3pgymo5@abyayala
ng0 transcribed 1.6K bytes:
Toggle quote (2 lines)
> efficient enough and sets the times out much too high

Curses, my mailing program broke the subject. I thought I fixed it.

Toggle quote (39 lines)
> Reply-To:
> In-Reply-To:
> When you configure a system to use bayfront, for example with these
> lines included in cons* of (services):
> (modify-services
> %base-services
> (guix-service-type
> config =>
> (guix-configuration
> (inherit config)
> (substitute-urls
> (cons* "https://bayfront.guixsd.org"
> %default-substitute-urls))
> (authorized-keys
> (cons*
> (plain-file "bayfront.guixsd.org.pub"
> (string-append "(public-key (ecc curve
> Ed25519) "
> "(q
> #8D156F295D24B0D9A86FA5741A840FF2"
>
> "D24F60F7B6C4134814AD55625971B394#)))"))
> %default-authorized-guix-keys))))))))
>
> please consider that this does not reflect the actual indent and that I
> can't paste all of the config here, but those are the relevant parts,
> you will experience that: "guix package", and "guix system" (or guix
> buld?) query all listed subsitute urls, while "guix pull" only queries
> the first one. If the first one is experiencing issues (for example
> server is offline or can't handle requests for whatever reasons), the
> timeout is much too high. I had to cancel guix pull processes which
> tried to request from bayfront.guixsd.org for 9, 12, and 3 hours.
>
> As bayfront wasn't the only server, a switch should occur even with the
> guix pull part where substitute servers are queried before the build of
> the fetched master tarball starts.
>
>
>
M
M
Maxim Cournoyer wrote on 29 Oct 2017 09:37
control message for bug #26035
(address . control@debbugs.gnu.org)
87r2tlzz8n.fsf@gmail.com
merge 26035 26833
Z
Z
zimoun wrote on 20 Aug 2021 04:04
Re: bug#26833: `guix substitute --substitute' dies on unreachable substitute server
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
86pmu8nzrt.fsf@gmail.com
Hi Maxim,

Your recent investigation bug#30290 [0] rings this bell:


If it appears the same issue, maybe we could merge them. WDYT?

On Mon, 08 May 2017 at 08:40, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
Toggle quote (34 lines)
> Problem: When using multiple substitute servers, if one of the server is
> temporarily unreachable, `guix substitute --substitute' will throw an
> exception. Example (while bayfront server was down, attempting to build
> a package only available locally (emacs-dvc)):
>
> guix package -i emacs-dvc
> ;;; note: source file /home/maxim/.config/guix/latest/gnu/packages/emacs.scm
> ;;; newer than compiled /home/maxim/.config/guix/latest/gnu/packages/emacs.go
> ;;; note: source file /home/maxim/.config/guix/latest/gnu/packages/emacs.scm
> ;;; newer than compiled /gnu/store/nqy9m6hhnkkfwr5wyq5bac96v9s9hc9i-guix-0.12.0-9.25a4/lib/guile/2.0/site-ccache/gnu/packages/emacs.go
> ;;; note: source file /home/maxim/.config/guix/latest/gnu/packages/emacs.scm
> ;;; newer than compiled /run/current-system/profile/lib/guile/2.0/site-ccache/gnu/packages/emacs.go
> ;;; note: source file /home/maxim/.config/guix/latest/gnu/packages/emacs.scm
> ;;; newer than compiled /home/maxim/.cache/guile/ccache/2.0-LE-8-2.0/home/maxim/src/guix/gnu/packages/emacs.scm.go
> The following package will be installed:
> emacs-dvc trunk-1.591 /gnu/store/sraxmg5qz9i4338s4ks7asgy4v68dgqs-emacs-dvc-trunk-1.591
>>
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> Downloading https://bayfront.guixsd.org/nar/gzip/6h7ym07plwxfn4zq53ld8zfpbx3a09al-at-spi2-core-2.22.0 (1.1MiB installed)...
> guix substitute: error: connect: No route to host
> killing process 13896
> killing process 13896: No such process
>
> Expected: Since multiple substitute servers are being used, rather than
> bombing out on the first unavailable one, `guix substitute --substitute'
> (or any other command implicated with substitute servers) should simply
> warn about it before attempting the next one.
>
> Bonus point: `guix substitute --query' should also print a warning
> message that substitute server X couldn't be reached (it doesn't print
> anything about that right now, just skips to the next one).


Cheers,
simon

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 26035@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 26035
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