zapper wrote:

Btw, you do know that your username isn't how they spell that drug right?:)

Congratulations, you're the 1,000,000th person who made a joke about it; your prize is a bucket of footsmell.

Awesome! I could use a bucket of footsmell, it keeps away the dwarves!

Btw, you do know that your username isn't how they spell that drug right?:)

Congratulations, you're the 1,000,000th person who made a joke about it; your prize is a bucket of footsmell.

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?

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

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.

So if you had done what I told you to:

Then you wouldn't have wasted everybody's time and effort here...

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.

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?

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.)

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

Yes, git hangs on all servers.

This command gave back nothing.

I'll try it tomorrow, thanks for the tip.

Curl works. With, or without the -k argument.

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