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
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
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.
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
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
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.
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
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
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
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
, 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
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
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
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
14 matches
Mail list logo
