On Wed, 21 Mar 2007, Ben Finney wrote:
How should the Debian packaging files interact with this? Examples
I've seen for using python-central have the egg being built in the
Debian-specific debian/rules targets, but this is clearly duplication
if the upstream Makefile already builds an egg.
[ Please Cc:-me on replies, I'm not subscribed to d-python ]
Hi all,
python-soappy has been maintained by NMUs for the last 3 years.
Since I needed the new upstream release (which integrates 2 patches from
the team I'm working with), after discussing the issue on #debian-python
I decided to
Raphael Hertzog [EMAIL PROTECTED] writes:
On Wed, 21 Mar 2007, Ben Finney wrote:
How should the Debian packaging files interact with this? Examples
I've seen for using python-central have the egg being built in the
Debian-specific debian/rules targets, but this is clearly
duplication if
Hi,
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
* making Provides: meaningful in the case of inter-module
Le mercredi 21 mars 2007 à 20:22 +0100, Josselin Mouette a écrit :
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
*
[Josselin Mouette, 21.03.2007]
* the deprecation of the current keyword;
current keyword is deprecated? Why? I'm using it a lot and I like
it...
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpeuiDfwvZtU.pgp
Description: PGP signature
On Wed, Mar 21, 2007, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
* making Provides:
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
[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
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
Experience a Charging Bull
CEO AMERICA INC
Sym-CEOA
Currently : 6 Cents, CHEAP!!!
Add this to your radar
AN ALL AMERICAN COMPANY
Get IN Before the rush TOMORROW
you or anything,'' Iverson said. ''It just feels good. It just feels like .
For once, it was the opposition that did both. Notes:
[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
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
So with
Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit :
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary
[Steve Langasek, 21.03.2007]
So with current deprecated, what is the solution for a package which wants
to build a single binary extension for the current python version in a
package named python-foo, with no support for other versions of python
returned by pyversions -s?
I think depending on
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
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
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
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
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
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
[Steve Langasek, 21.03.2007]
So with current deprecated, what is the solution for a package which wants
to build a single binary extension for the current python version in a
package named python-foo, with no support for other
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote:
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we
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,
On Wednesday 21 March 2007 23:26, Pierre Habouzit wrote:
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
[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:
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
Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit :
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
Le jeudi 22 mars 2007 à 00:06 +0100, Thomas Jollans a écrit :
There is also the option of only having one in the distribution, which should
be PySyck for having more features. This would mean chucking the official
binding out of debian, which I am not entirely comfortable with either.
If it
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
[Pierre Habouzit, 22.03.2007]
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
On Thu, Mar 22, 2007 at 12:36:07AM +0100, Pierre Habouzit 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,
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
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
On Thu, Mar 22, 2007 at 01:17:17AM +0100, Pierre Habouzit wrote:
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
Pierre Habouzit [EMAIL PROTECTED] writes:
On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
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
35 matches
Mail list logo
