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

[Sandro Tosi]

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.

On Sat, Jan 25, 2014 at 7:38 AM, Thomas Goirand  wrote:
> Hi,
>
> Indeed, that's the same source package.
>
> Indeed as well, there's lots of problems in the current package in
> Debian. The current maintainer, Sandro Tosi ,
> completely removes the "futures" API.
>
> As a consequence, there's no way for a normal package to use
> concurrent.futures correctly. I have been stuck on the python-taskflow
> for a long long time, not understanding what happened: it failed on most
> of it's unit tests (a bit less than 200 failed unit tests) because of
> this problem.
>
> Here's the problems I saw in the version 2.1.6-1 of the package in Sid:
>
> * python-concurrent.futures currently doesn't install itself at all
> inside /usr/lib/python2.7, which I don't think makes it possible to use
> it at all.
>
> * Surprisingly, there's a patch to *not* install the "futures" python
> module where upstream code is expecting it. I removed that.
>
> * the sphinx doc isn't handled correctly. There's was
> ${sphinxdoc:Depends}, so not correct dependencies. Sandro: lintian must
> have warned you about it, next time, please read the lintian report
> before uploading.
>
> * IMO, there's a missing Provides: python-futures, since that's what the
> dh_python2 is adding as depends: when I build python-taskflow.
>
> * the package is build-depending on python-support, which has been
> deprecated in the favor of dh_python2. Please see:
> https://wiki.debian.org/Python/TransitionToDHPython2
>
> Since the package is team maintained, I've fixed all these problems and
> just uploaded version 2.1.6-2 to Sid. I will ask for rejection of
> python-futures by the FTP masters.
>
> Cheers,
>
> Thomas Goirand (zigo)



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/cab4xwxxxcghdxadn9phj0sgs3ts0yw3snlnlvjd7ezl0cak...@mail.gmail.com

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

[Robert Collins]

On 25 January 2014 23:01, 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.

Huh? Thomas seemed to be doing the right thing per the DPMT standards
etc; if you don't want the package to be team maintained, perhaps take
it out of team maintenance?

-Rob


-- 
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/caj3hoz1o4gm8kakgz+ddxpxcshzoeqwvpa6kby04_1eeqqt...@mail.gmail.com

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

[Sandro Tosi]

> Huh? Thomas seemed to be doing the right thing per the DPMT standards
> etc;

if you change the python helper, you HAVE TO contact who's maintaining
the package and have they ack the change, that's the team standard.

> if you don't want the package to be team maintained, perhaps take
> it out of team maintenance?

lecturing is not required, thanks

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/CAB4XWXwK=+dd9-ztrdu55nkrpuewokflgwwbetuhu-tsgg6...@mail.gmail.com

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

[Thomas Kluyver]

On 25 Jan 2014 07:37, "Thomas Goirand"  wrote:
>
> 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?

I agree. Even if we don't have an explicit code of conduct, I think we
should expect more civil discourse. It sounds to me like Thomas G was
honestly trying to improve something, and disagreeing with how he did it
does not warrant a personal attack.

Thomas K

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

[Sandro Tosi]

> This kind of message saddens me.

the same holds for calling my packages as having "lots of problems"
(none of them ever being reported as bugs by any of the current users,
nor even by you) of accusing me of having done something without
thinking.

>  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"

and so I was expecting you to contact me *upfront* almost redoing the
packaging, and switching helper, but it did't come, did it?

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

"really do team work"? do you call your changes a "team work"? i
don't. teams talk, teams discuss, teams agree on a solution - you just
uploaded a package that fixes your problem without caring to
understand if that's ok with who maintainer (that far).

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.

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/cab4xwxzpzx7polafxg1oxdpkjnxeahpcoobp9rtyotdchvs...@mail.gmail.com

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

[Thomas Goirand]

Sandro,

I sent you a nice and long email explaining you the ins and outs of this
package, and why/how I did what I did. Now I think you've going really
too far, and crossed the line, IMO.

On 01/26/2014 01:57 AM, Sandro Tosi wrote:
>> This kind of message saddens me.
> 
> the same holds for calling my packages

Unless this changes:

Maintainer: Debian Python Modules Team


This is not "your package", but the one of the team. Again, remove the
team from the package if you do not expect this to happen.

> as having "lots of problems"

I really didn't want to do this in public, which is why I sent you a
private mail where I tried to be nice. Only there I may have used such
wording, which I'm not particularly proud of. I did re-read multiple
times to make sure it would read nicely, and I am sorry if it didn't
fully in all the bits of the message. Though now you're forcing me...

- No ${sphinxdoc:Depends} which means wrong dependencies for the doc.
I'd call it a minor issue.

- Unexpected removal of upstream API module "futures" that isn't even
documented in a README or something, and that broke reverse-dependency.

- Then (and it goes together), no support for the "futures" as module
name, package called "concurrent.futures" which is breaking the python
policy (and forces the use of pydist-overrides). On this page:
https://code.google.com/p/pythonfutures/
I can read: "import futures" as the first line of the example code
snippet, though this didn't work with the package.

- 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").

If that's not "lots of problems", how do you call this?

> (none of them ever being reported as bugs by any of the current users,
> nor even by you)

Then what? The package is declared as team maintained.

My understanding of the way the team should work, is that we don't have
to go through the cir-convolution of the BTS, wait for the maintainer to
wake up, discuss everything, etc. which is a very inefficient way of
improving the packages. Do you have another reading?

> of accusing me of having done something without
> thinking.

I haven't accused you of doing anything. And even though now it's
tempting to comment on your attitude, I will refrain from such
anti-social behavior, in the hope we restore a good atmosphere.

>> "thanks for fixing that, however there, you shouldn't have done this,
>> plus let me revert and fix that bit better"
> 
> and so I was expecting you to contact me *upfront* almost redoing the
> packaging, and switching helper, but it did't come, did it?

Feel free to switch back to a helper which is [1] declared as
deprecated. Everything can be reverted, it's not a so big deal, and I
personally don't care that much if the package continues to work. Though
I don't think reverting to a deprecated helper will please everyone, and
I believe that this should be discuss, not with you, but with the rest
of the team!

>> Maybe you could try this style and really do team work if your package
>> is team maintained, no?
> 
> "really do team work"? do you call your changes a "team work"?

I do. Do the same kind of fixes on *any* of my packages (even the
non-team maintained ones), and I wont complain unless there's obvious
technical mistakes. Even if there was errors, I don't think I'll start a
flame war thread like you just did... I'm by the way on the low NMU
threshold, and I invite anyone to work toward improving Debian.

> i don't. teams talk, teams discuss, teams agree on a solution -

I probably should have get in touch yes. Though I don't think you should
be that harsh and start a flame war, plus call me fanatic, then asking
me to leave the team.

> you just uploaded a package that fixes your problem

I can't agree with this wording. I fixed the problems for everybody,
because the package wasn't useable by anyone it the state it was. If you
do not agree, please comment technically about the changes and tell
everyone here where I did such a huge mistake. I'll be happy to learn in
the process if I did some mistakes. Bonus point if you can quit your
current aggressive tone.

Also, we're all working improving Debian for our own specific issues,
with our own goal and perspectives in mind. Even if this was the case on
this package, and that it fixed only a problem for me, I don't see it as
an issue.

Also, if I cared only about my own problem, the patch would have been
smaller, and I wouldn't have fixed cosmetic stuff like the wrong Format:
field for the debian/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 tea

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

[Jakub Wilk]

* 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?

--
Jakub Wilk


--
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/20140125202944.ga18...@jwilk.net

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

[Jakub Wilk]

* Thomas Goirand , 2014-01-26, 04:53:
- 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


The "futures" module is deprecated upstream, and provided upstream only 
for backwards compatibility:


$ 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.


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


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.

--
Jakub Wilk


--
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/20140125214722.ga21...@jwilk.net

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

[Andrew Starr-Bochicchio]

On Sat, Jan 25, 2014 at 3:53 PM, Thomas Goirand  wrote:
> 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?

Take a look at /usr/share/doc/python-support/README.gz

>  * Public modules (.py files that should be installed in the default
>sys.path) are handled through a foo.public file, which contains a
>list of files to install. The files are normally installed in
>/usr/share/pyshared/. They will be installed and bytecompiled in each
>Python specific directory: /usr/lib/pymodules/pythonX.Y/. If the header
>of the foo.public file contains a "pyversions=..." field, it will be
>parsed for the list of python versions the module supports. It should
>look like e.g.:
> 2.2,2.4-
>for a package supporting python2.2, and all versions starting from
>python2.4.

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


-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_AxQmuEtOgqV2u38D9P=98baja+esrs-mcfagnk3obj...@mail.gmail.com

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: Indeed, python-concurrent.futures is the same

[Dimitri John Ledkov]

On 25 January 2014 17:21, Sandro Tosi  wrote:
>> Huh? Thomas seemed to be doing the right thing per the DPMT standards
>> etc;
>
> if you change the python helper, you HAVE TO contact who's maintaining
> the package and have they ack the change, that's the team standard.
>

No, one does not within python apps/module teams. It's not the first
time when you are over-reacting to team changes in a very
aggressive/abusive manner.
Honestly, nobody is trying to purposely cause harm to debian packages.

>> if you don't want the package to be team maintained, perhaps take
>> it out of team maintenance?
>
> lecturing is not required, thanks
>

This is not a lecture. You clearly have "maintainer - team" balance
swayed way to the maintainer-mandated side of things, which is not
shared with anyone else in the debian apps/modules team.

I do not share your view that "Thomas Goirand is not welcomed here."
on the contrary, the Debian Project welcomes and encourages
participation by everyone. We welcome contributions from everyone as
long as they interact constructively. When packages that you declared
are maintained within the team are touched, at times (and this is not
the first time), you demand post-factum that you should have been
exclusively consulted first and you demand or threaten for all changes
to be reverted. This is not constructive interaction within python
apps/modules teams, nor wider Debian Project.

Regards,

Dimitri.


-- 
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/CANBHLUhGR=jkplvio8njsa0r_acekkukvg7bmwrjjkdyg6q...@mail.gmail.com

Set shebang line to default (instead of latest) Python 3 interpreter

[Ben Finney]

Howdy all,

How can I convince ‘dh_python3’ to set the shebang to the *default*
Python 3 interpreter?

The way the ‘dh_python3’ tool works (by default?), it will write the
shebang with the full “/usr/bin/python3.X” where “3.X” is whichever
version of Python was used to invoke the install.

For bug#736121 http://bugs.debian.org/736121> I need to convince
the Debian packaging to create a program whose shebang has
‘/usr/bin/python3’, or in some other way get the default Python 3.

The behaviour of ‘dh_python3’ in this regard is pretty hard to follow,
even when I read the source. How can I convince it to use a specific
Python version, or the default Python 3 version, or even a specific
shebang, for writing one particular program?

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\   so, Brain, but ‘apply North Pole’ to what?” —_Pinky and The |
_o__)   Brain_ |
Ben Finney


-- 
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/858uu3ff9r@benfinney.id.au