Package Details: lib32-gstreamer0.10-base 0.10.36-7

Git Clone URL: https://aur.archlinux.org/lib32-gstreamer0.10-base.git (read-only)
Package Base: lib32-gstreamer0.10-base
Description: GStreamer Multimedia Framework Base plugin libraries
Upstream URL: http://gstreamer.freedesktop.org/
Licenses: LGPL
Submitter: alucryd
Maintainer: alucryd
Last Packager: alucryd
Votes: 23
Popularity: 1.072215
First Submitted: 2014-09-22 09:13
Last Updated: 2015-06-09 12:23

Latest Comments

alucryd commented on 2014-12-16 07:55

--disable-examples does not, --disable-introspection does. Added it, I just hope nothing needed those .gir...

padfoot commented on 2014-12-16 06:36

I hope these packages get working again. While they may not be required for anything in the official repositories, there are games from steam, humble bundle etc that do require these libraries.


Currently I have held pacman on the last versions I had installed from multilib so I can still play my games.

mhspace commented on 2014-12-09 19:07

--disable-examples fixes build issues

mhspace commented on 2014-12-09 19:07

--disable-examples fixes build issues

Eachna commented on 2014-11-11 03:50

Three points just as a FYI...

1) This particular package is missing a pre-built binary. The binaries linked below are (useful) dependencies, not this package.

2) alucryd's unofficial repo mentioned below doesn't have PGP keys for some (all?) of the lib32 binaries, including this one (lib32-gstreamer0.10-base).

GordonGR commented on 2014-11-05 11:55

I understand. Unfortunately the issue will not be resolved soon, so pre-built binaries are necessary. For example:
https://code.google.com/p/singularity-viewer/issues/detail?id=1551&q=gstreamer&colspec=ID%20Type%20Status%20Priority%20Stars%20Milestone%20Owner%20Summary%20Opened%20Modified

At least the good-bad-ugly plugins still build.

As for the packages, I'm keeping up, but feel free to adopt any you like in general. No ego here :)

alucryd commented on 2014-11-05 11:30

GordonGR; Anytime :)

The reason why I demoted it to AUR is because we thought it was time we let gstreamer0.10 die, and the only multilib package that depended on it was lib32-wxgtk2.8, from which I removed gst support because pcsx2 doesn't need it. It's not that easy for the regular gstreamer0.10 unfortunately, a few popular packages still depend on it, and a lot more indirectly via wxgtk{,2.8}.

I wasn't expecting to get so many complaints about it not building outside of a chroot either, and as some users can now tell, patience is not exactly one of my virtues :P So, pre-built packages are back.

I'll take you on your offer and adopt lib32-gtk3 then. BTW, packages on that repo are automatically built every night at midnight CET if I pushed an updated PKGBUILD on my Github repo anytime before then, so updates are usually quick.

GordonGR commented on 2014-11-05 11:12

Thank you, alucryd. Though I must admit I fail to see why you took the packages off [multilib] if you were to put them in your own repository… but that's none of my business.

PS: I notice you have in your repository lib32-gtk3, which I maintain in AUR. Feel free to take it over there too if you wish.

Again, thanks for the compiled packages.

alucryd commented on 2014-11-05 09:31

I'm not exactly keen on wasting resources for this, but still, I've included them in my multilib repo: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#alucryd-multilib

GordonGR commented on 2014-11-04 14:22

I can't build it either. Error log here:
https://dl.dropboxusercontent.com/u/4361965/lib32-gstreamer0.10-base-0.10.36-6-x86_64-build.log

I haven't tried chroot yet.

My piece of input is that I have an Intel card, so I'm using lib32-mesa-libgl 10.3.2-1.

I understand gstreamer 0.10 is ancient, but I understand second life viewers still use it, hence the need for it to remain…

PS: Bason, thank you for the binaries. Do you think you can upload the -plugins package too?

alucryd commented on 2014-11-02 10:18

Same here, this is not related to libgl.

Bazon: Thx for providing those built packages.

alucryd commented on 2014-11-02 10:18

Same here, this is not related to libgl.

Bazon commented on 2014-11-02 10:07

PS:
I don't have lib32-nvidia-libgl but lib32-mesa-libgl and had to build in a chroot anyway.

Bazon commented on 2014-11-02 08:46

If it is useful for anyone: Ready-built package:
https://dl.dropboxusercontent.com/u/12168886/arch/lib32-gstreamer0.10-base-0.10.36-6-x86_64.pkg.tar.xz
Install with sudo pacman -U lib32-gstreamer0.10-base-0.10.36-6-x86_64.pkg.tar.xz

Note: You have to install the dependency lib32-gstreamer0.10-0.10.36-4 FIRST!
https://dl.dropboxusercontent.com/u/12168886/arch/lib32-gstreamer0.10-0.10.36-4-x86_64.pkg.tar.xz
Install with sudo pacman -U lib32-gstreamer0.10-0.10.36-4-x86_64.pkg.tar.xz
Status: Works for me.

techdude300 commented on 2014-11-01 18:32

I can also confirm that I can't build it, and I have lib32-nvidia-libgl. Makepkg output here: http://pastebin.com/WadistTM

What I notice in common with Schmeidenbacher is that I am also getting errors about memory:

GLib-ERROR **: gmem.c:353: overflow allocating 1852401526*4 bytes

This is possibly a bug in glibc? I'm not quite sure what this has to do with nvidia drivers, it's very strange. If there's any other debug info I can provide that would be helpful, let me know. Thanks!

Schmeidenbacher commented on 2014-11-01 16:53

I have a more complete error message for you.
http://pastebin.com/2Uds1HKm

While the package doesn't build on my system it does build in a chroot, as you said.

The only obvious difference i've noticed between those two systems was the difference in the lib32-libgl implementation used.

Since i have a nvidia card it i have lib32-nvidia-libgl installed, the chroot automatically chose lib32-mesa-libgs instead.

I have a suspicion that that actually might be the culprit.

@felipe.facundes, which implementation of lib32-libgl is installed on your system?

alucryd commented on 2014-11-01 09:51

DKay: I don't know why you deleted your comment, but anyway, I can still see it. You're right, I'm the worst for expecting people to know google-fu and how to rtfm.

Now, if you think you can do a better job with this dirty ancient broken package, you're welcome to try instead of just complaining. I will happily welcome patches, even hand over the package if you have something which builds outside of a chroot. Frankly, I have better things to do than fixing sth that for some unfathomable reason doesn't want to build anywhere but in a chroot.

As for lib32-libgl, there was a time when this convenience package didn't exist and we had to use lib32-mesa-libgl. Almost all packages needing lib32-libgl in [multilib] still want lib32-mesa-libgl. Anyway, I just fixed this.

felipe.facundes: The comment section isn't a log dump, please use an external service for that, not to mention your log isn't useful in any way, it doesn't show the actual error.

DKay commented on 2014-11-01 06:49

Judging by the package maintainer's despicable attitude, I doubt this package will ever be anything more than a clusterfuck of errors (did you seriously spend a whole paragraph passive-aggressively insulting someone for confusing a capital I with a lowercase L? what the fuck is wrong with you?)

I suggest YOU take the time to maintain your packages to an acceptable standard before throwing snarky lmgtfy.com links or suggesting that us filthy casuals should read more man pages. You have nobody to blame but yourself for this unworkable piece of shit.

Why did you make lib32-mesa-libgl a requirement? Make it lib32-libgl.

felipe.facundes commented on 2014-10-30 02:43

Makefile:1131: recipe for target 'GstInterfaces-0.10.gir' failed
make[5]: *** [GstInterfaces-0.10.gir] Error 1
make[5]: Leaving directory '/tmp/yaourt-tmp-rfacundes/aur-lib32-gstreamer0.10-base/src/gst-plugins-base-0.10.36/gst-libs/gst/interfaces'
Makefile:576: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[4]: Leaving directory '/tmp/yaourt-tmp-rfacundes/aur-lib32-gstreamer0.10-base/src/gst-plugins-base-0.10.36/gst-libs/gst/interfaces'
Makefile:817: recipe for target 'interfaces' failed
make[3]: *** [interfaces] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-rfacundes/aur-lib32-gstreamer0.10-base/src/gst-plugins-base-0.10.36/gst-libs/gst'
Makefile:471: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/tmp/yaourt-tmp-rfacundes/aur-lib32-gstreamer0.10-base/src/gst-plugins-base-0.10.36/gst-libs'
Makefile:591: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-rfacundes/aur-lib32-gstreamer0.10-base/src/gst-plugins-base-0.10.36'
Makefile:519: recipe for target 'all' failed
make: *** [all] Error 2

Bazon commented on 2014-10-05 19:33

I did not ask for baby sitting, my problem was solved before I wrote my first comment here. (See below.)
My intention was to give feedback in order to detect reproduceable problems. (works for me != works for all, you know.)
And at least the positive output of this is a detailed build instruction which may help other users in the future. Including the I-l problem.
Goodbye.

alucryd commented on 2014-10-05 18:58

I have to disagree, when something does not work, first thing I try is --help, that way you can understand why it doesn't work, do not blindly follow instructions and ask for baby-sitting whenever you run into an issue. Also, I'm not quite sure what you mean by effort because this is how all official packages are built, but anyway, packages have dependencies, deal with it.
Besides this was demoted to AUR because it's old, ugly, not to mention it's needed by packages that don't have x86_64 versions (most of them should be killed with fire), and as you can see, it doesn't even build outside a chroot. I don't know what the package you want is, but you might want to consider usint sth else.

Bazon commented on 2014-10-05 18:39

Oh, sorry. But in this case it's more a question of being able to distinguish "l" from "I"; whether it is written here or there...
(...or of screwing typing in favour of pasting.)

OK, so
$ sudo multilib-build -- -I lib32-gstreamer0.10-0.10.36-3-x86_64.pkg.tar.xz -I lib32-cdparanoia-10.2-2-x86_64.pkg.tar.xz -I lib32-orc-0.4.19-1-x86_64.pkg.tar.xz -I lib32-libtheora-1.1.1-9-x86_64.pkg.tar.xz -I lib32-libvisual-0.4.0-3-x86_64.pkg.tar.xz

did it.
After building lib32-cdparanoia, lib32-gstreamer, lib32-orc, lib32-libtheora and lib32-libvisual.

Quite some amount of effort just to get a package which is required for another package which is the one I really want to use...

alucryd commented on 2014-10-05 18:23

Sigh, I wonder why we keep including help dialogs in scripts and binaries because people never care to rtfm. Had you tried --help on multilib-build you'd have noticed that every flag passed after -- are makechrootpkg flags, then you would have been a single --help away from finding out that this is not an l but a capital I. An arch user is supposed to be familiar with man and --help.

Bazon commented on 2014-10-05 18:16

Sorry, that folder I talked about isn't empty, it includes a hidden folder which includes an empty file: /var/lib/archbuild/multilib-x86_64/lib32-gstreamer0.10-0.10.36-3-x86_64.pkg.tar.xz/build/.gnupg/pubring.gpg

Bazon commented on 2014-10-05 17:59

I tried
$ sudo multilib-build -- -l lib32-gstreamer0.10-0.10.36-3-x86_64.pkg.tar.xz -l lib32-cdparanoia-10.2-2-x86_64.pkg.tar.xz -l lib32-orc-0.4.19-1-x86_64.pkg.tar.xz -l lib32-libtheora-1.1.1-9-x86_64.pkg.tar.xz -l lib32-libvisual-0.4.0-3-x86_64.pkg.tar.xz
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
:: Starting full system upgrade...
there is nothing to do

==> Building in chroot for [multilib] (x86_64)...
==> Creating clean working copy [lib32-libvisual-0.4.0-3-x86_64.pkg.tar.xz]...done
==> Making package: lib32-gstreamer0.10-base 0.10.36-5 (Sun Oct 5 19:55:30 CEST 2014)
==> Retrieving sources...
-> Found gst-plugins-base-0.10.36.tar.xz
==> Validating source files with sha256sums...
gst-plugins-base-0.10.36.tar.xz ... Passed
==> ERROR: Build failed, check /var/lib/archbuild/multilib-x86_64/lib32-libvisual-0.4.0-3-x86_64.pkg.tar.xz/build


The directory /var/lib/archbuild/multilib-x86_64/lib32-libvisual-0.4.0-3-x86_64.pkg.tar.xz/build is empty, there is nothing to look at.

alucryd commented on 2014-10-03 13:49

You need to run "sudo multilib-build -- -I path/to/libfoo*.pkg.tar.xz", this will install the dep into the chroot. You need one -I before each dep.

Bazon commented on 2014-10-03 13:36

OK, I managed to build lib32-gstreamer0.10 in a chroot with multilib-build, but when I try the same with lib32-gstreamer0.10-base, I get dependency problems:
==> Making package: lib32-gstreamer0.10-base 0.10.36-5 (Fri Oct 3 15:31:42 CEST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
error: target not found: lib32-cdparanoia
error: target not found: lib32-gstreamer0.10>=0.10.35
error: target not found: lib32-orc
error: target not found: lib32-libtheora
error: target not found: lib32-libvisual

So how do I install these dependencies in the chroot? Sorry I didn't get it.

alucryd commented on 2014-10-03 11:20

Same as lib32-gstreamer0.10, please build in a clean chroot, build fails for some reason when building anywhere else :(

Bazon commented on 2014-10-03 11:02

Build fails for me.
Full output:
http://pastebin.com/k5dFXZ50

If anyone needs: Package from my /var/cache/pacman/pkg before:
https://dl.dropboxusercontent.com/u/12168886/arch/lib32-gstreamer0.10-base-0.10.36-5-x86_64.pkg.tar.xz
(use at your own risk of course, works for me.)