Here are the current OpenSSL 1.1.1a changes I have, in a seperate PR
I did some additional testing and have some test failures to investigate
tomorrows
test_parse_cert_CVE_2019_5010 only fails win32 debug (access violation)
works for amd64 debug/release and win32 release
test_load_default_cer
On Feb 6, 2019, at 18:28, Steve Dower wrote:
> On 06Feb2019 1423, Christian Heimes wrote:
>> Do you want to update Python 3.8 (master) only or also 3.7? I'm not
>> strictly against updating 3.7. However we have traditionally kept the
>> OpenSSL version of each branch stable. 1.1.1 comes with new f
On 06Feb2019 1423, Christian Heimes wrote:
Do you want to update Python 3.8 (master) only or also 3.7? I'm not
strictly against updating 3.7. However we have traditionally kept the
OpenSSL version of each branch stable. 1.1.1 comes with new features,
stricter security settings and some ciphers re
On 06/02/2019 02.09, Paul Monson via Python-Dev wrote:
> Updating OpenSSL and libffi are independent of ARM support but need to
> be done as prerequisites. OpenSSL 1.1.0 doesn't have support for ARM32
> on Windows but OpenSSL 1.1.1 does.
>
>
>
> I have OpenSSL 1.1.1a ready to check in to maste
The PR is here: https://github.com/python/cpython/pull/11774
Searching _M_ARM I see these #ifdef changes outside of ctypes:
* Include\pyport.h - adds on to existing MSVC ifdef
* Include\pythonrun.h - adds on to existing MSVC ifdef
* Modules\_decimal\libmpdec\bits.h
* Python\ceval.c - workaround co
On 06Feb2019 0054, Terry Reedy wrote:
On 2/5/2019 10:10 PM, Zachary Ware wrote:
I'm all for the first two changes (especially the second), and if 10
years of pledged corporate support for a new platform is the price we
have to pay for them, I'm ok with that :).
I would expect that the main qu
On 06Feb2019 0906, Antoine Pitrou wrote:
For the record there are number of initiatives currently to boost the
usefulness and efficiency of multi-process computation in Python.
One of them is PEP 574 (zero-copy pickling with out-of-band buffers),
which I'm working on.
Another is Pierre Glaser's
Hello,
For the record there are number of initiatives currently to boost the
usefulness and efficiency of multi-process computation in Python.
One of them is PEP 574 (zero-copy pickling with out-of-band buffers),
which I'm working on.
Another is Pierre Glaser's work on allowing pickling of dyn
On Wed, Feb 6, 2019 at 12:51 PM Giampaolo Rodola'
wrote:
>
> Unless they are already there (I don't know) it would be good to have a
> full set of unit-tests for all the register()ed types and test them against
> SyncManager and SharedMemoryManager. That would give an idea on the real
> interchan
On 2/6/19 2:26 PM, Matthias Klose wrote:
On 06.02.19 13:23, Petr Viktorin wrote:
FWIW, we're preparing to rebuild all Fedora packages with the 3.8 alphas/betas,
so everything's tested when 3.8.0 is released:
https://fedoraproject.org/wiki/Changes/Python3.8
That should cover the main Python proj
On 06.02.19 13:23, Petr Viktorin wrote:
> FWIW, we're preparing to rebuild all Fedora packages with the 3.8
> alphas/betas,
> so everything's tested when 3.8.0 is released:
> https://fedoraproject.org/wiki/Changes/Python3.8
>
> That should cover the main Python projects, too.
well, the real chal
On 2/6/19 8:43 AM, Stephane Wirtel wrote:
On 02/05, Barry Warsaw wrote:
On Feb 5, 2019, at 02:24, Stephane Wirtel wrote:
You’re welcome! I just pushed an update to add 3.8.0a1 to the set of
Python’s (including git head). Do you think there’s a better way to
publicize these images?
I know
Davin,
I am not familiar with the multiprocessing module, so take the following
with a big grain of salt. I took a look at the PR, then I got an idea of
how multiprocessing module is organized by reading the doc. Here's some
food for thought in terms of API reorganization.
SharedMemoryManager, Sha
On Wed, 6 Feb 2019 at 05:17, Neil Schemenauer wrote:
> My gut reaction is that we shouldn't revert. However, looking at
> the changes, it seems 'multiprocessing.shared_memory' could be an
> external extension package that lives in PyPI. It doesn't require
> changes to other interpreter internals
On 2/5/2019 10:10 PM, Zachary Ware wrote:
I'm all for the first two changes (especially the second), and if 10
years of pledged corporate support for a new platform is the price we
have to pay for them, I'm ok with that :).
I would expect that the main question should be the density of
WinArm
15 matches
Mail list logo
