• 0 Posts
  • 25 Comments
Joined 6 months ago
Cake day: June 23rd, 2024
  • Laser@feddit.orgtoLinux@lemmy.ml•fish-shell 4.0b1 released, now in Rust
    8·
    3 days ago

    Fish is a surprisingly good shell.

    It’s not POSIX compatible, but I don’t really care, it only executes its own scripts / functions. It’s not as innovative as elvish or nu, but it kind of does everything very conveniently and shell-y for lack of a better word – and it always seems so simple. It seems conservative in design, but the old concepts have been evolved in a very usable way. Something I can’t say for all the other shells I’ve tried – at some point, it always gets awkward where fish is just elegant.

  • Laser@feddit.orgtoOpen Source@lemmy.ml•I present: Managarr with Sonarr support!
    1·
    6 days ago

    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 = [ ];
  };
}
  • Laser@feddit.orgtoOpen Source@lemmy.ml•I present: Managarr with Sonarr support!English
    2·
    6 days ago

    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.

  • Laser@feddit.orgtoTechnology@lemmy.world•Let's Encrypt Announces New-Certificate-Every-6-Days OfferingEnglish
    16·
    7 days ago

    It’s kind of in line with their plan to get rid of OCSP: short certificate lifetimes keep CRLs short, so I get where they’re coming from (I think).

    90 days of validity, which was once a short lifetime. Currently, Google is planning to enforce this as the maximum validity duration in their browser, and I’m sure Mozilla will follow, but it wouldn’t matter if they didn’t because no provider can afford to not support chromium based browsers.

    I was expecting that they reduce the maximum situation to e.g. 30 days, but I guess they want to make the stricter rules optional first to make sure there are no issues.

  • Laser@feddit.orgtoOpen Source@lemmy.ml•I present: Managarr with Sonarr support!
    1·
    7 days ago

    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.