error: separateDebugInfo = true in lix requires __structuredAttrs if {dis,}allowedRequisites or {dis,}allowedReferences is set #917
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
ux
No milestone
No project
No assignees
11 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#917
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
While trying to update my flake I have started getting the error from the subject of the issue. This has happened first when upgrading nixpkgs from
d3807bc34e7d086b4754e1c842505570e23f9d01
tob47d4f01d4213715a1f09b999bab96bb6a5b675e
.nix flake check
is enough to get the error, flake below. The machine where I'm running the builds runsnix (Lix, like Nix) 2.92.3-pre20250629-f10ca0d
.I am honestly 100% sure I understand what this error means, so please let me know if I'm meowing under the wrong tree and should report to nixpkgs instead.
Full error:
flake.nix:
flake.lock:
@k900 that's the exact thing you fixed on main, right?
Yeah, I guess
378b360bf8
needs a backport?cherry-picks aren't possible directly from gerrit. until somefew get around to cherry-picking you can temporarily fix the problems by setting
separateDebugInfo = false
on lix using a nixpkgs overlay (though we'd suggest adding the overlay withmkAfter
to make sure it's applied after the lix-module overlay)It won't cherry-pick anyway, because it's from an entirely different repo.
@pennae wrote in #917 (comment):
Do you have an example on how to do this? I'm not quite confident with using overlays yet.
adding this to your config (as a separate module if necessary) should do the trick:
I'm not sure if I have some user error going on but adding this to my config doesn't solve the issue.
I'm on 2.93.2 by the way if this changes anything:
Same for me. I tried this config, I tried setting this as an overlay in
import nixpkgs {overlays = [...]}
, and also inpackageOverrides
in theconfig
inimport nixpkgs {config = {...}}
. I believe this might have something to do with the fact that the lix module replaces the package, instead of calling override/overrideArgs, but I don't know how to work around that.oh, fun. it is apparently impossible to override
separateDebugInfo
. nixpkgs bug! so yeah, overlays won't do anything. the options now seem to be using an older lix until fixes are cherry-picked, using main, or not updating nixpkgs. we would strongly advise against the last option.More creative solution: wipe disallowedRequisites?
@jade wrote in #917 (comment):
also jacked because only the initial mkDerivation args go into that calculation
https://gerrit.lix.systems/c/lix/+/3668, https://gerrit.lix.systems/c/lix/+/3671 cherry picks to 2.93 and 2.92. I expect to run a release of 2.93 and not bother with a 2.92 release.
hey now how can i override lix i use lix-nixosmodules
There will be a Lix (and module) update soon including this fix.
Is there anything that needs to be done to get this across the line?
A release is being worked on.
You may use the release-2.93 branch of lix in the meantime which contains the work in progress release. It probably works fine, we're just finishing some last touches.
@jade wrote in #917 (comment):
how? it can't rebuild without a version of lix that has this fixed
This fixed it for me
the release-2.93 version did not work but the main branch does.
I also had to add this hack to fix my evaluation but I don't know if this is related to lix or not:
should probably switch back once it's fixed and you'll have to wait for lix to build since it won't be cached
@freebritney132
This is unrelated. See: https://github.com/NixOS/nixpkgs/pull/425806
Replacing
lix-module.overlays.default
with this abomination has helped (it evaluates with newnixpkgs
without errors and without switching to bleeding edgemain
, and builds perfectly finestill waiting for an actual updated build – will edit this comment when I confirm with an actual build):inputs.lix
withrelease-2.93
branch doesn't help because the fix is not yet cherry-picked torelease-2.93
(you can see there's no__structuredAttrs = true;
inpackage.nix
)main
and then roll back__structuredAttrs
with aoverrideAttrs
oroverrideDerivation
, but both need to actually evaluate their input derivation, which failslix
argument pointing to path to lix source – at a point where we can compute/build itSo:
applyPatches
onlix-module.input-lix
to apply the fix from gerrit on the actual releasedlix-module
's input, get a patchedlix
sourceslix-module
's overlay from path, feed it the patched lix (and aversionSuffix
clearly indicating it's altered), get apatchedOverlay
patchedOverlay
in the overlay bodyAwful, right? Hope this helps!:)
That sucks. I've gotten those changes merged so your workaround is now not required; I was kind of dreading doing it due to the-distro/infra#182, but I remembered the workaround and manually triggered CI on the changes that weren't merged due to missing CI, then merged them.
Is there a difference between the main branch and release-2.93 I should care about? main branch has been working fine for me so far.
Not really, main has obviously more active development which means some newer features and some slightly higher probability of regressions, whereas release-2.93 is to be released officially in O(days).