You are not logged in.
I've upgraded my system from Devuan 2 to Devuan 4 and now git hangs on cloning any repository. Example:
# GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone --verbose https://github.com/punesemu/puNES
02:04:36.418257 git.c:444 trace: built-in: git clone --verbose https://github.com/punesemu/puNES
Cloning into 'puNES'...
02:04:36.420737 run-command.c:664 trace: run_command: git remote-https origin https://github.com/punesemu/puNES
02:04:36.423321 git.c:730 trace: exec: git-remote-https origin https://github.com/punesemu/puNES
02:04:36.423418 run-command.c:664 trace: run_command: git-remote-https origin https://github.com/punesemu/puNES
02:04:36.434643 http.c:756 == Info: Couldn't find host github.com in the .netrc file; using defaults
02:04:36.440239 http.c:756 == Info: Trying 140.82.121.3:443...
02:04:36.466931 http.c:756 == Info: Connected to github.com (140.82.121.3) port 443 (#0)
02:04:36.514346 http.c:756 == Info: found 384 certificates in /etc/ssl/certs
02:04:36.514423 http.c:756 == Info: ALPN, offering h2
02:04:36.514429 http.c:756 == Info: ALPN, offering http/1.1
I did upgrade to Devuan 3 first, i did not skipped it. cURL is able to fetch pages without errors. I do not know if git is able to clone if HTTP is used instead of HTTPS, because every repo i know instantly redirects the request to HTTPS.
# apt policy git
git:
Telepítve: 1:2.30.2-1
Jelölt: 1:2.30.2-1
Verziótáblázat:
*** 1:2.30.2-1 500
500 http://devuan.bio.lmu.de/merged chimaera/main amd64 Packages
100 /var/lib/dpkg/status
# apt policy ca-certificates
ca-certificates:
Telepítve: 20210119
Jelölt: 20210119
Verziótáblázat:
*** 20210119 500
500 http://devuan.bio.lmu.de/merged chimaera/main amd64 Packages
500 http://devuan.bio.lmu.de/merged chimaera/main i386 Packages
100 /var/lib/dpkg/status
I do not use firewall or proxy.
Any tips on this?
Offline
Further details on this problem here:
Brianna Ghey — Rest In Power
Offline
Probably a stupid suggestion...
There is a ready Devuan with TDE https://exegnulinux.net/
Works without problems.
Might be easier to install?
Offline
I'm on Chimaera & an upgrade included git just now (minutes earlier). However, no idea if that will have fixed *your* problem.
Offline
Probably a stupid suggestion...
There is a ready Devuan with TDE https://exegnulinux.net/
Works without problems.
Might be easier to install?
TDE was installed in 2015, when i migrated to SSD-s and switched to Debian 7 from Ubuntu 10.04. Since then i just update it without problems. But seriously, what has TDE do with git being unable to connect?
But thanks for the tip, i did not know about that distro.
I'm on Chimaera & an upgrade included git just now (minutes earlier). However, no idea if that will have fixed *your* problem.
The update came down here too, but nothing has changed unfortunately...
Offline
This Perl code
#!/usr/bin/perl
use strict;
use LWP::UserAgent;
my $token="";
my $uri = 'https://github.com/punesemu/puNES';
my $json => '{"username":"user","password":"pwd"}';
my $req = HTTP::Request->new('POST', $uri );
$req->header( 'Content-Type' => 'application/json');
$req->content( $json );
my $lwp = LWP::UserAgent->new;
my $message = $lwp->request( $req );
if ( $message->is_success ) {
my $token= $message->content;
print "\n Received POST Response:\n$token\n";
} else {
print "error code:", $message->code,"\n";
print "error message:", $message->as_string(), "\n";
}
gives back 403, because of cookies. Stupid question, but this cannot be the reason behind git's hanging, right?
error code:403
error message:HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Connection: close
Date: Sun, 29 Jan 2023 23:51:36 GMT
Server: GitHub.com
Vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame
Vary: Accept-Encoding, Accept, X-Requested-With
Content-Type: text/plain; charset=utf-8
Client-Date: Sun, 29 Jan 2023 23:51:40 GMT
Client-Peer: 140.82.121.3:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
Client-SSL-Cipher: TLS_AES_128_GCM_SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_3
Client-Transfer-Encoding: chunked
Content-Security-Policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com objects-origin.githubusercontent.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events *.actions.githubusercontent.com wss://*.actions.githubusercontent.com online.visualstudio.com/api/v1/locations github-production-repository-image-32fea6.s3.amazonaws.com github-production-release-asset-2e65be.s3.amazonaws.com insights.github.com wss://alive.github.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com objects-origin.githubusercontent.com; frame-ancestors 'none'; frame-src viewscreen.githubusercontent.com notebooks.githubusercontent.com; img-src 'self' data: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com identicons.github.com avatars.githubusercontent.com github-cloud.s3.amazonaws.com objects.githubusercontent.com objects-origin.githubusercontent.com secured-user-images.githubusercontent.com/ opengraph.githubassets.com github-production-user-asset-6210df.s3.amazonaws.com customer-stories-feed.github.com spotlights-feed.github.com *.githubusercontent.com; manifest-src 'self'; media-src github.com user-images.githubusercontent.com/ secured-user-images.githubusercontent.com/; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; worker-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Set-Cookie: _gh_sess=E%2FXP3lgu582cURwnByOLH4bQXxdIustR7%2BLLYoM8LvAsVLIZ6J%2FwP2xKdOdXTdOT7bSQvwHRfZDdwgKVWZ83aM5Tw4jD4hgvuWw4FJipikDAIBfx7bIRxDT%2BHu%2B6v3mPD%2BpbnezQkJHXBDFzHCln2cBx%2FfnjdjDu%2Buw7%2Fa1X7%2FIcl%2BIYKDM79mNnYmkL8VZCiJPwJw%3D%3D--ttDckMfA7a%2BcG5o7--ijrpO2QavxKMiStaaoG1Mw%3D%3D; path=/; secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-GitHub-Request-Id: D87C:9AD5:1EDD5F5:202975C:63D70688
X-XSS-Protection: 0
Cookies must be enabled to use GitHub.
Offline
@TCH
"...But seriously, what has TDE do with git being unable to connect? big_smile..."
I have no idea.
In my experience, this is often the easiest and fastest way to get a working system.
I don't need the source codes, just out of curiosity I installed git now and entered your command, here is the result. This is the same exegnu.
Offline
Okay, but i am trying to figure out why does it not work here and the desktop is definitely not related.
Offline
This Perl code
Is unrelated to Git.
gives back 403, because of cookies. Stupid question, but this cannot be the reason behind git's hanging, right?
No, because it's about GitHub not Git, and I'm fairly sure a 4xx response would not cause Git to hang - it'd fail with an error message.
What does this give:
curl -isS --user-agent 'git/2.30.2' 'https://github.com/punesemu/puNES/info/refs?service=git-upload-pack' | head -n20
If it fails, add --insecure --verbose --trace-time options and try again.
Does git clone work if you bypass network (i.e. git clone file:///path/to/local/repo.git/ repo_copy)?
Have you tried cloning using ssh and/or git protocols?
3.1415P265E589T932E846R64338
Offline
What does this give:
curl -isS --user-agent 'git/2.30.2' 'https://github.com/punesemu/puNES/info/refs?service=git-upload-pack' | head -n20
Seemed to work:
HTTP/2 200
server: GitHub Babel 2.0
content-type: application/x-git-upload-pack-advertisement
content-security-policy: default-src 'none'; sandbox
expires: Fri, 01 Jan 1980 00:00:00 GMT
pragma: no-cache
cache-control: no-cache, max-age=0, must-revalidate
vary: Accept-Encoding
x-frame-options: DENY
x-github-request-id: 7BC6:F3A2:793EB:7E41E:63D80EDE
001e# service=git-upload-pack
000001564084bf80b5ad067b53f3cc1bbe27de67c3abf248 HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed allow-tip-sha1-in-want allow-reachable-sha1-in-want no-done symref=HEAD:refs/heads/master filter object-format=sha1 agent=git/github-g6d81313a33fa
0044a00279228de64ea6f4548fad29e70c74cef56e12 refs/heads/l10n_master
003f4084bf80b5ad067b53f3cc1bbe27de67c3abf248 refs/heads/master
003d6fe668a8f4905bf421ff0fc32a74e1ce9531ae38 refs/heads/n163
004024842b0bed29f83d35649d80853efcdd6b5c7140 refs/pull/106/head
00408bd8e2d12e8f649dcb8f844b8329b29b41fc094f refs/pull/107/head
0040ef88fa7f38f500f56f53201ea5e928b32053242d refs/pull/109/head
00400c55cad3f8c4f0d0fa20edb000ba47872236b1cd refs/pull/110/head
Does git clone work if you bypass network (i.e. git clone file:///path/to/local/repo.git/ repo_copy)?
Good idea: yes, it does.
# git clone file:///tmp/rohadjmeg/
Cloning into 'rohadjmeg'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
So the problem is not with git itself.
Have you tried cloning using ssh and/or git protocols?
git, yes, and it failed too:
# GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone --verbose git://github.com/punesemu/puNES
19:43:40.388930 git.c:444 trace: built-in: git clone --verbose git://github.com/punesemu/puNES
Cloning into 'puNES'...
Looking up github.com ... done.
Connecting to github.com (port 9418) ...
ssh, not until now, because i've never tried that before. I made now an RSA key for github, put it unto github's keystore and then tried to clone, which worked like a charm.
# git clone git@github.com:punesemu/puNES.git
Cloning into 'puNES'...
Warning: Permanently added the ECDSA host key for IP address '140.82.121.4' to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_rsa':
remote: Enumerating objects: 36949, done.
remote: Counting objects: 100% (1937/1937), done.
remote: Compressing objects: 100% (744/744), done.
remote: Total 36949 (delta 1318), reused 1787 (delta 1189), pack-reused 35012
Receiving objects: 100% (36949/36949), 89.59 MiB | 3.12 MiB/s, done.
Resolving deltas: 100% (26825/26825), done.
So, it is not a git + network issue either.
Thanks for this tip, now even if git still refuses to work with HTTPS, i can clone with SSH. (But it would be good, if i would not need authentication at all.)
Last edited by TCH (2023-01-30 19:30:55)
Offline
Up. Any ideas, why git is unable to clone via HTTPS? SSL config misery? Certificate problem?
Offline
If Curl needs the --insecure option then it's a certificate issue, otherwise that's probably fine.
If you repeat the Curl command but force HTTP/1.1 with --http1.1 does it make any difference? (I doubt it, but worth ruling out.)
Have you tested non-GitHub URLs, e.g. from git.kernel.org - there's lots of sizable repos there, but https://git.kernel.org/pub/scm/docs/man-pages/website.git/ is only 0.5MB
If that works, I would guess you may have something configured that makes GitHub want to login, e.g. check git config --list | grep github
If it doesn't... is testing with a newer Git from backports an option?
3.1415P265E589T932E846R64338
Offline
SSL config misery?
Maybe try curl with the key " k"?
curl -k https://your_link.com
It can be read here
curl --help all
Or https://reqbin.com/req/c-bw1fsypn/curl-ssl-request
P.S.In my case, the command works without this key, an ssl connection is created.
From what you can see, my system has no repository
http://devuan.bio.lmu.de/merged chimaera/main i386 Packages
Last edited by aluma (2023-02-02 18:14:43)
Offline
If Curl needs the --insecure option then it's a certificate issue, otherwise that's probably fine.
It did not needed at all. (But worked with it too.)
If you repeat the Curl command but force HTTP/1.1 with --http1.1 does it make any difference? (I doubt it, but worth ruling out.)
Nope:
HTTP/1.1 200 OK
Server: GitHub Babel 2.0
Content-Type: application/x-git-upload-pack-advertisement
Content-Security-Policy: default-src 'none'; sandbox
Transfer-Encoding: chunked
expires: Fri, 01 Jan 1980 00:00:00 GMT
pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Vary: Accept-Encoding
X-Frame-Options: DENY
X-GitHub-Request-Id: C40A:E39A:2B95636:2CFC693:63DC3B0F
001e# service=git-upload-pack
000001564084bf80b5ad067b53f3cc1bbe27de67c3abf248 HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed allow-tip-sha1-in-want allow-reachable-sha1-in-want no-done symref=HEAD:refs/heads/master filter object-format=sha1 agent=git/github-gb0b8bfc075bf
0044a00279228de64ea6f4548fad29e70c74cef56e12 refs/heads/l10n_master
003f4084bf80b5ad067b53f3cc1bbe27de67c3abf248 refs/heads/master
003d6fe668a8f4905bf421ff0fc32a74e1ce9531ae38 refs/heads/n163
004024842b0bed29f83d35649d80853efcdd6b5c7140 refs/pull/106/head
00408bd8e2d12e8f649dcb8f844b8329b29b41fc094f refs/pull/107/head
0040ef88fa7f38f500f56f53201ea5e928b32053242d refs/pull/109/head
Have you tested non-GitHub URLs, e.g. from git.kernel.org - there's lots of sizable repos there, but https://git.kernel.org/pub/scm/docs/man-pages/website.git/ is only 0.5MB
Yes, git hangs on all servers.
If that works, I would guess you may have something configured that makes GitHub want to login, e.g. check git config --list | grep github
This command gave back nothing.
If it doesn't... is testing with a newer Git from backports an option?
I'll try it tomorrow, thanks for the tip.
SSL config misery?
Maybe try curl with the key " k"?
curl -k https://your_link.com
It can be read here
curl --help all
Or https://reqbin.com/req/c-bw1fsypn/curl-ssl-request
P.S.In my case, the command works without this key, an ssl connection is created.
From what you can see, my system has no repositoryhttp://devuan.bio.lmu.de/merged chimaera/main i386 Packages
Curl works. With, or without the -k argument.
Offline
fwiw, git clone https://github.com/punesemu/puNES works fine here.
Offline
Pretty sure this is caused by the OP running a FrankenDevuan system. See the daemonforums thread for full details.
Brianna Ghey — Rest In Power
Offline
I have the same opinion.
From experience, usually nothing good comes of it.
That's why I suggested reinstalling.
Offline
@ralph.ronnquist:
I've tried the git in backports, but to no avail.
Pretty sure this is caused by the OP running a FrankenDevuan system. See the daemonforums thread for full details.
By adding the repositories of TDE, LLVM and Mono, i've made a FrankenDevuan system? How TDE, LLVM or Mono is related to git? What packages they could install which results in git being unable to pull stuff via HTTPS? How is a bunch of desktop applications, a C compiler and some dotnet libraries can do that? And why did not they do this with Debian 7, Debian 8 and Devuan 2?
Last edited by TCH (2023-02-03 14:01:47)
Offline
Okay, i've solved it.
I've started to look around GNUTLS packages and i've found an old GNUTLS packages from Debian 8: libgnutls-deb0-28. Tried to remove it and much to my surprise, i could not, because half of the system would gone with it. I did apt-cache rdepends libgnutls-deb0-28 --installed and i've ran into the solution. The cause was librtmp1. It was not upgraded neither when i was upgrading from Debian 8 to Devuan 2, nor when i was upgrading from Devuan 2 to 3 and from 3 to 4. Because it was some kind of backported version of Debian 8's librtmp1 which had a higher version number than any of the later Debian/Devuan versions. Well, it actually had a lower one than Devuan 4's version, but due to a different - a higher - ASCII character separating the equivalent version number from the lower date, APT thought, it was actually higher.
So, the solution was to downgrade the older package to the newer, from 2.4~20150315.gita107cef9b-dmo1+deb8u2 to 2.4+20151223.gitfa8646d.1-2+b2. Now git works perfectly.
Thanks, everyone.
Last edited by TCH (2023-02-03 13:40:05)
Offline
That librtmp1 package is not from Debian or Devuan. It is listed in that "damage.log" you posted over at daemonforums.org and it was from one of those crappy third party repositories.
So if you had done what I told you to:
You can try removing all of the stuff installed from those repositories to see if that fixes git. Given that git works fine in the "pure" live environment I would expect that to be the case. Good luck!
Then you wouldn't have wasted everybody's time and effort here...
Last edited by Head_on_a_Stick (2023-02-03 15:18:09)
Brianna Ghey — Rest In Power
Offline
After reading this thread, my head hurts and I want to down a gallon of Pinot Grigio.
I have been Devuanated, and my practice in the art of Devuanism shall continue until my Devuanization is complete. Until then, I will strive to continue in my understanding of Devuanchology, Devuanprocity, and Devuanivity.
Veni, vidi, vici vdevuaned. I came, I saw, I Devuaned.
Offline
That librtmp1 package is not from Debian or Devuan. It is listed in that "damage.log" you posted over at daemonforums.org and it was from one of those crappy third party repositories.
So if you had done what I told you to:
I wrote:You can try removing all of the stuff installed from those repositories to see if that fixes git. Given that git works fine in the "pure" live environment I would expect that to be the case. Good luck!
Then you wouldn't have wasted everybody's time and effort here...
First, when i said "from Debian 8", i mean't my old Debian 8 system, not the Debian 8 repo.
Second, it came from a third party repo which was removed from the system years ago and not from TDE, LLVM or Mono.
Third, damage.log contained a list of 1188 packages. You really did not think that removing them one by one and testing if git becomes alive is a viable option, did you? Not mentioning time, it contained tons of programs i use. Therefore what you've told me to do was simply could not be done.
Last edited by TCH (2023-02-03 21:00:09)
Offline
damage.log contained a list of 1188 packages
Yeah, good luck with all the other bugs and issues induced by those that you have yet to discover
Brianna Ghey — Rest In Power
Offline
Why, thank you. I'd say, i'll be back with them, but i do not want to waste anyone's time and if i could solve this, i may solve those too.
Offline
Head_on_a_Stick wrote:That librtmp1 package is not from Debian or Devuan. It is listed in that "damage.log" you posted over at daemonforums.org and it was from one of those crappy third party repositories.
So if you had done what I told you to:
I wrote:You can try removing all of the stuff installed from those repositories to see if that fixes git. Given that git works fine in the "pure" live environment I would expect that to be the case. Good luck!
Then you wouldn't have wasted everybody's time and effort here...
First, when i said "from Debian 8", i mean't my old Debian 8 system, not the Debian 8 repo.
Second, it came from a third party repo which was removed from the system years ago and not from TDE, LLVM or Mono.
Third, damage.log contained a list of 1188 packages. You really did not think that removing them one by one and testing if git becomes alive is a viable option, did you? Not mentioning time, it contained tons of programs i use. Therefore what you've told me to do was simply could not be done.
Btw, you do know that your username isn't how they spell that drug right?
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline