On 07/15/2011 01:55 AM, Ralf Gommers wrote:


On Wed, Jul 13, 2011 at 11:10 PM, Ilan Schnell <[email protected] <mailto:[email protected]>> wrote:

    Hello List,

    Varun, who is a debian packager ran into some problems while
    compiling Enable, as it uses numpy.distutils, which did not locate
    the location of the X11 libraries correctly.  Maybe this can be fixed
in the numpy 1.6.1 release.

It's a bit late for that, since we're at 1.6.1rc3, this is not a patch and I'm not even sure it should be fixed in numpy.distutils.

Right now the searched dirs are ['/usr/X11R6/lib', '/usr/X11/lib', '/usr/lib'] or its 64-bit equivalents. See around line 200 in system_info.py. Is your proposal to add any arch-dependent paths that Debian can think of to that?

Leaving it up to the packager to specify the correct path in site.cfg may be cleaner. Or just apply the patch you received to the ETS Agg build.

Cheers,
Ralf
I did not think that numpy uses X11 so this is just some system output that may be useful for the user. Yes, a ticket could be filed but Debian's multarch support is so 'new' (announcement thread: http://thread.gmane.org/gmane.linux.debian.devel.announce/1609).

I think it is is premature to address multarch support yet because it does require a specific version of numpy only using the correct libraries when the user has multiple architecture versions installed. That will also be a problem here because just adding the paths alone is probably insufficient for the application to find the correct libraries.

Bruce






     Please the the forwarded conversation
    below.

    Thanks   Ilan


    ---------- Forwarded message ----------
    From: Varun Hiremath <[email protected]
    <mailto:[email protected]>>
    Date: Wed, Jul 13, 2011 at 4:03 PM
    Subject: [Enthought-Dev] Linking issues with libX11.so
    To: [email protected] <mailto:[email protected]>


    Hi Ilan,

    You were right, the issue was with the X11 library. The
    _plat_support.so was not linked to libX11 and so the chaco examples
    were failing; and the reason libX11 was not linked was because numpy
    distutils' x11_info was failing.

    I figured out that in debian/ubuntu with a new multi_arch build
    support [1] the libraries are being moved from the standard /usr/lib
    and /usr/lib64 directories to architecture specific directories like:

    /usr/lib/i386-linux-gnu/
    /usr/lib/x86_64-linux-gnu/

    and so the numpy.distutil was failing to find libX11 with the latest
    version of libX11-dev on debian which installs libX11.so in
    /usr/lib/x86_64-linux-gnu/ (on my amd64 system). The nump.distutils'
    scripts need to be updated to handle this, but for now I am using the
    following patch to force _plat_support.so link with X11 (which I think
    is always present in the default search path):

    ---------------------------
    @@ -230,6 +144,7 @@
        elif plat in ['x11','gtk1']:
            x11_info = get_info('x11', notfound_action=1)
            dict_append(plat_info, **x11_info)
    +        dict_append(plat_info, libraries = ['X11'])

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

    With this everything seems to be working fine!

    Thanks,
    Varun

    [1] https://wiki.ubuntu.com/MultiarchSpec

    On Mon, Jul 11, 2011 at 10:53 PM, Ilan Schnell
    <[email protected] <mailto:[email protected]>> wrote:
    > Hello Varun,
    >
    > the important part is: _plat_support.so: undefined symbol:
    XCreateImage
    > This indicates that the kiva/agg/_plat_support.so C extension was
    > not linked to X11 while compiling.  Until
    >
    
https://github.com/enthought/enable/commit/ebecdbfc5c4596282204e61ff687c3ab2442947a
    > which was made shortly after the release, it was easy to create
    a broken
    > Enable build like this one.  Note that this commit does *not*
    fix the problem,
    > it only causes the build to fail right away, instead of creating
    a broken build.
    > This was added because of the famous esr quote:
    > "When you must fail, fail noisily and as soon as possible."
    >
    > As enable uses numpy.distutils to build agg, the fix is to edit:
    > <python prefix>/lib/python2.6/site-packages/numpy/distutils/site.cfg
    >
    > and add:
    > [x11]
    > library_dirs = ...
    > include_dirs = ...
    >
    > - Ilan
    >
    >
    > On Mon, Jul 11, 2011 at 9:23 PM, Varun Hiremath
    <[email protected] <mailto:[email protected]>> wrote:
    >> Hi all,
    >>
    >> I am facing another issue running chaco examples with the new
    ETS 4.0
    >> packages. I am getting the following error when I run any chaco
    >> example:
    >> --------------------------
    >> $$ python zoom_plot.py
    >> /usr/lib/python2.6/dist-packages/enable/wx/image.py:16:
    Warning: Error initializing Agg:
    /usr/lib/python2.6/dist-packages/kiva/agg/_plat_support.so:
    undefined symbol: XCreateImage
    >>  from kiva.agg import CompiledPath, GraphicsContextSystem as
    GraphicsContext
    >> Traceback (most recent call last):
    >>  File "zoom_plot.py", line 15, in <module>
    >>    from enable.api import Component, ComponentEditor
    >>  File "/usr/lib/python2.6/dist-packages/enable/api.py", line
    42, in <module>
    >>    from graphics_context import GraphicsContextEnable,
    ImageGraphicsContextEnable
    >>  File
    "/usr/lib/python2.6/dist-packages/enable/graphics_context.py",
    line 86, in <module>
    >>    class GraphicsContextEnable(EnableGCMixin, GraphicsContext):
    >> TypeError: Error when calling the metaclass bases
    >>    metaclass conflict: the metaclass of a derived class must be
    a (non-strict) subclass of the metaclasses of all its bases
    >> -------------------------
    >>
    >> Does anybody know what could be the problem?
    >>
    >> Thanks,
    >> Varun
    >>
    >> p.s. Most of the ETS 4.0 debian packages are now available in
    debian unstable.
    >>
    >>
    >> On Sat, 09 Jul, 2011 at 12:45:32PM -0500, Ilan Schnell wrote:
    >>> I'm glad it worked.  That's a good idea, I'll release
    traitsui-4.0.1
    >>> later today.
    >>>
    >>> - Ilan
    >>>
    >>>
    >>> On Sat, Jul 9, 2011 at 11:20 AM, Varun Hiremath
    <[email protected] <mailto:[email protected]>> wrote:
    >>> > Hi Ilan,
    >>> >
    >>> > Thanks, that worked! Are you planning on doing a point
    release for
    >>> > traitsui to fix this bug? It would make packaging easier then.
    >>> >
    >>> > Thanks,
    >>> > Varun
    >>> >
    >>> > On Sat, 09 Jul, 2011 at 11:11:26AM -0500, Ilan Schnell wrote:
    >>> >> Hello Varun,
    >>> >>
    >>> >> I ran into the same bug when preparing the EPD 7.1 release.
    >>> >> The fix is commited to the github master of traitsui:
    >>> >>
    
https://github.com/enthought/traitsui/commit/4f36a8a27cfa131347dd90d1a8e10a37358cf634
    >>> >>
    >>> >> Just replace the two zip-files with the fixed ones, and it
    should work.
    >>> >>
    >>> >> - Ilan
    >>> >>
    >>> >>
    >>> >> On Sat, Jul 9, 2011 at 10:27 AM, Varun Hiremath
    <[email protected] <mailto:[email protected]>> wrote:
    >>> >> > Hi,
    >>> >> >
    >>> >> > I was trying to update the debian packages to the new ETS
    4.0 release,
    >>> >> > but I am having some trouble getting mayavi2 running. I
    get the error
    >>> >> > shown below when I run mayavi2. Could someone please let
    me know what
    >>> >> > might be causing this error?
    >>> >> >
    >>> >> > Thanks,
    >>> >> > Varun
    >>> >> >
    >>> >> > -----------------
    >>> >> > $ mayavi2
    >>> >> > Traceback (most recent call last):
    >>> >> >  File "/usr/bin/mayavi2", line 658, in <module>
    >>> >> >    main()
    >>> >> >  File "/usr/bin/mayavi2", line 649, in main
    >>> >> >    mayavi.main(sys.argv[1:])
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/mayavi/plugins/app.py", line
    195, in main
    >>> >> >    app.run()
    >>> >> >  File
    
"/usr/lib/python2.6/dist-packages/mayavi/plugins/mayavi_workbench_application.py",
    line 81, in run
    >>> >> >    window.open()
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py",
    line 144, in open
    >>> >> >    self._create()
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/pyface/ui/wx/application_window.py",
    line 150, in _create
    >>> >> >    contents = self._create_contents(body)
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py",
    line 217, in _create_contents
    >>> >> >    contents = self.layout.create_initial_layout(parent)
    >>> >> >  File
    
"/usr/lib/python2.6/dist-packages/pyface/ui/wx/workbench/workbench_window_layout.py",
    line 151, in create_initial_layout
    >>> >> >    self._wx_view_dock_window = WorkbenchDockWindow(parent)
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py",
    line 324, in __init__
    >>> >> >    if self.theme.use_theme_color:
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py",
    line 335, in _theme_default
    >>> >> >    return dock_window_theme()
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traitsui/dock_window_theme.py",
    line 92, in dock_window_theme
    >>> >> >    from .default_dock_window_theme import
    default_dock_window_theme
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traitsui/default_dock_window_theme.py",
    line 39, in <module>
    >>> >> >    label = ( 0, -3 ), content = ( 7, 6, 0, 0 ) ),
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traitsui/theme.py", line 63, in
    __init__
    >>> >> >    self.image = image
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traitsui/ui_traits.py", line
    229, in validate
    >>> >> >    self.error( object, name, value )
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traits/trait_handlers.py", line
    168, in error
    >>> >> >    value )
    >>> >> > traits.trait_errors.TraitError: The 'image' trait of a
    Theme instance must be an ImageResource or string that can be used
    to define one, but a value of '@std:tab_active' <type 'str'> was
    specified.
    >>> >> > Exception in thread Thread-1:
    >>> >> > Traceback (most recent call last):
    >>> >> >  File "/usr/lib/python2.6/threading.py", line 532, in
    __bootstrap_inner
    >>> >> >    self.run()
    >>> >> >  File "/usr/lib/python2.6/threading.py", line 484, in run
    >>> >> >    self.__target(*self.__args, **self.__kwargs)
    >>> >> >  File
    "/usr/lib/python2.6/dist-packages/traitsui/image/image.py", line
    329, in _process
    >>> >> >    if time() > (self.time_stamp + 2.0):
    >>> >> > TypeError: 'NoneType' object is not callable
    >>> >> > ---------------
    >>> >> > _______________________________________________
    >>> >> > Enthought-Dev mailing list
    >>> >> > [email protected]
    <mailto:[email protected]>
    >>> >> > https://mail.enthought.com/mailman/listinfo/enthought-dev
    >>> >> >
    >>> >> _______________________________________________
    >>> >> Enthought-Dev mailing list
    >>> >> [email protected]
    <mailto:[email protected]>
    >>> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
    >>> > _______________________________________________
    >>> > Enthought-Dev mailing list
    >>> > [email protected]
    <mailto:[email protected]>
    >>> > https://mail.enthought.com/mailman/listinfo/enthought-dev
    >>> >
    >>> _______________________________________________
    >>> Enthought-Dev mailing list
    >>> [email protected]
    <mailto:[email protected]>
    >>> https://mail.enthought.com/mailman/listinfo/enthought-dev
    >> _______________________________________________
    >> Enthought-Dev mailing list
    >> [email protected]
    <mailto:[email protected]>
    >> https://mail.enthought.com/mailman/listinfo/enthought-dev
    >>
    > _______________________________________________
    > Enthought-Dev mailing list
    > [email protected]
    <mailto:[email protected]>
    > https://mail.enthought.com/mailman/listinfo/enthought-dev
    >
    _______________________________________________
    Enthought-Dev mailing list
    [email protected]
    <mailto:[email protected]>
    https://mail.enthought.com/mailman/listinfo/enthought-dev
    _______________________________________________
    NumPy-Discussion mailing list
    [email protected] <mailto:[email protected]>
    http://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to