Hi Glenn,
> I'm thinking of replacing the current comment with
> something along the lines of:
>
> Git does not support cloning by commit hash. So attempt a shallow
> fetch by commit hash to minimize the amount of data downloaded and
> changes needed to be processed, which can drastically
Andy Moreton wrote:
> > Andy suggested a simple fix that I quoted here:
> >
> > https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
> >
> > We could apply that patch just to ntlib.c and just in emacs-28 (do not merge
> > to master) as Andy says that works for him;
>
> Yes, that minimal fix
Hi Bruno,
On Sat, 23 Oct 2021 00:20:32 +0200
Bruno Haible wrote:
> Hi Glenn,
>
> > The gnulib sources are large but more importantly have lots of changes. So
> > initial checkout of the repository can take a long time when network or
> > cpu resources are limited. The later is especially acute
> From: Óscar Fuentes
> Date: Sun, 24 Oct 2021 20:01:06 +0200
> Cc: bug-gnulib@gnu.org
>
> Paul Eggert writes:
>
> > I don't know why the
> > problem occurs only for GCC 11 on MS-Windows platforms, as I would
> > think it'd also occur with earlier GCC versions.
>
> Most likely the problem is
On Sun 24 Oct 2021, Paul Eggert wrote:
> On 10/24/21 9:58 AM, Eli Zaretskii wrote:
>> We could try all that, but not on the release branch. There, I'd like
>> a simple and safe fix. Is such a thing possible?
>
> Andy suggested a simple fix that I quoted here:
>
>
> Cc: andrewjmore...@gmail.com, bug-gnulib@gnu.org, emacs-de...@gnu.org
> From: Paul Eggert
> Date: Sun, 24 Oct 2021 13:05:32 -0400
>
> On 10/24/21 9:58 AM, Eli Zaretskii wrote:
> > We could try all that, but not on the release branch. There, I'd like
> > a simple and safe fix. Is such a thing
On 10/24/21 9:58 AM, Eli Zaretskii wrote:
We could try all that, but not on the release branch. There, I'd like
a simple and safe fix. Is such a thing possible?
Andy suggested a simple fix that I quoted here:
https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
We could apply that
> Cc: andrewjmore...@gmail.com, bug-gnulib@gnu.org, emacs-de...@gnu.org
> From: Paul Eggert
> Date: Sun, 24 Oct 2021 08:25:29 -0400
>
> > ntlib cannot include config.h,
> > due to various redefinitions and redirections we do in ms-w32.h for
> > Emacs.
>
> I now see Emacs has a symbol
On 10/24/21 6:50 AM, Andy Moreton wrote:
An alternative workaround in ntlib.c is to add the missing defines
before including :
#define _GL_ATTRIBUTE_MALLOC
#define _GL_ATTRIBUTE_DEALLOC_FREE
Although that works around this particular problem, it is vulnerable to
future changes in Gnulib that
On 10/24/21 2:26 AM, Eli Zaretskii wrote:
Let me turn the table and ask why that declaration of strdup is at all
needed in Gnulib's string.h when it's used in MinGW builds?
It's so that apps can be checked better statically. For example, the
contrived code:
return strcmp (x, strdup (x));
On Sun 24 Oct 2021, Eli Zaretskii wrote:
>> From: Paul Eggert
>> Date: Sat, 23 Oct 2021 23:45:04 -0400
>> Cc: bug-gnulib@gnu.org, emacs-de...@gnu.org
>>
>> On 10/23/21 4:42 PM, Andy Moreton wrote:
>> > Can this issue be addressed in gnulib so the emacs bug can be fixed ?
>>
>> This appears to
> From: Paul Eggert
> Date: Sat, 23 Oct 2021 23:45:04 -0400
> Cc: bug-gnulib@gnu.org, emacs-de...@gnu.org
>
> On 10/23/21 4:42 PM, Andy Moreton wrote:
> > Can this issue be addressed in gnulib so the emacs bug can be fixed ?
>
> This appears to be an issue in Emacs not Gnulib, as a few of
12 matches
Mail list logo
