pds: init at 0.4.67, nixos/pds: init

[t4ccer]

Things done

Self hosted server for https://bsky.social/

• 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.11 Release Notes (or backporting 23.11 and 24.05 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.

[pyrox0]

Upstream uses PNPM, why not use the existing PNPM tooling to generate the package? That means then there's no need to store an additional lockfile in-tree.

See https://nixos.org/manual/nixpkgs/stable/#javascript-pnpm for how to use nixpkgs' pnpm tooling.

Edit: I see your comment. Let me see if I can improve that for the pnpm tooling.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/4786

[soopyc]

Upstream has updated to 0.4.67, you might want to consider updating.

[BatteredBunny]

Small changes

[BatteredBunny]

Managed to successfully deploy it to my server :)
Had to modify the pdsadmin scripts though https://github.com/BatteredBunny/pds

[t4ccer]

Yeah, I didn't bother packaging the admin scripts because the main one just fetches scripts for subcommands and they all have wrong shebang. Probably upstream should be fixed to use /usr/bin/env bash

Edit: opened a PR upstream bluesky-social/pds#121

[pyrox0]

Yeah, I didn't bother packaging the admin scripts because the main one just fetches scripts for subcommands and they all have wrong shebang. Probably upstream should be fixed to use /usr/bin/env bash

Edit: opened a PR upstream bluesky-social/pds#121

You should also be able to run the patchShebangs script on the scripts. Does that work?

[pyrox0]

Nice work on the service, found a few nits though

[pyrox0]

Also, having looked into the sharp issue, I believe it's an issue with sharp being version 0.32.x, not 0.33.x, where there are now prebuilt binaries available. I'm looking into submitting a patch upstream to update this dependency

Edit: bluesky-social/atproto#2958

[t4ccer]

You should also be able to run the patchShebangs script on the scripts. Does that work?

Not really. It'll fix the main script but all it's doing is download subsequent ones that will still fail because they're not patched https://github.com/bluesky-social/pds/blob/main/pdsadmin.sh#L22-L30

Other way would be to patch the main script to use store path instead of downloading it but I wasn't sure if that's not too much change. But maybe that's a good idea to keep them locked to pds version

[pyrox0]

You should also be able to run the patchShebangs script on the scripts. Does that work?

Not really. It'll fix the main script but all it's doing is download subsequent ones that will still fail because they're not patched bluesky-social/pds@main/pdsadmin.sh#L22-L30

Other way would be to patch the main script to use store path instead of downloading it but I wasn't sure if that's not too much change. But maybe that's a good idea to keep them locked to pds version

yeah I'd say vendor the scripts, you could even make a new pdsadmin script in-tree and replace the one in the repo with it if you want. Removing what's essentially curl | bash is a great idea in my book. Them being in the nix store is fine, since if you look at the history for the scripts folder, they're not really touched much.

[t4ccer]

Hm ExecStart = getExe cfg.package; doesn't seem to work? I get

(pds)[1989597]: pds.service: Failed to execute /nix/store/w25c005jjb98frrvhd7bkwjqmnlrjg96-pds-0.4.67/bin/pds: Exec format error
(pds)[1989597]: pds.service: Failed at step EXEC spawning /nix/store/w25c005jjb98frrvhd7bkwjqmnlrjg96-pds-0.4.67/bin/pds: Exec format error

on my server

[t4ccer]

Missing shebang 🙃

[t4ccer]

I'll add NixOS test when I'll have more time, deployed on my server and works fine

[t4ccer]

Now with freeform settings and NixOS test!

[soopyc]

i personally still don't like the idea of switching package managers and maintaining an entirely different lockfile in-tree. this unnecessarily increases maintenance burden and i doubt r-ryantm knows how to update this automatically. please correct me if i am wrong.

otherwise, looks okay. remember to add a release note.

[pyrox0]

i personally still don't like the idea of switching package managers and maintaining an entirely different lockfile in-tree. this unnecessarily increases maintenance burden and i doubt r-ryantm knows how to update this automatically. please correct me if i am wrong.

otherwise, looks okay. remember to add a release note.

r-ryantm definitely can't update this without an update script. however, the linked upstream pr in one of my comments should help resolve the issue of needing to switch from pnpm(though that still needs to be fully tested once upstream releases a new version of the pds)

[t4ccer]

r-ryantm definitely can't update this without an update script. however, the linked upstream pr in one of my comments should help resolve the issue of needing to switch from pnpm(though that still needs to be fully tested once upstream releases a new version of the pds)

Yep. The next bump will need to be manually and tested if new pnpm hook will work this time, if yes we can drop the lock file

[pyrox0]

one last little nitpick, could there be an option to enable/disable adding the pdsadmin scripts to environment.systemPackages? just pds.pdsadmin.enable or something like that, and have it default to the same value as the pds.enable option. that way folks don't get confused about needing to add them separately.

[t4ccer]

pdsadmin is generally quite annoying because it needs environment variables from systemd to run correctly, let me see if we can generate a wrapper derived from settings