Bruno Haible wrote:
> Paolo Bonzini wrote:
>> I'll make it say "guessing yes" and still put "yes" in the variable.
>
> Thanks. Here is what the adaptation in gnulib could look like. But frankly,
> I'll prefer to remove the module altogether: The bug it cures occurred only
> on Sequents; the last ti
Bruno Haible wrote:
> Paolo Bonzini wrote:
>> I'll make it say "guessing yes" and still put "yes" in the variable.
>
> Thanks. Here is what the adaptation in gnulib could look like. But frankly,
> I'll prefer to remove the module altogether: The bug it cures occurred only
> on Sequents; the last t
Ludovic Courtès wrote:
> The `verify' module appears as LGPLv2+-licensed but says
> GPLv3+.
This is normal. See the README, section "License", or the manual [1].
Bruno
[1] http://www.gnu.org/software/gnulib/manual/html_node/Copyright.htmt
Paolo Bonzini wrote:
> I'll make it say "guessing yes" and still put "yes" in the variable.
Thanks. Here is what the adaptation in gnulib could look like. But frankly,
I'll prefer to remove the module altogether: The bug it cures occurred only
on Sequents; the last time I heard about this kind of
>>> - ac_cv_func_utime_null=no)])
>>> + ac_cv_func_utime_null=yes)])
>> I'd write this as 'ac_cv_func_utime_null="guessing yes"', to make it obvious.
>
> It would be a tad more backwards-compatible to stick with "yes".
> Consider a configure.ac that does this,
>
> AC_
Eric Blake wrote:
> Paolo Bonzini gnu.org> writes:
>
>> > This macro is obsolescent, as all current systems have a `utime'
>> > that behaves this way. New programs need not use this macro.
>>
>> I think that then _this_ is the cross-compilation default to be fixed.
>>
>> Ok?
>
> Fix the
Paolo Bonzini gnu.org> writes:
> > This macro is obsolescent, as all current systems have a `utime'
> > that behaves this way. New programs need not use this macro.
>
> I think that then _this_ is the cross-compilation default to be fixed.
>
> Ok?
Fix these nits before applying:
>
Kamil Dudka wrote:
> On Thursday 09 of April 2009 15:39:57 Jim Meyering wrote:
>> Like last time, I applied your patch in gnulib before running coreutils'
>> tests. I noticed the new resulting failure.
>
> Apologize. The regression fix has caused another regression, it's ridiculous.
> An incrementa
> This is the main problem: autoconf guessed wrong. The AC_FUNC_UTIME_NULL macro
> is already obsolete for 3 years:
>
> -- Macro: AC_FUNC_UTIME_NULL
> If `utime (FILE, NULL)' sets FILE's timestamp to the present,
> define `HAVE_UTIME_NULL'.
>
> This macro is obsolescent, as all c
Bruno Haible writes:
> I propose to either
> a) Change the cross-compiling default in m4/utime.m4 to
> "ac_cv_func_utime_null=yes", or
> b) Remove the 'utime' module altogether.
Thanks for the analysis. Either solution would be OK, but surely (b)
would be better, as nowadays the module
On Thursday 09 of April 2009 15:39:57 Jim Meyering wrote:
> Like last time, I applied your patch in gnulib before running coreutils'
> tests. I noticed the new resulting failure.
Apologize. The regression fix has caused another regression, it's ridiculous.
An incremental fix is attached. What abo
Hello,
The `verify' module appears as LGPLv2+-licensed but says
GPLv3+. Commit b6f8b81b changed the license from LGPL to LGPLv2+, so I
suppose it's the header that's incorrect. Am I right?
Thanks,
Ludo'.
Kamil Dudka wrote:
> On Thursday 09 April 2009 11:32:58 Kamil Dudka wrote:
>> On Thursday 09 April 2009 09:23:37 Sven Joachim wrote:
>> > Note that the #.b# file is listed at the top in (1) and at the bottom in
>> > (2), despite all filenames in the directory being the same!
>>
>> Thanks for disco
Kamil Dudka wrote:
> On Thursday 09 April 2009 11:32:58 Kamil Dudka wrote:
>> On Thursday 09 April 2009 09:23:37 Sven Joachim wrote:
>> > Note that the #.b# file is listed at the top in (1) and at the bottom in
>> > (2), despite all filenames in the directory being the same!
>>
>> Thanks for disco
On Thursday 09 April 2009 11:32:58 Kamil Dudka wrote:
> On Thursday 09 April 2009 09:23:37 Sven Joachim wrote:
> > Note that the #.b# file is listed at the top in (1) and at the bottom in
> > (2), despite all filenames in the directory being the same!
>
> Thanks for discovering this! The transitive
Pádraig Brady wrote:
> So would this simplification be appropriate, which just handles systems
> where utime("file", &ut); is OK while utime("file", NULL); is not?
Often, when files are exported over NFS, the server and the client have
different clocks. The write() call assigns to the file the cur
On Thursday 09 April 2009 09:23:37 Sven Joachim wrote:
> Note that the #.b# file is listed at the top in (1) and at the bottom in
> (2), despite all filenames in the directory being the same!
Thanks for discovering this! The transitive axiom of the predicate is broken.
I am working on a fix. It s
Andreas Schwab wrote:
> Pádraig Brady writes:
>
>> So would this simplification be appropriate, which just handles systems
>> where utime("file", &ut); is OK while utime("file", NULL); is not?
>
> Note that utime(,0) requires less privileges than utime(,&ut). For the
> latter you need to be own
Pádraig Brady writes:
> So would this simplification be appropriate, which just handles systems
> where utime("file", &ut); is OK while utime("file", NULL); is not?
Note that utime(,0) requires less privileges than utime(,&ut). For the
latter you need to be owner, whereas the former only requir
Jim Meyering wrote:
> ipif wrote:
>> I'm using coreutils-7.2 on an embedded sparc V8 with linux-2.6.21 and
>> uclibc-0.9.30.
>> The problem is, that in utime.c(73) it is tried to read a char from the file
>> and to write it back. As the fifo is empty touch gets stuck waiting for
>> input.
>> Becaus
I found another oddity with ls -v in coreutils 7.2. The placement of
Emacs autosave files is inconsistent:
,
| % touch a .b
| % ls -lav
| total 0
| drwxr-xr-x 2 sven sven 80 Apr 9 09:02 .
| drwxrwxrwt 11 root root 240 Apr 9 09:02 ..
| -rw-r--r-- 1 sven sven 0 Apr 9 09:02 .b
| -rw-r--r
21 matches
Mail list logo
