Gentle ping.

(In reply to Ondrej Dubaj from comment #1)
> Gentle ping.

I don't know what's expected here.

I followed the link above and found nothing useful.

Am I expect to checkout, build and install autoconf 2.70, or is that 2.71,
or 2.72, so that I can test if the package builds and works using them?

The problem is that the package runs autoconf and the script which does
that matches a specific version, it's easy to add versions there but
building and basic function needs to be checked.

What in terms of autoconf packages can you give me to help.

You can locally test the package in mock using the provided mock config (https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test)

am-utils requires autoconf 2.69, you have:
	autoreconf (GNU Autoconf) 2.71
error: Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)
    Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)

Can you try to create a simple downstream patch so, that am-utils will require autoconf-2.71 in configure ? Should be enough to go through this step and then we will see if the package builds fine.

(In reply to Ondrej Dubaj from comment #3)
> You can locally test the package in mock using the provided mock config
> (https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test)
> 
> am-utils requires autoconf 2.69, you have:
> 	autoreconf (GNU Autoconf) 2.71
> error: Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)
>     Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)
> 
> Can you try to create a simple downstream patch so, that am-utils will
> require autoconf-2.71 in configure ? Should be enough to go through this
> step and then we will see if the package builds fine.

Maybe I wasn't clear, the build runs a bootstrap script that creates
configure, that's how the upstream tarball is released, and it
deliberately allows only autoconf 2.69.

It's straight forward to add autoconf versions to the case statement
and the last time there was an autoconf bump everything worked fine,
yes, it's not the first time I've had to deal with this. I may need
to do a bit more but it shouldn't be too much hassle, last time was
ages ago so I can't remember exactly.

So I hope there won't be problems.

I'll have a go at using mock as you say but IIUC that won't allow me
to test basic function so I will need some other mechanism anyway,
rework is not my favorite pass time.

Ian

(In reply to Ian Kent from comment #4)
> (In reply to Ondrej Dubaj from comment #3)
> > You can locally test the package in mock using the provided mock config
> > (https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test)
> > 
> > am-utils requires autoconf 2.69, you have:
> > 	autoreconf (GNU Autoconf) 2.71
> > error: Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)
> >     Bad exit status from /var/tmp/rpm-tmp.xQmKkR (%prep)
> > 
> > Can you try to create a simple downstream patch so, that am-utils will
> > require autoconf-2.71 in configure ? Should be enough to go through this
> > step and then we will see if the package builds fine.
> 
> Maybe I wasn't clear, the build runs a bootstrap script that creates
> configure, that's how the upstream tarball is released, and it
> deliberately allows only autoconf 2.69.
> 
> It's straight forward to add autoconf versions to the case statement
> and the last time there was an autoconf bump everything worked fine,
> yes, it's not the first time I've had to deal with this. I may need
> to do a bit more but it shouldn't be too much hassle, last time was
> ages ago so I can't remember exactly.
> 
> So I hope there won't be problems.
> 
> I'll have a go at using mock as you say but IIUC that won't allow me
> to test basic function so I will need some other mechanism anyway,
> rework is not my favorite pass time.

Another thing to keep in mind is that I think this change is targeted
at F35 but I have work for RHEL-8.5 and RHEL-9 that is due before this
(well now really).

So I'm not ignoring this as much as trying to get to it in priority
order.

Understand, thanks for the explanation, pasting patch here:

diff --git a/am-utils.spec b/am-utils.spec
index a3f76c5..fef0ea1 100644
--- a/am-utils.spec
+++ b/am-utils.spec
@@ -144,6 +144,9 @@ mounting and unmounting filesystems.
 %patch34 -p1
 %patch35 -p1
 
+#moving to autoconf-2.71
+sed -i 's/2.69/2.71/g' bootstrap
+
 ./bootstrap
 
 find_requires=%{old_find_requires}


and moving this issue to state POST

(In reply to Ondrej Dubaj from comment #6)
> Understand, thanks for the explanation, pasting patch here:
> 
> diff --git a/am-utils.spec b/am-utils.spec
> index a3f76c5..fef0ea1 100644
> --- a/am-utils.spec
> +++ b/am-utils.spec
> @@ -144,6 +144,9 @@ mounting and unmounting filesystems.
>  %patch34 -p1
>  %patch35 -p1
>  
> +#moving to autoconf-2.71
> +sed -i 's/2.69/2.71/g' bootstrap
> +
>  ./bootstrap
>  
>  find_requires=%{old_find_requires}
> 
> 
> and moving this issue to state POST

This should enable am-utils to build although I was going to make a
slightly different change.

Would you like me make the change sufficient for the package to build
now?

am-utils is a very heavy user of autoconf and there are hundreds of
occurrences of deprecated macro usage and a number are not trivial
to convert.

I'll need to work on that but allowing it to build should be enough
for now, agreed?

If there is a need to make a bigger patch then we should make it, we have time to do things properly. I do not know anything about torque and I just resolved the compile error by the patch. You know way better how things should work in this package :)

*I do not know anything about am-utils...

(In reply to Ondrej Dubaj from comment #8)
> If there is a need to make a bigger patch then we should make it, we have
> time to do things properly. I do not know anything about torque and I just
> resolved the compile error by the patch. You know way better how things
> should work in this package :)

am-utils is the BSD automounter (amd).

It uses a somewhat different mount map syntax to the the SystemV automounter
autofs, which I also maintain. amd has somewhat more sophisticated map
features than autofs although autofs is more widely used, probably because
its mount map syntax is simpler.

The change I will do is effectively the same as the text replacement you
suggested.

The autoconf problems are deprecated warnings and I believe the autoconf
output will still work so the minimal change will be sufficient for now.
I'll do that as soon as I can.

I'll also build and install autoconf 2.71 in a Fedora VM, build an updated
am-utils and verify it works ok. I don't see any other way to do that since
I will need at least one NFS server to check basic function.

I'll raise another bug to update the deprecated autoconf functions since
that will take a while and amd should work fine in the mean time.

I'm having difficulty getting my other work done, not dew to development
problems but due to problems with the CI system and having to work through
the new development procedures, I'm trying though!

Ian

Thanks for your effort!

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Mostly I have updated the obsolete autoconf functions that were being used.

I'll come back to this later, meanwhile the package builds and functions in F33,
builds against the autoconf-2.71 Copr environment and in the current Rawhide
although it appears the current Rawhide buildroot is still using autoconf 2.69.

am-utils specifically allows autoconf 2.69 and 2.71, if the versions used changes
I will need to re-test and add that version to the check prior to the autoreconf
done at the start of the build.

Autoconf-2.71 Fedora Change is completed. According to this, I am closing this tracker and if any FTBFS will appear in Fedora Rawhide, new F36FTBFS tracker will be created for this purposes, thank you for cooperation.

I think this should be CURRENTRELEASE since AFAIK am-utils will now
build whether or not autoconf 2.71 is present.