Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
On Fri, 25 Jul 2025 01:01:13 +0200 Andreas Beckmann wrote: On 7/25/25 00:46, Santiago Vila wrote: > Ok, assuming none of the two packages will try to enter testing > before the release, I leave this to Timo, then. This needs to be fixed for trixie, we need the newer cccl in trixie otherwise we have an unsupported cccl+nvidia-cuda-toolkit combination in trixie. (Due to use of a wrong variable name the dependency was not bumped automatically in nvidia-cuda-toolkit, otherwise I would have noticed this earlier.) Thanks, Santiago, for catching this, and thanks, Andreas, for looking up the fix. I'm going to apply it and request a last minute unblock. If that does not work out, I agree with Andreas that it is more important for trixie to have a functional nvidia toolchain than stdgpu. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
On 7/25/25 00:46, Santiago Vila wrote: Ok, assuming none of the two packages will try to enter testing before the release, I leave this to Timo, then. This needs to be fixed for trixie, we need the newer cccl in trixie otherwise we have an unsupported cccl+nvidia-cuda-toolkit combination in trixie. (Due to use of a wrong variable name the dependency was not bumped automatically in nvidia-cuda-toolkit, otherwise I would have noticed this earlier.) Andreas
Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
retitle 1109841 stdgpu-contrib: FTBFS in forky/sid with new cccl affects 1109841 = thanks Ok, assuming none of the two packages will try to enter testing before the release, I leave this to Timo, then. Thanks a lot!
Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
Control: reassign -1 src:stdgpu-contrib 1.3.0+git20220507.32e0517-2 Control: tag -1 upstream fixed-upstream patch Control: forwarded -1 https://github.com/stotko/stdgpu/issues/407 On 7/24/25 22:18, Santiago Vila wrote: Package: src:cccl Version: 2.3.2-1 During a rebuild of all packages in unstable, package src:stdgpu-contrib failed to build from source: CMake Error at cmake/Findthrust.cmake:17 (math): math cannot parse the expression: "200302 // macro expansion with ## requires this to be a single value / 10": syntax error, unexpected exp_DIVIDE (9). Call Stack (most recent call first): src/stdgpu/CMakeLists.txt:7 (find_package) "The original regular replacement does not consider the possibility that THRUST_VERSION may be followed by comments." https://github.com/stotko/stdgpu/pull/408 https://github.com/stotko/stdgpu/commit/1f0b2d51718692ec9046fe1b36173a591c611bdb.patch Andreas
Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
El 24/7/25 a las 22:18, Santiago Vila escribió: If the broken package is fixed and the build-depends is updated to include libcu++-dev (>= 2.3.2-1) (and the other ones), I guess it would be ok to reassign this to src:stdgpu-contrib and consider the issue fixed. No, that would not work... The updated dependency would ensure that stdgpu-contrib will only migrate if cccl does as well, but not the opposite. So, still unsure about the best way to handle this (maybe if everybody was using autopkgtests this would happen less often, but naturally that takes time and effort). Thanks.
Bug#1109841: cccl: makes stdgpu-contrib to FTBFS
Package: src:cccl Version: 2.3.2-1 Severity: serious Control: affects -1 src:stdgpu-contrib Dear maintainer: During a rebuild of all packages in unstable, package src:stdgpu-contrib failed to build from source: CMake Error at cmake/Findthrust.cmake:17 (math): math cannot parse the expression: "200302 // macro expansion with ## requires this to be a single value / 10": syntax error, unexpected exp_DIVIDE (9). Call Stack (most recent call first): src/stdgpu/CMakeLists.txt:7 (find_package) I did a debbisect and this is what I found: bisection finished successfully last good timestamp: 20250720T202733Z first bad timestamp: 20250721T022532Z the following packages differ between the last good and first bad timestamp: libcu++-dev 2.2.0-5 -> 2.3.2-1 libcub-dev 2.2.0-5 -> 2.3.2-1 libthrust-dev 2.2.0-5 -> 2.3.2-1 At this point of the release cycle, I'm not sure about the best way to handle these kinds of bugs. If the broken package is fixed and the build-depends is updated to include libcu++-dev (>= 2.3.2-1) (and the other ones), I guess it would be ok to reassign this to src:stdgpu-contrib and consider the issue fixed. In the meantime, I'm filing this bug mainly to ensure that the updated build-dependency does not propagate to testing before the broken package. Thanks.
