On 8 October 2015 at 18:57, Brian May wrote:
>
>
> On Thu, 8 Oct 2015 at 08:12 Brian May
> wrote:
>>
>>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build;
>>python3.5 -m unittest discover -v
>>ajax_select (unittest.loader._FailedTest) ... ERROR
>>
>
> On second though
On Thu, 8 Oct 2015 at 08:12 Brian May
wrote:
>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build;
>python3.5 -m unittest discover -v
>ajax_select (unittest.loader._FailedTest) ... ERROR
>
>
On second thoughts, wonder what tests it is running. I can't see anything
that
On Oct 07, 2015, at 05:06 PM, Barry Warsaw wrote:
>It will be gmane.comp.python.linux-sig
The newsgroup is live and they named it gmane.comp.python.linux
Cheers,
-Barry
pgpuNgEFo1i8B.pgp
Description: OpenPGP digital signature
On 8 October 2015 at 12:05, Ben Finney wrote:
> Robert Collins writes:
>
>> On 8 October 2015 at 11:47, Ben Finney wrote:
>> > If you have a code base that is intended to run unchanged on Python
>> > 2 and Python 3, and that code base imports ‘unittest2’, you need
>> > both the Python 2 and Pyth
Robert Collins writes:
> On 8 October 2015 at 11:47, Ben Finney wrote:
> > If you have a code base that is intended to run unchanged on Python
> > 2 and Python 3, and that code base imports ‘unittest2’, you need
> > both the Python 2 and Python 3 version of that package.
> >
> > If your code bas
On 8 October 2015 at 11:26, Brian May wrote:
> On Thu, 8 Oct 2015 at 08:18 Robert Collins
> wrote:
>>
>> Probably the discover improvements in 3.5 try using python -m
>> unittest2.discover
>
>
> Just trying that now.
>
> I see that there is a python3-unittest2 package - should I be using that one
On 8 October 2015 at 11:47, Ben Finney wrote:
> Brian May writes:
>
>> I see that there is a python3-unittest2 package - should I be using that
>> one or the unittest built in Python 3.5?
>
> If you have a code base that is intended to run unchanged on Python 2
> and Python 3, and that code base
Brian May writes:
> I see that there is a python3-unittest2 package - should I be using that
> one or the unittest built in Python 3.5?
If you have a code base that is intended to run unchanged on Python 2
and Python 3, and that code base imports ‘unittest2’, you need both the
Python 2 and Pytho
On Thu, 8 Oct 2015 at 08:18 Robert Collins
wrote:
> Probably the discover improvements in 3.5 try using python -m
> unittest2.discover
>
Just trying that now.
I see that there is a python3-unittest2 package - should I be using that
one or the unittest built in Python 3.5?
Thanks for the feedback. I did rewrite this a little bit, so hopefully it's
clearer. I left some of the text in there because at least to me it reads
better and provides some rationale for why the rules are there. But hey, it's
a wiki so please feel free to make further improvements!
Cheers,
-B
[Brian May, 2015-10-07]
> > Probably... Now, I've followed your orders not to use Git, General
> > Piotr, so why complaining again?!?
> >
>
> Unfortunately, terms like "General Piotr" start looking like personal
> attacks; not going to help your arguments.
I take it as a compliment (it's a high r
On Thu, 8 Oct 2015 at 00:32 Thomas Goirand wrote:
> You've only enforced *your own* policy, backed-up by only a small vocal
> minority, taking the rule to the extreme (ie: a few days before the Git
> migration, it's still not ok to start new projects using Git, according
> to you...).
>
Accordin
[Debian Wiki, 2015-10-07]
> https://wiki.debian.org/Python/LibraryStyleGuide?action=diff&rev1=64&rev2=65
>
>
> == Gotchas ==
>
> + === Executables and library packages ===
> +
> + Let's say you have a Python package which results in Python 2 and 3
> libraries, and a Python 3 executable.
Probably the discover improvements in 3.5 try using python -m
unittest2.discover
On 8 Oct 2015 10:12, "Brian May" wrote:
> Hello,
>
> When debugging #801208, I noticed the following output:
>
>dh_auto_test -O--buildsystem=pybuild
>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_
Hello,
When debugging #801208, I noticed the following output:
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build;
python2.7 -m unittest discover -v
--
Ran 0
On Oct 08, 2015, at 07:32 AM, Ben Finney wrote:
>When you receive notification the group is created, please let that mailing
>list[0] know the GMane group name so its readers know where they can
>subscribe.
It will be gmane.comp.python.linux-sig
Cheers,
-Barry
Barry Warsaw writes:
> On Oct 08, 2015, at 05:34 AM, Ben Finney wrote:
>
> >Is it already available at GMane?
>
> It's been requested and acknowledged, and I resent a message to kick
> off creation of the newsgroup
Thank you! I'm confident the GMane admins will deal with it and the
group will ap
On Oct 08, 2015, at 05:34 AM, Ben Finney wrote:
>Is it already available at GMane?
It's been requested and acknowledged, and I resent a message to kick off
creation of the newsgroup, but I don't see it there yet and the gmane.org
website seems offline for me atm.
Cheers,
-Barry
Barry Warsaw writes:
> In the upstream Python project, we recently created a new mailing list as a
> focal point for cross-distro Linux-specific issues. I invite all interested
> folks to join and help make Python better on Linux.
>
> https://mail.python.org/mailman/listinfo/linux-sig
>
> Feel f
On Wed, 07 Oct 2015, Piotr Ożarowski wrote:
> I assume you all like other ideas, like no team in Maintainer, right?
While I understand the desire to have one identified maintainer for each
package, I don't agree with the rule.
Changing maintainer means changing the flow of information and it is a
On Oct 07 2015, Piotr Ożarowski wrote:
> I no longer think requiring contribution (the 3 months thing) is a good
> idea for DPMT (might be for a new team).
>
> I assume you all like other ideas, like no team in Maintainer, right?
>
> * team only in Uploaders field, the main contact (AKA Maintainer
On Oct 07, 2015, at 04:08 PM, Piotr Ożarowski wrote:
>I meant to use your exact words, see attachment
+1 !
Cheers,
-Barry
[Barry Warsaw, 2015-10-07]
> >how about making it official and adding it to the policy?
>
> I thought you had volunteered to do that (with native speaker review)? I
> previously mistakenly remembered Scott volunteering for that.
>
> If not, I'm happy to do it.
I meant to use your exact words, s
In the upstream Python project, we recently created a new mailing list as a
focal point for cross-distro Linux-specific issues. I invite all interested
folks to join and help make Python better on Linux.
https://mail.python.org/mailman/listinfo/linux-sig
Feel free to spread the announcement of t
On Oct 07, 2015, at 03:29 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2015-10-07]
>> * Team in Maintainers is a strong statement that fully collaborative
>> maintenance is preferred. Anyone can commit to the vcs and upload as
>> needed. A courtesy email to Uploaders can be nice but not requir
Quoting Piotr Ożarowski :
[Barry Warsaw, 2015-10-07]
* Team in Maintainers is a strong statement that fully collaborative
maintenance is preferred. Anyone can commit to the vcs and upload as
needed. A courtesy email to Uploaders can be nice but not required.
* Team in Uploaders is a weak
On 10/06/2015 11:36 PM, Piotr Ożarowski wrote:
> my point is that you could argue that your packages are better
> maintained than ours (less bug reports, wider Python 3 support,
> newest upstream releases, more popcon users, ...) but you choose the
> fact that you maintain more of them... and then
On Wed, 2015-10-07 at 14:18 +0200, Piotr Ożarowski wrote:
> I assume you all like other ideas, like no team in Maintainer, right?
I kind of liked the differentiation between the two options:
- I'm the primary maintainer and welcome other people working on my
packages (me in Maintainer, team in
[Barry Warsaw, 2015-10-07]
> * Team in Maintainers is a strong statement that fully collaborative
> maintenance is preferred. Anyone can commit to the vcs and upload as
> needed. A courtesy email to Uploaders can be nice but not required.
>
> * Team in Uploaders is a weak statement of collab
On Oct 07, 2015, at 02:33 PM, W. Martin Borgert wrote:
>Quoting Piotr Ożarowski :
>> I assume you all like other ideas, like no team in Maintainer, right?
>
>To me, "team maintenance" would mean, that the team appears in the
>"Maintainer" field. In "Uploaders" it doesn't make sense, so where
>woul
Quoting Piotr Ożarowski :
I assume you all like other ideas, like no team in Maintainer, right?
To me, "team maintenance" would mean, that the team appears in the
"Maintainer" field. In "Uploaders" it doesn't make sense, so where
would the team appear?
Personally, I prefer to have the team in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-07 14:18, Piotr Ożarowski wrote:
> I no longer think requiring contribution (the 3 months thing) is a
> good idea for DPMT (might be for a new team).
>
> I assume you all like other ideas, like no team in Maintainer,
> right?
if that's t
I no longer think requiring contribution (the 3 months thing) is a good
idea for DPMT (might be for a new team).
I assume you all like other ideas, like no team in Maintainer, right?
--
evil Piotr
On Fri, 2015-10-02 at 09:12 -0700, Nikolaus Rath wrote:
> I always assumed that it was generally preferred to have Python
> packages be maintained in the Python team, even if the maintainer has
> little interest or time in contributing to other Python packages.
Same here. I have a few packages in
On 07.10.2015 11:46, Piotr Ożarowski wrote:
[Jan-Pascal van Best, 2015-10-07]
I look forwarded to working with you on Python packaging. If I'm
accepted into the team, I'll upload the packaging work up to now to
oh, best join request so far!
do you call him by name or value? ;)
[Jan-Pascal van Best, 2015-10-07]
> I'd like to join the Debian Python application and modules teams. I'm a
> DM and my Alioth account is janpascal-guest.
>
> The root cause for this request is the dropping of the denyhosts package
> (a Python package) from Jessie. Once I noticed it was gone, I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Debian-Python folks,
I'd like to join the Debian Python application and modules teams. I'm a
DM and my Alioth account is janpascal-guest.
The root cause for this request is the dropping of the denyhosts package
(a Python package) from Jessie. O
37 matches
Mail list logo