New submission from Jeremy Howard :
imghdr.what does not set f if h is passed, but still passed f to tests
functions. None of the tests functions use it - they would not be able to
anyway since it is not always set.
imghdr.what is missing a docstring.
imghdr.what has a complex highly nest
Jeremy Lainé added the comment:
The OpenSSL authors make a fair point, QUIC seems to be taking a long time to
stabilize with little consideration for backwards compatibility at this stage.
As stated previously though it's perfectly feasible to implement a QUIC stack
by linking
Jeremy Kloth added the comment:
The error from importing numpy comes from attempting to load a 64-bit DLL in a
32-bit process. This stems from the shared user install directory (now fixed
in 3.9, I believe).
There is most likely a mix of 32- and 64-bit extensions in the user install
New submission from Jeremy Attali :
In a pure Wayland environment (without xwayland), the DISPLAY environment
variable is not present. Therefore the call to `xdg-settings get
default-browser` is not made. So the webbrowser behaviour is different between
X11 and Wayland environment. I'm
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue39978>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue39917>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Well, it only doesn't build on 3.9+ (master) due to not being supported going
forward. The *buildmaster* needs to be fixed to stop submitting those jobs to
unsupported platforms.
We need to continue testing 3.7 and 3.8 on Win7 until they go EOL to ensure
Jeremy Kloth added the comment:
What seems to be, at least, the conclusion of the thread:
https://mail.python.org/archives/list/python-...@python.org/thread/YXMD5EIHAODRZGTQ3HU74OPGEBAVCSK6/
--
nosy: +jkloth
___
Python tracker
<ht
Jeremy Kloth added the comment:
+1, obviously, as I came to the same conclusion above (see msg361122)
--
___
Python tracker
<https://bugs.python.org/issue39
Jeremy Kloth added the comment:
> The problem is to make Py_INCREF/Py_DECREF efficient.
That is exactly why I didn't propose a change to them. The singletons
still are refcounted as usual, just that their ob_refcnt is ignored.
If they somehow reach 0, they just "resurrect&quo
Jeremy Kloth added the comment:
Would it not suffice to just make the singletons "immortal"?
Without affecting the hotpaths that are Py_INCREF and Py_DECREF, changing
_Py_Dealloc to test for objects with a "special" destructor could be used:
destructor dealloc = Py_
Jeremy Kloth added the comment:
As noted on the PR landing page, this PR has caused failures of 2 buildbots:
https://buildbot.python.org/all/#builders/81/builds/272
https://buildbot.python.org/all/#builders/150/builds/227
(both are Windows 7)
--
nosy: +jkloth
Jeremy Kloth added the comment:
That covers the logging in _force_run(), but the warning.warn() line is also
not output, suggesting that the RuntimeWarning is being suppressed somewhere.
--
___
Python tracker
<https://bugs.python.org/issue38
Jeremy Kloth added the comment:
While not getting into the error itself, there seems to be another issue in
that the logging that should be happening when the deletion routines from
test.support fail:
https://github.com/python/cpython/blob/5bc6a7c06eda20ba131ecba6752be0506d310181/Lib/test
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue38544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
> Windows 7 is not supported for Python 3.9, so this buildbot can be
> disabled/upgraded.
As long as 3.7 and 3.8 are being tested through the buildbots, I would think
testing on Windows 7 is still advised.
That said, once those versions are no longer
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue38207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Another day, another stuck test_concurrent_futures...
https://buildbot.python.org/all/#/builders/40/builds/3030
The test process is again killed (line 568) but the processes from the
multiprocess pool are still alive. Once I manually kill those pool
Jeremy Kloth added the comment:
Well, the kill timeout doesn't seem to be working, at least completely:
https://buildbot.python.org/all/#/builders/40/builds/3012
The worker process has been killed (line 562), but regrtest is still waiting
New submission from Jeremy :
If a unittest is written which accesses a module written in C++ (I used
Pybind11 to allow Python access) which uses malloc for a string, a segmentation
fault is caused. This is not replicated when malloc is used for some other data
types such as int, char or char
Jeremy Kloth added the comment:
I happened to catch a stuck build prior to the process being killed:
https://buildbot.python.org/all/#/builders//builds/2887
In short, the PR doesn't change the problem. The regrtest main will wait
indefinitely on the successfully killed process.
I have
Jeremy Kloth added the comment:
Additional logging on failures is always welcome. Might I suggest that, in
this case, regrtest treats this action as a hard fail so as to not got lost in
the other transient failures (test_asyncio).
By that I mean, either to not re-run, or to still
Jeremy Kloth added the comment:
> Can you check the process hierarchy? I would like to know how many worker
> processes are still running under the main regrtest process. I expect to see
> exactly one. I don't know how to investigate more on such issue on Windows.
There are
Jeremy Kloth added the comment:
It seems that an issue still exists.
https://buildbot.python.org/all/#/builders/130/builds/1050
has been running for nearly 9 hours at this point. I can leave it "stuck" if
there is some diagnostics that would be beneficial. But I would prefer no
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
The test run was stopped by me terminating the stuck processes on the buildbot
worker itself. This happens approximately once a month or so.
As of late, its been stuck in test_concurrent_futures, but it can get stuck in
any test that uses multiprocessing
New submission from Jeremy Cline :
This is related to the new AsyncMock[0] class in Python 3.8b1. A simple
reproducer is:
from unittest import mock
mock_obj = mock.MagicMock()
mock_obj.mock_func = mock.MagicMock(spec=lambda x: x)
with mock.patch.object(mock_obj, "mock_func")
Jeremy Lainé added the comment:
I have started implementing a QUIC stack in Python [1] so I'll share a couple
of thoughts in addition to Christian's two valid points:
- SSLSocket is almost certainly not going to be the right entry point. QUIC's
interface to TLS is entirely focused on passing
Jeremy Kloth added the comment:
> * the experimental UTF-8 support was enabled because "de_DE" is not a
> known Windows locale name - try with "de-DE"
>
> Perhaps it would be easy to do the replacement of underscores with hyphens
> on Windows in this functi
Jeremy Kloth added the comment:
I have managed to setup a VM that can reproduce the error. Unfortunately, the
error (heap corruption) is coming from within the UCRT. Attempting to work
around that, I came across another error in the UCRT.
Due to these errors in all available UCRT versions
Jeremy Kloth added the comment:
I've added another test executable (issue36792-2.zip) which should bring some
insight into where things are going wrong. Please run and post the results.
--
Added file: https://bugs.python.org/file48324/issue36792-2.zip
Jeremy Kloth added the comment:
Thanks again! I will have some more tests for you to try tomorrow as I am out
of time for today.
I'm currently of the belief that there is something Python is going to have to
do to work around an issue within the CRT, but more testing will prove
Jeremy Kloth added the comment:
Final test, this time, no Python what so ever. I've added a zip containing a
simple C program (source and .exe) that performs the same test.
The output should be similar to:
The current locale is now: C
The time zone is: 'Mountain Daylight Time' (22
Jeremy Kloth added the comment:
Here is another test, this time removing Python from the equation (mostly :)
import ctypes, struct
crt_locale = ctypes.CDLL('api-ms-win-crt-locale-l1-1-0', use_errno=True)
crt_time = ctypes.CDLL('api-ms-win-crt-time-l1-1-0', use_errno=True)
crt_locale
Jeremy Kloth added the comment:
You can safely execute each line individually (omitting the aforementioned
count/value pairs) or depending on how the copy/paste is being done, just paste
the script into a text editor (notepad) and comment out those lines. Then
copy-paste that modified
Jeremy Kloth added the comment:
Thanks for your patience with this Charlie, but please try another run this
time without the strftime() and mbstowcs() calls. Honest, we are getting
closer!
--
___
Python tracker
<https://bugs.python.
Jeremy Kloth added the comment:
Thanks for the reminder Eryk Sun. This means the test needs to be run yet one
more time :)
import ctypes, locale, struct
crt_time = ctypes.CDLL('api-ms-win-crt-time-l1-1-0', use_errno=True)
locale.setlocale(locale.LC_ALL, 'de_DE')
buf
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue10653>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Oops, I forgot to add in my snippet, the setlocale() call prior to calling the
C strftime() function. So an updated test:
import locale
locale.setlocale(locale.LC_ALL, 'de_DE')
import ctypes, struct
libc = ctypes.cdll.msvcrt
buf = ctypes.create_string_buffer
Jeremy Kloth added the comment:
Ok, now let's try it using the C runtime directly:
import ctypes, struct
libc = ctypes.cdll.msvcrt
buf = ctypes.create_string_buffer(1024)
tm = struct.pack('9i', 2019, 5, 6, 9, 50, 4, 0, 126, 1)
print('count:', libc.strftime(buf, 1024, b'%Z', tm))
print('value
Jeremy Kloth added the comment:
So does that mean that simply doing:
import locale, time
locale.setlocale(locale.LC_ALL, 'de_DE')
time.localtime(time.time())
is enough to trigger the heap corruption? If yes, then what is the output of:
import locale, time
locale.setlocale(locale.LC_ALL
Jeremy Kloth added the comment:
Related to issue bpo-36319
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36792>
___
___
Python-bugs-list m
Jeremy McMillan added the comment:
I think the code in SaltStack to handle scoped IPv6 addresses is mature, so
please look at these examples.
https://github.com/saltstack/salt/blob/2085cb1078f187adf82a0cf19b39d350ff1bbd50/salt/_compat.py#L125
Jeremy Kloth added the comment:
>
> How does that cause tests to fail? Is it going to stderr? Or just causing
> an error.
>
It is causing an "unexpected output error". When the test is re-run at the
end, it is run in verbose mode so the extra output is ignored and thu
Jeremy Kloth added the comment:
A missed print statement in the 2.7 patch is causing the tests to fail.
Line 647 of Lib/test/test_urlparse.py
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36
Jeremy Kloth added the comment:
When I visit the provided link, I also see what OP describes.
Is it a caching/location issue? I'm in US-Colorado.
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36085>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Thank you for your testing of the venv and pip workflows. At this point, I
believe that all that remains would be for Steve Dower to incorporate the
`IncludeVEnv=true` parameter into the nupkg build process.
I personally do not see a problem with including
Jeremy Kloth added the comment:
> Why do I need to fetch another tool just to fetch Python?
Well, you still need a tool to fetch the zip and you need another tool
to unzip it. If not, how are you bootstrapping your script for those
uses?
> If this is the final decision then I rec
Jeremy Kloth added the comment:
On Sat, Feb 16, 2019 at 8:32 AM jt wrote:
> Is nuget a standard windows utility?
No, but if your script can download a zip of Python, it could download
the nuget executable.
> What happens if that process is interrupted?
Same as interrupting an
Jeremy Kloth added the comment:
For a "tool-style" installation of Python, see the 'PCBuild\find_python.bat'
script in the Python source tree, specifically the nuget section.
Ultimately, it is just:
> nuget install pythonx86 -ExcludeVersion -OutputDirectory "some\path&q
Jeremy Kloth added the comment:
Also of note, a largish temporary directory (16K+ entries) seemed to be causing
a slowdown in the cleanup of the tests, thus triggering the failures. A quick
purge later and the tests seem to run to completion.
Although the tests are currently passing
Jeremy Kloth added the comment:
This is an old, but recurring issue with Windows and directory tree removal:
see issue15496
Basically, for stable (Windows) buildbots, directory tree removal needs to go
through support.rmtree, not any of the stdlib methods for doing so. In a
nutshell
Jeremy Kloth added the comment:
GH-11274 desperately needs to be addressed! The 2 Windows 7 buildbots have been
failing on 3.x since the merge of GH-11135 on 12-18. Either that or the commit
b5c8cfa needs to be reverted.
Being the holiday season and all I can see the extra time needed
Jeremy Kloth added the comment:
All the Windows 3.6 windows buildbots are happy! Thanks to all!
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
> Oh, it's not the installation itself, I'm just wondering if allowing a newer
> version is ok too?
The original PR (included in 3.7, 3.x) uses the latest discovered SDK,
but Steve stated that that logic broke the Pipelines build, so I
reworked to PR t
Jeremy Kloth added the comment:
Well, if VS2015 is installed, the simplest way to have the required SDK(s) is
to go to Control Panel -> Uninstall -> Microsoft Visual Studio (Community) 2015
Click Modify.
Expand "Windows and Web Development"
Expand "Universal Windows
Jeremy Kloth added the comment:
I forgot to mention that the presence of UseWindows81SDK in the build log
indicates that the Build Tools are at most at version 1.2 (included with VS2015
Update 1) which should still work (it's what I tested against), but the
difference may be the standalone
Jeremy Kloth added the comment:
A quick look at the good build log does indicate that the 8.1 SDK was being
used (vars UseWindows81SDK=true and WindowsTargetPlatformVersion=8.1) which is
the default behavior for VS2015 if a matching (from python.props) Win10SDK
cannot be found.
It seems
Jeremy Kloth added the comment:
See also bpo-35450: venv module doesn't create a copy of python binary by
default
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue34
Jeremy Kloth added the comment:
I've added a PR for 3.6 using a different methodology for finding the available
SDK.
Without some change, my buildbot will continue to stay in the red (for 3.6).
It does not the the highest SDK currently (previously?) listed the hard-coded
list. It has
Change by Jeremy Kloth :
--
pull_requests: +10294
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Sorry for the delay, but I wanted to get an environment that still had an older
VS2015 install to test against. VS2015 prior to Update 3 use a different
heuristic to determine the SDK version for building.
I've made the following changes:
- version checking
Jeremy Kloth added the comment:
Not to be impatient or anything, but this change is keeping my buildbot from
being useful. Would it be possible for someone to merge as it has already been
approved (msg331263).
--
___
Python tracker
<ht
Jeremy Kloth added the comment:
> Is it a warning or an error? What is the warning/error message? What is your
> buildbot?
It is a compiler error as you point out below (with message). By buildbot is:
https://buildbot.python.org/all/#/workers/12
> Right now, it seems like on
Jeremy Kloth added the comment:
Sorry Victor, I should have added more context when I nosy'ed you to this issue.
Since you seem to be the "buildbot keeper" as of late, I wanted to give you a
pointer to the reason for my failing buildbot. Which, as I surmised, is
failing c
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10247
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32805>
___
___
Py
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Also, my buildbot *should* fail until this change is merged.
--
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Jeremy Kloth added the comment:
I've added two PRs (GH-11010 and GH-11011) along with bpo-35433 that should get
3.x warning free (finally!) on 64-bit Windows.
--
___
Python tracker
<https://bugs.python.org/issue9
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +10245
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +10244
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10243
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Py
New submission from Jeremy Kloth :
In the process of eliminating compiler warnings on my buildbot, I needed to
update VS2015 to the latest toolset (VS2015 Update 3). This in turn now causes
an error due about not having the required version of Windows SDK installed.
It seems
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue35420>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
As a heavy user of the non-limited Python C API, I would like to offer my
suggestions for consideration. (I'm not allowed to post in discourse)
First off, to me, 'unstable' comes off quite negative, i.e. risky or erratic.
Brett's suggestion of 'broad
Jeremy Kloth added the comment:
The changed succeeded in killing the actively stuck process, so I say its all
good! Thanks for the merge.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracke
Jeremy Kloth added the comment:
It seems my buildbot has a stuck process again.
The "sticking" occurred in this case due to test_concurrent_futures being hung
(for over 38hrs! which is a different issue) and a DSL link reset at the same
time.
So now, all builds on the master b
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +9263
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34980>
___
___
Py
Jeremy Kloth added the comment:
Alternatively, to test for yourself:
1) build a 64-bit python:
> build -e -d -k -v -p x64
2) start the newly built interpreter:
> amd64\python_d.exe
3) in a different command prompt (using dummy target to just do the KillPython)
> build
Jeremy Kloth added the comment:
My testing shows differently:
D:\Public\Devel\cpython\master\PCbuild>set MSBUILD="C:\Program Files
(x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe"
D:\Public\Devel\cpython\master\PCbuild>build -k -v -t foo
Using py -3.6 (found 3.6 with py.exe)
F
New submission from Jeremy Kloth :
Since the KillPython target has been rewritten as an InlineTask, it can no
longer detect 64-bit processes due to MSBuild being 32-bit.
This leads to stuck buildbot runs:
https://buildbot.python.org/all/#/builders/17/builds/348
A few solutions that I can
Jeremy McMillan added the comment:
subclass workaround implementation example
https://github.com/isbm/salt/blob/976fe19d73ca6bf5df375eaa15d77ce4a5a54b7a/salt/_compat.py#L125
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from Jeremy McMillan :
ipaddress module has no support for scoped IPv6 addresses which prevents the
use of ipaddress.ip_address() and ipaddress.IPv6Address() with (always
available by default on IPv6 systems) RFC conforming IPv6 link local addresses
that specify interface
Jeremy Kloth added the comment:
This is also an issue on Windows when the target path resides within a
junction, paths outside of a junction respond (err, fail) as expected.
https://developercommunity.visualstudio.com/content/problem/272379/createfile-non-error-on-filename-with-trailing
Jeremy Kloth added the comment:
Did you attempt to use the 3-line change I posted earlier? I stepped through
to test line-by-line to find the offending piece of code. And it was indeed
the open() call causing the test-tree to be processed prior to it being
completed. Thus making the .py
Jeremy Kloth added the comment:
For pip, in call_subprocess() (given here in rough pseudo-code)
is_python = (cmd[0] == sys.executable)
kwds = {}
if is_python:
env['PYTHONIOENCODING'] = 'utf8'
kwds['encoding'] = 'utf8'
proc = Popen(..., **kwds)
.
.
.
if stdout is not None:
while
Jeremy Kloth added the comment:
Related to issue34421
--
___
Python tracker
<https://bugs.python.org/issue34618>
___
___
Python-bugs-list mailing list
Unsub
New submission from Jeremy Kloth :
When running Python via subprocess with captured output an encoding error
occurs attempting to output a Unicode filename. The same does not happen when
just using spawnl().
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit
(AMD64
Jeremy Kloth added the comment:
The existing re-code solution is being triggered, as the `errors` in this case
is 'surrogateescape' with an encoding of 'cp1252'.
Here, pip is using subprocess.Popen() to have Python run setup.py. During
execution, a filename, 'taqdir\\\u0634\u0645\u0627
Jeremy Kloth added the comment:
Since my buildbot has been infected with this bug, I took some time to hunt it
out. It turns out that issue is caused by an internal import triggered by the
open() function (at least on Windows).
A recent change to the interpreter (commit 9e4994d) changed
Jeremy Kloth added the comment:
The RegisterWaitForSingleObject() function does use the thread pool API:
https://docs.microsoft.com/en-us/windows/desktop/ProcThread/thread-pool-api
However, PdhCollectQueryDataEx() also creates a user-space thread to handle its
work of setting the event
Jeremy Kloth added the comment:
Correct. Windows provides the building blocks for implementing getloadavg(),
but does not provide an interface that does the averaging. That is deferred to
a per application basis. The best that an application can do for that is to
use thread pools. You
Jeremy Kloth added the comment:
Not that it matters all that much, but from a terminology standpoint, WMI !=
PDH != Performance Counters.
Performance counters (the objects, not the topic) are provided by DLLs
registered in the HKLM\SYSTEM\CurrentControlSet\Services key. Their data
Jeremy Kloth added the comment:
Also prior conversation:
https://bugs.python.org/issue30263#msg296311
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue34
101 - 200 of 572 matches
Mail list logo
