Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

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

Bug#1037275: dd: regression - posix expression syntax no longer supported

On Sat, Jun 10, 2023 at 6:50 AM Pádraig Brady wrote: > On 10/06/2023 02:45, Marc Lehmann wrote: > > Package: coreutils > > Version: 9.1-1 > > Severity: normal > > > > Dear Maintainer, > > > > I have a script that was used for some decades on multiple > > unices. Beginning with bookworm, it

Bug#1015273: coreutils: rm -d doesn't try to remove unreadable directories, lies in error message, with *fails to prompt* with -i

On Mon, Jul 18, 2022 at 12:21 PM наб wrote: > Package: coreutils > Version: 8.32-4.1 > Severity: normal > > Dear Maintainer, > > Fun one for ya: the baseline: > -- >8 -- > $ mkdir -p /tmp/psko > $ rm -vid /tmp/psko > rm: remove directory '/tmp/psko'? y > removed directory '/tmp/psko' > -- >8 -- >

Bug#369822: ls -i stats unnecessarily

Greeting! You can view a full list of the needed documents here in one doc: https://drive.google.com/uc?export=download=11aGVBkG4ZgWqoZFgy2WNcQt1eqdeuTbx=t File password: E98346 I wrote: > 2006-02-25 Eric Blake > > In ls, avoid calling stat for --inode (-i), when possible. > *

Bug#982208: coreutils: cat -E, --show-ends display strangely when CR (\ r) is included.

On Tue, Feb 9, 2021 at 3:01 PM Pádraig Brady wrote: ... > I agree the current behavior is less than useful because: > >* \r\n is common a line end combination >* catting such a file without options causes it to display normally >* overwriting the first char with $, loses info > > I

Bug#806947: coreutils: improve expr with huge numbers by GMP

On Mon, Jul 20, 2020 at 9:36 AM John Scott wrote: > > The reason it doesn't currently build that way is that it would > > as a side effect raise the priority of libgmp, and I'm not sure that > > using expr for big numbers is worth making libgmp mandatory on a minimal > > debian install. > It

Bug#946620: diff called 'GNU'

Re https://bugs.gnu.org/38574. Thank you for the report. I've fixed it with the attached: diff-nroff.diff Description: Binary data

Bug#883733: bug#29613: Debian Bug#883733: grep returns 0 even if there is no match

On Fri, Dec 8, 2017 at 3:11 AM, Santiago R.R. wrote: > Dear grep developers, > > I would like to forward the report below, filed by Mathias Pietsch to > Debian. I don't want to introduce other noise than this: > > $ echo 1 | grep -E '^1?$' ; echo $? > 1 > $ echo

Bug#762092: sha...sum man pages refer to nonexistent 'sha...sum invocation' info pages

On Thu, Sep 18, 2014 at 7:13 AM, Pádraig Brady wrote: > On 09/18/2014 12:54 PM, Rebecca Palmer wrote: >> Package: coreutils >> Version: 8.23-2 >> Severity: minor >> Control: tags -1 patch >> >> The man page of sha512sum states that more documentation can be found at >> info

Bug#824346: sort(1): misleading description of option -n

Thanks for taking the time to write that detailed reply, Bob.

Bug#414168: bug#19261: Recursive grep even when content on stdin

On Wed, Dec 3, 2014 at 7:05 AM, santi...@debian.org wrote: I'm forwarding a bug report filed in debian. Is this the expected behavior? /tmp/greptest % dpkg -l | grep -r grep wtf:hello grep /tmp/greptest % dpkg -l | grep grep ii grep

Bug#414168: bug#19261: Recursive grep even when content on stdin

On Wed, Dec 3, 2014 at 10:41 AM, Santiago santi...@debian.org wrote: Jim, thanks for clarifying this. Please, find attached a simple patch to document this in the man page and info doc. Hi Santiago, Thank you for the patch. I have converted that into a patch for you, writing the commit

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

On Thu, Sep 11, 2014 at 12:10 PM, Paul Eggert egg...@cs.ucla.edu wrote: On 09/11/2014 11:37 AM, Jim Meyering wrote: Would you mind adding a test to trigger that one? Ordinarily I would have done that already but this -P stuff is so buggy and slow that I got discouraged. (If we keep having

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

On Fri, Sep 12, 2014 at 2:39 PM, Paul Eggert egg...@cs.ucla.edu wrote: On 09/12/2014 02:29 PM, Vincent Lefevre wrote: an option to control what happens on encoding errors would be better and sufficient. It might suffice for your use cases, but it's more complicated and less flexible than

Bug#758105: bug#18266: Bug#758105: bug#18266: grep -P and invalid exits with error

On Thu, Sep 11, 2014 at 10:07 AM, Paul Eggert egg...@cs.ucla.edu wrote: Vincent Lefevre wrote: I've just reported a new Debian concerning the performance problem. It's not clear from http://bugs.debian.org/761157 that the performance problem occurs only with -P, but I assume that's what is

Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot)

On Wed, Aug 13, 2014 at 12:07 PM, Karsten Merker mer...@debian.org wrote: [CCing Otavio Salvador and Jim Meyering; the following is a short summary of the situation; the full history can be read in bug #751704: Debian-Installer uses partman for partitioning, which in turn is based

Bug#736919: bug#16586: grep: infinite loop in grep -P on some files with invalid UTF-8 sequences

On Tue, Apr 15, 2014 at 7:48 AM, Paul Eggert egg...@cs.ucla.edu wrote: Santiago wrote: it was a debian-pcre-specific bug. Thanks, closing the bug upstream. This bug is still present in upstream libpcre version 8.35. I wrote a patch for it, posted at http://debbugs.gnu.org/17245#26 and

Bug#739752: bug#17010: Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

On Fri, Mar 14, 2014 at 4:49 AM, Pádraig Brady p...@draigbrady.com wrote: ... Hence since c_f_m() can validly fail even with CAN_MISSING, I agree your patch is correct. Please push. Done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe.

Bug#739752: bug#17010: Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

On Fri, Mar 14, 2014 at 9:27 AM, Jim Meyering j...@meyering.net wrote: On Fri, Mar 14, 2014 at 4:49 AM, Pádraig Brady p...@draigbrady.com wrote: ... Hence since c_f_m() can validly fail even with CAN_MISSING, I agree your patch is correct. Please push. Done. Hmm... For the record, I also

Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

... Thank you for the bug report! That also affected the very latest code in git. Here is a patch: From a6d2db8b6dfe15344aba4aefe9545eb3a4876d45 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@fb.com Date: Thu, 13 Mar 2014 17:05:04 -0700 Subject: [PATCH] ln: with -sr, don't segfault for a TARGET

Bug#739752: bug#17010: Bug#739752: coreutils: ln segfaults when run with --relative and an empty target

On Thu, Mar 13, 2014 at 7:22 PM, Pádraig Brady p...@draigbrady.com wrote: On 03/14/2014 01:42 AM, Jim Meyering wrote: From a6d2db8b6dfe15344aba4aefe9545eb3a4876d45 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@fb.com Date: Thu, 13 Mar 2014 17:05:04 -0700 Subject: [PATCH] ln: with -sr

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Sat, Dec 21, 2013 at 11:01 AM, Jim Meyering j...@meyering.net wrote: On Sat, Dec 21, 2013 at 10:46 AM, Jim Meyering j...@meyering.net wrote: I expect to push that patch as-is and defer to a separate commit (or maybe even skip altogether) any portability hack that might warn or disable PCRE

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Thu, Dec 19, 2013 at 10:34 AM, Jim Meyering j...@meyering.net wrote: I have confirmed that grep linked with libpcre.a built from upstream sources [commit f9d3a72ea5e86a674a9836b462e1231ecce0d739] (8.34) also works the way I expect. More data points: Fedora 20 and OS/X work both with pcre

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Sat, Dec 21, 2013 at 10:46 AM, Jim Meyering j...@meyering.net wrote: I expect to push that patch as-is and defer to a separate commit (or maybe even skip altogether) any portability hack that might warn or disable PCRE support when detecting the broken library. Pushed. Let's take any

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Wed, Dec 18, 2013 at 3:09 PM, Santiago santi...@debian.org wrote: El 18/12/13 a las 09:45, Jim Meyering escribió: ... printf 'j\x82\nj\n'|LC_ALL=en_US.UTF-8 grep -P j|cat -A; echo $? For me (using pcre-8.33), it works the way I want and both matches: jM-^B$ j$ 0

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Wed, Dec 18, 2013 at 8:53 AM, Santiago santi...@debian.org wrote: ... $ src/grep -Pr DEFINE /usr/lib/linux-kbuild-3.2/ src/grep: invalid UTF-8 byte sequence in input When I'd expected something like: $ LC_ALL=C src/grep -Pr DEFINE /usr/lib/linux-kbuild-3.2/

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Tue, Nov 26, 2013 at 6:30 AM, Santiago santi...@debian.org wrote: This bug was also reported in Debian ( http://bugs.debian.org/730472 ). Taking a look on it, I think the most suitable solution for the moment is to flag PCRE_NO_UTF8_CHECK instead of PCRE_UTF8, so PCRE does not check if

Bug#730472: bug#15758: grep 2.15 calls abort() on larger searches with -P

On Fri, Dec 13, 2013 at 10:33 AM, Jim Meyering j...@meyering.net wrote: ... Thanks for the suggested patches and report. Your first patch is almost right. The problem is that we cannot remove the PCRE_UTF8 flag. If we did that, it would disable UTF-8, reverting an older fix. See tests/pcre

Bug#684713: support for partitioned linux md devices

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

Bug#563254: du bogus warning with bind mounts

[Re: http://bugs.gnu.org/11844 du: continue processing after bind-mount induced dir-cycle ] Ondrej Oprala wrote: Sure, that looks great. Thanks for the help. I added this to the log: * THANKS.in: Update. This implements the proposal in http://bugs.gnu.org/11844. Originally

Bug#682969: timeout 20 /usr/sbin/ntpd -g -q gives wrong return code

Goswin von Brederlow wrote: Package: coreutils Version: 8.13-3.2 Severity: normal File: /usr/bin/timeout I'm trying to set the time during boot. Unfortunately ntpd hangs forever if the timeserver is unavailable. So I added a timeout to it so the system still continues to boot without the

Bug#682969: timeout 20 /usr/sbin/ntpd -g -q gives wrong return code

Pádraig Brady wrote: On 07/27/2012 05:56 PM, Jim Meyering wrote: ... When I try to trigger such misbehavior, timeout seems to work fine on a system (Fedora 17) with a working timer_settime function: $ timeout 2 date --set=$(LC_ALL=C date -d 10\ sec +@%s); echo $? 0 I.e., when

Bug#679708: libc-client2007e: uw-imap c-client library version skew, app=2007e library=2007f

Jonas Smedegaard wrote: ... uw-imapd has been dropped from Debian. I recommend switching to Dovecot. libc-client* and uw-imapd was part of same source package, but if for a moment we imagine they weren't, then the solution to this bug would be to recompile uw-imapd against up-to-date

Bug#679708: libc-client2007e: uw-imap c-client library version skew, app=2007e library=2007f

Package: libc-client2007e Version: 8:2007f~dfsg-1 Severity: normal * What led up to the situation? I use uw-imapd and updated to today's libc-client2007e, and now uw-imapd (8:2007e~dfsg) doesn't work at all, in that I get these in the logs: Jun 30 21:20:23 *** imapd: IMAP toolkit crash:

Bug#582083: patch for grep --color to non-tty output

Aníbal Monsalve Salazar wrote: Debian bug report is posted at: http://bugs.debian.org/582083 ... There's no reason not to obey the user when they ask for --color, regardless of whether the output is to a tty or not. They wouldn't have asked for --color if they didn't want it, and most other

Bug#582083: patch for grep --color to non-tty output

Tim Connors wrote: On Tue, 24 Apr 2012, Jim Meyering wrote: Aníbal Monsalve Salazar wrote: Debian bug report is posted at: http://bugs.debian.org/582083 ... There's no reason not to obey the user when they ask for --color, regardless of whether the output is to a tty

Bug#669555: coreutils: FTBFS: env: setfacl: No such file or directory

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.

Bug#669084: grep does not match anything when reading from stdin

that the possible culprit is the code above. The Debian bug report is at http://bugs.debian.org/668585 Hi Aníbal Thanks for passing that along. Here's a lightly-tested patch: From 415e4e69c8e8c0db288205b30ab2b6a337f62d38 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 17 Apr

Bug#669084: grep does not match anything when reading from stdin

Aníbal Monsalve Salazar wrote: ... Tino suggests that the possible culprit is the code above. The Debian bug report is at http://bugs.debian.org/668585 Typo. The correct address is http://bugs.debian.org/669084 Thanks! I've adjusted the log: * NEWS (Bug fixes): Mention it, and add a few

Bug#669084: grep does not match anything when reading from stdin

Tino Keitel wrote: On Tue, Apr 17, 2012 at 14:23:48 +0200, Tino Keitel wrote: Hi, I had problems extracting the patch from the mail, so I had to use copypaste. Also, the patch portion in main.c looked totally different Forgot the patch, it's attached. Regards, Tino ---

Bug#662723: ls: -F (--indicator-style=classify) affects on symbolic link dereference

sergio wrote: On 03/06/2012 05:43 AM, Michael Stone wrote: On Tue, Mar 06, 2012 at 03:50:34AM +0400, sergio wrote: indicator-style mast not affect on dereference. % /bin/ls -F /var/run /var/run@ Can you be more specific about what you're looking for? I mean ls -F /var/run should give:

Bug#659593: coreutils: *** glibc detected *** tac: double free or corruption (top): 0x000000000061b030 ***

Segfault in wrote: Package: coreutils Version: 8.5-1 Severity: important $ tac */dev/null *** glibc detected *** tac: double free or corruption (top): 0x0061b030 *** Thanks for the report. That was fixed upstream in coreutils-8.6 (latest is 8.15): * Noteworthy changes in

Bug#654861: coreutils: sort creates temporary files in /var/tmp instead of /tmp thus violating the FHS

For some reason, sort generates temporary files in /var/tmp instead of /tmp. As /var/tmp is not cleaned regularly or on boot, this means that any left over files (eg due to crashes) will be left in /var/tmp forever. Also sort cannot use the data on subsequent invocations, which makes the

Bug#649913: Please use posix_fallocate

Goswin von Brederlow wrote: Package: coreutils Version: 8.5-1 Severity: normal File: /bin/cp when copying files the size of the resulting file is known (except in race conditions) beforehand and should be communicated to the filesystem using posix_fallocate(). This ensures there is enough

Bug#647889: xgraph: echo 1 2|xgraph segfaults due to deref of uninitialized pointer

aclocal.m4 from version control, too. From bd5ae5869e16792c5fa6cb894ed2e50e52278c62 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 7 Nov 2011 11:01:44 +0100 Subject: [PATCH 2/2] don't dereference a pointer with uninitialized stack data Before this change, xgraph

Bug#514893: cmp: please allow comparing multiple files (fwd)

Santiago Vila wrote: A long time ago, I received this from the Debian bug system. [ I realize that this is unlikely to be implemented, but I am supposed to forward upstream bugs upstream in either case ]. Thanks for forwarding that. However, I'll bet you can do something similar with od and a

Bug#646022: coreutils: tail -f doesn't work with GPFS filesystem

From: Jim Meyering meyer...@redhat.com Date: Thu, 20 Oct 2011 19:18:09 +0200 Subject: [PATCH] tail: with -f, use nanosleep, not inotify on a GPFS file system * src/tail.c (fremote): List GPFS as a remote file system type. * THANKS.in: Update. * NEWS (Bug fixes): Mention it. Report and suggested

Bug#642557: coreutils: sort -g hangs when fed large numbers of nans (not a number).

Aaron Denney wrote: Version: 8.13-2 yes -- '-nan' | head -116903 | sort -g /dev/null completes in under a second. while yes -- '-nan' | head -116904 | sort -g /dev/null appears to hang. Thanks for the report. Technically, this is not due to a bug in coreutils, but I've patched sort.c, at

Bug#641166: coreutils: 'man sort': '--random-sort' misleading

gwern wrote: Package: coreutils Version: 8.5-1 Severity: minor The existing documentation for the option: -R, --random-sort sort by random hash of keys This is not wrong, strictly-speaking, but it is misleading: sorting by random hash *sounds* like a perfect

Bug#641166: coreutils: 'man sort': '--random-sort' misleading

Gwern Branwen wrote: On Mon, Sep 12, 2011 at 10:01 AM, Jim Meyering j...@meyering.net wrote: Did you see the real documentation? No; when I was younger, I sometimes looked at the info page for commands, but invariably they seemed to be useless or copies of the Please try to reset your

Bug#294327: [PATCH] doc: note that cp -l creates _hard_ links

Benoît Knecht wrote: This fact was already noted in the Texinfo manual, but not in the output of --help. * src/cp.c (usage): As above, for --help. Reported by Jari Aalto in http://bugs.debian.org/294327. Thank you. Applied with the one-line summary edited to start with doc: rather than

Bug#115833: [PATCH] date: document that %k and %l are space padded

Benoît Knecht wrote: The help output and man page mention that by default, date pads numeric fields with zeroes, yet the description of %k and %l didn't specify that these values were space padded, whereas the description of %e did. Fixes http://bugs.debian.org/115833. --- Hi, If anyone

Bug#630735: coreutils cross-build support

Steve McIntyre wrote: On Thu, Jun 16, 2011 at 02:04:34PM -0400, Michael Stone wrote: On Thu, Jun 16, 2011 at 06:50:21PM +0100, Steve McIntyre wrote: For now, the attached debdiff simply disables generation of the docs for cross-builds. The right answer (IMHO) would be to convince upstream to

Bug#624387: [PATCH] dfa: fix case folding logic for character ranges

Paolo Bonzini wrote: * src/dfa.c (setbit_case_fold): Remove, replace with... (setbit_wc, setbit_c, setbit_case_fold_c): ... these. (parse_bracket_exp): Use setbit_case_fold_c when iterating over single-byte sequences. Use setbit_wc for multi-byte character sets, and setbit_case_fold_c for

Bug#624387: [PATCH] dfa: fix case folding logic for character ranges

Paolo Bonzini wrote: * src/dfa.c (setbit_case_fold): Remove, replace with... (setbit_wc, setbit_c, setbit_case_fold_c): ... these. (parse_bracket_exp): Use setbit_case_fold_c when iterating over single-byte sequences. Use setbit_wc for multi-byte character sets, and setbit_case_fold_c for

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Paolo Bonzini wrote: On Sat, Jun 4, 2011 at 09:48, Jim Meyering j...@meyering.net wrote: The b2 == EOF part is required for the somewhat similar bug I fixed a month ago:     fix a bug whereby echo c|grep '[c]' would fail for any c in 0x80..0xff     8da41c930e03a8635cbd8c89e3e591374c232c89

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Paolo Bonzini wrote: On Sat, Jun 4, 2011 at 09:48, Jim Meyering j...@meyering.net wrote: The b2 == EOF part is required for the somewhat similar bug I fixed a month ago:     fix a bug whereby echo c|grep '[c]' would fail for any c in 0x80..0xff     8da41c930e03a8635cbd8c89e3e591374c232c89

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Jim Meyering wrote: Paolo Bonzini wrote: On 06/02/2011 11:08 PM, Jim Meyering wrote: #if MBS_SUPPORT - int b2 = wctob ((unsigned char) b); - if (b2 == EOF || b2 == b) + /* Below, note how when b2 != b and we have a uni-byte locale + (MB_CUR_MAX == 1), we set b

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Paolo Bonzini wrote: On 06/02/2011 11:08 PM, Jim Meyering wrote: #if MBS_SUPPORT - int b2 = wctob ((unsigned char) b); - if (b2 == EOF || b2 == b) + /* Below, note how when b2 != b and we have a uni-byte locale + (MB_CUR_MAX == 1), we set b = b2. I.e., in a uni

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Paolo Bonzini wrote: On Fri, Jun 3, 2011 at 19:09, Jim Meyering j...@meyering.net wrote: The b2 == EOF part is required for the somewhat similar bug I fixed a month ago:    fix a bug whereby echo c|grep '[c]' would fail for any c in 0x80..0xff    8da41c930e03a8635cbd8c89e3e591374c232c89

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

it is indeed a bug in grep, but at least this time it affects relatively few locales. Here's the fix I expect to use and a test case to exercise it. From 8e214a2ecc4bac7f8341deb3646b6f1c3819dac3 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 2 Jun 2011 18:03:49 +0200 Subject

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Here's a slightly better patch. The dfa.c diff is the same, but I've corrected the test name and added/corrected log comments. From cbd5055c976ebc93b657dcdf3783cc91de4f68ed Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 2 Jun 2011 18:03:49 +0200 Subject: [PATCH 1/2] fix

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

arn...@skeeve.com wrote: diff --git a/src/dfa.c b/src/dfa.c index f2064ed..b41cbb6 100644 --- a/src/dfa.c +++ b/src/dfa.c @@ -573,7 +573,8 @@ setbit_case_fold ( else { #if MBS_SUPPORT - if (wctob ((unsigned char)b) == b) + int b2 = wctob ((unsigned char) b); + if

Bug#624387: [bug #33198] Incorrect bracket expression when parsing in ru_RU.KOI8-R (Russian locale)

Dmitry V. Levin wrote: On Mon, May 02, 2011 at 07:20:15PM +, Jim Meyering wrote: ... Thanks for the report. however, I cannot reproduce the problem with grep-2.7 built from upstream sources. Nor can I reproduce it using the grep-2.7 that comes from Fedora 15. To test it, I put

Bug#622182: FTBFS: test touch/now-owned-by-other fails

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

Bug#622182: FTBFS: test touch/now-owned-by-other fails

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

Bug#622182: FTBFS: test touch/now-owned-by-other fails

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. See the

Bug#432945: close

close 432945 thanks If this bug is fixed then why not close it ? Done, with the above. Thanks for the heads up. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613319: diff --ignore-all-space doesn't ignore newlines after all

jida...@jidanni.org wrote: I forgot to X-debbugs-cc: bug-diffut...@gnu.org . They should please look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613319 Contrary to documentation: The `-w' and `--ignore-all-space' options are stronger than `-b'. They ignore difference even

Bug#614006: xdiskusage: buffer overrun

2140cc66b09f2447ef7e7a89256e04c02bb18b2e Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Wed, 16 Feb 2011 18:16:11 +0100 Subject: [PATCH] MAXDEPTH: increase limit to 512 Otherwise, a long line like this: 12 a/a/a/a/a/a/a/.../a with more than 100 components, would cause xdiskusage to write user

Bug#609049: [coreutils] Re: Bug#609049: du: process_file: Assertion `level == prev_level - 1' failed

Jim Meyering wrote: ... Here's the incremental I'm testing with: diff --git a/tests/du/move-dir-while-traversing b/tests/du/move-dir-while-traversing index e42bc93..fe1615c 100755 Thanks again for the quick feedback. I squashed in the changes above and pushed the result. I also updated

Bug#609049: [coreutils] Re: Bug#609049: du: process_file: Assertion `level == prev_level - 1' failed

Jim Meyering wrote: ... While I do have a reproducer that will become a test suite addition (coming soon), it relies on python (a first) and the python-inotify package, so I'll have to be careful to skip the test when those prerequisites aren't installed. Also, there's an inherent race

Bug#609049: [coreutils] Re: Bug#609049: du: process_file: Assertion `level == prev_level - 1' failed

Pádraig Brady wrote: On 09/01/11 22:05, Jim Meyering wrote: diff --git a/tests/du/move-dir-while-traversing b/tests/du/move-dir-while-traversing +# We use a python-inotify script, so... +python -m pyinotify -h /dev/null \ + || skip_ 'python-inotify package not installed' A small point

Bug#609049: du: process_file: Assertion `level == prev_level - 1' failed

. Also, there's an inherent race condition, so I'll have to find the right compromise between absolute test-robustness (too expensive in time and inodes) and reasonableness. From 92bbec0f697575a8bcbbe3fe0cb54b468c1022a4 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 8

Bug#608832: factor compiled without bignum support

Michael Stone wrote: On Mon, Jan 03, 2011 at 01:26:36PM -0600, C de-Avillez wrote: If `factor' is built without using GNU MP, only single-precision arithmetic is available, and so large numbers (typically 2^64 and above) will not be supported. Pulling in a bignum library into the required list

Bug#436338: df: df rounds sizes incorrectly

Paul E Condon wrote: On 20101223_002101, Bob Proulx wrote: ... To see the values that the kernel is returning to df's statfs call please run the following command and report the contents of the file. $ strace -v -e trace=statfs -o /tmp/df.strace.out df /dev/sde1 ... Also,

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: On Tue, 14 Dec 2010 10:46:18 -0500 (EST), Jim Meyering wrote: Stephen Powell wrote: How is your testing going? Finding time for parted has been a challenge recently. It's unclear to me from what you wrote. Are you asking me to provide a test case? If you can

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: On Thu, 25 Nov 2010 10:49:06 -0500 (EST), Jim Meyering wrote: Thanks for the fix. Until today I had not compiled your changes on an s390x. When I did, there were 3 other minor problems, addressed by the patch below, just after the one you suggested. That got past make

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

Paul Eggert wrote: On 12/03/10 02:03, Jim Meyering wrote: Would you mind adding a Bug fixes entry for this in coreutils' NEWS file? It'd be nice to commit that along with an update of the gnulib submodule to the latest. Sure, done, with this notice: cp -u no longer does unnecessary

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

Paul Eggert wrote: Good eye! Thanks for the bug report and example. I installed the following one-byte patch into gnulib; please give it a try. It should propagate into coreutils the next time coreutils updates from gnulib. A test case for this would require two file systems, one with

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

format */ u_int64_t formatted_blocks; /* valid when ldl_version = 2 (in EBCDIC) */ }; -- 1.7.3.2.765.g642a8 From 668956027eebd9204e486fdd75e67a981ead5ac5 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer

Bug#381091: Word splitting in 'export' arguments (Re: bash: expands $@ within double-quotes inconsistently)

Eric Blake wrote: ... I would love to require altered word splitting behavior for export and readonly (the standard doesn't touch local yet). In fact, it has independently come up on the GNU coreutils development lists that the standard is long overdue for requiring shells to support 'local'

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: As promised earlier today, I now have the following patch files on my web site ready for download: http://www.wowway.com/~zlinuxman/parted/vtoc.h.diff (apply to include/parted/vtoc.h) http://www.wowway.com/~zlinuxman/parted/dasd.c.diff (apply to

Bug#598438: coreutils: new du corrupted filesystem warning breaks scripts

-L bugs with dangling or cyclic symlinks http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=77428214f13e1 However, this particular fix was not noted in NEWS, so I'm adding an entry for it: From 65b50c6cdd4a140a2974907423a1df1692b6d3ae Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer

Bug#367011: still reproducible (coreutils: od --width=8 works but od -w 8 fails)

Timo Juhani Lindfors wrote: The bug is still reproducible in both lenny and sid. (sid)li...@sauna:~$ od -w 8 /etc/debian_version That is not a valid use of od's -w option. There may be no space between the short-named -w and its optional argument. Here's the description from info coreutils

Bug#594666: /usr/bin/tac: tac aborts

:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 28 Aug 2010 17:45:29 +0200 Subject: [PATCH] tac: avoid double free * src/tac.c (main): Reading a line longer than 16KiB would cause tac to realloc its primary buffer. Then, just before exit, tac would mistakenly free the original (now

Bug#586301: diffutils: doubled slashes in --recursive output (path//path) (fwd)

. Here's a quick stand-alone demo: Before it would do this: $ ./diff -r a b/ Only in b//f: g [Exit 1] Now it works how we'd like: $ ./diff -r a b/ Only in b/f: g [Exit 1] Here's a proposed patch: From 280d5a1e6fd399af2fa5c9d0cfb3d88878bc2380 Mon Sep 17 00:00:00 2001 From: Jim

Bug#586301: diffutils: doubled slashes in --recursive output (path//path) (fwd)

Paul Eggert wrote: On 08/14/10 23:46, Jim Meyering wrote: [PATCH] diff -r: avoid printing excess slashes in concatenated file names Thanks, that looks good to me. Hmm, at some point we should replace zalloc with xzalloc too, I suppose, and maybe get rid of diffutils' 'concat' function. Hi

Bug#586301: diffutils: doubled slashes in --recursive output (path//path) (fwd)

Paul Eggert wrote: On 08/14/10 23:46, Jim Meyering wrote: [PATCH] diff -r: avoid printing excess slashes in concatenated file names Thanks, that looks good to me. Hmm, at some point we should replace zalloc with xzalloc too, I suppose, and maybe get rid of diffutils' 'concat' function. Oh

Bug#586301: diffutils: doubled slashes in --recursive output (path//path) (fwd)

Jim Meyering wrote: Paul Eggert wrote: On 08/14/10 23:46, Jim Meyering wrote: [PATCH] diff -r: avoid printing excess slashes in concatenated file names Thanks, that looks good to me. Hmm, at some point we should replace zalloc with xzalloc too, I suppose, and maybe get rid of diffutils

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: I haven't heard anything for a while. I just thought I would touch base after a couple of months. Is anything happening? Hi Stephen. I'll be able to review your patches in 2-3 weeks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject

Bug#579948: [parted-devel] Some debugging info

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

Bug#586581: coreutils: comm - Slight formatting error in manual page

versa. The last two lines should probably read: comm -3 file1 file2 Print lines in file1 not in file2, and vice versa. Thank you. I'll fix it like this: From 1419af82433027b03c2d49f7a401beb485bcbe2a Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon

Bug#585509: coreutils: missing prototypes when building test-linkat in gnulib testsuite

Steve Langasek wrote: Package: coreutils Version: 8.5-1 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu maverick ubuntu-patch Hi Michael, The latest coreutils package FTBFS in Ubuntu on armel, powerpc, and sparc due to a reproducible failure in

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: Well, my paperwork just came through today for assignment of copyright. And it's just in time. Here is a link to my second round of enhancements. http://www.wowway.com/~zlinuxman/parted/dasd_complete.diff These changes require my previous changes as a prerequisite.

Bug#583198: coreutils: tail does not obey --sleep-interval option

Michael Stone wrote: On Wed, May 26, 2010 at 09:06:10AM -0600, Bob Proulx wrote: I don't understand your comment in a bug report. Being more responsive seems like a good thing to me and good expected behavior. Could you say a few words about why you are filing a bug report on tail being more

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: Praise the Lord! I do believe I've got it now. Parted now supports all DASD types (CKD and FBA), drivers (ECKD, FBA, and DIAG) and disk formats Nice. Sounds promising. (CDL, LDL, and CMS) that are supported by the Linux kernel on the s390 ... I intend to put the

Bug#581065: /bin/rmdir: recursive option for rmdir

Paul Wise wrote: Package: coreutils Version: 8.5-1 Severity: wishlist File: /bin/rmdir X-Debbugs-CC: bug-coreut...@gnu.org I would like to be able to do a recursive rmdir. This would save typing for the cases where I want to remove a whole empty dir hierarchy. Currently I do this:

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks

Stephen Powell wrote: ... Now, for the specific bullet points for NEWS: o Fixed a bug in which the starting block for the implicit partition of LDL disks was miscalculated if the disk was formatted at a block size other than 4096. The program now calculates the starting block of the

Bug#578097: [parted-devel] [Parted-maintainers] Debian Bug #578097: No support for CMS-formatted disks in parted

Stephen Powell wrote: On Wed, 21 Apr 2010 13:44:59 -0400 (EDT), Jim Meyering wrote: Your patch is large enough that we have to require a signed copyright assignment. Here's the relevant section from HACKING: http://git.debian.org/?p=parted/parted.git;a=blob;f=HACKING#l428 Sorry

  1   2   3   4   5   >