Xavier de Gaye added the comment:
New patch.
Please use autoreconf before running the patch (autoreconf instead of autoconf
because the description of HAVE_LOCKF has been updated).
--
title: configure links with lockf and F_LOCK is not declared in Android API 24
-> lo
Xavier de Gaye added the comment:
Thanks for the review Victor.
I have created issue 29040: building Android with android-ndk-r14.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
issue #29040: building Android with android-ndk-r14
--
dependencies: +building Android with android-ndk-r14
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Xavier de Gaye:
android-ndk-r14 introduces "Unified Headers" [1] and is planned to be released
late january/early february 2017 [2].
__ANDROID_API__ is not anymore defined in 'android/api-level.h' that is
currently included by Include/pyport.h, and is pass
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
These changes break the darwin platform, socket.if_nameindex() is not defined
anymore. On Darwin, 'net/if.h' requires that 'sys/socket.h' be included
beforehand (see the autoconf documentation).
--
___
Python
Xavier de Gaye added the comment:
No, the patch prevents posix.flock() to be defined on Android API 24 with
android-ndk-r13. But I plan to change it so that the test is skipped when posix
does not have the F_LOCK attribute as this problem is not worth a change in the
build machinery. It makes
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Xavier de Gaye added the comment:
The test is ok on Android when LANG=en_US.UTF-8.
When LANG is not set, the check made by the first statement in test_nonascii()
should skip the test but fails to skip it on Android as Py_EncodeLocale()
always encode to utf8 whatever the locale (same
Xavier de Gaye added the comment:
Martin in response to your last review, I still hold to my opinion stated in
msg283294 but this should not prevent this high priority issue to progress. Can
you propose another patch.
--
___
Python tracker <
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
Checking that the the problem is indeed an encoding problem on Android with
readline.set_pre_input_hook(): with tracing_the_completer_2.patch that replaces
'\xEB' with 'A', the test now succeeds and prints:
test_nonascii (test.test_readline.TestReadline
Xavier de Gaye added the comment:
FWIW on Android we have:
>>> readline.__doc__ and "libedit" in readline.__doc__
False
>>> getattr(readline, "set_pre_input_hook", None)
--
___
Python tracker <rep...
Xavier de Gaye added the comment:
> For me, it prints this: (includes “te” with an umlaut)
I got this same result when testing on Android with the interactive interpreter.
See the content of the 'completer' list below, when run with
tracing_the_completer.patch:
On linux:
test_nonas
Xavier de Gaye added the comment:
> If sender sends a lot of empty lines and file is not None, LF or CRLF is
> stripped from lines
Oh, I missed that. Maybe give a weight of 4 to 8 bytes or even more to a line,
this value being added to the bytes count whether the line is empty or not.
Xavier de Gaye added the comment:
I responded to your last review Serhiy, but the psf mail system reports a
delivery failure, so you may have missed the notification as well as the other
reviewers.
--
___
Python tracker <rep...@bugs.python.
Xavier de Gaye added the comment:
Here is a patch that skips test_strcoll_with_diacritic and
test_strxfrm_with_diacritic.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45942/test_locale_strcoll.pa
Xavier de Gaye added the comment:
Both strcoll() and strxfrm() are broken (character 'à' unicode code point is
'e0'):
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'C.UTF-8'
>>> locale.strcoll('\u00e0', 'b')
1
>>> locale.strxfrm('
Xavier de Gaye added the comment:
This patch defines a _MAXBYTES limit of 100 Mb. The limit is checked upon
reading one line and also upon reading the multi-lines of the response to a
user command.
--
Added file: http://bugs.python.org/file45939/nntplib_maxbytes.patch
Xavier de Gaye added the comment:
issue #28996: wcscoll is broken on Android and test_locale fails
issue #28997: test_readline.test_nonascii fails on Android
--
dependencies: +test_readline.test_nonascii fails on Android, wcscoll is broken
on Android and test_locale fails
New submission from Xavier de Gaye:
test_nonascii has been implemented in issue 16182.
The error message:
==
FAIL: test_nonascii (test.test_readline.TestReadline
Xavier de Gaye added the comment:
Closing the issue. Thanks for the patch Chi Hsuan Yen.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Xavier de Gaye:
These failures happen now that issue 28596 has been fixed and that
locale.getpreferredencoding(False) returns 'UTF-8'.
==
FAIL: test_strcoll_with_diacritic
Xavier de Gaye added the comment:
Closing as invalid, it is useful to have the test failing on platforms that do
not have CODESET and detect that too many modules are imported on startup. For
Android, this problem is fixed in issue 28596.
--
resolution: -> not a bug
stage: com
Xavier de Gaye added the comment:
> I'd be in favor of temporarily skipping the affected tests with a message
> that points back to here until we have a permanent solution.
I am working on it.
--
___
Python tracker <rep...@bugs.python.o
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
Forgot the issue number in the commit message for the default branch, the
corresponding changeset is 80a041d39c20.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
The patch fixes also the following errors in test_warnings:
==
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests
Xavier de Gaye added the comment:
Thanks for the patch. See my comments in Rietveld.
I think we can skip the 'step' command.
For the tests, can you use the existing run_pdb() method and trigger the
signals from within the code being executed with 'os.kill(os.getpid(),
signal.SIGINT
Xavier de Gaye added the comment:
It seems that the comment placed above the definition of _MAXLINE in the
nntplib module is not correct:
"RFC 3977 limits NNTP line length to 512 characters, including CRLF. We
have selected 2048 just to be on the safe side."
The 512 characters li
Xavier de Gaye added the comment:
The patch:
1) Increases _MAXLINE to 4096.
2) Reverts issue 16040 and that is not correct, please ignore that part.
The changes made in issue 16040 limit the amount of data read by readline() and
does not close the nntp session when the server sends a message
Xavier de Gaye added the comment:
> I found that there were three other mails raising this same
> NNTPDataError('line too long') in the 40 last mails.
Cannot reproduce it. These three exceptions must have been NNTPProtocolError
instead, caused by the initial NNTPDat
Xavier de Gaye added the comment:
When the server sends a line longer than _MAXLINE, nntplib reads only _MAXLINE
+ 1 bytes leaving the remaining bytes left to be processed by the next command
that will interpret those bytes as a protocol error. Hence the failing tests
that follow the first
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
BTW while searching for this problem, I found that there were three other mails
raising this same NNTPDataError('line too long') in the 40 last mails.
--
___
Python tracker <rep...@bugs.python.org>
Xavier de Gaye added the comment:
The problem is when getting an overview of the following comp.lang.python mail:
OT - "Soft" ESC key on the new MacBook Pro Michael Torrie
Tue Dec 13 21:33:07 EST 2016
This is at index (last - 16) now and that is why the buildbots do not fai
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28971>
___
_
New submission from Xavier de Gaye:
All the buildbots are currently failing at test_nntplib.
See the errors in attached test_nntplib.log.
The same error messages can be reproduced with a 3.5.2 interpreter:
$ python
Python 3.5.2 (default, Nov 7 2016, 11:31:36)
[GCC 6.2.1 20160830] on linux
Type
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
dependencies: -setup.py: do not add system header locations when cross
compiling
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Xavier de Gaye added the comment:
Same patch, but this one is properly set to be handled by Rietveld.
--
Added file: http://bugs.python.org/file45894/multiarch_2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
>> this assumption is wrong for the multiarch case.
>
> Please explain why it is wrong.
Sadly no explanations have been given, we have to take Matthias word for it.
This new patch updates the add_multiarch_paths() method and includes LIBDIR and
Xavier de Gaye added the comment:
test_pathlib must also be fixed for this same problem.
New patch.
--
Added file: http://bugs.python.org/file45878/bind_unix_socket_2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Xavier de Gaye added the comment:
For some reason the following notifications have not all been received (yet):
remote: added 1 changesets with 2 changes to 2 files
remote: buildbot: change(s) sent successfully
remote: sent email to roundup at rep...@bugs.python.org
remote
Xavier de Gaye added the comment:
Removing from the dependencies some issues that have become out of scope.
--
dependencies: -Cross-build _curses failed if host ncurses headers and target
ncurses headers have different layouts, add function to os module for getting
path to default
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
assignee: xdegaye ->
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28190>
___
_
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
New patch using sys.getandroidapilevel() that is only defined for Android.
getandroidapilevel() is only available in 3.7, so only 3.7 is being fixed.
--
assignee: -> xdegaye
dependencies: -add function to os module for getting path to default sh
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Xavier de Gaye added the comment:
New patch using sys.getandroidapilevel().
getandroidapilevel() is only available in 3.7, so only 3.7 is being fixed.
--
stage: commit review -> patch review
versions: -Python 3.6
Added file: http://bugs.python.org/file45858/test_socket_3.pa
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
Patch updated to the current head of the default branch.
--
stage: patch review -> commit review
Added file: http://bugs.python.org/file45855/pwd_3.patch
___
Python tracker <rep...@bugs.python.org&
Xavier de Gaye added the comment:
AFAIK many changes that have been made in Python 3 for the support of the cross
compilation have not been backported to 2.7, including this one.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
Hum, I did miss that line in configure.ac, thanks for pointing that out.
New patch.
--
Added file: http://bugs.python.org/file45850/no-path-to-ncursesw_2.patch
___
Python tracker <rep...@bugs.python.org>
Xavier de Gaye added the comment:
> Now users have to specify the path manually even for native builds.
This does not make sense, the patch does not change anything for the native
builds.
--
___
Python tracker <rep...@bugs.python.org&
Xavier de Gaye added the comment:
> no, this is a very wrong simplification. Both gcc and clang offer a method
> to search for header files and libraries in a target specific location.
> Please use these options.
Please open a new issue for the detection of the curses paths. Th
Xavier de Gaye added the comment:
> this assumption is wrong for the multiarch case.
Please explain why it is wrong.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Xavier de Gaye added the comment:
> Both gcc and clang offer a method to search for header files and libraries in
> a target specific location.
AFAIK there is no target specific location when cross compiling. What are those
cross compilation target specific locations according
Xavier de Gaye added the comment:
This patch does not add /usr/include/ncursesw to the include directories search
paths when cross compiling.
Restoring the original title.
@Chi Hsuan Yen
Please open a new issue for the detection of the curses paths. The current
issue is about the failure
Xavier de Gaye added the comment:
When cross compiling, setup.py must not look for headers in the directory for
installing C header files and must not look for libraries in the directory for
installing object code libraries of the _native_ interpreter which is being
used to run setup.py
Xavier de Gaye added the comment:
The only change that is needed here is to not include /usr/include/ncursesw in
setup.py when cross compiling to ensure that the headers of the build platform
are not included. When cross compiling Python, it is the responsability of the
packager to set
Xavier de Gaye added the comment:
Patch attached.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45812/xxlimited_abiflags.patch
___
Python tracker <rep...@bugs.python.org>
<http://bug
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
New submission from Xavier de Gaye:
This happens when the cross compilation is done with '--with-pydebug' while the
native interpeter used to run setup.py has been built without it. The error
message is:
Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and
Py_REF_DEBUG
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
issue #20211: setup.py: do not add system header locations when cross compiling
issue #28190: Detect curses headers correctly for cross-compiling
--
dependencies: +Detect curses headers correctly for cross-compiling, setup.py:
do not add system header
Xavier de Gaye added the comment:
This is a performance issue. I will look at it shortly.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
assignee: -> xdegaye
stage: needs patch -> patch review
type: behavior -> performance
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
The MULTIARCH triplet:
* is used by the build system in the suffix of the name of the _sysconfigdata
private module, it may have any value (including being empty) when the platform
is non-multiarch - for example cross-compiling for an Android emulator
Xavier de Gaye added the comment:
The change made by the patch in Makefile.pre.in handles the removing of the
dangling underscore in the patch of issue 28833, it is not needed.
android_multiarch_2.patch is simpler: the change in Makefile.pre.in has been
removed and test_triplet_in_ext_suffix
Xavier de Gaye added the comment:
FWIW the definition of free variables can be found in the Language Reference at
section 4.2.1. "Binding of names" [1].
The list of the free variables of a user defined function can be accessed
through the __closure__ function attribute, a tuple. Th
Xavier de Gaye added the comment:
Here is the output of getandroidapilevel(), a verbose run of test_sys and a run
of the test suite on the Android x86 emulator API 21. All the results are as
expected, the failed tests are the usual ones, BTW all of the failed tests have
either a patch ready
Xavier de Gaye added the comment:
> getandroidapilevel-3.patch: Updated version of getandroidapilevel.patch:
> replace "runtime" with "build time" in the doc :-) Remove also "version > 0"
> check in support/__init__.py.
LGTM
> About the version &g
Xavier de Gaye added the comment:
@Chi Hsuan Yen
And please, let us not waste any more time on lost battles, this suggestion of
using sys.implementation has already been rejected at issue 27442 (see
msg269748) as you must know since you were involved in the discussion
Xavier de Gaye added the comment:
> How about renaming sys.implementation._multiarch to
> sys.implementation.target_architecture and make it public?
> sys.androidapilevel() sounds too specific to me.
Please do not hijack this issue. The removal of sys.implementation._multiarch
fo
Xavier de Gaye added the comment:
$ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android
PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr
python3.7 setup.py build_ext
>
Variables prefixed by an underscore such as '_PYTHON_SYSCONFIGDATA_N
New submission from Xavier de Gaye:
Android is not a multiarch system and the unix build system can cross compile
non-multiarch systems as well as multiarch systems. This is a follow up of the
decisions implemented in issue 28046 and the patch fixes also an oversight made
in this issue
Xavier de Gaye added the comment:
So I suggest we start with this patch as it works for:
* The standard library extension modules (for debian as well).
* The third-party extension modules on platforms that have multiarch defined
and on platforms that do not have multiarch defined (on debian
Xavier de Gaye added the comment:
> I don't think that identifying the target by some path is the right way to
> go, and you should be able to identify the target by giving the target
> triplet as used by the configure parameters and then deduce the location from
> the tar
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28833>
___
_
Xavier de Gaye added the comment:
> This approach will not work with a "multiarch" enabled environment, and break
> cross builds on Debian and Ubuntu.
No, the patch does not break cross builds on Debian and Ubuntu, unless you can
demonstrate it does.
> Afaics, t
New submission from Xavier de Gaye:
With this patch, cross compiling a third-party extension module is done with
the command:
XBUILD_PYTHON_DIR=/path/to/python/dir python setup.py build
where XBUILD_PYTHON_DIR is the location of the directory of the cross-compiled
python executable.
It may
Xavier de Gaye added the comment:
I agree with Marc-Andre, Windows has sys.getwindowsversion() returning system
information for the Windows version, and a platform.win32_ver() returning
additional version information from the Registry obtained at run time. So it is
consistent to add
Xavier de Gaye added the comment:
New issues raised upon testing on the Android API 24 emulator:
issue #28683: bind() on a unix socket raises PermissionError on Android for a
non-root user
issue #28684: [asyncio] bind() on a unix socket raises PermissionError on
Android for a non-root user
New submission from Xavier de Gaye:
The patch fixes the problem that on Android API 24, a non-root user is not
allowed to create the hard links used by the mailbox module.
Related to issue 28759.
--
assignee: xdegaye
components: Library (Lib)
files: test_mailbox_link.patch
keywords
New submission from Xavier de Gaye:
The patch fixes the following error:
==
ERROR: test_lockf (test.test_posix.PosixTester)
--
Traceback (most recent call last
New submission from Xavier de Gaye:
List of the tests that fail with PermissionError when run as a non-root user on
an Android emulator (API 24) and fixed by this patch:
test_posix test_shutil test_stat test_genericpath test_ntpath
test_posixpath test_macpath test_eintr test_pathlib
Changes by Xavier de Gaye <xdeg...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Xavier de Gaye added the comment:
It seems the code path run by Android is not tested by any of the buildbots.
Patch attached.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45547/set_inheritable.pa
New submission from Xavier de Gaye:
test_socket on Android fails with:
FAIL: test_set_inheritable (test.test_socket.InheritanceTest)
--
Traceback (most recent call last):
File "/sdcard/org.bitbucket.pyona/lib/python3.7
Xavier de Gaye added the comment:
The build time Android API level is also a valuable information to Python users
(application developers), it may be used at installation time or to detect a
version mismatch.
--
___
Python tracker <
Xavier de Gaye added the comment:
__system_property_get() is not a public API, see Android bug report [1].
In this stackoverflow question, an Android developer confirms this point and
suggests to use the file /system/build.prop instead, noting however that
"build.prop isn't guara
Xavier de Gaye added the comment:
Patch tested with success on the android-24 emulator.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
issue #28740: Add sys.getandroidapilevel()
--
dependencies: +Add sys.getandroidapilevel()
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Xavier de Gaye added the comment:
> I proposed to add a new function to the sys module: sys.getandroidapilevel()
This would also help fixing the long standing issue 16255, and possibly also
issue 16353.
--
___
Python tracker <rep...@bugs.pyth
601 - 700 of 1480 matches
Mail list logo
