Jim Meyering [EMAIL PROTECTED] writes:
I initially tried something like that, but got too confused by it,
perhaps partly because I wanted to fall back on something like the
current approach when mkdirat didn't work (which is a common case
these days, even on GNU/Linux systems, alas).
What
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
I initially tried something like that, but got too confused by it,
perhaps partly because I wanted to fall back on something like the
current approach when mkdirat didn't work (which is a common case
these days, even
Coreutils version 6.2 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 mostly a bug-fix release. It may be worthy of the stable
label, but since this is the Coreutils, we're being extra careful.
Pádraig Brady [EMAIL PROTECTED] wrote:
...
If we are supporting c89 compilers with this patch,
wouldn't it be worth going the final step and
applying it automatically with configure?
It'd be worthwhile to a few people, certainly, and it'd probably avoid
a few bug reports. I've been trying not
I agree that this is a bug, and I'm interested in fixing this, but I
have little free time right now.
I'd prefer that --wrap can be used to indicate at what position the
tool should expect CR/LF on decoding. If there isn't a CR/LF at that
position, it should abort.
Also, there should be one new
URL:
http://savannah.gnu.org/bugs/?17794
Summary: error: possibly undefined macro: gl_LOCK_EARLY
Project: GNU Core Utilities
Submitted by: schwab
Submitted on: Montag 18.09.2006 um 17:29
Category: None
Here are the symptoms:
make[3]: Entering directory `/r/share1/src/coreutils-6.2/tests/chgrp'
PASS: no-x
PASS: posix-H
FAIL: basic
...
I tracked it down to what appears to be a typo in tests/chgrp/basic,
triggered when the build directory is setgid and the builder has
multiple groups. I
While building coreutils v6.1 on Tru64 Unix, I found a minor typo
breaking the build. Here is a patch to fix it.
diff -ur src-6.1/lib/getaddrinfo.c src-6.1-local/lib/getaddrinfo.c
--- src-6.1/lib/getaddrinfo.c 2006-08-10 09:17:38.0 +0200
+++ src-6.1-local/lib/getaddrinfo.c
Paul Eggert [EMAIL PROTECTED] wrote:
Here are the symptoms:
make[3]: Entering directory `/r/share1/src/coreutils-6.2/tests/chgrp'
PASS: no-x
PASS: posix-H
FAIL: basic
...
I tracked it down to what appears to be a typo in tests/chgrp/basic,
triggered when the build directory is setgid and
Bob Proulx wrote:
Petter Reinholdtsen wrote:
The ANSI C 89 compilers refuses code that fail to declare variables at
the start of the block. I found this problem on RHEL 2.1. The code
refused to compile, and I have to move the variables up to the start
of the block to get it building.
One of
Jim Meyering wrote:
And of course, even with a kernel that supports /proc, you can
create a chroot environment that lacks /proc altogether.
+1
I just wanted to say that I use chroot environments all of the time.
For many uses they are a godsend. I would hate to see behavior
introduced that
To get coreutils 6.1 to build on Tru64 Unix, in addition to the minor
typo reported earlier, I had to change the prototype used for
getnameinfo() to match the on in /usr/include/netdb.h. This ugly
patch solved the issue:
diff -ur src-6.1/lib/getaddrinfo.c src-6.1-local/lib/getaddrinfo.c
---
Jim Meyering wrote:
So, ideally, regular testing should include building not only
on at least four different file system types, but also with and
without a setgid build directory.
I am currently testing both with and without sgid directories. The
results you have seen for i686-gnu-linux and
Here are the symptoms:
./stat-vs-dirent: test failed: /export/duryea: d_ino(42214) != st_ino(2)
./stat-vs-dirent: This may indicate a flaw in your kernel or file system implem\
entation.
./stat-vs-dirent: This flaw won't impact coreutils, but it may well
./stat-vs-dirent: affect other tools,: not
mwoehlke wrote:
I have built coreutils (actually, a nice GNU suite plus a few others
like VIM7) on over a half dozen platforms, including Solaris 2.7, Irix,
HPUX 11.x, AIX... and of course Linux. These are old systems, but they
are still used in production (we keep them because our
Update of bug #17794 (project coreutils):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
I think that was
Follow-up Comment #2, bug #17794 (project coreutils):
There is no gnulib involved.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17794
___
Nachricht geschickt von/durch Savannah
mwoehlke [EMAIL PROTECTED] writes:
people seem to want to only support GNU software
on the latest stable release of Linux
That may be true for other packages but it's not true of coreutils.
Coreutils is built fairly regularly on older systems, even systems
like Solaris 2.6 (released 1997) that
Bob Proulx wrote:
mwoehlke wrote:
I have built coreutils (actually, a nice GNU suite plus a few others
like VIM7) on over a half dozen platforms, including Solaris 2.7, Irix,
HPUX 11.x, AIX... and of course Linux. These are old systems, but they
are still used in production (we keep them
Paul Eggert wrote:
mwoehlke [EMAIL PROTECTED] writes:
people seem to want to only support GNU software
on the latest stable release of Linux
That may be true for other packages but it's not true of coreutils.
Coreutils is built fairly regularly on older systems, even systems
like Solaris 2.6
Follow-up Comment #3, bug #17794 (project coreutils):
Ah, sorry, I misread the example. I guess the right answer is
that coreutils isn't set up to use autoreconf. You can use
bootstrap instead; it gets the pieces that autoreconf would
get, but omits stuff like the lock module that autoreconf
Follow-up Comment #4, bug #17794 (project coreutils):
There is no bootstrap.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17794
___
Nachricht geschickt von/durch Savannah
I installed this to change 'bootstrap' along the lines that we
discussed earlier:
2006-09-18 Paul Eggert [EMAIL PROTECTED]
* bootstrap (symlink_to_gnulib): New function.
(cp_mark_as_generated): Use it, to prefer symlinks-to-gnulib
to copies-of-gnulib.
I noticed that make check left behind a file tests/stty/.saved_size,
because I ran it under GNU Emacs on Solaris 8 and the test is skipped
in that case. I installed this to fix the little problem:
2006-09-18 Paul Eggert [EMAIL PROTECTED]
* tests/stty/row-col-1: Rewrite to avoid
`shuf -i 1-x' complained shuf: invalid input range `x', but the
invalid range is actually `1-x'. I installed this:
2006-09-18 Paul Eggert [EMAIL PROTECTED]
* src/shuf.c (main): Quote the entire range when reporting an
invalid one, rather than just the part that contained the
Paul Eggert wrote:
It's a bit weird, though, that Tru64 has getnameinfo declared but
getaddrinfo is not defined. Is that correct, or am I missing
something?
OSF/1 4.0 declares neither getnameinfo nor getaddrinfo.
OSF/1 5.1 declares both in netdb.h but has this:
#if defined (_SOCKADDR_LEN)
While testing the new mkdir -p stuff I noticed a bug in chmod:
it doesn't operate left-to-right as tradition and POSIX require:
$ mkdir d d/e
$ chmod 0 d/e d
$ chmod a+rwx d d/e
chmod: cannot access `d/e': Permission denied
The last chmod should succeed, but it fails.
I installed the
Bruno Haible [EMAIL PROTECTED] writes:
OSF/1 4.0 declares neither getnameinfo nor getaddrinfo.
OSF/1 5.1 declares both in netdb.h but has this:
#if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
#define getaddrinfo ngetaddrinfo
#else
#define getaddrinfo ogetaddrinfo
#endif
Update of bug #17794 (project coreutils):
Status: Fixed = In Progress
Open/Closed: Closed = Open
___
Follow-up Comment #5:
You can get
Follow-up Comment #6, bug #17794 (project coreutils):
If it serves as any reference point, M4 1.4.6 includes its bootstrap in its
tarball. Someone using the tarball is expected to neither run bootstrap nor
to run autoreconf (a fact that automake checks during 'make distcheck'), but
the files
30 matches
Mail list logo
