bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

On Tue, Apr 16, 2019 at 1:37 PM Assaf Gordon  wrote:

> Thank you both for testing.
>
> So, to summarize:
> whenever "inv-year" fails - it is a problem with glibc on your
> setup, *not* a problem in coreutils' date(1) program.
>
> If there is a setup where "inv-year" succeeds but date(1) still fails,
> then it is a problem in coreutils.
>
> I'm glad to hear latest Ubuntu 19.04 is working fine
> (though the reason for the earlier failure is still a mystery).
>
> As Paul suggested, trying 'strace' on the failing system
> might reveal more details.

Will run strace again. Meanwhile, I decided to test time zones. My
default TZ is America/Chicago -- in my laptop date fails. I then moved
to TZ=UTC, and it worked:

cerdea@piatam:~/Downloads$ echo $TZ
America/Chicago
cerdea@piatam:~/Downloads$ date
Tue Apr 16 10:04:48 CDT 2019

130 cerdea@piatam:~/Downloads$ date --debug +%-Y -d '- 110 years'
date: parsed relative part: -110 year(s)
date: input timezone: TZ="America/Chicago" environment value
date: using current time as starting value: '10:05:01'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 10:05:01'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: error: adding relative date resulted in an invalid date:
'(Y-M-D) 1909-04-16 10:05:01'
date: invalid date ‘- 110 years’

1 cerdea@piatam:~/Downloads$ export TZ=UTC
cerdea@piatam:~/Downloads$ date --debug +%-Y -d '- 110 years'
date: parsed relative part: -110 year(s)
date: input timezone: TZ="UTC" environment value
date: using current time as starting value: '15:05:21'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 15:05:21'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-110 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 1909-04-16 15:05:21'
date: '(Y-M-D) 1909-04-16 15:05:21' = -1915865679 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: -1915865679.603138125 (epoch-seconds)
date: final: (Y-M-D) 1909-04-16 15:05:21 (UTC)
date: final: (Y-M-D) 1909-04-16 15:05:21 (UTC+00)
1909

Will keep on trying.
-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

It has to be something messing/interacting with coreutils/date on
19.04 (and probably on Tumbleweed).

I created a new container with 19.04, and then:
* apt build-dep coreutils
* apt install rsync wget git
* git clone git://git.sv.gnu.org/coreutils
* cd coreutils
* export FORCE_UNSAFE_CONFIGURE=1 # too lazy to adduser
* ./boostrap
* ./configure
* make

at the end of the build I ran both the provided date and the
just-built one. Both ran correctly:

root@u1904:~/coreutils# date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:39'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:39'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:39'
date: '(Y-M-D) 0009-04-16 00:30:39' = -61874062161 epoch-seconds
date: timezone: system default
date: final: -61874062161.081576777 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC+00)
9

root@u1904:~/coreutils# src/date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:49'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:49'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:49'
date: '(Y-M-D) 0009-04-16 00:30:49' = -61874062151 epoch-seconds
date: timezone: system default
date: final: -61874062151.239637280 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC+00)
9

I then compiled & ran Asaf's inv-year.c:

root@u1904:~# gcc -o inv-year inv-year.c
root@u1904:~# ./inv-year
time() = 1555375408
localtime() = 2019-04-16 00:43:28
  (mday=16 wday=2, isdst=0)
struct tm (after adjustment) = 0009-04-16 00:43:28
   (mday=16 wday=2, isdst=0)
mktime() after date adjustment = -61874061392

So: a pristine 19.04 runs it. My laptop (which is my work machine,
full of other packages & programs), does not.

Oh -- Assaf, yes, I am very well aware 19.04 has not yet been
released. But -- unless we find something critical -- it is basically
what will be  released in a few days. I do not expect a rebuild of the
coreutils package, for example.

Cheers,

..C..

On Mon, Apr 15, 2019 at 6:11 PM O. Emmerson  wrote:
>
> On 15/04/2019 21:55, Assaf Gordon wrote:
> > To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> > issue, can you (and/or others) try the attached C program?
> >
> > It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
> >
> > Because the adjustment is to year 9 (about 1961 years before epoch),
> > the time_t value is negative. perhaps that's the issue? or perhaps
> > combined with a specific timezone it becomes problematic?
>
> For me it gives:
>
> $ ./inv-year
> time() = 1555369320
> localtime() = 2019-04-16 00:02:00
>(mday=16 wday=2, isdst=1)
> struct tm (after adjustment) = 0009-04-16 00:02:00
> (mday=16 wday=2, isdst=1)
> inv-year: mktime() failed: Value too large for defined data type
>
>
> And debug gives:
>
> $ date +%-Y -d "- 112 years" --debug
> date: parsed relative part: -112 year(s)
> date: input timezone: system default
> date: using current time as starting value: '00:04:32'
> date: using current date as starting value: '(Y-M-D) 2019-04-16'
> date: starting date/time: '(Y-M-D) 2019-04-16 00:04:32'
> date: warning: when adding relative months/years, it is recommended to
> specify the 15th of the months
> date: error: adding relative date resulted in an invalid date: '(Y-M-D)
> 1907-04-16 00:04:32'
> date: invalid date ‘- 112 years’
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

cerdea@piatam:~/Downloads$ gcc -o inv-year inv-year.c
cerdea@piatam:~/Downloads$ ./inv-year
time() = 1555368087
localtime() = 2019-04-15 17:41:27
 (mday=15 wday=1, isdst=1)
struct tm (after adjustment) = 0009-04-15 17:41:27
  (mday=15 wday=1, isdst=1)
inv-year: mktime() failed: Value too large for defined data type
1 cerdea@piatam:~/Downloads$

On Mon, Apr 15, 2019 at 3:55 PM Assaf Gordon  wrote:
>
> Thanks Bernhard,
>
> On 2019-04-15 2:14 p.m., Bernhard Voelker wrote:
> > I can easily reproduce here on my regular openSUSE:Tumbleweed from latest 
> > git:
> >
> >$ src/date --debug '+%-Y' -d '- 2010 years'
> []
> >date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
> > 0009-04-15 22:10:37'
>
> This makes it easy to pinpoint (hooray for "--debug" :) ).
>
> This error is given if gnulib's "mktime_z" fails
> to convert the adjusted "struct tm" to "time_t"
> (adjusted because its tm_year was decremented by 2010).
>
> https://opengrok.housegordon.com/source/xref/gnulib/lib/parse-datetime.y#2177
>
> To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> issue, can you (and/or others) try the attached C program?
>
> It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
>
> Because the adjustment is to year 9 (about 1961 years before epoch),
> the time_t value is negative. perhaps that's the issue? or perhaps
> combined with a specific timezone it becomes problematic?
>
> On my system it gives:
> 
>$ gcc -o inv-year inv-year.c
>
>$ ./inv-year
>time() = 1555361050
>localtime() = 2019-04-15 14:44:10
>  (mday=15 wday=1, isdst=1)
>struct tm (after adjustment) = 0009-04-15 14:44:10
>   (mday=15 wday=1, isdst=1)
>mktime() after date adjustment = -61874070118
> 
>
>
> regards,
>   - assaf
>
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

I have ran a few tests on Ubuntu 16.04, 18.04, 18.10, and 19.04 (all X86_64):

16.04:

root@u1604:~# date +%-Y -d '- 2010 years'
9
root@u1604:~# date --version
date (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.04:

root@bionic:~# date +%-Y -d '- 2010 years'
9
root@bionic:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.10:

root@u1810:~# date +%-Y -d '- 2010 years'
9
root@u1810:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

19.04:

cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Interestingly, it is also failing on git head:

130 cerdea@piatam:/data/buildd/coreutils$ src/date +%-Y -d '- 2010 years'
src/date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ src/date --version
date (GNU coreutils) 8.31.12-6d78a
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson  wrote:
>
> $ file /bin/date
> /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
> stripped
>
>
>
>


-- 
..hggdh..

bug#15257: stat and df report different filesystems for /dev

[C de-Avillez]

original Ubuntu bug: https://bugs.launchpad.net/bugs/1219529

Tested on linux 3.11.RC7 and 3.8.8, coreutils 8.20 and 8.21

When trying to use 'df -x tmpfs', /dev is still shown:

hggdh@chatto:~$ df -x tmpfs | grep udev
udev  247532   8247524   1% /dev

But 'stat' reports the filesystem as 'tmpfs':

hggdh@chatto:~$ stat -f /dev
  File: /dev
ID: 0Namelen: 255 Type: tmpfs
Block size: 4096   Fundamental block size: 4096
Blocks: Total: 61883  Free: 61881  Available: 61881
Inodes: Total: 61883  Free: 61479

This seems to happen because -- really -- the type is 'devtmpfs':

hggdh@chatto:~$ mount | grep udev
udev on /dev type devtmpfs (rw,mode=0755)

And, indeed, running 'df -x devtmpfs' works:

hggdh@chatto:~$ df -x devtmpfs
Filesystem 1K-blocksUsed Available Use% Mounted on
/dev/vda20511356 2518320  16944460  13% /
none   4   0 4   0% /sys/fs/cgroup
tmpfs  50300 232 50068   1% /run
none5120   0  5120   0% /run/lock
none  251484  52251432   1% /run/shm
none  102400   0102400   0% /run/user

I feel this is incorrect: even though 'info mount' does not list devtmpfs
as a possible FS type (which might be another bug in itself, but outside
coreutils), at least 'stat' and 'df' should be consistent on their output.

Cheers,

-- 
..hggdh..

bug#7255:

[C de-Avillez]

On Thu, 21 Oct 2010 00:28:40 +0200
Artur Rona ari-tc...@tlen.pl wrote:

 I am not an author of this patch, just only forwarder. We would like
 to upload a fix to this bug. I hoped that this patch will be helpful
 for coreutils developers.

The idea of this patch (which I copied, as in the LP bug, from Fedora)
was to provide a stopgap option until the Linux kernel implements the
equivalent.

The reason was (or, I guess, still is) that some upstream source rely
on this being available, and having the '-i' or '-p' would minimise
our deltas.

But I knew, from the beginning, that it would not be acceptable
upstream. Perhaps with a confluence of all Linux distros that might
happen, though.

Cheers,

-- 
C de-Avillez
IRC: hggdh

This email (and any attachments) is digitally signed using GNUpg
(http://gnupg.org). The public key is available at http://pgp.mit.edu.
The key Id is 0xD3133E56.


signature.asc
Description: PGP signature

bug#7061: loop on touch (fdutimens)

[C de-Avillez]

 and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, Arnold Robbins, Jim Kingdon,
David MacKenzie, and Randy Smith.
cer...@xango2:/build/buildd/coreutils$ 


-- 
C de-Avillez
IRC: hggdh

This email (and any attachments) is digitally signed using GNUpg
(http://gnupg.org). The public key is available at http://pgp.mit.edu.
The key Id is 0xD3133E56.


signature.asc
Description: PGP signature

bug#7061: loop on touch (fdutimens)

[C de-Avillez]

On Fri, 17 Sep 2010 19:03:30 -0700
Paul Eggert egg...@cs.ucla.edu wrote:

 On 09/17/2010 05:49 PM, C de-Avillez wrote:
 
  I just built  ran a quick test on coreutils GIT. I received a
  SEGV on touch, and ran it under GDB.
 
 I don't observe the problem.  I just now grabbed a fresh copy of
 coreutils. I ran your test on Ubuntu 10.04 x86 and on RHEL 5 x86-64.

I am running it on Ubuntu Maverick (soon to-be 10.10). I do not have
another Linux distro to test right now, but I will build a 10.04 on
KVM.

 My guess is that you are running coreutils with a slightly
 out-of-date gnulib, or vice versa.  You need to have either both of
 the following patches, or neither of them.
 
 http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2dd21704d63c4e7567695a9e43dc1631b930efe2
 
 http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=89b0db35db10a8beccaf83909c7f62f127fb5821

Both are applied on my git copy. Hum. I will go and redo it from a
fresh git copy.

Thanks, Paul. I will post what I find.

-- 
C de-Avillez
IRC: hggdh

This email (and any attachments) is digitally signed using GNUpg
(http://gnupg.org). The public key is available at http://pgp.mit.edu.
The key Id is 0xD3133E56.


signature.asc
Description: PGP signature

bug#6235: hostname and -b option

[C de-Avillez]

On Thu, 2010-05-20 at 16:31 -0600, Eric Blake wrote:
  Unfortunately, Ubuntu's startup script puts /usr/local/bin ahead of
  /bin and /usr/bin, thus getting a version of hostname that chokes on
  the -b option.  We patched the configuration file to force an explicit
  path:
  
  exec /bin/hostname -b -F /etc/hostname
 
 Correct - Ubuntu's script is buggy if it uses non-standard options
 without an explicit path to a version of the utility known to provide
 those options.

Ubuntu does not install *anything* under /usr/local -- this is a path
reserved for local stuff. On Ubuntu, 'hostname' is installed from the
hostname package. As such, there are no non-standard options being
played.

snip/

  [I'm not urging that this be done, merely that it be discussed.  In my
  view, Ubuntu is at fault for introducing nonstandard options, and
  messing up the boot PATH, and failing to use explicit paths on
  critical boot-time commands.
 
 Your view is correct.
 

I was looking at the coreutils source (git). 'hostname' is set not to be
installed by default (together with 'arch' and 'su') -- unless one
runs ./configure  --instal-program=hostname.

I am failing to see how Ubuntu is messing up the boot path;
additionally, there is no conflict for 'hostname' unless one installs
something outside of the distribution (but, then, all bets are off,
anyways). For example, I usually run coreutils git, and have no problems
like the OP.

Thank you,

..C..


signature.asc
Description: This is a digitally signed message part

Re: Suggestion for rm(1)

[C de-Avillez]

On Wed, 10 Mar 2010 14:08:33 +
Reuben Thomas r...@sc3d.org wrote:

 2010/3/10 Pádraig Brady p...@draigbrady.com:
  How about just doing: s/is usually/might be/
 
 That seems to me to go a little too far towards reassuring the user
 that the data has probably gone. We want to say two not obviously
 conflicting things:
 
 1. After rm the data is most probably still there.
 
 2. After rm it's probably quite a bit of trouble to recover it.
 

How about ... it might be possible, but not easy, to recover ...?

Cheers,

..C..


signature.asc
Description: PGP signature

unexpected result on basename/dirname

[C de-Avillez]

Hello,

I cannot explain the following difference between running a 'find -exec
basename {}', and a 'find -exec echo $(basename {})', and the same for
dirname. I am running GIT coreutils off /usr/local, so the absolute
paths. I would really appreciate help in undersstanding what is the
difference.

cer...@xango:~/Téléchargements$ find . -type f -exec echo {} \;
./test.sh
./ati-driver-installer-9-3-x86.x86_64.run
./test/aFile

cer...@xango:~/Téléchargements$ find . -type f -exec
/usr/local/bin/basename {} \;
test.sh
ati-driver-installer-9-3-x86.x86_64.run
aFile

cer...@xango:~/Téléchargements$ find . -type f -exec echo
$(/usr/local/bin/basename {}) \;
./test.sh
./ati-driver-installer-9-3-x86.x86_64.run
./test/aFile

cer...@xango:~/Téléchargements$ find . -type f -exec dirname {} \;
.
.
./test

cer...@xango:~/Téléchargements$ find . -type f -exec
/usr/local/bin/dirname {} \;
.
.
./test

cer...@xango:~/Téléchargements$ find . -type f -exec echo
$(/usr/local/bin/dirname {}) \;
.
.
.

cer...@xango:~/Téléchargements$ /usr/local/bin/basename --version
basename (GNU coreutils) 8.4.12-5d4952
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
cer...@xango:~/Téléchargements$

Thank you,

..C..




signature.asc
Description: OpenPGP digital signature

Re: unexpected result on basename/dirname

[C de-Avillez]

On 02/17/2010 08:20 PM, Bob Proulx wrote:
 The shell is processing $(...) on the command line before passing the
 result as an argument to the command.  You can see this using echo.

Thank you Bob. I was pretty sure it would be something I should have
known... and you proved me right ;-)

Sorry

..C..



signature.asc
Description: OpenPGP digital signature

Re: ls --color=always and unterminated last line of output

[C de-Avillez]

On 2009-12-31 13:17, Jim Meyering wrote:
  C de-Avillez wrote:
  
  Original Ubuntu bug:
  https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/494663
 
  Reporter complains last line of a 'ls --color=always' is unterminated,
  causing grief on a pipe to 'ls -FXR'.
 
snip/
  
  Here's a potential solution.
  The ls.c change not pretty, but I think it is correct.
  I'm not sure this belongs in coreutils-8.3, but I'm considering it.
  
 From bbeb3d4f3db5366fbfed6675e964d47dc9efa9d3 Mon Sep 17 00:00:00 2001
  From: Jim Meyering meyer...@redhat.com
  Date: Thu, 31 Dec 2009 20:09:06 +0100
  Subject: [PATCH] ls --color: don't emit a final no-op escape sequence
  
Current GIT requires more changes in misc/ls-misc. Specifically,
sl-dangle, sl-dangle-3, sl-dangle-4 and sl-dangle-5 .

I have adjusted the patch, and am submitting it for consideration.

Regards,

..C..

From c9ce23aa1830fbe91937d24d849ccae6d5a3c243 Mon Sep 17 00:00:00 2001
From: C de-Avillez hgg...@gmail.com
Date: Sat, 30 Jan 2010 16:52:46 -0600
Subject: [PATCH] ls --color: don't emit a final no-op escape sequence

* src/ls.c (main): With --color, avoid emitting the final color-
resetting escape sequence when it would be a no-op.
* tests/ls/color-clear-to-eol: Adjust expected output accordingly.
* tests/ls/color-dtype-dir: Likewise.
* tests/ls/multihardlink: Likewise.
* tests/ls/stat-free-symlinks: Likewise.
* tests/misc/ls-misc: Likewise.
Reported by Jim Avera in
http://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/494663
---
 src/ls.c|   10 +-
 tests/ls/color-clear-to-eol |2 +-
 tests/ls/color-dtype-dir|4 
 tests/ls/multihardlink  |   11 +--
 tests/ls/stat-free-symlinks |1 -
 tests/misc/ls-misc  |   17 -
 6 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/ls.c b/src/ls.c
index 9ef7eba..680679a 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -1442,7 +1442,15 @@ main (int argc, char **argv)
   int j;
 
   if (used_color)
-restore_default_color ();
+{
+  /* Skip the restore when it would be a no-op, i.e.,
+ when left is \033[ and right is m.  */
+  if (!(color_indicator[C_LEFT].len == 2
+ memcmp (color_indicator[C_LEFT].string, \033[, 2) == 0
+ color_indicator[C_RIGHT].len == 1
+ color_indicator[C_RIGHT].string[0] == 'm'))
+restore_default_color ();
+}
   fflush (stdout);
 
   /* Restore the default signal handling.  */
diff --git a/tests/ls/color-clear-to-eol b/tests/ls/color-clear-to-eol
index 96944cb..1be68ca 100755
--- a/tests/ls/color-clear-to-eol
+++ b/tests/ls/color-clear-to-eol
@@ -29,7 +29,7 @@ touch $long_name || framework_failure
 e='\33'
 color_code='0;31;42'
 c_pre=$e[0m$e[${color_code}m
-c_post=$e[0m$e[K\n$e[m
+c_post=$e[0m$e[K\n
 printf $c_pre$long_name$c_post\n  exp || framework_failure
 
 env TERM=xterm COLUMNS=80 LS_COLORS=*.foo=$color_code TIME_STYLE=+T \
diff --git a/tests/ls/color-dtype-dir b/tests/ls/color-dtype-dir
index 6532d84..29b872c 100755
--- a/tests/ls/color-dtype-dir
+++ b/tests/ls/color-dtype-dir
@@ -36,7 +36,6 @@ chmod o+t sticky || framework_failure
 
 ls --color=always  out || fail=1
 cat -A out  o1 || fail=1
-echo  o1 || fail=1
 mv o1 out || fail=1
 
 cat \EOF  exp || fail=1
@@ -44,7 +43,6 @@ cat \EOF  exp || fail=1
 ^[[34;42mother-writable^[[0m$
 out$
 ^[[37;44msticky^[[0m$
-^[[m
 EOF
 
 compare out exp || fail=1
@@ -56,7 +54,6 @@ rm exp
 
 LS_COLORS=ow=: ls --color=always  out || fail=1
 cat -A out  o1 || fail=1
-echo  o1 || fail=1
 mv o1 out || fail=1
 
 cat \EOF  exp || fail=1
@@ -64,7 +61,6 @@ cat \EOF  exp || fail=1
 ^[[01;34mother-writable^[[0m$
 out$
 ^[[37;44msticky^[[0m$
-^[[m
 EOF
 
 compare out exp || fail=1
diff --git a/tests/ls/multihardlink b/tests/ls/multihardlink
index 60bb399..20a94c8 100755
--- a/tests/ls/multihardlink
+++ b/tests/ls/multihardlink
@@ -30,7 +30,6 @@ code_mh='44;37'
 code_ex='01;32'
 code_png='01;35'
 c0=$(printf '\033[0m')
-c_end=$(printf '\033[m')
 c_mh=$(printf '\033[%sm' $code_mh)
 c_ex=$(printf '\033[%sm' $code_ex)
 c_png=$(printf '\033[%sm' $code_png)
@@ -44,7 +43,7 @@ compare out out_ok || fail=1
 LS_COLORS=mh=$code_mh ls -U1 --color=always file1 file2  out || fail=1
 printf $c0${c_mh}file1$c0
 ${c_mh}file2$c0
-$c_end  out_ok || framework_failure
+  out_ok || framework_failure
 compare out out_ok || fail=1
 
 # hard links and png (hard link coloring takes precedence)
@@ -53,7 +52,7 @@ LS_COLORS=mh=$code_mh:*.png=$code_png ls -U1 --color=always 
file1 file2.png \
out || fail=1
 printf $c0${c_mh}file1$c0
 ${c_mh}file2.png$c0
-$c_end  out_ok || framework_failure
+  out_ok || framework_failure
 compare out out_ok || fail=1
 
 # hard links and exe (exe coloring takes precedence)
@@ -63,7 +62,7 @@ LS_COLORS=mh=$code_mh:*.png=$code_png:ex=$code_ex \
 chmod a-x file2.png || framework_failure
 printf $c0${c_ex}file1$c0
 ${c_ex}file2.png$c0
-$c_end  out_ok

New .po did not trigger making a new .gmo

[C de-Avillez]

Hi,

I am not sure if I messed up somewhere. On GIT head, after Stéphane told
us he had updated a new fr.po, I went ahead and:

./bootstrap  configure  make

Indeed a new fr.po was downloaded.

then I ran 'du --help' again, to see the text fixed. It was not. Same
error.
I then looked at the ./po/fr.po, and indeed it was corrected there. But
the 'fr.gmo' file was dated from some days ago (and not, as I sort of
expected, newer than the fr.po).

I then *deleted* ./po/fr.gmo, and ran make under ./po -- no regen of
fr.gmo. make ended with no action being reported. A full make did not
change anything.

Cutting to the end: the only way for me to gen the new fr.gmo was by
running 'make fr.gmo' under ./po.

There seems to be an error somewhere in there. I will try and look more
at it later on, as work permits.

Regards,

..C..







signature.asc
Description: OpenPGP digital signature

Re: New .po did not trigger making a new .gmo

[C de-Avillez]

Eric Blake a écrit :
 According to C de-Avillez on 1/22/2010 1:04 PM:
 I then *deleted* ./po/fr.gmo, and ran make under ./po -- no regen of
 fr.gmo. make ended with no action being reported. A full make did not
 change anything.
 
 That's intentional.  Use 'make dist' to force the creation of up-to-date
 .gmo files; .po files change so frequently, take enough time to compile,
 and have little to no bearing on day-to-day development, that there is
 intentionally no rule to keep them up-to-date except as part of bundling a
 distribution.

Good! Then my GIT-head package building for Ubuntu will not be
impacted (where I run a 'make dist-gzip').

Thank you, Erik.




signature.asc
Description: OpenPGP digital signature

Re: Question about adding a tiny tool into GNU coreutils

[C de-Avillez]

On 01/07/10 12:52, Daniel Borkmann wrote:

 Sorry, but this is a developer tool
 
 Despite of the language such a util is written in, I was
 wondering if it's really only a developer tool? Aren't there enough
 programs out there that do not ever print their errors correctly?
 No question that this would be a bad style, but nevertheless, it
 isn't rarely.
   

Indeed. I usually float between different customers, with different *IX
brands -- of course, not all of them use coreutils, but that's life. Not
all of them deploy PERL, or Python, or MySQL (which provides 'perror'
for that).

But, if I could rely on all that deploy coreutils to have something like
that it would make my life much more simpler.

Of course, it can still be a contrib-type of thing -- but it would be there.




signature.asc
Description: OpenPGP digital signature

Re: Question about adding a tiny tool into GNU coreutils

[C de-Avillez]

On 01/07/10 15:36, Bob Proulx wrote:
 Does it really belong in coreutils installed on every computer in the
 known universe?  I don't think my GNU toaster needs it.  So I would
 vote against putting it in coreutils.  It would be fine in a different
 project package however.  This doesn't feel like a coreutils program.
 More like a dev-utils program.
   

Well, most of the times I am at a customer, I am working on their
production machines (or User Acceptance Testing, or QA), trying to fix
something on their environment -- and these as usually as far as
possible from dev tools. Sometimes I do get to do development, and then
I have the time to set it up, if needed.

Finding out an errno in production is as important as on development,
and they do happen. Making this a dev-utils thingie will very much
guarantee I will *never* see it in prod/QA/UAT.

So, yes, I think this would make sense to belong to coreutils (from my
own quite biased view, of course)

..C..



signature.asc
Description: OpenPGP digital signature

ls --color=always and unterminated last line of output

[C de-Avillez]

Original Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/494663

Reporter complains last line of a 'ls --color=always' is unterminated,
causing grief on a pipe to 'ls -FXR'.

Indeed it is unterminated:

cer...@xango:/usr/src/buildd/coreutils/src$ ls --color=always|tail -2 |
od -Xc
0002e7365795b1b0a6f006d
  y   e   s   .   o  \n 033   [   m
011
cer...@xango:/usr/src/buildd/coreutils/src$

I am not sure this *is* a bug, and would like input from the list.

A _few_ tests I performed, on a hacked version of 'ls' where I took out
the resetting of colours, do not show any impact in terms of terminal
colouring. Obviously, these tests are not even near being a  complete
test set

On the other hand, the only usage I can see for a 'ls --color=always' is
to produce human output -- for example, as the reporter states -- 'ls
--color=always | less -FXR'. I am pretty sure an human can discard an
empty last line.

Thank you,

..C..



signature.asc
Description: OpenPGP digital signature

Re: ls --color=always and unterminated last line of output

[C de-Avillez]

On 12/31/2009 01:17 PM, Jim Meyering wrote:
 Here's a potential solution.
 The ls.c change not pretty, but I think it is correct.
 I'm not sure this belongs in coreutils-8.3, but I'm considering it.

   

I applied the patch, ran a make check, and some other manual tests
trying to get it to misbehave. All tests were successful, so far.

It would be nice to have it on 8.3 -- then I am (almost) sure we would
get it on Ubuntu 10.04.

Thank you,

..C..



signature.asc
Description: OpenPGP digital signature

ls coloured output for others writable directories difficult to read

[C de-Avillez]

Original Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/498212

The default dircolours for an others writable directory is set as blue
over green:

STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable

The end result is a combination of colours that is rather difficult to
discern (light blue over lime green), at least on my tries.

I am not sure what colour would be better (I have a bit of a problem
with some colours), but I tried red over green, and it is readable:

OTHER_WRITABLE 31;42 # dir that is other-writable (o+w) and not sticky

Would this change be acceptable? If so, I will generate a patch for it.

Thanks,

..C..





signature.asc
Description: OpenPGP digital signature

Re: ls coloured output for others writable directories difficult to read

[C de-Avillez]

On 12/30/2009 01:04 PM, Jim Meyering wrote:
 I don't see the problem: it's readable for me when using
 roxterm as my terminal emulator.
   
(snip)
 That final line is rendered with a blue background and
 with green foreground text, other-writable.
   

You meant green background with blue foreground text, I guess.

 This sounds like a complaint about the default.
 Anyone can use dircolors to set LS_COLORS to reflect their
 personal preferences.
   

I absolutely agree, and have said so on other bugs.

 Unless it's a problem for most people[*], I'm reluctant
 to change this.  Besides, world-writable directories can
 pose a security risk, so you might consider the annoyance
 to be a *feature*.  Think of it as encouragement to change
 permissions to something safer.
   

Heh, indeed.

Meanwhile I went on and tested it on the default Linux console, plus 
konsole, roxterm, Gnome terminal, and guake. Turns out the *only* one to
make the output difficult to read is Gnome terminal (all other things
being equal: default black background, default colour palette, Bitstream
Vera Mono 9).

So, if there is a problem, it is not on Coreutils.

Thank you, and sorry,



signature.asc
Description: OpenPGP digital signature

Re: Update Manager and Core Utils

[C de-Avillez]

On Tue, 13 Oct 2009 23:53:53 -0700
Jan-Pawel Wrozstinski jpw...@gmail.com wrote:

   I did a little more digging and found that coreutils (is? are?)
 supported by the Synaptic Package Manager.  It reports the current
 version as matching the latest version, viz:  6.10-6ubuntu1
 

OK. You are running Ubuntu, either Intrepid (8.04) or Jaunty (8.10).
Both of them use coreutils 6.10-6ubuntu1. This is the current version
of coreutils for these Ubuntu versions, and they will *NOT* be upgraded
to coreutils v8.*. Although some times we do backport new versions of a
package, there must be a clear case of need. This clear case is not
present here, unfortunately. Even more, coreutils is a core package,
and there may be other impacts.

I ran a reinstallation anyway; no change.  tail --help still shows
 what I wrote before, and tail --version shows 6.10

Yes. See above.

I'm  kind  of  new to this neighborhood; I need a little
 guidance.  If coreutils is supposed to be at version 8 but is
 actually only at 6 and not getting upgraded, to whom should this be
 reported?  (And would it be naíve of me to think no-one has noticed
 it before and I should be the one to report it?)

This list, indeed, is not the correct place: this is coreutils
development/bugs, a.k.a. upstream for Ubuntu and other Linux
distributions.

For *Ubuntu* issues, you can go to:

 * https://ubuntuforums.org (the official Ubuntu forums)
 * https://answers.launchpad.net, (support questions, *not* package
   bugs)
 * https://bugs.launchpad.net/ubuntu (package bugs, *not* support
   questions)

But I can tell you, right now, that we will probably not upgrade
coreutils to version 8 on already-published versions of Ubuntu.
You can always build it yourself, though.

I am considering publishing an *unsupported* version of coreutils, and
publishing on my PPA for Ubuntu. But -- and this is an extremely
important 'but'-- you should be aware that there are *always* a risk on
using up-to-date, non-official, packages, on an older version. If you
use them, you will not be able to open bugs on Ubuntu.

Finally, even coreutils 8.0 may not be put available for the new Ubuntu
version -- Karmic, 9.10. It is too late in the cycle to test V8, and
put it in (we are releasing 9.10 by end-of-month).

Chhers,


signature.asc
Description: PGP signature

PATCH: add missing backslash at EOL on tail.c

[C de-Avillez]

Hi,

Eric's last commit missed a backslash at EOL on tail.c (usage()
function).

Just happened I had my usual bout of insomnia, and got it while
rebuilding from GIT.

Not really critical, of course.

Cheers,

From 41b40046738e17bf819824b04a20ec63a57ecd66 Mon Sep 17 00:00:00 2001
From: C de-Avillez hgg...@gmail.com
Date: Tue, 13 Oct 2009 02:58:25 -0500
Subject: [PATCH] src/tail.c: add missing backslash at the end of a line in 
usage()

---
 src/tail.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/tail.c b/src/tail.c
index b6ad290..97aa8d4 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -260,7 +260,7 @@ With no FILE, or when FILE is -, read standard input.\n\
 Mandatory arguments to long options are mandatory for short options too.\n\
 ), stdout);
  fputs (_(\
-  -c, --bytes=Koutput the last K bytes; alternatively, use -c +K\n
+  -c, --bytes=Koutput the last K bytes; alternatively, use -c +K\n\
to output bytes starting with the Kth of each 
file\n\
 ), stdout);
  fputs (_(\
-- 
1.6.3.3


signature.asc
Description: PGP signature

Missing link to mailing list archive at home page

[C de-Avillez]

Hi,

http://www.gnu.org/software/coreutils/ misses a link to the mailing list 
archive.

It seems I cannot edit the page, so I am sending this out.

A probable good place would be under the Mailing Lists header, adding
a paragraph after the first, like:

You can search the mailing list archive a 
href=http://lists.gnu.org/archive/html/bug-coreutils/;here/a.

Cheers,


signature.asc
Description: PGP signature

Re: (man|info) pages and --help

[C de-Avillez]

On Thu, 2009-09-17 at 11:59 -0700, Micah Cowan wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 C de-Avillez wrote:
  So. Would it be an acceptable idea to add, to the '--help', a warning
  that this is *not* the full documentation?
  
  Say, like:
  
  This is an abridged documentation. The full documentation for blahblah
  is maintained as a Texinfo manual. If the info and date programs are
  properly installed at your site, the command
  
info coreutils 'blahblah invocation'
  
 should give you access to the complete manual.
 
 Is there anyone who's unaware that --help doesn't provide complete
 documentation?

I would not expect anyone to *not* know that help output is abridged.
But I would rather have them go straight into 'info' than wasting time
on 'man', only to be redirected to 'info'.

Usually one looks at the '--help' output first. If we redirect on 'man',
why not there?

Cheers



signature.asc
Description: This is a digitally signed message part

Re: (man|info) pages and --help

[C de-Avillez]

On Fri, 18 Sep 2009 17:34:31 +0200
Jim Meyering j...@meyering.net wrote:

 Pádraig Brady wrote:
 
  Alfred M. Szmidt wrote:
  Is there anyone who's unaware that --help doesn't provide
  complete documentation?
  
 I would not expect anyone to *not* know that help output is
 abridged.  But I would rather have them go straight into 'info'
 than wasting time on 'man', only to be redirected to 'info'.
  
 Usually one looks at the '--help' output first. If we redirect
  on 'man', why not there?
  
  Because man pages are secondary on GNU systems, the offical spot
  has always been info.  The redirection is only for convience for
  old timers who still use man.
 
  While that may be the official line, practically nobody reads info
  pages, and if they do it's indirectly through google.
 
  I'd vote for removing the translation help line unconditionally
  (I notice it's not mentioned in man pages) and replace with:
 
  For complete documentation, run: info coreutils '$cmd invocation'
 
 Seconded.

Is this, then, good?

From c16d6e93cdc94e890ad653d4caa994ea4c315a50 Mon Sep 17 00:00:00 2001
From: C de-Avillez hgg...@ubuntu.com
Date: Fri, 18 Sep 2009 12:16:50 -0500
Subject: [PATCH] --help: link to 'info' for complete docs
 * src/system.h:
   - take out the translation line
   - add a reference to 'info' for complete documentation

---
 src/system.h |   13 ++---
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/src/system.h b/src/system.h
index a15c298..1ecdcff 100644
--- a/src/system.h
+++ b/src/system.h
@@ -646,17 +646,8 @@ emit_bug_reporting_address (void)
   PACKAGE_NAME, PACKAGE);
   fputs (_(General help using GNU software: http://www.gnu.org/gethelp/\n),
  stdout);
-
-  if (hard_locale (LC_MESSAGES))
-{
-  /* TRANSLATORS: Replace LANG_CODE in this URL with your language code
- http://translationproject.org/team/LANG_CODE.html to form one of
- the URLs at http://translationproject.org/team/.  Otherwise, replace
- the entire URL with your translation team's email address.  */
-  printf (_(Report %s translation bugs to 
-http://translationproject.org/team/\n),
-last_component (program_name));
-}
+  printf (_(For complete documentation, run: info coreutils '%s 
invocation'\n),
+  last_component (program_name));
 }
 
 #include inttostr.h
-- 
1.6.3.3



signature.asc
Description: PGP signature

Re: (man|info) pages and --help

[C de-Avillez]

On Fri, 18 Sep 2009 23:42:31 +0100
Pádraig Brady p...@draigbrady.com wrote:

 -emit_bug_reporting_address (void)
 +emit_ancillary_info (void)

Hi Pádraig,

Thank you for getting the details done. Well, it really seems I still
have a lot to learn on coreutils.

But there is an issue in the change above: pretty much all sources
have, hardcoded, calls to emit_bug_reporting_address. So, the end
result:

1. a lot of warnings like below (well, 'hard_locale' happens only
about 10 times):

who.c: In function 'usage':
who.c:668: warning: implicit declaration of function 
'emit_bug_reporting_address'
who.c: In function 'main':
who.c:791: warning: implicit declaration of function 'hard_locale'

2. since the modules are hardcoded to emit_bug_reporting_address, the
new message does not appear in the --help output;

3. on the other hand, it seems the Perl change is OK ;-)

Sorry, my presence is being required at the dinner table.

Cheers,


signature.asc
Description: PGP signature

(man|info) pages and --help

[C de-Avillez]

c.f.: https://bugs.launchpad.net/bugs/430953

I have been thinking about this, and discussed it a bit on our (Ubuntu)
bugs IRC channel (#ubuntu-bugs).

I understand the move to 'info', and the decision to make the man pages
a summary, taken off the '--help'. But, to old UNIX users -- those that
were taught 'read the man page' -- and mostly to users that use other
systems, like AIX, HP/UX, Solaris, etc, the idea of looking at 'info'
will not occur.

Hell, I myself every so often forget about it.

So. Would it be an acceptable idea to add, to the '--help', a warning
that this is *not* the full documentation?

Say, like:

This is an abridged documentation. The full documentation for blahblah
is maintained as a Texinfo manual. If the info and date programs are
properly installed at your site, the command

  info coreutils 'blahblah invocation'

   should give you access to the complete manual.

Thank you.

..Carl..


 


signature.asc
Description: This is a digitally signed message part

Re: [bug #27373] sort -h performs incorrectly if in utf8 locale.

[C de-Avillez]

On Wed, 2009-09-02 at 21:43 +, Pádraig Brady wrote:
 Follow-up Comment #1, bug #27373 (project coreutils):
 
 I can't reproduce this or see anything wrong with the code.
 
 All 720 of my locales work fine:
 
 $ for LANG in $(locale -a); do printf KnEnMnZn | ./sort -h | tr -d 'n';
 echo; done | uniq -c
 720 KMEZ
 
 Can you give your libc version?
 Could you add a printf() to the find_unit_order() function in sort.c to see
 if it's called?
 

Interestingly, it works here with the string you used, and fails in the
following case:

~ $ for LANG in $(locale -a); do printf A b\nAA b\nAAA b\n   | sort
-h|tr -d '\n'; echo; done | uniq -c
  1 A bAA bAAA b
 21 AAA bAA bA b
  1 A bAA bAAA b
  2 AAA bAA bA b
~ $ 


~ $ apt-cache policy libc6
libc6:
  Installed: 2.10.1-0ubuntu8
  Candidate: 2.10.1-0ubuntu8
  Version table:
 *** 2.10.1-0ubuntu8 0
500 http://archive.ubuntu.com karmic/main Packages
100 /var/lib/dpkg/status
~ $ sort --version
sort (GNU coreutils) 7.5.42-1b2d2
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and Paul Eggert.
~ $ 

I will add the printf you asked, and run it again.

A similar issue has also been reported on Ubuntu
(https://bugs.launchpad.net/bugs/422252), but for coreutils 6.10.

Cheers,

..Carl..


signature.asc
Description: This is a digitally signed message part

Re: new snapshot available: coreutils-7.4.132-a70ac; 7.5 due out tomorrow

[C de-Avillez]

On Wed, 2009-08-19 at 22:28 +0200, Jim Meyering wrote:
 Have any of you found anything worth addressing for 7.5?
 Otherwise, I'll make the release tomorrow.

make check and check-root passed. Ubuntu 9.10.


signature.asc
Description: This is a digitally signed message part

Re: new snapshot available: coreutils-7.4.125-eca6

[C de-Avillez]

On Mon, 2009-08-17 at 22:26 +0200, Jim Meyering wrote:
 Pádraig fixed a few bugs (thanks!), and I've pulled in
 the latest from gnulib, so here's another snapshot.
 Thanks to everyone who has been helping.

No issues on Ubuntu 9.10 Karmic Koala



signature.asc
Description: This is a digitally signed message part

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Sun, 2009-08-16 at 13:22 +0100, Pádraig Brady wrote:
 Jim Meyering wrote:
  C de-Avillez wrote:
 
  FAIL: tail-2/append-only (exit: 1)
  ==
  ...
  + chattr +a f
  + echo x
  + test 1 = 0
  + fail=0
  + sleep 1
  + pid=29813
  + tail --pid=29813 -f f
  + fail=1
  
  What type of file system is that? (i.e., run this: df -hT .)
 
 I think this was also fixed with my inotify fixup patch.

Seems to, since I cannot repeat it anymore. But, for the record, the FS
is an ext3.

Cheers,

..C..


signature.asc
Description: This is a digitally signed message part

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Wed, 2009-08-12 at 14:54 +0200, Jim Meyering wrote:

 Are these new failures?  If they are, it might be worth fixing.
 Otherwise, FC5 is so old that I won't worry.


Sorry for the delay, got busy. I just built  make check, and got two
errors.

First one is here, I will re-run the second error by itself in a few.

Running on Ubuntu 9.10 (kernel 2.6.31.5 with Ubuntu mods, libc6
2.10.1-0ubuntu6).

Did not have time to dig in it. Sorry again.

hg...@xango2:/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests $ 
make check TESTS=tail-2/pid VERBOSE=yes
make  check-TESTS
make[1]: Entering directory
`/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests'
make[2]: Entering directory
`/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests'
FAIL: tail-2/pid
===
   GNU coreutils 7.4.115-c9c92: tests/test-suite.log   
===

1 of 1 test failed.  

.. contents:: :depth: 2


FAIL: tail-2/pid (exit: 1)
==

+ tail --version
tail (GNU coreutils) 7.4.115-c9c92
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Ian Lance Taylor,
and Jim Meyering.
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++
test_dir_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests
+++ this_test_
+++ echo ././tail-2/pid
+++ sed 's,.*/,,'
++ this_test=pid
+++ /usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/src/mktemp -d 
--tmp=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests 
cu-pid.XX
++
t_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-pid.7WOIlLer56
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++
cd 
/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-pid.7WOIlLer56
++ diff --version
++ grep GNU
+ require_proc_pid_status_
+ sleep 2
+ local pid=6535
+ sleep .5
+ grep '^State:[ ]*[S]' /proc/6535/status
+ kill 6535
+ touch here
+ fail=0
+ tail -f here
+ bg_pid=6539
+ tail -s0.1 -f here --pid=6539
+ pid=6540
+ sleep 0.5
++ get_process_status_ 6540
++ sed -n '/^State:[ ]*\([[:alpha:]]\).*/s//\1/p' /proc/6540/status
sed: can't read /proc/6540/status: No such file or directory
+ state=
+ test -n ''
+ kill 6539
./tail-2/pid: line 54: kill: (6539) - No such process
+ sleep 0.5
++ get_process_status_ 6540
++ sed -n '/^State:[ ]*\([[:alpha:]]\).*/s//\1/p' /proc/6540/status
sed: can't read /proc/6540/status: No such file or directory
+ state=
+ test -n ''
+ getlimits_
++ getlimits
+ eval CHAR_MAX=127 CHAR_OFLOW=128 CHAR_MIN=-128 CHAR_UFLOW=-129
SCHAR_MAX=127 SCHAR_OFLOW=128 SCHAR_MIN=-128 SCHAR_UFLOW=-129
UCHAR_MAX=255 UCHAR_OFLOW=256 SHRT_MAX=32767 SHRT_OFLOW=32768
SHRT_MIN=-32768 SHRT_UFLOW=-32769 INT_MAX=2147483647
INT_OFLOW=2147483648 INT_MIN=-2147483648 INT_UFLOW=-2147483649
UINT_MAX=4294967295 UINT_OFLOW=4294967296 LONG_MAX=9223372036854775807
LONG_OFLOW=9223372036854775808 LONG_MIN=-9223372036854775808
LONG_UFLOW=-9223372036854775809 ULONG_MAX=18446744073709551615
ULONG_OFLOW=18446744073709551616 SIZE_MAX=18446744073709551615
SIZE_OFLOW=18446744073709551616 SSIZE_MAX=9223372036854775807
SSIZE_OFLOW=9223372036854775808 SSIZE_MIN=-9223372036854775808
SSIZE_UFLOW=-9223372036854775809 TIME_T_MAX=9223372036854775807
TIME_T_OFLOW=9223372036854775808 TIME_T_MIN=-9223372036854775808
TIME_T_UFLOW=-9223372036854775809 UID_T_MAX=4294967295
UID_T_OFLOW=4294967296 GID_T_MAX=4294967295 GID_T_OFLOW=4294967296
PID_T_MAX=2147483647 PID_T_OFLOW=2147483648 PID_T_MIN=-2147483648
PID_T_UFLOW=-2147483649 OFF_T_MAX=9223372036854775807
OFF_T_OFLOW=9223372036854775808 OFF_T_MIN=-9223372036854775808
OFF_T_UFLOW=-9223372036854775809 INTMAX_MAX=9223372036854775807
INTMAX_OFLOW=9223372036854775808 INTMAX_MIN=-9223372036854775808
INTMAX_UFLOW=-9223372036854775809 UINTMAX_MAX=18446744073709551615
UINTMAX_OFLOW=18446744073709551616
++ CHAR_MAX=127
++ CHAR_OFLOW=128
++ CHAR_MIN=-128
++ CHAR_UFLOW=-129
++ SCHAR_MAX=127
++ SCHAR_OFLOW=128
++ SCHAR_MIN=-128
++ SCHAR_UFLOW=-129
++ UCHAR_MAX=255
++ UCHAR_OFLOW=256
++ SHRT_MAX=32767
++ SHRT_OFLOW=32768
++ SHRT_MIN=-32768
++ SHRT_UFLOW=-32769
++ INT_MAX=2147483647
++ INT_OFLOW=2147483648
++ INT_MIN=-2147483648
++ INT_UFLOW=-2147483649
++ UINT_MAX=4294967295
++ UINT_OFLOW=4294967296
++ LONG_MAX=9223372036854775807
++ LONG_OFLOW=9223372036854775808
++ LONG_MIN=-9223372036854775808
++ LONG_UFLOW=-9223372036854775809
++ ULONG_MAX=18446744073709551615
++ ULONG_OFLOW=18446744073709551616
++ SIZE_MAX=18446744073709551615
++ SIZE_OFLOW=18446744073709551616
++ SSIZE_MAX=9223372036854775807
++ SSIZE_OFLOW=9223372036854775808
++ 

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Wed, 2009-08-12 at 17:15 +0100, Pádraig Brady wrote:

 I'd better try and pay attention in this meeting ;)

Heh. Please let me help you get distracted ;-)

Second error, also on tail:


FAIL: tail-2/pid (exit: 1)
==

+ tail --version
tail (GNU coreutils) 7.4.115-c9c92
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Ian Lance Taylor,
and Jim Meyering.
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++
test_dir_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests
+++ this_test_
+++ echo ././tail-2/pid
+++ sed 's,.*/,,'
++ this_test=pid
+++ /usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/src/mktemp -d 
--tmp=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests 
cu-pid.XX
++
t_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-pid.By9pH2douA
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++
cd 
/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-pid.By9pH2douA
++ diff --version
++ grep GNU
+ require_proc_pid_status_
+ sleep 2
+ local pid=22028
+ sleep .5
+ grep '^State:[ ]*[S]' /proc/22028/status
+ kill 22028
+ touch here
+ fail=0
+ bg_pid=22032
+ tail -f here
+ tail -s0.1 -f here --pid=22032
+ pid=22033
+ sleep 0.5
++ get_process_status_ 22033
++ sed -n '/^State:[ ]*\([[:alpha:]]\).*/s//\1/p' /proc/22033/status
sed: can't read /proc/22033/status: No such file or directory
+ state=
+ test -n ''
+ kill 22032
./tail-2/pid: line 54: kill: (22032) - No such process
+ sleep 0.5
++ get_process_status_ 22033
++ sed -n '/^State:[ ]*\([[:alpha:]]\).*/s//\1/p' /proc/22033/status
sed: can't read /proc/22033/status: No such file or directory
+ state=
+ test -n ''
+ getlimits_
++ getlimits
+ eval CHAR_MAX=127 CHAR_OFLOW=128 CHAR_MIN=-128 CHAR_UFLOW=-129
SCHAR_MAX=127 SCHAR_OFLOW=128 SCHAR_MIN=-128 SCHAR_UFLOW=-129
UCHAR_MAX=255 UCHAR_OFLOW=256 SHRT_MAX=32767 SHRT_OFLOW=32768
SHRT_MIN=-32768 SHRT_UFLOW=-32769 INT_MAX=2147483647
INT_OFLOW=2147483648 INT_MIN=-2147483648 INT_UFLOW=-2147483649
UINT_MAX=4294967295 UINT_OFLOW=4294967296 LONG_MAX=9223372036854775807
LONG_OFLOW=9223372036854775808 LONG_MIN=-9223372036854775808
LONG_UFLOW=-9223372036854775809 ULONG_MAX=18446744073709551615
ULONG_OFLOW=18446744073709551616 SIZE_MAX=18446744073709551615
SIZE_OFLOW=18446744073709551616 SSIZE_MAX=9223372036854775807
SSIZE_OFLOW=9223372036854775808 SSIZE_MIN=-9223372036854775808
SSIZE_UFLOW=-9223372036854775809 TIME_T_MAX=9223372036854775807
TIME_T_OFLOW=9223372036854775808 TIME_T_MIN=-9223372036854775808
TIME_T_UFLOW=-9223372036854775809 UID_T_MAX=4294967295
UID_T_OFLOW=4294967296 GID_T_MAX=4294967295 GID_T_OFLOW=4294967296
PID_T_MAX=2147483647 PID_T_OFLOW=2147483648 PID_T_MIN=-2147483648
PID_T_UFLOW=-2147483649 OFF_T_MAX=9223372036854775807
OFF_T_OFLOW=9223372036854775808 OFF_T_MIN=-9223372036854775808
OFF_T_UFLOW=-9223372036854775809 INTMAX_MAX=9223372036854775807
INTMAX_OFLOW=9223372036854775808 INTMAX_MIN=-9223372036854775808
INTMAX_UFLOW=-9223372036854775809 UINTMAX_MAX=18446744073709551615
UINTMAX_OFLOW=18446744073709551616
++ CHAR_MAX=127
++ CHAR_OFLOW=128
++ CHAR_MIN=-128
++ CHAR_UFLOW=-129
++ SCHAR_MAX=127
++ SCHAR_OFLOW=128
++ SCHAR_MIN=-128
++ SCHAR_UFLOW=-129
++ UCHAR_MAX=255
++ UCHAR_OFLOW=256
++ SHRT_MAX=32767
++ SHRT_OFLOW=32768
++ SHRT_MIN=-32768
++ SHRT_UFLOW=-32769
++ INT_MAX=2147483647
++ INT_OFLOW=2147483648
++ INT_MIN=-2147483648
++ INT_UFLOW=-2147483649
++ UINT_MAX=4294967295
++ UINT_OFLOW=4294967296
++ LONG_MAX=9223372036854775807
++ LONG_OFLOW=9223372036854775808
++ LONG_MIN=-9223372036854775808
++ LONG_UFLOW=-9223372036854775809
++ ULONG_MAX=18446744073709551615
++ ULONG_OFLOW=18446744073709551616
++ SIZE_MAX=18446744073709551615
++ SIZE_OFLOW=18446744073709551616
++ SSIZE_MAX=9223372036854775807
++ SSIZE_OFLOW=9223372036854775808
++ SSIZE_MIN=-9223372036854775808
++ SSIZE_UFLOW=-9223372036854775809
++ TIME_T_MAX=9223372036854775807
++ TIME_T_OFLOW=9223372036854775808
++ TIME_T_MIN=-9223372036854775808
++ TIME_T_UFLOW=-9223372036854775809
++ UID_T_MAX=4294967295
++ UID_T_OFLOW=4294967296
++ GID_T_MAX=4294967295
++ GID_T_OFLOW=4294967296
++ PID_T_MAX=2147483647
++ PID_T_OFLOW=2147483648
++ PID_T_MIN=-2147483648
++ PID_T_UFLOW=-2147483649
++ OFF_T_MAX=9223372036854775807
++ OFF_T_OFLOW=9223372036854775808
++ OFF_T_MIN=-9223372036854775808
++ OFF_T_UFLOW=-9223372036854775809
++ INTMAX_MAX=9223372036854775807
++ INTMAX_OFLOW=9223372036854775808
++ INTMAX_MIN=-9223372036854775808
++ INTMAX_UFLOW=-9223372036854775809
++ UINTMAX_MAX=18446744073709551615
++ UINTMAX_OFLOW=18446744073709551616
+ test 2147483647
+ tail --pid=2147483647 -f /dev/null
+ fail=1

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

Yet another one, on check-root. I am starting to wonder if this may be a
problem with my setup, since nobody has reported errors on tail.

FAIL: tail-2/append-only (exit: 1)
==

+ tail --version
tail (GNU coreutils) 7.4.115-c9c92
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Ian Lance Taylor,
and Jim Meyering.
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++
test_dir_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests
+++ this_test_
+++ echo ././tail-2/append-only
+++ sed 's,.*/,,'
++ this_test=append-only
+++ /usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/src/mktemp -d 
--tmp=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests 
cu-append-only.XX
++
t_=/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-append-only.dkK309eD5m
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++
cd 
/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-append-only.dkK309eD5m
++ diff --version
++ grep GNU
+ require_root_
+ uid_is_privileged_
++ id -u
+ my_uid=0
+ case $my_uid in
+ NON_ROOT_USERNAME=nobody
++ id -g nobody
+ NON_ROOT_GROUP=65534
+ chattr_a_works=1
+ touch f
+ chattr +a f
+ echo x
+ test 1 = 0
+ fail=0
+ pid=22129
+ sleep 1
+ fail=1
+ chattr -a f
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ cd /usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests
+ chmod -R u
+rwx 
/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-append-only.dkK309eD5m
+ rm
-rf 
/usr/src/buildd/coreutils-snapshot/coreutils-7.4.115-c9c92/tests/cu-append-only.dkK309eD5m
+ exit 1



signature.asc
Description: This is a digitally signed message part

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Wed, 2009-08-12 at 20:22 +0100, Pádraig Brady wrote:
 While I'm at it here's a patch to
 improve that test.

Thanks, Pádraig. Building  testing right now both of them on the
snapshot; then on git.


signature.asc
Description: This is a digitally signed message part

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Wed, 2009-08-12 at 20:22 +0100, Pádraig Brady wrote:
 While I'm at it here's a patch to
 improve that test.
 
 cheers,
 Pádraig.

OK. Both tests now succeed on the snapshot. I will apply them to git now
(where I also had the same error).

Cheers,

..C..



signature.asc
Description: This is a digitally signed message part

Re: no feedback on snapshot? coreutils-7.5 coming soon

[C de-Avillez]

On Wed, 2009-08-12 at 23:06 +0200, Jim Meyering wrote:
 C de-Avillez wrote:
  Yet another one, on check-root. I am starting to wonder if this may be a
  problem with my setup, since nobody has reported errors on tail.
 
  FAIL: tail-2/append-only (exit: 1)
  ==
 
 Thanks for the reports.
 How did you run those tests?
 When I do it like this (per README), they all pass.
 
   sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root

Yes, I did run them this way. I have just re-run them under git master
(so that I would have the current status, without Pádraig's fixes).

It failed the same. The following is the command line I used:

hg...@xango2:/usr/src/buildd/coreutils $ sudo env PATH=$PATH
NON_ROOT_USERNAME=$USER make  check-root

And here's the log:

FAIL: tail-2/append-only (exit: 1)
==

+ tail --version
tail (GNU coreutils) 7.4.114-e3232
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Ian Lance Taylor,
and Jim Meyering.
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/usr/src/buildd/coreutils/tests
+++ this_test_
+++ echo ././tail-2/append-only
+++ sed 's,.*/,,'
++ this_test=append-only
+++ /usr/src/buildd/coreutils/src/mktemp -d
--tmp=/usr/src/buildd/coreutils/tests cu-append-only.XX
++ t_=/usr/src/buildd/coreutils/tests/cu-append-only.qJhExA8KWr
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++ cd /usr/src/buildd/coreutils/tests/cu-append-only.qJhExA8KWr
++ diff --version
++ grep GNU
+ require_root_
+ uid_is_privileged_
++ id -u
+ my_uid=0
+ case $my_uid in
+ NON_ROOT_USERNAME=hggdh
++ id -g hggdh
+ NON_ROOT_GROUP=1000
+ chattr_a_works=1
+ touch f
+ chattr +a f
+ echo x
+ test 1 = 0
+ fail=0
+ sleep 1
+ pid=29813
+ tail --pid=29813 -f f
+ fail=1
+ chattr -a f
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ cd /usr/src/buildd/coreutils/tests
+ chmod -R u
+rwx /usr/src/buildd/coreutils/tests/cu-append-only.qJhExA8KWr
+ rm -rf /usr/src/buildd/coreutils/tests/cu-append-only.qJhExA8KWr
+ exit 1



signature.asc
Description: This is a digitally signed message part

Re: README-prereq update

[C de-Avillez]

On Tue, 2009-06-02 at 18:31 +0200, Matěj Cepl wrote:
 Pádraig Brady píše v Út 02. 06. 2009 v 16:15 +0100:
  Well the idea of that file was not to present how to build
  on the latest and greatest, but to present various methods
  available to get prerequisites.
 
 hmm, OK, except that the advice there is misleading ... if following the
 steps there I won't compile coreutils. But, yes not a big deal, and one
 should probably be able to deal with prerequisites without help.
 
 Matěj
 

Indeed, with the requirement for automake 1.11, README-prereq, as it is
nowadays, is wrong.

Cheers,


signature.asc
Description: This is a digitally signed message part
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils