Description of problem: $ xterm xterm: error while loading shared libraries: libXpm.so.4: cannot open shared object file: No such file or directory Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. boot boot-nonfree.iso 2. ftp network install, apply updates, reboot 3. urpmi xterm 4. xterm Workaround solution: cd /usr/lib64 ln -s nx/libXpm.so.4
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
CC: (none) => mageia, mageia
Hmm, xterm itself doesn't need libXpm (objdump -p `which xterm`| grep Xpm), so it must be one of the libraries that need it that had that require (ldd `which xterm` | grep Xpm does show results). Looking a bit closer, it seems that libXaw7 needs it... (objdump -p /usr/lib64/libXaw.so.7 | grep Xpm) rpm -q --requires -f /usr/lib64/libXaw.so.7 | grep Xpm libXpm.so.4()(64bit) So, what provides "libXpm.so.4()(64bit)"? urpmq --whatprovides "libXpm.so.4()(64bit)" lib64xpm4|lib64nxX11_0 So, lib64nxX11_0 has the provide, but it doesn't really provide that.... Now this problem isn't localised to libXpm... e.g. urpmq --whatprovides "libX11.so.6()(64bit)" lib64x11_6|lib64nxX11_0 urpmq --whatprovides "libXdamage.so.1()(64bit)" lib64nxX11_0|lib64xdamage1 So this lib64nxX11_0 package is just causing confusion.... Perhaps it needs to have some special tags in it to exclude these automatic provides? e.g. %define _provides_exceptions "libXdamage.so.1()(64bit)|..." (not sure of the syntax here). Either way I think this is something to fix in nx, not in xterm.
Source RPM: libxpm => nx-3.5.0-1.mga2.src.rpm
Adding Oliver as he is maintainer of nx.
CC: (none) => oliver.bgr
Looking into it
New nx package submitted, that does filter those provides.
clean beta1 install does not have the problem.
Status: NEW => RESOLVEDResolution: (none) => FIXED