bug#48355: Reporting bugs

tag 48355 notabug close 48355 stop On 11/05/2021 16:46, tom wrote: Hello, I have found some bugs within the coreutil-tools: md5sum, sha1sum, sha256, sha512 and b2sum. Have a look at the attached script and messages.txt files. I think you're passing a malformed checksum file. We don't

bug#48355: Reporting bugs

Hello, I have found some bugs within the coreutil-tools: md5sum, sha1sum, sha256, sha512 and b2sum. Have a look at the attached script and messages.txt files. With regards Thomas chksum-iso.sh Description: application/shellscript GNU bash, Version 5.0.3(1)-release (x86_64-pc-linux-gnu

bug#44635: bugs in watch

tag 44635 notabug close 44635 stop On 11/14/20 2:07 PM, John Lawrence Aspden wrote: > Hi Guys, > > I noticed a couple of things that look like bugs in 'watch' [...] You have reached the GNU coreutils mailing list, and 'watch' is not part of the coreutils [1]. [1] https://www.gnu.org

bug#44635: bugs in watch

Hi Guys, I noticed a couple of things that look like bugs in 'watch' in questions on unix.stackexchange.com (one of them is my own question). https://unix.stackexchange.com/questions/101041/does-watch-only-monitor-the-visible-output https://unix.stackexchange.com/questions/619461/why-does-watch

bug#10900: Clarification re: Regarding the observed bugs in cp

tags 10900 moreinfo close 10900 stop (triaging old bugs) On 30/08/12 10:39 PM, era eriksson wrote: From: subratkumar To: era eriksson Date: Thu, 30 Aug 2012 17:04 On Thursday 30 August 2012 01:38 PM, era eriksson wrote: I stumbled across your recent bug report for cp [1]http

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

Le 25/02/2018 à 03:24, Pádraig Brady a écrit : On 20/02/18 00:04, Declercq Laurent wrote: Le 20/02/2018 à 04:26, Pádraig Brady a écrit : 2. Non-permission bits are preserved, even when the --no-preserve=mode option is involved. Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

On 20/02/18 00:04, Declercq Laurent wrote: > Le 20/02/2018 à 04:26, Pádraig Brady a écrit : >>> 2. Non-permission bits are preserved, even when the --no-preserve=mode >>> option is involved. >>> >>> Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile >>> cp(1) command (run as

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

Le 20/02/2018 à 04:26, Pádraig Brady a écrit : 2. Non-permission bits are preserved, even when the --no-preserve=mode option is involved. Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile cp(1) command (run as root user): cp -r --no-preserve=mode spfile spfile_copy Current

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

On 19/02/18 02:22, Declercq Laurent wrote: > I think that I did found at least two bugs in cp(1) command when the > --no-preserve=mode option is involved and when copying special file. I > describe each of them below. > > 1. Mode set on special files seem to be wrong: > >

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

I think that I did found at least two bugs in cp(1) command when the --no-preserve=mode option is involved and when copying special file. I describe each of them below. 1. Mode set on special files seem to be wrong: Original file to copy: prw-rw-rw- 1 root staff 0 févr. 18 18:59 spfile cp(1

bug#25041: Bugs in TAC and TAIL for closed stdin

On 27/11/16 15:51, Jim Meyering wrote: > On Sun, Nov 27, 2016 at 7:40 AM, Pádraig Brady wrote: >> I'll push the attached later > > Thanks to both of you. > > That patch looks fine, modulo a formatting nit: the second line is > indented one space too far: > > +

bug#25041: Bugs in TAC and TAIL for closed stdin

On Sun, Nov 27, 2016 at 7:40 AM, Pádraig Brady wrote: > I'll push the attached later Thanks to both of you. That patch looks fine, modulo a formatting nit: the second line is indented one space too far: + f->ignore = ! (reopen_inaccessible_files +

bug#25041: Bugs in TAC and TAIL for closed stdin

I'll push the attached later thanks again, Pádraiag >From a31edf2aab384bfd33a6f0ab123d688939c4ddf6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Sun, 27 Nov 2016 13:00:35 + Subject: [PATCH 1/2] tail: fix uninitialized memory read when failing to

bug#25041: Bugs in TAC and TAIL for closed stdin

On 27/11/16 09:15, Marcel Böhme wrote: > Dear all, > > During fuzzing, we found one use-after-free in tac and one > invalid-loading-of-value in tail. > Interestingly, these errors can be observed only when stdin is externally > closed but internally expected to be open. >

bug#25041: Bugs in TAC and TAIL for closed stdin

Dear all, During fuzzing, we found one use-after-free in tac and one invalid-loading-of-value in tail. Interestingly, these errors can be observed only when stdin is externally closed but internally expected to be open. The bugs were found by AFLFast, a fork of AFL. The bug in tac was also

bug#25011: Bugs in PTX Utility

lid read of size 1. > > Both bugs were found by AFLFast, a fork of AFL. Thanks goes out to Van-Thuan > Pham. > > > $ ptx ptx ptx > /dev/null > Segmentation fault > > ASAN says: > ==47034==ERROR: AddressSanitizer: heap-use-after-free on address > 0x7f2b49433093 at

bug#25011: Bugs in PTX Utility

Dear all, The following produces a crash for the version in trunk and preinstalled version 8.21 on Ubuntu 14.04 x86_64. Below is also heap-buffer-overflow that doesn’t actually crash but is flagged by ASAN as an invalid read of size 1. Both bugs were found by AFLFast, a fork of AFL. Thanks

bug#24007: Report cat bugs to bug-coreutils@gnu.org

tag 24007 notabug thanks On 07/16/2016 12:11 AM, NAVEEN KUMAR wrote: > Hi Team, > > Greetings! > > I was sitting next my system looking for some basic code brush up and was > playing with CAT command, and though of some kind of additional features to > our existing CAT command, such as... > >

bug#24007: Report cat bugs to bug-coreutils@gnu.org

Hi Team, Greetings! I was sitting next my system looking for some basic code brush up and was playing with CAT command, and though of some kind of additional features to our existing CAT command, such as... *"Write a CAT command program, which will allow appending text or lines of code at

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

tag 23951 notabug close 23951 stop Hello, quoting an off-list email from David: > When I use "sort -k1.4n -u", system output miss [c3m1.ecld.com]. > then "sort -k1.4n aa |sort -u" the [c3m1.ecld.com] appear again. This is not a bug but correct behavior. The parameter "-k1.4n" means that the

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

Hello, > On Jul 11, 2016, at 21:38, David Pan wrote: > > It seems that I find a bug when using the command: > > sort -k1.4n -u > please refer to the attachment for detail . You have not indicated exactly what is the suspected incorrect output. May I ask you to detail what

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

Hello Dear: It seems that I find a bug when using the command: sort -k1.4n -u please refer to the attachment for detail . sort-u.bug Description: Binary data

bug#20729: true bugs

According to `man true', the --help and --version flags should have output. However, when I run `true --help' or `true --version', I get no output. These are true bugs (pun intended), so as instructed by the man page, I am reporting true bugs to bug-coreutils@gnu.org. -- Dan Burton

bug#20729: true bugs

tag 20729 notabug thanks On 06/03/2015 10:00 PM, Dan Burton wrote: According to `man true', the --help and --version flags should have output. However, when I run `true --help' or `true --version', I get no output. These are true bugs (pun intended), so as instructed by the man page, I am

bug#18681: The Linux cp command has bugs

close 18681 thanks Eric Blake wrote: Polehn, Mike A wrote: This still left the incorrect operation of the interactive operation when both -i and -f is used. The behavior of -i vs. -f interaction is required by POSIX; in particular, POSIX is explicit that -i and -f are NOT a toggle switch

bug#18681: The Linux cp command has bugs

cp --version: 8.21 running on Fedora 20, version 3.16.3-200.fc20.x86_64 with latest updates The Linux copy command (cp) has problems Problem need to copy a tree of 1000s of files to another directory that is a git directory that has a whole bunch of additional build files, so diff between

bug#18681: The Linux cp command has bugs

Polehn, Mike A wrote: Using: cp -f -r dir a dir b For each file being copied it asked: cp: overwrite X? That's not what I observe here (see below). Perhaps there's something else going on, maybe an alias. For example, I couldn't get the cp to work without also using -T.

bug#18681: The Linux cp command has bugs

Hello Mike, On 10/10/2014 01:25 PM, Polehn, Mike A wrote: Problem need to copy a tree of 1000s of files to another directory that is a git directory that has a whole bunch of additional build files, so diff between the directories will not do any good. This is slightly off-topic, but if you

bug#18681: The Linux cp command has bugs

Sorry, had a typo: On 10/10/2014 03:13 PM, Assaf Gordon wrote: # For each file managed by git (with 'git ls'), # compare it to the corresponding file in the other directory: git ls -0 | xargs -0 -I% diff -q % ../dpdk-1.7.1/% Should be: git ls -z | xargs -0 -I% diff -q %

bug#18681: The Linux cp command has bugs

the '-i' operation might be a good change. Thanks! Mike -Original Message- From: Assaf Gordon [mailto:assafgor...@gmail.com] Sent: Friday, October 10, 2014 12:14 PM To: Polehn, Mike A; 18...@debbugs.gnu.org Subject: Re: bug#18681: The Linux cp command has bugs Hello Mike, On 10/10

bug#18681: The Linux cp command has bugs

On 10/10/2014 02:00 PM, Polehn, Mike A wrote: This still left the incorrect operation of the interactive operation when both -i and -f is used. The behavior of -i vs. -f interaction is required by POSIX; in particular, POSIX is explicit that -i and -f are NOT a toggle switch of one another,

bug#18681: The Linux cp command has bugs

Hi Polehn, The -f option isn't `suppress interactive' in cp. It attempts to unlink a destination not to be able to override. It's different from the option in mv. As the behavior is clearly defined in POSIX as Eric says, we won't be able to change it. BTW, I don't like the alias `cp -i'. So

bug#18681: The Linux cp command has bugs

On Fri, Oct 10, 2014 at 7:48 PM, Norihiro Tanaka nori...@kcn.ne.jp wrote: If you temporarily want to cancel the the alias, you can define an another alias as `cpf', and/or can use below instead of `cp' Note that (in bash at least) you can prefix the command with a backslash (\) to override an

bug#17188: Sort bugs

On 04/05/2014 02:44 PM, Nikos Balkanas wrote: What about sorting input based on the input's locale, instead of the system's? And how do you propose to detect the input's locale? The canonical way to tell a program what locale the input is in is by setting the environment variable LC_COLLATE

bug#17188: Sort bugs

Hi, Sort is seriously bugged. This is the output from: sort -d -t \t -k1 input out 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/ 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ

bug#17188: Sort bugs

tag 17188 notabug thanks On 04/04/2014 08:07 PM, Nikos Balkanas wrote: Hi, Sort is seriously bugged. This is the output from: sort -d -t \t -k1 input out -d says to do a dictionary sort that ignores non-alphanumeric characters. But it still leaves it up to your current locale on whether

bug#17188: Sort bugs

On Sat, Apr 5, 2014 at 3:21 PM, Eric Blake ebl...@redhat.com wrote: tag 17188 notabug thanks On 04/04/2014 08:07 PM, Nikos Balkanas wrote: Hi, Sort is seriously bugged. This is the output from: sort -d -t \t -k1 input out -d says to do a dictionary sort that ignores

bug#17188: Sort bugs

the airplane. Don't let the airplane fly you. :-) You could file bugs with your system vendor that they defaulted you to LANG=en_US.UTF-8 and ask them to allow users to choose LANG=C at install time instead. I have done this and unfortunately the response from one vendor was That was intentional

bug#17188: Sort bugs

On Sat, Apr 5, 2014 at 11:23 PM, Bob Proulx b...@proulx.com wrote: [...snip...] Originally the locale was C. If you go back to the C locale things will be working for you as you wish it to work. It will work as it worked before. Agreed? Then you changed something. You changed the

bug#15206: Report od bugs

Dear Sir/Madam, I am writing this email to report a bug from od command. I am working in bioinformatics research filed, and currently I am trying to convert phred scores from fastq format file to Ascii values, and met weird things. For example, when I try to convert 100 characters into ASCII

bug#15206: Report od bugs

tag 15206 notabug thanks On 08/29/2013 12:01 AM, Kaitao Lai wrote: Dear Sir/Madam, I am writing this email to report a bug from od command. I am working in bioinformatics research filed, and currently I am trying to convert phred scores from fastq format file to Ascii values, and met

bug#15206: Report od bugs

On 08/29/2013 12:51 PM, Eric Blake wrote: tag 15206 notabug thanks On 08/29/2013 12:01 AM, Kaitao Lai wrote: Dear Sir/Madam, I am writing this email to report a bug from od command. I am working in bioinformatics research filed, and currently I am trying to convert phred scores from

bug#13899: Bugs in echo and printf

Hello! I discovered a few bugs in echo and printf. echo --help echo --version printf --help printf --version They all don't work... Sergio

bug#13899: Bugs in echo and printf

On Thursday 07 March 2013, Sérgio Coutinho wrote: Hello! I discovered a few bugs in echo and printf. echo --help echo --version printf --help printf --version They all don't work... Sergio Probably you are using the shell builtins. Have you tried with full path /usr/bin/echo --version

bug#13899: Bugs in echo and printf

tag 13899 notabug thanks On 03/07/2013 02:57 PM, Sérgio Coutinho wrote: Hello! I discovered a few bugs in echo and printf. echo --help echo --version printf --help printf --version They all don't work... Thanks for the report. However, without telling us what you saw vs. what you

bug#11164: reporting of bugs in lfs

tags 11164 - moreinfo close 11164 thanks http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11164 It has been five months since more information was requested on this bug. Without further information nothing can be resolved. Therefore I am closing this ticket. If you do have more information

bug#10900: Clarification re: Regarding the observed bugs in cp

I stumbled across your recent bug report for cp http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10900 and I was wondering if you could follow up with a bit of additional information. What did you expect to happen, and what should be fixed in order for cp to behave like you expect? Thanks for your

bug#10900: Clarification re: Regarding the observed bugs in cp

Forwarding a replyI only received in private. Please keep the Cc: on any followups. From: subratkumar subratkuma...@globaledgesoft.com To: era eriksson e...@iki.fi Date: Thu, 30 Aug 2012 17:04 On Thursday 30 August 2012 01:38 PM, era eriksson wrote: I stumbled across your recent bug report for

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

do 'ln --help' the german message will tell you in the second to last line: Melden Sie Übersetzungsfehler für ln an translation-team...@lists.sourceforge.net meaning Report ln translation bugs to http://translationproject.org/team/ Why didn't you do so? Please send your bug report

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

tags 11217 notabug On 04/11/2012 02:12 AM, cbr...@arcor.de wrote: Package: coreutils Version: 8.13 - 8.16 Faults: (only applicable to german localization): When trying to re-create an already created symbolic link, ln's error message contains three faults, one grammatical, one

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

Package: coreutils Version: 8.13 - 8.16 Faults: (only applicable to german localization): When trying to re-create an already created symbolic link, ln's error message contains three faults, one grammatical, one [important] logical one orthographical. Reproduction: touch ./foo ln -s ./foo

bug#11164: reporting of bugs in lfs

i am getting the bug while running the following command make RUN_EXPENSIVE_TESTS=yes check the error is See tests/test-suite.log Please report to bug-coreutils@gnu.org make[4]: *** [test-suite.log] Error 1 make[4]:

bug#11164: reporting of bugs in lfs

tag 11164 needinfo thanks On 04/03/2012 09:52 AM, vr tech labs wrote: i am getting the bug while running the following command make RUN_EXPENSIVE_TESTS=yes check the error is See tests/test-suite.log Please report to bug-coreutils@gnu.org Thanks for the report. However, you didn't follow

bug#10900: Regarding the observed bugs in cp

1. cp -r a a cp: cannot copy a directory, `a', into itself, `a/a' as per this the it is not allowable to copy a into a.But its doing 2. cp -s b ../ cp: `../b': can make relative symbolic links only in current directory its a symbolic link and should not restrict to current directory. i have

bug#9718: bugs in `date` command?

Jim Meyering wrote: Eric Blake wrote: ... As currently coded in the grammar, this is correct. But if someone were willing to put forth the effort to update parsedate.y, as well as enhance the testsuite to cover things, it might be possible to improve the grammar to accept both common

bug#9718: bugs in `date` command?

severity 9718 wishlist tags 9718 + notabug thanks Eric Blake wrote: ... As currently coded in the grammar, this is correct. But if someone were willing to put forth the effort to update parsedate.y, as well as enhance the testsuite to cover things, it might be possible to improve the grammar

bug#9718: bugs in `date` command?

Bryan Lee wrote: The term third wednesday seems to be evaluating incorrectly. glaive 12:24:56 [~]% date Mon Oct 10 12:24:59 EDT 2011 glaive 12:24:59 [~]% date -d first wednesday Wed Oct 12 00:00:00 EDT 2011 glaive 12:25:09 [~]% date -d second wednesday Wed Oct 12 00:00:01 EDT 2011

bug#9718: bugs in `date` command?

On 10/11/2011 01:31 AM, Voelker, Bernhard wrote: Bryan Lee wrote: The term third wednesday seems to be evaluating incorrectly. glaive 12:24:56 [~]% date Mon Oct 10 12:24:59 EDT 2011 glaive 12:24:59 [~]% date -d first wednesday Wed Oct 12 00:00:00 EDT 2011 glaive 12:25:09 [~]% date -d second

bug#9718: bugs in `date` command?

The term third wednesday seems to be evaluating incorrectly. glaive 12:24:56 [~]% date Mon Oct 10 12:24:59 EDT 2011 glaive 12:24:59 [~]% date -d first wednesday Wed Oct 12 00:00:00 EDT 2011 glaive 12:25:09 [~]% date -d second wednesday Wed Oct 12 00:00:01 EDT 2011 glaive 12:25:16 [~]% date

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

Paul Eggert wrote: That probably deserves a NEWS entry Thanks, I pushed this: Thanks. Closing.

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

On 07/24/10 18:13, Pádraig Brady wrote: That probably deserves a NEWS entry Thanks, I pushed this: From 01ca128807be89f7a2709e7a12e2cd1498f3d96b Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Sun, 25 Jul 2010 10:53:42 -0700 Subject: [PATCH] du: add NEWS entry for recent du

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

No further comment, and that patch does fix some real bugs and seems to be pretty safe, so I took the liberty of pushing it.

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

sometimes screws up, in that it doesn't report dangling symlinks, or it mistakenly counts the disk space for a symlink instead of for the pointed-to file, or it omits a directory entirely. Most of these bugs with du -L have been present for some time, but one (the omission) is something I introduced

bug#5979: installation bugs

Bob Proulx wrote: What is ns2? Since nothing has been heard in response I assume that your problem has been resolved satisfactorily by the previous response. Therefore I am closing this bug. It will remain in the archive and will remain available for further comment. Bob You have reached

bug#5979: installation bugs

I'm trying to install ns2 under linux fedora 12. Could you please help me in fixing these installation bugs: /root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:244: error: ‘TkBorder’ has no member named ‘darkGC’ /root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:245: error: ‘TkBorder

bug#5979: installation bugs

tags 5979 + moreinfo retitle 5979 ns2 installation problems thanks Najla Al-Nabhan wrote: I'm trying to install ns2 under linux fedora 12. Could you please help me in fixing these installation bugs: What is ns2? You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic

bug#5788: Savannah Bugs link broken

On the Savannah coreutils project page: https://savannah.gnu.org/bugs/?func=additemgroup=coreutils The Bugs link points to: http://debbugs.gnu.org/coreutils/ But that location produces an HTTP 404 Not Found error. The working link location is: http://debbugs.gnu.org/coreutils I don't

bug#5788: Savannah Bugs link broken

Bob Proulx wrote: The Bugs link points to: http://debbugs.gnu.org/coreutils/ But that location produces an HTTP 404 Not Found error. The working link location is: http://debbugs.gnu.org/coreutils Ah... I found where to correct this on Savannah. I also fixed the Patches link too. Bob

Re: new mailing list for non-bugs: coreut...@gnu.org

usage questions and general discussion on the new list. Otherwise, we'll have to close each of those non-bugs. No big deal if people forget -- I'm sure it will take a while for the word to get out. And finger-retraining takes time, too. Let's start with this policy: is if it might be a bug

Re: new mailing list for non-bugs: coreut...@gnu.org

Jim Meyering wrote: Sven Joachim wrote: As for the group name, gmane.comp.gnu.core-utils.general seems to be a reasonable choice. Like Bob, I would have preferred to spell it coreutils, but I think we're stuck with gmane's existing/legacy spelling. Legacy like this?

Re: new mailing list for non-bugs: coreut...@gnu.org

On 2010-03-08 08:59 +0100, Jim Meyering wrote: Sven Joachim wrote: I would like to subscribe this new list to Gmane¹ if nobody has done Thanks! That would be useful. this yet. I suppose address encryption² could be turned off (makes it somewhat more convenient to reply) ? Personally I

Re: new mailing list for non-bugs: coreut...@gnu.org

Bob Proulx wrote: Jim Meyering wrote: Sven Joachim wrote: As for the group name, gmane.comp.gnu.core-utils.general seems to be a reasonable choice. Like Bob, I would have preferred to spell it coreutils, but I think we're stuck with gmane's existing/legacy spelling. Legacy like this?

Re: new mailing list for non-bugs: coreut...@gnu.org

On 2010-03-08 09:57 +0100, Jim Meyering wrote: Bob Proulx wrote: Legacy like this? http://dir.gmane.org/gmane.comp.gnu.coreutils.announce Good point. Forgot about that. And that's the one *I* requested. It's just that I don't use that one as much and had become inured to the

new mailing list for non-bugs: coreut...@gnu.org

, we'll have to close each of those non-bugs. No big deal if people forget -- I'm sure it will take a while for the word to get out. And finger-retraining takes time, too. Let's start with this policy: is if it might be a bug, send it to bug-coreut...@gnu.org. Otherwise, use the new list: coreut

Re: new mailing list for non-bugs: coreut...@gnu.org

I'm assuming non-bug-fix patch submissions (i.e. adding features) should go to bug-coreutils still?

Re: new mailing list for non-bugs: coreut...@gnu.org

Chen Guo wrote: I'm assuming non-bug-fix patch submissions (i.e. adding features) should go to bug-coreutils still? Yes. I've made coreutils-patc...@gnu.org an alias for bug-coreutils.

Re: new mailing list for non-bugs: coreut...@gnu.org

and general discussion on the new list. Otherwise, we'll have to close each of those non-bugs. No big deal if people forget -- I'm sure it will take a while for the word to get out. And finger-retraining takes time, too. Let's start with this policy: is if it might be a bug, send it to bug

Re: new mailing list for non-bugs: coreut...@gnu.org

Sven Joachim wrote: As for the group name, gmane.comp.gnu.core-utils.general seems to be a reasonable choice. If we are voting then I would vote for coreutils and not core-utils. Bob

Re: new mailing list for non-bugs: coreut...@gnu.org

On 2010-03-08 08:50 +0100, Bob Proulx wrote: Sven Joachim wrote: As for the group name, gmane.comp.gnu.core-utils.general seems to be a reasonable choice. If we are voting then I would vote for coreutils and not core-utils. Yes, good point. It's just a bug that bug-coreutils@gnu.org is

Re: two new chroot bugs

Hi Jim, Jim Meyering j...@meyering.net writes: From cfe8e7a0001a10d4deceb6065134fe8c402d0368 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 28 May 2009 22:36:05 +0200 Subject: [PATCH 1/4] tests: use nobody as the default group name in chroot test the nobody

Re: two new chroot bugs

Giuseppe Scrivano wrote: Hi Jim, Jim Meyering j...@meyering.net writes: From cfe8e7a0001a10d4deceb6065134fe8c402d0368 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 28 May 2009 22:36:05 +0200 Subject: [PATCH 1/4] tests: use nobody as the default group name in

two new chroot bugs

Eric Blake wrote: According to Jim Meyering on 5/26/2009 7:21 AM: Merged and pushed. Thanks again. Would it be worth starting to patch the testsuite to replace 'setuidgid -g list usr cmd arg' with 'chroot --user usr --groups=list / cmd arg' in order to give this feature more exposure and

Re: two new chroot bugs

Jim Meyering wrote: ... Here are patches, for review. I'll add tests tomorrow. That latter log wasn't complete. Subject: [PATCH] chroot: don't set bogus user-ID or group-ID for --u=U or --u=:G * src/chroot.c (main): Initialize both uid and gid. To -1. This also allows one to set the

[PATCH] Fix arpa_inet bugs found when installing coreutils 7.2 on Solaris 8.

+ Fix bugs found when installing coreutils 7.2 on Solaris 8. + + * lib/arpa_inet.in.h (inet_ntop): Define to rpl_inet_ntop when + we implement it, to avoid colliding with Solaris 8's incompatible + declaration of the function (Solaris 8 lacks 'restrict'). + (inet_pton

Re: Bugs!

On Wed, Apr 1, 2009 at 1:41 AM, Henry Purvis golfer81...@yahoo.com wrote: Hi, um.my name is henry and there is a bug on an application I have (from cydia) and I typed in iPod --help on 'terminal' and it said to contact you guys to say that there was a bug.so could you please get it

Bugs!

Hi, um.my name is henry and there is a bug on an application I have (from cydia) and I typed in iPod --help on 'terminal' and it said to contact you guys to say that there was a bug.so could you please get it fixed? PLEASE! Thank you,

Multiple bugs and problems

in human readable form %t Type in hex Report bugs to bug-coreutils@gnu.org. vaio:~# Please note that the virus scannere seemed to work in the administrator window; however it detected a virus in the boot/linux-swap.swp. It could not repair but only quarentine. When deleated it was not able

Re: Multiple bugs and problems

On Friday 27 February 2009 21:54:55 Jen Donier wrote: We have been working with Michael LeBlanc at Xandros Support and have had one problem after another with the new Xandros 4 which we purchased in December and installed. See details below. so you should keep working with Xandros.

Old bugs in the man true man false

I apologise if this has been fixed already but we have an old version of RedHat. Both man true and man false state DESCRIPTION These option names may not be abbreviated. --help display this help and exit --version output version information and exit However

Re: Old bugs in the man true man false

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to peter.law...@barclayscapital.com on 2/20/2009 12:00 PM: However both true and false ignore any options provided. They do not support these options. Solution: delete their mention from the man pages. Not a bug, but a misunderstanding

Re: Bugs in unexpand(1) version 6.10

On Wednesday 11 February 2009 02:04:11 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: ... i was thinking a common change to the version-etc module to add a packager field rather than having every package out there allow people to tweak PACKAGE_NAME. what do you think of

Re: Bugs in unexpand(1) version 6.10

. This seems fine, but can we also include the information in --help, which is what we did when we amended the coding standards a few days ago? For instance, grep 2.5.4 --help ends with: Report bugs to: bug-g...@gnu.org GNU Grep home page: http://www.gnu.org/software/grep/ General help using GNU

Re: Bugs in unexpand(1) version 6.10

does this Please include a url to your downstream coreutils package in the distro string. This seems fine, but can we also include the information in --help, which is what we did when we amended the coding standards a few days ago? For instance, grep 2.5.4 --help ends with: Report bugs

Re: Bugs in unexpand(1) version 6.10

Mike Frysinger vap...@gentoo.org wrote: On Friday 06 February 2009 01:13:13 Jim Meyering wrote: Pádraig Brady p...@draigbrady.com wrote: Mike Frysinger wrote: On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009

Re: Bugs in unexpand(1) version 6.10

Mike Frysinger vap...@gentoo.org wrote: ... i was thinking a common change to the version-etc module to add a packager field rather than having every package out there allow people to tweak PACKAGE_NAME. what do you think of that ? Sounds sensible. The question then becomes whether to

Re: Bugs in unexpand(1) version 6.10

On Friday 06 February 2009 01:13:13 Jim Meyering wrote: Pádraig Brady p...@draigbrady.com wrote: Mike Frysinger wrote: On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What

Re: Bugs in unexpand(1) version 6.10

Mike Frysinger wrote: On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What distribution are you using (I'm guessing Fedora 10). Distributions that patch coreutils really should modify the

Re: Bugs in unexpand(1) version 6.10

Mike Frysinger wrote: On Thursday 05 February 2009 20:03:36 Pádraig Brady wrote: Mike Frysinger wrote: On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What distribution are you using (I'm

Re: Bugs in unexpand(1) version 6.10

Pádraig Brady p...@draigbrady.com wrote: Mike Frysinger wrote: On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What distribution are you using (I'm guessing Fedora 10). Distributions that

Re: Bugs in unexpand(1) version 6.10

On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote: Mike Frysinger vap...@gentoo.org wrote: On Friday 23 January 2009 09:35:54 Pádraig Brady wrote: What distribution are you using (I'm guessing Fedora 10). Distributions that patch coreutils really should modify the version string

  1   2   >