Description of problem: Python backend (installed by python2-omniORB) is not found by default when using omnidl (installed by omniORB-devel). Version-Release number of selected component (if applicable): 4.2.2-4 How reproducible: Easily Steps to Reproduce: 1. install omniORB-devel & python2-omniORB 2. run 'omniidl -bpython /usr/share/idl/omniORB/poa.idl' Actual results: omniidl: Could not import back-end 'python' omniidl: Maybe you need to use the -p option? omniidl: (The error was 'No module named 'omniidl_be.python'' Expected results: Expected files are generated Additional info: This is working in F26 but not in F27 Workaround is to add '-p /usr/lib/python2.7/site-packages/omniidl_be/'
Hmm since F27 has both python2-omniORB and python3-omniORB, I wonder whether we also need to add omniidl-py2 and omniidl-py3 wrappers, since otherwise it is unclear which version it should use. I'm not all that familiar with omniORB, so I welcome opinions.
(I am the maintainer of omniORB, but I have nothing do do with the Fedora packaging of it.) The same omniidl python back-end generates code for both Python 2 and Python 3. The problem with the packaging is that omniidl is in the omniORB-devel package, and that uses Python 3. Therefore, in the python2-omniORB package, the omniidl_be/python.py that is in the Python 2.7 site-packages directory is not found. The python2-omniORB package should not include omniidl_be/python.py. The python3-omniORB package does not include omniidl_be/python.py I see that there is an omniORBpy-devel package that _does_ include omniidl_be/python.py, in a form that will work fine for use with both Python 2 and Python 3. Unfortunately, omniORBpy-devel does not install because it depends on omniORB-devel, and both packages try to provide /usr/lib/python3.6/site-packages/omniidl_be/__pycache__/__init__.cpython-36.pyc : Error: Transaction check error: file /usr/lib/python3.6/site-packages/omniidl_be/__pycache__/__init__.cpython-36.opt-1.pyc conflicts between attempted installs of omniORBpy-devel-4.2.2-4.fc27.noarch and omniORB-devel-4.2.2-4.fc27.x86_64 file /usr/lib/python3.6/site-packages/omniidl_be/__pycache__/__init__.cpython-36.pyc conflicts between attempted installs of omniORBpy-devel-4.2.2-4.fc27.noarch and omniORB-devel-4.2.2-4.fc27.x86_64 The solution to this bug is therefore to: 1. Remove /usr/lib/python2.7/site-packages/omniidl_be/python.py* from python2-omniORB 2. Remove /usr/lib/python3.6/site-packages/omniidl_be/__pycache__/__init__.cpython-36* from omniORBpy-devel
Thanks, I'll look at fixing the packages this evening.
Can you confirm that this build fixes the issues? Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=23986387 F27: https://koji.fedoraproject.org/koji/taskinfo?taskID=23986395
Yes, it does
omniORBpy-4.2.2-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0d8de415d9
Is there some reason why omniORBpy-devel rpm is not build in referenced build https://koji.fedoraproject.org/koji/buildinfo?buildID=1013135 ?
It is, it's just noarch (omniORBpy-devel-4.2.2-5.fc27.noarch.rpm)
Ooops, sorry for my blindness...
omniORBpy-4.2.2-5.fc27 has been pushed to the Fedora 27 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-0d8de415d9
omniORBpy-4.2.2-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
I had to use the following workaround: $ omniidl -bpython -p./omniORBpy-4.3.0/python3/omniidl_be/ ... So point omniidl -p option to the source tree omniidl_be directory.