rarias/jungle
2
0
Fork 3
Code Issues 57 Pull Requests 7 Actions Packages Projects Releases Wiki Activity

Remove cudainfo and amd-uprof from crossSet #210

Manually merged
abonerib merged 3 commits from abonerib/jungle:cross-filter into master 2025-10-31 11:27:37 +01:00
Conversation 2 Commits 3 Files Changed 3 +15 -7
abonerib commented 2025-10-28 17:39:06 +01:00
Collaborator
Copy Link

These two packages result in evaluation errors when building crossSet.riscv64 due to their dependencies meta.platforms:

in job ‘cross.riscv64.amd-uprof’:
error: derivation 'cross.riscv64.amd-uprof' does not have valid outputs: error:
              … while calling the 'getAttr' builtin
                at <nix/derivation-internal.nix>:50:17:
                  49|     value = commonAttrs // {
                  50|       outPath = builtins.getAttr outputName strict;
                    |                 ^
                  51|       drvPath = strict.drvPath;

              … while calling the 'derivationStrict' builtin
                at <nix/derivation-internal.nix>:37:12:
                  36|
                  37|   strict = derivationStrict drvAttrs;
                    |            ^
                  38|

              (stack trace truncated; use '--show-trace' to show the full, detailed trace)

              error: Package ‘clang-rocm-18.0.0-4182046534deb851753f0d962146e5176f648893’ in /nix/store/zk8v61cpk1wprp9ld5ayc1g5fq4pdkwv-source/pkgs/development/compilers/llvm/common/clang/default.nix:27 is not available on the requested hostPlatform:
                hostPlatform.config = "riscv64-unknown-linux-gnu"
                package.meta.platforms = [
                  "x86_64-linux"
                ]
                package.meta.badPlatforms = [ ]
              , refusing to evaluate.

              a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
                 for a single invocation of the nix tools.

                   $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

                 Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                       then pass `--impure` in order to allow use of environment variables.

              b) For `nixos-rebuild` you can set
                { nixpkgs.config.allowUnsupportedSystem = true; }
              in configuration.nix to override this.

              c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
                { allowUnsupportedSystem = true; }
              to ~/.config/nixpkgs/config.nix.

in job ‘cross.riscv64.cudainfo’:
error: derivation 'cross.riscv64.cudainfo' does not have valid outputs: error:
              … while calling the 'getAttr' builtin
                at <nix/derivation-internal.nix>:50:17:
                  49|     value = commonAttrs // {
                  50|       outPath = builtins.getAttr outputName strict;
                    |                 ^
                  51|       drvPath = strict.drvPath;

              … while calling the 'derivationStrict' builtin
                at <nix/derivation-internal.nix>:37:12:
                  36|
                  37|   strict = derivationStrict drvAttrs;
                    |            ^
                  38|

              (stack trace truncated; use '--show-trace' to show the full, detailed trace)

              error: Package ‘cuda_cuobjdump-12.8.90’ in /nix/store/zk8v61cpk1wprp9ld5ayc1g5fq4pdkwv-source/pkgs/development/cuda-modules/generic-builders/manifest.nix:324 is not available on the requested hostPlatform:
                hostPlatform.config = "riscv64-unknown-linux-gnu"
                package.meta.platforms = [
                  "aarch64-linux"
                  "x86_64-linux"
                ]
                package.meta.badPlatforms = [
                  "aarch64-linux"
                  "x86_64-linux"
                ]
              , refusing to evaluate.

              a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
                 for a single invocation of the nix tools.

                   $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

                 Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                       then pass `--impure` in order to allow use of environment variables.

              b) For `nixos-rebuild` you can set
                { nixpkgs.config.allowUnsupportedSystem = true; }
              in configuration.nix to override this.

              c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
                { allowUnsupportedSystem = true; }
              to ~/.config/nixpkgs/config.nix.
These two packages result in evaluation errors when building `crossSet.riscv64` due to their dependencies meta.platforms: ``` in job ‘cross.riscv64.amd-uprof’: error: derivation 'cross.riscv64.amd-uprof' does not have valid outputs: error: … while calling the 'getAttr' builtin at <nix/derivation-internal.nix>:50:17: 49| value = commonAttrs // { 50| outPath = builtins.getAttr outputName strict; | ^ 51| drvPath = strict.drvPath; … while calling the 'derivationStrict' builtin at <nix/derivation-internal.nix>:37:12: 36| 37| strict = derivationStrict drvAttrs; | ^ 38| (stack trace truncated; use '--show-trace' to show the full, detailed trace) error: Package ‘clang-rocm-18.0.0-4182046534deb851753f0d962146e5176f648893’ in /nix/store/zk8v61cpk1wprp9ld5ayc1g5fq4pdkwv-source/pkgs/development/compilers/llvm/common/clang/default.nix:27 is not available on the requested hostPlatform: hostPlatform.config = "riscv64-unknown-linux-gnu" package.meta.platforms = [ "x86_64-linux" ] package.meta.badPlatforms = [ ] , refusing to evaluate. a) To temporarily allow packages that are unsupported for this system, you can use an environment variable for a single invocation of the nix tools. $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake, then pass `--impure` in order to allow use of environment variables. b) For `nixos-rebuild` you can set { nixpkgs.config.allowUnsupportedSystem = true; } in configuration.nix to override this. c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add { allowUnsupportedSystem = true; } to ~/.config/nixpkgs/config.nix. in job ‘cross.riscv64.cudainfo’: error: derivation 'cross.riscv64.cudainfo' does not have valid outputs: error: … while calling the 'getAttr' builtin at <nix/derivation-internal.nix>:50:17: 49| value = commonAttrs // { 50| outPath = builtins.getAttr outputName strict; | ^ 51| drvPath = strict.drvPath; … while calling the 'derivationStrict' builtin at <nix/derivation-internal.nix>:37:12: 36| 37| strict = derivationStrict drvAttrs; | ^ 38| (stack trace truncated; use '--show-trace' to show the full, detailed trace) error: Package ‘cuda_cuobjdump-12.8.90’ in /nix/store/zk8v61cpk1wprp9ld5ayc1g5fq4pdkwv-source/pkgs/development/cuda-modules/generic-builders/manifest.nix:324 is not available on the requested hostPlatform: hostPlatform.config = "riscv64-unknown-linux-gnu" package.meta.platforms = [ "aarch64-linux" "x86_64-linux" ] package.meta.badPlatforms = [ "aarch64-linux" "x86_64-linux" ] , refusing to evaluate. a) To temporarily allow packages that are unsupported for this system, you can use an environment variable for a single invocation of the nix tools. $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake, then pass `--impure` in order to allow use of environment variables. b) For `nixos-rebuild` you can set { nixpkgs.config.allowUnsupportedSystem = true; } in configuration.nix to override this. c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add { allowUnsupportedSystem = true; } to ~/.config/nixpkgs/config.nix. ```
abonerib added 3 commits 2025-10-28 17:39:07 +01:00
Set amd-uprof platforms to x86_64-linux only 9f740ec234
Add meta to cudainfo a13a4e66a6
Filter out packages by platform from crossSet
All checks were successful
CI / build:cross (pull_request) Successful in 6s
Details
CI / build:all (pull_request) Successful in 20s
Details
97e81b2f91
rarias reviewed 2025-10-30 11:05:58 +01:00
overlay.nix Outdated
@@ -111,0 +112,4 @@
genCross = platform:
# filter out packages by meta.platforms
filterAttrs (_: meta.availableOn final.pkgsCross.${platform}.stdenv.hostPlatform)
final.pkgsCross.${platform}.bsc.pkgsTopLevel;
rarias commented 2025-10-30 11:05:58 +01:00
Owner
Copy Link

IIUC this is adding packages with cross = false (or not set). Not sure if we want to keep both crossSet and crossList the same. In that case, using canCrossCompile may be handy.

In any case, I would place genCross before crossSet so it is defined before referenced.

IIUC this is adding packages with `cross = false` (or not set). Not sure if we want to keep both crossSet and crossList the same. In that case, using canCrossCompile may be handy. In any case, I would place genCross before crossSet so it is defined before referenced.
abonerib commented 2025-10-30 11:56:37 +01:00
Author
Collaborator
Copy Link

You are correct, I think crossSet should be all the packages that should theoretically be possible to cross-compile (opt-out) and crossList should the subset that we care about and are used in the CI so we don't introduce regressions (opt-in).

From hydra, I can monitor crossSet status and keep track of why some packages fail to cross compile and work on fixing them. I have a branch which fixes mpich, once that is fixed, only clangOmpss2, tagaspi, mcxx and paraver will remain broken.

You are correct, I think `crossSet` should be all the packages that should theoretically be possible to cross-compile (opt-out) and `crossList` should the subset that we care about and are used in the CI so we don't introduce regressions (opt-in). From hydra, I can monitor `crossSet` status and keep track of why some packages fail to cross compile and work on fixing them. I have a branch which fixes mpich, once that is fixed, only clangOmpss2, tagaspi, mcxx and paraver will remain broken.
rarias commented 2025-10-30 13:05:41 +01:00
Owner
Copy Link

I would like to keep the simple idea that either cross-compilation for a package works (for the pinned commit) and is maintained with cross=true or is broken (even if its is not).

I assume with hydra you will be testing newer commits, which will add substantial maintenance burden, and currently, many extra packages. Do we want to make the set of packages tested by hydra be larger than the ones where we have cross=true? Wouldn't make more sense to use the same set for both?

I would like to keep the simple idea that either cross-compilation for a package works (for the pinned commit) and is maintained with `cross=true` or is broken (even if its is not). I assume with hydra you will be testing newer commits, which will add substantial maintenance burden, and currently, many extra packages. Do we want to make the set of packages tested by hydra be larger than the ones where we have `cross=true`? Wouldn't make more sense to use the same set for both?
abonerib commented 2025-10-30 16:35:02 +01:00
Author
Collaborator
Copy Link

I assume with hydra you will be testing newer commits

Yes, but, right now I only track select repos (and have excluded cross-compilation entirely for the rolling tests)

Do we want to make the set of packages tested by hydra be larger than the ones where we have cross=true?

Currently, I use hydra to determine what should be put in cross=true and fix any low-hanging fruit.

I think we can wait until after nixpkgs 25.11, and then decide what to do for each package.

That being said, hydra caches build failures, so there is little overhead in having a "big" crossSet since most of the time the derivations won't change.

> I assume with hydra you will be testing newer commits Yes, but, right now I only track select repos (and have excluded cross-compilation entirely for the rolling tests) > Do we want to make the set of packages tested by hydra be larger than the ones where we have `cross=true`? Currently, I use hydra to determine what should be put in `cross=true` and fix any low-hanging fruit. I think we can wait until after nixpkgs 25.11, and then decide what to do for each package. That being said, hydra caches build failures, so there is little overhead in having a "big" crossSet since most of the time the derivations won't change.
rarias commented 2025-10-31 10:52:01 +01:00
Owner
Copy Link

Okay, then fine for me.

Okay, then fine for me.
rarias marked this conversation as resolved
abonerib force-pushed cross-filter from 97e81b2f91 to 3beae1f019 2025-10-30 11:55:49 +01:00 Compare
abonerib added the cross label 2025-10-30 12:26:09 +01:00
rarias approved these changes 2025-10-31 10:54:17 +01:00
rarias force-pushed cross-filter from 3beae1f019 to 7989779c8f 2025-10-31 11:22:08 +01:00 Compare
abonerib manually merged commit 7989779c8f into master 2025-10-31 11:27:37 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
rarias
Labels
Clear labels
bug
ceph
ci
config
cross
hw
io
kernel
mpi
net
nix
ops
repair
slurm
No Label cross
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
abonerib arocanon varcila rarias
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rarias/jungle#210
Delete Branch "abonerib/jungle:cross-filter"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?