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
Re: versioned .so files (over in python-dev)
* Barry Warsaw , 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
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: Proposed Email to the release team about XS/B-P-V
Il giorno Wed, 23 Jun 2010 13:15:46 -0400 Scott Kitterman 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 `. `' `- signature.asc Description: PGP signature
Re: Proposed Email to the release team about XS/B-P-V
"Josselin Mouette" 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
On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski 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
[Jakub Wilk, 2010-06-24]
> * Piotr Ożarowski , 2010-06-24, 09:27:
>> 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.
... which use py{,3}versions command¹ to get the list of supported
Python versions
[¹] just like all other packages that do not use cdbs/dh7 should do
[...]
> 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.
python (>= 2.6-1~) | python (>= 2.5)
(note that buildds ignore everything after "|")
> * 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.
well, right now python is pulled in anyway (via python-central or
python-support build dependency). If a package doesn't use helper
tools, it doesn't use XS-Python-Version as well.
>> 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.
most packages will have "python3-all (>= 3.1.2-2)" only
>> 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.
ok, postponing
--
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/20100624103545.gw18...@piotro.eu
Re: Proposed Email to the release team about XS/B-P-V
* Piotr Ożarowski , 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: Joining Debian-Python
Hi Pablo, thanks for your interest in joining our team! On Thu, Jun 24, 2010 at 10:06, Pablo Duboue 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
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: 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
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
