[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#261854: marked as spam Bug#261854 acknowledged by developer (Re: Bug#261854: xlibs: some softlinks not made correctly, installer fails to upgrade)


sorry if this is a double reply (this time, reply-all)

As said in first reply, I disagree.

NOTE: libXft2 is not some Xft replacement. It is written by Keith Packard and installed to /usr/X11R6/lib/ by default: not /usr/lib.

This is contrary to the comments of Daniel Stone, who apparently did no research before giving snide reply and hanging up.

None of XFree86, Debian, KDE, nor Gnome has moved their compiles to point to /usr/lib. They shouldn't on a linux system.

Below is a snipet from gnome.org's bugzilla. Dated '2002 bug the same problem - up to at least '2003 there are dup reports of it.

And can we thank Redhat? Likely so. What do we be it isn't broken in their $$ version of linux? I've have previous experiences with reporting bugs to Redhat. A broken ps and a refusal to fix or accept code comes to mind.

Only package gtk does this: and only for ONE of the xlibs. Which is likely an oversight.

if test $pango_omitted_x_deps = yes ; then
    # Old versions of Xft didn't necessarily include -lX11 in the output
    x_libs="`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS"

Sat Mar  2 14:32:50 2002  Owen Taylor  <otaylor@redhat.com>

        * configure.in: Default to --disable-gtk-doc (avoid Jade
        breakage) and --disable-static (static linking causes
        problems with Xft changes.)

* GTK+-2.4 now requires version 2 of Xft; old fashioned core X
  fonts are no longer supported.

* Try to build libraries with only shared library dependencies on Xft to
  deal with transition to Xft2 [Owen]


Now I see. libxft2 is the new lib, which installs to /usr/lib since it has nothing to do with XFree86.

gtk's pango support was adjusted by Redhat to be incompatible with XFree86, to use only libxft2.


That still doesn't explain why I got the message about libXft to begin with.

From Bugzilla



Bug 86150: Inability to even log in if your Xft is broken High priority

Opened:     2002-06-21 12:05
Product:     pango
Component:     general
Version:     unspecified
Status:     NEW
Priority:     High
Severity:     critical
Reporter: Jim.Gettys@hp.com (Jim Gettys)

If you happen to have a broken Xft (as I did; Keith has since fixed this
bug), Gnome logs you in, but the panel crashes if it cannot find any fonts.

You may get (in your .xsession-errors file, or say, from
gnome-font-properties) complaints that it can't find any fonts.

The panel eventually exists; various other apps have similar behavior.

If no client side fonts can be found, we'd have a much more robust
system that would not fail in a completely obscure way (I end up with
a completely blank screen!) if it would fail back to core fonts.

This problem could occur other other circumstances, like messed up
XftConfig files, I suspect.

------- Additional Comment #1 From Luis Villa 2002-06-25 21:06 -------

Jim: did we decide that this is a gtk bug?

------- Additional Comment #2 From Owen Taylor 2002-06-25 21:34 -------

It's a Pango RFE. I wouldn't call it a bug.

(Pointing Xft at a particular file turns out to work
less than perfectly so it will take some work.)

There are various other Pango bugs which are sitting
on 1.2 or future milestones with "the only way
to do better is to ship a font with Pango" so its
sort of a dup of that.

<<<<<<<<<  SEVERAL MORE DUPS >>>>>>>>>>>>

------- Additional Comment #6 From sven@gimp.org 2003-11-02 10:25 -------

*** Bug 111471 has been marked as a duplicate of this bug. ***

I now I remember. I couldn't open xterm until I fixed the bad linkage concerting libxft?

Of course once I did, I had to fix fonts dirs so adobe fonts could be found (another bug? another story).






Below, we see /usr/lib/libXft directly, which is wrong. A damn peritious thing. Difficult to find how it *became* that way.

If you look *carefully* you see /usr/lib/libXft.so is mentioned as an absolute filename.

If you then look at the blabber of Redhat "coder" in the snippet of Changelog above you see the magic. There is talk about problems with temporarily having to meantion libXft directly. Ahh.

Am I good?  Or does Redhat suck?   Ha ha....

Have fun!


gtk/libgtk-x11-2.0.la:dependency_libs=' /mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk/l ibgdk-x11-2.0.la -L/usr/X11R6/lib -lXrandr -lXinerama -lXext -lXft -lfreetype -l z -lXrender -lfontconfig /mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk-pixbuf/libgdk_pi xbuf-2.0.la -lX11 /usr/lib/libpangoxft-1.0.la /usr/lib/libpangox-1.0.la /usr/lib /libpango-1.0.la /usr/lib/libatk-1.0.la /usr/lib/libgobject-2.0.la /usr/lib/libg
module-2.0.la -ldl /usr/lib/libglib-2.0.la -lm   '
gtk/gtk-query-immodules-2.0:relink_command="(cd /mnt/hda4/hog/tmp/gnome/gtk+-2.4 .3/gtk; { test -z \"\${LIBRARY_PATH+set}\" || unset LIBRARY_PATH || { LIBRARY_PA TH=; export LIBRARY_PATH; }; }; { test -z \"\${COMPILER_PATH+set}\" || unset COM PILER_PATH || { COMPILER_PATH=; export COMPILER_PATH; }; }; { test -z \"\${GCC_E XEC_PREFIX+set}\" || unset GCC_EXEC_PREFIX || { GCC_EXEC_PREFIX=; export GCC_EXE C_PREFIX; }; }; { test -z \"\${LD_RUN_PATH+set}\" || unset LD_RUN_PATH || { LD_R UN_PATH=; export LD_RUN_PATH; }; }; PATH=\"/usr/local/sbin:/usr/sbin:/sbin:/usr/
l/bin\"; export PATH; gcc -g -O2 -Wall -o \$progdir/\$file queryimmodules.o ./. libs/libgtk-x11-2.0.so /mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk/.libs/libgdk-x11-2 .0.so -L/usr/X11R6/lib /usr/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf- 2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lXrandr -lXinerama -lXext /usr/lib/libXft .so /usr/lib/libfreetype.so -lz -lXrender -lfontconfig -lX11 /usr/lib/libpangoxf t-1.0.so /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so /mnt/hda4/hog/tmp/gn ome/gtk+-2.4.3/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lm -Wl,--rpath -Wl,/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gtk/.libs -Wl,--rpath -Wl,/mnt/hda4/hog/tmp/gnome /gtk+-2.4.3/gdk/.libs -Wl,--rpath -Wl,/mnt/hda4/hog/tmp/gnome/gtk+-2.4.3/gdk-pix
buf/.libs -Wl,--rpath -Wl,/usr/local/lib)"


Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#261854: xlibs: some softlinks not made correctly, installer fails to upgrade,
which was filed against the xlibs package.

It has been closed by one of the developers, namely
Daniel Stone <daniels@debian.org>.

Their explanation is attached below.  If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact the developer, by replying to this email.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Received: (at 261854-done) by bugs.debian.org; 28 Jul 2004 16:26:43 +0000
From daniel@fooishbar.org Wed Jul 28 09:26:42 2004
Return-path: <daniel@fooishbar.org>
Received: from fooishbar.org (tycho.fooishbar.org) [] (postfix)
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1BprGM-0007U9-00; Wed, 28 Jul 2004 09:26:42 -0700
Received: by tycho.fooishbar.org (Postfix, from userid 1000)
	id ADB28E9C036; Wed, 28 Jul 2004 09:26:42 -0700 (PDT)
Date: Thu, 29 Jul 2004 02:26:42 +1000
From: Daniel Stone <daniels@debian.org>
To: "John D. Hendrickson" <jdh@hend.net>, 261854-done@bugs.debian.org
Subject: Re: Bug#261854: xlibs: some softlinks not made correctly, installer fails to upgrade
Message-ID: <20040728162642.GP23526@fooishbar.org>
References: <200407281601.i6SG1c4W011734@hend.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="pN9MePJoZbRKbUk1"
Content-Disposition: inline
In-Reply-To: <200407281601.i6SG1c4W011734@hend.net>
User-Agent: Mutt/1.5.6+20040523i
Delivered-To: 261854-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level:

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 28, 2004 at 12:01:38PM -0400, John D. Hendrickson wrote:

Two things.  One, xlibs did not install files correctly.  Two, all X pack=


now require a new directory structure (which I hate).  Anyway the install=


does nothing to provide this new directory structure.  I made a script wh=


does this which has done this for me on several machines.
Just did a "dist-upgrade" to sarge
for libs I had xlib's /usr/lib/libXft.so and a couple others in /usr/lib
These are xlibs, not usr libs, they shouldn't even have links into /usr/l=


After remaking the links the installer goofed, it worked.  Somehow the
installer doesn't take into account the present / previous state when mak=


its links.
I found the ONLY reason libXft need to be in /usr/lib is due to gtk.  Whi=


all else of gnome correctly uses X11R6/lib, gtk uses /usr/lib, oddly.  Fix
that and you fix allot of confusion.  The ./configure for gtk is just flat
wrong.  And using ./configure --prefix=3DPATH won't help - becuase it is =


wrong - a goof up.

/usr/X11R6 is being moved away from by upstream and everyone else sane
because it's beyond a joke nowadays. Many things -- not just Xft;
fontconfig, Xcursor, Xrender, et al -- are in /usr/lib now. You haven't
been near specific enough. What failed? What 'goofed'? Which installer
were you using? Did you do a complete dist-upgrade? If so, why is your
xlibs package still at 4.1.0-16, which is the woody version?

Closing this bug report as utterly bogus and invalid unless submitter
provides a compelling rationale otherwise.

Daniel Stone                                                <daniels@debian=
Debian: the universal operating system                     http://www.debia=

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

Version: GnuPG v1.2.4 (GNU/Linux)



Reply to: