Reuben Thomas wrote:
> On 1 May 2011 22:39, Reuben Thomas wrote:
>> On 30 April 2011 21:39, Reuben Thomas wrote:
>>>
>>> Great, will modify patch for that.
>>>
>>
>> Attached.
>
> Just noticed I failed to switch the name of README-release back to
> that from README-release.in in modules file; up
Reuben Thomas wrote:
> It's all over my Lua. Really, it should only be checking the comments.
> Since most programs that know (roughly) what comments are seem to be
> either compilers, code line counters or syntax colorers, I'm not sure
> what accurate-ish tool one could use for this, but it seems
It's all over my Lua. Really, it should only be checking the comments.
Since most programs that know (roughly) what comments are seem to be
either compilers, code line counters or syntax colorers, I'm not sure
what accurate-ish tool one could use for this, but it seems a pity
either to turn off thi
This fixes the fclose failures detected in the previous patch,
but only when the GPL fflush module is also in use. That is
because the need for behavior of resetting seekable input streams
is much less common, and the fix more complex. The LGPLv2+ test
for fclose() in isolation is relaxed to pass
POSIX requires that fclose() on seekable input streams rewind back
to the next byte not actually given to the application. Glibc fails
this test. See:
http://sourceware.org/bugzilla/show_bug.cgi?id=3746
http://sourceware.org/bugzilla/show_bug.cgi?id=12724
Likewise for FreeBSD.
Cygwin 1.7.9 and
In a non-GPL project, the last change to fclose dragged in
inappropriate modules.
* modules/fclose (Depends-on): Switch from fflush/fseeko to
simpler lseek.
* lib/fclose.c (rpl_fclose): Likewise.
Reported by Simon Josefsson.
Signed-off-by: Eric Blake
---
> > Would it be equivalent to do
> >
>
it seems like a good idea. AFAICS, url.h has many functions, which
probably are not useful to expose in a gnulib module. What functions do
you exactly need?
For the disk filesystem module of libgnudpf we would be using url_parse
(valid url checking), url_escape, url_scheme, url_
Anyone using EXIT_FAILURE needs to depend on stdlib, now that
the exit module is gone.
* modules/argmatch (Depends-on): Replace exit with stdlib.
* modules/copy-file (Depends-on): Likewise.
* modules/execute (Depends-on): Likewise.
* modules/exitfail (Depends-on): Likewise.
* modules/obstack (Depe
On 05/02/2011 12:47 AM, Simon Josefsson wrote:
> k...@freefriends.org (Karl Berry) writes:
>
>> FWIW, I also agree with just removing the module instead of trying to
>> ever-escalate warnings. My experience is that few people are likely to
>> deal with it until it becomes an error regardless of w
On 05/02/2011 08:40 AM, Eric Blake wrote:
>> ! @item
>> ! @code{fflush} on an input stream changes the position of the stream to the
>> ! end of the previous buffer, on some platforms: mingw.
>>
>> Likewise not relevant: the position of the stream is irrelevant in fclose().
>
> Yes it is. test-cl
Agreed to in
http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00055.html
* modules/freading (License): Relax LGPL version.
Signed-off-by: Eric Blake
---
Now pushed.
ChangeLog|5 +
modules/freading |3 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
On 05/02/11 03:25, Bruno Haible wrote:
The bug is that while sharutils does not use libtool, in src/Makefile.am
it uses $(LTLIBINTL) when it should use $(LIBINTL).
Fixed in source. Build under way. I'll re-release when I get the next
opportunity. Thank you all. Regards, Bruce
On 05/02/11 05:09, Gary V. Vaughan wrote:
>> example, it could be that (which intprops.h includes)
>> > redefines UINT_FAST8_MAX to the wrong value.
> That seems to me to be what is happening. Is this something that gnulib
> stdint.h can fix? It looks like a stupid mistake on the part of the
> H
On 05/01/2011 10:49 AM, Bruno Haible wrote:
> Does anyone see the reason for this dependency? Can something go wrong if I
> remove it?
>
> --- modules/fchdir.orig Sun May 1 18:48:07 2011
> +++ modules/fchdirSun May 1 18:47:44 2011
> @@ -15,7 +15,6 @@
> fcntl-h
> filenamecat-lgpl
> g
On 05/01/2011 04:21 AM, Bruno Haible wrote:
> Eric Blake wrote:
>> + /* We only need to flush the file if it is not reading or if it is
>> + seekable. */
>> + if ((!freading (fp) || fseeko (fp, 0, SEEK_CUR) == 0) && fflush (fp))
>
> Would it be equivalent to do
>
> if ((!freading (fp)
On 05/01/2011 04:38 AM, Bruno Haible wrote:
> In fact, the dependency on 'fflush' should not be needed, because the fixes
> of that module are not relevant here:
>
> ! Portability problems fixed by Gnulib:
> ! @itemize
> ! @item
> ! @code{fflush} followed by @code{fseek} or @code{fseeko}, applied
On 1 May 2011 22:39, Reuben Thomas wrote:
> On 30 April 2011 21:39, Reuben Thomas wrote:
>>
>> Great, will modify patch for that.
>>
>
> Attached.
Just noticed I failed to switch the name of README-release back to
that from README-release.in in modules file; updated patch attached.
--
http://r
On 05/01/2011 04:29 PM, Bastien ROUCARIES wrote:
Did you test if dup2 work for socket ?
According tohttp://www.suacommunity.com/dictionary/dup-entry.php
andhttp://blog.csdn.net/linlu11/archive/2008/06/06/2518571.aspx it
will need more work.
dup2 indeed may not work for a socket on Windows. I
On Mon, May 2, 2011 at 12:02 PM, Lorenzo Bettini
wrote:
> On 04/25/2011 06:36 PM, Bruno Haible wrote:
>>
>> Lorenzo Bettini wrote:
>>>
>>> on the manual I read
>>>
>>> "These Gnulib substitute header files rely on being already
>>> included. Furthermore must be the first include in every
>>> com
Hi Paul,
Thanks for following up.
On Sun, May 01, 2011 at 10:52:48AM -0700, Paul Eggert wrote:
> On 05/01/11 10:15, Gary V. Vaughan wrote:
> > $ cat ,t.c
> > #include
> > #include "intprops.h"
> > int main (int argc, char **argv) {
> > printf("%lu\n", (unsigned long) ULONG_MAX);
> > printf("
Howdy Bruce!
I notice that the latest sharutils relies on iconv.m4 and friends from
gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
But, these macros are assuming that you will link using libtool, which
knows how to translate -R arguments into -R/-rpath/-Wl,-rpath/-blibpath
etc
Hi Bruce,
On Sun, May 01, 2011 at 01:46:18PM +, Gary V. Vaughan wrote:
> I notice that the latest sharutils relies on iconv.m4 and friends from
> gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
> But, these macros are assuming that you will link using libtool, which
> knows
Gary V. Vaughan wrote:
> > I notice that the latest sharutils relies on iconv.m4 and friends from
> > gnulib to provide --with-libiconv-prefix and --with-libintl-prefix.
> > But, these macros are assuming that you will link using libtool,.
No, they don't. They define a variable for use with li
On 04/25/2011 06:36 PM, Bruno Haible wrote:
Lorenzo Bettini wrote:
on the manual I read
"These Gnulib substitute header files rely on being already
included. Furthermore must be the first include in every
compilation unit. This means that to all your source files and likely
also to all your t
24 matches
Mail list logo
