Jim Meyering wrote on 08-10-07 11:05: In addition to adding mktemp, I've fixed a few low-probability bugs in rm. This also includes a lot of new code from gnulib, by virtue of coreutils now requiring
Yes. In summary, stable beta releases are "ok to use", according to the author. Don't use the alpha releases for production work, yet. I asked Lasse about this earlier today. Maybe he'll repost his r
Thank you. Here's one way to fix that: diff --git a/tests/misc/chcon b/tests/misc/chcon index 46aaf87..851b415 100755 -- a/tests/misc/chcon +++ b/tests/misc/chcon @@ -6,6 +6,7 @@ if test "$VERBOSE" =
The compression code is stable (it's from stable LZMA SDK). "Beta" refers mostly to the command line tool. It never got all the features that were planned, because development switched to a new branc
Take your pick: http://meyering.net/cu/coreutils-6.9-322-b6904.tar.gz 8.4M http://meyering.net/cu/coreutils-6.9-322-b6904.tar.lzma 3.5M http://meyering.net/cu/coreutils-6.9-322-b6904.tar.gz.sig http:
Here's another snapshot. FYI, I don't expect to make big changes before the next release[*], which will be of those can't-call-it-stable-but-think-it-is ones. [*] Of course, we never know... There ma
probably a gnulib issue, but m4/lseek.m4 causes a broken pipe error to be shown during configure ... doesnt affect the build, so you can prob just consider it a cosmetic issue as for tests, two rm te
Thanks for the testing and quick report. You can avoid this failure if you follow the advice in README. See the "Running tests as root" section, where it says build as a regular user, and run tests w
Hi Jim, That's it. coreutils needs to use also printf-posix, not only vasprintf-posix. Then 'seq' should work. I just wanted to download the new snapshot to make sure seq now works for me, before the
http://meyering.net/cu/coreutils-6.9-340-def15.tar.gz http://meyering.net/cu/ Hi Martin, Thanks for letting me know. It's fixed now. Ok, download is possible now. But seq is still wrong for me. Eithe
Can you please clarify? What I see from previous emails is this: http://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00121.html This refers to some private correspondence, but it's not exactly
Hi Paul, Martin Koeppe <address@hidden> writes: Ok, download is possible now. But seq is still wrong for me. Either include the gnulib printf-posix module, or change seq to use asprintf() instead of
I've added a test for the just-fixed printf bug, included below. Do any of you know of a system on which the printf _function_ would make the very latest printf from coreutils misbehave? ./printf %.2
Here are tarballs and signatures. If I don't hear about problems (feedback about successes would be nice), I'll make a coreutils-6.9.90 test release soon. 3.5M http://meyering.net/cu/coreutils-6.9-ss
i just got the eperm failure when running as root again on amd64 ... but all others passed running as a non-root user on a ppc system yielded these failures: seq printf-surprise but i imagine glibc-2
Jim Meyering wrote on 28-10-07 17:00: Here are tarballs and signatures. If I don't hear about problems (feedback about successes would be nice), The following (build and tests) as root: make bootstra
Jim Meyering wrote on 28-10-07 17:00: Here are tarballs and signatures. If I don't hear about problems (feedback about successes would be nice), I'll make a coreutils-6.9.90 test release soon. On x86
Bauke Jan Douma wrote on 29-10-07 00:09: But I have one difference in make-check results; I am getting: SKIP: fail-eperm.log SKIP: fail-eperm.log (exit: 77) == ./../../../coreutils-6.9-354-68c33a/tes
Bauke Jan Douma wrote on 29-10-07 00:30: Bauke Jan Douma wrote on 29-10-07 00:09: But I have one difference in make-check results; I am getting: SKIP: fail-eperm.log SKIP: fail-eperm.log (exit: 77) =