[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

Matthias Klose added the comment: steve, please can we keep this issue open until this is forwarded and accepted upstream? -- nosy: +doko resolution: fixed -> remind status: closed -> open ___ Python tracker <http://bugs.python.org/i

[issue22827] Backport ensurepip to 2.7 (PEP 477)

Matthias Klose added the comment: The mock backport doesn't come with a license. Please either include it in the file, or make it clear that the backport has the same license as python (?). -- nosy: +michael.foord ___ Python tracker

[issue22851] core crashes

New submission from Matthias Klose: seen with the current 2.7 branch: $ cat > x.py def foo(): yield gen = foo() print gen.gi_frame.f_restricted for i in gen: pass print gen.gi_frame gen = foo() print gen.next() print gen.gi_frame.f_restricted $ python x.py False None None Segmentation fa

[issue22462] Modules/pyexpat.c violates PEP 384

Matthias Klose added the comment: according to https://jenkins.qa.ubuntu.com/job/vivid-adt-python3.4/7/ test.test_pyexpat.HandlerExceptionTest now fails, but only when running in the installed location, not when running the tests from the builddir. any idea why? -- nosy: +doko

[issue22895] regression introduced by the fix for issue #22462

New submission from Matthias Klose: the fix for issue #22462 introduces a regression in the test_pyexpat test cases. I'm not yet sure why. This is only seen when running the testsuite from the installed location, which shouldn't matter. Tried to run the tests with a stripped exe

[issue22895] regression introduced by the fix for issue #22462

Matthias Klose added the comment: [258/383] test_pyexpat test test_pyexpat failed -- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_pyexpat.py", line 432, in test_exception parser.Parse(b"", 1) File "../Modules/pyexpat.c", line 405, in

[issue17750] allow the testsuite to run in the installed location

Changes by Matthias Klose : -- dependencies: +test failure introduced by the fix for issue #22462 ___ Python tracker <http://bugs.python.org/issue17750> ___ ___

[issue22895] test failure introduced by the fix for issue #22462

Matthias Klose added the comment: do we have something like skipIfInstalled? -- ___ Python tracker <http://bugs.python.org/issue22895> ___ ___ Python-bugs-list m

[issue22935] Disabling SSLv3 support

Matthias Klose added the comment: maybe it's time to generalise this one, still found on all branches: # Issue #9415: Ubuntu hijacks their OpenSSL and forcefully disables SSLv2 def skip_if_broken_ubuntu_ssl(func): -- nosy: +doko ___ Python tr

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Matthias Klose added the comment: seen as well with 3.3 -- keywords: +3.3regression, 3.4regression nosy: +doko ___ Python tracker <http://bugs.python.org/issue22

[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc

Matthias Klose added the comment: proposed patch: diff -r 8dacb1a21793 Lib/importlib/_bootstrap.py --- a/Lib/importlib/_bootstrap.py Fri Nov 28 13:15:41 2014 +0100 +++ b/Lib/importlib/_bootstrap.py Mon Dec 01 17:05:00 2014 +0100 @@ -453,7 +453,7 @@ else: suffixes

[issue12987] Demo/scripts/newslist.py has non-free licensing terms

Matthias Klose added the comment: thanks for bringing this up. I don't agree that the non-availability in the windows build should be used to close the issue. Linux distros distribute the source, and are still affected? If it's already removed in Python3, why not remove it he

[issue16041] poplib: unlimited readline() from connection

Matthias Klose added the comment: this looks ok to me, can we apply this for 2.7.9? -- nosy: +doko ___ Python tracker <http://bugs.python.org/issue16041> ___ ___

[issue16042] smtplib: unlimited readline() from connection

Changes by Matthias Klose : -- nosy: +doko ___ Python tracker <http://bugs.python.org/issue16042> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16043] xmlrpc: gzip_decode has unlimited read()

Matthias Klose added the comment: updated patch to use an optional parameter "max_decode". -- nosy: +doko Added file: http://bugs.python.org/file37343/xmlrpc_gzip_27_parameter.patch ___ Python tracker <http://bugs.python.o

[issue16043] xmlrpc: gzip_decode has unlimited read()

Matthias Klose added the comment: document the new exception -- Added file: http://bugs.python.org/file37344/xmlrpc_gzip_27_parameter.patch ___ Python tracker <http://bugs.python.org/issue16

[issue23085] update internal libffi copy to 3.1

Matthias Klose added the comment: some issues: - the local change for Windows still needs upstream forwarding. Steve, any progress on this? - the libffi.diff is not updated (including Steve's changes) - this should be applied to 2.7 as well. -- nosy: +steve.dower, tim.g

[issue23085] update internal libffi copy to 3.2.1

Matthias Klose added the comment: you should actively drive upstream integration, and ping patches if they are not addressed. -- ___ Python tracker <http://bugs.python.org/issue23

[issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5

New submission from Matthias Klose: richi: https://github.com/nemomobile-packages/python3/blob/master/Modules/faulthandler.c#L903 richi: LD_LIBRARY_PATH=/builddir/build/BUILD/Python-3.4.2/build/debug/ /builddir/build/BUILD/Python-3.4.2/build/debug/python -E -c 'import faultha

[issue24295] Backport of #17086 causes regression in setup.py

Matthias Klose added the comment: I'll look at this in June. I don't think that reverting is the right choice here. -- ___ Python tracker <http://bugs.python.o

[issue24705] sysconfig._parse_makefile doesn't expand ${} vars appearing before $() vars

New submission from Matthias Klose: LIPL has the value ${prefix}/lib/python3.5/config-$(VERSION)$(ABIFLAGS)-x86_64-linux-gnu and the code relies to substitute parameters from the left to the right, but it prefers $() variables. the attached patch substitutes all variables from the left to

[issue24705] sysconfig._parse_makefile doesn't expand ${} vars appearing before $() vars

Matthias Klose added the comment: On 07/24/2015 03:14 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Could you please provide an example where unpatched code fails but patched > code work? yes, see the substitution for the LIBPL macro, which

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: thanks for the draft! I'm not sure how to describe this properly. The extension names are derived from https://wiki.debian.org/Multiarch/Tuples and this again is derived from the GNU triplets/quadruplets. there is no "cpu" and "os&quo

[issue25109] test_code_module tests fail when run from the installed location

New submission from Matthias Klose: seen when running the tests in the installed location: the test expects: Traceback (most recent call last): File "", line 1, in ValueError but it gets: Traceback (most recent call last): File "/usr/lib/python3.5/code.py", line 91,

[issue17750] allow the testsuite to run in the installed location

Changes by Matthias Klose : -- dependencies: +test_code_module tests fail when run from the installed location ___ Python tracker <http://bugs.python.org/issue17

[issue17781] optimize compilation options

Matthias Klose added the comment: On 22.09.2015 12:31, Antoine Pitrou wrote: > Also note LTO can make compilation times much longer (it's the linking step > actually, which can take minutes). use -flto=jobserver -- ___ Python tra

[issue24931] _asdict breaks when inheriting from a namedtuple

Matthias Klose added the comment: reopening. the incompatible behavior is report in a Debian report as well. """ collections.namedtuple appears to not to create namedtuples which have the __dict__ attribute any more. Given that the stdlib docs stated that using vars() (and henc

[issue24931] _asdict breaks when inheriting from a namedtuple

Matthias Klose added the comment: now marked as regression, and lowered the priority. but how should regressions on release branches be marked else? -- keywords: +3.4regression, 3.5regression -patch priority: release blocker -> high ___ Pyt

[issue25440] python3.4-config --extension-suffix not expanded

New submission from Matthias Klose: $ python3.4-config --extension-suffix @SO@ this is fallout from issue #16754. Use EXT_SUFFIX directly in the shell script, which then gets expanded by configure. -- messages: 253177 nosy: doko priority: normal severity: normal status: open title

[issue25440] python3.4-config --extension-suffix not expanded

Changes by Matthias Klose : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue25440> ___ ___ Python-bugs-list

[issue25613] fix ssl tests with sslv3 disabled

New submission from Matthias Klose: Linux distributions (now starting with the Ubuntu development version for 16.04 LTS) are starting to disable SSLv3, letting at least two test_ssl tests fail. a partial fix is mentioned in https://launchpad.net/bugs/1515793 -- messages: 254573 nosy

[issue25698] test regressions introduced with the fix for #22995

New submission from Matthias Klose: seen with the 2.7.11 release candidate; I'm not yet 100% if this is the fix for #22995 causing these test regressions. [ 93/395] test_cpickle test test_cpickle failed -- multiple errors occurred; run in verbose mode for details [101/395/2] test_decimal

[issue25698] test regressions introduced with the fix for #22995

Matthias Klose added the comment: looks like re-running the tests in verbose mode using -w is affected by this issue. the first cpickle subtest failing is: == ERROR: test_recursive_dict_subclass_and_inst

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

Matthias Klose added the comment: this is not "fixable". and now when parsing os-release you get different values then you got before, e.g. changing "Ubuntu" to "ubuntu". -- ___ Python tracker <

[issue26621] test_decimal fails with libmpdecimal 2.4.2

New submission from Matthias Klose: test_decimal fails with libmpdecimal 2.4.2 that's because Lib/_pydecimal.py hardcodes __libmpdec_version__ = "2.4.1" # compatible libmpdec version -- components: Extension Modules messages: 262260 nosy: doko, skrah priority: normal s

[issue26621] test_decimal fails with libmpdecimal 2.4.2

Matthias Klose added the comment: please apply this to the 3.5 branch as well -- status: closed -> open ___ Python tracker <http://bugs.python.org/issu

[issue26839] python always calls getrandom() at start, causing long hang after boot

New submission from Matthias Klose: [forwarded from https://bugs.debian.org/822431] This regression / change of behaviour was seen between 20160330 and 20160417 on the 3.5 branch. The only check-in which could affect this is the fix for issue #26735. 3.5.1-11 = 20160330 3.5.1-12 = 20160417

[issue26839] python always calls getrandom() at start, causing long hang after boot

Matthias Klose added the comment: other issues fixed between these dates: - Issue #26659: Make the builtin slice type support cycle collection. - Issue #26718: super.__init__ no longer leaks memory if called multiple times. NOTE: A direct call of super.__init__ is not endorsed

[issue26673] Tkinter error when opening IDLE configuration menu (Tcl/Tk 8.6)

Matthias Klose added the comment: Seen on Debian and Ubuntu as well. All these distros have in common to use Tcl/Tk 8.6. -- nosy: +doko title: Tkinter error when opening IDLE configuration menu -> Tkinter error when opening IDLE configuration menu (Tcl/Tk

[issue26673] Tkinter error when opening IDLE configuration menu (Tcl/Tk 8.6)

Matthias Klose added the comment: using this as a work-around, not tested with Tcl/Tk 8.5 or older. --- a/Lib/idlelib/configDialog.py +++ b/Lib/idlelib/configDialog.py @@ -113,7 +113,11 @@ class ConfigDialog(Toplevel): def CreatePageFontTab(self): parent = self.parent

[issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault

Matthias Klose added the comment: 2.7.11+ translates to 20160330 from the 2.7 branch. -- ___ Python tracker <http://bugs.python.org/issue27052> ___ ___ Python-bug

[issue22079] Ensure in PyType_Ready() that base class of static type is static

Matthias Klose added the comment: reopening, this breaks some stuff in several places ... https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 -- nosy: +doko resolution: fixed -> status: closed -> open ___ Python tracker

[issue23555] behavioural change in argparse set_defaults in python 2.7.9

New submission from Matthias Klose: seen with ceph, https://launchpad.net/bugs/1413321 This appears to be a regression in the argparse package in python; under trusty ceph-disk works just fine, however in vivid, the cluster attribute remains unset (despite having a default of '

[issue7352] pythonx.y-config --ldflags out of /usr and missing -L

Matthias Klose added the comment: this seems to work for me: $ python-config --ldflags -L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions the patch is incomplete, no patch for the shell

[issue22359] Remove incorrect uses of recursive make

Matthias Klose added the comment: reopening, breaks cross builds. I'll have a look -- resolution: fixed -> status: closed -> open ___ Python tracker <http://bugs.python.

[issue22625] When cross-compiling, don’t try to execute binaries

Matthias Klose added the comment: there are two approaches here, one to check in generated files and try to avoid the rebuild, or completely fix the cross build. I think the patch for the parallel build just was a bit over-eager -- ___ Python

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

New submission from Matthias Klose: an unreleased version of cinder fails a test when run with python 2.7 from the branch. I don't have a test case yet, but looking at the error message and list of fixed issues after the 2.7.9 release, the fix for issue #23098 could be the culprit.

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

Matthias Klose added the comment: so the culprit is an "optimization": "Committed to 2.7 with small change: stat() and makedev() should return int instead of long if possible." the test case however expects a long. st_dev is now not always a long, but an int or long de

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

Matthias Klose added the comment: no, simpler: >>> import os >>> os.minor(os.makedev(8,65)) Traceback (most recent call last): File "", line 1, in SystemError: ../Objects/longobject.c:998: bad argument to internal function >>> os.major(os.makedev(8,

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

Matthias Klose added the comment: casting to a long works ... >>> os.major(long(os.makedev(8,65))) 8 so maybe revert that optimization for the released branches? -- ___ Python tracker <http://bugs.python.or

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

Changes by Matthias Klose : -- nosy: +benjamin.peterson priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue23842> ___ ___ Py

[issue23917] please fall back to sequential compilation when concurrent doesn't exist

New submission from Matthias Klose: issue #16104 introduces parallel byte compilation, however the method is now overly strict when workers > 1 and no concurrent support available. Please just fall back to sequential byte compilation in this case. -- components: Library (

[issue23918] symbols namespace pollution

New submission from Matthias Klose: 3.5 introduces the symbols: DirEntryType ScandirIteratorType introduced by the fix for issue #22524. These should either be local symbols, or prefixed with _Py or Py. -- components: Extension Modules messages: 240512 nosy: doko, haypo priority

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: I plan to revert this "fix" and replace it with a more general solution, at least for POSIX based systems. Ad hoc introduction of the bitness is at least wrong or not helpful for x32 and ARM ilp32. (currently at PyCon, and would like to discuss t

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: here is the more general approach encoding the triplet into the extension name. This is tested with GCC and clang (clang at least on x86_64, x86, powerpc, powerpc64le, arm and aarch64. -- Added file: http://bugs.python.org/file38964/ma.diff

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: @barry, worth updating PEP 3149? -- ___ Python tracker <http://bugs.python.org/issue22980> ___ ___ Python-bugs-list mailin

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/13/2015 11:01 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> here is the more general approach encoding the triplet into the extension >> name. > > Thanks. Two comments: > - is it possible to avoid t

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/13/2015 11:43 PM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Maintaining the arch list can be delegated to the platform maintainers, but I > agree a test would be valuable. > > I'd suggest a test in the platfo

[issue22631] Feature Request CAN_RAW_FD_FRAMES

Matthias Klose added the comment: it would be nice to have these constants backported to both 2.7 and 3.4. It may be good to check for other missing consgtants in this module in 2.7 and 3.4. -- nosy: +doko ___ Python tracker <http://bugs.python.

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: updated patch and test case. Nick's suggestion to use platform.machine() for the test is wrong. This would test for the environment, not for the just built binary. Try to run a 32bit executable on a 64bit kernel, you'll see x86_64. Same

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

New submission from Matthias Klose: Currently there is only one platform directory for all linux architectures, there are two reasons to have a separate directory for each architecture: - the contents of the files in this directory differ (most prominent case are the RTLD_* constants on

[issue23969] please set a SOABI for MacOSX

New submission from Matthias Klose: split out from http://bugs.python.org/issue22980#msg232065 please consider setting the SOABI for MacOSX. Afaics MacOSX is now the only major platform not setting these, at least including the SOABI. The idea is that it would be possible to ship &quo

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: now fixed on the trunk. opened a new issue #23969 for setting the SOABI on MacOSX. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue23969] please set a SOABI for MacOSX

Matthias Klose added the comment: what about iOS? isn't __APPLE__ there defined too? -- ___ Python tracker <http://bugs.python.org/issue23969> ___ ___ Pytho

[issue23670] Modifications to support iOS as a cross-compilation target

Matthias Klose added the comment: not reviewing everything, but - libffi_ios* will be bitrot. I understand that you'll need an unreleased version, however I would much prefer that any additional patches are added in the repo, and maybe then patching libffi from the iOS

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. What you describe as a "simple idea"

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/16/2015 05:56 PM, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 16.04.2015 17:30, Matthias Klose wrote: >> >> Matthias Klose added the comment: >> >> Nick filed issue #23966 to document t

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: > I'm not trying to discredit any use cases, I just don't see them. so why do you see this on x86 for 32/64bit, but not for ARM soft-float/hard-float. The example given was pretty clear. > All Linux distributions I know place the 32-bit and

[issue24125] Fix for #23865 breaks docutils

Changes by Matthias Klose : -- nosy: +benjamin.peterson priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue24125> ___ ___ Py

[issue24122] Install fails after configure sets the extending/embedding install directory to NONE

Changes by Matthias Klose : -- assignee: -> doko ___ Python tracker <http://bugs.python.org/issue24122> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24122] Install fails after configure sets the extending/embedding install directory to NONE

Matthias Klose added the comment: fixed for 3.4 and 3.5. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu

New submission from Matthias Klose: I see this on i586-linux-gnu and i686-linux-gnu. Reverting the 95844:fb6c2fbbde34 commit makes the problem go away. python: ../Modules/_collectionsmodule.c:711: deque_del_item: Assertion `i >= 0 && i < (((PyVarObject*)(deque))->ob_size)&

[issue24198] please align the platform tag for windows

New submission from Matthias Klose: Steve, I'd like to align the platform tag across platforms to "something" uniform. For POSIX systems we currently use the form --. This is derived from the autoconf host definition. Currently the windows builds use "win32&qu

[issue24198] please align the platform tag for windows

Matthias Klose added the comment: no, I mean something like the attached patch. get_platform() is dependent on the environment, not the platform that python was built for (e.g. it tells you x86_64 when running a 32bit python) on a 64bit kernel). -- keywords: +patch Added file: http

[issue24226] [3.5 Regression] unable to byte-compile the attached IN.py

New submission from Matthias Klose: seen while byte-compiling the attached IN.py on x86_64-linux-gnu. $ python3.5 -m py_compile IN.py Sorry: IndentationError: too many levels of indentation (IN.py, line 806) the very same IN.py is accepted by 3.4. -- components: Library (Lib

[issue24226] [3.5 Regression] unable to byte-compile the attached IN.py

Changes by Matthias Klose : Added file: http://bugs.python.org/file39418/IN.py ___ Python tracker <http://bugs.python.org/issue24226> ___ ___ Python-bugs-list mailin

[issue24226] [3.5 Regression] unable to byte-compile the attached IN.py

Matthias Klose added the comment: looks like a parser issue: $ for i in $(seq 200); do echo "def f$i(x): return (x)" >> foo.py; done $ python3.5 -m py_compile foo.py Sorry: IndentationError: too many levels of indentation (foo.py, line 100) $ for i in $(seq 200); do echo "

[issue24226] [3.5 Regression] unable to byte-compile the attached IN.py

Matthias Klose added the comment: this seems to be caused by the PEP 492 merge in r95969. -- nosy: +yselivanov ___ Python tracker <http://bugs.python.org/issue24

[issue24226] [3.5 Regression] unable to byte-compile the attached IN.py

Changes by Matthias Klose : -- components: +Interpreter Core -Library (Lib) ___ Python tracker <http://bugs.python.org/issue24226> ___ ___ Python-bugs-list mailin

[issue23969] please set a SOABI for MacOSX

Matthias Klose added the comment: so what you could do is to define more than one SOABI. The code in Python/dynload_shlib.c reads: "." SOABI ".so", ".abi" PYTHON_ABI_STRING ".so", ".so", so it still recognizes .so names. If yo

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

Matthias Klose added the comment: ping? I would like to get this into 3.5. -- keywords: +needs review -patch ___ Python tracker <http://bugs.python.org/issue23

[issue27917] Choose platform triplets for android builds

New submission from Matthias Klose: Following up to http://bugs.python.org/issue23968, I think we should choose different platform triplets for the android builds than we do for the linux builds. Not sure which ones. I saw the following gnu triplets used: - i686-linux-android - arm-linux

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

Matthias Klose added the comment: I don't see how the suggested android fix is related, and what it is supposed to fix. It adds the env command before setting the environment variables, which should be a no-op. However I think we should introduce different platform triplets for an

[issue27917] Choose platform triplets for android builds

Changes by Matthias Klose : -- nosy: +Chi Hsuan Yen ___ Python tracker <http://bugs.python.org/issue27917> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27917] Choose platform triplets for android builds

Matthias Klose added the comment: hmm, should the android api level be part of the platform triplet? or are these not relevant for modules? -- ___ Python tracker <http://bugs.python.org/issue27

[issue27917] Choose platform triplets for android builds

Matthias Klose added the comment: here's a patch, not yet including the ABI levels. I think we didn't need them for Linux, and maybe start for Android without using them. You can later introduce these if you have to. -- keywords: +patch Added file: http://bugs.python.org

[issue27917] Choose platform triplets for android builds

Matthias Klose added the comment: yes, it should follow the gnu triplets. I updated these, and added some for mips. However I can't check if the mips ones will do what they are supposed to do. Please could you check these if you have cross compilers available? -- Added file:

[issue27917] Choose platform triplets for android builds

Changes by Matthias Klose : Removed file: http://bugs.python.org/file44327/android.diff ___ Python tracker <http://bugs.python.org/issue27917> ___ ___ Python-bugs-list m

[issue27917] Choose platform triplets for android builds

Matthias Klose added the comment: I think that's good for now. The compiler checks maybe can be later adjusted. -- ___ Python tracker <http://bugs.python.org/is

[issue27917] Choose platform triplets for android builds

Matthias Klose added the comment: checked in. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue27917> ___ ___

[issue28046] Remove the concept of platform-specific directories

Matthias Klose added the comment: not sure if I fully understand: - The patch encodes the multiarch triplet into the _sysconfigdata name and installs it into the standard lib dir. - It removes the PLATDIR macro - what happens to the constants modules which are currently found in the

[issue28046] Remove the concept of platform-specific directories

Matthias Klose added the comment: this comes as a surprise. I can't remember that discussion and decision. -- ___ Python tracker <http://bugs.python.org/is

[issue28046] Remove the concept of platform-specific directories

Matthias Klose added the comment: The removal is not following the guidelines to first deprecate these for a release, and then to remove them. I know that at least the RTLD_* constants are used in a number of places, which will just stop working. I'm not against removing these i

[issue28027] Remove Lib/plat-*/* files

Matthias Klose added the comment: the removal of these modules should follow the normal deprecation process, for 3.6, then be removed for 3.7. There is no harm for this approach. -- nosy: +doko resolution: fixed -> status: closed ->

[issue28027] Remove Lib/plat-*/* files

Matthias Klose added the comment: Since the 3.6 cycle, these modules are regenerated for the build, so they are not outdated anymore. They are not a maintenance burden either. So I'd like to see these available in 3.6, and documented as deprecated. Then removed in 3.7. Apparentl

[issue28027] Remove Lib/plat-*/* files

Matthias Klose added the comment: whatever you searched, there are regressions: https://codesearch.debian.net/search?q=import+DLFCN some of these have conditional imports, however even boost uses unconditional imports, and is often used as an embedded copy

[issue28027] Remove Lib/plat-*/* files

Matthias Klose added the comment: these projects are the ones packaged by Debian; there are surely others. Now again, why can't the actual removal for 3.7, following the usual deprecation rules? -- ___ Python tracker <http://bugs.py

[issue28027] Remove Lib/plat-*/* files

Matthias Klose added the comment: you asked for evidence, you got evidence. re-opening the issue again. feel free to close it again without any evidence, and stating that you ignore the usual deprecation rules. -- resolution: fixed -> status: closed ->

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

New submission from Matthias Klose: pyhash's siphash24 assumes alignment of the data pointer, casting a void pointer (src) to an uint64_t pointer, increasing the required alignment from 1 to 4 bytes. That's invalid code. siphash24 can't assume that the pointer to the data to

[issue28055] pyhash's siphash24 assumes alignment of the data pointer

Changes by Matthias Klose : -- nosy: +christian.heimes ___ Python tracker <http://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    3   4   5   6   7   8   9   >