bug#11858: df -m undocumented, why no df -g

2012-07-05 Thread Paul Eggert
On 07/04/2012 11:48 PM, Bernhard Voelker wrote: > Wouldn't it then be consequent to remove the long option --megabyte? Yes, that does make sense.

bug#11854: make syntax-check -j issue

2012-07-05 Thread Jim Meyering
Bernhard Voelker wrote: > After pulling to the lastest revision (v8.17-37-g74427c7) and > a successful build (make -j), a subsequent "make syntax-check -j" > failed: > > ... > 8.47 vulnerable_makefile_CVE-2009-4029 > 8.78 copyright_check > CC hostname.o > CCLD arch > CCLD

bug#11858: df -m undocumented, why no df -g

2012-07-05 Thread Eric Blake
On 07/05/2012 12:48 AM, Bernhard Voelker wrote: >> I think the general idea is that -k was a mistake, but >> it's standardized, and that we don't want to have >> options -m, -g, -t, -p, -e, -z, -y for the other sizes >> (among other things -t is already taken). -m is there >> only for BSD compati

bug#11858: df -m undocumented, why no df -g

2012-07-05 Thread Jim Meyering
Bernhard Voelker wrote: > On 07/04/2012 09:38 PM, Paul Eggert wrote: >> On 07/04/2012 01:11 AM, Andreas Jaeger wrote: >>> df -k and df -m both work but only df -k is mentioned as part of df -- >>> help. So, the omission to document -m is IMO a bug. >> >> I think the general idea is that -k was a mi

bug#11858: df -m undocumented, why no df -g

2012-07-05 Thread Bernhard Voelker
On 07/05/2012 02:35 PM, Jim Meyering wrote: > However, I'm tempted to remove it directly this time, since it's been > undocumented for a while: > > 5 years in df.1 and df --help: COREUTILS-6_9-151-g1e07a21 > 11 years in coreutils.texi: FILEUTILS-4_1_4-28-gf5bf6fe > > What do you think? I ag

bug#11858: df -m undocumented, why no df -g

2012-07-05 Thread Jim Meyering
Bernhard Voelker wrote: > On 07/05/2012 02:35 PM, Jim Meyering wrote: >> However, I'm tempted to remove it directly this time, since it's been >> undocumented for a while: >> >> 5 years in df.1 and df --help: COREUTILS-6_9-151-g1e07a21 >> 11 years in coreutils.texi: FILEUTILS-4_1_4-28-gf5bf6fe

bug#11866: command date don't accept 61 sec. minutes

2012-07-05 Thread Juergen Heine
According to The International Earth Rotation Service (IERS) we have "Leap Seconds" included in our UTC time. Please refer http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat . ~ snip ~ A positive leap second will be introduced at the end of June 2012. The sequence of dates of the UTC second mar

bug#11866: Acknowledgement (command date don't accept 61 sec. minutes)

2012-07-05 Thread Juergen Heine
Hello, can you please do me a favor and correct the typo in the title? don't -> doesn't Thank you for the GNU system! -- Mit freundlichen Grüßen / Sincerely i. A. Juergen Heine juergen.he...@qvs-deutschland.de QVS GmbH Lange Laube 18 D-30159 Hannover http://www.qvs-deutschland.de Tel: 05

bug#11866: command date don't accept 61 sec. minutes

2012-07-05 Thread Eric Blake
retitle 11866 date doesn't accept 61-sec. minutes tag moreinfo thanks On 07/05/2012 02:15 AM, Juergen Heine wrote: > A positive leap second will be introduced at the end of June 2012. > The sequence of dates of the UTC second markers will be: > > 2012 June 30, 23h 59m 59s > 2012 June 30, 23h

bug#11866: command date doesn't accept 61 sec. minutes

2012-07-05 Thread Juergen Heine
On 05/07/12 18:39, Eric Blake wrote: > retitle 11866 date doesn't accept 61-sec. minutes thank you for the correction. > The command 'date' doesn't have any control over whether your system is > configured to honor or ignore leap seconds. Some systems are > intentionally configured to ignore lea

bug#11866: command date doesn't accept 61 sec. minutes

2012-07-05 Thread Paul Eggert
On 07/05/2012 01:05 PM, Juergen Heine wrote: > If i'm correct, can we add this information to the manual for > people who don't understand the simple line "leap seconds are > getting ignored"? Sure, I added the following and am marking this as done. >From bfda96e0ac5552bb1784f5e1dc311918ce077d50