handling packages built supporting the "current" python revision
Hi, I maintaint pyqonsole which has the following declarations in debian/control: Build-Depends: debhelper (>= 5.0.37.1), python-dev (>=2.3.5-7), python (>=2.3.5-7), python-central XS-Python-Version: current The current version in the archive is 0.2.0-2 which depends on python (>=2.3), python (<<2.4) (generated by dh_python). Am I expected to upload an unchanged 0.2.0-3 package so that it will get rebuilt with python2.4 as the default python version, or is something going to happen automatically, for instance a binary only NMU ? -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Bug#396394: python2.5: README.Debian provides incorrect information about distutils
Package: python2.5 Version: 2.5-3 Severity: minor Tags: patch In /usr/share/doc/python2.5/README.Debian, """ distutils can be found in the python2.5-dev package. Development files like the python library or Makefiles can be found in the python2.5-dev package in /usr/lib/python2.5/config. """ should be changed to something like """ distutils can be found in the python2.5 package. Development files like the python library or Makefiles can be found in the python2.5-dev package in /usr/lib/python2.5/config. Therefore, if you need to install a pure python extension, you only need python2.5. On the other hand, to install a C extension, you need python2.5-dev """ I am reporting this against the python2.5 package, but the README.Debian file should be fixed in python2.3 and python2.4 too, since the change occured a long time ago (nov 2004, from the changelog) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-amd64 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages python2.5 depends on: ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libdb4.4 4.4.20-8Berkeley v4.4 Database Libraries [ ii libncursesw5 5.5-4 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries ii libsqlite3-0 3.3.8-1 SQLite 3 shared library ii libssl0.9.8 0.9.8c-3SSL shared libraries ii mime-support 3.37-1 MIME files 'mime.types' & 'mailcap ii python2.5-minimal2.5-3 A minimal subset of the Python lan python2.5 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: detecting the right /usr/lib/python2.x in an upstream-compatible way
On Sun, Nov 26, 2006 at 02:31:06PM +0100, Thomas Viehmann wrote: > Hi, > > Matthias Klose filed a bug and patch against pyx because it had a > hardcoded /usr/lib/python2.3. Thanks! > The bugfix is to detect the python version and then use > /usr/lib/python$(PYTHON_VERSION). > While this is obviously correct for Debian, I'm wondering whether it > would be better to use something like > $(python -c "import os.path, site ; print os.path.dirname(site.__file__)") > in order be able to share with upstream who might want to cater for > local python installations (pyx upstream has "import site; print > site.here" in SVN but that doesn't work in python >= 2.4). import sys import os.path print os.path.join(sys.prefix, 'lib', 'python'+sys.version[:3]) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ signature.asc Description: Digital signature
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: > Hi, > > On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: > > I tried to do some development using Etch's python2.5, but it fails to > > import pygtk and gtk modules and this is a regression IIRC. v2.4 works > > fine. > > "pyversions --supported" only returns python2.4, so the source package > does not build the 2.5 flavor. Either patch pygtk's debian/rules or > patch pyversions and rebuild pygtk. Happy new year everyone. Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded "2.5" in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ signature.asc Description: Digital signature
Re: [Python-modules-team] Bug#543351: logilab.astng cannot be imported after upgrade from stable
On Thursday 03 September 2009 12:25:00 Sandro Tosi wrote: > Hi Chris, > thanks for your report. > > On Mon, Aug 24, 2009 at 14:43, Chris Lamb wrote: > > Package: python-logilab-astng > > Severity: serious > > Version: 0.19.0-2 > > ... > > > I can make it work by manually removing > > > > /usr/lib/python2.5/site-packages/logilab > > Since all the packages sharing logilab namespace have a new upstream > version to package, it's a good time to try to fix this on all of > them. > > The preinst file of logilab-astng is [1]: we already try to fix the > migration (central->support) problem but we don't remove to common > logilab/ directory. > > [1] > http://svn.debian.org/viewsvn/python-modules/packages/logilab-astng/trunk/d >ebian/python-logilab-astng.preinst?view=markup > > I'd like to know what would be the best solution for this (hence > -python in the loop): > > - logilab-common is the lower level of logilab* packages, so we can > add conflict there with all the other logilab-* packages and then > remove logilab/ completely from its preinst > - add extra logic to all logilab* packages to check if > /usr/lib/python*/site-packages/logilab is empty and then remove it > (could there be cases where it left hanging dirs?) > > I'm considering teh second solution a bit better, but I'd like to hear > from your what youi think. The problem I can see with removing blindly from the postinst is that potentially you're going to delete files belonging to other packages (e.g. older packages installed from Logilab's Debian repositories). Could the following work: logilab-common postinst removes /usr/lib/python*/site- packages/logilab/__init__.py*, and issues a warning if there are other stuff in the directory : this will stop packages installed under that tree from working without deleting the files themselves (enabling the administrator to find out what's broken with that installation). -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Intending to orphan python-psyco and python-psyco-doc
Hello, I've long stopped using psyco and don't have the time to give it proper care. Upstream (Armin Rigo) is no longer maintaining it, Christian Tismer has taken up the flag. The project is x86 only. Is there anyone wanting to take up that package ? http://packages.qa.debian.org/p/psyco.html http://packages.qa.debian.org/p/psyco-doc.html -- Alexandre Fayolle -- 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/201106201151.18160.afayo...@debian.org
Bug#639347: RFA: psyco -- Python specializing compiler
Package: wnpp Severity: normal I request an adopter for the psyco package, as I no longer use the package and cannot maintain it properly anymore. Due to lack of upstream support, maybe the package should be removed from Debian altogether, as supporting python >> 2.5 will require significant effort. Any feedback on this regard is welcome. The package description is: Psyco lets you run your existing Python software much faster, with no change in your source. . Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The result is that your unmodified Python programs run faster. . The plan for the next release is to include a fast low-level interpreter that can be used on non-Intel processors. It will finally make Psyco portable -- although of course not as fast as it could possibly be if it could emit real machine code. -- 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/20110826072922.4616.9944.reportbug@lacapelle
Documentation generation scripts
Hello, I'm working on the packaging of a python module (psyco). This module has some doc provided in Python's latex idiom, and therefore requires that the mkhowto script (provided in the Doc/tools/ directory of the python source distribution) be available. I've been unable to find a debian package providing these tools. Should I : * look better (any hint welcome) * file a bug report against the python packages, requesting a python-doc-tools package to be added to the debian archive * ship my own version of mkhowto in the package to build the documentation Any suggestion welcome. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: debian-python@lists.debian.org
On Fri, May 09, 2003 at 10:41:09AM -0400, Jim Penny wrote: > On Fri, May 09, 2003 at 10:26:57AM +0200, Alexandre Fayolle wrote: > > How big is this documentation? Is it big enough to have a -doc package? > If so, you might consider just building the -doc on your own system and > loading it up as a with Architecture: all. > > This is impure, but pragmatic. It is impure because anyone else who > wants to build it will have to do so by hand. It is pragmatic because > the autobuilders won't have to build it (or anyone else, either). Good point. The doc is quite small (20 pages in postscript), but I was considering making a -doc package anyway, since I'm providing packages for python2.1, 2.2 and 2.3, and there's not real point in providing the same doc 3 times. I think that until the tools are provided in some real package, I'll follow your advice. Thanks a lot. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: version independent pythin packages: ?
On Thu, Aug 07, 2003 at 12:58:25PM +1000, Donovan Baarda wrote: > The only problem is when someone with write access to > /usr/lib/site-python uses a non-default python... the pyc's will be > "updated" for the non-default python. > > After testing, it seems that there is no way to prevent root from > updating the pyc's when using a non-default python. However, even if Yes, even chmoding the .pyc file won't work. > this does occur, everything will still work, it will just be slightly > less optimal when using the default python. The only solution is "root > should never use the non-default python when importing modules from > /usr/lib/site-python"... which may or may not be OK. For most programs this should not really be a big issue. Most of the time, people tend to use mostly one python version on production machines. The worst case I've seen with missing/inapropriate .pyc files was on a cgi based web application, where the performance increase we got when fixing the problem was noticeable by end users. For long running processes, the import is done only once, so the loss of time is evened out in the long run. > Given the complexity of the alternatives, this is a simple solution that > fixes the problem with only minor issues. I'd be tempted to make this > the solution and put it into the Python policy. +1 > Anyone else agree? > > Other things to think about; > > Python applications using the default Python with their own modules not > in /usr/lib/site-python... not an issue? They are expected to configure their own PYTHONPATH, are they not? > Making sure all the pyc's are re-compiled when the default python is > updated. Yes. Should not be too difficult. > A brute force approach is to have the python packages post-inst run > "dpkg-reconfigure" over every package that depends on "python", and > require that packages recompile their pyc files on a "dpkg-reconfigure". > This has the advantage of "notifying" all these packages when the > default python has changed so they can do other stuff if they need to. This would be nice, but packages will take some time to catch up. Another thing we should take care of is packages which used to be pure python in version N, and include C extensions in version N+1. The packages for N+1 should be versioned, but how can we provide a nice upgrade path? In order to be sure not to break anything, we would have to make the new python-foobar package depend on python2.X-foobar for X in (1,2,3). The last point is how to write dependencies on packages which are ot available on all python versions. For instance python-docutils needs python-xmlbase and python-difflib. python-xmlbase exists for python2.1 and 2.2 but not 2.3, and difflib exists for 2.1, but not 2.2 or 2.3. How should the dependencies be written ? -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: version independent pythin packages: ?
On Thu, Aug 07, 2003 at 11:34:27AM +0100, Ricardo Javier Cardenes Medina wrote:
> Thinking on this problem a bit further (not feasible with current
> implementation), wouldn't it be nice if the user could enable Python
> (via environment or command line switch) to use some local repository
> (~/.python/X.Y/) to store .py{c,o} files if (s)he hasn't write access to
> the system files?
You always can copy the .py[co] files in
/usr/lib/python2.X/site-packages at install time. Since these directory
come before /usr/lib/site-python in the default sys.path, the compiled
modules will be used on import.
Now this has some unpleasant consequences:
* python no longer has a way of seeing if the .pyc is up to date
* I think this screws up the exception reporting routines in python
Maybe this could be handled with symlinks?
--
Alexandre Fayolle
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Développement logiciel avancé - Intelligence Artificielle - Formations
Re: version independent pythin packages: ?
On Fri, Aug 08, 2003 at 01:52:40PM +0200, Matthias Urlichs wrote: > Hi, > > Donovan Baarda wrote: > > It would be nice if you could specify dependencies as follows; > > > > Depends: (python2.2, python2.2-xmlbase, python-textwrap) | (python2.3), > > python-roman > > > Hmm. You can, just distribute the stuff out (standard Boole algebra): > Depends: python2.3 | python2.2, python2.2-xmlbase | python2.3, > python-textwrap | python2.3, python-roman > > It looks ugly as hell, though, and I'll have to check whether it really does > the right thing when you have python2.2 installed and pull in > python-docutils. I'm not sure this will work if I try to use docutils as a library in another package supporting only python2.2. Initially installed packages: python2.3 I apt-get install python2.2-so-and-so which Depends: python2.2, python-docutils python2.2 will be installed, so is python-docutils, but not python-textwrap nor python2.2-xmlbase because python2.3 is there. The result is a malfunctionning python2.2-so-and-so, unless the packager manually adds python-textwrap and python2.2-xml dependencies, but this feels wrong to me. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: python transition and python-xml
On Sun, Aug 10, 2003 at 01:26:46PM +0200, Sebastien Bacher wrote: > > > Hi, > > I need the python-xml package to rebuild some of my packages > (python-gtk, python-gtk2, python-gnome2, python-pyorbit, rubrica), but > python-xml is away from unstable because of transition. > > Several packages use python-gtk/gtk2, so I would upload these packages > today, but I don't know what's the best way. > > * NMU python-xml (I've mailed the maintainer yesterday but no response > for the moment). Yesterday was saturday, and I don't read my mail on week ends. The updated package is in progress (i.e. pbuilder is running right now), and I have contacted Jerome Marant who's my usual sponstor (I'm not a DD). I was planning to ask someone on the list to sponsor the upload if I don't get an answer from him by tomorow, but if people think this is more urgent, please tell me if you want to sponsor the upload today, and I'll give you the URL where you can dowload the source package for python-xml and python-unit. > * change Build-Depends from python-xml to python2.3-xml for the moment. This will surely work in the meantime. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: Support for Python2.1 and Python2.2
On Wed, Sep 10, 2003 at 10:53:07AM +0200, Andreas Rottmann wrote: > But it is OK to drop 2.1/2.2 support for packages that nothing depends on? -1 Developers are using such packages to check that their work will work on several python versions. For example, I recently had to work for a customer using AIX 4.3, and which required my program to work with python2.1, and I was *very* happy to find python2.1 and libraries on my debian box to test my work. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: Support for Python2.1 and Python2.2
On Wed, Sep 10, 2003 at 01:35:42PM +0200, Andreas Rottmann wrote: > Alexandre Fayolle <[EMAIL PROTECTED]> writes: > > > On Wed, Sep 10, 2003 at 10:53:07AM +0200, Andreas Rottmann wrote: > >> But it is OK to drop 2.1/2.2 support for packages that nothing depends on? > > > > -1 > > > if -1: >print "parsed as true" > else: >print "parsed as false" My fault, I thought I was on python-dev (where -1 stands for 'I vote against this', see http://www.python.org/peps/pep-0010.html) > > > > > Developers are using such packages to check that their work will work on > > several python versions. > > > > For example, I recently had to work for a customer using AIX 4.3, and > > which required my program to work with python2.1, and I was *very* happy > > to find python2.1 and libraries on my debian box to test my work. > > > OK, so keep them around until the version in question is dropped from > the archive? This would be nice. Or until upstream drops support for 2.1. If you already support 2.2 and 2.3, then supporting 2.1 does not require much more work (since you already have to deal with multiple calls to setup.py, alternatives, etc.), and it is of great value to people who work with python and have to support legacy versions. Now this leaves us with the question: how long should Debian ship python2.1? -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
upgrade path for python packages
Regarding the recent discussions about packaging of Python package, what is the recommended practise to provide a smooth upgrade path during the migration. Suppose upstream (pure) python lib foobar is currently packages as: python-foobar (dummy package depending on python2.3-foobar) python2.3-foobar (installs modules in /usr/lib/python2.3/site-packages) python2.4-foobar (installs modules in /usr/lib/python2.4/site-packages) And we want to migrate to a single package called python-foobar, which installs python module in /usr/lib/site-python/ How do we ensure that packages depending on python2.X-foobar won't break when the new package is installed? Do the following dependencies do the job: Package: python-foobar Provides: python2.3-foobar, python2.4-foobar Conflicts: python2.3-foobar, python2.4-foobar Replaces: python2.3-foobar, python2.5-foobar Thanks for your answers, -- Alexandre Fayolle signature.asc Description: Digital signature
python-xml up for adoption
Hi, I'm no longer using python-xml[1] for my daily development, and as a consequence, I feel I'm not doing as good a job as I should on the python-xml package. I'm therefore considering passing maintenance to someone else, or co-maintaining the package. The packaging itself is pretty straightforward, but * upstream is not very active * some long lasting bugs[2] are fixed in upstream cvs, but the fix might break other packages depending on the bug, so I'm a bit reluctant to add a patch which could lead to debian shipping a pyxml-0.8.4 package which would behave differently from other distributions * xbel is part of the debian package, but is essentially unmaintained by upstream (not a problem for the DTD, but one for xbel-utils scripts, which I don't use and have been the only one to change in upstream CVS during the past years). Additionnally, xbel has been moved to it's own separate project [3], so maybe it makes sense to move it to its own source package. I'm not sure how this should be done, debian-wise. Is anybody interested in maintaining the package? [1] http://packages.qa.debian.org/p/python-xml.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-xml [3] http://xbel.sourceforge.net/ -- Alexandre Fayolle signature.asc Description: Digital signature
bytecompilation and default python version
Hello, I have two small questions regarding byte-compiling python modules in the maintainer scripts of python library packages. 1. If a package installs modules under /usr/lib/site-python, should the postins script produce .pyc files ? .pyo files ? 2. If the answer to 1. is 'yes', the current common practise is to use the compileall.py script which lives in /usr/lib/python2.X, which means that the packages have to be changed if the default python version changes. I think things would be nicer and cleaner if this script was provided in the python package (maybe as a symbolic link, or an executable such as /usr/bin/python-compileall) so that the packages can avoid depending on a versioned python version when they are version independent. Thanks for your feedback. -- Alexandre Fayolle LOGILAB, Paris (France). signature.asc Description: Digital signature
Bug#354012: RFA: python-xml -- XML tools for Python [dummy package]
Package: wnpp Severity: normal I request an adopter for the python-xml[1] package. The package description is: The Python/XML distribution contains the basic tools required for processing XML data using the Python programming language, assembled into one easy-to-install package. The distribution includes parsers and standard interfaces such as SAX and DOM, along with various other useful modules. . The package currently contains: . * XML parsers: Pyexpat (Jack Jansen), xmlproc (Lars Marius Garshol), sgmlop (Fredrik Lundh). * SAX interface (Lars Marius Garshol) * minidom DOM implementation (Paul Prescod, others) * 4DOM and 4XPath from Fourthought (Uche Ogbuji, Mike Olson) * Schema implementations: TREX (James Tauber) * Various utility modules and functions (various people) * Documentation and example programs (various people) Reverse dependencies include fonttools, gdeskcal, gdesklets, imgseek, memaid-pyqt, python-davlib, qm, revelation, rubrica, zope. I'm no longer using python-xml for my daily development, and as a consequence, I feel I'm not doing as good a job as I should on the python-xml package. I'm therefore considering passing maintenance to someone else, or co-maintaining the package. The packaging itself is pretty straightforward, but * upstream is not very active * some long lasting bugs[2] are fixed in upstream cvs, but the fix might break other packages depending on the bug, so I'm a bit reluctant to add a patch which could lead to debian shipping a pyxml-0.8.4 package which would behave differently from other distributions * xbel is part of the debian package, but is essentially unmaintained by upstream (not a problem for the DTD, but one for xbel-utils scripts, which I don't use and have been the only one to change in upstream CVS during the past years). Additionnally, xbel has been moved to it's own separate project[3], so maybe it makes sense to move it to its own source package. I'm not sure how this should be done, debian-wise. [1] http://packages.qa.debian.org/p/python-xml.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-xml [3] http://xbel.sourceforge.net/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdbs to remove *.pyc on clean?
On Mon, Apr 10, 2006 at 06:59:04PM +0200, Peter Eisentraut wrote:
> I have a question on the bug report #252134 "cdbs: python-distutils.mk
> should remove .pyc files on clean". It seems that python setup.py
> clean actually creates a number .pyc files itself, and quite a number
> of packages therefore have code along the lines of
>
> clean::
> find . -name '*.pyc' -exec rm '{}' ';'
>
> in them. I'm considering adding exactly that line to cdbs. The
> question is whether that is too far reaching. I'm not an expert on the
> issue, but it seems unlikely that an upstream tarball or a clean source
> package should contain .pyc files. So it seems OK to me. Does anyone
> think this change would be a bad idea, or does anyone perhaps have a
> better solution for this bug?
It sounds OK to me. .pyc files in upstream tarball are most certainly an
error (and if upstream ships a required .pyc without the corresponding
.py, the package is probably non DFSG free).
Running setup.py will create .pyc for files in the module imported by
setup.py. For instance, logilab's packages use a common setup.py file
and put changing information (version number, description, etc.) in
__pkginfo__.py which is imported by setup.py, thus creating
__pkginfo__.pyc.
While you are at it, I suggest that you expand a little bit you search
and use '*.py[co]'. It probably won't catch a lot more files (optimized
bytecode is not that common), but does not involve a very high overhead.
--
Alexandre Fayolle LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
signature.asc
Description: Digital signature
Re: Deprecating /usr/lib/site-python in python policy
On Sun, Jun 11, 2006 at 02:35:05PM +0200, Raphael Hertzog wrote: > Hi, > > as part of the new policy we should also deprecate /usr/lib/site-python. I'll have to reread the new policy, but I think this is not a very good idea. /usr/lib/site-python exists for modules which do not care about which version of the python interpreter is used and is therefore very useful. > > Since this directory is in sys.path of all python versions, if we > byte-compile those in-place for the current version, then the modules > won't work with other python versions. This just not true. Python is smart enough not to use the .pyc if the version used to produce it is not the one which is used. The problem only exists for python extensions, but pure python modules have no problem with this. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
rejoindre l'équip e d'empaquetage python
Hi everyone I would be glad to join the python-modules packaging team. My alioth login is afayolle, and for those who dwell there, my irc nick is agurney. Thanks, -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
joining the python-modules team
Apologies for the French subject line in the previous mail. I'm resending in case it caused it to be trapped by spam filters. I would be glad to join the python-modules packaging team. My alioth login is afayolle, and for those who dwell there, my irc nick is agurney. Thanks, -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Bug#374799: python2.3-tables: has versioned dependency on virtual package python2.3-numarray
Package: python2.3-tables Severity: serious Tags: patch Justification: Policy 7.2 Hi, python2.3-tables is uninstallable on a sid distribution, because it depends on python2.3-numarray (>= 1.5). With the new python policy, python2.3-numarray is a virtual package provided by python-numarray. A simple fix is the change the dependency in the control file to python-numarray (>=1.5.1-4) for python2.3-tables and python2.4-tables. Thanks, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMU release for python-tables?
tag 373508 +patch On Wed, Jun 21, 2006 at 02:07:15PM +0200, Francesc Altet wrote: > Hi, > > I'm the maintainer for the python-tables packages. After the aparison of the > new Python police, the package is not installable anymore under Sid. I've > tried to adapt the python package to the new policy, but with no success. > > So, until I've more time to look into this, I'd like that someone would > create > a NMU for this package. I attach a .diff.gz of a possible NMU, bug I have to leave right now in order to catch a train (to give a training session in which I will have to demonstrate pytables), so I don't have time to test the package properly and upload it before early next week. It builds correctly with pbuilder, is lintian clean, and installs correctly on my system, but I can't test the functionnality and follow up quickly in case the package breaks something else. Anyone knowledgeable is welcome to verify the patch and upload it. If noone does so, I'll upload the NMU next monday, possibly with comments received by mail included. Cheers, I've got to run, now. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science pytables_1.3-1.1.diff.gz Description: Binary data signature.asc Description: Digital signature
Bug#375836: python2.4-gnome2-extras: versioned dependency on virtual package python2.4-gtk2
Package: python2.4-gnome2-extras Severity: serious Tags: patch Justification: makes package uninstalable on sid Hi, The python-gtk2 package has been updated to the new Python policy, and therefore the python2.4-gtk2 package is now a virtual package, on which no versionned dependencies should exist. Your package should be updated to depend on python2.4, python-gtk2 (>=2.4), python2.4-gtk2 to be installable. Thanks -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Europython 2006
Hi everyone, I'll be attending Europython next week. If anyone else involved with python packaging in Debian is there, I'll be glad to meet them. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Re: Python-Qwt
On Mon, Jul 10, 2006 at 05:02:42PM +0200, Gudjon I. Gudjonsson wrote: > Hi >I have been spending my time recently on packaging python-qwt for > Debian. I am very interested in getting it into the distribution. Is > there anyone that might be willing to help me. The packages can be > found at. > http://mve035.mc2.chalmers.se/~gudjon/debian/pyqwt4/ > I did compile the packages against python-numpy 0.9.8 that is still not in > the Debian distribution but on its way. Any suggestions on how to solve > that issue are welcome. numpy is coming to Debian. It is currently in the NEW queue, waiting for the ftp-master's approval, so you just need to wait a little bit for the package to hit the archive. Thanks for packaging Qwt. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Bug#377680: pyro: Does not follow the new python policy
Package: pyro Version: 3.5-1 Severity: important Tags: patch Hi Cédric, The pyro package currently does not follow the new Python policy (http://wiki.debian.org/DebianPython/NewPolicy), but strangely no bug has been filed against it so far. The attached patch fixes this, as well as the multiple python version bug which has been reported on pyro (it just lacks an entry to close this bug in debian/changelog). The migration was done using python-central. Unless you strongly oppose, I will probably upload the updated package tomorrow. A bientôt, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages pyro depends on: ii python2.3.5-11 An interactive high-level object-o pyro recommends no packages. pyro_3.5-1.1.diff.gz Description: Binary data
Re: python-scipy dependencies should be updated?
On Tue, Jul 11, 2006 at 12:28:44PM -0300, yaco wrote: > hi, > > i just installed python-numpy, and tried to remove python-numeric, but > python-scipy depends on it. is this scheduled for fixing? should i > report it as a bug? It is not a bug. The version of scipy in Debian is built with Numeric and won't work with numpy. Work in in progress in getting a more recent version of scipy in Debian. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Re: which wiki-like text encoding?
On Tue, Aug 01, 2006 at 04:54:27PM +0200, Pierre Habouzit wrote: > Le mar 1 août 2006 16:41, Andreas Barth a écrit : > > Hi, > > > > I'm looking for some "wiki-like"-language which can be parsed in > > python sufficiently fast. I was hinted to pytextile, but it looks > > dead upstream and isn't really fast (to say it nice :). So, any other > > hints for me? > > python people usually use restructured text. it depends what you want to > do exactly, and what the users of that syntax are likely to be able to > learn ;) Yes, ReST is nice, and can be parsed using python-docutils. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science signature.asc Description: Digital signature
Re: which wiki-like text encoding?
On Tue, Aug 01, 2006 at 06:06:33PM +0200, Andreas Barth wrote:
> * Alexandre Fayolle ([EMAIL PROTECTED]) [060801 17:06]:
> > On Tue, Aug 01, 2006 at 04:54:27PM +0200, Pierre Habouzit wrote:
> > > Le mar 1 août 2006 16:41, Andreas Barth a écrit :
> > > > Hi,
> > > >
> > > > I'm looking for some "wiki-like"-language which can be parsed in
> > > > python sufficiently fast. I was hinted to pytextile, but it looks
> > > > dead upstream and isn't really fast (to say it nice :). So, any other
> > > > hints for me?
> > >
> > > python people usually use restructured text. it depends what you want to
> > > do exactly, and what the users of that syntax are likely to be able to
> > > learn ;)
> >
> > Yes, ReST is nice, and can be parsed using python-docutils.
>
> Thanks to all these answers. I have taken rst now (and thanks to
> Matthias who pointed out the "sample code" in
> /usr/share/python-docutils/rst2html.py.
>
>
> My next question is for now, is there some nice/easy way to "hash"
> contents of regular files in python (like python itself does for
> .py-files)? ("nice" means: supported by python - I know how I could do
> that myself with low-level utils, but I'm lazy ...)
I'm afraid this is getting off topic for this list (which is about
the packaging of python module for debian). I suggest that you ask your
questions on a dedicated forum, such as comp.lang.python, where people
are very friendly and will certainly answer your questions.
BTW look at the sha and md5 modules in the standard library.
--
Alexandre Fayolle LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
Informatique scientifique: http://www.logilab.fr/science
signature.asc
Description: Digital signature
