Arch Linux User Repository

@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

You are right, thank you very much for pointing this out! I will adapt this latest with the next upstream release. I think it doesn't need a new package release only for that, as this is only a minor inconvenience.

I can confirm yochananmarqos's comment. pwvucontrol 0.5.0-1 builds fine in a clean chroot without cmake.

@moabeat: This does not require cmake to build.

The 0.4.9 version doesn't build on rust versions < 1.80. Github Issue.