Maitland Bottoms writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a start on packaging The Visualization Toolkit, as described
at http://www.kitware.com/vtk.html
Interested persons may see my preliminary efforts at
http://master.debian.org/~bottoms/debs/
Florian Weimer writes:
This is probably correct, but it is completely irrelevant in our case.
Some parts of Python 2.1 are still covered by the GPL-incompatible
CNRI license, so Python 2.1 as a whole is not GPL compatible.
which parts exactly?
Gregor Hoffleit writes:
I have uploaded experimental Python 2.1 packages. Grab them at
http://people.debian.org/~flight/python2/
thanks!
Now the problems start if neither 2.0.1 nor 2.1.1 would be ready in time. If
it's obious early that the won't be ready in time, we could start
Sean 'Shaleh' Perry writes:
I have filed an ITP for pyAda which is an Ada wrapper to allow Python to be
embedded and extended with Ada. Since pyada contains no python code I was
going to name the package pyada instead of python-pyada, or am I wrong
about the usage of 'python-' in a
Looking at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/LICENSE?only_with_tag=release21-maint
you see that the changed license is in the python-2.1 maintanance
branch as well. What about python packages based on this branch? I has
the advantage of a recent version which
In http://master.debian.org/~doko/python you find another set of
experimental packages for python. These packages are derived of the
packages from Gregor Hoffleit at http://people.debian.org/~flight.
Major changes are:
- converted python1.5-doc package
- new python2.1-doc package
- add missing
Donovan Baarda writes:
Some other questions;
what happens with other packages that might/might not have installed
stuff into /usr/lib/python1.5? Will they break?
No. However the priority of the python alternative from 1.5 should
greater than the prio of the pyton from 2.x (at least for some
Bastian Kleineidam writes:
Jérôme Marant wrote:
I said previously that the upgrade when OK. This is true, but I hadn't
look
further at that moment.
My upgrade had some errors:
No errors. The postinst just compiled the testsuite. Btw, do we really
need the testsuite as a
Ron writes:
On Tue, Oct 16, 2001 at 11:39:38AM +0200, Tille, Andreas wrote:
If you think that two separate wxgtk
versions are really necessary please speak now because Ron is preparing
packages for a new version.
Just to be completely clear about this, I almost certainly will
not
May I suggest a simpler alternative for (b) (or maybe an alternative c):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
Python Policy
Neil Schemenauer [EMAIL PROTECTED]
Matthias Klose [EMAIL PROTECTED]
version 0.3
Carey Evans writes:
Matthias Klose [EMAIL PROTECTED] writes:
[...]
2.4. Dependencies
-
Packaged modules must depend on `python-base ( X.Y)' and
`python-base ( X2.Y2)'.
(= X.Y), right?
Shouldn't this explain just what X2.Y2 is? I assume it's
Donovan Baarda writes:
On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote:
Matthias Klose [EMAIL PROTECTED] writes:
[...]
exactly. But you see that these packages will break when you try to
upgrade. We can't make 2.1 the default right now, because we will
_silently_
['iceme']
Ron Lee ron at debian.org ['libwxgtk2.2-python']
Danie Roux droux at tuks.co.za ['garchiver']
Matthias Klose doko at debian.org ['python-numeric',
'python-numeric-tutorial', 'python-distutils']
Roland Mas lolando at debian.org ['python-orbit-dev', 'python-orbit']
Joe Reinhardt jmr at debian.org
Donovan Baarda writes:
Good point... I'd forgotten about that. This means we might as well go
strait to python2.1 as the default, but make sure that the python2.1-xxx
packages have versioned conflicts with all the packages that depend on just
python or python-base and install into
Anthony Towns writes:
On Tue, Oct 23, 2001 at 06:13:31PM +0200, Gregor Hoffleit wrote:
Regarding (1): If you ask me how common the situation is that people
install local Python versions in /usr/local, then I will ask you how
common it is that it's reasonable that a script provided by
Jérôme Marant writes:
Gregor Hoffleit [EMAIL PROTECTED] writes:
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python/. The version is still a little
bit rough and sometimes incomplete, but it already gives a good outline
of the Python packaging
Joel Rosdahl writes:
Matthias Klose [EMAIL PROTECTED] writes:
It let's a package depend on:
python (= 2.1), python ( 2.2), python-foo
and can expect a working default Python version, which has support for
python-foo.
You mean
python, python-foo
I presume?
You may
Chris Lawrence writes:
- I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
name... maybe /usr/share/python/site-packages instead. (After all,
the things should be arch independent.) I'd be happy to code up the
symlink thingamajig for 2.1.2.2 if nobody's working on it.
See
Jérôme Marant writes:
Matthias Klose [EMAIL PROTECTED] writes:
2.1.1 Support Only The Default Version
+ does this Depends: python (= X.Y), python ( X.Y+1) really
work since versioned provides do not exist yet? Isn't it
python-base rather than python ?
yes. python
together with the new Python packages.
We hope to make a smooth upgrade from 1.5 to 2.1 and provide a current
Python version with bells, whistles and packages for woody.
Matthias Klose (and Gregor Hoffleit).
Carey Evans writes:
From Appendix B.2:
The new packages will conflict with every Python dependent
package, that does depend on `python', `python-base', without
depending on `python ( 1.6)' or `python-base ( 2.1)'.
Since the new packages conflict with python-base
Jérôme Marant writes:
Matthias Klose [EMAIL PROTECTED] writes:
But I don't want all my python packages to be uninstalled because
python changed. This is unacceptable.
So you simply set the new python packages on hold, until all packages
you need are converted. What's wrong
Federico Di Gregorio writes:
On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote:
Questions:
1. Does anyone need Python 1.5 versions of these packages?
Packages I have found that are associated with some of the mx
packages are:
python-mysqldb (Suggests:
Baruch Even writes:
Hello,
I've noticed that python package conflicts with LyX, I've also seen the
discussion on the python policy but couldn't understand the exact
reasons for this action and how to solve it.
I'd appreciate some explanation, it is also a good idea to file bug
reports on
Joel Rosdahl writes:
5) Use date in version, i.e. 2.2.port.20011104 or similar. (Best
solution I can come up with.)
but use something like 2.2.0.port.011104, so you don't need an epoch
for the next official 2.2.1 version.
Dirk Eddelbuettel writes:
Ben == Ben Burton [EMAIL PROTECTED] writes:
Ben Package: wajig Version: N/A; reported 2001-11-09 Severity: serious
Ben
Ben Hi. Package wajig cannot be installed because it depends on the
Ben non-existant python-base. Python packages have recently been
It looks like the move to python (v2.1) is done. There are three
packages remaining:
- pydb: http://bugs.debian.org/119203
Not yet ported to 2.1, but we do have an alterbate debugger
available (idle).
- python-pam: http://bugs.debian.org/119213
See
dman writes:
On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
| It looks like the move to python (v2.1) is done. There are three
| packages remaining:
Also gadfly depends on 1.5. Unfortunately it appears stagnant
upstream (last release in '98). The testsuite passes for 2.1
Mikhail Sobolev writes:
On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
- python-pam: http://bugs.debian.org/119213
See http://ftp-master.debian.org/~doko/python for a try.
However I couldn't get it reliably working ...
Could you please give more details
Anthony Towns writes:
On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
If I don't hear a serious reason to keep python1.5, I plan to file a
bug report for ftp.debian.org to remove the python1.5 package.
Eh?
python1.5's still useful to users, isn't it, especially ones
Donovan Baarda writes:
On Mon, Dec 10, 2001 at 11:53:24AM +1000, Anthony Towns wrote:
On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
If I don't hear a serious reason to keep python1.5, I plan to file a
bug report for ftp.debian.org to remove the python1.5 package.
Eh
Kim Oldfield writes:
On 10 Dec 2001, Matthias Klose typed:
] Anthony Towns writes:
] Dropping python1.5 doesn't seem a particularly clever thing to do.
] If we don't have any python1.5 dependencies, why not?
Because users will have no way of having both 1.5 and 2.1 on the same
machine
hmm, then we have to keep zope 2.1 as well (the version from
potato). Why do you want to keep 2.3, not 2.2? Why not 2.5? IMO If you
have a mission critical application, which is incompatible among zope
versions, then you should install your own zope. Am I wrong here?
Jim Penny writes:
I have a
Gregor Hoffleit writes:
On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote:
I agree, but... why not wait until python 2.1.1 is released?
(or, if we just discuss things a bit, it will be
released before any action is taken and we can jump right
to it :-))
sure, the
As David Maslen pointed out in
http://lists.debian.org/debian-python/2001/debian-python-200109/msg0.html
Debian doesn't have yet python-2.1 in it's distro, although released
in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0
maintainer) has put experimental packages at
ok, I'm giving up, just wanted to finish the python transition. please
could somebody look at #128349?
Torsten Landschoff writes:
On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote:
I have untested scripts python.postinst and python.prerm for this.
If you ask me, scripts for that should go into the python package so
that not every python-xxx package has to carry them itself.
Matt Zimmerman writes:
On Sun, Jan 13, 2002 at 10:00:23PM +0100, Matthias Klose wrote:
- wajig uses /usr/bin/python as interpreter and therefore should
depend on python (= 2.1), python ( 2.2). Same for the build
dependency.
Why is python ( 2.2) necessary? apt-listchanges
reopen 128531
thanks
From: [EMAIL PROTECTED] (Adam D. McKenna)
Changes:
tmda (0.46-1) unstable; urgency=low
.
* New upstream release
* Package split into 3 packages to help attempt to conform to Debian's
braindead Python policy. New packages are:
python-tmda (Python
Adam McKenna writes:
On Wed, Feb 20, 2002 at 12:55:59AM +0100, Matthias Klose wrote:
reopen 128531
thanks
From: [EMAIL PROTECTED] (Adam D. McKenna)
Changes:
tmda (0.46-1) unstable; urgency=low
.
* New upstream release
* Package split into 3 packages to help
Jérôme Marant writes:
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes:
we SHOULD be able to fix this ourselves, I just do not know enough about
distutils yet to tackle it.
I asked about this on the 4suite mailing list because I don't really
know what can be done with distutils (if ever
Bastian Kleineidam writes:
On Sun, Apr 28, 2002 at 04:30:49PM -0500, dman wrote:
I did a google search and a search using the engine on debian.org but
I can't find the Official Python Policy document anywhere. I did find
Neil's draft version 0.1 proposal with no trouble, but I'm looking
Moshe Zadka writes:
On Wed, 22 May 2002, Bastian Kleineidam [EMAIL PROTECTED] wrote:
On Wed, May 22, 2002 at 12:09:11PM -, Moshe Zadka wrote:
a) python2.1-foo: python foo.py module for 2.1
Depends: python2.1
b) python2.2-foo: python foo.py module for 2.2
Depends: python2.2
[forwarding to debian-python]
using distutils out of the box seems to be difficult, because many
upstream packages are broken down in several binary packages and
because distutils out of the box only builds for one python
version. Not sure which package to look at for a start ...
Tom Hall
Florent Rougon writes:
Bastian Kleineidam [EMAIL PROTECTED] wrote:
python2.1 (2.1.3-3) from sid
py2texi.el is a generated file
it is included in debian/patches/info-docs.dpatch
the fixinfo.el is replaced by it, fixinfo.el is not run.
OK, py2texi and fixinfo have nothing in common.
Federico Di Gregorio [EMAIL PROTECTED]:
Il gio, 2002-07-25 alle 16:04, Hugo van der Merwe ha scritto:
Sorry, I've not checked for existing threads on this topic... will Sarge
use Python2.2 by any chance? Once this is decided, the sooner it is made
official, the sooner packages will start
Jérôme Marant writes:
Bastian Kleineidam [EMAIL PROTECTED] writes:
Missing depends on libstdc++4:
Setting up python2.3 (2.2.90-1) ...
/usr/bin/python2.3: error while loading shared libraries:
libstdc++.so.4: cannot open shared object file: No such file or directory
It is strange
Jérôme Marant writes:
BTW, why is libstdc++ suddenly required? Are there some bits of C++
in the upcoming release of python?
the main program Modules/ccpython.cc is compiled with g++-3.1. No
other dependencies. hmm, I am sure, there was a bug report filed to
link against libstdc++...
Donovan Baarda writes:
On Fri, Aug 23, 2002 at 06:35:02PM +0200, Martin Sj?gren wrote:
fre 2002-08-23 klockan 18.28 skrev Jim Penny:
What packages do you have in mind? Some of the c-extension maintainers,
myself included, have an informal policy of support everything in the
Some comments:
- python-central should have a configuration option, how files are
compiled. Most users don't need compilation with -O. Maybe
a debconf option?
- A separate command to install a python version would be useful.
Assume I rename the packages again, or you want it to use for
Donovan Baarda writes:
On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote:
Some comments:
- python-central should have a configuration option, how files are
compiled. Most users don't need compilation with -O. Maybe
a debconf option?
Hmm, could be done I guess
Bastian Kleineidam writes:
On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote:
Some comments:
- python-central should have a configuration option, how files are
compiled. Most users don't need compilation with -O.
I will have commandline options for this, so the module
I'm preparing a NMU for python-happydoc for tonight. qm fails to
build, because python-happydoc isn't installable anymore.
Graham Wilson writes:
On Sun, Sep 01, 2002 at 09:08:36AM +0200, Tollef Fog Heen wrote:
Until dpkg supports triggers, I think what the emacsen does it the
most sane -- I'd be really, really happy if python modules/apps were
what do the emacsen do?
Don't know, maybe Tollef can explain?
Moshe Zadka writes:
I was wondering if you mind passing Python 1.5 maintainership to me.
I do not mind passing the maintainership, but I do mind keeping it in
unstable. Debian is not a museum for old python versions. What hinders
you to install the python1.5 packages from woody in unstable? apt
Neil Schemenauer writes:
Matthias Klose wrote:
Moshe Zadka writes:
I was wondering if you mind passing Python 1.5 maintainership to me.
I do not mind passing the maintainership, but I do mind keeping it in
unstable.
I don't think it is up to individual Debian developers to decide
The python default version changed to 2.2 in unstable. Your package
depends on
python (= 2.1), python ( 2.2)
which makes it uninstallable in unstable. Please either
- check that your packages works with python2.2 and change the
dependency to
python (= 2.2), python ( 2.3)
-
Hugo van der Merwe writes:
I was just about to post a big explanation...again, when I saw you had
figured it out :-)
Does anyone think the Python policy need a bit more explanation here? would
some use-cases help?
I think that would be a good idea, probably. To try to avoid having
Donovan Baarda writes:
I wouldn't call moving some files the packaging hell, and I have yet to
understand why /usr/lib/mailman is so much saner or better than
/usr/lib/python/site-packages/mailman.
I looked into the mailman package. It should not be that much work to
adapt it to the
=?iso-8859-15?B?Suly9G1l?= Marant writes:
On Thu, Oct 03, 2002 at 05:36:22PM +0200, Matthias Klose wrote:
Hi,
There are still about 20 packages not installable in sid due to the
change of the default python version. Asking for NMUs now, probably
for the next bug squashing party
Package: sqlrelay
Version: 1:0.32-1
Severity: grave
Original announcement at
http://lists.debian.org/debian-python/2002/debian-python-200209/msg00030.html
however I missed sqlrelay.
You need to keep the python2.1 package (zope uses python2.1). Please
build a python2.2-sqlrelay package as well
Evan Simpson writes:
I'm running into dependency clashes while trying to install wxPython,
and looking for help.
Since I am a Zope developer, and different versions of Zope rely on
different versions of Python, I need to have several versions of Python
installed. In fact, I have
Bastian Kleineidam writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just read this Post from Guido van Rossum[1] that the rexec.py and
Bastian.py modules have severe security flaws. These modules will be
disabled in the next 2.2 and 2.3 releases to avoid security risks.
[1]
Luca - De Whiskey's - De Vitis writes:
On Fri, Apr 18, 2003 at 10:02:39AM +0200, Tim Dijkstra wrote:
1) Should I ship .py or .pyc or both in the package. Byte-compile at
install time? Ask user what to do?
Ok, just saw a few other messages on this, my conclusion:
Byte-compile at install
Bastian Kleineidam writes:
On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote:
On Fri, 18 Apr 2003 11:22:11 +0200
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] wrote:
file:///usr/share/doc/python/python-policy.txt.gz (that is shipped
with the python package).
Maybe
Donovan Baarda writes:
On Fri, 2003-04-18 at 19:54, Matthias Klose wrote:
[...]
And/or take a look at dh_python, which does all this for free...
BTW, where can we find this? I'd like to take a look.
Included in debhelper.
As I am away the next two weeks, is somebody interested to make a
patch to build such a package from the python source?
Fabian Fagerholm writes:
Hi!
I've been working on packaging Albatross, a web application toolkit for
Python (see ITP: #193574). Albatross has very nice documentation that
Roland Stigge writes:
Hi,
why isn't there a default /usr/include/python (possibly accomplished as
a symlink in the package python-dev, like /usr/bin/python in the package
python)? (I'm sure there is a reason for that, I just didn't find it
documented somewhere.)
it's not needed. distutils
Ricardo Javier Cardenes Medina writes:
Of course, all this require manual handling from the user. What I was
proposing would require a whole PEP and some reasonable design and
implementation, etc, so Python itself could map those .pyc to their
original file, only resorting to them if the
If you use debhelper's dh_python, please make sure you use debhelper
(= 4.1.60), which will be in the archives tonight.
Matthias
This seems to be a common misunderstanding. Therefore the CC to
debian-python that I have something as a reference.
Lars Wirzenius writes:
On la, 2003-08-09 at 03:22, Matthias Klose wrote:
Please upgrade your packages soon, or ask on debian-python for NMU's or
help.
If the package doesn't
Lars Wirzenius writes:
Um, yeah, it does contain a .pyc. I don't think it should: the postinst
compiles the eoc.py file. The inclusion of the .pyc file seems like a
bug due to unforeseen interaction with the upstream Makefile's install
target. I'll have to remove the .pyc from the .deb in the
John Goerzen writes:
Hello,
Many Python programs use constructs like #!/usr/bin/env python2.3 to load
themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
these are the same.
The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
because he has his
Josselin Mouette writes:
I've put a summary of packages needing a rebuild in a world-writable
file at http://people.debian.org/~joss/python-list.txt
python-numarray-ext = updated but the new package misses python (= 2.3),
python ( 2.4)
unneeded, as it depends on python-numarray.
anyway,
Joss,
please could you update your transition summary (modulo the packages
already in queue/new) and file RC bugs on all python-* packages, which
cannot be installed. Many of these are needed as dependencies for
other packages. If this is done, we may start filing RC reports for
all other
The package doesn't seem to be maintained, there's no upstream source
given in the copyright file, the closest I could find is
http://pynms.sourceforge.net/
And the pstats module shadows a standard module of the same name.
Joss, you did the last NMU. Any opinions?
Matthias
Package: python-pmw
Just saw, that 0.8 is already 20 months old. Somebody volunteering to
package the current version?
Sebastien Bacher writes:
Hello,
The new pygtk 1.2 packages are available:
python-gtk-1.2
python-gnome-1.2
python-glade-1.2
python-gdk-imlib-1.2
Package which have some depends on old packages
(python-gtk/gnome/glade/gdk-imlib) have to update them.
Don't forget to check that py
On Thu, 3 Jul 2003 01:38:23 +0100 you wrote:
PyQt 3.7 is supposed to be released this weekend. Then I'll updated
fixed packages.
this seems to be a long weekend :-( in the meantime pyQt 3.8 was
released. would you mind fixing the FTBFS bug, or should the package
marked for removal from
Andreas Rottmann writes:
Hi!
I wonder how long source packages that build binary packages for
multiple versions (2.{1,2,3}) should continue to build packages for
the old Python versions. IMHO, this should be documented somewhere
(Policy?). Is there any timeline how long Python 2.2 and 2.1
Now that 2.6.2 is released:
- will you switch to python2.2 as the python interpreter used?
- or maybe will you wait for 2.7 to be released, which uses
python2.3?
please could somebody install this?
Thanks, Matthias
John Goerzen writes:
Hello,
I hope I am not alone in this.
I find the whole Python transition process to be rather confusing. For
instance, I recently received an e-mail asking me not to upload various
Python packages. A day later, one of them got NMU'd. I am confused; what
exactly is
John Goerzen writes:
On Tue, Oct 07, 2003 at 07:18:41PM +0200, Matthias Klose wrote:
The e-mail I sent made several exceptions from the freeze, one of them
fixing RC reports. So yes, you are supposed to fix these problems
yourself. As I introduced this RC in 0.5.1-5.1, I fixed it in
0.5.1
Ron writes:
Howdy,
Forgive my apparent ignorance here, but I'm a little confused if I read
Matthias' message correctly. I don't understand how uploading a new
libwxgtk2.4-python package (which build-deps on python2.3) might hold
up python from entering testing. Python doesn't depend on
Josselin Mouette writes:
Le ven 10/10/2003 =E0 14:02, Ron a =E9crit :
On Thu, Oct 09, 2003 at 08:03:32PM -0400, Derrick 'dman' Hudson wrote:
The libwxgtk2.4-python in testing depends on python (2.2).
=20
Ahh, ok. This is the piece of the vicious cycle I was overlooking.
=20
I've just
Colin Watson writes:
The only reason to put a version on a pythonX.Y dependency would be if
you know there was a particular version of pythonX.Y that your package
doesn't work with.
The versioned dependency is probably generated automatically by
dpkg-shlibdeps:
$ cat
Colin Watson writes:
On Tue, Oct 07, 2003 at 07:28:23PM +0200, Matthias Klose wrote:
Colin Watson writes:
For what it's worth, I think a python-defaults source package or some
such would help: at the moment there are several packages needlessly
stalled on python2.3, even though
Oliver Elphick writes:
I remember seeing a draft Python policy some time ago but it is not
linked from http://www.debian.org/devel/
see /usr/share/doc/python. It currently in a proposed state, I think
we won't submit it as formal policy for sarge.
The reason I am looking for it is that I need
Kenneth Pronovici writes:
Still need to be updated:
[...]
* python-epydoc: the default package doesn't depend on python
I did the last NMU for python-epydoc because Moshe seems to be missing
in action (?); I can probably fix this problem as well.
Just to make sure I understand, I
Terry Hancock writes:
On Monday 17 November 2003 09:22 am, Florent Rougon wrote:
Josselin Mouette [EMAIL PROTECTED] wrote:
Le dim 16/11/2003 à 11:34, Matthias Klose a écrit :
There is no reason why /usr/share/module should be disallowed.
That depends on whether .pyo files really
Junichi Uekawa writes:
Package: python2.3
Version: 2.3.2-3
python2.3 (2.3.2-3) unstable; urgency=low
* Downgrade the dependency of python2.3 on python (= 2.3) to
a recommendation.
this seems to have caused buildds to fail because 'python' does not
exist when building packages
Junichi Uekawa writes:
well, I think this is bug in these packages. OTOH, if there are too
many of these, it might be better to change it back. I did never see
much sense in keeping pythonX.Y without keeping python.
The configure script is checking for 'python' script.
What was the
Jan Hudec writes:
Package: python2.3
Version: 2.3.3-5
The default /etc/python2.3/site.py specifies ascii as a system
encoding. This causes errors if non-ascii characters are fed to
python programs unaware of i18n/l10n issues (eq. libglade-convert
script). Please make utf-8 (which is
Joey Hess writes:
Matthias Klose wrote:
to avoid side effects by a custom PYTHONPATH environment variable, see
the discussion on debian-python for the motivation.
Wouldn't setting such a variable come under the heading of using the
rope that unix gave you?
If I did this for python, I
Bartosz Fenski aka fEnIo writes:
Hello.
I'm trying to package imgSeek (image viewer and manager with content
based query), and I've got some questions.
First of all. This program contains some very small library in C++
which makes whole package architecture-dependent.
Is it suitable
Stefan Reichör writes:
Hi Marco!
Hallo pythoners,
ipython is an enhanced interactive shell for python.
It is in Debian, but with a version lower that the current stable
one (we have 0.4, while the upstream has released 0.5 time
ago..). Also a emacs mode for
Bruno Dusausoy writes:
Hi,
I'd like to package the python bindings of TagLib (1.2 first, 1.3 when
it will be released in Debian). This is my first attempt to make a
debian package.
It's pretty tiny (only 3 .i files, 1 .cxx file, the Makefile and the
resultings files : TagLib.py and
could you try rebuilding/reinstalling the libapache-mod-python package?
Jonas Meurer writes:
On 21/09/2004 Alexandre wrote:
On Tue, Sep 21, 2004 at 04:09:03PM +0200, Jonas Meurer wrote:
it's a problem with libapache-mod-python, it segfaults at using
MySQL-Python. see #270555 for more
1 - 100 of 381 matches
Mail list logo
