Summary: | media-video/vlc - add mediacontrol python bindings | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stefan de Konink <stefan> |
Component: | New packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | sergio.rodriguez.inclan |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stefan de Konink
2006-09-08 14:43:16 UTC
There is an issue... running build_scripts creating build/scripts-2.4 copying ./vlcwrapper.py -> build/scripts-2.4 changing mode of build/scripts-2.4/vlcwrapper.py from 644 to 755 running install_lib copying build/lib.linux-x86_64-2.4/vlc.so -> /usr/lib64/python2.4/site-packages error: /usr/lib64/python2.4/site-packages/vlc.so: Permission denied make[3]: *** [install] Error 1 make[3]: Leaving directory `/var/tmp/portage/vlc-0.8.5-r5/work/vlc-0.8.5/bindings/mediacontrol-python' So probably needs a sed in the makefile. (Not that trivial...) sed -i -e "s:setup.py install:setup.py install --root=\"${D}\":" bindings/mediacontrol-python/Makefile.am In the unpack section. Has this been reported upstream ? That would be a good idea not having to do that in the ebuild and let them modify their makefile so that it's sane with a sandbox. Perhaps adding --root=${DESTDIR} could do the trick (note that I've not tested it myself) (In reply to comment #3) > Has this been reported upstream ? Not by me. (In reply to comment #4) > (In reply to comment #3) > > Has this been reported upstream ? > > Not by me. > Then, could you please do so ? I don't think it's a good idea to add features that need some patching to gentoo ebuild without making sure that it's fixed upstream. (In reply to comment #5) > Then, could you please do so ? I don't think it's a good idea to add features > that need some patching to gentoo ebuild without making sure that it's fixed > upstream. Yes, I could. But what 'we' want, isn't this related to Gentoo? How would the automake utilities handle this DESTDIR / D? Because I thought that was pretty gentoo specific? D is gentoo specific, but DESTDIR is standard for autotools, that's why I suggested using DESTDIR rather than D ;) and that's also why we're doing "emake DESTDIR="${D}" install" in src_install (In reply to comment #7) > D is gentoo specific, but DESTDIR is standard for autotools, that's why I > suggested using DESTDIR rather than D ;) > > > and that's also why we're doing "emake DESTDIR="${D}" install" in src_install Taken that, I just looked at the vlc svn, and it looks they solved it in an other way. Currently I have a problem to compile the media bindings due to 32bit issues: creating ../../bindings/mediacontrol-python/lib.linux-x86_64-2.5 x86_64-pc-linux-gnu-gcc -pthread -shared -Wsign-compare -Wall -march=athlon64 -O2 -pipe -msse3 -pipe ../../bindings/mediacontrol-python/./vlcglue.o ../../bindings/mediacontrol-python/./../../src/control/mediacontrol_init.o ../../src/libvlc.a -L/usr/lib/python2.5/config -lpython2.5 -o ../../bindings/mediacontrol-python/lib.linux-x86_64-2.5/vlc.so -L../.. ../../modules/misc/memcpy/libmemcpymmx.a ../../modules/video_chroma/libi420_rgb_mmx.a ../../modules/video_chroma/libi422_yuy2_mmx.a ../../modules/video_chroma/libi420_ymga_mmx.a ../../modules/video_chroma/libi420_yuy2_mmx.a ../../modules/misc/memcpy/libmemcpymmxext.a ../../modules/misc/memcpy/libmemcpy3dn.a ../../modules/codec/libtheora.a -L/usr/lib64 -lhal -ldbus-1 -lrt -lpthread -ldl -lm -ltheora -logg x86_64-pc-linux-gnu-gcc: ../../src/libvlc.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/misc/memcpy/libmemcpymmx.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/video_chroma/libi420_rgb_mmx.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/video_chroma/libi422_yuy2_mmx.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/video_chroma/libi420_ymga_mmx.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/video_chroma/libi420_yuy2_mmx.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/misc/memcpy/libmemcpymmxext.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/misc/memcpy/libmemcpy3dn.a: No such file or directory x86_64-pc-linux-gnu-gcc: ../../modules/codec/libtheora.a: No such file or directory error: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1 make[3]: *** [all] Error 1 make[3]: Leaving directory `/var/tmp/paludis/media-video/vlc-0.8.6_p18636/work/vlc-0.8.6_p18636/bindings/mediacontrol-python' I added to the ebuild: IUSE; python if use python; then myconf="${myconf} --enable-mediacontrol-python-bindings" fi So I want to try it on a 32bit machine first if it isn't already fixed. It's not a 32/64 bit issue. According to [1] the --enable-mediacontrol-python-bindings and --enable-libtool configure flags are mutually exclusive in VLC 0.8.6. Gentoo's VLC needs --enable-libtool so the Python bindings are impossible for now. Fortunately this conflict is resolved in the VLC 0.9 series currently under development in svn. [1] http://wiki.videolan.org/Python_bindings#Building_notes in 0.9.5: dnl Deprecated options dnl to notify packagers that stuff has changed dnl AC_ARG_ENABLE(python-bindings, [ --enable-python-bindings Always fails for historical reasons)],, [enable_python_bindings="no"]) AS_IF([test "${enable_python_bindings}" != "no"], [ AC_MSG_ERROR([Python bindings are now built from a separate source package]) ]) so that's a wontfix on vlc's side :( |