Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 10:46:33PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). It works fine without it only in the sense that it has to re-generate it before the program can run. Much like any compiled form of a program. + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. This property still makes it change only when the packaging system upgrades or installs software. If it only changes at that time, it still seems more appropriate for /usr/ than /var/. Well maybe, I must say I've really no hard feelings on the matter, just it looks right that way to me :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpNNVa0NjRHQ.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 07:55:44AM +, Emilio Pozuelo Monfort wrote: Pierre Habouzit wrote: This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Even if you package doesn't work with some supported Python versions? (e.g. it uses the finally clause) Then you then don't have set XS-P-V to all, but something like = 2.4 e.g., or 2.4- in the pysupport syntax. And the result SHOULD be XB-PV: 2.4- too. So that when python 2.6 arrives, your package doesn't need to be rebuilt or whatever. IOW for arch:all packages, XB-PV should be the same as XS-PV, not the intersection betweel XS-PV and available python version at the time of the build. And again, it's what dh_pysupport does, and it's the proper thing to do. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKCg3S1qjsk.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. The .py files live in /usr/share. pysupport is supporting FHS to the letter. On the other side, pycentral puts things where they were installed, and pyc along them. That's why you find _totally_ arch indep .py files live in /usr/lib/python2.5, because they must go along with .pyc files and puting them in /usr/share where they belong would break because of .pyc files. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. pysupport is forward compatible with such a possible change in python, it would _just need_ to stop doing its symlink farm and keep byte compiled stuff in /var/lib like it does right now. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpl8FyV9yXUK.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Tue, May 20, 2008 at 10:59:05AM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 11:20:10PM +, Ben Finney wrote: Floris Bruynooghe [EMAIL PROTECTED] writes: /var/lib : Variable state information [...] State information is data that programs modify while they run, and that pertains to one specific host. [2] Agreed. Complied-one-time-on-install Python library code is not variable state information; rather, it is an unchanging (modulo package-system changes) part of the system, so belongs in /usr somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. What makes you think 'foo.pyc' is /var material? Oh yes that seems obvious to me. In fact, I'd say it should be /var/cache material because: + it's not mandatory to have it, python works fine without .pyc, just (way) slower (which makes it /something/*cache* material per se). + it can be regenerated any time when a python version change (so that we can gain new optimizations in how bytecode is built e.g.) which makes it rather /var material rather than /usr. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. Agreed, and thank you for a wonderful use of the word scabrous :-) Heh, it's a Gallicism in fact, I mean it was a word to word translation of a quite current French expression ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbGy3AOjrUk.pgp Description: PGP signature
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 06:47:10PM +, Michal Čihař wrote: Dne Mon, 19 May 2008 18:38:25 +0200 Josselin Mouette [EMAIL PROTECTED] napsal(a): Le lundi 19 mai 2008 à 14:39 +0200, Michal Čihař a écrit : What surprised me is different handling of XB-Python-Version field. I have XS-Python-Version: current and python-central makes XB-Python-Version: current from this, what I feel is correct (package is pure Python, no dependency on Python version) and package Depends: python, what corresponds to this. If your package is pure python and doesn’t have a dependency on a python version, you should make it XS-Python-Version: all (or simply remove the field). Well I did this at the end. So now I get XB-Python-Version: 2.4, 2.5. But I see no reason why package should not work with 2.6. I'm just a bit confused that XB-Python-Version is more strict that generated dependencies. I thought these fields should match somehow... FWIW python-support doesn't have such restrictions, as it doesn't hardcodes into the binary it produces the current python versions that were available at the time of the build (which is by essence volatile information) it's forward compatible, which pycentral isn't. This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this should be XB-PV: all or something similar. Such information must be kept only for arch:any packages, where we must remember for which python versions the binary extensions have been built. Private or public extensions have the same requirement in that regard, it's just that private extensions can _only_ be built for one python version at a time. That was probably for them that current was invented in the first place I think. Though it's useless as the dh_py* helper can figure that out by himself, and it's exactly what pysupport does. Pycentral OTOH requires a declarative list from the maintainer in XS-P-V, _AND_ the maintainer to build what he claimed to have built, which may differ, which is brittle. pysupport just looks at what has been built and computes things from that only, which is way more robust, because information exists in a single place. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8DDvws3aFF.pgp Description: PGP signature
Re: Python modules not installed correctly with pycentral
On Mon, Jan 07, 2008 at 05:52:52PM +, Vincent Bernat wrote: OoO Pendant le temps de midi du lundi 07 janvier 2008, vers 12:50, Pierre Habouzit [EMAIL PROTECTED] disait: Le lundi 07 janvier 2008 à 07:56 +0100, Vincent Bernat a écrit : Well, if you can change the order for postinst, you will get wrong order in prerm. debhelper (5.0.44) unstable; urgency=low * prerm and postrm scripts are now generated in a reverse order than preinst and postinst scripts. For example, if a package uses dh_pysupport before dh_installinit, the prerm will first stop the init script and then remove the python files. Good news. I will check that it works and propose to close the bug I cited in another message. It does work. I have just tested and #386970 is still present with py_support at least. In postinst, I have first the snippet by dh_installinit and then the snippet by dh_pysupport. In prerm, I have exactly the same thing. you need to use compat level 6 for that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpL7wFn8jyko.pgp Description: PGP signature
Re: Report on the situation of python2.5 in Debian
On Fri, Oct 05, 2007 at 06:42:46PM +, Bernd Zeimetz wrote: Hi, Now, for the bad news. The following packages have various kinds of issues that prevent them from working with python2.5. Some of them are trivial, some are much more tricky. In all cases, we need to focus on these bugs if we want to see those packages in lenny: You have missed Zope. Zope is kind of outside the python policy because it always lags behind, and is dealt with in its own round, I presume that's why Joss didn't talked about it. Does the list include those packages which are not conform to the new Python policy? There're still several of them out there. A zero-day NMU policy would be good to have here, too. http://bugs.debian.org/from:[EMAIL PROTECTED];pend-exc=done;exclude=fixed Last time I checked, most of them weren't in testing for ages. But this wasn't thorough. Please note that they can all be binNMUed after python2.5 has become the default, but all of them will have to migrate to testing at once. We must make this list shorter unless we want this transition to recall bad memories to the release team. mod-wsgi It's not possible to use more than one python version with mod-wsgi, therefore it will only work and be build against the default python version. A binNMU after changing the version should work well. yes, for some packages it makes sense, Joss didn't asked for an empty list, merely a shorter one, and I agree with him. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpH9Vodhz2uc.pgp Description: PGP signature
Re: Report on the situation of python2.5 in Debian
On Fri, Oct 05, 2007 at 06:04:27PM +, Josselin Mouette wrote: Hi, I have conducted a thorough analysis of all packages preventing us from migrating to python 2.5. Thanks a lot for the work ! Now, for the bad news. The following packages have various kinds of issues that prevent them from working with python2.5. Some of them are trivial, some are much more tricky. In all cases, we need to focus on these bugs if we want to see those packages in lenny: [...] I request a zero-day NMU policy for these bugs. I second this. The following packages do not support multiple versions of python at once. This is where we have the most serious regression compared to the situation of the python2.4 transition. It is understandable not to rebuild the gimp or OpenOffice.org packages for several python versions, but many of these packages are using distutils and are therefore *trivial* to get to work with several versions. Please note that they can all be binNMUed after python2.5 has become the default, but all of them will have to migrate to testing at once. We must make this list shorter unless we want this transition to recall bad memories to the release team. Here is the list: [...] I also request a zero-day NMU policy for these issues, at least for packages using distutils. This is a tad aggressive as for some of the packages (see wcgi) it make sense to stay like that, and an NMUer that does 10 of those in a round may miss the reasons. I'd rather see a mass bug filling on those packages, and see the maintainers that feel their package should be built for one version only say it loud first. Then maybe we will consider making it RC. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpIrVrtIEZdl.pgp Description: PGP signature
Re: how to package trac modules?
On Sat, May 05, 2007 at 09:21:08AM +0200, Andreas Jellinghaus wrote: Hi, I'm trying to create packages of trac plugins at least for local use (Account manager, web admin). what is the best way to handle these? http://trac.edgewall.org/wiki/TracPlugins tells me they use ez_setup.py, but the whole automatic download stuff is the opposite of the traditional debian way with orig.tar.gz. You will have to download the sources yourself obviously :) also trac wants *.egg files in /usr/share/trac/plugins, that seems to be very far off the debian python policy. Well, hell no ! I don't think it's against the policy at all: /usr/share/trac/plugins is a private module path, hence it's OK to put .egg, .py or whatever. Though, when you'll use e.g. dh_pysupport, you'll have to pass it the path where you put your installed files as it won't be able to guess it, that's all. has anyone already looked into trac plugins? what is the best way to handle these? IMHO you should rather contact the trac maintainer on this issue, as he should be the one having the more clues and good advices here IMHO. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpxR6hBitaHw.pgp Description: PGP signature
Re: Proposed update to the python policy
On Tue, May 01, 2007 at 12:17:33AM +0100, Floris Bruynooghe wrote: Hi On Wed, Mar 28, 2007 at 08:39:42PM +0200, Pierre Habouzit wrote: wrt the current thingie, I may have a proposal ready soon, I just need to polish the details, and look how hard it would be to upgrade the dh_py* tools to them. Well, I've a hard week of paid work ahead, so I don't expect to have it ready before next week. So is there any sort of consensus about current then? How should we use it -- or avoid it? Or did I completely miss the conclusion of this discussion? Due to real life events (a son) I've not been able to draft the proposal I want to make. But basically, current semantics as is is quite broken and we are many to concur. I'll *try* to have something soon, for a fairly blurry definition of soon. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpD8ToV7sEJS.pgp Description: PGP signature
Re: Proposed update to the python policy
On Fri, Mar 23, 2007 at 05:08:22PM +0100, Josselin Mouette wrote: Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit : XB-Python-Type: multiple (compile for all installed [and supported by the package] Python versions) or single (only for one Python version) That looks good to me And how do you ensure that this matches what's actually done inside debian/rules? XB is a binary package header. It's up to the dh_tool responsibility to check that if the maintainer puts single and that there is multiple python obviously supported it's wrong, and it should make the package FTBFS. Obviously, the problem is harder when only one python version is supported at the time, as you cannot made the difference between the two. That's why I've not done any proposal yet, because the problem does not look obvious in the first glance. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4HR7FdPPua.pgp Description: PGP signature
Re: Proposed update to the python policy
On Fri, Mar 23, 2007 at 06:47:03PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 23.03.2007]
On Fri, Mar 23, 2007 at 05:08:22PM +0100, Josselin Mouette wrote:
Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit :
XB-Python-Type: multiple (compile for all installed [and supported by
the package] Python versions) or single (only for one Python
version)
That looks good to me
And how do you ensure that this matches what's actually done inside
debian/rules?
and how do we do this now? It works fine with python-central (it just
adds current to the XB-P-V)
XB is a binary package header. It's up to the dh_tool responsibility
to check that if the maintainer puts single and that there is multiple
python obviously supported it's wrong, and it should make the package
FTBFS.
FTBFS? Why? No mater for how many Python versions you build your module in
debian/rules, only one set of .py files is installed (in
/usr/share/python-support/ or /usr/share/pycentral/) - that doesn't
apply to .so files, but why should the build process fail? If more than
one .so file is build, only the right one should be installed.
Maintainer have to know what single means and why he wants it. It
should not be used with normal Python modules (i.e. python-*
packages). If this field is not set, multiple should be assumed.
I think it can be detected automatically (f.e. by using mentioned
python-dev vs. python-all-dev dependency or dh_tool --single-version)
but if you think it's confusing, then setting it by hand shouldn't be a
big problem.
Obviously, the problem is harder when only one python version is
supported at the time, as you cannot made the difference between the
two.
Sorry, I don't see a problem here. This field cannot be set only by
checking for how many Python versions module was build at the build
time.
My point was: if the maintainer asks for a single packaging way, and
that the dh_tool finds a multiple package or the reverse, it should
complain, loudly. When it detects any kind of inconsistency in fact.
Here was what I tried to explain. Basically we just agree.
That's why I've not done any proposal yet, because the problem does
not look obvious in the first glance.
I know that it could be hard to understand me (I blame my English skills)
but I think you all understand the problem now and current will not
be removed from the policy. My packages are safe for now ;-)
Oh I think current will be removed from the policy as it is now.
Having it X?-PV is very confusing. THe current from pycentral can
remains where it is in XS-PV but that's an implementation detail from
pycentral, and won't be normative IMHO.
PS I thought it's time to think about merging py{central,support} but I
guess this discussion will end on current keyword.
No this discussion is about driving the remaining grey areas of the
policy from the needs that the policy has to fulfill rather than the
implementation details of the py* tools, which has been made for too
long.
Current was a big point of disagreement in the past, hence it has been
central in that discussion. It does not mean that we've forgotten the
rest :)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgp2u1e87jznT.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote:
[Tristan Seligmann, 22.03.2007]
* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and above, I can Build-depend on python-dev (= 2.5) |
python2.5-dev
and set XS-Python-Version: to current, =2.5
example packages: emma, pypar2, gaupol, griffith
could you explain me in which part 'current' is helping you here ? I
missed to understand what asking for:
XS-Python-Version: = 2.5
Doesn't this indicate that the package should be built for all versions
2.5 and up, rather than a single version?
yes, but since package is depending only on python-dev (and not
python-all-dev),
python-system should assume current by default (and add it to
XB-Python-Version
so that there will be no problems with recompilation of pyc files when 2.6
will become default)
exactly, putting current is just yet-another-place where the
maintainers declares that he will only prepare the package for current
python. And you're right, python-(all-?)-dev is a already here to give a
hint to the dh_tool about your intention. Excellent point.
and please tell me what it changed in the package you built with that.
I'm curious. Btw I don't think you answered the question properly, as
you didn't explained the think current achieves for you. And honnestly,
it's not a trick question, I mean it, what is its purpose for you. I
don't see its usefulness, but I may miss a thing :)
As I understood it, current indicates that the package should only be
built for one version of python, the version that is currently the
default version in Debian.
not necessary default (see current, =2.X where 2.X is greater than default)
but for single version only, yes. I understand it this way, but
apparently I don't understand current, though.
I think compiling (private or not) modules provided by
{emma,gaupol,grifffith,any
other Python application} for all supported Python versions is just a
waste of space.
For private modules, it's not possible to compile _or_ byte-compile it
for many python versions, because a private module lives in a non
versionned directory, hence you can't have it built for two python
version at a time. There is two cases though:
* either it's a pure python private module, and afaict, the case is
handled by dh_py* tools correctly, and nothing is needed from the
maintainer side.
* or it's a binary module, and then binNMU is mandatory.
When it's a public module, then well, I agree with Steve, it depends
on the popularity of the package. See zope e.g., it's always a python
version behind for many reasons, and people programming for zope will
want to be able to use any popular python module around. Not building
your module for them is a bad idea, so again here the case is twofold:
* either it's a pure python public module, and then, dh_py* tools will
handle an optimal byte compilation by themselves. Let them work like
that, it's exactly what is needed: if byte compiles only for python
versions that are installed on the user machine. There is absolutely
no waste here.
* either it's a binary module, and yes, then it has to be built by the
buildd, hence we can have some sort of waste, and the do you have a
lot of rdepends or not is the criterion to know if you should
provide modules for every supported version, or only default.
Just consider that when you are built for many python at the same
time, you ease the python default change a lot.
So there is pros and cons, and I now (with Steves remarks) believe
that this choice is indeed up to the maintainer. So as a matter of a
conclusion, we just need a way to make us aware that the maintainer
chosed one or the other.
I like your python-dev vs. python-all-dev remark, I really believe the
dh_py* helpers can use that when there is public binary modules involved
to know what the maintainer decided. For private modules, the task is
easy, and I know dh_pysupport knows how to detect them already, it would
just have to flag them in the Packages.gz somehow in order to help the
RMs.
Of course, that still leaves one corner case:
* there is only one python version supported (current scenario btw, we
only have python2.4) ;
* the package B-D upon python-all-dev ;
* the maintainer only builds for default.
This is the sole case when the dh_py* tools cannot verify if the
maintainer did correct stuff, but that's definitely a bug in the
package. Moreover we can add a lintian check for that: a package that
build-dep onto python-all-dev and do not use $(pyversions -s) has many
chances to be buggy.
I believe pieces are sticking together nicely.
Oh
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 07:50:35PM +0100, Josselin Mouette wrote: Le jeudi 22 mars 2007 à 14:50 +0100, Pierre Habouzit a écrit : exactly, putting current is just yet-another-place where the maintainers declares that he will only prepare the package for current python. And you're right, python-(all-?)-dev is a already here to give a hint to the dh_tool about your intention. Excellent point. Just nitpicking: the dh_ tool doesn't need to know that, as it can guess it from what was previously built. This is a hint for the release managers (to know which packages need a binNMU), and could be the base for a script automating the build process. It's not necessarily true: when there is only one python supported, you can't tell the difference between a package that only supports the default python, or any of them :) And the maintainer can change his mind too, so looking in the past packages looks brittle. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKEDkdGHW2O.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote:
current keyword is deprecated? Why? I'm using it a lot and I like
it...
What are you using it for exactly ? I mean, please give an example,
with an actual package, that would be okay. Because I'm 100% sure that
current is (1) not a good idea (2) not needed in fact.
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and above, I can Build-depend on python-dev (= 2.5) | python2.5-dev
and set XS-Python-Version: to current, =2.5
example packages: emma, pypar2, gaupol, griffith
could you explain me in which part 'current' is helping you here ? I
missed to understand what asking for:
XS-Python-Version: = 2.5
would haven't achieved. In fact, what I understand from current, is
that it designs python2.4 for now, so how is that accurate for your
example ?
I mean, try to set:
XS-Python-Version: = 2.5
and please tell me what it changed in the package you built with that.
I'm curious. Btw I don't think you answered the question properly, as
you didn't explained the think current achieves for you. And honnestly,
it's not a trick question, I mean it, what is its purpose for you. I
don't see its usefulness, but I may miss a thing :)
BTW: I like rest of your diffs (I don't know much about Python-Depends
control field, though)
PS Is it the right time to think about merging python-{central,support}
or is it to early for that?
It's only thinking for now, and I think it's really the moment to
think about further plans for lenny obviously.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpcgOXFuCLdd.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 10:38:30PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and above, I can Build-depend on python-dev (= 2.5) |
python2.5-dev
and set XS-Python-Version: to current, =2.5
example packages: emma, pypar2, gaupol, griffith
could you explain me in which part 'current' is helping you here ? I
missed to understand what asking for:
I could swear that with this keyword pycentral will set hashbang to
python2.5 (with python2.4 set as default) but apparently it doesn't (I
just tested it with emma), it just sets Depends: to python (=2.5) |
python2.5, just like pysupport do with 2.5- in debian/pyversions
file.
is it a bug in both pycentral and pysupport?
No it was my point: current does nothing. In fact, for the very
example you propose it serves no end at all :)
PS Is it the right time to think about merging python-{central,support}
or is it to early for that?
It's only thinking for now, and I think it's really the moment to
think about further plans for lenny obviously.
How about a vote about which one should be used in Lenny? I mean, both
vote sucks, I'd really prefer to see a real solution be drafted. IMHO
the vote should be the last resort.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgprQUvf3vSIs.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 03:14:27PM -0700, Steve Langasek wrote: On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote: Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit : On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote: If this is a public extension, this goes completely against the spirit of the policy and should not be allowed. It just means more packages having to migrate simultaneously with python-defaults. It's not against the spirit of what was discussed in Mexico, it's just against the spirit of what you personally think. I'm not the one who suddenly declared all packages complying with the old policy RC-buggy. WTF? Neither did the release team. Do I understand that we can drop all the multi-version stuff now? Who's we? Please (and it's meant as much to both of you) that part of the thread is going nowhere useful. We can avoid this easily, shall we ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp0DpVKLrfwH.pgp Description: PGP signature
Re: module package naming
On Wed, Mar 21, 2007 at 08:46:35PM +0100, Thomas Jollans wrote: Hi, the debian python policy states that module packages should be named python-foo, foo being the module name. I intend to package PySyck, which contains the module/package 'syck', which is also in python-syck (AFAICT PySyck is basically a fork of the upstream bindings). Would python-pysyck be a reasonable name for the package, or is something else more adequate ? If the module name is syck and that there already is a python-syck then you're going into trouble, because you will have conflicts between the two. you should call a package python-$(foo) if to use it you have to import $(foo). At least it's what the policy says, and it's IMHO sane. And if you have two different libraries providing the same module $(foo) they can't be installed at the same time. In that case, well, I don't really know what to say. Having two things not really the same called the same suck. I hardly see someone fork the openssl and say that the new lib would be called libssl too. That would be disastrous. That's the same here IMHO. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjqGRKVJLej.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: If we don't, I don't see the purpose of the policy alltogether. Allowing transitions between default versions of python without package renames, bypassing NEW, allowing binNMUable transitions, and generally simplifying the python upgrade path for users across releases. Supporting multiple binary extensions in a single python-foo package is a tool that *facilitates* that goal, but it was *never* supposed to be mandatory. There are extensions with no/few reverse-dependencies and a small install base, such that supporting multiple versions of python is useless archive bloat. Evidently everyone has lost sight of this I see. What does current has to do with it then ? in the current state of affairs, nothing prevent the maintainer to only build the package for $(pyversions -d) only, which would be: (1) binNMUable (2) only built for the current python version as per spec of what you want to achieve. I think I don't say anything foolish here, and that current was not a requirement. Though, I know what you will argue next, it's that you need (as a RM) to be able to compute the list of packages needing to be queued for binNMU. I've not evaluated yet if current helps here or not (I don't think so, but I've nothing to backup that assertion yet, so I wont say anything until I've a good and minimal solution to propose). as a result of Josselin's process hijacking. Oh well. Bleh, I think we can avoid that part :) I don't want to point fingers, but to find solutions. Really. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXiV1CCpJFv.pgp Description: PGP signature
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
[Steve Langasek, 21.03.2007]
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
I think depending on python-dev for current only modules/apps and
python-all-dev for the rest should be enough (if both systems will
recognize it correctly, I mean also: python-dev(=2.5)|python2.5-dev )
No, this has nothing to do with the question of being able to get the
version number of, and build binary extensions for, the current version of
python.
how about this:
^^^
case 1: emma - python application that installs private module
Build-Depends: python-dev (= 2.5) | python2.5-dev
XS-Python-Version: =2.5
Architecture: all
case 2: emma - python application that installs private module (and lets
say it is providing private python extension as well)
Build-Depends: python-dev (= 2.4) | python2.4-dev
XS-Python-Version: =2.4
Architecture: any
case 3: sqlalchemy - python module
Build-Depends: python-all-dev
XS-Python-Version: =2.3
Architecture: all
case 4: pywavelets - python extension
Build-Depends: python-all-dev
XS-Python-Version: =2.4
Architecture: any
and I expect python-system to:
case 1:
* compile it for current Python version only (no binNMU needed after
default Python version change, just recompile the module on user's
machine)
for a pure module or a binary one ?
* set XB-Python-Version to current, 2.5 # here current can't be
deprecated,
but this field should be filled automatically (think ${python:Versions})
so maintainer doesn't have to know about current
current, 2.5 has no sense at all, at least today, as current is
(today) meaning: please build that for python2.4
* change hashbang if needed (and remember about it [also in in
XB-Python-Version
probably] - what if Python version from versioned hashbang will be
removed from supported Python versions?)
hashbang should always be /usr/bin/python as soon as the default
version is supported. We implicitely assume that as soon as a X.Y python
is supported, next version will. This is safe for 99% of the packages.
But IMHO the new policy doesn't help you if your package doesn't
support the current default python. I mean, there is obviously tricks in
the debian/rules that are possible to render the package binNMUable, but
I don't think the dh_py* tools can help here. But I may be mistaken.
case 2:
* as above, except binNMU is needed after default python version change, no
need
to remember hashbang change
A default python change only requires to binNMU packages that have
private binary modules. _or_ packages with binary extensions that were
only built for the old default version and not others.
So for your example, indeed, you have to build only for $(pyversions -s).
case 3:
* build for all supported python versions (that are =2.3)
* set XB-Python-Version to 2.3 (or 2.3-)
* no binNMU needed, just recompile after `pyversions -s` will change
no recompilation is needed in that case, even if pyversions -s
changes.
case 4:
* as above, binNMU needed
* XB-Python-Version: =2.4
* Provides: python2.4-wavelets
no binNMU is needed here either for a default python change. It is
recommended for a python version removal (to avoid to waste space) and
needed for the introduction of a new python (to support the new one).
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpz9r8cZemBg.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 04:50:30PM -0700, Steve Langasek wrote: On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote: On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: If we don't, I don't see the purpose of the policy alltogether. Allowing transitions between default versions of python without package renames, bypassing NEW, allowing binNMUable transitions, and generally simplifying the python upgrade path for users across releases. Supporting multiple binary extensions in a single python-foo package is a tool that *facilitates* that goal, but it was *never* supposed to be mandatory. There are extensions with no/few reverse-dependencies and a small install base, such that supporting multiple versions of python is useless archive bloat. I see. What does current has to do with it then ? in the current state of affairs, nothing prevent the maintainer to only build the package for $(pyversions -d) only, which would be: (1) binNMUable (2) only built for the current python version as per spec of what you want to achieve. In the original proposal, 'current' was the flag to tell the packaging tools that pyversions -d *should* be used. There is of course nothing that stops a maintainer from invoking pyversions -d manually; Okay I see. As a coder, I don't like it then, and I feel reinforced in my gut dislike of that field. current is declarative, and does not says anything about what the packager really put in his debian/rules. If he does not writes what has to be to multi-build the package, and that he does not puts current, well, the package basically will only be built for current. As you already acknowledge the reverse situation also holds. And as a matter of a fact, maintainers do not seem to understand what current is for, Piotr python2.5-only package is a very good example of this IMHO. the question is, how will doing so fit into the python policy, will there be support for automating this in the helper tools, and will packages that do this (and are therefore binNMUable for python transitions) be automatically detectable from the Sources and/or Packages files? like I say later, I knew it was what really matters for you. And IMHO it's really more interesting that the dh_py* tools explains what has really been built. They already do the job to generate the correct substs for python:Depends and python:Provides, so basically, the code to detect that exists. One just has to make it clear in the Packages.gz files. Like I said, I don't really think Sources.gz are relevant, as it's declarative from the maintainer PoV. But like said, I've not yet thought about all the consequences yet, and I do not know what's needed or not. I've the suspicion that XB-P-V could indeed be the way to go (even if for packages with modules Provides: show that information already), but I'm not sure that the current use of XB-P-V carries all the information we need. Though, I know what you will argue next, it's that you need (as a RM) to be able to compute the list of packages needing to be queued for binNMU. Exactly. :) I've not evaluated yet if current helps here or not (I don't think so, but I've nothing to backup that assertion yet, so I wont say anything until I've a good and minimal solution to propose). Ok, I look forward to hearing this proposal. Thanks. I'll try to make this proposal driven from our needs, and not trying to advantage this or that implementation of the dh_py* helpers, which was the ground of the argument when I joined this (mess ?) half a year ago. I think with your explanations, I quite understand the requirements from the user and packager point of view (NEW, number of packages efficiency, etc...), and I believe the sole other need is the ease to deal with transitions from the RM PoV and for that it needs to answer the 3 questions: * what should be binNMUed for a python version removal (assuming it was not default btw ;P), that one is easy IMHO: basically nothing _needs_ to, but: + packages with a strong dependency on that pythonX.Y and _no_ python dependency have to be dropped altogether (or likely need porting and are not binNMUable) ; + for space efficiency we could think of binNMUing every package that has built a public module for that particular python version. Here, XB-P-V is not needed if we have the Provides that is mandatory (and that is what Joss proposes, and I think it's sane anyway). * what should be done for a default python change: here concerned packages are: + packages with private binary extensions, + packages built only for the current python version. * what should be done for a new python: here concerned packages are _only_ packages that build public binary modules for more than
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 22.03.2007]
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
* set XB-Python-Version to current, 2.5 # here current can't be
deprecated,
but this field should be filled automatically (think
${python:Versions})
so maintainer doesn't have to know about current
current, 2.5 has no sense at all, at least today, as current is
(today) meaning: please build that for python2.4
How will python-system know to recompile it just for one version and not
for all supported ones?
Why would you prevent the user to bytecompile your package for every
python version he choose to install ? I see the point to avoid archive
bloat in not building every binary extension. But locally ? Well, that
seems wrong. Really.
Especially since the dh_py* tools will only byte-compile code for
python versions that are supported _and_ installed on the user machine.
For pure python packages current does not makes sense.
* change hashbang if needed (and remember about it [also in in
XB-Python-Version
probably] - what if Python version from versioned hashbang will be
removed from supported Python versions?)
hashbang should always be /usr/bin/python as soon as the default
version is supported. We implicitely assume that as soon as a X.Y python
is supported, next version will. This is safe for 99% of the packages.
But IMHO the new policy doesn't help you if your package doesn't
support the current default python. I mean, there is obviously tricks in
the debian/rules that are possible to render the package binNMUable, but
I don't think the dh_py* tools can help here. But I may be mistaken.
What if my application needs python2.X where X = Y+1 and Y is default
one? (I had this problem with gaupol when python2.3 was default, and
current, 2.4 worked just fine!)
then you ask for 2.4- and the dh_* tool will deal with things for the
dependencies. It's up to you to fix the hashbangs properly. But again,
dh_py* tools won't help you a lot for packages that do not _at least_
support pyversions -d. You will need to do some extra work.
But IMHO the whole point of that policy is that a move to a new python
(python2.5 here) can be done very fast, before there is too many
packages that only work with python2.5, meaning that there will be few
packages in that case, and that it will only be a transitionnal
situation for them.
case 4:
* as above, binNMU needed
* XB-Python-Version: =2.4
* Provides: python2.4-wavelets
no binNMU is needed here either for a default python change. It is
recommended for a python version removal (to avoid to waste space) and
needed for the introduction of a new python (to support the new one).
new supported python version is available, package provides .so files
and you say no binNMU is needed?
You definitely seem to have misread me.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpypgIZ5cTsR.pgp
Description: PGP signature
Re: Python PATH problem
On Wed, Jan 03, 2007 at 09:58:53AM +0100, Vincent Danjean wrote: Hi, I'm the maintainer of mercurial. At least one of the users has a problem with loading python modules. Can someone look at bug #382252 ? In short, echo 'import sys; print sys.path; from mercurial import bdiff' | python2.4 works on my system, but not on its one. Both have '/var/lib/python-support/python2.4' in sys.path Both have /var/lib/python-support/python2.4/mercurial/bdiff.so a symlink to /usr/lib/python-support/mercurial/python2.4/mercurial/bdiff.so that is a ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped from the strace he says that the package is searched under $path/bdiff.so instead of mercurial/bdiff.so like it should. though it searches in /usr/lib/python2.4/site-packages/mercurial/bdiff.so first. so my guess, but I may be wrong, is that there is old byte compiled things from your package before the new policy, and that when /usr/bin/hg does `from mercurial import mdiff` it finds the mdiff.pyc from /usr/lib/python2.4/site-packages/mercurial/mdiff.pyc mdiff.pyc does `import bdiff` and not from mercurial import bdiff. so it searches in paths stripped from the 'mercurial' part. and the user can't do from mercurial import bdiff either because /usr/lib/python2.4/site-packages/mercurial/ comes first in the path. I can't say I'm right here, you should ask the user, though if that's the case, then: (1) it's your fault (2) it's RC (serious) and that must be fixed for etch. (3) the solution is to rm -rf /usr/lib/python*/site-packages/mercurial/ (yes * because you presumably left python2.3 bytecode over too) from the postinst. you will be able to drop that upgrade stanza after the etch release. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOMFfbQ8ARu.pgp Description: PGP signature
Re: Bug#382252: Python PATH problem
# sorry pal but mishandling *.pyc files is a policy violation. severity 382252 serious thanks $ ls -l /usr/lib/python*/site-packages/mercurial/ [.. lots of *.pyc ..] Can you also tell me if you have installed mercurial from upstream sources ? he does not needs to, having run hg as root is enough to produce the *.pyc if your package (even against the previous policy) did not managed them. To Wouter: to resolve your problem, just rm -rf /usr/lib/python*/site-packages/mercurial. You can do that safely, that'll solve your problem. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQPEuCw8ya9.pgp Description: PGP signature
Re: Bug#382252: Python PATH problem
On Wed, Jan 03, 2007 at 01:10:42PM +, Sam Morris wrote: Josselin Mouette wrote: mdiff.py does import bdiff which looks for bdiff.so in the same directory. On your system, mdiff.py is is in /var/lib/python-support/python2.4/mercurial/ which is the correct place for packages handled by python-support, while on the user's system it is in /usr/lib/python2.4/site-packages/mercurial/. Therefore you need to understand how the file ended up in this place. Wouter Cloetens wrote: $ ls -l /usr/lib/python*/site-packages/mercurial/ -rw-r--r-- 1 root root134 Jun 1 2006 __init__.pyc -rw-r--r-- 1 root root168 Jun 1 2006 __version__.pyc -rw-r--r-- 1 root root 5494 Jun 1 2006 appendfile.pyc -rw-r--r-- 1 root root 7589 Jun 1 2006 archival.pyc ... etc ... This is #397111 cropping up again. Python really shouldn't import modules from .pyc and .pyo files unless the original .py file still exists alongside them. that's not really it. The thing is python should not build .pyc/.pyo alongside the files for public modules but parallel to the install, e.g. in /var/lib/python/pyc2.4/. what's crappy is the necessity for the .pyc to be in the exact same directory than the .py (or a symlink to it). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9YXhqiQrdS.pgp Description: PGP signature
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007 at 03:20:10PM +0100, Loïc Minier wrote: Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. or do that the clean way: edit /usr/share/python/debian_defaults Not sure what has to be done though to force the byte compilation and links creation for the pure modules, and that won't compile binary extention either anyway (but maybe pygtk already forces it I don't know I shall say, I've not checked). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpN0Ut8wE6cv.pgp Description: PGP signature
Re: which packages still depend on python2.3?
On Sat, Oct 21, 2006 at 12:13:42PM +0200, Tshepang Lekhonkhobe wrote: Hi, I managed to remove python2.3 without problems on my system, meaning that everyone uses python2.4. Are there packages which depend only on python2.3, and if not, why is it still kept around? grep-dctrl -sPackage -FDepends python2.3 is your friend. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpNvN1WXBcfv.pgp Description: PGP signature
Re: Help needed with python-gpod
Le sam 30 septembre 2006 01:47, Frank Lichtenheld a écrit : Hi. I maintain the libgpod package which also provides python bindings in the python-gpod package. While preparing a new upstream version for upload I noticed that upstream changed the build system for the python bindings so that the patch provided by Raphael Hertzog to build them according to python policy doesn't work anymore. Now it seems awful complicated to patch the package again to build more than one version of the bindings. Which means I would have to go back to only providing some for the default python version. As far as I can tell this wouldn't cause much problems since the only rdepends is using the 2.4 version anyway. But maybe someone of you has a good idea to patch the package to make providing more than one version easy again (given the fact that many of you have probably seen more than one build system for python bindings unlike me)? Or maybe someone would like to point out why only providing a 2.4 version of the bindings is really a bad idea (e.g. people that might actually use the package, again unlike me)? with the autotools, to chose the python version you build for, you just need: PYTHON=pythonX.Y ./configure . -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgphG0gflqbJW.pgp Description: PGP signature
Re: Who is supposed to remove the .pyc files? (see #386211)
Le ven 8 septembre 2006 14:51, Ludovic Rousseau a écrit : Le 07.09.2006, à 16:55:59, Pierre Habouzit a écrit: # sorry pal, but such a bug renders the package completely unusable, and # is also a policy violation. Why is the package completely unusable? I just see a complain by dpkg that /usr/lib/python2.3/site-packages/PyPlucker/ is not empty. I agree with the policy violation. Note that I adopted the package recently and the problem was already there. the problem is that under some condition, even with the missing .py, the .pyc are seen as validate candidates to do an import. this often lead in broken setups. so now, you are just fucked, you have to : 1. rm -rf /usr/lib/python2.3/site-packages/PyPlucker/ in the preinst of your package. OK. The plucker package is not available in Debian stable. I imagine it had a RC bug when sarge was released since the first package version is dated Dec 2000. So only people using unstable or testing _and_ running the scripts as root will suffer from this bug. How long should I keep the rm in preinst? Until etch is released ? yes you will be able to drop that in etch+1, because upgrades from a stable release to the one after the next is not supported. We assume users always upgrade from one stable to the next. Or can I just close the bug without adding anything in preinst since packages in unstable/testing _may_ have bugs. no, packages un unstable/testing cannot have known bugs. they *may* have not-yet-known ones. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgph8kz79naIb.pgp Description: PGP signature
Re: Who is supposed to remove the .pyc files? (see #386211)
# sorry pal, but such a bug renders the package completely unusable, and # is also a policy violation. severity 386211 grave thanks Le jeu 7 septembre 2006 14:20, Ludovic Rousseau a écrit : Hello, I received bug report #386211: Package: plucker Version: 1.8-16+b1 Severity: normal Upon update to this version the byte-compiled files in /usr/lib/python2.3/site-packages/PyPlucker/ were left behind. 1.8-16+b1 is generated for Python 2.4 so the installed files are now in /usr/lib/python2.4/site-packages/PyPlucker/ and /usr/lib/python2.3/site-packages/PyPlucker/ should be empty (and deleted). My problem is that the package does not provide the .pyc files. These files are generated when executing the Python script as _root_. Executing the Python scripts as a normal user does not create the .pyc (permission denied, of course). How am I supposed to manage this? you were supposed to remove them in the postrm of you package, as per policy (the old one). so now, you are just fucked, you have to : 1. rm -rf /usr/lib/python2.3/site-packages/PyPlucker/ in the preinst of your package. 2. and then make it comply with the new policy, using dh_pysupport or dh_pycentral that will take care of the byte-compilation of your package, and the transitions also. wich seems to be already done. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJjMdyn6NmY.pgp Description: PGP signature
Re: debian/pycompat usage?
Le lun 28 août 2006 09:12, Pierre Habouzit a écrit : so to me, the harm looks quite small, given the fact that my current experiments show that only a few packages do have an upper bound, and do not use XS-P-V already. the list of suck packages (run on a fresh local miror) is: avahi : 2.4 bzrtools: 2.4 codeville : 2.3 drpython: 2.3 gaphor : 2.4 gnome-sudoku: 2.4 hamlib : 2.3-2.5 libmetakit2.4.9.3 : 2.3 opensync: 2.4 and I suspect that most of those should have been x.y- and not x.y. the 2.3-2.5 from hamlib looks quite suspicious. and those two are buggy: notify-python : =2.3 - should be 2.3- xulrunner : current - should be 2.3- as well I will fill reports to ask the pyversions fields to be sort out, but please be reassured wrt that transition, the lack of XS-P-V is (by luck I reckon) not harmfull yet, and I'll personnaly ensure that it won't become. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpsMNPvRtKrR.pgp Description: PGP signature
Re: debian/pycompat usage?
Le ven 25 août 2006 03:50, Floris Bruynooghe a écrit : Hello I've somewhat lost track of the exact current status of the new policy. AIUI debian/pycompat is not needed anymore currently as dh_python has enough by having the XS-Python-Version field, while if you are using python-support dh_python is not used at all anymore so it doesn't need the debian/pycompat anymore either. Please correct me if I'm wrong. Also the wiki needs updating to reflect this, so if no one corrects me I will do that (unless someone beats me to it). debian/pycompat is needed if you want dh_python to do the substitution. You also can (atm) use dh_pysupport do it alone, in that case you must not use debian/pycompat, neither dh_python. Also, fairly unrelated, since pyversions is part of the python package should we build-depend on python? I found somewhere that build-depending on python-all-dev (= 2.3.5-11) is sufficient to pull in pyversions, is that really the appropriate way though? I would prefer to list python directly as dependency instead of indirect. it depends. if you build for a pythonX.Y you should just B-D on pythonX.Y-dev, if you build for current on python-dev, if you do a multi-build you should use python-all-dev. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6dhSCgeDIt.pgp Description: PGP signature
Re: debian/pycompat usage?
Le sam 26 août 2006 00:39, Pierre Habouzit a écrit : Le ven 25 août 2006 22:26, Josselin Mouette a écrit : Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : I object to basing future work exclusively on dh_pysupport as long as it implements your unilateral decision to abandon the XB-Python-Version field and deprecate the XS-Python-Version This decision was not unilateral, sorry. As long as these fields don't even have clear semantics, implementing them is, at best, useless. without offering any alternative suitable for mass-detection of binNMU candidates. What if I provide you with a script that does the same without the fields? I will do that, I've promised it. I've had a hell of a week, but I will work on that this week. week-end obviously sorry. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXopAAE8GvB.pgp Description: PGP signature
Re: Future of dh_python
Le mar 22 août 2006 01:00, Josselin Mouette a écrit : * -V is a redundant interface, since it does something approximating what debian/pyversons does. So things should be able to switch to the other interface, except in edge cases (although IMHO it's not an appropriate interface for a debhelper program), and for the edge cases, -V could be added to the other two programs. Exactly, we should get rid of the -V parameter completely. I strongly disagree here. The -V flag achieves something very specific (e.g. for Zope packages) and there is no way that we can get rid of it (or another interface achieving similar functionality). See #381389 for an explanation. -V may also be used for packages that are not in the scope of the policy: meaning applications that do not support current python /yet/. For those, you need to build-dep upon pythonX.Y-dev (X.Y current) and to dh_pysupport -VX.Y. when that application will support current (e.g. because X.Y becomes current) the packaging has to be changed to use python-dev as a B-D and remove the -VX.Y call. and even with a more clever dh_pysupport (and I don't think that's doable without bloating the script) you won't spare the B-D change anyway, so it won't spare the new sourceful upload. (the same is true for applications that do not support current python *anymore*, e.g. applications that only work with python2.3 nowadays, if that exists). the policy deals with package that support current (and to some extent, for pure python modules where the python (= X.Y) | pythonX.Y dependency kludge allow a more smooth upgrades[1]). Everything else is on its own, and there -V *is* a way to help packaging those applications. Except for the pure modules, when you package a thing for a specific non-current python version, you should build-depend on pythonX.Y-dev[2]. [1] I repeat this is a kludge, and only appliable to pure python modules. Given that there is quite a couple of them, it's a useful kludge though. [2] build-depending on python-all-dev is horrible as a general rule, if you build against a sole python version. Though, even for applications, there is cases where you can kludge the debian/rules to switch from a pythonX.Y only build to a /usr/bin/python one, using things like: * B-D on p-all-dev * building with a magic substitutions of $(shell pyversions -d) by python in the requested list of pyversions, so that when the X.Y you depend upon, you magically switch to a package built for current. Though, I really think such packaging methods are harmful, and that the python2.4-that-is-out-since-years should not happen again thanks to the new policy, so that we can assume that only *few* packages will not support the current version. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQ8e93YtZfA.pgp Description: PGP signature
Re: Bug#383958: lintian: python-script-but-no-python-dep error with python-support
Le lun 21 août 2006 02:30, Russ Allbery a écrit : [ Resending to get the right address -- sorry about that. ] Cameron Dale [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: wishlist Lintian generates python-script-but-no-python-dep errors for binary packages depending on python-support (which depends on python). These dependencies are sufficient and are generated automatically by the dh_pysupport debhelper script. I asked on debian-python and they said this was a bug in lintian and not in python-support: http://lists.debian.org/debian-python/2006/08/msg00098.html I don't think I agree with this. [snip] If it's really the intention that python-support will always provide a Python interpreter, that should be added to its long description so that there's documentation that this is an invariant and a promise that won't be changed later. python-support is written in python (same is true for python-central) and will *always* depend upon 'python' -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpqp9RL7JVaM.pgp Description: PGP signature
Re: Bug#383958: lintian: python-script-but-no-python-dep error with python-support
Le lun 21 août 2006 03:53, Russ Allbery a écrit : Pierre Habouzit [EMAIL PROTECTED] writes: python-support is written in python (same is true for python-central) and will *always* depend upon 'python' Maybe some examples to illustrate will help. It may not be entirely clear why the above statement doesn't actually resolve the problem. [snip] Let me turn this around: what advantage is there to the current approach? Why would you ever want a package containing a Python script to depend on python-support and *not* python? Is this just saving eight bytes in the Depends field, and if so, is that really worth it for, say, not being able to locate all packages that depend on Python by simply looking for packages that depend on Python (rather than having to also factor in packages that use transitive dependencies)? that's indeed a fair question, maybe python-support should not be too clever and let 'python' be explicitely listed, even if it's *currently* not needed. Also note that if versionned depends are needed (like a python (= X.Y)) it is obviously added, so that problem hits only arch:all packages that do not need a specific python version... Maybe Joss will have more insight about that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyLqg3RUADC.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le dim 13 août 2006 22:17, Manoj Srivastava a écrit : As to the BOF thing, I'll bite: Why one earth did the bof come up with design decisiosn that require every single goldarned python module package to be reuploaded every time a new version of python is added or removed? actually,it's not truly needed, it's needed iff a package do needs the new provides or not. and those reuploads are kind of binNMUs, the real problem here is that tehre is no arch:all binNMU and maybe that's here the problem that need fixing. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptHBQYsMOcp.pgp Description: PGP signature
Re: dh_python and python policy analysis
maintainer to merge those scripts if possible. Moreover a binNMU on the package (if 2.3 is not supported, and that the package uses pyversions -s) will fix that trivially anyway, wich remains quite acceptable. 3.5. Private Extension These are compiled files linked to python libraries, and kept in a no, in most cases, any extension needs to be linked against libpython. sorry I miss that mistake by rereading manoj's doc, you're obviously right. by the binary package (XB-Python-Version field or the file .versions) is set to that version (copied from XS-Python-Version). If the current version is not supported, this field it set to the minimum version actually supported by the module. what do you mean? if the version range is e.g. 2.4- with current beeing 2.3, then ... then it's indeed wrong. at least I don't understand the rationale anymore here. needs a fix. Depending on the packaging utility used, the modules live in either /usr/share/python-central or in /usr/share/python-support/$package. that is wrong. 1) there's nothing wrong having these still in /usr/lib/pythonX.Y/site-packages. 2) please avoid naming of these directories in the document. these should be considered private directories for the tools. For the case of pycentral, you can get the directory name using pycentral pycentraldir package name. aggreed. Official pure Python modules generally live in a different set of official? like in upstream's is there any python modules that go in /usr/lib/python2.3/ directly ? 3.6.1. Byte compiling In the common case of pure Python modules in unversioned public module directories, tools exist to help byte compile the pure Python modules for all versions of Python installed on the target system. In case of pure Python modules in versioned public module directories, byte compilation is up to the package scripts. maybe that's not the best place to mention /etc/python/debian_config, but scripts byte-compiling files should honor the byte-compile property. packages should only byte-compile the files belonging to the package, or else error message for byte-compilations are reported for random packages. 3.8 missing: Packages using embedded python interpreters (libapache2-pythonX.Y, which should not be collapsed as libapache2-python), vim, and maybe other packages. agreed 4.1.1. rtupdate script invocation 1. in the pre-installation phase of the python package, the package supplied scripts are called with the parameter: pre-rtupdate old runtime new runtime A failure in any script results in the failure of the pre-installation script of the python package. [42]Note Whether or not all scripts are run, or the process aborts at the first failure, is still under flux Since such a failure of a script would leave all packages whose pre-rtupdate has been run in a dangling state, a bug in a pre-rtupdate will always be a critical bug. Be very very careful when working on a pre-rtupdate script. I'm adding a failed-pre-rtupdate hook for the next upload, which is run, if the pre-rtupdate hook fails (to allow the package to go to a sane state again). that's a good idea obviously. I do have a different view on raising build and support information to the Packages/Sources files; in other cases the document clarifies things well. IMO the current section 3.6 makes things more confusing than they are (at least for me). Would it be helpful to add paragraphs starting with Example: in sections where they are useful? I.e. most package maintainers won't need the rtupdate scripts, and therefore could skip reading when they don't need these scripts. I think the examples should be in an annex, that follow 3.6 TOC so that one can read the examples in front of the spec, without poluting the spec. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6rcOuzEKUy.pgp Description: PGP signature
Re: Stackless Python
Le ven 11 août 2006 19:48, Ethan Glasser-Camp a écrit : Hi guys, I asked on #debian-python a few days ago about the odds of Stackless being packaged. MadCoder, speaking unofficially, told me that this question would be better to ask on this list, and suggested I do some research about the compatibility between Stackless and vanilla CPython. I went to the Stackless mailing list and asked some questions and I think the answer is: If Stackless isn't binary compatible, it is considered a bug in Stackless. Here is the thread I started: http://www.stackless.com/pipermail/stackless/2006-August/001876.html .pyc files should be compatible (compiler and interpreter are not changed by Stackless). Stackless is 100% compatible with pure Python code. There has been an occurrence of a C extension (PyQT) not being binary compatible, but this is a rare case, and the Stackless people are interested in resolving the bug if it can be reproduced. well, then all is not lost, one could package it, and install it either as an alternative of vanilla python, or anything like that. If it's able to use the same module path for the extensions, and its own path for its own private things, that should just work withoug duplicating all the work. now one has to take care of that, I don't know if anyone that has packaging skills is interested into packaging stackless python. At least, it does not sounds horrible, one has to give it a try I'd say. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9CrK2xGsXp.pgp Description: PGP signature
Re: Stackless Python
On Fri, Aug 11, 2006 at 08:07:05PM +0200, Matthias Klose wrote: long time ago, stackless was distributed as a patch to python. is this still the case? They provide full tarballs on the site. what is important to know is wether it can live in a separate tree for his own files, and use the common from vanilla python for the rest. If that can work, I don't see any reason to refuse packaging stackless (if anybody step up to do that btw). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: dh_python and python policy analysis
Le mar 8 août 2006 21:33, Joe Wreschnig a écrit : It's possible to build Python modules for all versions with only python-dev, if they are pure Python modules (feedparser is such a package, its dependency on python-all-dev is extraneous and could be just python-dev). So simply looking at the dependencies is not enough information. correct, but that holds only for pure python modules, that are arch:all, and thus very rarely need to be tracked. What is important is to be able to list binNMUs to schedule, for extensions. * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. This is exactly the *point* of the field. It means you can just binNMU packages and support the new version. If we lose this ability we've lost much of the point of the Python transition. Packages with private extensions still cannot make use of anything but current to take real advantage of the new policy (things like = 2.3 are a lie because they can still only support one version at a time). If you get rid of it, they are back to the crappy situation we were at a year ago. that's because you are taking XS-P-V as a declaration of what is beeing built. It's not, it's a list of python version the source package is theorically compatible with. Then the maintainer choose the python for which it's built: current only if there is private modules involved, the python versions extensions have been built for, or any of them for most of the pure python extensions. XS-P-V (and debian/pyversions) does not explain that, it's the role of XB-P-V for pycentral, or the .version files for pysupport, and it's trivial to guess from the generated depends upon python: if your package depends upon python ( 2.6), python (= 2.4) then it has been built for python2.4 and python2.5. When you track transitions, that's all the information you need to know. but current as a XS-P-V is IMHO not correct, and that has been explained in my mail, and in Manoj doc with very good arguments. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMDMCZhpywz.pgp Description: PGP signature
Re: Obtain Python version number
Le mar 8 août 2006 06:54, Andreas Tille a écrit :
Hi,
to write a wrapper script I wonder what might be the best possibility
to find out the version numer of the running python interpreter. The
wrapper script is of the type
/var/lib/python-support/python${PYVER}/${package}/${realscript}
and I wonder, how I can obtain ${PYVER} according to the version
of the python binary that is installed as /usr/bin/python.
I tried
PYVER=`python -V 21 | sed
's/Python[[:space:]]\+\([0-9]\+\.[0-9]\+\).*/\1/'`
which works in principle but I wonder if there is some other
reasonable way.
pyversions -vd will answer the short versions (2.3 today)
pyversions -d will answer python2.3
pyversions -s / -vs do the same with the supported versions.
It indeed is the preferred way to obtain those
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpv1yK7V1V9Z.pgp
Description: PGP signature
Re: dh_python and python policy analysis
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : § 2.3.3, 2.4.2, 2.5.3, 2.6.2: *here* the python$version alternative is correct, because /extensions/ can be used with a '/usr/bin/python' as soon as the python current version is in their supported range. so take the previous algorithm, and add to (2): if current python version isn't in that range, add an alternative to the pythonX.Y corresponding to the range lower bound. Meaning that in my test cases, instead of *SHOULD NOT HAPPEN* you will get: python (= 2.4) | python2.4 and in fact, wrt Depends, the algorithm for pure modules or extensions, private or public is the same. I forgot to explicitely mention that when extensions are in the package, then you have to restrict your 'python' range to the range of the python for which extensions have been built. That seems obvious, but it has to be stated in the policy very clearly. That means that if you ship a .so for e.g. 2.3, 2.4, then your python depends will be: python (= 2.3), python ( 2.5) even if the pyversions is 2.1- about debian/pyversions, unlike his brother XS-P-V it does not supports all/current. for python support you have to use sth like 2.1-. current explicitely says that the package is only built for the current python version, and not for any other supported in debian. But I don't like that value for the following reasons: * it says for what the package is built, whereas other values explain for which range of python versions the package is build-able, so semanticaly it's not homogenous ; * it prevents the packager to explain with which python versions the package is compatible, as saying 'current' suggests that the package is now compatible with the current python version, and will always in the future, wich may be wrong when (if that happen) some python 3.0 that is not 100% backward compatible should exists ; * it also give an information we already have as a package that is built for the current python version should depend upon python-dev and not python-all-dev ; * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. so IMHO the current value should be documented as an internal pycentral value, and should not be recommended to be used for other ways of python packaging. OTOH, I thing pysupport should also support all as it's prettier than 2.1- and more explicit to the packager, and then it could go into the policy as a recomended value in that case. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpiVolufOJDz.pgp Description: PGP signature
Python Transition, Mass Bug fill and NMUs…
Yesterday, a last round of bugs has been filled against packages that may need an upgrade to comply with the recent python policy[1]. Some developpers have raised concerns directly to me about the 0-day NMU policy warning in that report. This § has been added because /usr/bin/python beeing python2.4 is a release goal, and that migrating packages to that policy indeed helps to that. That's a statement for a fact, not a thread. If you don't want an NMU, just state it in an answer to the bug, that shows that you are aware, but that for some foo or bar reason you want to deal with that bug with a later upload. this is *OK*. So, dear developpers: if you don't want to be NMUed, just say it. If you don't want to be NMUed just for that, but want your next upload to deal with the python policy, and that you don't know how to handle that new policy correctly, just tag your bug + help, I do follow those bugs, and I've already prepared and sent (or am currently preparing) patches for those who already asked for some. If you want help, but already have a preference between python-support/python-central please state it also, so that the patch do follow your choice, else the one that helps will choose for you (if one or the other helper is indeed needed). So, dear NMUers: *DO* respect the wish of maintainers that ask not beeing NMUed. If you really feel a maintainer just procrastinates, sending a 'NMU patch' on the bug is OK though. If a bug is tagged + help, please do only send the patch, except if the maintainer explicitely allowed NMUs. That way this messy transition will be able to come to an end, peacefully. Thanks for caring. [1] yes I know this was not re-announced, but it was obvious to me that the repeated announces (at least 2 or 3 mails on d-d-a@) about the python transition were sufficient. that plus the fact that the bugs are /important/ and not RC (some may become, for packages that B-D upon python2.3 where they should on python-dev, but we are not here yet, and /that/ will be announced and coordinated with the RM team). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYXThd7cENR.pgp Description: PGP signature
Re: Python Transition, Mass Bug fill and NMUs...
Le mer 2 août 2006 11:23, Loïc Minier a écrit : - status of the transition Wiki page: a summary of steps which are in progress (pointer to python transition pseudo-bug, pointers to the list of bugs to be fixed in the mass bug filing, description of the step) that could have been more clear, but I do have such tools to follow the transition, I use[1]. The two rounds of mass bug have been package that build public modules and extensions, and then all the other ones (+ some missed one at the first stage). - collection of things to do and no to do: this is both intended as a reference of things that we have discussed and decided to be good or wrong, and might help in defining the exact criteria prior to e.g. a mass bug filing; this probably belong to the FAQ on the Wiki this seems to be quite well documented on the DebianPython/NewPolicy pages, buxy added some full examples, and I added some more things about cdbs recenlty. The page was also updated for private modules before the second mass bug fill. - test suite that misses, and this is IMHO *the* real thing that sucks here. the rest lacked some advertising, but exists. [1] http://bugs.debian.org/from:[EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpStUj93TdFU.pgp Description: PGP signature
Re: Request for help to convert the lyx package
Le mer 2 août 2006 12:37, Sven Hoexter a écrit : Hello, I've been working on the lyx package to get it in a state complying with the new python policy. LyX generates some .pyc and .pyo files during build time and I'm not sure what to do with them because I thought that the dh_pycentral call would handle them correctly. Having build a package[1] from the stuff we currently have in our svn repo[2] I can not find a postinst/prerm script added to handle the recompilation of those files. From the resulting packages lyx-common is the one with the python stuff. I'd appreciate if someone could enlight me and tell me how to deal with this case correctly. first you need to build depends on python-dev and not python. and the pyo and pyc files are generated by your build process. you have to remove them manually, e.g. using some find -name '*.pyo' mantra. there should be no .pyo/.pyc in the packages you build, those are created by pycentral at postinst / prerm time of your package, thanks to debhelper magic. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzPlPQad2S6.pgp Description: PGP signature
Re: Request for help to convert the lyx package
Le mer 2 août 2006 20:09, Iustin Pop a écrit : On Wed, Aug 02, 2006 at 08:02:05PM +0200, Pierre Habouzit wrote: Le mer 2 août 2006 19:51, Iustin Pop a écrit : On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: and the pyo and pyc files are generated by your build process. you have to remove them manually, e.g. using some find -name '*.pyo' mantra. The (old) dh_python did remove the .pyc and .pyo files at package build time, so one did not have to bother with their removal. Are the new fancy tools not doing this (asks a developer still not up-to-date with the new python policy)? looking at dh_python source, bumping PYCOMPAT to 2 does not changes that part of its behaviour. though, even for the lyx-common in the archive there is .pyo/.pyc in /usr/share/lyx/lyx2lyx/ (wich in itself is quite bad). Ah, then that must be it - it must be invoked as: dh_python /usr/share/lyx/lyx2lyx in order for it to scan other dirs and generate the correct postinstall/prerm. well actually, with pycompat to 2, it does not generates the pre/postrm. pycentral/support do takes care of that part. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQq2dIHJIwa.pgp Description: PGP signature
Re: which wiki-like text encoding?
Le mar 1 août 2006 16:41, Andreas Barth a écrit : Hi, I'm looking for some wiki-like-language which can be parsed in python sufficiently fast. I was hinted to pytextile, but it looks dead upstream and isn't really fast (to say it nice :). So, any other hints for me? python people usually use restructured text. it depends what you want to do exactly, and what the users of that syntax are likely to be able to learn ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVRIJsVtuJ6.pgp Description: PGP signature
Re: dpkg-repack warnings: what effect?
Le lun 24 juillet 2006 16:26, Joey Hess a écrit : Hugo Vanwoerkom wrote: dpkg-repack (from sid dpkg 1.13.22) gives warnings when repacking python packages: ... warning, `./dpkg-repack-5343/DEBIAN/control' contains user-defined field `Python-Version' ... What effect does this have? Can the .deb be used or not? It's harmless, though perhaps a pity that the python maintainers decided on this ugly solution. just FYI, it's not mandatory, one can use debian/pyversions instead (with python-support). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTiadqojggg.pgp Description: PGP signature
Re: dpkg-repack warnings: what effect?
Le lun 24 juillet 2006 19:52, Adeodato Simó a écrit : * Pierre Habouzit [Mon, 24 Jul 2006 17:11:14 +0200]: just FYI, it's not mandatory [XB-Python-Version], one can use debian/pyversions instead (with python-support). Hm. I can see how debian/pyversions can substitute XS-Python-Version (both are available only at build time), but I fail to see how it can substitute XB-Python-Version which is presumably needed at install time. (I'm not very familiar with how pycentral works, though.) I agree that having Python-Version in binary packages is dislikeable. Out of curiosity, Matthias, would be a DEBIAN/pyversions file able to provide the same information to pycentral? I don't know pycentral at all, and not pysupport enough to know *why*, but I know for sure pysupport do not need the XB-Python-Version at all. afaict, it seems reading the code that it uses a special custom registry in /usr/share/python-version/.version or sth like that. if you need more insight on this, ask Josselin, I suppose he can tell you how that works deep inside. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRRaazQmsJX.pgp Description: PGP signature
Re: [Fwd: python-soappy: fpconst missing]
Le ven 21 juillet 2006 13:31, Manuel Metz a écrit : Sorry to bother you again. I have the feeling that the maintainer of SOAPpy is not fixing bugs very quickly :-( I figured out a problem with fpconst.py again (not yet reported the bug to debian bug report). The version included in SOAPpy (0.6.0) does not work correctly on 64 Bit systems. G. R. Warnes has released an updated version: http://mac.warnes.net/~warnes/files/fpconst-0.7.2.tar.gz , also attached to this E-Mail. Could you please update the package. And again, sorry for bothering you. Manuel well, I'd like to avoid doing that, I don't use python-soappy at all, even does not know what it does. My two previous uploads were due to : (1) transitionning the package to a new packaging standard, (2) fixing a bug due to my previous upload (that you reported to me, and you were right to do so). But I'm not well placed to deal with a package I don't know well. I forward your mail to the debian-python list, maybe someone will be willing to check on that package, and ensure it's of release quality. Also note that if the package is unusable, you should open a bug on the BTS, with a high severity (if relevant). bugs of high severity *will* be checked by developpers, presumably by some that know about that package better than me. Note that here, I'm convinced a new upstream has to be packaged asap, but as said, not knowing the package, I don't know how stable the more recent upstream releases are, and can't take such a decision. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpq4fjTi3Akf.pgp Description: PGP signature
Re: [HELP] new policy with a compiled python program and generic python plugin module
Le ven 30 juin 2006 21:03, Vincent Danjean a écrit :
Hi,
I'm converting one of my package (commit-tool) to the new policy.
I was thinking it will be easy, but I found several difficulties.
I'm able to deal with them so that I will be conformed to the new
policy, but I would like to do the Right Things.
[...]
So, I would be glad to get help/comments/advices on this, in
particular on the way to generate dependencies for my B (B1 or B2)
proposal.
you need to compile the public modules for every python version.
and the private module + gct only for /usr/bin/python (beeing python2.3
currently).
that is made by installing the modules to be compiled into every:
usr/lib/$python/site-packages/$(package)/
for each python in $(shell pyversions -r).
for the rest, just use the standard mechanism of your package to install
the package, and if there is private modules, pass it to
dh_py{central,support}.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpKPFWOA2FoU.pgp
Description: PGP signature
Re: [HELP] new policy with a compiled python program and generic python plugin module
Le sam 1 juillet 2006 00:19, Pierre Habouzit a écrit :
Le ven 30 juin 2006 21:03, Vincent Danjean a écrit :
Hi,
I'm converting one of my package (commit-tool) to the new policy.
I was thinking it will be easy, but I found several difficulties.
I'm able to deal with them so that I will be conformed to the new
policy, but I would like to do the Right Things.
[...]
So, I would be glad to get help/comments/advices on this, in
particular on the way to generate dependencies for my B (B1 or B2)
proposal.
you need to compile the public modules for every python version.
and the private module + gct only for /usr/bin/python (beeing
python2.3 currently).
that is made by installing the modules to be compiled into every:
usr/lib/$python/site-packages/$(package)/
for each python in $(shell pyversions -r).
for the rest, just use the standard mechanism of your package to
install the package, and if there is private modules, pass it to
dh_py{central,support}.
forget it... sorry I should have read more carefully
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpOstLk9jkdq.pgp
Description: PGP signature
Re: News from the python policy transition
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : So you don't have any excuse to not update your packages any more. About 60% of the Python modules have already been updated, but 109 are left to be done: http://bugs.debian.org/from:[EMAIL PROTECTED] The bugs have been filled two weeks ago, it is now time to NMU the remaining packages where the maintainer didn't gave any update plan in the bug report. We need your help for that. I've done 16 of them already. that has also fixed 2 RC bugs as a side effect (uninstallability bugs). 7 other person like me, and it's old story ! -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcBRpNK6Eec.pgp Description: PGP signature
Re: News from the python policy transition
Le jeu 29 juin 2006 16:37, Sam Morris a écrit : On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote: Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : So you don't have any excuse to not update your packages any more. About 60% of the Python modules have already been updated, but 109 are left to be done: http://bugs.debian.org/from:[EMAIL PROTECTED] The bugs have been filled two weeks ago, it is now time to NMU the remaining packages where the maintainer didn't gave any update plan in the bug report. We need your help for that. I've done 16 of them already. that has also fixed 2 RC bugs as a side effect (uninstallability bugs). 7 other person like me, and it's old story ! I noticed the original list didn't include the python-gmenu package. The source package (gnome-menus) produces some regular machine code packages as well as the python module package. Perhaps there are others like this? that's possible, you are welcomed to open the right bugs... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgWF05IxeV8.pgp Description: PGP signature
Python-Standards-Version
I'd like to suggest a last minute amendment to the Python Policy, that would help further transitions a lot. I'd suggest that packages uses a XS-Python-Standards-Version, that would'nt be mandatory for the current policy but *strongly* advised (a followup on every mass bug could help here) to use a: XS-Python-Standards-Version: 0.4 to specify the python policy the package is conforming to. that would help transitions a lot, and help to keep track of future transition statuses. comments ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOjZO0pWlBk.pgp Description: PGP signature
Re: Python-Standards-Version
Le jeu 15 juin 2006 10:50, Piotr Ozarowski a écrit : Pierre Habouzit ([EMAIL PROTECTED]): I'd like to suggest a last minute amendment to the Python Policy, that would help further transitions a lot. I'd suggest that packages uses a XS-Python-Standards-Version, that would'nt be mandatory for the current policy but *strongly* advised (a followup on every mass bug could help here) to use a: XS-Python-Standards-Version: 0.4 to specify the python policy the package is conforming to. that would help transitions a lot, and help to keep track of future transition statuses. comments ? I think a better idea is to use Standards-Version as we did before (version 3.8.0 should be released) well the thing is there is no way to track all the packages that *have* to follow the python subpolicy, and that makes the work of tracking them for transition harder. I think/thought it makes sense that a source package lists all the subpolicies it's supposed to follow, because it makes our lifes easier. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpr2FG8RvS4N.pgp Description: PGP signature
Re: Python-Standards-Version
Le jeu 15 juin 2006 13:36, Piotr Ozarowski a écrit : Pierre Habouzit ([EMAIL PROTECTED]): well the thing is there is no way to track all the packages that *have* to follow the python subpolicy, and that makes the work of tracking them for transition harder. I think/thought it makes sense that a source package lists all the subpolicies it's supposed to follow, because it makes our lifes easier. You can't bump Standards-Version number if your package is not following *all* standards (i.e subpolicies). The fact is that python policy is not official yet (at least document on d.o is not updated) and /usr/share/doc/debian-policy/upgrading-checklist.txt.gz doesn't mention about new python policy at all. we are not talking about the same target. My goal is to be able to spot every package that has to conform to the python subpolicy by just listing those fields. Obviously the Standards-Version is bumped also, but it's not distinctive of python and not python related packages. Thouth I think it's handy, but it's not more than a suggestion, I don't really care about that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpR4so3rmVnd.pgp Description: PGP signature
Re: Coordinated effort to update python packages
Le Mar 13 Juin 2006 20:38, Raphael Hertzog a écrit : For NMUers, always start by filling a bug report refering to this announce, register the bug number and your intent to work on it in the wiki page, do the work, send the patch to the BTS and upload the package appropriately (using a DELAYED queue if needed). A mass bug filling occured, sorry for the few false positives I may have triggered, you can watch the list here : http://bugs.debian.org/from:[EMAIL PROTECTED] there is also a usertag [EMAIL PROTECTED], tag=policy: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=policy;[EMAIL PROTECTED] adding a ;pend-exc=done gives a good list of what the TODO is ;) Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpFXRFwUHgYp.pgp Description: PGP signature
question about the new policy
let's imagine we have that case: python-foo is a python module that uses and needs features from python2.X. python-bar uses python-foo but can work with all 2.* python version. Python-Versions will be: * = 2.X for python-foo * all for python-bar how do we ensure that a user that has a python 2.Y installed, Y X will not been able to install python-bar without also pulling python2.X ? Note that such a scheme can arise if a python-foo module decide to drop the support for a python release they consider ancient (like 2.3 nowadays). all the informations I got around for that problem were that it had to be manually tracked, which: * looks rather error prone ; * is computable since in that case, python-foo should not advertise its python2.Y support, but only = 2.X. its Python-Version should be intesected avec the ones of its Depends, and only generate the relevant Provides. Reading the policy, it's unclear to me if arch:all package would have the python#.#- provides or if only arch:any will. if the former, then I fear computing the Depends: in the packages will become a real challenge and prevent bin-NMUS, not to mention uninstability problems, if the latter it will hide problems like the one above. Is there anything planned to address that ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprv4GVGAVi4.pgp Description: PGP signature
Re: amd64 uploads
Le Dim 9 Avril 2006 19:56, Pierre Habouzit a écrit :
Le Dim 9 Avril 2006 14:18, Kurt Roeckx a écrit :
On Fri, Apr 07, 2006 at 09:47:25PM +0200, Pierre Habouzit wrote:
what's the policy about them ?
should the packages be built for python 2.3 and 2.4 ? only for
2.3 ? only for 2.4 ?
I guess it depends on the package. Currently the default seems
to be 2.3, but if it supports multiple versions, adding 2.4
probably won't hurt.
and currently bugs like #351145 are only normal bugs. is it okay
to nmu in delayed/7 without warning ?
See:
http://lists.debian.org/debian-release/2006/04/msg5.html
okay, I've send delayed/7 NMUs for python packages in Dep-Wait of
python2.{1,2}-dev. (actually I have still 5 to do, but that will be
soon OK).
I've not touched decompyle2.2, boot-floppies,
libapache{,2}-mod-python, that hadn't any bug open related to
python2.1 and python2.2 drop. I've (currently at least) not opened
bugs to those 4 packages, feel free to do so.
ok, done.
I'd also like to alert debian-python about #351149 and #351150. Those
were fixed in a quite short period, but Lustin did not found any
sponsor. I don't know how hard he searched, but at least his packages
looked clean and well followed. He deserves better ;)
maybe someone from debian-python can step up as a sponsor ? I offered
him to do so, but I'm not *that* python interested, and someone more
involved with python would surely be better.
Cheers,
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpBL03mAhrwW.pgp
Description: PGP signature
Re: when and why did python(-minimal) become essential?
Le Jeu 19 Janvier 2006 22:47, Matt Zimmerman a écrit : On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? One of the appealing things about the Python language is their batteries included philosophy: users can assume that the standard library is available, documentation and examples are written to the full API, etc. When it's broken into pieces, they get complaints and support requests from their user community when things don't work the way they should. It is already a source of frustration to them that we don't install python-dev with python. IMHO, python-minimal has not to be a developpement environment that is viable as-is, but only what is needed to run the scripts that need it. That has to be stated clearly in the description of the package, so that nobody would assume anything about it. Honnestly, I would be really surprised that we can't find a consensus here, if it's needed one day (which currently isn't in Debian if I've followed that thread correctly enough). Ubuntu does not AFAICT the same size requirements as debian do for base, and I really think that python upstream can understand that the *full* python suite on a embeded device just does not makes sense. To me, this looks like a bad excuse. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp744tnc1Bg5.pgp Description: PGP signature
