roundup and dh_python2
Hi,
I'm trying to build the new roundup package with dh_python2. That is
the right thing to do, right?
I get this:
... lots of output (DH_VERBOSE=1), then:
D: dh_python2:584: processing package roundup...
D: dh_python2:464: package roundup details = {'requires.txt': set([]),
'shebangs': set([('python', None)]), 'compile': True, 'ext': set([]),
'nsp.txt': set([]), 'public_vers': set([(2, 7)]), 'private_dirs':
{'/usr/share/roundup': {'compile': True, 'shebangs': set([('python', None)])}}}
D: dh_python2:136: guessing files for Python 2.6
Traceback (most recent call last):
File "/usr/bin/dh_python2", line 699, in
main()
File "/usr/bin/dh_python2", line 601, in main
dependencies.parse(stats, options)
File "/usr/share/python/debpython/depends.py", line 154, in parse
self.depend("python (<< %s)" % vrepr(vr[1] + 1))
TypeError: can only concatenate tuple (not "int") to tuple
plus a few cleanup messages.
Now I would like to know what should be wrong - the error message
isn't very enlightening. Maybe the problem lies here:
debian/control:
...
X-Python-Version: >= 2.5, << 2.8
TIA!
Kind regards,
--Toni++
--
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/20120618105515.ga24...@spruce.wiehl.oeko.net
Re: roundup and dh_python2
* Toni Mueller , 2012-06-18, 12:55:
... lots of output (DH_VERBOSE=1), then:
D: dh_python2:584: processing package roundup...
D: dh_python2:464: package roundup details = {'requires.txt': set([]),
'shebangs': set([('python', None)]), 'compile': True, 'ext': set([]),
'nsp.txt': set([]), 'public_vers': set([(2, 7)]), 'private_dirs':
{'/usr/share/roundup': {'compile': True, 'shebangs': set([('python', None)])}}}
D: dh_python2:136: guessing files for Python 2.6
Traceback (most recent call last):
File "/usr/bin/dh_python2", line 699, in
main()
File "/usr/bin/dh_python2", line 601, in main
dependencies.parse(stats, options)
File "/usr/share/python/debpython/depends.py", line 154, in parse
self.depend("python (<< %s)" % vrepr(vr[1] + 1))
TypeError: can only concatenate tuple (not "int") to tuple
Look like a bug in dh_python2.
Now I would like to know what should be wrong - the error message isn't
very enlightening. Maybe the problem lies here:
debian/control:
...
X-Python-Version: >= 2.5, << 2.8
In any case, I'd get rid of the "<< 2.8" part. Surely roundup cannot be
incompatible with Python 2.8, given that such version doesn't exist and
never will (or so upstream says...).
--
Jakub Wilk
--
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/20120618110955.ga2...@jwilk.net
Re: roundup and dh_python2
Hi, On Mon, Jun 18, 2012 at 01:09:55PM +0200, Jakub Wilk wrote: > * Toni Mueller , 2012-06-18, 12:55: > >debian/control: > >... > >X-Python-Version: >= 2.5, << 2.8 > > In any case, I'd get rid of the "<< 2.8" part. Surely roundup cannot > be incompatible with Python 2.8, given that such version doesn't > exist and never will (or so upstream says...). I am aware of the fact that there will be no 2.8 version of Python, but the package is incompatible with 3.x, and I need to express that, lest the package will fail on a 3.x installation. Suggested fix? Kind regards, --Toni++ -- 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/20120618113124.gb24...@spruce.wiehl.oeko.net
Re: roundup and dh_python2
Toni Mueller wrote: > >Hi, > >On Mon, Jun 18, 2012 at 01:09:55PM +0200, Jakub Wilk wrote: >> * Toni Mueller , 2012-06-18, 12:55: >> >debian/control: >> >... >> >X-Python-Version: >= 2.5, << 2.8 >> >> In any case, I'd get rid of the "<< 2.8" part. Surely roundup cannot >> be incompatible with Python 2.8, given that such version doesn't >> exist and never will (or so upstream says...). > >I am aware of the fact that there will be no 2.8 version of Python, but >the package is incompatible with 3.x, and I need to express that, lest >the package will fail on a 3.x installation. > >Suggested fix? X-P-V only ever refers to Python versions, never Python 3 versions. There's X-Python3-Version for that. It's safe and correct to remove the << 2.8. Scott K -- 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/7fb76971-9a12-42fe-a518-311c2c7f6...@email.android.com
Supporting Python 2 and 3 in libpeas
Apologies for the cross-posting, but I think both lists will have valuable input on this issue. As part of Ubuntu's push to ship only Python 3 on our desktop image, I'm now looking at libpeas (Gnome plugin system). The good news is that upstream supports Python 3.2 and 2.6/7 just fine, however the Debian packaging only builds for the default the Python 2 version. I've had a few discussions with some other developers, but none of us have actually used libpeas so I'm looking for more feedback. Debian's packaging gives us /usr/lib/libpeas-1.0/loaders/libpythonloader.so in its libpeas-1.0-0 binary package. What's the best way to provide a Python 3 version of the loader? Our first thought is to split the packaging into a python-libpeas package and a python3-libpeas package. The former would provide /usr/lib/libpeas-1.0/loaders/libpythonloader.so and the latter would provide /usr/lib/libpeas-1.0/loaders/libpython3loader.so. (Of course, we'll have parallel twiddling for the debug packages.) Then, IIUC, clients which want to use the Python 3 loader would specify "python3" to peas_engine_enable_loader() and specify 'python3' as Loader in their .plugin section. I don't want to add Conflicts headers to the python-libpeas and python3-libpeas packages because I think it's entirely reasonable to have mixed Python 2 and Python 3 libpeas plugins on the same *system*, but of course it makes no sense to have mixed plugins in the same *application*. Would a Build-Conflict in the binary packages help to prevent this, or do we need something more somewhere (i.e. in the libpeas Python layer, or do we just let the consenting adults rule keep us safe?). What do you think? I'm willing to work up a patch, once consensus has been reached on the right way to provide Python 3 support. Cheers, -Barry signature.asc Description: PGP signature
