| Summary: | app-i18n/uim-1.7.3 - config.status: error: qt/chardict/po/Makefile.in.in was not created by intltoolize. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Muneyuki Noguchi <nogu.dev> |
| Component: | Current packages | Assignee: | CJK Team <cjk> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bircoph, nbowler, nogu.dev |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://archives.gentoo.org/gentoo-dev/msg_6478b733dcdfeebba75c40fa27b099bc.xml | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 413483 | ||
| Attachments: | build.log | ||
Created attachment 313081 [details]
build.log
I doubt your solution can get accepted, otherwise bug 416789 would have been resolved differently. Now one that could get accepted, would be something like cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in after eautoreconf. (In reply to comment #2) > I doubt your solution can get accepted, otherwise bug 416789 would have been > resolved differently. > > Now one that could get accepted, would be something like > cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in > cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in > > after eautoreconf. My patch may not be a good solution, but this bug isn't related to neither qt/chardict/po/ nor qt4/chardict/po/ because uim-1.8.0 doesn't have these directories and emerging uim-1.8.0 fails with the same error. Is there any other solution for this bug? FYI, configure.ac in uim uses IT_PROG_INTLTOOL. Bah, silly typo, it should have been:
cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/Makefile.in.in
cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/Makefile.in.in
or simply
cp ${S}/po/Makefile.in.in ${S}/qt/chardict/po/
cp ${S}/po/Makefile.in.in ${S}/qt4/chardict/po/
The problems lies in autopoint being significantly more creative in seaching for its Makefile.in.in than intltolize.
The directories are definitely there - your build log says so.
...oh, you mean in 1.8.0 ? But that would mean it's does not fail with *the same* error. (In reply to comment #6) > ...oh, you mean in 1.8.0 ? > But that would mean it's does not fail with *the same* error. Sorry, the reason why I failed to emerge uim 1.8.0 is that my Gentoo environment was broken. After I fixed my env, I could emerge uim 1.8.0 successfully. Anyway, app-i18n/uim-1.7.3 is still broken. autogen.sh in uim 1.7.3 may help Gentoo devs fix this bug. The autogen.sh in uim 1.7.3 is messy, http://uim.googlecode.com/svn/tags/uim-1.7.3/autogen.sh compared with that in uim 1.8.0: http://uim.googlecode.com/git-history/uim-1.8.0/autogen.sh Fix is in the tree.Thanks for your help. |
Recent changes in autotools.eclass have caused econf failure in app-i18n/uim-1.7.3. Reproducible: Always Steps to Reproduce: 1. emerge uim With the following patch, I could avoid this econf failure. --- autotools.eclass.org +++ autotools.eclass @@ -165,7 +165,6 @@ # Run all the tools before aclocal so we can gather the .m4 files. local i tools=( # <tool> <was run> <command> - gettext false "eautopoint --force" # intltool must come after autopoint. intltool false "autotools_run_tool intltoolize --automake --copy --force" libtool false "_elibtoolize --install --copy --force"