[vote] Release apr[-util] 1.3.2

[William A. Rowe, Jr.]

Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
happens within the hour... vote away;

   +/-1
   [  ] Release apr 1.3.2 as GA
   [  ] Release apr-util 1.3.2 as GA


Of course 1.3.1 images were scuttled, thanks to all who tested!  Windows
.zip's will follow after a bit of initial response for unix.

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
> happens within the hour... vote away;
>

Ubuntu x86 2.6.24-19-generic
>  [+1] Release apr 1.3.2 as GA
>  [+1] Release apr-util 1.3.2 as GA

The only thing that stands out is apr-util's ./buildconf:
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a
template without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.

but this is a non-issue :)

--
Lucian

[Paul Querna]

Lucian Adrian Grijincu wrote:

> On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
>> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
>> happens within the hour... vote away;
>>
>
> Ubuntu x86 2.6.24-19-generic
>>  [+1] Release apr 1.3.2 as GA
>>  [+1] Release apr-util 1.3.2 as GA
>
> The only thing that stands out is apr-util's ./buildconf:
> autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
> autoheader: WARNING: is deprecated and discouraged.
> autoheader:
> autoheader: WARNING: Using the third argument of `AC_DEFINE' and
> autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a
> template without
> autoheader: WARNING: `acconfig.h':
> autoheader:
> autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
> autoheader: [Define if a function `main' is needed.])
> autoheader:
> autoheader: WARNING: More sophisticated templates can also be produced, see the
> autoheader: WARNING: documentation.
>
> but this is a non-issue :)
>

On a release tarball, you shouldn't have to run buildconf, infact I'd
say its better not too -- we want to make sure the packagers generated
./configure works correctly.

-Paul

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 18:44, Paul Querna <chip@...> wrote:
> On a release tarball, you shouldn't have to run buildconf, infact I'd say
> its better not too -- we want to make sure the packagers generated
> ./configure works correctly.

I know this policy.

I first tested both apr and apr-util with the tar ball provided
./configure. There were no incidents.

Afterwards I ran ./buildconf to see whether some things run haywire
because of it. The only thing noteworthy was apr-util's ./buildconf
warning. All tests ran ok.


--
Lucian

[William A. Rowe, Jr.]

Lucian Adrian Grijincu wrote:
>
> Afterwards I ran ./buildconf to see whether some things run haywire
> because of it. The only thing noteworthy was apr-util's ./buildconf
> warning. All tests ran ok.

You mean the nested expat's ./buildconf warning ;-)

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
> happens within the hour... vote away;
A Cell Blade system: Linux  2.6.22-5.20070920bsc #1 SMP Tue Sep 25
10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux


>  [-1] Release apr 1.3.2 as GA
-bash-3.2$ ./testall testlfs
testlfs             : |Segmentation fault
I'll try and figure it out sometime later.

>  [-1] Release apr-util 1.3.2 as GA
[snip]
All tests passed.
Failed to load driver file apr_dbd_sqlite2.so
Loaded sqlite3 driver OK.
Opened sqlite3[] OK
======== create table ========
create table test successful

======== insert rows ========
insert rows test successful

======== invalid op ========
invalid op returned 1 (should be nonzero).  Error msg follows
'no such table: apr_dbd_test1'
valid op returned 0 (should be zero; error shouldn't affect subsequent ops)
invalid op test successful

======== select random ========
ROW 5: wibble nothing 5
ROW 1: asdfgh bar 1
select random test successful

======== select sequential ========
ROW 1: asdfgh bar 1
ROW 2: bar foo (null)
ROW 3: foo (null) (null)
ROW 4: qwerty foo 0
ROW 5: wibble nothing 5
ROW 6: wibble other 5
select sequential test successful

======== transactions ========
Transaction 1
6 rows updated
Valid insert returned 1.  Should be nonzero (fail) because transaction is bad
Transaction ended (should be rollback) - viewing table
A column of "failed" indicates transaction failed (no rollback)
ROW 1: asdfgh bar 1
ROW 2: bar foo (null)
ROW 3: foo (null) (null)
ROW 4: qwerty foo 0
ROW 5: wibble nothing 5
ROW 6: wibble other 5
Transaction 2
6 rows updated
Valid insert returned 0.  Should be zero (OK)
Transaction ended (should be commit) - viewing table
ROW 1: aaa zzz 3
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: foo success (null)
ROW 5: qwerty success 0
ROW 6: wibble success 5
ROW 7: wibble success 5
transactions test successful

======== prepared select ========
Selecting rows where col3 <= 3 and bar row where it's unset.
Should show four rows.
ROW 1: qwerty success 0
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: aaa zzz 3
prepared select test successful

======== prepared query ========
Showing table (should now contain row "prepared insert 2")
ROW 1: aaa zzz 3
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: foo success (null)
ROW 5: prepared insert 2
ROW 6: qwerty success 0
ROW 7: wibble success 5
ROW 8: wibble success 5
prepared query test successful

======== drop table ========
drop table test successful



--
Lucian

[Oden Eriksson]

Den Tuesday 17 June 2008 15:40:06 skrev William A. Rowe, Jr.:

> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
> happens within the hour... vote away;
>
>    +/-1
>    [  ] Release apr 1.3.2 as GA
>    [  ] Release apr-util 1.3.2 as GA
>
>
> Of course 1.3.1 images were scuttled, thanks to all who tested!  Windows
> .zip's will follow after a bit of initial response for unix.

All tests passed in Cooker.

[Brad Nicholes]

>>> On 6/17/2008 at 7:40 AM, in message <4857BEB6.3080007@...>, "William
A. Rowe, Jr." <wrowe@...> wrote:

> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
> happens within the hour... vote away;
>
>    +/-1
>    [  ] Release apr 1.3.2 as GA
>    [  ] Release apr-util 1.3.2 as GA
>
>
> Of course 1.3.1 images were scuttled, thanks to all who tested!  Windows
> .zip's will follow after a bit of initial response for unix.

+1 Netware

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 19:25, Lucian Adrian Grijincu
<lucian.grijincu@...> wrote:

> On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
>> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
>> happens within the hour... vote away;
> A Cell Blade system: Linux  2.6.22-5.20070920bsc #1 SMP Tue Sep 25
> 10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux
>
>
>>  [-1] Release apr 1.3.2 as GA
> -bash-3.2$ ./testall testlfs
> testlfs             : |Segmentation fault

It seems that in `apr_mmap_create` on this system `mmap` returns
MAP_FAILED == (void *)-1 but does not set `errno` to an appropriate
value:
   │133         mm = mmap(NULL, size, native_flags, MAP_SHARED,
file->filedes, offset);
   │134
   │135         if (mm == (void *)-1) {
   │136             /* we failed to get an mmap'd file... */
   │137             *new = NULL;
  >│138             return errno;
   │139         }
(gdb) print mm
$2 = (void *) 0xffffffff
(gdb) print errno
$5 = 0

Should we check whether `errno` is 0 and if it is should we return a
default error?
Because `apr_mmap_create` returns errno=0=APR_SUCCESS the tests
believe that `map` is set to an appropriate value and then proceed to
dereference it:

   │265         APR_ASSERT_SUCCESS(tc, "mmap 8GB file",
   │266                            apr_mmap_create(&map, fh, off, len,
APR_MMAP_READ, p));
   │267
   │268         APR_ASSERT_SUCCESS(tc, "close file", apr_file_close(fh));
   │269
  >│270         ABTS_ASSERT(tc, "mapped a 16K block", map->size == len);
(gdb) print map
$8 = (apr_mmap_t *) 0x0
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x10023aa4 in test_mmap (tc=0xffe4f73c, data=0x0) at testlfs.c:270


--
Lucian

[Ruediger Pluem]

On 06/17/2008 06:25 PM, Lucian Adrian Grijincu wrote:

> On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
>> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
>> happens within the hour... vote away;
> A Cell Blade system: Linux  2.6.22-5.20070920bsc #1 SMP Tue Sep 25
> 10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux
>
>
>>  [-1] Release apr 1.3.2 as GA
> -bash-3.2$ ./testall testlfs
> testlfs             : |Segmentation fault
> I'll try and figure it out sometime later.

I guess a gdb backtrace would be very useful to share.

>
>>  [-1] Release apr-util 1.3.2 as GA

What the reason for your -1 here. I cannot see anything wrong
below.

> [snip]
> All tests passed.
> Failed to load driver file apr_dbd_sqlite2.so
> Loaded sqlite3 driver OK.
> Opened sqlite3[] OK
> ======== create table ========
> create table test successful
>
> ======== insert rows ========
> insert rows test successful
>
> ======== invalid op ========
> invalid op returned 1 (should be nonzero).  Error msg follows
> 'no such table: apr_dbd_test1'
> valid op returned 0 (should be zero; error shouldn't affect subsequent ops)
> invalid op test successful
>
> ======== select random ========
> ROW 5: wibble nothing 5
> ROW 1: asdfgh bar 1
> select random test successful
>
> ======== select sequential ========
> ROW 1: asdfgh bar 1
> ROW 2: bar foo (null)
> ROW 3: foo (null) (null)
> ROW 4: qwerty foo 0
> ROW 5: wibble nothing 5
> ROW 6: wibble other 5
> select sequential test successful
>
> ======== transactions ========
> Transaction 1
> 6 rows updated
> Valid insert returned 1.  Should be nonzero (fail) because transaction is bad
> Transaction ended (should be rollback) - viewing table
> A column of "failed" indicates transaction failed (no rollback)
> ROW 1: asdfgh bar 1
> ROW 2: bar foo (null)
> ROW 3: foo (null) (null)
> ROW 4: qwerty foo 0
> ROW 5: wibble nothing 5
> ROW 6: wibble other 5
> Transaction 2
> 6 rows updated
> Valid insert returned 0.  Should be zero (OK)
> Transaction ended (should be commit) - viewing table
> ROW 1: aaa zzz 3
> ROW 2: asdfgh success 1
> ROW 3: bar success (null)
> ROW 4: foo success (null)
> ROW 5: qwerty success 0
> ROW 6: wibble success 5
> ROW 7: wibble success 5
> transactions test successful
>
> ======== prepared select ========
> Selecting rows where col3 <= 3 and bar row where it's unset.
> Should show four rows.
> ROW 1: qwerty success 0
> ROW 2: asdfgh success 1
> ROW 3: bar success (null)
> ROW 4: aaa zzz 3
> prepared select test successful
>
> ======== prepared query ========
> Showing table (should now contain row "prepared insert 2")
> ROW 1: aaa zzz 3
> ROW 2: asdfgh success 1
> ROW 3: bar success (null)
> ROW 4: foo success (null)
> ROW 5: prepared insert 2
> ROW 6: qwerty success 0
> ROW 7: wibble success 5
> ROW 8: wibble success 5
> prepared query test successful
>
> ======== drop table ========
> drop table test successful
>
>
>

Regards

Rüdiger

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 22:11, Ruediger Pluem <rpluem@...> wrote:

>
>
>> A Cell Blade system: Linux  2.6.22-5.20070920bsc #1 SMP Tue Sep 25
>> 10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux
>>
>>
>>>  [-1] Release apr 1.3.2 as GA
>>
>> -bash-3.2$ ./testall testlfs
>> testlfs             : |Segmentation fault
>> I'll try and figure it out sometime later.
>
> I guess a gdb backtrace would be very useful to share.
>

addressed in another mail.



>>
>>>  [-1] Release apr-util 1.3.2 as GA
>
> What the reason for your -1 here. I cannot see anything wrong
> below.
....
>> ======== invalid op ========
>> invalid op returned 1 (should be nonzero).  Error msg follows
Sorry. I'm a moron. I misread the above message as "invalid op
returned 1 (should be ZERO)". -ENOCOFFEE.


--
Lucian

[Ruediger Pluem]

On 06/17/2008 08:55 PM, Lucian Adrian Grijincu wrote:

> On Tue, Jun 17, 2008 at 19:25, Lucian Adrian Grijincu
> <lucian.grijincu@...> wrote:
>> On Tue, Jun 17, 2008 at 16:40, William A. Rowe, Jr. <wrowe@...> wrote:
>>> Candidates will be up at http://apr.apache.org/dev/dist/ once the sync
>>> happens within the hour... vote away;
>> A Cell Blade system: Linux  2.6.22-5.20070920bsc #1 SMP Tue Sep 25
>> 10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux
>>
>>
>>>  [-1] Release apr 1.3.2 as GA
>> -bash-3.2$ ./testall testlfs
>> testlfs             : |Segmentation fault
>
> It seems that in `apr_mmap_create` on this system `mmap` returns
> MAP_FAILED == (void *)-1 but does not set `errno` to an appropriate
> value:
>    │133         mm = mmap(NULL, size, native_flags, MAP_SHARED,
> file->filedes, offset);
>    │134
>    │135         if (mm == (void *)-1) {
>    │136             /* we failed to get an mmap'd file... */
>    │137             *new = NULL;
>   >│138             return errno;
>    │139         }
> (gdb) print mm
> $2 = (void *) 0xffffffff
> (gdb) print errno
> $5 = 0

Thanks for investigating, but keep two things in mind:

1. If errno is really 0 it would be a bug in your glibc / Linux kernel
    as the man page is very clear about setting an error code in errno here.
2. I don't trust print errno here as errno in threaded environments (I assume
    you compiled APR with thread support) is not a static variable as it was
    in the past, but a macro wrapping something different in order to make the
    whole errno process thread safe. So I guess it would be much safer here to
    print the value that is returned in the calling function. Of course in our
    case this is more difficult as the call is convoluted in a macro.
    Maybe you can call apr_mmap_create(&map, fh, off, len, APR_MMAP_READ, p));
    directly instead via APR_ASSERT_SUCCESS, assign the return value to a variable
    and do a print via gdb afterwards.

Regards

Rüdiger

[Lucian Adrian Grijincu-3]

On Tue, Jun 17, 2008 at 22:24, Ruediger Pluem <rpluem@...> wrote:
> Thanks for investigating, but keep two things in mind:
>
> 1. If errno is really 0 it would be a bug in your glibc / Linux kernel
>   as the man page is very clear about setting an error code in errno here.

Yeah, but if it /would/ be a bug in glibc shouldn't APR route around
the error somehow?
It's not an error, gdb was wrong.

> 2. I don't trust print errno here as errno in threaded environments (I
> assume
>   you compiled APR with thread support) is not a static variable as it was
>   in the past, but a macro wrapping something different in order to make the
>   whole errno process thread safe. So I guess it would be much safer here to
>   print the value that is returned in the calling function. Of course in our
>   case this is more difficult as the call is convoluted in a macro.
>   Maybe you can call apr_mmap_create(&map, fh, off, len, APR_MMAP_READ, p));
>   directly instead via APR_ASSERT_SUCCESS, assign the return value to a
> variable
>   and do a print via gdb afterwards.

apr_mmap_create returns 22 (Invalid argument).

│133         mm = mmap(NULL, size, native_flags, MAP_SHARED,
file->filedes, offset);
(gdb) print size
$3 = 16384
(gdb) print offset
$4 = 8589918208

man 2 mmap says:
> void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);

> EINVAL (since Linux 2.6.12), length was 0.
this cannot be it.

> EINVAL flags contained neither MAP_PRIVATE or MAP_SHARED, or  contained both of these values.
neither can this.

> EINVAL We  don't  like  start,  length,  or  offset (e.g., they are too large, or not aligned on a page boundary).
start=0
length=16384
offset=8589918208

Any ideas?

--
Lucian

[Ruediger Pluem]

On 06/17/2008 10:37 PM, Lucian Adrian Grijincu wrote:

> On Tue, Jun 17, 2008 at 22:24, Ruediger Pluem <rpluem@...> wrote:
>> Thanks for investigating, but keep two things in mind:
>>
>> 1. If errno is really 0 it would be a bug in your glibc / Linux kernel
>>   as the man page is very clear about setting an error code in errno here.
>
> Yeah, but if it /would/ be a bug in glibc shouldn't APR route around
> the error somehow?
> It's not an error, gdb was wrong.
>
>> 2. I don't trust print errno here as errno in threaded environments (I
>> assume
>>   you compiled APR with thread support) is not a static variable as it was
>>   in the past, but a macro wrapping something different in order to make the
>>   whole errno process thread safe. So I guess it would be much safer here to
>>   print the value that is returned in the calling function. Of course in our
>>   case this is more difficult as the call is convoluted in a macro.
>>   Maybe you can call apr_mmap_create(&map, fh, off, len, APR_MMAP_READ, p));
>>   directly instead via APR_ASSERT_SUCCESS, assign the return value to a
>> variable
>>   and do a print via gdb afterwards.
> apr_mmap_create returns 22 (Invalid argument).
>
> │133         mm = mmap(NULL, size, native_flags, MAP_SHARED,
> file->filedes, offset);
> (gdb) print size
> $3 = 16384
> (gdb) print offset
> $4 = 8589918208
>
> man 2 mmap says:
>> void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
>
>> EINVAL (since Linux 2.6.12), length was 0.
> this cannot be it.
>
>> EINVAL flags contained neither MAP_PRIVATE or MAP_SHARED, or  contained both of these values.
> neither can this.
>
>> EINVAL We  don't  like  start,  length,  or  offset (e.g., they are too large, or not aligned on a page boundary).
> start=0
> length=16384
> offset=8589918208
>
> Any ideas?

Please execute the following command on your box and supply the output:

/usr/bin/time --verbose sleep 0


Regards

Rüdiger

[Lucian Adrian Grijincu-3]

On Wed, Jun 18, 2008 at 00:53, Ruediger Pluem <rpluem@...> wrote:
> Please execute the following command on your box and supply the output:

Never knew time could list so many things :)

/usr/bin/time --verbose sleep 0

        Command being timed: "sleep 0"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: 16%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 48
        Voluntary context switches: 29
        Involuntary context switches: 1
        Swaps: 0
        File system inputs: 128
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 65536
        Exit status: 0


FWIW,
-bash-3.2$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8192
max locked memory       (kbytes, -l) 512
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

--
Lucian

[Lucian Adrian Grijincu-3]

On Wed, Jun 18, 2008 at 00:57, Lucian Adrian Grijincu
<lucian.grijincu@...> wrote:
> On Wed, Jun 18, 2008 at 00:53, Ruediger Pluem <rpluem@...> wrote:
>> Please execute the following command on your box and supply the output:
>
> Never knew time could list so many things :)
>
> /usr/bin/time --verbose sleep 0
>        Page size (bytes): 65536
offset/pagesize = 8589918208 / 65536 = 131071.75
I guess the hardcoded value
   apr_size_t len = 16384; /* hopefully a multiple of the page size */
from `test_mmap` is wrong.


--
Lucian

[Ruediger Pluem]

On 06/17/2008 11:57 PM, Lucian Adrian Grijincu wrote:

> On Wed, Jun 18, 2008 at 00:53, Ruediger Pluem <rpluem@...> wrote:
>> Please execute the following command on your box and supply the output:
>
> Never knew time could list so many things :)
>
> /usr/bin/time --verbose sleep 0
>
> Command being timed: "sleep 0"
> User time (seconds): 0.00
> System time (seconds): 0.00
> Percent of CPU this job got: 16%
> Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
> Average shared text size (kbytes): 0
> Average unshared data size (kbytes): 0
> Average stack size (kbytes): 0
> Average total size (kbytes): 0
> Maximum resident set size (kbytes): 0
> Average resident set size (kbytes): 0
> Major (requiring I/O) page faults: 0
> Minor (reclaiming a frame) page faults: 48
> Voluntary context switches: 29
> Involuntary context switches: 1
> Swaps: 0
> File system inputs: 128
> File system outputs: 0
> Socket messages sent: 0
> Socket messages received: 0
> Signals delivered: 0
> Page size (bytes): 65536
> Exit status: 0

Thanks. Please try if the following patch fixes the segfault:

Index: test/testlfs.c
===================================================================
--- test/testlfs.c»·····(Revision 668795)
+++ test/testlfs.c»·····(Arbeitskopie)
@@ -251,7 +251,7 @@
  {
      apr_mmap_t *map;
      apr_file_t *fh;
-    apr_size_t len = 16384; /* hopefully a multiple of the page size */
+    apr_size_t len = 65536; /* hopefully a multiple of the page size */
      apr_off_t off = eightGB - len;·
      apr_status_t rv;
      void *ptr;


If it does it is simply a bug in the testcase and we do not need to worry any
further. So IMHO in this case it would be nothing that would prevent us from
releasing 1.3.2.

Regards

Rüdiger

[Lucian Adrian Grijincu-3]

On Wed, Jun 18, 2008 at 01:04, Lucian Adrian Grijincu
<lucian.grijincu@...> wrote:

> On Wed, Jun 18, 2008 at 00:57, Lucian Adrian Grijincu
> <lucian.grijincu@...> wrote:
>> On Wed, Jun 18, 2008 at 00:53, Ruediger Pluem <rpluem@...> wrote:
>>> Please execute the following command on your box and supply the output:
>>
>> Never knew time could list so many things :)
>>
>> /usr/bin/time --verbose sleep 0