I have a deeper set of followup changes I am working on for a post-4.3
release that rewrite the signal handling in GNU make, so that we do not do
any work in signal handlers other than setting flags. Today, far too much
is done in signal handlers resulting in a number of bugs about hangs etc.
(and
On Fri, 2020-01-03 at 02:42 -0500, Paul Smith wrote:
> A new release candidate for GNU make 4.3 is available now for download:
>
> 6b252188079b36d13e96d5527f8ca033 make-4.2.93.tar.lz
> 929d4d3a216c02d0d86eb379356f4d1c make-4.2.93.tar.gz
>
> You can obtain a copy from: https://alpha.gnu
Am 05.01.20 um 17:03 schrieb Paul Smith:
That is not the right URL; you want git://git.sv.gnu.org/gnulib (note the
/git subdirectory is removed).
When you use https: you need to use /git/gnulib after the hostname, but
when you use the git: protocol you just use /gnulib after the hostname.
Ups
On Sun, 2020-01-05 at 12:12 +0100, Christof Warlich wrote:
> Thus, everything looks perfectly fine so far. But the following still
> fails:
>
> > $ git ls-remote git://git.sv.gnu.org/git/gnulib
> > fatal: remote error: access denied or repository not exported:
> > /git/gnulib
That is not the righ
On Fri, 2020-01-03 at 22:19 -0500, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> This patch enhances error reporting from the test suite.
Thanks I applied this.
On Fri, 2020-01-03 at 23:30 -0500, Paul Smith wrote:
> On Fri, 2020-01-03 at 22:21 -0500, Dmitry Goncharov via Bug reports and
> discussion for GNU make wrote:
> > This patch replaced a c99 piece of code with c90 code.
> > This c99 piece of code does not compile with the default ./configure &&
> >
Am 04.01.20 um 21:55 schrieb Paul Smith:
Hm, this worked fine for me:
$ git ls-remote git://git.sv.gnu.org/gnulib
...list of branches...
Perhaps your system is sequestered behind some sort of firewall that will
not allow the git: protocol (port 9418 IIRC) to pass through? Almost all
f
