FS#24608 - [luxrender] wants to install "nvidia-utils" and conflicts with libgl from ati

Attached to Project: Community Packages
Opened by Justus (schnorchelkatze) - Monday, 06 June 2011, 21:55 GMT
Last edited by Lukas Jirkovsky (6xx) - Thursday, 09 June 2011, 17:09 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Lukas Jirkovsky (6xx)
Imanol Celaya (ornitorrincos)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

When updating Luxrender from version 0.7.1 to 0.8 pacman tries to delete libgl (required by ati-dri / driver for my laptop graphics-card)because of the dependancy to luxrays and install nvidia-utils for opencl-support(?). This is Nonsense (i guess) because then my ati-driver won't work anymore!?


Additional info:
* luxrays 0.8-1
* luxrender 0.8-1

Steps to reproduce:
1. install the needed open-source-ati driver (needed for your graphics card!)
2. try to install luxrender (depends on luxrays)
3. pacman wants to replace libgl with nvidia-utils
This task depends upon

Closed by  Lukas Jirkovsky (6xx)
Thursday, 09 June 2011, 17:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in luxrender 0.8-2
Comment by Jelle van der Waa (jelly) - Tuesday, 07 June 2011, 09:08 GMT
The problem is glew, which wants mesa,
|--mesa
+--nvidia-utils provides libgl
+--nvidia-utils provides libcl
Comment by Ionut Biru (wonder) - Tuesday, 07 June 2011, 09:14 GMT
luxrays should drop libcl dependency. only proprietary drivers have support for that
Comment by Lukas Jirkovsky (6xx) - Tuesday, 07 June 2011, 09:47 GMT
it shouldn't because it won't work without libcl.
Comment by Lukas Jirkovsky (6xx) - Tuesday, 07 June 2011, 09:52 GMT
It seems that luxrender can work without luxrays, but it still needs libOpenCL.so
Comment by Lukas Jirkovsky (6xx) - Tuesday, 07 June 2011, 10:00 GMT
@Justus: you should give amdstream (https://aur.archlinux.org/packages.php?ID=21933) a try. It provides libcl for AMD.

@All: anyone wants to bring amdstream to repos? I don't want to maintain it, because I have nvidia or intel everywhere so I can't test it.
Comment by Ionut Biru (wonder) - Tuesday, 07 June 2011, 10:04 GMT
just make luxrays optdepends and add a proper description.
Comment by Lukas Jirkovsky (6xx) - Tuesday, 07 June 2011, 10:16 GMT
@ionut: unfortunately it won't solve anything, because luxrender itself requires libcl too.

Can someone try whether luxrender works with amdstream package I mentioned earlier? If it works, it would be nice to bring amdstream into a repository so libcl is available for AMD users too. However there still will be a problem with OSS drivers, which doesn't support OpenCL at all.
Comment by Justus (schnorchelkatze) - Tuesday, 07 June 2011, 11:50 GMT
Luxrender works with latest amdstream from AUR (just tested it). Although now it has no GPU-rendering support - smallppmgpu just shows me my dualcore processor available for rendering.
Comment by Imanol Celaya (ornitorrincos) - Tuesday, 07 June 2011, 14:48 GMT
luxrays can be compiled without opencl by executing cmake -DLUXRAYS_DISABLE_OPENCL=1 (I haven't tested it though as my system doesn't boot right now)

my proposal is not making dependencies from libcl until there exist at least an open source cpu implementation, as that way we can guarantee that opencl is present in the system(as you can now take for granted opengl is present through mesa even if there's no gpu installed)

edit: changed the cmake line, seems it needs the =1 thing
Comment by Lukas Jirkovsky (6xx) - Wednesday, 08 June 2011, 07:08 GMT
ornitorrincos: great find. However I don't have time to try it now because I need to prepare for exam tomorrow. I hope I can update it by the Friday.
Comment by orbisvicis (orbisvicis) - Wednesday, 08 June 2011, 16:42 GMT
I disagree, luxrays has no purpose in existing aside from providing OpenCL-accelerated (GPU) ray-intersection calculations.

+1 optdepends

Is it possible that luxrender is statically linked against luxrays, thus explaining the OpenCL dependency? (both packages ship with static libraries, which is probably a bug in and of itself)
Comment by Imanol Celaya (ornitorrincos) - Wednesday, 08 June 2011, 19:38 GMT
well, luxrays right now has has the raytracer algorithms(hence the name ;P) the difference with the cmake definition is if it also compiles the opencl algorithms or not, the one that's right now on the repo does so, although with the definition shouldn't do it, as for optdepends, it's statically compiled that that's how it's designed to be upstream so not sure about considering it a bug, although it could be considered to be submitted upstream as a suggestion to link dynamically and allow both opencl and non-opencl versions to coexist.

Loading...