Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
versions: +Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
What do you think about just removing the keyword?
--
keywords: +patch
nosy: +cstratak
Added file: http://bugs.python.org/file42231/issue17167.patch
___
Python tracker <rep...@bugs.python.org>
Charalampos Stratakis added the comment:
Any info regarding that? Patch seems good and it actually works.
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29640>
___
Charalampos Stratakis added the comment:
Second version of the patch:
Adjusted the test_ensurepip test cases to account for the new modules
--
Added file:
http://bugs.python.org/file46627/bundle-setuptools-dependencies2.patch
___
Python tracker
Charalampos Stratakis added the comment:
Will send a pull request which includes the extra wheels.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Charalampos Stratakis:
The latest versions of setuptools stopped bundling its dependencies and instead
starting requiring them [0]. This seems to break virtualenvs as those
dependencies are not bundled with python.
In order to reproduce it, replace the setuptools-28.8.0
Charalampos Stratakis added the comment:
@jason.coombs
Already tried to just bump the setuptools version and bundle the other wheels
but the result is still the same
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +95
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +97
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
Pull Request has been sent: https://github.com/python/cpython/pull/67
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29324>
___
Charalampos Stratakis added the comment:
Pinging here. Christos could you test the patch?
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Charalampos Stratakis added the comment:
Hello,
Is there any progress on the issue? Should someone take over?
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Charalampos Stratakis:
Until python3.6.0a04 it was possible to pass multiple times the -x option at
regrtest.
However since the 3.6.0b1 when trying the same thing I get an error. Test names
are random.
python3 -m test.regrtest -x test_venv -x test_gdb
usage: python -m
Charalampos Stratakis added the comment:
@Łukasz
Dug a bit more to it.
Yes it is RPM specific for that case, in the sense that we create different
subfolders for the debug and the normal(optimized) builds under the build/ dir,
where the Include directory does not exist. the dtrace wrapper
Charalampos Stratakis added the comment:
Also there is an external project now aiming to provide this functionality:
https://github.com/nir0s/distro
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Charalampos Stratakis added the comment:
Tested this in Fedora Rawhide virtual machine, where the fix for the
problematic openssl commit was backported, and now the tests hang at
test_poplib.
Exception in thread Thread-982:
Traceback (most recent call last):
File "/home/harris/dev/cp
Charalampos Stratakis added the comment:
Fixed upstream:
https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f515b578eb7
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Charalampos Stratakis:
By invoking an out of tree build of python with the --with-dtrace flag enabled,
make fails with an error.
Create a new folder at the source directory:
$ mkdir _build && cd _build
$ ../configure --with-dtrace
$ make
/usr/bin/dtrace -o
Charalampos Stratakis added the comment:
@Łukasz
Would it be possible to review the patch?
Or is it preferable to open a new issue?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28604>
___
Charalampos Stratakis added the comment:
Fedora so far has been using the systemtap patch downstream from dmalcolm [0].
So for 3.6 by removing the systemtap patch (it cannot be applied anymore
cleanly) and by enabling the --with-dtrace configure flag I get this error [1]:
make: *** [Makefile
New submission from Charalampos Stratakis:
Trying to compile gdb, with python support and by having it depend on Python
3.6 produces an error that the HAVE_LONG_LONG has been redefined [0].
This seems to have been introduced by this commit [1].
I'm in no way expert on gdb, but from what I
Charalampos Stratakis added the comment:
The downstream patch we currently use in Fedora [0].
[0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/plain/00102-lib64.patch
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
Charalampos Stratakis added the comment:
Patch for protecting the key list while forking.
--
Added file:
http://bugs.python.org/file46753/0001-Protect-key-list-during-fork.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Charalampos Stratakis added the comment:
Sent a PR against the master branch. What do you think about it?
Would it make sense as well for python 3.6 now?
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +698
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
Bumped upon a similar issue today where a package I was working on couldn't
import a module from one of its dependencies (which was not the case in python
3.5).
One of the lines that fail is this [0] with:
ModuleNotFoundError: No module named
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29943>
___
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +687
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
In order to reproduce:
Apply the python.patch from bz1268226_reproducer2.tar.gz
Compile python
Run the reproduce4.py from bz1268226_reproducer2.tar.gz
As indicated by the reproducer, the status returned by os.wait() for the child
is 139.
I
Charalampos Stratakis added the comment:
Since this newly added assertion [0] fails for aarch64 shouldn't this be
considered a regression?
And taking into account the timeframe, a release blocker for 3.6.1?
--
nosy: +cstratak
___
Python tracker
Charalampos Stratakis added the comment:
[0]
https://github.com/python/cpython/commit/a86339b83fbd0932e0529a3c91935e997a234582#diff-39e8978a35ab16f78e60027c61b810f7R413
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Charalampos Stratakis added the comment:
Currently we haven't updated to Python 3.6.1 at Fedora 26 due to this issue.
While it is a release blocker for 3.6.2, what can be done for 3.6.1?
--
___
Python tracker <rep...@bugs.python.org>
Charalampos Stratakis added the comment:
Just a small note here for the documentation patch.
yum is deprecated in Fedora, and dnf is now the default package manager, so the
respective instructions for Fedora should reflect that.
--
nosy: +cstratak
Charalampos Stratakis added the comment:
@Andrew
This has already been implemented downstream for RHEL and centos.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26415>
___
Charalampos Stratakis added the comment:
This is a duplicate of http://bugs.python.org/issue30714
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Charalampos Stratakis added the comment:
Yeah the warnings are quit annoying when compiling the master and 3.6 branch.
Fedora 26 currently includes gcc 7 which emits those warnings, other distros
will follow up when they update gcc, so I'd think it would be better to fix
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31013>
___
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
New submission from Charalampos Stratakis:
On gcc 7 the new -Wimplicit-fallthrough option was introduced which produces
warnings about switch cases that can fall through.
The easiest way to silence these warnings is to add the comment /* Falls
through. */ for those cases. More information
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29411>
___
Charalampos Stratakis added the comment:
I've observed the exact same issue on Fedora at random times.
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Charalampos Stratakis:
FAIL: test_prlimit (test.test_resource.ResourceTest)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-3.6.2/Lib/test/support/__init__.py",
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29243>
___
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29712>
___
Charalampos Stratakis added the comment:
All the dependencies dragged.
gdb is of version 7.11. The failures do not happen with gdb 7.12 (which exists
in later Fedora releases).
--
Added file: http://bugs.python.org/file46857/root.log
___
Python
Charalampos Stratakis added the comment:
Full build log
--
nosy: +cstratak
Added file: http://bugs.python.org/file46856/build.log
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Charalampos Stratakis added the comment:
Note: test_gdb is skipped on later Fedora's actually (possibly due to gdb
package no being dragged at the minimal buildroot) so the issue might still be
there, so the gdb version might have no effect on that. Will investigate
further
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +1642
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
So the issue wasn't restricted to a specific gdb version or distro release, as
due to some issues dependency issues the gdb binary wasn't pulled in the
buildroot which makes test_gdb to get skipped.
So I was able to reproduce it on my system
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +ishcherb
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30353>
___
Charalampos Stratakis added the comment:
A 'defined(__aarch64__)' can be used for the arm64 arch. I will add it to your
patch and test it on an arm64 machine to see if the test passes.
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +1619
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Charalampos Stratakis added the comment:
Closing this per the discussion at the PR.
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Charalampos Stratakis:
After updating openssl in Fedora 26 from 1.1.0e to 1.1.0f the
test_alpn_protocols from test_ssl started failing:
==
FAIL: test_alpn_protocols (test.test_ssl.ThreadedTests
Charalampos Stratakis added the comment:
Note: Python version is 3.6.1
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9146>
___
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9216>
___
Charalampos Stratakis added the comment:
This bug affects also the 3.6 branch. Can the fix be backported?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Charalampos Stratakis added the comment:
For what it's worth, in Fedora 26 we already rebased Python to 3.6.1, so this
issue now is non existent for our ecosystem, and we are not shipping 3.6.0 in
any way now.
--
___
Python tracker <
Charalampos Stratakis added the comment:
Downstream backporting of PEP 538 to the 3.6 branch also depends on this fix.
Would it be beneficial in any way to cherry-pick it for 3.6?
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Forgot the mention the kernel version which is 3.10.0-693.2.1.el7.ppc64le
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Indeed the version of strace is 'strace-4.12-4.el7'.
I will try to provide output from the latest one.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Which CentOS/RHEL version do you have?
Could you provide the output of 'cat /etc/redhat-release' ?
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Attaching the output of:
strace -s 128 -e trace=%network -o trace ./python3 -m test -v test_socket -m
test_sha256
using the latest version of strace (4.19).
--
Added file: https://bugs.python.org/file47204/
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31733>
___
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Attaching the strace output.
--
Added file: https://bugs.python.org/file47202/trace
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31692>
___
New submission from Charalampos Stratakis <cstra...@redhat.com>:
Trying to create an archive with the tarfile module, by specifying a different
blocking factor, doesn't seem to work as only the default value is being used.
The issue is reproducible on all the active python branches.
Att
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31450>
___
Changes by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31429>
___
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +christian.heimes
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Charalampos Stratakis <cstra...@redhat.com>:
The issue is reproducible on a CentOS 7.4 on ppc64le architecture. It passes
successfully on other arch's (however the other power pc arch's might also be
affected).
How to reproduce:
Compile python 3.6 from source
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Pinging here. Is there some way to push the issue forward?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.o
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Pinging here. Is there some way I can help to move the issue forward?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Thanks for the fix Victor!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32367>
___
New submission from Charalampos Stratakis <cstra...@redhat.com>:
Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1484497
It seems that on the development branch of Fedora, when we updated glibc from
2.26 to 2.26.90, test_float_with_comma started failing.
Detail
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Tested the PR on a system with glibc 2.26.90 where the test was failing, and it
successfully passed.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
This is an issue with the stack size.
It was encountered recently while building Python 3.6 under CentOS 6 [0] and
the way to fix it was to increase the maximum stack size using ulimit e.g. [1]
[0] https://bugzilla.redh
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Is it possible/feasible to fix that for the 3.7 and 3.6 branches as well?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis added the comment:
I'd say there are use cases where gdb will be used with optimizations
especially in downstream distribution.
--
___
Python tracker
<https://bugs.python.org/issue32
Charalampos Stratakis added the comment:
The latest stable Fedora's have glibc >= 2.26
Maybe the buildbot needs to be updated?
--
nosy: +cstratak
___
Python tracker
<https://bugs.python.org/issu
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Ping. Could someone take a look? There is a PR ready.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +Dormouse759
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
PR has been rebased on top of master and also blurbified.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
nosy: +cstratak
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32007>
___
New submission from Charalampos Stratakis <cstra...@redhat.com>:
Currently on the development branch of Fedora (28), an upstream change of glibc
is being pushed where the Sun RPC support is removed from our downstream glibc
package in favor of the libtirpc library. More deta
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
title: NIS module fails to build due to the remove of interfaces related to Sun
RPC from glibc. -> NIS module fails to build due to the removal of interfaces
related to Sun RPC f
Charalampos Stratakis <cstra...@redhat.com> added the comment:
Already tried. Unfortunately it doesn't.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Charalampos Stratakis <cstra...@redhat.com> added the comment:
The header is located at /usr/include/tirpc/rpc/rpc.h
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
components: +Extension Modules
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
versions: +Python 3.6, Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Charalampos Stratakis <cstra...@redhat.com>:
Currently in Fedora glibc stopped providing libcrypt[0] a change which is
slowly being upstreamed as well[1] in favor of the libxcrypt project[2].
This causes a segfault when importing the crypt module as python a
Change by Charalampos Stratakis <cstra...@redhat.com>:
--
pull_requests: +5130
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
1 - 100 of 293 matches
Mail list logo
