Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1942977 - am-utils: FTBFS with upcoming autoconf-2.71
Summary: am-utils: FTBFS with upcoming autoconf-2.71
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: am-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1942967
TreeView+ depends on / blocked
 
Reported: 2021-03-25 12:34 UTC by Ondrej Dubaj
Modified: 2021-04-14 09:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ondrej Dubaj 2021-03-25 12:34:53 UTC
Your package fails to build with the newest upcoming autoconf-2.71, which is part of a wide Fedora change. Please see the attached copr: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/. More information about testing your package when building with autoconf available here: https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test

Comment 1 Ondrej Dubaj 2021-04-12 07:11:12 UTC
Gentle ping.

Comment 2 Ian Kent 2021-04-12 10:28:52 UTC
(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.

Comment 3 Ondrej Dubaj 2021-04-12 12:02:34 UTC
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.

Comment 4 Ian Kent 2021-04-12 13:15:04 UTC
(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

Comment 5 Ian Kent 2021-04-12 13:24:45 UTC
(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.

Comment 6 Ondrej Dubaj 2021-04-12 14:48:36 UTC
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

Comment 7 Ian Kent 2021-04-14 03:43:36 UTC
(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?

Comment 8 Ondrej Dubaj 2021-04-14 05:55:35 UTC
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 :)

Comment 9 Ondrej Dubaj 2021-04-14 05:57:07 UTC
*I do not know anything about am-utils...

Comment 10 Ian Kent 2021-04-14 08:51:18 UTC
(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

Comment 11 Ondrej Dubaj 2021-04-14 09:07:02 UTC
Thanks for your effort!


Note You need to log in before you can comment on or make changes to this bug.