the ebuild does this mv "${f}" "${f/in/ac}" || die when it should be doing this mv "${f}" "${f%in}ac" || die and since $f is the whole path to configure.in, it can corrupt the path to the file instead of renaming the extension.
*** Bug 604894 has been marked as a duplicate of this bug. ***
(In reply to Mart Raudsepp from comment #2 / From bug #604894) > Marking as duplicate of newer bug as the newer one has a fix suggestion > > *** This bug has been marked as a duplicate of bug 614982 *** Unclear. I see two different proposed fixes: (In reply to LE GARREC Vincent from comment #0 / From bug #604894) > I'm using PORTAGE_TMPDIR="/home/legarrec/info". > > In the ebuild (src_prepare), there is a replacement : "/in/ac" that doesn't > replace the good string. I suggest "configure.in/configure.ac". > This does look like a safer way of matching. (In reply to Mikael Magnusson from comment #0 / From bug #614982) > the ebuild does this > mv "${f}" "${f/in/ac}" || die > when it should be doing this > mv "${f}" "${f%in}ac" || die > > and since $f is the whole path to configure.in, it can corrupt the path to > the file instead of renaming the extension. Not as easily (human) readable, but might work. Unsure if this syntax is from bash or coreutils. (maybe it's a POSIX standard for shells?) If it's valid, perhaps something like: ${f%configure.in}configure.ac this way the path ambiguity would be resolved (and it's still human readable / clear intent)
% dash -c 'a=foo/bar/baz.ac; echo ${a%baz.ac}' foo/bar/ http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html ${parameter%word} Remove Smallest Suffix Pattern. The word shall be expanded to produce a pattern. The parameter expansion shall then result in parameter, with the smallest portion of the suffix matched by the pattern deleted. So yeah, it's standard and should work everywhere, and just the %in will work since the filename is (obviously) always at the end of the path to the file, but %configure.in will work just as well if you prefer it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=69dc05bada5cb4272c7af647306a68bbd9820bc0 commit 69dc05bada5cb4272c7af647306a68bbd9820bc0 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-01-04 02:26:39 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-01-04 17:18:00 +0000 x11-libs/wxGTK: don't eautoreconf or rename configure.in files wxWidgets doesn't use full autotools (at least not automake), and it maintains an autoconf'ed configure script inside its code repository, which gets (usually) updated after each configure.in update. Because we don't eautoreconf to see a slightly dumb warning about configure.in vs configure.ac, remove the renaming, as the code is buggy and breaks on some non-default PORTAGE_TMPDIR values. I don't intend to ever add back an eautoreconf if at all possible, but if it is, make sure such renaming isn't buggy like this. Also note that other Makefile.in's seem to refer to the preset configure.in's by name (with .in ending), so renaming them is probably wrong as well via such a global "find" approach, at least without patching the references too. The eautoreconf and buggy renaming was already removed on bump for 3.0 SLOT. Closes: https://bugs.gentoo.org/614982 Package-Manager: Portage-2.3.19, Repoman-2.3.6 x11-libs/wxGTK/wxGTK-3.0.3-r300.ebuild | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
