Change:
, extraBwrapArgs ? [ ] # extra arguments to pass to bubblewrap (real default is at usage site) , extraArgs ? "" # arguments to always pass to steam , extraEnv ? { } # Environment variables to pass to Steam <ins> # steamwebhelper deletes unrelated electron programs' singleton cookies from /tmp on startup: # https://github.com/ValveSoftware/steam-for-linux/issues/9121 , privateTmp ? true # Whether to separate steam's /tmp from the host system </ins> , withGameSpecificLibraries ? true # include game specific libraries }@args:

Discussion:
The Steam application crashes when opened Steps to reproduce the behavior: Steam e.g. from Bash I expected steam to open. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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. [j nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(j): nixpkgs: I'm using the channel. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
How did you "install" it?
I to in my file. Thing is, my most recent must have broken things, because it was working yesterday.
Steam needs to set up extra stuff (such as 32-bit drivers which I think is the problem here), you should use instead.
As it turns out, was also in my I've disabled the entry, and still get the same issue. So I guess the problem is with whatever does.
Hm, weird. Anyway, I think the initial problem is this here: I think the libxml error is just a result of Steam trying to run zenity due it not being able to open its window to show an error message. Should probably be fixed as well but it's not the main problem.
Just rolled back to my previous system update @ December 15. Steam works, confirming a window of - for this bug to have crept in. I'm not really sure what that is though, or what to do about it. Though if there's any other info or help I can provide, please let me know; Steam works, but I'm invested in this bug being squashed quickly, because I use an NVidia card. The driver (headers) for NVidia cards is recompiled for each kernel update (breaking the other installed kernels w.r.t. gfx accel), and so games have a horrible frame rate on the rolled-back system snapshot.
I am having the same problem with an NVidia GPU running on KDE.
An AppStream PR was by about 2 weeks ago.

I can't say for sure, but given the delay between merge and it popping up in unstable, perhaps that backport is related? EDIT: Similar story for which was merged by
Are you using a Wayland-based desktop environmnent such as GNOME? Maybe Xwayland is missing in your setup.
Can't open it too when running on Plasma (X11), although it works when starting with Plasma (Wayland).
Same issue with an AMD card, using the mesa packages ( + 32bit and ) on KDE Plasma X11. Only difference is that Steam is installed through home-manager, but both the system and hm are on unstable. UPDATE: Steam works when rolling back home-manager's nixpkgs to revision (just before the merged PR mentioned) whilst keeping the system on the latest revision, so I suppose that limits the affected packages (I don't have any "system" or desktop environment packages in home-manager)
I am using KDE / Xorg. I did try KDE / Wayland today, but Steam itself was flickering so wildly it was plausibly seizure-inducing. That's something I've never seen before on Xorg, so I went back to my regular KDE / Xorg session. EDIT: I just installed XWayland and tried KDE / Wayland again. That works, so that just became the path of least resistance (sort of, the Steam flickering issue remains). That said, if anything else is needed from me, please let me know. I'd still like this issue resolved.
Pinning just the package to revision ~~ lets it work again. This is the commit just before the three last commits (on 2023-12-14) to the steam package. It would seem the first of those three commits () is what broke steam as none of the later ones work either.
I'm guessing you mean pinning to works, idk what happened but previously for me steam was getting stuck loading after logging in. I'm still getting a weird error that makes Steam switch between No Connection and Online and don't know the reason why it happens :sob:
Just for clarification, doesn't work for me, but it's parent does work. I am testing with though, so it may have different results when installed.
Yeah that makes more sense lol
Almost, I meant - like mentions. Sorry - copy-paste fail from my side.

Same here on KDE/Xorg with intel gpu Current nixos-unstable is broken, works fine for me
Can confirm that the solution mentioned by seems to temporarily resolve the issue. (Thanks! :blush:)
Same -- not working on X11/AMD, does work on Wayland though. Works on X11 if I revert to my previous generation.
Can also confirm the same issue on X11/KDE and Nvidia GPU. Reverting to a generation from last week also works for me as of now.
Binding my current file into the FHS lets it load with X11 - - trying to figure out how to predictably know what the name will be or find another way to ensure this is available inside the environment. In :
It definitely works on some X11 setups as well. I tested it primarily on X11/i3. I wonder if the location of the X authority is dependent on the display manager used? Can you all share what display managers you're using? I tested on lightdm with no problem. I really should have made an overrideable option on the steam package itself...
Plasma here -- Wayland working, X11 not working.
Display manager, not desktop environment. I'm guessing sddm, to go with plasma?
Yeah, sddm, sorry -- read on my phone and answered too fast :)
I think the reason for only triggering for sddm is this explanation from
Ok, so the proper fix is to add some bash code to that checks if starts with , and if it does, bind it to itself?
I can reproduce this in sddm+i3, in a qemu vm. Will get to work on a fix.
Fixed in the above PR. I also made overrideable with , so you can turn it off if it's causing problems.
that is rather odd. I am using myself () and I am experiencing crashes. EDIT: Going to update my and try again for the sake of testing.
How does this work now that the PR is merged into master. Does it take a while for the update to show up on a command?
it will make its way into once hydra finishes building the next batch of packages without blocking errors. You can track it with
Nice! I was tracking it (erroneously) with the backport gh action.
As I'd thought, the rev in my happens to be .

Therefore it should already contain the changes you submitted not so long ago, I wonder what else could be causing this issue?
Thank you all for the quick fix :) Sorry to crowd this issue, had a question. How can one tell from whether this built successfully or not and is merged into nixpkgs-unstable?
You probably mean rather than , and if so, the relevant jobset is . You can see the status of evaluations there and what commit of nixpkgs they're from. But it's hard to tell whether the channel advanced from the hydra interface, since it does advance in the presence of some errors. Also, hydra doesn't actually build steam, because it's unfree, so there's no specific job to look at. If what you want to know is whether a given PR has hit unstable yet, alyssa's tracker is the best way.
Awesome, thank you
This doesn't quite work on my box, but the modified form does work for me :slightlysmilingface:
I apologize for the confusion that I could've caused, I should've mentioned that I have both and enabled in my flakes setup. Your command should work for everyone without the prerequisites that I'd mentioned.
I can confirm switching from sddm to lightdm with slick greeter fixes it for me, for some reason .Xauthority wasn't being created with sddm.
It's just how sddm chooses to place the x authority cookie. lightdm puts it in , gdm puts it in somewhere, and sddm puts it in . It normally doesn't actually matter where it puts it as long as the environment variable contains the path to it. The problem here was that I changed the steam package's fhs environment to run with a separate in order to workaround a steam bug, and that broke sddm's placement. The fix has now reached , incidentally, so there should be no need to switch anymore. :-)
Can confirm that the changes you last merged fixed the issue. Appreciate the fix!