Re: Bug#178373: debconf: severity critical
Bernhard Kuemel wrote: > apt-get dist-upgrade now won't install even a single package. At first I > chose severity normal because mailman depends on debconf, but now > totally unrelated packages don't get installed. Unfortunately it seems > reportbug won't set the severity of this bug to critical but I was asked > if this bug is already listed and enter it's number. Should I have filed > a new bug report? It should not be severity critical anyway, packages break in unstable from time to time and there are workarounds to upgrade everything else. Anyway. > s:~# apt-get dist-upgrade > Reading Package Lists... Done > Building Dependency Tree... Done > Calculating Upgrade... Done > The following NEW packages will be installed: > libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl > libmailtools-perl libmime-base64-perl liburi-perl libwww-perl > 87 packages upgraded, 7 newly installed, 0 to remove and 0 not > upgraded. > 2 packages not fully installed or removed. > Need to get 0B/60.6MB of archives. After unpacking 8738kB will be used. > Do you want to continue? [Y/n] > Preconfiguring packages ... > Setting up debconf (1.2.21) ... > option -q not recognized > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp] What version of python2.2 do you have installed? What does it say when you run -- sh -ex /var/lib/dpkg/info/debconf.postinst configure 1.2.21 I was told by some python people that I could use -q after compileall to shut it up, if that no longer works it is porbably a bug in python or possibly debhelper, not debconf. -- see shy jo
Re: Bug#178373: debconf: severity critical
Le jeu 30/01/2003 à 19:44, Joey Hess a écrit : > > Setting up debconf (1.2.21) ... > > option -q not recognized > > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp] > > What version of python2.2 do you have installed? > What does it say when you run -- > > sh -ex /var/lib/dpkg/info/debconf.postinst configure 1.2.21 > > I was told by some python people that I could use -q after compileall to > shut it up, if that no longer works it is porbably a bug in python or > possibly debhelper, not debconf. Your python installation is screwed. The compileall.py module in Debian does support -q in all versions. It's not possible to be mistaken about that, as the error message included in Debian's compileall.py is not exactly this one. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Bug#178373: debconf: severity critical
Josselin Mouette wrote: > > Le jeu 30/01/2003 à 19:44, Joey Hess a écrit : > > > Setting up debconf (1.2.21) ... > > > option -q not recognized > > > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp] > > > > What version of python2.2 do you have installed? > > What does it say when you run -- > > > > sh -ex /var/lib/dpkg/info/debconf.postinst configure 1.2.21 > > > > I was told by some python people that I could use -q after compileall to > > shut it up, if that no longer works it is porbably a bug in python or > > possibly debhelper, not debconf. > > Your python installation is screwed. The compileall.py module in Debian > does support -q in all versions. It's not possible to be mistaken about > that, as the error message included in Debian's compileall.py is not > exactly this one. Thank you very much. I had python 2.1 installed and with 2.2 the problem disappeared. Seems python2.2 should be a dependency for debconf and mailman. There is, however, a new error message in the mailman configuration but I'll file that as a new bug: s:~# apt-get dist-upgrade Reading Package Lists... Done Building Dependency Tree... Done Calculating Upgrade... Done 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 packages not fully installed or removed. Need to get 0B of archives. After unpacking 0B will be used. Do you want to continue? [Y/n] Setting up mailman (2.0.13-2) ... Traceback (most recent call last): File "/usr/lib/mailman/bin/update", line 31, in ? from Mailman import Utils File "/var/lib/mailman/Mailman/Utils.py", line 32, in ? import random File "/usr/local/lib/python2.2/random.py", line 76, in ? from math import log as _log, exp as _exp, pi as _pi, e as _e ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined symbol: PyFPE_jbuf dpkg: error processing mailman (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: mailman E: Sub-process /usr/bin/dpkg returned an error code (1) Bernhard
Re: Bug#178373: debconf: severity critical
Le jeu 30/01/2003 à 22:42, Bernhard Kuemel a écrit : > Thank you very much. I had python 2.1 installed and with 2.2 the > problem disappeared. Seems python2.2 should be a dependency for > debconf and mailman. > Traceback (most recent call last): > File "/usr/lib/mailman/bin/update", line 31, in ? > from Mailman import Utils > File "/var/lib/mailman/Mailman/Utils.py", line 32, in ? > import random > File "/usr/local/lib/python2.2/random.py", line 76, in ? > from math import log as _log, exp as _exp, pi as _pi, e as _e > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined > symbol: PyFPE_jbuf The issue isn't in mailman. You have some python2.2 binaries in your /usr/local tree, that's why some things started to fail at the very beginning. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Bug#178373: debconf: severity critical
Josselin Mouette wrote: > [unable to configure mailman] > > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined > > > symbol: PyFPE_jbuf > > The issue isn't in mailman. You have some python2.2 binaries in your > /usr/local tree, that's why some things started to fail at the very > beginning. Thanks again! Obviously a former flat mate had installed a non debian version of python2.2. After removing it these bugs are gone, too. Bernhard
Re: Bug#178373: debconf: severity critical
On Thu, Jan 30, 2003 at 10:42:11PM +0100, Bernhard Kuemel wrote: > Josselin Mouette wrote: > > Le jeu 30/01/2003 à 19:44, Joey Hess a écrit : > > > > Setting up debconf (1.2.21) ... > > > > option -q not recognized > > > > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp] > > > > > > What version of python2.2 do you have installed? > > > What does it say when you run -- > > > > > > sh -ex /var/lib/dpkg/info/debconf.postinst configure 1.2.21 > > > > > > I was told by some python people that I could use -q after compileall to > > > shut it up, if that no longer works it is porbably a bug in python or > > > possibly debhelper, not debconf. > > > > Your python installation is screwed. The compileall.py module in Debian > > does support -q in all versions. It's not possible to be mistaken about > > that, as the error message included in Debian's compileall.py is not > > exactly this one. > Thank you very much. I had python 2.1 installed and with 2.2 the > problem disappeared. Seems python2.2 should be a dependency for > debconf and mailman. > There is, however, a new error message in the mailman configuration > but I'll file that as a new bug: > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined > symbol: PyFPE_jbuf Also not a Mailman bug, and certainly not a python2.2-in-debian bug either. Look at the path: /usr/local. Nothing in Debian installs things in /usr/local. You installed Python in the non-debian way, and it's interfering with your debian-installed python software. Remove it, and software will be happy again. This is the same reason the compileall -q wasn't working. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: Bug#178373: debconf: severity critical
On Fri, 2003-01-31 at 09:59, Josselin Mouette wrote: > Le jeu 30/01/2003 à 22:42, Bernhard Kuemel a écrit : [...] > > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined > > > symbol: PyFPE_jbuf > > The issue isn't in mailman. You have some python2.2 binaries in your > /usr/local tree, that's why some things started to fail at the very > beginning. How is it that the /usr/local/ modules were even being imported? I thought there was a big discussion about using "#!/usr/bin/python" instead of "#!/usr/bin/env python" to avoid exactly this problem. If Mailman or debconf or whatever is running python scripts with "#!/usr/bin/env python" then this is arguably a minor bug that should be reported against it. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Mentor needed for python-opengl2
On Thu, Jan 23, 2003 at 05:23:17PM +0100, Thomas Wouters wrote: > Hi, my name is Thomas Wouters and I'm looking for a mentor. :) > The PyOpenGL debian package, python-opengl, is heavily outdated, being > version 1.5.7 whereas the upstream stable version is 2.0.0.44 by now. It > also has some other issues, like being built against the wrong version of > Tk. PyOpenGL 2.0 is a not-quite-compatible release though, being one of > those 'rewrite' major changes. It does improve greatly on the Python OpenGL > bindings, and fixes a bunch of bugs. Python-opengl's maintainer, Enrique > Zanardi (see Cc), doesn't have the time or inclination anymore to maintain > the package, as he explained in a seperate email to me, and offered I adopt > the package or build new binary packages. In either case, I'm in need of a > mentor. > I've debianized PyOpenGL 2.0.0.44 based on how python-opengl 1.5.7 does it, [...] I subsequently re-did the debianization the Proper way, yielding separate packages for each of the available Python versions. I also split off the Togl part (Tkinter bindings for OpenGL) into seperate packages so python-opengl2 doesn't depend on python-tk. Unfortunately, because python2.1-tk is built against a different tk (8.3, rather than 8.4) I can't build python2.1-togl from the same source package. Not too big a deal, I think. The licensing is still a bit vague. One of the licenses that covers it is the SGI Free Software License B, which is only available in PostScript or MS Word format. I converted it to text for the copyright file for reference, and included the original postscript. I've also emailed about the legality and DSFG-compliance of that conversion, the SGI license and the other licenses to debian-legal, but haven't heard back yet. Another problem I had was with lintian: E: python2.3-togl: python-script-but-no-python-dep ./usr/lib/python2.3/site-packages/OpenGL/Tk/__init__.py E: python2.2-togl: python-script-but-no-python-dep ./usr/lib/python2.2/site-packages/OpenGL/Tk/__init__.py Both packages only depend on python2.x, as they should be installable even if the 'python' package is of a different version. Yet lintian does not complain about the python2.x-opengl packages ? I'm confused. Lintian gives no other errors, however. The end result is this list (I should probably change the short descriptions a bit :-) python-opengl2 - Python binding to OpenGL python-togl - Python binding to OpenGL python2.1-opengl2 - Python binding to OpenGL python2.2-opengl2 - Python binding to OpenGL python2.2-togl - Python binding to OpenGL python2.3-opengl2 - Python binding to OpenGL python2.3-togl - Python binding to OpenGL The packages can be had from here: deb http://www.xs4all.nl/~thomas/debian ./ deb-src http://www.xs4all.nl/~thomas/debian ./ Testing and bugreports would of course be appreciated, especially with different GL libraries (Mesa, nVidia, utah ?) There are some demo scripts in the doc/examples/ directories of both the opengl and the togl packages, but they aren't very good quality. I also have a simple python script that uses GL, GLU and GLUT from the python-opengl2 package, as well as python-numeric, that might be more obvious to test with: http://www.xs4all.nl/~thomas/torus.py It has a solid torus orbited by three suns of different sizes and colours. The largest, white sun is actually a spotlight aiming slightly off-center of the torus. Depending on your GLUT library, the edges of the spotlight on the torus will seem 'blocky'; this is 'correct'. The suns start rotating when you press the left mousebutton (in the window.) Holding down the left button and dragging the mouse rotates your point of view. Pressing escape exits. It doesn't do much beyond that. It's an heavily-added-on example from the OpenGL Programming Guide, please don't judge my Python programming abilities from this script :) I would still very much appreciate a mentor or sponsor (or advocate ;) for these packages. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! pgpL7LrKj6AxR.pgp Description: PGP signature
