| 12 Mar 2025 |
 SomeoneSerge (back on matrix) | ruro: I'm ok with that, I just thought applying mapAttrs packagePlatforms is not such a complex thing that we really need to be so verbose about it | 08:50:34 |
|  Adam Neverwas set their display name to Adam Neverwas. | 14:27:37 |
| 17 Mar 2025 |
 Michal Koutenský | Any ideas why tensorrt from 24.11 is failing to build? I downloaded and imported the sources into nix store as instructed, but it doesn't want to unpack it.
$ nix log /nix/store/nxmsg8d5w8rljhigv5yaqhrsblzvdndi-python3.12-tensorrt-10.3.0.26.drv
warning: The interpretation of store paths arguments ending in `.drv` recently changed. If this command is now failing try again with '/nix/store/nxmsg8d5w8rljhigv5yaqhrsblzvdndi-python3.12-tensorrt-10.3.0.26.drv^*'
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing wheel setup hook
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing auto-add-driver-runpath-hook
Using autoAddDriverRunpath
Sourcing fix-elf-files.sh
Running phase: unpackPhase
@nix { "action": "setPhase", "phase": "unpackPhase" }
tar: TensorRT-10.3.0.26/python/tensorrt-10.3.0.26-cp312-none-linux_x86_64.whl: Not found in archive
tar: Exiting with failure status due to previous errors
| 12:29:56 |
| Michal Koutenský | The wheel in the archive is called tensorrt-10.3-cp312-none-linux_x86_64.whl, so not sure what's going on | 12:31:21 |
| Michal Koutenský | * The wheel in the archive is called tensorrt-10.3.0-cp312-none-linux_x86_64.whl, so not sure what's going on | 15:14:31 |
|  @i.me:matrix.org joined the room. | 16:10:28 |
| 18 Mar 2025 |
 connor (burnt/out) (UTC-8) | Michal Koutenský: try manually unpacking and verifying the tarball has it at the same path its expecting; also try adding an echo with the current directory in the derivation to make sure the script is printing where its searching from | 14:58:01 |
| Michal Koutenský | the tarball has it without the last version number (.26). i managed to get it working yesterday by modifying the unpack phase to extract the correct wheel. is there a chance nvidia changed how the tarball contents look and no one caught it yet? if i had a different tarball i assume the hashes wouldn't match with what is at https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/development/cuda-modules/tensorrt/releases.nix, but since the build process needs manual intervention i assume there's not much automation for it nor do many people use it | 15:04:09 |
| Michal Koutenský | looking at the python package, the listed maintainer only had one commit for it in 2022 | 15:05:33 |
 Kevin Mittman (EOY sleep) | TRT 10.3 is pretty old | 18:17:09 |
 stick | Michal Koutenský: i recommend you to use CUDA stuff from master/nixpkgs-unstable - many fixes go there and are not being backported to stable (24.11) | 18:35:39 |
| stick | for example I updated TRT to 10.8 there (and there is already 10.9, yay) | 18:36:04 |
| stick | btw, zdravim do Brna :D | 18:36:36 |
| Michal Koutenský | does the python package build though? i checked master (and issues/prs) yesterday and there doesn't seem to be anything significant https://github.com/NixOS/nixpkgs/commits/master/pkgs/development/python-modules/tensorrt/default.nix | 18:37:19 |
| Michal Koutenský | i guess i'll try building master and possibly move our stuff off 24.11 | 18:37:42 |
| Michal Koutenský | a Brno zdraví naspäť :D | 18:37:53 |
| stick | i updated the package here https://github.com/NixOS/nixpkgs/commit/1609398c9def5a31bb7951c284cf21f45b981b39
the python-module is just a simple wrapper that does not need changes i guess | 18:38:45 |
| Michal Koutenský | well the issue is with the preUnpack, which tries to get the wheel by a wrong name, at leas in my case | 18:39:26 |
| stick | try it with unstable - if it works great - if it does not work, please open an issue and tag me in the comment | 18:41:26 |
| Michal Koutenský | yup, will do that | 18:41:59 |
| Michal Koutenský | so, unstable with 10.8.0.43 builds and the tarball has the full 4 part version number in the filenames, 10.3.0.26 has a 3 part version number which breaks the build | 19:34:29 |
| Kevin Mittman (EOY sleep) | often the build number field is dropped from release label version (also # of fields is subject to change) | 19:38:17 |
| Michal Koutenský | then this is not really reliable is it? https://github.com/NixOS/nixpkgs/blob/59b1aef59071cae6e87859dc65de973d2cc595c0/pkgs/development/python-modules/tensorrt/default.nix#L33 | 19:40:09 |
| stick | well it is not, but also i think it is a bug in nvidia packaging, so hopefully it won't happen anymore | 19:59:10 |
| stick | looking at pypi - https://pypi.org/project/tensorrt/#history - it seems they are following the scheme where they add the build number to the pypi version | 20:00:20 |
| stick | might be worth adding code that uses only a.b.c instead of a.b.c.d for versions <10.8 | 20:00:57 |
| Michal Koutenský | i tried listing the archive and grepping for cpXY and tensorrt- but that's quite slow unfortunately | 20:01:51 |
| stick | looking at versions of tensorrt and pypi - only these two are affected:
8.6.1.6 vs 8.6.1
10.3.0.26 vs 10.3.0 | 20:03:39 |
| stick | because 8.5.3.1 uses the same version in pypy (including the .1) and older versions are not present on pypi at all | 20:04:37 |
| Michal Koutenský | guess i can submit a PR that conditionally changes the filename for those two | 20:06:15 |
