!eWOErHSaiddIbsUNsJ:nixos.org

NixOS CUDA

290 Members
CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda57 Servers

Load older messages


SenderMessageTime
12 Mar 2025
@ss:someonex.netSomeoneSerge (back on matrix) * Well, ok. Let's swap the order. And for the packageSets variable and for evalPackageSet they actually don't seem to be doing anything useful. The packageSets there really only serves the purpose of automatically identifying the cuda package sets, so let's rename it to cudaPackageSets as, I think, you've already suggested. Let's not introduce the extra variable for evalPackageSet nor for its image, but instead just use packagePlatforms directly in jobs = let in HERE // { ... = linux; } 01:24:42
@ss:someonex.netSomeoneSerge (back on matrix)wdyt?01:24:45
@ss:someonex.netSomeoneSerge (back on matrix)If we want to add any other package set well we just add another function call there 🤷01:25:52
@ss:someonex.netSomeoneSerge (back on matrix) Ah we maybe want to give a name to mapTestOn . packagePlatforms? 01:28:28
@ruroruro:matrix.orgruro

How about

  # Package sets to evaluate whole
  # Derivations from these package sets are selected based on the value
  # of their meta.{hydraPlatforms,platforms,badPlatforms} attributes
  autoPackageSets = builtins.filter (lib.strings.hasPrefix "cudaPackages") (builtins.attrNames pkgs);
  autoPackagePlatforms = lib.genAttrs autoPackageSets (pset: packagePlatforms pkgs.${pset});

  # Explicitly select additional packages to also evaluate
  # The desired platforms must be set explicitly here
  explicitPackagePlatforms = (
    # This comment prevents nixfmt from changing the indentation level, lol
    {
      blah = linux;
      ...
    });
  
  # Explicitly specified platforms take precedence over the platforms
  # automatically inferred by release-lib.packagePlatforms
  allPackagePlatforms = lib.recursiveUpdate autoPackagePlatforms explicitPackagePlatforms;
  jobs = mapTestOn allPackagePlatforms;
01:36:27
@ruroruro:matrix.orgruroAlso, if you have any ideas on how to remove the "load-bearing comment" without changing the indentation - be my guest)))01:38:26
@ruroruro:matrix.orgruro *

How about

  # Package sets to evaluate whole
  # Derivations from these package sets are selected based on the value
  # of their meta.{hydraPlatforms,platforms,badPlatforms} attributes
  autoPackageSets = builtins.filter (lib.strings.hasPrefix "cudaPackages") (builtins.attrNames pkgs);
  autoPackagePlatforms = lib.genAttrs autoPackageSets (pset: packagePlatforms pkgs.${pset});

  # Explicitly select additional packages to also evaluate
  # The desired platforms must be set explicitly here
  explicitPackagePlatforms =
    # This comment prevents nixfmt from changing the indentation level, lol
    {
      blah = linux;
      ...
    };
  
  # Explicitly specified platforms take precedence over the platforms
  # automatically inferred by release-lib.packagePlatforms
  allPackagePlatforms = lib.recursiveUpdate autoPackagePlatforms explicitPackagePlatforms;
  jobs = mapTestOn allPackagePlatforms;
01:41:00
@ruroruro:matrix.orgruro *

How about

  # Package sets to evaluate whole
  # Derivations from these package sets are selected based on the value
  # of their meta.{hydraPlatforms,platforms,badPlatforms} attributes
  autoPackageSets = builtins.filter (lib.strings.hasPrefix "cudaPackages") (builtins.attrNames pkgs);
  autoPackagePlatforms = lib.genAttrs autoPackageSets (pset: packagePlatforms pkgs.${pset});

  # Explicitly select additional packages to also evaluate
  # The desired platforms must be set explicitly here
  explicitPackagePlatforms =
    # This comment prevents nixfmt from changing the indentation level, lol
    {
      blah = linux;
      ...
    };
  
  # Explicitly specified platforms take precedence over the platforms
  # automatically inferred in autoPackagePlatforms
  allPackagePlatforms = lib.recursiveUpdate autoPackagePlatforms explicitPackagePlatforms;
  jobs = mapTestOn allPackagePlatforms;
01:41:55
@ss:someonex.netSomeoneSerge (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:matrix.orgAdam Neverwas set their display name to Adam Neverwas.14:27:37
17 Mar 2025
@koutensky:matrix.nesad.fit.vutbr.czMichal 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
@koutensky:matrix.nesad.fit.vutbr.czMichal 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
@koutensky:matrix.nesad.fit.vutbr.czMichal 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@i.me:matrix.org joined the room.16:10:28
18 Mar 2025
@connorbaker:matrix.orgconnor (he/him) 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
@koutensky:matrix.nesad.fit.vutbr.czMichal 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 it15:04:09
@koutensky:matrix.nesad.fit.vutbr.czMichal Koutenskýlooking at the python package, the listed maintainer only had one commit for it in 202215:05:33
@justbrowsing:matrix.orgKevin Mittman (UTC-8)TRT 10.3 is pretty old18:17:09
@stick:matrix.orgstick 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:matrix.orgstickfor example I updated TRT to 10.8 there (and there is already 10.9, yay)18:36:04
@stick:matrix.orgstickbtw, zdravim do Brna :D18:36:36
@koutensky:matrix.nesad.fit.vutbr.czMichal 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.nix18:37:19
@koutensky:matrix.nesad.fit.vutbr.czMichal Koutenskýi guess i'll try building master and possibly move our stuff off 24.1118:37:42
@koutensky:matrix.nesad.fit.vutbr.czMichal Koutenskýa Brno zdraví naspäť :D18:37:53
@stick:matrix.orgsticki 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 guess18:38:45
@koutensky:matrix.nesad.fit.vutbr.czMichal Koutenskýwell the issue is with the preUnpack, which tries to get the wheel by a wrong name, at leas in my case18:39:26
@stick:matrix.orgsticktry it with unstable - if it works great - if it does not work, please open an issue and tag me in the comment18:41:26
@koutensky:matrix.nesad.fit.vutbr.czMichal Koutenskýyup, will do that18:41:59
@koutensky:matrix.nesad.fit.vutbr.czMichal 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 build19:34:29
@justbrowsing:matrix.orgKevin Mittman (UTC-8)often the build number field is dropped from release label version (also # of fields is subject to change)19:38:17

Show newer messages


Back to Room ListRoom Version: 9