Package Details: lib32-gstreamer 1.28.3-1

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) - core
Upstream URL: https://gstreamer.freedesktop.org/
Licenses: LGPL-2.1-or-later
Submitter: patlefort
Maintainer: patlefort
Last Packager: patlefort
Votes: 28
Popularity: 17.27
First Submitted: 2026-04-05 17:52 (UTC)
Last Updated: 2026-05-15 17:14 (UTC)

Pinned Comments

patlefort commented on 2026-05-18 20:11 (UTC)

A copy of the GPG key is located in keys/pgp of this package.

gpg --import keys/pgp/D637032E45B8C6585B9456565D2EEE6F6F349D7C.asc

Latest Comments

1 2 3 4 5 6 Next › Last »

codemutation commented on 2026-05-19 03:55 (UTC)

I was hitting the same issue with not being able to fetch the key, and as multiple people suggested I tried:

gpg --keyserver hkps://pgp.mit.edu --recv-keys D637032E45B8C6585B9456565D2EEE6F6F349D7C

Which also kept giving me:

gpg: keyserver receive failed: No keyserver available

Until I tried about 9 hours later and it immediately worked:

gpg: key 5D2EEE6F6F349D7C: public key "Tim Müller <tim@gstreamer-foundation.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Then as multiple people have suggested, I also needed to run:

rustup target add i686-unknown-linux-gnu

And then it worked.

I shared the key on ipfs with pinata so that it's easy to get:

ipfs cat bafkreielxq2umw3k24y5jsgy42ec64geygfze6qey6nu3kq5u3pwoou5ou | gpg --import

Or using the gateway:

curl -fsSL https://ipfs.io/ipfs/bafkreielxq2umw3k24y5jsgy42ec64geygfze6qey6nu3kq5u3pwoou5ou | gpg --import

If you run an externally discoverable ipfs node, help make it more available by pinning it:

ipfs pin add bafkreielxq2umw3k24y5jsgy42ec64geygfze6qey6nu3kq5u3pwoou5ou

patlefort commented on 2026-05-18 20:11 (UTC)

A copy of the GPG key is located in keys/pgp of this package.

gpg --import keys/pgp/D637032E45B8C6585B9456565D2EEE6F6F349D7C.asc

WildCard65 commented on 2026-05-18 20:02 (UTC)

gpg key D637032E45B8C6585B9456565D2EEE6F6F349D7C doesn't exist on a keyserver, unable to update.

patlefort commented on 2026-05-16 07:37 (UTC)

lib32-flex is not needed.

veganvelociraptr commented on 2026-05-16 07:33 (UTC)

@Vryali, thank you. That fixed the 'Program 'flex win_flex' not found or not executable' error. @patlefort, yes I do have base-devel installed. lib32-flex, however, wasn't istalled.

Still trying to work my way around the cdda_paranoia error.

nirnakinho commented on 2026-05-16 07:15 (UTC)

Thanks for the replies, I hadn't suspected rustup being the cuplrit here, when used instead of the normal rust package. amiablechiefs comment, adding the 32bit target to rustup, fixed the problem for me.

Regards,

patlefort commented on 2026-05-16 07:07 (UTC)

bison and flex are installed as part of base-devel which is assumed to be installed.

Vryali commented on 2026-05-16 00:02 (UTC)

Installing lib32-flex & bison did fix the error @veganvelociraptr reported that I also ran into.

Unsure if it's due to changing deps (not ran into this package failing to build before) or something I did on my system, but fix was fair simple.

airbreather commented on 2026-05-15 16:53 (UTC) (edited on 2026-05-15 20:44 (UTC) by airbreather)

I wouldn't say it's the only correct way to build packages, but I do want to point out that trying it that way is one of the steps recommended on: https://wiki.archlinux.org/title/Arch_User_Repository#Debugging_the_package_build_process

The "no automatic toolchain when using rustup" issue is mentioned multiple times on the ArchWiki page for Rust, including here: https://wiki.archlinux.org/title/Rust#Usage

Edit to add: in case it's not clear, this is me agreeing with @patlefort. I sympathize with those who suddenly started running into unexpected problems when this package moved out of the supported repos. I would have had those same problems if this had happened many years ago. But it's absolutely not the responsibility of the maintainer to either:

  1. add explicit workarounds to compensate for documented quirks about the exact mechanism by which a dependency of a dependency is provided, or
  2. go out of their way to pin a comment instructing users on which subset of the routine AUR procedures will be needed under common circumstances.

patlefort commented on 2026-05-15 16:32 (UTC)

It's not my responsibility to do what the user should know when they decided to install rustup instead of rust. Also, and I repeat, the only correct way to build packages is in clean containers. If it builds with makechrootpkg, provided you have a sane makepkg.conf and building against Arch and not some derivative, the package is fine. Otherwise, it's endless issues with broken systems and maintainers can't support everything.

1 2 3 4 5 6 Next › Last »