celeste64: add package

[itslychee]

Description of changes

Packages https://github.com/ExOK/Celeste64

This is the source code and general information for Celeste 64: Fragments of the Mountain, a game made by the original Celeste developers in under 2 weeks for Celeste's 6th Anniversary. We haven't done a lot of 3D development so much of this is not very optimized, it's coded in libraries mostly intended for 2D games, and we put it all together very, very quickly. Consider this similar to a weekend jam game, so experiment and learn at your own risk!

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[NobbZ]

Result of nixpkgs-review pr 285232 run on x86_64-linux 1

1 package built:

• celeste64

[NobbZ]

Sadly this host does not enable me to actually run the package under test, as it fails with GLX related errors, I assume this is to the fact that this is not NixOS and I do not use NixGL.

[Henry-Hiles]

LGTM

[puzzlewolf]

Result of nixpkgs-review pr 285232 run on x86_64-linux 1

1 package built:

• celeste64

It builds successfully, but the binary segfaults for me :(

$ nix-shell -p nixpkgs-review --run "nixpkgs-review pr --print-result 285232"
$ ./results/celeste64/bin/Celeste64 
Celeste 64 v.0.2024.1
Foster: v0.1.14
Platform: NixOS 23.11 (Tapir) (X64)
Framework: .NET 8.0.1
SDL: v2.28.5
Segmentation fault (core dumped)

output of coredumpctl:

           PID: 27615 (Celeste64)
           UID: 1000 (nora)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Thu 2024-02-01 23:04:37 CET (15min ago)
  Command Line: /nix/store/p6knlm12x276h3hq90lx50fnv5a01cl6-celeste64-0-unstable-2024-01-31/lib/celeste64/Celeste64
    Executable: /nix/store/p6knlm12x276h3hq90lx50fnv5a01cl6-celeste64-0-unstable-2024-01-31/lib/celeste64/Celeste64
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (nora)
       Boot ID: b277d87b13fa47e9a07ec667aea57729
    Machine ID: 6051726aa06a4896b720e8ea711527fe
      Hostname: taschenrechner
       Storage: /var/lib/systemd/coredump/core.Celeste64.1000.b277d87b13fa47e9a07ec667aea57729.27615.1706825077000000.zst (present)
  Size on Disk: 4.6M
       Message: Process 27615 (Celeste64) of user 1000 dumped core.                
                Module libpciaccess.so.0 without build-id.
                Module libxml2.so.2 without build-id.
                Module libncursesw.so.6 without build-id.
                Module libffi.so.8 without build-id.
                Module libdrm_intel.so.1 without build-id.
                Module libdrm_nouveau.so.2 without build-id.
                Module libdrm_amdgpu.so.1 without build-id.
                Module libelf.so.0 without build-id.
                Module libdrm_radeon.so.1 without build-id.
                Module libsensors.so.5 without build-id.
                Module libzstd.so.1 without build-id.
                Module libz.so.1 without build-id.
                Module libxcb-xfixes.so.0 without build-id.
                Module libxcb-sync.so.1 without build-id.
                Module libxcb-present.so.0 without build-id.
                Module libxcb-dri3.so.0 without build-id.
                Module libxcb-randr.so.0 without build-id.
                Module libxshmfence.so.1 without build-id.
                Module libexpat.so.1 without build-id.
                Module libxcb-shm.so.0 without build-id.
                Module libXxf86vm.so.1 without build-id.
                Module libxcb-dri2.so.0 without build-id.
                Module libX11-xcb.so.1 without build-id.
                Module libxcb-glx.so.0 without build-id.
                Module libdrm.so.2 without build-id.
                Module libGLdispatch.so.0 without build-id.
                Module libGLX.so.0 without build-id.
                Module libGL.so.1 without build-id.
                Module libcap.so.2 without build-id.
                Module libudev.so.1 without build-id.
                Module libXrandr.so.2 without build-id.
                Module libXi.so.6 without build-id.
                Module libXfixes.so.3 without build-id.
                Module libXrender.so.1 without build-id.
                Module libXcursor.so.1 without build-id.
                Module libXext.so.6 without build-id.
                Module libXdmcp.so.6 without build-id.
                Module libXau.so.6 without build-id.
                Module libxcb.so.1 without build-id.
                Module libX11.so.6 without build-id.
                Module liburcu-common.so.8 without build-id.
                Module liburcu-cds.so.8 without build-id.
                Module liburcu-bp.so.8 without build-id.
                Module libnuma.so.1 without build-id.
                Module liblttng-ust-tracepoint.so.0 without build-id.
                Module liblttng-ust.so.0 without build-id.
                Module libicudata.so.73 without build-id.
                Module libicuuc.so without build-id.
                Module libicui18n.so without build-id.
                Module libgcc_s.so.1 without build-id.
                Module libstdc++.so.6 without build-id.
                Stack trace of thread 27615:
                #0  0x0000000000000000 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64

Also, both ./results/celeste64/bin and ./results/celeste64/lib/celeste64 contain both a binary and .so files. Is it supposed to be like that? Don't usually binaries go in ./bin and shared objects in ./lib?

[itslychee]

Also, both ./results/celeste64/bin and ./results/celeste64/lib/celeste64 contain both a binary and .so files. Is it supposed to be like that? Don't usually binaries go in ./bin and shared objects in ./lib?

I believe that's a quirk with buildDotnetModule as the documentation implies that this is its intended purpose, but I do believe after re-reading it I should be using executables = [ ... ]

Unsure of why you're getting that error because most of those dependencies should be accounted for in runtimeDeps

[eclairevoyant]

Runs fine on my end, some feedback below

[puzzlewolf]

I updated my system. Sadly, Celeste64 still segfaults. I noticed the following lines in the journal

Feb 02 16:47:50 taschenrechner kernel: Celeste64[28960]: segfault at 0 ip 0000000000000000 sp 00007ffe47cf1168 error 14 in Celeste64[55c403776000+7000] likely on CPU 7 (core 3, socket 0)
Feb 02 16:47:50 taschenrechner kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.

Googling those lead me to flathub/com.valvesoftware.Steam#1104 (also on an AMD Ryzen). But I can't find a solution there or in the other linked bugs :(

I don't know my way around gdb or coredumps, so this is as far as I got. Suggestions welcome, maybe we can figure out what is going on and improve this package.

My machine is a Thinkpad T495, AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx and amdgpu drivers.

[itslychee]

I updated my system. Sadly, Celeste64 still segfaults. I noticed the following lines in the journal

Feb 02 16:47:50 taschenrechner kernel: Celeste64[28960]: segfault at 0 ip 0000000000000000 sp 00007ffe47cf1168 error 14 in Celeste64[55c403776000+7000] likely on CPU 7 (core 3, socket 0)
Feb 02 16:47:50 taschenrechner kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.

Googling those lead me to flathub/com.valvesoftware.Steam#1104 (also on an AMD Ryzen). But I can't find a solution there or in the other linked bugs :(

I don't know my way around gdb or coredumps, so this is as far as I got. Suggestions welcome, maybe we can figure out what is going on and improve this package.

My machine is a Thinkpad T495, AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx and amdgpu drivers.

Hmm could you run strace -o output result/bin/Celeste64 and upload it, and thank you for sharing this error! It may or may not be related to EXOK/Celeste64#14 but I'll update the revision to latest.

[itslychee]

Feel free to try the latest commit!

[puzzlewolf]

Tried with the newest commit, still segfaulting. Here's the output of strace -o output.txt results/celeste64/bin/Celeste64:
output.txt. Do you see anything?

If this doesn't seem packaging related I'm happy to stop this here and take it upstream.

[itslychee]

@puzzlewolf my only guess from judging by your output is that libdrm was needed, i'm not 100% sure but i added it to see if it'd fix anything, otherwise I have no idea.

[puzzlewolf]

@puzzlewolf my only guess from judging by your output is that libdrm was needed, i'm not 100% sure but i added it to see if it'd fix anything, otherwise I have no idea.

That did the trick! Thanks for taking the time and guessing correctly :D

[puzzlewolf]

I'm so happy it works 🎉

Just one small nit that I can see: The commit message should be celeste64: init at 0-unstable-2024-02-02.

[itslychee]

super happy it worked!

[lelgenio]

Result of nixpkgs-review pr 285232 run on x86_64-linux 1

1 package built:

• celeste64