Re: [Python-Dev] buildbottest on Android emulator with docker
Timeout (360 seconds) reached; failed to start emulator
---> Device ready.
---> Install Python on the emulator.
/home/pydev/build/python-native/python -B
/home/pydev/abifa/Android/tools/install.py
error: device 'emulator-5556' not found
I can reproduce this error after removing the kvm kernel modules (I am on
ArchLinux and ArchLinux kernels provide the required kernel modules to support
KVM virtualization). So my fault, forgot to explain that kvm is required to
run this docker image, kvm is not required though when the docker image is
built for other architectures (non x86_64), but it is very very slow then.
To fix the problem one must install the Linux distribution packages that
provide KVM virtualization. Whatever the Linux distribution it may also be
necessary to enable virtualization support in the BIOS.
I will enter an issue and update the documentation at
https://gitlab.com/xdegaye/abifa.
Thanks Stephane for the report.
Xavier
On 2/19/19 4:52 PM, Stephane Wirtel wrote:
Hi Xavier,
I get this exception
Timeout (360 seconds) reached; failed to start emulator
---> Device ready.
---> Install Python on the emulator.
/home/pydev/build/python-native/python -B
/home/pydev/abifa/Android/tools/install.py
error: device 'emulator-5556' not found
unzip -q /home/pydev/dist/python3.8-android-24-x86_64-stdlib.zip -d
/tmp/tmpt_v_gdbo
/home/pydev/android/android-sdk/platform-tools/adb -s emulator-5556 shell mkdir
-p /data/local/tmp/python
Command "('/home/pydev/android/android-sdk/platform-tools/adb', '-s',
'emulator-5556', 'shell', 'mkdir -p /data/local/tmp/python')" returned non-zero exit
status 1
/home/pydev/abifa/Android/emulator.mk:57: recipe for target '_install' failed
make: *** [_install] Error 1
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Question - Bug Triage for 3.4 & 3.5
Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issues (non-security) to 3.6/3.7 & 3.8? Cheers, Stéphane -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
After discussion with Victor, my proposal will generate noise with the ML, maybe for nothing. On 02/20, Stephane Wirtel wrote: Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issues (non-security) to 3.6/3.7 & 3.8? Cheers, Stéphane -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
On 20Feb.2019 0711, Stephane Wirtel wrote: > After discussion with Victor, my proposal will generate noise with the > ML, maybe for nothing. > > On 02/20, Stephane Wirtel wrote: >> Hi, >> >> As you know, Python 3.4 and 3.5 are in security mode and the EOL for >> these versions are respectively 2019-03-16 and 2020-09-13. >> >> Number of issues >> >> 3.4: 1530 issues >> 3.5: 1901 issues >> >> But some issues are not related to the security. >> >> Could we update these issues (non-security) to 3.6/3.7 & 3.8? >> >> Cheers, >> >> Stéphane It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. I'm always in favor of cleaning up inactionable bugs (as much as I'm in favor of keeping actionable-but-low-priority bugs open, which causes quite a few conflicts at work...) That said, maybe it makes sense to wait until 2.7's EOL and do them all at once? Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
20.02.19 17:01, Stephane Wirtel пише: As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issues (non-security) to 3.6/3.7 & 3.8? I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them. Sure, I don't want to update them massively, just one by one. But I prefer to ask before this kind of operation. -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
Hi Steve, I reply on the mailing list On 02/20, Steve Dower wrote: It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. As Serhyi proposed, a one by one could be interesting, to be sure we "migrate" the right issue to the right version. I'm always in favor of cleaning up inactionable bugs (as much as I'm in favor of keeping actionable-but-low-priority bugs open, which causes quite a few conflicts at work...) That said, maybe it makes sense to wait until 2.7's EOL and do them all at once? I have already started with some issues. -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5
Hi, If Python 3.4 was the current version when a bug was reported, I would expect the version field of the bug set to Python 3.4. Maybe the bug has been fixed in the meanwhile, maybe not. Closing all bugs affected to 3.4 is a risk of loosing useful information on real bugs: closed bugs are ignored by default in "Search" operation. Changing the version field: well, I don't think that it's useful. I usually ignore this field. And it would send like 3000 emails... I don't see the point. It's not uncommon that I fix bugs which 5 years old if not longer. Sometimes, I decide to look at all bugs of a specific module. And most of old bugs are still relevant nowadays. Sometimes, closing the bug as WONTFIX is the right answer, but it can only be done on a case by case basis. Note: Same rationale for Python 3.5, Python 2.6, or another other old Python version ;-) Bug triage is hard and requires plenty of time :-) Victor Le mer. 20 févr. 2019 à 16:05, Stephane Wirtel a écrit : > > Hi, > > As you know, Python 3.4 and 3.5 are in security mode and the EOL for > these versions are respectively 2019-03-16 and 2020-09-13. > > Number of issues > > 3.4: 1530 issues > 3.5: 1901 issues > > But some issues are not related to the security. > > Could we update these issues (non-security) to 3.6/3.7 & 3.8? > > Cheers, > > Stéphane > > -- > Stéphane Wirtel - https://wirtel.be - @matrixise > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making PyInterpreterState an opaque type
On Tue, Feb 19, 2019 at 12:45 PM Steve Dower wrote: > On 19Feb2019 1141, Barry Warsaw wrote: > > Steve Dower wrote on 2/16/19 14:34:> > >> This is mostly about being able to assign blame when things break, so > >> I'm totally okay with extension modules that want to play with internals > >> declaring Py_BUILD_CORE to get access to them (though I suspect that > >> won't work out of the box - maybe we should have a > >> Py_I_TOO_LIKE_TO_LIVE_DANGEROUSLY?). > > > > Let's call it Py_POINTED_STICK of course! > > > > http://www.montypython.net/scripts/fruit.php > > +1, and instead of "using the internal API" we can call it "coming at > CPython with a banana" :D > I don't think now is the exact time to do this since how to even handle PEPs isn't really settled in this new steering council world, but eventually maybe a PEP to outlining the re-org, how to opt into what seems to be the 3 different layers of the C API for users, guidelines on how to decide what APIs go where, etc. might be warranted? Stuff is starting to get strewn about without a centralized thing to focus discussions around so probably having a PEP to focus around might help. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime.timedelta total_microseconds
On Fri, Feb 15, 2019 at 5:29 PM Paul Ganssle wrote: > it allows you to use non-traditional units like weeks (timedelta(days=7)) > Weeks are traditional: >>> timedelta(weeks=1) datetime.timedelta(7) :-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform
Thanks for the feedback.
I updated the PR to use get_platform and get_host_platform.
More testing is still needed before it's ready to merge to make sure it still
does what it was intended to do.
-Original Message-
From: Python-Dev On
Behalf Of Xavier de Gaye
Sent: Tuesday, February 19, 2019 12:06 PM
To: Steve Dower ; python-dev@python.org
Subject: Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the
"target" platform
> [Any reason for dropping python-dev?]
Sorry. just clicked the wrong button.
> And the answer is a resounding "yes, it returns the target platform"? It
> seems you're saying this, but the wording of your email sounds just enough of
> a question that I'm not sure whether you are definitively answering it or not.
The answer is yes indeed, it returns the target platform.
This is a listing of the non-obvious steps that lead to this conclusion.
Xavier
On 2/19/19 8:45 PM, Steve Dower wrote:
> [Any reason for dropping python-dev?]
>
> On 19Feb2019 1139, Xavier de Gaye wrote:
>> Is distutils.util.get_platform() the "current" or the "target" platform ?
>
> I *think* you're answering this below, yes?
>
>> * When cross-compiling on posix platforms using autoconf, configure is
>> run with the '--host=host-type' [1] command line option to specify
>> the target platform.
>>
>> * The AC_CANONICAL_HOST macro is used by configure.ac to get the
>> canonical variables `host' and `host_cpu' [2].
>> Those variables are used to compute _PYTHON_HOST_PLATFORM.
>>
>> * The Makefile generated by configure runs setup.py,
>> generate-posix-vars, etc... on the build platform using
>> PYTHON_FOR_BUILD, a native python interpreter that is set
>> to run with the _PYTHON_HOST_PLATFORM environment variable.
>>
>> * get_platform() in setup.py and in Lib/distutils/util.py returns the
>> value of _PYTHON_HOST_PLATFORM when cross-compiling.
>>
>> So the process of cross-compilation on posix platforms has
>> get_platform() return the target ('host' in autoconf terminology) platform.
>>
>> [1]
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsavannah-checkouts%2Fgnu%2Fautoconf%2Fmanual%2Fautoconf-2.69%2Fhtml_node%2FSpecifying-Target-Triplets.html&data=02%7C01%7CPaul.Monson%40microsoft.com%7C186de203c3d644c7517208d696a5f266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862036817328765&sdata=2PMKn%2Bt5ed82gkSBnew0nT1TA1qzDuU3VZNOFPYPqIM%3D&reserved=0
>> [2]
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsavannah-checkouts%2Fgnu%2Fautoconf%2Fmanual%2Fautoconf-2.69%2Fhtml_node%2FCanonicalizing.html&data=02%7C01%7CPaul.Monson%40microsoft.com%7C186de203c3d644c7517208d696a5f266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862036817328765&sdata=zRtcyLjDrkL%2BfcignLCDjtUri29j7mCscdVkGqhNk50%3D&reserved=0
>
> And the answer is a resounding "yes, it returns the target platform"? It
> seems you're saying this, but the wording of your email sounds just enough of
> a question that I'm not sure whether you are definitively answering it or not.
>
> Cheers,
> Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-dev&data=02%7C01%7CPaul.Monson%40microsoft.com%7C186de203c3d644c7517208d696a5f266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862036817328765&sdata=Au0xrggEwNRRAen6dr8GnBuTTvMbxVhSuWOtX67p3Ts%3D&reserved=0
Unsubscribe:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Foptions%2Fpython-dev%2Fpaulmon%2540microsoft.com&data=02%7C01%7CPaul.Monson%40microsoft.com%7C186de203c3d644c7517208d696a5f266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636862036817328765&sdata=nVHiEW69so29h6uTbY7XDjPF6%2FwU0pnlNpQEeYSoygY%3D&reserved=0
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
