Summary: | www-client/w3m-0.5.3_p20210102 error: gettext infrastructure mismatch | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Austin Kilgore <kilgorephotoshop> |
Component: | Current packages | Assignee: | CJK Team <cjk> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Letto2, mscardovi, myloveyuxuan, polynomial-c, sam, spikyatlinux, tero, ulm, xavier.miller |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/20545 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
build patch w3m-gettext.patch |
Description
Austin Kilgore
2021-04-26 02:54:18 UTC
I am seeing this too, it fails in src_compile. The key error message is: make[1]: Entering directory '/tmp/portage/www-client/w3m-0.5.3_p20210102/work/w3m-0.5.3-git20210102/po' *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.20 make[1]: *** [Makefile:149: check-macro-version] Error 1 Looks like the problem is a mismatch of the gettext version for po/Makefile.in.in. Adding the following line to configure.ac fixes it here: AM_GNU_GETTEXT_VERSION([0.18]) BTW, autoheader fails as well (because of missing templates): * Running eautoreconf in '/tmp/portage/www-client/w3m-0.5.3_p20210102/work/w3m-0.5.3-git20210102' ... * Running 'aclocal -I m4' ... [ ok ] * Running 'autoconf -I m4 --force' ... [ ok ] * Running 'autoheader -I m4' ... [ !! ] * Running elibtoolize in: w3m-0.5.3-git20210102/ Maybe the least painful fix would be to just run eautoconf instead of eautoreconf? Then the codeset.m4 macro won't be needed either. Created attachment 702549 [details, diff]
build patch
(In reply to Ulrich Müller from comment #3) > BTW, autoheader fails as well (because of missing templates): > > * Running eautoreconf in > '/tmp/portage/www-client/w3m-0.5.3_p20210102/work/w3m-0.5.3-git20210102' ... > * Running 'aclocal -I m4' ... [ > ok ] > * Running 'autoconf -I m4 --force' ... [ > ok ] > * Running 'autoheader -I m4' ... [ > !! ] > * Running elibtoolize in: w3m-0.5.3-git20210102/ > > Maybe the least painful fix would be to just run eautoconf instead of > eautoreconf? Then the codeset.m4 macro won't be needed either. +1 replacing eautoreconf with eautoconf fixed it in the least painful way for me. I have added a sed and released a new pr. This should fix the problem with eautoreconf. I'm sorry for bad things happened here (In reply to Marco Scardovi from comment #6) > I have added a sed and released a new pr. This should fix the problem with > eautoreconf. I'm sorry for bad things happened here Why would you want to run eautoreconf, in the first place? The package uses autoconf only, but neither automake nor libtool. (In reply to Ulrich Müller from comment #7) > Why would you want to run eautoreconf, in the first place? The package uses > autoconf only, but neither automake nor libtool. sam asked me to change it *** Bug 785802 has been marked as a duplicate of this bug. *** (In reply to Marco Scardovi from comment #8) > (In reply to Ulrich Müller from comment #7) > > Why would you want to run eautoreconf, in the first place? The package uses > > autoconf only, but neither automake nor libtool. > > sam asked me to change it So, the reason is that: - where there isn't automake, it should be a noop anyway - autoconf was obviously chosen here because autoreconf doesn't work - it's a bug which needs fixing by itself. For now, I'll change back to eautoconf, but as I've just woken up, I can't tell you why I didn't notice this last night (apologies!). (In reply to Sam James from comment #10) > (In reply to Marco Scardovi from comment #8) > > (In reply to Ulrich Müller from comment #7) > > > Why would you want to run eautoreconf, in the first place? The package uses > > > autoconf only, but neither automake nor libtool. > > > > sam asked me to change it > > So, the reason is that: > - where there isn't automake, it should be a noop anyway > - autoconf was obviously chosen here because autoreconf doesn't work - it's > a bug which needs fixing by itself. > > For now, I'll change back to eautoconf, but as I've just woken up, I can't > tell you why I didn't notice this last night (apologies!). I have already released a PR for it, please tell me if it's ok for you when you have time :) (In reply to Sam James from comment #10) > - autoconf was obviously chosen here because autoreconf doesn't work - it's > a bug which needs fixing by itself. Yes, but it should be reported and fixed upstream. Adding distro specific patches will most likely require additional maintenance in the future. (For example, fixing the autoheader issue would mean updating _all_ AC_DEFINEs in configure.ac, and there are many of them.) eautoconf just works, or are there any known problems? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8003dbb063a24b67ad723b6b153617b24ab7d697 commit 8003dbb063a24b67ad723b6b153617b24ab7d697 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-04-26 09:57:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-04-26 09:57:32 +0000 www-client/w3m: revert back to eautoconf for now Earlier, we switched to eautoreconf because: - it's a noop when *.am is missing anyway - fixing the build system is preferable - this allows patches to be added without first having to fix an unrelated issue first Let's roll back to eautoconf for now because of a gettext mismatch. Fixes: 50c53cbcbe84fe1473244e2bd6ad5e4533601bac Fixes: 5d3abfa9559c11bd9ac3087a9bf3debd51cf0c30 Bug: https://bugs.gentoo.org/778482 Closes: https://bugs.gentoo.org/785760 Signed-off-by: Sam James <sam@gentoo.org> www-client/w3m/w3m-0.5.3_p20210102.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Created attachment 702612 [details, diff]
w3m-gettext.patch
This is a better patch that is robust to the "mkdir_p" still being used in gettext.
(In reply to Ulrich Müller from comment #12) > (In reply to Sam James from comment #10) > > - autoconf was obviously chosen here because autoreconf doesn't work - it's > > a bug which needs fixing by itself. > > Yes, but it should be reported and fixed upstream. Adding distro specific > patches will most likely require additional maintenance in the future. (For > example, fixing the autoheader issue would mean updating _all_ AC_DEFINEs in > configure.ac, and there are many of them.) > Of course, but generally, you end up fixing a problem in the distro first, when e.g. an incompatibility arises, possibly with new gettext. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a2b0043db4a6af646e549feb68b50c3dccff7708 commit a2b0043db4a6af646e549feb68b50c3dccff7708 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-04-26 11:48:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-04-26 12:55:33 +0000 www-client/w3m: fix gettext with eautoreconf Thanks-to: David Seifert <soap@gentoo.org> Bug: https://bugs.gentoo.org/785760 Signed-off-by: Sam James <sam@gentoo.org> ...w3m-0.5.3_p20210102-fix-configure-gettext.patch | 26 ++++++++++++++++++++++ www-client/w3m/w3m-0.5.3_p20210102.ebuild | 6 ++--- 2 files changed, 29 insertions(+), 3 deletions(-) This has reintroduced the autoheader issue, though: * Running 'autoheader -I m4' ... [ !! ] > This has reintroduced the autoheader issue, though:
I'd suggest setting AT_NOEAUTOHEADER="yes" as a workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb7ce6a2fdee051faeef6cb236d8791c62973a1a commit bb7ce6a2fdee051faeef6cb236d8791c62973a1a Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-04-26 15:06:34 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-04-27 07:25:45 +0000 www-client/w3m: Don't run autoheader because it fails Bug: https://bugs.gentoo.org/785760 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Ulrich Müller <ulm@gentoo.org> www-client/w3m/w3m-0.5.3_p20210102.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |