This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 77838 - Upgrading to XFCVS snapshot disabled Xft2
Upgrading to XFCVS snapshot disabled Xft2
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: 79579
  Show dependency treegraph
 
Reported: 2002-11-14 04:22 EST by Per Winkvist
Modified: 2007-04-18 12:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-30 04:59:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Per Winkvist 2002-11-14 04:22:19 EST
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:
Comment 1 Mike A. Harris 2002-11-15 21:06:52 EST
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.
Comment 2 Mike A. Harris 2002-12-26 20:35:05 EST
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.

Comment 3 Mike A. Harris 2003-01-19 19:58:10 EST
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.
Comment 4 Mike A. Harris 2003-02-13 05:11:18 EST
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.
Comment 5 Mike A. Harris 2003-02-13 05:15:38 EST
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.
Comment 6 Jeff Johnson 2003-02-13 10:29:22 EST
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
Comment 7 Per Winkvist 2003-02-25 01:24:15 EST
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. 
 
Comment 8 Mike A. Harris 2003-02-25 08:54:46 EST
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
}
Comment 9 Mike A. Harris 2003-02-25 08:58:22 EST
Any ideas?
Comment 10 Jeff Johnson 2003-02-25 10:12:18 EST
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.
Comment 11 Per Winkvist 2003-02-26 07:01:18 EST
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 
 
 
 
Comment 12 Mike A. Harris 2003-05-30 04:59:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.