Message ID | cover.1630896250.git.iskarian@mgsn.dev |
---|---|
Headers | show |
Series | gnu: ocl-icd: Fix build. | expand |
Hi Sarah, > This fixes the build by updating one minor patch version to 2.2.13. (There > is a 2.3.1 available if that's preferable.) The package seems to have > permanently moved to Github, so this updates the location as well. note that I replaced this package on master with commit 4d1157fca7627c11672df0cd80fae4f4d27e2185 by the Khronos Group’s loader, which seemed the only maintained one. I didn’t know the project had moved to GitHub. Cheers, Lars
Hello, Lars-Dominik Braun <lars@6xq.net> writes: > Hi Sarah, > >> This fixes the build by updating one minor patch version to 2.2.13. (There >> is a 2.3.1 available if that's preferable.) The package seems to have >> permanently moved to Github, so this updates the location as well. > note that I replaced this package on master with commit > 4d1157fca7627c11672df0cd80fae4f4d27e2185 by the Khronos Group’s loader, > which seemed the only maintained one. I didn’t know the project had > moved to GitHub. Thanks for letting me know. Is the Khronos Group one better, such that there's no reason to keeping ocl-icd? (The README for ocl-icd states "[t]his package aims at creating an Open Source alternative to vendor specific OpenCL ICD loaders." Is the Khronos Group one similarly not vendor-specific?) If so, would you consider replacing ocl-icd with it in core-updates-frozen, since it and its dependents are currently broken? -- Sarah
Hi Sarah, > Is the Khronos Group one better, such that there's no reason to keeping > ocl-icd? (The README for ocl-icd states "[t]his package aims at > creating an Open Source alternative to vendor specific OpenCL ICD > loaders." Is the Khronos Group one similarly not vendor-specific?) I’m not really sure which one is “better”, but the Khronos-loader is vendor-independent like ocl-icd, so there’s no real reason to keep two imho. > If so, would you consider replacing ocl-icd with it in > core-updates-frozen, since it and its dependents are currently broken? Ludovic actually merged master into core-updates-frozen yesterday, so this issue should be resolved. Unfortunately the CI is going to take some time to catch up, so we don’t know yet whether that was successful. Cheers, Lars
Hi, Lars-Dominik Braun <lars@6xq.net> writes: > Hi Sarah, > >> Is the Khronos Group one better, such that there's no reason to keeping >> ocl-icd? (The README for ocl-icd states "[t]his package aims at >> creating an Open Source alternative to vendor specific OpenCL ICD >> loaders." Is the Khronos Group one similarly not vendor-specific?) > I’m not really sure which one is “better”, but the Khronos-loader > is vendor-independent like ocl-icd, so there’s no real reason to > keep two imho. > >> If so, would you consider replacing ocl-icd with it in >> core-updates-frozen, since it and its dependents are currently broken? > Ludovic actually merged master into core-updates-frozen yesterday, so > this issue should be resolved. Unfortunately the CI is going to take > some time to catch up, so we don’t know yet whether that was successful. > > Cheers, > Lars Since we already have opencl-icd-loader deprecating ocl-icd in the frozen branch (see commit 4d1157fca7), let's drop this change for now. Thank you, Closing. Maxim