[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

libgnutls-deb0-28 missing from Debian repos - Re: git clone https://... fails, git://... succeeds — ?



On Wed, Jul 11, 2018 at 01:37:44PM +0200, john doe wrote:
> On 7/11/2018 12:37 PM, Zenaan Harkness wrote:
> > On Wed, Jul 11, 2018 at 11:32:30AM +0200, john doe wrote:
> > > On 7/11/2018 11:12 AM, Zenaan Harkness wrote:
> > > > Anyone know why git is failing to clone with the HTTPS protocol (but
> > > > succeeds with the git protocol)?
> > > > 
> > > > Example:
> > > > 
> > > > $ git clone https://github.com/gnubee-git/GnuBee_Docs.git docs.gits
> > > > Cloning into 'docs.gits'...
> > > > fatal: unable to access
> > > > 'https://github.com/gnubee-git/GnuBee_Docs.git/': gnutls_handshake()
> > > > failed: Public key signature verification has failed.
> > > > 
> > > > 
> > > > whereas:
> > > > 
> > > > $ git clone git://github.com/gnubee-git/GnuBee_Docs.git docs.gits
> > > > Cloning into 'docs.gits'...
> > > > remote: Counting objects: 1218, done.
> > > > remote: Compressing objects: 100% (29/29), done.
> > > > ...
> > > > 
> > > 
> > > It is working fine here:
> > > 
> > > $ git clone https://github.com/gnubee-git/GnuBee_Docs.git docs.gits
> > > Cloning into 'docs.gits'...
> > > remote: Counting objects: 1218, done.
> > > remote: Compressing objects: 100% (29/29), done.
> > > remote: Total 1218 (delta 16), reused 31 (delta 11), pack-reused 1178
> > > Receiving objects: 100% (1218/1218), 872.28 MiB | 11.39 MiB/s, done.
> > > Resolving deltas: 100% (288/288), done.
> > > Checking out files: 100% (510/510), done.
> > > 
> > > Maybe:
> > > 
> > > https://superuser.com/questions/1250527/git-clone-stopped-working
> > 
> > OK so that page suggests reinstalling package libgnutls-deb0-28
> > BUT, that package is not in the archives for Debian stable:
> > 
> > https://packages.debian.org/search?keywords=libgnutls-deb0-28

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why is this package missing from the repos, but installed in my
stretch install?

This also looks like a core security-type package, so, concerning!



> > shows that it's only available in wheezy-backports, jessie
> > (oldstable) and sid (unstable) as a debports port for arm64.
> > 
> > So the file
> > pool/main/g/gnutls28/libgnutls-deb0-28_3.3.8-6+deb8u7_amd64.deb
> > 
> > is in the archives, but not listed as a stable/stretch package.
> > 
> > Interestin. Given it's apparently not in stretch, perhaps I should
> > simply uninstall it:
> > 
> 
> Note that I'm also on stretch.
> Looks like something is broken on your end.

Well that's the question - how do I figure out the problem?

Perhaps there's some dodgy Debian mirroring going on?

Again, when I look at that packages.debian.org link above, the
package no longer exists in stable, so how can it be that over 100
other packages recursively depend on this package, when it's missing?

Hopefully someone can steer me in the right debugging direction...



> > I clone in 2 ways: --mirror for those repositories I am initially
> > keeping an archive for, and regular clone for those I want to
> > immediately look at.
> > 
> > In order to automate updates to these repos, I use this dir-name
> > convention to simply my scripts:
> > 
> >   - .gitm for --mirror (--bare) repos
> >   - .gits for regular "source checked out/ work dir" repos
> > 
> 
> I would rework the script to handle something like:
> 
> docs-mirror.git
> docs-bare.git
> docs
> 
> http://blog.plataformatec.com.br/2013/05/how-to-properly-mirror-a-git-repository/
> 
> Note that '--mirror' implies '--bare'; mirror and bare are two different things.:
> 
> https://git-scm.com/docs/git-clone

Thank you for the links.

For a given repo, I only have one primary clone or mirror. I have
various such local repos.

For GnuBee docs (or any other repo) I only clone it once, either with
plain clone, or with --mirror, never both - once I have a --mirror
repo locally available, I then either:

 - clone it to a "working dir", or

 - browse it insitu with git-ls

Hope that makes sense...


Reply to: