How to rebuild a flake pkg

Help
1

So some kde pkgs were updated to 6.2.4 an normally on arch I would have to rebuild Kwin effect force blur (Better Blur) and all is well. But on nix since its used in a flake I cant do that to my knowledge. I’ve tried nix flake update and sudo nixos-rebuild switch --flake /etc/nixos/

Any idea how I can get the system to rebuid it in the flake. If it helps im using the garuda nix subsystem

Operating System: NixOS 25.05
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.12.1-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 GRE

2

If anything needs to get rebuilt it will happen automatically (assuming you installed it declaratively). This ain’t your grandpa’s build system :wink:

Correct deployments is one of the main selling points of nix.

1 Like
3

Here is my main flake since that wasn’t helpful, again I am using garuda nix subsystem.

{
    description = "Garuda Linux Nix Subsystem Flake";

    inputs = {
        garuda.url = "gitlab:garuda-linux/garuda-nix-subsystem/stable";
        nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

        kwin-effects-forceblur = {
            url = "github:taj-ny/kwin-effects-forceblur";
            inputs.nixpkgs.follows = "nixpkgs";
        };
    };

    outputs = { self, garuda, nixpkgs, kwin-effects-forceblur, ... }:
    let
        system = "x86_64-linux";
    in
    {
        nixosConfigurations.elite-garuda = garuda.lib.garudaSystem {
            inherit system;
            modules = [
                ./configuration.nix
                {
                    # Define a module that includes the kwin-effects-forceblur package
                    environment.systemPackages = [
                        kwin-effects-forceblur.packages.${system}.default
                    ];
                }
            ];
        };
    };
}
4

Hi,
So as i am using KWin also i wanted to give it a try to understand where your issue might be located.
So with the given instructions nix picks it initally up fine and builds the pkgs.
Its afterwards available as Window Decoration in KSystemSettings (as described on the github readme). Tho i was not really able to get blur effects (as i dont want to dig into what all configs i need to change).

What i try to understand is what you mean by “rebuilding” a flake pkgs (specific in your phrase and what you try to archive), as i have the impression there is some misunderstanding in how things work with nix (if that is not the case i am sorry).

(simplified and possibly something is missing) So when nix picks up a derivation for building it checks if the path that needs to be build is a) already existing in the /nix/store (then nothing to do), if its not existing b) it queries all configured binary caches (If its found there it will just download from there), if its not existing in any binary cache, c) it will build the derivation locally (or with attached distributed builders).
After a derivation was build successfully, it is existing in the /nix/store. So that means on any later nix build (nixos-rebuild will invoke nix build), it will just see that its already in store and just use that, so it will not freshly build it every time.
You can force rebuild a derivation, when adding --rebuild to the build of that specific derivation, it will then attempt to rebuild the derivation and check if its the same like the one that is already in the /nix/store (so that mean the command is mainly to check for reproducibility).

So that mean when you want forcefully rebuild so could remove the derivation from all of your system closures and then run a garbage collection, which will remove it from /nix/store and on next build it will have to rebuild the derivation again.

If you build input would change (so either the source code that you have build [e.G when the git rev changes] or if an build dependency of the derivation changes) nix will automatically figure that out and rebuild the pkgs on the next build by its own knowledge.

That leaves me to the question: What are you trying to archive or where exactly are you stuck that you want to “rebuild” a package, as you might be stuck in a x-y-Problem.

If the Plugin is not available to your KWin it might also be related to that garuda stuff, i am not sure what its actually doing, it sounds quite magical to mix a nixos with a arch based distro on OS level, and i could imagine that if you use garuda as core (and nixos on top of that), that a garuda kwin might not pick of plugins from nix derviations.
But that is just blind guessing as the information that you gave it quite limited to acutally dig into your specific setup situation.

1 Like
5

This is a waste of time, don’t do this.

pacman is an incompetent package manager which necessitates rebuilding individual reverse dependencies on every library (ABI) bump. nix on the other hands takes care of rebuilding whatever’s needed. So if you have a problem, tell us the problem; if you don’t have a problem, don’t go creating one with nix just because you’re used to pacman being bad at its job.

6

I give it a shot here as soon as i get home. The reason this happens has nothing to do with pacman or any other pkg builder its that when kwin gets upgraded it always wipes this and kde rounded corners. The way to fix it on anything no arch. is to build it from source right after the kde update. What i mean by kde update is 6.2 to like 6.3 it would need to be built from source. Its a KDE 6 thing. i can’t tell you why.

Its just something that breaks and needs to be built again after everything else. or it wwont show up in desktop effects. But also as im well burnt out on this an nix i plan to give it a shot with normal nixos kde an see if it happens around 6.2.4 or 6.2.5. if so my real answer is drop the nixos an just use the pkg manager on other distros.

Don’t get me wrong I really like nix. but time wasters like this really get to you.
An I thank you for looking into it.Aanything helps as nix docs are just not as useful as I would like.

7

Did you accidentally encounter such a situation? Or are you asking about it, as it was a thing in arch? (Sorry I did not get that so explicit)

I checked that the blur package depends on kwin as build Input. That means as soon as the kwin output changes, the blur package will be built again with the new kwin input.

A possible pitfall that I see from your snippets.
Your garuda system builder seems to follow a different nixpkgs instance (so it does not define a follow so it will use the upstream flake ones), tho your plugin does follow the nixpkgs input that you have defined.

That means that you might have a different kwin version from garudas nixpkgs instance than from your own nixpkgs input.

That might be the issue you are facing.

I assume that garuda updates are behind nixpkgs unstable, thus it will break when nixpkgs updates (garuda not yet has updated), and should work again when garuda is updated.

Possible solution to that, either let garuda follow nixpkgs as well, or pass a nixpkgs instance that is your unstable one to the system (I recommend the first if possible)

1 Like
8

Yeah I’m not to sure fully. I’ve just gotten into the whole nix setup so I’m still learning.

Oh no worries i was just explaining it for the sake of context. As its what i used to do to solve the problem.

But good news the rest of the plasma core pkgs got a update today when i checked. an it solved it. I’m taking it as i have to wait for all plasma pkgs. An thank you again for the help an looking into it i appreciate it.

9

Actually, after thinking about the issue and assuming that garuda is following a nixos unstable, and you are updating the system regulary the said situation might acutally be the problem.

garuda seems to have an automatic updater for their flake.lock. You are updating your flake.lock in another time frame.

So as those updates are happening in another timespan, you might result in the situation that your nixpkgs instance.
In addition to that garudas nixpkgs is actually a fork.

So the actual content of the garudas nixpkgs is in worst case totally different than your nixos/nixpkgs/nixos-unstable.

That will result in a mixed up dependency chain, as you build your for the blur plugin is build against a nixos/nixpkgs/nixos-unstable.

What you want to do is:
Either let garuda follow your nixos/nixpkgs instance (which i would not recomment, as garuda seems to patch nixpkgs if i see something like (droid-sans-mono-nerdfont: drop (upstreamed) · chaotic-cx/nyx@12fd51d · GitHub) or what i would do in your situaton:

Add chaotic-nyx/nixpkgs as your flake input, add a follows to the garuda nixpkgs (so that it follows the newly added input) and let the blur plugin follow the same input.

So something like

   inputs = 

        nixpkgs.url = "github:chaotic-cx/nyx/nyxpkgs-unstable";

        garuda = { 
               url = "gitlab:garuda-linux/garuda-nix-subsystem/stable";
                inputs.nixpkgs.follows = "nixpkgs";
        };

        kwin-effects-forceblur = {
            url = "github:taj-ny/kwin-effects-forceblur";
            inputs.nixpkgs.follows = "nixpkgs";
        };
    };

That should result in having the same rev for all of your inputs.
You could check that if you inspect your flake.lock, if you result in having the same rev.

1 Like