Change:
dbus-next mpd2 psutil <ins> pulsectl-asyncio </ins> pyxdg pygobject3 pywayland pywlroots xkbcommon <del> pulseaudio </del> ]; buildInputs = [

Discussion:
Steps to reproduce the behavior: the unstable branch is used <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This PR () could be the first step to solve the issue.
I think this is a duplicate of
It's not a duplicate, that issue was from someone who was trying to build Qtile from its master branch. Qtile in nixpkgs-unstable is currently failing to build because of or because those packages were updated without waiting for Qtile to release a version that supports them. For people running qtile from nixos-unstable, you should install and from to make Qtile build again. Once Qtile releases 0.23.0, we will update the package in unstable and then the dependencies will align again. This is probably still some time in the future though.
How would that override look like? I am struggling right now to replace the packages
The simplist way to fix this is to set to the version of . If you're using flakes you can and do something like: Or use whatever method you prefer to get .
Worked like a charm a non flake solution if someone is as un-flake as I
This didn't work for me. But I got it working by downgrading my entire config to stable 23.05. :shrug:
which display manager are you using? I tried that with Lightdm, but I get a black screen when I try to login, and then get dropped back to Lightdm after some seconds. I didn't find anything in the qtile logs, or in journalctl. Very strange. I did something similar to what you did, but with flakes
i use startx instead of a DisplayManager but if you get thrown back into lightdm after a while, the qtile logs should show something i recommend asking in the discord or the forum, someone there can probably help you better
I had the same problem, fixed it with the following by overriding the xsession package that was called. You would need to add the stable release as an overlay (as described earlier in this thread). I am using qtile-unwrapped, if you use standard qtile, you would probably need to update the package name.

This is basically just copied from the and there is probably a better way on how to achive this. (I am just getting started)
Not sure If it's the same issue or If you haven't missed it, but I had the same problem and journalctl did catch the issue:
I was checking for critical errors , and this error is definitely not there. But thanks for sharing, I should have look in the full logs. Unfortunately, the solution proposed by did not work for me out of the box, I haven't had the time to investigate further. Did you in the meantime found a workaround?
Unfortunately the solution proposed in did not work for me. Rebuilding the system went fine but the problem comes when booting as Qtile just won't start : , in you say that the problem comes from another package that was updated and broke the current release of qtile. I don't wand to be rude and maybe I don't understand fully the problem but isn't the core promise of nix (and nixos) to enable devs to pin dependencies and package them with their application? I would try your solution of installing the missing libs myself but I am not sure how to proceed here (if you would indulge me I would appreciate a lot). I would also build qtile from master but that looks like a whole other story with its own set of problems. I think basing my whole system on unstable packages was a mistake in the first place and I should expect these problems but a dependency problem just feels weird. In lack of a better solution I'll just bite the bullet and move to gnome or hyprland.
The was released a few hours ago and theoretically it should fix the (see the latest comments)
Great news :)
i cannot believe i overlooked this for like two straight weeks :man_facepalming:
In theory, you're right about being able to pin dependencies. But that isn't how nixpkgs works. Packages usually have a single version available at any point in time in nixpkgs, and those can be updated independently, breaking other packages in the process. PR submitters should account for that and make sure their PRs don't break other packages, but this isn't always done fully or sometimes isn't even possible without building every single package in nixpkgs. Pinning dependencies can be easily done outside nixpkgs though.

In your local repo you could define your own overlays or packages in which you force for instance and to a specific version. Or you could pin to a specific revision from their master repo. And if you would be the dev of qtile, you could indeed publish your own that pins all dependencies to known working versions. Basing a system on is a choice that everyone can make, but can be annoying sometimes. In my case, I have regular (every 1 to 2 weeks) evaluation or build failures that make me unable to update my systems. But those build time failures are really one of nixos's strengths, because those failures don't make their way into my live system. Run time failures happen almost never, so even on nixos-unstable my systems are always rock solid. Regarding build failures like this, I think there are essentially 3 choices: Fix it locally, either by mixing in packages from stable, pinning dependencies/versions or by applying some patch. Note that you need at least some nix skills to be able to do this Wait for someone else to fix it and don't update your system in the mean time Switch to the latest stable release
thank you, that is a summary I can get behind. It actually wasn't obvious to me that you couldn't pin nixpkgs, inside nixpkgs. How so? You can fetch any external repository from nixpkgs to get the actual source code. Can you do that with these two librairies? Do you have to rely on nixpkgs? Aren't these just additional python dependencies?
In theory, yes. But in practice all dependencies are also packages in nixpkgs that just get referenced. Due to the pure evaluation of nix code in nixpkgs, you can't just do in a build script, because the inputs and outputs of a derivation (package in this case) must be known beforehand, which in turn means it has to be available in nixpkgs. This also means the build process of nixpkgs packages can't have internet access and can't download anything from build scripts. So, as a package maintainer I could add specific version-pinned inputs (derivations) for and , but then I would be duplicating the pre-existing packages in nixpkgs with slightly different inputs.

In some cases, like , multiple versions are available in nixpkgs due to the incompatibilities between versions, but that's not the usual approach.