Re: The "regex" module brings in GPLv3 code even with --lgpl

On 05/08/2017 12:09 PM, Bruno Haible wrote: It is perfectly OK to do compile-time verifications in a non-tests module. Thanks, in hindsight the change isn't needed for Gnulib. However, the change also helps in another thing I'd like, which is to encourage the use of intprops.h in glibc intern

Re: The "regex" module brings in GPLv3 code even with --lgpl

Ævar Arnfjörð Bjarmason wrote: > > When you use the --lgpl option to gnulib-tool, it should replace the > > copyright headers of the files accordingly. If not, that's a bug in > > gnulib-tool. > > That wasn't happening in the latest gnulib.git today: > > ---cut--- > $ rm -rf /tmp/rx.tmp; ./gnul

Re: The "regex" module brings in GPLv3 code even with --lgpl

Hi Paul, The modules argmatch count-leading-zeros c-vasnprintf dfa exclude fma fmaf fmal ino-map i-ring malloca mbrtowc mbsinit mktime nanosleep parse-datetime pipe2 relocatable-prog-wrapper sleep stat strerror strtoimax strtoumax unistdio/u8-u8-vasn

Re: The "regex" module brings in GPLv3 code even with --lgpl

On Mon, May 8, 2017 at 8:22 PM, Bruno Haible wrote: > Hi Ævar, > >> The regex.c module depends on regex_internal.h, which depends on >> intprops.h, which depends on verify.h, which is GPLv3, not LGPL like >> the rest of the regex module. > > verify.h is under LGPLv2+. As described in >

Re: The "regex" module brings in GPLv3 code even with --lgpl

Hi Ævar, > The regex.c module depends on regex_internal.h, which depends on > intprops.h, which depends on verify.h, which is GPLv3, not LGPL like > the rest of the regex module. verify.h is under LGPLv2+. As described in the

Re: The "regex" module brings in GPLv3 code even with --lgpl

On Mon, May 8, 2017 at 7:39 PM, Paul Eggert wrote: > Thanks for reporting that. I installed the attached, which I hope fixes the > problem. Great, that looks much better than my monkeypatch & solves the problem. I.e. no GPLv3 header dependency anymore.

Re: The "regex" module brings in GPLv3 code even with --lgpl

Thanks for reporting that. I installed the attached, which I hope fixes the problem. From 624ac1a3466bba1e18215df3f91c6d581f7bcb55 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 8 May 2017 10:37:48 -0700 Subject: [PATCH] =?UTF-8?q?intprops:=20don=E2=80=99t=20depend=20on=20?= =?UTF-8?q?=E2

The "regex" module brings in GPLv3 code even with --lgpl

The regex.c module depends on regex_internal.h, which depends on intprops.h, which depends on verify.h, which is GPLv3, not LGPL like the rest of the regex module. I'm using the equivalent of the patch at the end of this E-Mail to import the engine into a GPLv2 only project, but this seems like a

Re: utimens: support for native Windows

Oops, I had verified the subsecond resolution support (through Cygwin's 'ls', as "ls -l --full-time") only for the case fd >= 0. For the case fd < 0, this patch adds the subsecond resolution support. 2017-05-07 Bruno Haible utimens: On native Windows, support 100ns resolution also if f

Re: utimens: support for native Windows

A small correction to this new code: 2017-05-07 Bruno Haible utimens: Improve error code on native Windows. * lib/utimens.c (fdutimens): If fd was not opened with O_RDWR, fail with error code EACCES, not EINVAL. diff --git a/lib/utimens.c b/lib/utimens.c index 5f3a846.