Bugzilla Bug 56621

see summary. ;-)

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=35122) [edit]
gst-python-0.7.92.ebuild

prefered location: dev-python/gst-python
homepage: http://gstreamer.freedesktop.org/

This ebuild failed to work due to a problem with xmlto not being able to
convert HTML to text or something.  I fixed that by editting the eBuild so that
it wouldn't compile the documentation.

That was only the first problem.  Second problem is that Python's dl module
doesn't seem to exist, so gst-python doesn't work anyway, seeing as it needs to
import this module:

bash-2.05b$ python ./player.py
Traceback (most recent call last):
  File "./player.py", line 22, in ?
    import gst
  File "/usr/lib/python2.3/site-packages/gst/__init__.py", line 24, in ?
    import dl
ImportError: No module named dl

And so that is where this seemingly broken eBuild stands...

No, it isn't broken, it WORKS!

stefan@wintv:/vol1/rip> python /usr/share/doc/gst-python-0.7.92/examples/gstplay/player.py ride.wav
stream length: 00:00:00.000000

and music is playing.

maybe some missing dependencies?

ok, I re-emerged my ebuild.

1. no xmlto problem
2. player.py works

and now?

we have to find out, what's missing. I think I forgot one or more needed dependencies. So I have the needed packages installed and you not. So the only thing we have to do, is to fix the DEPEND=".." line.

python "import dl; help(dl)"

----------------------------------------

Help on module dl:

NAME
    dl

FILE
    /usr/lib/python2.3/lib-dynload/dl.so

CLASSES
    exceptions.Exception
        error

    class error(exceptions.Exception)
     |  Methods inherited from exceptions.Exception:
     |
     |  __getitem__(...)
     |
     |  __init__(...)
     |
     |  __str__(...)

FUNCTIONS
    open(...)

DATA
    RTLD_GLOBAL = 256
    RTLD_LAZY = 1
    RTLD_LOCAL = 0
    RTLD_NODELETE = 4096
    RTLD_NOLOAD = 4
    RTLD_NOW = 2

epm -qf /usr/lib/python2.3/lib-dynload/dl.so

python-2.3.4

so it seems, that you have a broken python installation. Try to fix this first!

my python-USE-flags:

+X -berkdb -bootstrap -build -debug -doc +gdbm +ipv6 +ncurses +readline +ssl +tcltk -ucs2

Alright, for starters, your USE flags are invalid.  Emerge complains out the
wang if you prepend USE flags with the + sign.  Secondly, I just reemerged
Python and it still didn't give me the necesary dl.so file.  I then proceded to
download the latest stable version (2.3.4) from python.org and configure and
compile it by hand.  I tried a couple different options and it still didn't
give the dl.so file.

On a side note, my system's install is a stage1 install less than two weeks
old.

As far as the xmlto error goes, I haven't looked at that in detail, all I know
is that regardless of whether I emerge gst-python or compile it from scratch it
gives me the error unless I configure it with --disable-docs.

Hold, I found the problem.  Gentoo doesn't have the dl module anyway.  I'm
looking at the CVS repository for gst-python and reading changes to the file
that calls import dl.  A change has been made so that it doesn't import that
module.  It even specifically mentions Gentoo.

So, in whort, we need an ebuild that pulls it from CVS in order for it to work
on modern Gentoo systems...

well, why in hell does *my* python has dl.so?
it's also a stage1 install!

Wait, I check it on another PC...

epm -qa | grep ^python-2

python-2.3.4

on all machines

epm -ql python | sort | grep "dl.so"

pc1: /usr/lib/python2.3/lib-dynload/dl.so
pc2: /usr/lib/python2.3/lib-dynload/dl.so
laptop: /usr/lib/python2.3/lib-dynload/dl.so

three machines, three times the same result. So either my Gentoo's are alien or yours!

and all are stage1 installations (of course! ;-)).

btw: my USE-flags are correct. It was just the output of

emerge -pv python

so that I can post only the relevant flags.

here are my "real" USE-flags:

USE="3dnow aac acl acpi adns amd artswrappersuid async audiofile bidi \
     bzlib caps cdb cddb cdf cdparanoia cdrom chroot codecs curl \
     curlwrappers dga dio djbfft dnd dts dv dvd dvdr dvdread exif expat \
     ext-png ext-zlib extensions faac faad fam fbcon ffmpeg fftw flac \
     flash foreign-package foreign-sysvinit freetype gd gd-external \
     gettext gimp gimpprint glut gmp gs gstreamer gtkhtml gui icq idea idl \
     ieee1394 imagemagick imap imlib2 inifile innodb ipv6 jabber jack \
     jack-tmpfs java javascript jbig jikes jit joystick jp2 ladcca lcms \
     libcaca libsamplerate live lzo lzw lzw-tiff matroska mbcvs mbox mcal \
     md5sum memlimit mmx mng monkey mozcalendar mozdomi moznocompose \
     moznoxft mozp3p mozsvg mpeg4 mplayer mysqli native net network nis \
     nptl nvidia offensive ooo-kde openal pcre pda pic plotutils portaudio \
     posix ppds psyco pthreads recode rtc samba shared sharedmem slp \
     sndfile socks5 sox speex sqlite svg szip t1lib theora threads tiff \
     timidity transcode type1 usb v4l v4l2 wifi wmf wxwindows X509 xalan \
     xbase xface xine xinerama xml xosd xprint xsl xvid yv12 -gpm -gtk2 \
     -gnome -berkdb"

ok, now I check the python-ebuild. It's an absolute bad habbit not to use
'use_with' and 'use_enable' for *all* supported configure-flags, but let the
configure choose some of the flags. So you can't reproduce a merge, if you
don't know all the other installed libs.

here are some flags, which should be added (or fixed internally) to the
python-ebuild:

--with-signal-module
--with(out)-universal-newlines
--with(out)-doc-strings  (could be used with 'doc' flag)
--with-dl-dld=DL_DIR (aha!)
--with-wctype-functions

now I try to figure out, when and where the dl-module is auto-selected.

./configure --prefix=/tmp/python

[..]
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
[..]

the code in question is this one:

./Modules/dlmodule.c

in ./setup.py, we find this one:

  # Dynamic loading module
  if sys.maxint == 0x7fffffff:
      # This requires sizeof(int) == sizeof(long) == sizeof(char*)
      dl_inc = find_file('dlfcn.h', [], inc_dirs)
      if (dl_inc is not None) and (platform not in ['atheos', 'darwin']):
          exts.append( Extension('dl', ['dlmodule.c']) )

so 'dl.so' will not be built, when:

- sys.maxint isn't 0x7fffffff (perhaps on some 64-Bit archs)
- dlfcn.h can't be found

dlfcn.h is located in /usr/include/dlfcn.h (at least on my systems).

epm -qf /usr/include/dlfcn.h

tells me: glibc-2.3.4.20040619

so it's part of glibc.

hmmm...

hmmm. It's not clever to use 'dl', when the above rules are not met and so
'dlmodule' isn't available. *THIS* is really a Bug in gst-python. Nonetheless,
it should be there at least on x86 (for which my ebuild was made and tested,
see 'KEYWORDS').

[/usr/lib/python2.3/site-packages/gst/__init__.py]

import sys
import dl

try:
   import ltihooks
except:
   pass

import gobject
del gobject

sys.setdlopenflags(dl.RTLD_LAZY | dl.RTLD_GLOBAL)
del sys, dl

from _gst import *

Did you even look at the current CVS snapshot of gst-python?  It replaces dl
with dlfcn.  Not to mention, the CVS snapshot compiles and runs cleanly on my
machine, as opposed to the version this eBuild is for.

Secondly, this is an AMD64 machine.

hmpf! ;-)

I thought that, that you have amd64, because of the
"if sys.maxint == 0x7fffffff:" stuff.

well, my ebuild was correctly marked with KEYWORDS="~x86" so
it's clear, that I've tested it only on x86! If I had tested
it on other platforms, I would have set the corresponding
flags also. So it was not my fault nor the fault of my ebuild.

Please test it on x86 and put it into portage with '~x86'
for the time being. If the cvs code is released, then we
can set other platforms as well. I don't think, it's a
good idea to use cvs (and though unstable) code.

low prio, development release 

open

Created an attachment (id=42411) [edit]
gst-python-0.7.93.ebuild

Latest version of gst-python ebuild

Created an attachment (id=43408) [edit]
gst-python-0.7.94.ebuild

Version bump

gst-python-0.8.0 is out so will wait till freedesktop is fully operational
before posting an updated ebuild

*** Bug 76790 has been marked as a duplicate of this bug. ***

This has turned stagnant.

Still no ebuild in Portage? What's causing the problems?

don't know. So 'remind', 'remind', 'remind'. ;-)

Created an attachment (id=52621) [edit]
gst-python-0.8.1.ebuild

Version bump

remind again. what's the stopper?

we'll get it in :)

ok committed into portage

ebuild is no good..

not as bad as i thought it was...