Re: PyGPU
> Just a question for d-python: I can't quite get the convention (if it > exists) for names.. should I call the package pygpu, python-gpu, > python-pygpu? Or call the package pygpu and Provides: ? binary package should follow python-modulename schema. In your case: python-pygpu (I saw `import pygpu` in example scripts) BTW: join DPMT[1] - we will try to help you maintain this package [1] http://python-modules.alioth.debian.org/python-modules-policy.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hello, I'd like to join the team
[Jason Gerard DeRose, 2014-03-19] > > [Jason Gerard DeRose, 2013-12-30] > >> Hello, I'd like to join the Debian Python Modules Team. > > > > Please create an account on Alioth.debian.org and send me your username. > > Sorry, lost track of this email. My Alioth username is jderose (well, > jderose-guest currently it seems). welcome! :) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]): > Dear Debian developers, I'm not a DD, but maybe my comments will be useful [...] > In case there are problems, please let me know, so that I can correct > them as necessary. * Standards-Version is outdated (check upgrading-checklist.txt file) * debian/pycompat file is missing (`echo "2" > debian/pycompat`) * debhelper should be moved to Build-Depends * You've missed binary-arch rule in debian/rules (see lintian info) * "current, >=2.4" will not work with current dh_python so putting "2.4" in XS-Python-Version header is correct but why do you have hardcoded python2.4 in debian/rules? Please use something like PYTHON=$(shell pyversions -r) and compile with $(PYTHON) instead of python2.4 * remove "Replaces: harvestman (<= 1.4.6-2)" line in control file, it's the same package, right? * why are you using `find -name file | chmod 755` (and similar)? Isn't `chmod 755 file` not good enough? * no need to use sed in order to change hashbang, pycentral will take care of it * IMHO putting docs list in debian/docs file instead of calling dh_installdocs 4x is better idea (BTW: you can do it in one line) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpOmyeAWnhGi.pgp Description: PGP signature
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]):
> Piotr Ozarowski gmail.com> writes:
> > * You've missed binary-arch rule in debian/rules (see lintian info)
>
> I don't think it's necessary for Arch-Indep packages, lintian doesn't complain
> on my system.
$ lintian --version
Lintian v1.23.22
$ lintian ../harvestman_1.4.6-3.dsc
E: harvestman source: debian-rules-missing-required-target binary-arch
build-arch is not optional, but since it's not needed in your package,
just add an empty rule.
> > * why are you using `find -name file | chmod 755` (and similar)?
> > Isn't `chmod 755 file` not good enough?
>
> Well, since I don't know whether there are subdirectories with more files.
> Bad,
> but doesn't hurt, does it? :-)
These lines are not needed:
find ./doc |xargs chmod 644
find -name 'config.xml' | xargs chmod 644
dh_fixperms will do the job
Line ("install-$(PYTHON)" rule)
find debian/harvestman -name '*.py[co]' -exec rm -f {} \;
is also not needed, python-central will remove *.py[co] files automatically
(please don't remove the one from clean rule)
> > * no need to use sed in order to change hashbang, pycentral will take
> > care of it
>
> Done.
I don't know why, but dh_python didn't set hashbangs correctly (it's not
changing them at all). I will try to investigate it later, for now please use
sed again, sorry.
> Hope things are better now. See http://kumar.travisbsd.org/debpackages
* please update DH_COMPAT var. in debian/rules (you still have "4" there):
(I recommend using debian/compat file instead, you will not have to export
DH_COMPAT=5 in order to run dh_* manually without warnings/errors)
* remove debian/harvestman.links file and use dh_link in debian/rules
(you have hardcoded "python2.4" there)
* dh_installchangelogs, dh_installdocs and dh_installexamples are called twice,
see
install-$(PYTHON) and binary-indep rules
BTW: it would be easier (at least for me ;-P) if you could provide direct link
to .dsc file in your mails (I use dget to download all necessary files)
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpuGsAfPLjkU.pgp
Description: PGP signature
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]): > Piotr Ozarowski gmail.com> writes: > > These lines are not needed: > > > > find ./doc |xargs chmod 644 > > find -name 'config.xml' | xargs chmod 644 > > > > dh_fixperms will do the job > > Removed. Hmm... I pasted one line too much - config.xml file is installed with dh_installexamples and thus permissions are not changed, please change them manually as you did before (I hope you're not mad at me that I didn't test it further; `find ...|chmod ...` changed permissions in upstream sources as well, and thats why I didn't notice that before, sorry) > > I don't know why, but dh_python didn't set hashbangs correctly (it's not > > changing them at all). I will try to investigate it later, for now please > > use > > sed again, sorry. > > Done. use: find ./debian/harvestman/usr/ -name '*\.py' | xargs sed -i -e '1 s|^#\!.*python.*|#!/usr/bin/$(PYTHON)|' (you used "python2.4" again, with "$(PYTHON)" it will be easier when current python will be greater than 2.4) > > * remove debian/harvestman.links file and use dh_link in debian/rules > > (you have hardcoded "python2.4" there) > > Sorry, missed that! Set it right now. You're now making link to /usr/share/pycentral/..., please use: dh_link -i /usr/lib/$(PYTHON)/site-packages/HarvestMan/harvestman.py /usr/bin/harvestman instead (compiled files will be placed in /usr/lib/...) > And many thanks for your patient response. The rules file looks a lot better > now! Heh, hope you will forgive me my mistakes as well ;-) > Please get back to me for corrections. It's not very important, but if I were you, I would remove configure* rules (they're not used) and collapse build-$(PYTHON), build-common and build-common-stamp into build-stamp, same with install-$(PYTHON) / install-prereq One more thing: please bump debhelper version in Build-Depends to 5.0.37.3 (fixed python version in XS-Python-Version parsing issue) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpMeoScG1XaY.pgp Description: PGP signature
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]): > And again, get it at: > http://kumar.travisbsd.org/debpackages/harvestman_1.4.6-3.dsc Looks very good to me. As I said before, I'm not a DD so I can't sponsor it. If you want, you can also add these 2 lines to long description: . Homepage: http://harvestman.freezope.org/ ^- don't miss this extra space (dev. ref. 6.2.4) PS Please remember to change XS-Python-Version from "2.4" to "current" and "python-all-dev" to "python-dev" in Build-Depends-Indep after python2.4 will become current (with next upstream version upload, package will work without any changes with python2.4 as current so no need to extra upload) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgps8OocEjE77.pgp Description: PGP signature
Re: help with python transition in pyracerz game
tags 380914 + patch
thanks
Attached patch will only make necessary changes for the new python
policy, some other issues still has not been resolved, i.e.
* old Standards-Version
* missed space before Homepage pseudo header (dev ref 6.2.4)
* file permission problems, after saving scores I'm getting:
Traceback (most recent call last):
File "/usr/bin/pyracerz", line 276, in ?
if __name__ == '__main__': main()
File "/usr/bin/pyracerz", line 179, in main
race.play()
File "/usr/share/games/pyracerz/modules/game.py", line 546, in play
self.computeScores(currentTrack)
File "/usr/share/games/pyracerz/modules/game.py", line 609, in computeScores
if misc.addHiScore(track, play) == 1:
File "/usr/share/games/pyracerz/modules/misc.py", line 183, in addHiScore
fwrite = file("/var/games/pyracerz/pyracerz.conf", "w+")
IOError: [Errno 13] Permission denied: '/var/games/pyracerz/pyracerz.conf'
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
diff -u pyracerz-0.2/debian/control pyracerz-0.2/debian/control
--- pyracerz-0.2/debian/control
+++ pyracerz-0.2/debian/control
@@ -3,13 +3,16 @@
Priority: optional
Maintainer: Jose Carlos Medeiros <[EMAIL PROTECTED]>
Uploaders: Ola Lundqvist <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5), docbook-to-man, python (>= 2.3.5)
+Build-Depends: debhelper (>= 5.0.37.2), docbook-to-man
+Build-Depends-Indep: python-central (>= 0.5), python (>= 2.3.5-11)
+XS-Python-Version: current
Standards-Version: 3.6.2
Package: pyracerz
Architecture: all
-Depends: ${shlibs:Depends}, python (>= 2.3.5), python-pygame (>= 1.7.0),
libsdl-ttf2.0-0
+Depends: ${python:Depends}, ${shlibs:Depends}, python-pygame (>= 1.7.0),
libsdl-ttf2.0-0
Recommends: python-psyco
+XB-Python-Version: ${python:Versions}
Description: multiplayer top view 2D racing game
It features multiplayer (on the same computer), tournaments, high scores,
replays, 6 tracks (really 12, because each track can be used Normal or
diff -u pyracerz-0.2/debian/rules pyracerz-0.2/debian/rules
--- pyracerz-0.2/debian/rules
+++ pyracerz-0.2/debian/rules
@@ -82,6 +82,7 @@
dh_strip
dh_compress
dh_fixperms
+ dh_pycentral
dh_python
dh_installdeb
dh_shlibdeps
only in patch2:
unchanged:
--- pyracerz-0.2.orig/debian/pycompat
+++ pyracerz-0.2/debian/pycompat
@@ -0,0 +1 @@
+2
pgpbadsvku71t.pgp
Description: PGP signature
Re: INFO: using old version '/usr/bin/python2.3'
Yaroslav Halchenko wrote: > INFO: using old version '/usr/bin/python2.3' It's just an info that you have python2.3 installed on your system and this version is not supported anymore. It's not related to your package. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp3i33smxleU.pgp Description: PGP signature
Re: Bug#404355: python-psycopg: Python 2.5 support missing
> * 2006-12-23 23:12, Christian Joergensen wrote: > > It seems as if there is no support for python 2.5 in this package: $ pyversions --supported python2.4 or: $ apt-cache show python-all | grep Depends Depends: python (= 2.4.4-2), python2.4 (python2.5 is not yet supported in Debian) -- wq! pgp2ZMdVIdPBp.pgp Description: PGP signature
Re: Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations
Thomas Viehmann wrote: > I'd be very thankful if the following could be packaged. I'd be able to > sponsor non-DDs if the packages are good. http://debian.pox.one.pl/pywavelets_0.1.6-1.dsc (I need a sponsor) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpNBGai3BIjN.pgp Description: PGP signature
Re: Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations
Yaroslav Halchenko wrote: > It seems that one.pl DNS servers are bad now... can't resolve even > pox.one.pl now. Alternative location? ip? It's in NEW already, but thanks for trying :-) -- :wq! pgpIVx6O6uCyj.pgp Description: PGP signature
Re: Deploying/packaging Pylons projects
# creating new Pylons app. $ paster create --template=pylons helloworld # creating Egg (f.e. for Windows users) $ python setup.py bdist_egg # will create an Egg in dist dir # creating debian package $ zcat ../helloworld_0.0.0dev-1.diff.gz | patch -p1 # see attachment $ debuild -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- helloworld_0.0.0dev-1.diff.gz Description: application/gunzip pgpsEAotYiJZ6.pgp Description: PGP signature
Re: Deplyoing Pylons applications as Debian packages?
Piotr Ozarowski wrote: > # creating new Pylons app. > $ paster create --template=pylons helloworld > > # creating Egg (f.e. for Windows users) > $ python setup.py bdist_egg # will create an Egg in dist dir > > # creating debian package > $ zcat ../helloworld_0.0.0dev-1.diff.gz | patch -p1 # see attachment > $ debuild and (as promised on #debian-python) here's pure debhelper version (init.d script is still missing) To Pylons ML readers: here's CDBS one: http://lists.debian.org/debian-python/2007/03/bin0.bin If you're using pkg_resources(), add python-setuptools to Depends: (and other used dependencies, like: python-elixir, python-mako, ...) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- helloworld_0.0.0dev-1.diff.gz Description: application/gunzip pgp0bCAwbXwQr.pgp Description: PGP signature
Re: Proposed update to the python policy
[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
Re: Proposed update to the python policy
[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
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?
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp9ebcVJNaDY.pgp
Description: PGP signature
Re: Proposed update to the python policy
[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?
Anyway, if it does not change hashbang then OK, it's deprecated.
> > 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
systems are doing basically the same thing now. I'm using python-central
in most of my packages (I use python-support in some co-maintained
packages) - I moved to pycentral because pysupport was not handling
Python extensions at the time I needed it. It does handle it now so if
pysupport wins the vote I will be able to easily move to the new default
system.
BTW: I would really love to see pyversions file content moved back to
debian/control file, so that using grep-dctrl would be a lot easier.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgprRv2yrWq58.pgp
Description: PGP signature
Re: Proposed update to the python policy
[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 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" ) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp8mCFvBDkzM.pgp Description: PGP signature
Re: Proposed update to the python policy
[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- 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)
* 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"
* 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?)
case 2:
* as above, except binNMU is needed after default python version change, no
need
to remember hashbang change
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
case 4:
* as above, binNMU needed
* XB-Python-Version: >=2.4
* Provides: python2.4-wavelets
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpm37LHCXcce.pgp
Description: PGP signature
Re: Proposed update to the python policy
[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 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- 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 ?
I mean just recompile .pyc files (for new default Python version), leave
package untouched
> > * 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- know to recompile it just for one version and not
for all supported ones?
>
> > * 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!)
> > 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.
I mean recompile pyc files only of course, not the whole package (as I
said: no binNMU )
> > 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?
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpK5zbY9XiLN.pgp
Description: PGP signature
Re: Proposed update to the python policy
[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- 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)
> > 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.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpPq44hl27Vi.pgp
Description: PGP signature
Re: Proposed update to the python policy
[Josselin Mouette, 22.03.2007] > Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit : > > > 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 :) > > This is not a problem for the dh_ tool, as the resulting binary package > will be exactly the same in both cases. simplejson package is build only for python2.4, because only this version is fully supported in Debian now. I (as a package maintainer) want it to be (byte-)compiled for all supported Python versions. It's arch:all so when new (2.5, 2.6, ...) Python version will be added to the supported ones or user will install unsupported Python version (that still matches versions specified in package's Python-Version header) I want python- to byte-compile it for all installed Python versions that my package can work with. I think it's dh_tool task to set Python-Version field correctly (by parsing build dependencies and XS-P-V / pyversions) so that python- and RMs will not have problems with telling (grep-dctrl): * which packages will need binNMU when list of supported Python version will change (public python extensions) * which packages will need binNMU when default Python version will change (shebang issue, private python extensions) * which packages will only need byte-compilation for newly added Python versions (or removal of old .pyc files) * which packages will only need recompilation of .pyc files (private modules, public modules used only by Python applications ["current" keyword]) If dh_tool will set Python-Version header in binary package and it's (Python-Version's) content will be standardised as well as the location where python- should look for .py/.so files, I think we can just set Depend: to python-system where python-system is provided by python-central or python-support (no need to install both systems) > This is indeed a problem for the release managers, as they need a way to > disambiguate between these two cases. In this case, "current" is a hint, > a declaration that has to be matched by what's in debian/rules, but it's > not a proof the package is built this way. > > If we really need such a hint, I'd prefer to see it in another place > than the field containing version information. However we might as well > use the python-dev / python-all-dev build-dependencies to obtain the > same information. python-dev / python-all-dev issue should be (IMHO, of course) used just at the build time to set Python-Version correctly. python-system should not depend on informations from source packages (it simply doesn't have access to them). Python-Version (or whatever we will call it) should contain informations about: * which Python versions this package can work with * is this package meant to be compiled for all allowed Python versions or just for a single (default or nearest available) version * and maybe: does this package has a shebang to handle If the second, python-system can check [1] if it can/should change shebangs automatically (if package is arch:all and default Python version meets requirements) [1] at user's machine (when new version of "python" package will be installed) > I don't think we are missing any case, but we should probably write some > binNMU detection script for use by the release managers, summarizing all > of these thoughts. It should be really easy if all Python-related packages will have Python-Version field. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpcG4pKkUDFa.pgp Description: PGP signature
Re: Proposed update to the python policy
[Pierre Habouzit, 22.03.2007] > On Thu, Mar 22, 2007 at 10:13:40PM +0100, Piotr Ożarowski wrote: > > [Josselin Mouette, 22.03.2007] > > > Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit : > > > > > 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 :) > > > > > > This is not a problem for the dh_ tool, as the resulting binary package > > > will be exactly the same in both cases. > > > > simplejson package is build only for python2.4, because only this version > > That's a pure python module, that scope of the policy is well > understood, and works without anybody's help thanks to the dh_tools. > There is no human help needed for that, at all. I wasn't in Mexico, I didn't write the policy but (I think) I still know the basics of the new policy. I'm maintaining pure Python modules [1], Python extensions [2], Python applications with public modules [3], Python applications with private modules [4] and I try to help other Debian Python Modules Team members. I just want to say that current tools are not perfect [5] to me and I think we could make them better (and I'm using both, though I prefer python-central for now; heck, I have even sent (accepted) patches to CDBS, but still prefer pure debhelper) [1] chardet, elixir, jinja, mako, paste, pastedeploy, pastescript, pastewebkit, pudge, pygments, routes, simplejson, sqlalchemy [2] pyenchant, pywavelets [3] gaupol [4] griffith, pypar2 [5] f.e. both systems are not handling old .pyc files (#385775, #409390) > > > This is indeed a problem for the release managers, as they need a way to > > > disambiguate between these two cases. In this case, "current" is a hint, > > > a declaration that has to be matched by what's in debian/rules, but it's > > > not a proof the package is built this way. > > > > > > If we really need such a hint, I'd prefer to see it in another place > > > than the field containing version information. However we might as well > > > use the python-dev / python-all-dev build-dependencies to obtain the > > > same information. > > > > python-dev / python-all-dev issue should be (IMHO, of course) used just > > at the build time to set Python-Version correctly. python-system should > > not depend on informations from source packages (it simply doesn't have > > access to them). Python-Version (or whatever we will call it) should > > contain informations about: > > > > * which Python versions this package can work with > > that's not doable. The PV field or its equivalent debian/pyversions > has to be filled. There is no way for the build system to know if this > or that extension is compatible with this or that python version. This > is a declaration that the maintainer has to do. I'm just saying that there's no need to put "current" (better name would be "single") in XS-P-V but dh_tool should put it in *XB-P-V* when needed. I still think it's maintainer's job to specify (XS-P-V field) all compatible Python versions for the package. > This information is only useful for the dh_tool though, so I don't see > the need to make it mandatory. It's up to the maintainer to choose what > fits his needs. What has to be mandatory is the annotations that other > python packages needs (the Python-Provides proposal), and what the RM > need (and here PV is only part of the things the RM need). another example: when python2.3 was default and pytho2.4 "only" a supported one, I've packaged gaupol. Gaupol is Python application with public modules (i.e. it has files in "site-packages" directory) and it requires at least python2.4. All I needed to do was: * set Build-depends: to python-dev (>=2.4) | python2.4-dev * set XS-P-V to "current, >=2.4" and pycentral did change the hashbang and didn't compile modules for 2.3 (and I mean on user's machines as well as during the build time). Now I just want to be sure that pycentral will not compile it for python2.5 when it will be added to the supported Python-versions. Without "current" in XB-Python-Version I can't be
Re: Proposed update to the python policy
[Steve Langasek, 22.03.2007] > On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote: > > yes, but since package is depending only on python-dev (and not > > python-all-dev), > > python- 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) > > hmm, three things: > > - relying on Build-Depends to indicate whether a package builds "current" or > "all" doesn't seem to leave a way to differentiate between packages that > follow the new policy and really /are/ binNMUable, from those that don't > follow the new policy but obviously still need to b-d on python-*dev. > - Build-Depends information is only in the Sources file, not in Packages; > detecting packages that need binNMUs requires trawling the Packages file, > it would be nice if it didn't require correlating both Packages and > Sources Build-Depends is used only at build time. Python-Versions field is in binary package. > - having a package's build rules behavior vary in response to the contents > of the build-depends is unprecedented and, IMHO, a very bad idea. > Basically, this would eliminate a very important check that the maintainer > hasn't made a mistake along the line -- it's far better to get a build > failure in such a case than to get a misbuilt package. so lets keep "current" in XS-P-V (and not only in XB-P-V) BTW: I'm building my python modules for *all* supported Python version at build time, even for arch:all packages - just to make sure they compile fine. > > > 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 don't think it was intended that "current, >= 2.X" be used to > *successfully* build packages when 2.X is greater than the currently > available python-dev. if python-dev (>=2.X) | python2.X-dev is not available during build process, it will just fail and maintainer will not be able to upload such package, am I right? BTW: "current, >=2.4" helped me a lot with packaging gaupol when python2.3 was default -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpEOkapNSqUL.pgp Description: PGP signature
Re: Proposed update to the python policy
[Steve Langasek, 23.03.2007] > On Fri, Mar 23, 2007 at 09:58:18AM +0100, Piotr Ożarowski wrote: > > > - relying on Build-Depends to indicate whether a package builds "current" > > > or > > > "all" doesn't seem to leave a way to differentiate between packages that > > > follow the new policy and really /are/ binNMUable, from those that don't > > > follow the new policy but obviously still need to b-d on python-*dev. > > > - Build-Depends information is only in the Sources file, not in Packages; > > > detecting packages that need binNMUs requires trawling the Packages > > > file, > > > it would be nice if it didn't require correlating both Packages and > > > Sources > > > Build-Depends is used only at build time. Python-Versions field is in binary > > package. > > Sorry, what's your point? You seem to be repeating what I've said. My point is Python-Version can contain "current" in XB-P-V even if it's not in XS-P-V. It was just an proposal (for people that don't like redundant data) > > > > > 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 don't think it was intended that "current, >= 2.X" be used to > > > *successfully* build packages when 2.X is greater than the currently > > > available python-dev. > > > if python-dev (>=2.X) | python2.X-dev is not available during build > > process, it will just fail and maintainer will not be able to upload > > such package, am I right? > > Ugh, it should fail *regardless* of the existence of python2.X-dev. Why > would you ever call it "current" if it's building for something that *isn't* > the current version of python? A package should only be called "python-foo" > if it's built for "python"; if it's built for python2.X explicitly, the > package name needs to reflect that, which means manual changes are needed to > update it for a new python version. That's out of scope for 'current'. when I write "current" I mean "single" (I didn't choose name for this keyword) If package is build for a single Python version and default Python version is not supported by this package, hashbang has to be set correctly and modules it provides (byte-)compiled (at build time *and* during the install/default python version change) > > BTW: "current, >=2.4" helped me a lot with packaging gaupol when > > python2.3 was default > > Which is not an arch: any package, so is irrelevant to binNMU support. I couldn't set "python" in hashbang (as I said before: gaupol will not work with python2.3). Package was build when python2.3 was default so hashbang was set to python2.4. Now when python2.3 was removed from Debian, package needed binNMU (due to wrong hashbang) even if it's arch:all. > Oh, and if gaupol really needs python 2.4 or better, then the package's > current dependencies are wrong... python2.4 is default now so there's no need to add extra dependencies -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgphBsElVc2D9.pgp Description: PGP signature
Re: Proposed update to the python policy
[Pierre Habouzit, 23.03.2007]
> current in X?-P-V sucks a lot because X?-P-V explains which python
> version the package supports, whereas current is not about that but
> about the kind of packaging ways it has. This information should never
> have been folded in the same field, I only recently got what it really
> meant because of that. It's more than confusing.
OK
X?-Python-Version: informations about supported Python versions ("2.3-", ">2.3",
">=2.4, <=2.7", etc.)
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
> IMHO that's better suited to say that to the dh_tool. Like a :
>
> dh_py{support,central} --single-version
another solution and it looks good as well. If it will set package type
correctly
so that python-system (the one installed on target machine, not the one
installed
on build machine) will byte-compile only for Python versions I want, then it's
OK
with me. I'm able to control Python versions used during build time, if
I will be able to control it on target machine as well (through
XB-Python-Version and XB-Python-Type) than it's all what I want.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpY06Th5wtXg.pgp
Description: PGP signature
Re: Proposed update to the python policy
[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.
> 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 ;-)
BTW: I was using "XS-Python-Version: 2.4" when "current, >=X.Y" was not
supported. That really wasn't "New policy"-like.
PS I thought it's time to think about merging py{central,support} but I
guess this discussion will end on "current" keyword.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgplgIbybbtBO.pgp
Description: PGP signature
Re: Proposed update to the python policy
[Steve Langasek, 24.03.2007] > On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote: > > I couldn't set "python" in hashbang (as I said before: gaupol will not work > > with python2.3). Package was build when python2.3 was default so > > hashbang was set to python2.4. Now when python2.3 was removed from > > Debian, package needed binNMU (due to wrong hashbang) even if it's > > arch:all. > No, it needed an *update* when python2.3 was removed. BinNMUs a) are for > arch: any packages only (this is for a reason), and b) not an appropriate > method for changing things like the python hashbang used in a script, which > is something that should be evaluated on a per-package basis. you're right, python2.4 is still available in Debian so update is not required, but please note that all applications with python2.3 in hashbang will not work now, even if they're arch:all (so new upload is needed). > > > Oh, and if gaupol really needs python 2.4 or better, then the package's > > > current dependencies are wrong... > > > python2.4 is default now so there's no need to add extra dependencies > > Um, no. Your package is supposed to have a versioned dependency on python > (>= 2.4), and it doesn't. I have replaced "2.4" with "current" when python2.4 became default, but yes - I will change it to "current, >=2.4" with my next upload (package depends on python (>=2.4) only during build time now) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpJoHByZhUHc.pgp Description: PGP signature
Re: Proposed update to the python policy
[Josselin Mouette, 28.03.2007] > While the discussion is still ongoing about the "current" keyword, it > seems that everyone agrees with the other changes which are only loosely > related. Can we proceed with these, until we agree on how "current" > should be replaced? IMHO, yes -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpMzbtEu5Fxx.pgp Description: PGP signature
Re: PMPT membership
> I'm the current maintainer for the python-scapy debian package. I want > to join the Python Molules Packaging Team to maintain this and others > future python related packages. I want to use the subversion repo for > the debian files too. I see two accounts in Alioth for David Villa: dvilla-guest and davidvilla-guest, which one is yours? -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpNX3rgduhwH.pgp Description: PGP signature
Re: PMPT membership
[David Villa, 11.04.2007] > Oh, I forgot to give you my Alioth login. Sorry for that. My login is > davidvilla-guest. > > thank you. You have been added. Welcome! -- :wq! pgplYDTrSIVs2.pgp Description: PGP signature
Re: PMPT membership
let me cite alioth's gforge: "User Added Successfully" Welcome Ondrej :-) PS OK, OK, I will also mention that I can add new members to the team next time I ask someone to consider joining DPMT... -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpyLxWr2VuAB.pgp Description: PGP signature
Re: Python modules team membership request
> I would like to be added to the team. I intend to maintain my package > pubtal within the team, and help out with general QA work. > > My alioth login is rodrigogc-guest You have been added. Welcome! :-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpUodzuYufP5.pgp Description: PGP signature
Re: packages using python-support and renaming egg-info directories will FTBFS
[Gustavo Noronha Silva, 12.05.2007] > Beware when updating your packages! Below you'll find a dd-list -i of > packages containing .egg-info in the name in a directory or file, and > also depending on python-support generated by me and POX. packages already updated: myghtyutils, nose, kid, pylons, python-cherrypy, cherrypy3, json-py, configobj, turboentity, urwid, elementtree, myghty, simplejson, turbokid, turbojson, beaker, webhelpers, kiwi yeah, keeping debian dirs inside DPMT's repo has some advantages ;-P Want to join the team? See http://python-modules.alioth.debian.org/ -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpLnsBAk9dMA.pgp Description: PGP signature
Re: Python modules team membership request
> Em Dom, 2007-05-27 às 12:23 -0300, Goedson Teixeira Paixao escreveu: > > I'd like to be added to the Python modules team. I'm adopting the kiwi > > package and would like to keep maintaining it within the team and also > > help with general QA work. > > My alioth id is goedson you have been added, welcome :-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpRBg2Q2ANPa.pgp Description: PGP signature
Re: Joining the team
> Hi! I would like to join the team so I can maintain my packages within the > team as well as help out with maintainance of Debian python-related packages. > I currently maintain python-pmock, and have two python-related [1] packages > needing sponsorship at mentors.debian.net (related to two outstanding ITPs). > My alioth username is 'jmalonzo-guest'. > > Thank you and I hope this request will be approved. You have been added. I will take a look at your packages later tonight (if no one else will volunteer) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpQ5r8cJCpzt.pgp Description: PGP signature
Re: Python plotting packages
> Hi
Hello
>I do have two packages that I would really like to get into the Debian
> distribution. They are both python plotting packages and their names are
> pyqwt
> pyqwt3d
* please don't repackage upstream tarball if it's not needed (dpkg-source
will change directory name if it's changed in diff.gz)
* XB-Python-Version header is not needed in python-qwt3d-doc and
python-qwt5-doc packages
* is "dh_clean -k" really needed in install rule?
* "This package contains the Qt4 python bindings" is in both
python-qwt3d-qt4 *and* python-qwt3d-qt3 package's description
(same with python-qwt5-qt{3,4} and Qt3). Please fix the Qt version and
add lines with "." char so that this line will not be wrapped f.e. in
aptitude. See description's example below
* Please replace "It's homepage is http://pyqwt.sourceforge.net/"; with
Homepage: http://..., see example bellow (note the line with dot and
additional space char. - see dev.ref. 6.2.4 [1])
* python-qwt5-doc and python-qwt3d-doc packages should be build in
binary-indep rule (and not binary-arch) (see dh_*'s -a and -i options)
* please add comments ("## DP:" lines) to your patches, it's not obvious
why you're removing these options
* why are you recommending *-dev packages?
* CHANGES-5.0.0 and CHANGES-0.1.4.TXT files can be used as upstream's
changelog (add it as a parameter to dh_installchangelogs)
[...]
| 3-dimensional data.
| .
| This package contains the Qt4 python bindings
| .
| Homepage: http://pyqwt.sourceforge.net/
[1] http://tiny.pl/gpf4
[CCing Torsten Marek, python-qt{3,4} maintainer]
Torsten:
packages:
http://mentors.debian.net/debian/pool/main/p/pyqwt3d/pyqwt3d_0.1.4-1.dsc
http://mentors.debian.net/debian/pool/main/p/pyqwt5/pyqwt5_5.0.0-1.dsc
upstream sources (md5sums don't match):
http://downloads.sourceforge.net/pyqwt/PyQwt-5.0.0.tar.gz
http://downloads.sourceforge.net/pyqwt/PyQwt3D-0.1.4.tar.gz
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpjgApCKJp3R.pgp
Description: PGP signature
Re: Joining the Python Packaging Team
> I'd like to join the Python Packaging Team to work on Louie and > probably the other existing modules the team maintains. > > My Alioth username is "lool". "User Added Successfully", welcome :-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp94alnIR5MV.pgp Description: PGP signature
Re: new upstream versions of DPMT's packages
[Bernd Zeimetz, 24.06.2007] > Hi, > > uscan detected some new upstream versions of packages maintained within > > the team (see below). My question is: how can I help you with uploading > > these new versions into Debian? If there are any problems, please ask on > > the mailing list or on #debian-python channel. > > > seems you've setup a cronjob to check for the pacakges? Some weekly or > monthly output to the -team list would be nice to have in my opinion. For now it runs only on my local machine, here's the command: $ uscan --check-dirname-level 0 --report python-modules/packages/*/trunk/ > Also I can take care of pyusb, I'm listed as Uploader anyway. ping me on #debian-python when you will need an upload -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp0y6SYesWyn.pgp Description: PGP signature
new upstream versions of DPMT's packages
notify-python: Newer version (0.1.1) available on remote site: http://www.galago-project.org/files/releases/source/notify-python/notify-python-0.1.1.tar.gz (local version is 0.1.0) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgphTfpG6jNQk.pgp Description: PGP signature
Re: Joining the team
> I'd like to maintain python-feedparser (and some other packages in a near > future) within the team. You're in. Welcome in the group :-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp3TYlFCsvxK.pgp Description: PGP signature
Re: new upstream versions of DPMT's packages
[Jonas Meurer, 25.06.2007] > On 24/06/2007 Piotr Ożarowski wrote: > > Processing watchfile line for package python-mysqldb... > > Newest version on remote site is 1.2.2c1, local version is 1.2.2 > > python-mysqldb: Newer version (1.2.2c1) available on remote site: > > > > ftp://heanet.dl.sourceforge.net/m/my/mysql-python/MySQL-python-1.2.2c1.tar.gz > > (local version is 1.2.2) > > This one is a false positive. 1.2.2 is the final stable version while > 1.2.2c1 is a testing version superseeded by 1.2.2. watch file fixed in rev. 2615 -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpM9TkVjGypz.pgp Description: PGP signature
Re: Making all DD members of the team by default
[Raphael Hertzog, 26.07.2007] > I believe the perl and python team would benefit from using similar ACL > so that any DD who wishes to integrate his packages in the team can do so > without requesting access that we'll grant him anyway. We expect DD to be > educated and to ask before messing up if they're not sure of what > they're doing. In most cases, they'll figure it by themselves because > the available documentation hopefully directed them correctly. :-) > > This also let NMUer integrate their NMU in the VCS directly if they so > wish. > > As an Alioth admin, I can add those ACL. However I'd like to have your > opinion and agreement first. I think it's a good idea to add those ACLs. For people who want to be more involved in the team - I recommend to request joining alioth project here [1], though. This way we will know who actually is a member of our team and it will help non-DDs in searching for sponsor. OK, almost all RFS questions are asked on our IRC channel, but that list helped me when I was listed there as pox-guest. [1] https://alioth.debian.org/project/request.php?group_id=30714 -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpstLHJmN7zI.pgp Description: PGP signature
Re: RFS: feedparser (updated package)
> I am looking for a sponsor for the new version 4.1-9 of feedparser package. uploaded -- http://people.debian.org/~piotr/sponsor.txt pgpl2QvSJ5rSc.pgp Description: PGP signature
Re: Making all DD members of the team by default
[Gustavo Franco, 05.08.2007] > Piotr, would you mind update our dpmt policy, please? If you're busy > with other stuff ping me. :-) I'm not really a good doc writer, but my changes are in SVN already. Please fix them ;-P -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp97kdVcWeW6.pgp Description: PGP signature
Re: ITS: tftpy
> I am looking for a sponsor for my package "tftpy". see my tiny change in SVN, if you're OK with it, I'll upload -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpvSXbgGBLPG.pgp Description: PGP signature
Join the Python Applications Packaging Team
Hi, Do you need help with your Python application package but DPMT guys don't want to inject it in their repo because it's not a module? Do you have problems with finding sponsor due to this new nasty Debian Python Policy? I have something for you: new, shiny: *Python Applications Packaging Team* Interested? Read [1] or join us on #debian-python channel (OFTC network) [1] http://python-apps.alioth.debian.org/policy.html -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpmJdBbH8vOy.pgp Description: PGP signature
Re: Joining the PATP
Hi Julien > I created an initial packaging for screenlets, a python program to > display tiny stuffs on the desktop. I'm quite new in the world of > packaging so my work is far from perfect, and I have some difficulties > to find a sponsor for previous works I done. So, someone advise me to > join your team, for increasing my skills, find easier a sponsor and work > as a team to maintain the package. > > I'll be very glad if you accept me as a member of your team. if your alioth login is gilir-guest then you're in. Welcome :-) Please read our policy[1] and then inject your package in the team's SVN repository. You can also join #debian-pyton (OFTC network) if you want some fast comments. I will take a look at your package tomorrow after work. [1] http://python-apps.alioth.debian.org/policy.html -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpUAngkhV9VM.pgp Description: PGP signature
Re: RFS: python-pyglew + join team
Hi [Sandro Tosi, 23.10.2007] > http://matrixhasu.altervista.org/debian/python-pyglew_0.1.2-1.dsc I will check it tomorrow if no one will be faster. [...] > As soon as I'll find time, I'll inject (this and other python pkgs) > into group's svn repository; in the meantime, I'd like to request to > join the team; my alioth account is: morph-guest. You're added, welcome in the team :-) -- :wq! pgp6HeXXAoDPH.pgp Description: PGP signature
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
> 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
Hi Peter, > I'd like to join the team to continue the maintainership of my package > pydot. My alioth login is pcc-guest. Welcome in the team :-) PS Now we have three Peters in the team (ex equo with Davids) One more and we (Peters) will lead... ;-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp3gM9AjAQ30.pgp Description: PGP signature
Re: Why still 2.4? How can I help you?
> But Lenny and Sid are both still at Python level 2.4... If not now, then > when? don't worry, Lenny will not have python2.4 as a default Python version (or it will be released with python2.4 over my dead body ;) How can you help? See this thread: http://people.debian.org/~terpstra/message/20071005.180427.1dddb386.en.html -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp3bmtBj382N.pgp Description: PGP signature
Re: RFS: feedparser (updated package)
[Carlos, 02.01.2008] > I am looking for a sponsor for the new version 4.1-11 of "feedparser". my motherboard is working again, no need to mail @lists.d.o. anymore :) I will take care of it this evening. -- http://people.debian.org/~piotr/sponsor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pycha packaging
Hi Vincent,
> I have packaged Pycha, a simple chart-drawing library using Cairo as
> backend.
[...]
> Any feedback on the packaging is welcome.
* Priority: extra - why not optional?
* Build depend on python-support (>= 0.6.4) or you will have some
problems with Eggs
* add python-setuptools (>= 0.6b3-1) to Build-Depends
* add to source stanza (in debian/control):
Vcs-Svn: svn://svn.debian.org/python-modules/packages/pycha/trunk
Vcs-Browser:
http://svn.debian.org/wsvn/python-modules/packages/pycha/trunk/?op=log
* Provides: ${python:Provides} is not really needed (sorry Joss)
you can add ${misc:Depends} to Depends
* remove CHANGES.txt from debian/docs, add in debian/rules
DEB_INSTALL_CHANGELOGS_ALL = CHANGES.txt
* I want to make few uploads by myself before adding
"XS-DM-Upload-Allowed: yes", so please remove it for now (feel free to
leave it if upload will be done by any other DD that already knows
you)
> I would like to maintain it into the debian modules packaging team. My
> alioth login bernat-guest.
you're added, welcome in the team :-)
--
http://people.debian.org/~piotr/sponsor.txt
pgpYOAWlFqp9U.pgp
Description: PGP signature
Re: Pycha packaging
[Bernd Zeimetz, 04.01.2008] > Vincent Bernat wrote: > > I have uploaded to SVN using svn-inject -o. Because of the modified > > SOURCES.txt, I have now a not-so-clean SVN tree. Should I leave as is or > > should I remove SOURCES.txt from trunk and branches? > > please remove it and add a patch using quilt or dpatch. or just remove this file in clean rule, it will be regenerated with every ./setup.py call... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-modules team membership request
Cześć Jakub, > I'm the author of the pipeline[1] module. Please add a full copy of GPL licence inside the upstream tarball, we cannot distribute it without it. Removing debian dir would make our lives a little bit easier as well... :-) > I'd like to join the python-modules team in order to maintain the Debian > package for python-pipeline. I could possibly also help with some other > packages. > > My Alioth login is jwilk-guest. you're in. Welcome! :-) Inject debian dir into the repository, if you will have questions, ping me via GG or IRC -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpPWo9IEyMyj.pgp Description: PGP signature
Re: Pycha packaging
[Vincent Bernat, 04.01.2008] > I have removed it. I will upload this to SVN shortly and will ask you > for upload when the description review by debian-l10n-english is > complete. ping me via private mail or on IRC (#debian-python, OFTC network, nickname: POX) > > you're added, welcome in the team :-) [...] > May I also add nevow to the list of team-maintained packages? > http://packages.qa.debian.org/n/nevow.html it's a Python module, you're a team member - I don't see a reason why you shouldn't add it :) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpuCU2KvpD9T.pgp Description: PGP signature
Re: RFS: pondus
Hi Eike, [Eike Nicklas, 2008-02-04T17:51] > It would be great if you had a look at the package, provided some > feedback on the packaging and eventually sponsored the package once it > is packaged properly. * you've missed python-gobject (src/pondus/gui/dialog_add.py, line 23), but since python-gtk2 depends on it, I guess it's OK. * how about installing NEWS file as upstream changelog? (`dh_installchangelogs NEWS`) I can upload it now (without above changes), but please consider joining PAPT [1] first. [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam -- http://people.debian.org/~piotr/sponsor.txt pgpKn2T1WKj6D.pgp Description: PGP signature
Re: RFS: pondus
Hi, [Eike Nicklas, 2008-02-05T17:44] > Thanks for the hint, I will add the dependency on the next upload (or I > can reupload, if you prefer that). no need to upload it anywhere anymore, just inject it into the repo (please remember about svn-inject's "-o" option [1]) and ping me. > > * how about installing NEWS file as upstream changelog? > > (`dh_installchangelogs NEWS`) > > This is done by upstream setup.py, the NEWS file is already in the > package. I know. I just wanted it to have new name (that's what dh_installchangelogs would do). Could you symlink it to /usr/share/doc/pondus/changelog.gz then? [1] we're keeping debian dir only in SVN; I will download upstream sources via debian/watch or `debian/rules get-orig-source`) -- http://people.debian.org/~piotr/sponsor.txt pgpbpsWwOXbhq.pgp Description: PGP signature
Re: I want to join the Python Modules Packaging Team
Jan, you're a new team member. Welcome :) Please add DPMT [1] to Uploaders or Maintainer field, add these two fields to debian/control (in source stanza): Vcs-Svn: svn://svn.debian.org/python-modules/packages/migrate/trunk Vcs-Browser: http://svn.debian.org/wsvn/python-modules/packages/migrate/trunk/?op=log , inject package into the repo and mail me. [1] Debian Python Modules Team <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to DDs: sponsors needed in DPMT and PAPT
Hi, We need more sponsors in Debian Python Modules Team and Python Modules Packaging Team. If you have few free hours, please take a look at our TODO pages [1,2] and put your name in "DD" column if you're willing to work on a package with our non-DD member (and remove row once package is uploaded). Most of packages there are NEW (packages previously accepted are easier to check, so they're processed fast). Thanks in advance [1] http://wiki.debian.org/Teams/PythonModulesTeam/TODO [2] http://wiki.debian.org/Teams/PythonAppsPackagingTeam/TODO -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpCHLShsQXIo.pgp Description: PGP signature
Re: On team maintainership of DPMT (PAPT) packages
Hi, [Sandro Tosi, 2008-03-09] > I'd like to report here my feelings about the current way to maintain > package in our repositories (DPMT and PAPT). my turn. How I understand the team relationship: [0] * if DPMT/PAPT is in our repo. (no matter where the team name is, in Maintainer or in Uploaders field) I'm doing changes in SVN, not via bugs in BTS. I'm not asking anyone before commiting (unless I'm doing major[1] changes, see below) * if team name is in Maintainer field, I'm also uploading without asking anyone (but I'm adding my name in Uploaders if changes are major[1], otherwise I'm[2] using team address as uploader[3]) * if team name is in Uploaders, I'm asking Maintainer or one of people listed in Uploaders before uploading (or even before commiting, see[1]). If bug (that my change will fix) is RC, I *try* to reach Maintainer, but I'm uploading before dinstall time even without having a response from M. If my changes are not really that important (example: s/XS-Vcs-Browser/Vcs-Browser change) I'm just updating it in SVN and leaving it there with distribution field set to "UNRELEASED". Unless I'm wrong[0], I don't see a need to change the policy. INAL, but I think the policy allows me to do above (nasty) things :-) [0] I might be wrong, correct me and I'll stop doing it [1] major = switching from python-support to python-central, changing installation directory (think: DESTDIR), etc. [2] well, never happened so far, I will do it once I need it, though[0] [3] i.e. "last updater" - name in changelog, the one before the date -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpWKvTrGv5Ba.pgp Description: PGP signature
Re: On team maintainership of DPMT (PAPT) packages
[Piotr Ożarowski, 2008-03-09] > * if DPMT/PAPT is in our repo. (no matter where the team name is, in s,DPMT/PAPT,package sorry pgpN28nSzs0aN.pgp Description: PGP signature
Re: handling /usr/local/lib/python2.x/site-packages in sys.path
[Matthias Klose, 2008-03-11] > - add another path (e.g. /usr/local/python/lib2.x/site-packages), >and remove the /usr/local/lib/python2.x/site-packages path after >the next release. Does provide an upgrade path, but doesn't solve >the probem immediately. I would choose this option or even remove /usr/local/* from sys.path completely. If one wants to play with unsupported Python modules or Eggs, he should sys.path.append(his_path) by hand, IMHO. If we additionally force ez_* mess to install to /usr/local/ by default, we will get rid of one of the most common problems I receive from users of my packages. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp5fH41nar8Z.pgp Description: PGP signature
Re: handling /usr/local/lib/python2.x/site-packages in sys.path
[Sebastian Rittau, 2008-03-11] > On Tue, Mar 11, 2008 at 06:58:56PM +0100, Piotr Ożarowski wrote: > > I would choose this option or even remove /usr/local/* from sys.path > > completely. If one wants to play with unsupported Python modules or > > Eggs, he should sys.path.append(his_path) by hand, IMHO. > > I would not consider installing packages that are not packaged in Debian > "playing". Installing such packages is a common use case for system > administrators and advanced users. With the same reasoning we could > remove /usr/local/lib from /etc/ld.so.conf. true. /me still doesn't know how to (at the same time) eat a cookie (get rid of Egg problems) and still be able to keep it (give advanced users/administrators possibility to add local modifications). -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgptrogCSkHrZ.pgp Description: PGP signature
Re: Request: mother
Hi Antonio, [Antonio De Luci, 2008-03-24] > I would like to be added to Team DMTP. I intend to keep the mother's > package on DPMT. You're a new team member, welcome! BTW: you will need to list some good advantages over SQLAlchemy to get it sponsored by me (python-sqlalchemy maintainer :-) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpevfmMMKe5U.pgp Description: PGP signature
Re: Would like to join the PMPT
Hi, [Y Giridhar Appaji Nag, 2008-03-28] > I would like to maintain sclapp [1] and pytagsfs [2] within the Python > Modules Packaging Team. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472769 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471971 > > Please add me to the PMP Team on Alioth. My userid is appaji-guest. You're a new team member, welcome! Inject your packages into the repository and let us know[1] if you will need help with something or when your packages will be ready for an upload. [1] via #debian-python channel or debian-python ml or python-modules-team ml -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpN3mbsyrOZq.pgp Description: PGP signature
Re: Phatch-0.1.3 is ready for packaging
[Stani, 2008-04-07] > Phatch 0.1.3 contains some fixes and updated translations. > > It is available at the usual place: > http://sd-2986.dedibox.fr/photobatch/download/package/phatch-0.1.3.tar.gz > > I've updated the changelog already. Could someone upload it? uploaded (please send "RFS" mails directly to me for packages I sponsored once, specially if I'm listed in Uploaders :) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpnP1mD8GCBi.pgp Description: PGP signature
Re: Debian has switched to python2.5
python2.5 is default since less than 24h, binNMUs were requested, please give our build daemons some time. In the mean time you can take a look at [1] and try to fix some old DPMT bugs :-) [1] http://qa.debian.org/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
[Raphael Hertzog, 2008-04-15 09:31]
> On Mon, 14 Apr 2008, Adeodato Simó wrote:
> > Finally, and quite importantly, there is what to do with modules that
> > have been added to the standard library in 2.5 (ctypes, celementtree,
> > wgsiref). These use either pycentral or pysupport, and since they mark
> > themselves as for python << 2.5 only, the dependency generated is on
> > python (<< 2.5), rendering them uninstallable.
>
> I think they should simply be updated to not use ${python:Depends}.
> I wonder if that should be replaced by some custom dependency however.
> Probably not. There's no reason to depend on python-2.4... that's the
> job of packages containing python scripts requiring 2.4.
I guess my mail from yesterday didn't make it... anyway, ctypes and wgsiref
are already fixed (I will file bugs against python-support and python-central
later) and celementtree should be fixed by binNMU (it worked on my
desktop)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs that'll block python 2.5
[Josselin Mouette, 2008-04-15 12:32] > On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote: > > Finally, and quite importantly, there is what to do with modules that > > have been added to the standard library in 2.5 (ctypes, celementtree, > > wgsiref). These use either pycentral or pysupport, and since they mark > > themselves as for python << 2.5 only, the dependency generated is on > > python (<< 2.5), rendering them uninstallable. > > The solution is really simple, just add them to python’s Provides: list. python2.5 package already does that, the problem was that python-support generated something like "python (<<2.5)" for "2.1-2.4", anyway, Depends are filled in by hand in python-wsgiref package and I will file a bug in python-support after work. In python-ctypes there was a different problem - XS-Python-Version's content was wrong (I changed "all" to ">=2.1, <<2.5") -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mutagen (1.14-1)
[Tristan Seligmann, 2008-06-03] > http://mithrandi.net/debian/pool/main/m/mutagen/mutagen_1.14-1.dsc uploaded -- http://people.debian.org/~piotr/sponsor.txt pgpqV9oLTfQy3.pgp Description: PGP signature
Re: Namespace and packaging
Hi,
[Jerome Schneider, 2008-06-08]
> I took python-pastedeploy as example because it's the same type Of
wow, my package taken as a reference ;-)
> package. But with my package after an installation, Python doesn't find
> my module :
> >>> import aditam.core
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: No module named core
in debian/rules, add after line 25:
rm -f debian/${p_name}/usr/lib/python$*/site-packages/aditam.core-*.pth
and everything will work fine (package still needs some work, though)
> If someone could take a look to the sources :
> http://dl.share-spirit.net/aditam.core-0.1.tar.gz
please point us to .dsc file next time, it's easier to download all the
files with dget.
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp78ZynJSLgP.pgp
Description: PGP signature
Re: Joining the team with new packages: rope and ropemacs
[David Spreen, 2008-07-30] > I am interested in joining the python-modules team with two new "netzwurm" user added, welcome > Any feedback on the packages is appreciated. * debian/docs - README.txt is listed twice (in both packages) * rope-0.8.4: python-svn and mercurial packages are missing in Depends/Recommends/Suggests -- :wq pgpcLbHTVRDKV.pgp Description: PGP signature
Re: New versions of packages with DPMT in Uploaders field
[David Spreen, 2008-08-08 00:52] > What's the policy for new versions of packages that have DPMT in the > Uploaders field instead of the Maintainers field? see this[1] thread, my opinion is here[2] > Is it okay for team > members to upload new versions to the SVN or is that discouraged? update it in SVN without asking anyone, ask before uploading, thats *my* policy [1] http://lists.debian.org/debian-python/2008/03/msg00014.html [2] http://lists.debian.org/debian-python/2008/03/msg00016.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sclapp and pytagsfs (updated packages)
[Y Giridhar Appaji Nag, 2008-08-15] > I am looking for sponsors for my sclapp and pytagsfs packages. What about your previous sponsor (who-uploads reports the same person for both packages)? Is he busy? If yes, ping me in private, I will check and upload it (if everything is ok). -- http://people.debian.org/~piotr/sponsor pgpTsuwnOa4fv.pgp Description: PGP signature
Re: RFS: sclapp and pytagsfs (updated packages)
both packages uploaded and tagged (I fixed lintian warning in sclapp before uploading) [Alexander Reichle-Schmehl, 2008-08-18] > Yes, I am busy. Sorry :( no problem; some of my sponsorees are asking on various mailing lists for sponsoring packages I uploaded once without even trying to reach me first. I thought it's the same here (there was nothing about previous sponsor being busy in original mail) so that's why I asked. -- http://people.debian.org/~piotr/sponsor pgpkDmoVOncn7.pgp Description: PGP signature
Re: request to join debian python teams
Hi Serafeim, [Serafeim Zanikolas, 2008-08-20] > I'd like to join the python modules and apps teams to help with general QA. I've added you to both teams, welcome :-) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpzvprMBvBtR.pgp Description: PGP signature
Re: RFS: json-py (updated package)
[Daniel Watkins, 2008-08-21] > I am looking for a sponsor for the new version 3.4-4 > of my package "json-py". uploaded. Please contact release managers about unblocking it (note that -3 didn't propagate to testing) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpIlqWaI1xXx.pgp Description: PGP signature
Re: RFS: json-py (updated package)
2008/8/22 Daniel Watkins <[EMAIL PROTECTED]>: > On Fri, 22 Aug 2008 00:27:32 +0200 Piotr Ożarowski <[EMAIL PROTECTED]> wrote: >> uploaded. Please contact release managers about unblocking it >> (note that -3 didn't propagate to testing) > Thanks for your sponsorship (once again). > > I'm not totally convinced that it is worth requesting a freeze > exception (which I assume is what you're talking about) as the changes > between -2 and -4 are almost entirely concerned with the packaging > (there are no modifications to the functionality of the installed > package) and no bugs have been closed by -3 or -4 (with the exception > of the adoption bug). that lintian error you fixed is a RC bug (clean rule will not always work in -2)
Re: [Python-modules-commits] r6316 - in packages/python-feedvalidator/trunk/debian (watch)
2008/8/27 Carlos <[EMAIL PROTECTED]>: > On Sat, Aug 23, 2008 at 9:19 PM, <[EMAIL PROTECTED]> wrote: >> Added: packages/python-feedvalidator/trunk/debian/watch >> === > [...] >> +version=3 >> +http://code.google.com/p/feedparser/downloads/list >> http://feedparser.googlecode.com/files/feedparser-(\d.*)\.zip > > Piotr, I think you mixed up feedvalidator and feedparser here. They > are two different packages. sorry, my mistake (watch file removed) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwibber
[I just took a quick look at the package, I'm still on VAC] [Daniel Watkins, 2008-09-02 23:08] > I am looking for a sponsor for my package "gwibber". PAPT is in Uploaders so you can add the package to our TODO list[1] and/or ping us on #debian-python from homepage: | Please note that this is pre-alpha software are you sure you want to upload it to unstable? How about experimental? Did you contact Jorge and ask him about co-maintaining this package? Vcs-* fields are missing, python2.5 is hardcoded in debian/control (you probably want "python (>= 2.5)") [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam/TODO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of python2.6
[Ondrej Certik, 2008-10-03 11:41] > is there anyone packaging python2.6? Any plans for it? I'm sure Matthias will upload python2.6 to unstable short after releasing Lenny. For now Lenny has the highest priority. (i.e. if you want python2.6 in Debian - fix some RC bugs :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of python2.6
[Ondrej Certik, 2008-10-03 12:44] > When will Lenny be released? When the number of RC bugs goes to 0? mostly, yes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
[oc-spam66, 2008-10-08 11:55] >I went back to the former python-matplotlib package (0.98.1-1) and could >import pylab again. So I think there is a problem with python-matplotlib >0.98.1-1+lenny1.1 could you please try unstable one? (0.98.3-3) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-uniconvertor breaks help("modules") in python
FYI: python-uniconvertor 1.1.2-2 uploaded to testing-proposed-updates pgphpKtnUTWxI.pgp Description: PGP signature
Re: Joining the PMPT, got a package to add
[Vernon Tang, 2008-12-17] > I've got a Python module package to add (python-pytc, ITP #508822) and would > like to have it maintained within the PMPT, so I'd like to join. You're a new Python Modules Packaging Team (aka Debian Python Modules Team) member. Welcome on board :-) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpajB3kgnD4u.pgp Description: PGP signature
Re: [RFC] python-pyevent (unrelease)
Hi,
[Luciano Bello, 2008-12-18 00:58]
> I would like to listen/read your comments about python-pyevent before upload
> it.
binary package name should be changed to "python-event" (source package
probably as well) - you're using "import event" to load the module,
right?
it's arch:any package, so:
* you should build the package in binary-arch, not binary-indep
* please replace python-dev with python-all-dev, and build the
extensions for all supported Python versions (see jinja2 package for
an example debian/rules)
* add -dbg package (there are examples in our repo, again jinja2 has it)
* add Provides: ${python:Provides}
also:
* please add these fields in debian/control:
Vcs-Svn: svn://svn.debian.org/python-modules/packages/python-pyevent/trunk/
Vcs-Browser:
http://svn.debian.org/viewsvn/python-modules/packages/python-pyevent/trunk/
* add debian/watch file
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: Name for "real" python-pgsql module
[Paweł Tęcza, 2008-12-18 10:49] > I'm not DD, but I would like to make Debian package with python-pgsql > module [1]. I need it for PostgreSQL support for Courier-Pythonfilter > framework [2]. It has been debianized by Frederik Dannemare [3] and still > waits for sponsoring at mentors.d.n site [4]. > > The problem with python-pgsql module is that Debian has package with the > same name for long time, but it's different Python module! Its real name > is pypgsql [5]. > > So my question is: what should I call that package? python-pypgsql? ;) Will it be a problem to use psycopg2 instead? If these two libraries are compatible (they should provide the same api, no?), just use psycopg2. You can check it by changing filters/TtlDb.py lines 59-60 into: import psycopg2 self.dbapi = psycopg2 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
[Ondrej Certik, 2008-12-08] > P.S. bzed, POX, isn't it time to move our packaging to git? I was planing it for a long time, but never found time to actually do it. If you volunteer to do this, please send a message to PAPT mailing list, wait a week and if no one will complain, go ahead and convert the repository. Then we'll test it for a bit and if it will work fine, we'll do the same with DPMT repo (which has more developers so we'll use "hey, it's working perfectly fine in PAPT" argument ;). BTW, I'm Piotr or Piotrek outside IRC ;-P -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpIPMxrC11xa.pgp Description: PGP signature
Re: [Python-modules-team] ITP: python-pivy -- Coin binding for Python
[Teemu Ikonen, 2008-12-13] > http://git.debian.org/?p=collab-maint/pivy.git;a=summary [...] > The package is in a 'works for me' state and lintian clean, but there > may be something I missed. I'm not sure if I should build the C > extensions with than one python version, now they are built just for > the default python version. * please build it for all supported Python versions (pyversions -vs) [1] * add -dbg package [1] * why not Priority: optional? * optional: (required if I will be the one who uploads it ;) + remove the 0.5.0~svn2008.12.11-1 changelog entry and + rename 0.3.0-1 into 0.5.0~svn2008.12.11-1 (or mark 0.3.0-1 as UNRELEASED) * missing dependencies (Depends/Recommends/Suggests): + python-qt4* (-common?) + python-qt4-gl + python-opengl * how about adding a -doc package and installing (among other docs) examples there? * there's a local Scons in the upstream sources, make sure Debian's one is used Pleas note that I didn't build it as libsoqt4-dev's required version is still not available, any progres on this one? [1] see jinja2 package for an example -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp4ClGVPnLnm.pgp Description: PGP signature
Re: RFS: python-pytc
[Vernon Tang, 2008-12-18] > Now that I'm a member of the PMPT, I've committed python-pytc to svn. Could > someone take a look at it? * why not Priority: optional? * please build -dbg package * consider using debhelper7's command sequencer (man dh) instead of CDBS, it will be easier to build -dbg package without CDBS, IMHO * add Vcs-Svn and Vcs-Browser fields * did you send patches upstream? -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp9QwhG1IVyY.pgp Description: PGP signature
Re: [RFR] urlwatch
[Franck Joncourt, 2008-12-13] > http://git.debian.org/?p=collab-maint/urlwatch.git;a=summary looks good (just one question, see below). If you want me to upload it, please remove DM-Upload-Allowed for now (feel free to keep it if your regular sponsor is ok with uploading it with this flag) > /usr/share/urlwatch/examples/hooks.py.example > /usr/share/urlwatch/examples/urls.txt.example how about installing these in /usr/share/doc/urlwatch/examples ? > The only problem I have by working this way, is I have to patch urlwatch > to add /usr/share/urlwatch to the sys.path in order to be able to use > ical2txt :) if you want to avoid patching, you can install urlwatch binary in /usr/share/urlwatch directory and then symlink it into /usr/bin/urlwatch You can even install it as /usr/share/urlwatch/urlwatch.py (but still symlink it without the extension) - this way you'll have additional .pyc file which will speed urlwatch a little bit -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpPS7kavEOeP.pgp Description: PGP signature
Re: [RFR] urlwatch
[Adeodato Simó, 2008-12-18] > * Piotr Ożarowski [Thu, 18 Dec 2008 22:06:35 +0100]: > > > You can even install it as /usr/share/urlwatch/urlwatch.py (but still > > symlink it without the extension) - this way you'll have additional .pyc > > file which will speed urlwatch a little bit > > AFAIK, .pyc files are only for imported modules, and never for executed > scripts. They are certainly not created by default, and strace does not > show them being used either. that's why I wrote to install it as /usr/share/urlwatch/urlwatch.py (note the additional extension). > (Plus you wouldn't want .pyc files in /usr/share/ anyway AFAIK.) lots of packages are installing .py files into /usr/share/ (IMHO all Python applications should do this and thus not pollute global namespace) and pycentral/pysupport handles it fine. -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpOn0qBLaHOG.pgp Description: PGP signature
Re: [RFR] urlwatch
[Adeodato Simó, 2008-12-18] > Yes, I got that. You mean: > > /usr/bin/urlwatch -> /usr/share/urlwatch/urlwatch.py > > But even with that, strace does not show that a > /usr/share/urlwatch/urlwatch.pyc file would get used when invoking > "urlwatch". oh, right, thanks -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpxr8rf0c9hG.pgp Description: PGP signature
Re: [RFR] urlwatch
[Franck Joncourt, 2008-12-19 21:21] > >> /usr/share/urlwatch/examples/hooks.py.example > >> /usr/share/urlwatch/examples/urls.txt.example > > > > how about installing these in /usr/share/doc/urlwatch/examples ? > > You are right, that is a good idea. [...] > Upstream does that when setup.py is installed and I do not see how I > could bypass this without rewriting the setup.py file. The argument you can simply move (mv) files/directory in debian/rules -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
[Ondrej Certik, 2008-12-23 11:19] > emi...@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut > -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r > 865 piotr > 609 morph > 598 kov > 532 bzed > 388 pox 865+388=1253 looks like my vote is most meaningful ;-) unfortunately I use Git only outside Debian, so I don't know about issues git-buildpackage might have. I know it doesn't have mergeWithUpstream but it's written in Python, so we can implement this. The problem is (FWIK) that it's better to use Git with upstream sources (with tools like pristine-tar)... anyway, I vote for Git, but I'm open to alternative suggestions. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
[Piotr Ożarowski, 2008-12-23 13:37] > unfortunately I use Git only outside Debian, so I don't know about > issues git-buildpackage might have. I know it doesn't have > mergeWithUpstream but it's written in Python, so we can implement this. > The problem is (FWIK) that it's better to use Git with upstream sources > (with tools like pristine-tar)... anyway, I vote for Git, but I'm open > to alternative suggestions. update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream) for now - at least until all top contributors will have decent internet connection or we'll work out some kind of remote upstream branches schema so that one could choose what to download (and a script to download all repositories (packages) within the team) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: python-pytc
I cannot build it as I have currently access to i386 arch. only (and libtokyocabinet-dev is available for amd64 only), Please ping me (in private) when libtokyocabinet will be available for i386 or next week (I will be back home then)... unless someone else will pick it up in the meantime :-) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 3.0 ?
[andmalc, 2008-12-27 23:00] > I'd appreciate a package, if only to play with and not for > production. $ dget -x https://launchpad.net/ubuntu/jaunty/+source/python3.0/3.0-0ubuntu1/+files/python3.0_3.0-0ubuntu1.dsc $ cd python* $ debuild -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
