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 for

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 stopped

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&id=11aGVBkG4ZgWqoZFgy2WNcQt1eqdeuTbx&confirm=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 pro

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 appea

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 1 | grep -E

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 coreutils 'sha512sum i

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 10:41 AM, Santiago 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 log message and u

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

On Wed, Dec 3, 2014 at 7:05 AM, 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 grep2.21-1 > amd

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 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 being able

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 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. (I

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 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 meant. > >

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 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 o

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 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 Norihiro forwarded it

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 wrote: > On Fri, Mar 14, 2014 at 4:49 AM, Pádraig Brady 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

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 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". Trouble? Contact

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 wrote: > On 03/14/2014 01:42 AM, Jim Meyering wrote: >> From a6d2db8b6dfe15344aba4aefe9545eb3a4876d45 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Thu, 13 Mar 2014 17:05:04 -0700 >> Subject: [PATCH] ln: wit

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

: segmentation fault ln -sr '' foobar > Expected result: Some kind of error message ... 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 Date: Thu, 13 M

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 wrote: > On Sat, Dec 21, 2013 at 10:46 AM, Jim Meyering 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 suppo

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 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 Thu, Dec 19, 2013 at 10:34 AM, Jim Meyering 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-8

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

On Wed, Dec 18, 2013 at 3:09 PM, Santiago 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: >> &

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

On Wed, Dec 18, 2013 at 8:53 AM, Santiago 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/ > /usr/lib/linux-kbuild-3.2/scripts/kerne

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 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/p

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

On Tue, Nov 26, 2013 at 6:30 AM, Santiago 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 inputs are UTF8 va

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 ker

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 reporte

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\

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 withou

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 l

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: c

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

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 mos

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

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 >> copy&paste. Also, the patch portion in main.c looked totally different > > Forgot the patch, it's attached. > > Regards, > Tino > > -

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

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

> > $ echo foo | grep -D skip foo; echo $? > 1 > > Timo suggests 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 415e4e69c8e8c0db288205b3

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/

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

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

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

emove aclocal.m4 from version control, too. >From bd5ae5869e16792c5fa6cb894ed2e50e52278c62 Mon Sep 17 00:00:00 2001 From: Jim Meyering 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 was un

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 an

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

nition of S_MAGIC_GPFS. >From c07d7486432429eb9e5cadd083d15247b0f4ab0d Mon Sep 17 00:00:00 2001 From: Jim Meyering 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 t

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 patche

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

Gwern Branwen wrote: > On Mon, Sep 12, 2011 at 10:01 AM, Jim Meyering 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

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 per

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 . > --- > > Hi, >

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 >>>upstr

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 fo

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 fo

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 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

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 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

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

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 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 >>

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_C

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

p -qE "[Пп]"; > echo $? > 1 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 Date: Thu, 2 Jun

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

ven with the single-byte version. So 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 Date: Thu, 2

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 c

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 +0000, 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 >&

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 mism

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:0

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. > > Se

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

rying to fix here. >From 2140cc66b09f2447ef7e7a89256e04c02bb18b2e Mon Sep 17 00:00:00 2001 From: Jim Meyering 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

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 t

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

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, th

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

on), 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 condition, so I'll have to find the right compromise between absolute test-robustness (too expens

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 requir

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

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

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 on

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,

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

id for ldl format */ +char ldl_version[1];/* Version number, valid for ldl format */ u_int64_t formatted_blocks; /* valid when ldl_version >= "2" (in EBCDIC) */ }; -- 1.7.3.2.765.g

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 'loca

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 > libparted/l

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

3e1 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 Date: Thu, 30 Sep 2010 14:24:42 +0200 Subject: [PATCH] maint: mention the du-exclude--vs--cycle-dir fix * NEWS

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 coreuti

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

b3959fc691e606857a3c6e9b316ec34819972245 Mon Sep 17 00:00:00 2001 From: Jim Meyering 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

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 xzall

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

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

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

ne arguments before using them for > output. Thanks to both Santiago and Jari. 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 propos

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 subjec

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

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

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

file1 file2 Print lines in file1 not in file2, and vice 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 1419af82433027b03c2d49f7a401be

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 fai

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 prerequis

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

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 ch

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 > o

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 thi

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 > libparted/l

  1   2   3   4   5   >