Bug 1652992
| Summary: | lirc-setup: No module named 'gi' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brian J. Murrell <brian> | ||||
| Component: | lirc | Assignee: | Alec Leamas <leamas.alec> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 33 | CC: | hobbes1069, jarodwilson, leamas.alec | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-11-03 16:40:48 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
>All of this could be due to installing on a "minimal" system, indeed, but the package should set the correct dependencies to be functional.
Indeed, this looks bad. Could you please attach the list of packages installed, preferably before installing lirc but if you cannot backtrack the current list should work as well.
Created attachment 1508340 [details]
dnf.rpm.log
I believe this is a log of the RPMs installed in the order installed.
The initial set of packages is more-or-less:
kernel kodi-inputstream-adaptive nfs-utils libwbclient openssh-server autofs kmod-nvidia-340xx screen dracut-network initscripts lirc-core xorg-x11-xinit hostname $NVIDIA_KMOD lirc-config
Maybe that gives you a starting point to repro.
So, the issue with the:
ModuleNotFoundError: No module named '_client'
is because of a nasty little bit of code in python-pkg/lirc/paths.py:
if os.path.exists(os.path.join(HERE, '_client.so')):
try:
os.unlink(os.path.join(HERE, '_client.so'))
except PermissionError:
pass
if os.path.exists(os.path.join(HERE, '..', 'lib', '.libs', '_client.so')):
if not os.path.exists(os.path.join(HERE, '_client.so')):
# development tree Makefile.am creates lib/libs/_client.so
# after 'make install'; plain 'make' isn't enough.
os.symlink(os.path.join('..', 'lib', '.libs', '_client.so'),
os.path.join(HERE, '_client.so'))
else:
# 'python setup.py' artifact:
SRC = glob.glob(os.path.join(
HERE, '..build/lib.linux*/_client.cpython*.so'))
if len(SRC) == 1:
os.symlink(os.path.join(SRC[0]), os.path.join(HERE, '_client.so'))
This is obviously disastrous in a production deployment (i.e. RPMs) when lirc-setup is run as root as it nukes /usr/lib64/python3.7/site-packages/lirc/_client.so and doesn't restore it.
This code probably needs patching out at build time for RPM deployment.
I've filed https://sourceforge.net/p/lirc/tickets/341/ upstream about it.
Any activity here? This problem still exists in Fedora 30. I'm leaving for work related training today but I may take a look at this while at the hotel... Can you confirm it just removing the whole "if" section works? Should lirc-setup be run as root? I'm not intimately familiar with it. > just removing the whole "if" section works? Yeah, you could just remove the: if os.path.exists(os.path.join(HERE, '_client.so')): try: os.unlink(os.path.join(HERE, '_client.so')) except PermissionError: pass for the most minimum change needed. But honestly, the block after it: if os.path.exists(os.path.join(HERE, '..', 'lib', '.libs', '_client.so')): if not os.path.exists(os.path.join(HERE, '_client.so')): # development tree Makefile.am creates lib/libs/_client.so # after 'make install'; plain 'make' isn't enough. os.symlink(os.path.join('..', 'lib', '.libs', '_client.so'), os.path.join(HERE, '_client.so')) else: # 'python setup.py' artifact: SRC = glob.glob(os.path.join( HERE, '..build/lib.linux*/_client.cpython*.so')) if len(SRC) == 1: os.symlink(os.path.join(SRC[0]), os.path.join(HERE, '_client.so')) is pretty useless if you do so it should probably get removed also. > Should lirc-setup be run as root? I'm not intimately familiar with it. I think it has to be to modify the files in /etc/lirc/. Well, there's not much more in the file... What would actually be left? This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 '30'. 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 30 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. No evidence that this has been fixed. This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33. hm... F32: the /usr/bin/lirc-setup link is definitely broken, pointing to somehting not existing. lrwxrwxrwx 1 root root 52 Jan 29 2020 /usr/bin/lirc-setup -> ../lib/python3.8/site-packages/lirc-setup/lirc-setup Problem seems to be that lirc-setup lives in /usr/lib64/python3.8/site-packages/lirc-setup/lirc-setup i. e., in lib64 instead of lib. Invoked here, it seems to work fine, the initial 'module not found' is not present. For reasons I cannot understand, the link is ok and program starts fine in rawhide. Will look into backporting something (what?) into at least F33, but closing now as fixed Where exactly is this fixed? I don't see anything relevant in https://src.fedoraproject.org/rpms/lirc/commits/master. |
Description of problem: Packaging is missing dependencies. Version-Release number of selected component (if applicable): lirc-config-0.10.0-14.fc29.noarch How reproducible: 100% Steps to Reproduce: 1. Install bare minimum system + lirc-config 2. run lirc-setup 3. Actual results: Traceback (most recent call last): File "/usr/bin/lirc-setup", line 16, in <module> import mvc_control File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py", line 12, in <module> import gi ModuleNotFoundError: No module named 'gi' Expected results: Should work Additional info: After installing python3-gobject-base the fun continues with: # lirc-setup /usr/lib64/python3.7/site-packages/gi/overrides/Gtk.py:55: RuntimeWarning: You have imported the Gtk 2.0 module. Because Gtk 2.0 was not designed for use with introspection some of the interfaces and API will fail. As such this is not supported by the pygobject development team and we encourage you to port your app to Gtk 3 or greater. PyGTK is the recomended python module to use with Gtk 2.0 warnings.warn(warn_msg, RuntimeWarning) /usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py:13: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '2.0') before import to ensure that the right version gets loaded. from gi.repository import Gtk # pylint: disable=no-name-in-module Traceback (most recent call last): File "/usr/bin/lirc-setup", line 16, in <module> import mvc_control File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py", line 16, in <module> import choosers File "/usr/lib64/python3.7/site-packages/lirc-setup/choosers.py", line 11, in <module> import mvc_model File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_model.py", line 14, in <module> from lirc.database import Database File "/usr/lib64/python3.7/site-packages/lirc/__init__.py", line 7, in <module> from .client import get_default_lircrc_path File "/usr/lib64/python3.7/site-packages/lirc/client.py", line 38, in <module> import _client ModuleNotFoundError: No module named '_client' The file is there before I run lirc-setup but then it's gone after: bash-4.4# ls -l /usr/lib64/python3.7/site-packages/lirc/_client.so -rwxr-xr-x 1 root root 15352 Oct 12 18:24 /usr/lib64/python3.7/site-packages/lirc/_client.so bash-4.4# lirc-setup /usr/lib64/python3.7/site-packages/gi/overrides/Gtk.py:55: RuntimeWarning: You have imported the Gtk 2.0 module. Because Gtk 2.0 was not designed for use with introspection some of the interfaces and API will fail. As such this is not supported by the pygobject development team and we encourage you to port your app to Gtk 3 or greater. PyGTK is the recomended python module to use with Gtk 2.0 warnings.warn(warn_msg, RuntimeWarning) /usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py:13: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '2.0') before import to ensure that the right version gets loaded. from gi.repository import Gtk # pylint: disable=no-name-in-module Traceback (most recent call last): File "/usr/bin/lirc-setup", line 16, in <module> import mvc_control File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py", line 16, in <module> import choosers File "/usr/lib64/python3.7/site-packages/lirc-setup/choosers.py", line 11, in <module> import mvc_model File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_model.py", line 14, in <module> from lirc.database import Database File "/usr/lib64/python3.7/site-packages/lirc/__init__.py", line 7, in <module> from .client import get_default_lircrc_path File "/usr/lib64/python3.7/site-packages/lirc/client.py", line 38, in <module> import _client ModuleNotFoundError: No module named '_client' bash-4.4# ls -l /usr/lib64/python3.7/site-packages/lirc/_client.so ls: cannot access '/usr/lib64/python3.7/site-packages/lirc/_client.so': No such file or directory Then trying with an unprivilledged user so that the file can't be removed: bash-4.4# su - brian -c lirc-setup /usr/lib64/python3.7/site-packages/gi/overrides/Gtk.py:55: RuntimeWarning: You have imported the Gtk 2.0 module. Because Gtk 2.0 was not designed for use with introspection some of the interfaces and API will fail. As such this is not supported by the pygobject development team and we encourage you to port your app to Gtk 3 or greater. PyGTK is the recomended python module to use with Gtk 2.0 warnings.warn(warn_msg, RuntimeWarning) /usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py:13: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '2.0') before import to ensure that the right version gets loaded. from gi.repository import Gtk # pylint: disable=no-name-in-module Traceback (most recent call last): File "/usr/bin/lirc-setup", line 16, in <module> import mvc_control File "/usr/lib64/python3.7/site-packages/lirc-setup/mvc_control.py", line 16, in <module> import choosers File "/usr/lib64/python3.7/site-packages/lirc-setup/choosers.py", line 12, in <module> import baseview File "/usr/lib64/python3.7/site-packages/lirc-setup/baseview.py", line 7, in <module> gi.require_version('Gtk', '3.0') File "/usr/lib64/python3.7/site-packages/gi/__init__.py", line 121, in require_version (namespace, loaded_version)) ValueError: Namespace Gtk is already loaded with version 2.0 Seems like this package is riddled with issues, hence the Severity: urgent setting. All of this could be due to installing on a "minimal" system, indeed, but the package should set the correct dependencies to be functional.