Re: Indeed, python-concurrent.futures is the same
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: Indeed, python-concurrent.futures is the same
On Tue, Feb 04, 2014 at 06:35:56PM +0800, Thomas Goirand 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. To not make more noise. Seems he didn't care about this package that much after all, and that he's just pissed off. :( Sometimes it's easier to give up. -- WBR, wRAR -- 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/20140204103915.ga5...@belkar.wrar.name
Re: Indeed, python-concurrent.futures is the same
* Vincent Bernat ber...@debian.org, 2014-01-31, 08:20: 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. Given that he was the only uploader, this makes perfect sense. Should we just close the bug report and remove Sandro from the Uploaders field? No. Policy §5.6.3 reads “if the ‘Maintainer’ control field names a group of people and a shared email address, the ‘Uploaders’ field must be present and must contain at least one human with their personal email address.” -- 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/20140131085508.ga3...@jwilk.net
Re: Indeed, python-concurrent.futures is the same
[Vincent Bernat, 2014-01-31] Sandro has orphaned python-concurrent.futures: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714 sorry to see that, unfortunately people who do something also have to have thick skin to ignore people who talk much 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? orphaning does make sense, packages without human in Maintainer or Uploaders fields are not allowed -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20140131100543.gu4...@sts0.p1otr.com
Re: Indeed, python-concurrent.futures is the same
2014-01-26 Barry Warsaw ba...@debian.org: I do think we should be switching all team maintained packages to dh_py2 and finally getting rid of py-support and py-central (!). python-central is no longer a problem, see #717091 :) -- 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/cadk7b0py1ee3dakklzdgtesd16hybi2ob+jqrwcuy5d6-kw...@mail.gmail.com
Re: Indeed, python-concurrent.futures is the same
Excerpts from Piotr Ożarowski's message of 2014-01-31 02:05:43 -0800: [Vincent Bernat, 2014-01-31] Sandro has orphaned python-concurrent.futures: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714 sorry to see that, unfortunately people who do something also have to have thick skin to ignore people who talk much 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? orphaning does make sense, packages without human in Maintainer or Uploaders fields are not allowed I would hope that a team member would feel that the team would be the first place to turn to, rather than orphaning it on the bug tracker. :-/ -- 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/1391200052-sup-8...@fewbar.com
Re: Indeed, python-concurrent.futures is the same
[...] 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? -- panic(Oh boy, that early out of memory?); 2.2.16 /usr/src/linux/arch/mips/mm/init.c -- 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/87r47oobvq@guybrush.luffy.cx
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On 2014-01-27 at 00:14:12 +0100, Nicolas Dandrimont wrote: It has been a while since I have been meaning to post a message like this. I Thanks for writing this - Be more welcoming to newcomers. I think that the proof of previous work policy is a hurdle that we would be better off without. The worst that could happen is that someone starts packaging something and then the package languishes in svn. I don't know about this: in my case the proof of previous work was just a package submitted on mentors, and it was my first package for debian ever, still not in a great shape, not a big hurdle. On the other hand, having to declare which packages you intend to work on when joining the team is probably helping maintaing the idea that you should only look at your own things and not dare touch anything else. -- Elena ``of Valhalla'' -- 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/20140127102313.gb2...@virginsteele.home.trueelena.org
Re: Indeed, python-concurrent.futures is the same
❦ 26 janvier 2014 02:49 CET, Thomas Goirand z...@debian.org : 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? As it is deprecated, I agree that it is a good step to convert a team-maintained package to another helper. I think Thomas' changes were done in good faith. It is not like he has repeteadly tried to modify the package against Sandro's will. -- Don't diddle code to make it faster - find a better algorithm. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Indeed, python-concurrent.futures is the same
On Jan 26, 2014, at 03:50 AM, Thomas Goirand wrote:
[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)
I do think we should be switching all team maintained packages to dh_py2 and
finally getting rid of py-support and py-central (!). For the sake of
consistency, I'd love to see the latter two just disappear completely, but at
least we here can work toward modernizing team packages to the newer helper.
The use of dh_py2 is a nice parallel with dh_py3, which is the only helper for
Python 3. pybuild doesn't eliminate the use of dh_py2 and dh_py3, it's just
built on top of them and makes supporting bilingual libraries usually really
easy. I'd personally like to see all of our Py 2/3 compatible libraries use
it if possible.
That having been said, if DPMT is in maintainers, I'd say it's a courtesy but
not requirement to file a bug, and then contact the maintainer about the
proposed packaging changes. Wait a reasonable amount of time, attach a patch,
and see if you can have a conversation about it. If DPMT is in uploaders but
not maintainers, then I think the requirement to contact the maintainer is
stronger, but I'm not sure it should be *so* strong as to prevent other team
members from making packaging changes. Maybe require contact with maintainer,
and a longer waiting period, with a little more deference to the maintainer's
preferences?
In any case, an email to this list saying I want to change package foo to use
pybuild and dhpy2/3 from python-{support,central}, and here's the patch
probably wouldn't hurt.
Cheers,
-Barry
--
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/20140126132438.034d7e61@anarchist
Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
* Barry Warsaw ba...@debian.org [2014-01-26 13:24:38 -0800]:
I do think we should be switching all team maintained packages to dh_py2 and
finally getting rid of py-support and py-central (!). For the sake of
consistency, I'd love to see the latter two just disappear completely, but at
least we here can work toward modernizing team packages to the newer helper.
The use of dh_py2 is a nice parallel with dh_py3, which is the only helper for
Python 3. pybuild doesn't eliminate the use of dh_py2 and dh_py3, it's just
built on top of them and makes supporting bilingual libraries usually really
easy. I'd personally like to see all of our Py 2/3 compatible libraries use
it if possible.
Ditto.
That having been said, if DPMT is in maintainers, I'd say it's a courtesy but
not requirement to file a bug, and then contact the maintainer about the
proposed packaging changes. Wait a reasonable amount of time, attach a patch,
and see if you can have a conversation about it. If DPMT is in uploaders but
not maintainers, then I think the requirement to contact the maintainer is
stronger, but I'm not sure it should be *so* strong as to prevent other team
members from making packaging changes. Maybe require contact with maintainer,
and a longer waiting period, with a little more deference to the maintainer's
preferences?
In any case, an email to this list saying I want to change package foo to use
pybuild and dhpy2/3 from python-{support,central}, and here's the patch
probably wouldn't hurt.
I am strongly of the opinion that the DPMT should be a team, not just a SVN
repository with random packages and a mailing-list where people shout at each
other when they dare touch those packages.
This continuing atmosphere of fear, and the constant bad faith accusations,
make it really hard to work in the team efficiently, and all of this makes the
Python ecosystem in Debian weaker, as some packages which would be relevant for
the team go to collab-maint or other teams instead, and therefore do not get
the level of care and/or expertise they would get otherwise.
It has been a while since I have been meaning to post a message like this. I
have been following the work of the Perl team for a while now and this is
obviously the gold standard we should strive for. Here's a short
TODO-kind-of-list (in no specific order) for making Python module maintenance
in DPMT fun again:
- Kill the meme that people own their packages when the team is in the
maintainer field.
- Dust off the team's PET instance ([1], which looks rather outdated).
- Only have one sponsorship queue. I think the VCS is the obvious place where
that queue should be. PET allows you to list the packages ready for upload
(i.e. packages where debian/changelog says that an upload is ready). When a
reviewer thinks a package is not fit for upload, just unreleases and adds
TODO
items to d/changelog, so that the sponsoree knows what to do.
- Be more welcoming to newcomers. I think that the proof of previous work
policy is a hurdle that we would be better off without. The worst that could
happen is that someone starts packaging something and then the package
languishes in svn. If we get some tools to help ourselves manage our packages
(and I honestly think PET is that tool), then I don't see what's next.
- Amend the Python Modules policy to stop mentioning deprecated helpers.
- Get rid of python-support.
- Try to standardize on pybuild instead of cargo-culting debian/rules.
- Adding Python 3 support when upstream has it, or even contributing it
upstream.
- Getting rid of Python 2 in standard installs (that work is well underway
AIUI).
- General package gardening (bugfixes, upstream updates, merging ubuntu
changes, unused package removals ...)
(I'm afraid to put this in here, as it's mostly a matter of taste, but)
- Migration to a more modern VCS. A few weeks back, I started to toy around
with svn-all-fast-export on the DPMT repo. I had to lightly patch it to do
what I wanted it to do, but the result is up on alioth[2]. It's a first take
at
the issue, and there are a lot of kinks to work out. The scripts I used are
available[3] for scrutiny. Please don't take this as an occasion to rehash
the
same arguments all over again: just talk if you want to take this further.
Obviously all of this means work. I'd be glad to put my money where my mouth is
on some of those tasks if there is general consensus that they would be useful
things to work on. For instance, as a first task, I'd be happy to do whatever
is necessary to get our PET instance to work again, as this is a valuable tool
to manage the number of packages we have to.
I'll probably be a bit busy this week as I have a FOSDEM talk to prepare.
However, I'm pretty much always around on IRC and, well, I'll be in Brussels
this week-end so if some of you happen to be here too you can hit me up and we
can discuss all of this around a
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On 26 Jan 2014 16:33, Paul Tagliamonte paul...@debian.org wrote: On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Ditto - I agree with just about everything Nicolas said. I'd love to see this become a cooperative and welcoming team. Thomas
Re: Indeed, python-concurrent.futures is the same
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 z...@debian.org 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 mo...@debian.org,
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
On 25 January 2014 23:01, Sandro Tosi mo...@debian.org 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
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
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
On 25 Jan 2014 07:37, Thomas Goirand z...@debian.org 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
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
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
python-modules-t...@lists.alioth.debian.org
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 team
Re: Indeed, python-concurrent.futures is the same
* Thomas Goirand z...@debian.org, 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
On 01/26/2014 04:29 AM, Jakub Wilk wrote: * Thomas Goirand z...@debian.org, 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 stdin, line 1, in module 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
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 z...@debian.org, 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 stdin, line 1, in module 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
On Sat, Jan 25, 2014 at 3:53 PM, Thomas Goirand z...@debian.org 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 https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb 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
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
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
On 25 January 2014 17:21, Sandro Tosi mo...@debian.org 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
