Re: RFS: decibel-audio-player (Adoption, new upstream release)

[Thomas Goirand]

On 09/20/2011 06:26 AM, Leonardo Marín wrote:
> Hi,
> This was what I did,
>
> ljmarin@LM trunk $ svn diff
> Index: debian/control
> ===
> --- debian/control(revisión: 7520)
> +++ debian/control(copia de trabajo)
> @@ -4,11 +4,12 @@
>  Maintainer: Leonardo Marín 
>  Uploaders: Python Applications Packaging Team 
> 
>  Build-Depends: debhelper (>= 8.0.0)
> -Build-Depends-Indep: python (>=2.4), python-support
> +Build-Depends-Indep: python (>= 2.6.6-3~)
>   

For what reason do you need that exact specific version of Python?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e788a8e.3040...@debian.org

Re: RFS: decibel-audio-player (Adoption, new upstream release)

[Thomas Goirand]

On 09/20/2011 09:13 PM, Piotr Ożarowski wrote:
>
> python binary package provides dh_python2 helper and that's why Leonardo
> bumped minimum required python version. See also
> http://wiki.debian.org/Python/TransitionToDHPython2
>   
Thanks for the pointer. However, I don't understand this:

"All packages that use the same namespace have to be
converted at the same time. Be sure to use Breaks or
Depends relationships to ensure you cannot mix
installation of python-support-based packages with
dh_python2-based ones."

Can you explain, or even better, enhance the wiki so
that you wont have to explain to another person?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e78de1d.7080...@goirand.fr

Re: Comments regarding xen-api_1.3-14_amd64.changes

[Thomas Goirand]

On 01/07/2012 08:44 PM, Luca Falavigna wrote:
> Hi,
> 
> it seems python files in python-xenapi package aren't byte-compiled properly.
> You may want to refine dh_python2 call to fix that.
> 
> Cheers,
> Luca

Hi Luca,

Good catch, thanks for noticing it and letting me know! I was doing
"dh_python2 /usr/lib/xcp", thinking that dh_python2 would only take that
folder as a supplementary one, but in fact, it seems that when I do
that, dh_python2 doesn't look anymore in /usr/lib/python*.

Frankly, I think this is an issue in the man page of dh_python2 which
doesn't explain how it works correctly. I've been staring at the man
page trying to guess what would happen, and here, miserably failed
(truth, I should have double checked the result, but still...).

Now, my understanding of the man page is that I should have done:

override_dh_python2:
dh_python2
dh_python2 --skip-private /usr/lib/xcp

Best would have been to explicitly write that one example in the man
page, IMHO (see patch attached). Please let me know if I'm wrong here.

I'm Cc:-ing debian-python@lists.debian.org and doko (current maintainer
for python) hoping that the man page can be fixed and such explicit
example added.

Cheers,

Thomas

P.S: There was other issues on this xen-api package that also pushed me
for another upload (like python-xenapi should have Replaces: xcp-xapi).
--- a/dh_python2.rst	2012-01-08 04:53:09.0 +
+++ b/dh_python2.rst	2012-01-08 04:55:33.0 +
@@ -70,6 +70,13 @@
 dh_python2 with --skip-private option and add another call with a path to this
 directory and new options.
 
+For example, if your package is called foo, and packages things in the folder
+/usr/lib/foo-bar, then you could do the following in your debian/rules:
+
+override_dh_python2:
+	dh_python2
+	dh_python2 --skip-private /usr/lib/foo-bar
+
 pyinstall files
 ~~~
 Files listed in debian/pkg.pyinstall file will be installed as public modules

How does team maintenace of python module works?

[Thomas Goirand]

Hi,

Because I'm currently packaging Openstack Grizzly, which will be out
next April, I need a newer version of python-mock. So I filled:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699147

but no reply so far, and this worries me.

I haven't done the bug fillings for other python modules which I'm
concerned about, but the problem will be the same for others.

So I wonder, how is the python module packaging policy? Since this
module is marked as team maintained, and that I've been accepted in the
python module packaging team on Alioth, am I allowed to just refresh the
package, and upload version 1.0 in debian experimental? Or do I need
approval from current uploaders?

What does it mean for a package to be team maintained in the python
packaging team?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511a58fa.5040...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/12/2013 11:13 PM, Dmitrijs Ledkovs wrote:
> On 12 February 2013 15:08, Dmitry Shachnev  wrote:
>> Hi Thomas,
>>
>> On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand  wrote:
>>> ...
>>> So I wonder, how is the python module packaging policy? Since this
>>> module is marked as team maintained, and that I've been accepted in the
>>> python module packaging team on Alioth, am I allowed to just refresh the
>>> package, and upload version 1.0 in debian experimental? Or do I need
>>> approval from current uploaders?
>>>
>>> What does it mean for a package to be team maintained in the python
>>> packaging team?
>>
>> If the team is in Maintainer field, I think you can freely upload the
>> new version. See
>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>> for details.
> 
> But please join the team and update the svn repository, or
> alternatively ask somebody from the team to commit your upload.
> 
> Regards,
> 
> Dmitrijs.

Hi,

Thanks for both of your replies.

I've joined the team on Alioth already.

The only problem is that I quite hate SVN (mostly because I never learn
it). Don't you guys have plans to switch to git at some point? I've seed
that in /git/python-modules/packages there's already 3 packages. Is it
fine to switch to Git?

There's a bunch of python modules which I maintain for Openstack. I'd
happily move them in the /git/python-modules/packages repository. :)

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511a6a84.8000...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/14/2013 04:53 PM, Sandro Tosi wrote:
>>> If the team is in Maintainer field, I think you can freely upload the
>>> new version. See
>>> <http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields>
>>> for details.
> 
> Bug fixing is always fine for team-maintained pkgs, but just throwing
> a new upstream release into the repository and they disappear is *not*
> what team maintenance is for

What makes you think that this is the kind of behavior that I will
adopt? Please don't without giving me the opportunity to do maintenance
work. Also, the fact that I'm introducing myself and asking what the
team rules is a good sign that I really do intend to do team work, and
integrate with whatever your work-flow is.

> (which might be the situation at hand
> given zigo just joined and we don't have any history); so please at
> least try to get in contact with the uploaders first (isn't it xnox?)

I did and received no reply. See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699147

which is what made me ask in this list, as I really need the module to
be updated (it's a build-dependency of other things I maintain).

Now, I will continue to use SVN for the modules maintained inside the
team, but I don't think I will put my currently maintained python
modules in SVN, as I prefer Git.

IMO, it's not very nice that you don't at least give the choice, and
impose an inferior VCS, especially considering that most (in fact,
currently *absolutely all*) upstream authors of the python modules I
maintain are using Git (and github), which makes it quit convenient to
use Git.

Is there a valid reason despite history? Is there a chance that this
rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be
the only one happy with such decision.

Cheers, and thanks for the many replies,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511cd4a7.6000...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/14/2013 08:52 PM, Thomas Kluyver wrote:
> Please don't be put off by the somewhat hostile atmosphere that seems to
> be an unfortunate feature of this list. There seem to be historical
> tensions between some of the senior members.
> 
> Thomas

It is indeed not a very welcoming start at all.

Was there some tensions because some of the team members wished to
switch to Git, and there was some resistance against it? What do I miss?

(sorry, I have no time to read all the list archive...)

On 02/14/2013 08:50 PM, Sandro Tosi wrote:
>> IMO, it's not very nice that you don't at least give the choice, and
>> impose an inferior VCS, especially considering that most (in fact,
>> currently *absolutely all*) upstream authors of the python modules I
>> maintain are using Git (and github), which makes it quit convenient
>> to use Git.
>>
>> Is there a valid reason despite history? Is there a chance that this
>> rule may be reconsidered? It'd be really nice, as I'm sure I
>> wouldn't be the only one happy with such decision.
>
> please stop the discussion now, and accept what the team is currently
> using.

Sandro, I have some problems with such an answer, especially when I
tried to remain polite. This is an incentive so that I change my tone as
well, and that's not what I would expect from Debian packaging teams.

You can't just throw away my (IMO valid) arguments and say "it's like
that, don't complain or go away, plus I wont bother explaining why".
Because that's basically what you just wrote. Using another wording,
maybe, but that's exactly the same meaning.

Also, if you're fine to use SVN, it's your right, and I do respect it
(even if I think it's going 10 years backward). I will also try as much
as I can to use SVN for existing packages within the team, I think
that's the least I can do.

But nobody can force me into using SVN for the packages which I want to
maintain (and for the reasons I already explained). If there is a bunch
of people who wishes to collectively maintain a bunch of python module
packages using Git, there's nothing you can do to prevent it. If this
can't be done inside the python module team, because of some hostile
members, I think it's a shame. And indeed, I'll go away and package
these using another repository, outside of the team...

During these exchanges, I have already found that there's at least 4
people (including myself) who would like to use Git. And that's without
including all the members of the Openstack packaging team, who might
also help. Do you think that we should form another Alioth project for
that? Wouldn't that be silly? What are the alternatives that you see, if
we are a lot of people willing to do python module team maintenance
using Git?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511cfe0b.1020...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/15/2013 12:41 AM, Sandro Tosi wrote:
> On Thu, Feb 14, 2013 at 4:08 PM, Thomas Goirand  wrote:
>> Sandro, I have some problems with such an answer, especially when I
>> tried to remain polite. This is an incentive so that I change my tone as
>> well, and that's not what I would expect from Debian packaging teams.
> 
> so please search into the mailing list archive about the several
> iterations of such discussion and the outcome of them.

After some search, I have found some discussions about *switching* to
Git for *all* of the python module team, which is absolutely *not* what
I'm asking for. There's several of such tread indeed, from 2008, 2011,
and probably more, showing that there's a real interest into switching.
In fact, I mostly saw a lot more people willing to use Git and to switch
than I expected.

But..., no outcome at all. As it happens very often in Debian, there's
discussion but nothing happens, or not clear cut decision is made. If I
missed it, please point to me to the outcome email(s) so that I could
read it/them.

Anyway, yet, I have seen *NO* discussion about maintaining *some* of the
python modules using Git. Probably only this one:

https://lists.debian.org/debian-python/2011/03/msg00076.html

All this is very far from being *forbidden* to send packages to the
python module team using Git and maintain them this way.

If I missed some posts, please point to the relevant URL(s)!

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511d1df7.6060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/15/2013 02:04 AM, Dmitry Shachnev wrote:
> I'm not against switching to Git

Hi Dmitry,

I believe there's some misunderstanding, so I must make it square.
Again, I'm *not* asking for a full switch (or any switch at all) of all
(or even some) packages of the python module team. I have *NEVER*
written such thing, so could anyone writing in this tread refrain from
switching to this topic? If you do want to talk about it (which would be
a great move, IMO), do it in another thread, or at least not as a reply
to my message.

What's happening is that some of the python modules which I maintain in
Git can continue to be maintained this way. Nothing more, nothing less.
I'm perfectly fine using git-svn for what exists already under the team
maintenance. However these:

python-cinderclient
python-cloudfiles
python-django-appconf
python-django-compressor
python-django-openstack-auth
python-extras
python-glanceclient
python-json-patch
python-json-pointer
python-jsonschema
python-keystoneclient
python-novaclient
python-pecan
python-quantumclient
python-swiftclient
python-tablib
python-warlock

which I have to maintain because they are dependencies of Openstack, I
am using some git commands in debian/rules to:
- generate the orig.tar.xz out of the git tree using "git archive"
- generate the MANIFEST.in using "git ls-files" (not on all pkgs though)
- generate the upstream changelog using "git log"  (not on all pkgs though)

Also, upstream is using git, so being able to cherry-pick -x some
commits is quite convenient. Absolutely *all* of upstream packages are
hosted or mirrored on Github.

My build process of "openstack-pkg-builder" (scripts hosted on Alioth to
make sure that Openstack is easily "bootstrapable") is using git to
clone the packaging branch from Alioth, and the upstream branch from Github.

We also have some Jenkins jobs doing some basic checks (for the moment,
building in a cowbuilder, soon, piuparts too), also using Git.

Switching to SVN would be a brainless time consuming move, which I do
not intend to even debate. If it's mandatory to use SVN, I wont maintain
them inside the python module team, full stop.

So my request was: would the python module team accept *these packages*
to be maintained in Git? (probably, the python-*client will stay in the
Openstack Git repository on Alioth though)

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511d32d9.6070...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/15/2013 05:21 PM, Dmitry Shachnev wrote:
> On Thu, Feb 14, 2013 at 10:54 PM, Thomas Goirand  wrote:
>> I believe there's some misunderstanding, so I must make it square.
>> Again, I'm *not* asking for a full switch (or any switch at all) of all
>> (or even some) packages of the python module team. I have *NEVER*
>> written such thing, so could anyone writing in this tread refrain from
>> switching to this topic? If you do want to talk about it (which would be
>> a great move, IMO), do it in another thread, or at least not as a reply
>> to my message.
> 
> I'm speaking about the same thing as you are. Having some packages is
> SVN and some in Git (it's what you mean) will make it harder to do
> mass-commits, mass-search and keeping up with others' changes.
> 
> Again, I prefer Git to SVN, but I agree with Barry, Scott and others
> that divergence is *not* what we want.
> 
> --
> Dmitry Shachnev

So, should I open a new Alioth group for maintaining Python modules
collectively using Git?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511e1718.4010...@debian.org

New upstream release of python-testtools

[Thomas Goirand]

Hi Robert & Jelmer,

I would like to upload a new upstream version of python-testtools. I
have worked out some changes in the packaging, which I have attached to
this message.

Do you agree with such NMU?

Can I also upload this package in the python module team SVN repository,
instead of collab-maint BZR (since we agreed on it for python-fixtures,
probably you would like this to be done as well for this package)?

Cheers,

Thomas Goirand (zigo)
diff -u -N -r e/python-testtools-0.9.21/debian/changelog python-testtools-0.9.29/debian/changelog
--- e/python-testtools-0.9.21/debian/changelog	2013-02-15 12:23:09.0 +
+++ python-testtools-0.9.29/debian/changelog	2013-02-15 12:48:20.0 +
@@ -1,3 +1,17 @@
+python-testtools (0.9.29-0.1) experimental; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Rewrote debian/copyright using parsable format 1.0.
+  * Now using source format 3.0 (quilt).
+  * Standard-Version is now 3.9.4.
+  * Compat and debhelper are now 9.
+  * X-Python-Version: >= 2.6 instead of 2.5.
+  * Removes embedded version of jquery.js and underscore.js, and recommends
+corresponding Debian packages.
+
+ -- Thomas Goirand   Fri, 15 Feb 2013 12:18:38 +
+
 python-testtools (0.9.21-1) experimental; urgency=low
 
   * New upstream release.
diff -u -N -r e/python-testtools-0.9.21/debian/compat python-testtools-0.9.29/debian/compat
--- e/python-testtools-0.9.21/debian/compat	2013-02-15 12:23:09.0 +
+++ python-testtools-0.9.29/debian/compat	2013-02-15 12:20:42.0 +
@@ -1 +1 @@
-6
+9
diff -u -N -r e/python-testtools-0.9.21/debian/control python-testtools-0.9.29/debian/control
--- e/python-testtools-0.9.21/debian/control	2013-02-15 12:23:09.0 +
+++ python-testtools-0.9.29/debian/control	2013-02-15 12:40:00.0 +
@@ -3,18 +3,18 @@
 Uploaders: Jelmer Vernooij 
 Section: python
 Priority: optional
-Standards-Version: 3.9.3
+Standards-Version: 3.9.4
 Build-Depends:
-debhelper (>= 7.0.50~),
+debhelper (>= 9),
 python-all (>= 2.6.6-3~),
 python3-all,
 python-fixtures,
 python-sphinx,
 python-twisted
 Vcs-Bzr: http://bzr.debian.org/bzr/collab-maint/python-testtools/experimental
-X-Python-Version: >= 2.5
+X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.0
-Homepage: https://launchpad.net/testtools
+Homepage: http://pypi.python.org/pypi/testtools
 
 Package: python-testtools
 Architecture: all
@@ -23,15 +23,17 @@
 python-pkg-resources
 Provides: ${python:Provides}
 Breaks: python-subunit (<< 0.0.6)
-Recommends: python-fixtures
+Recommends: python-fixtures, libjs-jquery, node-underscore
 Suggests: python-twisted
-Description: Extensions to the Python unittest library
+Description: Extensions to the Python unittest library (Python 2.x)
  testtools (formerly pyunit3k) is a set of extensions to the Python standard
  library's unit testing framework. These extensions have been derived from
  years of experience with unit testing in Python and come from many different
  sources. It's hoped that these extensions will make their way into the
  standard library eventually. Also included are backports from Python trunk of
  unittest features that are not otherwise available to existing unittest users.
+ .
+ This package contains the libraries for Python 2.x.
 
 Package: python3-testtools
 Architecture: all
@@ -39,10 +41,12 @@
 ${misc:Depends},
 python3-pkg-resources
 Provides: ${python:Provides}
-Description: Extensions to the Python unittest library
+Description: Extensions to the Python unittest library (Python 3.x)
  testtools (formerly pyunit3k) is a set of extensions to the Python standard
  library's unit testing framework. These extensions have been derived from
  years of experience with unit testing in Python and come from many different
  sources. It's hoped that these extensions will make their way into the
  standard library eventually. Also included are backports from Python trunk of
  unittest features that are not otherwise available to existing unittest users.
+ .
+ This package contains the libraries for Python 3.x.
diff -u -N -r e/python-testtools-0.9.21/debian/copyright python-testtools-0.9.29/debian/copyright
--- e/python-testtools-0.9.21/debian/copyright	2013-02-15 12:23:09.0 +
+++ python-testtools-0.9.29/debian/copyright	2013-02-15 11:50:17.0 +
@@ -1,24 +1,67 @@
-This is python-testtools, packaged for Ubuntu by Elliot Murphy.
-Now packaged for Debian by Robert Collins
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: testtools
+Upstream-Contact: Jonathan M. Lange 
+Source: https://github.com/testing-cabal/testtools
 
-Homepage is https://launchpad.net/testtools
+Files: debian/*
+Copyright: (c) 2009, Elliot Murphy 
+	(c) 2009-2011, Robert Collins 
+	(c) 2012, Jelmer Vernooij 
+License: MIT
 
-Copyright (c) 2008 Jonathan M. Lange 
+Files: testtools/run.py

Re: [Openstack-devel] New upstream release of python-testtools

[Thomas Goirand]

On 02/16/2013 06:09 AM, Robert Collins wrote:
> On 16 February 2013 01:52, Thomas Goirand  wrote:
>> Hi Robert & Jelmer,
>>
>> I would like to upload a new upstream version of python-testtools. I
>> have worked out some changes in the packaging, which I have attached to
>> this message.
>>
>> Do you agree with such NMU?
> 
> Yes, thank you.
> 
>> Can I also upload this package in the python module team SVN repository,
>> instead of collab-maint BZR (since we agreed on it for python-fixtures,
>> probably you would like this to be done as well for this package)?
> 
> Yes please.
> 
> -Rob

Hi Robert!

Thanks for letting me do it. This really helps, because I needed this
dependency.

FYI, here's the full debian/changelog:

* New upstream release.
* Rewrote debian/copyright using parsable format 1.0.
* Now using source format 3.0 (quilt).
* Standard-Version is now 3.9.4.
* Compat and debhelper are now 9.
* X-Python-Version: >= 2.6 instead of 2.5.
* Removes embedded version of jquery.js and underscore.js, and
recommends corresponding Debian packages.
* Sets the Debian Python Modules Team as new Maintainer:, switches the
VCS field to the SVN of the team, removed debian/bzr-builddeb.conf.
* Added minor changes in long and short descriptions (so that python 2
and 3 modules don't have the same descriptions).
* The watch file now uses tags from github.
* Cleans now does rm -rf build testtools.egg-info doc/_build.
* Added doc-base registration.

I've uploaded it to experimental, but I have yet to find the way to push
the files into the SVN. I roughly know how to use git svn (and
understand git svn rebase, git svn dcommit and the like), but despite my
searches, I couldn't find out yet how to push a new package.

Maybe someone from the python module team (like Didier or Piotr), who's
using git svn, will be able to give me the few commands that I missed?
That would be really nice and helpful.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511f29ba.9060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

Tristan Seligmann wrote:
> I don't think forming a separate team would be silly at all.

I agree with absolutely all of what Ansgar wrote about this.

What is important is people doing the work, and being able to find
advices. In other words: team work.

> When you say "I want to maintain my packages in Git, in the team",
> there are really only two possible implications that I can see:
>
> 1) "I want everyone in the team to comply with this way of doing
> things, even though they don't want to do so", and
>
> 2) "I want to do things my own way separate from the rest of the
> team, but claim to be working as part of the team".

Oh! Are you *sure* this is what you think of me? It's quite shocking to
read that. It's not that at all. It's:

3) Upstream uses Git, and I have already lots of git things inside my
package and workflow (I already explained, I have no choice at all),
plus I know there's others willing to use Git, and not having the
possibility to do team work with them because of some member resisting
would be a bit silly.

It would be really stupid to only want to "claim" to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can, and receive help when I need, which is the point of a team.

I don't want to impose my workflow on anyone, you could continue to use
your current workflow if you like for the existing packages. I'm not at
all asking for a full switch. But the opposite isn't true, some members
of the team would like to impose the SVN workflow on me... or I should
just leave and maintain these packages on my own (or inside another
team)! Well, if I'm not allowed to use Git within the team, that's
exactly what is going to happen for these packages. And I think it's a
shame.

Tristan Seligmann wrote:
> Now, written that way, perhaps you can see why this
> produces a negative reaction from some existing team members, even if
> you did not mean it in that way?

If others see it that way, then they are missing the main point, which
is I have absolutely no choice of the VCS, given how much my packaging
work is intertwined with what upstream is using. Let me enumerate again:
signed pgp git tags (remember: I live in China, and China played with
man in the middle attacks with Github...), cherry-pick of patches, "git
merge -X theirs " for new release tags, "git ls-files" to
generate the MANIFEST.in, "git archive" to generate the orig.tar.xz, my
auto-builder script which is fully git based, using the upstream
repository for the master branch, etc. SVN or git-svn will not allow me
to do this.

I have absolutely no intention of disturbing the current workflow of the
team, I just want to have the possibility to do the work for these
packages where Git is convenient for me. I am ok to use SVN for the
*other* packages which I maintain / contribute already, but for some it
just wouldn't work. Note that I already did use SVN and pushed some
commits. And wish to add some more packages to the SVN (I just didn't
find out how yet... help would be appreciated so that I can push
python-testtools and python-fixtures!).

I do understand why some would like to keep a single VCS though. But
maybe it could be a more relaxed rule not written into a stone, where
some exceptions would be allowed at least. Recognizing that SVN doesn't
work in some cases (which I already explained above and in other posts)
would be a good step on the right direction IMHO.

Cheers,

Thomas Goirand (zigo)

P.S: I'm truly sorry for breaking the thread, I was reading through the
archive, but now I'm registered to the list. This will not happen again.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511f4d0c.8040...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/16/2013 08:36 PM, Tristan Seligmann wrote:
> But this is exactly the point; if team members are doing work in SVN,
> then your packages in Git are not benefitting from this work.

Let's be practical for a bit.

Some members of the team already said they like to use Git.
So we wont have everyone using SVN, and just me, isolated,
using Git, in the world you describe above.

> Conversely, if you are doing work on the packages in Git, other
> packages in SVN are not benefitting.

I never wrote I would work *only* with Git, I wrote that it made
sense for some of the packages I maintain. I already sent
some updates in the SVN, and I do intend to do some more.
especially for Openstack dependencies (which is, a lot of
python modules...).

Using multiple VCSes may be simply just annoying. But not for
the reasons above.

On 02/16/2013 08:36 PM, Tristan Seligmann wrote:
> I just don't see how you hope to benefit
> from maintaining the packages "in the team" when you aren't actually
> making use of the team infrastructure that provides these benefits.

Simply because in the team, there's many different people,
and I'm sure some would happily contribute using Git. Just
like for the rest of Debian, it's voluntary based. I don't force
anyone, but accept any help. I just thought that this team
was the most relevant place to do so (and I still think it is).

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511fdc29.5030...@debian.org

Re: Package adoptions

[Thomas Goirand]

On 02/18/2013 04:43 AM, Vincent Bernat wrote:
>  ❦  4 février 2013 20:00 CET, Örjan Persson  :
>
>> I don't have the time to maintain my packages anymore. I just wanted to
>> check with you guys first if you're interested in adopting the packages
>> before I RFA them. The packages are python-setproctitle[1],
>> python-greenlet[2] and python-gevent[3].
>>
>> [1] https://github.com/op/pkg-python-setproctitle
>> [2] https://github.com/op/pkg-python-greenlet
>> [3] https://github.com/op/pkg-python-gevent
> I am currently too short on time to do anything but I have high interest
> in both setproctitle and gevent and therefore if nobody steps in, I will
> maintain them under the DPMPT. I could also take python-greenlet since
> it seems in good shape.
I may help as well with python-greenlet if needed. It's a dependency for
ceilometer, cinder, heat, keystone and nova...

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51214a92.30...@debian.org

Re: [Openstack-devel] New version of python-fixtures for debian experimental

[Thomas Goirand]

On 02/15/2013 03:23 PM, Robert Collins wrote:
> +1 on what you've done and what you propose. If you want to set
> Maintainer to DPMT and commit it to the DPMT svn repository at the
> same time, that would be awesome.

Robert,

Both python-fixtures and python-testtools are now stored in the SVN of
the python module team. Note that python-fixtures doesn't have the
correct VCS fields yet, but it's not a big deal, since I was planing
(with your agreement) to switch from CDBS to dh, so this will happen on
the next upload.

Both the latest versions of python-fixtures and python-testtools are now
uploaded to Experimental.

By the way, is there a Git repository for these packages? I've found one
for testtools:
https://github.com/testing-cabal/testtools

but not for -fixtures.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5121a7fb.3060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/19/2013 06:08 AM, Thomas Kluyver wrote:
> On 18 February 2013 20:46, Ludovic Gasc  > wrote:
>
> I vote D, and I can handle the migration from SVN to Git, I've
> done this several times for my work and WYMeditor.
>
> Are you interested?
>
> I'm interested personally, but the votes so far suggest there's no
> real will for any change - the only option with more than one first
> preference vote is the status quo.
>
> Thomas
So far, those who could have vote C or D (this shows in previous reply
that some could have voted that) didn't bother answering the "poll".
Probably because of the tone of some participants of this thread, who
didn't take it seriously, replied unrealistic answers who were not even
in the original poll, or discussed previously in the thread.It would
probably have been more efficient to just read previous contribution in
this thread, if some of the participants just ran away from it...

It seems that there's a will to completely destroy this discussion
anyway (which is quite successful), so don't expect much from now on.
I just hope not too many people will read this shameful thread.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5123b24d.6020...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand  wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev
Mine is CDAB.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5123b93b.7060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
> On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand  wrote:
>> So far, those who could have vote C or D (this shows in previous reply
>> that some could have voted that) didn't bother answering the "poll".
> I've already expressed my opinion in this thread, but to be formal: my
> vote is DA.
>
> --
> Dmitry Shachnev
>
>
I have reviewed (I hope, MOST) answers, and here's what I get:

Scott K
E - Migrated to bzr, but I want someone else to to all the work.

Jakub Wilk
F - Migrate to Mercurial, but I want someone else to do all the work.

Dmitrijs
DA

Daniele Tricoli
A, F.1 but my F option imply that I will help "to do the work"

Robert Collins
Seems to want to allow Git

Barry Warsaw
Likes BZR, but seems to possibly agree with git on some workflow conditions

Chow Loong Jin
Didn't express himself, but knows how to use git and git-buildpackage

Javi Merino
FCDAB

Ludovic Gasc
D

Thomas Kluyver
Seems to be ok with migrating to Git (so, option D)

Myself:
CDBA

So, we have 12 persons who expressed themselves, about 6 persons
who would agree with Git in some ways, 3 who would like to move
to another system, but if they don't do the work. We also have
2 persons who proposed themselves for doing the work of moving
to Git.

If the above isn't correct, please let everyone know your view.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5123bc84.4040...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 06:20 AM, Barry Warsaw wrote:
> * Figure out whether full-source or debian/ only works better (maybe give us
>   both repos so we can play with them and discuss the pros and cons from
>   actual working examples).

What is important, I believe, is that git-buildpackage always works.

I've found that having a debian/rules entry called "get-vcs-source"
which gets what is needed from upstream works quite nicely. Our
workflow is described here:

http://openstack.alioth.debian.org/

The idea to use "git archive" was mostly from Julien Danjou. It's
very nice because that way, we can use xz compression, instead
of what upstream provides (that is, github .zip or .tar.gz, which
isn't the best). It's also quite nice because that way, it's possible
to tag a specific commit and package that as upstream release.
This is mostly why I think using Git is convenient, so I really would
like this to be part of the draft.

Though this workflow only works if upstream uses Git, which isn't
the case. In other cases, probably using a pristine tar branch
would do.

BTW, I of course agree that it's 100% necessary to make sure we
have a unified policy, including on branch names and all. For branch
names, I've used the following:

- debian-sid
- upstream-sid
- debian-squeeze
- upstream-squeeze
- etc.

But also:

- debian/unstable
- debian/experimental
- master

then I used the tags from the master branch.

I think it's ok to have both naming shemes. The important bit,
IMO, is that everything is referenced in the debian/gbp.conf so
that nobody has to second-guess what to do.

Just my 2 cents, and if help is needed for migrating, I hope to
be able to be available if you ask.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51244fa6.4020...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 12:38 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
>> The idea to use "git archive" was mostly from Julien Danjou. It's
>> very nice because that way, we can use xz compression, instead
>> of what upstream provides (that is, github .zip or .tar.gz, which
>> isn't the best).
> See devref 6.7.8.  This not an appropriate reason to not use the upstream 
> tarball.
>
> Scott K
Thanks Scott, but I believe I know what I'm doing. This wasn't the
only reason I stated, it's only one of the consequences.

What upstream considers "release tarballs" are *not* what Github
provides anyway (it is a little bit more complex than this).

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512489eb.7080...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> This all seems to assume full source branches which is not something I'm 
> interested in participating in at all.  I've tried it and I find it very 
> difficult to work with.
>
> Currently we have one VCS and one package layout.  In the end, we should have 
> that still.  Anything else raises a substantial barrier to collaboration.
>
> Scott K
Would you care explaining why full source branches is difficult to work
with?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51248a7d.3000...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 04:31 PM, Luca BRUNO wrote:
> This may suit well for the openstack scenario, however in general I
> could see at least two shortcomings:
> * pristine upstream tarballs are not used (see the first "should" in
>   devref §6.7.8.2)
> * it assumes that no tarball generation process (eg. make dist) is
>   needed
>
> I'm not sure how much impact they have on normal python-team workflow,
> though.
>
> Cheers, Luca
I agree it only fits cases where upstream uses git and tags.
Though it's a more and more common case. Some upstream
authors don't even care to release a tarball at all nowadays.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51248ec5.1050...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 04:57 PM, Matthias Klose wrote:
> So there would be no way anymore to build using upstream tarballs?

Upstream tarballs, in some cases, is a concept of the past. When
they are released (sometimes, they simply don't exist), it may only
an image based on a git tag. Then using Git tags is often better,
because tags may be PGP signed. I live in China, and the Chinese
government did twice some man in the middle attack... Tarballs
don't include PGP signatures. Plus it's possible for me to tag at
any point in time, any commit, and use that to generate a tarball.

Signed git tags is the new trend, you shouldn't fear it, and stick
to the old 1980's concepts forever, only because we always did
this way.

If sticking to our old habits is not the only valid point, that there
are real technical reasons why we should never be using a git tag
as the key for an upstream release, or if you think they might be
real difference between the "git archive" generated xz file and the
github/gitorious/etc. tag based tar.gz, please explain.

> This doesn't sound appropriate to force on a whole team.

Of course it's not. In fact, I don't think it's the right thing to do to
impose rules set that strong, and write them into a stone. There's
no "one size fit all", and such a rigidity may bring inconvenience.

I by the way think that switching everything from SVN to Git will
probably be painful for a lot of the team members, which is why
I think it isn't a so good idea, and that best would have been to
allow both even if I understand why using more than one VCS
might be at least annoying and probably very inconvenient
sometimes.

This doesn't mean that we shouldn't try to define some standards,
and try to stick with them whenever possible, but only to some
reasonable extend.

Also, if you have valid arguments to use one type of workflow, and
if it really is convenient to work the way you tell, I will happily adopt
your way. Please share your view, and packaging habits and tricks!

My intention when describing our workflow was to give ideas, and
confront them. If everyone shares, I'm sure this will be beneficial.

> I don't think that many of the people that voted are aware of your implicit
> changes (no release tarballs, including upstream source in the VCS) by moving 
> to
> git.
>
>   Matthias

Once more, I never wanted to change anything in the team,
I just wanted to be allowed to use Git when relevant. I voted
CDBA, in this order, as I didn't wish to distrub anyone that
likes SVN.

Now, do you know if it is possible to use git-buildpackage
without storing the full upstream source in a branch? I never
did that way. For me, using git-buildpackage is mandatory, it
is simply too convenient. What is the problem of storing
upstream source code anyway (that's the 2nd time I ask,
as nobody explained yet why it's a problem)?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5124da42.9020...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 10:23 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>
>> If sticking to our old habits is not the only valid point, that there
>> are real technical reasons why we should never be using a git tag
>> as the key for an upstream release, or if you think they might be
>> real difference between the "git archive" generated xz file and the
>> github/gitorious/etc. tag based tar.gz, please explain.
> You better be darn sure that upstream has excellent QA then, and that you know
> for sure that a tag is correctly assigned to a buildable, tested, QA passed
> snapshot of the project.

In what way the QA is different because it's a tag instead of a tarball ?
I don't understand your reasoning. In both cases, you must make sure
that what you are packaging is buildable, tested, QA, etc.

> Also, you must ensure that everything necessary to
> build and deploy the package is either included in the repository or is easily
> generated by something that is in the repository. I bet that's going to cover
> a minority of projects still. At least with a tarball, you know you have a
> releasable "thing" that upstream has blessed (which could still have problems,
> sure, but that's different than not being sure.)
>
> Look at it from a Debian Python packager's point of view.  If it's on PyPI,
> then there's no guessing.  If it's a git tag in some repo, you have to carry
> along much more implicit context (e.g. the workflow of the upstream project,
> do I have the right repo, etc.).

With many PiPY projects, I can see that the generated tarball are the
exact same thing as what's tagged in the Git repository. Often, the
release process is automated so the tag and the tarball are released
at once. This has been the case, for example, for:

- python-pecan (https://github.com/dreamhost/pecan)
- python-json-patch (https://github.com/stefankoegl/python-json-patch)
- python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
- python-tablib (https://github.com/kennethreitz/tablib)
- cliff-tablib (https://github.com/dreamhost/cliff-tablib)
- python-warlock (https://github.com/bcwaldon/warlock)

(non exhaustive list... and not including all of Openstack!)

I don't understand your reasoning, they are all using setuptools, and
are perfectly buildable, installable, etc. Did I miss something?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5124e387.8080...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 10:43 PM, Scott Kitterman wrote:
> First, full source repositories are much larger than debian only 
> repositories.  
> I don't have a full checkout of all team packages locally, so that means if 
> I'm going to touch a package I don't have to download, it's more time, 
> bandwidth, etc.  Even for a new upstream version, debian directory in the 
> repository and upstream tarball is still smaller.

If you are modifying some packages, it's to upload them at some point.
In such case, you will need the upstream tarball, right? I don't see where
the waste of bandwidth is then.

> Second, I think Debian packaging work and upstream's product should be 
> distinct in the source package.  The source package is what Debian as a 
> project ships as the source for DFSG purposes and it should be useful.

Which is why we have branches. One with the upstream code, and one
with the debian folder added. Everything being contained in that debian
folder. So it's really distinct.

> "Here's a huge mass of code and to understand what we did to it, you need to 
> refer to this external repository (VCS)" is not socially acceptable to me.

It's not any different to have absolutely zero upstream code in the VCS:
you will need to refer to an upstream tarball, which has "a huge mass
of code".

> Third, I have yet to see a workflow for maintaining debian/patches in a VCS 
> as 
> part of a full source branch that was not more work than just having the 
> patches in a debian/patches and letting dpkg handle getting them applied/ 
> unapplied.

Having full source branches do not prevent you from using debian/patches.
I use that often, together with dpkg-source --commit and friends. If you
have
in debian/gbp.conf the following:

[git-buildpackage]
export-dir = ../build-area/

patches are applied/unapplied by git-buildpackage automatically at build
time,
in a separate folder, which doesn't pollute your VCS tree. So I'd say
it's the same,
with the added benefit of being able to use upstream commits to generate
diffs.

> Finally, I have upstreams that use cvs, svn, bzr, and git.  Trying to figure 
> out a workflow that integrates all those just seems impossible.

For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and
hg-fast-export).
If that doesn't work, you can use the pristine-tar thing, that should
always work.
I never used it, probably I should learn, it seems quite convenient. Can
anyone
give feedback about it?

By the way, I do the packaging of MLMMJ, and upstream provides both
mercurial
and Git, which I think is really awesome. If we could have that, and not
only Git,
that would be best, IMO, so that those who likes hg could use it. Last
time I
looked, it didn't seem so hard to setup. Probably that would be a nice
addition
to Alioth as well, so that any Alioth project using Mercurial would have
Git too.
Do you also think it would be worth asking the Fusion Forge team?

> I've used partial (debian dir) VCS branches for years in both Debian and 
> Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at 
> all 
> to full source.
WIthout full source, how do you use git-buildpackage? Could you describe
your workflow so that I can understand your view as well?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5124ea80.5080...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 11:09 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote:
>
>>> You better be darn sure that upstream has excellent QA then, and that you
>>> know for sure that a tag is correctly assigned to a buildable, tested, QA
>>> passed snapshot of the project.
>> In what way the QA is different because it's a tag instead of a tarball ?
>> I don't understand your reasoning. In both cases, you must make sure
>> that what you are packaging is buildable, tested, QA, etc.
> Right, but it's a matter of context.  If you have a release on PyPI, you know
> it's been blessed.  You don't need any more context.  For a git tag, I have to
> know what is the blessed repo url, how the tagging scheme works, what the
> latest releasable snapshot is tagged, etc.  I need much more context to know
> what is "a release" (even though upstream might find them quaint, Debian still
> does releases of packages, i.e. uploads).  What if the repo url changes?  What
> if they start using a different tagging scheme?  What if someone accidentally
> assigned a release tag to a non-releasable revision?

For the packages which I worked on, there was always a Git URL in PiPY,
and I didn't have any of the issues you're talking about above. I'm not
saying it can ever happen, but only that I see no difference with making
a tarball: in both cases, you can do mistakes, can't find the correct
URL and have it changed, etc. I haven't yet met a "context" problem like
you describe above, but truth, I have seen multiple tagging scheme, the
most reoccurring one being to add a "v" in front of the version number
(which is easily worked around in the gbp.conf).

> That might not be so important for someone who has intimate and ongoing
> knowledge of package maintenance, but it's really important for team
> maintained packages where I might have to fix a bug or grab a new upstream for
> a package you primarily maintain.

Team members can read debian/copyright, where you have the Source: field.

>> With many PiPY projects, I can see that the generated tarball are the
>> exact same thing as what's tagged in the Git repository. Often, the
>> release process is automated so the tag and the tarball are released
>> at once. This has been the case, for example, for:
>>
>> - python-pecan (https://github.com/dreamhost/pecan)
>> - python-json-patch (https://github.com/stefankoegl/python-json-patch)
>> - python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
>> - python-tablib (https://github.com/kennethreitz/tablib)
>> - cliff-tablib (https://github.com/dreamhost/cliff-tablib)
>> - python-warlock (https://github.com/bcwaldon/warlock)
> That's great, but I bet it's a minority of projects on PyPI.

Like you, I have no stats available, so I can't tell. But for me, that
was a vast
majority of the packages I worked on.

Anyway, I'm not asking anyone to follow my workflow, I was merely explaining
what I've been doing, and what I was very happy with. It might indeed only
work for a group of packages only.

Do you guys think we should only have *one type* of workflow? I wouldn't
mind switching to some different way of doing things if the team finds it
relevant, and if it is more easy and unified across all packages. If so,
please tell how you would like to work. We would loose most of the cool
features I was used to, but so be it...

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512504bf.3060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/20/2013 11:45 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
>>> First, full source repositories are much larger than debian only
>>> repositories. I don't have a full checkout of all team packages locally,
>>> so that means if I'm going to touch a package I don't have to download,
>>> it's more time, bandwidth, etc.  Even for a new upstream version, debian
>>> directory in the repository and upstream tarball is still smaller.
>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth is then.
> A VCS with all the upstream history will always be bigger than the tarball 
> for 
> just the current release.  Sometimes substantially so.

But you only very rarely clone from scratch, and only get some
incremental changes.
While with tarballs, you always have to get the full of it.

>
>>> Second, I think Debian packaging work and upstream's product should be
>>> distinct in the source package.  The source package is what Debian as a
>>> project ships as the source for DFSG purposes and it should be useful.
>> Which is why we have branches. One with the upstream code, and one
>> with the debian folder added. Everything being contained in that debian
>> folder. So it's really distinct.
> You're missing my point.  If it's only in the VCS, it's not in the source 
> package.  The source package needs to stand alone without the VCS to, in my 
> opinion, properly comply with the spirit of the DFSG.

It's funny that you say it this way. I've read some other opinion saying
that with the
tarball, you're missing lots of information from upstream. That person
went up to
say that he thought it'd be a good idea to package the git repository as
source
package (sorry, I can't remember who and when, just that it was in
-devel@l.d.o).
I quite agree with this view.

>>> "Here's a huge mass of code and to understand what we did to it, you need
>>> to refer to this external repository (VCS)" is not socially acceptable to
>>> me.
>> It's not any different to have absolutely zero upstream code in the VCS:
>> you will need to refer to an upstream tarball, which has "a huge mass
>> of code".
> Right, but if you embed Debian specific changes and don't use patches

That's not what I do.

> I know sometimes this isn't done, but it is supposed to be

I agree it's a bad idea, so we are on the same line.

> I generally unpack the upstream tarball, export the debian dir from 
> the VCS into the unpacked tarball, update the package, build it with dpkg-
> buildpackage, and then commit the changes back to the VCS repository with 
> debcommit (which is very nice since it speaks to multiple VCS through the 
> same 
> interface).
So, basically, you're doing all by hand... That's very tedious. IMO, the
whole
point of using git (or any other VCS), is to use either git-buildpackage, or
"git-stuff" (that's a package name...), so you have tools to do all this
manual
boring work. git-stuff works the opposite way. You'd do all the changes in
your packaging, then it would write the debian/changelog based on the
commit messages. I find it a lot better, because then you can have a history
of you changes, do rebase, squashes, cancel, etc. without the risk to loose
any of your changes.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51250a67.1060...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 12:32 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:
>
>> It is to a degree, but the learning curve for git is subtantially steeper
>> than for other VCS.  I've learned CVS, SVN, BZR, and Git at one time or
>> another and there is no question in my mind which one, by a lot, is the most
>> complex to learn.
> No one's accusing git of actually being user friendly. 
>
> http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
>
> -Barry
Some of the points in this page are really wrong.
Like in the point 6, 7, 8 and 9, the author didn't understand
at all the necessity of having fast-forward history when
a project scales up, with lots of contributors.

Then finally, I agree, the only thing that remains is the
complexity. :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5125b737.4030...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 01:36 PM, Scott Kitterman wrote:
> Agreed.
>
> I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to 
> be able to find it 4 years later).
>
> Scott K
Lucky, 4 years later, the error messages of Git are
much much more helpful than they used to be (in
fact, since version >= 1.7).

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5125c34b.2030...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 02:29 PM, Scott Kitterman wrote:
> I've tried doing this.  Then I looked back and noticed that I was spending a 
> LOT of time making the VCS pretty, just in case and rarely had to revert 
> anything.  It turned out I was spending a lot of time to save a little time 
> and that's just not path to being productive.
>
> Scott K
If you are working alone, probably. If you are working
with a team, that's a different story. Having a very
dirty commit history with changes going back and
forth is just horrible and makes it very hard to follow.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5125c3e1.7050...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 02:26 PM, Scott Kitterman wrote:
>
>> I undertand that learning Git after BZR is hard, because learning BZR after
>> Git is equally painful.  I think that the key difficulty is whether a
>> system is learned first or second, not the system itself.
>>
>> This is where git-buildpackage is nice, as it re-implements the same user
>> experience as with svn-buildpackage, and therefore provides some kind of
>> upgrade path.
> I disagree.  Learning git is harder than all the others.  It doesn't matter 
> what order you learn them in.  If you look at the figures in point 10 of 
> http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ (you can 
> largely substitute bzr for svn there and it won't get any more complex) and 
> tell me those are of equal complexity.
>
> For all it's power, the git U/I is just inconsistent and counter intuitive.  
> If you use it routinely, you get so you remember it and it seems easy.  If 
> you 
> don't, you have to re-climb up the learning curve each time.  
>
> Scott K
I've learn first CVS. Then switch to Git. Then when I tried to learn bzr,
it was quite hard (and now I can't remember it at all). I always found
SVN something of the past, hard to use and stupid, because I never
took the time to learn it correctly (and in full honesty, I don't think
I should, as there are way better VCS out there). But I perfectly know
this comes *from me* and not the tool itself, which I know shouldn't
be harder to use than CVS, which I used for years.

So I deeply agree with Charles here.

Also, for this point 10, the author completely skipped alltogether
the very reason why Git needs more commands: because it doesn't
do network access all the time. Only when you ask it to do so. And
because I worked with launchpad BZR from China, with about 5 KB/s
of bandwidth to it available (when I could connect at all...), I can tell
you that it is really important. Lucky, launchpad.com has nicer
connectivity now, but that's not what I'm debating. With BZR, I wouldn't
be able to work in the train without my 3G connection opened...

This debate can go on, and on, and on forever. It will go nowhere.
We got the point that you find Git difficult, and like bzr more.
I don't think posting such wrong argumentation helps.

Moreover, ease of use is *not* the main point of any software (it does
seem to me that this is your main point). Sometimes, convenience
means that you do need to learn to later be more efficient.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5125c80a.6090...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 04:55 PM, Piotr Ożarowski wrote:
> Can we go back to DPMT/PAPT workflow? Git vs. Bzr vs. Hg war is not
> that relevant (and we already know which VCS won, at least in Debian ;P)
>
> Can we focus on what we want (without taking VCS into account if
> possible) so that those who will propose workflow/tools/do the initial
> migration can start working? I'd love to be forced to choose between
> WORKING implementations. I want to play with hg, bzr or git in a
> DPMT/PAPT context and THEN decide which works better for me
> (I love git, but maybe git-buildpackage is not that shiny as others
> describe)
git-buildpackage takes some time to learn.

I think it might be worth trying git-stuff (eg: the package).
I know few people who use it and are happy with it.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5125e95c.7090...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/21/2013 01:59 AM, Scott Kitterman wrote:
> I don't keep local copies of things I don't work on regularly, so for team 
> packages I would be downloading all of it.

I thought about it for a long time. Then I tried again today, and now,
I don't buy into this "it takes too much time to download" argument.

Currently, with SVN, givent the size of the repository, it takes really
a huge amount of time to clone a package *debian folder only*.

>From a server in a data center in Seattle, it took me 90 seconds
to download the packaging sources of python-eventlet. Compare
this to the 4 seconds it takes me to clone python-warlock from
Alioth, upstream source included !!!

Then because this was only a small package with only a very small
amount of upstream code, I tried again to benchmark how much
time it took with a bigger project. Well, with nova, which I consider
a quite big project, it took me 32 seconds to get all of it. And about
10 seconds for glance, which I would consider a medium size project.

Then I repeated the experience from my (very) slow Chinese
ADSL connection. Even there, it took me 42 seconds to clone
glance from Alioth (a 9.4 MB repository).

Scott, I would be *very* surprised if you had an internet connection
slower than mine, considering where you live (if db.debian.org still
has accurate information).

The problem is that with SVN, it takes so much time and space
(as each tag will generate some files), so you might have been
fooled into thinking it would also with Git. But the reality simply
not that at all.

If you could suffer the slowness of SVN for so many years with the
python module team, I'm sure you will like the upgrade to Git which
will make clones so much faster.

So in the end, I don't buy into your point that having an upstream
source branch type of repository is too slow and too big. It's just
simply not the case.

Cheers,

Thomas Goirand


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51271ad6.8020...@debian.org

Re: How does team maintenace of python module works?

[Thomas Goirand]

On 02/22/2013 03:57 PM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-02-22]
>> From a server in a data center in Seattle, it took me 90 seconds
>> to download the packaging sources of python-eventlet. Compare
>> this to the 4 seconds it takes me to clone python-warlock from
>> Alioth, upstream source included !!!
> your data is wrong (see below).
>
> piotr@hadar /tmp/test
> 0% time svn co 
> svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/
So probably, it's git-svn which is slow (and plain svn isn't). Interesting!

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51278afb.9050...@debian.org

Re: RFS: Fix for #678169 (python-mysqldb)

[Thomas Goirand]

On 03/12/2013 10:14 AM, Mika Pflüger wrote:
> The debdiff is attached to the bug [bug] and I would be very happy if
> someone could add the changes to the svn and upload to unstable; I'm
> offering to write the unblock request once the fixed version hits
> unstable.
>
> Cheers,
>
> Mika
>
Hi Mika,

At this time in the release, we got to be extra careful.

Please send a pre-approval bug against release.debian.org, with
the attached debdiff, so we can make sure that the release team
agrees. If they do (and I'm quite sure they will), then I have no
problem at all to sponsor such an upload in SID.

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513ea0ff.5000...@debian.org

Circular build-dependency in python-webob

[Thomas Goirand]

Hi,

When doing apt-get build-dep python-webob --no-install-recommends, I was
surprised to see in the list, python-webob itself:

root@GPLHost>_ ~# apt-get build-dep python-webob --no-install-recommends
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  binutils build-essential cpp cpp-4.7 debhelper docutils-common
  dpkg-dev file g++ g++-4.7 gcc gcc-4.7 gettext intltool-debian
  libc-dev-bin libc6-dev libgmp10 libgomp1 libitm1 libjs-jquery
  libjs-sphinxdoc libjs-underscore libmagic1 libmpc2 libmpfr4
  libquadmath0 libstdc++6-4.7-dev linux-libc-dev make mime-support
  patch po-debconf python python-all python-dns python-docutils
  python-formencode python-jinja2 python-markupsafe python-minimal
  python-nose python-paste python-pastedeploy python-pastescript
  python-pkg-resources python-pygments python-roman python-setuptools
python-sphinx python-support *python-webob* python-webtest python2.6
python2.6-minimal python2.7 python2.7-minimal sphinx-common
0 upgraded, 57 newly installed, 0 to remove and 0 not upgraded.

There must be something wrong here.

What is the best way to investigate and fix this?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513f5efe.8060...@debian.org

Re: Circular build-dependency in python-webob

[Thomas Goirand]

On 03/13/2013 01:44 AM, Julien Cristau wrote:
> On Wed, Mar 13, 2013 at 00:59:42 +0800, Thomas Goirand wrote:
>> There must be something wrong here.
> What makes you think that?
Well, I know that's arch all that we're talking about, but still,
it doesn't feel right to have circular build-dependency.

How may I generate a build-depends graph, to check it out?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513f8353.7000...@debian.org

Re: RFS: Fix for #678169 (python-mysqldb)

[Thomas Goirand]

On 03/15/2013 08:45 AM, Mika Pflüger wrote:
> The release team just (reluctantly (-; ) pre-approved the fix [1], so it
> would be really nice if you could upload to sid.
>
> Cheers,
>
> Mika
Uploaded and sent to the SVN.

Note that I also added:
-rm -fr build build-python$*
+rm -fr build build-python$* MySQL_python.egg-info/PKG-INFO

in debian/rules, as it was otherwise impossible to build the package
twice without manually deleting that file. I'm quite convince that this
isn't a problem to get it approved by the release team.

As per your proposal, please make a new debdiff between -1 and -2,
and deal with the release team for having this change unblocked.

Thanks for your contribution in Debian,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5142ba88.9010...@debian.org

Re: statsd + voluptuous packaged!

[Thomas Goirand]

On 03/21/2013 08:59 PM, Antoine Musso wrote:
> statsd http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703613
> voluptuous http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698354
>
> The voluptuous one has been build and deployed on one of the Wikimedia
> server already, the statsd is in the pipeline.  I have posted some
> details on the voluptuous ITP:
>
Hi,

I happen to also have worked on statsd:
http://anonscm.debian.org/gitweb/?p=openstack/statsdpy.git

My ITP was filled before yours: #699411
Next time, please check wnpp better please.

I would be happy to co-maintain the package with you.
What do you think?

My nick is "zigo" on OFTC and Freenode. Please ping me.
I'm French as well (though I live in China currently).

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514b4f9d.1020...@debian.org

Re: statsd + voluptuous packaged!

[Thomas Goirand]

On 03/22/2013 06:19 AM, Antoine Musso wrote:
> Le 21/03/13 19:21, Thomas Goirand a écrit :
>> I happen to also have worked on statsd:
>> http://anonscm.debian.org/gitweb/?p=openstack/statsdpy.git
> Bonjour =)
>
> It seems they are different packages:
>  - statsdpy is a statsd server
>  - python-statsd a client for the nodejs statsd

Oh! That is quite annoying then, with such similar names.

>> My ITP was filled before yours: #699411
>> Next time, please check wnpp better please.
> I guess that is what happens when newbie joins. They do mistake, so do
> I.

No worries. FYI, the page to look at as well as packages.d.o
is this one:
http://www.debian.org/devel/wnpp/being_packaged

(if you want to remember: you can reach it if you type
"debian wnpp", then click on "packages being worked on"

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514beb7e.4070...@debian.org

Re: statsd + voluptuous packaged!

[Thomas Goirand]

On 03/22/2013 06:19 AM, Antoine Musso wrote:
> Le 21/03/13 19:21, Thomas Goirand a écrit :
>> I happen to also have worked on statsd:
>> http://anonscm.debian.org/gitweb/?p=openstack/statsdpy.git
> Bonjour =)
>
> It seems they are different packages:
>  - statsdpy is a statsd server
>  - python-statsd a client for the nodejs statsd
Just FYI:
https://pypi.python.org/pypi/statsdpy
and
https://pypi.python.org/pypi/python-statsd

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514bef07.7020...@debian.org

Re: About canonical Vcs fields

[Thomas Goirand]

On 03/24/2013 01:16 AM, Jakub Wilk wrote:
> * Dmitrijs Ledkovs , 2013-03-23, 13:01:
>>> Okay. Unless I hear objections, I'll do mass-commit to switch to
>>> anonscm.d.o in ~2 weeks.
>> Can you do such commit simply after wheezy is out the door?
>
> I don't mind if we release in two weeks. ;P
>
Sure, let me inform the release team that we need to do a
change in our VCS fields, and so they should release Wheezy now!

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514ff7ef.90...@debian.org

Re: RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub

[Thomas Goirand]

On 05/08/2013 02:04 AM, Simon Chopin wrote:
> bunch: Dot-accessible Python dictionary (a la JavaScript objects)
> kitchen: Cornucopia of useful Python code
> grapefruit: Python module to manipulate color information easily
> fabulous: Makes your terminal output totally fabulous
I thought these were jokes, not package names! :)

Cheers,

Thomas

P.S: Lucky the short desc are good enough, though even after
reading the one of "kitchen", I still don't know what it does.
Would it be possible to review that one? Or it's really just a
bunch of functions impossible to describe better without
itemizing them?


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518a7308.5000...@debian.org

Is subgit for migrating from Git to SVN?

[Thomas Goirand]

Hi,

I came accross http://subgit.com/

Could it be of any help for us?

Thomas

P.S: This seems to be a server tool, not a git plugin for SVN, which I
was searching for, seeing how lame git-svn is...


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518db5cf.9070...@debian.org

Re: Upload of python-mock 1.0.1 to Debian unstable

[Thomas Goirand]

On 05/08/2013 01:46 PM, Michael Fladischer wrote:
> On 2013-05-07 22:32, Simon Chopin wrote:
> > I'd like to know if/when you plan to upload python-mock 1.0.1 in
> > unstable (it sits at the moment in experimental).
>
> I'm preparing it right now in SVN.
>
> @Stefanor: Could you sponsor me again?
>
> Cheers,

Hi Michael,

I have uploaded the package (as it was in the SVN).

Thanks for your contribution,
Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518dd1bf.60...@debian.org

Upload of python-eventlet to experimental without SVN commits

[Thomas Goirand]

Hi Laszlo,

I noticed that python-eventlet 0.12.1-1 has been uploaded to
experimental, with the last changelog entry being from you. on the 02
Mar 2013. However, the packaging source hasn't been modified on the SVN,
leading to a bit of frustration on my side, seeing that I worked on the
package and discovered that at the end of my work, when I needed to upload.

Next time you modify the package, could you please also modify the SVN?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518dd834.5070...@debian.org

Re: Upload of python-eventlet to experimental without SVN commits

[Thomas Goirand]

On 05/11/2013 01:33 PM, Thomas Goirand wrote:
> Hi Laszlo,
>
> I noticed that python-eventlet 0.12.1-1 has been uploaded to
> experimental, with the last changelog entry being from you. on the 02
> Mar 2013. However, the packaging source hasn't been modified on the SVN,
> leading to a bit of frustration on my side, seeing that I worked on the
> package and discovered that at the end of my work, when I needed to upload.
>
> Next time you modify the package, could you please also modify the SVN?
>
> Cheers,
>
> Thomas
When I'm at it, how come the Uploaders: has been changed, with
only you in it, and all of the previous uploaders being removed,
without any mention of that in the changelog? This doesn't seem right!

1/ Have you asked the maintainers you removed if they wished to do that?
2/ Please document this fact in the changelog next time.

I have reverted your change and added you to the Uploaders: list.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518dda57.7080...@debian.org

Re: Upload of python-eventlet to experimental without SVN commits

[Thomas Goirand]

On 05/11/2013 01:42 PM, Thomas Goirand wrote:
> When I'm at it, how come the Uploaders: has been changed, with
> only you in it, and all of the previous uploaders being removed,
>
> 1/ Have you asked the maintainers you removed if they wished to do that?
> 2/ Please document this fact in the changelog next time.
Seems it was documented, and I didn't see the changelog
entry. Sorry for that.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518e1f6d.9040...@debian.org

Re: Accepted requests 1.2.0-2 (source all)

[Thomas Goirand]

On 05/11/2013 07:32 PM, Daniele Tricoli wrote:
> Hello,
> 
> On Saturday 11 May 2013 06:33:00 you wrote:
>> Changed-By: Thomas Goirand 
>> Description:
>>  python-requests - elegant and simple HTTP library for Python, built for
>> human being python3-requests - elegant and simple HTTP library for Python3,
>> built for human bein Changes:
>>  requests (1.2.0-2) unstable; urgency=low
>>  .
>>* Uploading to unstable.
>>* rm -rf requests.egg-info on clean so the package can be built twice.
> 
> Please don't think I'm not open to help from the Team but your upload broke 
> requests on sid: #707780.
> I was already working on python-urllib3...

Hi,

I'm sorry, my fault indeed. I didn't notice it because I had
python-urllib3 1.5 installed, and because I'm not used to SVN, I didn't
build in a cowbuilder like I do with git-buildpackage. Please close
#707780 in your next upload of python-urllib3.

> First time you uploaded requests on experimental I asked only for a ping: 
> just 
> to know and I told you (on IRC) that I want to fix #698258 before uploading 
> requests in sid.
> 
> Please, next time coordinate with the actual maintainer.

I just forgot about it. :(

FYI, I just uploaded a bunch of dependencies that I need for uploading
OpenStack Grizzly into SID (it's currently in Experimental).
python-requests was one of them.

If you need help for python-urllib3, let me know.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518e6789.8020...@debian.org

Fwd: python-eventlet_0.12.1-2_amd64.changes REJECTED

[Thomas Goirand]

Hi there!

What's happening? Is dak going mad? :)

FYI, here's the chain of event that lead to this situation (as it might
help you to debug). What happened is that:

1- I first uploaded python-eventlet_0.12.0-2 as I wanted it to move from
Experimental to sid.

Then it was rejected because there was no .orig.gz in the archive. I
didn't understand at first. Then discovered that this was because
python-eventlet_0.12.1 was in experimental, and not 0.12.0, and that the
previous uploaded didn't update the SVN of the package. So I tried to
correct it, built 0.12.1-2, but unfortunately

2- uploaded the missing orig.gz for 0.12.0-2 (I just did a bad copy /
past when using dupload).

Then I am now trying to upload 0.12.1-2, and I get what's below...

Please help me to correct this mess and migrate python-eventlet 0.12
from Experimental to sid.

Cheers,

Thomas

 Original Message 
Subject: python-eventlet_0.12.1-2_amd64.changes REJECTED
Date: Sat, 11 May 2013 16:18:49 +
From: Debian FTP Masters 
To: Debian Python Modules Team
, Thomas Goirand



There was an uncaught exception when processing your upload:
Traceback (most recent call last):
  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 213,
in wrapper
return function(directory, upload, *args, **kwargs)
  File "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 265,
in accept
upload.install()
  File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line
1198, in install
self._do_bts_versiontracking()
  File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line
1125, in _do_bts_versiontracking
sourcedir = self.unpacked_source()
  File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 698,
in unpacked_source
subprocess.check_call(["dpkg-source", "--no-copy", "--no-check",
"-x", dsc_path, sourcedir], shell=False, stdout=devnull)
  File "/usr/lib/python2.6/subprocess.py", line 488, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['dpkg-source', '--no-copy', '--no-check',
'-x',
'/srv/ftp-master.debian.org/tmp/dakRDPyYk/python-eventlet_0.12.1-2.dsc',
'/srv/ftp-master.debian.org/tmp/dakRDPyYk/source']' returned non-zero
exit status 9

Any original reject reason follows below.


===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518e7d8b.6070...@debian.org

Re: Is subgit for migrating from Git to SVN?

[Thomas Goirand]

On 05/12/2013 04:26 PM, Dmitry Shachnev wrote:
> “SubGit is a closed source software.”

Oh! Missed that. Thanks for taking the time to look at it.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518f65f3.3050...@debian.org

Update of python-anyjson 0.3.3

[Thomas Goirand]

Hi Michael,

I've seen that you've updated the debian/changelog in order to upload
the new upstream version. Is it ok if I upload it to Sid right now?

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ca85c2.2030...@debian.org

Re: Update of python-anyjson 0.3.3

[Thomas Goirand]

On 06/26/2013 02:10 PM, Thomas Goirand wrote:
> Hi Michael,
> 
> I've seen that you've updated the debian/changelog in order to upload
> the new upstream version. Is it ok if I upload it to Sid right now?
> 
> Thomas Goirand (zigo)

FYI, this has been done.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51caf173.9050...@debian.org

Inconsistency in source package naming for python modules

[Thomas Goirand]

Hi,

Over the last months, I've seen lots of inconsistency in the source
package naming scheme in the python module maintained in the team.
Sometimes, module X will have its source package called python-X or just X.

If we have a python module named X, then IMO, we should stick to call
the source package python-X, and not just X. Why? Because AFAICT it
seems that there's a consensus in Debian that, if a package is producing
a single binary, then its source package should have the same name.

It isn't my intention to fix mistakes already made (IMO, too much work
for not enough rewards), but I wanted to raise this topic to check if
others have the same opinion, and to make sure we have this in the
python policy (in one way or the other). Thoughts anyone?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51dac5a6.5090...@debian.org

Re: Inconsistency in source package naming for python modules

[Thomas Goirand]

On 07/08/2013 10:10 PM, Scott Kitterman wrote:
> There is no policy on this either way, so there's no "mistake".

Well, the mistake is precisely to have no rule, IMO.

On 07/08/2013 11:37 PM, Barry Warsaw wrote:
> Hopefully, it will become more and more common to have at least
> python-X and python3-X.  With that in mind, many of our source
> packages that are producing a single binary package today should
> hopefully be producing two or more binary packages tomorrow.

Never the less, I think we should collectively decide what to do, rather
than continuing the mess, with everyone having its own rule.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51dd0631.5000...@debian.org

Re: Inconsistency in source package naming for python modules

[Thomas Goirand]

On 07/10/2013 10:30 PM, Stuart Prescott wrote:
> Thomas Goirand wrote:
>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>>> There is no policy on this either way, so there's no "mistake".
>>
>> Well, the mistake is precisely to have no rule, IMO.
> 
> Rules for packaging things are normally there to solve problems of 
> interoperability and to assist QA efforts. Which of these is it going to 
> help?
>  
>> Never the less, I think we should collectively decide what to do, rather
>> than continuing the mess, with everyone having its own rule.
> 
> What mess? If there is a perceived mess, why is that a problem in any case? 
> How does it help to make a new rule? Who does it help? What problem does 
> this solve? Why is any intellectual energy being spent on this at all?

Oh, I need this pyX package... Let's download it.

# apt-get source pyX
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for pyX

shit, let's try again...

# apt-get source python-X
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for python-X

grr...

# apt-get source X
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]

And then, finally, it's called "migrate" instead of "sqlalchemy-migrate"
like upstream called it... :)

(this never happened to me with python-migrate, though that's a good
example of a IMO badly named source package)

And that's just an example on what can go wrong and be really annoying.
It's even more annoying when you are trying to do a "git svn clone"
which takes forever.

Sure, we can continue and have a "free for all" thing, though knowing
what the others do, and try to do the same so we *at least try* to have
a bit of consistency, can't hurt.

> It looks exceedingly like a rule for the sake of having a rule. It will be 
> an exceedingly complicated rule in that it will have to cover python 
> modules, python applications and other libraries that offer python bindings 
> all separately. It will have to be accompanied an explanation of why so many 
> packages don't follow it because they were uploaded prior to the rule 
> existing. Basically... unless we are going to force every existing source 
> package to change name to comply with this rule there is no point in having 
> it (and no-one has advocated renaming source packages as is useless work for 
> everyone).

Ok, so let's not use the word "rule" but call it "guide-line", and for
future packages only (I have *never* proposed to change already uploaded
packages). Do you feel more comfortable now? :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ddbbdb.6070...@debian.org

Re: Inconsistency in source package naming for python modules

[Thomas Goirand]

On 07/11/2013 03:59 AM, Bradley M. Froehle wrote:
> I think a recommendation (for new packages) would be helpful, but I'm
> against any source naming requirements or strict rules.

Then we agree! That's all what I'm asking for.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51de573e.9060...@debian.org

Re: Inconsistency in source package naming for python modules

[Thomas Goirand]

On 07/11/2013 04:07 AM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-07-10]
>> And then, finally, it's called "migrate" instead of "sqlalchemy-migrate"
>> like upstream called it... :)
>> (this never happened to me with python-migrate, though that's a good
>> example of a IMO badly named source package)
> 
> if you wanted to download python-migrate's sources... why didn't you
> tell apt-get that that's what you want?
> apt-get is clever enough to figure out the right source package name:
> 
> $ apt-get source python-migrate
> [...]
> Picking 'migrate' as source package instead of 'python-migrate'
> [...]

Please don't pick on that specific example.

> `debcheckout python-migrate` will pick the right source package as well

debcheckout will use SVN, and I prefer git-svn.

Anyway, we're digressing. If you don't see a value in consistency, never
mind.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51de57b2.5000...@debian.org

Re: Inconsistency in source package naming for python modules

[Thomas Goirand]

On 07/11/2013 09:07 PM, Stuart Prescott wrote:
> 
>> Oh, I need this pyX package... Let's download it.
> 
> You're using a python module name because you need to import it. If you want 
> to import modules, you want the binary package name; if you want to work on 
> the source package then you need *either* the binary package name or the 
> source package name as others have already pointed out. Knowledge of source 
> package names isn't required.

But if you have py (let's say on pypi), then even the binary
package isn't obvious. It could be:
python-py

or:
python-

I've seen both cases in the archive!

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51dedbc9.7000...@debian.org

Re: PyCon 2013 -- anyone submitted/planing to go?

[Thomas Goirand]

On 09/05/2013 09:10 PM, Yaroslav Halchenko wrote:
> and present what
> to expect in upcoming stable (wheezy) release of Debian

You may want to update that part! :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/522b3cc4.1080...@debian.org

Re: PEP 453 affects Debian packaging of Python packages

[Thomas Goirand]

On 09/18/2013 11:41 PM, Piotr Ożarowski wrote:
>>   4) Python modules from dpkg are borderline useless for developers. We
>>  package modules so that apps can use them, not so that people can
>>  develop with them.
> 
> nobody forces Python/Ruby/... developers to use libraries prepared by
> us... and yet they want to force us to use their .eggs and overwrite our
> files.

Kind of funny to read this. Before doing a lot of Python packaging, I
was doing some PHP PEAR packaging. There as well, they forced the users
to use "pear install" instead of apt / dpkg. There as well, they were
writing stuff in their README about how to use PEAR. I suppose we have
lots of this kind of occurrence all over the place in Debian (Piotr, you
mentioned Ruby, it must be a good example, I guess (I don't know ruby at
all)).

In PHP, having the pear shell tool wasn't a problem, even if you don't
use it (and even if I would recommend against using it). Then Mathieu
Parent wrote pkg-php-tools, and I wrote "debpear" over it, which
automatically transforms a PEAR package into a Debian package. The same
way, I wrote debpypi, so that I don't waste my time writing again and
again the same stuff. Though my debpypi isn't good enough to be
released, I heard Piotr wrote the same kind of tool.

Shouldn't we go the same way, and encourage our users to use a kind of
wrapper around pip, so that they really get a Debian package installed
instead of a "pip install" thing which will mess everything? Piotr,
where is the tool you told me about? Could you share it? I've attached
my stupid script, just as a reference (though please don't tell me it's
not good enough, I know that already).

Cheers,

Thomas

#!/bin/sh

set -e
set -x

if [ "${1}" = "-u" ] && [ -n "${2}" ] ; then
ORIG_URL="${2}"
shift
shift
fi

if [ -z "${1}" ] ; then
echo "Usage: ${0} package-name"
exit 1
fi

PKG_NAME=${1}
DEB_PKG_NAME=python-${PKG_NAME}


if [ ! -e ${PKG_NAME}.xml ] ; then
echo "===> Downloading DOAP XML record"
wget -nv "https://pypi.python.org/pypi?:action=doap&name=${PKG_NAME}"; 
-O ${PKG_NAME}.xml
fi

# Get info from the XML document using xpath.
VERSION_STRING=`xpath -e "//release/Version/revision/text()" ${PKG_NAME}.xml 2> 
/dev/null`
SHORT_DESC=`xpath -e "//shortdesc/text()" ${PKG_NAME}.xml 2> /dev/null`
LONG_DESC=`xpath -e "//description/text()" ${PKG_NAME}.xml 2> /dev/null`
UP_MAINT_NAME=`xpath -e "//maintainer/foaf:Person/foaf:name/text()" 
${PKG_NAME}.xml 2> /dev/null`
HOMEPAGE=`xpath -e "//homepage/@rdf:resource" ${PKG_NAME}.xml 2> /dev/null | 
cut -d= -f2 | sed 's#"##g'`
FIRST_LETTER=`echo ${PKG_NAME} | awk '{print substr($0,0,1)}'`
if [ -e ${DEB_PKG_NAME}_${VERSION_STRING}.orig.tar.xz ] ; then
ORIG=${DEB_PKG_NAME}_${VERSION_STRING}.orig.tar.xz
else
ORIG=${DEB_PKG_NAME}_${VERSION_STRING}.orig.tar.gz
fi

if [ ! -e ${ORIG} ] ; then
echo "===> Downloading ${ORIG} file"
if [ -z "${ORIG_URL}" ] ; then

ORIG_URL=https://pypi.python.org/packages/source/${FIRST_LETTER}/${PKG_NAME}/${PKG_NAME}-${VERSION_STRING}.tar.gz
fi
wget -nv "${ORIG_URL}" -O ${ORIG}
fi

echo "===> Extracting ${ORIG}"
tar -xf ${ORIG}
mv ${PKG_NAME}-${VERSION_STRING} ${DEB_PKG_NAME}-${VERSION_STRING}

echo "===> Creating debian folder for ${DEB_PKG_NAME}"
if [ ! -d ${DEB_PKG_NAME}-${VERSION_STRING}/debian/source ] ; then
mkdir -p ${DEB_PKG_NAME}-${VERSION_STRING}/debian/source
fi
cd ${DEB_PKG_NAME}-${VERSION_STRING}

echo "Source: ${DEB_PKG_NAME}
Section: python
Priority: optional
Maintainer: PKG OpenStack 
Uploaders: Julien Danjou ,
   Thomas Goirand ,
   Mehdi Abaakouk 
Build-Depends: debhelper (>= 9), python-setuptools, python-all (>= 2.6.6-3~), 
openstack-pkg-tools
Standards-Version: 3.9.4
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=openstack/${DEB_PKG_NAME}.git
Vcs-Git: git://anonscm.debian.org/openstack/${DEB_PKG_NAME}.git
Homepage: ${HOMEPAGE}

Package: ${DEB_PKG_NAME}
Architecture: all
Pre-Depends: dpkg (>= 1.15.6~)
Depends: \${python:Depends}, \${misc:Depends}
Recommends: \${python:Recommends}
Description: ${SHORT_DESC}
 ${LONG_DESC}
" >debian/control
EDITOR=touch dch --create --package ${DEB_PKG_NAME} --distribution unstable 
--urgency low -v ${VERSION_STRING}-1
rm +1

echo "9" >debian/compat
echo "Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: ${PKG_NAME}
Source: ${HOMEPAGE}

Files: debian/*
Copyright: (c) 2013, Thomas Goirand 
License: Apache-2

Files: *
Copyright: (c) 2013, ${UP_MAINT_NAME}
License: Ap

Re: PEP 453 affects Debian packaging of Python packages

[Thomas Goirand]

On 09/19/2013 12:55 AM, Thomas Kluyver wrote:
> On 18 September 2013 08:41, Piotr Ożarowski  > wrote:
> 
> so instead of reinventing the wheel and trying to make something that
> works everywhere they should make it easier for others to convert
> whatever they provide (tarballs?) into .rpm, .deb or .exe.
> 
> 
> From a developer point of view: this leaves you dependent on other
> people to get the latest release of your software to users, which can be
> very frustrating. For instance, I'm a developer for IPython: we made a
> 1.0 release over a month ago, and there's already been a 1.1 release
> since then, but Debian unstable still doesn't have either of these. This
> is not to criticise our packager, who we have a good relationship with,
> but simply to point out that this system is beyond our control. If we
> recommend that people use apt/yum/port/whatever to install IPython,
> they'll get an old package, with bugs that we've already fixed. By
> contrast, we update the packages on PyPI at release time, so users
> installing with pip will always get the current version.
> 
> Thomas

Then get involved in the Debian packaging: problem solved!

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523c031e.3030...@debian.org

Re: Disabling pip for root?

[Thomas Goirand]

On 09/19/2013 05:26 PM, W. Martin Borgert wrote:
> On 2013-09-18 09:36, Paul Tagliamonte wrote:
>>   1) pip isn't for global package management, for this is stupid. If we
>>  disabled root use of pip, I think we'd all be a bit happier.
> 
> Very quick and very dirty patch attached.
> 
>>   4) Python modules from dpkg are borderline useless for developers. We
>>  package modules so that apps can use them, not so that people can
>>  develop with them.
> 
> That is maybe my problem with pip: Developers tend to use every Python
> library in every version they like from PyPI.

I couldn't agree more with that. In OpenStack, I see upstream writing:

package-name==1.2.3

Or even:

package-name>=1.2.3,<=1.2.4

when in fact, there's not even a 1.2.4 released, and the developer just
writes this "just in case". I've been fighting a lot of these. That's
really bullshit dependency management, and fighting with it is
exhausting, patching endelessly the requirements.txt file. Especially
tiring when dealing with nearly a hundred package.

Worse, some upstream developers don't understand that writing a
dependency like <= 1.2.4 in a requirements.txt file does *not* fix the
problem for a distribution, and that if 1.2.5 is available in the
distro, we will *not* go back and package an older version. This is the
kind of trouble we have with pip, and it's not going away.

How can we get rid of this, or at least keep it to a bearable minimum?
Well, unfortunately, I think that there's no other way but educating
upstream coders. But also, it'd be super nice if the people upstream for
Python itself understood it and could see from the point of view of a
distribution like Debian. Seeing that they push for even more pip crap
shows that they didn't get it.

> As a project leader I
> generally have to think about deployment and this means: Use Debian
> stable and backports! Only for long-term projects the next Debian
> stable release might be relevant. But if you have a dozen or so
> libraries installed by pip, there are libraries that will not be
> packaged for Debian and the deployment is wrecked.

It's really not hard to package some Python modules for Python. Having a
tool that does it automatically - even not very well -, like debpear
does, can solve this kind of trouble. Giving access to this kind of
tools to a wide user base can also help solving the "oh, but that module
isn't available in Debian" kind of problem.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523c0780.7010...@debian.org

Re: Disabling pip for root?

[Thomas Goirand]

On Fri Sep 20 2013 07:48:07 PM HKT, Paul R. Tagliamonte  
wrote:

> Why not see if upstream pip wants to add an optional dpkg install method
> when using root on a dpkgey system? Slightly hackish but at least itd
> reduce suck.

Very good idea indeed!

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1379678437.1838.5.camel@Nokia-N900-42-11

Re: PEP 453 affects Debian packaging of Python packages

[Thomas Goirand]

PLEASE everyone, I'm registered to the list, and adding me as Cc: is
breaking my filters...

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523d1d76.60...@debian.org

Packaging wheel

[Thomas Goirand]

Hi,

I came across this in the OpenStack global-requirements.txt file:
https://pypi.python.org/pypi/wheel

Is this of any interest for Debian? Has anyone used it? Would it be nice
to have it packaged? Your thoughts?

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5247e95f.8010...@debian.org

Re: Python-babel 1.3 available from Sid

[Thomas Goirand]

On 10/08/2013 03:34 AM, Sebastian Ramacher wrote:
> Hi
> 
> On 2013-10-08 00:50:27, Thomas Goirand wrote:
>> Hi,
>>
>> FYI, I have uploaded python-babel 1.3 in Sid. I couldn't wait for more,
>> so I did the work...
>>
>> I haven't pushed to the SVN, because git-svn is producing some weird
>> errors. Andrey, could you push the changes?
>>
>> Cheers,
>>
>> Thomas
> 
> How about you clean up the mess you've created?
> 
> Andrey clearly stated in the bug that he's working on it

He wrote that on Wed, 28th of Aug 2013. That's a long time ago, and as I
couldn't wait for more, as some or my packages for OpenStack
(build-)depends on Babel 1.3.

> and changed the topic of #debian-python to look for a sponsor.

I'm sorry that I missed it, and that I got fooled by the wrong VCS
fields in the old package. Though probably writing in this bug would
have been more efficient than writing in the topic of the IRC channel?

> So you could have at
> least asked Andrey what's the status of the packaging and helped him
> upload the changes he has prepared in the repository.
> 
> I find this behavior very inappropriate.

You want to talk about behaviors and include the -python list to add
some fun? Let's do that if you think that helps (I think it's a huge
waste of time). wRAR/Andrey's behavior is bordeline with me on IRC all
the time, and it starts to be quite annoying. I'd like this type of
harassment to to stop right away: it's not fun to read at all.

> Apart from that your changes in debian/copyright are wrong.

Would you care explain what is wrong there?

> debian/changelog is inaccurate (python-pybabel is still there).

Yes right, because I saw that there was still some reverse dependencies
and reverted my change, then forgot to also revert the changelog. I have
filled bugs against packages that still depends on pybabel and I think
it's best to wait until they are fixed.

> There is no ${python:Recommends}.

What do you mean there's no ${python:Recommends}?

> Why does python-babel-doc depend on
> python3-pkg-resources and why is ${sphinxdoc:Depends} missing?

This is a bad copy/past which should be fixed. Not a huge deal to fix
though (the bulk of the work in the other parts of the package was the
most important bit of what was urgently needed).

Let's fix the above problems, though I'd like to know what's the way to
fix the VCS. What's the new path for it?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52538f93.8050...@debian.org

Re: Python-babel 1.3 available from Sid

[Thomas Goirand]

On 10/08/2013 07:28 PM, Sebastian Ramacher wrote:
>> He wrote that on Wed, 28th of Aug 2013. That's a long time ago, and as I
>> couldn't wait for more, as some or my packages for OpenStack
>> (build-)depends on Babel 1.3.
> 
> For a package that had to go through NEW anyway that's really no excuse.
> Pinging him and waiting a day or two for a reply doesn't hurt.

You are writing this as if I knew that he had something ready. That is
*not* the case. Sorry, I don't spend my life on IRC reading channel
topics. This is the first time ever that I see a case of an RFS in a
channel topic, and frankly, this really isn't the proper way IMO. Also,
I've checked the VCS (as advertized on the VCS fields of the package),
and saw nothing. How could I guess that the sources moved? (don't reply
"IRC channel topic" again please...)

To stay on the IRC topic, you may have (not) notice that I did say that
I couldn't write in the advertized VCS of babel. Nobody noticed... And
that was before the upload, IIRC. See what I mean? IRC is a very bad way
to keep track of things.

Besides this, pointing fingers *twice* at me on a public list serves no
purpose. Can't you just move on?

>>> Why does python-babel-doc depend on
>>> python3-pkg-resources and why is ${sphinxdoc:Depends} missing?
>>
>>This is a bad copy/past which should be fixed. Not a huge deal to fix
>>though (the bulk of the work in the other parts of the package was the
>>most important bit of what was urgently needed).
>
> That's no excuse to upload an unfinished package.

What are you trying to achieve with this sentence? Piss me off? Well
done, you've succeeded. Do something more productive, this attitude
doesn't help.

Mind you, I spent hours on this update, and did quite some work. It's
not a perfect work I admit, but it did what it should have: have
python-babel and python3-babel available for others to use, on time for
my purpose (which is to have OpenStack ready for its release). So I say
it again: the -doc missing ${sphinxdoc:Depends} is a tiny small issue
which is fixable easily.

You are BTW welcome to do the work if you wish (and I will be happy to
sponsor it if you ask properly in this list, or if you highlight my nick
on IRC, in which case I will notice, but please, don't just use the
channel's topic...).

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5255ab9c.9030...@debian.org

Re: Program shebang line with specific ‘/usr/bin/pythonX.Y’ interpreter

[Thomas Goirand]

On 10/10/2013 07:04 PM, Ben Finney wrote:
> Dmitry Shachnev  writes:
> 
>> In your particular case, python3-coverage depends on 'python3 (<<
>> 3.4), python3 (>= 3.3)', so when it is installed /usr/bin/python3 will
>> be always a link to python3.3, so the shebang doesn't matter here. But
>> in general, I recommend people to use non-versioned shebangs in their
>> packages.
> 
> For dependencies, the ‘debian/control’ has:
> 
> =
> …
> Package: python-coverage
> Depends:
> ${python:Depends},
> …
> Package: python3-coverage
> Depends:
> …
> ${python3:Depends},
> …
> =
> 
> The dependencies in the resulting binary packages are created by the
> Debhelper tools for Python.

Hi Ben (and others),

FYI, I'm currently working on the package. I'm having a hard time with
bzr, though... so I probably will send you a patch against the current
version. Just one thing that would help me a lot: could you please add
what I attached to the debian/rules to generate a dfsg orig file, run
it, and then put the generated content instead of what is currently in
the BZR repository? That's because currently, even if debian/changelog
says version 3.7, there's differences with upstream tarball which makes
FTBFS, so I can't work correctly on the packaging...

Then when done, I'll be able to test it more, and see if I can sponsor
it. I'll be very happy if we can tackle this one package which I need to
be ready for next week.

Cheers,

Thomas Goirand (zigo)


DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p')
VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e 
's/[-].*//')
NO_DFSG ?= $(shell echo '$(VERSION)' | sed -e 
's/\+dfsg\.[[:digit:]]*//')

.PHONY: get-orig-source
get-orig-source:
rm -f coverage-$(NO_DFSG).tar.gz 
$(CURDIR)/../python-coverage_$(VERSION).tar.gz
wget 
http://pypi.python.org/packages/source/c/coverage/coverage-$(NO_DFSG).tar.gz
tar -xzf coverage-$(NO_DFSG).tar.gz
rm coverage-$(NO_DFSG)/coverage/htmlfiles/jquery.min.js
rm coverage-$(NO_DFSG)/coverage/htmlfiles/jquery.tablesorter.min.js
rm coverage-$(NO_DFSG)/tests/farm/html/src/htmlcov/jquery-1.4.3.min.js
rm 
coverage-$(NO_DFSG)/tests/farm/html/src/htmlcov/jquery.tablesorter.min.js
rm coverage-$(NO_DFSG)/tests/qunit/jquery.tmpl.min.js
mv coverage-$(NO_DFSG) python-coverage-$(VERSION)
tar -czf $(CURDIR)/../python-coverage_$(VERSION).tar.gz 
python-coverage-$(VERSION)
rm -r python-coverage-$(VERSION) rm -f coverage-$(NO_DFSG).tar.gz

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

[Thomas Goirand]

On 10/12/2013 01:26 AM, Barry Warsaw wrote:
> On Oct 11, 2013, at 07:23 PM, Julian Taylor wrote:
> 
>> It is better if one disables internet access of package builds completely.
>> With pbuilder and iptables this is very easy, just run this when booting:
>>
>> iptables -I OUTPUT ! -d 127.0.0.1 -m owner --gid-owner 1234 -j REJECT 
>> --reject-with icmp-port-unreachable
>> ip6tables -I OUTPUT ! -d ::1 -m owner --gid-owner 1234 -j REJECT 
>> --reject-with icmp6-port-unreachable
>>
>> (It works because pbuilder builds as user 1234, won't work for --login 
>> sessions)
> 
> And if you don't use pbuilder? :)
> 
> -Barry

Well, if you don't, you should! :)


Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5258c164.2020...@debian.org

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

[Thomas Goirand]

On 10/12/2013 11:33 AM, Scott Kitterman wrote:
> On Saturday, October 12, 2013 11:26:28 Thomas Goirand wrote:
>> On 10/12/2013 01:26 AM, Barry Warsaw wrote:
>>> On Oct 11, 2013, at 07:23 PM, Julian Taylor wrote:
>>>> It is better if one disables internet access of package builds
>>>> completely.
>>>> With pbuilder and iptables this is very easy, just run this when booting:
>>>>
>>>> iptables -I OUTPUT ! -d 127.0.0.1 -m owner --gid-owner 1234 -j REJECT
>>>> --reject-with icmp-port-unreachable ip6tables -I OUTPUT ! -d ::1 -m
>>>> owner --gid-owner 1234 -j REJECT --reject-with icmp6-port-unreachable
>>>>
>>>> (It works because pbuilder builds as user 1234, won't work for --login
>>>> sessions)> 
>>> And if you don't use pbuilder? :)
>>>
>>> -Barry
>>
>> Well, if you don't, you should! :)
>> 
> 
> IIRC Barry uses sbuild, so I think you missed his point.

I was just trying to be funny, and wasn't following any point... :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5258d814.7020...@debian.org

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

[Thomas Goirand]

On 10/14/2013 07:23 PM, Jakub Wilk wrote:
> * Barry Warsaw , 2013-10-11, 11:03:
>> The point of this recommendation is so that missing Build-Depends are
>> exposed when you are testing your package builds locally.
> 
> ACK
> 
>> If you omit them, your package will still properly FTBFS, but only on
>> the buildds.
> 
> Unless something changed recently, Debian buildds don't block Internet
> access. :(

I've read multiple times that they do. Could you show a build log where
something is downloaded?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525c2e23.6040...@debian.org

Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

Hi everyone in the Python list!

I've been working with Ben Finney on upgrading python-coverage to 3.7. I
believe the package was in good shape before the upload, at the
exception that /usr/bin/coverage isn't provided by the package. Ben
opened but #726255 to track the issue.

My proposal fix was this:

http://anonscm.debian.org/loggerhead/collab-maint/python-coverage/python-coverage.debian/revision/176

which uses update-alternatives, like I saw in other python packages (for
example, in waitress, and many others). Ben didn't agree with it, he
wrote to me on IRC that there is a "controversy" about it. He then
reverted my change, and I agree to not commit in his trunk anymore.

We both didn't want to hold the update of python-coverage which was
really overdue: the last upload was from 2012-05, and version 3.6
(required for many packages) was released early last January. So I went
ahead and sponsored the upload of python-coverage 3.7.

Though, #726255 still needs a resolution, and I would like to have the
view of other Python module maintainers. Is using update-alternatives
the way to go? Was my commit correct? Is there any other (better) way to
do things here?

Please let both Ben and I know your view.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525cb199.2010...@debian.org

Re: Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

On 10/15/2013 02:39 PM, Ben Finney wrote:
> My disagreement is several-fold:
> 
> * The binary package ‘python-coverage’ is for Python 2, and
>   ‘python3-coverage’ is for Python 3. These are, as I understand it,
>   deliberately treated as distinct runtime systems in Debian's Python
>   world.
> 
>   So is it correct for both of them to attempt to provide the same
>   command, when in most Python packages we're deliberately naming
>   development tools to have Python 3 explicitly a separate runtime
>   system?

You will *not* find any upstream source code that will be using
/usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all
of them will be using /usr/bin/coverage (if they need the command line
tool). Thinking that you will be able to patch all of them is both an
illusion and a waste of time IMO.

If we have update-alternatives, then it's very easy for a maintainer to
choose which one of the 2 implementation it wants:

Build-Depends: python-coverage
Build-Conflicts: python3-coverage

if you need /usr/bin/coverage to be python-coverage, or:

Build-Depends: python3-coverage
Build-Conflicts: python-coverage

if you want /usr/bin/coverage to be the python3-coverage implementation.
That's easy enough. Also, with priorities like I wished to set,
python-coverage (eg: Python 2) was the preferred implementation.

> * If we're not going to have Python 2 and Python 3 packages attempt to
>   provide the same command name, there doesn't seem much point using the
>   Debian alternatives system. A symlink, as is already used in existing
>   releases of the package, should be sufficient.

There's no symlink in /usr/bin/coverage in the current package.

> * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in
>   Debian for a Python-only development tool.

While I agree in principles, there is, so far, no other package that
claims this file. You can use "apt-file search /usr/bin/coverage" to
check for this. The problem is that *upstream code* is using
/usr/bin/coverage. So unless you explain this to upstream and have the
issue fixed over there, and have it fixed in the pypi package, you
cannot expect downstream code (users of python-coverage) to use anything
else.

Also, if there was another package that were using /usr/bin/coverage, it
could also use the update-alternatives thing (if it's implementing the
same thing, of course... otherwise we have a problem).

>   This was the reason for
>   renaming the binary ‘/usr/bin/python-coverage’ in every Debian release
>   of the package so far.

If you went into renaming the *source* package of python-coverage, then
IMO you wasted your time. There's never a problem with source package
name conflicts in Debian (I mean other than having things look nice,
there's no technical problem), only with the resulting binaries and the
files that they include.

>> We both didn't want to hold the update of python-coverage which was
>> really overdue: the last upload was from 2012-05, and version 3.6
>> (required for many packages) was released early last January. So I
>> went ahead and sponsored the upload of python-coverage 3.7.
> 
> I'm really glad to see this, and thanks to Thomas for agreeing to get
> Coverage 3.7 into Debian separately from this mostly-unrelated issue.

:)

Let's hope it passes the NEW queue fast.

>> Though, #726255 still needs a resolution, and I would like to have the
>> view of other Python module maintainers. Is using update-alternatives
>> the way to go? Was my commit correct? Is there any other (better) way to
>> do things here?
>>
>> Please let both Ben and I know your view.
> 
> Likewise. (I'm subscribed to this forum, and AFAIK Thomas is also, so
> no need to Cc us on the discussion.)

Agreed, also because that's the Debian list code of conduct to not do so
unless requested.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525d08b4.2030...@debian.org

Re: Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

On 10/15/2013 07:04 PM, Jakub Wilk wrote:> Apparently two (mostly
orthogonal) problems have been squeezed into a
> single bug report:
>
> 1) Is the name /usr/bin/coverage appropriate?
> 2) Can the alternatives mechanism be used to switch between the two
> implementations of the coverage command line tool?

Please let's focus on providing /usr/bin/coverage. I don't really care
by what mechanism, as long as the unit tests are working, and Debian
behaves like upstream coverage package from pypi. We can leave the
implementation details for later. Even if only python-coverage (as
opposed to the python3- version) was providing it, I'd be satisfied.

On 10/15/2013 06:21 PM, Tristan Seligmann wrote:
> What sort of upstream "source code" would be using the /usr/bin
> wrapper at all? (I ask this question without prejudice; I can
> obviously imagine some ways this might happen, but I'm more interested
> in the actual existing use cases that you implied, not ones that only
> exist in my imagination)

I'm not sure if you're talking about the *full path* bit or what.
Upstream code (or at least, unit tests...) is calling "coverage" from
the standard accessible $PATH.

For example:

zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage
  python setup.py testr --coverage

Nearly all OpenStack projects are using testrepository. All of them are
using python-coverage. Many python modules are as well, and I had to
patch some of them to avoid the problem (sorry, I can't remember which
one right now...). I would like that it doesn't happen again, and also
that our users (eg: developers trying to find out unit test coverage)
can run the coverage tests without troubles.

>>> * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in
>>>   Debian for a Python-only development tool.
>>
>> While I agree in principles, there is, so far, no other package that
>> claims this file. You can use "apt-file search /usr/bin/coverage" to
>> check for this. The problem is that *upstream code* is using
>> /usr/bin/coverage. So unless you explain this to upstream and have the
>> issue fixed over there, and have it fixed in the pypi package, you
>> cannot expect downstream code (users of python-coverage) to use anything
>> else.
> 
> I think this is ultimately the problem of whichever package comes
> second, not python-coverage. (cf. other examples of name collisions,
> like ack/ack-grep)
> 
>> Also, if there was another package that were using /usr/bin/coverage, it
>> could also use the update-alternatives thing (if it's implementing the
>> same thing, of course... otherwise we have a problem).
> 
> Presumably it would /not/ be implementing the same thing.

The thing is, we can bikeshed about what *may* happen *in the future*.
Though right now, there's a problem which I would like to fix. And that
is very easily fixed by providing /usr/bin/coverage, while "ugly
hacking" (because that's what it is about) in all other upstream
projects is a much, much harder task.

Thomas


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525d2b37.50...@debian.org

Re: Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

On 10/15/2013 07:01 PM, Dmitry Shachnev wrote:
> On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand  wrote:
>> If we have update-alternatives, then it's very easy for a maintainer to
>> choose which one of the 2 implementation it wants:
>>
>> Build-Depends: python-coverage
>> Build-Conflicts: python3-coverage
>>
>> if you need /usr/bin/coverage to be python-coverage, or:
>>
>> Build-Depends: python3-coverage
>> Build-Conflicts: python-coverage
> 
> This looks wrong to me. If these programs are incompatible (i.e.
> provide different outputs), then this is a bug. Otherwise, there
> should be no need in Build-Conflicts.
> 
>> if you want /usr/bin/coverage to be the python3-coverage implementation.
>> That's easy enough. Also, with priorities like I wished to set,
>> python-coverage (eg: Python 2) was the preferred implementation.
> 
> I think our goal is to switch as many modules to Python 3 as we can,
> so I don't see any point in giving python-coverage a bigger priority.
> 
> --
> Dmitry Shachnev

Let's please forget about the above, and focus on python-coverage (eg:
the Python 2.x implementation) to provide the /usr/bin/coverage support.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525d2bad.1090...@debian.org

Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool

[Thomas Goirand]

On 10/16/2013 07:32 AM, Ben Finney wrote:
>> Nearly all OpenStack projects are using testrepository. All of them
>> are using python-coverage.
> 
> That sounds like an excellent central point to make the command name
> parameterisable: fix it in one place to match the Debian
> ‘python-coverage’ package, and all OpenStack packages can benefit from
> that.
> 
> Note that I don't know whether that would work, but it's one option that
> seems available.

Unfortunately, that's not the case.

>> Many python modules are as well, and I had to patch some of them to
>> avoid the problem (sorry, I can't remember which one right now...). I
>> would like that it doesn't happen again, and also that our users (eg:
>> developers trying to find out unit test coverage) can run the coverage
>> tests without troubles.
> 
> Patching upstream's assumptions of command names is a feature of the
> landscape for Debian packagers. I don't consider that a reason to
> presume ‘/usr/bin/coverage’ on Debian should refer to a Python-specific
> tool.

I'm not denying the fact it's possible to do what you say. I'm saying
it's too much effort compared to providing /usr/bin/coverage in Debian.
You are simply ignoring this point of my argumentation, which is the
most important part.

You have also ignore the point where I say that there's currently no
conflict, so it doesn't mater. In the future *IF* there is one, then we
may fix, but in the meanwhile, there is no problem at all. So why should
we bother?

Could you please reply to both points?

Thomas

P.S: Also, please keep 726...@bugs.debian.org as CC.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e166d.3020...@debian.org

Re: Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

On 10/16/2013 02:20 PM, Robert Collins wrote:
> I think it's reasonable to get OpenStack to look for python-coverage
> to run it's tests when using a system package. Or use python -m
> coverage. 'coverage' is indeed super generic and the precedent within
> Debian for the package is to call the binary 'python-coverage'.
> 
> Is there some reason we can't take that approach?
> 
> -Rob

Hi Robert,

If you think this way, as an upstream author, then I have to agree.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e4164.7080...@debian.org

Re: Using update-alternatives for /usr/bin provided binaries

[Thomas Goirand]

On 10/16/2013 01:52 PM, Tristan Seligmann wrote:
> On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand  wrote:
>> On 10/15/2013 06:21 PM, Tristan Seligmann wrote:
>>> What sort of upstream "source code" would be using the /usr/bin
>>> wrapper at all? (I ask this question without prejudice; I can
>>> obviously imagine some ways this might happen, but I'm more interested
>>> in the actual existing use cases that you implied, not ones that only
>>> exist in my imagination)
>>
>> I'm not sure if you're talking about the *full path* bit or what.
>> Upstream code (or at least, unit tests...) is calling "coverage" from
>> the standard accessible $PATH.
>>
>> For example:
>>
>> zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage
>>   python setup.py testr --coverage
> 
> Does this really invoke /usr/bin/coverage, as opposed to just
> importing the coverage module (I'm not familiar with testrepository)?

Yes, please look at the beginning of #726255 where I show what happens.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e423d.6000...@debian.org

Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool

[Thomas Goirand]

On 10/16/2013 02:05 PM, Ben Finney wrote:
> Thomas Goirand  writes:
> 
>> On 10/15/2013 06:21 PM, Tristan Seligmann wrote:
>>> What sort of upstream "source code" would be using the /usr/bin
>>> wrapper at all? (I ask this question without prejudice; I can
>>> obviously imagine some ways this might happen, but I'm more
>>> interested in the actual existing use cases that you implied, not
>>> ones that only exist in my imagination)
>>
>> I'm not sure if you're talking about the *full path* bit or what.
>> Upstream code (or at least, unit tests...) is calling "coverage" from
>> the standard accessible $PATH.
> 
> If some upstream code is making many invocations of one command with a
> hard-coded name, that's an argument to work with upstream and ask them
> to parameterise their code better (and patch it until they do), so
> OS packagers can easily alter the invocations to match OS-specific
> command locations.

I think you didn't get what I was trying to explain, so I'll try again.

I didn't wrote a single upstream project uses "coverage" in multiple
places. If it was the case, indeed it would be a problem in that one
upstream project, and it wouldn't be reasonable to change the Debian
package for *one* upstream project.

What I wrote is that multiple project does. That's very different. In
the former case, you have to convince a vast number of upstream, with
multiple types of answer, ranging from "sure, give me 5 minutes and I
fix this", to "I don't care, get off my bug tracker" type of answer.
Multiply this by a non-negligible amount of project, and you get a good
picture of why I think it could be very painful.

> In which vein, you've motivated me to raise an issue for this problem
> upstream https://bitbucket.org/ned/coveragepy/issue/272/> with the
> Python Coverage library maintainer, to argue for addressing the cause of
> the problem. Thanks!

Awesome! If upstream fixes it, then downstream projects will be forced
to follow. Let's hope it works. Thanks for doing this.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e4453.40...@debian.org

Re: Best practice: .egg-info with pybuild from git

[Thomas Goirand]

On 11/21/2013 08:28 PM, Mathias Behrle wrote:
> So finally I would appreciate any input on
> 
> 1) Which is the preferred procedure to handle .egg-info directories together
>with building from git?
> 
> 2) Is there a way to satisfy all common build tools as debuild,
>git-buildpackage, pbuilder, when running the build more than once?
> 
> Thanks,
> Mathias

Hi Mathias,

Thanks for raising this important topic.

I've seen all sorts of ways to fix this problem. What I found the most
easy was to simply add:

extend-diff-ignore = "^[^/]*[.]egg-info/"

in debian/source/options. That's just a one liner, and it solves all
problems. I've found this in a package, and I now use it. Probably
there's a better regular expression, I didn't investigate, though that
one above works well. Comments on it are welcome.

Does anyone have a counter-argument for (not) doing this?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/528e4909.3010...@debian.org

Re: Trim out Ubuntu entries in d/changelog?

[Thomas Goirand]

On 12/08/2013 03:04 AM, Barry Warsaw wrote:
> I've been working with gtimelog's upstream maintainer Marius, and with the
> permission of the old gtimelog Debian maintainers, have added it to PAPT.
> Please note that gtimelog was removed from Debian a while ago, but remained in
> Ubuntu, and now the plan is to add the latest upstream version back to
> Debian.  I've put myself as Maintainer and PAPT as uploaders.
> 
> Here's my question though: the d/changelog in PAPT svn has a bunch of entries
> from the times it was updated in Ubuntu ahead of Debian.  There's useful
> information in there, but I'm wondering if I should trim d/changelog to just
> the changes that occurred in Debian.  E.g. dropping everything between
> 0.0+svn88-3 (last squeeze version) to 0.9.1-1 which will be the new upload.
> OTOH, I suppose it doesn't hurt that much to keep all the Ubuntu changelog
> entries in the file.
> 
> Anybody have strong opinions either way?
> 
> -Barry

My take on this is that what you are writing is a debian/changelog,
meaning that what you care here, is to have a log file of what is
changing in Debian. I mean, you don't care Ubuntu, Mint, or whatever,
you really want to document what has happened in Debian, and have your
debian/changelog match the revisions that can be seen in the PTS.

If there are changes that have happened in Ubuntu, then it's a very good
idea to list them in your debian/changelog if you import these changes.
However, I would consider bad practice if this means putting them in
changelog entries for versions which never were in Debian. So you
shouldn't just copy some entries for revisions that have never been in
Debian (because that will not reflect the reality of the package), but
probably put them all in a single changelog entry.

In this specific case, I would suggest that you write something like this:

* Reintroduce the package after it was removed from Debian.
* Import Ubuntu changes which happened there when the package was removed:
  - Whatever ...
  - Whatever ...

What I wrote as "Whatever" can be an exact copy of what you have found
in the Ubuntu debian/changelog file, and you can even reference dates
and Ubuntu package release numbers if you like. So, something like:

  - [release 1.2.3-4, 2013-01-02] Whatever ...

Of course, the above is what *I* would do, and there's no Debian policy
regarding this. Though I think it does make sense.

Your thoughts?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a3de3d.3040...@debian.org

python-networkx 1.8 in Sid

[Thomas Goirand]

Hi Sandro,

I've seen that you've prepared a new version of python-networkx in our
SVN. What is holding you from uploading to Sid? I've noticed that the
last commit was from the 4th of august. Do you lack time working on the
package? Can I do the work and upload the package to Sid?

Let me know,
Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bc0b97.7030...@debian.org

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

[Thomas Goirand]

On 12/17/2013 01:02 AM, Barry Warsaw wrote:
> [...]
>   You'll want to have at least the following build dependencies:
>   
>* debhelper (>= 8)
> -  * dh-python
>* python-all (>= 2.6.6-3~)
>* python-setuptools
>* python3-all
>* python3-setuptools

Hi,

Just reacting on the above change. It's my understanding that we do need
to add dh-python explicitly if we want clean backports (eg: unchanged
from Sid). Am I right? If that's the case, shouldn't we advise to write
dh-python explicitly for until Jessie is released?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bd95f6.70...@debian.org

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

[Thomas Goirand]

On 12/28/2013 01:00 AM, Dimitri John Ledkov wrote:
> OK, I'm sorry.
> 
> What does it mean a "clean backport" vs other type of backports?
> dh-python is in backports, so no changes are required to backport
> packages build-depending on dh-python. Is that not clean enough?

I think you somehow misunderstood me. Let me try to expand in a longer
message then.

python3 depends on dh-python. As much as I can see, that's the only
package with a direct dependency on dh-python. Therefore, for Jessie, it
is perfectly valid to omit dh-python in build-depends, as long as your
package build-depends on python3.

However, if we want to backport a package to Wheezy, and that package is
using pybuild, then it needs an explicit build-depends on dh-python,
because in Wheezy, there's no dh-python, and python3 doesn't depend on
it. Therefore, to facilitate backports to Wheezy, I think it is nice to
just leave the dh-python as explicit dependency in new packages, at
least for until we have released Jessie.

What I called "clean backports" was just a backport to Wheezy with
unmodified source package (just a rebuild without modification). I think
it is a good thing to make it possible for ourselves to do easy
backports this way. It is also a good thing to make it possible for our
users to backport packages to Wheezy themselves without too much hassle,
even if the package isn't officially in backports.

So, yes, we don't explicitly need dh-python for Jessie if we have
python3 as build-depends, but IMO it is nice to do so.

On 12/27/2013 11:18 PM, Dimitri John Ledkov wrote:
> I don't understand why are you insisting on blocking migrations to
> dh-python. Is there some non-Debian requirement that you are omitting
> / not-telling here?

I absolutely don't want to block any migration to dh-python. Quite the
opposite, I think it's great that we don't have to manually do stuff to
support python3, and I am very happy that this part has been automated
by pybuild. I do not know enough pybuild (which is very new, so I think
that's normal), but working on a few package maintained by Piotr, I like
what I saw about it. Packages supporting both Python 2.x and Python 3
have a very short debian/rules, which is a very good thing.

As for the "omitting / not-telling" part here, I'm not sure what you are
referring to. Maybe the fact that I do maintain unofficial backports of
a lot of python modules in order to have OpenStack to work in Wheezy?
Well, if that's what you are thinking about, my opinion is that it is a
good thing if someone cares about doing easy backports, and even do some
work in Sid to make them more easy. I would love to make this happen
through the official backports of Debian, however because of the amount
of packages, and the difficulty to have them all migrated to testing, I
don't think this is technically possible in good conditions. Like many
others, I am hoping for the Debian PPAMAIN repositories to be available
to start doing that. That's the only way, or we'd have to change the
backports policy, which I don't see happening anytime soon. Thoughts on
this would be very much welcome!

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52be6f61.1010...@debian.org

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

[Thomas Goirand]

On 12/28/2013 10:47 PM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-12-28]
>> python3 depends on dh-python. As much as I can see, that's the only
>> package with a direct dependency on dh-python. Therefore, for Jessie, it
>> is perfectly valid to omit dh-python in build-depends, as long as your
>> package build-depends on python3.
> 
> please don't do that, though. python3 depends on dh-python only because
> dh_python3 is now provided by dh-python. dh-python dependency will be
> removed from python3 at some point.

Ok, so I was right to say that the removed dh-python line from the wiki
was wrong then. Thanks for confirming this.

Also, pastedeploy is currently wrong and misses the dh-python
build-depends, which is what me think it was probably correct to omit it
if we had a python3 build-depends (since you worked out this package
Piotr, and I trusted your work). It turns out it's a problem in the
current package. May I correct the package and upload the fix?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bfdd48.8010...@debian.org

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

[Thomas Goirand]

On 01/14/2014 09:24 PM, Alexandre Rossi wrote:
> I also found out that some packages maintained
> by the team are hosted on alioth in collab-maint (src: bugz,
> dajaxice).

Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable, predicted, and unavoidable.

In fact, using collab-maint is something that I would advise right now
if nothing moves in this team.

On 01/14/2014 09:55 PM, Piotr Ożarowski wrote:
> I reported bug reports, thanks

Why doing this? It doesn't make sense. It seems obvious to me that the
person using collab-maint do want to use Git. Don't force them back to
SVN please, it wouldn't be nice to them, especially if our plan is to
migrate away from it at some point. I don't see this as a bug, I see it
as a problem in the Python team, unless the Git repo is reactivated, and
the person who deactivated it doesn't do it again.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> I need to spend more time playing with git-bp, but last time I looked at it
> (cannot remember which package), I had a lot of trouble unless the package
> repo was organized Just Right.  One nice thing about svn-bp is that it pretty
> much just works with a checked out working directory, even when you have local
> uncommitted changes (--svn-ignore-new).

Probably you're not used enough with Git, because for what I'm doing,
"it pretty much just work with a checked out working directory" with Git
as well.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> git-bp OTOH required a specific set of branches inside the repo to
> stitch everything together and if those were missing, it failed
> miserably.

It all depends how you do it. If you base your Git packaging on tags,
and not using branches, which means having a debian/gbp.conf that
configures this, then it's really strait forward.

On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> I've mostly made my peace with git, so in theory I wouldn't be
> opposed to the team switching

There's been a vote that we should switch already. I don't think it's a
good idea to express oneself about liking or not Git: we agreed we
should switch to it.

>, but I still think it's not a good idea
> to have some team packages in git and the bulk in svn.  I value the
> ability to use the same tools and workflows for all team maintained
> packages.

Now, this could be back on the table: it's been months that we've talked
about it, and nothing is happening, because nobody has time. So the only
way I see to switch is to do it slowly, having both SVN and Git for some
time. Other teams have reported that it worked for them, so I don't see
why it wouldn't for python modules.

By the way, something like "mr" (from Joey Hess) could help regarding
mass commits.

On 01/14/2014 11:09 PM, Hans-Christoph Steiner wrote:
> I'm a fan of a gradual transition like this, with people switching or
> setting up git repos as they can.

I'm not a "fan" of it (it'd be IMO better to completely switch), but I
don't see any other practical way to move forward right now.

On 01/14/2014 11:51 PM, Olivier Berger wrote:
> It more or less requires only 2 branches : upstream (when you
> want to track upstream sources) and master (or debian) for the
> packaging source.

Hum... I'd say that *your workflow* requires it, but git-buildpackage
itself doesn't. You don't have to do this way. Everything can be
contained in a single branch if you use tags. Also, if you don't use
tags, and prefer to use upstream tarballs, then I think you're much
better off using pristine tar (and git-import-orig).

Also, I don't like using "debian" and "master" for branch names. These
express nothing. It's much better to use "unstable-debian" and
"upstream-debian" for example.

As a reference, here's a debian/gbp.conf for tags:
[DEFAULT]
debian-branch = debian/unstable
upstream-tag = %(version)s

And here's one for pristine-tar:
[DEFAULT]
upstream-branch = upstream-unstable
debian-branch = debian-unstable
pristine-tar = True

I also always add in my debian/gbp.conf:
[git-buildpackage]
export-dir = ../build-area/

to make sure no contributors dirties the git with build files (yes, you
can do that in your ~/.gbp.conf, and the system configuration file in
/etc, but the point here is to make sure *everyone* uses the build-area).

Thomas

[1] I know who it is, though I don't think it is useful to tell who.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df4045.6080...@debian.org

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

[Thomas Goirand]

On 01/22/2014 12:24 PM, Barry Warsaw wrote:
> Do you really think that it's unfeasible for git proponents on this team to
> find the necessary resources to plan an orderly en mass transition?  It might
> indeed be so, we're all busy.  But let's hopefully all agree that the end goal
> is to have all team-maintained packages in the same vcs.

I can't answer this question, as I can't speak for the others, and I
don't have time myself.

> So let's say we have to move packages slowly.  I want to make sure there's a
> team commitment (and especially from the git proponents) that we'll have a
> deadline at which all remaining packages will be switched.  I *really* want to
> avoid the typical long tail where packages just linger under svn and bit rot.
> (E.g. long tail conversions to dh_python2.)

Well, if we decide to move slowly things to Git, then the packages that
will stay in the SVN repo will be those largely unmaintained...

> So I would be in favor of an experiment. Pick 5 packages that are
> representative of team packages, that can be updated and uploaded by anyone on
> the team, and that see regular but not too often new upstream releases.  I'd
> happily volunteer one of my packages if that helps.

Well, if the team decides to move to Git, then I would put *ALL* of the
python module packages I maintain for OpenStack directly within the
DPMT. That's a consequent list of about 50 python modules:

http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

The only reason they are maintained within the OpenStack team is because
I don't want to be forced to use SVN, and I think it's safer than in
collab-maint where so many people have commit access (which means they
can rm -rf...).

> The most important thing though is to *document* in detail *on the wiki* how
> to work with those packages in git.

I agree that documenting the workflow is very important. I have
described my workflow here for OpenStack:
http://openstack.alioth.debian.org/

I wish to continue using this git based workflow whenever possible, and
use the pristine-tar workflow when there's no upstream git.

> Be opinionated, like the way we are with
> the LibraryStyleGuide.  Don't worry if others disagree with you - we can hash
> out best practices in this mailing list over time, but it's really important
> to put a stake in the ground.  If you can't decide which of two ways is
> better, do one package one way and another the other way.

I do believe in freedom as well! :)

> On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote:
>> Yes, because someone found it useful to disable the git area in the team
>> repo on Alioth [1] !!! And this drove people to collab-maint. This was
>> predictable, predicted, and unavoidable.
> 
> I don't know if my proposed experiment means re-enabling git on the team repo

I believe it does.

> or doing the experiment on collab-maint.

Any non-DD will have to request for access to collab-maint. This is
unnecessary, potentially dangerous, and administratively heavy to do that.

> But then my question is: how closely does your vision of the team git repo
> overlap with general Debian initiatives like dgit and source branches?  It
> might be nice if they align rather closely.

I don't think this is related. I see dgit as a tool to use only if the
package isn't maintained using Git...

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52df7328.8040...@debian.org

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

[Thomas Goirand]

On 01/22/2014 07:39 PM, Matthias Klose wrote:
> Am 22.01.2014 08:28, schrieb Thomas Goirand:
>> On 01/22/2014 12:24 PM, Barry Warsaw wrote:
>>> Do you really think that it's unfeasible for git proponents on this team to
>>> find the necessary resources to plan an orderly en mass transition?  It 
>>> might
>>> indeed be so, we're all busy.  But let's hopefully all agree that the end 
>>> goal
>>> is to have all team-maintained packages in the same vcs.
>>
>> I can't answer this question, as I can't speak for the others, and I
>> don't have time myself.
> 
> sure, so you are proposing something which you don't want to finish, just
> pursuing a rather selfish interest of using git yourself.  You did try this 
> with
> the debian-java team as well.

I don't think so. I don't maintain any Java package.

>> Well, if we decide to move slowly things to Git, then the packages that
>> will stay in the SVN repo will be those largely unmaintained...
> 
> and these will be magically maintained when converted to Git?

I guess, not more than with SVN...

> please don't be silly.

I don't think I have. You are making wrong assumptions here, I believe.

> unmaintained packages are not a property of the used VCS.

Agreed!!!

> And you said
> you don't have time to spend on these yourself.
> 
>> http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
>>
>> The only reason they are maintained within the OpenStack team is because
>> I don't want to be forced to use SVN, and I think it's safer than in
>> collab-maint where so many people have commit access (which means they
>> can rm -rf...).
> 
> apparently these were first needed for openstack. so it seems to make sense to
> maintain these over there.

That's truth only for a subset of them, not all of them. Many are of
general purpose.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dfca83.7020...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

On 01/25/2014 06:01 PM, Sandro Tosi wrote:
> Sorry, what? and you didn't think to contact me first to almost
> rewrite the package? If there's problems, open bugs. Revert your
> changes or I'll do at the first occasion. and mainly, why don't you go
> away from DPMT once and for all? you're doing more harm than good
> here. you're not welcome here.

Shortly to the list:

This kind of message saddens me. I'm not expecting this kind of
interaction, but rather:

"thanks for fixing that, however there, you shouldn't have done this,
plus let me revert and fix that bit better"

Maybe you could try this style and really do team work if your package
is team maintained, no?

Thomas

P.S: Sent a much much larger mail privately explaining the context of
this upload.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e3da27.2050...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

bian/copyright, and things like this.

> without caring to
> understand if that's ok with who maintainer (that far).

The maintainer for this package is: Debian Python Modules Team.

I'm part of that team, last time I checked, so that's fine. Remove the
team if you do not agree.

> it is not the first time your interactions with DMPT or its team
> members has been problematic (if you need a hint, think about all the
> problems your fanatism to GIT has generated): maybe it's you that
> should rethink how you interact with the team and stop imposing your
> way.

Ah ... So I've been *imposing* git? Are you sure of this? That's a very
interesting view. You see, from my viewpoint, I'm only trying to
convince a small (but very vocal and active) resistant to change
minority. Could you care to tell "problems" are you talking about? I'm
not aware of any until now. That you were bored reading me, at most?

Unfortunately, last time I checked, we're still using SVN, which
everyone else but about half a dozen member of this team think it's
something of the past, and which other teams have moved (or are in the
process of moving) away. Even a majority inside the team thinks we
should switch. The problem is just how. Also, I believe a vast majority
inside Debian also agrees with me that Git is better. Sticking to SVN
has, and will continue, to drive people away from the team (there's
numerous examples of this already, including these TEAM modules on
collab-maint). So, I really wonder who's doing fanaticism in this case.

Now, are you done calling me names? Please, let's focus on improving
Debian. We have better things to do than his...

Peace, love, flowers, etc.
Oh, and ... cheers!

Thomas Goirand (zigo)

[1] https://wiki.debian.org/Python/TransitionToDHPython2 has:
"The two traditionally popular Python helpers, python-support and
python-central have both been deprecated in favor of dh_python2."

So if someone do not agree with this, it should IMO be written
explicitly in this wiki page that it's actually not OK to convert things
to dh_python2. Also, probably we should switch everything to pybuild,
no? (and /me should learn more about it)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e4159d.9080...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

On 01/26/2014 04:29 AM, Jakub Wilk wrote:
> * Thomas Goirand , 2014-01-26, 03:50:
>> - No file shipped into /usr/lib/python2.x/dist-packages (well, 2.7 for
>> Sid, and 2.x if you consider an eventual backport). Now, I'm saying:
>> "sorry what?" like on your 1st mail. This breaks the package for
>> everybody (and not "only my case").
> 
> It has always worked for me. Now what?

Now, try this:

zigo@host # sudo dpkg -i python-concurrent.futures_2.1.6-1_all.deb
(Reading database ... 108371 files and directories currently installed.)
Preparing to unpack python-concurrent.futures_2.1.6-1_all.deb ...
Unpacking python-concurrent.futures (2.1.6-1) over (2.1.6-1) ...
Setting up python-concurrent.futures (2.1.6-1) ...
Processing triggers for python-support (1.0.15) ...
zigo@host # python
Python 2.7.6 (default, Jan 11 2014, 14:34:26)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import futures
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named futures

I'm however confused how "import concurrent" works, even if there's
nothing in /usr/lib/python2.7/dist-packages in this package. How come?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e4243c.2000...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

On 01/26/2014 01:21 AM, Sandro Tosi wrote:
>> if you don't want the package to be team maintained, perhaps take
>> it out of team maintenance?
> 
> lecturing is not required, thanks

Actually, it seems it's required here. From this page:
https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

on chapter "Policy About Maintainer and Uploaders Fields":

"There is a unwritten policy about the usage of Maintainer and Uploaders
field, you might be interested to know about:

If the team is in the Maintainer field (and you are in Uploaders field)
then every member of the team can apply changes to the package and
upload it freely;

if you are in the Maintainer field (and the team is in Uploaders field)
then every member of the team can apply changes to the package but any
upload should be acknowledged by you (there are some exceptions, like
uploads to fix RC bugs, but are infrequent)."

What is it that you don't understand in "the team can apply changes to
the package and upload it freely"?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e429ec.1090...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

Thanks for your comments Jakub,

On 01/26/2014 05:47 AM, Jakub Wilk wrote:
> $ PYTHONWARNINGS=d python -c 'import futures'
> /usr/lib/python2.7/dist-packages/futures/__init__.py:24:
> DeprecationWarning: The futures package has been deprecated. Use the
> concurrent.futures package instead.
>DeprecationWarning)
> 
> Surely you must have become aware of this fact when you removed the
> 10_dont_install_futures patch.

Well, that's really weird that the homepage of that said project
advertizes, as the first line of code example, to use "import futures".

I'll revert that then, and see if python-taskflow continues to work (and
if it does, I'll patch upstream code).

> Not shipping a deprecated and generically-named module, when there were
> no reverse-dependencies relying on its existence, sounds like a
> reasonable decision.

Sure!

>> I'm however confused how "import concurrent" works, even if there's
>> nothing in /usr/lib/python2.7/dist-packages in this package. How come?
> 
> That's how python-support works.

Oh ok. I have to admit I never really used it, since it was deprecated
for dh_python2 already when I first started to do python module packages.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e46965.3050...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

On 01/26/2014 05:52 AM, Andrew Starr-Bochicchio wrote:
> Also from Python Policy:
> 
>> > Modules managed by python-support are installed in another directory
>> > which is added to the sys.path using the .pth mechanism.
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths

Oh ok. Thanks! However, we shouldn't use python-support anymore, right?

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e469b6.40...@debian.org

Re: Making packaging Python modules fun again

[Thomas Goirand]

On 01/27/2014 11:23 PM, Matthias Klose wrote:
> Am 27.01.2014 00:14, schrieb Nicolas Dandrimont:
>> - Adding Python 3 support when upstream has it
> 
> I think this should make it into the python policy.
> 
>   Matthias

I agree.

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e6a1bb.4010...@debian.org

Re: Is python-django still maintained in DPMT svn?

[Thomas Goirand]

On 01/28/2014 10:03 PM, Barry Warsaw wrote:
> Cool.  I may also take a look at #736878 (Python 3 support).

This would be much much much appreciated if someone took care of that
one indeed! :)

And the sooner the better, so that reverse dependencies we maintain can
also support Python 3.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e7f7a2.8090...@debian.org

Re: Indeed, python-concurrent.futures is the same

[Thomas Goirand]

On 01/31/2014 03:20 PM, Vincent Bernat wrote:
> [...]
> 
> Sandro has orphaned python-concurrent.futures:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714
> 
> Since it is team maintained, I don't think it really makes sense. Should
> we just close the bug report and remove Sandro from the Uploaders field?

What doesn't make sense is to do this silently, after all this thread
and noise. Seems he didn't care about this package that much after all,
and that he's just pissed off. :(

I'm seriously sad by this. I'd prefer if everyone was on the same line
as Nicolas Dandrimont (thanks man for your message), and if all this was
fun.

I'll take over the package (already filled the ITA).

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f0c28c.3080...@debian.org

Re: python-future: clean single-source support for Python 2/3

[Thomas Goirand]

On 02/05/2014 06:04 AM, Brian May wrote:
> Hello,
> 
> Has anybody considered packaging python-future for Debian?
> 
> No, I am not talking about python-futures, python-concurrency.futures,
> or anything relating to #736523 (the first message in this bug had
> rather confused at first).
> 
> Rather I am talking about:
> 
> http://python-future.org/
> 
> "future is the missing compatibility layer between Python 2 and Python
> 3. It allows you to use a single, clean Python 3.x-compatible codebase
> to support both Python 2 and Python 3 with minimal overhead."
> 
> Unfortunately, Google now lists #736523 as the major search result, so I
> thought I would ask here to see if there is any interest.
> 
> Thanks
> -- 
> Brian May  >

Hi Brian,

Just a quick message to say sorry for being the source of this big
confusion between future and futures (with "s").

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f1f0c9.1040...@debian.org