Bug: Nixos not rebuilding after regreet was added to stylix #577
Comments
psynyde
changed the title
Do you mean by "stable", the
Either way, thanks for posting this for reference. In the future, #543 would partially resolve similar issues. I will close this issue, as I don't think there is much Stylix can do about this at this point. Feel free to re-open, if I am wrong on this. |
|
Setting |
I see your use case. Maybe we could backport to |
|
Basically, can't update stylix, past the update that added regreet, because stylix is set to expect regreet to have options that are only available in nixpkg-unstable. So the options don't exist so stylix fails the build. It's not relevant if you have regreet enabled or not, and it's not relevant if you have regreet installed or not. Right now stylix 24.05 doesn't work. If you check programs.regreet in search.nixos.org/options and compare what options are available in 24.05 and unstable, there are more options in unstable. Hopefully these options can be removed from stylix 24.05. Thank you! |
I already mentioned this:
What do you mean by "stylix 24.05"? If you mean the release-24.05 Stylix branch, then this should not be an issue because it does not have a regreet module. If you mean that you are explicitly overriding Stylix's Similar to Nixpkgs and Home Manager, Stylix supports only the latest versions from |
|
@trueNAHO Thanks for answering. inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";
stylix = {
url = "github:danth/stylix";
inputs.nixpkgs.follows = "nixpkgs";
};
};Which I assume means I get stylix/release-24.05? (please advice) nixpkgs 24.05: nixpkgs unstable: |
|
@sigboe unsure if you are having this problem, but no you are pulling the master branch for Stylix. You would need to adjust |
|
I encountered this issue today after updating my inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-24.05";
nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";
stylix = {
url = "github:danth/stylix";
inputs.nixpkgs.follows = "nixpkgs-unstable";
};
};I use |
|
That will only make the flake use packages from unstable but not the nixosModules. You would need to define your system with unstable instead of stable or as previously stated use the stable branch of stylix that matches your nixpkgs. |
I would prefer to follow nixpkgs-unstable for stylix, but it breaks right now due to a mismatch in settings for a few packages. Since most of my NixOS config is on the stable release, it's not possible to use the master/main branch of stylix without issues like this: danth/stylix#577
…here the system wouldn't switch to the new configuration. See: 'danth/stylix#577'.
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ];
Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly anywhere in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like #577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ]; Reviewed-by: Daniel Thwaites <[email protected]> Reviewed-by: NAHO <[email protected]>
…nth#631) Apparently `../modules` is creating a separate derivation that contains only that folder, so it's now separate from the flake source. But this transient derivation isn't mentioned explicitly anywhere in the flake outputs. It makes it impossible to target those modules in `disabledModules` directive. For example, after this change is applied, users can solve issues like danth#577 locally, by just adding the following snippet to their configuration: disabledModules = [ "${inputs.stylix}/modules/regreet/nixos.nix" ]; Reviewed-by: Daniel Thwaites <[email protected]> Reviewed-by: NAHO <[email protected]>
|
I'm running into this now and I'm a little unclear about what I should expect from the Should I expect |
Ideally, yes.
Does commit 7689e62 resolve the issue? |
|
It doesn't |
|
Is this issue resolved by updating to |
|
Changing my flake input fixed my stable NixOS systems:
|
|
Closing this issue, as it seems to be resolved in |
I'm creating this issue for who are facing this error below or something similar even though their system doesn't use regreet at.
changing stylix input to
github:danth/stylix/cf8b6e2d4e8aca8ef14b839a906ab5eb98b08561.should fix the issue.
I assume the main issue is nixpkgs-unstable introduced more customization to regreet which isn't available on stable (ie. 24.05) The input above points to the commit before regreet was introduced in styix.
The text was updated successfully, but these errors were encountered: