Package Base Details: lib32-gstreamer0.10-base

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

Latest Comments

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

Schmeidenbacher commented on 2014-11-01 16:53 (UTC)

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 (UTC)

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.

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

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

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