Created attachment 310967 [details] build log media-gfx/geeqie-1.0-r2 build fails on `make install` stage: /usr/bin/install: cannot create regular file ‘/mnt/1/p/tmp/portage/media-gfx/geeqie-1.0-r2/image//usr/share/doc/geeqie-1.0-r2/html/AdvancedFeatures.html’: No such file or directory ...
Created attachment 310969 [details] emerge --info output
media-gfx/geeqie-1.0-r1 is fine so it is either the patch or the autoreconf. I'll see if I can narrow it down to one of them. +src_prepare() { + epatch "${FILESDIR}"/${P}-lfs_support.patch + eautoreconf +} +
(In reply to comment #2) > media-gfx/geeqie-1.0-r1 is fine so it is either the patch or the autoreconf. > I'll see if I can narrow it down to one of them. I commented out the patch and it fails with this message. Then I did a diff on the original source against the one generated by autoreconf. The uncompressed diff is half a meg o_O. Look like they have not run their automagic for a while.. (Or I am wrong which is more likely). Anyway, the culprit is the autoreconf so a simple mask =media-gfx/geeqie-1.0-r2 for anyone hit by this should do the trick untill the maintainer sorts it out.
I've been hit by this as well. What about completely masking the ebuild in the tree or just removing it?
Apparently some changes in autotools (since I added -r2 in tree) broke the build system Debian worked around this by creating the html directory before the make install... (see the "See Also" link), but I would rather add a proper fix. And sorry for the delay on this bug, I still do not have a working Gentoo box at the moment, so cannot study it and fix. In the meantime, -r1 should work fine (and only lacks large file support)
(In reply to comment #5) > Apparently some changes in autotools (since I added -r2 in tree) broke the > build system > > And sorry for the delay on this bug, I still do not have a working Gentoo > box at the moment, so cannot study it and fix. In the meantime, -r1 should > work fine (and only lacks large file support) So it looks like a parallel install issue then. I'll see if I can make it install correctly with MAKEOPTS="-j1". This *may* be a reasonable workaround for the time being. If you have patches I can try.. I am happy to test.
From what I read from Debian and Fedora comments, the mkdir commmand is simply skipped (or disappeared), maybe an old macro or something like that? Anyway, to workaround this, I think adding this as the first line of src_install() should do the trick: dodir /usr/share/doc/${PF}/html
Thanks, Bernard Cafarelli, the one-liner does the trick.
Created attachment 313931 [details, diff] Be compatible with >=automake-1.11.4 Geeqie's doc/Makefile.am does this: # empty help_DATA just installs the directory help_DATA = And the automake 1.11 NEWS file mentions a "long-standing bug" fixed in 1.11.4: - An empty declaration of a "foo_PRIMARY" don't cause anymore the generated install rules to create an empty $(foodir) directory; Which is exactly what geeqie is relying on, and its shipped Makefile.in files are generated by automake 1.10, so that fits. The attached patch removes the no longer functional empty help_DATA, and has geeqie's install-data-hook just create its target directory before it tries to use it, using the same mkdir command that automake would run for us if help_DATA was non-empty. This makes the build work for me.
(In reply to comment #9) > Created attachment 313931 [details, diff] [details, diff] > Be compatible with >=automake-1.11.4 <snip> > The attached patch removes the no longer functional empty help_DATA, and has > geeqie's install-data-hook just create its target directory before it tries > to use it, using the same mkdir command that automake would run for us if > help_DATA was non-empty. This makes the build work for me. Confirmed installing and running with this patch.
Thanks for the explanation and patch, marienz! That is some side-effect Added to tree in -r2. I'm plannig a -r3 with some patches grabbed from Debian and Fedora, but first let's fix compilation for those patiently waiting here
