Description of problem: start up Version-Release number of selected component: setroubleshoot-3.3.16-1.fc27 Additional info: reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.4-300.fc27.x86_64 runlevel: N 5 type: Python3 uid: 1000 Truncated backtrace: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) Traceback (most recent call last): File "/usr/bin/seapplet", line 158, in <module> my = SEApplet() File "/usr/bin/seapplet", line 85, in __init__ '/org/fedoraproject/Setroubleshootd' File "/usr/lib/python3.6/site-packages/pydbus/proxy.py", line 47, in get 0, timeout_to_glib(timeout), None) GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) Local variables in innermost frame: timeout: None kwargs: {} object_path: '/org/fedoraproject/Setroubleshootd' bus_name: 'org.fedoraproject.Setroubleshootd' self: <pydbus.bus.Bus object at 0x7fdd94d0c0b8>
Created attachment 1402223 [details] File: backtrace
Created attachment 1402224 [details] File: cgroup
Created attachment 1402225 [details] File: cpuinfo
Created attachment 1402226 [details] File: environ
Created attachment 1402227 [details] File: mountinfo
Created attachment 1402228 [details] File: namespaces
Created attachment 1402229 [details] File: open_fds
Similar problem has been detected: I forget when is the first day this problem is happen. When I notice this information, everytime I turn on my laptop, it just said "SELinux is crashed". I hope I can reinstall it to solve this prob. reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.4-300.fc27.x86_64 package: setroubleshoot-3.3.16-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
Similar problem has been detected: I just logged in reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.4-300.fc27.x86_64 package: setroubleshoot-3.3.16-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
Similar problem has been detected: Starting fedora. Crash... every time... reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.6-300.fc27.x86_64 package: setroubleshoot-3.3.16-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
Similar problem has been detected: Starting Fedora xD reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.6-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
*** Bug 1554808 has been marked as a duplicate of this bug. ***
Similar problem has been detected: cold boot of computer tried rebooting several times and problem occured every time occurred every time Samsung Book 7, Model NP740U3E 12GB Memory reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.6-300.fc27.x86_64 package: setroubleshoot-3.3.16-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: unknown type: Python3 uid: 1000
Similar problem has been detected: o notebook estava executando o sistema, e, foi abaixada a tampa, o mesmo permaneceu assim por um longo tempo, ao retornar o sistema não travou e não conseguiu restaurar a sessão, destruindo a mesma e criando uma nova. reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.9-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
*** Bug 1561821 has been marked as a duplicate of this bug. ***
*** Bug 1561982 has been marked as a duplicate of this bug. ***
*** Bug 1563183 has been marked as a duplicate of this bug. ***
Similar problem has been detected: I tried to login after the pc was in standby, 4-5 times the login failed (passwort correct, but just showing shortly a black screen and falling back to login). Finally the Desktop was loaded - with the current error. reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.14-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
Similar problem has been detected: just starting the pc, login to desktop reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.14-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
Similar problem has been detected: No idea, sorry. I got a popup in Gnome just a fresh boot. reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.14-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
I can reproduce the issue simply by running the command: /usr/bin/python3 /usr/bin/seapplet I got more information when guessing the DBus call: vstinner@apu$ dbus-send --session --dest=org.fedoraproject.Setroubleshootd --type=method_call --print-reply /org/fedoraproject/Setroubleshootd org.freedesktop.DBus.Introspectable.Introspect With this DBus call, I got a new traceback: avril 11 10:19:28 apu dbus-daemon[1534]: [session uid=1000 pid=1534] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.113' (uid=1000 pid=3490 comm="dbus-send --session --dest=org.fedoraproject.Setro" label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") avril 11 10:19:28 apu python3[3492]: detected unhandled Python exception in '/usr/bin/sealert' avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: Traceback (most recent call last): avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: File "/usr/bin/sealert", line 56, in <module> avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: from setroubleshoot.util import get_identity, load_plugins, log_init, log_debug avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: File "/usr/lib/python3.6/site-packages/setroubleshoot/util.py", line 324, in <module> avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: from sepolicy import get_all_file_types avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: File "/usr/lib/python3.6/site-packages/sepolicy/__init__.py", line 9, in <module> avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: import setools avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: File "/usr/lib64/python3.6/site-packages/setools/__init__.py", line 24, in <module> avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: __version__ = pkg_resources.get_distribution("setools").version avril 11 10:19:28 apu org.fedoraproject.Setroubleshootd[1534]: AttributeError: module 'pkg_resources' has no attribute 'get_distribution' avril 11 10:19:28 apu dbus-daemon[1534]: [session uid=1000 pid=1534] Activated service 'org.fedoraproject.Setroubleshootd' failed: Process org.fedoraproject.Setroubleshootd exited with status 1 It seems to be related to setuptools (pkg_resources). Using "regular" system python3, the Python call works as expected: $ python3 Python 3.6.5 (default, Apr 4 2018, 15:01:18) >>> import pkg_resources >>> pkg_resources <module 'pkg_resources' from '/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py'> >>> pkg_resources.get_distribution("setools").version '4.1.1' But /usr/bin/sealert runs python3 with -E -s: vstinner@apu$ head /usr/bin/sealert #!/usr/bin/python3 -Es Using these flags, I get a different flavor of pkg_resources which fails: $ python3 -Es Python 3.6.5 (default, Apr 4 2018, 15:01:18) >>> import pkg_resources >>> pkg_resources <module 'pkg_resources' (namespace)> >>> pkg_resources.__path__ _NamespacePath(['/usr/lib/python3.6/site-packages/pkg_resources']) >>> pkg_resources.get_distribution("setools").version Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'pkg_resources' has no attribute 'get_distribution' I installed setuptools manually using: sudo python3 -m pip install -U setuptools. -- I uninstalled setuptools: vstinner@apu$ sudo python3 -m pip uninstall setuptools Uninstalling setuptools-39.0.1: /usr/local/bin/easy_install /usr/local/bin/easy_install-3.6 /usr/local/lib/python3.6/site-packages/__pycache__/easy_install.cpython-36.pyc /usr/local/lib/python3.6/site-packages/easy_install.py /usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py (...) /usr/local/lib/python3.6/site-packages/setuptools/wheel.py /usr/local/lib/python3.6/site-packages/setuptools/windows_support.py (...) Then, python3 fails with and without -E -s: $ python3 Python 3.6.5 (default, Apr 4 2018, 15:01:18) >>> import pkg_resources >>> pkg_resources.get_distribution("setools").version Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'pkg_resources' has no attribute 'get_distribution' >>> pkg_resources <module 'pkg_resources' (namespace)> >>> pkg_resources.__path__ _NamespacePath(['/usr/lib/python3.6/site-packages/pkg_resources'])
Oh ok, I succeeded to reproduce the bug. First, cleanup to get a "fresh" Fedora: remove setuptools installed by pip and reinstall the RPM sudo python3 -m pip uninstall setuptools sudo dnf reinstall -y python3-setuptools pkg_resources works as expected: $ python3 -Es -c 'import pkg_resources; print(pkg_resources.get_distribution("setools").version)' 4.1.1 $ python3 -c 'import pkg_resources; print(pkg_resources.get_distribution("setools").version)' 4.1.1 To reproduce the bug: 1. install setuptools using pip sudo python3 -m pip install -U setuptools 2. the /usr flavor of pkg_resources (installed by RPM) is broken, whereas /usr/local flavor (installed by pip) works as expected: # pip flavor, /usr/local $ python3 -c 'import pkg_resources; print(pkg_resources.get_distribution("setools").version)' 4.1.1 # RPM flavor, /usr $ python3 -Es -c 'import pkg_resources; print(pkg_resources.get_distribution("setools").version)' Traceback (most recent call last): File "<string>", line 1, in <module> AttributeError: module 'pkg_resources' has no attribute 'get_distribution'
Fresh Fedora (after my cleanup): $ find /usr/lib/python3.6/site-packages/pkg_resources/ -name "*.py" /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/__about__.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/__init__.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/_compat.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/_structures.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/markers.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/requirements.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/specifiers.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/utils.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/packaging/version.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/__init__.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/appdirs.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/pyparsing.py /usr/lib/python3.6/site-packages/pkg_resources/_vendor/six.py /usr/lib/python3.6/site-packages/pkg_resources/extern/__init__.py /usr/lib/python3.6/site-packages/pkg_resources/__init__.py /usr/lib/python3.6/site-packages/pkg_resources/py31compat.py Install setuptools using pip: sudo python3 -m pip install -U setuptools The pip installation removes all .py files from /usr: $ find /usr/lib/python3.6/site-packages/pkg_resources/ -name "*.py" (no result)
Could I ask everybody to try this workaround and report back? $ sudo dnf reinstall python3-setuptools Thanks Victor for the investigation. The problem seems to stem from the fact that python3's pip is set to install only to the `/usr/local/lib/` prefix, but if it encounters an older version in `/usr/lib/` it will happily remove it. The result is that programs that run in isolated environment (that don't see into `/usr/local/lib/`) can't find setuptools and crash. If the above workaround is confirmed, the proposed solution is to patch python3's pip never to remove packages from `/usr/lib/` and just happily install the new version into `/usr/local/lib/` where it takes precedence over `/usr/lib/` anyway. This isn't a complete solution though, because if pip itself is updated in this fashion, it will start interfering again. Coordination with upstream and a non-trivial patch would be needed to address that issue.
Similar problem has been detected: No clue reporter: libreport-2.9.3 cmdline: /usr/bin/python3 /usr/bin/seapplet crash_function: get exception_type: GLib.GError executable: /usr/bin/seapplet kernel: 4.15.10-300.fc27.x86_64 package: setroubleshoot-3.3.17-1.fc27 reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25) runlevel: N 5 type: Python3 uid: 1000
(In reply to Yaron Shahrabani from comment #25) > Similar problem has been detected: > Please try this workaround and report back: $ sudo dnf reinstall python3-setuptools
(In reply to Phillip Bagwell from comment #13) > Similar problem has been detected: > > cold boot of computer > tried rebooting several times and problem occured every time occurred every > time > Samsung Book 7, Model NP740U3E > 12GB Memory > > reporter: libreport-2.9.3 > cmdline: /usr/bin/python3 /usr/bin/seapplet > crash_function: get > exception_type: GLib.GError > executable: /usr/bin/seapplet > kernel: 4.15.6-300.fc27.x86_64 > package: setroubleshoot-3.3.16-1.fc27 > reason: proxy.py:47:get:GLib.GError: g-dbus-error-quark: > GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper > exited with unknown return code 1 (25) > runlevel: unknown > type: Python3 > uid: 1000 Reinstalling python3-setuptools solved the problem for me
Thanks for confirming! I've talked to mcyprian who worked on the original sudo pip change, and he agreed to look into this as soon as his time allows.
Essentially, sudo pip installing into /usr/local/ should behave as pip install used with the `--user` switch. If you `pip install --user -U foo`, then foo is installed into the user location without it being removed from the system-wide location.
Agreed.
*** Bug 1520199 has been marked as a duplicate of this bug. ***
*** Bug 1526713 has been marked as a duplicate of this bug. ***
*** Bug 1579593 has been marked as a duplicate of this bug. ***
I implemented a patch to make sudo pip installing into /usr/local behave as pip install into user site as Tomas suggested. https://src.fedoraproject.org/rpms/python-pip/pull-request/10
Victor, could you please review the patch in https://src.fedoraproject.org/rpms/python-pip/pull-request/10
Victor, please make this a priority.
https://fedoramagazine.org/troubleshooting-selinux/ Edit the /etc/sysconfig/selinux file to set SELINUX=permissive. did help me. and the other comments in the article were useful.
Victor, will you be able to do this during this week? As there anything that blocks this?
Ok, let me summary the progress on that issue and what I did. At Jun 11, 2018, Michal Cyprian wrote a PR to modify pip behavior on Fedora, to not remove files in /usr. The patch is based on pip-9.0.3: https://src.fedoraproject.org/rpms/python-pip/pull-request/10 I reviewed the PR multiple times, but I didn't comment because I don't want to write a public comment until I'm sure of what I write. Let me share my mood on this change anyway: leaving /usr unmodified when upgrading a package and write new files in /usr/local seems like a good idea. But I'm not sure that having an old version in /usr and a new version in /usr/local works well on Fedora: I'm not sure if /usr/local always get the priority, especially using -E or -I command line option of Python, or when using platform-python (I'm not sure if platform-python still exists in Fedora rawhide, that's also why I didn't want to complain about something that no longer exists :-)). I rebased the patch on the pip 18.0, but I had to basically rewrite the patch from scratch since pip 18 code base looks as it has nothing in common with pip 9. A big and deep refactoring occurred after Michal wrote his change. I tested my rebased patch on Fedora Rawhide (using mock). I installed "python3-setuptools-39.2.0-7.fc30.noarch.rpm", and then I upgraded setuptools using "sudo python3 -m pip install -U setuptools". Problem: .py files are removed from /usr. Now I'm confused: did Michal patch work, or did I do something wrong when I "rebased" (rewrote) his patch for pip 18? I'm not sure if Michal tested the upgrade case, but it is the main issue of this GNOME SELinux seapplet bug. I also tried to get help from pip developers to rebase the change, but they didn't reply. Again, maybe my review is wrong, maybe Michal's change is just fine for pip 9, but anyway, we have to make it working on pip 18 (version used on Fedora Rawhide).
(In reply to Victor Stinner from comment #42) > I reviewed the PR multiple times, but I didn't comment because I don't want > to write a public comment until I'm sure of what I write. Let me share my > mood on this change anyway: leaving /usr unmodified when upgrading a package > and write new files in /usr/local seems like a good idea. It's still a better ide than current behavior. > But I'm not sure > that having an old version in /usr and a new version in /usr/local works > well on Fedora: I'm not sure if /usr/local always get the priority, > especially using -E or -I command line option of Python It gets priority when no flags are used. It does not get priority when -s is used. You can try other flags with: [~]$ sudo mkdir -p /usr/local/lib/python3.7/site-packages [~]$ sudo mkdir -p /usr/local/lib64/python3.7/site-packages [~]$ python3 -c 'import sys; print(sys.path)' | grep local ['', '/usr/lib64/python37.zip', '/usr/lib64/python3.7', '/usr/lib64/python3.7/lib-dynload', '/usr/local/lib64/python3.7/site-packages', '/usr/local/lib/python3.7/site-packages', '/usr/lib64/python3.7/site-packages', '/usr/lib/python3.7/site-packages'] [~]$ python3 -sc 'import sys; print(sys.path)' | grep local [~]$ python3 -Ec 'import sys; print(sys.path)' | grep local ['', '/usr/lib64/python37.zip', '/usr/lib64/python3.7', '/usr/lib64/python3.7/lib-dynload', '/usr/local/lib64/python3.7/site-packages', '/usr/local/lib/python3.7/site-packages', '/usr/lib64/python3.7/site-packages', '/usr/lib/python3.7/site-packages'] [~]$ python3 -Ic 'import sys; print(sys.path)' | grep local [~]$ If the behavior is not good, we can file bugs and fix them. > or when using > platform-python (I'm not sure if platform-python still exists in Fedora > rawhide, that's also why I didn't want to complain about something that no > longer exists :-)). There is no platform-python on Fedora 28+ > I rebased the patch on the pip 18.0, but I had to basically rewrite the > patch from scratch since pip 18 code base looks as it has nothing in common > with pip 9. A big and deep refactoring occurred after Michal wrote his > change. Where can we see the patch? > I tested my rebased patch on Fedora Rawhide (using mock). I installed > "python3-setuptools-39.2.0-7.fc30.noarch.rpm", and then I upgraded > setuptools using "sudo python3 -m pip install -U setuptools". Problem: .py > files are removed from /usr. Now I'm confused: did Michal patch work, or did > I do something wrong when I "rebased" (rewrote) his patch for pip 18? Not sure. Maybe try debug what's going on and why they are removed. > I'm not sure if Michal tested the upgrade case, but it is the main issue of > this GNOME SELinux seapplet bug. I'd say that he did. At least that was what the patch was for. > I also tried to get help from pip developers to rebase the change, but they > didn't reply. That can happen. > Again, maybe my review is wrong, maybe Michal's change is just fine for pip > 9, but anyway, we have to make it working on pip 18 (version used on Fedora > Rawhide). Yes we do. Carry on please. Feel free to hit me with questions.
s/better ide/better idea/
tl; dr Michal Cyprian's patch works as expected, great! > It gets priority when no flags are used. It does not get priority when -s is used. You can try other flags with: (...) I confirm: /usr/local/lib has the priority over /usr/lib by default, but /usr/local/lib is excluded from sys.path if -s or -I flag is used. > Where can we see the patch? I created a new PR: https://src.fedoraproject.org/rpms/python-pip/pull-request/16 Miro spotted the bug that I made during the rebase, the package now works as expected. Thanks Miro! I tested to upgrade python-setuptools-39.2.0-7.fc30.src.rpm on Fedora Rawhide using "sudo python3 -m pip install -U setuptools". Result with the patch: by default, Python 3.7 loads the newer setuptools 40.4.1 from /usr/local/lib, but it loads setuptools 39.2.0 from /usr/lib if -s or -I flag is used. It means that seapplet (which is run using "python3 -E -s") will still be able to load the old setuptools 39.2.0 from /usr/lib.
Thank You! I'll take it from here and move it down to F29, 28, 27...
python-pip-18.0-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5a70fc7038
python-pip-18.0-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5a70fc7038
*** Bug 1604045 has been marked as a duplicate of this bug. ***
*** Bug 1610946 has been marked as a duplicate of this bug. ***
*** Bug 1631785 has been marked as a duplicate of this bug. ***
*** Bug 1632409 has been marked as a duplicate of this bug. ***
python-pip-18.0-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
*** Bug 1653852 has been marked as a duplicate of this bug. ***
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
*** Bug 1765989 has been marked as a duplicate of this bug. ***
*** Bug 1765987 has been marked as a duplicate of this bug. ***