Pipewire 0.3.67 + big module cleanup

[K900]

Description of changes

• update pipewire to new upstream release
• add tinycompress support
• (POSSIBLY LARGE BREAKING CHANGE) remove extremely broken config overriding

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.11 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.

[mweinelt]

Where to place those drop-in files? That's a bit unclear.

[K900]

I'm not sure how verbose we want to be here. The drop-in files go into /etc/pipewire/<whatever>.conf.d and there are multiple config files, so it's hard to explain without getting into a lot of detail. Also I kinda just hope no one is using this, because it does not work the way anyone would expect.

[Atemu]

Given that there's a whole wiki page dedicated to tweaking services.pipewire.config, I think going into detail is warranted.

[Atemu]

You'd probably even want to announce it in the breaking changes thread.

[K900]

That entire page will need to be updated. It's on my list. I'll probably write up a post detailing the migration steps and post that in the thread.

[K900]

Draft migration guide: https://gist.github.com/K900/20fb1651d72411e3419d278bb29343ea

[jansol]

The migration guide should preferrably be mentioned in the release notes too, since it's a pretty big chunk of not necessarily obvious manual work.

[K900]

It's definitely going in the docs somewhere, I just need to find a good place to put it in.

[K900]

Ended up adding the migration guide to the end of the release notes.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/19

[jansol]

Looks good, should make future updates a lot simpler since we won't have to care about default config changes any more. I'd have to check what this implies for my filter-chain and custom node setups. I guess I'd just keep my existing setup for those since it was just writing custom files to /etc to begin with.

But it'll be at least one more week before I can get to that so it's probably not necessary to wait for me if there seems to be a consensus already.

[jansol]

The migration guide should preferrably be mentioned in the release notes too, since it's a pretty big chunk of not necessarily obvious manual work.

[K900]

So, should I just merge this at this point? It looks like either no one is testing it or no one is having issues...

[mweinelt]

I would expect that no one is testing. 😉

[Atemu]

You would be wrong! I'm affected by a bug that's supposedly fixed in 0.3.67 and I'm testing this as we speak but the bug is hard to repro.

The NixOS changes LGTM. I can't really test pipewire itself much due to the amount of rebuilds but building the services up manually works just fine via pipewire-pulse and mpv.

[Atemu]

(I haven't tried the new way of configuring modules but I didn't use the old way either and had stateful config files in ~/.conf which still work fine.)

[K900]

I'm just going to send this to avoid any more merge conflicts.

[trofi]

I have the following config module that I fail to convert to a new way:

{ ... }:
{
  # rtkit is optional but recommended
  security.rtkit.enable = true;
  services.pipewire.enable = true;
  # emulation layers:
  services.pipewire.alsa.enable = true;
  services.pipewire.alsa.support32Bit = true;
  services.pipewire.pulse.enable = true;
  # allow other user use sound by absolute address:

  services.pipewire.config.pipewire-pulse = {
    "pulse.properties" = {
      "server.address" = [
        # default:
        "unix:native"
        # extension:
        "unix:/tmp/pulse-for-all"
      ];
    };
  };
  hardware.pulseaudio.extraClientConf = ''
    default-server=unix:/tmp/pulse-for-all
  '';
  # Also add an activation:
  # ~/.config/systemd/user/pipewire-pulse.socket.d:
  #   [Socket]
  #   ListenStream=/tmp/pulse-for-all
}

Specifically services.pipewire.config.pipewire-pulse now fails with:

       error:
       Failed assertions:
       - The option definition `services.pipewire.config' in `/etc/nixos/pipewire.nix' no longer has any effect; please remove it.
       Overriding default Pipewire configuration through NixOS options never worked correctly and is no longer supported.
       Please create drop-in files in /etc/pipewire/pipewire.conf.d/ to make the desired setting changes instead.

I tried a few override types via /etc/pipewire/pipewire.conf.d/ and all of them failed. Just adding something like

{
  "pulse.properties": {
    "server.address": [
      "unix:native",
      "unix:/tmp/pulse-for-all"
    ],
  },
}

does not work. Do I need to copy the full config file to recover from the breakage?

[K900]

Those settings go into pipewire-pulse.conf.d, not pipewire.conf.d

[trofi]

Thank you! I think I was misled by the warning message. Bellow config did the trick:

  environment.etc."pipewire/pipewire-pulse.conf.d/pulse-for-all.conf".text = ''
    pulse.properties = {
      # the addresses this server listens on
      server.address = [
        # default:
        "unix:native"
        # extension:
        "unix:/tmp/pulse-for-all"
      ]
    }
  '';

[Atemu]

I feel like we should have a more abstract way of configuring that.

[K900]

What exactly?

[Atemu]

Configuring PW, PW-pulse etc. "Put a file with some text into /etc" is about as low-level as it gets. That's documentation on the level I'd expect to find on the Arch Wiki, not in NixOS.

I'm thinking resurrecting the config options and simply toJSONing the values into files in pipewire.conf.d etc. in the module; an abstract interface.

[K900]

I agree with that, maybe naming it extraConfig or something, I just haven't gotten around to it yet.

[K900]

(feel free to submit a PR if that's something you want to work on, btw)

[Atemu]

As per NixOS/rfcs#42, it should be settings. I'll see if I can work on that this weekend but I wouldn't bet on it.

[K900]

I'd rather have the option name indicate that it's being merged with the defaults somehow.

[Atemu]

Prior art on how to handle that:

nixpkgs/nixos/modules/services/networking/dnscrypt-proxy2.nix

Lines 11 to 38 in e0d3d8b

	settings = mkOption {
	description = lib.mdDoc ''
	Attrset that is converted and passed as TOML config file.
	For available params, see: <https://github.com/DNSCrypt/dnscrypt-proxy/blob/${pkgs.dnscrypt-proxy2.version}/dnscrypt-proxy/example-dnscrypt-proxy.toml>
	'';
	example = literalExpression ''
	{
	sources.public-resolvers = {
	urls = [ "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md" ];
	cache_file = "public-resolvers.md";
	minisign_key = "RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3";
	refresh_delay = 72;
	};
	}
	'';
	type = types.attrs;
	default = {};
	};
	upstreamDefaults = mkOption {
	description = lib.mdDoc ''
	Whether to base the config declared in {option}`services.dnscrypt-proxy2.settings` on the upstream example config (<https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml>)
	Disable this if you want to declare your dnscrypt config from scratch.
	'';
	type = types.bool;
	default = true;
	};

(by yours truly)