This patch reduces the mismatch from
GNULIB_TOOL_IMPL=py ./test-create-testdir-2.sh
2024-03-23 Bruno Haible
gnulib-tool.py: Print "executing touch config.h.in".
* pygnulib/GLTestDir.py (GLTestDir.execute): Print
"executing touch config.h.in", like
On 06/26/2012 04:32 AM, Bruno Haible wrote:
> Stefano Lattarini wrote:
>> I'm almost inclined not to do so, to force the affected
>> projects' broken setup to be fixed; i.e., if you are using Automake 1.11,
>> you let it install the correct 'missing' program, instead of forcing it
>> to use the 'mi
Severity: minor
thanks
[Adding bug-automake]
On 06/26/2012 12:32 PM, Bruno Haible wrote:
> Stefano Lattarini wrote:
>> I'm almost inclined not to do so, to force the affected
>> projects' broken setup to be fixed; i.e., if you are using Automake 1.11,
>> you let it install the correct 'missing' p
Stefano Lattarini wrote:
> I'm almost inclined not to do so, to force the affected
> projects' broken setup to be fixed; i.e., if you are using Automake 1.11,
> you let it install the correct 'missing' program, instead of forcing it
> to use the 'missing' from Automake 1.13.
But developers don't h
Hi Eric.
On 06/26/2012 05:46 AM, Eric Blake wrote:
> On 06/20/2012 03:30 PM, Stefano Lattarini wrote:
>> Before this change, the missing script had a twofold role:
>>
>> - it warned the user if some required maintainer tools was missing,
>> or too old;
>>
>> - in such a case, it tried to "
On 06/25/2012 09:46 PM, Eric Blake wrote:
>
>> case $1 in
>> ---run)
>> - # Try to run requested program, and just exit if it succeeds.
>> - run=
>> - shift
>> - "$@" && exit 0
>> - # Exit code 63 means version mismatch. This often happens
>> - # when the user try to use an ancient versio
On 06/20/2012 03:30 PM, Stefano Lattarini wrote:
> Before this change, the missing script had a twofold role:
>
> - it warned the user if some required maintainer tools was missing,
> or too old;
>
> - in such a case, it tried to "fix" the timestamp of the files that
> should have bee
Ben Walton wrote:
>> Ben, can you confirm that touch from coreutils-8.7 did not have this
>> problem? I'll wait for confirmation before pushing.
>
> I just built 8.7 (I skipped from 8.4 -> 8.8) with my build script and
> tested it. It works correctly, so I&#x
Excerpts from Jim Meyering's message of Sun Mar 13 05:11:33 -0400 2011:
Hi Jim,
> I've just updated coreutils to use the latest from gnulib, so this
> will be fixed in coreutils-8.11.
Great!
> Ben, can you confirm that touch from coreutils-8.7 did not have this
> p
ary to most NEWS-worthy bugs, I have not tried
to determine when this one was introduced. From the initial report,
I'm assuming it was introduced in coreutils-8.8, and wrote that in NEWS.
Ben, can you confirm that touch from coreutils-8.7 did not have this problem?
I'll wait for confir
Excerpts from Bruno Haible's message of Sat Mar 12 07:11:51 -0500 2011:
Hi Bruno,
> I'm applying this patch:
Thanks for saving me the legwork on this. The patch does correct the
problem. I appreciate the quick turnaround on this.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University
Paul Eggert wrote:
> That sounds good, but why make Solaris 9 a special case?
> Wouldn't it be simpler to do it for all platforms where gnulib
> defines futimens or utimensat functions?
The functions of the two cycles are available on the following platforms:
Cycle #1:
futimensAIX 7, Cygwin
On 03/11/2011 02:41 PM, Bruno Haible wrote:
> I propose to change gnulib so that it uses
> #define futimens rpl_futimens
> #define utimensat rpl_utimensat
> also on Solaris 9 (with the usual idioms for the C++ and the gnulib
> namespace).
That sounds good, but why make Solaris 9 a special cas
t futimens.c:36
#4 0x00013c6c in fdutimensat (fd=0, dir=-3041965,
file=0xffbffd4a , ts=0x0, atflag=0)
at fdutimensat.c:48
#5 0x00012be8 in touch (file=0xffbffd4a )
at touch.c:168
#6 0x00013b48 in main (argc=2, argv=0xffbffc5c) at touch.c:434
So the situation is this:
- On Solar
[adding bug-gnulib]
On 03/10/2011 06:53 PM, Ben Walton wrote:
>
> Hi All,
>
> Since 8.8, touch has dumped core on solaris 10 (built on solaris 9).
> The command that triggers the core dump is a simple: touch somefile
>
> This is seemingly related to the recommend pa
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- Stéphane Raimbault
Stéphane Raimbault
Open Source Project Leader and Software developer at Makina Corpus
Nantes Area, France
Confirm that you know Stéphane Raimbault
https://www.linkedin.com/e/n5bqwk-gl2143
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 12/30/2009 5:50 AM:
> So in general, the problem can be characterized precisely by the presence
> of UTIME_OMIT, and can be worked around with a mere stat() (no gettime()
> is needed, since UTIME_NOW still works). Do you hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/29/2009 10:38 PM:
> I couldn't find where UTIME_NOW etc. is defined, so I just pulled the
> values off the internet.
They are defined in . I keep forgetting that while many
systems implicitly include as part of (which PO
On 12/29/2009 01:12 PM, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/29/2009 11:58 AM:
Re: touch --ref file1 -m file2 or touch -m file1 --ref file2
Does not work on ntfs-3g. See attached
Thanks. That confirmed half of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/29/2009 11:58 AM:
> Re: touch --ref file1 -m file2 or touch -m file1 --ref file2
> Does not work on ntfs-3g. See attached
Thanks. That confirmed half of what I was worried about.
> valid/UTIME_NOW , make -k
On 12/28/2009 07:10 AM, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/20/2009 10:04 PM:
touch -m no longer seems to modify the file modification date. Archlinux,
coreutils-8.2 (package coreutils-8.2-1-i686). Works if use coreutils-7.6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to ctrn3e8 on 12/20/2009 10:04 PM:
>>>>touch -m no longer seems to modify the file modification date.
>>>> Archlinux,
>>>>coreutils-8.2 (package coreutils-8.2-1-i686). Works if use
>>
Eric Blake wrote:
> According to Jim Meyering on 12/22/2009 3:21 AM:
>> Eric Blake wrote:
>>> Yep - it is indeed an example of the mtime (and ctime) failing to update,
>>> even though utimensat claimed success.
>>
>> Here's an interesting glibc change from just a few hours ago:
>>
>> http://sources
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 12/22/2009 3:21 AM:
> Eric Blake wrote:
>> Yep - it is indeed an example of the mtime (and ctime) failing to update,
>> even though utimensat claimed success.
>
> Here's an interesting glibc change from just a few hours ag
Jim Meyering wrote:
> > So, any objections to removing this module?
>
> Why don't we first mark it as obsolete?
> I'll stop using it in coreutils right away, and we can
> remove it altogether after a reasonable grace period.
OK, I've committed the cross-compilation fix and done that:
2009-04-10
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
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:
>
> 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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Schwab on 6/3/2008 2:00 AM:
|
| You would also lose the capability to build on a system with an old
| kernel, but new glibc (eg in a chroot), and getting the same result as
| if building on the target system. Runtime configure ch
Eric Blake <[EMAIL PROTECTED]> writes:
> I could also work on a patch like this - basically, gnulib/m4/utimens.m4
> could check whether futimens/utimensat fail with ENOSYS, and if so, treat
> them as though they were not declared. But then you lose the ability to
> adjust timestamps to the nanose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Schwab on 6/2/2008 3:57 PM:
| Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
|
|> Mike, I thought the *at wrappers fell back to emulation if the
|> syscalls were missing. Is that impossible for utimensat?
|
| Emulating utimensat i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 6/2/2008 3:32 PM:
| On Monday 02 June 2008, Andreas Schwab wrote:
|> Mike Frysinger <[EMAIL PROTECTED]> writes:
|>> also after reading it, i dont think gnu/stubs.h would help in this
|>> particular case. gnulib would ne
On Monday 02 June 2008, Bob Proulx wrote:
> Daniel Jacobowitz wrote:
> > Bob Proulx wrote:
> > > Most common systems only support backward compatibility. I have not
> > > heard of a system which supported forward compatibility.
> > >
> > > In other words, compiling on a platform usually results in
Daniel Jacobowitz wrote:
> Bob Proulx wrote:
> > Most common systems only support backward compatibility. I have not
> > heard of a system which supported forward compatibility.
> >
> > In other words, compiling on a platform usually results in an
> > executable that only runs on that version or
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> Mike, I thought the *at wrappers fell back to emulation if the
> syscalls were missing. Is that impossible for utimensat?
Emulating utimensat is rather difficult, due to the UTIME_NOW/UTIME_OMIT
feature.
Andreas.
--
Andreas Schwab, SuSE Labs, [E
On Monday 02 June 2008, Andreas Schwab wrote:
> Mike Frysinger <[EMAIL PROTECTED]> writes:
> > also after reading it, i dont think gnu/stubs.h would help in this
> > particular case. gnulib would need a runtime test to detect that
> > utimensat() is actually not available.
>
> That should be prett
Mike Frysinger <[EMAIL PROTECTED]> writes:
> also after reading it, i dont think gnu/stubs.h would help in this particular
> case. gnulib would need a runtime test to detect that utimensat() is
> actually not available.
That should be pretty easy, just fall through to the fallback code when
er
piled against recent kernel headers (say 2.6.25) but execute on
> > > > an older kernel (say 2.6.18), then the resulting touch binary will
> > > > attempt to use utimensat() which fails with ENOSYS.
> >
> > Most common systems only support backward compatibility.
On Monday 02 June 2008, Jim Meyering wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > a recent gnulib commit (faeb3e6b21...) causes trouble for some packages
> > (such as touch in coreutils) on certain combinations of software. for
> > example, if you're r
t; an older kernel (say 2.6.18), then the resulting touch binary will
> > > attempt to use utimensat() which fails with ENOSYS.
>
> Most common systems only support backward compatibility. I have not
> heard of a system which supported forward compatibility.
>
> In other
Jim Meyering wrote:
> Mike Frysinger wrote:
> > for example, if you're running a recent version of glibc (say 2.7)
> > compiled against recent kernel headers (say 2.6.25) but execute on
> > an older kernel (say 2.6.18), then the resulting touch binary will
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/2/2008 12:43 PM:
| I'm afraid the best advice I can give you is to run the tools on the same
| (or newer) version of the system on which you configured the package.
Or configure with ac_cv_func_futimens=no ac_cv_func_ut
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such
> as touch in coreutils) on certain combinations of software. for example, if
> you're running a recent version of glibc (say 2.7) compiled against rec
a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such
as touch in coreutils) on certain combinations of software. for example, if
you're running a recent version of glibc (say 2.7) compiled against recent
kernel headers (say 2.6.25) but execute on an older kernel
I installed this to merge from coreutils the support for "touch -":
2005-09-24 Paul Eggert <[EMAIL PROTECTED]>
* utimens.c (ENOSYS): Define if not already defined.
(futimens): Support having a null PATH if the file descriptor
is nonnegative.
54 matches
Mail list logo
