Build note for current Arch/CachyOS with cuda 13.2: if makepkg/paru is launched from an environment that has not sourced CUDA paths, CMake may fail to find nvcc. After fixing PATH, nvcc may still pick the system default GCC 16 and fail during CMakeCUDACompilerId with errors from /usr/include/c++/16.1.1/type_traits (e.g. char8_t/requires).

This worked for me:

env PATH=/opt/cuda/bin:$PATH CUDAToolkit_ROOT=/opt/cuda CUDAHOSTCXX=/usr/bin/g++-15 NVCC_CCBIN=/usr/bin/g++-15 CC=/usr/bin/gcc-15 CXX=/usr/bin/g++-15 makepkg -si

Same env also worked when driving the build through paru. Not a package bug as far as I can tell, just easy to hit on rolling systems where the default host compiler is newer than CUDA supports.

@medaminezghal The python-tensorrt package has the same version of the pkgname array of packages, which currently is 10.15.1.29, and that's what matters. If python-tensorrt would hypothetically have a version different than the other ones in the pkgname array, than that could be a case of inconsistency (even though I would still question if it would be in fact an inconsistency). The names you mentioned are not part of the pkgname array, but are listed in the provides array (we currently ship only 2 of the ones you mentioned). The ones listed in the provides array do not have restrictions in the relation the main pkgver, as a package can provide any other package in any version. And to avoid the heavy maintenance burden of creating a separate PKGBUILD for a very small 300kb package like tensorflow_quantization, coming a from a source file that is 7 GIGABYTES in size and that requires a complex build process, it is perfectly acceptable in my opinion to ship it through the provides array with its own version, which, as already explained, is not inconsistent.

@dbermond Every package under tools has different version from the provided package.

For example:

polygraphy has the version 0.49.27

trt-engine-explorer has the version 0.2.1

onnx-graphsurgeon has the version 0.5.9

polygraphy-extension-trtexec has the version 0.0.9

pytorch-quantization has the version 2.2.1

tensorflow-quantization has the version 0.2.0

@medaminezghal onnx-graphsurgeon still fails to build for me. Can you please point where in the package are these "tools with different versions" you mentioned?

@dbermond The issue mentioned by @sekubedabu has been fixed. Could you re-enable onnx-graphsurgeon again?

Also, Is installing tools with different versions than the given one in PKGBUILD file compatible with the Arch package guidelines?

For me, when there is different packages versions from the same source, I provide them as different packages with 2 PKGBUILD file.

@jholmer Independently of specifying or not the optional '#fragment' part in the source url, makepkg will always download the entire git repository and history, as shallow clones and sparse checkouts are not supported. The needed commit is to be picked by git itself (and not by makepkg) during the submodule initialization at prepare(), based on the parent repository internals. See working with git submodules in the ArchWiki.

Given that this is not a -git package, and this package takes a non-trivial amount of time to build, it is an undesirable behavior that AUR helpers like paru pull the latest commit of this package nearly daily. This is occurring because the submodules are pulled as the latest git commit. These should be locked to specific tags or commits to prevent this behavior.

Although I am receiving the same error "AttributeError: module 'onnx.helper' has no attribute 'float32_to_bfloat16'" as the linked issue that originated the PR, as far as I can see the git submodules are locked to earlier versions.

To move forward I commented out the building, providing, and packaging of "onnx-graphsurgeon" python package, after which the rest of the build was a success.