-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Colin and Gnulib maintainers
I was considering to update the Gnulib translation (which seems to be
partially included in man-db), but after a closer look at the Gnulib
sources, no translation seems to be shipped anymore, so I wonder if it
is wort
Paul Eggert wrote:
> I'll CC: this to bug-gnulib, as it raises the more-general issue
> of why we ever put gnulib's .h files into lib_SOURCES.
Ralf Wildenhues answered this question on 2011-01-12 [1]:
"things like 'make tags ctags cscope' etc. look at all _SOURCES files."
I never use these tar
On 05/07/11 02:35, Eli Zaretskii wrote:
> As result of recent changes in the lib/ subdirectory,
> autogen/Makefile.in (which reflects changes in lib/Makefile.in at
> least on some Posix platform) acquired the following strange change:
>
> +am__libgnu_a_SOURCES_DIST = allocator.c careadlinkat.c
On 05/07/2011 05:32 PM, Bruno Haible wrote:
So, my vote for the license of libposix would be LGPLv3+ | GPLv2+.
For that I agree.
However, relicensing-wise, the best path to achieving this, is to first
ensure that all gnulib modules meant for libposix are LGPLv2+. Then
libposix can be distri
Eric Blake wrote:
> In fact, given the earlier question about libposix (should it
> be LGPLv2+ or LGPLv3+), we may be repeating our line of questioning.
Paolo Bonzini wrote:
> In fact, shouldn't we aim at LGPLv2+ for libposix, since that's the
> glibc license?
Because of the known advantages of
On 05/05/2011 10:48 AM, Jim Meyering wrote:
Bruce Korb wrote:
...
Is it a "small" thing if a half dozen engineers spend days
exchanging emails trying to figure it out? Not so small to me.
Fortunately, this doesn't happen often, and once it does for a given
module, it's not likely to happe
On 05/05/2011 07:23 AM, Gary V. Vaughan wrote:
This makes it a lot easier to distribute software through Apple's
various AppStore channels under the more onerous terms they impose,
while still having the freedom to share the actual code under the
GPL.
I'm afraid this would only be a Pyrrhic vic
Hi Simon,
The macro gl_PREREQ_GC in m4/gc.m4 is nowhere invoked in gnulib and also not
needed, because none of the files lib/gc.h, lib/gc-libgcrypt.c, lib/gc-gnulib.c
uses the 'restrict' keyword.
I guess this macro could just be removed?
Bruno
--
In memoriam The victims of the Skelani massacre
Eric Blake wrote:
> * modules/fclose (Depends-on): Add fflush.
Now that 'fclose' depends on 'fflush', an m4_ifdef is not necessary any more:
2011-05-07 Bruno Haible
fclose: Simplify autoconf macro.
* m4/fclose.m4 (gl_FUNC_FCLOSE): Assume gl_FUNC_FFLUSH_STDIN is
define
Hi Eric,
> For reference, here is libvirt's custom generator:
>
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=daemon/remote_generator.pl;h=062ccc1;hb=d3c5104
>
> And here's the generated file it produced, just before we removed it
> from libvirt.git:
>
> http://libvirt.org/git/?p=libvirt.git
10 matches
Mail list logo
