@AndersonTorres The darwin patch shouldn't be needed anymore. This also means the package requires darwin.codesign instead of rcodesign again.

Edit: It doesn't build on darwin, it looks like this update might require a more recent apple SDK. (error: value of type 'NSCondition' has no member 'withLock')

1. I will then delete the patch
2. Still needs Darwin testers, since I am not one of them :)

What is happening that this expression is not building?

What is happening that this expression is not building?

If I had to guess it could be related to wrapping mpv? You could try moving it to pkgs/by-name. So there is no import issue.

by-name - related errors are catched by a specific script, not by ofBorg.

Currently mpv uses that dreadful darwin.apple_sdk.callPackage instead of plain callPackage. It makes the migration impossible.

@ofborg build mpv-unwrapped

Currently mpv uses that dreadful darwin.apple_sdk.callPackage instead of plain callPackage. It makes the migration impossible.

It can still be migrated, just changing the path to callPackage accordingly

It can still be migrated, just changing the path to callPackage accordingly

No, it does not. Saving my fingers:

#305509 (comment)

Yeah, I just tested and ended up on the same error.
https://github.com/NixOS/nixpkgs-check-by-name/blob/7d6d26de7b271498d003e239b2a62cf22966398f/src/nixpkgs_problem.rs#L273-L277

I'm not completely sure why it fails to eval, but you can use the following as a workaround:

--- i/pkgs/applications/video/mpv/default.nix
+++ w/pkgs/applications/video/mpv/default.nix
@@ -11,6 +11,7 @@
   ninja,
   pkg-config,
   python3,
+  sigtool,
   ffmpeg,
   freefont_ttf,
   freetype,
@@ -210,7 +211,7 @@ stdenv'.mkDerivation (finalAttrs: {
       pkg-config
     ]
     ++ lib.optionals stdenv.isDarwin [
-      darwin.sigtool
+      sigtool
       xcbuild.xcrun
     ]
     ++ lib.optionals swiftSupport [ swift ]
--- i/pkgs/top-level/all-packages.nix
+++ w/pkgs/top-level/all-packages.nix
@@ -33005,6 +33005,7 @@ with pkgs;
 
   mpv-unwrapped = darwin.apple_sdk_11_0.callPackage ../applications/video/mpv {
     stdenv = if stdenv.isDarwin then swiftPackages.stdenv else stdenv;
+    inherit (darwin) sigtool;
     inherit lua;
   }; 

or

--- c/pkgs/applications/video/mpv/default.nix
+++ i/pkgs/applications/video/mpv/default.nix
@@ -22,6 +22,7 @@
   xcbuild,
   rcodesign,
+  buildPackages,
 
   waylandSupport ? stdenv.isLinux,
@@ -210,7 +211,7 @@ stdenv'.mkDerivation (finalAttrs: {
       pkg-config
     ]
     ++ lib.optionals stdenv.isDarwin [
-      darwin.sigtool
+      buildPackages.darwin.sigtool
       xcbuild.xcrun
     ]

Let's try.

P.S.: can I put this on the account of splicing?

@Scrumplex I have patched the expression for sublime at #318319. Can you please test it?

Result of nixpkgs-review pr 304349 run on x86_64-linux 1

Seems to build fine now!

shouldn't there be an alias/redirection instead of hitting:

    error: attribute 'wrapMpv' missing
       at /nix/store/1jnssw33bwg5cywr9arnd4pg02pdx4l3-source/modules/programs/mpv.nix:59:5:
           58|   else
           59|     pkgs.wrapMpv pkgs.mpv-unwrapped { scripts = cfg.scripts; };

Some note about how to fix breakage resulting from this would have been nice :)

I came up with something like:

     programs.mpv = {
       enable = true;
-      package = pkgs.wrapMpv (pkgs.mpv-unwrapped.override {
-        ffmpeg = pkgs.ffmpeg-full;
-      }) {
+      package = (pkgs.mpv-unwrapped.wrapper {
+        mpv = pkgs.mpv-unwrapped.override {
+          ffmpeg = pkgs.ffmpeg-full;
+        };
+      }).override {
         scripts = [
           pkgs.mpvScripts.mpris

shouldn't there be an alias/redirection instead of hitting:

    error: attribute 'wrapMpv' missing
       at /nix/store/1jnssw33bwg5cywr9arnd4pg02pdx4l3-source/modules/programs/mpv.nix:59:5:
           58|   else
           59|     pkgs.wrapMpv pkgs.mpv-unwrapped { scripts = cfg.scripts; };

The interface changed in the new release. Alias would not work
However why wasn't this catched by ofBorg? o.O

P.S.: oh, another case for phagocyte.

The interface changed in the new release. Alias would not work

At least a throw would be ideal to point at the new interface

why wasn't this catched by ofBorg

borgo doesn't test code in files that you didn't touch, unless you tell it to, or there's some package test, etc

there was a test, but it seems like it wasn't set up properly so ofborg could run it: #318588 (comment)

seems like there was little/no other usage of wrapMpv in nixpkgs itself, so nixpkgs-review would not have helped either

The interface changed in the new release. Alias would not work

wouldn't something like this work? (completely untested)

wrapMpv = unwrapped: (pkgs.mpv-unwrapped.wrapper { mpv = unwrapped; }).override;

borgo doesn't test code in files that you didn't touch, unless you tell it to, or there's some package test, etc

indeed this code was external, from home-manager.

Hi, why didn’t you add a backwards-compat layer for wrapMpv? Or a deprecation period?

We did not ponder it at that time.

Besides, the discussions about, ehr, breakages on unstable are very hot:

https://discourse.nixos.org/t/can-we-please-stop-breaking-stuff-willy-nilly/48496

How is "people are discussing how to handle breakages" an excuse for breaking more things? At least stick with the first reason of "nobody realized," which is at least logical.

I was not saying this as an excuse, in case you did not notice.

I merely pointed this Discourse link because we do not have anything remotely similar to a deprecation policy (besides "not breaking stable, tagged NixOS releases").

And that lack of a deprecation policy is a recurrent issue that is receiving a little bit more attention after each iteration:

• https://discourse.nixos.org/t/unmaintained-software-when-do-we-deprecate-software/7030
• https://discourse.nixos.org/t/should-we-consider-a-deprecation-removal-policy-for-nixpkgs/17516
• Revert "Merge pull request #155048 from mweinelt/python2-must-die" #157959
• Revert "{citra,yuzuPackages}: remove package" #295587

I don’t particularly care about people writing books on discourse on this topic (they have been doing that every few months for the last ~decade or so).

Just adding a little “hey this was replaced with xy, here’s an easy example how to fix it in your config” throw would be enough.