How to skip rebuilding packages that fail due to an upstream error

Help
1

I make use of the makemkv package to rip physical media for my Jellyfin instance. Currently, this package fails to build, as the server gives an incomplete .tar.gz file, which fails to extract.

As a result, all attempts to update my system fail:

┏━ 4 Errors:
┃ error: Cannot build '/nix/store/75f811kz9vlb33ki2rcrj4kffv1jaar6-nixos-system-yzma-25.11.6495.e764fc9a4058.drv'.
┃        Reason: 1 dependency failed.
┃        Output paths:
┃          /nix/store/k804g5hgxzn6a0rn850nngzb2vk2hds7-nixos-system-yzma-25.11.6495.e764fc9a4058
┃ error: Cannot build '/nix/store/9wncrm3n2rmpmf342plxb661074gx2zz-system-path.drv'.
┃        Reason: 1 dependency failed.
┃        Output paths:
┃          /nix/store/618m3kyf0lrhkixy264crp90g54na4ch-system-path
┃ error: Cannot build '/nix/store/nkf65g1c74svhrz0ylk9s1ydabm0kklv-makemkv-1.18.3.drv'.
┃        Reason: 1 dependency failed.
┃        Output paths:
┃          /nix/store/pbrw1mshxwnzzgqg5wmawn33671qa726-makemkv-1.18.3
┃ error: hash mismatch in fixed-output derivation '/nix/store/r8m5gqcrjk5lf2p07ws7zl4hag7a82gm-makemkv-bin-1.18.3.tar.gz.drv':
┃          specified: sha256-we5yCukbJ2p8ib6GEUbFuTRjGDHo1sj0U0BkNXJOkr0=
┃             got:    sha256-s8qloVEQU7+8HKLPo52FoPvhvuDZfqMzXndVoNzOkEM=
┣━ Dependency Graph:
┃          ┌─ ⏸ X-Restart-Triggers-polkit waiting for 1 ⚠ 5 ⏵ 2 ↓ ⏸
┃       ┌─ ⏸ unit-polkit.service
┃       │        ┌─ ⏵ obsidian-1.11.5.tar.gz ⏱ 3m56s (∅ 1m24s)
┃       │     ┌─ ⏸ obsidian-1.11.5
┃       │     │  ┌─ ⏵ discord-0.0.125.tar.gz ⏱ 3m57s
┃       │     ├─ ⏸ discord-0.0.125
┃       │     │  ┌─ ⏵ VSCode_1.109.4_linux-x64.tar.gz ⏱ 3m57s
┃       │     ├─ ⏸ vscode-1.109.4
┃       │     │  ┌─ ⏵ makemkv-oss-1.18.3.tar.gz ⏱ 3m56s (∅ 4s)
┃       │     │  ├─ ⚠ makemkv-bin-1.18.3.tar.gz failed with hash mismatch after ⏱ 43s
┃       │     ├─ ⏸ makemkv-1.18.3
┃       │     ├─ ⏵ gaphor-3.2.0 (pytestCheckPhase) ⏱ 3m55s
┃       │  ┌─ ⏸ system-path
┃       ├─ ⏸ unit-accounts-daemon.service
┃    ┌─ ⏸ system-units
┃ ┌─ ⏸ etc
┃ ⏸ nixos-system-yzma-25.11.6495.e764fc9a4058
┣━━━ Builds            │ Downloads        │ Host
┃    ⏵ 5 │ ✔ 14 │      │     │      │     │ localhost
┃        │      │      │     │ ↓ 27 │     │ https://cache.nixos.org
┗━ ∑ ⏵ 5 │ ✔ 14 │ ⏸ 23 │ ↓ 0 │ ↓ 27 │ ⏸ 4 │ ⚠ Exited after 1 build failures at 22:50:21 after 4m29s
Error:
   0: Failed to build configuration
   1: Command exited with status Exited(1)
  • I do not wish to uninstall makemkv, as it is essential for adding to my digital media library.
  • I do not want to be stuck on an outdated system while I wait for MakeMKV to fix their servers.

Hypothetically, there should be no reason to rebuild makemkv at all, as my system is already running the latest version, 1.18.3, which should be clear from nixpkgs.

As such, how can I skip the updating of this one package without removing it entirely?

2

Nix considers it a different derivation if any buildtime or runtime dependency (or transitive dependency) has changed in any way whatsoever. Only the tendencies of programmers not to do crazy things keeps it from actually behaving quite differently when built with different dependencies and build tools, even if it is the same version. This is actually important behavior to get the reproducibility nix aims for. (Take, as an example, the xz trapdoor in openssh a while back. It was a trojan horse that changed the behavior of sshd when it was linked against a certain version of xz.)

“Skip updating” is a phrase firmly rooted in the kind of package management NixOS does not do. That is, stateful package management. For NixOS, it’s trying to build a system from scratch on every update. Sometimes it finds it “happens” to already have a lot of the stuff it needed, but that’s what it’s doing in principle.

Thus, what you need to do is change the definition you’re using, to specifically install that package from another version of nixpkgs. If that would even help in your case. I haven’t looked into the root cause of the issue. At the least, installing it from the last version of nixpkgs you built from should work, if only by caching.

2 Likes
3

Unfortunately, I don’t have any versions cached, and since the application is closed-source, it isn’t cached by NixOS. As such, any attempt to change nixpkgs versions runs into the same issue. So while your explanation makes sense, it is sadly unhelpful for my situation.

Fortunately, I found an alternative workaround, which is to include my existing build from the nix-store in my packages list:

  environment.systemPackages = with pkgs; [
    # Currently, MakeMKV servers are down, meaning that rebuilds would fail due
    # to attempting to download the makemkv-bin-1.18.3.tar.gz file, and
    # receiving an incomplete and corrupted copy. As such, I am directly
    # referencing the installed package in order to avoid rebuilding the
    # existing package.
    # makemkv
    (builtins.storePath "/nix/store/7rr30kilhbac4s86zy27s5xc756a5dm9-makemkv-1.18.3/")
  ];

I should be able to change it back to the normal version as soon as MakeMKV sort out their servers.

4

You have the version already in your nix store as part of the generation you’re currrently running, though. If you use the same commit of nixpkgs that was built from, it should reuse it.

This… is a fairly bad idea, generally speaking. But if you only keep it for a few days, problems are unlikely. I suppose it’s better than not being able to update? Probably?

As a general rule, any time you manually put a store path into any permanent file, you’re almost certainly making a big mistake. In this case, though, I believe the only issue is that your configuration will no longer be buildable on a machine that does not already have that store path. Probably nothing else.

5

Unfortunately, the version from the generation I’m running is from nixpkgs-unstable. v1.18.2 had a bug under Gnome on NixOS, and I switched to the unstable branch to see if v1.18.3 fixed it, and then forgot to switch back. I imagine that finding the nixpkgs-unstable version it was built from would be quite difficult, since most of my packages are from nixpkgs-25.11.

let
  # Add the unstable channel declaratively
  nixosUnstable = fetchTarball "https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz";
in
{
  nixpkgs.config = {
    packageOverrides = pkgs: {
      unstable = import nixosUnstable {
        config = config.nixpkgs.config;
      };
    };
  };

Whether this is the intended way to mix-and-match between stable and unstable is another question (alternative suggestions are welcome), but it seems to work. I mainly use it to get updated versions of fast-moving software such as zed-editor and vscode.

6

Unpinned inputs! Arg. This is exactly why you shouldn’t do that! :stuck_out_tongue: (Also, I now understand the urgency of the problem for you. You can’t even make a change to your system because of this.)

Add another channel for it so you control the updates to unstable as well, and can roll them back if desired. That would at least let you rebuild to make changes, even if you couldn’t advance to a new nixpkgs without breaking something.

1 Like
7

Oh dear looks like my config is going to have to become a flake after all (if I want my channels to remain part of my config)

8

Doesn’t have to be flakes. If you want inputs pinned in your source repo, there are other options, such as npins.

Definitely don’t use unpinned fetchers, though. You have no control or traceability, and thus no actual reproducibility that way.

2 Likes
9

Thanks for the advice. For now I’ll just stick to manually adding the channel, since it turns out that works nicely with my little update script. Thanks so much for all the advice!

1 Like