Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 12:44:36AM -0400, Scott Kitterman wrote: On Wednesday, June 23, 2010 11:08:47 pm Paul Wise wrote: On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman deb...@kitterman.com wrote: The email is meant to go to the release team to address what I understand to be release team specific requirement. I think that the broader question needs to be discussed in a broader audience. I think it is relevant there as well, IIRC folks from the then release team were behind the move from python2.X-foo to python-foo modules. OK. I'll include them in that discussion, although I think what we are proposing now is entirely unrelated to that decision. As one of the aforementioned release team members, I agree. When module compatibility between python2.x and python3.x is not the common case, I don't think the arguments for consolidating on python-foo apply here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposed Email to the release team about XS/B-P-V
Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
5. End this madness and use the version in build-dependencies instead of
asking maintainers to specify it twice - which they usually do wrong.
With this approach then with the current python-defaults in Sid, how would
one specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (= 2.5), python{-all} (= 2.7)
Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
Also how does that intersect with needing specific package features to
build (e.g python-all (= 2.6.5-2~) because I switched from
python-central to dh_python2)?
I'd love to just specify it once if we can do it in a reasonably
non-convoluted and complete way.
Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
requiring it.
--
.''`.
: :' : “Fuck you sir, don’t be suprised when you die if
`. `' you burn in Hell, because I am a solid Christian
`-and I am praying for you.” -- Mike
--
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/1277361894.29067.2.ca...@meh
Re: Proposed Email to the release team about XS/B-P-V
[Josselin Mouette, 2010-06-24]
Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
5. End this madness and use the version in build-dependencies instead of
asking maintainers to specify it twice - which they usually do wrong.
With this approach then with the current python-defaults in Sid, how would
one specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (= 2.5), python{-all} (= 2.7)
Since a python-all version of 2.6 may at different times reflect b-d on
2.5, 2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
it gets a little bit messy when minimum required Python version is
greater than the default one, but it should work, yes (IIRC last year
someone gave me example where it wouldn't work, but I don't remember it
now, hopefully it will be pointed out again soon)
example for default=3.1 minimum=3.2 maximum=3.5:
python-all | python-all (= 3.2), python-all ( 3.5), python-all (= 3.1.2-2)
or even
python-all (= 3.1.2-2) | python-all (= 3.2), python-all ( 3.5)
I will implement it in dh_python3 (only = X.Y and X.Y will be
taken into account, I will ignore all .* X\.Y.* including X.Y-Z)) and
use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version
is not available (in that order)
Also how does that intersect with needing specific package features to
build (e.g python-all (= 2.6.5-2~) because I switched from
python-central to dh_python2)?
I'd love to just specify it once if we can do it in a reasonably
non-convoluted and complete way.
Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
requiring it.
it's not required
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20100624072719.gt18...@piotro.eu
Re: Proposed Email to the release team about XS/B-P-V
[Piotr Ożarowski, 2010-06-24] [Josselin Mouette, 2010-06-24] example for default=3.1 minimum=3.2 maximum=3.5: python-all | python-all (= 3.2), python-all ( 3.5), python-all (= 3.1.2-2) or even python-all (= 3.1.2-2) | python-all (= 3.2), python-all ( 3.5) err, python3-all of course I will implement it in dh_python3 (only = X.Y and X.Y will be taken into account, I will ignore all .* X\.Y.* including X.Y-Z)) and and .* X\.Y.+ here use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version is not available (in that order) or drop debian/pyversions and XS-Python-Version from above list -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100624073755.gu18...@piotro.eu
Joining Debian-Python
Hi, I'm requesting to join Debian-Python to work on NLTK. My alioth account is pabloduboue-guest and I usually hang out on #debian-nyc as DrDub. Best regards, Pablo -- 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/aanlktin2jsray_asbdfvl1y1qylbho29gdepfgttt...@mail.gmail.com
Re: Joining Debian-Python
Hi Pablo, thanks for your interest in joining our team! On Thu, Jun 24, 2010 at 10:06, Pablo Duboue pablo.dub...@gmail.com wrote: My alioth account is pabloduboue-guest and I usually hang out on #debian-nyc as DrDub. Just one suggestion: since you already use IRC, you might also want to join #debian-python on OFTC network: in case you'll need help and/or sponsorship, it's the fastest way Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlktin1gdujqi6wdmn-vygkbtj70p4uxiymsqok8...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
* Piotr Ożarowski pi...@debian.org, 2010-06-24, 09:27:
5. End this madness and use the version in build-dependencies
instead of asking maintainers to specify it twice - which they
usually do wrong.
With this approach then with the current python-defaults in Sid, how
would one specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (= 2.5), python{-all} (= 2.7)
Since a python-all version of 2.6 may at different times reflect
b-d on 2.5, 2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
it gets a little bit messy when minimum required Python version is
greater than the default one, but it should work, yes (IIRC last year
someone gave me example where it wouldn't work, but I don't remember it
now, hopefully it will be pointed out again soon)
XSPV is currently used for two things:
1. cdbs/dh7 etc. use it to iterate over Python versions to build,
install etc. stuff.
2. pysupport/pycentral etc. use it to determine for which Python
versions pure-python modules are bytecompiled.
Point 1 is related to build-dependencies, but not everyone use
cdbs/dh7. Point 2 has nothing to do with build-dependencies. Using
build-dependencies as replacement of XP3V is just semantically wrong.
Here are some real world examples (for 2.X, but that's irrelevant):
* A module that works perfectly with every Python = 2.5, but its
documentation generation system required Python 2.6. Build-dep on
python (= 2.6) is needed, which doesn't mean that modules shouldn't be
byte-compiled for 2.5.
* A module with no upstream build-system, which works only with Python
2.5. Build-dep on python normally isn't needed at all, yet one should be
able to specify which Python version are supported by this module.
example for default=3.1 minimum=3.2 maximum=3.5:
python-all | python-all (= 3.2), python-all ( 3.5), python-all (= 3.1.2-2)
or even
python-all (= 3.1.2-2) | python-all (= 3.2), python-all ( 3.5)
This is neither human readable nor human writable.
I will implement it in dh_python3 (only = X.Y and X.Y will be
taken into account, I will ignore all .* X\.Y.* including X.Y-Z)) and
use it if -V, debian/pyversions, X-Python-Version and XS-Python-Version
is not available (in that order)
If you implement this, I will refrain from doing any QA work on
python3-* packages. Have fun.
--
Jakub Wilk
signature.asc
Description: Digital signature
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski pi...@debian.org wrote: * A module that works perfectly with every Python = 2.5, but its documentation generation system required Python 2.6. Build-dep on python (= 2.6) is needed, which doesn't mean that modules shouldn't be byte-compiled for 2.5. python (= 2.6-1~) | python (= 2.5) (note that buildds ignore everything after |) I don't think that relying on the current behaviour of the buildds to make semantically incorrect build-deps work is a great idea, even if that behaviour never changes. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- 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/aanlktimiojzbkoggkwuuqpqks0o4whuktqlfnka1r...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
Josselin Mouette j...@debian.org wrote:
Le mercredi 23 juin 2010 à 21:17 -0400, Scott Kitterman a écrit :
5. End this madness and use the version in build-dependencies instead of
asking maintainers to specify it twice - which they usually do wrong.
With this approach then with the current python-defaults in Sid, how would
one specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (= 2.5), python{-all} (= 2.7)
Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
2.6, and/or 2.7 versions, this isn't clear to me.
Indeed, but I doubt this is a real problem.
Also how does that intersect with needing specific package features to
build (e.g python-all (= 2.6.5-2~) because I switched from
python-central to dh_python2)?
I'd love to just specify it once if we can do it in a reasonably
non-convoluted and complete way.
Then at the very least, make your X-Whatever-Ugly-Hack opt-in instead of
requiring it.
If there is concurrence from the release team that there is no need to expose
this externally then I don't see a need to require it. It would be part of a
tool set, but up to the package maintainer if they use it.
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/e318c32f-76fb-43ce-9e5b-9985f0392...@email.android.com
Re: Proposed Email to the release team about XS/B-P-V
Il giorno Wed, 23 Jun 2010 13:15:46 -0400 Scott Kitterman deb...@kitterman.com ha scritto: I have consulted with Luca Falavigna (DktrKranz) and Jakub Wilk (jwilk), who did most of the analysis for the last two Python transitions (Adding 2.6 to supported versions and the current transition to 2.6 as default) and neither of them found this embedded information useful in their analysis. They did their work based on package dependencies. I conducted my analysis in order to provide binNMUs for python2.6 as supported version using the method explained at [1]. Fields were used only marginally to exclude some false positives, most of the job was done by looking at package content, generated by helpers rather than XS-P-V or equivalent. Those could be completely ignored in case a stricted dependency had been in place (e.g. python ( 2.6)). [1] 20100123201506.35c9d...@utumno -- .''`. : :' : Luca Falavigna dktrkr...@debian.org `. `' `- signature.asc Description: PGP signature
versioned .so files (over in python-dev)
For those of you not closely following python-dev, I've made a proposal for versioned .so file naming for Python 3.2. It would allow us to place extension module .so files for different Python versions (or really, Python builds, e.g. 3.2/3.3, debug, UCS2/4, etc) in the same directory without naming collisions. The thread starts here: http://mail.python.org/pipermail/python-dev/2010-June/100998.html Except as it specifically impacts Debian, it's probably best to comment on the proposal over in python-dev. -Barry signature.asc Description: PGP signature
Re: versioned .so files (over in python-dev)
* Barry Warsaw ba...@python.org, 2010-06-24, 17:31: For those of you not closely following python-dev, I've made a proposal for versioned .so file naming for Python 3.2. It would allow us to place extension module .so files for different Python versions (or really, Python builds, e.g. 3.2/3.3, debug, UCS2/4, etc) in the same directory without naming collisions. The thread starts here: http://mail.python.org/pipermail/python-dev/2010-June/100998.html Except as it specifically impacts Debian, it's probably best to comment on the proposal over in python-dev. What's the point in making distutils produce versioned .so? Such a change is going to break lots of packages for exactly zero benefit: helper tools will need to do unversioned-versioned renames anyway, in order to handle non-distutils build systems. -- Jakub Wilk signature.asc Description: Digital signature
Re: versioned .so files (over in python-dev)
On Jun 24, 2010, at 11:58 PM, Jakub Wilk wrote: What's the point in making distutils produce versioned .so? Such a change is going to break lots of packages for exactly zero benefit: Why so? helper tools will need to do unversioned-versioned renames anyway, in order to handle non-distutils build systems. Such helper tools will still need to know what versioned names Python will import. Having it in distutils will make the common case easy. It does indicate that external tools will need to know what names a particular Python build supports. It probably shouldn't be hardcoded. -Barry signature.asc Description: PGP signature
