If we start now, to rename configure.in to configure.ac before eautoreconf we will avoid lots of breakages due to the deprecation of .in in automake-1.13. What du you think?
(In reply to comment #0) > If we start now, to rename configure.in to configure.ac before eautoreconf > we will avoid lots of breakages due to the deprecation of .in in > automake-1.13. > What du you think? Isn't that more like pretending they aren't broken? Well, it would help the old versions on which we run eautoreconf but then i'm not sure if we shouldn't do autoreconf with the older automake version.
As far as I understand from what is written, it is just a name deprecation. So simply renaming it, fixes the issue.
I think we can start with having it throw a warning first, then we can move on..
if the package doesn't work with automake-1.13, then it should be setting WANT_AUTOMAKE=1.12 in the ebuild, or the package itself should be doing the compatible fixes if they can't get upstream updated
(In reply to comment #3) > I think we can start with having it throw a warning first, then we can move > on.. I personally think a warning in portage would be better than in one the eclasses. autotools-utils can do it but autotools would only print it if eautoreconf is done already. Possibly, we could embed the check into econf, with a nice QA warning. Zac, what do you think?
Yeah, a warning in portage sounds good.
I am still thinking the autotools.eclass is the better place. .in vs. .ac only matters in case eautoreconf is called. So why don't we only warn in this case?
(In reply to comment #7) > I am still thinking the autotools.eclass is the better place. .in vs. .ac > only matters in case eautoreconf is called. So why don't we only warn in > this case? Because then a random package will want to apply a single patch and add an eautoreconf, and take your guess..
And _then_ they'll receive the warning, so the developer can inform upstream. And _when_ automake 1.13 will be out, if WANT_AUTOMAKE is not set to older version, autotools.eclass will warn _and_ rename. I agree with Justin, autotools.eclass is the one that should do the work, not the PM.
This has been moved in on .14 for failure.
(In reply to comment #5) i don't think checking in econf makes sense. if i have a package that never runs autotools (because the generated ones are perfectly fine), i'm not going to care about configure.{in,ac}. in fact, trying to "fix" that warning is only going to slow things down.
*** Bug 468720 has been marked as a duplicate of this bug. ***
Could we please get a QA warning when autotools.eclass functions act on configure.in? the bad autotools release is coming closer and we should start to prepare the tree.
(In reply to Justin Lecher from comment #13) i've added a eqawarn now: http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165&r2=1.166 let's see how it shakes out in the tree
*** Bug 530478 has been marked as a duplicate of this bug. ***
OK, I'm confused. SpanKY's patch led me to file #530478, which got marked as a duplicate of this one. But this one was marked RESOLVED/FIXED already, even though my filing is an issue caused by the commit in question. How is this going to get resolved if everything new gets directed toward a bug that's already marked RESOLVED/FIXED?
@base-system, have you think in adding the moving to eautoreconf directly? Otherwise, we will need to add the "mv configure.in configure.ac || die" to really a lot of ebuilds (I have already needed to fix it myself on them in some ebuilds I have been touching and that even without running a tinderbox test over the big amount of packages that didn't get any update for ages and will likely be broken too :/)
A note...if you do this in a general way, you should probably have a "QA notice, this package is using configure.in. Do not file a bug report, but file upstream", so people know to let upstream know.
From what I hear, configure.in was used in versions before 2001. Looking at the home page repository for autoconf, autoconf-2.50 was released in 2001. Since autoconf-2.13 is still within Portage with all other Portage autoconf versions being newer, our EBuild script fixes should contain a check in the case autoconf-2.13 is ever used? ie: if AUTOCONF_VERSION > 2.13 then mv configure.in configure.ac fi Just searching or grepping through the Portage tree, I don't think I see any packages currently explicitly calling for autoconf-2.13, but this still could occur. Some EBuilds called for earlier autoconf versions, such as autoconf-2.5. Reference: "...could be named configure.in. It is the name used in older version (before 2001) of Autoconf." http://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en
*** Bug 613860 has been marked as a duplicate of this bug. ***
Not to step on anyone's toes, but I was CCed to this bug when a bug I filed for a specific package with this bug was closed as a duplicate. There are still many packages which use the old scheme, and IMHO, this message needs to be removed or the packages need to be updated. Closing bugs before package maintainers can resolve the problem does not help things.
Right. Given that the resolution to this bug was to output a warning message, marking bugs as duplicates is strange. jer: Why was this bug re-opened?
(In reply to Mike Gilbert from comment #23) > Right. Given that the resolution to this bug was to output a warning > message, marking bugs as duplicates is strange. And what should we do with those warnings? Add a `mv' to every ebuild instead of fixing it for everyone in autotools.eclass? > jer: Why was this bug re-opened? Because "autotools/autotools-utils eclasses should rename configure.in to configure.ac internally" is not the same as "warn about configure.in".
(In reply to Jeroen Roovers from comment #24) > (In reply to Mike Gilbert from comment #23) > > Right. Given that the resolution to this bug was to output a warning > > message, marking bugs as duplicates is strange. > > And what should we do with those warnings? Add a `mv' to every ebuild > instead of fixing it for everyone in autotools.eclass? Yes. It's a bug in upstream sources; submit a patch upstream, and add a workaround in your ebuild. > > jer: Why was this bug re-opened? > > Because "autotools/autotools-utils eclasses should rename configure.in to > configure.ac internally" is not the same as "warn about configure.in". At least one of the maintainers decided not to implement the proposed change. If you want to be picky, change the resolution to WONTFIX instead.
(In reply to Mike Gilbert from comment #25) > > And what should we do with those warnings? Add a `mv' to every ebuild > > instead of fixing it for everyone in autotools.eclass? > > Yes. It's a bug in upstream sources; submit a patch upstream, and add a > workaround in your ebuild. Ebuild? Singular? > > > jer: Why was this bug re-opened? > > > > Because "autotools/autotools-utils eclasses should rename configure.in to > > configure.ac internally" is not the same as "warn about configure.in". > > At least one of the maintainers decided not to implement the proposed > change. If you want to be picky, change the resolution to WONTFIX instead. Bug #530632 should be blocked by hundreds if not thousands of bugs but nobody cared. On the other hand, fixing this in autotools.eclass is trivial.
Since 613860 was closed again without the package being fixed, I will not be filing any further bugs on this issue. I only have limited time to devote to contributing to OSS, and I do not have the time to go to every upstream package maintainer and ask them to rename their files. I was hoping that our own package maintainers would be able to do this for me, but that appears not to be the case. My recommendation in this case would then be to rename the files in the background and not print a message at all. 607686 and 606754 can also be closed if we're just going to ignore these.
(In reply to Jeroen Roovers from comment #27) Maybe you could send a patch for review? Someone needs to push this forward, or the issue will remain unresolved.
Created attachment 475898 [details, diff] 426262-autotools.eclass-deprecated-configure.in.patch Sent to gentoo-dev@
Let's do this as an EAPI 8 change to force people to check it actually works, in case of strange edge cases.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fe3f65790fabb6e98d0b851d3013714c7706eccc commit fe3f65790fabb6e98d0b851d3013714c7706eccc Author: Sam James <sam@gentoo.org> AuthorDate: 2021-04-01 00:00:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-04-11 20:59:55 +0000 autotools.eclass: rename configure.in to configure.ac on new EAPIs automake is eventually going to fail when it detects configure.in. Don't do this immediately - instead only on new EAPIs to avoid breaking existing ebuilds. Bug: https://bugs.gentoo.org/426262 Signed-off-by: Sam James <sam@gentoo.org> eclass/autotools.eclass | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff7fb4695d7656feb7b793cd897882b7d49342d6 commit ff7fb4695d7656feb7b793cd897882b7d49342d6 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-10 15:12:16 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-07-10 21:41:02 +0000 autotools.eclass: rename configure.in to configure.ac on new EAPIs automake is "eventually" going to fail when it detects configure.in. Don't do this immediately - instead only on new EAPIs to avoid breaking existing ebuilds. We give an eqawarn (which is triggered by e.g. PORTAGE_ELOG_CLASSES="qa" and is opt-in) for maintainers to upstream these where possible, but this isn't always the case for software ehich otherwise works but is unmaintained upstream. Bug: https://bugs.gentoo.org/426262 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> eclass/autotools.eclass | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
I got case when simple file rename is not enough: https://github.com/GModal/raton It required at least this replacement to get configure not broken: sed -i 's/configure.in/configure.ac/g' configure.in Although autogen.sh also has commands referring it directly (which is in turn referred from top level Makefile.am), above was enough for ebuild.
(In reply to Nikita Zlobin from comment #34) > I got case when simple file rename is not enough: > https://github.com/GModal/raton > > It required at least this replacement to get configure not broken: > sed -i 's/configure.in/configure.ac/g' configure.in > > Although autogen.sh also has commands referring it directly (which is in > turn referred from top level Makefile.am), above was enough for ebuild. I think that's interesting although I'm not sure if that's a reason to change the existing logic.
*** Bug 546614 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15bc4ddeb0d78cf15632d7d9247532f295943602 commit 15bc4ddeb0d78cf15632d7d9247532f295943602 Author: Huang Rui <vowstar@gmail.com> AuthorDate: 2022-04-25 11:04:38 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-04-27 13:18:57 +0000 sci-electronics/iverilog: backport fix compile bug EAPI: update EAPI 7 -> 8 fix parse.cc fatal error fix calls nm directly fix can't find configure.in fix depend on sys-libs/readline:= Bug: https://bugs.gentoo.org/721022 Bug: https://bugs.gentoo.org/734760 Bug: https://bugs.gentoo.org/426262 Closes: https://bugs.gentoo.org/731906 Closes: https://bugs.gentoo.org/730096 Signed-off-by: Huang Rui <vowstar@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/25191 Signed-off-by: Joonas Niilola <juippis@gentoo.org> .../iverilog/files/iverilog-10.3-call-nm.patch | 67 +++++++++++++++ .../files/iverilog-10.3-configure-ac.patch | 12 +++ .../files/iverilog-10.3-gen-bison-header.patch | 97 ++++++++++++++++++++++ .../files/iverilog-10.3-override-var.patch | 12 +++ sci-electronics/iverilog/iverilog-10.3.ebuild | 23 +++-- 5 files changed, 202 insertions(+), 9 deletions(-)
(In reply to Larry the Git Cow from comment #33) [...] > We give an eqawarn (which is triggered by e.g. PORTAGE_ELOG_CLASSES="qa" > and > is opt-in) for maintainers to upstream these where possible, but this > isn't > always the case for software ehich otherwise works but is unmaintained > upstream. > > Bug: https://bugs.gentoo.org/426262 > Signed-off-by: Sam James <sam@gentoo.org> > Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> > > eclass/autotools.eclass | 17 ++++++++++++++--- > 1 file changed, 14 insertions(+), 3 deletions(-) Hello Is there a way to skip the QA warning without disabling all the other QA checks? As with eapi8 the renaming is done automatically, people have started to drop the manual renaming but, as a consequence, we start to get this useless warning more and more: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff Useless because it usually affects to software that is not actively maintained upstream and, then, we will keep getting this warning logged even if we cannot do much more than the renaming to fix it :/ Personally I would downgrade it to einfo... but, if you don't want, maybe the eclass could rely on a QA_CONFIGUREIN variable to ignore this kind of issues (as currently dont for ignoring other QA warnings) Thanks a lot Thanks
(In reply to Pacho Ramos from comment #38) > Useless because it usually affects to software that is not actively > maintained upstream and, then, we will keep getting this warning logged even > if we cannot do much more than the renaming to fix it :/ In such cases, the ebuild author can/should silence the warning by renaming the file before calling eautoreconf. I think the portion of fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff which removes the renaming should be reverted.
(In reply to Mike Gilbert from comment #39) > (In reply to Pacho Ramos from comment #38) > > Useless because it usually affects to software that is not actively > > maintained upstream and, then, we will keep getting this warning logged even > > if we cannot do much more than the renaming to fix it :/ > > In such cases, the ebuild author can/should silence the warning by renaming > the file before calling eautoreconf. > > I think the portion of fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff which > removes the renaming should be reverted. I don't agree, packages still using a configure.in are nearly /all/ dead nowadays, so we would be putting this in roughly every ebuilds still using it under those terms. The eclass doing it allows to simplify ebuilds and it's what's was done there, there'd be almost no point to this move existing in the eclass otherwise. Could instead argue that the eclass still giving a qa warning doesn't mean much nowadays, given little hope to report/change for any upstreams at this point.
(In reply to Ionen Wolkens from comment #40) > Could instead argue that the eclass still giving a qa warning doesn't mean > much nowadays, given little hope to report/change for any upstreams at this > point. Albeit the information is still semi-useful to know it happened (the move can sometime break the package), could be a einfo instead.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7835e0d3715d2554e207cb7ed90cf123379acd87 commit 7835e0d3715d2554e207cb7ed90cf123379acd87 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-05-28 13:12:42 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-05-29 07:57:53 +0000 autotools.eclass: Downgrade eqawarn for renaming configure.in At this point, almost all upstreams will have switched to configure.ac. Therefore, configure.in is most likely an indication of an inactive upstream, and there is no reasonable way for the ebuild maintainer to silence the warning (other than the ebuild renaming the file). Keep the message as einfo, so there is still an indication that the file was renamed. Bug: https://bugs.gentoo.org/426262 Reviewed-by: Sam James <sam@gentoo.org> Reviewed-by: Pacho Ramos <pacho@gentoo.org> Signed-off-by: Ulrich Müller <ulm@gentoo.org> eclass/autotools.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
