| Git Clone URL: | https://aur.archlinux.org/lib32-gstreamer.git (read-only, click to copy) |
|---|---|
| Package Base: | lib32-gstreamer |
| Description: | Multimedia graph framework (32-bit) - base plugins |
| Upstream URL: | https://gstreamer.freedesktop.org/ |
| Licenses: | LGPL-2.1-or-later |
| Submitter: | patlefort |
| Maintainer: | patlefort |
| Last Packager: | patlefort |
| Votes: | 39 |
| Popularity: | 13.79 |
| First Submitted: | 2026-04-05 17:52 (UTC) |
| Last Updated: | 2026-07-16 18:04 (UTC) |
Yes I know it is not you who control this. It was more likely just a general feedback.
Afaik, as of why it was removed was something to do with CVE (not my post) : https://discuss.cachyos.org/t/arch-broke-cachyos-gaming-today-lib32-gst-plugins-base-libs-cachyos-gaming-meta-cachyos-gaming-applications/27182/8
I don't control official arch repos nor do I know why it was removed. Putting it here is the next best option.
Right. I'm not sure what changed since April 5th or even since yesterday evening - when I was still facing this conflict. Nothing changed on my PC in the meantime, as I powered it off right after my last attempt (so my previous comment was based on my consistent experience from the 5th up until 12 hours ago). However, when I attempted the installation today (now, few minutes ago) to gather logs for you, but now everything went through without any conflicts (??? confusedface)
It seems the dependency hell resolved itself for now, but I’m going to keep my eyes open. If the problem reappears - especially after a package update - I’ll report back with the details. For now, it seems to be working, but moving this to AUR still feels like it creates unnecessary friction for many users.
I don't understand the problem. lib32-pipewire-jack provides lib32-jack. Also it is only a make dependency, building in a clean container is always preferred.
The removal of lib32-jack from multilib and its current state in AUR is causing a major dependency deadlock for wine-meta (Garuda) users. On Garuda and other Arch-based distros, trying to resolve this often leads to conflicts where the system tries to replace the entire sound stack (Pipewire/Pulse) with legacy Jack components.
As @rusted mentioned, we desperately need a solution that plays nice with modern setups. Most of us are using Pipewire, so a proper lib32-pipewire-jack provider for the dependency tree is essential. Moving this to AUR without a seamless transition was a massive oversight that broke gaming for many of us. Please consider restoring the previous functionality or providing a dummy/provider package to break this dependency hell.
Oh, oops. Yeah thanks.
Import the key into your gpg keyring with gpg --receive-keys D637032E45B8C6585B9456565D2EEE6F6F349D7C.
==> Validating source files with b2sums...
gstreamer ... Passed
0001-HACK-meson-Disable-broken-tests.patch ... Passed
==> Verifying source file signatures with gpg...
gstreamer git repo ... FAILED (unknown public key 5D2EEE6F6F349D7C)
==> ERROR: One or more PGP signatures could not be verified!
Package failed to build on my machine with this error:
gstreamer/subprojects/gstreamer/libs/gst/helpers/ptp/meson.build:26:4: ERROR: Problem encountered: PTP not supported without Rust compiler
I had been providing rust with rustup. When I replaced that package with plain rust, the build got past that error.
I'm not sure what to make of that, myself, but at least for now, maybe this comment will save someone else some time.
calling lib32-jack2 specifically leads to an unresolvable conflict for people using pipewire-jack, this should probably use lib32-jack instead
Pinned Comments
patlefort commented on 2026-05-18 20:11 (UTC)
A copy of the GPG key is located in
keys/pgpof this package.gpg --import keys/pgp/D637032E45B8C6585B9456565D2EEE6F6F349D7C.asc