Re: cycle-check: needs inline

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > The cycle-check module uses 'inline', therefore should make sure it's > supported > or defined away. Currently it leads to a failure like this, on Solaris 2.5.1 > with SunPRO C 5.0: > > cc -O -DHAVE_CONFIG_H -I. -I.. -g -c cycle-check.c >

Re: i-ring: needs stdbool

Bruno Haible <[EMAIL PROTECTED]> wrote: > The i-ring.h file includes . Therefore it should depend on > the 'stdbool' module. Currently it gives an error on Solaris 10 for example: > > cc -xarch=v9 -O -DHAVE_CONFIG_H -I. -I.. -g -c i-ring.c > "/usr/include/stdbool.h", line 42: #error: "Use of

adding bootstrap and bootstrap.conf

FYI, I've just added these two new files. * build-aux/bootstrap: New file. * build-aux/bootstrap.conf: New file, from coreutils. Variants of this bootstrap script are being used in at least 6 or 7 different projects, and having it here seems like the best way to keep everyone up t

FYI, savannah still down

In case you're wondering what's wrong with savannah.gnu.org, here's the word from IRC: URL: irc://irc.freenode.net/savannah Topic: The server for savannah.gnu.org has experienced 3 disk failures (out of 6) in 24 hours. Savannah was retrieved from the colocation to transfer the late

Re: adding bootstrap and bootstrap.conf

Bruno Haible <[EMAIL PROTECTED]> wrote: >> Variants of this bootstrap script are being used in at least 6 or >> 7 different projects, and having it here seems like the best way >> to keep everyone up to date. However there's plenty of room for >> improvement. > > Well, I'd suggest two improvements

Re: [PATCH] Specifying the name of the gnulib library.

"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: > this allows a user to specify the name of the gnulib library > (currently libPACKAGE) to something that they might prefer through > bootstrap.conf by setting the variable gnulib_name. In inetutils we > use libgnu for gnulib, and libinetutils.a for ou

Re: [PATCH] autopoint always run even though it might not be used

"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: ... >Please use "yes" and "no" for such values, or ":"/"true" and "false" >if you intend to use them as commands (as in `if $with_gettext'). "t" >is impossible to understand for those that don't speak the language this >idiom originated

bootstrap: fix HPUX/grep portability problem

* build-aux/bootstrap: Don't use \> in grep regexp. For HP-UX. Index: build-aux/bootstrap === RCS file: /cvsroot/gnulib/gnulib/build-aux/bootstrap,v retrieving revision 1.3 diff -u -p -r1.3 bootstrap --- build-aux/bootstrap

Re: [BUG] Check for AC_CONFIG_AUX_DIR is incorrect

"Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: > The check for AC_CONFIG_AUX_DIR is incorrect, since autoconf (really, > m4) allows one to quote arguments. So if ones configure.ac contains > the following valid code: > > AC_CONFIG_AUX_DIR([build-aux]) > > the check will fail. Not entierly sure how

Re: [BUG] Check for AC_CONFIG_AUX_DIR is incorrect

Jim Meyering <[EMAIL PROTECTED]> wrote: ... > +if test $found_aux_dir = no; then >{ > echo "$0: expected line not found in configure.ac. Add the following:" > >&2 > -echo " AC_CONFIG_AUX_DIR($build_aux)" >&2. > +echo &quo

Re: adding bootstrap and bootstrap.conf

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyring wrote: >> My impression is that few (if any) of the autogen scripts use gnulib > > The one gettext does. > >> there's another definition (the first one when I type "dict bootstrap") >> that is more evocative: to load and initialize the operatin

Re: warning in at-func.c

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > On MacOS X, we have this warning during the compilation of fchownat.c: > > at-func.c:39: warning: implicit declaration of function `lchown' > > The reason is that lchown() is not available on this system and therefore > not declared in . This pr

Re: adding bootstrap and bootstrap.conf

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: ... >> A missing feature: files supplied by gnulib-tool should be >> removed by "make maintainer-clean". If gnulib-tool doesn't >> do that soon, I'll be changing bootstrap to do it.

Re: adding bootstrap and bootstrap.conf

[EMAIL PROTECTED] (Karl Berry) wrote: > The only reason maintainer-clean typically has not removed files like > configure and Makefile.am is that they have been (until relatively > recently) version controlled. > > That doesn't seem quite right to me. Makefile.am is typically Whoops.

Re: --version output change proposal

[EMAIL PROTECTED] (Karl Berry) wrote: > rms and I have been batting around the --version output stuff. > Here's what we seem to be settling on: > > sort (GNU coreutils) 6.4 > Copyright (C) 2006 Free Software Foundation, Inc. > License GPLv2+: GNU GPL version 2 or later

Re: --version output change proposal

Simon Josefsson <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Karl Berry) writes: >> If any comments, let me know before we inscribe it into standards.texi ... > > I suppose lib/version.c in gnulib should be modified too? Yep, version-etc.c I'll wait a day or two, in case things change.

Re: add limited support for Solaris 10 ZFS-style ACLs to gnulib

Paul Eggert <[EMAIL PROTECTED]> wrote: > Sun has seriously rethought ACLs for Solaris 10 and ZFS. I installed > this first step at supporting them in gnulib; it's just enough to get > GNU 'ls' to work. I have tested this on Solaris 8, Solaris 10, and > Debian stable; I haven't tested it on a Linu

savewd.c: treat ESTALE like EACCES

I've just moved the following delta from coreutils to gnulib. It's useful when mkdir-p.c's make_dir_parents is called from a process with working directory on an NFS-mounted directory for which open fails with ESTALE. When trying to open ".", treat ESTALE like EACCES. * lib/savewd.

Re: --version output change proposal

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 3/19/2007 2:45 AM: >> Simon Josefsson <[EMAIL PROTECTED]> wrote: >>> [EMAIL PROTECTED] (Karl Berry) writes: >>>> If any comments, let me know before we inscribe it into standards.texi

Re: argp: listen to gcc warnings

Bruno Haible <[EMAIL PROTECTED]> wrote: > Eric Blake wrote: >> Rather than use lots of casts, coreutils does this in a common header: >> >> /* Convert a possibly-signed character to an unsigned character. This is >>a bit safer than casting to unsigned char, since it catches some type >>er

Re: gnulib support for st_birthtime (second revision of patch)

James Youngman <[EMAIL PROTECTED]> wrote: > 2007-03-27 James Youngman <[EMAIL PROTECTED]> > >* lib/stat-time.h (get_stat_birthtime): New function for > retrieving st_birthtime as provided by UFS2 (hence *BSD). >* m4/stat-time.m4 (gl_STAT_BIRTHTIME): Probe for st_birthtime

Re: group modules into subdirectories

Simon Josefsson <[EMAIL PROTECTED]> wrote: ... > I'm Cc'ing Jim because he is the owner of the md5 module. I believe > md5 is the only crypto-related module that I'm not the owner of. Jim, > are you ok with moving the md5 module to modules/crypto/ together with > the rest of the modules? Hi Simo

Re: gnulib ChangeLog split

Bruno Haible <[EMAIL PROTECTED]> wrote: > Karl Berry asked: >> The ChangeLog file is over a megabyte now, and I'm still stuck on dialup >> sometimes. Can we split it to, say, ChangeLog.1997-2006 and just keep >> 2007 in the active file? > > I believe that the size of the ChangeLog becomes insigni

Re: switching to git

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> A good argument for upgrading any cvs servers you control. > > Unfortunately, it's the clients that you would need to upgrade - it's the > GPLed 'cvs' client which pushes the load to th

Re: Issue with ls -v / sort -V and strverscmp() usage

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Kamil, >> New version of filevercmp.c is attached, now without copying of the input >> strings. I've also made a simple performance test - the speed was about 7-8x >> slower than original glibc strverscmp function, but the glibc's result is >> mostly wro

Re: [PATCH] add new module filevercmp

Kamil Dudka <[EMAIL PROTECTED]> wrote: > as it was mentioned in the thread at > http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00198.html I propose > new gnulib module filevercmp - in the attachment. ... Thanks for all that work! A few comments in-line: > From 842bccfc33b46570b73956e39be

fts: avoid O(n^2) ext3/ext4 performance hit on million+-entry dirs

patch also improves performance on reiserfs and xfs, but not on tmpfs. I've been using this on multiple systems via coreutils, and of course, it passes all of the tests there. I expect to push this tomorrow. >From 81cd6073dfc09d295f9cf0910cc29138f017f58d Mon Sep 17 00:00:00 2001 From: Jim

Re: fts: avoid O(n^2) ext3/ext4 performance hit on million+-entry dirs

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Thu, Sep 25, 2008 at 06:16:58PM CEST: >> --- a/lib/fts.c >> +++ b/lib/fts.c > >> +/* A comparison function to sort on increasing inode number. >> + For some file system types, sorting either

Re: fts: avoid O(n^2) ext3/ext4 performance hit on million+-entry dirs

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> +if (nitems > _FTS_INODE_SORT_DIR_ENTRIES_THRESHOLD >> +&& !sp->fts_compar >> +&& dirent_inode_sort_may_be_useful (sp)) { >> +sp->fts_compar =

Re: fts: avoid O(n^2) ext3/ext4 performance hit on million+-entry dirs

Jim Meyering <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>> + if (nitems > _FTS_INODE_SORT_DIR_ENTRIES_THRESHOLD >>> + && !sp->fts_compar >>> + && dirent_inode_sort_

Re: Changing module from LGPL to LGPLv2+

Bruno Haible <[EMAIL PROTECTED]> wrote: > Yoann Vandoorselaere wrote: >> would it be possible to change their license from LGPL to LGPLv2+? ... >> raise > > Jim? Sure. It's trivial.

Re: [PATCH] add new module filevercmp

Kamil Dudka <[EMAIL PROTECTED]> wrote: > On Wednesday 24 September 2008 22:52:00 Jim Meyering wrote: ... if (!strcmp (s1, s2)) >> > + int rc = verrevcmp (s1, s1_len, s2, s2_len); >> > + return (rc == 0) >> > +/* return 0 if (and only

Re: fts: avoid O(n^2) ext3/ext4 performance hit on million+-entry dirs

Jim Meyering <[EMAIL PROTECTED]> wrote: > Here is a patch that makes it so tools using fts, > like chmod, chown, chgrp, chcon, du, and find are no > longer susceptible to an O(n^2) performance penalty when > processing very large directory-entry counts (as in millions). >

Re: skipping message for vc-list-files tests

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > Eric reminded me that it is good practice to provide a message that explains > why a test is skipped. (When I did this in GNU gettext, it uncovered a couple > of real bugs on various systems.) Hi Bruno, Go ahead, but please correct (s/git/cvs/

Re: [PATCH] add new module filevercmp

Kamil Dudka <[EMAIL PROTECTED]> wrote: > thank you for review. I've made the changes you requested, new patch attached. Hi Kamil, I see a warning due to unnecessary test module dependent: $ ./gnulib-tool --dir /tmp/pm --create-testdir --with-tests --test filevercmp warning: module filevercmp

Re: [PATCH] add new module filevercmp

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> To have any hope of sanity/reproducibility in different locales, >> this function must return the same result, regardless of the current >> locale settings. > > Yes. In the opposite case, if the

Re: willing to contribute verrevcmp to gnulib?

Ben Pfaff <[EMAIL PROTECTED]> wrote: > Hi Ian. The GNU gnulib project is considering adding a function > that would compare strings in the same way that dpkg compares > version numbers, as you can see in the thread here: > http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/14693 > > Is

Re: willing to contribute verrevcmp to gnulib?

Ian Jackson <[EMAIL PROTECTED]> wrote: > Jim Meyering writes ("Re: willing to contribute verrevcmp to gnulib?"): >> Ben Pfaff <[EMAIL PROTECTED]> wrote: >> > Hi Ian. The GNU gnulib project is considering adding a function >> > that would c

Re: git warning about whitespace?

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi, > > Just saw this while performing a git operation: > > $ git rebase origin/master > First, rewinding head to replay your work on top of it... > Applying Propagate effects of putenv/setenv/unsetenv to child processes. > Applying A new test for

Re: willing to contribute verrevcmp to gnulib?

Ian Jackson <[EMAIL PROTECTED]> wrote: > Jim Meyering writes ("Re: willing to contribute verrevcmp to gnulib?"): >> Depending on the code: GPL, LGPL, LGPLv2+. >> For this function, LGPL or LGPLv2+ would be appropriate, >> since it's intended to replac

Re: [PATCH]: Do not allow countable dayshifts in getdate.y

Ondřej Vašík <[EMAIL PROTECTED]> wrote: > this patch for getdate.y module restricts usage of countable dayshifts > e.g. +40 tommorow ago, next yesterday etc. > Tests to gnulib getdate testsuite were added. > As this usage of dayshifts is quite insane, I guess no documentation for > it is required.

Re: tests cleanup

Simon Josefsson <[EMAIL PROTECTED]> wrote: > I ported Eric Blake's test-memchr.c fix to test-memrchr.c, and fixed > another minor bug in test-getdate.c. This fixed the two warnings that > are easy to fix on: > > http://autobuild.josefsson.org/gnulib/log-200809290932420171000.txt > > The rest are w

Re: printf("%.0f", 0.5) and round-to-even

Eric Blake <[EMAIL PROTECTED]> wrote: > An interesting question popped up on the bug-gnu-utils list: > http://lists.gnu.org/archive/html/bug-gnu-utils/2008-09/msg00055.html > > POSIX states that with %f, the low-order digit is rounded in an > implementation- > defined manner. However, since 0.5 i

[PATCH] fts.m4: correct the test for statfs.f_type

I noticed that the configure-time test for the f_type member of struct statfs was failing on some systems. It didn't include . I've pushed the obvious fix: >From af791bcb46dd123f336f10c05d8fbb708e2022a2 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Tue

[PATCH] fts.c: adjust a new interface to be more generally useful

I'm preparing to pull this code out into its own module, since it's already used by coreutils' remove.c. >From 2c65e30590ff468ad1e94df2c30ca4bfa9ce98d5 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 1 Oct 2008 09:22:11 +0200 Subject: [PA

Re: [PATCH] fts.m4: correct the test for statfs.f_type

Bruno Haible <[EMAIL PROTECTED]> wrote: >> I noticed that the configure-time test for the f_type member >> of struct statfs was failing on some systems. >> >> It didn't include . >> I've pushed the obvious fix: > > This introduces a regression on HP-UX. > > The use of HAVE_STRUCT_STATFS_F_TYPE is p

Re: [PATCH] Implementation of fsync for Windows

Hi Rich, To make gnulib-tool's --with-tests option work, you can add this to your change set: >From ac7caea063e546b0c99cf7a11947837ea7490b90 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Wed, 1 Oct 2008 17:52:17 +0200 Subject: [PATCH] add fsync tests --- modu

Re: [PATCH] Implementation of fsync for Windows

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > Like the earlier patch, but this relicenses to LGPLv2+, includes > license text, and assigns everything to the FSF. This looks fine. Thanks, Rich. I'll wait for feedback, then push tomorrow morning.

Re: [PATCH] Implementation of fsync for Windows

Eric Blake <[EMAIL PROTECTED]> wrote: > Richard W.M. Jones redhat.com> writes: >> Like the earlier patch, but this relicenses to LGPLv2+, includes >> license text, and assigns everything to the FSF. > > Do you have copyright on file for gnulib yet? No. Technically he doesn't need it, since the wo

Re: [PATCH] Implementation of fsync for Windows

Eric Blake <[EMAIL PROTECTED]> wrote: > Richard W.M. Jones redhat.com> writes: >> Like the earlier patch, but this relicenses to LGPLv2+, includes >> license text, and assigns everything to the FSF. Addressing Eric's feedback, and tweaking copyright and a comment, FYI, this is the incremental I'm

Re: [PATCH] Implementation of fsync for Windows

Jim Meyering <[EMAIL PROTECTED]> wrote: > Eric Blake <[EMAIL PROTECTED]> wrote: >> Richard W.M. Jones redhat.com> writes: >>> Like the earlier patch, but this relicenses to LGPLv2+, includes >>> license text, and assigns everything to the FSF. &g

fts: bug fixes

This propagates a change from coreutils and also fixes a typo in fts.m4: diff --git a/lib/fts.c b/lib/fts.c index 95d0c7a..a55a98d 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -934,8 +934,8 @@ fts_children (register FTS *sp, int instr) return (sp->fts_child); } -#if defined HAVE_SYS_VFS_H &

[PATCH] fts.c: sync with similar code from coreutils' remove.c

FYI. This also fixes the stub parameter type. >From ada9b2b3b470ec372e521ee2c1f82f8bc87b1e0a Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Thu, 2 Oct 2008 10:00:46 +0200 Subject: [PATCH] fts.c: sync with similar code from coreutils' remove.

Re: [PATCH] fts.m4: correct the test for statfs.f_type

Bruno Haible <[EMAIL PROTECTED]> wrote: >> If someone is interested enough to time things on HP-UX >> and finds that there's a file system type (probably memory backed) >> that it'd be good to exempt, then it might be worthwhile to >> pursue this. > > I didn't mean to discuss for which filesystems

filevercmp: worth pursuing formal copyright assignment ?

Hi Bruno, You're the one who started this ;-) so I have to ask: Do you really think getting a formal assignment from anyone for such a small function (that's already been GPL'd for so long) is necessary? There is precedent with the *l.c math functions, which are copyright by Stephen L. Moshier and

Re: [RFH] macro ordering problems in sed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Hi all, git sed gives this problem when running "sh autoboot": > > configure.ac:17: warning: AC_COMPILE_IFELSE was called before AC_GNU_SOURCE > ../../lib/autoconf/specific.m4:331: AC_GNU_SOURCE is expanded from... ... > > Can anyone help? Also, I would l

Re: Preliminary patch for flock (just for discussion)

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > I have to go off and do something else this afternoon, but here is a > preliminary patch for flock support for Windows. It compiles with my > MinGW cross-compiler but I haven't really tested it properly yet. > > As you can see, it introduces anothe

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> >* lib/close-stream.c (close_stream): Ignore error EPIPE from fclose. >> > >> I know this condition arises only when ignoring or handling SIGPIPE, >> (which should be rather unusual) but e

Re: filevercmp: please post final filevercmp

c_isdigit, c_isalpha, c_isalnum directly; no need for casts - reword match_suffix comment - reword module description - s/0/NULL/ in test-filevercmp.c >From 44266b31e530ce198638700d401d9c589aa332a3 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Fri, 3 O

Re: filevercmp: please post final filevercmp

Kamil Dudka <[EMAIL PROTECTED]> wrote: > On Friday 03 of October 2008 09:55:40 Jim Meyering wrote: >> Please review these small changes that I expect to fold into your change >> set: - use c_isdigit, c_isalpha, c_isalnum directly; no need for casts - > Sorry, but I am

Re: filevercmp: please post final filevercmp

Kamil Dudka <[EMAIL PROTECTED]> wrote: > On Friday 03 of October 2008 09:55:40 Jim Meyering wrote: >> Please review these small changes that I expect to fold into your change >> set: - use c_isdigit, c_isalpha, c_isalnum directly; no need for casts - > Sorry, but I am

Re: c-ctype.h calling conventions

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> >> set: - use c_isdigit, c_isalpha, c_isalnum directly; no need for casts - >> > Sorry, but I am not sure here. ... >> >> Oops. You're right. >> While some of the uses are ok wit

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim, > >> Imagine a scenario in which the pipe reader is expected always to >> be reading, and so the pipe writer can expect that any write failure with >> errno==EPIPE indicates the reader has terminated unexpectedly. > > If the writer should terminate fi

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > EPIPE is part of the normal shutdown >> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE. >> >> First, you're assuming that the pipe writer chooses to &g

Re: c-ctype.h calling conventions

FYI, this might be the final iteration ;-) Here's the incremental, and following it, the combined patch: >From 5c26b63b1bd8aaf0bfaa275b884ff8b7edb4ce25 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Fri, 3 Oct 2008 11:51:55 +0200 Subject: [PATCH] tw

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>> Jim, >>> >>>> Imagine a scenario in which the pipe reader is expected always to >>>> be reading, and so the pipe writer can

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: > >>>>>> Imagine a scenario in which the pipe reader is expected always to >>>>>> be reading, and so the pipe writer can expect that any write failure with >>>>>

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> What else do you propose to cover these cases, if not a global variable? > > If only one behavior is needed across an entire package, a dummy module > with gl_MODULE_INDICATOR would do. Better than having fwriteerror do > one thing and close_stdout do a

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > ... if SIGPIPE is blocked or ignored. >> > >> >> which is not generally recommended. >> >> In some contexts. Some environments (mis-configured login/csh) have >> resulted

Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL

"Debarshi Ray" <[EMAIL PROTECTED]> wrote: >> Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as >> AM_PROG_LIBTOOL > > Wow! Thanks a lot. Will this make its way into build-aux/bootstrap of > Gnulib as well? That *was* for gnulib. I'm Cc'ing the right list this time. >> * build-aux/

Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Sun, Oct 05, 2008 at 01:01:14PM CEST: >> "Debarshi Ray" <[EMAIL PROTECTED]> wrote: >> >> Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as >> >> A

Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL

then use `$EGREP', and similarly for > `AC_PROG_FGREP' and `$FGREP'. > > In a script like this, where you cannot rely on AC_PROG_EGREP either, I would > just grep configure.ac twice, with two different basic regular expressions. Unfortunate, but true. Thanks. How a

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > You can distinguish close_stream and close_stdout. close_stream is library >> > code, >> > close_stdout is not. What about a 'bool ignore_epipe' that influences the >> > b

Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Unfortunate, but true. >> Thanks. How about this? >> ... >> +grep '^[ ]*A[CM]_PROG_LIBTOOL\>' configure.ac >/dev/null \ > > \> is also not a portable piece of

Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Sun, Oct 05, 2008 at 07:42:45PM CEST: >> Bruno Haible <[EMAIL PROTECTED]> wrote: >> > >> > \> is also not a portable piece of regular expression: not in a basic >> > re

Re: [PATCH] flock implementation (version 2)

"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > Thanks for the feedback. The updated version attached should correct > all those points. Thanks! I've merged in the patch below, adjusted the log message to have a blank line after the summary, and pushed the result. diff --git a/modules/flock-te

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: ... >> s/is/may be/ >> Early reader termination may still deserve a diagnostic. >> Or it could be that POSIX requires the application to diagnose EPIPE, >> regardless ;-) > > I disagree here.

Re: GNUmakefile: git-version-gen, maintainer-check, install

ersion" as the new target name? With that, GNUmakefile impinges less on the name space of all subsidiary Makefiles. >From 010ea87efb4115232ec12f11fc4aad4ecd1d2178 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Thu, 9 Oct 2008 10:35:37 +0200 Subject: [PATCH] G

bootstrap tweak

from 15M, I made it slightly more portable instead ] I've just pushed this: >From 19c0b3920532a8044490a03c6400c856520c3abb Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Fri, 10 Oct 2008 08:34:05 +0200 Subject: [PATCH] bootstrap: use git's --depth=N option o

Re: improvements to announce-gen user messages

Ben Pfaff <[EMAIL PROTECTED]> wrote: > Hi Jim. While attempting to use announce-gen for the first time > I discovered and fixed a couple of minor flaws in its user > interface. OK to push this to gnulib? > > commit f70e255e4db6200d6352ba794deb8d4f110461d5 > Author: Ben Pfaff <[EMAIL PROTECTED]> >

automatically preventing merge commits on master

Does anyone object to my installing a server-side hook that would prevent pushing merge commits on master? In our experience here (with gnulib.git), pushing a merge commit is always unintentional.

Re: automatically preventing merge commits on master

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> Does anyone object to my installing a server-side hook >> that would prevent pushing merge commits on master? >> In our experience here (with gnulib.git), pushing a mer

Re: automatically preventing merge commits on master

Jim Meyering <[EMAIL PROTECTED]> wrote: > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Jim Meyering <[EMAIL PROTECTED]> writes: >> >>> Does anyone object to my installing a server-side hook >>> that would prevent pushing merge commits on

Re: Warnings to be fixed

d unsigned type in conditional expression Thanks for the report. I've just addressed the first one above with this: [after confirming that openat.h is already listed in modules/openat-die] >From c590a4c86428649863b9b82be386747586e0 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTE

Re: Warnings to be fixed

Reuben Thomas <[EMAIL PROTECTED]> wrote: > Compiling with the Debian gnulib snapshot of 20081001, I am delighted > that I no longer get warnings about #include_next. (Un?)fortunately, > this enables me more easily to spot "real" warnings: ... > open-safer.c: In function ‘open_safer’: > open-safer.c

Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Eric Blake on 10/10/2008 7:15 AM: >>> I've wanted to get rid of "signal" uses for ages. >>> Are you interested in doing it? >> >> Yes, I'll tackle this. > > Round 2 begins with a question. src/install.c has the following use of > signal, needed

Re: Warnings to be fixed

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> mode = (sizeof (mode_t) < sizeof (int) >>? va_arg (ap, int) >>: va_arg (ap, mode_t));<<< line 43 >> >>

[PATCH] ignore-value: new module

I wanted to ignore some new warnings in coreutils, but a "(void)" cast no longer does the job with the latest gcc and libc headers. Here's the proposed module: >From 179c0e32f86c8b0013111d343f17d27730391e63 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> D

Re: [PATCH] ignore-value: new module

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I wanted to ignore some new warnings in coreutils, >> but a "(void)" cast no longer does the job with the latest gcc >> and libc headers. > > Do you have a reduced testcase? No, but I wi

Re: [PATCH] ignore-value: new module

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>> Jim Meyering wrote: >>>> I wanted to ignore some new warnings in coreutils, >>>> but a "(void)" cast no longer does the

Re: [PATCH] ignore-value: new module

Jim Meyering <[EMAIL PROTECTED]> wrote: > I wanted to ignore some new warnings in coreutils, > but a "(void)" cast no longer does the job with the latest gcc > and libc headers. > > Here's the proposed module: > >>From 179c0e32f86c8b0013111d343f17d277

Re: [PATCH] ignore-value: new module

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> >>> Jim Meyering wrote: >>>> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>>>> Jim Meyering wrote: >>>>&g

Re: [PATCH] ignore-value: new module

y care whether the function gets > inlined or not. In this situation, a simple AC_C_INLINE invocation would be > sufficient: > > Depends-on: > > configure.ac: > AC_REQUIRE([AC_C_INLINE]) Thanks. I've done that: >From 916dbd2380c32ea05e01ee9328fdce73197fd691 M

minus_zero-related tests fail to compile on ppc with recent gcc

Markus Armbruster <[EMAIL PROTECTED]> wrote: > With the appended patch, koji ate it up: > http://koji.fedoraproject.org/koji/taskinfo?taskID=886652 Great! Thanks a lot, Markus. Bruno, FYI, Markus discovered that an upcoming idutils release fails to compile on ppc-based systems: (details here htt

Re: pragma GCC diagnostic

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote: > 2008/10/17 Bruno Haible <[EMAIL PROTECTED]>: >> "#pragma GCC diagnostic" has a few limitations, which make it unusable to >> resolve warnings like this one: >> >> Jim Meyering wrote in

Re: [PATCH] ignore-value: new module

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>> Jim Meyering wrote: >>>> I wanted to ignore some new warnings in coreutils, >>>> but a "(void)" cast no longer does the

Re: pragma GCC diagnostic

Jim Meyering <[EMAIL PROTECTED]> wrote: > "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote: >> 2008/10/17 Bruno Haible <[EMAIL PROTECTED]>: >>> "#pragma GCC diagnostic" has a few limitations, which make it unusable to >>>

Re: minus_zero-related tests fail to compile on ppc with recent gcc

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Markus Armbruster <[EMAIL PROTECTED]> wrote: >> > With the appended patch, koji ate it up: >> > http://koji.fedoraproject.org/koji/taskinfo?taskID=886652 >> >> Great! Thanks a lo

Re: Warnings to be fixed

Jim Meyering <[EMAIL PROTECTED]> wrote: > Paul Eggert <[EMAIL PROTECTED]> wrote: >> Jim Meyering <[EMAIL PROTECTED]> writes: >> >>> mode = (sizeof (mode_t) < sizeof (int) >>> ? va_arg (ap, int) >>> : va_arg

Re: "unused parameter" warnings

Bruno Haible <[EMAIL PROTECTED]> wrote: > Reuben Thomas wrote: >> gl_anylinked_list2.h: In function ‘gl_linked_node_value’: >> gl_anylinked_list2.h:124: warning: unused parameter ‘list’ >> gl_anylinked_list2.h: In function ‘gl_linked_node_set_value’: >> gl_anylinked_list2.h:130: warning: unused par

<    1   2   3   4   5   6   7   8   9   10   >