Description of problem: The createrepo command does not work to create a DNF repository. Version-Release number of selected component (if applicable): createrepo-0.10.3-15.fc28.noarch How reproducible: Run the command to create a repository. Steps to Reproduce: 1. Go to the repository directory # cd /my/repo 2. Remove the existing repository data # rm -rf repodata 3. Create the repository data # createrepo --database . Actual results: # createrepo --database . Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 29, in <module> import createrepo File "/usr/lib/python2.7/site-packages/createrepo/__init__.py", line 21, in <module> import yumbased File "/usr/lib/python2.7/site-packages/createrepo/yumbased.py", line 27, in <module> from yum.packages import YumLocalPackage File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 96, in <module> from yum.drpm import DeltaInfo, DeltaPackage File "/usr/lib/python2.7/site-packages/yum/drpm.py", line 27, in <module> from xml.etree.cElementTree import iterparse File "/usr/lib64/python2.7/xml/etree/cElementTree.py", line 3, in <module> from _elementtree import * ImportError: PyCapsule_Import could not import module "pyexpat" Expected results: The repository data should have been created successfully. Additional info: The output of "dnf check" is empty, so no dependency issue exists in the specific machine.
Standard Python libraries failing to load is not a createrepo problem but a Python problem, possibly a corrupted installation. I'd suggest 'rpm -V python2-libs' for starters. If there are missing files etc then reinstall ought to fix.
$ createrepo --database . Spawning worker 0 with 1 pkgs Workers Finished Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs Sqlite DBs complete $ rpm -q createrepo createrepo-0.10.3-15.fc28.noarch $ python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from _elementtree import * >>> Could you please post output of: $ python2 >>> import sys >>> import pprint >>> pprint.pprint(sys.path)
Just to clarify that the output of 'rpm -V python2-libs' does not print any issue. The requested information is: $ python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> import pprint >>> pprint.pprint(sys.path) ['', '/usr/lib/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gst-0.10', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages'] >>>
This seems all OK. What about: >>> import pyexpat and >>> from _elementtree import *
The output follows: $ python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pyexpat >>> from _elementtree import * >>>
And this is all in the same folder with your repo and in the same shell with the same variables? Because if so, it's very very weird. I assume the following works as well? >>> import createrepo or: >>> from yum.packages import YumLocalPackage
You are right! I have tested the above commands with normal user, wheras the problem was observed on root. I have isolated the problem to be related to the use of "sudo" command, because it was also maintaining my LD_LIBRARY_PATH. There is a 12.2.0.1.0 client installation that seems to affect the python installation with the following weird behaviour: # su - # python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import createrepo >>> from yum.packages import YumLocalPackage >>> # export LD_LIBRARY_PATH=/home/oracle/client/product/12.2.0/devel/lib # python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import createrepo Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/createrepo/__init__.py", line 21, in <module> import yumbased File "/usr/lib/python2.7/site-packages/createrepo/yumbased.py", line 27, in <module> from yum.packages import YumLocalPackage File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 96, in <module> from yum.drpm import DeltaInfo, DeltaPackage File "/usr/lib/python2.7/site-packages/yum/drpm.py", line 27, in <module> from xml.etree.cElementTree import iterparse File "/usr/lib64/python2.7/xml/etree/cElementTree.py", line 3, in <module> from _elementtree import * ImportError: PyCapsule_Import could not import module "pyexpat" >>> import pyexpat Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/lib64/python2.7/lib-dynload/pyexpat.so: undefined symbol: XML_SetHashSalt >>> # export LD_LIBRARY_PATH= # python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import createrepo >>> from yum.packages import YumLocalPackage >>> However, normal users are not affected by this issue: $ export LD_LIBRARY_PATH=/home/oracle/client/product/12.2.0/devel/lib $ python2 Python 2.7.15 (default, May 16 2018, 17:50:09) [GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import createrepo >>> import pyexpat >>>
I cannot reproduce this even as root, maybe it depends on the actual content of that directory?
Maybe it has something from this list: linux-vdso.so.1 libexpat.so.1 libpthread.so.0 libc.so.6 libdl.so.2 libutil.so.1 libm.so.6
Created attachment 1473619 [details] oracle-client-library-listing.txt It surely depends on the contents. There is a "Oracle Database 12c Release 2 Client (12.2.0.1.0) for Linux x86-64" installed there from Oracle: https://www.oracle.com/technetwork/database/enterprise-edition/downloads/oracle12c-linux-12201-3608234.html It is 473MB and I cannot include it in the ticket. I have included only the contents in the file "oracle-client-library-listing.txt".
Ok, there is libexpat.so.1 which is libexpat.so.1.5.2 but we have libexpat.so.1.6.7. Clearly, when you set LD_LIBRARY_PATH like this, things can break. As for why it only happens with root, I have no idea, maybe the regular user cannot read the files in /home/oracle?
That would be it: $ wget https://kojipkgs.fedoraproject.org//packages/expat/2.0.1/11.fc15/x86_64/expat-2.0.1-11.fc15.x86_64.rpm $ file expat-2.0.1-11.fc15.x86_64.rpm expat-2.0.1-11.fc15.x86_64.rpm: RPM v3.0 bin i386/x86_64 expat-2.0.1-11.fc15 $ rpm2cpio ./*.rpm | cpio -idmv ./lib64/libexpat.so.1 ./lib64/libexpat.so.1.5.2 ./usr/bin/xmlwf ./usr/share/doc/expat-2.0.1 ./usr/share/doc/expat-2.0.1/COPYING ./usr/share/doc/expat-2.0.1/README ./usr/share/man/man1/xmlwf.1.gz 396 blocks $ ls expat-2.0.1-11.fc15.x86_64.rpm lib64 usr $ LD_LIBRARY_PATH=./lib64/ createrepo --database . Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 29, in <module> import createrepo File "/usr/lib/python2.7/site-packages/createrepo/__init__.py", line 21, in <module> import yumbased File "/usr/lib/python2.7/site-packages/createrepo/yumbased.py", line 27, in <module> from yum.packages import YumLocalPackage File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 96, in <module> from yum.drpm import DeltaInfo, DeltaPackage File "/usr/lib/python2.7/site-packages/yum/drpm.py", line 27, in <module> from xml.etree.cElementTree import iterparse File "/usr/lib64/python2.7/xml/etree/cElementTree.py", line 3, in <module> from _elementtree import * ImportError: PyCapsule_Import could not import module "pyexpat" $ chmod 700 ./lib64/ $ sudo chown root:root ./lib64/ $ LD_LIBRARY_PATH=./lib64/ createrepo --database . Spawning worker 0 with 1 pkgs Workers Finished Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs Sqlite DBs complete
The LD_LIBRARY is required by the Oracle Client to run the tools. You are right about the permissions. Although I am a member of oinstall group, it seems that the specific library does not provide read permissions to the group: $ ls -al $ORACLE_HOME/lib/libexpat.so.1.5.2 -rw------- 1 oracle oinstall 437915 Μαΐ 12 2016 /home/oracle/client/product/12.2.0/devel/lib/libexpat.so.1.5.2 OK, the mystery was resolved. It is the evil use of LD_LIBRARY_PATH to blame. If there is nothing that can be done to prevent this issue, the workaround to reset the LD_LIBRARY_PATH is sufficient.