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.63
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 Next › Last »

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.

shaybox commented on 2026-05-15 15:44 (UTC)

patlefort My goodness read the comments, you need to add rustup target add i686-unknown-linux-gnu to your PKGBUILD

1 2 3 4 5 Next › Last »