zip archive in python search path
Hi *,
Today I got the attached two mails. I wonder how this happens and how to
fix it. Is it correct that zip archives are supported in sys.path now?
In that case probably python-gtk needs fixing. Otherwise something in
python is wicked.
Greetings
Torsten
--- Begin Message ---
Don't know, might be a python problem:
LibGimp-WARNING **: gimp: wire_read: unexpected EOF
Traceback (most recent call last):
File "/usr/lib/gimp/1.2/plug-ins/foggify.py", line 3, in ?
from gimpfu import *
File "/usr/lib/python2.3/site-packages/gimpfu.py", line 48, in ?
pygtk.require('1.2')
File "/usr/lib/python2.3/site-packages/pygtk.py", line 47,
in require
versions = _get_available_versions()
File "/usr/lib/python2.3/site-packages/pygtk.py",
line 34, in _get_available_versions
for filename in os.listdir(dir):
OSError: [Errno 2] No such file or directory:
'/usr/lib/python23.zip'
^^^
gimp: 1.2.5-2
gimp-python: 1.2-6
python: 2.3-4
Any clue?
--
'(wave++ "Yuri D'Elia" "http://www.yuv.info/";)
--- End Message ---
--- Begin Message ---
On Wed, Sep 10, 2003 at 02:23:48PM +0200, Torsten Landschoff wrote:
> > Any clue?
>
> Looks like your python path is messed up for some reason. What does
>
> $ python
> >>> import sys
> >>> print sys.path
>
> say?
% python
Python 2.3+ (#2, Aug 10 2003, 11:33:47)
[GCC 3.3.1 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
['', '/usr/lib/python23.zip', '/usr/lib/python2.3',
'/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk',
'/usr/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages/HTMLgen',
'/usr/lib/python2.3/site-packages/Numeric',
'/usr/lib/python2.3/site-packages/PIL',
'/usr/lib/python2.3/site-packages/gtk-1.2']
--
'(wave++ "Yuri D'Elia" "http://www.yuv.info/";)
--- End Message ---
pgpatSv2QkNzT.pgp
Description: PGP signature
Re: python 2.2 -> python 2.3 transition
On Wed, Aug 13, 2003 at 08:33:26AM -0500, John Goerzen wrote: > Now, I could do the dependency on python (>= 2.2), python (<<2.3) thing. > But what would that gain me or users? I see no benefit there, other than > people tracking sid would find OfflineIMAP uninstallable until it gets > updated to depend on Python 2.3. > > There are plenty of OfflineIMAP users that don't use Python themselves, > don't care that it's written in Python -- and probably some that don't > *know* it's written in Python. > > (And yes, the bang path explicitly calls python2.2) The dependency on python (>= 2.2), python (<< 2.3) is for the case where you have a module which loads into python and supports only a single python version. After python changed you can't install that package (wxgtk-python or whatever) anymore. The positive effect for the users is that you can't upgrade python while wxgtk-python is installed so your system won't break. apt will only upgrade python after a new wxgtk-python is available. That's the benefit of this dependency scheme. Greetings Torsten pgpb1bxAjexkr.pgp Description: PGP signature
Re: Error building package (uses python)
Hi Brian,
On Tue, Apr 22, 2003 at 09:08:57AM -0400, [EMAIL PROTECTED] wrote:
> I have a package that I am getting ready for my sponsor to upload.
> I began getting these errors when I upgraded my python debs from stable to
> the unstable versions.
>
> checking for gtk.py... no
> configure: error:
> The python interpreter can't find the python bindings for gtk.
Hmpf. Reminds me of the odd situation of pygtk in Debian. Currently
the gtk 1.2 bindings are still the default. Probably that should be
fixed.
> Here is a list of the debs I have installed.
This throws up the question if you need the gtk 1.2 or 2.0 bindings
for that tool...
> Here is the build error I get.
> checking for gtk.py... no
> configure: error:
> The python interpreter can't find the python bindings for gtk.
Argh. Whoever wrote that script should be larted. Because the error
message does not match reality. In fact, configure.in does not ask the
python interpreter to find gtk.py:
dnl Check if python bindings for gtk are installed
AC_CHECK_PROG(have_pygtk, gtk.py, yes, no, $PYTHON_SITE_DIR)
if test "x$have_pygtk" != xyes
then
AC_MSG_ERROR([
The python interpreter can't find the python bindings for gtk.])
fi
Where does that call python? In fact, even $PYTHON_SITE_DIR does not
make much sense. In realitas python searches in a number of paths which
can be adjusted by throwing a file with extension .pth in there, like
python-gtk does:
[EMAIL PROTECTED]:~$ dpkg -L python-gtk|grep pygtk.pth
/usr/lib/python2.2/site-packages/pygtk.pth
[EMAIL PROTECTED]:~$ cat /usr/lib/python2.2/site-packages/pygtk.pth
gtk-1.2
This results in the following search list in python:
[EMAIL PROTECTED]:~$ python -c "import sys; print sys.path"
['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2',
'/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload',
'/usr/local/lib/python2.2/site-packages', '/usr/local/lib/site-python',
'/usr/lib/python2.2/site-packages',
'/usr/lib/python2.2/site-packages/Numeric',
'/usr/lib/python2.2/site-packages/PIL',
'/usr/lib/python2.2/site-packages/gtk-1.2', '/usr/lib/site-python']
This is what the script should check for. Or, just use python to figure
out the path:
code="
import sys
try:
import gtk
except ImportError:
sys.exit(1)
except:
sys.exit(0)
sys.exit(0)"
if $PYTHON -c "$code"; then
AC_MSG_RESULT(yes)
else
AC_MSG_ERROR("no gtk.py found")
fi
Something along the lines - did not write autoconf for a while...
Greetings
Torsten (python-gtk maintainer)
pgpNlfdTNKL54.pgp
Description: PGP signature
Re: bug reports preventing the python transition
On Sat, Apr 05, 2003 at 06:37:44PM +0200, Torsten Landschoff wrote: > > Torsten, Christian, this package is installable (again?). Tagged as > > fixed. > > It is in fact not installable in unstable because libpanel-applet0 is > no longer available. I'll fix this with a new upload today. Done, new packages in incoming. Greetings Torsten pgpP4peAZR2Nl.pgp Description: PGP signature
Re: bug reports preventing the python transition
On Sat, Apr 05, 2003 at 11:41:20AM +0200, Matthias Klose wrote: > Package: python-gnome (debian/main) > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]> > 183250 [ ] python-gnome: Package un-installable > > Torsten, Christian, this package is installable (again?). Tagged as > fixed. It is in fact not installable in unstable because libpanel-applet0 is no longer available. I'll fix this with a new upload today. Greetings Torsten pgpNNftMVcRmY.pgp Description: PGP signature
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 04:28:53PM -0400, Jim Penny wrote: > One final point. We will almost definitely not switch the default > python in sid (current unstable), until there is talk that Sarge is > nearing a freeze. There is simply no point in undergoing the pain of > a major python release twice in a single unstable cycle. We will > instead make the decision of what python will be default in Sarge > when it nears release, not now. That's silly. If we want to catch problems in all those python packages (which are for only the default python version often enough) then we should upgrade the default python version early and find those problems. Waiting for the freeze and then pulling 2.1 from under those python packages looks like a really bad idea to me. cu Torsten pgplBVNf8c29w.pgp Description: PGP signature
Re: slightly update python-gnome2 and python-gtk2 package
On Wed, Aug 07, 2002 at 01:22:59AM +0200, Torsten Landschoff wrote: > Most of it works, but the opengl stuff is not working (missing > python2.2-opengl, will NMU if time permits). Next step will be > getting python2.2-gnome2 working. Just built python2.2-gnome2 and uploaded to experimental. The changelog should speak for itself. I don't want to upload this to unstable while it is working fine so far. But I want to split up the package so that you can install python2.2-gnome2 without all of gnome2 ;) Thanks Torsten pgpYvBRVuF7ox.pgp Description: PGP signature
Re: python-gtk and python-gtk2 (and gnome packages), please comment
On Wed, Aug 07, 2002 at 11:09:33AM +0200, Florent Rougon wrote: > > that route. But - do we want to continue supporting the old gnome > > for sarge? Otherwise I would be for removing the old binding > > entirely before the next release. Just wondering if any dependent > > package will be updated for the new gnome. > > Of course I understand that the transition between python-gnome and > python-gnome2 is not an easy task, but Debian packages are probably not > the only thing to consider when it comes to removing the old binding. > People may have local apps that are not packaged and use the old > binding. However, they will presumably have time to speak up or port > their apps to gnome2 before sarge is released. Problem with this: No matter which python-gnome release shall be used the upstream will use "import gnome.ui". So which binding should he get? I am in favor of giving him the new bindings by default. If anybody really needs the old stuff again we can still put it into another directory and have python prepend it to the search path. Let's see if such a package is really needed. I won't have a problem with maintaining it but I rather spend the time on more important stuff... Thanks Torsten pgpBsnt972HZn.pgp Description: PGP signature
Re: python-gtk and python-gtk2 (and gnome packages), please comment
On Sat, Jun 22, 2002 at 12:07:19AM +0200, Tom Cato Amundsen wrote: > === > 3. > === > Quite messy, but... > Since python-gtk2 require python2.2 or later, we let python2.1-gtk > install as upstream does (in /usr/lib/python2.2/site-packages/) and > install python2.2-gtk in /usr/lib/python2.2/site-packages/gtk1.2/. And > python2.2-gtk2 can install as upstream does in > /usr/lib/python2.2/site-packages. That's probably the only way we can go. I don't expect that any upstream tool will user "import gtk2" or something as upstream kept the module name "gtk". So basically I think we don't have a choice. Of course if consensus is different from my opinion I'll go out of the way ;) Reading your mail for real again (it's late) you got a point. #2 would be the right thing to do (tm) I think. There is still time to go that route. But - do we want to continue supporting the old gnome for sarge? Otherwise I would be for removing the old binding entirely before the next release. Just wondering if any dependent package will be updated for the new gnome. cu Torsten pgpDSTRWGkP5b.pgp Description: PGP signature
Re: slightly update python-gnome2 and python-gtk2 package
On Mon, Jun 24, 2002 at 11:53:21PM +0200, Tom Cato Amundsen wrote: > I just uploaded a slightly updated python-gnome2 and python-gtk2 > packages to http://klecker.debian.org/~tca . They are apt-get'able > using: > > deb http://klecker.debian.org/~tca unstable main > deb-src http://klecker.debian.org/~tca unstable main Oops, did not stop by again. I finished python2.2-gtk2 today, or at least got something worth uploading to unstable. Most of it works, but the opengl stuff is not working (missing python2.2-opengl, will NMU if time permits). Next step will be getting python2.2-gnome2 working. Sorry for being stuck in real life ;) Torsten pgpzTSZGFb3y1.pgp Description: PGP signature
Re: python2.2 for sarge?
On Fri, Jul 26, 2002 at 08:40:02AM +0200, Martin Sjögren wrote: > > If people really need 2.2, then it doesn't need to be the default anyway... > > just use the python2.2- packages... > > Except that a lot of packages only exist as python. python-gtk and > pygame come to mind for example. Just uploaded python2.2-gtk2. I don't think I will beat the dead python-gtk to python2.2... cu Torsten pgpkrZ5Vnln5d.pgp Description: PGP signature
Re: python2.2 for sarge?
On Fri, Jul 26, 2002 at 12:40:36AM +0200, Federico Di Gregorio wrote: > > - remove python1.5 from unstable > > and all packages depending on it. right. Not a big deal, it seems. Just checked - all packages depending on python1.5 are available for python(2.1) already. Greetings Torsten pgpDGws2xvm0w.pgp Description: PGP signature
Re: python2.2 for sarge?
Hi Federico, On Fri, Jul 26, 2002 at 12:40:36AM +0200, Federico Di Gregorio wrote: > eheh. given that sarge won't be stable for another 12 months > (optimistically) 2.3 will have plenty of time to stabilize. Remembering what aj said I think it would be wise to expect a release at any time since we want to keep testing in releasable state. So perhaps we don't really want python2.3 beta in testing as default, do we? cu Torsten pgp4C8xjdK8mM.pgp Description: PGP signature
Re: python-gnome: float weirdness with gnome.ui is back
On Thu, Jan 17, 2002 at 10:11:11AM -0600, Chris Lawrence wrote: > I don't know what exactly is going on, but it's probably something in > python-gnome. I'm passing this along to its maintainer. > > (Torsten: I suspect the fix for #59713 got rolled back somewhere along > the line, or something similar is going on elsewhere in the code.) Maybe. I have to check... Time to add a regression test to the package. cu Torsten pgpvNgk4kqGNP.pgp Description: PGP signature
Re: pure python modules - Python Policy 2.2.3
On Sun, Jan 13, 2002 at 09:32:58PM +0100, Matthias Klose wrote: > > 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. Something > > like /usr/lib/python/new-module $(pkgname) should do all the > > preprocessing. > > the python package may not yet be configured, before a package uses > it for registration. If the package module package depends on python (as it has to anyway) dpkg will configure python before the module in any case (safe circular dependencies). So this is not an issue. Apart from that, it would suffice to drop the scripts into the filesystem. If a maintainer script of the module package can call /usr/bin/python .../compileall.py directly I see no reason why it should not be able to do this through a wrapper (which could even remember which source files are compiled so that python2.3 when available can automatically recompile all modules). Am I missing something? Torsten pgpzgUm7WEvSB.pgp Description: PGP signature
Re: pure python modules - Python Policy 2.2.3
On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote: > A pythonX.Y package must have > > 1) a postinst script to byte-compile all previously installed >packages who use dh_purepython > > 2) a prerm script to remove byte-compiled files from all previously >installed packages who use dh_purepyton > > 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. Something like /usr/lib/python/new-module $(pkgname) should do all the preprocessing. Gregor, what do you think: Is this doable/practical? cu Torsten pgpjYaNJGCoJY.pgp Description: PGP signature
Re: python policy is unclear on whether python programs should be arch all or arch any
On Sun, Jan 13, 2002 at 10:53:53AM +0900, Junichi Uekawa wrote: > During discussion in debian-devel, it was pointed out that > byte-compiled python code is cross-platform, and thus it should be > architecture: any. I think you mean arch: all. Any means a rebuild for each architecture. More interestingly the python policy should mention how to handle byte-compiled code. My packages are building them on installation and I think this is the way how it should be. I am not sure if the same .pyc file runs on all systems... Greetings Torsten pgpBoBWbxxENO.pgp Description: PGP signature
Re: report #128349
On Wed, Jan 09, 2002 at 07:45:01AM +0200, Danie Roux wrote: > On Wed, Jan 09, 2002 at 04:56:40AM +0100, Matthias Klose wrote: > > ok, I'm giving up, just wanted to finish the python transition. please > > could somebody look at #128349? > > Apologies for all your trouble. The University network has been down > since early December and I've been writing finals before that. I'll be > fixing all the bugs and uploading it ASAP. This seems to be a bug in the autobuilder environment. python-gtk checks if DISPLAY is set since the very first release. If it is not it does not try to open the DISPLAY. Seems like somebody injected his DISPLAY setting into the autobuilder environment and the DISPLAY is long gone now... I would try unsetting DISPLAY before running the configure script. Also this bug should be reassigned to build.debian.org or whatever the right package is. Greetings Torsten (python-gtk maintainer) pgpmql41PFHgM.pgp Description: PGP signature
Re: FYI: Mail to python package maintainers
On Sun, Oct 28, 2001 at 05:33:31PM +0100, Matthias Klose wrote: > Where do we head? We want to upload these new packages to unstable on > Tuesday (2001-10-30) or Wednesday (2001-10-31). Because most of the > python dependent packages in Debian have unversioned dependencies on > the python version, you will have to set the new python packages on > hold, until you have verified, that they work with the new python version. Sorry, but I can't understand this sentence. Which new packages will I need to set on hold? cu Torsten pgpAEi85Kypbk.pgp Description: PGP signature
Re: libglade -- absent!?
On Thu, Oct 25, 2001 at 12:06:46PM -0400, dman wrote: > Thanks! I was searching for "libglade". > > Hint to Torsten : put the word "libglade" in the Description: > somewhere to aid 'apt-cache search'. Done for the next release. cu Torsten pgp657nCfrHph.pgp Description: PGP signature
