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
> 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 run
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. Wh
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.
> 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 instea
Hi,
I should probably check in to this discussion, since I'm the current
(inactive) maintainer of jython -- I put it up for adoption several
months ago since I don't have so much time these days and I no longer
have much involvement with either java or jython.
A couple of notes:
- I'll probably
> 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 ja
> > - python2.1 is needed at least by zope and jython
>
> Would it still be needed in sarge if zope2.6.1 & jython were built
> against python2.2?
It's not a case of jython building against python 2.2 (in fact, it
doesn't build-depend on any version of python at all). It's a case of
jython provi
> 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 y
> Bug#118664: omniorb 1:3.0.4-2.1 omniorb 1:3.0.4-2.1 i386
I have an NMU ready to go for omniorb that fixes this and other bugs; just
waiting for word from the maintainer (who is usually quite good with writing
back).
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
h
#x27;ve already used it once, when I inadvertently deleted a .py file and after
searching the web for a decompiler managed to retrieve an almost perfect copy
of the source by running decompyle on the .pyc file.
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://baasil.humbug.o
If binaries, how
> big are they ?
Oops, I mean scripts. Very small.
> Would it really be an issue to include three of them in a
> single package ?
No, my problem was with placing them in *separate* packages (decompyleX.Y),
each containing about ten lines of material plus a copyright
her hand I don't want to provide binaries
that people can't run (if the appropriate python version is not installed)
and I don't want decompyle to depend on *every* version of python in debian.
Thoughts?
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://baasil.humb
> "python" is a real package, no virtual one. I.e. at any given time,
> there is only one package "python" on a system (neither python1.5 nor
> python2.1 will provide "python").
Duh, okay. :)
Thanks - Ben.
> > 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
a
> > 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
documents precisely what properties that symlinked python
should have and I can verify that jython satisfies them. Reason being that
jython differs from cpython in many more ways than cpython(x) differs from
cpython(y).
Ben.
(*) unless of course there is an overwhelming call for me to do so regardless
rn is that if an administrator has /usr/bin/python pointing to
jython and random package foo provides its own foo.so cpython module and
proceeds to run /usr/bin/python to open it, there will be problems.
Hence one of the reasons I wouldn't want to offer jython as a /usr/bin/python
alterna
Stackless
Just as far as jython goes, I really wouldn't want to offer it as an
alternative for /usr/bin/python, one strong reason being that it won't use
CPython dynamic libraries.
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://baasil.humbug.org.au/bab/
Public Key
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
ctually 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
> 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.
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
24 matches
Mail list logo
