Re: [Python-Dev] Py 3.6 on Ubuntu Zesty

2017-02-08 Thread Tim Golden 

On 07/02/2017 22:38, Barry Warsaw wrote:

On Feb 07, 2017, at 02:15 PM, Mike Miller wrote:


Does anyone know why Python 3.6 is not the default Python 3 under the
upcoming Ubuntu Zesty, or what may be holding it back?


I guess that would be me. :)


Is there anyone that could give it a nudge?  It's in the repos but not as
python3:

http://packages.ubuntu.com/zesty/python3
http://packages.ubuntu.com/zesty/python3.6


I posted about this on the ubuntu-devel mailing list:


[... snip comprehensive explanation about how versions get promoted 
within Debian / Ubuntu ...]


Well I'm only a casual Linux user, but this was interesting just because 
of the better understanding it gives of the processes which distros have 
to go through once new versions are released upstream.


Thanks

TJG
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenIndiana and Solaris support

2017-02-08 Thread Victor Stinner 
Hi,

Is there anything new about Solaris or OpenIndiana since September?
Right now, it seems like the cea-indiana-x86 buildbot slave is offline
since longer than 54 days.

Oracle decided to stop Solaris 12 development:
https://arstechnica.com/information-technology/2017/01/oracle-sort-of-confirms-demise-of-solaris-12-effort/

I'm not opposed to help if someone provides patches to fix Solaris
issues, but it seems like no one wants to do this job.

So I suggest to drop official Solaris support, but I don't propose to
remove the C code specific to Solaris. In practice, I suggest to
remove Solaris and OpenIndiana buildbots since they are broken for
months and are more annoying than useful.

Victor

2016-09-27 0:54 GMT+02:00 Brett Cannon :
>
>
> On Mon, 26 Sep 2016 at 15:38 Guido van Rossum  wrote:
>>
>> Thanks for the reality check Trent! I think if enough people with core
>> committer bits want to keep supporting Solaris / Illumos / OpenIndiana
>> / other variants that's fine, but I don't think that just having some
>> VMs to test on is enough -- we also need people who can fix problems
>> if those buildbots start failing, and that requires pretty specialized
>> knowledge. Plus of course we won't know if fixing it for OpenIndiana
>> will also fix it for Solaris 11 Express or for other Illumos forks.
>> (For Linux it's easier to assess these things because so many people
>> in open source use Linux and its many forks.)
>
>
> The official requirement to support a platform is a stable buildbot and a
> core dev to keep the support up:
> https://www.python.org/dev/peps/pep-0011/#supporting-platforms. Victor has
> asked that the OpenIndiana buildbot be removed from the stable pool as it
> consistently throws MemoryError which means its support is not improving. If
> Trent is willing to maintain a buildbot in a Joyent VM that at least takes
> care of that part, but it still requires Jesus to volunteer to keep the
> support up if it's going to be supported for free. Otherwise Joyent could
> consider contracting with one of the various core devs who happen to be
> consultants to help maintain the support.
>
> At minimum, though, a new buildbot could go into the unstable pool so
> illumos devs can keep an eye on when things break to try and get
> platform-independent changes upstreamed that happen to help illumos (e.g. no
> #ifdef changes specific to illumos, but if something just needed to be made
> more robust and it happens to help illumos that's typically fine).
>
>>
>>
>> On Mon, Sep 26, 2016 at 3:32 PM, Trent Mick  wrote:
>> > I work for Joyent (joyent.com) now, which employs a number of devs that
>> > work
>> > on illumos (illumos.org). We also provide cloud infrastructure. Would it
>> > help if we offered one or more instances (VMs) on which to run buildbot
>> > slaves (and on which volunteers for bug fixing could hack)?  I know a
>> > lot of
>> > people in the illumos community would be quite sad to have it dropped as
>> > a
>> > core Python plat.
>> >
>> > Guido,
>> > Yes you are correct that Oracle owns the Solaris brand.
>> >
>> > tl;dr history if you care:
>> > - sunos -> Solaris
>> > - Sun open sources Solaris, called OpenSolaris (2005)
>> > - Oracle acquires Sun and closes Solaris (Aug 2010). Shortly after, the
>> > community forks OpenSolaris and calls it illumos (Sep 2010)
>> > - OpenIndiana is a distro of illumos (somewhat similar to how Ubuntu is
>> > a
>> > distro of Linux). Other distros are SmartOS (the one Joyent works on),
>> > and
>> > OmniOS.
>> > - Oracle continues work on Solaris, releasing "Solaris 11 Express".
>> >
>> > I've no real numbers of usage of illumos vs Solaris 11 vs others.
>> >
>> > Cheers,
>> > Trent
>> >
>> > p.s. I hear that Jesus is also in contact with some of the illumos-devs
>> > on
>> > IRC (and perhaps email). I hope we can help there.
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Py 3.6 on Ubuntu Zesty

2017-02-08 Thread Petr Viktorin 

On 02/07/2017 11:38 PM, Barry Warsaw wrote:

On Feb 07, 2017, at 02:15 PM, Mike Miller wrote:


Does anyone know why Python 3.6 is not the default Python 3 under the
upcoming Ubuntu Zesty, or what may be holding it back?


I guess that would be me. :)



Thank for the in-depth explanation!



The Fedora/RH ecosystem probably has their own list, which I'd expect to
mostly overlap with ours, but I don't have those links handy.


Hello,

Python 3.6 is the python3 in Fedora Rawhide, on track to become Fedora 
26 in June.
These packages fail to build (which, for properly packaged software, 
includes passing upstream tests where feasible):


insight  (failure unrelated to Python)
python-django-admin-honeypot  (not ported for django 1.10)
python-os-brick  (unrelated packaging problems)
python-oslo-messaging  (blocked by python-oslo-middleware)
python-oslo-middleware  (not ported for webob 1.7+)
python-oslo-versionedobjects  (blocked by python3-oslo-messaging)
python-recommonmark  (not ported to latest commonmark)
python-repoze-who-plugins-sa  (test failures)
rb_libtorrent  (probably unrelated to Python)
shogun  (probably unrelated to Python)

That's 10 of 3349 python3-compatible packages.
The list used to be much longer and contain much more important 
packages, but got to the current state thanks to individual maintainers 
and people like Adam Williamson, Zbigniew Jędrzejewski-Szmek, and Igor 
Gnatenko (and the python-maint team, but we're paid for it).
The list was also longer than usual because there was no mass rebuild of 
packages for Fedora 25, so some build failures introduced in the last 
year are only popping up now.



Released versions of Fedora will be getting getting a "python36" package 
soon; for now it's installable using:


   dnf install --enablerepo=updates-testing python36

This is one of Fedora's "other Pythons" (interpreters other than the 
"current" 2.x and 3.x, i.e.  python26, python34, python33). It's enough 
to make virtualenv/venv and tox work, but no system packages are built 
for these.




___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenIndiana and Solaris support

2017-02-08 Thread Jesus Cea 
On 08/02/17 11:24, Victor Stinner wrote:
> So I suggest to drop official Solaris support, but I don't propose to
> remove the C code specific to Solaris. In practice, I suggest to
> remove Solaris and OpenIndiana buildbots since they are broken for
> months and are more annoying than useful.

Give me a week to move this forward. Last hope.


-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenIndiana and Solaris support

2017-02-08 Thread Jesus Cea 
On 08/02/17 11:24, Victor Stinner wrote:
> So I suggest to drop official Solaris support, but I don't propose to
> remove the C code specific to Solaris. In practice, I suggest to
> remove Solaris and OpenIndiana buildbots since they are broken for
> months and are more annoying than useful.

The main issue is that something wrong is going on with buildbot. From
time to time, it eats gigabytes of RAM (last time, 64GB) and kills the
machine. maybe once per week. This is not very welcomed by my host and
his reaction is to shutdown the solaris "zone" because we don't "behave"
and this is impacting production system.

I am trying to convince him to launch buildbot process tree with an
"ulimit" to protect the machine. Lets see.

Sorry. Thanks for your patience.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenIndiana and Solaris support

2017-02-08 Thread Jesus Cea 
On 08/02/17 16:18, Jesus Cea wrote:
> I am trying to convince him to launch buildbot process tree with an
> "ulimit" to protect the machine. Lets see.
> 
> Sorry. Thanks for your patience.

I am launching now the buildbot with a limit of 1GB *PER PROCESS*. At
least, when the memory skyrockets it will die without impacting the rest
of the machine. Unless it does a fork-bomb...

Backlog is huge. That will be useful to stress the buildbot and,
hopefuly, make it fails faster.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Brett Cannon 
On Tue, 7 Feb 2017 at 23:38 Victor Stinner  wrote:

> 2017-02-08 8:35 GMT+01:00 Victor Stinner :
> > I'm sure the patch author would appreciate it, but I don't think we
> > need to require it as we have gone this long without it.
>
> I know that different people have different expectation on GitHub. I
> would like to take the opportunity of migrating to Git to use the
> "author" and "committer" fields. If the author is set to the real
> author, the one who proposed the change on the bug tracker or someone
> else, we will be able to compute statistics on most active
> contributors to more easily detect them and promote them to core
> developers.
>
> What do you think?
>

Personally I think this would be great for everyone to do. Do you want to
propose a PR for the devguide to document what to include (I assume
committer will automatically be filled with the core dev's info so that
should only require authorship to be specified).


>
> I agree that pull requests avoid the issues of filling manually the
> author field, but I expect that not everyone will use PR, especially
> because we will still use our current bug tracker which accepts to
> attach patch files. Ok to propose them to create a PR instead.
>

My expectation is there will be a transition period of dealing with patches
on bpo which have submitters who don't want to bother making an equivalent
PR on GitHub.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Terry Reedy 

On 2/8/2017 2:38 AM, Victor Stinner wrote:


I know that different people have different expectation on GitHub. I
would like to take the opportunity of migrating to Git to use the
"author" and "committer" fields. If the author is set to the real
author, the one who proposed the change on the bug tracker or someone
else, we will be able to compute statistics on most active
contributors to more easily detect them and promote them to core
developers.

What do you think?


Many patches have multiple authors. Does the 'author' field allow that? 
  Often, the committer adds missing chunks or rewrites the work with 
various degrees of editing.  Sometimes a read a patch for the idea and 
then start fresh with the actual code.  An acknowledgement in the news 
entry can be written different ways to reflect the situation.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Brett Cannon 
On Wed, 8 Feb 2017 at 12:33 Terry Reedy  wrote:

> On 2/8/2017 2:38 AM, Victor Stinner wrote:
>
> > I know that different people have different expectation on GitHub. I
> > would like to take the opportunity of migrating to Git to use the
> > "author" and "committer" fields. If the author is set to the real
> > author, the one who proposed the change on the bug tracker or someone
> > else, we will be able to compute statistics on most active
> > contributors to more easily detect them and promote them to core
> > developers.
> >
> > What do you think?
>
> Many patches have multiple authors. Does the 'author' field allow that?
>

No.


>Often, the committer adds missing chunks or rewrites the work with
> various degrees of editing.  Sometimes a read a patch for the idea and
> then start fresh with the actual code.  An acknowledgement in the news
> entry can be written different ways to reflect the situation.
>

Yep, I assume the Misc/NEWS entry, commit log, and Misc/ACKS all provide
opportunities to overcome the shortcoming of a single author attribution.

-Brett


>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Victor Stinner 
2017-02-08 21:32 GMT+01:00 Terry Reedy :
> Many patches have multiple authors. Does the 'author' field allow that?
> Often, the committer adds missing chunks or rewrites the work with various
> degrees of editing.  Sometimes a read a patch for the idea and then start
> fresh with the actual code.  An acknowledgement in the news entry can be
> written different ways to reflect the situation.

In my experience, the common case is two "authors": the initial patch
autor, and the core dev who makes minor changes like filling Misc/NEWS
and adjust some parts of the code. If changes are minor, there is no
need to elaborate. But if changes are non straightforward, they can be
listed in the commit messages.

If a patch has more author, you have to pick the name, decide which
author helped the most, and add the other authors in the commit
message.

Using GitHub, it will become easier to use patch series, and so
smaller changes. Each change may have a different author :-D

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Brett Cannon 
On Wed, 8 Feb 2017 at 13:33 Victor Stinner  wrote:

> 2017-02-08 21:32 GMT+01:00 Terry Reedy :
> > Many patches have multiple authors. Does the 'author' field allow that?
> > Often, the committer adds missing chunks or rewrites the work with
> various
> > degrees of editing.  Sometimes a read a patch for the idea and then start
> > fresh with the actual code.  An acknowledgement in the news entry can be
> > written different ways to reflect the situation.
>
> In my experience, the common case is two "authors": the initial patch
> autor, and the core dev who makes minor changes like filling Misc/NEWS
> and adjust some parts of the code. If changes are minor, there is no
> need to elaborate. But if changes are non straightforward, they can be
> listed in the commit messages.
>
> If a patch has more author, you have to pick the name, decide which
> author helped the most, and add the other authors in the commit
> message.
>
> Using GitHub, it will become easier to use patch series, and so
> smaller changes. Each change may have a different author :-D
>

Don't forget we are doing squash merges, so if a PR has multiple authors
then the author information won't carry forward in git (I don't know if
GitHub has custom logic to work around this).
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Victor Stinner 
2017-02-08 23:42 GMT+01:00 Brett Cannon :
> Don't forget we are doing squash merges,

Ah, I didn't know. Why not using merges?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Sven R. Kunze 

On 09.02.2017 00:03, Victor Stinner wrote:

2017-02-08 23:42 GMT+01:00 Brett Cannon :

Don't forget we are doing squash merges,

Ah, I didn't know. Why not using merges?



Same question here. I see no benefit just overhead, mistakes and longer 
processes.



Sven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub migration scheduled for Friday

2017-02-08 Thread Brett Cannon 
On Wed, 8 Feb 2017 at 15:04 Victor Stinner  wrote:

> 2017-02-08 23:42 GMT+01:00 Brett Cannon :
> > Don't forget we are doing squash merges,
>
> Ah, I didn't know. Why not using merges?
>

Because other core devs wanted a linear history. This preference was very
strong to the point people were willing to forgo the Merge button in
GitHub's web UI to enforce it until GitHub added the squash merge support
for the Merge button. This was decided over a year ago and documented in
PEP 512 as the decision made since I believe the beginning of that PEP.

Now I know Victor was asking out of curiosity, but I'm going to ask nicely
now and then ignore later anyone who starts second-guessing my decisions at
this point as someone did as a follow-up to Victor's question. This process
has been discussed for over 2 years and PEP 512 has existed for over one
year. There has also been an open mailing list where I have held
discussions on various topics and people have been free to ask and
participate on. Now is not the time to start second-guessing things that
have already been decided and discussed to great length before we even have
any experience with the chosen workflow.

The final stretch of this whole process has been going smoothly, so I'm
trying to ask nicely that everyone give me the benefit of the doubt and
assume everything has been thought out and there is a reason behind
everything before you choose to second-guess my decisions at the 11th hour.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenIndiana and Solaris support

2017-02-08 Thread Jesus Cea 
On 08/02/17 17:06, Jesus Cea wrote:
> On 08/02/17 16:18, Jesus Cea wrote:
>> I am trying to convince him to launch buildbot process tree with an
>> "ulimit" to protect the machine. Lets see.
>>
>> Sorry. Thanks for your patience.
> 
> I am launching now the buildbot with a limit of 1GB *PER PROCESS*. At
> least, when the memory skyrockets it will die without impacting the rest
> of the machine. Unless it does a fork-bomb...
> 
> Backlog is huge. That will be useful to stress the buildbot and,
> hopefuly, make it fails faster.

Checking the mailing list archives, I am seen Openindiana buildbot
memory issues since 2011, at least.
.
It was never triaged.

I am getting mercurial errors because some incompatibility with current
release
.
Since we are moving to github in a couple of days, I will wait until
that time to keep pursuing this.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com