gnome-extra/yelp-2.22.1 fails to install (after compiling successfully) with the following error creating a symlink: ... rm -f /var/tmp/portage/gnome-extra/yelp-2.22.1/image//usr/bin/gnome-help && \ ln -s yelp /var/tmp/portage/gnome-extra/yelp-2.22.1/image//usr/bin/gnome-help make[3]: Nothing to be done for `install-data-am'. ln: creating symbolic link `/var/tmp/portage/gnome-extra/yelp-2.22.1/image//usr/bin/gnome-help': No such file or directory make[3]: *** [install-exec-local] Error 1 ... The attempted upgrade was performed from an existing installation of gnome-extra/yelp-2.22.0 on an ~amd64 installation of Gentoo. Reproducible: Always Steps to Reproduce: 1. Upgrade from yelp-2.22.0 by using emerge -av1 yelp Actual Results: Compiled OK. Error during portage installation phase (see attached build.log) Expected Results: Installation should have succeeded. See attached output of emerge --info.
Created attachment 149365 [details] build.log of yelp-2.22.1
Created attachment 149366 [details] output of emerge --info
Can't even replicate this one now... hmmm... closed.
Well maybe I'm wrong about not being able to reproduce this bug. I just tried the following procedures (I start with yelp-2.22.1 installed): 1. emerge --unmerge yelp 2. emerge -1 =yelp-2.22.0 3. emerge -1 =yelp-2.22.0 4. emerge -1 yelp 5. emerge -1 yelp 6. emerge --unmerge yelp 7. emerge -1 yelp 8. emerge --unmerge yelp 9. emerge -1 =yelp-2.22.0 10. emerge -uND world (2) failed to create the symlink but all other commands were OK. I can't accurately reproduce this problem so will leave it as WORKSFORME unless someone else encounters similar issues (reopen this bug).
I'm thinking this could be a parallel make issue. Could you try again (running emerge -1 yelp in a loop) with an unset MAKEOPTS? Thanks
I've confirmed gnome-extra/yelp-2.22.1-r1 emerges / installs fine after removing parallel make option ("-j3"), whereas before I had the identical errors above.
I've tried "emerge -1 yelp" in a loop with both MAKEOPTS=-j3 and with MAKEOPTS undefined. After about 20 tries I haven't been able to reproduce this bug. Ashu, have you worked out a way to reproduce this potential bug more consistently?
(In reply to comment #7) > > Ashu, have you worked out a way to reproduce this potential bug more > consistently? > Ya - I've just reproduced both the installation failure and the successful emerge / install - only change is to enable / disable parallel make, respectively. I'm attaching the two build logs + the emerge --info for both
Created attachment 151398 [details] Failed emerge install w/ parallel make enabled
Created attachment 151399 [details] Successful emerge / install with parallel make disabled
Created attachment 151400 [details] "emerge --info" with parallel make enabled (resulting in failed emerge / install)
Created attachment 151401 [details] "emerge --info" with parallel make disabled (resulting in successful emerge / install)
BTW - my USE options: ashu@liberte ~ $ grep yelp /etc/portage/package.use gnome-extra/yelp firefox beagle xulrunner lzma
Could you try putting something like this in the ebuild's src_unpack() sed -e "s/install-exec-local:/install-exec-hook:/" -i src/Makefile.am eautomake Thanks
(In reply to comment #14) > Could you try putting something like this in the ebuild's src_unpack() > > sed -e "s/install-exec-local:/install-exec-hook:/" -i src/Makefile.am > eautomake > > Thanks > Yep - that works well: with parallel make enabled, adding the above line to the ebuild enables a successful emerge / install. I'll attach the two build logs + the updated ebuild
Created attachment 151488 [details] Build log of failed emerge / install
Created attachment 151490 [details] Build log of successful emerge / install w/ above suggested ebuild modification
Created attachment 151491 [details] Modified ebuild for gnome-extra/yelp-2.22.1-r1 that allows successful emerge / install with parallel make enabled
(In reply to comment #18) > Created an attachment (id=151491) [edit] > Modified ebuild for gnome-extra/yelp-2.22.1-r1 that allows successful emerge / > install with parallel make enabled > is this patch going to be accepted by gnome herd ?
(In reply to comment #19) > is this patch going to be accepted by gnome herd ? 1) I wrote that patch 2) I'm part of the Gnome Herd Therefore, I would say that there's a high probability that the Gnome Herd will accept that patch... Sarcasm aside, we work on Gentoo on our free time, so please understand that we don't necessarily fix all bugs the very minute they come in. Thanks PS, bug reported upstream too
(In reply to comment #20) > (In reply to comment #19) > > is this patch going to be accepted by gnome herd ? > > 1) I wrote that patch > 2) I'm part of the Gnome Herd > I didn't know that . You should agree with me that there are a lot of devs in gentoo and I could not know them all and I should not know about what devs belongs to what herd. >[...] > Sarcasm aside, we work on Gentoo on our free time, so please understand that we > don't necessarily fix all bugs the very minute they come in. > I didn't mean that , sorry for posting too soon > Thanks > > PS, bug reported upstream too >
(In reply to comment #21) > I didn't mean that , sorry for posting too soon No harm done ;) Fixed in portage without a revbump. Thanks everyone. @Gilles, I quietly removed the AT_M4DIR="${AT_M4DIR} m4" env before calling eautoreconf because the autotools eclass picks it up automatically from Makefile.in.
this affects current stable (2.20.0) too. can you backport this fix?
