severity 739409 normal thanks On 18/02/2014 13:24, bastien ROUCARIES wrote: > Package: ocl-icd-libopencl1 > Version: 2.1.3-4 > Severity: serious > > Your symbols file is broken
We will discuss about this below > and allow to install non free package. This is by design. So, I downgraded this bug report for now. I will try to explain you the situation for this library and we will see if we must close this bug or fix something in the package. > 12:06:33) _rene_: libopencl-1.1-1) AND libopencl-1.1-1 itself?! > (12:07:04) _rene_: without looking at the source the former sounds like > dh_shlibdeps' result and the latter one bogus :) > (12:07:21) _rene_: oh, even better: > (12:07:43) jcristau: broucarie: i have no idea what you're trying to say > (12:08:22) _rene_: Depends: [...] libopencl-1.1-1 [!x32], libopencl1 [x32], > [...]. ocl-icd-libopencl1 | libopencl1 The mention of x32 seems strange to me here. Can you provide me more context so that I understand it (there is nothing about x32 in the source package). > (12:08:34) _rene_: that's umm. <no comment> > (12:09:18) jcristau: broucarie: the bug is in ocl-icd-libopencl1ls file is > broken and allow non free package during upgrade > (12:09:26) jcristau: its symbols file is fucked up > (12:12:37) broucarie: jcristau: How should I report it ? How do you know the > symbols file is fucked up ? > (12:13:16) jekhor a quitté le salon (quit: Ping timeout: 480 seconds) > (12:14:12) _rene_: by looking at it > (12:14:17) _rene_: libOpenCL.so.1 ocl-icd-libopencl1 #MINVER# | libopencl1 > (12:14:17) _rene_: | ocl-icd-libopencl1 #MINVER# | libopencl1, libopencl-1.1-1 > (12:14:28) _rene_: note the | libopencl1, libopencl-1.1-1 > (12:14:36) _rene_: which is those virtual packages... > (12:15:37) _rene_: and even the | libopencl1 in the fist line. and the third > (no idea what that means, need to look it up) is | ocl-icd-libopencl1 > #MINVER# | libopencl1, libopencl-1.2-1 > (12:16:01) _rene_: so yes, .symbols is broken, it should not magically allow > non-free packages > (12:16:08) _rene_: or virtual ones, for that matter Back to the background. First, read http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD It was written a few months ago and should probably be updated a bit but important information are present. For this bug report: * OpenCL is a norm written by a consortium: we have to deal with (bad) design of this consortium * OpenCL implementations are divided in several parts, mainly: * libOpenCL : the library applications link against (that load ICDs) * ICDs : real OpenCL drivers (to execute code on various hardware) libOpenCL is mainly a dispatcher of function calls to one or more ICDs * ICDs in Debian are all currently non-free. I hope to find time to finish the packaging of pocl (current state in collab-maint, help welcome) so that a free ICD is available * libOpenCL is provided by non-free OpenCL implementations (mainly AMD, NVidia and Intel) but also by an independant free project: ocl-icd * All libOpenCL library should be equivalent (ie work with any ICD) => all packaged ones in Debian provides/conflict with the virtual package libopencl1 but consortium's decision mitigate this (hence the existence of other virtual packages, see below) When you package a OpenCL application with the ocl-icd libOpenCL packaged in Debian, the goal is to depends on ocl-icd (free implementation) but also on virtual package as alternative, so that one can use other (non-free) implementation if they wish. Putting ocl-icd as the first part of the alternative is done so that, by default, apt and other tools will install the free alternative (if non-free is enabled) The symbol file is written like this (stripping out the comments, adding line numbers) : 1: libOpenCL.so.1 #PACKAGE# #MINVER# | libopencl1 2: | #PACKAGE# #MINVER# | libopencl1, libopencl-1.1-1 3: | #PACKAGE# #MINVER# | libopencl1, libopencl-1.2-1 4: (symver|optional)OPENCL_1.0 1.0 1 5: (symver|optional)OPENCL_1.1 1.0 1 6: (symver|optional)OPENCL_1.2 1.0 2 The first line is always added as dependencies in all programs linked with libOpenCL.so.1 (see #737731). If the consortium have done correct design, this would be all what is needed. We depends on the ocl-icd implementation or the virtual package for user that will want to switch to a non-free implementation. Line 2 and 3 are here to add the virtual packages libopencl-1.1-1 and libopencl-1.2-1. They are added when a program linked against libOpenCL use symbols from the 1.0 or 1.1 version of the OpenCL standard or the 1.2 version (2.0 will probably come soon). Note that correct design should have use different sonames. It would have been easiest as we have to deal with several binaries implementations (that have different versionning). Currently, ocl-icd, AMD and Intel (not packaged due to licence) provides an OpenCL library that deals with OpenCL version 1.0, 1.1 and 1.2. NVidia only provides symbols for 1.0 and 1.1. Their provides line reflect this: apt-cache show ocl-icd-libopencl1/unstable | grep Provides Provides: libopencl-1.1-1, libopencl-1.2-1, libopencl1 apt-cache show nvidia-libopencl1/unstable | grep Provides Provides: libopencl-1.1-1, libopencl1 apt-cache show amd-libopencl1/unstable | grep Provides Provides: libopencl-1.1-1, libopencl-1.2-1, libopencl-2.0-1, libopencl1 What is not solved by current dependencies is what occurs if an OpenCL application uses 1.2 symbols and try to load a 1.1 ICD. There is no standard way to know (by libOpenCL) which functions are supported by ICDs. Just looking at version standard is not enought (Intel ICD report 1.1 while most of 1.2 functions are implemented but not all of them...) So, do you think we can close this bug? Else, what is your precise problem? Regards, Vincent PS: the stange part "libopencl-1.1-1 [!x32], libopencl1 [x32]," in your logs perhaps comes from #737731 fixed in 2.1.3-3 for ocl-icd (but that needs a binary rebuild of all reverse dependencies to fix dependencies (and to allow installation of non-free implementation) > Thank > > Bastien > -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
