* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities @ 2018-10-20 2:22 Maxim Cournoyer 2018-10-20 14:05 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-20 2:22 UTC (permalink / raw) To: 33100 Hello, Today I stumbled upon libssh that wouldn't build, due to the following git error: --8<---------------cut here---------------start------------->8--- fatal: dumb http transport does not support shallow capabilities" --8<---------------cut here---------------end--------------->8--- There are now substitutes served from Berlin, so it's a bit more difficult to reproduce, but the following worked for Ludovic and myself: guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv The output looks like: --8<---------------cut here---------------start------------->8--- guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv... Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/ fatal: dumb http transport does not support shallow capabilities --8<---------------cut here---------------end--------------->8--- Leo, would you have an idea? Thanks, Maxim ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-20 2:22 bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities Maxim Cournoyer @ 2018-10-20 14:05 ` Ludovic Courtès 2018-10-21 3:24 ` Maxim Cournoyer 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2018-10-20 14:05 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100 Hello! Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv > building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv... > Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/ > fatal: dumb http transport does not support shallow capabilities On closer inspection, it seems that there’s nothing “fatal” here: if you let it run for a while (1 or 2 minutes), it ends up silently cloning the whole repo and the derivation build eventually succeeds. Could you check if that’s the case for you? berlin.guixsd.org has a substitute for this checkout, which suggests it went fine there. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-20 14:05 ` Ludovic Courtès @ 2018-10-21 3:24 ` Maxim Cournoyer 2018-10-21 19:10 ` Leo Famulari 2018-10-22 9:55 ` Ludovic Courtès 0 siblings, 2 replies; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-21 3:24 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done Hi, ludo@gnu.org (Ludovic Courtès) writes: > Hello! > > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > >> guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv >> building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv... >> Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/ >> fatal: dumb http transport does not support shallow capabilities > > On closer inspection, it seems that there’s nothing “fatal” here: if you > let it run for a while (1 or 2 minutes), it ends up silently cloning the > whole repo and the derivation build eventually succeeds. It did end up working fine, although it took a large amout of time for doing what seems to be a checkout (4 min 46 s). I did some experiments and this is really the time it took to do a full clone of the libssh project. --8<---------------cut here---------------start------------->8--- time git clone git://git.libssh.org/projects/libssh.git libssh Cloning into 'libssh'... remote: Enumerating objects: 28264, done. remote: Counting objects: 100% (28264/28264), done. remote: Compressing objects: 100% (11718/11718), done. remote: Total 28264 (delta 20985), reused 21830 (delta 16350)s Receiving objects: 100% (28264/28264), 5.21 MiB | 263.00 KiB/s, done. Resolving deltas: 100% (20985/20985), done. real 4m19.419s user 0m3.272s sys 0m0.540s --8<---------------cut here---------------end--------------->8--- It's a bit of a shame, given that the shallow clone takes about 2 seconds (!): --8<---------------cut here---------------start------------->8--- time git clone --depth 1 git://git.libssh.org/projects/libssh.git libssh Cloning into 'libssh'... remote: Enumerating objects: 367, done. remote: Counting objects: 100% (367/367), done. remote: Compressing objects: 100% (358/358), done. remote: Total 367 (delta 39), reused 53 (delta 1) Receiving objects: 100% (367/367), 704.23 KiB | 728.00 KiB/s, done. Resolving deltas: 100% (39/39), done. real 0m2.028s user 0m0.160s sys 0m0.071s --8<---------------cut here---------------end--------------->8--- Based on the discussion here: https://github.com/CocoaPods/CocoaPods/issues/6270, it would seem this means that the libssh git server doesn't support the newer "smart HTTP transport" and the git client bails out (IIUC). At least in our case the guile-ssh library seems to already correctly fallback to doing a full clone. Perhaps just clearer messages would have helped here also ('Failed to do a shallow git clone due to ~error message~, falling back to a full clone'). Such a change would need to be made in guile-git IIUC. I'll close this bug now; thank you! Maxim ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-21 3:24 ` Maxim Cournoyer @ 2018-10-21 19:10 ` Leo Famulari 2018-10-21 21:42 ` Maxim Cournoyer 2018-10-22 9:55 ` Ludovic Courtès 1 sibling, 1 reply; 17+ messages in thread From: Leo Famulari @ 2018-10-21 19:10 UTC (permalink / raw) To: 33100, maxim.cournoyer [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] On Sat, Oct 20, 2018 at 11:24:24PM -0400, Maxim Cournoyer wrote: > ludo@gnu.org (Ludovic Courtès) writes: > > On closer inspection, it seems that there’s nothing “fatal” here: if you > > let it run for a while (1 or 2 minutes), it ends up silently cloning the > > whole repo and the derivation build eventually succeeds. > > It did end up working fine, although it took a large amout of time for > doing what seems to be a checkout (4 min 46 s). I did some experiments > and this is really the time it took to do a full clone of the libssh > project. Great, you figured it out :) More explanation: Git has a few different server protocols: git, dumb HTTP, smart HTTP, and SSH: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols The dumb HTTP protocol is slow and does not show any progress status or other informative message while it works, but if you monitor your network traffic you can see it working. For obvious reasons, it's rare to see the dumb HTTP protocol deployed nowadays, but you may still find it on legacy installations. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-21 19:10 ` Leo Famulari @ 2018-10-21 21:42 ` Maxim Cournoyer 0 siblings, 0 replies; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-21 21:42 UTC (permalink / raw) To: Leo Famulari; +Cc: 33100 Hello Leo, Leo Famulari <leo@famulari.name> writes: > On Sat, Oct 20, 2018 at 11:24:24PM -0400, Maxim Cournoyer wrote: >> ludo@gnu.org (Ludovic Courtès) writes: >> > On closer inspection, it seems that there’s nothing “fatal” here: if you >> > let it run for a while (1 or 2 minutes), it ends up silently cloning the >> > whole repo and the derivation build eventually succeeds. >> >> It did end up working fine, although it took a large amout of time for >> doing what seems to be a checkout (4 min 46 s). I did some experiments >> and this is really the time it took to do a full clone of the libssh >> project. > > Great, you figured it out :) > > More explanation: > > Git has a few different server protocols: git, dumb HTTP, smart HTTP, > and SSH: > > https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols > > The dumb HTTP protocol is slow and does not show any progress status or > other informative message while it works, but if you monitor your > network traffic you can see it working. > > For obvious reasons, it's rare to see the dumb HTTP protocol deployed > nowadays, but you may still find it on legacy installations. Thanks for the extra bits of information :) Cheers, Maxim ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-21 3:24 ` Maxim Cournoyer 2018-10-21 19:10 ` Leo Famulari @ 2018-10-22 9:55 ` Ludovic Courtès 2018-10-22 17:07 ` Leo Famulari 2018-10-24 13:01 ` Maxim Cournoyer 1 sibling, 2 replies; 17+ messages in thread From: Ludovic Courtès @ 2018-10-22 9:55 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100-done Hello, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > It did end up working fine, although it took a large amout of time for > doing what seems to be a checkout (4 min 46 s). I did some experiments > and this is really the time it took to do a full clone of the libssh > project. > > time git clone git://git.libssh.org/projects/libssh.git libssh > Cloning into 'libssh'... > remote: Enumerating objects: 28264, done. > remote: Counting objects: 100% (28264/28264), done. > remote: Compressing objects: 100% (11718/11718), done. > remote: Total 28264 (delta 20985), reused 21830 (delta 16350)s > Receiving objects: 100% (28264/28264), 5.21 MiB | 263.00 KiB/s, done. > Resolving deltas: 100% (20985/20985), done. > > real 4m19.419s > user 0m3.272s > sys 0m0.540s > > > It's a bit of a shame, given that the shallow clone takes about 2 > seconds (!): > > time git clone --depth 1 git://git.libssh.org/projects/libssh.git libssh > Cloning into 'libssh'... > remote: Enumerating objects: 367, done. > remote: Counting objects: 100% (367/367), done. > remote: Compressing objects: 100% (358/358), done. > remote: Total 367 (delta 39), reused 53 (delta 1) > Receiving objects: 100% (367/367), 704.23 KiB | 728.00 KiB/s, done. > Resolving deltas: 100% (39/39), done. > > real 0m2.028s > user 0m0.160s > sys 0m0.071s > > Based on the discussion here: > https://github.com/CocoaPods/CocoaPods/issues/6270, it would seem this > means that the libssh git server doesn't support the newer "smart HTTP > transport" and the git client bails out (IIUC). At least in our case the > guile-ssh library seems to already correctly fallback to doing a full > clone. Switching to the git:// transport would seem like a reasonable workaround—we’d lose encryption and authentication, but the latter is covered by the content hash in the ‘origin’ anyway. WDYT, Leo? > Perhaps just clearer messages would have helped here also ('Failed to do > a shallow git clone due to ~error message~, falling back to a full clone'). I agree, and that’s something to suggest to the Git folks. :-) Thanks, Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-22 9:55 ` Ludovic Courtès @ 2018-10-22 17:07 ` Leo Famulari 2018-10-24 13:01 ` Maxim Cournoyer 1 sibling, 0 replies; 17+ messages in thread From: Leo Famulari @ 2018-10-22 17:07 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done, Maxim Cournoyer [-- Attachment #1.1: Type: text/plain, Size: 1198 bytes --] On Mon, Oct 22, 2018 at 11:55:26AM +0200, Ludovic Courtès wrote: > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > > It did end up working fine, although it took a large amout of time for > > doing what seems to be a checkout (4 min 46 s). I did some experiments > > and this is really the time it took to do a full clone of the libssh > > project. [...] > > It's a bit of a shame, given that the shallow clone takes about 2 > > seconds (!): Yeah, it's incredibly slow. The repo is not even 10 MB. At first, I too thought the HTTPS clone had stalled. Protocol duration ------------------------ https:// 217 sec git:// 10 sec git:// shallow 1.5 sec And of course, the shallow clone is 3.6 MB instead of 10 MB. > Switching to the git:// transport would seem like a reasonable > workaround—we’d lose encryption and authentication, but the latter is > covered by the content hash in the ‘origin’ anyway. > > WDYT, Leo? Overall, I think the slowness doesn't matter too much, since we offer substitutes for the patched source code. However, here is a patch. Please feel free to apply it! I'll ask the libssh team to support "smart" HTTP Git. [-- Attachment #1.2: 0001-gnu-libssh-Fetch-the-source-code-more-efficiently.patch --] [-- Type: text/plain, Size: 1524 bytes --] From 683713dd8f5d67e3f077d5d13c23e5556d8ad779 Mon Sep 17 00:00:00 2001 From: Leo Famulari <leo@famulari.name> Date: Mon, 22 Oct 2018 13:00:55 -0400 Subject: [PATCH] gnu: libssh: Fetch the source code more efficiently. * gnu/packages/ssh.scm (libssh)[source]: Use the git:// protocol. --- gnu/packages/ssh.scm | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm index e806fc80f..b93cb03a1 100644 --- a/gnu/packages/ssh.scm +++ b/gnu/packages/ssh.scm @@ -71,8 +71,14 @@ (source (origin (method git-fetch) (uri (git-reference - (url "https://git.libssh.org/projects/libssh.git") - (commit (string-append "libssh-" version)))) + ;; git.libssh.org does not support the fast "smart" HTTP + ;; Git protocol. The "dumb" HTTP Git protocol is extremely + ;; slow, and does not support shallow clones, so we use the + ;; plain Git protocol despite its flaws. This offers an + ;; incredible speedup and reduces the size of the the + ;; source by more than half. + (url "git://git.libssh.org/projects/libssh.git") + (commit (string-append "libssh-" version)))) (patches (search-patches "libssh-hostname-parser-bug.patch")) (sha256 (base32 -- 2.19.1 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-22 9:55 ` Ludovic Courtès 2018-10-22 17:07 ` Leo Famulari @ 2018-10-24 13:01 ` Maxim Cournoyer 2018-10-24 14:11 ` Ludovic Courtès 2018-10-24 14:15 ` Leo Famulari 1 sibling, 2 replies; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-24 13:01 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done [-- Attachment #1: Type: text/plain, Size: 512 bytes --] Hi Ludovic, ludo@gnu.org (Ludovic Courtès) writes: [...] >> Perhaps just clearer messages would have helped here also ('Failed to do >> a shallow git clone due to ~error message~, falling back to a full clone'). > > I agree, and that’s something to suggest to the Git folks. :-) Upon further inspection, we can do better on our side, specifically by printing a message of the fallback occurring when calling git-fetch. The patch below implements this simple change. What do you think? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-build-git-fetch-Print-message-when-falling-back-to-a.patch --] [-- Type: text/x-patch, Size: 1130 bytes --] From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer <maxim.cournoyer@gmail.com> Date: Wed, 24 Oct 2018 08:49:50 -0400 Subject: [PATCH] build: git-fetch: Print message when falling back to a full checkout. Otherwise the user might believe that git-fetch stalled, observing the lack of output following a 'fatal' git error message (see: https://debbugs.gnu.org/33100). * guix/build/git.scm (git-fetch): Print message when falling back to a full checkout. --- guix/build/git.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/guix/build/git.scm b/guix/build/git.scm index 14d415a6f..df8f1548b 100644 --- a/guix/build/git.scm +++ b/guix/build/git.scm @@ -45,6 +45,7 @@ recursively. Return #t on success, #f otherwise." (if (zero? (system* git-command "fetch" "--depth" "1" "origin" commit)) (invoke git-command "checkout" "FETCH_HEAD") (begin + (format #t "Failed to do a shallow fetch; retrying a full fetch...~%") (invoke git-command "fetch" "origin") (invoke git-command "checkout" commit))) (when recursive? -- 2.19.0 [-- Attachment #3: Type: text/plain, Size: 7 bytes --] Maxim ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-24 13:01 ` Maxim Cournoyer @ 2018-10-24 14:11 ` Ludovic Courtès 2018-10-24 14:15 ` Leo Famulari 1 sibling, 0 replies; 17+ messages in thread From: Ludovic Courtès @ 2018-10-24 14:11 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100-done Hi, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > Upon further inspection, we can do better on our side, specifically by > printing a message of the fallback occurring when calling git-fetch. The > patch below implements this simple change. > > What do you think? > > From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer <maxim.cournoyer@gmail.com> > Date: Wed, 24 Oct 2018 08:49:50 -0400 > Subject: [PATCH] build: git-fetch: Print message when falling back to a full > checkout. > > Otherwise the user might believe that git-fetch stalled, observing the lack of > output following a 'fatal' git error message (see: > https://debbugs.gnu.org/33100). > > * guix/build/git.scm (git-fetch): Print message when falling back to a full > checkout. Oh indeed, I had overlooked that. Go for it! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-24 13:01 ` Maxim Cournoyer 2018-10-24 14:11 ` Ludovic Courtès @ 2018-10-24 14:15 ` Leo Famulari 2018-10-24 21:33 ` Ludovic Courtès 1 sibling, 1 reply; 17+ messages in thread From: Leo Famulari @ 2018-10-24 14:15 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100-done [-- Attachment #1: Type: text/plain, Size: 755 bytes --] On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote: > From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer <maxim.cournoyer@gmail.com> > Date: Wed, 24 Oct 2018 08:49:50 -0400 > Subject: [PATCH] build: git-fetch: Print message when falling back to a full > checkout. > > Otherwise the user might believe that git-fetch stalled, observing the lack of > output following a 'fatal' git error message (see: > https://debbugs.gnu.org/33100). > > * guix/build/git.scm (git-fetch): Print message when falling back to a full > checkout. I like it, but it doesn't seem to actually print anything for me when I trigger the failing case, for example by fetching the libssh source over HTTP. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-24 14:15 ` Leo Famulari @ 2018-10-24 21:33 ` Ludovic Courtès 2018-10-25 1:02 ` Leo Famulari 2018-10-25 1:44 ` Maxim Cournoyer 0 siblings, 2 replies; 17+ messages in thread From: Ludovic Courtès @ 2018-10-24 21:33 UTC (permalink / raw) To: Leo Famulari; +Cc: 33100-done, Maxim Cournoyer Leo Famulari <leo@famulari.name> skribis: > On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote: >> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer <maxim.cournoyer@gmail.com> >> Date: Wed, 24 Oct 2018 08:49:50 -0400 >> Subject: [PATCH] build: git-fetch: Print message when falling back to a full >> checkout. >> >> Otherwise the user might believe that git-fetch stalled, observing the lack of >> output following a 'fatal' git error message (see: >> https://debbugs.gnu.org/33100). >> >> * guix/build/git.scm (git-fetch): Print message when falling back to a full >> checkout. > > I like it, but it doesn't seem to actually print anything for me when I > trigger the failing case, for example by fetching the libssh source over > HTTP. If might be that current-output-port is fully buffered. What if you add: (setvbuf (current-output-port) 'line) before the ‘format’ call? Thanks, Ludo’, who is found guilty of not actually running the code. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-24 21:33 ` Ludovic Courtès @ 2018-10-25 1:02 ` Leo Famulari 2018-10-25 1:44 ` Maxim Cournoyer 1 sibling, 0 replies; 17+ messages in thread From: Leo Famulari @ 2018-10-25 1:02 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done, Maxim Cournoyer On Wed, Oct 24, 2018 at 11:33:03PM +0200, Ludovic Courtès wrote: > If might be that current-output-port is fully buffered. What if you > add: > > (setvbuf (current-output-port) 'line) > > before the ‘format’ call? Yeah, this lets' the message through. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-24 21:33 ` Ludovic Courtès 2018-10-25 1:02 ` Leo Famulari @ 2018-10-25 1:44 ` Maxim Cournoyer 2018-10-25 12:24 ` Ludovic Courtès 1 sibling, 1 reply; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-25 1:44 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done ludo@gnu.org (Ludovic Courtès) writes: > Leo Famulari <leo@famulari.name> skribis: > >> On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote: >>> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 >>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com> >>> Date: Wed, 24 Oct 2018 08:49:50 -0400 >>> Subject: [PATCH] build: git-fetch: Print message when falling back to a full >>> checkout. >>> >>> Otherwise the user might believe that git-fetch stalled, observing the lack of >>> output following a 'fatal' git error message (see: >>> https://debbugs.gnu.org/33100). >>> >>> * guix/build/git.scm (git-fetch): Print message when falling back to a full >>> checkout. >> >> I like it, but it doesn't seem to actually print anything for me when I >> trigger the failing case, for example by fetching the libssh source over >> HTTP. > > If might be that current-output-port is fully buffered. What if you > add: > > (setvbuf (current-output-port) 'line) > > before the ‘format’ call? > > Thanks, > Ludo’, who is found guilty of not actually running the code. What is preferable, between your solution or using (force-output)? I'll send a revised patch accordingly. Thank you, Maxim ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-25 1:44 ` Maxim Cournoyer @ 2018-10-25 12:24 ` Ludovic Courtès 2018-10-27 2:05 ` Maxim Cournoyer 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2018-10-25 12:24 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100-done Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> Leo Famulari <leo@famulari.name> skribis: >> >>> On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote: >>>> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001 >>>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com> >>>> Date: Wed, 24 Oct 2018 08:49:50 -0400 >>>> Subject: [PATCH] build: git-fetch: Print message when falling back to a full >>>> checkout. >>>> >>>> Otherwise the user might believe that git-fetch stalled, observing the lack of >>>> output following a 'fatal' git error message (see: >>>> https://debbugs.gnu.org/33100). >>>> >>>> * guix/build/git.scm (git-fetch): Print message when falling back to a full >>>> checkout. >>> >>> I like it, but it doesn't seem to actually print anything for me when I >>> trigger the failing case, for example by fetching the libssh source over >>> HTTP. >> >> If might be that current-output-port is fully buffered. What if you >> add: >> >> (setvbuf (current-output-port) 'line) >> >> before the ‘format’ call? >> >> Thanks, >> Ludo’, who is found guilty of not actually running the code. > > What is preferable, between your solution or using (force-output)? I’d go for line buffering since you only need to do it once for all. Thanks! Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-25 12:24 ` Ludovic Courtès @ 2018-10-27 2:05 ` Maxim Cournoyer 2018-10-27 14:45 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-27 2:05 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done [-- Attachment #1: Type: text/plain, Size: 823 bytes --] Hello! ludo@gnu.org (Ludovic Courtès) writes: >>>> I like it, but it doesn't seem to actually print anything for me when I >>>> trigger the failing case, for example by fetching the libssh source over >>>> HTTP. >>> >>> If might be that current-output-port is fully buffered. What if you >>> add: >>> >>> (setvbuf (current-output-port) 'line) >>> >>> before the ‘format’ call? >>> >>> Thanks, >>> Ludo’, who is found guilty of not actually running the code. >> >> What is preferable, between your solution or using (force-output)? > > I’d go for line buffering since you only need to do it once for all. I finally got around to reproducing the problem and testing the fix; it was costly to build using --no-substitutes. Is it OK to push this patch into master? Thanks, Maxim [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-git-download-Print-a-message-when-falling-back-to-a-.patch --] [-- Type: text/x-patch, Size: 1173 bytes --] From 44782db3f63a29cdbd98cddb77eab8a473806765 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer <maxim.cournoyer@gmail.com> Date: Wed, 24 Oct 2018 08:49:50 -0400 Subject: [PATCH] git-download: Print a message when falling back to a full fetch. Otherwise the user might believe that git-fetch stalled, observing the lack of output following a 'fatal' git error message (see: https://debbugs.gnu.org/33100). * guix/build/git.scm (git-fetch): Print message when falling back to a full fetch. --- guix/build/git.scm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/guix/build/git.scm b/guix/build/git.scm index 14d415a6f..2d1700a9b 100644 --- a/guix/build/git.scm +++ b/guix/build/git.scm @@ -45,6 +45,8 @@ recursively. Return #t on success, #f otherwise." (if (zero? (system* git-command "fetch" "--depth" "1" "origin" commit)) (invoke git-command "checkout" "FETCH_HEAD") (begin + (setvbuf (current-output-port) 'line) + (format #t "Failed to do a shallow fetch; retrying a full fetch...~%") (invoke git-command "fetch" "origin") (invoke git-command "checkout" commit))) (when recursive? -- 2.19.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-27 2:05 ` Maxim Cournoyer @ 2018-10-27 14:45 ` Ludovic Courtès 2018-10-29 2:45 ` Maxim Cournoyer 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2018-10-27 14:45 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 33100-done Hi Maxim, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >>>>> I like it, but it doesn't seem to actually print anything for me when I >>>>> trigger the failing case, for example by fetching the libssh source over >>>>> HTTP. >>>> >>>> If might be that current-output-port is fully buffered. What if you >>>> add: >>>> >>>> (setvbuf (current-output-port) 'line) >>>> >>>> before the ‘format’ call? >>>> >>>> Thanks, >>>> Ludo’, who is found guilty of not actually running the code. >>> >>> What is preferable, between your solution or using (force-output)? >> >> I’d go for line buffering since you only need to do it once for all. > > I finally got around to reproducing the problem and testing the fix; it > was costly to build using --no-substitutes. > > Is it OK to push this patch into master? Definitely, thank you! Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities 2018-10-27 14:45 ` Ludovic Courtès @ 2018-10-29 2:45 ` Maxim Cournoyer 0 siblings, 0 replies; 17+ messages in thread From: Maxim Cournoyer @ 2018-10-29 2:45 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 33100-done Hello, ludo@gnu.org (Ludovic Courtès) writes: [...] >> Is it OK to push this patch into master? > > Definitely, thank you! > > Ludo’. Pushed as commit 2f18b7329! Thank you, Maxim ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-10-29 2:47 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-10-20 2:22 bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities Maxim Cournoyer 2018-10-20 14:05 ` Ludovic Courtès 2018-10-21 3:24 ` Maxim Cournoyer 2018-10-21 19:10 ` Leo Famulari 2018-10-21 21:42 ` Maxim Cournoyer 2018-10-22 9:55 ` Ludovic Courtès 2018-10-22 17:07 ` Leo Famulari 2018-10-24 13:01 ` Maxim Cournoyer 2018-10-24 14:11 ` Ludovic Courtès 2018-10-24 14:15 ` Leo Famulari 2018-10-24 21:33 ` Ludovic Courtès 2018-10-25 1:02 ` Leo Famulari 2018-10-25 1:44 ` Maxim Cournoyer 2018-10-25 12:24 ` Ludovic Courtès 2018-10-27 2:05 ` Maxim Cournoyer 2018-10-27 14:45 ` Ludovic Courtès 2018-10-29 2:45 ` Maxim Cournoyer
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).