Nvidia driver and KDE 4 on 10.1-RELEASE

On 10.1-RELEASE, when installing using pkg, kde4 and nvidia-driver seem to be mutually exclusive.

Using pkg I installed nvidia-driver, then installed kde4. Then when I checked, it seemed that nvidia-driver was not installed, so I tried to install it again and got:

Code:
# pkg install nvidia-driver
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (2 conflicting)
Checking integrity... done (0 conflicting)
The following 11 packages will be affected (of 0 checked):

Installed packages to be REMOVED:
        kde-workspace-4.11.13
        kget-4.14.2
        kdenetwork-4.14.2
        kde-4.14.2
        kdeartwork-4.14.2
        kdeplasma-addons-4.14.2_1
        ktux-4.14.2
        kdetoys-4.14.2
        libglesv2-9.1.7_3
        libEGL-9.1.7_4

New packages to be INSTALLED:
        nvidia-driver: 340.46

The operation will free 20 MB.

Proceed with this action? [y/N]:

I hope I'm just clueless and missing something.
 
No, they are not mutually exclusive. The conflict is between nvidia-driver and libglesv2 (or libEGL, or both. I don't remember correctly) because they install some file(s) in the same position.
You have to recompile x11/kde4-workspace without "OpenGL ES 2.0 support".
On my system this also solved the creation of kwin_opengl_test.core core dump file every time KDE starts.
 
Thanks for the help. I feel like I'm going down a rabbit hole now though, because when I do a make install in x11/kde4-workspace, I get an error with sphinx:

Code:
===>  Building for py27-sphinx-1.2.3
running build
running build_py
running egg_info
writing requirements to Sphinx.egg-info/requires.txt
writing Sphinx.egg-info/PKG-INFO
writing top-level names to Sphinx.egg-info/top_level.txt
writing dependency_links to Sphinx.egg-info/dependency_links.txt
writing entry points to Sphinx.egg-info/entry_points.txt
reading manifest file 'Sphinx.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'doc/_build'
writing manifest file 'Sphinx.egg-info/SOURCES.txt'
cd /usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib &&  /usr/bin/env PYTHONPATH=/usr/ports/textproc/py-sphinx/work/Sphinx-1.2.3/build/lib:/usr/local/lib/python2.7/site-packages  /usr/local/bin/python2.7 -m sphinx.pycode.pgen2.driver -c 'import load_grammar'
/usr/local/bin/python2.7: No module named docutils
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/textproc/py-sphinx
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/devel/cmake
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/cmake
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/kde4-workspace
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/kde4-workspace
 
Code:
/usr/local/bin/python2.7: No module named docutils

My x11/kde4-workspace doesn't have any python dependencies, maybe because I have not activated "Python plasmoids support" in make config.

If I activate support to Python plasmoids and I get this:
Code:
kde4-workspace# make missing
x11/plasma-scriptengine-python
textproc/xmlto
So probably you don't have these ports installed.

Alternatively, try to install x11/kde4-workspace using portmaster(8)
 
I did turn plasmoids on, but just now I went back and did a make rmconfig followed by a make config-recursive to deselect it, and when I make it now, it still wants sphinx, apparently as a dependency for cmake. Portmaster, huh?

Code:
===>  Extracting for cmake-3.0.2
=> SHA256 Checksum OK for cmake-3.0.2.tar.gz.
===>  Patching for cmake-3.0.2
===>  Applying FreeBSD patches for cmake-3.0.2
/bin/rm -f /usr/ports/devel/cmake/work/cmake-3.0.2/Help/manual/cmake-gui.1.rst
===>   cmake-3.0.2 depends on executable: sphinx-build - not found
===>    Verifying install for sphinx-build in /usr/ports/textproc/py-sphinx
 
http://www.freshports.org/textproc/py-sphinx/


/usr/ports/devel/cmake/Makefile

Code:
.if !defined(CMAKE_MODULES)
OPTIONS_DEFINE= DOCS
OPTIONS_SUB=  yes
HAS_CONFIGURE=  yes

BUILD_DEPENDS=  sphinx-build:${PORTSDIR}/textproc/py-sphinx
LIB_DEPENDS=  libcurl.so:${PORTSDIR}/ftp/curl \
  libexpat.so:${PORTSDIR}/textproc/expat2
RUN_DEPENDS=  ${LOCALBASE}/share/cmake/Modules/CMake.cmake:${PORTSDIR}/devel/c
make-modules
.endif

If you turn the option docs off, it should not need textproc/py-sphinx
 
No, they are not mutually exclusive. The conflict is between nvidia-driver and libglesv2 (or libEGL, or both. I don't remember correctly) because they install some file(s) in the same position.
You have to recompile x11/kde4-workspace without "OpenGL ES 2.0 support".
On my system this also solved the creation of kwin_opengl_test.core core dump file every time KDE starts.

This is a bit of a pain for folks just using pkg and prebuilt packages. Is there likely to be a better solution?
 
I stumbled into the same issue. Just for fun, I tried to install PC-BSD on the same hardware (HP Z620), and it runs without a glitch. Since I would prefer to run a pure FreeBSD system, I am trying to see how PC-BSD is installing FreeBSD with x11/nvidia-driver/ and KDE to remedy that while using mostly pkg. But I am afraid one would need to resort to ports-mgmt/poudriere.
 
I don't think so. Packages are built using default options, and by default x11/kde4-workspace has "OpenGL ES 2.0 support" enabled.
Oh, just for the record, the kwin_opengl_test.core file is still present :(

The same issue was discussed on ports@ about a year ago and the conclusion was that there's no better solution available until X11 evolves to have a proper plugin system for things like OpenGL and allows vendors to provide their own implementations in a way that they don't conflict with the default implementations.
 
I ended up downloading the drivers from the nvidia website and just installing those. Worked great. No annoying dependencies.
 
I ended up downloading the drivers from the nvidia website and just installing those. Worked great. No annoying dependencies.

Your possibly setting yourself up for problems down the road by installing the nvidia drivers in this fashion.

This issue was fixed a few weeks ago as per PR 194924. I would assume the packages have been updated by now to include this fix.
 
Back
Top