roc-toolkit: 0.3.0 -> 0.4.0

[noblepayne]

Description of changes

Update roc-toolkit from 0.3.0 to 0.4.0:

• GitHub Release
• Changelog
• Git Diff

Changes:

• Bump version and update hash.
• Added libsndfile.

Testing:

• Built and ran main binaries.
• Built and ran pipewire with roc module.

Things done

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

[superherointj]

Ops. I think this should have targeted staging.

Now I'm wondering if I should revert and target staging. =/

[noblepayne]

@superherointj Thanks for reviewing and merging this! Apologies about targeting the wrong branch. I see now that the branch conventions indicate this should have gone to staging due to the number of rebuilds:

Which changes cause mass rebuilds is not formally defined. In order to help the decision, CI automatically assigns rebuild labels to pull requests based on the number of packages they cause rebuilds for. As a rule of thumb, if the number of rebuilds is over 500, it can be considered a mass rebuild.

and

Mass rebuilds to master should go to staging instead

Will be more careful next time.

[superherointj]

@noblepayne There isn't a hard rule. Sometimes 1000 packages is fine, because the packages aren't that large. Sometimes a 300 packages can be enough to drag builders to a halt.

I suggest this heuristic:
If you can't do the downstream build (nixpkgs-review) of PR yourself at your host (considering it's a modern, decent sized one, like Ryzen 5950x, 64GB), it's a good hint for considering staging. If you can build downstream it's master for sure.

Here, the mistake was mainly mine, because I was the one reviewing/merging it.

In retrospect, I should have reverted the PR and made a new PR targeting staging and cherry-picked your commit.

Thanks for your understanding.

[CyberShadow]

Hi, I think this version bump caused a regression: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4070

[superherointj]

Hi, I think this version bump caused a regression: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4070

Do you want me to revert this? Or a fix downstream is doable?

[CyberShadow]

Looks like Pipewire added a compatibility patch: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/6acfb53884c6f3936030fe43a584bfa01c27d3ea

I don't know if they plan to tag a release soon, looks like they had a release just a few days before that commit.

So, perhaps cherry pick just the Pipewire patch, instead of reverting the version bump?

[CyberShadow]

I'm going to test with:

  nixpkgs.overlays = [.
    (final: prev: {
      pipewire = prev.pipewire.overrideAttrs (old: {
        patches = (old.patches or []) ++ [
          (prev.fetchpatch {
            url = "https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2048.patch";
            hash = "sha256-UQTWnw2fJ8Sx+eMaUmbJEFopV3HPr63v4xVtk0z3/xM=";
          })
        ];
      });
    }).
  ];

but it's a big rebuild so maybe I can tell you if it works in the morning.

[superherointj]

Looks like Pipewire added a compatibility patch: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/6acfb53884c6f3936030fe43a584bfa01c27d3ea

I don't know if they plan to tag a release soon, looks like they had a release just a few days before that commit.

So, perhaps cherry pick just the Pipewire patch, instead of reverting the version bump?

I have tested patch:

    (fetchpatch {
      url = "https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2048.patch";
      hash = "sha256-UQTWnw2fJ8Sx+eMaUmbJEFopV3HPr63v4xVtk0z3/xM=";
    })

pipewire builds but nixosTests.installed-tests.pipewire still fails.
I think, now I've got enough cache to do fast builds. So if you have an experiment in mind, let me know.

Logs: https://termbin.com/sbla

[CyberShadow]

but it's a big rebuild so maybe I can tell you if it works in the morning.

I have just discovered that I can use system.replaceRuntimeDependencies to test patches without rebuilding half the world, and can confirm that the patch fixes the issue for me.

Tested with:

  system.replaceRuntimeDependencies = [
    {
      original = pkgs.pipewire;
      replacement = pkgs.pipewire.overrideAttrs (old: {
        patches = (old.patches or []) ++ [
          (pkgs.fetchpatch {
            url = "https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2048.patch";
            hash = "sha256-UQTWnw2fJ8Sx+eMaUmbJEFopV3HPr63v4xVtk0z3/xM=";
          })
        ];
      });
    }
  ];