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 t
On 4/25/24 10:00 AM, Paul Eggert wrote:
> Is there some way to cajole 'git clone' into using less memory, with a
> '--depth 1' or similar options? Cloning shallowly would clone Gnulib a
> lot faster, if you're cloning from a remote repository.
Maybe '--single-branch' would help too. If space is re
Paul Eggert writes:
> You raise several good points. A couple of quick reaction:
>
> On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
>
>> - the gnulib git submodule is huge. Not rarely I get out of memory
>>errors during 'git clone' in CI/CD jobs.
>
> First I've heard
You raise several good points. A couple of quick reaction:
On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
- the gnulib git submodule is huge. Not rarely I get out of memory
errors during 'git clone' in CI/CD jobs.
First I've heard of this problem (other than with G
Bruno Haible writes:
> Hi Simon,
>
>> you can ... via
>> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
>> needs. ...
>> [1]
>> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
>> [2] https://salsa.debian.org/auth-team/libntlm/-/tree/ma
Hi Simon,
> you can ... via
> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
> needs. ...
> [1]
> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
> [2] https://salsa.debian.org/auth-team/libntlm/-/tree/master/debian
I see GNULIB_REVISI
