When emerging app-office/dia, the following warning is emitted: * This package has a configure.in file which has long been deprecated. Please * update it to use configure.ac instead as newer versions of autotools will die * when it finds this file. See https://bugs.gentoo.org/426262 for details. Per the warning, the configure.in file should be updated to configure.ac. (Also, #426262 seems unrelated to anything having to do with configure.in, but I don't know which bug was intended to be referenced.) Reproducible: Always Steps to Reproduce: 1. emerge app-office/dia
*** This bug has been marked as a duplicate of bug 426262 ***
Not a dupe, but something to fix.
Re my remark about the incorrect bug being referenced...I must have typo'd the bug number. Or the server glitched and gave me the wrong result. Heck, I think I clicked on the link in my own comment to verify. I don't know what happened there.
(In reply to Justin Lecher from comment #2) > Not a dupe, but something to fix. You're going to fix all those thousands of packages in the tree? Just by adding a cp ${subdirs}/configure.{in,ac} all over the package sources? Maybe you want to bring this up on the dev mailing list before you start "fixing" things. *** This bug has been marked as a duplicate of bug 426262 ***
This is _not_ a dupe. Future autotools will not work with .in but require .ac. In order to proactivaly fix those packages _before_ they actually break, we need bug reports like this.
@gnome, should we add the move from configure.in to configure.ac to gnome2.eclass? I would do it in a more generally used eclass (maybe autotools.eclass one)
(In reply to Pacho Ramos from comment #6) > @gnome, should we add the move from configure.in to configure.ac to > gnome2.eclass? I would do it in a more generally used eclass (maybe > autotools.eclass one) The addition to the autotools-urils.eclass was already refused in favour of the warning.
Adding it to autotools-utils.eclass wouldn't either help as gnome2.eclass doesn't use that one (and only a part of the packages in the tree do that). I was thinking in plain autotools.eclass and that be done by the "eautoreconf" set. Let me comment in original bug report. Please note I am not against doing this at all, I have already fixed this in some ebuilds I saw some days ago that was hitting the warnings but that lead me to think we probably will need a more "general" solution to not have to fix it in a ton of ebuilds :/
