Where is the source code of MiniInstaller?
#NixOS support
humble vessel
vernal onyx
i would recommend against packaging ahorn, since it's been unmaintained for a couple years now and is basically completely superceded by lönn
humble vessel
For MiniInstaller development, I think people should just develop it independently of Olympus.
humble vessel
Yes.
vernal onyx
yea, compiling the everest repo spits out miniinstaller; so you'd be effectively packaging everest if i understand correctly
humble vessel
i would recommend against packaging ahorn, since it's been unmaintained for a co...
OK, but why still leave that feature in Olympus?
vernal onyx
because some people still use ahorn
the button has been made more difficult to access (i believe you have to manually edit the config file) but removing it entirely at this stage would break some people's workflows
ivory bloom
because some people still use ahorn
the button has been made more difficult to a...
yeah you do need to edit the config
humble vessel
Really? I can see that button the first time I launch Olympus.
ivory bloom
because if you had ahorn/both already selected you would see ahorn
humble vessel
By first time I mean earlier this year.
hearty palm
Either way, I'm still in favor of adding more knobs instead of less
humble vessel
When user omits the MiniInstaller wrapper argument, we should use the FHS env we wrote, right? But that is a long definition which cannot be inserted as the default argument value in the argument list. If we make it default to null and stipulate that null means the default FHS env, then users cannot unset the wrapper by setting it to null (they can still unset using an empty string, but that is a little counterintuitive).
Also users are always free to set the wrapper by providing an env variable. The knob is always available either way.
hearty palm
Setting by an env var means that they have to wrap Olympus themselves
And they can provide an empty string in case they really don't want the wrapper
humble vessel
OK this is later than me launching Olympus the first time. No wonder now.
@silver cloud Add the other two wrapper options.
silver cloud
For loenn and mini installer?
humble vessel
Yeah.
silver cloud
Should be like Celeste wrapper right? I'm going to sleep but I might do it tomorrow
humble vessel
Should be easy, but I am busy today. Sleep tight.
unique timber
So.. How does one exactly run everest on nixos? 
hearty palm
@silver cloud is it too late to get those knobs in (conveniently) now? If yes, then just forget about those, if no, it would be great to get those in before the merge 
(pinging since the PR seems to be getting closer to getting merged afaik)
silver cloud
<@390226958241366016> is it too late to get those knobs in (conveniently) now? I...
Uh sure, doesn't seem too hard
silver cloud
--set-default OLYMPUS_CELESTE_WRAPPER "${celeste-wrapper}" \
--set-default OLYMPUS_LOENN "${if loennWrapper == null then "" else loennWrapper}" \
--set-default OLYMPUS_MINIINSTALLER_WRAPPER "${miniinstaller-wrapper}" \
and
miniinstaller-wrapper =
if miniinstallerWrapper == null then
(writeShellScript "miniinstaller-wrapper" "${miniinstaller-fhs}/bin/${miniinstaller-fhs.name} -c \"$@\"")
else
miniinstallerWrapper;
@hearty palm
i think this looks fine? not sure about the loennWrapper
maybe ill use that lib.optional string
hearty palm
Yeah I would use that
Also, I would treat all wrapper args the same as celesteWrapper is treated currently
So you probably want to have a small helper function which takes a wrapper, and returns the env var value
silver cloud
i mean if it was more complex maybe i could do a function? i dont think it worth it, if someone asks me in the PR sure
hearty palm
I mean we have special treatement for celesteWrapper, so IMO it would make the most sense to duplicate that
So something like ```nix
wrapper-to-env = wrapper:
if lib.isDerivation wrapper then
lib.getExe wrapper
else if celesteWrapper != null then
wrapper
else
"";
miniinstaller-wrapper =
if miniinstallerWrapper == null then
(writeShellScript "miniinstaller-wrapper" "${miniinstaller-fhs}/bin/${miniinstaller-fhs.name} -c "$@"")
else
(wrapper-to-env miniinstallerWrapper);
...
--set-default OLYMPUS_MINIINSTALLER_WRAPPER "${miniinstaller-wrapper}"
--set-default OLYMPUS_CELESTE_WRAPPER "${wrapper-to-env celesteWrapper}"
--set-default OLYMPUS_LOENN_WRAPPER "${wrapper-to-env loennWrapper}" \
alright should be pushed
hearty palm
Thanks! 👍
silver cloud
@humble vessel ```postBuild = ''
dotnet_out=sharp/bin/Release/net452
dotnet_out=$dotnet_out/$(ls $dotnet_out)
what is the purpose of these lines? to make a env var with every file in sharp/bin/Release/net452?
ivory bloom
i should notify you that dev olympus is moving away from mono into .net core
silver cloud
i guess i'll update this to work and then we migrate, guessing this is the recent main commits?
ivory bloom
stable still uses mono btw
silver cloud
silver cloud
stable still uses mono btw
i guess for now its fine as update.sh fetches from azure
frank barn
I don't think so 
humble vessel
what is the purpose of these lines? to make a env var with every file in sharp/b...
To find the path of the sole subdir.
silver cloud
ah because ls lists the subdir last?
silver cloud
To find the path of the sole subdir.
postBuild = ''
dotnet_out=sharp/bin/Release/net452/
# we have only a single deep directory
# we search for it by finding the deepest not empty
# could break if the structure changes in the future
dotnet_out=$(find $dotnet_out -type d ! -empty | tail -1)
makeWrapper ${lib.getExe mono} $dotnet_out/Olympus.Sharp.bin.x86 \
--add-flags ${phome}/sharp/Olympus.Sharp.exe
cp $dotnet_out/Olympus.Sharp.bin.x86 $dotnet_out/Olympus.Sharp.bin.x86_64
'';
i'm not sure if this is acceptable
i was thinking for a bit, this works if there are no more folders added and it does what's wanted
i guess its a bit more clear but it has the "pitfall" of still parsing find
i mean i kinda dont even need to search for empty but that's what ls is doing, i wonder what other way there is other than a loop with recursion
silver cloud
I don't think so <:thinkeline:410534291462815745>
heya sorry to annoy you, checking the core version and this is what /sharp/bin looks like
i'm guessing im not running the proper build commands? there's no publish folder
im looking for the Olympus.Sharp.bin.x86, maybe the design changed?
frank barn
dotnet publish --self-contained Olympus.Sharp.sln should do it
and the executable is Olympus.Sharp
silver cloud
ah so its there as Olympus.Sharp
nix is different as we use a builder, buildDotnetModule
frank barn
either you build it self-contained, or you make sure that the dotnet runtime is installed somehow I guess
silver cloud
i think it should be installed as it probably declared inside the builder
silver cloud
either you build it self-contained, or you make sure that the dotnet runtime is ...
last thing, there was an OlympusSharp.exe that ran stuff? what should i need fromlinux-64 to properly run?
fig1 is old version /sharp
fig2 is new version /sharp
frank barn
the old one had an exe because it was run using MonoKickstart (Olympus.Sharp.bin.x86_64), basically the exe was Olympus.Sharp and the bin was the runtime
the new one doesn't need that anymore
silver cloud
alright i think i found the issue
we have the sdk in path but not the runtime
hmm i think i have to wrap the thingabab
silver cloud
bruh
silver cloud
last thing, there was an OlympusSharp.exe that ran stuff? what should i need fro...
@humble vessel i wonder if I'm pursuing a false lead but the most recent versions are different in how sharp works
silver cloud
```nix
postBuild = ''
dotnet_out=sharp/bin/Release/net452/
# we have ...
as such i was trying to substitute this part because Olympus.Sharp.bin.x86 and Olympus.Sharp.exe are gone, replaced by Olympus.Sharp only
olympus doesnt find sharp so my guess is it's the fault of Olympus.Sharp not running properly and Olympus.Sharp isn't finding the olympus install
bruh i just need to set DOTNET_ROOT?
yep
humble vessel
buildDotnetModule handles those things (adding runtime to PATH, setting DOTNET_ROOT) for you by default. We overrided the install phase, so it doesn't work now.
Actually we may be able not to override install phase now? Using the argument makeWrapperArgs instead may be enough?
silver cloud
i tried the default install phase and dotnet --info gives me this
also we need to manually install /bin so we need an override in Install or PostInstall
ah its cause i didnt run the phases in the nix shell
i think
humble vessel
You can look at the source code of buildDotnetModule to see how the install phase is defined.
humble vessel
ah because ls lists the subdir last?
Ah no, because there is only one entry in the dir, and it's a subdir.
There should be an option in find command that can separate the output with the \0 character instead of \n to avoid the problem of ls (because filename cannot contain \0 in Linux).
Anyway this problem may be irrelevant now if we move to default install phase.
silver cloud
Anyway this problem may be irrelevant now if we move to default install phase.
this is current state
it does work on the most recent version but i'm not sure if I did everything right
if you want i can push it to the PR and you can formalize the review there or just say here what needs to change
i dont think dotnet-runtime = dotnet-runtime; is proper convention is it?
and i'm not sure if we're x86 exclusive now tbh
hmm
does it have to do with me running nix-build locally
humble vessel
I will test.
silver cloud
That sounds ominous
silver cloud
because i realised we are specifically doing linux stuff and mac procedure is different
guess self contained is fine even if it bloats the exe a bit?
humble vessel
Yeah I think so.
Alternatively you can add --set DOTNET_ROOT ${... in the makeWrapper call that makes $out/bin/olympus.
humble vessel
What linux specific stuff?
frank barn
Keep me updated when you're ready
humble vessel
Of course. Btw thank you because it's good to have upstream developers helping.
silver cloud
What linux specific stuff?
We explicitly match the Linux folders and the Linux desktop files.
I'm not sure if that's 100% Mac compatible, but if the binaries are fine and search paths are the same it should be okay
silver cloud
Alternatively you can add `--set DOTNET_ROOT ${...` in the `makeWrapper` call th...
I think I'll do this and push then
humble vessel
Is self-contained build larger than normal build + runtime?
humble vessel
Don't need to mind the desktop files. It supports darwin as long as the binary can run.
humble vessel
Change the installPath line to installPath = "${placeholder "out"}/lib/${pname}/sharp";, and remove the line commented with NixOS/nixpkgs#368936 in postInstall.
And for darwin, it turns out that LÖVE on nixpkgs does not support darwin.
For the comment about aarch being bad platform, you can write "Celeste doesn't support aarch in the first place".
vernal onyx
hi! i'm considering moving to nixos reasonably soon and would like to be able to use olympus, as well as build mods/everest from source; is there anything i should know before going in?
i'd be perfectly happy using / maybe contributing to in-development stuff
humble vessel
It is usable, so nothing particular to worry about using Olympus.
You may need to read some manuals to set up the dotnet dev env for mod dev.
I myself amn't C# developer, so I cannot provide too much help.
vernal onyx
👍
silver cloud
Change the `installPath` line to `installPath = "${placeholder "out"}/lib/${pnam...
Will do in a bit
silver cloud
For the comment about aarch being bad platform, you can write "Celeste doesn't s...
right so only platforms.Linux and aarch is bad
humble vessel
No, still platforms.unix.
People cannot build it for darwin anyway because a dependency does not build.
vernal onyx
@humble vessel just switched to nixos and have managed to install everest; but it seems fna3d isn't working:
[microlith57@microlith57-workstation:~/Code/celeste/instances/main]$ ./Celeste
Restarting with LD_LIBRARY_PATH="/home/microlith57/Code/celeste/instances/main/lib64-linux:/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib"...
Vulkan: SDL_Vulkan_LoadLibrary failed!
No supported FNA3D driver found!
--------------------------------
System.InvalidOperationException: No supported FNA3D driver found!
at Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError(IntPtr msg) in /tmp/FNA/src/FNALoggerEXT.cs:line 98
--------------------------------
Detailed exception log:
--------------------------------
(01/02/2025 13:18:01) [Everest] [Info] [EverestSplash] Running splash on EverestSplash421800
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] Unhandled exception. System.Exception: Failed to create renderer!
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] Couldn't find matching render driver
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] at EverestSplash.EverestSplashWindow.Init() in /home/vsts/work/1/s/EverestSplash/EverestSplash.cs:line 271
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] at EverestSplash.EverestSplashWindow..ctor(String targetRendererName, String postFix) in /home/vsts/work/1/s/EverestSplash/EverestSplash.cs:line 231
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] at EverestSplash.EverestSplashWindow.CreateNewWindow(String targetRenderer, String postFix) in /home/vsts/work/1/s/EverestSplash/EverestSplash.cs:line 177
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] at EverestSplash.EverestSplash.CreateWindow(String targetRenderer, String postFix) in /home/vsts/work/1/s/EverestSplash/EverestSplash.cs:line 68
System.InvalidOperationException: No supported FNA3D driver found!
at Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError(IntPtr msg) in /tmp/FNA/src/FNALoggerEXT.cs:line 98
(01/02/2025 13:18:01) [Everest] [Error] [EverestSplash] at EverestSplash.EverestSplash.Main(String[] args) in /home/vsts/work/1/s/EverestSplash/EverestSplash.cs:line 52
Unhandled exception. System.InvalidOperationException: No supported FNA3D driver found!
at Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError(IntPtr msg) in /tmp/FNA/src/FNALoggerEXT.cs:line 98
_IceTransSocketUNIXConnect: Cannot connect to non-local host nixos
_IceTransSocketUNIXConnect: Cannot connect to non-local host nixos
Did you successfully launch Celeste without Everest?
vernal onyx
will check
humble vessel
Then not a problem with Everest. Is the installation managed by Steam?
vernal onyx
nope this is itch
humble vessel
Try nix-shell -p steam-run --run 'steam-run ./Celeste'.
humble vessel
Is ./Celeste a wrapper script?
vernal onyx
yea, i changed it from #!/bin/bash to #!/usr/bin/env bash but otherwise unchanged
humble vessel
Does it have a bundled Mono? Maybe try your system Mono?
vernal onyx
how do i do that? and also i don't think i have a system mono right now
humble vessel
You may need to look into the script to see which mono it uses. For a system Mono, nix-shell -p mono, and you have one.
vernal onyx
the script does not seem to call mono; it just executes ./Celeste.bin.x86_64, which is not a script; i think that's monokickstart
i guess i can run the exe directly with mono?
humble vessel
Maybe.
vernal onyx
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'Celeste.Celeste' threw an exception. ---> System.DllNotFoundException: libSDL2-2.0.so.0 assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) SDL2.SDL.INTERNAL_SDL_GetPlatform()
at SDL2.SDL.SDL_GetPlatform () [0x00000] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Celeste.Celeste..cctor () [0x00006] in <d7b2abb405ec4c97954549f0a02e4a41>:0
--- End of inner exception stack trace ---
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Celeste.Celeste' threw an exception. ---> System.DllNotFoundException: libSDL2-2.0.so.0 assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) SDL2.SDL.INTERNAL_SDL_GetPlatform()
at SDL2.SDL.SDL_GetPlatform () [0x00000] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Celeste.Celeste..cctor () [0x00006] in <d7b2abb405ec4c97954549f0a02e4a41>:0
--- End of inner exception stack trace ---
uhh that means i need to mess with the ld path right?
humble vessel
Maybe steam-run mono xxx.exe.
vernal onyx
System.DllNotFoundException: libFNA3D.so.0 assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) Microsoft.Xna.Framework.Graphics.FNA3D.FNA3D_PrepareWindowAttributes()
at Microsoft.Xna.Framework.SDL2_FNAPlatform.CreateWindow () [0x00000] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Microsoft.Xna.Framework.Game..ctor () [0x000f1] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Monocle.Engine..ctor (System.Int32 width, System.Int32 height, System.Int32 windowWidth, System.Int32 windowHeight, System.String windowTitle, System.Boolean fullscreen, System.Boolean vsync) [0x0000b] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste..ctor () [0x00012] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste.Main (System.String[] args) [0x0012a] in <d7b2abb405ec4c97954549f0a02e4a41>:0
progress i think?
humble vessel
Ah I think steam-run does not have libFNA3D.so.0. Try adding fna3d to nix-ld.
vernal onyx
microlith57@microlith57-workstation:~/Code/celeste/instances/vanilla/ > export NIXPKGS_ALLOW_UNFREE=1; nix-shell -p steam-run -p mono --run "steam-run mono Celeste.exe"
System.DllNotFoundException: libFNA3D.so.0 assembly:<unknown assembly> type:<unknown type> member:(null)
at (wrapper managed-to-native) Microsoft.Xna.Framework.Graphics.FNA3D.FNA3D_PrepareWindowAttributes()
at Microsoft.Xna.Framework.SDL2_FNAPlatform.CreateWindow () [0x00000] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Microsoft.Xna.Framework.Game..ctor () [0x000f1] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Monocle.Engine..ctor (System.Int32 width, System.Int32 height, System.Int32 windowWidth, System.Int32 windowHeight, System.String windowTitle, System.Boolean fullscreen, System.Boolean vsync) [0x0000b] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste..ctor () [0x00012] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste.Main (System.String[] args) [0x0012a] in <d7b2abb405ec4c97954549f0a02e4a41>:0
Just run ./Celeste after you add fna3d to nix-ld packages.
vernal onyx
wait a sec
nix-shell -p steam-run -p mono -p fna3d --run "steam-run ./Celeste"
worked
humble vessel
Good.
vernal onyx
ok working on everest now
microlith57@microlith57-workstation:~/Code/celeste/instances/main/ > export NIXPKGS_ALLOW_UNFREE=1; nix-shell -p steam-run --run "steam-run ./Celeste";
An error occurred while trying to prepare Everest for startup.
Please report this in the Celeste discord server!
(https://discord.gg/celeste, channel #modding_help)
Failed to launch the application binary '/home/microlith57/Code/celeste/instances/main/Celeste.dll':
The call to coreclr_initialize failed.
?
ohh do i need dotnet runtime 7
humble vessel
This error message doesn't seem very helpful.
vernal onyx
yep and there's no log.txt
humble vessel
Everest requires dotnet runtime?
vernal onyx
i mean maybe? worth a try installing it
uhh how do i install 2 dotnet versions
nvm found it in the manual
microlith57@microlith57-workstation:~/Code/celeste/instances/main/ > export NIXPKGS_ALLOW_UNFREE=1; nix-shell -p steam-run --run "steam-run dotnet ./Celeste.dll"
Failed to create CoreCLR, HRESULT: 0x8007000E
If it needs dotnet runtime, it would expect the env var DOTNET_ROOT.
Write this to shell.nix, and run nix-shell:
{ pkgs ? (import <nixpkgs> {}) } : with pkgs; mkShell {
packages = [
fna3d
# ...
];
shellHook = ''
export DOTNET_ROOT=${dotnetCorePackages.runtime_8_0}/share/dotnet
'';
}
If some .so files not found again, you can add export LD_LIBRARY_PATH=${lib.makeLibraryPath [ xxx ]} to shellHook.
vernal onyx
Write this to `shell.nix`, and run `nix-shell`:
```nix
{ pkgs ? (import <nixpkgs...
ok did this; i have a DOTNET_ROOT now; but
[nix-shell:~/Code/celeste/instances/main]$ steam-run ./Celeste
An error occurred while trying to prepare Everest for startup.
Please report this in the Celeste discord server!
(https://discord.gg/celeste, channel #modding_help)
Failed to launch the application binary '/home/microlith57/Code/celeste/instances/main/Celeste.dll':
The current state is incompatible with the requested operation.
[nix-shell:~/Code/celeste/instances/main]$ steam-run dotnet ./Celeste.dll
Failed to create CoreCLR, HRESULT: 0x8007000E
What is CoreCLR?
vernal onyx
.net core common language runtime
it's weird because i could run miniinstaller but not celeste apparently
actually @hearty palm do you know anything about this?
humble vessel
I didn't buy Celeste on itch.io, but I downloaded one from a fishy source. It just runs fine with steam-run.
And I can install Everest and run it fine with steam-run, too.
vernal onyx
what command specifically?
will try with steam
humble vessel
The command is steam-run ./Celeste.
vernal onyx
hmm
vernal onyx
itch
vernal onyx
? yes you do?
i downloaded the linux release from the itch.io website, which i can do because i own the game on itch
humble vessel
No I mean the file format.
humble vessel
Oh so sad because the fishy source gives me a 7z. If it is the same format I can compare it with yours by hash.
vernal onyx
ah
vernal onyx
@humble vessel ok so i think the problem is steam-run actually; miniinstaller crashes with the same error when i run it through steam-run dotnet, but succeeds with plain dotnet
[nix-shell:~/Code/celeste/instances/main]$ dotnet Celeste.dll
Restarting with LD_LIBRARY_PATH="/home/microlith57/Code/celeste/instances/main/lib64-linux:/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib"...
Vulkan: SDL_Vulkan_LoadLibrary failed!
No supported FNA3D driver found!
--------------------------------
System.InvalidOperationException: No supported FNA3D driver found!
at Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError(IntPtr msg) in /tmp/FNA/src/FNALoggerEXT.cs:line 98
however ^ there seems to be still some ld problems
891541: find library=libGL.so.1 [0]; searching
891541: search path=/home/microlith57/Code/celeste/instances/main/lib64-linux:/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib:/run/current-system/sw/share/nix-ld/lib (LD_LIBRARY_PATH)
891541: trying file=/home/microlith57/Code/celeste/instances/main/lib64-linux/libGL.so.1
891541: trying file=/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib/libGL.so.1
891541: trying file=/run/current-system/sw/share/nix-ld/lib/libGL.so.1
891541: search cache=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/etc/ld.so.cache
891541: search path=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib:/nix/store/2d5spnl8j5r4n1s4bj1zmra7mwx0f1n8-xgcc-13.3.0-libgcc/lib (system search path)
891541: trying file=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libGL.so.1
891541: trying file=/nix/store/2d5spnl8j5r4n1s4bj1zmra7mwx0f1n8-xgcc-13.3.0-libgcc/lib/libGL.so.1
891541: find library=libOpenGL.so.0 [0]; searching
891541: search path=/home/microlith57/Code/celeste/instances/main/lib64-linux:/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib:/run/current-system/sw/share/nix-ld/lib (LD_LIBRARY_PATH)
891541: trying file=/home/microlith57/Code/celeste/instances/main/lib64-linux/libOpenGL.so.0
891541: trying file=/nix/store/04c8gw62pbskgnb61f63w7ji8vafs87n-libdbusmenu-glib-16.04.0/lib/libOpenGL.so.0
891541: trying file=/run/current-system/sw/share/nix-ld/lib/libOpenGL.so.0
891541: search cache=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/etc/ld.so.cache
891541: search path=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib:/nix/store/2d5spnl8j5r4n1s4bj1zmra7mwx0f1n8-xgcc-13.3.0-libgcc/lib (system search path)
891541: trying file=/nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libOpenGL.so.0
891541: trying file=/nix/store/2d5spnl8j5r4n1s4bj1zmra7mwx0f1n8-xgcc-13.3.0-libgcc/lib/libOpenGL.so.0
got these from LD_DEBUG=libs ^
humble vessel
Interesting. Could you try disabling nix-ld?
Disable nix-ld and only use steam-run.
vernal onyx
like globally disable it?
nope still fails, doesn't even launch coreclr
same 0x8007000E hresult; which i am told is an OOM / other 'out of resource'
humble vessel
Hah? Out of resource? So is any resource running out?
vernal onyx
no, that's the thing. and again, miniinstaller runs fine in dotnet and fails with that hresult in steam-run dotnet
humble vessel
My nix-ld is like this.
programs.nix-ld = {
enable = true;
libraries = with pkgs; [
stdenv.cc.cc
zlib
fuse3
icu
zlib
nss
openssl
curl
expat
ncurses
];
};
Just for reference, because I don't think nix-ld is the problem.
vernal onyx
```
[nix-shell:~/Code/celeste/instances/main]$ dotnet Celeste.dll
Restarting wit...
well, what is the problem here?
humble vessel
Could you share your nix-info -m?
vernal onyx
- system: `"x86_64-linux"`
- host os: `Linux 6.6.68, NixOS, 24.11 (Vicuna), 24.11.712148.edf04b75c13c`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.24.11`
- channels(root): `"home-manager-24.11.tar.gz, nixos-24.11"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`
Got no idea now.
vernal onyx
934895: /home/microlith57/Code/celeste/instances/main/lib64-linux/libSDL2.so: error: symbol lookup error: undefined symbol: udev_device_get_action (fatal)
934895: /home/microlith57/Code/celeste/instances/main/lib64-linux/libSDL2.so: error: symbol lookup error: undefined symbol: _udev_device_get_action (fatal)
ok what about this
found in the ld log just before the error
humble vessel
This is even more confusing.
vernal onyx
https://github.com/libsdl-org/SDL/issues/4879 may be relevant?
humble vessel
Oh, so it just means udev is missing.
vernal onyx
how do i get that? i'm currently in the middle of installing nix-index so will know the package name shortly but if you know it already then i can shortcut that
humble vessel
nix run github:nix-community/nix-index-database xxx.so
Use this command. Very convenient.
vernal onyx
[microlith57@microlith57-workstation:~/Code/celeste/Everest]$ nix --extra-experimental-features nix-command --extra-experimental-features flakes run github:nix-community/nix-index-database libudev.so
error: builder for '/nix/store/mmfj2aq0jx72grj8z770yd2nrzhsriwn-index-x86_64-linux.drv' failed with exit code 1;
last 13 log lines:
> structuredAttrs is enabled
>
> trying https://github.com/nix-community/nix-index-database/releases/download/2024-12-29-031725/index-x86_64-linux
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
...
> Warning: Problem : timeout. Will retry in 4 seconds. 1 retries left.
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: github.com
> error: cannot download index-x86_64-linux from any mirror
For full logs, run 'nix-store -l /nix/store/mmfj2aq0jx72grj8z770yd2nrzhsriwn-index-x86_64-linux.drv'.
error: 1 dependencies of derivation '/nix/store/cv11ydjv7wxm756lnz74xb7mpdgg4xfy-nix-index-database.drv' failed to build
error: 1 dependencies of derivation '/nix/store/m2nkid7h2kqz2fbn1slhd6dnix8lllgp-nix-index-with-full-db-0.1.8.drv' failed to build
oh that's probably my fault
uhh will wait for github:nix-community/nix-index#nix-index to finish cooking before fixing that
humble vessel
Actually, does Everest require the Celeste installation dir be writable? If not, then I may try to directly package Celeste with Everest.
vernal onyx
for updates, yes; also log.txt goes there
also mods folder etc
in theory those things could be configurable though
would it be possible to symlink / make editable those things though?
regardless idk how packaging celeste would work since it's copyrighted
humble vessel
For log.txt, wouldn't it make more sense for it to go to ~/.local/share/Celeste?
humble vessel
regardless idk how packaging celeste would work since it's copyrighted
It is fine. For example Mathematica is packaged on nixpkgs.
vernal onyx
fine as in nixpkgs accepts it, or fine as in it would require a purchase?
humble vessel
User just need to manually put necessary file in nix-store.
vernal onyx
i mean technically the drm can be removed from a drm copy (as eg. a miniinstaller step); and i think this would be acceptable if used for non-piracy reasons
i own both steam and itch copies so could diff them. not epic though
humble vessel
also mods folder etc
I mean we can make that declarable, like
{
# ...
withEverest ? false,
mods ? [],
} :
...
true actually
humble vessel
But the thing is does mod zip files just got extracted in the installation folder?
If yes, then the installation dir needs to be writable.
vernal onyx
mod zip files go unmodified into the mods folder (still zipped). they can be symlinked i believe
humble vessel
Link to where?
vernal onyx
well whereever really
humble vessel
What does the dir Mods/Cache do?
vernal onyx
cache for relinked assemblies & some fmod stuff
humble vessel
Can it be populated before launching Celeste so that it doesn't need to be writable?
vernal onyx
nope
since everest has the ability to install/update mods; and that triggers relinking
also the relinker is currently part of everest itself, not a separate application; and it would be tricky to separate
humble vessel
If the mods are declaratively managed using nix, user cannot use Everest to install mods anyway, but I can see it is still hard.
Maybe we need to modify Everest to use ~/.cache instead.
vernal onyx
hmm maybe
humble vessel
Or maybe we let it use somewhere like $EVEREST_CACHE_DIR/Mods.
vernal onyx
yea that'd be nice
humble vessel
Gah, but if I want to manage mods using nix, basically I have to reimplement mons. Seems like an awful lot of work.
vernal onyx
see #1323569287524519979 ; might be useful as a backend
there's no actual implementation yet but the idea is there
humble vessel
Oh actually I can just use mons at build phase.
Oh never mind. The build phase cannot have access to internet.
vernal onyx
i think mons is broken at the moment actually?
humble vessel
Yes.
And there is currently no PR fixing the situation.
And coloursofnoise is not responding to anything, neither GitHub issue nor Discord ping.
vernal onyx
unfortunately only colours has pypi access so we can't do much about that
humble vessel
Actually, since basically Mods is the only dir that needs writing, it would make sense to allow using some env var like $EVEREST_MODS_DIR to control where it is so that it can be somewhere writable.
And then I don't need to worry about declaratively installing mods because that dir is managed outside nix store.
humble vessel
There are three ways:
- Fetch MiniInstaller from Azure pipeline and run it.
- Fetch the source codes of Everest and then build MiniInstaller and then run it.
- Reimplement MiniInstaller.
humble vessel
1 would be easiest, but 2 and 3 are better because fetching source code is always preferred over fetching binary (though the reason is very weak in this case because Celeste is proprietary in the first place).
vernal onyx
then 2
humble vessel
Yeah my thoughts too. I need to look into how to do that.
vernal onyx
i mean i am pretty close to getting it building from source; #modding_dev message
ofc i was doing that before switching to nixos
humble vessel
Hmm, I thought building it on ordinary Linux distros should be easy because it's basically copying commands from the Azure pipeline definition.
vernal onyx
should be yes
humble vessel
It's been late in my time zone, and I need to get shower and sleep.
Wish you good luck on getting Everest working.
vernal onyx
oh sure go ahead
thanks :3
humble vessel
i mean technically the drm can be removed from a drm copy (as eg. a miniinstalle...
It will work as long as the hash matches. Or if the hash doesn't match but you're sure it'd work, just override the hash to let nix accept it.
vernal onyx
ok cool
humble vessel
Actually, since basically `Mods` is the only dir that needs writing, it would ma...
It would be good if one can configure that on Olympus for each installation.
Then different installations can amazingly share mods.
vernal onyx
@humble vessel added libGL to my ld libraries, and it gets to loading now! doesn't seem to create a window though
like. it just stops at "done loading" and doesn't create a window
ivory bloom
--headless 2.0
humble vessel
like. it just stops at "done loading" and doesn't create a window
Is there sound?
vernal onyx
not that i remember, will check
humble vessel
Does the zip downloaded from itch.io contain a single top level dir that has the installation dir structure, or directly contains the installation dir structure at top level?
humble vessel
And what's the filename of the zip?
vernal onyx
celeste-linux.zip; can get a hash if you want
vernal onyx
Is there sound?
nope
it does log INFO: SDL_INIT_AUDIO failed: dsp: No such audio device but no such failure for window creation
humble vessel
Could you tell me the hash by running this?
nix-hash --flat --sri --type sha256 $(nix-store --add-fixed sha256 celeste-linux.zip)
sha256-q4gniSgg00U3j5TZpvIZnSmqAyCHd/pOVAuQ3rDYEAs=
humble vessel
if (File.Exists("BuildIsXNA.txt"))
File.Delete("BuildIsXNA.txt");
if (File.Exists("BuildIsFNA.txt"))
File.Delete("BuildIsFNA.txt");
// we cannot use Everest.Flags.IsFNA at this point because flags aren't initialized yet.
File.WriteAllText($"BuildIs{(typeof(Game).Assembly.FullName.Contains("FNA") ? "FNA" : "XNA")}.txt", "");
@frank barn Can this be changed so that it avoids deleting the existing file? Like this:
File.WriteAllText("Build.txt", (typeof(Game).Assembly.FullName.Contains("FNA") ? "FNA" : "XNA"))
This is because the installation dir needs to be read-only on NixOS. I can work around writing to an existing file by making it a symlink, but I cannot work around creating/deleting a file directly under the installation dir.
Or maybe at least don't delete the existing file if the build type matches the existing file. This way it is backward compatible.
vernal onyx
...i mean it should always be fna now right?
vast stratus
unsure about legacyref, but probably it can be forced to use fna as well
(or we could get rid of it 
)
humble vessel
OK, if this error is fixed, the packaging of Everest would be a success.
Currently it gets running on the Azure build result of my PR.
However, this build result will get cleaned up after 10 days, so it cannot be a proper solution.
Also downloading dependency in Everest would fail because it tries to download to dependency-download.zip directly under the game installation dir.
How come Olympus cannot manage dependencies??
Everything else works fine. One can manage mods and launch game with Olympus.
It would be better if Everest uses $(mktmp -d) for dependency-download.zip and FileProxyStreamDummy.txt etc instead.
Or maybe uses an env var like $EVEREST_TMPDIR?
humble vessel
Added a commit to the PR for that, and now it's perfect.
humble vessel
Yeah my thoughts too. I need to look into how to do that.
Met with difficulty because of this bug.
humble vessel
Oh, it seems that just disabling debug mode in mod options will make it disappear. The term "Debug Build" is misleading me to think that whether it is debug build is determined when it was built.
humble vessel
@vernal onyx Try this. Change the two paths according to your needs. After build success, run result/bin/celeste.
NIXPKGS_ALLOW_INSECURE=1 NIXPKGS_ALLOW_UNFREE=1 nix build --impure --print-build-logs --expr 'with import (fetchTarball https://github.com/UlyssesZh/nixpkgs/tarball/celeste) {}; celestegame.override { everest = celestegame.everest; writableDir = "/home/ulysses/test/celeste/writable"; gameDir = "/home/ulysses/test/celeste/game"; }'
thats inherited from vanilla i believe :P
runic heron
```
[microlith57@microlith57-workstation:~/Code/celeste/instances/main]$ ./Celes...
I'm on NixOS aarch64 and used Celeste-ARM64 repo to get the required libraries. I then changed the above nix files to allow aarch64 and have mono and tried without everest.
I get the same error as the person I replied to:
Current directory: /lib/Celeste
Vulkan: SDL_Vulkan_LoadLibrary failed!
No supported FNA3D driver found!
System.InvalidOperationException: No supported FNA3D driver found!
at Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError (System.IntPtr msg) [0x00012] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at (wrapper native-to-managed) Microsoft.Xna.Framework.FNALoggerEXT.FNA3DLogError(intptr)
at (wrapper managed-to-native) Microsoft.Xna.Framework.Graphics.FNA3D.FNA3D_PrepareWindowAttributes()
at Microsoft.Xna.Framework.SDL2_FNAPlatform.CreateWindow () [0x00000] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Microsoft.Xna.Framework.Game..ctor () [0x000f1] in <4c19a1a736204d189ba94c3bc07cd4ac>:0
at Monocle.Engine..ctor (System.Int32 width, System.Int32 height, System.Int32 windowWidth, System.Int32 windowHeight, System.String windowTitle, System.Boolean fullscreen, System.Boolean vsync) [0x0000b] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste..ctor () [0x00012] in <d7b2abb405ec4c97954549f0a02e4a41>:0
at Celeste.Celeste.Main (System.String[] args) [0x0012a] in <d7b2abb405ec4c97954549f0a02e4a41>:0
Any clue as to why by any chance?
The script is running the exe with mono (while changing LD_LIBRARY_PATH to the path containing the Celeste-ARM libraries).
humble vessel
I don't have ARM device.
frank barn
do you think I can merge dev into stable? or would you like me to wait?
humble vessel
do you think I can merge dev into stable? or would you like me to wait?
Thank you for asking my opinion, but I don't quite understand. Wait for what?
frank barn
Merging main into stable, aka releasing a new stable Olympus version with Olympus.Sharp running on .NET 8 instead of Mono
humble vessel
Ah I see. I think you can suit yourself on that matter. The packaging on nixpkgs is following the main branch, so it doesn't matter.
Could you please look at my PR to Everest? Sorry for bothering, but I am asking again in case you missed it.
hearty palm
The patch in Everest.Updater is definitely unnecessary, that's for legacyref installs
Also you definitely want to disable automatic update checks in that scenario
Tbh I have doubts about packaging Everest up like this; Everest updates frequently, and mods aren't good at explicitly declaring which version they need, so frequently updating is something which is widely recommended
Additionally, this PR doesn't seem to address the mod cache folder (located in Mods/Cache) at all, which is fairly critical for Everest to work
You could theoretically disable the cache, but that means startup will take minutes every time, and some code paths (like native libs and maybe audio banks as well) actually require having a cache, so I'm almost certain things will break
This also ignores mods which might assume that the Celeste directory is writable; one example that comes to mind is CelesteTAS, which (afaik) downloads and unpacks the studio binaries into the Celeste folder
You could technically work around all of this, but I'm almost certain that it will be fairly hacky, and that no one here wants to be responsible for maintaining things long-term
So I'm unsure whether we want to support such a use case at all, considering the incredibly small niche this is for
humble vessel
Frequent update isn't a very bad issue because the source can be easily overridden, and I will also write an update script to make sure nixpkgs will not fall behind too much.
Mods/Cache is fine because Mods is writable (symlink to user specified path).
The mods that assume Celeste dir is writable will be a problem.
hearty palm
I'm still against supporting this use case officially
And I'm not sure I would want to see something like this in nixpkgs, since that implies a level of support which is simply not given
humble vessel
This is a common thing that happens in nixpkgs. Some developers express that they don't want to support users that use the packaged version in nixpkgs, and nixpkgs maintainers respect that by including an indication of "this is a NixOS specific version of the software" somewhere (e.g. the "nixos" in the version name, which I did for both Olympus and Everest), so that when users report a problem to the dev with some log, the dev can see they are using the NixOS version and refuse to support.
Also technically the open source license permits copying and distributing, so the developer cannot stop nixpkgs from including the package.
hearty palm
I mean you're free to do whatever with the source code, but we're also free to say "we don't wanna support immutable Celeste installs since that invalidates an implicit assumption made by everyone in the past"
Obviously I'm not speaking for the entire team here, but I would not be on the side of supporting this
humble vessel
https://github.com/NixOS/nixpkgs/pull/288841/files#diff-57b1fb31cec230df8ba1dc5598d34cc56fd6e7317f5196d2be4bf35f3d762b70
Possibly I can do something like this.
To patch the support or bug report URL.
silver cloud
Merging main into stable, aka releasing a new stable Olympus version with Olympu...
Yep, it should be fine as it has been changed to work with .Net 8 already
spark kayak
I dont know if this solves/helps with the celeste install being read only, but everest apparently supports placing Everest files in ~/.local/share/Everest
Its trigged by a certain file existing
Not sure if that is useful, just pointing it out 
humble vessel
Oh thank you. I didn't know that. It can help.
hearty palm
I dont know if this solves/helps with the celeste install being read only, but e...
I have never encountered that in the codebase
Where do you have that from?
spark kayak
I have never encountered that in the codebase <:thinkeline:410534291462815745>
...
Got curios how PathGame and PathEverest differ and which one i should use for studio
hearty palm
Isn't PathEverest some legacy cruft which is still around?
Or am I mixing things up
(might be mixing up things with MiniInstaller path comments)
spark kayak
I dont know. I dont think there were an comments about legacy / deprecated
Iirc the file it checks is called XDG something
hearty palm
Seems like all that was added here: https://github.com/EverestAPI/Everest/pull/29
7 years ago
I doubt anyone has touched / used this since then
I don't see a reason why it shouldn't work, but I wouldn't bet on it working either
vast stratus
it seems like it is used for some stuff, but PathGame is used for everest stuff too, which makes it less cool
hearty palm
Can we just do an Everest 2.0 at this point?
vivid cloak
just installed Olympus on NixOS using the nixpkgs PR, it was much more simple and straightforward than I expected (considering I am beginner with nix)
Thank you to all the contributors
silver cloud
just installed Olympus on NixOS using the nixpkgs PR, it was much more simple an...
glad to hear it
Just wanna note that if you wanna launch it using the button in Olympus you have do use a small override
If you're using steam it should have 0 issues
vivid cloak
I did have a tiny issue where rebuilding my OS always showed me a warning starting with evaluation warning: getExe: Package "olympus-miniinstaller-fhs-24.12.28.01" does not have the meta.mainProgram attribute.
Seems to have gone away once i simply added meta.mainProgram = "olympus-miniinstaller-fhs";, not sure if that was the right solution but it worked
humble vessel
This is a warning that you can safely ignore. It will go away in a future update of your system nixpkgs.
neat rampart
Came across this after trying to get the old olympus flake to work for a while... Great work and I can't wait to see this get merged. What are the next steps here before merging this?
humble vessel
Basically nothing. You can react to the PR with a thumb up emoji.
neat rampart
Thats very exciting! Hope it is merged soon!
eager flint
we'll get there one day
eager flint
but i switched to NixOS recently and thanks for the pr it works great 
tepid dove
Is there an way to reliably install Olympus on Nixos?
humble vessel
Use the olympus package from a specific commit of petingoso's fork of nixpkgs. This should avoid almost any future breakage and is immune to regression (hopefully).
tepid dove
I have never heard on petingoso's fork of nixpkgs, I didn't know it was a thing, and google doesn't know this fork. What to google in order to find it?
humble vessel
Ah it is a clear thing in the context of this thread, but you are new here. See PR 309327 of nixpkgs on GitHub.
tepid dove
I found the repo
But I couldn't find olympus and I and even if, dose this explanation is the best way to add the package? https://nixos.wiki/wiki/Flakes#Importing_packages_from_multiple_channels
humble vessel
Write inputs.nixpkgs-olympus.url = "github:Petingoso/nixpkgs/<commit>", and then you can use olympus package from that input.
If you don't use flakes, you can just use nixpkgs-olympus = (import (fetchTarball https://github.com/Petingoso/nixpkgs/tarball/<commit>) { config = config.nixpkgs.config; }); in configuration.nix, and then just add nixpkgs-olympus.olympus to your packages.
silver cloud
You can
- do that and have my nixpkgs
- create an overlay (google has how to do that)
- copy the files locally and use a callPackage directive
Maybe I should make a flake for easier access for people?
tepid dove
Personally, I am trying to avoid flakes when ever I can so if there is a way to improve the situation without it (or home manager) I am all for it
tepid dove
If you don't use flakes, you can just use `nixpkgs-olympus = (import (fetchTarba...
I tried to add nixpkgs-olympus = (import (fetchTarball https://github.com/Petingoso/nixpkgs/tarball/<commit>) { config = config.nixpkgs.config; }); in configuration.nix, and then just add nixpkgs-olympus.olympus
and it returned the error:
error: Failed to open archive (Source threw exception: error: unable to download 'https://github.com/Petingoso/nixpkgs/tarball/': HTTP error 404
response body:
Not Found)
and: while evaluating the error message for definitions for `nixpkgs-olympus', which is an option that does not exist
humble vessel
You need to define the variable nixpkgs-olympus in a say let ... in block to make it available.
tepid dove
Write `inputs.nixpkgs-olympus.url = "github:Petingoso/nixpkgs/<commit>"`, and th...
I feel bad from the possibility that my questions are too "general nix" and not Celeste specific, but I just want my mods! So let's stick to flakes.
I added inputs.nixpkgs-olympus.url = "github:Petingoso/nixpkgs/olympus";
What about the output?
What about configuration.nix?
silver cloud
I feel bad from the possibility that my questions are too "general nix" and not ...
output is something else in flake.nix
if your config now has that as an input you can now access its properties
like
{config,inputs}: {(you might need to pass inputs as a special parameter depending on file)
let nixpkgsOlympus = import inputs.nixpkgs-olympus;
{
home.packages = with nixpkgsOlympus [ olympus];
}
}
it will not exactly be this but it should of the sort
tepid dove
I want to thank you guys for your help and to mention that Flathub managed to make the installation easy
azure hound
this post was helpful because it taught me the actual executable is patched and the original executable remains at orig/Celeste. I was looking for a solution to launch with steam-run but i no longer need such options because I can just run with Steam. I am using #309327 fyi.
silver cloud
If you want you can use that PR with steam run, you just need to override the package with celesteWrapper = pkgs.steam-run iirc
silver cloud
Well, people probably got the email but just wanna finally say its merged , thank you everyone
humble vessel
I wanted to react with 🎉 but just recalled that this channel didn't allow emoji reaction.
vast stratus
you can now 
magic cradle
you're supposed to replace the commit hash
do you need to keep updating it with the newest one? is there no better way
humble vessel
It is merged now. Just use nixpkgs.
subtle stump
im using the nixpkgs package, and i can't launch Everest or Celeste through Olympus at all.
/nix/store/q4z2cwi1zdrn1s5qhn8lhrgzbs90n52y-olympus-unwrapped-25.10.15.03/lib/olympus
[sharp] New TCP connection: 127.0.0.1:51524
[sharp] Executing setolympusversion
[sharp] Executing getversionstring
[sharp] Executing getrunningpath
[sharp] Executing getmodidtonamemap
[CmdGetIdToNameMap] Cache location set to: /home/lukasd/.config/Olympus/cached-mod-ids-to-names.json
[CmdGetIdToNameMap] Loading mod IDs from maddie480.ovh
[sharp] Executing launch
Starting Celeste process: /home/lukasd/Games/SteamLibrary/steamapps/common/Celeste/Celeste (without args)
chmod: changing permissions of '/nix/store/q4z2cwi1zdrn1s5qhn8lhrgzbs90n52y-olympus-unwrapped-25.10.15.03/lib/olympus/suppress-output': Read-only file system
[sharp] Executing launch
nextLaunchIsVanilla.txt created
Starting Celeste process: /home/lukasd/Games/SteamLibrary/steamapps/common/Celeste/Celeste (without args)
chmod: changing permissions of '/nix/store/q4z2cwi1zdrn1s5qhn8lhrgzbs90n52y-olympus-unwrapped-25.10.15.03/lib/olympus/suppress-output': Read-only file system
Did you set celesteWrapper?
subtle stump
No, what is that?/what do i set
humble vessel
olympus.override { celesteWrapper = "steam-run"; }
I just added a page on NixOS Wiki for Celeste. Can someone with permissions pin it in this thread?
vernal onyx
https://wiki.nixos.org/wiki/Celeste
the "celestegame" link in this section seems to be broken; it definitely exists in nixpkgs so not sure what's going on there
vernal onyx
I just added a page on NixOS Wiki for Celeste. Can someone with permissions pin ...
<@&673384065327431700>
bronze umbra
https://wiki.nixos.org/wiki/Celeste
humble vessel
the "[celestegame](<https://search.nixos.org/packages?show=celestegame>)" link i...
Click on unstable.
vernal onyx
unstable is selected
humble vessel
Huh, not sure what happened. It worked when I wrote this.
Let me check for something.
vernal onyx
well if the package itself works i guess it's kind of fine? 
vernal onyx
seems to be known but with an unknown cause: https://github.com/NixOS/nixos-search/issues/1073
humble vessel
8 hours ago, so new.
humble vessel
`sha256-q4gniSgg00U3j5TZpvIZnSmqAyCHd/pOVAuQ3rDYEAs=`
It was updated in April last year. Could you share the new hash?
vernal onyx
It was updated in April last year. Could you share the new hash?
sha256-phNDBBHb7zwMRaBHT5D0hFEilkx9F31p6IllvLhHQb8=
humble vessel
@vernal onyx Thank you. Could you also share the results of sha256sum lib/* lib64/* after you unzip it?
vernal onyx
sure one sec
```
513ba9f97a8af0f5fe7ab9c53efa27c8d7cd29271e3657f47670edffd7eecd25 lib/libSDL2-2.0.so.0
78d550e671f0916de6dd2a2ed0f1e49a8807d1e1f57c2ca2dd681d202e68d6e5 lib/libSDL2_image-2.0.so.0
c1cc6957f82b1d72b6422848bdf0b2cbd387ca5e683a56869be601cb986767e6 lib/libfmod.so.10
b232d339e2a93d04e170f99117ea4ae96bd59e2b07932dff1fe5e3172828ad2d lib/libfmod_SDL.so
5bd8f09efb74c6699aa8baccd27745a6668618f09f197b2de95183fb9c1e1177 lib/libfmodstudio.so.10
c55cceb92918da487fd12df710a690795a7c872ff4408648a43d19c5ab72321d lib/libmojoshader.so
8d3d3d37f6b004a6b5bcab7c9343fe28e01adfd71c5d9b7c02769616cad380d9 lib/libpng15.so.15
547990f643e09bf4ab68c755f89dad7548b8d07803a843c2e18c08ef2e9d3300 lib64/libFNA3D.so.0
33ad36b9505c8bad96931c6fc1392ef4f38ab589baa097015b5a743d1ab0dd5f lib64/libSDL2-2.0.so.0
affd4c117ab4064d861fcdea291c13cd1edab953556c03c2a0c54e9c9ebfdca7 lib64/libfmod.so.10
a566787abc02ee24a24e5f04555958b795fbc43dec2cd36d54c15d4f09338231 lib64/libfmod_SDL.so
2db1a3877b3ad89990ba7d690171db3b06e402735acd2c3eb9f5f2676aa5536d lib64/libfmodstudio.so.10
So the only thing that changed is lib64/libfmod.so.10, I see.
pliant acorn
New and unsure if I should be posting here, but i tried booting up the game today for the first time in a while (iirc last time i exited the game after updating everest) and got hit with a persistent System.DllNotFoundException: Unable to load shared library 'fmodstudio' or one of its dependencies.
(installed and running celeste through plain old steam which i got from programs.steam.enable = true;
humble vessel
Update the vanilla version.
If you run through Steam, it is probably not related to NixOS specifically.
pliant acorn
wdym update the vanilla version?
humble vessel
Vanilla Celeste got an update in April last year.
pliant acorn
(admittedly i think ive gaslit myself into assuming every "missing .so" error is a nixos problem)
humble vessel
And that update solves this problem you met with.
pliant acorn
steam doesn't seem to show any pending updates
i think i installed the update
i did notice that my libfmodstudio.so was inside the steamapps/common/Celeste/lib64/ which is absent from the list of folders that the error log says it searched
pliant acorn
i think i installed the update
actually steam doesnt list any updates from last year
if this is not a nixos issue should i open a new thread?
humble vessel
The correct way of doing this would be to reinstall Celeste, though that would mean you would lose all the mods and you need to install all of them again.
However I know a shortcut that you can take, no warranty though.
pliant acorn
do tell
pliant acorn
The correct way of doing this would be to reinstall Celeste, though that would m...
cant i just copy out Mods/*.zip
humble vessel
patchelf --clear-execstack lib64/libfmod.so.10
Yeah you can do that if you didn't delete them.
pliant acorn
hmm i will backup my celeste folder before doing that i think
humble vessel
You only need to back up lib64/libfmod.so.10.
Hmm maybe lib64-linux instead of lib64.
humble vessel
Oh right the NixOS one does not have that, but the Arch one does have it.
Never mind then just reinstall.
humble vessel
Actually it does have --clear-execstack, but I don't know why what went wrong.
https://github.com/NixOS/patchelf/blob/0.18.0/tests/modify-execstack.sh#L132-L135
But you are probably not interested about this now.
pliant acorn
oh pkgs.patchelf is just really old i think
theres patchelfUnstable that probably has it
awesome, it works!
humble vessel
Good to hear that.
pliant acorn
(first time launching celeste in ages with no mods, i miss how fast it loads...)
ty for the help
silver cloud
ty for the help
I know this person 