Re: removing python2.3
1) removing packages only needed for python2.3: ... decompyle (2.3 only) Decompyle is a funny one, in that even though it only decompiles python2.3 bytecode, it remains useful as a disaster recovery tool after python2.3 has been removed. In that sense, I'd be happy to get it running under python2.4 instead (i.e., running under python2.4 but decompiling python = 2.3), and assuming that works I'd suggest it stay in the archive for now. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing python2.3
Regarding decompyle again: In that sense, I'd be happy to get it running under python2.4 instead (i.e., running under python2.4 but decompiling python = 2.3), and assuming that works I'd suggest it stay in the archive for now. This is now done. I've just uploaded decompyle_2.3.2-4, which removes all dependencies on python2.3. For the reasons outlined in the previous mail, even though it cannot *decompile* 2.4 bytecode yet, I'd prefer for this package to stay in the archive even after python2.3 is removed. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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]
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]
Re: Python 2.1/2.2 removal; Python 2.4 as default
decompyle2.2 has an unsatisfied build-dependency: python2.2-dev This is a legacy package, and it requires python 2.2 (it will not work with 2.3 or newer). I have just filed an ftp.d.o bug asking for it to be removed. Users should have no problem switching to the newer decompyle package instead. jython has an unsatisfied build-dependency: python2.1 I orphaned this a couple of months ago. It requires python2.1 at runtime because it is actually an implementation of python2.1. The simplest fix is probably to copy across the pure python modules from cpython2.1 and add them to the jython2.1 package in /usr/share/jython/Lib/, at which point the python2.1 dependency should be able to be removed. However, the jython packages are not ageing gracefully. Unless someone has time to spend actively looking after this (see my WNPP bug for what is required), I'd (regretfully) suggest its removal also. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's think about removing Python 2.1 and 2.2
However we should keep jython in the archives, upstream shows some activity for python2.3/2.4 compatibility. For reference, it seems upstream is currently looking at a final (non-beta) release around August [1]. Though they've missed deadlines before, so please don't take this as definitive. b. 1. http://www.jython.org/cgi-bin/wiki/RoadMap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#233035: jython: should depend on Python 2.3 instead of 2.1
And there is no upstream version for Python 2.3? Not even for 2.2. Anyway, in this case, I guess the package should be called jython2.1 instead of jython. And maybe a meta-package providing Jython should be uploaded too? It all seems a bit much, given that jython is a specialised java tool and not a general-use scripting tool. Random python scripts will almost certainly be run in cpython, which is faster and more reliable (i.e., doesn't rely on bug-free and feature-rich JVMs). Support for multiple versions would of course also be theoretical at this stage, since in 3 years of jython in debian it has never been anything other than some form of 2.1. Having said this, if there is a popular call for jython to be repackaged in order to support simultaneous multiple versions (ready for whenever 2.2 might come out), I'll do it. CCing debian-java and debian-python for comment. (Of course none of this will resolve your dependency problems - the cpython dependency has to match the jython version, otherwise jython will break.) Ben.
Re: building a module for 2 versions
I'm wondering if anyone has any nice methods of building python modules for multiple versions of python. Try apt-get source python-pgsql - all the patches of interest are in python-pgsql/debian. Since pymad comes with setup.py a similar technique should work. Specifically, in debian/rules you replace your calls to $(PYTHON)/setup.py with three separate calls running three different versions of python (or however many versions you want to support). There's also calls to debian/pathmangle.sh to fix the interpreters called by the various runtime scripts. b.
Re: lintian and new python policy
Also, someone else reported that lintian complains against Depends: python (= 2.1), python ( 2.2) This is a lintian bug. It's not bothering to notice that one's a less-than and the other's a greater-than. Btw, isn't this Depends line problematic anyway? I could have python 1.5 and 2.2 simultaneously installed and the depends would be satisfied without achieving what the maintainer really wants (i.e. python 2.1). Ben.
Re: Large-scale java policy violations
Does this bother anyone else but me? Yes, it does, but not for the same reason. Well, yes for the same reason, which is lack of adherence to a tidy convention. If that convention can spread in general across libraries for interpreted languages then all the better. In which case I'm all for putting something in debian policy proper advocating this. I personally don't care in the slightest whether it's lib-foo-java or libfoo-java (java policy says one and perl policy says the other; AFAIK these are the only documents where the issue is raised). Though I suspect it will be much easier to change over the (fewer) java packages, so I'm happy with the libfoo-language suggestion. Ben.
Re: Jython Licensing
Hi. On the topic of Jython, I received this from jython-dev (see below) - so it seems the GPL incompatibility is not likely to go away any time soon. does it matter? There is at least one small hassle (which can be a large hassle for the command-line jython user), which is readline support. There is also the issue of embedding jython in a larger (Java) program (which I see as the main strength of jython since all Java classes become magically accessible and thus scriptable, etc) where the larger program contains GPLed components. the licence is DFSG compliant, and the main gripe about python licence was that there are GPLed modules written in C, and thus linked with python interpreter. Hmm. So given the very different concept of linking in Java: 1) If I use a set of GPLed .py modules in my jython script, am I combining the GPLed modules with my script, jython and/or the java interpreter? - which combination applies? My interpretation here is script only. 2) If I use JNI wrappers to a C library that is GPLed, am I combining the GPLed library with my script, jython and/or the java interpreter? My interpretation here is script *and* java interpreter, but I deeply fear that I am wrong. Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] People play games when they've got you under the microscope and when they don't understand something I say or an experience that I've talked about. They jump on it and try and make it look silly or insane. - Tori Amos
Re: Somebody interested in packaging Jython ?
Perhaps there's an volunteer somewhere who'd like to give Jython a look and start packaging it. Assuming the offer's still standing, I'm happy to have a go. I find it useful. Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] I can resist everything except temptation. - Oscar Wilde
Jython Licensing
Hi. On the topic of Jython, I received this from jython-dev (see below) - so it seems the GPL incompatibility is not likely to go away any time soon. Ben. -- Forwarded Message -- Subject: Re: [Jython-dev] Jython license and GPL incompatibility Date: Sun, 01 Jul 2001 20:49:02 GMT From: [EMAIL PROTECTED] (Finn Bock) [ snip ] According to the FSF website (http://www.gnu.org/philosophy/license-list.html): The License of Python 1.6b1 and later versions, through 2.0 and 2.1. This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this. The license for Jython, as found on www.jython.org and in the CVS, currently contains this GPL-incompatible clause. CPython has recently altered their license to make CPython compatible with the GPL (http://www.python.org/2.0.1/). Is Jython likely to follow suit? I somehow doubt it. Not only must CNRI be prepared to release their JPython-1.1 code with a changed license, but they must also be able to actually create a new release. It is not my impression that any of the fine people working at CNRI have the tools or experience to create a JPython-1.1.1 release. Even if is 10 times easier for jython to change license that it was for python, I still think it will be 100 times too much work for me to tackle. [ snip ] -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] I don't have to try in the least to shock people. My beliefs are sufficiently shocking to most people. Because we live in a culture where passion and sexuality have been replaced by shame. We are miles away from our hearts, our feelings. In Greek mythology the gods were sleeping with humans all the time. But the Christians claim Jesus was fathered without a single drop of sperm. There wasn't even a penis involved. It's a religion without penetration. And subsequently the same believers take their swords and chop the non-believers to pieces, stab babies to death and burn witches at the stake. And you think I'm shocking when I say I gave God a blowjob? Give me a fucking break. - Tori Amos, Nieuwe Revu
Packaging - file locations?
Hi.. if I am packaging an application that relies on python scripts, should I be putting those scripts in /usr/share/package or /usr/lib/package? Browsing through existing packages I seem to find both standards used. Thanks, Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee I was implying that the Honorable Member for Wentworth was like a lizard on a rock - alive, but looking dead. - Paul Keating, on John Hewson
