another way to reproduce the bug or make use of /usr/share/i18n/SUPPORTED
N.B. I'm sorry if you got this email twice... I mixed up an email on my
1st trial... need sleep... please reply to this one instead so all
relevant entities get in the loop
I think that this old bug (185776) is related to fresh #372684 and
#369689 (which I reassigned to python2.3)
Following code snippet having locale en_DK installed leads to the
desired behavior (the same was shown in #369689)
cat ./test_locale.py
#!/usr/bin/python2.3
import locale
import time
print `locale.setlocale(locale.LC_ALL,'')`
print time.strptime('May 31 09:30:01', '%b %d %H:%M:%S')
* LC_ALL=en_DK python2.3 ./test_locale.py
'en_DK'
Traceback (most recent call last):
File ./test_locale.py, line 8, in ?
print time.strptime('May 31 09:30:01', '%b %d %H:%M:%S')
File /usr/lib/python2.3/_strptime.py, line 402, in ?
_locale_cache = TimeRE()
File /usr/lib/python2.3/_strptime.py, line 318, in __init__
self.locale_time = LocaleTime()
File /usr/lib/python2.3/_strptime.py, line 106, in __init__
self.__lang = _getlang()
File /usr/lib/python2.3/_strptime.py, line 31, in _getlang
return locale.getlocale(locale.LC_TIME)
File /usr/lib/python2.3/locale.py, line 365, in getlocale
return _parse_localename(localename)
File /usr/lib/python2.3/locale.py, line 280, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: en_DK
Interesting enough it is in the same state for python 2.4 and 2.5 but
works fine for 2.2 (probably due to the fact that there were not
fancy locale handling at all, and strptime was merely a wrapper to libc
functions):
* LC_ALL=en_DK python2.2 ./test_locale.py
'en_DK'
(1900, 5, 31, 9, 30, 1, 3, 151, 0)
Having closer look at how locale deals with locales (and disregarding
all shortcuts for this bug discussion ;-)), I found that it
depends on hardcoded list of locales in locale_alias and neither en_DK
nor many other (eg ru_UA) are in that list. That causes locale.normalize
function to do nothing on those, thus providing function
_parse_localename with no '.' in the normalized name (ie without split
into language.encoding which at the end causes _parse_localename to
throw an exception. No comment to locale_alias about missing locales
was detected. only for windows_locale there was:
# NOTE: this mapping is incomplete. If your language is missing, please
# submit a bug report to Python bug manager, which you can find via:
# http://www.python.org/dev/
# Make sure you include the missing language identifier and the suggested
# locale code.
So my guess to fix all those bugs in fast way, missing locales
should be added to the list. It seems, although en_ZA was found
missing,it wasn't added and still missing for locale_alias, thus
showing that this solution might be highly ineffective and wrong way.
Better way to fix this would be probably to add use of
/usr/share/i18n/SUPPORTED which has all those lang.encoding aliases
defined. That also would favor more orthogonal design, so that python's
internals don't duplicate (and thus ommit) some locales defined on the
system. /usr/share/i18n/SUPPORTED is highly Linux specific solution thus
might not be favored by python upstream, but might be very crucial for
i18n support of python among debian community.
P.S. Please CC me replies from the list since I'm not subscribed to d-p
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
Re: Deprecating /usr/lib/site-python in python policy
On Mon, 12 Jun 2006, Alexandre Fayolle wrote: 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. /usr/lib/site-python is on the sys.path of all python versions so we must make sure to provide the best (ie .py with working .pyc) for all python versions. We can't do that within /usr/lib/site-python so we must do it outside. python-support and python-central provides convenient support for that. Any package using /usr/lib/site-python shoud be changed to use one of those ... or if the modules shouldn't be public, then it should use a private directory that the application manually adds to the sys.path. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Joe Wreschnig ([EMAIL PROTECTED]): I have updated the Python policy document based on the discussions on the list. An updated DebianDoc (and HTML and text files) can be found at http://people.debian.org/~piman/python-policy/. great work! [...] It does not: 1) Cover CDBS, since I don't know how to use it properly 2) Give examples for Python packages without using debhelper; I suspect those are now almost impossible to make sanely. What about an Egg support? I think it's worth mentioning in policy I'm talking about: * --single-version-externally-managed parameter passed to `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL (CDBS) * Egg's dirname's issue (python's/module's version in dirname) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpQfkJw9XNz9.pgp Description: PGP signature
Re: Bug#370833: New dh_python proposal
On Mon, 12 Jun 2006, Raphael Hertzog wrote: I would love to have this fixed by today's dinstall. That's why I prepared the attached NMU, please just send an OK and I'll upload it (of course, feel free to do it yourself in a maintainer upload). Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
How about adding example for building compiled extensions? Otherwise there will be used many ways to produce binaries for all supported python versions. - Packaging examples - CDBS (not yet available) - python-central (http://python-modules.alioth.debian.org/python-central_howto.txt) - python-support (http://wiki.debian.org/DebianPythonFAQ) If a package has just extensions, then you don't need python-support or python-central at all. Just put all extensions for each supported python version into the same python-foo package. We do not explicitely disallow having copies of the same .py files in /usr/lib/pythonX.Y, so that can be done as well (example is python-newt which comes with one extension and one module). Extensions and modules in packages (the python sense, a directory with an __init__.py) must end up in the same directory. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
On Mon, 12 Jun 2006, Raphael Hertzog wrote: On Mon, 12 Jun 2006, Raphael Hertzog wrote: I would love to have this fixed by today's dinstall. That's why I prepared the attached NMU, please just send an OK and I'll upload it (of course, feel free to do it yourself in a maintainer upload). Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). And for extra-care, here's the package for testing: http://people.debian.org/~hertzog/python/ http://people.debian.org/~hertzog/python/debhelper_5.0.37.1_all.deb Please test and report me ASAP any problem with it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Hi, On Mon, 12 Jun 2006, Michal Čihař wrote: On Mon, 12 Jun 2006 02:29:51 -0500 Joe Wreschnig [EMAIL PROTECTED] wrote: I have updated the Python policy document based on the discussions on the list. An updated DebianDoc (and HTML and text files) can be found at http://people.debian.org/~piman/python-policy/. How about adding example for building compiled extensions? Otherwise there will be used many ways to produce binaries for all supported python versions. There will be example packages soon we hope. In the mean time, I can tell you that you will have to Build-Depends on python (= 2.3.5-6), python-all-dev and that you should use `pyversions -r debian/control` to find out the list of python versions that you must use to build the package with, then your job in the rules file is to do something like that: for python in $(PYVERS); do \ $$python setup.py ...; \ done Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
Coin, Raphael Hertzog [EMAIL PROTECTED] writes: Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). This is perfectly reasonnable. -- Marc Dequènes (Duck) pgpU3t0AM8OF7.pgp Description: PGP signature
Re: New Python policy
Hi no need to CC me... On Mon, 12 Jun 2006 12:34:18 +0200 Matthias Klose [EMAIL PROTECTED] wrote: - Packaging examples - CDBS (not yet available) - python-central (http://python-modules.alioth.debian.org/python-central_howto.txt) - python-support (http://wiki.debian.org/DebianPythonFAQ) If a package has just extensions, then you don't need python-support or python-central at all. Just put all extensions for each supported python version into the same python-foo package. We do not explicitely disallow having copies of the same .py files in /usr/lib/pythonX.Y, so that can be done as well (example is python-newt which comes with one extension and one module). I understand this, I just want that policy mentions what is suggested way to get all supported python versions (and thus what pythonX.Y to call setup.py with). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: New Python policy
Hi On Mon, 12 Jun 2006 13:18:53 +0200 Raphael Hertzog [EMAIL PROTECTED] wrote: In the mean time, I can tell you that you will have to Build-Depends on python (= 2.3.5-6), python-all-dev and that you should use `pyversions -r debian/control` to find out the list of python versions that you must use to build the package with, [...] This is exactly information I miss there right now. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Deprecating /usr/lib/site-python in python policy
On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote: /usr/lib/site-python is on the sys.path of all python versions so we must make sure to provide the best (ie .py with working .pyc) for all python versions. Why must? Has this for some reason become a problem just recently or has this always been a problem? I do not think missing or invalid .pyc's there could cause noticable performance problems (especially since it is at the end of the search path or at least near it) and certainly the modules are importable from multiple python versions already. As a user I am greatful for all the people making an effort to improve Debian Python, but I am beginning to worry if you people are taking too many steps at once this close to the freeze. signature.asc Description: Digital signature
Re: Deprecating /usr/lib/site-python in python policy
On Mon, 12 Jun 2006, Juha-Matti Tapio wrote: On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote: /usr/lib/site-python is on the sys.path of all python versions so we must make sure to provide the best (ie .py with working .pyc) for all python versions. Why must? Well should. Has this for some reason become a problem just recently or has this always been a problem? I do not think missing or invalid .pyc's there could cause It's not a major problem, we won't be pushing hard for it but it's good to update the policy accordingly however. We'll concentrate on fixing the modules first. The application won't stop working whereas modules could. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debhelper support should be ready tomorrow
On Mon, 12 Jun 2006, Raphael Hertzog wrote: On Mon, 12 Jun 2006, Raphael Hertzog wrote: I would love to have this fixed by today's dinstall. That's why I prepared the attached NMU, please just send an OK and I'll upload it (of course, feel free to do it yourself in a maintainer upload). Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). Debhelper uploaded. We also had a python-central upload (fixing dh_pycentral) and a python-support (adding dh_pysupport). So hopefully we should be able to really start updating modules to the new policy tomorrow. Build-Depends will have to require: - python (= 2.3.5-7) (for pyversions script) - debhelper (= 5.0.37.1) (first dh_python for the new policy) - python-central (= 0.4.10) (fixed dh_pycentral to work with new dh_pyhton) - python-support (= 0.2.3) (first version with dh_pysupport) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
On Mon, Jun 12, 2006 at 09:06:43PM +0200, Raphael Hertzog wrote: On Mon, 12 Jun 2006, Raphael Hertzog wrote: On Mon, 12 Jun 2006, Raphael Hertzog wrote: I would love to have this fixed by today's dinstall. That's why I prepared the attached NMU, please just send an OK and I'll upload it (of course, feel free to do it yourself in a maintainer upload). Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). Debhelper uploaded. We also had a python-central upload (fixing dh_pycentral) and a python-support (adding dh_pysupport). So hopefully we should be able to really start updating modules to the new policy tomorrow. Build-Depends will have to require: - python (= 2.3.5-7) (for pyversions script) Are packages expected to call pyversions directly, or is this something that should be a versioned dep from one of the other build-dependencies? Hmm, I guess it's called by dh_python, and debhelper doesn't depend on python at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
On Mon, 12 Jun 2006, Joe Wreschnig wrote: - python (= 2.3.5-7) (for pyversions script) Okay, I've updated the policy document to use that version in the Build Dependencies section. Which is only really needed for extensions. Modules don't need more than an unversioned dependency on python / python-dev. Extensions will also need a build-dep on python-all-dev. Are packages expected to call pyversions directly, or is this something that should be a versioned dep from one of the other build-dependencies? Some packages will call pyversions themselves to get the available list of Python versions, and run each one on setup.py (see [EMAIL PROTECTED] for an example). Pure Python modules using python-support won't need to. ... using python-support or python-central BTW. Hmm, I guess it's called by dh_python, and debhelper doesn't depend on python at all. No, pyversions is not (yet) used by dh_python. I don't need to know which versions I'm building but which version I have built... If we want dh_python to fail when the versions built do not match what has been announced in XS-Python-Version, then I might start using it (but I have perl code to do the same since it was in my first dh_python). -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper support should be ready tomorrow
Raphael Hertzog writes: On Mon, 12 Jun 2006, Joe Wreschnig wrote: - python (= 2.3.5-7) (for pyversions script) Okay, I've updated the policy document to use that version in the Build Dependencies section. Which is only really needed for extensions. Modules don't need more than an unversioned dependency on python / python-dev. Extensions will also need a build-dep on python-all-dev. except if you build an extension for just the default version. Hmm, I guess it's called by dh_python, and debhelper doesn't depend on python at all. No, pyversions is not (yet) used by dh_python. I don't need to know which versions I'm building but which version I have built... If we want dh_python to fail when the versions built do not match what has been announced in XS-Python-Version, then I might start using it (but I have perl code to do the same since it was in my first dh_python). we should detect that. the resulting package will not be usable? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do when a source package has Python components in a subdir?
Zack Weinberg writes: Since Python policy is being revamped just now I thought I'd bring up a complicated situation that I ran across recently (in packages that are currently just for private use, but I might try to get them into Debian eventually). Consider a source package that builds a shared library, Python bindings for that library (consisting of both extensions and modules), and programs for /usr/bin that are written in Python and use the library bindings. Upstream distributes this as one big tarball with a top-level autoconf-based configure script and Makefile. I assume these bindings are for public usage. The Python bindings are in a subdirectory; Make recurses into that directory and invokes setup.py there. Upstream makes no provision for building the bindings against multiple versions of Python; however, they work fine with all versions I've tried (2.3 and 2.4). Policy questions: * What is the appropriate set of binary packages for this scenario, and what goes in each? - the minimum would be one binary package - a python-foo package can be split out (if there is a large chunk of modules, it could further be split out into a python-foo and python-foo-bin package. * What should the /usr/bin programs have on their #! line? (I assume /usr/bin/python, i.e. the default version, but explicitness would be good.) yes, we should mention that. I'm not sure, how /usr/bin programs should be handled which are installed versioned (foo-py23-bin, foo-py24-bin) and use the versioned interpreter explicitely. Just remove them, and keep foo-bin, or keep them all, but do not explicitely depend on the versioned python packages. Packaging practices question: * What is the best way to code debian/rules for this scenario? Hack up the upstream Makefiles to run setup.py repeatedly, or have debian/rules reach in there and invoke it itself, or what? depends on the packaging system, but that decision is up to the package maintainer. I looked once at subversion and just did build the whole stuff twice. If you have the possibility to just build the python stuff, then maybe build the package for the default version completley, and then for the other versions EXTRAVERS := $(filter-out $(shell pyversions -d), $(shell pyversions -r)) build: $(EXTRAVERS:%=build-python%) build-python%: python$* setup.py build install: build $(EXTRAVERS:%=install-python%) install-python%: python$* setup.py install --no-compile \ --root $(CURDIR)/debian/python-foo Hacking the upstream Makefiles should be done independently from the currently supported python versions. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Python policy
Joe Wreschnig writes: I have updated the Python policy document based on the discussions on the list. An updated DebianDoc (and HTML and text files) can be found at http://people.debian.org/~piman/python-policy/. It: 0) Removes a lot of cruft/debate from the document itself 1) Explains X*-Python-Version 2) Explains that we don't want tight dependencies 3) Deprecates /usr/lib/site-python 4) Outlines using python-support/central with debhelper 5) Tries to cover more on private modules It does not: 1) Cover CDBS, since I don't know how to use it properly 2) Give examples for Python packages without using debhelper; I suspect those are now almost impossible to make sanely. Some additions: - mention /usr/share/python/debian_defaults - add paragraph about python packages - describe the XB-Python-Version field - add section about provides - extend paragraph about byte compilation - remove the paragraph about distutils - enhance the section about support tools Matthias pypol.diff Description: Binary data
Instructions to update a package for the new python policy
Hi, I've prepared this: http://wiki.debian.org/DebianPython/NewPolicy Feel free to enhance. I also converted python-pam as an example (std debhelper package): http://people.debian.org/~hertzog/python/examples/ I'll gladly put other examples packages at the same place. Just send them to me. Now it's time to ask all maintainers to update their packages. Someone should prepare several list of source packages: - python extensions - python modules only - python apps Then we need to fill bugs, and usertag them policy-ext, policy-mod and policy-apps with identity debian-python@lists.debian.org to be able to follow the progress here: http://bugs.debian.org/usertag:debian-python@lists.debian.org Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Instructions to update a package for the new python policy
Coin, Raphael Hertzog [EMAIL PROTECTED] writes: Now it's time to ask all maintainers to update their packages. Someone should prepare several list of source packages: - python extensions - python modules only - python apps Fact is python-support is not yet ready for extensions, and CDBS class not yet integrated into the cdbs package. I talked to Joss about it today (which is yesterday for humans), and we are near a solution, this should be solved soon. I made the simplifications and changes needed in the CDBS class, but still a bug remains. I hope this would be solved tomorrow. Btw, you forgot to enforce python-support à least = 0.2, or even 0.2.2 in the generated Depends (suggested on IRC). -- Marc Dequènes (Duck) pgpDNUyXnhcaz.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, With the upcoming releases of the last packages which didn't support 2.4 yet (Plone on the Zope application server) we may be able to drop support for 2.3 in sid and etch as well. For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). Issue #2 is not really relevant to dropping python2.3, since keeping python2.3 around is not going to help the fact that people will be wanting to decompile bytecode for the new default python2.4. Issue #1 is a problem however, so if there are plans to drop 2.3 for etch, I'd be very happy for a rough timeframe so I know when this all needs to be dealt with. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New python distutils class
Coin, As you may have heard, Python packaging is moving fast these days. We plan the move the current Python version to 2.4 and in the same time are drafting a new policy and creating new tools to greatly improve the current situation. All this leads to the need for a newer class, which will at the end replace the current one completly. The current status is : the class was updated today to reflect the latest changes in the debhelper dh_python script and tool-specific helpers. Remains a bug i'll try to fix tomorrow, and i need to test it with another package, just to be sure nothing is left over. Then, i'd like your support to integrate this class as soon as possible, when it is considered finished, to allow moving to the new policy approximately at the same time we move to 2.4, to avoid making the transition longer than necessary. I of course would appreciate much if you could have a look at it before and give some advice. You can find the current class here : http://perso.duckcorp.org/duck/soya-new-policy/ For the documentation point of view, as our documentation are forked, i'll write what is necessary in the original one and, by rights given by the licence, you may borrow what you need to update yours. -- Marc Dequènes (Duck) pgp0Bg2R3jcUC.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Coin, Ben Burton [EMAIL PROTECTED] writes: For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). You may still ask for help. 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Python 2.4 is out since a while, what are upstream plans for their software ? -- Marc Dequènes (Duck) pgpASsE9n5U8g.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). You may still ask for help. This will be easy enough to have ready by the time 2.3 is removed, which I'm assuming is not happening tomorrow. Where I'd love the help is with the python2.4 decompilation (see below). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Well, it's certainly useful at the moment since python2.3 is the default, and I claim it's still useful even after python2.3 is dropped -- just because debian changes the default python doesn't mean all your old bytecode disappears. One of the more important uses of this software is for repairing things in an emergency (e.g., rm *.py, oops), which is why I want to keep it around. Python 2.4 is out since a while, what are upstream plans for their software ? Upstream went commercial back in the 2.2 days. The debian packages forked and essentially became the de-facto upstream source when 2.3 decompilation was introduced, and it's still that way now. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
