Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 12/4/2006 2:21 AM:
>> So far, no one has objected to my proposal to convert gnulib development
>> from cvs to git. If there are any nay-sayers, it's time to speak up.
>>
>> I've just go
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Eric Blake on 12/27/2006 6:18 AM:
>>
>> I'm checking this in to fix this issue on platforms that do not need a
>> replacement . It is not a true reversion, since it rearranges
>> the include order to let pulls in prerequisites required for
>>
Hi Sylvain,
As you know, we want to convert gnulib to use git soon. I'd like
to use coreutils as a testbed for that. Currently, the coreutils
master repo is a git one. I manually run a script to mirror its
changes to a cvs repo on my local system. Then, I rsync that
repo to Bob's system (proul
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Shouldn't there be a modules file for announce-gen? Ok to install the
> following?
Yes. Thank you.
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Done.
>
> The script seem to make some non-generic assumptions, but I'll send
> patches for that later on.
I'm
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Announce-gen assumes that there are *.tar.bz2 and xdelta files, libidn
> doesn't use either. This patch disables printing information for
> those files, when the files doesn't exist. An alternate solution
> would be to warn instead, but I think it is n
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Eric Blake <[EMAIL PROTECTED]> writes:
>
>> * lib/version-etc.c (COPYRIGHT_YEAR): Bump for new year.
>
>> --- lib/version-etc.c 13 Sep 2006 22:38:14 - 1.24
>> +++ lib/version-etc.c 1 Jan 2007 15:05:49 -
>
> Thanks, but that's more than
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Seems to have fixed several of the modules I mentioned, although the
>> builder is still working on some remaining ones. Thanks!
>
> One failure is still there, at
> http://autobuild.josefsson.org/gnulib/log-200701021304717357000.txt
>
> In file include
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This looks like a typo. OK to fix?
>
> 2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
>
> * modules/lchmod (Include): Require lchmod.h, not lchown.h.
Hi Bruno.
Thanks. I applied that.
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> Now that gnulib-tool defines GNULIB_CANONICALIZE when the canonicalize module
> is in use, the PROVIDE_CANONICALIZE_FILENAME_MODE macro is redundant. Here is
> a proposed patch:
>
> 2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/ca
ing base64_decode
interfaces, and instead use a new pair of functions. Let me know,
and I'll finish the job. E.g., I haven't updated the base64 documentation
in coreutils yet, either.
For your reviewing fun, I've included both the gnulib parts
and the coreutils parts:
[gnulib]
2007
Jim Meyering <[EMAIL PROTECTED]> wrote:
> For your reviewing fun, I've included both the gnulib parts
> and the coreutils parts:
>
> [gnulib]
> 2007-01-03 Jim Meyering <[EMAIL PROTECTED]>
>
> When decoding, always allow newlines in input, wit
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> In the mean time -- sometimes it's easier to review things
>> when they're checked in...
>
> Thanks! I hope to review it soon. Sorry about the delay on this...
&
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Paul Eggert on 1/5/2007 5:29 PM:
>> I installed this, in response to the recent bug reports for IRIX 5.3
>> by Georg Schwarz.
>>
>> 2007-01-05 Paul Eggert <[EMAIL PROTECTED]>
>>
>> Don't worry about using IRIX 5.3's wctype.h broken defini
I've just checked in this change:
Slight readability improvement: use an assert-like macro
in place of literal "abort ()" uses.
* lib/fts.c (fts_assert): Define.
(fts_set_stat_required, cwd_advance_fd, fts_read, fd_ring_check):
Use this macro instead of a ba
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Thanks, but that doesn't matter. When st_size is used that way (when
>> ->fts_info == FTS_NSOK), its value must be FTS_STAT_REQUIRED (1) or
>> FTS_NO_STAT_REQUIRED
Bruno Haible <[EMAIL PROTECTED]> wrote:
> I've now removed the "magic" from gnulib-tool's func_get_autoconf_snippet
> function, and instead created a gnulib-common.m4 that people not using
> gnulib-tool can use in their project.
Hi Bruno,
I'm glad you found a better way.
Now we can have our cake
;
haible=Bruno Haible <[EMAIL PROTECTED]>
handa=Kenichi Handa <[EMAIL PROTECTED]>
jas=Simon Josefsson <[EMAIL PROTECTED]>
jbailey=Jeff Bailey <[EMAIL PROTECTED]>
jimb=Jim Blandy <[EMAIL PROTECTED]>
karl=Karl Berry <[EMAIL PROTECTED]>
kwzh=Karl Heuer <[
I wrote:
> FYI, I have updated the git mirror of the gnulib CVS repository once again.
>
> http://git.sv.gnu.org/gitweb/?p=gnulib.git
If you've looked at the above summary, you might notice that if the first
line of a commit log message is a summary for the entire change set,
it renders better w
Jim Meyering <[EMAIL PROTECTED]> wrote:
...
> How about this instead: we can continue to keep the generated file under
> version control and accessible, but instead of letting its deltas clutter
> up the source code repo, generate it into the savannah web repo inst
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> How about this instead: we can continue to keep the generated file under
>> version control and accessible, but instead of letting its deltas clutter
>> up the source code repo, generate it into th
[EMAIL PROTECTED] (Karl Berry) wrote:
> generate it into the savannah web repo instead:
> http://web.cvs.savannah.gnu.org/viewcvs/gnulib/?root=gnulib
>
> That sounds fine to me. Do you want me to do it now, or do you want to
> do it as part of the git stuff, or what?
Hi Karl!
It'd be g
Bruno Haible <[EMAIL PROTECTED]> wrote:
> 2007-01-09 Bruno Haible <[EMAIL PROTECTED]>
>
> * MODULES.html.sh: Accept options --cvs-urls, --git-urls.
> (repo_url_prefix, repo_url_suffix, repo_url_suffix_repl): New
> variables.
> (func_module): Use them.
Thanks for the speed
I've just checked in the following change:
fts.c: a small readability/maintainability improvement
* lib/fts.c (fts_read): Make this code slightly more readable and
maintainable by hoisting the "sp->fts_cur = p" assignments to
immediately follow the statements that s
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Following Jim's and Paul's ideas for portability of the coreutils to
> BeOS, Woe32 and DJGPP, which all lack an fchdir(), here is a first working
> fchdir module.
>
> The module installs wrappers around open(), close(), opendir(), closedir(),
> dup(), dup2(
"Daniel Richard G." <[EMAIL PROTECTED]> wrote:
> Building coreutils CVS on AIX 4.3 with GCC 4.1 ends with...
>
> BEGIN
> gcc -std=gnu99 -I.-D_THREAD_SAFE -O0 -g3 -MT readutmp.o -MD -MP -MF
> .deps/readutmp.Tpo -c -o readutmp.o readutmp.c
> In file included from readutmp.h:39,
>
"Daniel Richard G." <[EMAIL PROTECTED]> wrote:
> That did the trick. The coreutils tarball you provided builds (and tests)
> without a hitch on the same AIX 4.3 system.
Thanks for confirming.
I've checked it in.
File exists
make[1]: *** [sys/time.h] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/f/w/cu/lib'
make: *** [all-recursive] Error 1
So I checked in this fix:
2007-01-18 Jim Meyering <[EMAIL PROTECTED]>
Use "$(MKDIR_P) sys&quo
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> This patch seem to cause plenty of build failures like this:
Hi Simon,
Thanks for the report.
What version of autoconf are you using on that system?
I tried to reproduce the failure like this:
cd /tmp
rm -rf x
/gnulib/gnulib-tool --dir x
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Sun, Jan 21, 2007 at 10:27:30PM CET:
>> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> > This patch seem to cause plenty of build failures like this:
>
>> What version of autoconf are you us
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> "James Youngman" <[EMAIL PROTECTED]> writes:
>
>> However, I think the problem is that on this system, the Makefile.in
>> file is not actually using @MKDIR_P@ :-
>
> Yes, I still get the same problem. I have tried Bruno's patch, but it
> makes no differ
Bruno Haible <[EMAIL PROTECTED]> wrote:
> James Youngman wrote:
>> The following patch fixes the problem. I'm not sure if it is
>> the *right* fix for the problem, since I have only been working with
>> Autoconf/Automake macros for ten years, and so I don't understand it
>> well enough yet.
>>
>>
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> > For the other 9 cases, invoking
>> > instead of requiring the macro is the solution.
>>
>> Won't that bloat 'configure' and slow it down?
>
> For gl_GETOPT_SUBSTITUTE, configure's size will increase, yes. But this is
> exactly how gl
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
>> # M4 code to put before or right after AC_INIT:
>> m4_ifdef([_m4_require_call],
>> [m4_rename([_m4_require_call], [_m4_require_call_orig])dnl
>> m4_define([_m4_require_call],
>> [m4_pushdef([AC_LIBOBJ],
>> [m4_warning([AC_LIBOBJ
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I'd like to add a 'string' module to gnulib, which does for
> what the sys_time module does for , namely, sets up a
> substitute string.h that has needed GNU declarations. That way,
> we don't need to worry about the little include files like "strstr.h"
>
Paul Eggert <[EMAIL PROTECTED]> wrote:
> While we're on the subject, here are the changes to coreutils
> that will be needed once this stuff goes into gnulib. (This
> is the fun part -- removing stuff)
>
> 2007-01-26 Paul Eggert <[EMAIL PROTECTED]>
>
> * src/dircolors.c: Don't include
Check out the red columns here:
http://proulx.com:9000/
Maybe a system-provided mempcpy macro is causing trouble?
---
...
source='mempcpy.c' object='mempcpy.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -Ae -O -c mem
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Jim Meyering wrote:
>> Check out the red columns here:
>>
>> http://proulx.com:9000/
>>
>> Maybe a system-provided mempcpy macro is causing trouble?
>> ...
>> cc -I. -Ae -O -c mempcpy.c
>&
Jim Meyering <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Bob Proulx) wrote:
>
>> Jim Meyering wrote:
>>> Check out the red columns here:
>>>
>>> http://proulx.com:9000/
>>>
>>> Maybe a system-provided mempcpy macro is causin
HP-UX's cc warned about this.
"q" was set twice, but never used.
* lib/regex_internal.c (re_string_reconstruct): Remove declaration
of set-but-not-used local, "q".
Index: lib/regex_internal.c
===
RCS file: /sources/gn
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul, Jim,
>
> Most developers are using glibc systems nowadays. When gnulib creates many
> replacement header files on such systems, it makes look gnulib a bit
> ridiculous. So can we avoid to create a header file when it's easy to do so?
> Here is a pr
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> - use $(SYS_TIME_H) also in the definition of MOSTLYCLEANFILES
>
> This is not a good change. Suppose a user does in the same directory
> - first, a "./configure; make" for a deficient platform,
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Bob Proulx wrote:
>> That seemed to mostly work. It is still failing under ia64 though. I
>> think the compiler there has no support for restrict. If I define
>> restrict to be nothing to disable it completely then the compilation
>> succeeds.
>> ...
>> So
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Avoid a compile error from HP-UX's ia64 cc: s/__restrict\>/restrict/
>> * lib/regex.h: Use "restrict", not "__restrict", since only t
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> If you're serious about merging back to glibc, it'll help
>> (name space cleanliness) to add the "__" prefix: i.e., change
>> your Restrict to __Rest
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Paul,
>
>> Such a function can lead to faster execution
>> in some important cases, as I have verified using GNU 'ls' as a guinea pig.
>
> Does the speedup come from the use of the mergesort algorithm, or from
> avoiding a function call in the compari
Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> Here is a GnuLib module providing the strptime function, merged from the
> glibc implementation. From my minor testing, the module seem to work.
Thanks for contributing that.
On what systems it necessary?
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Does the major speedup come from the transition a) -> b), or from the
>> transition b) -> c) ?
>
> I didn't code those solutions separately, so I don't know.
>
> I have written a replacement qsort that has the s
2007-01-30 Jim Meyering <[EMAIL PROTECTED]>
* lib/mpsort.c (mpsort): Remove spurious "return" in void function.
Index: lib/mpsort.c
===
RCS file: /sources/gnulib/gnulib/lib/mpsort.c,v
retrieving revisio
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I ran into a problem building CVS coreutils on Debian stable, since
> coreutils does not use some of the string.h-related modules, but
> Debian string.h #defines some of the symbols that string.h therefore
> attempts to #define to foo_is_unportable, and the
For background, this thread started here:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/9581
Andi Kleen <[EMAIL PROTECTED]> wrote:
>> [*] Can you even get a 2GB-long string into expr?
>
> At least on Linux you can't, the kernel limits arguments and environments
> to 128K or so. There ar
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> ...for some reason, configure on AIX is incorrectly thinking that it has
> strndup (declared, anyway) from the OS, when it does not UNLESS
> '_ALL_SOURCE' is defined. This causes a build failure in xstrndup (from
> coreutils 6.6, and Jim's 6.7+ snapshot
coreutils didn't bootstrap, due to a syntax error (AC_PROG_MKDIR_P)
in its generated lib/Makefile. I fixed it with this:
* modules/arpa_inet: Put AC_PROG_MKDIR_P in the configure.ac:
section, not in the Makefile.am: one.
Index: modules/arpa_inet
==
Thank you for reporting that!
I've just checked in the patch below.
I'll add tests to coreutils some time next week.
This bug affects only systems with openat support (glibc-2.4 and
newer and Solaris 10).
2007-02-03 Jim Meyering <[EMAIL PROTECTED]>
Make pwd and readlin
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I've just changed xalloc's x2nrealloc to do n = 3n/2, rather than n *= 2,
>
> Which means that the time needed for realloc() will grow by a factor of 1.7
> on average. If it matters - haven'
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> - if (((size_t) -1) / 2 / s < n)
>> + if ((2 * (((size_t) -1 - 1) / 3)) / s < n)
>
> That's not quite right. As an extreme case, suppose S is
> SIZE_
7;s getcwd.c
to try the value of $PWD from the environment when all else fails.
diff --git a/ChangeLog b/ChangeLog
index dbd3059..8b41ce7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2007-02-03 Jim Meyering <[EMAIL PROTECTED]>
+
+ Test for today's gnulib/lib/getcw
Albert Chin <[EMAIL PROTECTED]> wrote:
> Any reason all uses of #include aren't wrapped with #ifdef
> HAVE_CONFIG_H like so:
> #ifdef HAVE_CONFIG_H
> # include
> #endif
>
> Some .c files have the above and some don't. Seems to make sense for
> all to have the form above.
The vast majority
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Bruno, Jim, Paul, all,
>
> I found a couple more underquotations. Here's a proposed quick patch.
> If you prefer some other quoting style (e.g., maximal quoting or
> quadrigraphs, but rather not changequote), I'd be happy to redo.
> OK to apply?
)/.#bootmp/build-aux/link-warning.h
With the embedded "#", that was equivalent to
LINK_WARNING_H = $(top_srcdir)/.
Obviously, it's better not to use such file names, but it'd be nice
for gnulib-tool to support it, or at least to diagnose the problem.
I've worked
I've just made another snapshot.
Changes since the previous one are from gnulib
and from using autoconf-2.61a rather than 2.61.
Both bring bug fixes.
http://meyering.net/cu/coreutils-6.7-dirty.tar.gz
http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig
aka
http://meyering.net/cu/coreutils-6
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> I expect to release coreutils-6.8 (not called "stable", but not
>> particularly "unstable" either) soon. Then, soon (i.e. a week)
>> afterwards, I want to make a stable 6.9 release.
>
> Hmm, should we reduce the amount of gnulib changes in
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This creates a "complete" . The include files exit.h, mkdtemp.h,
> mkstemp.h no longer exist - use instead.
Hi Bruno,
I don't have time to look into it now, but this seems to
be the cause of some new coreutils buildbot failures, e.g.,
http://proulx.co
Currently, the primary repository for gnulib is CVS-based.
The GIT-based mirror, is now updated semi-automatically.
View a summary or browse:
http://git.sv.gnu.org/gitweb/?p=gnulib.git
Check out gnulib using git:
git clone git://git.sv.gnu.org/gnulib
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> A gnulib testdir with the module 'ftruncate', cross-compiled to mingw
> (--host=i386-pc-mingw32), showed me this:
>
> configure: error: Your system lacks the ftruncate function.
> Please report this, along with the output of "uname -a"
I don't know of a system on which this bug can be exercised.
I found it only by manually building getcwd.o, even though
this system already has a mostly-working one.
The symptom is that getcwd would always fail with ENOENT.
Don't use FD after a successful "fdopendir (fd)".
* lib/ge
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Does the following accurately describe the behaviour of getcwd() in gnulib?
> I'm asking because lib/getcwd.c mentions a certain GNU extension, whereas
> lib/getcwd.h merely refers to the POSIX spec.
>
> /* Get the name of the current working directory, and
I wrote:
...
> Unlike most other getcwd implementations, this one may *potentially*
> return a name that is arbitrarily long (and hence much longer than PATH_MAX).
>
> Currently that doesn't ever happen because the only systems
> that have openat support also have a mostly-working getcwd,
> and *it
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> * m4/ftruncate.m4: Adjust comment to give this module a 3-year reprieve.
>> Prompted by a report from Bruno Haible that mingw lacks ftruncate.
>
> I also meant to make life easier to people using mingw. mingw will not have
> gone a
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This, I can't tell, as I'm only cross-compiling. I can't do more than "nm"
> on the object files.
At least we know gnulib-based applications that use ftruncate
will continue to link when compiled for mingw.
>> If we're no closer to removing the module, th
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I've made another snapshot:
>> http://meyering.net/cu/coreutils-6.7-dirty.tar.gz
>> http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig
>> Please give it a try and report anythi
Paul Eggert <[EMAIL PROTECTED]> wrote:
> I installed this to work around some porting problems on Solaris 10.
> dirfd needs declaring. And cc complains about rpl_putenv being
> redeclared with a different type, since Solaris 10 header files
> declare it with a char * arg.
>
> 2007-02-20 Paul Egge
Paul Eggert <[EMAIL PROTECTED]> wrote:
> coreutils "make check" failed on Solaris 10 with Sun C 5.8 due to "df
> ." failing. I tracked it down to a getcwd issue exposed by recent
> changes to getcwd.c, and installed this patch to gnulib.
>
> After installing this patch (and the other fixes I sent
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Matthew Woehlke wrote:
>> Anyway thanks for the quick fix, I nuked the line manually and that
>> seemed to fix IRIX. I am also going to test the new snapshot. So far
>> I have at least one test failure on IRIX that looks like a problem
>> with my perl i
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Why does your config.h define HAVE_PARTLY_WORKING_GETCWD
>> when using Sun C 5.8?
>
> Sorry, I don't know offhand. I don't currently have access to the
> affect
Harvey Eneman <[EMAIL PROTECTED]> wrote:
>> Which functions are those?
>
> I was referring to getenv(3), putenv(3), unsetenv(3) and setenv(3) functions.
>
> In my particular case, the LD_PRELOAD shared object starts a thread which
> will call getenv() but consider what could happen if the thread
This fixes it:
* modules/utimens (Depends-on): Add timespec, required for
utimens.h's inclusion of timespec.h.
Index: modules/utimens
===
RCS file: /sources/gnulib/gnulib/modules/utimens,v
retrieving revision 1.9
diff
Albert Chin <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 22, 2007 at 01:22:31AM +0100, Jim Meyering wrote:
>> Paul Eggert <[EMAIL PROTECTED]> wrote:
>> > Jim Meyering <[EMAIL PROTECTED]> writes:
>> >
>> >> Why does your config.h def
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 2/22/2007 2:26 PM:
>> This fixes it:
>>
>> * modules/utimens (Depends-on): Add timespec, required for
>> utimens.h's inclusion of timespec.h.
>
> stat-time is another module t
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
>>
>> There is a declaration of struct timespec in time_.h,
>> so utimens.h, stat-time.h, and getdate.h should include
>> rather than timespec.h. Then timespec.h can be remo
Eric Blake <[EMAIL PROTECTED]> wrote:
> 2007-02-23 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/getdate.h (includes): Include , not "timespec.h".
> * lib/stat-time.h (includes): Likewise.
> * lib/utimecmp.c (includes): Likewise.
> * lib/utimens.h (includes): Likewise.
>
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Bad timing. I was about to make a test release.
>> If anyone else has access to a Solaris 10 system (x86 or otherwise),
>> with Sun C, would you please try the latest snapshot?
>> http://meyerin
Bruno Haible <[EMAIL PROTECTED]> wrote:
> 2007-02-23 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/perl.m4 (gl_PERL): Require version 5.005, not 5.003. Needed for
> help2man.
> * man/Makefile.am (.x.1): If the autoconf test has determined that
> perl is missing or not a suffic
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Bruno Haible wrote on Sat, Feb 24, 2007 at 01:30:53AM CET:
> [...]
>> +@case $(PERL) in\
>
> You probably want to put that in quotes, so $(PERL) expanding to two
> words won't cause a syntax error.
Thanks, R
I've had this change sitting around for a while...
* m4/regex.m4: Update the description of the configure-time option,
--without-included-regex, to state accurately what the defaults are,
and perhaps to give people an idea why using this option is risky.
Index: m4/regex.m4
I've just committed this:
[coreutils-6.8 needs this patch on FreeBSD]
Avoid conflicting types for 'unsetenv' on FreeBSD.
* lib/putenv.c (_unsetenv): Rename from "unsetenv", to avoid
conflicting with FreeBSD's (5.0 and 6.1) function declaration
in stdlib.h.
Index: l
I've checked in this change:
* build-aux/announce-gen: When complaining about excess arguments,
list them.
Index: build-aux/announce-gen
===
RCS file: /sources/gnulib/gnulib/build-aux/announce-gen,v
retrieving revisio
Bruno Haible <[EMAIL PROTECTED]> wrote:
> What can we do in gnulib?
>
> (a) Have 2 xreadlink like functions. Since the one without prior stat is more
> natural, I would propose to rename the coreutils one, with the 'size'
> argument, to 'xreadlink_after_stat'.
>
> Or
>
> (b) Merge the two f
"Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> For this reason, and for the difficulty of reboot-strapping old releases
> of gnulib using projects, I find the anti-release model of gnulib
> somewhat
> depressing. It would be nice for gnulib to make occasional feature
> freezes,
> or release branch
Eric Blake <[EMAIL PROTECTED]> wrote:
...
> Eventually, when the move to git is complete, doing this will be easy -
> you just make a branch in your local git copy of gnulib, and base your m4
> release off of that branch.
>
> But so far, it has not been too much of an issue - I have been actively
>
Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> I tried that now, since I kind of agree with the reasoning, although
> this breaks the maintainer-makefile module that I'm using in several
> projects. The module contains a 'GNUmakefile' that really need to be
> in the top-level directory to make s
Bruno Haible <[EMAIL PROTECTED]> wrote:
> The package I announced two days ago shows that most systems have isnan()
> as a function:
>
> $ ./show-portability isnan
> libcfreebsd-5.2.1
> libcfreebsd-6.0
> libcirix-6.5
> libcmacosx-10.3
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00269.html
Oh! In _this_ list. Thanks.
I never received that message.
I wish list-delivery-to-subscribers were more reliable.
Perhaps I should make gnus start reading via e.g., gmane.org.
,5 +22,4 @@ License:
GPL
Maintainer:
-Bruno Haible
-
+Bruno Haible, Jim Meyering
Index: modules/xreadlink-with-size
===
RCS file: /sources/gnulib/gnulib/modules/xreadlink-with-size,v
retrieving revision 1.2
diff -u -p -r1.2 xreadlink-with-s
Yesterday, Nelson Beebe tested coreutils-6.8+.
I replied:
> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> ...
> > I have a question, however. Since 6.8 got installed, I've been
> > seeing a + at the end of the permission field, e.g., on abajo:
> >
> > % ls -l /usr/local/share/man/man3cw/urcw4
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Yesterday, Nelson Beebe tested coreutils-6.8+.
>
> I replied:
>> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
>> ...
...
>> > The other peculiar thing is that when I do a "make install"
>
The preceding was not complete:
* lib/acl.c (ACL_NOT_WELL_SUPPORTED): New macro.
Use it consistently, rather than enumerating errno constants.
Index: lib/acl.c
===
RCS file: /sources/gnulib/gnulib/lib/acl.c,v
retrievi
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>>> Any suggestions?
>>
>> The config.rpath in gnulib is newer than the one from the latest gettext
>> release (0.16.1). Therefore I would move build-aux/config.rpath away so
>> that autopoint doesn't see it, an
FYI, this change removed 1500 lines of ChangeLog content:
Author: Bruno Haible <[EMAIL PROTECTED]>
Date: Sun Feb 18 15:10:28 2007 +
New module 'math'. replaces mathl.h.
I presume that was accidental and have restored those lines.
Using git, you can see the diff like this:
git-diff
Eric Blake <[EMAIL PROTECTED]> wrote:
> Is this patch acceptable? Most platforms already use 1 for EXIT_FAILURE. It
> fixes what are otherwise false negatives in the M4 testsuite. It also makes
> it
> easier to use GNU applications with xargs (since POSIX requires xargs to
> behave
> different
301 - 400 of 3877 matches
Mail list logo
