Ralf Wildenhues [EMAIL PROTECTED] wrote:
With coreutils 5.96, I get three failures on AIX 4.3.3, namely:
cp/fail-perm, rm/inaccessible, help-version.
...
rm: cannot remove `rel': The file access permissions do not allow the
specified action.
---
rm: cannot remove `rel': Permission denied
-27 Jim Meyering [EMAIL PROTECTED]
| * src/chgrp.c: Support new options: --preserve-root and
| --no-preserve-root. Somehow this program was skipped when those
| options were added to chown, chmod, and rm. Reported by
| [EMAIL PROTECTED] in http
Ralf Wildenhues [EMAIL PROTECTED] wrote:
I need this patch for successful `make check' on a GNU/Linux with
non-English locale settings.
Applied. Thanks.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Ralf Wildenhues [EMAIL PROTECTED] wrote:
On powerpc-apple-darwin8.2.0, I get one test failure:
Cheers,
Ralf
$ cd tests/du
$ make check TESTS=basic VERBOSE=yes
...
out exp differ: char 1, line 1
+ fail=1
+ test 1 = 1
+ diff -u out exp
--- out 2006-05-27 15:14:12.0 -0500
+++ exp
Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hi Jim,
* Jim Meyering wrote on Sun, May 28, 2006 at 03:48:21PM CEST:
Ralf Wildenhues [EMAIL PROTECTED] wrote:
With coreutils 5.96, I get three failures on AIX 4.3.3, namely:
cp/fail-perm, rm/inaccessible, help-version.
$ env VERBOSE=yes TESTS
Vasek Potocek [EMAIL PROTECTED] wrote:
I think I have found some bug in chmod.
...
touch a
mkdir b
touch c
cd b
chmod a-x ../*
makes a segmentation fault.
The versions are:
chmod (GNU coreutils) 5.93
Fedora Core 5 on a i686 (2.6.16-1.2111_FC5)
glibc 2.4
Thank you for the report.
Justin Pryzby [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.94-1
Severity: minor
Tags: upstream patch
X-Fuzzies-Translation: yes
:.!man ls |grep -i sort
Reformatting ls(1), please wait...
Sort entries alphabetically if none of -cftuSUX nor --sort.
Ralf Wildenhues [EMAIL PROTECTED] wrote:
I get 3 failures on hppa2.0w-hp-hpux11.23:
Regarding this one,
misc/close-stdout
it's because HP-UX's exec-family functions are not POSIX conforming.
As described in http://www.opengroup.org/susv3xsh/execl.html, calling
exec* with one or more of the
Albert Chin [EMAIL PROTECTED] wrote:
On Sun, May 28, 2006 at 07:58:24PM +0200, Jim Meyering wrote:
I have to confess that I wonder if it's worth trying to work around
bugs in AIX 4. Is it still officially supported? Is it used by many?
I haven't had access to such a system for a few years
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
it's because HP-UX's exec-family functions are not POSIX conforming.
Thanks for explaining this. The first failure, though, I think is
due to an unportable use of \ and \ in a sed pattern. And the
other failures
Ian Jackson [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
-davenant:~ strace -e trace=lstat64 /bin/ls --sort=none -i
/export/mirror/Repository/data-md5 21 | head
lstat64(/export/mirror/Repository/data-md5/063096bcf34e489e5a6c3a7a20214368,
{st_mode=S_IFREG|0664, st_size=834,
I wrote:
Thanks for the report.
You're right that in some cases ls could be optimized to avoid the
lstat calls. However deciding when to do it is not easy.
It is possible
- when dirent.d_ino is available (this is easy), and
- when dirent.d_ino is guaranteed to be valid (this is tricky)
I wrote:
2006-02-25 Eric Blake [EMAIL PROTECTED]
In ls, avoid calling stat for --inode (-i), when possible.
* src/pwd.c (NOT_AN_INODE_NUMBER, D_INO): Move to ...
* src/system.h: ... here, for use in ...
* src/ls.c (main): ... here. Prefer dirent.d_ino to stat when
Ian Jackson [EMAIL PROTECTED] wrote:
Ian Jackson writes (Re: Bug#369822: ls -i stats unnecessarily):
There are I think two approaches to this problem:
* find a list of mountpoints in some system-specific way
for each one stat mountpoint/..
compare device and inode with those of the
Michael Stone [EMAIL PROTECTED] wrote:
Have you seen this bug report?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329451
Yes.
I've just dealt with it on the upstream trunk:
2006-06-03 Jim Meyering [EMAIL PROTECTED]
Make `cp --link --no-dereference' work also on systems where
Wiktor Wandachowicz [EMAIL PROTECTED] wrote:
2006/5/27, Jim Meyering [EMAIL PROTECTED]:
Many packages like the coreutils use the .po files available via
the Translation Project. In this case, I updated all .po files
just prior to release of 5.96. At that time, the latest pl.po
file
Paul Eggert [EMAIL PROTECTED] wrote:
Jim, should I also install this patch on the 5.9x branch of coreutils?
2006-06-05 Paul Eggert [EMAIL PROTECTED]
Fix problems when building with Solaris/SVR4/etc. make, which uses a
different and somewhat bogus implementation of VPATH. In
and
the stable branch (tests coming, too):
2006-06-07 Jim Meyering [EMAIL PROTECTED]
Ensure that cat works with any of the options, -A -v -e -E -T,
when applied to files in /proc and /sys, even when the FIONREAD
ioctl produces nonsensical results. Before this change, cat would
Rafal Maszkowski [EMAIL PROTECTED] wrote:
I have sent the result to [EMAIL PROTECTED] and made available as
ftp://sunsite.icm.edu.pl/packages/private/rzm/patches/coreutils-5.96.pl.po
Thank you!
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Paul Eggert [EMAIL PROTECTED] wrote:
...
(gdb) print merge_buffer_size
$1 = 185835729
Wow. That is a huge number. It indicates that there is at least one
line of text in your file that is 185 MB long. Or, that there is a
bug in 'sort' or in your compiler or debugger or whatnot.
Can you
done this instead:
2006-06-11 Jim Meyering [EMAIL PROTECTED]
Setting TIME_STYLE=long-iso in the environment would make the
cp/same-file test fail.
* tests/envvar-check (vars): Add TIME_STYLE to the list.
* tests/cp/same-file: Revert last change.
Source
Jim Meyering [EMAIL PROTECTED] wrote:
Thanks for looking into that, but the problem persists
if e.g., TIME_STYLE=long-iso is set in the environment.
I've done this instead:
2006-06-11 Jim Meyering [EMAIL PROTECTED]
Setting TIME_STYLE=long-iso in the environment would make
Paul Eggert [EMAIL PROTECTED] wrote:
Sorry, I didn't know about it. I installed the following obvious fix
in the trunk. Jim, OK to install this in the 5.9x branch?
Yes. Thanks.
2006-06-12 Paul Eggert [EMAIL PROTECTED]
* doc/Makefile.am (check-texinfo): Use $(_W) and $(W_) instead
Ralf Wildenhues [EMAIL PROTECTED] wrote:
...
* tests/du/Makefile.am (TESTS_ENVIRONMENT): Pass $(PERL), for
files0-from test.
Applied. Thank you.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
[EMAIL PROTECTED] (Bob Proulx) wrote:
goesh wrote:
Further, i have used find . -print
to do the same thing, however, i really like having the absoulte path in
outputs such as ls -ltr, and i could not see a way to get find to do
this.
...
$ ls -ltrZ
Well, I can't think of a way to have
[EMAIL PROTECTED] (Bob Proulx) wrote:
Building CVS corutils on HP-UX 11.11 produces the following test
failure for the inaccessible test. It is expected to fail. But it is
expected to fail with a different message. I am not sure what the
best way to handle differences such as this.
...
Paul Eggert [EMAIL PROTECTED] wrote:
Thanks, Andreas. I have filed this as a Debian bug (against glibc) here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373930
A possible workaround for coreutils is to use a path of more than
16384 bytes in length for the test, rather than just more
Dan Jacobson [EMAIL PROTECTED] wrote:
Could check for e.g., sleep 4 5
Sorry, but that's legitimate usage,
so wouldn't want to give a diagnostic about it.
You can currently say sleep 5h 3m 20s.
And sleep 4 5 is equivalent to sleep 9.
Other implementations (e.g., solaris) work the same way.
François Giron [EMAIL PROTECTED] wrote:
Hello,
I have a problem with coreutil update. I do fink update-all, then
fink rebuild coreutils; but it's the same :
Making check in basename
make check-TESTS
PASS: basic
==
All 1 tests passed
==
Making check in
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
Here's a patch to skip this test on such systems:
I think that is the best answer. Because the behavior is known and
the best that can be done at this time.
The skip test patch worked fine for me to skip the test. But it was
too
[EMAIL PROTECTED] (Bob Proulx) wrote:
Trying to build today's CVS version of coreutils on an ia64 machine
running Debian GNU/Linux Sarge/stable I get the following assertion
failure from pwd-long. This is using Debian's stock stable release of
glibc 2.3.2 and gcc 3.3.5 running a linux 2.6.12
Since ftruncate has been used unconditionally in shred since 1999,
this seems like a safe bet. I suspect it'll eventually be ok to
remove the SysV-ish lib/ftruncate.c, as well.
I've just made this change in coreutils (trunk, not branch):
2006-06-18 Jim Meyering [EMAIL PROTECTED
-directory failed.
Not likely.
2006-06-18 Jim Meyering [EMAIL PROTECTED]
* getcwd-path-max.m4 (gl_FUNC_GETCWD_PATH_MAX): Fix typo.
Low-probability clean-up should be to use rmdir to get rid of
the just-created directory, not unlink.
Index: m4/getcwd-path-max.m4
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
I should have created a directory whose abs. name length
is a little *larger* than 16K, not just smaller.
Does it provoke the failed assertion if you change this line
size_t buf_len = 16 * 1024;
to e.g., this:
size_t buf_len
Jim Meyering [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
I should have created a directory whose abs. name length
is a little *larger* than 16K, not just smaller.
Does it provoke the failed assertion if you change this line
size_t buf_len = 16
[EMAIL PROTECTED] (Bob Proulx) wrote:
...
One thing that I am a little worried about by the test is the initial
mkdir call.
if (mkdir (dir_name, S_IRWXU) 0 || chdir (dir_name) 0)
{
fail = 3; /* Unable to construct deep hierarchy. */
That also fails if remnants of
François Giron [EMAIL PROTECTED] wrote:
Le 18 juin 06 à 19:33, Bob Proulx a écrit :
François Giron wrote:
I transmit to you the results of tests:
% make -C tests/chgrp TESTS=basic
make: Nothing to be done for `all'.
Unfortunately the instructions given to you were missing a check
target
Jim Meyering [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bob Proulx) wrote:
...
One thing that I am a little worried about by the test is the initial
mkdir call.
if (mkdir (dir_name, S_IRWXU) 0 || chdir (dir_name) 0)
{
fail = 3; /* Unable to construct deep
François Giron [EMAIL PROTECTED] wrote:
...
% env VERBOSE=yes make -C tests/chgrp check TESTS=basic
make check-TESTS
+ chgrp --version
chgrp (GNU coreutils) 5.96
...
+ framework_failure=0
+ mkdir basic.13520
mkdir: cannot create directory `basic.13520': Permission denied
+
/fcntl.h:226: error: previous declaration of 'tee' was here
Since coreutils always defines _GNU_SOURCE such types of conflicts can
happen any time.
Thanks.
I've just fixed this on the trunk and branch.
2006-06-22 Jim Meyering [EMAIL PROTECTED]
* src/tee.c (tee_files): Rename from tee
This is a stable release.
Two points are worth special mention.
I built it using autoconf tools from cvs of June 23. Normally, I would
not use development infrastructure to create a stable coreutils release,
but since autoconf-2.60 is so near, and since I did it for 5.96,
too, I think it's a
Pádraig Brady [EMAIL PROTECTED] wrote:
The reason for this I think is so that one gets accurate totals,
as the following will only give subtotals for each invocation of wc,
if there are enough files to make the cmd line go above the max len.
find -print0 | xargs --null wc
Right.
Might be
fixed it on the trunk with the patch below.
Will look at the branch later.
2006-06-26 Jim Meyering [EMAIL PROTECTED]
* NEWS: rm no longer fails to remove an empty, unreadable directory
* src/remove.c (remove_cwd_entries): If we can't open a directory,
and the failure
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
The description of wc's --files0-from is nearly identical
to that of du. I've added an example:
...
[EMAIL PROTECTED]
+find . -name '*.[ch]' -print0 | ./wc -L --files=- | tail -n1
[EMAIL PROTECTED] example
Here you are using
Paul Eggert [EMAIL PROTECTED] wrote:
Matt Keenan [EMAIL PROTECTED] writes:
Making a patch from the debian sources is not a difficult task
and I can provide one if necessary.
On thinking about it further, I like the idea of having 'uniq' be
consistent with 'sort', but I'd prefer 'uniq' to
Matt Keenan [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
[snip snip]
I agree, and think I wrote exactly the same thing: uniq needs the
same
-k key-selection options as sort -- probably in response to a request
to integrate the Debian patch. I went to look for it a couple days ago
Pádraig Brady [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Hi Matt,
I'm glad you're willing to work on this.
It's an often-requested feature.
Unfortunately, the Debian -W patch was not acceptable.
It did not allow the same flexibility that sort does in
selecting keys. To provide
Pádraig Brady [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
The description of wc's --files0-from is nearly identical
to that of du. I've added an example:
...
[EMAIL PROTECTED]
+find . -name '*.[ch]' -print0 | ./wc -L --files=- | tail
[EMAIL PROTECTED] (Bob Proulx) wrote:
The HP-UX /bin/sh using command tracing (set -x) and stderr
redirection behaves badly when stderr is redirected before stdout. I
tested on HP-UX 10.20, 11.0, 11.11, and 11.23 and all had this
problem. Here is an example:
$ /bin/sh -xc ': 2/tmp/err
it now.
I've made this change:
2006-06-30 Jim Meyering [EMAIL PROTECTED]
* tests/stty/basic-1: Work around an intermittent test failure
on HP-UX 11.11. Report and analysis from Bob Proulx.
http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/7475
Index: tests/stty
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 6/11/2006 2:32 AM:
Jim Meyering [EMAIL PROTECTED] wrote:
Thanks for looking into that, but the problem persists
if e.g., TIME_STYLE=long-iso is set in the environment.
I've done this instead:
2006-06-11 Jim Meyering [EMAIL
In case some application is using coreutils' revamped src/remove.c
(only on the trunk) in a context where small leaks triggered by unusual
conditions can make a difference, here's an FYI:
2006-07-03 Jim Meyering [EMAIL PROTECTED]
Plug another unusual leak.
(AD_mark_helper
Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello there,
This patch against CVS HEAD fixes some trivial typos, and makes some
spellings a bit more consistent.
Thank you.
I've applied that.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Paul Eggert [EMAIL PROTECTED] wrote:
I installed this to sync from gnulib to coreutils. Most of this is
for ctype.h, where gnulib no longer cares about the obsolete pre-C89
bugs with things like isprint (255).
2006-07-09 Paul Eggert [EMAIL PROTECTED]
Adjust to recent updates from
Rüdiger Willmann [EMAIL PROTECTED] wrote:
I guess I found a bug in csplit. (csplit (coreutils) 5.2.1 with debian 3.1
sarge):
csplit crashes with a memory access violation
when trying to split a file with very long lines.
Thanks for the report.
That was probably fixed in coreutils-5.90.
The
Paul Eggert [EMAIL PROTECTED] wrote:
As a result of the recent changes, the files lib/chdir-safer.c,
lib/chdir-safer.h, and m4/chdir-safer.m4 can be removed from
coreutils. This is because mkdir-p no longer uses the open/fchdir
method; it simply uses mkdir, on the theory that you can't close
Thomas Schwinge [EMAIL PROTECTED] wrote:
Hello!
#v+
2005-12-05 Andreas Gruenbacher
* src/copy.c [!HAVE_FCHOWN]: Define fchown(...) to -1.
(set_owner, preserve_author): New functions, factored out of copy_reg.
(copy_reg): Use them.
(copy_internal): Use them here,
Thomas Schwinge [EMAIL PROTECTED] wrote:
Hello!
Before I start digging deeper: can someone imaging offhand why `touch'
broke?
#v+
[EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/touch foo
[EMAIL PROTECTED]:/var/tmp/coreutils/build $ ls -l foo
-rw-r--r-- 1 thomas users 0 Jan 1 1970 foo
I found two bugs in ls.
Also, the df change mentioned below is actually more of a fix
than a feature. For now, these changes are only on the trunk.
Here are the changes:
2006-07-21 Jim Meyering [EMAIL PROTECTED]
Fix another bug: ls --indicator-style=file-type would call
stat
I've just done this:
* src/su.c (usage): Correct typo in --help output: s/commmand/command/
Reported by Tim Waugh.
Also remove the comment duplicating much of --help output.
Index: src/su.c
===
RCS file:
included the net diff for src/ls.c below.
See CVS for the individual deltas:
2006-07-25 Jim Meyering [EMAIL PROTECTED]
* src/ls.c (gobble_file): When handling a stat-failed entry,
print the entry name not the absolute_name -- to be consistent
with the usual case
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
?- ? ???? cwd
How about outputting something like this instead?
d? ? ???? cwd
The file type is typically known, so it can be listed as d instead
Paul Eggert [EMAIL PROTECTED] wrote:
I don't think it is a good idea to make
chmod 500 dir
behave differently than
chmod 0500 dir
That simply seems too subtle and will be too confusing to most people.
It is a bit subtle, and if there is consensus on this I'd be willing
to remove
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
?- ? ???? cwd
How about outputting something like this instead?
d? ? ???? cwd
The file type is typically known, so it can be listed as d instead
[EMAIL PROTECTED] (Bob Proulx) wrote:
Paul Eggert wrote:
* tests/cp/fail-perm: Use chmod 0500 rather than chmod 500.
--- tests/cp/fail-perm 28 May 2006 12:11:35 - 1.10
+++ tests/cp/fail-perm 25 Jul 2006 18:37:23 -
-chmod 500 D || framework_failure=1
+chmod 0500
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
If we remove this feature, I'd like to change things to be 100%
consistent with Solaris, and to preserve the setgid bit even if the
user says chmod 0755 DIR.
I think that is the right approach.
I started
Eric Blake [EMAIL PROTECTED] wrote:
Based on the fact that you addressed the obsolete bug-sh-utils list, you
probably need to upgrade. sh-utils was absorbed by coreutils, which is
now at version 5.97.
According to Mixo Shiburi on 8/2/2006 6:23 AM:
The date command seems to have an issue
Mike Frysinger [EMAIL PROTECTED] wrote:
any chance of getting the other terms i posted a while back added as well ?
i posted a patch which sorted TERM alphabetically (minor thing) and added:
TERM ansi
TERM color-xterm
TERM gnome
TERM konsole
TERM kterm
TERM rxvt-cygwin
TERM
Paul Eggert [EMAIL PROTECTED] wrote:
The Translation Project has changed their repository format, and
the coreutils procedure for getting translations no longer works.
I'll temporarily work around this problem by getting them by hand.
The first step is to remove the old code so that people
Coreutils version 6.0 has been released.
If you haven't heard about the GNU coreutils, the FAQ is a good
place to start: http://www.gnu.org/software/coreutils/faq/
Coreutils development branched after the stable 5.92 release.
Since then, there have been five releases from the stable branch:
5.93
Aug 2006 16:20:49 - 1.1221
+++ lib/ChangeLog 15 Aug 2006 18:19:57 -
@@ -1,3 +1,16 @@
+2006-08-15 Jim Meyering [EMAIL PROTECTED]
+
+ * at-func.c: New file, with the logic of all emulated at-functions.
+ * openat-priv.h: Include errno.h and define ENOSYS
Michael Stone [EMAIL PROTECTED] wrote:
test failure:
/usr/bin/make check-TESTS
make[4]: Entering directory
`/tmp/buildd/coreutils-6.0/build-tree/coreutils-6.0/tests/ls'
PASS: stat-failed
ls: cannot access d/s: Permission denied
out exp differ: char 2, line 1
1c1
s
---
s@
FAIL:
Paul Eggert [EMAIL PROTECTED] wrote:
One thing we noticed right away when putting coreutils 6.0 in a place
where others could use it is that df /usr no longer outputs a
header. This change isn't intended, surely. While fixing this I
noticed that the new behavior of exiting with nonzero
Michael Stone [EMAIL PROTECTED] wrote:
On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote:
What version of Linux is that?
2.6.17
From the name of the directory, it's probably a tmpfs file system.
actually it's xfs. it's inside a pbuilder chroot, so the mtab is going
Andreas Schwab [EMAIL PROTECTED] wrote:
The == operator is not a portable test operator, it should be = instead.
2006-08-16 Andreas Schwab [EMAIL PROTECTED]
* tests/cp/acl: Don't use non-portable == operator for test.
Applied. Thanks.
Bruno Haible [EMAIL PROTECTED] wrote:
On Linux/x86 (Linux 2.4.21, glibc-2.3.6) I get:
make[3]: Entering directory `/build/coreutils-6.0/tests/dd'
dd iflag=noatime updated atime; O_NOATIME bug in your kernel?
FAIL: misc
Your announcement says that O_NOATIME is only supported in Linux =
Bruno Haible [EMAIL PROTECTED] wrote:
The problem is the gzip call in Makefile.maint. make is GNU make 3.79.
gzip is 1.2.4, and it prints --help output to stderr.
The appended patch fixes the problem.
Bruno
2006-08-16 Bruno Haible [EMAIL PROTECTED]
* Makefile.maint
it for me:
[This problem shows up only if you have sufficient ACL libraries and headers
installed, and run in a directory on a file system that supports ACLs. ]
2006-08-16 Jim Meyering [EMAIL PROTECTED]
* tests/cp/Makefile.am: Don't mark acl as XFAIL.
* tests/cp/acl: Instead, skip
Coreutils version 6.0 has been released.
I'm planning to release coreutils 6.1 soon (but not before Saturday),
so if any of you can do further testing, please do it sooner, and report
any problems.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
-automake* pack-w3* texmacs/
cvsroot/ gnulib/pack-binutils* pbbuttons/ wotan/
Hi Andreas,
Thanks for the report.
Here's a patch:
2006-08-17 Jim Meyering [EMAIL PROTECTED]
ls -CF would misalign columns in some cases.
* src/ls.c (get_type_indicator): New
the patch:
2006-08-18 Jim Meyering [EMAIL PROTECTED]
* gethrxtime.m4 (gl_PREREQ_GETHRXTIME): Reverse sense of test for
CLOCK_MONOTONIC. Otherwise, linking a gethrxtime-using program
with $(LIB_GETHRXTIME) could fail due to unresolved clock_gettime.
Reported by Gabor
Jim Meyering [EMAIL PROTECTED] wrote:
Gabor Z. Papp [EMAIL PROTECTED] wrote:
...
Tried to compile coreutils 6.0 from alpha.gnu, and here is the result.
...
gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreutils.a
../lib/libcoreutils.a
../lib/libcoreutils.a(gettime.o
I've just posted the above question to fedora-list:
https://www.redhat.com/archives/fedora-list/2006-August/msg02264.html
Feedback welcome.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Alan, thanks for the report and patch.
FYI, I expect all !HAVE_FTRUNCATE code to be removed sometime in 2007.
2006-08-19 Jim Meyering [EMAIL PROTECTED]
* NEWS: Fix cp --sparse so that it preserves tail-end sparseness, even
when the file's apparent size is not a multiple of its
2006-08-19 Jim Meyering [EMAIL PROTECTED]
Some of my 2006-07-03 changes to tests/*/Makefile.am were being
backed out due to updates provoked by the copyright changes.
* tests/Makefile.am.in (PATH): Prepend $(VG_PATH_PREFIX), so that
it propagates to the derived
A documentation change:
* README: Describe potential pre-C99 build failure, and work-around.
Index: README
===
RCS file: /fetish/cu/README,v
retrieving revision 1.27
diff -u -r1.27 README
--- README 17 Aug 2006 19:58:18
2006-08-19 Jim Meyering [EMAIL PROTECTED]
* tests/ls/stat-dtype: Test for the 2006-08-17 `ls -CF' fix.
Index: tests/ls/stat-dtype
===
RCS file: /fetish/cu/tests/ls/stat-dtype,v
retrieving revision 1.6
diff -u -r1.6 stat
, with minor syntactic changes:
2006-08-19 Jim Meyering [EMAIL PROTECTED]
Avoid test failure when `make check' is run through debuild.
* tests/help-version: Ensure that $SHELL is set to some value
and exported. Patch from Sven Joachim. For details, see
http
Coreutils version 6.1 has been released.
If you haven't heard about the GNU coreutils, the FAQ is a good
place to start: http://www.gnu.org/software/coreutils/faq/
This is a bug-fix and portability-fix release.
Thanks to everyone who's helped.
Paul Eggert [EMAIL PROTECTED] wrote:
I installed this patch, which mostly consists of removing files and
replacing them with a bootstrap script. Now, when you check things
out from CVS, you must run ./bootstrap before running ./configure.
The upside is that the CVS sources get simpler and we
Paul Eggert [EMAIL PROTECTED] wrote:
Please let me know if there are problems (there will undoubtedly
be some, as it's a disruptive change)
One small bit of fallout:
2006-08-21 Jim Meyering [EMAIL PROTECTED]
* src/od.c: Now that HAVE_UNSIGNED_LONG_LONG is no longer defined
type option given
--- 1
! dircolors: k:1: invalid line; missing second token
quote...
other-wr...
FAIL: simple
Thanks for reporting that.
Here's how I've fixed it:
2006-08-21 Jim Meyering [EMAIL PROTECTED]
* tests/dircolors/simple (a): Don't fail with an unexpected diagnostic
Frederik Eaton [EMAIL PROTECTED] wrote:
...
The question is, is there a reason why users wouldn't always want a
copyFile function to remove the destination first?
Sometimes, cp --remove-dest will fail, because the destination
cannot be removed. Yet cp without that option would be able to
James Youngman [EMAIL PROTECTED] wrote:
On 6/16/06, James Youngman [EMAIL PROTECTED] wrote:
On 6/16/06, Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
find $PWD/* -printf '%A@ %p\n'|sort -nr
Wow, learn something every day. Thanks.
Alas, though
Hi Bruno,
Thanks for all of your recent BeOS porting work.
We've received very few reports about BeOS problems, other than yours.
I'm curious: what's your motivation for using it?
Bruno Haible [EMAIL PROTECTED] wrote:
...
After producing this patch, I noticed that the replacement 'statfs' that
Matthew Burgess [EMAIL PROTECTED] wrote:
...
Is there anything I can do to help out with regard to this? Would you
accept patches that add i18n related testcases, which XFAIL for the time
being?
Of course!
Test case additions are always welcome.
mwoehlke [EMAIL PROTECTED] wrote:
Mike Frysinger wrote:
On Thursday 24 August 2006 17:03, mwoehlke wrote:
https://savannah.gnu.org/bugs/?func=detailitemitem_id=15043
Is this going to get fixed, or what? There is a trivial fix available,
it just needs someone that knows how to make it
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 8/25/2006 11:18 AM:
As usual, it requires an addition to the test suite.
That is a little tricky, since the test will have to be
skipped on a file system without d_type support.
Why? The test is still valid on a system without
Jim Meyering [EMAIL PROTECTED] wrote:
mwoehlke [EMAIL PROTECTED] wrote:
Mike Frysinger wrote:
On Thursday 24 August 2006 17:03, mwoehlke wrote:
https://savannah.gnu.org/bugs/?func=detailitemitem_id=15043
Is this going to get fixed, or what? There is a trivial fix available,
it just needs
Update of bug #15043 (project coreutils):
Status:None = Fixed
___
Follow-up Comment #4:
Thanks again.
I've just checked in a fix for coreutils-6.2:
701 - 800 of 4474 matches
Mail list logo
