On 4/25/24 10:43, Simon Josefsson wrote:
https://gitlab.com/gsasl/inetutils/-/jobs/6706396721
That's an malloc failure on the server side. The savannah admins should
be told about the issue soon after it happens. Routine clones of GNU
projects shouldn't fail like that. (It's never happened to me, but then
I don't clone from Savannah all that often - maybe Savannah is giving
less server memory to clients that seem to hog?)
Btw, using --depth 1 is incompatible with gnulib's git-version-gen
We could fix that by not requiring git-version-gen for the Gnulib
submodule. git-version-gen is pretty useless for that anyway, as for
Gnulib it currently outputs a string like "0.1.7513-648ae" which is not
much more useful than the commit ID
"648aeb575db7af9ddd51cf17d1b56ee91e9ef3c5".
Isn't the real problem that we don't put (for example) gzip's own
commit ID into the coreutils tarball? If we did that, Gnulib's commit
ID would come for free, since it can be derived from gzip's commit ID.
I suppose you meant s/coreutils/gzip/
Yes, sorry.
SHA1 git
commits aren't long-term stable either, since SHA1 is broken
As you say, they're good enough for now. And anyway I would think SHA1
is good enough longer term unless an adversary infects your Git
repository (and in that case you probably have bigger problems...).
