| Summary: | dev-libs/libgdata-0.17.9-r1 : Makefile:<snip>: *** missing separator. Stop. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, leio, leonchik1976 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge-info.txt
dev-libs:libgdata-0.17.9-r1:20190515-235040.log emerge-history.txt environment etc.portage.tbz2 logs.tbz2 temp.tbz2 Patch adding libgdata-0.17.9-r2.ebuild and Makefile patch |
||
new issue? Created attachment 576846 [details]
emerge-info.txt
Created attachment 576848 [details]
dev-libs:libgdata-0.17.9-r1:20190515-235040.log
Created attachment 576850 [details]
emerge-history.txt
Created attachment 576852 [details]
environment
Created attachment 576854 [details]
etc.portage.tbz2
Created attachment 576856 [details]
logs.tbz2
Created attachment 576858 [details]
temp.tbz2
Created attachment 577518 [details, diff]
Patch adding libgdata-0.17.9-r2.ebuild and Makefile patch
This patch fixes the issue.
Patch did not work here... >>> Emerging (1 of 3) dev-libs/libgdata-0.17.9-r1::gentoo * Fetching files in the background. * To view fetch progress, run in another terminal: * tail -f /var/log/emerge-fetch.log * libgdata-0.17.9.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking libgdata-0.17.9.tar.xz to /var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work >>> Source unpacked in /var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work >>> Preparing source in /var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work/libgdata-0.17.9 ... * Applying libgdata-0.17.8-disable-demos.patch ... [ ok ] * Applying libgdata-0.17.9-r2.patch ... [ ok ] * User patches applied. * Disabling deprecation warnings ... [ ok ] * Running eautoreconf in '/var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work/libgdata-0.17.9' ... * Running intltoolize --automake --copy --force ... [ ok ] * Running gtkdocize --copy ... [ ok ] * Running libtoolize --install --copy --force --automake ... [ ok ] * Running aclocal --install -I m4 ... [ ok ] * Running autoconf --force ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --force-missing ... [ ok ] * Running elibtoolize in: libgdata-0.17.9/ * Running elibtoolize in: libgdata-0.17.9/build-aux/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.3 patch ... ...snip.... config.status: creating docs/reference/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing po/stamp-it commands >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work/libgdata-0.17.9 ... make -j5 Makefile:4495: *** missing separator. Stop. * ERROR: dev-libs/libgdata-0.17.9-r1::gentoo failed (compile phase): * emake failed For me patch also didn't work I got the patch file to work. However, I am new to Gentoo and encountered this issue during my first install. Here is what I did: - Saved the patch to /usr/portage/makefile.patch - Ran 'patch -p1 < makefile.patch' inside same dir. - Ran 'ebuild libgdata-0.17.9-r2.ebuild manifest' from dev-libs/libgdata. Continued my emerge of gnome-base/gnome and the package successfully built and moved on. Not too sure --^ that is how the patch file was meant to be used, but that's how I got it to work. any news on this? (In reply to Mark Sanders from comment #12) > I got the patch file to work. However, I am new to Gentoo and encountered > this issue during my first install. Here is what I did: > > - Saved the patch to /usr/portage/makefile.patch > - Ran 'patch -p1 < makefile.patch' inside same dir. > - Ran 'ebuild libgdata-0.17.9-r2.ebuild manifest' from dev-libs/libgdata. > > Continued my emerge of gnome-base/gnome and the package successfully built > and moved on. > > Not too sure --^ that is how the patch file was meant to be used, but that's > how I got it to work. That works for me. Thanks! Having a patch within a patch, and then modifying the portage tree is a rather messy way of doing things. The way I got it to work is by extracting just the Makefile patch, and placing it here : /etc/portage/patches/dev-libs/libgdata/libgdata-0.17.9-fix-make-breakage.patch ... Wait a sec. This problem was already fixed by adding sys-devel/autoconf-archive as a dep. but upgrading to autoconf-archive-2019.01.06 broke it again. Take a look at bug 675006 (In reply to cyrillic from comment #15) > Having a patch within a patch, and then modifying the portage tree is a > rather messy way of doing things. Or a really convenient way for a Gentoo developer who will just have to run `git am` and push. (In reply to Denis Dupeyron from comment #17) > Or a really convenient way for a Gentoo developer who will just have to run > `git am` and push. I agree with that. I meant messy for the end user because the push has not taken place yet. Would be useful to CC autoconf-archive maintainers. Seems like a breakage there. Something went wrong with my CC, lets try that again :) base-system@ - why is the newer autoconf-archive breaking things? > The macro AX_CODE_COVERAGE was modified to use AX_ADD_AM_MACRO_STATIC,
> and thus unfortunately usage was changed.
Wonder what other consumers are broken.
So autotools.eclass eaclocal is ever so "helpfully" parsing out the ACLOCAL_AMFLAGS from libgdata Makefile.am file, which includes --install; so it calls aclocal with --install -I m4, which overwrites the older m4/ax_code_coverage.m4 that libgdata itself ships fine, thus breaking everything due to the incompatible changes in that copy of newer version. Albeit libgdata autogen.sh also passes --install manually. (In reply to cyrillic from comment #16) > ... Wait a sec. This problem was already fixed by adding > sys-devel/autoconf-archive as a dep. but upgrading to > autoconf-archive-2019.01.06 broke it again. > > Take a look at bug 675006 That was the wrong fix by me, apparently. The fix seemed obvious, due to not having an autoconf-archive dep before, but in reality they were there in m4/, but newer autoconf-archive macros started to get used instead, which I hadn't upgraded to. Just it didn't get re-opened or re-reported until May again. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eb482f5626e53bdee63ff4a45c982db493ccde21 commit eb482f5626e53bdee63ff4a45c982db493ccde21 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-06-19 20:14:33 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-06-19 20:16:06 +0000 dev-libs/libgdata: fix build with newer autoconf-archive present Workaround eaclocal overwriting the older ax_code_coverage.m4 provided by the tarball, stopping breakage when newer autoconf-archive is present on the system. Due to all necessary ax_*.m4 being present in the tarball, the autoconf-archive build dep is also unnecessary (and now it doesn't update the copies either anymore if it's present on the build system). Closes: https://bugs.gentoo.org/686082 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> .../files/libgdata-0.17.9-ax2019-compat.patch | 20 ++++++++++++++++++++ dev-libs/libgdata/libgdata-0.17.9-r1.ebuild | 4 ++-- 2 files changed, 22 insertions(+), 2 deletions(-) |
>>> Compiling source in /var/tmp/portage/dev-libs/libgdata-0.17.9-r1/work/libgdata-0.17.9 ... make -j1 Makefile:4495: *** missing separator. Stop. * ERROR: dev-libs/libgdata-0.17.9-r1::gentoo failed (compile phase): * emake failed * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_libressl_20190510-220703 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-9.1.0 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) [3] ruby26 (with Rubygems) * Available Rust versions: [1] rust-1.34.1 * [2] rust-bin-1.34.2 emerge -qpvO dev-libs/libgdata [ebuild N ] dev-libs/libgdata-0.17.9-r1 USE="crypt introspection -gnome-online-accounts -static-libs -test -vala"