You can also track the progress at https://nixpk.gs/pr-tracker.html?pr=367042, is already part of nixos-unstable-small at the time of writing, though this is probably not what a lot of people use. I’ll see when it hits nixos-unstable and let you know, but don’t know when I used my machine the coming days

And why can he not use the Kokiri Sword as a dagger? It’s like he’s not even trying

What makes the OoT animation a bit cooler is that Link is older after the animation, like the beams hide him from your view and after the flash of light, he grew old (and everything else changed as well, but you only see that after leaving the cathedral)

I have opened a pull request at https://github.com/NixOS/nixpkgs/pull/367042, there might be more changes needed as I had an error in the meta section of the package which I rectified according to the reviewers proposed changes. Not sure this is the end of it, but the request is open

Cool stuff, now of Firefox didn’t switch back to Google every major update or so, that would be great… because I actually do have Ecosia selected and need to switch back to it every once in a while because hey why not

No, Cargo.lock is the only relevant optional one for Rust packages and that is already there, so we should be good. I’ll request it tomorrow if someone else doesn’t beat me to it ;)

No, but I will try to incorporate the nixpkgs update script into it now that the metadata is fixed for the release. I’m not a nixpkgs maintainer (yet) though but usually this is close to automatic.

If you want, you can also submit and maintain the package, or I can put us both as maintainers

It’s rather simple in good cases, here’s my version:

{
  lib,
  fetchFromGitHub,
  rustPlatform,
  perl,
}:

let
  pname = "managarr";
  version = "0.4.1";
in

rustPlatform.buildRustPackage {
  inherit pname version;
  src = fetchFromGitHub {
    owner = "Dark-Alex-17";
    repo = pname;
    rev = "df9bba32cb1628fe0bdf33c71089d7ae085066d4";
    hash = "sha256-2KWuqv0nxMc+H+lmuNQ0lbEm5yE2akuZTa7PT5JcvBs=";
  };

  cargoHash = "sha256-hB4uRgVUp6YngMoXqd03U/n+HdlcYdL5bwvTxI4xCLE=";

  nativeBuildInputs = [ perl ];

  meta = {
    description = "A TUI and CLI to manage your Servarrs";
    homepage = "https://github.com/Dark-Alex-17/managarr";
    license = lib.licenses.mit;
    maintainers = [ ];
  };
}

No worries, I look forward to using this in the future :) (though probably rarely, I don’t use my *arr stack often)

Once you have pushed your next release, I’ll submit the package definition I wrote to nixpkgs, currently worked around the ordering by checking out two commits after the tag, but since there’s no rush to push this, I’ll wait for the next release.

So I’m currently building the package, and there’s one thing that irks me a bit about it, which is that you first tagged your release as 0.4.1 and then changed your Cargo.toml… which means that if you check out that tag on GitHub, the information is always one release behind. This also seemed to be the case with other releases (0.4.0 shows as 0.3.7, 0.3.7 as 0.3.6…). From the commit history, this also seems to affect Cargo.lock, so we’re always getting the lock file for the previous release when checking out the tag. Not ideal

An issue with the program itself: it will always show servers for both radarr and sonarr, regardless if you have them configured or not. Switching to an unconfigured one will yield an error for missing configuration. The program itself looks nice, though I’d prefer if there was the option to respect my shell’s color theme.

Sheesh gramps get with the times