rarias/jungle
2
0
Fork 3
Code Issues 61 Pull Requests 11 Actions Packages Projects 1 Releases Wiki Activity

Set strictDeps=true on our top level packages #192

Manually merged
abonerib merged 9 commits from enableStrictDeps into master 2026-03-19 14:50:18 +01:00
Conversation 6 Commits 9 Files Changed 32 +259 -17
abonerib commented 2025-10-07 16:45:31 +02:00
Collaborator
Copy Link

rarias/bscpkgs#12

https://jungle.bsc.es/git/rarias/bscpkgs/pulls/12
abonerib changed title from WIP: Set strictDeps=true on our top level packages to Set strictDeps=true on our top level packages 2025-10-08 12:33:00 +02:00
rarias commented 2025-10-09 12:23:41 +02:00
Owner
Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?
abonerib commented 2025-10-09 13:08:58 +02:00
Author
Collaborator
Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

We already discussed it bscpkgs: rarias/bscpkgs#10 (comment)

TL;DR: I think it's preferable to enforce strictDeps so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.

> I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve? We already discussed it bscpkgs: https://jungle.bsc.es/git/rarias/bscpkgs/pulls/10#issuecomment-4209 TL;DR: I think it's preferable to enforce `strictDeps` so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.
rarias commented 2025-10-09 13:38:54 +02:00
Owner
Copy Link

I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve?

We already discussed it bscpkgs: rarias/bscpkgs#10 (comment)

TL;DR: I think it's preferable to enforce strictDeps so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand.

I have two issues with strictDeps:

  1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future).
  2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations.

If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.

> > I was planning to add another job to the CI to run the cross compilation target. Wouldn't that cover what this patch is trying to solve? > > We already discussed it bscpkgs: https://jungle.bsc.es/git/rarias/bscpkgs/pulls/10#issuecomment-4209 > > > TL;DR: I think it's preferable to enforce `strictDeps` so our derivations are correct before wasting time and resources cross-compiling something that we could already have known would fail beforehand. I have two issues with strictDeps: 1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future). 2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations. If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.
abonerib commented 2025-10-09 14:54:55 +02:00
Author
Collaborator
Copy Link
  1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future).

I have taken a look in stdenv and there the two takeaways are:

  1. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations.

I think that explicitly setting it to false could also have unintended consequences (see above).

If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set.

I agree that adding it by default magically to all our packages is a bit of a hack. Maybe we can add it as a ci target, but that would mean a lot of rebuilds.

> 1. Is not well documented so I don't know if it does only what you think it does. This can be resolved by reviewing the relevant parts of the stdenv machinery (and ideally having some notes for the future). I have taken a look in stdenv and there the two takeaways are: - When cross-compiling, by default it is enabled: https://github.com/NixOS/nixpkgs/blob/f00b180ed496b11337983fe4b0b979419cb3e472/pkgs/stdenv/generic/make-derivation.nix#L225 - This has the unfortunate consequence that setting `strictDeps = false` will affect cross compilation (I may be wrong) - The actual logic is in the stdenv setup.sh: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L850 - There are only 3 uses of strictDeps. From what I could understand: - 2 of them related to skip adding things to the HOST_PATH and - the other skips running setup hooks from activated packages. The setup hooks could do anything, so who knows what the consequences are. > 2. I don't like auto-enabling this when is not done in upstream yet (this is partially caused by the point above). Maybe a less risky option is to fail to evaluate if you forgot to set it either to true of false, so you have to explictly set it in all derivations. I think that explicitly setting it to false could also have unintended consequences (see above). > If you think it is still useful to have it, I would need to review how it works internally. If that point is clear, I won't oppose enabling it for those derivations that you have worked on. Not sure if we want to enable it for all where is not set. I agree that adding it by default magically to all our packages is a bit of a hack. Maybe we can add it as a ci target, but that would mean a lot of rebuilds.
abonerib changed target branch from master to upgrade/25.11 2025-12-09 15:17:40 +01:00
rarias changed target branch from upgrade/25.11 to master 2026-01-20 13:51:32 +01:00
rarias added 15 commits 2026-01-20 13:51:32 +01:00
Upgrade nixpkgs to 25.11 6e089344da
Fix renamed llvm bintools d2025d35d9 
Moved from llvmPackages_latest.tools.bintools to
llvmPackages_latest.bintools
Set pyproject=true in buildPythonApplication eb9358abab 
The buildPythonPackage and buildPythonApplication functions now
  require an explicit format attribute. Previously the default format
  used setuptools and called setup.py from the source tree, which is
  deprecated. The modern alternative is to configure pyproject = true
  with build-system = [ setuptools ].
Fix changed cudaPackages.cuda_cudart output 5bc928c407 
See: https://github.com/NixOS/nixpkgs/pull/437723
Replace wrapGAppsHook with wrapGAppsHook3 ad812ea32d
Fix renamed option watchdog.runtimeTime 1457d85f4c 
The option 'systemd.watchdog.runtimeTime' has been renamed to
'systemd.settings.Manager.RuntimeWatchdogSec'.
Use standard gcc for intel packages 209f8a582e 
This reverts 26f52aa27d
Fix replaced nixseparatedebuginfod 2264e15102 
nixseparatedebuginfod has been replaced by nixseparatedebuginfod2
Fix moved package linuxPackages.perf is now perf 87bf095dae
Mark mcxx as broken and remove from package list
All checks were successful
CI / build:cross (pull_request) Successful in 8s
Details
CI / build:all (pull_request) Successful in 16s
Details
1d3bda33a0
Set strictDeps to true on all our packages 21d9e132aa
Fix cudainfo buildInputs aab17ab0c4
Fix papi_version_check f77a36ee4c 
Instead of running the papi_version binary, use the
builtin version check from pkg-config.
Remove unused sys-devices requirement in ld test b831f0a0bf
Fix openmp buildInputs
All checks were successful
CI / build:cross (pull_request) Successful in 49m18s
Details
CI / build:all (pull_request) Successful in 57m9s
Details
755e6dd1a7
abonerib force-pushed enableStrictDeps from 755e6dd1a7 to 1cb632a170 2026-01-21 12:43:58 +01:00 Compare
abonerib force-pushed enableStrictDeps from 1cb632a170 to 61ed93c951 2026-01-21 12:46:25 +01:00 Compare
abonerib added 1 commit 2026-01-21 15:11:49 +01:00
Do not force derviation inputs, use booleans instead
Some checks failed
CI / build:all (pull_request) Failing after 4s
Details
CI / build:cross (pull_request) Failing after 4s
Details
fb653b7d98
abonerib force-pushed enableStrictDeps from fb653b7d98 to 0ac3d3e515 2026-01-21 15:13:36 +01:00 Compare
abonerib force-pushed enableStrictDeps from 0ac3d3e515 to 9c6f2e0097 2026-01-21 15:16:10 +01:00 Compare
abonerib force-pushed enableStrictDeps from 9c6f2e0097 to c70480d56d 2026-03-17 18:48:10 +01:00 Compare
abonerib added this to the Kanban project 2026-03-18 14:31:55 +01:00
rarias self-assigned this 2026-03-18 15:02:16 +01:00
rarias moved this to In Progress in Kanban on 2026-03-18 15:02:44 +01:00
rarias approved these changes 2026-03-19 11:48:42 +01:00
Dismissed
rarias left a comment
Owner
Copy Link

Thanks a lot! I left some minor comments mostly for adding a bit of context.

Thanks a lot! I left some minor comments mostly for adding a bit of context.
pkgs/papi/default.nix Outdated
@@ -0,0 +7,4 @@
papi
else
papi.overrideAttrs (old: {
configureFlags = (old.configureFlags or [ ]) ++ [
rarias commented 2026-03-19 11:37:07 +01:00
Owner
Copy Link

Could you add a small comment here about those flags just to remember why they are needed? The rationale is to provide some context to help us on future PAPI releases that may break, as we probably would need to adjust them.

Could you add a small comment here about those flags just to remember why they are needed? The rationale is to provide some context to help us on future PAPI releases that may break, as we probably would need to adjust them.
abonerib marked this conversation as resolved
pkgs/papi/default.nix Outdated
@@ -0,0 +8,4 @@
else
papi.overrideAttrs (old: {
configureFlags = (old.configureFlags or [ ]) ++ [
"--enable-perf_event_uncore=no"
rarias commented 2026-03-19 11:29:41 +01:00
Owner
Copy Link

--disable-perf-event-uncore ?

`--disable-perf-event-uncore` ?
abonerib marked this conversation as resolved
test/compilers/clang-openmp-ld.nix Outdated
@@ -25,4 +25,1 @@
# nOS-V requires access to /sys/devices to request NUMA information
requiredSystemFeatures = [ "sys-devices" ];
rarias commented 2026-03-19 11:17:01 +01:00
Owner
Copy Link

Could you add a comment in the commit message explaining why we don't need this anymore?

Could you add a comment in the commit message explaining why we don't need this anymore?
abonerib marked this conversation as resolved
abonerib force-pushed enableStrictDeps from c70480d56d to 4a18915b38 2026-03-19 12:13:53 +01:00 Compare
abonerib force-pushed enableStrictDeps from 4a18915b38 to 98cac0fb8d 2026-03-19 12:53:54 +01:00 Compare
abonerib added 1 commit 2026-03-19 13:04:11 +01:00
Add papi and nosv to cross-compilation CI
All checks were successful
CI / build:all (pull_request) Successful in 32s
Details
CI / build:cross (pull_request) Successful in 2m58s
Details
587e764024
rarias approved these changes 2026-03-19 14:43:04 +01:00
rarias moved this to Done in Kanban on 2026-03-19 14:46:50 +01:00
abonerib force-pushed enableStrictDeps from 587e764024 to 4f51ebe607 2026-03-19 14:50:16 +01:00 Compare
abonerib manually merged commit 4f51ebe607 into master 2026-03-19 14:50:18 +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
Milestone
No items
No Milestone
Projects
Clear projects
No project Kanban
Assignees
Clear assignees
abonerib anavarro arocanon varcila rarias
No Assignees rarias
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rarias/jungle#192
Delete Branch "enableStrictDeps"

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?