[issue35970] no help flag in base64 util
New submission from Robert Kuska : I failed today to print help message for base64 utility without an error: $ python3 -m base64 -help option -h not recognized usage: /usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py [-d|-e|-u|-t] [file|-] -d, -u: decode -e: encode (default) -t: encode and decode string 'Aladdin:open sesame So I felt like this is a ripple in time space continuum worth adjusting. I already opened a PR to address this (probably not so worthy) issue (link attached). -- messages: 335255 nosy: rkuska priority: normal pull_requests: 11851 severity: normal status: open title: no help flag in base64 util ___ Python tracker <https://bugs.python.org/issue35970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26661] python fails to locate system libffi
New submission from Robert Kuska: Python fails to locate system version of ffi when building. We delete bundled version of ffi and build process fail with following error: error: [Errno 2] No such file or directory: '/builddir/build/BUILD/Python-3.5.1/Modules/_ctypes/libffi' This is caused by setup.py@1993 checking only for '#define LIBFFI_H' within ffi.h. Content of /usr/include/ffi.h: > $ cat /usr/include/ffi.h /* This file is here to prevent a file conflict on multiarch systems. */ #ifdef ffi_wrapper_h #error "Do not define ffi_wrapper_h!" #endif #define ffi_wrapper_h #if defined(__i386__) #include "ffi-i386.h" #elif defined(__powerpc64__) #include "ffi-ppc64.h" #elif defined(__powerpc__) #include "ffi-ppc.h" #elif defined(__s390x__) #include "ffi-s390x.h" #elif defined(__s390__) #include "ffi-s390.h" #elif defined(__x86_64__) #include "ffi-x86_64.h" #else #error "The libffi-devel package is not usable with the architecture." #endif #undef ffi_wrapper_h It is important to note that this content is Fedora specific. As a workaround we (Fedora) use attached patch. Would it be plausible to accept this patch in upstream? -- components: Build files: 00184-ctypes-should-build-with-libffi-multilib-wrapper.patch keywords: patch messages: 262598 nosy: rkuska priority: normal severity: normal status: open title: python fails to locate system libffi type: compile error Added file: http://bugs.python.org/file42320/00184-ctypes-should-build-with-libffi-multilib-wrapper.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] Make default HTTPS certificate verification setting configurable
Robert Kuska added the comment:
If test fail it will print out non-telling message which make debugging a
little bit hard:
FAIL: test__https_verify_envvar (test.test_ssl.ContextTests)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-2.7.5/Lib/test/test_ssl.py", line 1143,
in test__https_verify_envvar
assert_python_ok("-c", https_is_verified, **extra_env)
File "/builddir/build/BUILD/Python-2.7.5/Lib/test/script_helper.py", line
55, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File "/builddir/build/BUILD/Python-2.7.5/Lib/test/script_helper.py", line
47, in _assert_python
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Would be possible to change following code which is being executed:
+https_is_verified = """import ssl, sys;\
+sys.exit(ssl._create_default_https_context is not
+ ssl.create_default_context)"""
into something like
https_is_verified = """import ssl, sys;\
value = ssl._create_default_https_context is not ssl.create_default_context;\
sys.exit('ssl._create_default_https_context should be set to verified' if value
else value)"""
So traceback will look like this:
...
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
ssl._create_default_https_context should be set to verified
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23857>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19527] Test failures with COUNT_ALLOCS
Robert Kuska added the comment: With Python-3.5 and COUNT_ALLOCS enabled following new tests fail also: FAIL: test_is_finalizing (test.test_sys.SysModuleTest) -- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.5.0/Lib/test/test_sys.py", line 767, in test_is_finalizing self.assertEqual(stdout.rstrip(), b'True') AssertionError: b'' != b'True' - == FAIL: test_print_traceback_at_exit (test.test_traceback.SyntaxTracebackCases) -- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.5.0/Lib/test/test_traceback.py", line 210, in test_print_traceback_at_exit self.assertEqual(stderr.splitlines(), expected) AssertionError: Lists differ: [] != [b'Traceback (most recent call last):', b'[75 chars]ero'] Second list contains 3 additional elements. First extra element 0: b'Traceback (most recent call last):' - [] + [b'Traceback (most recent call last):', + b' File "", line 8, in __init__', + b'ZeroDivisionError: division by zero'] -- nosy: +rkuska ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19527] Test failures with COUNT_ALLOCS
Robert Kuska added the comment: FYI There is also issue23034 where is proposed "-X showalloccount" option to suppress the output, we use (custom patch) environment variable to filter out the verbose output in Fedora. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22032] Use __qualname__ together with __module__
Robert Kuska added the comment: FYI This also broke nosetests tests which relies on exact output. https://github.com/nose-devs/nose/issues/928 -- nosy: +rkuska ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] Make default HTTPS certificate verification setting configurable via global ini file
Robert Kuska added the comment: Le 06/04/2015 13:29, Nick Coghlan a écrit : So while this isn't a feature upstream itself needs, it's one potentially needed by multiple *downstreams*, so in my view it makes sense for us to work with upstream to come up with the one obvious way for redistributors to handle the problem (now that we know that my initial attempt at providing such a way doesn't work in practice). So would it be possible for the actual implementation to be done outside of CPython? (in a dedicated fork, for example) Yes it would and most likely will be, but as Nick pointed out, it is important to come up with the one obvious way. I understand why my patch is not acceptable for the upstream, it was my first shot (yet suitable for us) to start a discussion about cert verification. From the proposed solutions mentioned I favour the ENV variable which would address also Donald concerns, using ENV variable per application to enable/disable cert verification instead of global enable/disable, (yet it could be also `export`ed for global settings), are there any real disadvantages of using this method? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] [RFE] Make certificate verification optionable
Changes by Robert Kuska rku...@gmail.com: -- nosy: +bkabrda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] [RFE] Make certificate verification optionable
Robert Kuska added the comment: 1) patch attached, dunno how I missed it, thank you. 3) I work for Red Hat additional interest for example here http://seclists.org/oss-sec/2015/q1/785 2) It exists but it is not system wide, I would like to provide users option to opt-in or opt-out without interfering with code. There are many of users who rely on python and not all of them are programmers. -- keywords: +patch Added file: http://bugs.python.org/file38817/custom-cert-verify.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] [RFE] Make certificate verification optionable
Robert Kuska added the comment: If you mean hack site.py to be sitecustomize I don't find it as a sufficient solution because users may use their own sitecustomize and this way we would replace theirs. Sslcustomize solution could be another option how to handle this but the config idea seems to me much more easier (also from the linux user POV). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] [RFE] Make certificate verification optionable
Robert Kuska added the comment: ( ^ I was replying to Victor) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23857 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23857] [RFE] Make certificate verification optionable
New submission from Robert Kuska:
Proposed patch adds possibility to opt-out certificate verification.
Disclaimer: it is just proof of concept as the config value is hard-coded.
How it works?
This patch depends on existence of config file which holds information about
the protocol settings.
$ cat cert-verification.conf
[https] # each protocol affected by cert-verification got its own section
verify=platform_default
Possible values for verify are:
enable - to enable certificate verification
disable - to disable certificate verification
platform_default - to use default (platform-specific) settings
Why platform_default?
This choice is for users who don't care about the security settings so they put
the decision into their platform (distro) from which they get python. In rpm we
can set package to not replace user edited configs when rpm is updated, so if
user change the default value of config the config will remain the same.
Python example:
import http.client
cn = http.client.HTTPSConnection('www.google.com')
cn._context.verify_mode
0L # CERT_NONE
# config changed to verify=enable, still same interpreter
cn2 = http.client.HTTPSConnection('www.google.com')
cn2._context.verify_mode
2L # CERT_REQUIRED
This is how currently works patch attached, but I guess it would make more
sense make this behave consistent within the same interpreter even when config
is changed and the change will be propagated in the next interpreter
run/service restart.
Also the patch could be changed to instead of being protocol based to be module
based, but this would need also patching the affected modules.
I open the RFE mainly to see if there is a will to implement optionable
certificate verification in upstream as it is in downstream [citation needed].
I've added some people to nosy list based on
https://docs.python.org/devguide/experts.html
--
components: Library (Lib)
messages: 239965
nosy: alex, dstufft, haypo, janssen, ncoghlan, pitrou, rkuska
priority: normal
severity: normal
status: open
title: [RFE] Make certificate verification optionable
type: enhancement
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23857
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23769] valgrind reports leaks for test_zipimport
Robert Kuska added the comment: I tried leak2.py with valgrind, I've uncommented the lines you mentioned. $ valgrind python3 leak2.py ==28421== Memcheck, a memory error detector ==28421== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==28421== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==28421== Command: python3 leak2.py ==28421== ==28421== ==28421== HEAP SUMMARY: ==28421== in use at exit: 1,599,354 bytes in 11,594 blocks ==28421== total heap usage: 284,971 allocs, 273,377 frees, 37,976,898 bytes allocated ==28421== ==28421== LEAK SUMMARY: ==28421==definitely lost: 0 bytes in 0 blocks ==28421==indirectly lost: 0 bytes in 0 blocks ==28421== possibly lost: 597,482 bytes in 2,319 blocks ==28421==still reachable: 1,001,872 bytes in 9,275 blocks ==28421== suppressed: 0 bytes in 0 blocks ==28421== Rerun with --leak-check=full to see details of leaked memory ==28421== ==28421== For counts of detected and suppressed errors, rerun with: -v ==28421== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) I've removed `import readline` from leak2.py, everything else left as in previous run (also ofc removed tracemalloc). $ valgrind python3 leak3.py ==28515== Memcheck, a memory error detector ==28515== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==28515== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==28515== Command: python3 leak2.py ==28515== ==28515== ==28515== HEAP SUMMARY: ==28515== in use at exit: 1,599,384 bytes in 11,595 blocks ==28515== total heap usage: 285,648 allocs, 274,053 frees, 38,126,379 bytes allocated ==28515== ==28515== LEAK SUMMARY: ==28515==definitely lost: 30 bytes in 1 blocks ==28515==indirectly lost: 0 bytes in 0 blocks ==28515== possibly lost: 597,375 bytes in 2,317 blocks ==28515==still reachable: 1,001,979 bytes in 9,277 blocks ==28515== suppressed: 0 bytes in 0 blocks ==28515== Rerun with --leak-check=full to see details of leaked memory ==28515== ==28515== For counts of detected and suppressed errors, rerun with: -v ==28515== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Duh? Why does readline have this effect? -- Added file: http://bugs.python.org/file38684/leak3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23769] valgrind reports leaks for test_zipimport
Changes by Robert Kuska rku...@gmail.com: Added file: http://bugs.python.org/file38673/report ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23769] valgrind reports leaks for test_zipimport
New submission from Robert Kuska: Leaks happen only when both testDoctestFile and testDoctestSuite are run. Run with Python 3.4.2 and 3.4.1 with same result. I have extracted those two tests into `leak.py` (attached). $ valgrind --suppressions=/../cpython/Misc/valgrind-python.supp python3 leak.py ==17896== Memcheck, a memory error detector ==17896== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17896== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==17896== Command: python3 leak.py ==17896== ==17896== ==17896== HEAP SUMMARY: ==17896== in use at exit: 1,599,328 bytes in 11,595 blocks ==17896== total heap usage: 283,757 allocs, 272,162 frees, 37,891,147 bytes allocated ==17896== ==17896== LEAK SUMMARY: ==17896==definitely lost: 30 bytes in 1 blocks ==17896==indirectly lost: 0 bytes in 0 blocks ==17896== possibly lost: 597,418 bytes in 2,319 blocks ==17896==still reachable: 1,001,880 bytes in 9,275 blocks ==17896== suppressed: 0 bytes in 0 blocks ==17896== Rerun with --leak-check=full to see details of leaked memory ==17896== ==17896== For counts of detected and suppressed errors, rerun with: -v ==17896== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Note that when I remove support.modules_cleanup(*modules_before) from leak.py valgrind reports no leaks (in original test_zipimport those are run in setUp and tearDown). Output of valgrind --suppressions=/home/rkuska/upstream/cpython/Misc/valgrind-python.supp --leak-check=yes -v python3 leak.py attached as `report`. -- components: Tests files: leak.py messages: 239193 nosy: rkuska priority: normal severity: normal status: open title: valgrind reports leaks for test_zipimport versions: Python 3.4 Added file: http://bugs.python.org/file38672/leak.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23769] valgrind reports leaks for test_zipimport
Robert Kuska added the comment: Summary for valgrind python3 test_zipimport.py ==18608== ==18608== HEAP SUMMARY: ==18608== in use at exit: 1,596,390 bytes in 11,536 blocks ==18608== total heap usage: 343,849 allocs, 332,313 frees, 59,355,776 bytes allocated ==18608== ==18608== LEAK SUMMARY: ==18608==definitely lost: 90 bytes in 3 blocks ==18608==indirectly lost: 0 bytes in 0 blocks ==18608== possibly lost: 594,488 bytes in 2,258 blocks ==18608==still reachable: 1,001,812 bytes in 9,275 blocks ==18608== suppressed: 0 bytes in 0 blocks ==18608== Rerun with --leak-check=full to see details of leaked memory ==18608== ==18608== For counts of detected and suppressed errors, rerun with: -v ==18608== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23249] test_win32 fails on aarch64
Robert Kuska added the comment: Sorry for the late answer, I forgot about this issue. 3.2.1 doesn't contain required fix(sorry for the misleading suggestion 'or update bundled libffi' from report) but master branch at upstream repo (https://github.com/atgreen/libffi) does. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23249 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23420] python -m cProfile -s fails with non informative message
New submission from Robert Kuska: Originaly reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1160640 I've forgotten to add the sort value to the -s option of cProfile which results in a traceback instead of user friendly error message. In the example below hello.py just prints a Hello World: $ python -m cProfile -s hello.py Traceback (most recent call last): File /usr/lib64/python2.6/runpy.py, line 122, in _run_module_as_main __main__, fname, loader, pkg_name) File /usr/lib64/python2.6/runpy.py, line 34, in _run_code exec code in run_globals File /usr/lib64/python2.6/cProfile.py, line 190, in module main() File /usr/lib64/python2.6/cProfile.py, line 185, in main parser.print_usage() File /usr/lib64/python2.6/optparse.py, line 1597, in print_usage print file, self.get_usage() File /usr/lib64/python2.6/optparse.py, line 1583, in get_usage self.expand_prog_name(self.usage)) File /usr/lib64/python2.6/optparse.py, line 1560, in expand_prog_name return s.replace(%prog, self.get_prog_name()) File /usr/lib64/python2.6/optparse.py, line 1555, in get_prog_name return os.path.basename(sys.argv[0]) IndexError: list index out of range Tested with python2.7, python3.4 with the same result. Attached patch adds `choices` for sort option of cProfile. $ python -m cProfile -s sdds.py Usage: cProfile.py [-o output_file_path] [-s sort] scriptfile [arg] ... cProfile.py: error: option -s: invalid choice: 'sdds.py' (choose from 'cumulative', 'module', 'ncalls', 'pcalls', 'file', 'line', 'name', 'calls', 'stdname', 'nfl', 'filename', 'cumtime', 'time', 'tottime') -- components: Extension Modules files: sort-choices.patch keywords: patch messages: 235602 nosy: rkuska priority: normal severity: normal status: open title: python -m cProfile -s fails with non informative message type: enhancement versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38053/sort-choices.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23420] python -m cProfile -s fails with non informative message
Changes by Robert Kuska rku...@gmail.com: Added file: http://bugs.python.org/file38055/sort-choices.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23420] python -m cProfile -s fails with non informative message
Changes by Robert Kuska rku...@gmail.com: Added file: http://bugs.python.org/file38054/sort-choices.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23249] test_win32 fails on aarch64
New submission from Robert Kuska:
Original bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1174037
Additional informations at Issue #20160
Note that this was reproduced not only with separate libffi package but also
with libffi bundled in python.
Reproduced with Python 2.7.9 but same issue should exists also in 3.4.x.
Richard Henderson provided fix in original bug report at bugzilla (attached).
Summary:
==
FAIL: test_struct_by_value (ctypes.test.test_win32.Structures)
--
Traceback (most recent call last):
File /builddir/build/BUILD/Python-2.7.9/Lib/ctypes/test/test_win32.py, line
112, in test_struct_by_value
self.assertEqual(ret.left, left.value)
AssertionError: -200 != 10
--
(gdb) b ReturnRect
Function ReturnRect not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ReturnRect) pending.
(gdb) run test_win32.py
Starting program: /usr/bin/python test_win32.py
Missing separate debuginfos, use: debuginfo-install
glibc-2.20.90-12.fc22.aarch64
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Breakpoint 1, ReturnRect (i=0, ar=..., br=0x59b750, cp=..., dr=...,
er=0x59b750, fp=...,
gr=error reading variable: Cannot access memory at address
0x)
at /usr/src/debug/Python-2.7.9/Modules/_ctypes/_ctypes_test.c:552
552 if (ar.left + br-left + dr.left + er-left + gr.left != left * 5)
(gdb) p fp
$1 = {x = 4396722194992, y = 5879632}
(gdb) p cp
$2 = {x = 15, y = 25}
(gdb)
Consider to apply a patch or update bundled libffi.
--
components: ctypes
files: libffi-henderson
messages: 234119
nosy: rkuska
priority: normal
severity: normal
status: open
title: test_win32 fails on aarch64
type: crash
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37723/libffi-henderson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23249
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23249] test_win32 fails on aarch64
Changes by Robert Kuska rku...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file37724/libffi-mattip.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23249 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Robert Kuska added the comment: I have created #23249. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Robert Kuska added the comment: FYI The bug was found in libffi. I have tried and rebuilt python also with *bundled libffi* with the *same result* (=test failure). There is more info in the bugzilla mentioned in my previous post along with the libffi patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Robert Kuska added the comment:
This commit (probably) breaks aarch64 python build.
See https://bugzilla.redhat.com/show_bug.cgi?id=1174037
Build was done with libffi 3.1.6, I have also tried with latest upstream libffi
version with same result.
(gdb) b ReturnRect
Function ReturnRect not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ReturnRect) pending.
(gdb) run test_win32.py
Starting program: /usr/bin/python test_win32.py
Missing separate debuginfos, use: debuginfo-install
glibc-2.20.90-12.fc22.aarch64
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Breakpoint 1, ReturnRect (i=0, ar=..., br=0x59b750, cp=..., dr=...,
er=0x59b750, fp=...,
gr=error reading variable: Cannot access memory at address
0x)
at /usr/src/debug/Python-2.7.9/Modules/_ctypes/_ctypes_test.c:552
552 if (ar.left + br-left + dr.left + er-left + gr.left != left * 5)
(gdb) p fp
$1 = {x = 4396722194992, y = 5879632}
(gdb) p cp
$2 = {x = 15, y = 25}
(gdb)
--
nosy: +rkuska
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20160
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Robert Kuska added the comment: FYI fedora (rawhide) has SSLv3 disabled in SSLv23 method of openssl package. http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=80b5477597e9f0d9fababd854adfb4988b37efd5 This looks like the same approach as in attached issue22638.diff. -- nosy: +rkuska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21308] PEP 466: backport ssl changes
Robert Kuska added the comment: Hi everyone, I went ahead and I've applied ssl-backport.diff (alex, 2014-08-07 18:49) patch into Python 2.7.8 on Fedora Rawhide (currently only scratch build). My report: Firstly, I've encountered seg fault, I fixed this with patch from http://bugs.python.org/issue22023 Next issue was/is distro specific, there is disabled SSLv2 protocol when SSLv23_method is used[0]. However python3 builds fine[1]: In test_ssl.py:test_protocol_sslv23 when calling try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_SSLv2, True) this will raise an OSError on python3 but this error is caught by test. In python 2 this will raise a socket.error[2] instead, but test_protocol_sslv23 is catching ssl.SSLError, shouldn't be that changed to socket.error so both python2 and python3 behave the same? [0] SSLv23 http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl-1.0.1h-disable-sslv2v3.patch [1] Python3 build https://kojipkgs.fedoraproject.org//work/tasks/9993/733/build.log (search for test_protocol_sslv23) [2] Python2 build https://kojipkgs.fedoraproject.org//work/tasks/9367/7399367/build.log (search for test_protocol_sslv23) -- nosy: +rkuska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298835] Add a vendor-packages directory for system-supplied modules
Robert Kuska added the comment: Ok, I have started a thread at pypa-devs google group. https://groups.google.com/forum/#!topic/pypa-dev/r6qsAmJl9t0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298835 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298835] Add a vendor-packages directory for system-supplied modules
Robert Kuska added the comment: There is ongoing discussion on pip's github tracker [1] about default location where to install user modules. IMO this is something that should be dealt with in Python Interpreter Core [2][3]. I would like to hear some opinion from python devs on this. [1] https://github.com/pypa/pip/issues/1668 [2] https://github.com/pypa/pip/issues/1668#issuecomment-38418185 [3] https://github.com/pypa/pip/issues/1668#issuecomment-38428857 -- nosy: +rkuska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298835 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
