Re: RFS: matplotlib 0.90.1-3

2008-02-24 Thread Ondrej Certik
On Sat, Feb 23, 2008 at 5:08 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas <[EMAIL PROTECTED]> wrote:
>  > Hi Ondrej et al.,
>  >
>  >
>  >  >
>  >  > Yes, I read that bug. There are more problems with matplotlib - it is
>  >  > not lintian clean,
>  >  > it still uses Numerics and numarray besides numpy (I don't know if
>  >  > this is a feature or a bug),
>  >  >
>  >
>  >  I think upstream deprecated Numerics and numarray and the latest
>  >  version only uses numpy.
>  >
>  >  Changelog excerpts:
>  >
>  >  2007-06-01 Deprecate Numeric and numarray for use as numerix.
>  >  2007-06-02 Released 0.90.1 at revision 3352
>  >  2007-06-07 Disable build of numarray and Numeric extensions for
>  >internal MPL use and the numerix layer.
>  >  2007-07-19 replaced the Python code in numerix/ by a minimal wrapper
>  >around numpy that explicitly mentions all symbols that need
>  >to be addressed for further numpification
>  >  [...]
>  >  and only numpy is mentioned in the current README.
>  >
>  >  Anyway, as a matplotlib user, I am happy that you want to fix the
>  >  current issues, but sadly I currently don't have the time to help with
>  >  that.
>
>  It shouldn't be a big problem and I'll do it, as I also use and need it. We
>  are actually only waiting for an approval from the matplotlib maintainers.

Anyway, this seems it will take quite some time before it gets
resolved, so I compiled the fixed packages for i386 and amd64 and put
them here to my repository:

http://debian.certik.cz/

Ondrej


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

2008-02-24 Thread Bernd Zeimetz
Hi,

I'd suggest to do

> 3. Put the libraries in different subdirectories, e.g.
> 
>   /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

and add a symlink to /usr/lib which points to the library version for
the current default python version. You could use rtupdate to handle
the symlink, so there's no need to rebuild the package when the default
Python version is changed.


Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]