gephgui-wry: init at 5.4.1

[MCSeekeri]

gephgui-wry, the official GUI for the current version of geph, replaces the deprecated geph-client-gui component in the existing geph package.
After this PR is merged, the geph-client-gui component within the existing geph package will be removed to align with upstream changes.
I hope to distinguish between these two—geph as CLI software and gephgui as GUI software.

The current name references the official repository's nomenclature; I haven't yet conceived a name that explicitly highlights this distinction.

Tested and functional on my device, but I feel the current packaging still doesn't fully align with best practices. Feedback on improvements is welcome.

@penalty1083

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[MCSeekeri]

Geph has been updated to version 5.4.0, but the master branch has not been updated. I'm wondering if we should switch the branch used for fetching and compiling to next or perform a forced update when fetching submodules.

[penalty1083]

5.4.1 has been published. I thought we only need to care about the tag. Why is this marked as draft? Is there anything to fix?

[MCSeekeri]

5.4.1 has been published. I thought we only need to care about the tag. Why is this marked as draft? Is there anything to fix?

I've been quite busy these days and haven't been able to keep up with the PR status promptly. Once we fix the current issues we're working on, we can take it out of draft status.

[MCSeekeri]

Ofborg fails to properly package the executable. This is likely related to the incomplete package-lock.json used upstream in gephgui – since @esbuild depends on different binaries across operating systems. The current solutions are either waiting for the upstream fix or manually modifying package-lock.json.
However, modifying package-lock.json would prevent nixpkgs-update from correctly handling subsequent automated updates...
I’m uncertain how this should be handled.

[gepbird]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 471304
Commit: bd532070d1e78fc8fc9a5a1af0ab31c209afe2db

---

x86_64-linux

❌ 1 package failed to build:

• gephgui-wry

[gepbird]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 471304
Commit: bd69ab7156ca09b763617299f9f83d6a1ce979a2

---

x86_64-linux

✅ 1 package built:

• gephgui-wry

resolved

[MCSeekeri]

The issue has not been fully resolved yet; compilation on the aarch64 platform still fails due to issues with package-lock.json. However, this can be deferred for now. I have already submitted a PR upstream and hope it gets merged.
geph-official/gephgui#50

[nixpkgs-ci]

Successfully created backport PR for release-25.11:

• [Backport release-25.11] gephgui-wry: init at 5.4.1 #484315