, chown, chgrp,
and via "make check" for find]
FWIW, I plan to separate this into at least two separate patches
before checking it in.
2006-10-11 Jim Meyering <[EMAIL PROTECTED]>
* modules/fts (Depends-on): Add d-type. Alphabetize.
* l
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> ./bootstrap: aclocal --force -I m4 ...
>> configure.ac:39: warning: AC_COMPILE_IFELSE was called before
>> AC_USE_SYSTEM_EXTENSIONS
>
> Thanks for reporting that. I in
du, chmod, chown, chgrp,
> and via "make check" for find]
>
> FWIW, I plan to separate this into at least two separate patches
> before checking it in.
Separating the patch into parts wasn't really an option after all.
I've checked this in:
2006-10-12 Jim Meyerin
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> Separating the patch into parts wasn't really an option after all.
>> I've checked this in:
>
> Looks great. Thanks.
>
> What's the easiest way to try this out? The patch doesn't apply to
> the gnulib present in findutils-4.3.1, and I have no idea how
coreutils' configure-time test for existence of lib/getloadavg.c
was failing because that file is now typically a symlink.
Here's how I've fixed it:
2006-10-12 Jim Meyering <[EMAIL PROTECTED]>
* m4/getloadavg.m4 (gl_GETLOADAVG): Test for the existence of
l
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for reporting that. In looking at the code, I found
> some other problems (notably, errno was sometimes mishandled)
> and installed the following more-general patch into gnulib.
>
> 2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
>
> * lib/rename-
Jim Meyering <[EMAIL PROTECTED]> wrote:
> coreutils' configure-time test for existence of lib/getloadavg.c
> was failing because that file is now typically a symlink.
>
> Here's how I've fixed it:
>
> 2006-10-12 Jim Meyering <[EMAIL PROTECTED]>
>
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Simon Josefsson wrote:
>> The last patch wasn't working, but this is somewhat better.
>
> This appears to work reasonably well, and I need it also for gettext,
> so I committed it.
> Simon, compared to your proposed patch, I
> - applied the same change t
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> coreutils now fails to pass "make
>> distcheck" after a bootstrap. At least part of the problem is that
>> lib/Makefile's DIST_COMMON ends up being nearly empty.
>
> This should fix
Jim Meyering <[EMAIL PROTECTED]> wrote:
> For example, this command, applied to the imported .m4 files for
> coreutils, produces the required list of .c file names:
>
> grep -h 'AC_LIBOBJ(' *.m4 \
> |sed 's/^ *//;/^#/d;/^dnl/d;s/.*AC_LIBOBJ(//;s/^\[//;s/[]
Eric Blake <[EMAIL PROTECTED]> wrote:
> Bruno Haible clisp.org> writes:
>> Jim Meyering wrote:
>> > coreutils now fails to pass "make
>> > distcheck" after a bootstrap. At least part of the problem is that
>> > lib/Makefile's DIST_COMM
Hi Eric,
Your recent change to modules/error causes trouble with coreutils.
I think it was automake that complained [yep, diagnostic below].
Did you need that change?
I've reverted it locally, and now bootstrap-and-build works fine again.
Jim
date: 2006-10-12 22:04:19 +0200; author: ericb; sta
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
>> It passed "make distcheck" with only one additional kludge.
>> The above mistakenly added lib/tmpfile-safer.c to the list,
>> even though coreutils doesn't use the file.
>> It was pulled in due to this unused macro in stdio-safer.m4:
>>
>> AC_DEFUN([
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> These are good arguments for making gnulib-tool use autoconf --trace
>> on the underlying macro rather than relying on heuristics.
>
> Rather, it indicates that: when searching for all AC_LIBOBJ calls,
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> I've tried out the CVS version of findutils+gnulib, and it does indeed
> seem to fix the problem with inode-less filesystems, in addition to
> using noticably less system time.
>
> I've also found that the -xdev option of find no longer works: it
> output
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> I've tried out the CVS version of findutils+gnulib, and it does indeed
>> seem to fix the problem with inode-less filesystems, in addition to
>> using noticably less syste
Jim Meyering <[EMAIL PROTECTED]> wrote:
...
> Here's the patch (same as proposed, but with a comment),
> followed by a patch to add a findutils test that exercises the bug.
...
I didn't include ChangeLog entries for the new find test case.
Here they are.
BTW, without the p
USER_PROCESS.
> * lib/readutmp.h (READ_UTMP_USER_PROCESS): New flag
Hi Sergey,
That change looks fine. Next time I'll try to reply sooner.
I've made this additional change:
2006-10-18 Jim Meyering <[EMAIL PROTECTED]>
* lib/readutmp.c (desirable_utmp_entry): Use
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This fixes the build error of fchmodat on mingw.
Thanks. Applied.
> 2006-10-19 Bruno Haible <[EMAIL PROTECTED]>
>
> * lib/openat-priv.h (EOPNOTSUPP): Provide fallback definition. Needed
> for mingw.
?
If there were an inttostr *function*, I would have been happy
to use that, but there isn't. Substituting any of the other *tostr
functions would require using an 8-byte type on some systems,
which makes them too wasteful for me.
2006-10-21 Jim Meyering <[EMAIL PROTECTED]>
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-10-21 at 10:39 +0200, Jim Meyering wrote:
>> Paul, Simon,
>> Any objection to the changes below?
>
> Seems generally fine to me, thanks!
>
>> + short int port = ntohs (((const struct sockaddr_in *)
I expect to make a stable coreutils-6.4 release very soon (maybe even
tomorrow), so if you know of remaining portability (or other) problems
and want to see them fixed in that release, report them now.
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> On Sat, 2006-10-21 at 10:39 +0200, Jim Meyering wrote:
>>> Paul, Simon,
>>> Any objection to the changes below?
>>
>> Seems generally fine to me, thanks!
..
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> ...
>> +# Prerequisites of lib/uinttostr.c.
>> +AC_DEFUN([gl_PREREQ_UINTTOSTR], [:])
>
> What are these dummy functions useful for, anyway?
Not much.
They're just place-holders.
Eric Blake-1 <[EMAIL PROTECTED]> wrote:
> I checked this in:
>
> 2006-10-23 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/getaddrinfo.c (includes): Add missing include.
Thanks!
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Compiling coreutils-6.4 with gcc-4.1 and
>
> ./configure --prefix=/packages/gnu \
> CPPFLAGS="-Wall -Wformat=2 -Wmissing-field-initializers
> -Wmissing-format-attribute -Wpointer-arith -Wstrict-aliasing=2
> -Wwrite-strings" \
> CFLAGS="-O2 -g -Wbad-fu
[EMAIL PROTECTED] (Karl Berry) wrote:
> When I run MODULES.html.sh now, I get the following msg (several times):
>
> gnulib-tool: module uinttostr doesn't exist
That was my doing. Fixed.
* MODULES.html.sh: Remove uinttostr. It's not a module.
Reported by Karl Berry.
Index: MODU
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for catching those. I prefer the 'const' after the type that
> it modifies, so I installed the following into gnulib. (For coreutils
> I guess I need to come up to speed on its new version control system.)
No rush. I'm looking at them now.
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
...
>> fts.c:1076: warning: ISO C90 forbids mixed declarations and code
>>
>> gnulib still assumes C89 only. Here is a fix.
>>
>> Jim, OK to apply?
>
> That lo
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I have found that it is useful to keep the commit log message
>> very similar to the ChangeLog entry.
>
> ... whereas I find it useful to put rationale information into the cvs
> commit message. (Becau
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This is one of 2 more changes needed for C++ compilation of GNU gettext
> without errors.
>
> Is this acceptable?
This is borderline.
Obviously, in general, we should try to avoid casts,
but since it's just one, and I see no way around it, ok.
> 2006-10-2
[EMAIL PROTECTED] (Karl Berry) wrote:
> How do people maintain the list of Gnulib source files for POTFILES.in?
> Other than simply tracking the ever-changing list of sources, is there
> any built-in support of some kind?
>
> I can imagine writing a script that greps the gnulib dir or whatever,
> b
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Another consistency change: canonicalize_filename_mode should be
> renamed to canonicalize_file_name_mode as per the GNU coding standards.
> Any objections? (Jim? :-)
That's fine by me.
Gnulib needs more *automatic* consistency checks,
especially now tha
As Ralf pointed out, module-check reports a lot of oddities.
This fixes one of them.
FWIW, fts.c doesn't really care about _LIBC anymore, since
I've resolved to rename the functions/macros (maybe to nfts, etc).
That's because with the ABI changes, there's no hope of merging
gnulib-fts changes back
I've just done this:
* lib/fts.c (fts_safe_changedir): Add a comment.
Index: lib/fts.c
===
RCS file: /sources/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.24
diff -u -r1.24 fts.c
--- lib/fts.c 8 Nov 2006 07:42:26 -
I tried to build coreutils using the very latest from gnulib and got
link failures due to missing xcharalloc, used by e.g., quotearg.o.
I tracked it back to the lack of a HAVE_INLINE definition in config.h,
which in turn was due to a defect in the gnulib xalloc module. It did
not arrange to use th
NLINE was not
defined. However, when compiling (with $CFLAGS containing -O), there
was no external definition of any function like xnmalloc or xcharalloc.
Paul, here's the change I'm using:
2006-11-10 Jim Meyering <[EMAIL PROTECTED]>
* m4/inline.m4 (gl_INLINE): Check w
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> 2006-11-10 Jim Meyering <[EMAIL PROTECTED]>
>>
>> * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp,
>> so that relevant options in CFLAGS (like -O, -fno-inline) are
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
> * Jim Meyering wrote on Fri, Nov 10, 2006 at 03:53:42PM CET:
>>
>> I did not run "make clean", but did ensure that config.h was updated.
>> That alone should have caused all "old" .
n
# define bindtextdomain(Domainname, Dirname) /* empty */
#endif
Then your function body isn't "dirtied" with #if directives,
the *textdomain functions are defined away,
and you don't need the anachronistic-looking (void) casts.
2006-11-10 Jim Meyering <
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Better still, add this in system.h:
>>
>> #if ! ENABLE_NLS
>> # undef textdomain
>> # define textdomain(Domainname) /* empty */
>> # undef bindtextdomain
>> #
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've just made a new release of vc-dwim:
Here are the files:
http://et.redhat.com/~meyering/vc-dwim-0.2.2.tar.gz
http://et.redhat.com/~meyering/vc-dwim-0.2.2.tar.gz.sig
You can check out the sources like this:
hg clone http://hg.et.redhat.com/h
I've just checked in this change:
* lib/fts.c [FTS_DEBUG]: Don't try to print a pointer via %s.
Index: lib/fts.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.25
diff -u -r1.25 fts.c
--- lib/fts.c 8
software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ bu
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It sounds like the recent trend to remove uses of AC_LIBSOURCE
>> (in favor of listing source file names in each module-file Files: section)
>> is the reason for at least some of my missing depen
patch, but I'd prefer to begin converting coreutils' few
remaining m4/* and lib/* files (the rest have all migrated to gnulib,
of course) into modules in a local gnulib dir. So I've done this:
2006-11-14 Jim Meyering <[EMAIL PROTECTED]>
* gl/m4/root-dev-ino.m4: Now t
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
>> The following modules are licensed under GPL but used by LGPL modules:
>>
>> - inttostr: used by getaddrinfo
>
> Ouch, this is serious, and was introduced recently. Jim, Paul, would
> you agree to re-l
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
...
> coreutils now still needs one more fix, after Jim's:
> some of its own lib files are still not dependency-tracked:
> | ls: .deps/fdopendir-glibc.Po: No such file or directory
> | ls: .deps/lstat-stub.Po: No such file or directory
> | ls: .deps/readli
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
>
>> warning: getaddrinfo is LGPL but depend on intprops which is GPL
>> warning: inttostr is LGPL but depend on intprops which is GPL
>
> Jim, Paul, is it possible to have intprops be under LGPL? The
> a
Bruno Haible <[EMAIL PROTECTED]> wrote:
> I would propose:
...
> - euidaccess: change group-member.c so that it doesn't use xmalloc. If the
> memory allocation fails, let group_member() return -1 with errno = ENOMEM.
> Jim, would you accept patches to that effect?
Sure.
> - fts-lgpl & openat:
12 Nov 2006 17:35:39 - 1.1
+++ modules/i-ring 18 Nov 2006 11:13:55 -
@@ -7,6 +7,7 @@
m4/i-ring.m4
Depends-on:
+verify
configure.ac:
gl_I_RING
@@ -17,7 +18,7 @@
"i-ring.h"
License:
-GPL
+LGPL
Maintainer:
Jim Meyering
There are still plenty of violations, but this removes a few false-positives.
* check-module (%exempt_header): Add exception for some
conditionally-included headers.
Index: check-module
===
RCS file: /sources/gnulib/g
'm sure we won't
mind having to run "configure" once in a while, and an
automake-derived "make check" framework *would* be better.
Though, perhaps an autotest-based framework would be better still.
2006-11-20 Jim Meyering <[EMAIL PROTECTED]>
The begi
Michael Deutschmann <[EMAIL PROTECTED]> wrote:
> Yet again, a new C89-incompatibility has appeared in coreutils (6.5) that
> is not covered by c99-to-c89.diff. It's different from all I've reported
> before.
>
> The fix is appended.
Thanks for the patch. I applied it.
As you can see, I am not ve
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> It'd sure be nice to keep gnulib's instability from affecting
>> "stable" coreutils releases.
>
> What I do for my (less-ambitious-than-coreutil
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Michael Deutschmann <[EMAIL PROTECTED]> wrote:
>>> Yet again, a new C89-incompatibility ... [snip]
>> As you can see, I am not very motivated to be
>> proactive about supporting such
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> Do you have a comparison of git with mercurial, monotone
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Would anyone be averse to switching gnulib development from CVS to git?
>>> I switched coreutils a month ago and am very happy with the result.
>
<[EMAIL PROTECTED]> wrote:
> On 2006-11-21 07:56:27 -0600, Jim Meyering <[EMAIL PROTECTED]> said:
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> I found this
FYI, I've just checked these in:
* m4/clock_time.m4 (gl_CLOCK_TIME): Quote AC_SUBST argument.
* m4/euidaccess.m4 (gl_PREREQ_EUIDACCESS): Likewise.
Index: m4/clock_time.m4
===
RCS file: /sources/gnulib/gnulib/m4/clock_
[EMAIL PROTECTED] (Karl Berry) wrote:
> this change would not force you to learn about or use git.
>
> Granting that git is a zillion times better than cvs, even so, far fewer
> people can contribute to a git repository than cvs.
>
> As I understand it, the reason for the proposal is because br
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
>> > - automatic daily backup,
>>
>> Not relevant.
>> With git or hg, anyone who pulls gets the entire repository.
>
> Hmm, but if the central repository got lost, and was restored through - say -
> my copy, everyone would see my temporary branches,
No
[EMAIL PROTECTED] (Karl Berry) wrote:
...
> but we'd commit changes only against the git repo
>
> That was my point. Have you written a cheat sheet for coreutils git
> users? Or maybe one exists independently? You know,
> (a) how to check out
On the command line, it's probably best to start
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
>
>> source='fts.c' object='fts.o' libtool=no \
>> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
>> cc -I. -I/home/install/gnu/hp700_hpux/include -g -c
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> The OS is 11.00, and I can't tell about the compiler ('cc -v' is giving
FYI, I've checked in a slightly different change:
Work around a compile-time error from the HP-UX 11.00 /bin/cc.
* lib/fts.c (enum Fts_stat): Give this previously-a
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> +enum Fts_stat need_stat = p->fts_statp->st_size;
>> +switch (need_stat)
>
> Dunno if this matters, but on typical 64-bit platforms convertin
Free Software Foundation,
+# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+# Written by Jim Meyering
+
+use strict;
+
+use Getopt::Long;
+use Digest::MD5;
+use Digest::SHA1;
+
+(my $VERSION = '$Revision: 1.25 $ ') =~ tr/[0-9].//cd;
+(my $ME = $0) =~
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Matthew Woehlke <[EMAIL PROTECTED]> writes:
>
>> Ok, happen to have a quick how-to? (A cron job that *doesn't* mail me
>> unless there is a problem would be nice :-).)
>
> http://buildbot.sourceforge.net/
>
> I haven't built one myself, but others have
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> This will keep me from releasing decl-after-stmt code in coreutils/src:
>
> This inspired me to try harder for an automated check for departures
> from C89. Here's a propo
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>> This will keep me from releasing decl-after-stmt code in coreutils/src:
>> This inspired me to try harder for an automated check for departures
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Paul Eggert wrote:
>> Matthew Woehlke <[EMAIL PROTECTED]> writes:
>>
>> > I could probably do it on
>> > this box, but since it's Linux, it would still be with gcc.
>>
>> Even that would be helpful, since our current buildbot doesn't do the
>> particular comb
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Jim Meyering wrote:
>> Here's what Paul just added to Makefile.maint.
>> That should do it, as long as you do that build
>> on a relatively modern Linux system:
>>
>> $ grep -C2 ansi Makefile.maint
>>
Sylvain Beucler <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 27, 2006 at 10:41:49PM +0100, Jim Meyering wrote:
>> Hi Sylvain,
>>
>> Do you know of a good way to sync a git repository to cvs?
>> Ideally, it'd happen upon each commit or push, via a hook.
>&g
[EMAIL PROTECTED] (Bob Proulx) wrote:
> Jim Meyering wrote:
>> Yes, but the code that decides whether to skip the test should know
>> whether there is a version of linux-2.4.x for which the bug is fixed.
>>
>> I guess you don't have access to an ia64 system with
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> If anyone in the audience has access to an ia64 system running a kernel
>> newer than linux-2.4.19, would you please let me know?
>
> SLES8 is using 2.4.21.
Thanks.
Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> tests/test-base64.c in the gnulib repository checks out marked
>> executable for me. Seems odd.
>
> Here too. Is this possible to fix without direct access to the CVS
> repository?
Yep, but it's a kludge.
Remove it and re-add without the execute bit
[EMAIL PROTECTED] (Larry Jones) wrote:
> Jim Meyering writes:
>> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> > Here too. Is this possible to fix without direct access to the CVS
>> > repository?
>>
>> Yep, but it's a kludge.
>> Remove it a
Sylvain Beucler <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 28, 2006 at 11:32:55AM +0100, Jim Meyering wrote:
>> BTW, I've converted gnulib's (as of a day or two ago) CVS repo into a
>> git repository (with proper "User Name <[EMAIL PROTECTED]>" labels
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> (...which, aside from the infamous NSK/OSS you've all come to hate me
> for :-) reportedly includes OS/2. According to "The Linux Programmer's
> Manual" (i.e. 'man fchdir'), "The fchdir call is compatible with SVr4,
> 4.4BSD and X/OPEN". Note the conspic
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
...
>> I did a survey, some time ago, of reasonable porting targets, and all
>> had fchdir. Eventually I should remove the test for fchdir, too.
>
> So NSK/OSS has just been demoted to 'unreasonab
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> ...except that a declaration for fchdir() is already provided (hmm,
> sorry, should have mentioned it is the link that dies, not the compile).
> So why would an fchdir.h be needed?
If your system really does have an fchdir declaration (in unistd.h?),
th
I noticed that three .m4 files have LGPL copyright notices,
rather than the standard, more-permissive one.
This change corrects what I think must have been an oversight.
Paul, the latter two are yours. Any objection?
* m4/warning.m4: Use the all-permissive copyright notice
recomm
Eric Blake <[EMAIL PROTECTED]> wrote:
> To my knowledge, gettext does not depend on fchdir (as evidenced by the fact
> that it builds on mingw). But coreutils, findutils, tar, and gzip all use
> gnulib directory traversal.
When I think of gnulib directory traversal, I think of its lib/fts.c.
I kn
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
>> Right.
>> I did a survey, some time ago, of reasonable porting targets, and all
>> had fchdir. Eventually I should remove the test for fchdir, too.
>
> FYI, mingw is anothe
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Btw, here are links to modules that failed to build on my machine:
>
> http://autobuild.josefsson.org/gnulib/gnulib.html#fts-lgpl
> http://autobuild.josefsson.org/gnulib/gnulib.html#savewd
Nice.
Here's a proposed (but untested) patch. Gotta run.
[EMAIL PROTECTED] (Karl Berry) wrote:
> since no one cares if gzip can't recursively compress or decompress a
> hierarchy that's really deep or that contains very long names.
>
> Really?
Hi Karl!
I figure if someone cared, it would have been fixed in the last 10 years ;-)
> Well, I guess
o gnulib.
Below, there's also a patch for coreutils adding the mandatory test
and NEWS entry.
[gnulib]
2006-12-03 Jim Meyering <[EMAIL PROTECTED]>
* lib/fts.c (fts_load): Don't set sp->fts_dev here, since
p->fts_statp may not yet be defined.
(fts_read)
Georg Schwarz <[EMAIL PROTECTED]> wrote:
> coreutils 6.6 fails to compile on IRIX 5.3 like this:
Thanks for the report.
For starters, I suggest that you try to use a different compiler.
> lorenz 10% env GREP=/usr/sbin/grep ./configure --prefix=/usr/local
> checking build system type... mips-sgi-i
Thanks for the details.
For the record, I'm sending this to bug-gnulib, so others know, too.
From: Georg Schwarz <[EMAIL PROTECTED]>
Subject: Re: coreutils 6.6 fails to compile on IRIX 5.3
Date: Sun, 3 Dec 2006 23:31:31 +0100
To: Jim Meyering <[EMAIL PROTECTED]>
Am 03
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 gone through the conversion process once more, and
pushed the result to the usual place:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=summary
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> Does anyone object to my removing the $Id...$ strings from those files?
>> They will serve no purpose once we migrate.
>
> I'd rather not remove them as long as we ar
[EMAIL PROTECTED] (Karl Berry) wrote:
> Do you really care whether any of the following files (the only ones
> affected in gnulib) contain an CVS/RCS-style $Id...$ string?
>
>COPYING
>
> COPYING has no $Id$. What am I missing?
this?
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/1
I did not include bootstrap tool version information in the announcement
for coreutils-6.7. Not a big deal, of course, but with the following
changes, that won't happen again. Cc'ing bug-gnulib, since the announce-gen
script is now there.
Now, if you invoke announce-gen with --bootstrap-tools=..
FYI, I've just done this:
* build-aux/announce-gen ($VERSION): Don't use of $Revision...$.
Instead, use Emacs' time-stamp write hook. Note that the time is UTC.
Index: build-aux/announce-gen
===
RCS file: /sources/gn
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> I now have coreutils-6.7 installed on all local systems.
Thanks for the quick results!
I'm Cc'ing the lists.
> There were no build issues, but there is one minor problem on two
> systems:
>
> NetBSD 1.6:
> % /usr/local/bin/uptime
> /us
Paul Eggert <[EMAIL PROTECTED]> wrote:
> How about the following patch instead? It seems a bit more
> straightforward. However, I don't fully understand the problem so I
> may well have gotten it wrong.
>
> 2006-12-11 Paul Eggert <[EMAIL PROTECTED]>
>
> * m4/openat.m4 (gl_FUNC_OPENAT): Do
Hi Simon,
[For background, see
http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00336.html ]
I'm sure you recall that the base64 program (relatively new to coreutils)
cannot decode its own output, unless we resort to use of the sledgehammer
--ignore-garbage option.
This is a pretty u
Eric Blake <[EMAIL PROTECTED]> wrote:
> Solaris 8 gets this particular test correct, as does CVS cygwin. So your
> failure report means that we have just uncovered a glibc bug. POSIX
> requires the following behavior when stdin is seekable:
>
> $ echo 1 2 3 | tr ' ' '\n' > file
> $ (sed -ne 1q; c
Bruno Haible <[EMAIL PROTECTED]> wrote:
> For some complicated reasons (too long to explain here), gettext needs to
> use safe-read.h with a C++ compiler on mingw and cygwin. Is this patch ok
> with you?
>
> 2006-12-23 Bruno Haible <[EMAIL PROTECTED]>
>
> * lib/safe-read.h [C++]: Wrap decla
The following patch fixes a test failure in coreutils-6.N (N <= 7),
when run on a system using glibc-2.4.
2006-12-24 Jim Meyering <[EMAIL PROTECTED]>
Work around an fchownat bug in glibc-2.4:
http://lists.ubuntu.com/archives/ubuntu-users/2006-September/093218.html
201 - 300 of 3902 matches
Mail list logo
