pds: init at 0.4.74, nixos/pds: init

[t4ccer]

Things done

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

Closes #357466

• 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

[SuperSandro2000]

Why do we need a temporary file?

[t4ccer]

Cause the script tries to source it and it almost always does not exist (the default is /pds/pds.env which looks docker-ish) but even if it does we still want to use our variables instead
https://github.com/bluesky-social/pds/blob/main/pdsadmin/account.sh#L6-L7

[lucasew]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 350645

---

x86_64-linux

✅ 1 test built:

• nixosTests.pds

✅ 2 packages built:

• pds
• pdsadmin

[t4ccer]

The branch this PR will merge in to does not cleanly evaluate, and so this PR cannot be checked.

I don't even have the Details button, how do I debug that?

[t4ccer]

@ofborg eval

[lucasew]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 350645

---

x86_64-linux

✅ 1 test built:

• nixosTests.pds

✅ 2 packages built:

• pds
• pdsadmin

[w4]

What are the blockers here? Would be nice not to have to drop into virtualisation.containers but it’s not the end of the world

[t4ccer]

Ugh I didn't notice the merge conflict label, would be great if it would also ping the PR author

[t4ccer]

Are we good to merge now @SuperSandro2000? Merge conflicts in release notes are getting quite annoying.

Was addressed

[infinisil]

This PR looks very fine, great work! To not stretch this out any further, I'm jumping in with the merge. If anybody still has nits to complain about, I encourage creating a follow-up PR. In general I'd like to see more optimistic merging in Nixpkgs to avoid situations like these, which are often discouraging for contributors.