ALVR+SteamVR broken on latest unstable

[eyJhb]

Describe the bug

Using ALVR + SteamVR on latest unstable will not work, and it will crash as soon as a headset is connected.
This is likely introduced here #341219 , and there is a fix here #351928 (this cannot be cherry picked, there are more things in staging-next that is required for this to work according to k900).
Running that PR has worked for me without any issues.

It is also possible to run revision fb4afaa before the decimate of Steam.

There is also another PR trying to "un-decimate" Steam here #352004 .

This issue can be closed once either #351928 or #352004 has been merged into unstable latest, and confirmed to be working in there.

Steps To Reproduce

Steps to reproduce the behavior:

1. Open Steam
2. Open ALVR
3. Preass Launch SteamVR in ALVR
4. Connect headset
5. Crash

Expected behavior

That it works, and I can see SteamVR in my headset.

This issue is made to move the discussion away from the PR here #308097

[LuNeder]

there is a fix here #351928 (this cannot be cherry picked, there are more things in staging-next that is required for this to work according to k900). Running that PR has worked for me without any issues.

It is also possible to run revision fb4afaa before the decimate of Steam.

There is also another PR trying to "un-decimate" Steam here #352004 .

This issue can be closed once either #351928 or #352004 has been merged into unstable latest, and confirmed to be working in there.

Hey! Can you confirm that it actually still works for you on #352004 or #351928 on their latest commits/force-pushes? Switching my system to those don’t fix SteamVR/ALVR at all for me!
(ALVR/SteamVR continues broken on undecimate and on the new K900 PR exactly the same way as on latest unstable)

Aditionally: while fb4afaa does work, it does not seem to be the parent commit of #341219 (git is weird). If I get the parent of the first commit in that PR (which is 273673e according to github, it seems to have been merged into unstable before fb4afaa - but its parents are way more recent than fb4afaa), SteamVR is already broken there so it feels weird for the decimate pr to be the cause. If my observations are correct, I imagine that the culprit for the breakage should be somewhere between 273673e’s parent and fb4afaa’s parent commits (but I have no idea how to check those commits if github history page isn’t reliable enough for that).

[LuNeder]

A few days ago I also opened alvr-org/ALVR#2476 and ValveSoftware/SteamVR-for-Linux#748. If this is a NixOS-only issue, as it seems to be, maybe I should close them?

Anyway, there’s some extra context for this issue available on those issues (such as a nix store diff between a working alvr generation and a broken alvr generation) in case anyone wants that for extra troubleshooting

[Atemu]

(ALVR/SteamVR continues broken on undecimate and on the new K900 PR exactly the same way as on latest unstable)

Could you confirm that it works on the commit before #341219 and is broken after?

This should work: 273673e
This should break: a3ccb7f

[LuNeder]

Could you confirm that it works on the commit before #341219 and is broken after?

This should work: 273673e This should break: a3ccb7f

No. As I mentioned on the above comment, it is broken on a3ccb7f but also broken on 273673e. It works fine on fb4afaa, which on nixos-unstable commit history is immediately before the decimate pr commits, but while fb4afaa was merged after 273673e into nixos-unstable, fb4afaa’s parents are older than 273673e ones. Due to that I assume that the ALVR breaking culprit is not actually the decimate PR, but some commit between 273673e’s parent and fb4afaa’s parent commit.

As I mentioned on my above comment:

while fb4afaa does work, it does not seem to be the parent commit of #341219 (git is weird). If I get the parent of the first commit in that PR (which is 273673e according to github, it seems to have been merged into unstable before fb4afaa - but its parents are way more recent than fb4afaa), SteamVR is already broken there so it feels weird for the decimate pr to be the cause. If my observations are correct, I imagine that the culprit for the breakage should be somewhere between 273673e’s parent and fb4afaa’s parent commits (but I have no idea how to check those commits if github history page isn’t reliable enough for that).

[Atemu]

@eyJhb does 273673e also not work for you?

[LuNeder]

Just retested it to make sure, and that's still true for me:

• Working on fb4afaa
• Already broken on 273673e
• Still broken on buildFHSEnv: rewrite env building #351928

Unsure how helpful this is, but here's a result of a store diff between fb4afaa (newest known working for now) and 273673e (oldest known broken for now): alvr-gen-diff4.txt

I was talking with @eyJhb on the nix gaming room on Matrix, and we have no idea how to do the bisect thing to figure out which commits exist between 273673e’s parent and fb4afaa’s parent so we could try those and know exactly which commit broke ALVR. If there's a way of listing that on GitHub or something, or if someone better at git could try doing the bisect, that'd be very helpful

[LuNeder]

figure out which commits exist between 273673e’s parent and fb4afaa’s parent so we could try those and know exactly which commit broke ALVR. If there's a way of listing that on GitHub or something,

Apparently this might do the job: fb4afaa...273673e
Now there are around 800 commits in there to check,

I got some college stuff to do rn, but later today or friday I'll take a closer look at those and try some of them out

[Atemu]

fb4afaa is a commit on master, not staging-next. Though staging-next did contain it because master is periodically merged into it, it's not relevant here. As far as this bug is concerned, fb4afaa should behave the same as the branch-off point of that staging cycle which is the merge of the last staging-next (fb4afaa).

Could you please verify that assertion and then do a quick first-parent bisect between 28e9b6d (good) and 273673e (bad)?

If it lands you on that cycle's staging merge (3cafcf5), you need to bite the bullet and bisect from that staging merge's second parent as the bad commit in order to find the cause. At that point I'd advise you to debug this because bisecting staging is anything but fun with such a huge closure even on a fast machine.

[eyJhb]

@eyJhb does 273673e also not work for you?

This DOES work for me. Full rebuild, reboot, and I can get the SteamVR inside my headset.
I've also double checked #351928 , full rebuild, full reboot, and it works inside SteamVR.

AFAIK all the times I've ran the bisect wit h--first-parent, I end up at that merge, and I haven't dug further (at least not anything meaningful).

[Atemu]

So it appears @eyJhb's case is different from @LuNeder and this is indeed fixed by #351928.

@LuNeder please create a separate issue and do this bisect: #352304 (comment)

[eyJhb]

(ALVR/SteamVR continues broken on undecimate and on the new K900 PR exactly the same way as on latest unstable)

Could you confirm that it works on the commit before #341219 and is broken after?

This should work: 273673e This should break: a3ccb7f

Also confirming that this statement is correct for me as well.

eyjhb@chronos ~/p/n/nixpkgs (master)> git bisect start --first-parent
status: waiting for both good and bad commits
eyjhb@chronos ~/p/n/nixpkgs (master|BISECTING)> git bisect good 273673e
status: waiting for bad commit, 1 good commit known
eyjhb@chronos ~/p/n/nixpkgs (master|BISECTING)> git bisect bad a3ccb7f
Bisecting: 0 revisions left to test after this (roughly 1 step)
[70cb669a2f5608583caedde7e691b104f83ad718] buildFHSEnv: fix nested fhsenvs with LD_PRELOAD
eyjhb@chronos ~/p/n/nixpkgs ((70cb669a)|BISECTING)> git bisect good
a3ccb7f562a93826ad0112adf20dc7f697b7713e is the first bad commit
commit a3ccb7f562a93826ad0112adf20dc7f697b7713e
Author: K900 <[email protected]>
Date:   Thu Sep 19 18:21:35 2024 +0300

    steam: decimate

 nixos/modules/programs/steam.nix                           |   2 +-
 pkgs/build-support/build-fhsenv-bubblewrap/buildFHSEnv.nix |   3 +
 pkgs/games/steam/default.nix                               |  17 +--
 pkgs/games/steam/fhsenv.nix                                | 431 ++++++++++++++++--------------------------------------------
 pkgs/games/steam/runtime-wrapped.nix                       |  45 -------
 pkgs/games/steam/runtime.nix                               |  37 ------
 pkgs/top-level/aliases.nix                                 |   1 +
 pkgs/top-level/all-packages.nix                            |   1 -
 8 files changed, 118 insertions(+), 419 deletions(-)
 delete mode 100644 pkgs/games/steam/runtime-wrapped.nix
 delete mode 100644 pkgs/games/steam/runtime.nix

(all tested, all fully rebooted)