|
| From: | Paul Eggert |
| Subject: | Re: GNULIB_REVISION |
| Date: | Thu, 25 Apr 2024 11:49:34 -0700 |
| User-agent: | Mozilla Thunderbird |
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...).
| [Prev in Thread] | Current Thread | [Next in Thread] |