Joining the team and RFS
Hi, I'd like to join the Debian Python Modules Team to maintain a new python module called pysol_cards. It is a dependency of pysolfc and freecell-solver. The role of the pysol_cards module seems to be mainly to share code between those two. Packaging is ready for review and upload, please see https://salsa.debian.org/jnumm-guest/python-pysol-cards . I'd like to ask that the team create a new git repo https://salsa.debian.org/python-team/modules/python-pysol-cards for this package. I have read and agree to the team policy. My salsa account is "jnumm-guest". Cheers, Juhani Numminen
Re: Joining the team and RFS python-avc
Le mardi 06 novembre 2007 à 01:25 +0100, Bernd Zeimetz a écrit : Josselin Mouette wrote: Of course they do. What if a package Depends: python2.5, python2.5-avc? Depends: python2.5, python-avc (=new_policy_version) Sorry, but that dependency is incorrect. What if a later python-avc version starts requiring python = 2.6 ? Then you have a problem anyway - all packages Depending on python-avc (which is the only sane default for packages which work for all python versions AND depend on a different package) will need to be updated. Erm, no. If a pure-python package uses it, it won't have to change. Adding versioned depends again brings us back to the old policy. Trying desperately to see something new in the policy isn't going to make a point. It took time to notice it, but it is merely an evolution that allows extensions to be available for several versions of python at once. The real thing that brings us back to the former situation is the 70 packages or so which require an upload at each new python version. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Joining the team and RFS python-avc
Le mardi 06 novembre 2007 à 05:20 +0100, Bernd Zeimetz a écrit : Matthias Klose wrote: proposed policy changes should be filed as bug reports against python-defaults. What is the point of having this list if it cannot even be used for discussing policy changes? You still haven't added the changes that were approved here almost one year ago. Do we have to submit a bug report and subscribe the list to this bug if we want to have your feedback? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Joining the team and RFS python-avc
Hi all! I am looking for sponsorship for my new python module: python-avc, ITP http://bugs.debian.org/448646, mentors http://mentors.debian.net/debian/pool/main/p/python-avc. I would like to join the team, so I can maintain my package within the team. My alioth username is 'fabrizio-guest'. Thank you in advance for any reply. -- Regards, Fabrizio Pollastri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Hi Fabrizio
I am looking for sponsorship for my new python module: python-avc,
ITP http://bugs.debian.org/448646,
mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
* you've missed some packages in Depends (for modules: gtk, qt, PyQt4,
Tkinter)
I will take a deeper look and upload[1] this package after work
I would like to join the team, so I can maintain my package within the
team.
I will add you this evening, I don't have my alioth password ATM
[1] if ftp-master.debian.org will be back online, there are some problems
with it now
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Piotr Ożarowski wrote:
Hi Fabrizio
I am looking for sponsorship for my new python module: python-avc,
ITP http://bugs.debian.org/448646,
mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
OK.
* you've missed some packages in Depends (for modules: gtk, qt, PyQt4,
Tkinter)
Since python-avc is multiplatform, a user will probably use only one
among the supported toolkits. So python-avc really needs to depend from
them all or it only suggests them?
I will take a deeper look and upload[1] this package after work
I would like to join the team, so I can maintain my package within the
team.
I will add you this evening, I don't have my alioth password ATM
[1] if ftp-master.debian.org will be back online, there are some problems
with it now
--
Cheers,
Fabrizio.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
* you've missed some packages in Depends (for modules: gtk, qt, PyQt4, Tkinter) Since python-avc is multiplatform, a user will probably use only one among the supported toolkits. So python-avc really needs to depend from them all or it only suggests them? How is decided which toolkit avc uses? If there's a preferred one, let's call it foo, I'd add Recommends: foo | bar | fuzz if not, I'd add them all to suggests. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Bernd Zeimetz wrote: * you've missed some packages in Depends (for modules: gtk, qt, PyQt4, Tkinter) Since python-avc is multiplatform, a user will probably use only one among the supported toolkits. So python-avc really needs to depend from them all or it only suggests them? How is decided which toolkit avc uses? By user selection: he imports from python-avc the proper module for the desired toolkit, i.e. for gtk 'from avc.avcgtk import *'. -- Cheers, Fabrizio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Fabrizio Pollastri wrote: Bernd Zeimetz wrote: * you've missed some packages in Depends (for modules: gtk, qt, PyQt4, Tkinter) Since python-avc is multiplatform, a user will probably use only one among the supported toolkits. So python-avc really needs to depend from them all or it only suggests them? How is decided which toolkit avc uses? By user selection: he imports from python-avc the proper module for the desired toolkit, i.e. for gtk 'from avc.avcgtk import *'. Then I'd add them all to Suggests: Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Hi,
Le lundi 05 novembre 2007 à 15:40 +0100, Piotr Ożarowski a écrit :
Hi Fabrizio
I am looking for sponsorship for my new python module: python-avc,
ITP http://bugs.debian.org/448646,
mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
Of course they do. What if a package Depends: python2.5, python2.5-avc?
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Joining the team and RFS python-avc
Le lundi 05 novembre 2007 à 15:40 +0100, Piotr Ożarowski a écrit :
Hi Fabrizio
I am looking for sponsorship for my new python module: python-avc,
ITP http://bugs.debian.org/448646,
mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
Of course they do. What if a package Depends: python2.5, python2.5-avc?
Depends: python2.5, python-avc (=new_policy_version)
Joss, python2.5-avc is not in new policy spirit. Think about this
situation: Fabrizio is uploading this package now, it provides
python2.4-avc and python2.5-avc. Some packages are depending on
python2.4-avc and then 2.4 is removed from supported Python versions.
Should Fabrizio upload new version just because 2.4 is no longer
supported? Should he upload new version when 2.6 will be added?
What with package that still depends on python2.4-avc?
Why do we have python-central and python-support then?
Please note that I'm talking about architecture *independent* packages.
Architecture dependent package *have to* provide pythonX.Y-module.
Fabrizio: you're added, welcome in the team :-)
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpsNskfMWjrI.pgp
Description: PGP signature
Re: Joining the team and RFS python-avc
Josselin Mouette wrote:
Hi,
Le lundi 05 novembre 2007 à 15:40 +0100, Piotr Ożarowski a écrit :
Hi Fabrizio
I am looking for sponsorship for my new python module: python-avc,
ITP http://bugs.debian.org/448646,
mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
Of course they do. What if a package Depends: python2.5, python2.5-avc?
No, they don't.
Please get the _official_ Python Policy fixed and such requirements
included if you like to have them. Neither the wiki nor Manoj's home are
the appropriate place for that. Coming up with random requirements or
undocumented things here is not the way to go.
http://wiki.debian.org/DebianPython/NewPolicy requires Provides:
${python:Provides} in two cases:
- if the package used to build pythonX.Y-foo binary packages
(the package didn't exist before, so I never built such packages)
- if your package provides public extensions.
(no extensions here - please note that it defines an extension as .so
file some lines above)
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
says:
2.5 Provides
Provides in packages of the form python-foo must be specified, if the
package contains an extension for more than one python version. Provides
should also be added on request of maintainers who depend on a
non-default python version.
-- Same here - contains an _extension_. An arch:all package doesn't
ship extensions. The policy defines extensions in the same way as the
wiki does.
Not to forget that the policy is still outdated.
Even Manoj's start of a new policy document says the same:
http://people.debian.org/~srivasta/manoj-policy/x316.html#AEN469
Public pure Python modules that have a subset of all python versions
supported, or for public extensions, the Provides field indicates which
versions of Python are supported (for which one may import the module).
For every version of python supported the package should provide
pythonX.Y-foo packages. This assumes that the package correctly depends
on all the appropriate versions of any version specific module that it
itself requires.
-- We neither have an extension here, nor does it support a _subset_ of
Python versions.
I'd suggest it's time to replace the more than outdated policy by
Manoj's new version, which seems to be fine (didn't read everything yet).
--
Bernd Zeimetz
[EMAIL PROTECTED] http://bzed.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a écrit : Please get the _official_ Python Policy fixed and such requirements included if you like to have them. The official Python policy is currently unmaintained. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Joining the team and RFS python-avc
Le lundi 05 novembre 2007 à 23:57 +0100, Piotr Ożarowski a écrit :
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
Of course they do. What if a package Depends: python2.5, python2.5-avc?
Depends: python2.5, python-avc (=new_policy_version)
Sorry, but that dependency is incorrect. What if a later python-avc
version starts requiring python = 2.6 ?
Joss, python2.5-avc is not in new policy spirit.
There is no spirit in the policy. There are only ways to obtain
correct dependencies and working packages.
Anyway, my initial reply was wrong: packages don't *need* to provide
${python:Provides}. This field should only be added if some
reverse-dependencies are requiring it (the reason being, without
automatic addition of python2.X-bar dependencies for all
modules/extensions you depend on, these provides are incorrect).
Please note that I'm talking about architecture *independent* packages.
Architecture dependent package *have to* provide pythonX.Y-module.
There shouldn't be any difference between both when it comes to
dependencies. Generally, architecture: all packages won't need them, but
this is not because of their architecture-independence.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Joining the team and RFS python-avc
Josselin Mouette wrote: Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a écrit : Please get the _official_ Python Policy fixed and such requirements included if you like to have them. The official Python policy is currently unmaintained. Then let's maintain it again. We maintain a lot of packages in a team, so I can't see a problem to maintain the policy there, too. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Josselin Mouette wrote:
Le lundi 05 novembre 2007 à 23:57 +0100, Piotr Ożarowski a écrit :
* remove Provides: ${python:Provides} - architecture independent
packages don't need it
Of course they do. What if a package Depends: python2.5, python2.5-avc?
Depends: python2.5, python-avc (=new_policy_version)
Sorry, but that dependency is incorrect. What if a later python-avc
version starts requiring python = 2.6 ?
Then you have a problem anyway - all packages Depending on python-avc
(which is the only sane default for packages which work for all python
versions AND depend on a different package) will need to be updated.
Adding versioned depends again brings us back to the old policy.
--
Bernd Zeimetz
[EMAIL PROTECTED] http://bzed.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
On Tue, 06 Nov 2007 01:21:31 +0100 Bernd Zeimetz [EMAIL PROTECTED] wrote: Josselin Mouette wrote: Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a écrit : Please get the _official_ Python Policy fixed and such requirements included if you like to have them. The official Python policy is currently unmaintained. Then let's maintain it again. We maintain a lot of packages in a team, so I can't see a problem to maintain the policy there, too. +1 from me. I'd help. Scott K
Re: Joining the team and RFS python-avc
reassign 447231 debian-policy,python-defaults thanks [adding the debian-python list again, I guess you've missed it]. Matthias Klose wrote: Bernd Zeimetz writes: Then let's maintain it again. We maintain a lot of packages in a team, so I can't see a problem to maintain the policy there, too. The policy files are not unmaintained; They are. Maintaining is more than having a minimal update every other year. proposed policy changes should be filed as bug reports against python-defaults. If that's the preferred way - I'm reassigning a related bug from d-policy to d-policy AND python-defaults to make sure it's not forgotten. Also in my opinion the Python policy should be team-maintained (preferable by a small and _active_ team) like most Python related packages. Manoj's Python 'policy' is much more complete, formal and uptodate then the official one, so it should replace the current one. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
