On Fri, Jul 21, 2023 at 4:38 PM Paul Eggert wrote:
> To fix just this bug (as opposed to the other Gnulib-related bugs that
> may be lurking) try applying the attached Gnulib patch to a grep 3.11
> tarball.
>
> Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.
Thanks
Miquel van Smoorenburg wrote:
I've also filed this as a debian bugreport,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684713
Linux md raid array devices come in two flavours: partionable
(/dev/md_d0) and non-partitionable (/dev/md0). Or at least,
that used to be the case, until kernel
Lucas Nussbaum wrote:
Source: coreutils
Version: 8.13-3.1
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20120419 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Mathias Brodala wrote:
FAIL: misc/tail (exit: 1)
=
...
f-pipe-1.p...
tail: test f-pipe-1.p: stderr mismatch, comparing f-pipe-1.p.E
(actual) and f-pipe-1.p.3 (expected)
*** f-pipe-1.p.E Sat Apr 9 22:58:08 2011
--- f-pipe-1.p.3 Sat Apr 9 22:58:08 2011
Mathias Brodala wrote:
Hi.
Jim Meyering, 11.04.2011 09:13:
Mathias Brodala wrote:
FAIL: misc/tail (exit: 1)
=
...
f-pipe-1.p...
tail: test f-pipe-1.p: stderr mismatch, comparing f-pipe-1.p.E
(actual) and f-pipe-1.p.3 (expected)
*** f-pipe-1.p.E Sat Apr 9 22
Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 26 Jun 2010 09:22:59 +0200
Subject: [PATCH] tests: adjust sun-partition-creating test to conform
* tests/t4000-sun-raid-type.sh: Adjust partition size so the
end falls on a cylinder boundary.
---
tests/t4000-sun-raid-type.sh
Aníbal Monsalve Salazar wrote:
I reproduced this bug, see below.
grep --version
GNU grep 2.6.3
cat /tmp/a
root:x:0:0:root:/root:/bin/bash
anibal:x:1000:1000:Anibal Monsalve Salazar,,,:/home/anibal:/bin/bash
Debian-exim:x:102:104::/var/spool/exim4:/bin/false
retitle 548493 dash: don't read-uninitialized for \177 in a here-doc
reassign 548493 dash
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
It was indeed a bug in dash.
I tracked it down and wrote the patch below:
From 53924ce6da7fece91e57b7238e6aa81a4df636a5 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 28 Sep 2009 11:00:05 +0200
Subject: [PATCH] don't read-uninitialized for \177 in a here-doc
A DEL
Jim Meyering wrote:
It was indeed a bug in dash.
I tracked it down and wrote the patch below:
From 53924ce6da7fece91e57b7238e6aa81a4df636a5 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 28 Sep 2009 11:00:05 +0200
Subject: [PATCH] don't read-uninitialized
Bruno Haible wrote:
Jim Meyering wrote:
# Test with seekable stdin; the followon process must see remaining data.
-cat EOF ${p}in.tmp
+cat EOF |tr @ '\177' ${p}in.tmp
This can be simplified to:
tr @ '\177' EOF ${p}in.tmp
Of course! Thanks.
I've pushed this:
From
/build.php?arch=alphapkg=coreutilsver=7.5-6
Thanks for the report.
Does the following change fix it?
If so, please tell me what version of bash it's using
so I can add that to the commit log.
From 0f02aaf44de2d5dc0470bc9ca979f047df7df024 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer
Kurt Roeckx wrote:
On Sun, Sep 27, 2009 at 08:51:48AM +0200, Jim Meyering wrote:
Thanks for the report.
Does the following change fix it?
If so, please tell me what version of bash it's using
so I can add that to the commit log.
Note that /bin/sh points to dash, not bash. And the same
:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 6 Sep 2009 18:35:40 +0200
Subject: [PATCH] tests: ls-misc: don't let a bogus umask cause test failure
* tests/misc/ls-misc: Set umask to 022. A umask setting permitting
world-write access, e.g., umask o+w, would cause this test to fail
Thanks to Otavio Salvador for finding/reporting this.
Here's the patch I'm considering:
From 570beb56f58bb087a614af885bec7e9cf6b19423 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 22 Apr 2009 08:45:27 +0200
Subject: [PATCH] sort -m: don't segfault when output file
Adam Conrad [EMAIL PROTECTED] wrote:
On Fri, Feb 15, 2008 at 07:16:12PM -0500, Michael Stone wrote:
Could you send an strace from one of the non-working systems? That might
be enough to figure out what's going wrong and whether it can be worked
around.
Attached.
Thanks.
Please double-check
Jim Meyering [EMAIL PROTECTED] wrote:
For the record, here's what I did:
Simulate the lack of openat functions:
ac_cv_func_openat=no ./configure make make check
All tests passed.
Next, pretend we don't have /proc/self/fd support either, by changing
the openat-emulation code
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Thanks for the suggestion. It looks like a good one.
The suggestion also applies to the 'md5' module, after which the 'sha1' module
is modeled.
Yep. md2 and md4 too.
For now, I've pushed the sha1 changes.
But if you apply
Jim Meyering [EMAIL PROTECTED] wrote:
David Shaw [EMAIL PROTECTED] wrote:
Peter Palfrader reported a bug against the sha1 code in paperkey, but
that code actually comes from gnulib, so I'm referring it to you.
The issue comes up (as noted in the comment) if resbuf is not 32-bit
aligned
David Shaw [EMAIL PROTECTED] wrote:
Peter Palfrader reported a bug against the sha1 code in paperkey, but
that code actually comes from gnulib, so I'm referring it to you.
The issue comes up (as noted in the comment) if resbuf is not 32-bit
aligned. Rather than requiring all programs that
Jim Meyering [EMAIL PROTECTED] wrote:
...
Thanks for the suggestion. It looks like a good one.
However, I don't want to change the type of the resbuf parameter.
Here's the change I'm considering:
And of course, coreutils/lib/sha*.c would get the same change.
--
To UNSUBSCRIBE, email
Michael Stone [EMAIL PROTECTED] wrote:
On Wed, Jan 23, 2008 at 09:04:22PM +0100, Lucas Nussbaum wrote:
Note that the mipsel buildd failed in the exact same way.
Yeah, same theory holds. Until it can be duplicated with a manual
build or we get the build logs it ain't gonna be easy to fix. It's
Bram Senders [EMAIL PROTECTED] wrote:
On Wed, Sep 12, 2007 at 07:58:22PM +0200, Jim Meyering wrote:
Thanks for the report.
However, I've just built from the very latest upstream sources
(but probably no change to seq since the 20070907 snapshot)
on bruckner, with CFLAGS=-g ./configure make
Bram Senders [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 6.10~20070907
Severity: serious
Justification: no longer builds from source
Hi there,
I cannot build the current coreutils from experimental from source on
PowerPC, because of a failure in the seq test suite:
...
***
Michael Stone [EMAIL PROTECTED] wrote:
On Tue, Jul 17, 2007 at 03:54:03PM +0200, you wrote:
Alright. Will there be an update? Upstream already is at version 6.9.
I'm aware of the upstream version. The difficulty is with the
integration of the selinux stuff (which wasn't in the experimental
Tshepang Lekhonkhobe [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.97-5
Severity: serious
Justification: no longer builds from source
make[3]: Entering directory
`/home/wena/temp/coreutils-5.97/build-tree/coreutils-5.97/tests/chgrp'
/usr/bin/make check-TESTS
make[4]: Entering
Pierre Habouzit [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.97-5.3
Severity: important
$ /usr/bin/printf '%-1.2500s\n' 'Hello'
Is a quite good testcase :)
FWIW libc printf seems to work properly. Further poking shows that it
may be locale-dependant as the following
Bastian Blank [EMAIL PROTECTED] wrote:
On Sat, Feb 24, 2007 at 04:52:12AM -0800, Steve Langasek wrote:
Bastian, do you have any explanation for this? coreutils now builds
successfully in the test environment Manoj set up using bind mounts, but
still fails on the s390 buildd. What is
peter green [EMAIL PROTECTED] wrote:
reopen 380552
thanks
looks like this is still an issue.
http://buildd.debian.org/fetch.cgi?pkg=coreutils;ver=5.97-5.3;arch=s390;stamp=1170189620
FAIL: pwd-long
Thanks for reporting that.
Somehow, even gnulib's getcwd is failing,
and then the
to rewrite the test so that it would actually work on a
bind mount. Maybe we could only compare the part from pwd-long.tmp on,
but would that still test for whatever failure lead to the test in the
first place?
Thanks.
I've fixed it on the trunk like this:
2007-01-20 Jim Meyering [EMAIL PROTECTED
[EMAIL PROTECTED] (Bob Proulx) wrote:
Michael Stone wrote:
Bastian Blank wrote:
[...]
FAIL: pwd-long
Since this is the only failure listed, I'll assume it's the problem. Was
there any actual diagnostic message in the part you snipped?
Thanks for the report. If you can set the VERBOSE=yes
Thomas Hood [EMAIL PROTECTED] wrote:
If the solution is going to be: to fix the programs that use
the stat program so that they work either with the old or with the
new behavior, and/or to add versioned Conflicts to coreutils for
each package version containing a program that depends on the
Junichi Uekawa [EMAIL PROTECTED] wrote:
reopen 339136
retitle 339136 stat --format behavior change with default newline
thanks
...
Older (sarge system):
...
stat * --format %d %i:|tr : '\n' | head
2054 21186142
2054 21186136
2054 7831563
Newer(current sid):
...
$ stat * --format %d
[ For those reading this via bug-coreutils, the original bug report
is here: http://bugs.debian.org/339136. ]
Thanks for the report.
FYI, this change was mentioned in the NEWS for upstream coreutils-5.3.0,
10 months ago.
With stat, a specified format is no longer automatically newline
Michael Stone [EMAIL PROTECTED] wrote:
On Tue, Nov 15, 2005 at 11:42:12AM +0100, Jim Meyering wrote:
With stat, a specified format is no longer automatically newline terminated.
If you want a newline at the end of your output, append `\n' to the format
string.
Hmm. I don't know if I like
Michael Stone [EMAIL PROTECTED] wrote:
...
My main concern here is that there is no way for someone to use
stat -c %whatever file1 file2
and expect it to work for both syntaxes without reverting to some truely
hideous sed games or somesuch.
But there *is* a way. It's just that the portable
Anthony Towns aj@azure.humbug.org.au wrote:
tag 274705 + patch
thanks
So the relevant code seems to be in src/copy.c, where it checks if
--reply=no was set _and_ the file isn't overwritable; or if -i was
set, or if no option was given and the file isn't overwritable. So
--reply=no has an
37 matches
Mail list logo
