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: 18.35
First Submitted: 2026-04-05 17:52 (UTC)
Last Updated: 2026-05-15 17:14 (UTC)

Sources (2)

Latest Comments

1 2 3 4 5 Next › Last »

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

amiablechief commented on 2026-05-15 11:51 (UTC)

Compilation succeeds if you run the following command ahead of installing:

rustup target add i686-unknown-linux-gnu

Frestein commented on 2026-05-14 08:22 (UTC)

@patlefort If you're so smart, you would write an answer to the most common problems in a separate comment and pin it. That's common practice.

1 2 3 4 5 Next › Last »