alsa-ucm-conf: fix hardcoded FHS paths

[drupol]

I recreated #371100 here, hopefully it won't ping all the people this time.

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[nixos-discourse]

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

https://discourse.nixos.org/t/dell-xps-13-9320-microphone-not-working/40932/8

[wolfgangwalther]

There seem to be a few /sbin/ references, too: https://github.com/search?q=repo%3Aalsa-project%2Falsa-ucm-conf%20%2Fbin%2F&type=code

Not sure if they can/should be replaced, though.

[drupol]

Great, going to fix them too now.

[hraban]

@drupol re #371100 (comment) What happened there is that your PR contained commits from master that weren't in staging yet, and when you changed the merge base from master to staging a bot detects those commits and asks for a review of everyone who is a relevant owner for anything touched by any of those commits. It's a bit of a bug in the CI automation of nixpkgs if you ask me but it only goes wrong once every ~3mo, so for now people just seem to live with it :)

The nixpkgs way to change base is to first rebase your new commits onto $(git merge-base upstream/{master,staging}), force push that, then change the PR target in github. Finally, if you wish, rebase your changes back on top of the latest commit of master or staging, if that makes you happy.

[wolfgangwalther]

It's a bit of a bug in the CI automation of nixpkgs if you ask me but it only goes wrong once every ~3mo, so for now people just seem to live with it :)

It's not supposed to go wrong anymore. code-owners-v2 has fixed this for code-owner review requests and if it wasn't for the recent change from ofborg to GA for maintainer requests, it wouldn't happen for those cases either.

So yes, it was a bug, but a very recent one, introduced yesterday, fixed today.

[hraban]

It's a bit of a bug in the CI automation of nixpkgs if you ask me but it only goes wrong once every ~3mo, so for now people just seem to live with it :)

It's not supposed to go wrong anymore. code-owners-v2 has fixed this for code-owner review requests and if it wasn't for the recent change from ofborg to GA for maintainer requests, it wouldn't happen for those cases either.

So yes, it was a bug, but a very recent one, introduced yesterday, fixed today.

Good to hear, although I'm surprised to hear "introduced yesterday" part because I've run into this problem myself, and been pinged when others did. Am I talking about something else? Pretty sure "changing the target branch of a github PR" has been a dangerous thing to do since I joined >2y ago.

[drupol]

Feel free to also review this PR 😆 !

[FliegendeWurst]

Pretty sure "changing the target branch of a github PR" has been a dangerous thing to do since I joined >2y ago.

It is fairly safe since #347610. Worst case is some excessive labeling.