The ebuild webkit-gtk-2.4.7 contains a faulty check for the version of the x11-drivers/nvidia-drivers package. The check in question is in line 304 of the ebuild: has_version '>=x11-drivers/nvidia-drivers-304.123' && [...] This check is wrong because it precludes the ebuild from being emerged on systems with an up-to-date nvidia-driver. It is designed to prevent webkit from being emerged on systems with older nvidia-drivers (there is some bug in webkit that is triggered in that scenario) and therefore the inequality should be '<='. Previosuly (in older version of this ebuild), the atom was given with equality instead of the >=. To fix this I suggest to adapt the atom to correctly reflect that older packages, not newer ones, are the problem.
nvidia_check() { if [[ ${MERGE_TYPE} != "binary" ]] && use introspection && has_version '>=x11-drivers/nvidia-drivers-304.123' && OK. Is that the correct version to check for? [[ $(eselect opengl show 2> /dev/null) = "nvidia" ]] then eerror "${PN} freezes while compiling if x11-drivers/nvidia-drivers-325.* is" But you just said 304.123? eerror "used as the system OpenGL library." eerror "You can either update to >=nvidia-drivers-331.13, or temporarily select" And now everyone should UPGRADE THEIR HARDWARE for yet another version of nvidia-drivers? And 331.13 somehow fixes this issue, you think? eerror "Mesa as the system OpenGL library:" eerror " # eselect opengl set xorg-x11" You could do that in pkg_setup() instead of failing and revert it at the end of the build.
Also, referring to bug #463960 with its 154 comments (and counting) and a ton of conflicting information is not going to enlighten anyone. You should probably write a HOWTO on the wiki about this.
No, we cannot switch implementations of anything at build time, because anything the user would do during the 1 to many hours depending on hardware would use the switched libraries. If user did it on purpose, then it is fine, but if build system starts to switch things in his back, this is not acceptable. Also, how would you recover from build failures ? Next run would have no idea what to select anymore. As for the exact version, this is the usual problem with nvidia drivers, you never really know when things get fixed due to conflicting statements from users, etc.
(In reply to Gilles Dartiguelongue from comment #3) > As for the exact version, this is the usual problem with nvidia drivers, you > never really know when things get fixed due to conflicting statements from > users, etc. You could have asked, like, let's see, I don't know, wait a second, the maintainer of x11-drivers/nvidia-drivers for guidance?
What if we did, but the check still sucks. This was long ago though. Before you became maintainer of the driver it seems.
So if you can figure out something better, feel free to help. Also, please note that webkit-gtk-2.6 is coming with a different build system and all these checks were removed. It is currently in the gnome overlay and will be moved in the next few days to the tree.
(In reply to Gilles Dartiguelongue from comment #3) > No, we cannot switch implementations of anything at build time, because > anything the user would do during the 1 to many hours depending on hardware > would use the switched libraries. If user did it on purpose, then it is > fine, but if build system starts to switch things in his back, this is not > acceptable. Also, how would you recover from build failures ? Next run would > have no idea what to select anymore. You're setting yourself up for failure with this type of reasoning: 1) You assume the user has an optimal (GUI) user experience during the build of one of the biggest nasties in the tree in terms of system resources. 2) You assume that this optimal user experience is degraded only or primarily by newly launched applications not having hardware acceleration during the build. 3) You assume building webkit-gtk will fail anyhow, which has the side-effect of leaving hardware acceleration disabled until the user corrects this.
(In reply to Gilles Dartiguelongue from comment #5) > What if we did, but the check still sucks. > This was long ago though. Before you became maintainer of the driver it > seems. Now you're bury the thing in the past? Also, you're wrong.
(In reply to Gilles Dartiguelongue from comment #6) > So if you can figure out something better, feel free to help. > Also, please note that webkit-gtk-2.6 is coming with a different build > system and all these checks were removed. It is currently in the gnome > overlay and will be moved in the next few days to the tree. That's not the issue as people are building a newly stabilised webkit-gtk right now.
I am also running into this problem. I've got =x11-drivers/nvidia-drivers-346.22 installed and the ebuild is breaking after telling me a possible solution is to install >=nvidia-drivers-331.13 If x11-drivers/nvidia-drivers-325.* is indeed causing problems, it seems like the ebuild is just missing an upper bound on the version check. We might add something like this into the if statement: has_version '>=x11-drivers/nvidia-drivers-304.123' && has_version '<=x11-drivers/nvidia-drivers-331.13'
Same problem here. I have an optimal (GUI) user experience and am updating world. webkit-gtk fails to update from 2.4.4-r1 to 2.4.7-r200 with the following error: * webkit-gtk freezes while compiling if x11-drivers/nvidia-drivers-325.* is * used as the system OpenGL library. * You can either update to >=nvidia-drivers-331.13 or <irrelevant> I'm using x11-drivers/nvidia-drivers-340.65
(In reply to Gilles Dartiguelongue from comment #6) > So if you can figure out something better, feel free to help. Something like this. nvidia_workaround() { if [[ ${MERGE_TYPE} != "binary" ]] && use introspection && has_version x11-drivers/nvidia-drivers WEBKIT_GTK_OPENGL_OLD=$(eselect opengl show 2> /dev/null) case "${WEBKIT_GTK_OPENGL_OLD}" in nvidia) eselect opengl set xorg-x11;; esac } pkg_postinst() { if [[ "${WEBKIT_GTK_OPENGL_OLD}" && "x$(eselect opengl show 2> /dev/null)" != "x${WEBKIT_GTK_OPENGL_OLD}" ]]; then eselect opengl set "${WEBKIT_GTK_OPENGL_OLD}" fi }
(In reply to Jeroen Roovers from comment #12) > (In reply to Gilles Dartiguelongue from comment #6) > > So if you can figure out something better, feel free to help. > > Something like this. > > nvidia_workaround() { > if [[ ${MERGE_TYPE} != "binary" ]] && > use introspection && > has_version x11-drivers/nvidia-drivers > WEBKIT_GTK_OPENGL_OLD=$(eselect opengl show 2> /dev/null) > case "${WEBKIT_GTK_OPENGL_OLD}" in > nvidia) eselect opengl set xorg-x11;; > esac > } > > pkg_postinst() { > if [[ "${WEBKIT_GTK_OPENGL_OLD}" && "x$(eselect opengl show 2> > /dev/null)" != "x${WEBKIT_GTK_OPENGL_OLD}" ]]; then > eselect opengl set "${WEBKIT_GTK_OPENGL_OLD}" > fi > } For reasons already explained here, this is not acceptable. I'd much rather die on nvidia users than switch things in their back and get funky reports like "after running emerge @world, my desktop is broken/3d is slow/etc".
(In reply to Gilles Dartiguelongue from comment #13) > For reasons already explained here, this is not acceptable. I'd much rather > die on nvidia users than switch things in their back and get funky reports > like "after running emerge @world, my desktop is broken/3d is slow/etc". Er, emerge @world just failed. You should expect bug reports about that, not about the aftermath. As it currently is, emerge @world has already failed (see bug #533128) because your solution to the problem sucks. Also, you can warn users in pkg_setup() that you're temporarily disabling hardware acceleration. There, fixed.
(In reply to Jeroen Roovers from comment #14) > (In reply to Gilles Dartiguelongue from comment #13) > > For reasons already explained here, this is not acceptable. I'd much rather > > die on nvidia users than switch things in their back and get funky reports > > like "after running emerge @world, my desktop is broken/3d is slow/etc". > > Er, emerge @world just failed. You should expect bug reports about that, not > about the aftermath. sure > As it currently is, emerge @world has already failed (see bug #533128) > because your solution to the problem sucks. sure > Also, you can warn users in pkg_setup() that you're temporarily disabling > hardware acceleration. There, fixed. You must really stop thinking about this solution, people just don't read these messages and/or forget about it and we do not want to create a state that must be remembered between two runs of your favorite package manager. These kind of problems have already been discussed on the gentoo-dev ml afaik without ever getting to a proper solution. The only hope I can see is some chat I caught from mgorny (iirc) who was working on making it possible to always use mesa for build and leave the user setup alone. That would be a good solution.
IMO best of worst ways to workaround this issue is use LD_LIBRARY_PATH hack as i suggest here: https://bugs.gentoo.org/show_bug.cgi?id=463960#c141 For <app-admin/eselect-opengl-1.3.0 it should prepend (as i remember) /usr/$(get_libdir)/opengl/xorg-x11 I don't like it cause a real bug is in sandbox (as i think), but it will just work for all users.
(In reply to Jeroen Roovers from comment #4) > (In reply to Gilles Dartiguelongue from comment #3) > > > As for the exact version, this is the usual problem with nvidia drivers, you > > never really know when things get fixed due to conflicting statements from > > users, etc. > > You could have asked, like, let's see, I don't know, wait a second, the > maintainer of x11-drivers/nvidia-drivers for guidance? Errr... all this comes from bug 463960 and, looking to its history, you are CCed there since 2013-10-10 and we all can see all the subsequent comments and see that nothing has been "hidden" to you :/
(In reply to Pacho Ramos from comment #17) > > > As for the exact version, this is the usual problem with nvidia drivers, you > > > never really know when things get fixed due to conflicting statements from > > > users, etc. > > > > You could have asked, like, let's see, I don't know, wait a second, the > > maintainer of x11-drivers/nvidia-drivers for guidance? > > Errr... all this comes from bug 463960 and, looking to its history, you are > CCed there since 2013-10-10 and we all can see all the subsequent comments > and see that nothing has been "hidden" to you :/ Bug #463960 comment #56 already gave you the answer. (It has nothing to do with any nvidia-drivers version, and everything with the OpenGL library symlinks.) Bug #463960 comment #124 underlined that. Meanwhile various people went off and added cruft to the webkit-gtk ebuilds based on versions of nvidia-drivers, mentioning other nvidia-drivers versions, issuing bad advice, and so on. With 156 comments and counting, it's a terrible example of how to respond to bug reports in general and you can't expect everyone (particularly maintainers of tangentially related packages) to read the important bits among all the me-toos, voodoo advice and well-intended but ill-devised solutions. Especially when you've gone against the advice of those maintainers every step along the way.
(In reply to Jeroen Roovers from comment #18) > and everything with the OpenGL library symlinks.) Bingo, problem found. Why exactly has the webkit-gtk maintainer not patched the build system to completely bypass the eselect system and build against the Mesa libs directly? That way the user could keep their system implementation set to nVidia, and webkit-gtk can stop failing with obscure errors. There's already an nvidia check function, if necessary the patch could only be applied when nvidia-drivers are found. In most scenarios, something like this would be the reason Portage has the concept of package blockers; however, there's too big of an overlap between people who absolutely need webkit-gtk and people who absolutely need nvidia-drivers for the one truly reasonable solution to be valid. I've been stuck on webkit-gtk-2.4.8 for a couple of months now because there was no indication I needed to disable something that's actually important in my case, and nvidia-drivers-346.35 has absolutely *not* solved a single thing, and neither has webkit-gtk-2.6.x (the build process still hangs and does nothing).
(In reply to Nicholas O'Connor from comment #19) > (In reply to Jeroen Roovers from comment #18) > > and everything with the OpenGL library symlinks.) > > Why exactly has the webkit-gtk maintainer not patched the build system to > completely bypass the eselect system and build against the Mesa libs > directly? That way the user could keep their system implementation set to > nVidia, and webkit-gtk can stop failing with obscure errors. You even do not understand cause of this problem but trying to blame webkit-gtk maintainer. This is not link-time problem
Latest ebuilds for 2.4.x look to work finally
