autoconf 2.71 landed
Hi, autoconf 2.71 just landed in openSUSE:Factory and it looks like a good 100 more packages are failing now than they did before. I surely didn't look at all of them, but most of them I've seen are basically all the same: calling either autoreconf directly or triggering autoconf through patching input files on very old sources. The general advise is not to do that, but rather append the output of autoconf to a patch. We also have autoconf213 in Factory, which might be more fitting to old projects. Greetings, Stephan
On 07.04.22 20:20, Stephan Kulow wrote:
Hi,
autoconf 2.71 just landed in openSUSE:Factory and it looks like a good 100 more packages are failing now than they did before. I surely didn't look at all of them, but most of them I've seen are basically all the same: calling either autoreconf directly or triggering autoconf through patching input files on very old sources.
The general advise is not to do that, but rather append the output of autoconf to a patch. We also have autoconf213 in Factory, which might be more fitting to old projects.
vdr:plugins/tntnet (and server:http/tntnet) are failing in a way that let's me think there is a bug in autoconf resulting in syntactically incorrect configure script. I have no idea how "appending the output of autoconf to a patch" would solve this. This is the output of autoconf: abuild@strolchi:~/rpmbuild/BUILD/tntnet-3.0> autoconf configure.ac:27: warning: The macro `AC_LANG_C' is obsolete. configure.ac:27: You should run autoupdate. ./lib/autoconf/c.m4:72: AC_LANG_C is expanded from... m4/acx_pthread.m4:49: ACX_PTHREAD is expanded from... configure.ac:27: the top level configure.ac:27: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:27: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... m4/acx_pthread.m4:49: ACX_PTHREAD is expanded from... configure.ac:27: the top level I did run "autoupdate" already, but this did not change anything. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Saturday 2022-04-09 12:10, Stefan Seyfried wrote:
vdr:plugins/tntnet (and server:http/tntnet) are failing in a way that let's me think there is a bug in autoconf resulting in syntactically incorrect configure script.
It's a bug in tntnet's configure.ac. All arguments ought to be enclosed in [], like so: --- tntnet-3.0.orig/configure.ac +++ tntnet-3.0/configure.ac @@ -110,7 +110,7 @@ AC_ARG_WITH([md2man], AS_IF( [test "$with_md2man"], - AC_CHECK_PROG(MD2MAN, [go-md2man], [go-md2man]) + [AC_CHECK_PROG(MD2MAN, [go-md2man], [go-md2man])] AS_IF( [test -z "$MD2MAN"], AC_MSG_ERROR([go-md2man not found]) (Repeat for every argument everywhere, i.e. AS_IF([test ...], [AC_CHECK_PROG([MD2MAN], ...)], [AS_IF([test ...], [AC_MSG_ERROR([... This is simply because macros such as AC_CHECK_PROG can expand to something that includes a comma, which changes the meaning of the expansion, e.g. » cat >x.m4 <<-EOF define(`foo', `a, b') define(`as_ifff', `1=$1; 2=$2') as_ifff(foo) as_ifff(`foo') EOF » m4 x.m4 1=a; 2=b 1=a, b; 2=
On 09.04.22 14:35, Jan Engelhardt wrote:
On Saturday 2022-04-09 12:10, Stefan Seyfried wrote:
vdr:plugins/tntnet (and server:http/tntnet) are failing in a way that let's me think there is a bug in autoconf resulting in syntactically incorrect configure script.
It's a bug in tntnet's configure.ac. All arguments ought to be enclosed in [], like so:
--- tntnet-3.0.orig/configure.ac +++ tntnet-3.0/configure.ac @@ -110,7 +110,7 @@ AC_ARG_WITH([md2man],
AS_IF( [test "$with_md2man"], - AC_CHECK_PROG(MD2MAN, [go-md2man], [go-md2man]) + [AC_CHECK_PROG(MD2MAN, [go-md2man], [go-md2man])] AS_IF( [test -z "$MD2MAN"], AC_MSG_ERROR([go-md2man not found])
(Repeat for every argument everywhere, i.e. AS_IF([test ...], [AC_CHECK_PROG([MD2MAN], ...)], [AS_IF([test ...], [AC_MSG_ERROR([...
Ah, OK. Thanks for the hint :-) I meanwhile think I decoded what coolo wanted to point out and instead of patching Makefile.am patched (additionally) Makefile.in and thus got rid of autoconf for the build completely :-)
This is simply because macros such as AC_CHECK_PROG can expand to something that includes a comma, which changes the meaning of the expansion, e.g.
» cat >x.m4 <<-EOF define(`foo', `a, b') define(`as_ifff', `1=$1; 2=$2') as_ifff(foo) as_ifff(`foo') EOF » m4 x.m4 1=a; 2=b 1=a, b; 2=
Thanks again, I'll try to remember if I encounter this again in the future (very likely some of my own code has problems like that ;-) I also submitted my fix to server:http as sr#968018 -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 09.04.22 um 15:48 schrieb Stefan Seyfried:
Ah, OK. Thanks for the hint :-)
I meanwhile think I decoded what coolo wanted to point out and instead of patching Makefile.am patched (additionally) Makefile.in and thus got rid of autoconf for the build completely :-)
Right :) This strategy of course only works if you have a working autoconf handy. So it only works towards the future. Greetings, Stephan
On 09.04.22 22:11, Stephan Kulow wrote:
Am 09.04.22 um 15:48 schrieb Stefan Seyfried:
Ah, OK. Thanks for the hint :-)
I meanwhile think I decoded what coolo wanted to point out and instead of patching Makefile.am patched (additionally) Makefile.in and thus got rid of autoconf for the build completely :-)
Right :)
This strategy of course only works if you have a working autoconf handy. So it only works towards the future.
Well, in this case it was simple enough to basically apply the same change that was in Makefile.am also to Makefile.in. But yes, I also tried using autoconf-2.13 before, that failed in much more spectacular ways of course :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thu, 2022-04-07 at 20:20 +0200, Stephan Kulow wrote:
Hi,
autoconf 2.71 just landed in openSUSE:Factory and it looks like a good 100 more packages are failing now than they did before. I surely didn't look at all of them, but most of them I've seen are basically all the same: calling either autoreconf directly or triggering autoconf through patching input files on very old sources.
The general advise is not to do that, but rather append the output of autoconf to a patch. We also have autoconf213 in Factory, which might be more fitting to old projects.
Greetings, Stephan
It has probably been asked before, but why do we run "automake" and "autoreconf" at all in OBS? It's not how autotools are intended to be used. Makefile.in and configure are part of the source code, and should be inputs to OBS. Martin
Am 14.04.22 um 09:03 schrieb Martin Wilck:
It has probably been asked before, but why do we run "automake" and "autoreconf" at all in OBS? It's not how autotools are intended to be used. Makefile.in and configure are part of the source code, and should be inputs to OBS.
2 reasons: - we have a lot of old packages that had their configures created before the creation of aarch64 or riscv64 or you name it. - as soon as one of your patches updates a Makefile.am you're doomed to run the automake that ran during the creation process of the tar. So it's easier to reset that in %prep. I say easier because patching Makefile.in (as well) is possible if your Makefile.am patch is easy enough. But that kind of conflicts with another goal we have: bring patches upstream. Calling autoreconf is just often enough the easier solution. Greetings, Stephan
On Apr 14 2022, Stephan Kulow wrote:
- we have a lot of old packages that had their configures created before the creation of aarch64 or riscv64 or you name it.
That usually only requires updating config.{guess,sub}, though (and that happens automagically). -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Am 14.04.22 um 11:37 schrieb Andreas Schwab:
On Apr 14 2022, Stephan Kulow wrote:
- we have a lot of old packages that had their configures created before the creation of aarch64 or riscv64 or you name it. That usually only requires updating config.{guess,sub}, though (and that happens automagically).
Usually. Greetings, Stephan
On Apr 14 2022, Stephan Kulow wrote:
Am 14.04.22 um 11:37 schrieb Andreas Schwab:
On Apr 14 2022, Stephan Kulow wrote:
- we have a lot of old packages that had their configures created before the creation of aarch64 or riscv64 or you name it. That usually only requires updating config.{guess,sub}, though (and that happens automagically).
Usually.
It works for a very big part of factory already. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Thu, 2022-04-14 at 09:14 +0200, Stephan Kulow wrote:
2 reasons: - we have a lot of old packages that had their configures created before the creation of aarch64 or riscv64 or you name it.
It's optimistic to expect that such packages would work with autoconf 2.71. It makes some sense to assume that if "configure" doesn't cut it any more for a given package, the package is unmaintained upstream. Martin
On 14.04.22 09:03, Martin Wilck wrote:
On Thu, 2022-04-07 at 20:20 +0200, Stephan Kulow wrote:
Hi,
autoconf 2.71 just landed in openSUSE:Factory and it looks like a good 100 more packages are failing now than they did before. I surely didn't look at all of them, but most of them I've seen are basically all the same: calling either autoreconf directly or triggering autoconf through patching input files on very old sources.
The general advise is not to do that, but rather append the output of autoconf to a patch. We also have autoconf213 in Factory, which might be more fitting to old projects.
Greetings, Stephan
It has probably been asked before, but why do we run "automake" and "autoreconf" at all in OBS?
Because for some reason *.ac/*.am needs to be patched?
It's not how autotools are intended to be used. Makefile.in and configure are part of the source code,
Not always. Nowadays there are enough upstreams which had their last release in the first decade of this century and later versions can just be fetched from github. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thu, 14 Apr 2022, Stefan Seyfried wrote:
On 14.04.22 09:03, Martin Wilck wrote:
On Thu, 2022-04-07 at 20:20 +0200, Stephan Kulow wrote:
Hi,
autoconf 2.71 just landed in openSUSE:Factory and it looks like a good 100 more packages are failing now than they did before. I surely didn't look at all of them, but most of them I've seen are basically all the same: calling either autoreconf directly or triggering autoconf through patching input files on very old sources.
The general advise is not to do that, but rather append the output of autoconf to a patch. We also have autoconf213 in Factory, which might be more fitting to old projects.
Greetings, Stephan
It has probably been asked before, but why do we run "automake" and "autoreconf" at all in OBS?
Because for some reason *.ac/*.am needs to be patched?
It's not how autotools are intended to be used. Makefile.in and configure are part of the source code,
Not always. Nowadays there are enough upstreams which had their last release in the first decade of this century and later versions can just be fetched from github.
Then autoconf can be called as part of the source service? I know there are "excuses" to call auto(re)conf at build time but they do not make it a valid solution. Richard.
On Thu, 14 Apr 2022, Jan Engelhardt wrote:
On Thursday 2022-04-14 10:25, Richard Biener wrote:
Then autoconf can be called as part of the source service?
Technically yes, but running autoreconf requires significant BuildRequires, and that the source service environment does not have.
But "technically" that problem could be solved.
Richard.
--
Richard Biener
Am 14.04.22 um 10:25 schrieb Richard Biener:
Then autoconf can be called as part of the source service?
I know there are "excuses" to call auto(re)conf at build time but they do not make it a valid solution.
https://build.opensuse.org/request/show/965152 isn't exactly nice either. But it's still the clearer path. Greetings, Stephan
On Thu, 2022-04-14 at 09:26 +0200, Stefan Seyfried wrote:
Not always. Nowadays there are enough upstreams which had their last release in the first decade of this century and later versions can just be fetched from github.
Arguably, such projects are using autotools wrongly as well. It's possible to maintain "configure" in git. Martin
On 14.04.22 15:39, Martin Wilck wrote:
On Thu, 2022-04-14 at 09:26 +0200, Stefan Seyfried wrote:
Not always. Nowadays there are enough upstreams which had their last release in the first decade of this century and later versions can just be fetched from github.
Arguably, such projects are using autotools wrongly as well. It's possible to maintain "configure" in git.
You are certainly free to argue with them ;-) If I was such an upstream, this would probably just get you into my killfile or I'd just offer that project to you for adoption. And yes, I have a few projects where "it works on my machine and everyone else can take or leave it" is my mode of operation. None of them is in openSUSE, though ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
participants (6)
-
Andreas Schwab -
Jan Engelhardt -
Martin Wilck -
Richard Biener -
Stefan Seyfried -
Stephan Kulow