Zack Weinberg wrote:
On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
Zack Weinberg wrote:
[snip everything addressed in the other thread]
Yes, there was a bit of confusion here; not only is the FileUtils
module synchronized between autom4te and automake
Thanks for
On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
[snip everything addressed in the other thread]
> Yes, there was a bit of confusion here; not only is the FileUtils
> module synchronized between autom4te and automake
Thanks for reminding me that I need to make sure
Zack Weinberg wrote:
On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I
I thought we were talking about automake's testsuite probing the behavior
of *autom4te*
Yes, exactly. Sorry for the confusion.
$ ./tests/autom4te --version
autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty (subsecond timestamps supported)
Looks good to me. Thanks.
a third party
On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
>> There would not need to be much parsing, just "automake --version | grep
> > HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> > easc" to avoid running grep if you want.
>
> I specifically want to hear what
Karl Berry wrote:
> There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifically want to hear what Karl thinks.
I lean towards Jacob's
upthread somewhere Karl (iirc) threw out a bikeshed idea like
--has=.
Pretty sure it wasn't me :).
> There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifically want to hear what Karl thinks.
I lean towards Jacob's view that automake
Mike Frysinger wrote:
On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
Mike Frysinger wrote:
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
Karl Berry wrote:
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was
On Sat, Dec 2, 2023, at 8:58 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> Either way is no problem from my end, but it would be more work
>> for automake (parsing --version output, instead of just checking the
>> exit status of autom4te --assert-high-resolution-timestamp-support)
>> Karl,
Zack Weinberg wrote:
On Sat, Dec 2, 2023, at 7:33 PM, Jacob Bachmeyer wrote:
Zack Weinberg wrote:
Would it help if we added a command line option to autom4te that made
it report whether it thought it could use high resolution timestamps?
Versions of autom4te that didn't recognize this
On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> >> Karl Berry wrote:
> >>> jb> a more thorough test would locate the autom4te script and grep it
> >>> for the perllibdir that was substituted when autoconf was
> >>>
On 02 Dec 2023 18:33, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
> > On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> >> The best way to check if high-resolution
> >> timestamps are available to autom4te is to have perl load
> >> Autom4te::FileUtils and check if that also loaded
On 02 Dec 2023 19:17, Zack Weinberg wrote:
> On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> > The best way to check if high-resolution
> > timestamps are available to autom4te is to have perl load
> > Autom4te::FileUtils and check if that also loaded Time::HiRes.
> >
> > The
On Sat, Dec 2, 2023, at 7:33 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> Would it help if we added a command line option to autom4te that made
>> it report whether it thought it could use high resolution timestamps?
>> Versions of autom4te that didn't recognize this option should be
>>
Zack Weinberg wrote:
On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
The best way to check if high-resolution
timestamps are available to autom4te is to have perl load
Autom4te::FileUtils and check if that also loaded Time::HiRes.
The problem with that turned out to be that
On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> The best way to check if high-resolution
> timestamps are available to autom4te is to have perl load
> Autom4te::FileUtils and check if that also loaded Time::HiRes.
>
> The problem with that turned out to be that Time::HiRes got
The best way to check if high-resolution
timestamps are available to autom4te is to have perl load
Autom4te::FileUtils and check if that also loaded Time::HiRes.
The problem with that turned out to be that Time::HiRes got loaded from
other system modules, resulting in the test
Mike Frysinger wrote:
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
Karl Berry wrote:
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was substituted when autoconf was
configured.
I guess that would work.
Challenge
On Sat, Dec 2, 2023, at 6:58 AM, Mike Frysinger wrote:
> On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
>> Karl Berry wrote:
>> > jb> a more thorough test would locate the autom4te script and grep it
>> > for the perllibdir that was substituted when autoconf was
>> > configured.
>> >
>>
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> Karl Berry wrote:
> > jb> a more thorough test would locate the autom4te script and grep it
> > for the perllibdir that was substituted when autoconf was
> > configured.
> >
> > I guess that would work.
>
> Challenge accepted. Here's a
Are you sure about that?
Yes. Well, as sure as I can be. I don't see any $(...) constructs in
Automake's *.m4 now, and this is certainly deliberate. We discussed
shell portability many times over the decades of Automake development.
I can't quickly find where it's documented, if anywhere,
Karl Berry wrote:
Hi Jacob,
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
Wouldn't have worked on my own system :).
Challenge accepted.
Thanks!
if $PERL -I${autom4te_perllibdir:-$(sed -n \
Hi Jacob,
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
Wouldn't have worked on my own system :).
Challenge accepted.
Thanks!
if $PERL -I${autom4te_perllibdir:-$(sed -n \
'/autom4te_perllibdir/{s/^.*||
Karl Berry wrote:
jb> The test also guesses the location of autoconf's Perl libraries;
I'm skeptical that any "guessing" of library locations would be reliable
enough.
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
jb> a more
jb> The test also guesses the location of autoconf's Perl libraries;
I'm skeptical that any "guessing" of library locations would be reliable
enough.
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was substituted when autoconf was
Bogdan wrote:
Jacob Bachmeyer , Mon Apr 03 2023 06:16:53
GMT+0200 (Central European Summer Time)
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or
On Tue, Apr 4, 2023, at 3:51 PM, Bogdan wrote:
> Nice. The 0 and 1 may not be portable to each OS in the Universe
> (see EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be
> good/portable enough for our goals. Or maybe some other simple solution.
ISO C guarantees that exit(0) has the
Jacob Bachmeyer , Mon Apr 03 2023 06:16:53
GMT+0200 (Central European Summer Time)
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or
not
(i.e., has
Karl Berry , Mon Apr 03 2023 02:08:23 GMT+0200
(Central European Summer Time)
I modified my autom4te using the attached patch,
Thank you very very much for finding this, Bogdan.
:) Hope it saved some headaches :)
I'm glad that Paul has already installed it in Autoconf.
I can't
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or not
(i.e., has the patch installed)? And then use the longer sleep in
automake testing if needed.
I modified my autom4te using the attached patch,
Thank you very very much for finding this, Bogdan.
I'm glad that Paul has already installed it in Autoconf.
I can't easily confirm it for myself right now, but I'm hopeful.
(Maybe Frederic or others can try with the development autoconf.)
Thanks for reporting that. I installed the attached slightly different
patch into Autoconf on Savannah. This patch also changes one other
instance of file timestamp comparison from < to <=. Something like this
should appear in the next Autoconf release.From
Jacob Bachmeyer , Sat Apr 01 2023 04:54:22
GMT+0200 (Central European Summer Time)
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with
sporadic random test failures, seemingly due to "disk writes not
taking effect" (as
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with sporadic
random test failures, seemingly due to "disk writes not taking effect"
(as Karl Berry mentioned when starting the thread). Bogdan appears to
have traced the
Bogdan , Sun Mar 05 2023 22:31:55 GMT+0100 (Central
European Standard Time)
Karl Berry , Sat Mar 04 2023 00:00:56 GMT+0100
(Central European Standard Time)
Note that 'config.h' is older (4 seconds) than './configure',
which
shouldn't be the case as it should get updated with new
Hello,
I spent some more time on testing, and I could reproduce the issue on
Fedora rawhide, which gives more freedom for reproduction.
Regarding what I said earlier, since that wasn't clear enough, I couldn't
reproduce `make check` failures with the 1.16.5 official taball in a mock
environment,
Oh, and I forgot, regarding autoconf: the RHEL 8 image I tested with had
autoconf 2.69. Failures could be detected with automake trunk, not with
official tarball (at least so far).
On Mon, Mar 6, 2023 at 11:19 PM Frederic Berat wrote:
> Hello,
>
> I spent some more time on testing, and I could
Karl Berry , Sat Mar 04 2023 00:00:56 GMT+0100
(Central European Standard Time)
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
Indeed. That is the same sort of thing as I was observing with nodef.
But
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
Indeed. That is the same sort of thing as I was observing with nodef.
But what (at any level) could be causing that to happen?
Files just aren't getting
Bogdan , Fri Mar 03 2023 14:56:07 GMT+0100 (Central
European Standard Time)
Bogdan , Fri Mar 03 2023 11:21:25 GMT+0100 (Central
European Standard Time)
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux,
Bogdan , Fri Mar 03 2023 11:21:25 GMT+0100 (Central
European Standard Time)
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux,
Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q
Hi Frédéric,
While building the trunk directly led to check failures,
Confirmation is good.
rebuilding the RPM in a mock environment didn't.
Puzzling.
I'll likely spend more time next week to perform more testing. It
may simply be an environment problem:
I guess it's
Hello,
For the record, I made a first run of testing on a rhel 8 system.
While building the trunk directly led to check failures, rebuilding the RPM
in a mock environment didn't.
I'll likely spend more time next week to perform more testing. It may
simply be an environment problem: I noticed the
FAIL: t/remake-aclocal-version-mismatch.sh
Thanks for trying it, Nick.
I'm glad it's not just me.
And I sure wonder wtf is going on :(. -k
On 2023-03-01, Karl Berry wrote:
> Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky
> Linux, original RHEL, or even (sort of) CentOS 8? It would be nice if
> someone could run a make check there (from automake dev).
> git clone -q git://git.savannah.gnu.org/automake.git
>
47 matches
Mail list logo
