lldap: rust 1.80 compatibility

[bendlas]

Description of changes

following up on #332957, this prepares lldap for compilation with rust 1.80

lldap/lldap#945 necessitates a relatively awkward workaround: We're using different lock files for client and server.

Things done

• Build latest main instead of 0.5.0, for a few 1.80 fixes that are already in
• Split Cargo.lock into Cargo.original.lock and Cargo.updated.lock, the latter resulting from cargo update
• Keep building frontend with original, backend with updated

---

• 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.

[SuperSandro2000]

Do we really need to commit both lock files?

[alyssais]

If other updated dependencies cause problems, why can't you update just the time crate?

[alyssais]

As expected, updating just the time crate is painless and fixes the issue: lldap/lldap#947

[alyssais]

Upstream suggests using a daily tag as a release. Should we do that instead of patching?

[SuperSandro2000]

Upstream suggests using a daily tag as a release. Should we do that instead of patching?

Which daily tag? I don't see any. https://github.com/lldap/lldap/tags

We can't grab anything from actions as they get deleted after some time.

[alyssais]

I don't know — but if they think any daily version is good enough, we could just do current HEAD. They also said they don't consider 0.5.0, the currently packaged version, to be a proper release.

[emilazy]

Yes, going by lldap/lldap#947 (comment) I think we should bump to HEAD.

[emilazy]

Final diff looks good to me, thanks! Please remove the unused fetchpatch and squash away the obsolete commits.

[bendlas]

I'll use the squash commit feature, which github hilariously blocked for me until @emilazy approves.

[emilazy]

SGTM. Would be good to rename the PR to “lldap: 0.5.0 -> 0.5.1-unstable-2024-08-09” so the version bump is preserved in the squashed commit description.