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 for
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 ker
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:
> 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 mism
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:0
Mathias Brodala wrote:
> Package: coreutils
> Version: 8.5-1
> Severity: grave
> Justification: renders package unusable
>
> Building coreutils fails on the test touch/now-owned-by-other. I see the
> same result when building via pbuilder, thus I’d assume it’s nothing
> about my environment.
>
> Se
le non-cylinder alignment
> (http://bugs.debian.org/579948).
Thanks! I've applied that.
However, since it would have made a test fail,
I first applied this change:
>From a582ca642f4817dd02e65a3ecc55e951008969b2 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 26 Jun 2010 09:22:59 +020
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
> ntp:x:106:108::/home/
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
Bruno Haible wrote:
> Jim Meyering wrote:
>> # Test with seekable stdin; the followon process must see remaining data.
>> -cat < ${p}in.tmp
>> +cat < ${p}in.tmp
>
> This can be simplified to:
>
> tr @ '\177' < ${p}
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
> Date: Mon, 28 Sep 2009 11:00:05 +0200
> Subject: [PATCH] don't read-uni
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
Date: Mon, 28 Sep 2009 11:00:05 +0200
Subject: [PATCH] don't read-uninitialized for \177 in a here-doc
A DEL (0177, dec 1
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
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
Date: Sun, 27 Sep 2009 08:41:55 +0200
Subject: [PATCH] test-yesno: use here document *without* parameter
ass. (ls-misc fails with
> the same output as you posted)
Thanks for finding the root cause.
I've fixed it upstream like this:
>From 9403417175b40656bbaac0f109841c90f9c05838 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 6 Sep 2009 18:35:40 +0200
Subject: [PATCH] tests: ls-misc: don't let a bogus umask
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
Date: Wed, 22 Apr 2009 08:45:27 +0200
Subject: [PATCH] sort -m: don't segfault when output fil
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
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 do
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 n
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,
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.
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 t
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 fi
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)
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 experime
"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]:
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 f
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 rob
has the right inode) and I'm not sure that I can
> think of a way 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?
[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 se
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 t
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 * --
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 por
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
>>
[ 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 termina
Package: libssl0.9.8
Version: 0.9.8-3
Severity: grave
Justification: renders package unusable
This is mainly a guess/warning.
A few minutes ago I ran aptitude to upgrade
all but the libc6 packages and pulled in 0.9.8a-1
versions of libssl and openssl. But right after an
uneventful install, I saw
Anthony Towns 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 effect when
39 matches
Mail list logo
