Created attachment 287487 [details] Log of the failed patch >>> Preparing source in /var/tmp/portage/net-libs/webkit-gtk-1.4.3-r300/work/webkit-1.4.3 ... * Applying webkit-gtk-1.4.3-underlinking.patch ... * A dry-run of patch command succeeded, but actually * applying the patch failed! * Failed Patch: webkit-gtk-1.4.3-underlinking.patch ! * ( /usr/portage/net-libs/webkit-gtk/files/webkit-gtk-1.4.3-underlinking.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/net-libs/webkit-gtk-1.4.3-r300/temp/webkit-gtk-1.4.3-underlinking.patch.out * ERROR: net-libs/webkit-gtk-1.4.3-r300 failed (prepare phase): * Failed Patch: webkit-gtk-1.4.3-underlinking.patch! * * Call stack: * ebuild.sh, line 91: Called src_prepare * environment, line 3197: Called epatch '/usr/portage/net-libs/webkit-gtk/files/webkit-gtk-1.4.3-underlinking.patch' * environment, line 1861: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; ----------------------------------------------------------------------------------------------------------------------------------------- Attached is the patch.out file mentioned in the emerge output
You may not need webkit-gtk-1.4.3-r300 any longer. Try doing: emerge -p --depclean webkit-gtk-1.4.3-r300 and check if it's selected for removal.
(In reply to comment #1) Wouldn't it be webkit-gtk-1.4.2-r300 since the 1.4.3 package isn't even installed due to the error when trying to emerge? In that case these packages depend on the r300 slot: * These packages depend on net-libs/webkit-gtk-1.4.2-r300: dev-python/pywebkitgtk-1.1.8 (>=net-libs/webkit-gtk-1.1.15:2) gnome-extra/gnome-web-photo-0.10.2 (>=net-libs/webkit-gtk-1.1.23:2) media-gfx/gimp-2.7.3 (webkit ? net-libs/webkit-gtk:2) media-sound/rhythmbox-0.13.3 (webkit ? >=net-libs/webkit-gtk-1.1.7:2) media-video/handbrake-0.9.5_p4210 (gtk ? net-libs/webkit-gtk) www-client/xxxterm-1.518 (net-libs/webkit-gtk) The package is slotted, I have two slots installed: (2) 1.4.3-r200 (3) 1.4.2-r300 The package in slot (3) is marked for upgrade but the upgrade is what fails to build.. The upgrade being 1.4.3-r300. If I was going to try to eliminate a slot with depclean, shouldn't it be the older one in slot (2) which is r200? I don't think removing the package in slot 3 is going to keep things fixed, this isn't in my world, so something has definitely pulled it in by the slot..
Confirmed. Removing webkit-gtk-1.4.2-r300 does indeed do the trick. It also allows me to remove a few other packages. :-) Of course, that workaround doesn't fix webkit-gtk-1.4.3-r300...
I cannot reproduce this at all, please attach full build.log and provide "emerge --info" output
Created attachment 287541 [details] build.log
Created attachment 287543 [details] emerge --info
Same problem here ~AMD86. I will attach the build.log and emerge --info
Created attachment 287551 [details] build.log
Created attachment 287553 [details] emerge --info
Created attachment 287593 [details] build.log
Created attachment 287595 [details] emerge --info Same problem here. My build.log and "emerge --info" attached. Hope it helps to debug the problem.
Created attachment 287597 [details] webkit-gtk-1.4.3-underlinking.patch.out Maybe the output of the patch command may help too. It is quoted in the build.log.
Not even a compile test before committing ebuilds in portage. Nice
(In reply to comment #13) > Not even a compile test before committing ebuilds in portage. Nice That is not true, it compiles fine for me and I compiled it before committing (as I ALWAYS do)
What I don't understand yet is why it works for me, maybe we have different patch versions? I have sys-devel/patch-2.5.9
(In reply to comment #15) > What I don't understand yet is why it works for me, maybe we have different > patch versions? I have sys-devel/patch-2.5.9 Good guess. I've 2.6.1 installed: Installed versions: 2.6.1(13:13:39 05/31/11)(-static -test)
I can confirm reverting to patch-2.5.9 works when patch-2.6.1 does not.
(In reply to comment #17) Interesting, as we might have uncovered a bug with sys-devel/patch that could possibly be the true culprit of this issue .
Odd thing is I'd been using patch 2.6.1 since december 2010 but recently recompiled (august 24) fyi
okay recompile comment is irrelevant as my chroot copy was compiled in december with no rebuild since also fails
The patch fails with =sys-devel/patch-2.5.9-r1 and =sys-devel/patch-2.6.1 and it succeds with =sys-devel/patch-2.5.9
actually the problem is that upstream has already applied the patch to the sources .. checking the tarball .. revealled this ... thus patch fails .. solution drop patch for this version ..
I'm not sure if it's a bad version of patch, but looking at the output and the patch itself: It tries to add "$(XRENDER_CFLAGS) \" around line 5111 in Source/WebCore/GNUmakefile.am.. presumably where the `libWebCore_la_CPPFLAGS` Makefile variable is defined. 1) that definition actually ends at line 5087 and `EXTRA_DIST` is being defined on 5111 and 2) "$(XRENDER_CFLAGS) \" is already in the definition of `libWebCore_la_CPPFLAGS` in that file. So it seems to me that particular (part of the) patch is not needed.
Looks like my previous post was a bit too late.
note: webkit-gtk-1.4.3-r200 lacks the 1.4.3-underlinking patch and thus compiles fine with patch-2.6.1 (as it never sees the patch)
original patch was with bug ..371751 using gold linker ..
+ 24 Sep 2011; Pacho Ramos <pacho@gentoo.org> webkit-gtk-1.4.3-r300.ebuild, + -files/webkit-gtk-1.4.3-underlinking.patch: + underlinking patch is not needed as it was already applied by upstream, bug + #384181 by Lance Poore, Hilco, Albert W. Hopkins, S.Holzbach and maby others. + You are true, it is not needed as upstream already included it. But I am really surprised with sys-devel/patch-2.5.9 exiting with status 0 even when patch cannot be applied and, even worse, it behaving differently than newer versions. We should probably stabilize latest patch version as it fixes this problem and also, after cleaning older versions, we no longer would have patch versions behaving differently
(In reply to comment #27) Are you saying the ebuild has been corrected upstream to omit the patch? If not have any of you tried the ebuild in a local overlay and removing the epatch for webkit-gtk-1.4.3-underlinking.patch? Seems the patch isn't needed with this source version of webkit, and also seems it is true that Patch needs to be stabalized to prevent these types of failures or possibly worse ones.
yes compiled fine
(In reply to comment #28) > (In reply to comment #27) > Are you saying the ebuild has been corrected upstream to omit the patch? If > not have any of you tried the ebuild in a local overlay and removing the epatch > for webkit-gtk-1.4.3-underlinking.patch? Seems the patch isn't needed with > this source version of webkit, and also seems it is true that Patch needs to be > stabalized to prevent these types of failures or possibly worse ones. Yes, it no longer applies that patch as, as confirmed some time ago, all its changes are already applied in upstream sources
(In reply to comment #30) I don't think the ebuild has been fixed in upstream yet, I will have to change this status back to Confirmed instead of Resolved fix, as it still fails with same error for me, and just sync'd portage before testing..
patience .. the tree and mirrors take a while to update ... :)
(In reply to comment #32) > patience .. the tree and mirrors take a while to update ... :) I just assumed that they had been updated since you had mentioned previously in your comment: "confirmed some time ago". So I was taking your word on it :) It's all good though, I edited the ebuild in a local overlay to omit the patch, and tested it, all goes well. So as soon as I see the ebuild updated in portage I will mark it fixed again. Thanks everyone for helping get this resolved
Please don't mark this as fixed until patch maintainers comment here about differences between patch behavior depending on versions (and stable one exiting ok even not really applying the patch)
(In reply to comment #34) > Please don't mark this as fixed until patch maintainers comment here about > differences between patch behavior depending on versions (and stable one > exiting ok even not really applying the patch) OK I won't change it then, but shouldn't the sys-devel/patch issue be filed under a separate bug instead of this one? This one shouldn't still be open because of an issue that exists with another package (sys-devel/patch) should it? I'd just think that if this ebuild has been fixed to compile on either version of patch (even the one that doesn't work properly), that it should be marked fixed and then an issue with patch exiting with 0 status even when it fails to patch should be filed under a new bug regarding sys-devel/patch in particular. But that's just my opinion. I will let a maintainer change the status of this as they seem to be fit.
(In reply to comment #34) > Please don't mark this as fixed until patch maintainers comment here about > differences between patch behavior depending on versions (and stable one > exiting ok even not really applying the patch) bug 146660, arch and ~arch sys-devel/patch versions are different and have been for years.
(In reply to comment #36) > (In reply to comment #34) > > Please don't mark this as fixed until patch maintainers comment here about > > differences between patch behavior depending on versions (and stable one > > exiting ok even not really applying the patch) > > bug 146660, arch and ~arch sys-devel/patch versions are different and have been > for years. CLosing then as fixed, but, can you (or vapier) explain me the reasons to not stabilize latest 2.6.1 version? I don't know where to find IRC logs referred in https://bugs.gentoo.org/show_bug.cgi?id=146660#c5 Thanks
that was specific to 2.5.9-r1. some fixes have gone into upstream post 2.6.1 and i wish they'd release a 2.6.2, but maybe 2.6.1 itself is fine.
Then, if the tree is building and applying all patches fine with sys-devel/patch-2.6.1, I would try to stabilize that version... but feel free to ask for it when you feel it's ready :)
