Package Base Details: lib32-gstreamer0.10-base

Git Clone URL: https://aur.archlinux.org/lib32-gstreamer0.10-base.git (read-only, click to copy)
Submitter: alucryd
Maintainer: None
Last Packager: micwoj92
Votes: 36
Popularity: 0.23
First Submitted: 2014-09-22 09:13
Last Updated: 2020-11-30 19:22

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

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.