Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 10:50 +1100, Felipe Sateler a écrit : current does not mean anything, semantically, especially for public modules/extensions. There is a set of supported versions, and that’s all. For extensions, it is the set of versions the extension has been built against, and for modules, it is the set of versions the module can work with. In neither of these cases does current mean anything. But it does mean something. Modules which build from C sources have to be built for each version it wants to support, right? Maybe current is an arbitrary, unjustified choice, but it means that C modules which only build once don't will only work with that version. You’re talking about XS-Python-Version: current. I don’t think there is any possible discussion about XB-Python-Version: current, which doesn’t mean anything at all. XS-Python-Version: = 2.x declares something useful for the packaging tools: that python versions starting from 2.x are supported. (Note that this could also be read directly from the build-depends, but well, people like adding useless fields to the source packages.) XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. In the real world, there is no need for this information. The packaging tool can detect much more reliably the versions for which the extension was built *after* they have been built (which is what python-support has always been doing). And since the maintainers don’t understand the difference between all and current (rightfully, since there isn’t any real difference), the real-world packages don’t fill this field as Matthias intended it. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Josselin Mouette wrote: XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. I'm not sure what you mean. If a module is only built for one version, then the other versions are not supported. Or by supported you mean that the module would eventually work with another python version if compiled for it? -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 22:06 +1100, Felipe Sateler a écrit : Josselin Mouette wrote: XS-Python-Version: current means the following: even if several Python versions are available, the module will only be built for the default version. *This declaration has nothing to do with the supported Python versions.* If we really needed it, it should go in another field. I'm not sure what you mean. If a module is only built for one version, then the other versions are not supported. Or by supported you mean that the module would eventually work with another python version if compiled for it? Yes, and actually it *will* work with another Python version when it becomes the default. The fact that it is only built for the default version is a detail of the build system, and it has nothing to do with the list of supported versions. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit : I really like the idea of using the same location for both tools, please note that you'll have to change pycentral to use something like /usr/lib/pyshared (for Python extensions) where is the advantage of having a /usr/lib/pyshared? Robustness. When you have a directory of Python modules that is an autogenerated symlink farm, you need to be able to rebuild it from scratch if anything goes wrong. This brings the packaging helper to the same level of robustness as dpkg itself. I don't like python ( X.Y) dependencies, it's so... old-policy like. Not a good idea, IMHO well, just not liking is a weak argument. Having to regularly re-upload all architecture-independent packages without any gain sounds like a less weak one. As I did write above, the support for namespace packages should be implemented using diversions. It's ok to generate these by a packaging helper. Generating diversions automatically is doomed to fail. Diversions are fragile, and they should be the exception, not the rule. What do you do when more than 2 packages need the same empty __init__.py ? -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 15:03 +0100, Bernd Zeimetz a écrit : - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. You really can’t say I’m not trying to discuss. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Hi Joss, On Dienstag, 17. Februar 2009, Josselin Mouette wrote: You really can’t say I’m not trying to discuss. I'm not sure if one cannot say this, as you nicely show in the following words that you definitly totally fail to discuss :( But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Python related changes for unstable/squeeze
On Tue, 2009-17-02 at 17:09 +0100, Holger Levsen wrote: Hi Joss, On Dienstag, 17. Februar 2009, Josselin Mouette wrote: You really can’t say I’m not trying to discuss. I'm not sure if one cannot say this, as you nicely show in the following words that you definitly totally fail to discuss :( I disagree. Joss is posting to the list. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. Joss says that Matthias has been unresponsive for years. That could be a factual statement ... I think you might give Matthias some time to respond himself before jumping in. regards, Holger -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ITP: skype4py -- Skype API wrapper for Python
Package: wnpp Owner: David Spreen netzw...@debian.org Severity: wishlist * Package name: skype4py Version : 1.0.31.1 Upstream Author : Arkadiusz Wahlig y...@nokix.pasjagsm.pl * URL or Web page : https://developer.skype.com/wiki/Skype4Py * License : BSD Style License Description : Skype API wrapper for Python Category: contrib I intend to co-maintain skype4py (the binary package is called python-skype) with Rafael Laboissiere raf...@debian.org, who prepared unofficial packages at http://alioth.debian.org/~rafael/skype/. We plan to do this within the Debian Python Modules Team, if the team agrees. The packages above need some work, particularly the copyright file points to the wrong license and the author is not mentioned. Moreover, the package needs to be updated to the newest version. If DPMT is okay with this, Rafael would like to transfer the package into the team svn so we can begin the work. Best Wishes, David Spreen -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 6:44 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 15:03 +0100, Bernd Zeimetz a écrit : - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. You really can't say I'm not trying to discuss. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. But those should be resolved by discussing it on the list, coming to a consensus and then fixing it by merging the packages or starting from scratch. Josselin, it's true that if you were discussing with me in the same tone as you are with Matthias, it will not make me very happy (as many people have pointed out), but I appreciate that you discuss and reply to criticisms and that's the most important. So Matthias, please, try to come to this list and get this resolved once and for all. Failing to discuss and pushing things your way is bad. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Le mardi 17 février 2009 à 10:09 -0800, Ondrej Certik a écrit : Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. I’d be happy to hear these reasons; I’m always eager to improve python-support when there is room to. Currently I know one reason why you could consider python-central better: this is because it installs files at the same place the upstream packages do. This avoids breaking some (bad) packages’ expectations. I have two remarks about this: * The python-support README has documented for long how to work around this problem if you encounter it (remember it concerns a handful of packages). * If python-support was the only tool to write files to /usr/lib/pythonX.Y/site-packages, there would be no problem with using this directory. However there are packages using python-central and packages shipping files directly there, so it is simply not possible without losing the advantages of python-support (like, not introducing 50 RC bugs every time something is changed). Besides, I could show you several reasons why python-support is superior, and at least one why python-central is broken. Josselin, it's true that if you were discussing with me in the same tone as you are with Matthias, it will not make me very happy But I am not using this tone with you, and the reason is that you are behaving correctly. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
OoO Lors de la soirée naissante du mardi 17 février 2009, vers 17:09, Holger Levsen hol...@layer-acht.org disait : This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Hint: it takes two to discuss. If I were Matthias and would read those statements, I probably wouldnt see added value in talking to you neither. IMO, this is unfortunate but it is really difficult to discuss with Matthias. Most comments are just ignored. For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474630 Matthias made a short statement about the problem and ignored the rest of the discussion. I had to switch to python-central to solve this bug. Josselin added a functionality to python-support to circumvent this limitation. Here is another example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440 Some fixes were proposed to circumvent this problem but bug was just marked as won't fix. This hits all users using easy_install (which is fairly popular among Python developers). And this bug is in Lenny. -- A TRAINED APE COULD NOT TEACH GYM A TRAINED APE COULD NOT TEACH GYM A TRAINED APE COULD NOT TEACH GYM -+- Bart Simpson on chalkboard in episode AABF15 pgp2g2lBuYQQM.pgp Description: PGP signature
Re: Python related changes for unstable/squeeze
[Matthias Klose, 2009-02-16]
Piotr Ożarowski schrieb:
- 2.5 is superseded by 2.6; currently there doesn't seem to be
a reason to ship 2.5 and modules for 2.5 with the next stable
release. The upstream 2.5 maintainance branch doesn't see bug
fixes anymore, only security releases will be made from this
branch.
What about a smooth upgrade path for those who use Python2.5 for their (3rd
party) applications? I think Python 2.6 should be default in Squeeze and
Python
2.42.5 in supported.
FTR: I meant 2.5 in supported and 2.4 in semi-supported (as in only
Zope related modules should be supported for this version)
always having the default version of the stable release included in the next
release would mean that Debian releases keep up with Python release, or we
would
end up shipping more than two 2.x versions. Same if 2.7 gets released in time.
what if administrators will install some local applications that will
have python2.5 hardcoded in shebang? Do you want to provide
python2.5-python2.6 symlink? I'm not sure it's a good idea. Are you
sure Python 2.6 (and all modules/extensions) are 2.5-compatible? Or do
you simply want to add an instruction in release notes what to do in
such situation (but then again: are you sure 2.6 and 2.5 are compatible?)
/usr/local/lib/pythonX.Y/site-packages will only be used if you install your
own python, and use this interpreter to call setup.py install. When using the
python (= 2.6) provided by Debian without to call setup.oy install
--install-layout=deb, the installation will go to
/usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to
/usr/lib/pythonX.Y/dist-packages.
/usr/local/lib/pythonX.Y/site-packages should definitely *not* be
symlinked to /usr/local/lib/pythonX.Y/dist-packages then (and vice versa)
I really like the idea of using the same location for both tools, please
note
that you'll have to change pycentral to use something like /usr/lib/pyshared
(for Python extensions)
where is the advantage of having a /usr/lib/pyshared?
it's one of the sacrifices you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
Once we'll agree on the paths, I will rise another problem I want to
discuss before we'll start converting packages but lets leave it for
later (note that I don't want to merge both tools, it's not possible, I
want a situation where one helper can ConflictProvide the other one -
yeah, you'll say it's not possible! You're crazy! - we'll see about
that :-)
Oh, one more thing: for now, I'm using both helper tools (to be aware of
their advantages/disadvantages and to be able to help my sponsorees -
please note that I never forced my sponsoree to use one of the helpers -
see FAQ#2 [1]), it's time however to decide which one will be my
winner - I'll decide that in next weeks (maybe months, but it
will happen sooner than later - my packages in Squeeze will use one
helper only!) and once I decide that, I will force all my sponsorees to
choose the same one (by refusing to upload package that uses the other
one)
IMNSHO
[placeholder for all those who want to make jokes about what I wrote in
next few lines - feel free to also make fun of me on #debian-python - at
least I will feel a little bit better after writing so many immodest
stuff ;]
If you care how many packages are using your tool, my preference should
matter to you as I'm the one who sponsored more Python related Debian
packages than anyone else in Debian - right now no one else has more
sponsored packages on QA page than I do (Anibal listed first on this[2]
page has less sponsored packages) and besides Sandro and Bernd, I'm the
only one who does regular sponsoring in PAPT and DPMT (which are
becoming more popular every day, there are rumors about magic way to get
a Python related package very well reviewed and really fast sponsored in
Debian even on #ubuntu-motu and people are prefering to do this via
Debian, really!) - I will also try to convince Bernd, Sandro and few
other DDs (Ana: that includes you! :) to use the same helper.
anyway, my army[3] and I can make a difference when it comes about
popconf stats. ;-P
[1] http://people.debian.org/~piotr/sponsor
[2] http://merkel.debian.org/~myon/sponsorstats/
[3] http://people.debian.org/~piotr/sponsorees.png
I don't like python ( X.Y) dependencies, it's so... old-policy like.
Not a good idea, IMHO
well, just not liking is a weak argument.
that's OLD-POLICY-LIKE, that should be enough argument, IMO ;-P
Providing
Re: Python related changes for unstable/squeeze
Le mercredi 18 février 2009 à 01:20 +0100, Piotr Ożarowski a écrit :
where is the advantage of having a /usr/lib/pyshared?
it's one of the sacrifices you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
It seems that there is one thing you got wrong here. /usr/lib/pyshared
will be for C extensions and data that varies from a Python version to
another (like /usr/lib/python-support/$package currently). It is not the
place where the symlinks and byte-compiled files will land after running
the script.
For this last thing, I initially thought of
using /usr/lib/pythonX.Y/python-support, but I guess the rtinstall
script of python-central will mess with that directory, so in the end
I’d prefer to find something else. Maybe /usr/lib/pymodules/pythonX.Y ?
Please also note that pysupport has a nice feature (that IMO should be
disabled by default, though (I'll file a bug soon), of byte compiling
modules for officially not supported Python versions (if installed *and*
maintainer claims it's compatible with that version) - this helps f.e.
if one installed python2.6 right now (or python2.5 in Etch)
Actually, it’s just that the supported list in python-support is
maintained separately from that of python-defaults. The reason is that
the pyversions script cannot be reliably used from maintainer scripts.
See #396840 for part of the explanation.
--
.''`. Debian 5.0 Lenny has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`-me that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
Le mercredi 18 février 2009 à 02:23 +0100, Piotr Ożarowski a écrit :
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
OK, I misunderstood you then :)
Any comment on the module installation directory? Is /usr/lib/pymodules
fine for you?
--
.''`. Debian 5.0 Lenny has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`-me that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 10:34 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 10:09 -0800, Ondrej Certik a écrit : Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. I'd be happy to hear these reasons; I'm always eager to improve python-support when there is room to. Currently I know one reason why you could consider python-central better: this is because it installs files at the same place the upstream packages do. This avoids breaking some (bad) packages' expectations. I have two remarks about this: * The python-support README has documented for long how to work around this problem if you encounter it (remember it concerns a handful of packages). * If python-support was the only tool to write files to /usr/lib/pythonX.Y/site-packages, there would be no problem with using this directory. However there are packages using python-central and packages shipping files directly there, so it is simply not possible without losing the advantages of python-support (like, not introducing 50 RC bugs every time something is changed). Besides, I could show you several reasons why python-support is superior, and at least one why python-central is broken. I forgot already what those reasons were, Matthias told me in Prague and they seemed reasonable to me. In fact, we were having a similar flame discussion about python-central and python-support just before the summit on this list and the result of which was (to me, as a bystander) that python-support is clearly superior, so I asked Matthias about it, and he provided some good arguments for python-central. But these arguments should be put on the list and things should get discussed and fixed. Anyway, I think now it's Matthias' turn to come forward and also do a few steps to get this discussed and eventually fixed. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
[Piotr Ożarowski, 2009-02-18]
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
and by that I mean /usr/lib/py{3,}shared/python2.5,
/usr/lib/py{3,}shared/python2.6 and so on (including .py files that are
not suitable for /usr/share/py{3,}shared)
/me really goes to bed
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpvzCW3mFzIM.pgp
Description: PGP signature
Compiled bytecode files location (was: Python related changes for unstable/squeeze)
Piotr Ożarowski pi...@debian.org writes:
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff
is probably the worst of it's bugs, but maintainer is aware of this
and will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
I saw no response to Message-ID: 87skwceynw@benfinney.id.au on
this forum, but would love to be convinced this will be fixed. This is
probably the last remaining issue keeping me with ‘python-central’ for
my packages.
--
\ “He may look like an idiot and talk like an idiot but don't let |
`\ that fool you. He really is an idiot.” —Groucho Marx |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 6:03 AM, Piotr Ożarowski pi...@debian.org wrote: [Matthias Klose, 2009-02-16] Besides the normal pending update of the python version for the unstable distribution, there will be more changes around python packaging, including the introduction of python-3.x and addressing some packaging issues. How do other distributions deal with these issues? Will the need for special per-tool directories ever be obsoleted by upstream? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
