From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: When I Uvh'd the 20021105 snapshot and restarted the fonts looked awful. After upgrading it seems I no longer have any /usr/lib/libXft* files... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Make sure you have Xft and Xft-devel installed 2. Install the XF 20021105 snapshot 3. Where did Xft/Xft-devel go ? Additional info:
Xft2 used to be part of the "Xft" package in RHL 8.0. Now that it is officially included in XFree86 CVS directly however, we no longer need to supply it as a separate RPM package, so the new X RPMs will obsolete the Xft package and uninstall it. The XFree86 supplied Xft2 libraries are in the usual X11R6 lib dir in: /usr/X11R6/lib A few people have reported this problem occuring upon upgrades to the CVS packages, but I've not been able to reproduce it yet. I believe there is some kind of race condition occuring which triggers only randomly, although I have not looked to deep into the problem yet. The simple solution is to manually run "ldconfig" as root after upgrading. That will solve the problem until I can figure out where the race condition is occuring exactly.
I'm able to reproduce this sometimes, but not always for some reason. Still not sure what is happening. Running ldconfig after upgrading solves the problem, however all post/postun scripts contain the proper ldconfig calls that are needed for things to work properly, so I'm not sure what the problem is.
Can anyone out there still reproduce this? I'm thinking it was some weird rpm bug or similar, as I've not had any more bug reports from people since, haven't gotten any emails about it, nor seen people reporting the problem on our mailing lists or in IRC lately either. Clean 8.0 install with or without updates then upgraded to latest rawhide X, with all dependancies should prove all that is needed to test if it is reproduceable. I can't seem to get it to occur anymore, but don't want to close it as RAWHIDE just in case it is indeed still a problem.
Yes, I just reproduced this again. It is unlikely to occur on a full operating system upgrade, which is the fully supported method of installing XFree86, so it isn't likely to hit us on a supported path. Nonetheless, there is an irritating bug that I can't for the life of me figure out here. All of the RPM scripts in post/postun, etc. are calling ldconfig as they should, however once X is upgraded, Xft2 is no longer useable until ldconfig is ran. One thing to note, is that the Xft2 library moved from /usr/lib to /usr/X11R6/lib if that matters. It shouldn't though, since ldconfig is ran properly in %post as stated above. I'm at my wits end as to what could be causing this irritating bug. Is it an RPM bug with bad transaction ordering? Or is it some other obscure issue? No idea. I'm going to continue to test things out however and see if I can figure it out. I've carbon copied various other engineers who might be able to shed some fresh ideas on the issue.
I've changed the Obsoletes: lines to remove version information for Xft and Xft-devel, and I've added Conflicts: Xft / Xft-devel lines where appropriate, in hopes RPM will order things differently.
Adding Obsoletes: and Conflicts: will not affect package ordering at all. What may be going on is that the ldconfig in the package is skipped because the previous package just ran ldconfig. If you attach the output of a failed install with -vv, I'll verify whether this is happening. Otherwise, you can try writing your %post as %post /sbin/ldconfig rather than %post -p /sbin/ldconfig
I noticed this again on the 4.2.99.902-20030218.0 snapshot while Uvh from XFree86 4.2.1 (mharris/testing/8.0/XFree86/Dec or Jan release, don't remember) I tried to start an xterm and saw that libXft was missing. Running ldconfig solved it once again.
jbj) None of the post scripts use the form: %post -p /sbin/ldconfig Here are the post scripts: %post libs { grep "^%{_x11libdir}$" /etc/ld.so.conf &> /dev/null [ $? -ne 0 ] && echo "%{_x11libdir}" >> /etc/ld.so.conf /sbin/ldconfig } %postun libs { if [ "$1" = "0" ]; then grep -v "^%{_x11libdir}$" /etc/ld.so.conf > /etc/ld.so.conf.new # preserve permissions cat /etc/ld.so.conf.new > /etc/ld.so.conf rm -f /etc/ld.so.conf.new fi /sbin/ldconfig } %post Mesa-libGL { grep "^%{_x11libdir}$" /etc/ld.so.conf &> /dev/null [ $? -ne 0 ] && echo "%{_x11libdir}" >> /etc/ld.so.conf /sbin/ldconfig } %postun Mesa-libGL { /sbin/ldconfig } %post Mesa-libGLU { grep "^%{_x11libdir}$" /etc/ld.so.conf &> /dev/null [ $? -ne 0 ] && echo "%{_x11libdir}" >> /etc/ld.so.conf /sbin/ldconfig } %postun Mesa-libGLU { /sbin/ldconfig }
Any ideas?
Can you reproduce this problem? If so, please give the list of packages installed in the exact order (i.e. output with -Uv or -Uvv) so I can tell whether this is an rpm or packaging problem. I need to see what packages were installed just before so that I can tell whether a skipped ldconfig is the cause. From what I looked at before this was not the case, but it was hard to tell from looking at --last output.
I tried it again now and I couldn't reproduce it :( 1. Uvh --oldpackage XFree* freetype* Xft* kernel chkfontpath fontconfig (from 8.0) 2. Then (all packages are from rawhide/SRPMS except kernel which is from rawhide/i386) : [root@h204n1fls20o1047 gold]# rpm -Uvh *.rpm &> rpm_uvh.log warning: kernel-2.4.20-2.54.athlon.rpm: V3 DSA signature: NOKEY, key ID 897da07a Preparing... ### freetype ### fontconfig ### ttmkfdir ### freetype-devel ### kernel ### XFree86-Mesa-libGLU ### fontconfig-devel ### XFree86-libs-data ### XFree86-doc ### XFree86-Xvfb ### XFree86-libs ### XFree86-font-utils ### XFree86-Mesa-libGL ### XFree86-xfs ### chkfontpath ### XFree86-xauth ### XFree86-base-fonts ### XFree86 ### XFree86-100dpi-fonts ### XFree86-75dpi-fonts ### XFree86-Xnest ### XFree86-devel ### XFree86-tools ### XFree86-truetype-fonts ### XFree86-twm ### XFree86-xdm ### freetype-demos ### freetype-utils ### ldd -r /usr/X11/bin/xterm looks ok
This problem is too bizarre to track down, and it isn't worth spending the amount of time on it that it likely requires to figure out. The only time this problem manifests itself in practice, is when performing operations which are officially unsupported, such as upgrading Red Hat Linux 8.0 with packages from Red Hat Linux 9 or rawhide. It isn't worth spending the time to try and figure out at this stage, as nobody is reporting it any more, and most people likely just upgraded to RHL 9 anyway, or will. Also, running ldconfig is a simple and easy workaround we can give to anyone who does hit this problem.