Arch Linux User Repository

@ggnoredo: As Pirgosth rightly wrote, upstream decided to re-release a new source archive with the same version. This is not expected by the packaging process. I can see, you are using yay and you most probably still have the old archive, the first one published as 0.5.3, lying around in the yay folder under .cache. Try to remove all untracked AUR files via the yay -Sc command, answering the last question with yes. This should fix your issue.

==> Validating source files with b2sums...
    pwvucontrol-0.5.3.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error downloading sources: /home/USERNAME/.cache/yay/pwvucontrol
     context: exit status 1


:: (1/1) Parsing SRCINFO: pwvucontrol
==> Making package: pwvucontrol 0.5.3-2 (Sun 19 Jul 2026 08:32:30 PM +03)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found pwvucontrol-0.5.3.tar.gz
==> Validating source files with b2sums...
    pwvucontrol-0.5.3.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error making: pwvucontrol-exit status 1
 -> Failed to install the following packages. Manual intervention is required:
pwvucontrol - exit status 1

@pirgosth Thanks for letting me know! Otherwise I would have missed that. As far as I can see, there are only two commits added since the first release of 0.5.3. One of them was the wrong version in the 'about' window, the other the dependency updates. I think it's fine. The PKGBUILD is now updated.

I'm wondering if I should let the upstream people know, that this kind of re-release of the same version is causing these kind of troubles.

@moabeat Hi, the release for 0.5.3 was updated using the same release version as before, causing a Failed validation for checksum. I've checked it and it's about dependencies upgrades. Here is the commit in question: https://github.com/saivert/pwvucontrol/commit/fd5c9d1e5458b625d45e4159634b5b072f66cde1

If everything's good, we just need to update the b2sum with the new binary, hoping this is not some obscure form of hack attempt.

Thanks!

@moabeat: As of 0.5.2, this now requires blueprint-compiler to build. git is not needed at all. This also uses appstream-glib in the Meson test for validating the AppStream file and should be added to checkdepends().

This has been failing to compile since the 14th. You can find more information in the upstream issue where I added my investigation: https://github.com/saivert/pwvucontrol/issues/99#issuecomment-4065764789

@moabeat Realized the lack of support for latest wireplumber.. I'll have to hold off until that is resolved.

Thanks anyways!

@carsme Sure! I am happy to see it in the official repositories! However, you would need to take into account, the latest release version still uses the earlier version 0.4.17 of libwireplumber which is also in the AUR. Upstream struggles with moving to version 0.5.x, as the wireplumber-rs crate seems to be not actively maintained anymore. But there are some good news lately for another solution.

Unfortunately, on top of this, I made a mistake when creating this package and wrongly named it libwireplumber-4.0-compat. This could be a good time to correct it and name it correctly libwireplumber-0.4-compat.

The 0BSD license has been added to both packages now. Cheers!

I'm planning to move this to the official repositories. In order to base our package on your PKGBUILD, we'll need you to license it under 0BSD, see https://rfc.archlinux.page/0040-license-package-sources/.

Could you add a 0BSD license file to the repository? Alternatively, run pkgctl license setup and it will do it for you.

Thanks for maintaining this so far!

The following comment might be useful for noobies like me who install rust as a dependency here (in my case as a result of installing libwireplumber-4.0-compat. The version of cargo that pacman installed with rust or rust up were old enough that the result of makepkg -sri of pwvucontrol ends badly:

INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /   
/home/scott/build/pwvucontrol/src/build
ninja: Entering directory `/home/scott/build/pwvucontrol/src/build'
[0/2] Generating data/dev-schema with a custom command
[1/2] Generating src/cargo-build with a custom command
error: failed to parse lock file at:                 
/home/scott/build/pwvucontrol/src/pwvucontrol-0.5.1/Cargo.lock

Caused by:
    lock file version `4` was found, but this version of Cargo does not understand this lock file, perhaps Cargo needs to be updated?
FAILED: [code=101] src/pwvucontrol 
/usr/bin/env CARGO_HOME=/home/scott/build/pwvucontrol/src/build/cargo-home CODEGEN_DIR=/home/scott/build/pwvucontrol/src/build/src/home/scott/.cargo/bin/cargo build --manifest-path /home/scott/build/pwvucontrol/src/pwvucontrol-0.5.1/Cargo.toml --target-dir /home/scott/build/pwvucontrol/src/build/src --release && cp src/release/pwvucontrol src/pwvucontrol
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

Various posts online suggest that you can just edit the top line of the lock file from "4" to "3". Unfortunately, the lock file is generated during the build process, so the lockfile is overwritten.

Since I don't know much more about rust than its existence, it took me some time to understand that the correct way to update cargo is just to run the command

$ rustup update

Note that you do this as user, not as root. (Running it as root will update /usr/bin/cargo, but if you installed rust as a dependency of libwireplumber-4.0-compat as i did, via makepkg, you have ~/.cargo/bin/cargo)

Bottom line: if you get that lockfile error, do rustup update