Problem with np.power in numpy 1.5.1-2

[M.]

Hi all,

I've been using numpy without problems - version .1.4.1-5 - until this
morning, when I upgraded my Debian sid system to numpy 1.5.1-2. A
function that was working that uses np.power

def get_far_field(self, chi, n):
       return np.sum(self.an[n,1:self.j] * np.power(chi,-np.arange(1,self.j)))

outputs "Warning: overflow encountered in power". I'm using python
2.6.6-12. Is this a bug in the numpy library or (more probably) my
code? If it's in my code, what can be happening? How to debug it?

Thanks


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktim+y83ay9qwx5ejewdaarbcjom...@mail.gmail.com

Re: Python C-library import paths

[M. Zhou]

On Fri, 2022-04-01 at 02:32 +0100, Wookey wrote:
> 
> RuntimeError: Cannot find the files.
> List of candidates:
> /home/wookey/bin/libtvm.so
> /usr/local/bin/libtvm.so
> /usr/bin/libtvm.so
> /bin/libtvm.so
> /usr/local/games/libtvm.so
> /usr/games/libtvm.so
> /usr/lib/python3/dist-packages/tvm/libtvm.so
> /usr/lib/libtvm.so
> /home/wookey/bin/libtvm_runtime.so
> /usr/local/bin/libtvm_runtime.so
> /usr/bin/libtvm_runtime.so
> /bin/libtvm_runtime.so
> /usr/local/games/libtvm_runtime.so
> /usr/games/libtvm_runtime.so
> /usr/lib/python3/dist-packages/tvm/libtvm_runtime.so
> /usr/lib/libtvm_runtime.so
> 
> So it tries quite hard to find it, but doesn't know about multiarch
> and thus fails to look in the right place:
> /usr/lib//   (/usr/lib/x86_64-linux-gnu/ on this box)

dlopen should know the multiarch triplet on debian. They have written
their own ffi loader, so I think it is an upstream bug. The upstream
should detect and add multiarch directory to the paths.

> 
> I see that /usr/lib/python3/dist-packages/tvm/_ffi/libinfo.py
> contains
> a function 'get_dll_directories' which looks promising and adds
> TVM_LIBRARY_PATH to the search list and if I run tvmc like this:
>  TVM_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ tvmc
> then that path is at the top of the list.

User specified stuff goes first. That makes sense.

> OK, but that mostly reveals a second issue: it's looking for
> libtvm.so, but that unversioned link is only provoded in the dev
> package
> libtvm-dev. The library package has the versioned filenames
> /usr/lib/x86_64-linux-gnu/libtvm.so.0
> /usr/lib/x86_64-linux-gnu/libtvm_runtime.so.0

I think it is fine to let it dlopen the libtvm.so, as it says
itself as some sort of "compiler".

Take pytorch as example, python3-torch has some functionalities
for extending itself with C++. As a result, libtorch-dev is
a dependency of python3-torch.

> So I also have to persuade it to look for libtvm.so.0 not
> libtvm.so. Where does that info live?  OK, a bit more research shows
> that that is in /usr/lib/python3/dist-packages/tvm/_ffi/libinfo.py
> which is in the source as python/tvm/_ffi_libinfo.py, in
> find_lib_path
> and that's easy to fix, and probably even the right place to fix it?

If the upstream's own ffi loader does not look at the SOVERSION,
then it should be designed to work without it.

> The paths is harder though. get_dll_directories in
> python/tvm/_ffi_libinfo.py adds $PATH after $LD_LIBRARY_PATH to make
> it's search list. Is searching $PATH for libraries ever right?
> 
> What it should actually be adding is what's in /etc/ld.so.conf.d/*
> That can be listed with
> /sbin/ldconfig -v 2>/dev/null | grep -v ^$'\t' | cut -d: -f1
> (yuk? is there really no better way?)
> 
> How does one do that in python to get that set of path added in the
> libinfo.py function?
> https://github.com/apache/tvm/blob/main/python/tvm/_ffi/libinfo.py
> 
> Am I barking up the right tree here or is there a better way?
> 

This really looked like an ffi loader bug.

Re: Python 3.11 for bookworm?

[M. Zhou]

There is not yet an accurate estimate of time required to fix the
python packages during the transition -- and I still remember the
transition from python3.9 -> python3.10 took a very long period
that does not seem short enough to be covered by the freeze schedule.

Apart from that, package maintainers have their own plans as well.
I believe that at the current stage, many people have assumed that
the next stable will ship python3.10, and have their packages
finalized for freeze already. Making that transition at the current
stage will push a number of maintainers into a rush of updating
their packages again -- in the worst case, the package upstreams
might be not even ready for python 3.11.

A significant Python performance improvement in 3.11 is good.
But note, when python performance has really become an issue,
people already have mature solutions, e.g. offloading the
performance critical part onto a compiled language.

I think the risk of greatly breaking the release plan
outweighs the gain.

On Wed, 2022-12-21 at 20:21 -0500, Nicholas D Steeves wrote:
> Sandro Tosi  writes:
> 
> > thoughts from a concerned maintainer
> > 
> 
> Sandro, thank you for writing this email.
> 
> > 
> > it seems this email advocates for a "let's wing it"[1] type of
> > transition.
> > 
> > [1] https://en.wiktionary.org/wiki/wing_it
> > 
> > It appears there has been little work in preparing the work to
> > introduce python3.11 from its maintainer, instead that works has
> > been
> > pushed downstream to maintainers.
> > 
> > if we continue with the plan as described above, several python
> > libraries/applications maintainers will be left with the short end
> > of
> > the stick and deal with an unknown amount of issues (upstream fixes
> > not available, not ready and or/ not released, rushed, etc) with
> > less
> > than a month from the beginning of the transition freeze[2]
> > 
> 
> Agreed. At a bare minimum, complete data from ratt (Rebuild All The
> Things) should be required at this point.
> 
> > [2] https://release.debian.org/bullseye/freeze_policy.html
> > 
> > [2] also highlights at the very beginning "Plan your changes for
> > bullseye", this change appears as if it was not planned and we
> > should
> > be skeptical to proceed without further (and in advance)
> > understanding
> > of the impact it may have on Bullseye.
> > 
> 
> 100% +1  I'm especially concerned about how a clear plan was not
> communicated to other teams--whose work will be broken by the
> proposed
> transition, were an exception to be granted.
> 
> Debian is not a paragon of community if it makes late, unannounced
> changes that result in a yet-undetermined number of projects being
> dropped from bookworm's release.  If Python 3.11 as the only
> supported
> version is a release goal, then the freeze schedule would need to be
> modified.
> 
> Regards,
> Nicholas

Re: Python 3.11 for bookworm?

[M. Zhou]

I'm the regular uploader of python3-llvmlite.

Please give up with numba. Its core dependency llvmlite is not even
ready for llvm != 11, while Sid had already get llvm-11 removed.
I have tried to cherry-pick an upstream fix to bump llvmlite's
llvm dependency to 12/14, but the autopkgtest shows numba would
be vastly broken.

Unless they bump LLVM dependency to a newer version:
https://github.com/numba/llvmlite/issues/897
https://github.com/numba/llvmlite/pull/830
there is zero chance to get numba in stable. I do not want to
bump LLVM by force and leave a broken package in stable.

llvmlite's python 3.11 support is still on the way:
https://github.com/numba/llvmlite/issues/885

One possibility is that we may apply for freeze exception
and wait for the llvmlite v0.40.0 release and see whether
they will bump llvm dependency.


On Thu, 2022-12-22 at 18:46 +, Stefano Rivera wrote:
> Hi Timo (2022.12.22_12:56:20_+)
> > > There have been rebuilds in Ubuntu that give us some idea of how much
> > > work remains. I think it's tractable, but also will have some package
> > > casualties.
> > I have some spare time right now, and I am happy to help
> > work on problematic cases, so hopefully nobody will feel left out in
> > the cold with their favorite packages.
> 
> Offhand, the one I most expect trouble with is numba. We were reliant on
> upstream for the 3.10 transition, and probably will be for 3.11.
> 
> Thanks for your help with pony ORM, Timo. I didn't think we'd be able to
> port that without upstream, but it did end up being tractable.
> 
> I'm expecting to have more time in the upcoming weeks, too.
> 
> So, release team, I still think we should go ahead!
> 
> SR
> 

Re: Python 3.11 for bookworm?

[M. Zhou]

It seems I was a little bit out of date. Diane Trout has tried
with an unreleased snapshot which looks good with llvm-14
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024795
Will work on it soon.

On Thu, 2022-12-22 at 18:04 -0500, M. Zhou wrote:
> I'm the regular uploader of python3-llvmlite.
> 
> Please give up with numba. Its core dependency llvmlite is not even
> ready for llvm != 11, while Sid had already get llvm-11 removed.
> I have tried to cherry-pick an upstream fix to bump llvmlite's
> llvm dependency to 12/14, but the autopkgtest shows numba would
> be vastly broken.
> 
> Unless they bump LLVM dependency to a newer version:
> https://github.com/numba/llvmlite/issues/897
> https://github.com/numba/llvmlite/pull/830
> there is zero chance to get numba in stable. I do not want to
> bump LLVM by force and leave a broken package in stable.
> 
> llvmlite's python 3.11 support is still on the way:
> https://github.com/numba/llvmlite/issues/885
> 
> One possibility is that we may apply for freeze exception
> and wait for the llvmlite v0.40.0 release and see whether
> they will bump llvm dependency.
> 
> 
> On Thu, 2022-12-22 at 18:46 +, Stefano Rivera wrote:
> > Hi Timo (2022.12.22_12:56:20_+)
> > > > There have been rebuilds in Ubuntu that give us some idea of how much
> > > > work remains. I think it's tractable, but also will have some package
> > > > casualties.
> > > I have some spare time right now, and I am happy to help
> > > work on problematic cases, so hopefully nobody will feel left out in
> > > the cold with their favorite packages.
> > 
> > Offhand, the one I most expect trouble with is numba. We were reliant on
> > upstream for the 3.10 transition, and probably will be for 3.11.
> > 
> > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to
> > port that without upstream, but it did end up being tractable.
> > 
> > I'm expecting to have more time in the upcoming weeks, too.
> > 
> > So, release team, I still think we should go ahead!
> > 
> > SR
> > 
> 

unsubscribe

[M Mohamed]

Re: llvmlite, numba, and llvm versions

[M. Zhou]

On Tue, 2025-02-18 at 09:50 -0800, Diane Trout wrote:
> 
> Do you have any ideas of what could be done to help get a version of
> llvmlite that works with numba into Debian?

No idea. I'm keeping an eye on upstream release but the only option
I can see to make it work is to depend on the LLVM version that does
not exist in unstable.

Re: llvmlite, numba, and llvm versions

[M. Zhou]

Hi Diane,

Thank you for working on this.

Do you have LLVM team write access? If so please help your self and
directly push the commits there. If not, please open a merge request
and I'll process it quickly.

On Tue, 2025-04-08 at 22:59 -0700, Diane Trout wrote:
> Hi,
> 
> I have a version of llvmlite that builds against llvm-19 with 2 test
> failures that don't look to important. One of them is definitely just
> the layout of the object file changed from what was expected.
> 
> I got most of the help in the comments in here:
> https://github.com/numba/llvmlite/pull/1092
> 
> Additionally with some other patches I was able to get numba to build
> with this version of llvmlite and with numpy 2.2 and all it's tests
> passed on x86_64. It also got through some tests on arm64 before it
> timed out.
> 
> I pushed all my changes to llvmlite to
> https://salsa.debian.org/diane/llvmlite
> at commit 17e84a9243ba92a9248e7415c84a980e0ff96886
> 
> The important bit is this patch from upstream
> https://salsa.debian.org/diane/llvmlite/-/blob/master/debian/patches/llvm-19-support-pr1182.patch?ref_type=heads
> And this patch skips/expects the two failed tests
> https://salsa.debian.org/diane/llvmlite/-/blob/master/debian/patches/skip-llvm-19-broken-tests.patch?ref_type=heads
> 
> I also pushed all my changes to numba for it to build with the above
> version of llvmlite and numpy 2.2
> https://salsa.debian.org/science-team/numba.git
> 
> (numba should work, though I had to merge a small change to the tests
> that I forgot to push to salsa a while ago, and it's building again,
> but I'm tired and it'll take a while to run through all the tests
> again)
> 
> I hope it's still not too late to get numba back in to testing.
> 
> Diane

Re: Report on the situation of python2.5 in Debian

[Aaron M. Ucko]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> The following packages need a round of binNMUs as soon as possible, to
> build extensions for python2.5, after which they shouldn't bother us.
> Can anyone schedule the binNMUs please?
> bitpim

Please don't bother with this one; BitPim actually builds its
extensions only for whichever Python version is currently default, as
they're private and the app needs wxPython anyway.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: Report on the situation of python2.5 in Debian

[Aaron M. Ucko]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Still, it would be nice to build extensions for all python versions, but
> the fact they are private makes this process more complicated.

... particularly given that neither python-support (which BitPim
currently uses) nor python-central actually supports that case
AFAICT. :-/  As such, I'll leave the (binNMU-friendly) packaging as is.

BTW, do you have an ETA for the transition?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: Report on the situation of python2.5 in Debian

[Aaron M. Ucko]

[-release dropped, as this subthread is no longer on topic.]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> If anyone has ideas about how to deal with such cases, I'm all open for
> implementing them. It would be easy for python-support to maintain a
> list of files that should be symbolic links to the version linked
> against the current python. The difficulty is about where to install
> those files in the packaging process so that dh_pysupport sees them.

I was actually somewhat more concerned about getting a sane
${python:Depends} setting, but that's definitely also an issue.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: python-numpy has problems on buildbots

[Aaron M. Ucko]

"José Fonseca" <[EMAIL PROTECTED]> writes:

> Or find someway to override dpkg-shlibdeps behavior so that it
> produces the right dependency list.

Supplying a suitable shlibs.local should achieve this.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

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

[Steve M. Robbins]

Hi,

I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian.  Debian currently ships Python 2.4
and 2.5.

When reading the following, keep in mind that Boost.Python is not a
Python extension but, rather, a library that eases writing an
extension in C++.  So it is necessary that the compiled libraries be
visible to be linked with user-written C++ code.


One idea is to use a user-config.jam file containing

using python : 2.4 : /usr ;
using python : 2.5 : /usr ;

Then run jam twice

bjam variant= ...
bjam variant= ... python python=2.5

This produces pairs of library files such as

bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a

(and similar pairs for shared libraries and all other variants).

The key item to note is that the two files have the same name.  The
python version, unlike the GCC version, is not embedded in the library
name.  So these files cannot both be installed into /usr/lib.

The question, then, is how to distinguish them once installed?  
Should we:


1. Rename the resulting libraries to decorate them with the python
version in addition to the gcc version?  This could generate

libboost_python-py24-gcc42-1_34_1.a
libboost_python-py25-gcc42-1_34_1.a


2. Similar to above, but use bjam's --buildid option?  This has the
drawback that the build ID shows up differently than the GCC version
decoration, e.g.

libboost_python-gcc42-1_34_1-py24.a
libboost_python-gcc42-1_34_1-py25.a


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


4. Put the default version directly in /usr/lib and the others
in subdirectories, e.g.

/usr/lib/libboost_python-gcc42-1_34_1.a
/usr/lib/python2.5/libboost_python-gcc42-1_34_1.a


The drawback to all these approaches is that client code has to be
adjusted to build on Debian.  Linking against Boost (for non-bjam
projects) is already hard enough with the decorated library names that
I fear making the situation worse.  

The attraction of #4 is that at least the variants for the default
python version are found in a natural manner.  This has some appeal to
me, personally, but I worry that it is too easy to build an extension
to python 2.5 and link in the wrong Boost.Python library.  In
contrast, the other options have the advantage that it forces the user
to declare which version of Python is being used.

I'd appreciate your thoughts.  Have I overlooked a better solution?
What are the other packagers of Boost.Python doing?  In principle,
it would be nice to have the Boost libraries named the same across
distributions. 

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

Hi,

Thanks to Steve, Bernd, and Josselin for ideas.


On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:

> Decorate only the shared library names with the python versions, and retain
> the current names for the .a files and .so symlinks - with two separate -dev
> packages that conflict with one another?
> 
> That still prevents anyone from packaging an extension that builds for both
> python2.4 and python2.5 at once using Boost.Python, but I think it solves
> all the other drawbacks of the other solutions you suggested.

Indeed.  Do you think this is a serious restriction?  Given that
Debian likes to package extensions for all python versions, I tend to
think it will become a problem.


On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
> Hi,
> 
> Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :

> > 1. Rename the resulting libraries to decorate them with the python
> > version in addition to the gcc version?  This could generate
> > 
> > libboost_python-py24-gcc42-1_34_1.a
> > libboost_python-py25-gcc42-1_34_1.a
> 
> I think this is fine.

[ ... ]

> The solution is to keep the names decorated with both python versions,
> but to maintain a farm of symbolic links pointing to the current python
> version. As Steve noted, you don???t need one for the runtime libs, but
> for the .a and the .so symlink that are used at build time, this is
> required.

OK, both you and Bernd suggested rtupdate.  Bernd even pointed me to a
description of it [1]; thanks.  Let me see if I understand your
proposal.

The idea is to create a single -dev package that contains the
following in /usr/lib:

libboost_python-py24-gcc42-1_34_1.so
libboost_python-py24-gcc42-1_34_1.a

libboost_python-py25-gcc42-1_34_1.so
libboost_python-py25-gcc42-1_34_1.a

The -dev package contains an rtupdate script to create the following
symlinks (also in /usr/lib):

libboost_python-gcc42-1_34_1.so
libboost_python-gcc42-1_34_1.a

Does that sound right?

This has the advantage that a Python extension can be build and
packaged for either or both supported Python versions, albeit at the
cost of changing the link line.  Code that just needs the default
version can use the undecorated form in the link line.  The
disadvantage is that if you use the undecorated form, you're not quite
sure what version of Boost.Python is linked in.


-Steve

[1] http://people.debian.org/~srivasta/manoj-policy/x673.html


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
> Steve M. Robbins wrote:
> > Hi,
> > 
> > Thanks to Steve, Bernd, and Josselin for ideas.
> > 
> > 
> > On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
> > 
> >> Decorate only the shared library names with the python versions, and retain
> >> the current names for the .a files and .so symlinks - with two separate 
> >> -dev
> >> packages that conflict with one another?
> >>
> >> That still prevents anyone from packaging an extension that builds for both
> >> python2.4 and python2.5 at once using Boost.Python, but I think it solves
> >> all the other drawbacks of the other solutions you suggested.
> > 
> > Indeed.  Do you think this is a serious restriction?  Given that
> > Debian likes to package extensions for all python versions, I tend to
> > think it will become a problem.
> 
> extensions for different python installations don't conflict because 
> they end up in separate directories. 

The proposal above is that we provide a boost-python-2.4-dev and a
boost-python-2.5-dev package that conflict with one another (because
they would contain files of the same name).  This prevents a source
package from depending on both for a build, and therefore a source
package for a Python extension cannot produce an extension for each
Python version.


-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote:

> (I still don't see the problem: Source packages don't depend on binary  
> packages, only binary packages do. 

Source packages *do*, in fact, depend on binary packages.  Each source
package describes exactly the packages required to build the source;
e.g. whether Qt3 libraries or X11 libraries are needed.  These are
called "build-time dependencies" or "build-deps" for short.


> And if you package your extension module you are in control of what
> python version(s) you build against, no ?)

That's a true statement.  

Several extension modules will, in fact, build for both Python 2.4 and
2.5.  Now imagine an extension module that uses Boost.Python.  As
mentioned, it must have the relevant build-deps.  To support this, the
relevant boost-python development packages must be co-installable
(i.e. not conflict with each other).

It's not yet clear to me whether this is an achievable goal, but it
would be nice.

Regards,
-Steve


signature.asc
Description: Digital signature

Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
> 
> on Sat Feb 23 2008, "Steve M. Robbins"  wrote:

[...]

> > This produces pairs of library files such as
> >
> > bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
> > bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a
> >
> > (and similar pairs for shared libraries and all other variants).
> >
> > The key item to note is that the two files have the same name.  The
> > python version, unlike the GCC version, is not embedded in the library
> > name.  So these files cannot both be installed into /usr/lib.
> 
> I don't know how such name gristing is generated in Boost.Build, but IMO
> we should change the naming to account for the Python version.

Perhaps.  For the moment, I can get the desired effect using
--buildid.


> > The question, then, is how to distinguish them once installed?  
> > Should we:
> >
> >
> > 1. Rename the resulting libraries to decorate them with the python
> > version in addition to the gcc version?  This could generate
> >
> > libboost_python-py24-gcc42-1_34_1.a
> > libboost_python-py25-gcc42-1_34_1.a
> 
> I'm not an expert in this area, but it's been my understanding that
> simply renaming library files doesn't work for some reason.

Partly true.  I believe you can rename the static libs (.a files) at
will.  The problem lies in the shared libs.  Subsequent to writing the
above, I discovered that the two shared libraries (.so.*) have exactly
the same SONAME, so renaming doesn't work for them.


> > 2. Similar to above, but use bjam's --buildid option?  This has the
> > drawback that the build ID shows up differently than the GCC version
> > decoration, e.g.
> >
> > libboost_python-gcc42-1_34_1-py24.a
> > libboost_python-gcc42-1_34_1-py25.a
> 
> Sounds more likely to work, even though it's ugly.

Yes, this works because the --buildid is incorporated into the
SONAMEs, thus distinguishing them.  Using --buildid is therefore the
*only* solution short of hacking the soname generation myself.



> > I'd appreciate your thoughts.  Have I overlooked a better solution?
> > What are the other packagers of Boost.Python doing?  
> 
> Unfortunately, we don't tend to get a lot of interaction with packagers
> around here, so we don't tend to know what they're doing.  I think Boost
> raises more packaging issues than most other libraries, so it would be
> good to have more involvement from y'all.

Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. "gcc42") is embedded in the library
filename.  I just wrote a response on Boost.Build outlining this in
some detail [1].  Embedding the compiler version requires Debian to
rebuild all the boost packages each time a compiler change is made.
This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
4.2) and also unnecessary when the ABI is broken, as Debian has
another mechanism to handle that.  Note that rebuilding the boost
packages has a huge ripple effect, so it is more than simply
"unnecessary", it is a very large headache.

The fact that Boost embeds the Boost version in the library name is
cause for grief to client software authors.  But this is unavoidable
as long as Boost doesn't take care to maintain ABI across versions.
Fortunately, there is a simple solution to this, which I touch on in
my post [1].

Regards,
-Steve

[1] http://lists.boost.org/boost-build/2008/03/18565.php


signature.asc
Description: Digital signature

Re: Problem with python boost libraries on amd64?

[Aaron M. Ucko]

AFAICT, the problem here essentially amounts to version skew -- the
module you're trying to load into Python 2.5 uses a support library
currently built only against 2.4 (as that remains Debian's default for
now).  This combination evidently happens to work without problems on
32-bit architectures, but fails on 64-bit platforms due to intervening
ABI changes.

Anyway, Boost's packager is looking into supporting 2.5 alongside 2.4;
you can find the relevant thread starting at

http://lists.debian.org/debian-python/2008/02/msg00033.html

and continued at

http://lists.debian.org/debian-python/2008/03/msg00033.html

(yes, really message 33 in both months!)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Boost.Python: providing libs for both Python 2.4 and 2.5.

[Steve M. Robbins]

Hello,

I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions.  Several very helpful suggestions were made, for which I am
grateful.

I have been plugging away, very slowly, ever since.  I'm hoping to
upload it later today and I'd appreciate have some second opinions on
what I've done.

I settled on creating libraries with suffix "-py24" and "-py25" using
the available Boost mechanism of "--buildid" since that ensures the
SONAME also has "-py24" or "-py25".  The shared library files thus
coexist peacefully.

For the link libraries, I chose to retain both the fully-decorated
forms including the "-pyXY" suffix, as well as create symlinks (with
no suffix) for those who just want the default python version.  These
symlinks are maintained by an "rtupdate" script as suggested by a
couple of people.

Focusing only on the simpler, Debian-specific, library names,
the intent is that the following link libraries are availble:

libboost_python-py24.a -> libboost_python-gcc42-1_34_1-py24.a
libboost_python-py24.so -> libboost_python-gcc42-1_34_1-py24.so
libboost_python-py25.a -> libboost_python-gcc42-1_34_1-py25.a
libboost_python-py25.so -> libboost_python-gcc42-1_34_1-py25.so
libboost_python.a -> libboost_python-py24.a
libboost_python.so -> libboost_python-py24.so

The rtupdate script (attached) will replace the last two libraries
with

libboost_python.a -> libboost_python-py25.a
libboost_python.so -> libboost_python-py25.so

This allows extension builders to select either the default Python
version, or a specific version, without knowing the Boost
and GCC versions [2].

I'd appreciate any feedback on the above, and especially on what
follows.

I'd love some folks to look over the attached rtupdate script.  My
understanding is that this gets run when the Python default version
changes.  If so, I guess that a bug in the script will cause the
Python package install to fail.  I'd like to avoid the hate mail
generated if that happened; so if you've got a moment, have a look at
the script.

I'd like to ask about intended behaviour if a bad action is supplied.
Or if an unsupported python version is given.  I chose to exit with an
error message and status 1.  Now I'm a little worried that will break
some Python installs and generate the hate mail.  What's the
recommended behaviour here?

Note that my libboost-python-dev postinst script calls it
to populate the symlinks initially:

/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
rtupdate none $(pyversions -d)

I also use it in the prerm to remove all the symlinks:

/usr/share/python/runtime.d/libboost-python-dev.rtupdate \
remove

Thanks,
-Steve


[1] http://lists.debian.org/debian-python/2008/02/msg00033.html
[2] http://lists.debian.org/debian-python/2008/02/msg00045.html
#! /bin/sh
#
# Update link-library symlinks after a Python default runtime change

set -e

version=1_34_1

die() {
echo "$@" >&2
exit 1
}

update_linklibs() {
py=$1
suf=$2

cd /usr/lib
for thread in "" -mt; do
for gcc in gcc41 gcc42; do
ln -s -f 
libboost_python-${gcc}${thread}${debug}-${version}-${py}.${suf} \
 libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
ln -s -f libboost_python${thread}${debug}-${py}.${suf} \
 libboost_python${thread}${debug}.${suf} 
done
}

remove_linklibs() {
suf=$1

cd /usr/lib
for thread in "" -mt; do
for gcc in gcc41 gcc42; do
rm -f libboost_python-${gcc}${thread}${debug}-${version}.${suf}
done
rm -f libboost_python${thread}${debug}.${suf} 
done
}

rtupdate() {
case "$1" in
python2.4)  py=py24 ;;
python2.5)  py=py25 ;;
*)  die $0 unknown python version $1 ;;
esac

update_linklibs $py a
update_linklibs $py so
}

remove() {
remove_linklibs a
remove_linklibs so
}


if [ "$1" = "-d" ]; then
debug=-d
shift
fi

action="$1"
shift

case "$action" in
pre-rtupdate)  ;;
post-rtupdate) ;;
rtupdate)  rtupdate $1 ;;
remove)remove ;;
*) die "$0 called with unknown argument '$action'" ;;
esac



signature.asc
Description: Digital signature

Re: Boost.Python: providing libs for both Python 2.4 and 2.5.

[Aaron M. Ucko]

"Steve M. Robbins" <[EMAIL PROTECTED]> writes:

> This allows extension builders to select either the default Python
> version, or a specific version, without knowing the Boost
> and GCC versions [2].

Yep; so far so good.

> I'd like to ask about intended behaviour if a bad action is supplied.
> Or if an unsupported python version is given.  I chose to exit with an
> error message and status 1.  Now I'm a little worried that will break
> some Python installs and generate the hate mail.  What's the
> recommended behaviour here?

Good question.  I'd favor exiting with non-zero status, per the
proposed implementation; if you're really concerned about potential
disruption, you can always add "|| true" to the prerm's invocation so
that users can at least readily pull libboost-python-dev from their
systems until you resolve the breakage.

I do, however, see a couple of concrete issues with your script:

> if [ "$1" = "-d" ]; then
> debug=-d
> shift
> fi

Shouldn't you fix that at build time à la $version?

> rtupdate)  rtupdate $1 ;;

More critically, AFAICT you want to pass $2, not $1.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.

[Steve M. Robbins]

On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote:

> I do, however, see a couple of concrete issues with your script:
> 
> > if [ "$1" = "-d" ]; then
> > debug=-d
> > shift
> > fi
> 
> Shouldn't you fix that at build time à la $version?

You noticed a complication I was avoiding.  There are actually two
packages that need an rtupdate script: libboost-python-dev, and
libboost-dbg.  The latter holds all the "debug" versions of the
libraries, including the Boost.Python libraries.  The only difference
in names is that the debug libraries have "-d" in them.  So I was
avoiding two scripts by this parameterization.

[I have subsequently done the parameterization slightly differently;
consult the boost svn repo for details or wait for the upload in a few
hours]


> > rtupdate)  rtupdate $1 ;;
> 
> More critically, AFAICT you want to pass $2, not $1.

Indeed.  I had sent out the note before fully testing
the script.  How embarrassing.

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.

[Aaron M. Ucko]

"Steve M. Robbins" <[EMAIL PROTECTED]> writes:

> libraries, including the Boost.Python libraries.  The only difference
> in names is that the debug libraries have "-d" in them.  So I was
> avoiding two scripts by this parameterization.

Ah, thanks for clarifying; I had forgotten about the -dbg package, and
thought that there might instead be a build-time switch.

> [I have subsequently done the parameterization slightly differently;
> consult the boost svn repo for details or wait for the upload in a few
> hours]

I took a quick glance, and have no further concerns offhand.  Thanks
for the excellent work!

> Indeed.  I had sent out the note before fully testing
> the script.  How embarrassing.

No problem; typos happen, and help remind reviewers to stay on their
toes. :-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: [pkg-boost-devel] Boost.Python: providing libs for both Python 2.4 and 2.5.

[Steve M. Robbins]

On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote:

> However, it looks to be like the shlibs file needs updating.

Yes, and thanks for the bug report.  Upload is being prepared now.

-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] Bug#473973: libboost-python-dev: rdeps fails?to built - python packaging seems weird

[Steve M. Robbins]

For the debian-python readers just joining in: the recent modification
of Boost to support multiple Python runtimes has some unintended
consequences; see bug #473973.  Below are some questions for your
consideration.


On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote:

> If I ask specifically for -lboost_python-py24 or -lboost_python-py25 
> or -lboost_python-mt-py24 or -lboost_python-py25, kdeedu seems to build 
> properly. If I just ask for one of the defaults (-lboost_python 
> or -lboost_python-mt it doesn't build)

You might want to consider doing so; this allows you to be
clear as to which version of python you support.  Or, indeed,
build support for both 2.4 and 2.5.


> > Please let me know what sequence of package installs (and what version
> > of libboost-python-dev) led to the situation of no symlinks.
> 
> The sequence of installation described here leaves it without those symlinks:
> 
> http://people.debian.org/~lucas/logs/2008/04/01/kdeedu_4%3A3.5.9-1_sid32.buildlog

OK, so this is using libboost-python-dev 1.34.1-10, which has the bug
previously mentioned: if you don't have python installed prior to
installing libboost-python-dev, you don't get the symlinks.

The sequence shown in the build log indicates that no python-dev
package is installed at all.  This is due to another change made to
support multiple python runtimes.  The libboost-python-dev package
used to depend on python-dev.  Now that it supports two runtimes, it
doesn't make sense to depend on both.  Arguably it could depend on the
default, but what I did instead is weaken the dependencies to suggest.
This breaks your build because the suggestions are not installed.

So here are some questions, and I'd like to throw then out to the
wisdom of debian-python, too.

1.  When does the rtupdate script get run?  I assumed it will be run
upon first install of python so as to configure all the python-using
packages previously installed.  But that does not seem to be the case.
Should it be?  If not, how should I handle the situation where
libboost-python-dev is installed/configured prior to python being
installed?

2.  Prior to supporting multiple runtimes, libboost-python-dev used to
depend on python2.4-dev.  Now it simply suggests python2.4-dev and
python2.5-dev since users of this package may need any of the
currently-supported Python development packages.  It means that some
(perhaps all) packages that build-depend on libboost-python-dev now
have to add python2.4-dev to their own build-deps.  Is that tenable?

3.  Alternatively, shall I add back python2.4-dev as a dependency for
libboost-python-dev?  This "penalizes" in some sense those who just
want Python 2.5, but not egregiously so.  It also assumes we can sort
out issue #1, I think, unless we can assume something about the
install ordering of the two packages.

4.  For a package that build-depends on libboost-python-dev, what is
the recommended strategy: to hack the build config and use the -py24
and -py25 library variants, or to rely on the symlinks and having the
correct Python installed?  Naively, I'd expect the latter strategy
for those who simply need to support the default Python version,
and the former for those who support all Python runtimes.


> kdeedu build doesn't fail by itself if it isn't found as it is only optional, 
> but we test afterwards if it is actually build.

Testing afterwards is a wise move!

Cheers,
-Steve


signature.asc
Description: Digital signature

When is rtupdate run?

[Steve M. Robbins]

On Thu, Apr 03, 2008 at 03:03:11PM +0200, Josselin Mouette wrote:
> On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote:

> > So here are some questions, and I'd like to throw then out to the
> > wisdom of debian-python, too.
> > 
> > 1.  When does the rtupdate script get run?  I assumed it will be run
> > upon first install of python so as to configure all the python-using
> > packages previously installed.  But that does not seem to be the case.
> > Should it be?  If not, how should I handle the situation where
> > libboost-python-dev is installed/configured prior to python being
> > installed?
> 
> You need to run it by hand in the postinst.

Right: libboost-python-dev does run it by hand in the postinst.

In fact, so does the package libboost-dbg, which provides debug
versions of all the Boost libs.  However there is no reason for
libboost-dbg to depend on python.  This means I can't count on
pyversions being available, so it is possible to install libboost-dbg
without having the symlinks created.

I was hoping is that if python is subsequently installed, that python
itself would run the rtupdate scripts.  This doesn't seem to be the
case.  Should it be?  If not, how should I handle the situation where
libboost-dbg is installed/configured prior to python being installed?

To be concrete: if I install python, then libboost-dbg, I get the
proper symlinks created by the libboost-dbg postinst invocation of the
rtupdate script.  However, if I install first libboost-dbg then
python, the symlinks are not created.  But I think they ought to be.


Thanks,
-Steve

P.S. As you and Sune suggested, I'll change libboost-python-dev to
depend on python-dev.



signature.asc
Description: Digital signature

Re: When is rtupdate run?

[Steve M. Robbins]

On Fri, Apr 04, 2008 at 10:29:37PM +0200, Josselin Mouette wrote:
> On ven, 2008-04-04 at 10:48 -0500, Steve M. Robbins wrote:
> > I was hoping is that if python is subsequently installed, that python
> > itself would run the rtupdate scripts.  This doesn't seem to be the
> > case.  Should it be?  If not, how should I handle the situation where
> > libboost-dbg is installed/configured prior to python being installed?
> 
> It seems indeed like a good idea to run them when python is first
> installed, so that is clearly a limitation of the current
> python-defaults rtupdate mechanism.
> 
> On the other hand, [...]

Without getting bogged down in the precise details of my situation,
the use case is simply this: a package that provides optional Python
support may have an rtupdate script that is called by its postinst
using "pyversions" to find the default runtime version.

Since the Python support is optional, the package does not depend on
python.  In this case, its postinst script must skip the rtupdate if
python is not available.

When Python is subsequently installed, the rtupdate scripts of all
previously-installed packages should be run.

Sound reasonable?  Shall I file a bug to this effect?  On python?


> On the other hand, I???m not sure such symbolic links are necessary for
> debugging libraries; at least they are not for usual libraries.

The debug library names all have the same -py24 and -py25 decoration
as the non-debug ones found in libboost-python-dev.  The symlinks are
to support linking with the default Python runtime.  This may not be
"usual", but how else do you deal with a library supporting two Python
runtimes?


-Steve


signature.asc
Description: Digital signature

Re: When is rtupdate run?

[Steve M. Robbins]

On Sat, Apr 05, 2008 at 02:23:21AM +0200, Josselin Mouette wrote:
> On ven, 2008-04-04 at 19:08 -0500, Steve M. Robbins wrote:

> > > On the other hand, I???m not sure such symbolic links are necessary for
> > > debugging libraries; at least they are not for usual libraries.
> > 
> > The debug library names all have the same -py24 and -py25 decoration
> > as the non-debug ones found in libboost-python-dev.  The symlinks are
> > to support linking with the default Python runtime.  This may not be
> > "usual", but how else do you deal with a library supporting two Python
> > runtimes?
> 
> This is all good for regular libraries, but as they are decorated, the
> debuglink information added by dh_strip should point to the decorated
> debugging library location, so you shouldn???t need the undecorated
> symbolic link for the debugging libraries.

Ah, now I see your confusion.

For a "standard" library, you're perfectly right.  The -dbg library has
the same SONAME as the non-debug version.

Boost is different: they decorate the debug library name (and SONAME)
with an extra "-d".  So the debug versions do need the default runtime
symlinks.

Cheers,
-Steve


signature.asc
Description: Digital signature

Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
> 
> on Thu Mar 13 2008, "Steve M. Robbins"  wrote:
> 
> > Actually, the only thing about Boost that causes grief to packagers is
> > that the toolset name (e.g. "gcc42") is embedded in the library
> > filename.  I just wrote a response on Boost.Build outlining this in
> > some detail [1].  Embedding the compiler version requires Debian to
> > rebuild all the boost packages each time a compiler change is made.
> > This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
> > 4.2) and also unnecessary when the ABI is broken, as Debian has
> > another mechanism to handle that.  Note that rebuilding the boost
> > packages has a huge ripple effect, so it is more than simply
> > "unnecessary", it is a very large headache.
> 
> I'm not sure that's the end of the story.  One reason we embed the
> compiler name in the library name is that version-specific workarounds
> often show up in header files.  The result is that when compiled against
> gcc-4.2, client code will effectively see different header contents than
> the precompiled boost library that was built with gcc-4.1 did.

Interesting.  I didn't know that.  Debian's "unstable" distribution
has been using the same compiled Boost libraries with a mix of GCC 4.1
and 4.2 since December.  GCC 4.3 is being added to the mix, too.

I should grep the boost headers for BOOST_WORKAROUND to see what
differences might arise.


> I think we'd need to work out a discipline of avoiding
> BOOST_WORKAROUND code in headers that distinguishes compiler minor
> versions.  I'm not very confident that I've thought that issue
> through completely... is it that simple?

If possible, that would be nice from a library distributor's 
point of view.


> > The fact that Boost embeds the Boost version in the library name is
> > cause for grief to client software authors.  But this is unavoidable
> > as long as Boost doesn't take care to maintain ABI across versions.
> > Fortunately, there is a simple solution to this, which I touch on in
> > my post [1].
> 
> This is just a change to bjam?  Have you gotten any traction with that
> idea?

It turns out to be simpler than that.  With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations.  I will use this for the
upcoming Boost 1.35.0 Debian packages.

We had a long thread in Boost.Build about this idea [1].  I'm not sure
I convinced anyone to my point of view.  :-)  We'll proceed with
Debian-specific changes for the short term and see how it goes.

Regards,
-Steve

[1] Thread starts at
http://lists.boost.org/boost-build/2008/04/18835.php
The shortest statement of Debian's position is
http://lists.boost.org/boost-build/2008/04/18839.php
(And please ignore http://lists.boost.org/boost-build/2008/04/18918.php
 as I've changed my mind again)


signature.asc
Description: Digital signature

Re: Packaging question on private extension modules

[Aaron M. Ucko]

Manuel Prinz <[EMAIL PROTECTED]> writes:

> I have a Python application with private extension modules, so the package is 
> Arch: any. Because there is no way (at least I'm not aware of that) to split 
> the package because the modules are private, I can't seperate the large part 
> of the app out to /usr/share/package/ because the extension module parts 
> under /usr/lib/package/ can't be loaded. Is there a way to do that or is the 
> recommended way to put everything to /usr/lib/package/ even thought large 
> parts are arch-indep?

You're welcome to copy the approach I take with BitPim, which is in
the same boat: the main package (bitpim) is architecture-independent
and installs its Python modules under /usr/share (specifically, in
/usr/share/bitpim/code).  However, because a couple of modules are
architecture-dependent, they go into a separate bitpim-lib package on
which bitpim depends, with a carefully crafted __init__.py that lets
Python find them:

$ cat /usr/share/bitpim/code/native/__init__.py
# Handle Debian's split-up layout
__path__.insert(0, '/usr/lib/bitpim/native')

I suspect one could do the same with a .pth file.

> Also, is it OK to build just against the default Python version in Debian or 
> should all versions be supported? Upstream's build system does not enable to 
> build against a specific version of Python.

You shouldn't need to build against multiple Python versions as long
as you arrange for inter-package dependencies to be bin-NMU safe (no
strict all -> any dependencies).

> P.S.: Please CC me in replies, I'm not subscribed.

Done; thanks for warning us.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]


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

Re: Bug#516766: insighttoolkit: generates incorrect package with python-support from experimental

[Steve M. Robbins]

On Mon, Feb 23, 2009 at 04:16:50PM +0100, Josselin Mouette wrote:

> the insighttoolkit rules file contains the following:
>
> PYMODDIR = usr/share/python-support/$(pkg_python)
> PYEXTDIR = usr/lib/python-support/$(pkg_python)/$(PYVERS)
> ...
> install/$(pkg_python)::
> dh_install -p$(pkg_python) -XlibSwig 
> debian/tmp/usr/lib/InsightToolkit/*Python.so* $(PYEXTDIR)
> dh_install -p$(pkg_python) 
> debian/tmp/usr/lib/InsightToolkit/libSwigRuntimePython.so* usr/lib
> dh_install -p$(pkg_python) debian/tmp/usr/lib/InsightToolkit/python/* 
> $(PYMODDIR)
> dh_install -p$(pkg_python) debian/tmp/usr/lib/InsightToolkit/*.py   
> $(PYMODDIR)
> dh_pysupport -p$(pkg_python)
> 
> With the upcoming version of python-support (currently in experimental),
> the files installed in /usr/lib/python-support are ignored and the built
> package is, as such, broken. 
> 
> You should install these packages to a standard place instead of adding
> all this complexity. Then, dh_pysupport will pick them and do whatever
> is fit.

OK.  I'm certainly in favour of avoiding complexity.  However, I
thought I was following the python policy [1] where B.1 says:

When using python-support, you should install your modules to
/usr/share/python-support/package rather than the standard Python
directories.

Where should I be installing the .py files?
Where should I be installing associated .so files?


Thanks,
-Steve

[1] 
http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html#s-pysupport


signature.asc
Description: Digital signature

python policy manual not reliable

[Steve M. Robbins]

On Sun, Mar 08, 2009 at 05:27:33AM +0100, Josselin Mouette wrote:
> Le samedi 07 mars 2009 ? 22:17 -0600, Steve M. Robbins a ?crit :
> > OK.  I'm certainly in favour of avoiding complexity.  However, I
> > thought I was following the python policy [1] where B.1 says:
> 
> This document is incorrect. Since it is basically unmaintained and
> contains many similar mistakes, you should especially not rely on it.

Thanks, that's good to know.

The document does look authoritative to the casual observer, however.
Maybe we could get it removed until such time as it gets updated.  

WWW team: how does one go about getting
http://www.debian.org/doc/packaging-manuals/python-policy/
removed?


Thanks,
-Steve


signature.asc
Description: Digital signature

Re: RFS: pyfltk

[Aaron M. Ucko]

[Mailing you directly, since I'm not sure you're on the list.]

Luca Falavigna  writes:

> Could a sponsor have a look at it and, if fine, upload it for me?

Everything appears to be order; given that I am not only a team member
(albeit merely for the sake of one small module, python-dsv) but
Debian's fltk1.1 maintainer, I'm probably the natural choice of
sponsor, and will proceed to upload the package within the next few
days unless somebody else chooses to step in.

Thanks for putting the package together.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: pyfltk

[Aaron M. Ucko]

Luca Falavigna  writes:

> Thanks! I'll also have a look at the package to adhere to 3.8.1 policy.

I see you have done so and concluded (correctly, AFAICT) that no
changes were necessary.  I've gone ahead with the upload, with
DM-Upload-Allowed enabled; please don't make me regret it. ;-)

Thanks for your contribution to Debian!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

SONAME for python modules is bad?

[Steve M. Robbins]

Hi,

Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
python module is wrong, with reference to an oblique comment from
Josselin Mouette [1].

Is this true?  What is the rationale for not versioning these shared
objects?

Is there any "more official" document that mandates this?  For
example, the python policy?

Thanks,
-Steve


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378049#25



signature.asc
Description: Digital signature

Re: SONAME for python modules is bad?

[Steve M. Robbins]

Hi,

A cc is appreciated as I don't subscribe to debian-python.

On Fri, Jul 24, 2009 at 03:49:16PM +0200, Mathieu Malaterre wrote:
> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins wrote:
> > Hi,
> >
> > Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
> > python module is wrong, with reference to an oblique comment from
> > Josselin Mouette [1].
> >
> > Is this true? ?What is the rationale for not versioning these shared
> > objects?

Chow Loong Jin responded noting that Python modules are loaded
using dlopen or similar, and not by the runtime linker.  He concludes
that this implies the normal shared object versioning is not required.

I don't quite follow that logic.  I guess that conventionally a module
named "fooextension.so" is loaded; i.e. without a version.  However,
one could, in principle, dlopen("fooextension.so.3") if one wanted
multiple versions of fooextension to coexist.  Is it simply the case
that this need has not (yet?) arisen in practice?

In any event, if convention dictates that modules are not versioned,
that's fine with me.  My next question is then: does it bother people
if ITK installs versioned shared objects *in addition to* the simple
".so" link that is used by the python code?  It does this currently,
just because the build process treats all shared objects (modules and
libraries) identically.  Is it worth while to change this or can we
just leave it alone?


> > Is there any "more official" document that mandates this? ?For
> > example, the python policy?
> 
> This issue was raised by Denis Barbier. [...]

> It would be extremely nice too if all wrap language would adopt the
> same convention.

That would be nice.  

Personally, I'd settle for each language having a clear policy written
down (in a location that I can easily find) so that I don't have to
guess.  ;-)

Regards,
-Steve



signature.asc
Description: Digital signature

Re: SONAME for python modules is bad?

[Steve M. Robbins]

On Fri, Jul 24, 2009 at 07:13:19PM +0100, Max Bowsher wrote:

> IMO it's potentially misleading clutter, but it doesn't harm anything,
> so I'd consider it something that ought to be fixed, but very much low
> priority.

Agreed.

Thanks,
-Steve



signature.asc
Description: Digital signature

Re: Endianness detection change on numpy

[Aaron M. Ucko]

Kumar Appaiah  writes:

> The fix is simple: either their new npy_endian.h method is broken,
> since it does not attempt to find the endian.h present on all Debian
> machines, or I have not figured out how to force the use of
> endian.h. A simple workaround I'd suggest is to path the npy_endian.h
> provided to force the use of endian.h, for that is the most general
> way and sure to work on all Debian systems. However, before resorting
> to patching, I wanted know if someone can suggest a more elegant
> method to get around this problem, which I haven't been able to figure
> out.

In general, it's fine to assume endian.h on Debian.  For broader
portability, though, I'd add the following suggestions to the one from
#544291:

- Fix numpy's build system to #define NPY_HAVE_ENDIAN_H as
  appropriate, and npy_endian.h to #include "numpyconfig.h".

- Per pyconfig.h, take advantage of the fact that GCC predefines
  __BIG_ENDIAN__ or __LITTLE_ENDIAN__ as appropriate.  (Numpy's
  headers shouldn't actually #include , of course, just
  learn from it.)

- Fall back on trying  rather than #error-ing out, on the
  grounds that a possible error is better than a guaranteed one.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

python-sip4 should be updated

[Ville M. Vainio]

I'm posting to call some attention to broken python-sip4 package. If
this is a wrong place, point me at the right one ;-). It has been
causing numerous systematic crashes to various people. Easy way to
test:

bzr branch lp:leo-editor
cd leo-editor
python launchLeo.py

Relevant links with discussion:

http://sidux.com/PNphpBB2-viewtopic-t-18465.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552511

I have confirmed that this is fixed by installing the python-sip4
package from Karmic

http://packages.ubuntu.com/fi/karmic/python-sip4

Confirmed with version 4.9.1-snapshot-20091015-0ubuntu1

-- 
Ville M. Vainio
http://tinyurl.com/vainio


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#595786: libboost-python-dev: Boost Python should also be compiled against Python3

[Steve M. Robbins]

On Mon, Sep 06, 2010 at 12:22:07PM -0400, Andreas Kloeckner wrote:

> I very much appreciate that you already compile Boost Python against
> Python 2.5 and 2.6. Since upstream already also supports Python3, it
> would be nice to also compile against whatever the currently supported
> version of Python3 is (3.1 as of this writing).

I agree.  Unfortunately, when I tried building Boost 1.44 (just
uploaded to experimental), it failed to build Boost.MPI.  I posted the
build failure to the Boost list [1] but no response yet.

I'd appreciate help in tracking down the problem.  You can find the
Debian package sources in svn [2].  The following patch adds
support for Python 3.1.

Thanks,
-Steve

[1] http://lists.boost.org/Archives/boost/2010/09/170659.php
[2] svn://svn.debian.org/svn/pkg-boost/boost/trunk


Index: debian/control
===
--- debian/control  (revision 14598)
+++ debian/control  (working copy)
@@ -4,9 +4,10 @@
 Priority: optional
 Maintainer: Debian Boost Team 
 Uploaders: Steve M. Robbins , Domenico Andreoli 

-Build-Depends: debhelper (>= 7), bison, flex, docbook-to-man, xsltproc, 
doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-all-dev, python-support (>= 
0.6), mpi-default-dev
-Build-Conflicts: boost-build, libopenmpi-dev (= 1.3.2-2)
+Build-Depends: debhelper (>= 7), bison, flex, docbook-to-man, xsltproc, 
doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-all-dev, python3-all-dev 
(>= 3.1), python-support (>= 0.6), mpi-default-dev
+Build-Conflicts: libopenmpi-dev (= 1.3.2-2)
 XS-Python-Version: >= 2.4
+XS-Python3-Version: >= 3.0
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-boost/boost/trunk/
 Vcs-Svn: svn://svn.debian.org/svn/pkg-boost/boost/trunk
 Standards-Version: 3.8.3
Index: debian/rules
===
--- debian/rules(revision 14599)
+++ debian/rules(working copy)
@@ -13,7 +13,7 @@
 SOVERSION = 1.44.0
 SHLIBS_VERSION = (>= 1.44.0-1)
 
-pyversions = $(shell pyversions -rv)
+pyversions = $(shell pyversions -rv) 3.1
 
 # Boost libraries for which we want separate packages
 boost_libs := date-time filesystem graph-parallel graph iostreams math \



signature.asc
Description: Digital signature

Python 3.2: convert convert PyObject* to PyUnicodeObject*?

[Steve M. Robbins]

Hi,

Boost 1.46.1 fails to build with Python 3.2 on linux (Debian).  The
build fails with:

error: cannot convert -F?PyObject*? to ?PyUnicodeObject*? for argument ?1? to 
?Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)?-A

at this code:

  static std::wstring extract(PyObject* intermediate)
  {
  std::wstring result(::PyObject_Length(intermediate), L' ');
  if (!result.empty())
  {
  int err = PyUnicode_AsWideChar(
  intermediate
, &result[0]
, result.size());

  if (err == -1)
  throw_error_already_set();
  }
  return result;
  }

Is there an easy fix?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: [PSF-Board] may be a logo?

[M.-A. Lemburg]

Adam wrote:
> Paul Wise wrote:
> 
>> On Thu, Sep 15, 2011 at 3:41 AM, Yaroslav Halchenko wrote:
>>> Do we have a logo for our Python-In-Debian effort(s) (was needing one
>>> for a recent talk but failed to deliver in time)?  What about
>>> having one?  I am not a designer and possibly lacking any taste, so
>>> please do not judge wildly.  What would be your choice among the
>>> following 6:
>>>
>>> http://www.onerussian.com/tmp/pydebian-red_tuned/
>>>
>>> ?  choice 0 == do not like any
> 
> Very nice logos. I favour #2.
> 
> An alternative suggestion is #6 in the colors blue and yellow (let's
> call it #6by). It is attached (changes done with Gimp's fill tool).
> 
>> I wonder if that is an allowed use of the Python trademark though.
>>
>> A similar combination of the GNOME foot and the Debian logo is
>> apparently not allowed:
>>
>> http://lists.debian.org/1309267090.5023.15.ca...@novo.hadess.net
> 
> The Python Trademark Policy¹ states under "Derived Logos":
> 
> | * Derived logos must always be sufficiently different from the Python
> |   logos to allow the community to tell the difference. For example, if you
> |   want to create a derived logo for a local Python user group, you might
> |   be able to insert an unaltered Python logo graphic into the local
> |   group's name in a way that does not cause confusion. But confusingly
> |   similar derived logos are not allowed. This includes entwining Python
> |   logos with other logos, or connecting them together in a confusing
> |   manner. Logos that simply change the colors or fonts are not allowed.
> |
> | * […]
> | 
> | * Use of derived logos for user groups and conferences -- Allowed if
> |   used to refer to the Python programming language. 
> 
> So all logos should be fine. CCing the python-foundation so they correct
> me if needed (and FYI).

I'll forward this to the PSF trademark committee.

FWIW: Your logo suggestions mix the Debian Logo with the Python
one and change its shape. We generally prefer to have the logo
used unaltered when combined with other logos, e.g. you could
put the Python logo centered and on top of the Debian one.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 15 2011)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2011-10-04: PyCon DE 2011, Leipzig, Germany19 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e720044.5000...@egenix.com

Re: Third round of advise on packaging python-csb

[Bradley M. Froehle]

Interesting, the LibraryStyleGuide [1] suggests a plain `=` and the
AppStyleGuide [2] suggests `:=`.  (The difference of course is that `=`
does delayed evaluation meaning the command is run once for every time the
variable is needed, and `:=` does immediate evaluation meaning the command
is run only once when the variable is set.

Naively I would have always reached for `:=`, but I think you are correct
that `=` would be slightly cheaper in that the variable is not used every
time it is processed by make.

[1]: http://wiki.debian.org/Python/LibraryStyleGuide
[2]: http://wiki.debian.org/Python/AppStyleGuide

Two comments:
>
>  PYVERS :=  $(shell pyversions -r)
>> PY3VERS := $(shell py3versions -r)
>>
>
> Using simple "=" instead of ":=" should be cheaper.
>

Re: Inconsistency in source package naming for python modules

[Bradley M. Froehle]

On Wed, Jul 10, 2013 at 12:54 PM, Thomas Goirand  wrote:
> On 07/10/2013 10:30 PM, Stuart Prescott wrote:
>> Thomas Goirand wrote:
>>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
 There is no policy on this either way, so there's no "mistake".
>>>
>>> Well, the mistake is precisely to have no rule, IMO.
>>
>> Rules for packaging things are normally there to solve problems of
>> interoperability and to assist QA efforts. Which of these is it going to
>> help?
>>
>>> Never the less, I think we should collectively decide what to do, rather
>>> than continuing the mess, with everyone having its own rule.
>>
>> What mess? If there is a perceived mess, why is that a problem in any case?
>> How does it help to make a new rule? Who does it help? What problem does
>> this solve? Why is any intellectual energy being spent on this at all?
>
> Oh, I need this pyX package... Let's download it.
>
> # apt-get source pyX
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to find a source package for pyX
>
> shit, let's try again...

It works to me (in Ubuntu, anyway):

$ apt-get source python-matplotlib
Reading package lists... Done
Building dependency tree
Reading state information... Done
Picking 'matplotlib' as source package instead of 'python-matplotlib'
NOTICE: 'matplotlib' packaging is maintained in the 'Svn' version
control system at:
svn://svn.debian.org/svn/python-modules/packages/matplotlib/trunk/
Need to get 38.5 MB of source archives.
Get:1 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib
1.2.1-0ubuntu1 (dsc) [3,240 B]
Get:2 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib
1.2.1-0ubuntu1 (tar) [38.4 MB]
Get:3 http://mirror.pnl.gov/ubuntu/ raring/universe matplotlib
1.2.1-0ubuntu1 (diff) [25.1 kB]

I think a recommendation (for new packages) would be helpful, but I'm
against any source naming requirements or strict rules.

-Brad


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cahxv-mgtoi_l8v6jjdrty3skdpenb7yh1d_pv6uvcvgqwxj...@mail.gmail.com

Will rtupdate be used for python 2 --> python 3 transition?

[Steve M. Robbins]

Hello,

The Debian Python Policy documents [1] the rtupdate script for dealing with 
default runtime changes.  Is this documentation still valid?  Will rtupdate be 
used when the default runtime changes to python 3 or later?

Thanks,
-Steve


[1] 
http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-runtimes_hooks


signature.asc
Description: This is a digitally signed message part.

Re: Will rtupdate be used for python 2 --> python 3 transition?

[Steve M. Robbins]

Hi,

On October 29, 2013 09:49:53 AM Dmitrijs Ledkovs wrote:

> python3.X series and python2.X series are two distinct languages
> (incompatible API and ABI changes), and it has been decided to keep
> both alive as independent implementations.
> thus "/usr/bin/python" will always point to a python2.X
> implementation, 

Is there any documentation of this decision?  
The PEP you reference 

> http://www.python.org/dev/peps/pep-0394/

is much less firm on this matter:

*Future Changes to this Recommendation[1]*

It is anticipated that there will eventually come a time where the third party 
ecosystem surrounding Python 3 is sufficiently mature for this recommendation 
to 
be updated to suggest that the python symlink refer to python3 rather than 
python2.


[1] http://www.python.org/dev/peps/pep-0394/#id14


Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

Re: Joining the DPMT

[IOhannes m zmölnig]

On 07/05/2015 09:51 PM, Piotr Ożarowski wrote:
> 
> PPS hint to others: my favourite join requests are signed, include
> "I've read 
> https://python-modules.alioth.debian.org/python-modules-policy.html and I 
> accept it"
> and mention previous Pyton/Debian work (package names? patches? bug
> reports?)
> 

as someone who has only recently joined DPMT, i have to admit that i
subscribed to this list at the same time i applied for team membership.
as such, i wouldn't have known about your favourites.
maybe it would be good to add them to the wiki (right i could do that
myself, but now i'm going to sleep :-))

gfmasr
IOhannes



signature.asc
Description: OpenPGP digital signature

Re: DPMT: server-side git hooks

[IOhannes m zmölnig]

On 07/06/2015 10:30 PM, Sandro Tosi wrote:
>> another problem is a spurious complaint about "Invalid revision range
>> 00..".
>> i haven't been able to track that down yet, but will report back if i
>> find something.
> 
> this is probably the first push you made, and it says it cant compare
> to a previous version (0) simply because there is none.

nah, it happens repeatedly, though not always.
e.g. when i push a new signed tag i get the same error message.

it might be however, that it only happens when i push for the first time
a given "kind" (e.g. a certain branch; or a signed tag;...).



fgmards
IOhannes




signature.asc
Description: OpenPGP digital signature

Re: pyvtk: deprecation of python-support

[Steve M. Robbins]

On Wed, May 20, 2015 at 06:36:33PM +0200, dktrkr...@debian.org wrote:
> Source: pyvtk
> Version: 0.4.74-3

I haven't uploaded pyvtk since 2011.  So while looking to fix this
bug, I went looking for the most recent sources and found out that you
can easily get pyvtk via pip.

Since I don't use pyvtk anymore, it occurred to me to simply remove
the .deb package and assume folks will use pip.  What does
debian-python say to that idea?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: Bug#786247: pyvtk: deprecation of python-support

[Steve M. Robbins]

On August 8, 2015 10:13:04 AM Piotr Ożarowski wrote:
> [Steve M. Robbins, 2015-08-08]
> 
> >  I went looking for the most recent sources and found out that you
> > 
> > can easily get pyvtk via pip.
> 
> `sudo pip install ...` is the same as `rm -rf /` to me.

I see.

> Please don't suggest it! 

In my defense: I did not say you need to use "sudo".  All you need (at least 
for pyvtk) is privilege to write into /usr/local, so it is more like "rm -rf 
/usr/local" ... still damaging but not as dramatic.  :-)


> If you don't want to maintain it, report RFA or O
> bug or simply remove it from the archive, but never ever suggest users
> to use pip for installing system libs/apps. I had to clean after these
> tools way too many times! pip is great when used inside virtualenv or
> tools like this, but should return "please use rpm/dpkg" whenever
> invoked as root, period!

Thanks.  I had read Paul Tagliamonte's essay [1] and wondered whether I'd get 
this kind of response.  :-)   I won't wade into the debate.

[1] http://notes.pault.ag/debian-python/

Best,
-Steve

signature.asc
Description: This is a digitally signed message part.

Re: Git migration schedule

[IOhannes m zmölnig]

On 10/10/2015 12:16 AM, Brian May wrote:
> On Sat, 3 Oct 2015 at 00:24 Barry Warsaw  wrote:
> 
>> 5-Oct - Do one last test run with an updated svn dump.  Put the results in
>> a
>> public place for folks to play with and comment on.
>>
>> 8-Oct - Assuming no objections or showstoppers, turn off write access to
>> all
>> of DPMT svn.
>>
>> 9-Oct - One more svn dump and conversion run.  Move the git repos into
>> their
>> final resting place.
>>
>> Announce, celebrate, ???, profit!
>>
> 
> We haven't finished yet. We still need to do the celebrate step :-)
> 

congratulations to all the people that have done this fantastic piece of
work.
hurray!

fgmards
IOhannes



signature.asc
Description: OpenPGP digital signature

Request to join the DPMT

[Diego M. Rodriguez]

Dear Debian Python Modules Team,

I would like to join the team with the initial goal of maintaining the
python-jellyfish package, which has currently ITP [1] and RFS [2] status,
under the umbrella and guidance of the team. The jellyfish package is a
dependency needed for updating the beets [3] package, which I currently
contribute to in the upstream repository [4].

Once I learn the ropes, I would love to lend a hand with any other packages -
not only beets itself but hopefully any other packages that need work, in the
hopes of giving back to Debian after many years being a regular user. I have
been working professionally with Python for the last 5 years in a number of
projects, most of them related to Django as well, and occasionally make some
small-time code contributions to related packages on their ecosystem
(such as django-extensions and py-authorize).

Alternatively, I'd also welcome guidance and/or sponsorship, in case joining
the team is deemed a bit premature or undesired for any reason. I have worked
on the package for the last couple of weeks on mentors [5], hopefully adhering
to the recommended Debian practices, but the work has not been formally
reviewed yet.

My alioth login name is "diegom-guest". I have read the DPMT policy [6] and
I accept it.

Best regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775719
[4] https://github.com/sampsyo/beets/commits/master?author=diego-plan9
[5] https://mentors.debian.net/package/python-jellyfish
[6] http://python-modules.alioth.debian.org/policy.html

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Enabling Python bindings for jellyfish

[Diego M. Rodriguez]

On Tue, Dec 29, 2015 at 12:56:20PM -0500, Scott Kitterman wrote:
> I think the respective maintainers should talk and then discuss with their 
> upstreams as the collision potential isn't just in Debian.

I'm chiming in as the (prospective) maintainer of the ITP python-jellyfish
package, just to note that I have discussed it with Andreas [1] and fully
agreed to rename "my" package. The choice of name was due to not being aware
of the Python bindings on the existing DNA-jelyfish package (and in part also
due to my inexperience on these matters), and I have contacted upstream
earlier today in the hopes of coming up with a good alternative name.

I'd be happy to follow up on the discussion with upstream once I get a reply,
in order to find out if he would be open to solving the conflict at a "higher"
level.

Best regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#42
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Enabling Python bindings for jellyfish

[Diego M. Rodriguez]

On Tue, Dec 29, 2015 at 02:07:05PM -0500, Paul Tagliamonte wrote:
> That won't solve the problem, since both will provide the python module
> jellyfish

Fair point indeed, and I fully agree that ideally the problem should be solved
at the python module level.

I'm wondering if you or other senior, more experienced developers could
suggest what would be the recommended solution for the namespace conflict,
taking into account:

a) DNA-jellyfish is an stablished Debian package since 2011 [1]
b) STR-jellyfish is on PyPI [2] since 2010 (version 0.1)
c) both packages started their Github repos around the same time (summer 2010)
d) both packages seem to be a bit "niche" (popcon stats for "jellyfish" [3] and
"beets" [4], the package that would depend on STR-jellyfish, seem to hint that
they are both modestly used within Debian and cater to specific groups of
users)
e) other considerations I'm probably missing!

I would personally place a bit more weight on the fact that STR-jellyfish is
already on PyPI (based on the rationale that it is arguably the "de facto"
repository for Python packaging); but, again, I am relatively new to
Debian practices and arguing for keeping consistency within the Debian
repository seems reasonable to me as well.

Best regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644925
[2] https://pypi.python.org/pypi/jellyfish
[3] https://qa.debian.org/popcon.php?package=jellyfish
[4] https://qa.debian.org/popcon.php?package=beets

> 
> On Tue, Dec 29, 2015 at 1:24 PM, Diego M. Rodriguez 
> wrote:
> 
> > On Tue, Dec 29, 2015 at 12:56:20PM -0500, Scott Kitterman wrote:
> > > I think the respective maintainers should talk and then discuss with
> > their
> > > upstreams as the collision potential isn't just in Debian.
> >
> > I'm chiming in as the (prospective) maintainer of the ITP python-jellyfish
> > package, just to note that I have discussed it with Andreas [1] and fully
> > agreed to rename "my" package. The choice of name was due to not being
> > aware
> > of the Python bindings on the existing DNA-jelyfish package (and in part
> > also
> > due to my inexperience on these matters), and I have contacted upstream
> > earlier today in the hopes of coming up with a good alternative name.
> >
> > I'd be happy to follow up on the discussion with upstream once I get a
> > reply,
> > in order to find out if he would be open to solving the conflict at a
> > "higher"
> > level.
> >
> > Best regards,
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#42
> > --
> > Diego M. Rodriguez
> > 36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232
> >
> >
> 
> 
> -- 
> All programmers are playwrights, and all computers are lousy actors.
> 
> #define sizeof(x) rand()
> :wq

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Enabling Python bindings for jellyfish

[Diego M. Rodriguez]

> That bit of policy doesn't officially kick in yet since these aren't both in 
> the 
> archive yet.  The policy is about consensus finding and not winning and 
> losing.  
> That's why I recommended discussing with the upstreams (and hopefully getting 
> them in direct communication).

Thanks for the pointer to the relevant Debian Policy chapter, Scott. My
previous message was indeed intented to hopefully serve as a common ground
towards reaching a consensus and as an aid when taking the discussion upstream,
rather than force or impose a decision - my apologies if it came too strong!

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Request to join the DPMT

[Diego M. Rodriguez]

> Welcome to the team.
> 
> Scott K

Thank you - looking forward to a fruitful collaboration!

Best regards,
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Bug#806716: Jellyfish name conflicts

[Diego M. Rodriguez]

Hello Andreas,

> This was not really intended but now it happened.  We now need to
> decide about the two options:
> 
>   1. Cancel the upload to new and drop the python3-jellyfish package
>   2. Just leave this as is and follow the advise of the jellyfish
>  author quoted on top of this mail to the python list[4] to
>  rename just the Python module.
> 
> I think option 2. is better for all parts and if you agree I'd
> immediately cancel the upload to new.

thanks for the detailed clarification on the events surrounding the
package and the prompt response!

I would be happy to go with either option (personally leaning towards
option 2 as well), and basically rely on your expertise - the upstream
string-jellyfish author has explicitely mentioned that he has no strong
opinion on the Debian package name and I don't have either.

With this in mind, I'm wondering if this would be a good time to rename
this ITP and the RFS (and the mentors package, etc) to the hopefully
final Debian package name ("python-jellyfishstr"?)?

Best regards,
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Re: Bug#806716: Jellyfish name conflicts

[Diego M. Rodriguez]

Hello Andreas,

> H, ftpmaster was fast - now python-jellyfish is accepted.  This only
> leaves us option 2 without fiddling around to much.

I noticed - and feels like yet another argument in favour of option 2.
If there is something I can do to help with the renaming of the DNA
jellyfish python module (collaborating on the upstream repository,
gathering more opinions on the matter, or anything else) I'd be willing
to lend a hand, just let me know!

> > With this in mind, I'm wondering if this would be a good time to rename
> > this ITP and the RFS (and the mentors package, etc) to the hopefully
> > final Debian package name ("python-jellyfishstr"?)?
> 
> The latter sounds sensible.  Sorry for all the confusion and leaving you
> alone a bit with this issue.

Thanks for sharing your thoughts on the package renaming issue, and no
worries at all - I really apreciate your guidance and efforts on helping
move this issue forward.

Best regards,
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#837805: (no subject)

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 

* Package name: python-can
  Version : 1.5.2
  Upstream Author : Brian Thorne 
* URL : https://bitbucket.org/hardbyte/python-can
* License : LGPL v3
  Programming Lang: Python
  Description : Controller Area Network (CAN) interface module for Python

Binary package names: python-can, python3-can

 The Controller Area Network (CAN, aka "CAN bus") is a bus standard designed
 to allow microcontrollers and devices to communicate with each other. It
 has priority based bus arbitration, reliable deterministic
 communication. It is used in cars, trucks, boats, wheelchairs and more.
 .
 The ``can`` package provides controller area network support for
 Python developers; providing `common abstractions to
 different hardware devices`, and a suite of utilities for sending and receiving
 messages on a can bus.

I intend to maintain this package (and another CAN bus related package) within
the Debian Python Modules Team.

Bug#837806: ITP: python-canmatrix -- Handle CAN (Controller Area Network) database formats

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 

* Package name: python-canmatrix
  Version : 0.4
  Upstream Author : Eduard Broecker 
* URL : http://github.com/ebroecker/canmatrix
* License : BSD
  Programming Lang: Python
  Description : Handle CAN (Controller Area Network) database formats

Binary package names: python3-canmatrix python-canmatrix

 Canmatrix implements a "Python CAN Matrix Object" which describes the
 CAN-communication and the needed objects (Boardunits, Frames, Signals, Values,
 ...)
 Canmatrix also includes two Tools (canconvert and cancompare) for
 converting and comparing CAN databases. There are also some extract and merge
 options for dealing with CAN databases.
 Supported file formats for import:
  * .dbc candb / Vector
  * .dbf Busmaster (open source!)
  * .kcd kayak (open source!)
  * .arxml autosar system description
  * .yaml dump of the python object
  * .xls(x) excel xls-import, works with .xls-file generated by this lib
  * .sym peak pcan can description
 Supported file formats for export:
  * .dbc
  * .dbf
  * .kcd
  * .xls(x)
  * .json Canard (open source!)
  * .arxml (very basic implementation)
  * .yaml (dump of the python object)
  * .sym

I intend to maintain this package (and another CAN bus related package) within
the Debian Python Modules Team.

Re: Updating pip

[Diego M. Rodriguez]

On 1/24/20 8:00 PM, Scott Kitterman wrote:
> I would suggest that people who decide to work on one of the above reply to 
> this message so we don't end up with people doing duplicate works.

I can work on bumping "progress".

Best,
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Re: Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)

[Diego M. Rodriguez]

On 5/26/20 11:06 PM, Scott Talbert wrote:
> It looks like it's a bug in sphinx.

I'm suspecting the same - and I was also not able to reproduce it in
a local installation (pip-installed sphinx trying to match the
dependencies and versions). However, it seems the culprit is at
"case/mock.py":51:

call = mock.call

In case a new upload of sphinx does not land in time, perhaps a
workaround along the lines of:

diff --git a/docs/reference/case.mock.rst b/docs/reference/case.mock.rst
index 1a28a5c..2b6562c 100644
--- a/docs/reference/case.mock.rst
+++ b/docs/reference/case.mock.rst
@@ -9,3 +9,4 @@
 .. automodule:: case.mock
 :members:
 :undoc-members:
+:exclude-members: call

might be acceptable? While not the ideal solution, the upstream
generated docs [1] end up including the docstring from
"unittest.mock._Call" [2] for that member, which might not provide too
much relevant info for end users anyway (and the inheritance from
"tuple" might be related to the original error).

[1] 
https://case.readthedocs.io/en/latest/reference/case.mock.html#case.mock.call
[2] https://github.com/python/cpython/blob/3.8/Lib/unittest/mock.py#L2352

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#993797: ITP: python-beniget -- collection of compile-time Python AST analyzers

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-python@lists.debian.org, debian-scie...@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-beniget
  Version : 0.4.1
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/beniget
* License : BSD
  Programming Lang: Python
  Description : collection of compile-time Python AST analyzers

Collection of compile-time analyzers of Python Abstract Syntax Trees
that can be used as building blocks to write static analyzers or
compilers:
* Ancestors: map a node to the list of its enclosing nodes
* DefUseChains: map a node to the list of definition points in that node
* UseDefChains: map a node to its list of potential definitions

This package is a dependency of ITP "pythran" [1]. My intent is to
package this software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
---
Diego M. Rodriguez

Bug#993800: ITP: python-gast -- compatibility layer for the AST of various Python versions

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-python@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-gast
  Version : 0.5.2
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/gast
* License : BSD
  Programming Lang: Python
  Description : compatibility layer for the AST of various Python versions

Provides an homogeneous API over the Abstract Syntax Trees of various
Python versions (including Python 2 and Python 3), which itself is
compatible with the standard library "ast" module API.

This package is a dependency of ITP "pythran" [1] (and also of ITP
"beniget" [2], another dependency itself). My intent is to package this
software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993797

---
Diego M. Rodriguez

Request to join the team

[Eduardo M KALINOWSKI]

I'd like to join the Python team. I intend to package the 
browser_cookie3 module (https://github.com/borisbabic/browser_cookie3), 
ITP #1056159.


My salsa login is ekalin.

I've read and accept the Python Python policy.


Thanks,

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

RFS: browser-cookie3/0.19.1-1 - Python module for extracting cookies from browser

[Eduardo M KALINOWSKI]

I am looking for a sponsor for my package "browser-cookie3":

 * Package name : browser-cookie3
   Version  : 0.19.1-1
   Upstream contact :Boris Babic https://github.com/borisbabic/browser_cookie3/
 * License  : LGPL-3
 * Vcs  :https://salsa.debian.org/ekalin/browser-cookie3
   Section  : python

The source builds the following binary packages:

  python3-browser-cookie3  -Python module for extracting cookies from browser 
Changes for the initial release:

browser-cookie3 (0.19.1-1) unstable; urgency=medium  * Initial release 
(Closes: #1056159) My plan is for the package to be team-maintained (the 
VCS fields in control are even pointing to a non-existing repository 
under python/), bu sine I'm not yet part of the team 
(https://lists.debian.org/debian-python/2023/11/msg00033.html), I've 
uploaded the package to a personal repository, but I'll gladly move it 
to the python team). I've had to manually add the dependency on 
python3-jeepney because of the complex way it's specified in setup.py. 
The package has some tests, but they need the webdriver_manager module 
(which is not packaged), so the tests are not being run. Thanks,


--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Request to join the team

[Eduardo M KALINOWSKI]

On 31/12/2023 15:02, Stefano Rivera wrote:

Hi Eduardo (2023.11.19_12:52:22_+)

I'd like to join the Python team. I intend to package the browser_cookie3
module (https://github.com/borisbabic/browser_cookie3), ITP #1056159.


What's the use-case for this package in Debian? It's a bit of a weird
library (digging around in the user's browser profile isn't something
expected).


The general use case is mostly for scraping utilities that require a 
session cookie, one logs in to the site, then this library can help 
getting the cookie so that the requests including the cookie can be made.


The specific use case is that a next version of instaloader 
(https://tracker.debian.org/pkg/instaloader), a Instagram scraper, will 
probably require this library (the current RC version includes the 
feature that uses this library).



Please prepare some packaging on salsa and get some review of it. I
don't really like to add members to the team when the only work I can
see of theirs is an email requesting membership...


As a matter of fact, I have already done so: 
https://lists.debian.org/debian-python/2023/12/msg00042.html . The 
package is in my personal salsa area: 
https://salsa.debian.org/ekalin/browser-cookie3


--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: RFS: browser-cookie3/0.19.1-1 - Python module for extracting cookies from browser

[Eduardo M KALINOWSKI]

On 14/12/2023 10:38, Eduardo M KALINOWSKI wrote:

I am looking for a sponsor for my package "browser-cookie3":

  * Package name : browser-cookie3
Version  : 0.19.1-1
Upstream contact : Boris Babic https://github.com/borisbabic/browser_cookie3/
  * License  : LGPL-3
  * Vcs  : https://salsa.debian.org/ekalin/browser-cookie3
Section  : python

The source builds the following binary packages:

   python3-browser-cookie3  -Python module for extracting cookies from browser 
Changes for the initial release:

browser-cookie3 (0.19.1-1) unstable; urgency=medium  * Initial release 
(Closes: #1056159) My plan is for the package to be team-maintained (the 
VCS fields in control are even pointing to a non-existing repository 
under python/), bu sine I'm not yet part of the team 
(https://lists.debian.org/debian-python/2023/11/msg00033.html), I've 
uploaded the package to a personal repository, but I'll gladly move it 
to the python team). I've had to manually add the dependency on 
python3-jeepney because of the complex way it's specified in setup.py. 
The package has some tests, but they need the webdriver_manager module 
(which is not packaged), so the tests are not being run. Thanks,


This is a friendly ping to let you know that I'm still looking for a 
sponsor for this package.



--
Unix will self-destruct in five seconds... 4... 3... 2... 1...

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: RFS: browser-cookie3/0.19.1-1 - Python module for extracting cookies from browser

[Eduardo M KALINOWSKI]

On 07/02/2024 12:15, Salvo Tomaselli wrote:

In data venerdì 19 gennaio 2024 20:55:45 CET, Eduardo M KALINOWSKI ha scritto:

On 14/12/2023 10:38, Eduardo M KALINOWSKI wrote:

I am looking for a sponsor for my package "browser-cookie3":
   * Package name : browser-cookie3
   
 Version  : 0.19.1-1

 Upstream contact : Boris Babic
   * URL  : https://github.com/borisbabic/browser_cookie3/

   * License  : LGPL-3
   * Vcs  : https://salsa.debian.org/ekalin/browser-cookie3
   
 Section  : python


The source builds the following binary packages:
python3-browser-cookie3  -Python module for extracting cookies from

browser Changes for the initial release:

browser-cookie3 (0.19.1-1) unstable; urgency=medium  * Initial release
(Closes: #1056159) My plan is for the package to be team-maintained (the
VCS fields in control are even pointing to a non-existing repository
under python/), bu sine I'm not yet part of the team
(https://lists.debian.org/debian-python/2023/11/msg00033.html), I've
uploaded the package to a personal repository, but I'll gladly move it
to the python team). I've had to manually add the dependency on
python3-jeepney because of the complex way it's specified in setup.py.
The package has some tests, but they need the webdriver_manager module
(which is not packaged), so the tests are not being run. Thanks,


This is a friendly ping to let you know that I'm still looking for a
sponsor for this package.

> You have a link to the dsc file?

Sure, I've uploaded the package to mentors and the dsc is here:

https://mentors.debian.net/debian/pool/main/b/browser-cookie3/browser-cookie3_0.19.1-1.dsc

--
We are using Linux daily to UP our productivity - so UP yours!
(Adapted from Pat Paulsen by Joe Sloan)

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: RFS: browser-cookie3/0.19.1-1 - Python module for extracting cookies from browser

[Eduardo M KALINOWSKI]

On 10/02/2024 08:10, Salvo Tomaselli wrote:

I decided not to sponsor it.

It doesn't seem to handle local storage, just cookies. Which are trivial to
access in python with sqlite3.

So for me it has no use. Does anything depend on it?


Nothing currently. The next version of instaloader (a tool for 
downloading Instragram data) will likely depend on it. (Or at least 
recommend it.)


--
Some men are all right in their place -- if they only the knew the right 
places!

-- Mae West

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Is there anybody out there? [Was Re: Grail (was: ...))]

[Lorenzo M. Catucci]

On Thu, 17 Sep 1998, Gregor Hoffleit   > 
>  > An interested user told me that CNRI/NIST decided to leave the code
>  > alone, after having used it as a testbed for network research and
>  > might lighten the license.
[...]
> 
> I wonder if we are the only ones reading this list. Is it possible to
> see who is subscribed to the list ?
> 
`An interested user', at least... BTW, I'm pondering on both your latest
posting arguments (Jpython and python policy), as I think that both
deserve a careful answer, especially the latter, which is of most use to
me by now... (I know, I'm just a bit egotic...)

Just to let you know I'm hearing what goes here: do you really think
someone would use a python without regexp? Just think about cgi, or better
do a:


$ egrep \\bre\(\|gex\)\\b /usr/lib/python/*.py|grep import|wc

I see 46 lines, some of whose in important modules like {url,xmg,sgml}lib!

And later will write on more important stuff, keep tuned!

Yours,

l.

Re: Experimental slink python and jpython packages

[Lorenzo M. Catucci]

I told to stay tuned... And now here I am, still waiting for your upcoming
Debian Python Policy... But I see some part of it, at least...

On Tue, 15 Sep 1998, Gregor Hoffleit wrote:

> Hi,
> 
> - removal of python-net and python-misc
> - instead, a new package python-lib
>

Nice, I think it was about the time to condense the python distribution
files...

>
> - python-lib is Architecture: all; it's the architecture-independent part 
>   of python-1.5.1/Lib.
> - /usr/share/python instead of /usr/lib/python1.5
> - /usr/lib/python1.5 has the architecture-dependent stuff like 
>   lib-dynload and config (this should probably be /usr/lib/python/).
>

I'm still unsure if it wouldn't be better to stay closer to upstream
behaviour

>
> - sitecustomize should be a conffile and therefore live in /etc/python/.
>

This is right

>
> - Not yet done: Change Makefile.pre.in so that it installs in the correct 
>   places.
>

I think it is mandatory, if we want to change the default paths

>
> - Not yet included, the code exists: Build a shared libpython

I think it would be of some use (at least) to those willing to use stuff
like apache-module.

> 
> 
> The layout with /usr/share/python and /usr/lib/python has many advantages 
> for Debian, but also a few drawbacks: It makes it impossible to install 
> two different Debian python versions at the same time (not possible 
> yet with the current layout; do we really need this ???). It drives us 
> away from the upstream python layout. Still I think the advantages (much 
> easier upgrade paths; let the Debian packaging system handle versioned 
> dependencies) are more important.
> 

I should think a lot more before replying, but we wouldn't lose dpkg
dependancies even if we stayed closer to upstream...

> 
> Then, there's the question where and how to install Debian Python add-on 
> packages. I'd like to adopt a mechanism similar to emacen-common, where 
[...]
> Python add-on packages: e.g. /usr/share/site-python or 
> /usr/share/python/site-packages (for architecture-independent files) 
> or /usr/lib/python/site-packages or /usr/lib/site-python or even 
> /usr/lib/python1.5/site-packages (for architecture-dependent or binary 
> packages). Finally, how to handle "old-style" packages ?
> 

For old style packages, I think^H^H^H^H^H am almost sure we should use the
.pth solution, and make each of them reside in a separate subdirectory.
I don't understand why don't you like a (not buggy) compileall.py, which
would leave alone .py files elder than their corresponding .py[co]; and
then, does Jpython use a different extension? If so, wouldn't we need a
compileall mechanism to compile stuff present before jpython install?

A problem with your proposed lib - share split could come from mixed
binary/python packages like PIL... I think it would be a small clearness
advantage being able to put the whole package inside a single directory,
but then /usr/share should only contain arch-independant stuff...

>
> I really would like to introduce these changes with slink.
>

I fear we are a bit late... seems slink is about to freeze (without a
working pam, which is really sad for me!). 

A final comment: I really like the python-xxx convention to name any
python add-on package much more than libpython-yyy, but any one (I told
one!) would do...

Yours,


l.

Re: Experimental slink python and jpython packages

[Lorenzo M. Catucci]

On Tue, 13 Oct 1998, Gregor Hoffleit wrote:

> 
> 1.) Play safe. Stick with the current scheme for slink. I'll upload a
> new revision 1.5.1-5 with minor fixes only (all official patches
> applied).
>
This is how I think we should go...
> 
> 2.) Play risk. Adopt a new scheme similar to my proposal, e.g.
> 
> - Remove python-net, python-misc; new package python-lib. This would
>   break a few packages' dependencies; those had to be rebuilt.
>
This could be done too; python-lib could even provide python-net and
python-misc, therefore I think it could well be done too

I'm still unsure about the /var/cache idea: we all know Cpython can import
packages even though the corresponding py[co] doesn't exist -if with some
speed drawback- and I expect for Jpython it is just the same, but the
speed drawback is there, and (worse to me) /var/cache is meant to be a
local hierarchy, while /usr/{lib,share} can really be shared between
different machines...

As for the install time, I think it would be better to 

a. make sure pycompile doesn't end up recompiling un-needed stuff
b. put in an option to call it backgrounded and redirected to /dev/null

As for the py[co] removal while uninstalling python, wouldn't something
like a 

   find  -name '*py[co]' -exec rm {} \; 

or, better 

for file in 
do
for add_char in co
do
rm $file$add_char
done
done

inside any postrm do equally well (or even better?)

Ciao,

l.

Re: Experimental Python 1.5.2c1 packages available

[Lorenzo M. Catucci]

On Tue, 13 Apr 1999, Gregor Hoffleit wrote:

> I have put together a set of experimental Python 1.5.2c1 packages. To use 
> them with apt, try the following line:
>
[...]
> 
>   * Python 1.5.2 release candidate 1.
> 
>   * libpython1.5.so reworked. Please report any anomalities! If I don't 
> get any negative feedback, the next potato packages will use a shared 
> libpython for the first time in Debian history ;-)
> 
Excellent!
>
>   * break sketch 0.5.4. This is a problem with the new multi-threaded 
> Tkinter and sketch' Pax modules. Sketch' author will try to fix this, 
> in the meantime sketch will have to provide an alternative 
> python-tk-nothreads package.
>
This should be thought out very well... There should be a way to tell
sketch to use a "private _tkinter", and have the standard _tkinter
available as well (IMHO)
> 
>   * python-doc 1.5.2. Is html enough, or should I also include 
> python-doc-ps and python-doc-pdf.
> 
I think that having both ps and pdf is a bit overkill; look out for
a4/letter, and maybe make two packages like python-doc-ps-a4 and
python-doc-ps-ltr instead of a single one (or pdf-a4 and pdf-letter, if
the consesus is pdf being better than ps). I seem to remember there is now
a complete info set, which I sure would like to install for use within
{x,}emacs, but I don't know how many of debian/python users would find a
need for it.


Have a nice forthweek.


l.

Re: Experimental Python 1.5.2c1 packages available

[Lorenzo M. Catucci]

On Wed, 14 Apr 1999, Gregor Hoffleit wrote:
>
> > I do. Please do include info docs.
> 
> I will.
> 
> The docs are quite big (700k resp. 450k for html and info
> gzipped). Is there support for splitting them in separate packages ?
> Then, is there also a need for postscript resp. pdf packages ?
> 
IMHO, info and html should be regarded as being in the same footing as the
main information gathering means (but I sure understand I'm a bit biased,
since I like info much more than the mean python programmer). As for
ps/pdf, I won't tell you I feel a real need (after all, I printed my copy
of python docs this summer, at 1.5.2 alpha time, and I won't reprint them
at least until 1.6), but I think they might be useful for first time
python programmers, and I think both of us would like making their life
simpler... I stand by my earlier suggestion of a couple of
doc-pdf-{a4,letter} or doc-ps-{a4,letter}, but I'm unable to tell which
is best. Votes, please!

l.

Re: Python 2.1 out

[David M. Cooke]

At some point, D-Man <[EMAIL PROTECTED]> wrote:

> On Thu, Apr 19, 2001 at 12:17:40PM +0200, Florian Weimer wrote:
> | Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> | 
> | [Python warning messages]
> | 
> | > Could you mail an example of such a message ?
> | 
> | y = None
> | def fun():
> | y = None
> | def bar():
> | y
> | bar()
> | 
> | fun()
> | 
> | results in:
> | 
> | :2: SyntaxWarning: local name 'y' in 'fun' shadows use of 'y' as 
> global in nested scope 'bar'
> |   def fun():
> 
> Yeah, that code will almost certainly break in 2.2 when nested scopes
> become mandatory.  It may have been intended, but assignment to a
> local variable overshadowing a global is rarely the intended effect.
> 

Just to make it clearer -- the warning is *not* because of the global
y. The minimalist version is

def fun():
y = None
def bar():
y

:1: SyntaxWarning: local name 'y' in 'fun' shadows use of 'y' as global 
in nested scope 'bar'

Also, it's a syntax warning, so it's caught at compile time -- any
scripts where this occurs will be caught before they run, making it
trivial to figure out where the problems are.

> Anyways, if you want to get rid of those message now, without changing
> the code use the  -W option to the interpreter.  Example :
> 
> $ python -W ignore Scope.py
> 
> (I created a file called Scope.py with that code in it)
> 

A quick examination of the package lists show ~39 'python-*' packages
that don't have equivalent 'python2-*' packages. There are about ~100
packages that depend on python-base that would have to be checked for
compatibility with Python 2.1.

I think it's safe to say that wholesale use of 'python -W ignore'
would be unwarranted, because a lot of other stuff has to checked
any way ;-)

-- 
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]

Re: Status report on python2 transition (possible solution)

[David M. Cooke]

At some point, D-Man <[EMAIL PROTECTED]> wrote:

> On Fri, Jul 13, 2001 at 11:30:28PM +0200, Carel Fellinger wrote:
> | On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote:
> | ...
> | > o   The #! line should look something like
> | > #!/usr/bin/deb_py_ver 1.5.2 -
> | 
> | I can't get things like this to work.  It seems one parameter at
> | most is allowed there.  
> 
> Huh?  The idea was that there would be a script/program named
> deb_py_ver.  It would take 2 command-line arguments and determine
> which python binary should be used.  It would then exec that python on
> the script (which, IIRC, is on stdin of deb_py_ver).  This would allow
> having a single program, rather than an exponentially growing number
> of symlinks.  Otherwise the symlink idea is the simplest
> implementation, except for handling which package to put each link in.
> 

That's not the problem -- the problem is that the command specified in
the #! is passed the rest of the line as _one_ argument (at least on
Linux). That's why you can't do, for instance,

#!/usr/bin/env python -O

as the first line.

I suppose you could split the argument on spaces -- although I'm not sure if
other Unices (the Hurd, anyone?) pass the rest of the line or just the first
argument.

Another alternative would be

#!/usr/bin/deb_py_ver 1.5.2-

and

#!/usr/bin/deb_py_ver 1.5.2-2.1.1

That's one argument.

-- 
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]

Re: python2.1 et al.

[David M. Cooke]

At some point, Gregor Hoffleit <[EMAIL PROTECTED]> wrote:

> My proposal for woody: Python 1.5.2 is renamed to python1.5-*. Python
> 2.1.1 will be shipped as python2.1-*. Do we need python2.0-* as well ?

I don't see why. Looking at the list of changes from 2.0 to 2.1 at
http://www.amk.ca/python/2.1/ I can see only a few difficulties in
using code written for 2.0 in 2.1:

- complex numbers can only be compared with == and != now
- 'from module import *' will only import some of the names in
  module if module has an __all__ attribute

There are some C API changes too, but the old API is still there.

None of these look like they'll break old code (or require more than 5
minutes to fix).

> Then, we still have to agree on a strategy how to set up the
> dependencies, in order to make the upgrade work in an intuitive way.
> 
> For maintainers of Python extension modules, this would mean that they
> would have to build one package for each included Python version, e.g.
> python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb.
> 
> There would be no python-* packages in woody!!!

How about a 'python' package, much like the 'gcc' package, whose only
purpose is to set what is the default python interpreter for Debian?
It would depend on python2.1-base.

-- 
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]

Re: Python 2.0 in Debian (was: Re: [Python-Dev] PEPS, version control, release intervals)

[M.-A. Lemburg]

Gregor Hoffleit wrote:
> 
> If somebody could give me a legal advice that the Python license is in fact
> compatible with the GPL, and if this was accepted by the guys at
> debian-legal@lists.debian.org, I would happily adopt this opinion and that
> would make (b) go away as well.
> 
> Until this happens, I think the best way for Debian to handle this situation
> (clearly not perfect!) is to use a per-case judgement--if there's GPL code
> in a package, ask the author if it's okay to use it with Python2 code. If he
> says alright, go on with packaging. 

Say, what kind of clause is needed in licenses to make them explicitly
GPL-compatible without harming the license conditions in all other
cases where the GPL is not involved ?

> If he says nogo (as the FSF did for
> readline), do away with the package (therefore python2-base doesn't include
> readline support).

Oh boy... about time we switch to editline as the default line
editing package.

-- 
Marc-Andre Lemburg
__
Company:http://www.egenix.com/
Consulting:http://www.lemburg.com/
Python Pages:   http://www.lemburg.com/python/

Re: Python 2.0 in Debian

[M.-A. Lemburg]

Gregor Hoffleit wrote:
> 
> On Fri, Feb 16, 2001 at 01:51:14PM +0100, M.-A. Lemburg wrote:
> > Gregor Hoffleit wrote:
> > >
> > > If somebody could give me a legal advice that the Python license is in 
> > > fact
> > > compatible with the GPL, and if this was accepted by the guys at
> > > debian-legal@lists.debian.org, I would happily adopt this opinion and that
> > > would make (b) go away as well.
> > >
> > > Until this happens, I think the best way for Debian to handle this 
> > > situation
> > > (clearly not perfect!) is to use a per-case judgement--if there's GPL code
> > > in a package, ask the author if it's okay to use it with Python2 code. If 
> > > he
> > > says alright, go on with packaging.
> >
> > Say, what kind of clause is needed in licenses to make them explicitly
> > GPL-compatible without harming the license conditions in all other
> > cases where the GPL is not involved ?
> 
> Hmm, during the great KDE confusion (KDE was GPL, and Qt was not compatible
> with the GPL), it was suggested that the authors of the KDE code should add
> this clause to their license boiler plate (cf.
> http://www.debian.org/News/1998/19981008):
> 
>   `This program is distributed under the GNU GPL v2, with the
> additional permission that it may be linked against Troll Tech's Qt
> library, and distributed, without the GPL applying to Qt''

Uhm, that's backwards from what I had in mind with the question.
Sorry for not being more to the point. 

Here's the "problem" I have: I want to put my code under a license
similar to the Python 2 license (that is including the choice of 
law clause which caused all this trouble). 

Since some of my code is already being used by GPL-software
out there,I would like to add some kind of extra-clause to
the license which permits the GPL-code authors to the new versions
as well.

This is somewhat similar to the problem that Python2 has with the GPL; 
don't know how CNRI is going to change the license for 1.6.1, but I
want to include something similar in my license.

Anyway, since Debian is very sensitive to these issues, I thought
I'd ask you for a possible way out.

Thanks,
-- 
Marc-Andre Lemburg
__
Company:http://www.egenix.com/
Consulting:http://www.lemburg.com/
Python Pages:   http://www.lemburg.com/python/

Re: [Python-Dev] Re: Python 2.0 in Debian

[M.-A. Lemburg]

Gregor Hoffleit wrote:
> 
> On Fri, Feb 16, 2001 at 03:34:07PM +0100, M.-A. Lemburg wrote:
> > Here's the "problem" I have: I want to put my code under a license
> > similar to the Python 2 license (that is including the choice of
> > law clause which caused all this trouble).
> 
> Why don't you simply remove the first sentence of this clause ("This License
> Agreement shall be governed by and interpreted in all respects by the law of
> the State of Virginia, excluding conflict of law provisions.") ?
> 
> Is there any reason for you to include this choice of law clause anyway, if
> you don't live in Virginia ?

I have to make the governing law the German law since that is where
my company is located. The text from my version is:

"""
This License Agreement shall be governed by and interpreted in all
respects by the law of Germany, excluding conflict of law
provisions. It shall not be governed by the United Nations Convention
on Contracts for International Sale of Goods.
"""

Does anyone know of the wording of the new 1.6.1 license ? 

-- 
Marc-Andre Lemburg
__
Company:http://www.egenix.com/
Consulting:http://www.lemburg.com/
Python Pages:   http://www.lemburg.com/python/

Re: libwxgtk2.2-python (fwd)

[David M. Cooke]

At some point, Ron <[EMAIL PROTECTED]> wrote:

> > I'd prefer the latest python and wxpython (and wxwindows-c++),
> 
> I prefer the latest of everything too :)  but this:
> 
> > assuming there aren't any critical bugs.
> 
> is one of the questions I want an anwser to here.
> 
> Personally I've never even installed python2.1 so I have no idea
> about it's stability.  What I'm interested in figuring out is which
> version we should be concerned with getting into Woody.

Well, 2.1 isn't the latest version (2.2a4 is, with 2.2b1 coming soon).
I had a one problem with crashing in 2.1, but that was fixed in 2.1.1.
I would say 2.1.1 is even more stable than 1.5.2.

Can anyone think of any reason why 2.0 should stay? (Besides packages
depending on it.) I mean, is there any difference between 2.1 and 2.0
that would be difficult to fix when upgrading a package to depend on
2.1 instead of 2.0? (I can't)

-- 
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]

Re: What should we do now?

[David M. Cooke]

At some point, Anthony Towns  wrote:

> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local. 
> > > How about we just say "Don't install other versions of python in
> > > /usr/local" ?
> > Please no.  Making this work properly is not hard.  
> 
> Again, _why_ does this matter? Who does this? Is it even remotely common?
> That people would even consider installing another version of python in
> /usr/local surely just points to a problem with the Debian packaging, no?
> 
Well, I do it for one. My reasons are two-fold: I like experimenting
with the latest, greatest, bleeding-edge python, and I also want to
compile it with optimizations (which can give me a small speedup;
important for the numerical work I do). 

And not just into /usr/local: On some machines I don't have root
access, so I put it into my home directory under ~/usr. (Ok, so those
machines aren't Debian, but I think the same principle applies.)

> The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> makes dependencies that much more complicated: *all* python scripts have
> to depend on versioned modules in every way, ie "Depends: python1.5-base,
> python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
> python executables need to be modified at the source level for every
> python upgrade, and finally it makes Debian veer away from upstream
> standards for python scripts.

Looking at my /usr/bin, I see (with the command

file /usr/bin/* | grep script | sed 's/:.*$//' | awk '{ getline a <
$1; if (a ~ /^#\!/) { print a } close($1) }' | sort

) that almost all script files specify the location of the interpreter
-- the only exceptions being some python scripts and one perl script
(all of the other perl scripts do some variant of #!/usr/bin/perl).
So, I don't think it's too much to ask that scripts that Debian
installs specify the location of the interpreter.

As for the versioned depends, how else do you want to do it? Say I
have a package python2.1-foo, which only supports Python 2.1 (it uses
list comprehensions, say). Now, assume it depends on python-gtk and
python-numeric. It has to depend on *2.1* versions of those packages,
not 1.5. This has nothing to do with the scripts in python2.1-foo
having to use #!/usr/bin/python2.1. (I use 2.1 here instead of 1.5 as
I believe there is little to prevent one from making a 1.5 package use
2.1 -- however, going to 2.2 would be more difficult).

Updating the #! line in the script would be small potatoes compared to
checking that the package works correctly with a new version of
Python.

> And all this for what, precisely?
> 
> If you install new versions of standard tools in /usr/local you have
> to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
> a /usr/local/bin/sed, or whatever. Going out of your way to make sure
> it doesn't apply to a /usr/local/bin/python seems to this observer a
> complete waste of time.

[Your two examples are essential base programs in Debian -- it would
be stupid to fiddle with them, unless you know what you're doing]

I see it as: this package I installed worked, and I don't care whether
it's written in python or perl or tcl... Now, I've compiled my own
python, and the package doesn't work anymore! I see no reason why
scripts shouldn't specify exactly which interpreter they expect to be
using.

-- 
|>|\/|<
/--\
|David M. Cooke
|[EMAIL PROTECTED]

Re: Python 2.0 in Debian (was: Re: [Python-Dev] PEPS, version control, release intervals)

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [M.-A. Lemburg]
> > Say, what kind of clause is needed in licenses to make them explicitly
> > GPL-compatible without harming the license conditions in all other
> > cases where the GPL is not involved ?
> 
> You can dual-license (see, e.g., Perl).

Right and it looks as if this is the only way out: either you give
people (including commercial users) more freedom in the use of
the code and add a choice-of-law clause or you restrain usage
to GPLed code and cross fingers that noone is going to sue the
hell out of you... doesn't really matter if the opponent lives
in Kingdom of Unlimited Liability or not -- the costs of finding 
out which law to apply and where to settle the dispute would already
suffice to bring the open source developer down to his/her knees.

Oh well,
-- 
Marc-Andre Lemburg
__
Company:http://www.egenix.com/
Consulting:http://www.lemburg.com/
Python Pages:   http://www.lemburg.com/python/

pure python and postinst

[Steve M. Robbins]

Howdy,

I've just finished my first attempt at packaging a python module.
This module (people.debian.org/~smr/pyvtk) is purely python.

I followed the "python policy" outlined in /usr/share/doc/python, and
also looked at a couple of example packages.

One thing I noticed in the packages (that isn't covered in the policy)
is the practice of deleting the ".pyc" files in debian/rules, and
then running "compileall.py" in the postinst.  Would someone comment on
this?  Is it a requirement -- is it a bug to include the compiled
python files in the .deb?

Thanks,
-Steve

P.S.  Other comments on my package (url above) greatly appreciated!

breaks other packages

[Steve M. Robbins]

severity 170711 critical
thanks

Hi,

I ran into coredumps when using python-vtk, see bug #170498.

I believe the coredumps are due to python moving from tcl/tk 8.3 to
tcl/tk 8.4.  Other python extenion modules are still built with the
older tcl/tk, so you end up with both 8.3 and 8.4 loaded.

I think this bug should be release-critical to hold up the move to
"testing" until all the modules are in sync, right?

-Steve

Re: pure python and postinst

[Steve M. Robbins]

On Wed, Apr 02, 2003 at 09:20:22AM +1000, Donovan Baarda wrote:
> G'day, 
> 
> just going through my old inbox messages that didn't seem to be replied
> to;
> 
> On Mon, 2002-11-18 at 13:11, Steve M. Robbins wrote:

Well, thanks!  I had forgotten about this.  I'm no longer sure what
prompted my question.  Perhaps it was idle curiousity ...


> > I've just finished my first attempt at packaging a python module.
> > This module (people.debian.org/~smr/pyvtk) is purely python.
> > 
> > I followed the "python policy" outlined in /usr/share/doc/python, and
> > also looked at a couple of example packages.
> > 
> > One thing I noticed in the packages (that isn't covered in the policy)

... or maybe I was wondering why this common practice isn't covered in
the python packaging document that I was using at the time.

A summary of this little thread would make a nice addition to
the policy if it is not yet in there.

-S

Python 2.3 as default?

[David M. Cooke]

What's the word on making the default version of python to be 2.3
instead of 2.2, now that 2.3 is released?

-- 
|>|\/|<
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

os.path: ImportError: cannot import name realpath

[M. Emal Alekozai]

Hallo Mailinglist,
I never used Python before (just perl) :-( .
I got problems to get the python Programm "archmage" [1] runnig under woody.
I'm not sure, but I think the os.path "library" is missing or not correctly 
installed
(Point 3. says it is installed).
Were is the error, which additional (deb) package do I have to install to get 
it working?
Thanks in advance.
Regards and a happy New Year's Eve
Emal

[1]: It's a programm to convert "chm" (Microsoft Compiled HTML files) to html
See Freshmeat for more details:
http://freshmeat.net/projects/archmage/?topic_id=234,849,867
1. Error output of arCHMage:

[EMAIL PROTECTED]:~$ ls -l test.chm
-rwxr-xr-x1 emal family   738K 2003-12-26 19:04 test.chm
[EMAIL PROTECTED]:~$ archmage test.chm /tmp
Traceback (most recent call last):
  File "/usr/bin/archmage", line 7, in ?
from CHM import *
  File "/usr/lib/python2.1/site-packages/CHM.py", line 2, in ?
from os.path import isfile,isdir,exists,dirname,realpath,getsize,walk
ImportError: cannot import name realpath
2. CHM.py:
==
[EMAIL PROTECTED]:~$ less /usr/lib/python2.1/site-packages/CHM.py
from os import mkdir,makedirs,chdir,getcwd,listdir
from os.path import isfile,isdir,exists,dirname,realpath,getsize,walk
from re import match,escape,search,sub
from shutil import copytree
from HTMLParser import HTMLParser,HTMLParseError,piclose
from BaseHTTPServer import HTTPServer,BaseHTTPRequestHandler
from urllib import unquote
from time import sleep
from mimetypes import guess_type
import chmlib
...
3. I'm using woody python2.1:
===
[EMAIL PROTECTED]:~$ ls -l `which python`
lrwxrwxrwx1 root root9 2002-12-17 14:10 /usr/bin/python -> 
python2.1
[EMAIL PROTECTED]:~$ python -v
# /usr/lib/python2.1/site.pyc matches /usr/lib/python2.1/site.py
import site # precompiled from /usr/lib/python2.1/site.pyc
# /usr/lib/python2.1/os.pyc matches /usr/lib/python2.1/os.py
import os # precompiled from /usr/lib/python2.1/os.pyc
import posix # builtin
# /usr/lib/python2.1/posixpath.pyc matches /usr/lib/python2.1/posixpath.py
import posixpath # precompiled from /usr/lib/python2.1/posixpath.pyc
# /usr/lib/python2.1/stat.pyc matches /usr/lib/python2.1/stat.py
import stat # precompiled from /usr/lib/python2.1/stat.pyc
# /usr/lib/python2.1/UserDict.pyc matches /usr/lib/python2.1/UserDict.py
import UserDict # precompiled from /usr/lib/python2.1/UserDict.pyc
Python 2.1.3 (#1, Sep  7 2002, 15:29:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
import readline # dynamically loaded from 
/usr/lib/python2.1/lib-dynload/readline.so


# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] readline
# cleanup[1] exceptions
# cleanup[1] posix
# cleanup[1] site
# cleanup[1] signal
# cleanup[2] os.path
# cleanup[2] os
# cleanup[2] UserDict
# cleanup[2] posixpath
# cleanup[2] stat
# cleanup sys
# cleanup __builtin__
# cleanup ints: 2 unfreed ints in 1 out of 3 blocks
# cleanup floats

4. arCHMage is used the correct way:
=
The manual says:
$:more README
 arCHMage is an extensible reader and decompiler for files in the CHM 
format.
 This is the format used by Microsoft HTML Help, and is also known as 
Compiled HTML.
 arCHMage is based on chmlib by Jed Wing 
(http://66.93.236.84/~jedwin/projects/chmlib/).
 There is three ways to use arCHMage package now:
 1) Extract .chm to directory(directory will be created):
 archmage  
 ...

os.path: ImportError: cannot import name realpath

[M. Emal Alekozai]

Hallo Mailinglist,
I never used Python before (just perl) :-( .
I got problems to get the python Programm "archmage" [1] runnig under woody.
I'm not sure, but I think the os.path "library" is missing or not correctly 
installed
(Point 3. says it is installed).
Were is the error, which additional (deb) package do I have to install to get 
it working?
Thanks in advance.
Regards and a happy New Year's Eve
Emal

[1]: It's a programm to convert "chm" (Microsoft Compiled HTML files) to html
See Freshmeat for more details:
http://freshmeat.net/projects/archmage/?topic_id=234,849,867
1. Error output of arCHMage:

[EMAIL PROTECTED]:~$ ls -l test.chm
-rwxr-xr-x1 emal family   738K 2003-12-26 19:04 test.chm
[EMAIL PROTECTED]:~$ archmage test.chm /tmp
Traceback (most recent call last):
  File "/usr/bin/archmage", line 7, in ?
from CHM import *
  File "/usr/lib/python2.1/site-packages/CHM.py", line 2, in ?
from os.path import isfile,isdir,exists,dirname,realpath,getsize,walk
ImportError: cannot import name realpath
2. CHM.py:
==
[EMAIL PROTECTED]:~$ less /usr/lib/python2.1/site-packages/CHM.py
from os import mkdir,makedirs,chdir,getcwd,listdir
from os.path import isfile,isdir,exists,dirname,realpath,getsize,walk
from re import match,escape,search,sub
from shutil import copytree
from HTMLParser import HTMLParser,HTMLParseError,piclose
from BaseHTTPServer import HTTPServer,BaseHTTPRequestHandler
from urllib import unquote
from time import sleep
from mimetypes import guess_type
import chmlib
...
3. I'm using woody python2.1:
===
[EMAIL PROTECTED]:~$ ls -l `which python`
lrwxrwxrwx1 root root9 2002-12-17 14:10 /usr/bin/python -> 
python2.1
[EMAIL PROTECTED]:~$ python -v
# /usr/lib/python2.1/site.pyc matches /usr/lib/python2.1/site.py
import site # precompiled from /usr/lib/python2.1/site.pyc
# /usr/lib/python2.1/os.pyc matches /usr/lib/python2.1/os.py
import os # precompiled from /usr/lib/python2.1/os.pyc
import posix # builtin
# /usr/lib/python2.1/posixpath.pyc matches /usr/lib/python2.1/posixpath.py
import posixpath # precompiled from /usr/lib/python2.1/posixpath.pyc
# /usr/lib/python2.1/stat.pyc matches /usr/lib/python2.1/stat.py
import stat # precompiled from /usr/lib/python2.1/stat.pyc
# /usr/lib/python2.1/UserDict.pyc matches /usr/lib/python2.1/UserDict.py
import UserDict # precompiled from /usr/lib/python2.1/UserDict.pyc
Python 2.1.3 (#1, Sep  7 2002, 15:29:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
import readline # dynamically loaded from 
/usr/lib/python2.1/lib-dynload/readline.so
>>>

# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] readline
# cleanup[1] exceptions
# cleanup[1] posix
# cleanup[1] site
# cleanup[1] signal
# cleanup[2] os.path
# cleanup[2] os
# cleanup[2] UserDict
# cleanup[2] posixpath
# cleanup[2] stat
# cleanup sys
# cleanup __builtin__
# cleanup ints: 2 unfreed ints in 1 out of 3 blocks
# cleanup floats

4. arCHMage is used the correct way:
=
The manual says:
$:more README
 arCHMage is an extensible reader and decompiler for files in the CHM 
format.
 This is the format used by Microsoft HTML Help, and is also known as 
Compiled HTML.
 arCHMage is based on chmlib by Jed Wing 
(http://66.93.236.84/~jedwin/projects/chmlib/).
 There is three ways to use arCHMage package now:
 1) Extract .chm to directory(directory will be created):
 archmage  
 ...

os.path: Installing Pyhton2.2 the debian way

[M. Emal Alekozai]

Hi Mailinglist,
> it looks like os.path.realpath was introduced in python2.2.
How do I install python2.2 the debian way ?
On my PC I got the deb's: python (dummy), python2.1 and python2.2 installed
[EMAIL PROTECTED]:~$ ls -l /usr/bin/python*
lrwxrwxrwx1 root root9 2002-12-17 14:10 /usr/bin/python -> 
python2.1
-rwxr-xr-x1 root root 511K 2002-09-07 17:36 /usr/bin/python2.1
-rwxr-xr-x1 root root 726K 2002-09-07 16:38 /usr/bin/python2.2
The programm "dpkg-reconfigure" has no effekt, it run a few seconds and 
then stop without any output.
[EMAIL PROTECTED]:~$dpkg-reconfigure --frontend Dialog --force python
[EMAIL PROTECTED]:~$dpkg-reconfigure --frontend dialog --force python2.1
[EMAIL PROTECTED]:~$dpkg-reconfigure --frontend dialog --force python2.2
All 3 packages have (nearly) the same content, it would be possible, to change all symbolic links 
(bin, man, etc.) and the paths and env variables. But it's lots of work and a really "unclean" solution.
How does the "debian way" (if it exists)  looks like to do this?
Are there any other solutions, suggestions?

Thanks and regards
Emal
[EMAIL PROTECTED]:~$ dpkg -L python
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python
/usr/share/doc/python/README.Debian
/usr/share/doc/python/copyright
/usr/share/doc/python/python-policy.txt.gz
/usr/share/doc/python/changelog.Debian.gz
/usr/share/doc/python/python-policy.sgml.gz
/usr/share/man
/usr/share/man/man1
/usr/share/apps
/usr/share/apps/konsole
/usr/share/apps/konsole/python.desktop
/usr/bin
/usr/share/man/man1/pydoc.1.gz
/usr/share/man/man1/pygettext.1.gz
/usr/share/man/man1/python.1.gz
/usr/bin/python
/usr/bin/pydoc
/usr/bin/pygettext
[EMAIL PROTECTED]:~$ dpkg -L python2.1
..
/usr/bin/python2.1
/usr/bin/pydoc2.1
/usr/bin/pygettext2.1
[EMAIL PROTECTED]:~$ dpkg -L python2.2
...
/usr/bin
/usr/bin/python2.2
/usr/bin/pydoc2.2

Debian, get discount on medications here

[Rosily M. Oil]

Oops... :)A college education should equip one to entertain three things: a friend, an idea and oneself.Wherever the fates lead us let us follow.
Debian, need cheap medication?
http://parabiotic.nnaew1.com/d13/index.php?id=d13 spasmed
It is all one to me if a man comes from Sing Sing Prison or Harvard. We hire a man, not his history.By common consent gray hairs are a crown of glory the only object of respect that can never excite envy.To love abundantly is to live abundantly, and to love forever is to live forever.Talk to a man about himself and he will listen for hours.

Re: help with seemingly Debian-specific python bug

[David M. Cooke]

On Mon, Jun 07, 2004 at 06:55:09PM +, Faheem Mitha wrote:
> Dear People,
> 
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252517
> 
> I'd like to ask for help in debugging this. Firstly, can anyone
> reproduce this on sarge?
> 
> When I run inside gdb I don't get any information about the segfault,
> presumably because I don't have python2.3 compiled with  debugging support
> 
> I tried to compile python2.3 with debugging support. I made what I
> thought were appropriate changes in rules (see patch below).
> 
> However, when I try to do *anything* with the resulting executable, I
> get errors, eg. something about cannot import site (whatever that
> means), and I cannot load the numarray shared libraries.

With a debug build of python, *all* the C extensions you use must be
recompiled. The debug build changes the layout of PyObject, so non-debug
C extensions access the fields of that wrong.

[This of course makes a debug build pretty hard to use...]

-- 
|>|\/|<
/------\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

help

[Gary M. Witscher]

-- 
You go slow, be gentle.  It's no one-way street -- you know how you
feel and that's all.  It's how the girl feels too.  Don't press.  If
the girl feels anything for you at all, you'll know.
-- Kirk, "Charlie X", stardate 1535.8


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

RFS: Python-MySQL Web Client

[Gary M. Witscher]

Hi:

I'm looking for a sponsor for a new package, webQuery.
I'd appreciate any and all feedback. I've posted this RFS on
debian-mentors several times without response. If posting it here is NOT
an acceptable alternative please let me know and I won't bother this
list again.

Test drive it at: http://www.webquery.org/

('guest' user does not require a password. It's a slow server, just a
DSL connection, so please be patient.)

 webQuery is a collection of python cgi scripts that can access
 MySQL databases. These scripts will allow viewing, searching 
 and editing of tables. If tables are configured IAW certain
 rules table relationships are supported in such a way that 
 linking of tables is automated and a table hierarchy is emulated.
 .
 Features include: Combining fields for reports, exporting reports,
 report sorting, fulltext searching, creating and editing records, 
 multiuser tracking, multi language configurable, simplified privileges,
 saved queries, query picklists, navagation bar.
 .
 It's been tested and found to work on Mac OSX, Win98, and Debian Linux,
but should work on any system configured to execute cgi's (cookie
support is required).

Packages can be found at:
http://mentors.debian.net/debian/pool/main/w/webquery/

or at: http://www.webquery.org/debian/


Thanks,
Gary

Re: [Distutils] formencode as .egg in Debian ??

[M.-A. Lemburg]

Phillip J. Eby wrote:
> At 01:04 AM 11/22/2005 -0600, Bob Tanner wrote:
> 
>>On Tuesday 22 November 2005 12:15 am, Martin v. Löwis wrote:
>>
>>>I don't think Debian should use the egg structure. It apparently relies
>>>on building a long sys.path (even though through only a single .pth
>>>file);
>>
>>I'm not sure of how .eggs are implemented, but I'm going to cross-post this
>>info to the python-distutils mailing list. See below for additional comments.
>>
>>
>>>this adds additional costs to all import statements on startup.
>>>It gets worse if these are zipfiles, because then each import statement
>>>will have to look into each zipfile (until the import is resolved).
>>
>>The is the opposite of what I was told  by upstream development over on
>>distutils, snippet from Phillip J. Eby <[EMAIL PROTECTED]>:
>>
>>
>>Note also that in many cases, the package will be a single .egg file,
>>(analagous to a Java .jar file) rather than a directory, and files are
>>preferable to directories in most cases as they make Python import
>>processing faster.
>>
> 
> 
> Yes, it's true, zipfile import processing is faster than normal import 
> processing; 

Only after *all* ZIP files on sys.path have been scanned
for their contents. The more you add to sys.path, the longer
Python takes to startup.

What's worse is that the slow-down affects the whole Python
installation - each and every application using Python will
have to scan all these ZIP files in case it tries to import
a non-existing module or one which it finds late on sys.path.

> it is in fact one of the reasons zipfile imports were added to 
> Python, because the zip directories are cached.  A zipfile import lookup is 
> a single dictionary lookup, whereas a directory import lookup requires 
> multiple stat() calls.  For all practical purposes, zipfiles added to 
> sys.path are free after the initial directory read operation.

They are "free" for long running applications only where
this caching makes sense.

> Note that the need for a .pth is a limitation caused by the requirement to 
> have packages importable at startup.  Packages installed in "multi-version" 
> or "deactivated" mode are only added to sys.path upon request and have no 
> impact on startup time.  Relatively few eggs *need* to be installed with a 
> .pth file; we are simply in a transitional period where people still expect 
> "installed" packages to be importable without an additional require() 
> operation.
> 
> Finally, I think it's important to note that what Debian should or should 
> not use isn't really relevant to Debian's users, who will quite simply need 
> eggs for many packages.  If Debian doesn't provide them, the users will be 
> forced to obtain them elsewhere.  Over time, the number of packages that 
> users need in egg form will continue to increase, and there will be an 
> increasing number of users wanting to know why Debian can't provide 
> them.  It's perfectly reasonable not to redo existing Debian packages to 
> use eggs, but for some packages, *not* using eggs is simply not an option.

Why should "eggs" be the only way to install a package ?

Doesn't the standard "python setup.py install" work with
eggified packages anymore (meaning that the package is
installed as normal site-packages package) ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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

Re: [Distutils] formencode as .egg in Debian ??

[M.-A. Lemburg]

Ian Bicking wrote:
> M.-A. Lemburg wrote:
> 
>>> Finally, I think it's important to note that what Debian should or
>>> should not use isn't really relevant to Debian's users, who will
>>> quite simply need eggs for many packages.  If Debian doesn't provide
>>> them, the users will be forced to obtain them elsewhere.  Over time,
>>> the number of packages that users need in egg form will continue to
>>> increase, and there will be an increasing number of users wanting to
>>> know why Debian can't provide them.  It's perfectly reasonable not to
>>> redo existing Debian packages to use eggs, but for some packages,
>>> *not* using eggs is simply not an option.
>>
>>
>>
>> Why should "eggs" be the only way to install a package ?
>>
>> Doesn't the standard "python setup.py install" work with
>> eggified packages anymore (meaning that the package is
>> installed as normal site-packages package) ?
> 
> 
> Eggs give room for package metadata that doesn't exist otherwise.
> Putting dependencies aside, this is functionality that simply doesn't
> exist with the standard distutils installation.  In the case of
> FormEncode, it doesn't make use of any egg features (except that other
> packages may want to depend on it using setuptools).  In the case of
> other frameworks -- including TurboGears (which I think is the ultimate
> packaging goal here) -- the Egg metadata really is important, it's not
> just used for dependencies.

Understood, but wouldn't it be reasonably possible to
also install this meta-data into a standard site-packages
package directory ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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

Re: [Distutils] formencode as .egg in Debian ??

[M.-A. Lemburg]

Ian Bicking wrote:
> M.-A. Lemburg wrote:
> 
>>> Eggs give room for package metadata that doesn't exist otherwise.
>>> Putting dependencies aside, this is functionality that simply doesn't
>>> exist with the standard distutils installation.  In the case of
>>> FormEncode, it doesn't make use of any egg features (except that other
>>> packages may want to depend on it using setuptools).  In the case of
>>> other frameworks -- including TurboGears (which I think is the ultimate
>>> packaging goal here) -- the Egg metadata really is important, it's not
>>> just used for dependencies.
>>
>>
>>
>> Understood, but wouldn't it be reasonably possible to
>> also install this meta-data into a standard site-packages
>> package directory ?
> 
> 
> An egg and Python packages don't map 1-to-1.  An egg can contain
> multiple packages (which is fairly uncommon so far), but also a
> top-level package can exist in more than one egg (i.e., namespace
> packages, like zope.interfaces or paste.script).  The metadata belongs
> to the egg, not to the package inside the egg.
> 
> Also, some of the metadata is encoded in the directory name itself, like
> the version information.  I think this makes it easier to do some
> scanning operations, without a single database of installed packages
> (and also respecting sys.path manipulation).

Well, yes, but all of this is only needed for the egg support.

In order to keep compatibilty with the existing wide-spread
approach to install packages in site-packages/ using "python setup.py
install", it should be possible (and I believe this should be the
default to not disrupt existing usage and documentation) to
run "python setup.py install" with an eggified source
distribution in addition to the command to install it as
regular egg.

Otherwise, we'll end up with completely confused users
and two disjoint and incompatible installations mechanisms.

> That said, I think it would be nice if the transition was smoother.
> E.g., if a file "ElementTree-1.2.6.egg-provided" could point to an
> installed elementtree library (similar to the currently-supported
> .egg-link file, but also slightly different).  And, perhaps,
> elementtree/ElementTree.egg-info could exist (with the same data as the
> current ElementTree-1.2.6/EGG-INFO), though I think the simpler case
> where extra metadata is disallowed would be easier.  That would only
> work for situations when there's a 1-to-1 mapping from packages to
> eggs/projects, but that covers many situations, especially cases where
> we're currently seeing conflicts.  You lose the ability to easily
> support multiple versions of a package with this, though that could
> probably be handled too.

I'm not suggesting to port over all the features you
get from using setuptools' eggs (even though I do believe
that you can go a long way using a special egg import
hook), but it should be possible to get a regular working
installation using "python setup.py install".

PS: I understand setuptools and eggs as feature set which
adds functionality to distutils, not as competitive
and disjoint all-in-one solution. The latter won't fly
well with installations that require native installers
to be used such as Debian's apt-get, rpm and all
the others.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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

Re: [Distutils] formencode as .egg in Debian ??

[M.-A. Lemburg]

Phillip J. Eby wrote:
> At 06:33 PM 11/22/2005 +0100, M.-A. Lemburg wrote:
> 
>>Phillip J. Eby wrote:
>>
>>>Yes, it's true, zipfile import processing is faster than normal import
>>>processing;
>>
>>Only after *all* ZIP files on sys.path have been scanned
>>for their contents. The more you add to sys.path, the longer
>>Python takes to startup.
> 
> 
> This is simply not true.  If you don't believe PEP 302 and site.py, measure 
> it for yourself.  The *only* addition to startup is the time to actually 
> read the .pth file and append the entries to the list.
> 
> 
>>What's worse is that the slow-down affects the whole Python
>>installation - each and every application using Python will
>>have to scan all these ZIP files in case it tries to import
>>a non-existing module or one which it finds late on sys.path.
> 
> 
> And how often do programs attempt to import non-existing modules along 
> performance critical paths?

Every single time you fire up Python and the user has not
installed a module called "sitecustomize" (which is deliberatly
not shipped with Python), Python will scan the complete sys.path
for this module... and that's just one example.

It is rather common in Python code to test for the availability
of a faster variant by trying an import (e.g. for XML parsers)
and then falling back to some slower emulations.

> Note by the way that "scan all these ZIP files" is a misleading term in any 
> case - the files are not "scanned".  They are opened, and a small amount of 
> data is read from the end of the file.  Nothing that I would consider 
> "scanning" is involved.

The data read from the end of the file is the directory
which is decoded using marshal functions. You normally
call this scanning data.

Like Martin said: you always have to read the whole ZIP
directory - even if you're just interested in a single
module with the file.

Actually loading the module then requires decompressing
the code which takes a whole lot longer than just reading
a file from the file system.

In summary, things get slower when importing from ZIP files;
it really only makes sense for applications that have a long
run time and where startup is not that important, e.g.
Zope et al.

The main argument for using ZIP imports is to easy
distribution of complete pure-Python packages, not
a performance gain. You'd use one of the freeze tools
for that, e.g. mxCGIPython which creates a single
file Python interpreter which has a really good
startup time due to the fact that the Python lib
is embedded into the Python executable as static data
and then loaded on demand by the OS as needed.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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

Re: [Distutils] Egg support for system packages (including bdist_wininst)

[M.-A. Lemburg]

Phillip J. Eby wrote:
> Setuptools in SVN now provides preliminary support for installing eggs in 
> .egg-info directory style, so that setuptools-based projects can be wrapped 
> by system packagers who wish to avoid using .egg files or directories.  In 
> addition, you can now use setuptools to install non-setuptools packages in 
> such a way that an .egg-info directory is included, so that 
> setuptools-based packages can detect the presence of the 
> non-setuptools-based package.

Thanks for adding this.

I'd just wish that this would be the default and the .egg ZIP
file installation approach be made an option.

setuptools would then finally be compatible to the rest of the
distutils world again and avoid all the added overhead and
problems of ZIP file imports.

Perhaps you could have two commands, e.g. the default install
would create the normal package directory (with added .egg-info
dir) and a new install_eggfile to install the .egg ZIP file
instead.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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

Re: [Distutils] Egg support for system packages (including bdist_wininst)

[M.-A. Lemburg]

M.-A. Lemburg wrote:
> Phillip J. Eby wrote:
>> Setuptools in SVN now provides preliminary support for installing eggs in 
>> .egg-info directory style, so that setuptools-based projects can be wrapped 
>> by system packagers who wish to avoid using .egg files or directories.  In 
>> addition, you can now use setuptools to install non-setuptools packages in 
>> such a way that an .egg-info directory is included, so that 
>> setuptools-based packages can detect the presence of the 
>> non-setuptools-based package.
> 
> Thanks for adding this.
> 
> I'd just wish that this would be the default and the .egg ZIP
> file installation approach be made an option.
> 
> setuptools would then finally be compatible to the rest of the
> distutils world again and avoid all the added overhead and
> problems of ZIP file imports.
> 
> Perhaps you could have two commands, e.g. the default install
> would create the normal package directory (with added .egg-info
> dir) and a new install_eggfile to install the .egg ZIP file
> instead.

Somewhat related to this: wouldn't it be possible to build
.egg ZIP files using the same layout, ie. with the .egg-info
subdir inside the package instead of having a top-level
EGG-INFO directory in the ZIP file ?!

That way, you could simply unzip the .egg file somewhere
on your PYTHONPATH in order to install it and still have
the meta information at hand.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 22 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 


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