Hi, qt-3.1 is out and it supports xft-2, but our xft-handling is not the best imho: -emerged xfree-4.2.1 and never xft-2: works great (with xft from xfree) -emerged xfree-4.2.1 and xft-2, but removed xft-2: does not work, because xft-2 has overwritten /usr/include/X11/Xft/Xft.h this works after emerge xfree again -emerged xfree-4.2.1 and xft-2: does not work, the following problems are in the xft-2 ebuild: -it overwrites files from xfree (/usr/include/X11/Xft/*) and do not replace /usr/include/X11/Xft/XftFreetype.h (which is located in ${S}/Xft/XftFreetype.h -it installs /usr/lib/libXft.so.2.0 (and libXft.so), but qt fails because there is also /usr/X11R6/lib/libXft.so this works after removing /usr/X11R6/lib/libXft.* i think we should only have xft-2 in portage, xfree should no longer install xft. are there any apps which needs xft-1? foser said a newer pango also needs xft-2.
pango 1.1, basicly a developers release. But afaik RH used it in their 8.0 release, so i think it's safe to use it (i've been running it for weeks just fine now). And as i mentioned in the mailing, i think we avoid a lot of problems if we can do the move to xft2 in one go : xfree, GNOME (pango), kde, mozilla ... <things i forgot here> .
Get kde to work fine with it first, and we can talk. Also i think stuff like fluxbox may use xft (maybe patched). Afaik, xft-2 should create its own libXft.so symlinked to libXft.so.2.0. Also, it do not come with XftFreetype.h.
ok, then we can talk now, azarah, kde works with xft-2 :) the only problem we have during xfree/xft2 installation is the following: we have a libXft.so in /usr/X11R6/lib/ and in /usr/lib/, the one in /usr/X11R6/lib points to libXft.so.1.1, the one in /usr/lib points to libXft.so.2.0. the only thing to do is to remove /usr/X11R6/lib/libXft.so, then qt will build fine with xft-2 support, and kde-3.1 will also have xft-2 support after emerge kdelibs. kde is ready for xft-2 (if kde-3.1 final is out, which should be next monday).
*** Bug 10773 has been marked as a duplicate of this bug. ***
My consern is rather for those that still use 3.0.4, or will want to use it. We should make sure that 3.0.4 will compile fine (for instance kdebase broke with xft1.2 ...).
well, if we split xft from xfree ebuild, there will be no problem imho: qt-3.0.5/kde-3.0.4 have a depend on xft-1, qt-3.1/kde-3.1 have a depend on xft-2. xfree can depend on xft-1. or are there any problem i disregarded?
Yes, they do not coexist.
i just tested xft-2 and qt-3.1 with kde-3.0.4, it compiles & works fine. qt-3.0.5 does only compile with xft-support if there is a X11/Xft/XftFreetype.h (which is only provided by xft-1), so it will skip XftFreetype-support with xft-2 merged.
Ah and that should be fixed in the xft-2.0-r1 ebuild.
Ok, I merge xft-2.0, pango-1.1.3, atk-1.1.1 and gtk+-2.1.2. Everthing seems to be working fine, except sawfish-1.2 which I saw could use the xft pkgconfig stuff, but fails to compile. The ownly hassles I ran into was right after I merged it, I had to restart X or some things segfaulted, and gnome-terminal used the old font name for ms-courier, and segfaulted until I changed it in gconf-editor (cool app btw ;D ). On the KDE side ... qt-3.1 merge fine against latest xft ebuild. kdelibs merged fine. I will test kdebase tonight.
Openbox just hit 2.2.1 (development release) that wants/needs Xft2. I just spent some time talking with an OB dev and he made me realize that the last 2 devel releases and the latest stable release ALL want Xft2 and that I've been doing some seds, not as a fix, but to get around Xft2. Regardless.. The sooner we can get a real/working/stable/full Xft2 in portage, the better. Fluxbox also just hit 0.1.13 which has AA support, though I believe it's using the older Xft. It can't be far behind though.
Azarah: i think i know why sawfish fails to compile, contact me on IRC for that. something weird is going on and i'm not sure why it happens. For that matter i have checked the rawhide packages of both gtk+-2.1 and pango-1.1 and the patches seem to be unimportant. mkeadle: the xft2 in portage is stable and working, the only problem is that as soon as you install it you need to upgrade all xft using packs Hmm on another note, what to do about possible fontconfig crashes on bad(?) fonts. I'm no great hacker, but we could at least do a minimal patch to make it show the font it is working so people know where it fails (i had to debug build it and run it in gdb to find out).
Ok status update, can everybody report where it's at ? GNOME seems to test fine, besides me and Azarah there are probably a few people running unstable gtk right now (x86). It's also marked testing for ppc. How about KDE ? And the *box-es ? Mozilla 1.2.1 is on it's way and so far i've tested 1.2(b) and they all work fine with my system xft2. Is time to get the other archs involved as well ?
Sawfish issue is fixed. Gnome is working fine, so is mozilla-1.2. Also KDE 3.0.4 test fine with QT 3.1. I say we should be ready to go. Maybe just mark xft, pango-1.1 and gtk+-2.1 as testing, and unmask. Also feel we should use the unstable atk, as that is how I tested it, and it works fine.
Err, maybe also mask the libgnomeui versions that we know segfault (ie, without the patch).
Well it's about time i unmask GNOME 2.0.3 , i can put all this in. I'll fix control-center as well to use the XFT2 stuff.
at martin's invitation i would like to help test Xft2 i upgraded to pango-1.1.3, gtk-2.1.2 mozilla-1.2 and rebuild galeon-cvs its all very pretty now and works fine here i am still running the non masked ~86 version's of the rest of gnome-2 im thinking about going all the way and installing all the masked gnome 2.1 ebuilds let me know if there is anything i can help test
No need for that. The test is just to see if gnome-2.0 works fine with pango-1.1.3, gtk-2.1.2 and xft-2.0.
Foser, small problem ... What are we going to do when xfree-4.3.0 comes out ? I *think* it would have been better if we put the Xft libs in /usr/X11R6/lib ... Comments ?
Make it block xft2 ? The problem was that if you change the prefix it installed the pkgconfig file wrong (and maybe had the paths in it wrong too.. im not sure of that).
Hmm, ok. I am working on xfree-4.2.1-r2, and as we are near Xft2, Was thinking to integrate it so long (to not have the /usr/X11R6/lib/libXft.so issue). Will see how it goes.
Doesn't this (integrating in 4.2.1) cut the backwards compatability ?
Well, we will eventually have 4.3.0, and then we will have mostly the same issues. But you are right, prob too close to 1.4, and not tested.
guys just like to let you know something i spotted after upgrading to gtk+-2.1.2 my gtk theme's based on engines wernt working properly when i used a engine based theme it looked mostly like the default theme gtk+-2.0 puts the engine libs in /usr/lib/gtk-2.0/2.0.0/engines and 2.1.2 puts them in /usr/lib/gtk-2.0/2.0.102/engines i had to re emerge them to fix the problem maybe something to let people know about when upgrading foser - i like the new control-center BTW very cool :)
Just a quickie: The xft2/pango 1.1.3 update from portage broke nearly all my apps. [output] snafu x11-libs # pan ** (pan:2381): CRITICAL **: file pango-fontset.c: line 84 (pango_fontset_get_font): assertion `fontset != NULL' failed ** (pan:2381): CRITICAL **: file pango-fontset.c: line 84 (pango_fontset_get_font): assertion `fontset != NULL' failed ** (pan:2381): CRITICAL **: file pango-fontset.c: line 84 (pango_fontset_get_font): assertion `fontset != NULL' failed ** (pan:2381): CRITICAL **: file pango-fontset.c: line 84 (pango_fontset_get_font): assertion `fontset != NULL' failed (pan:2381): GLib-GObject-CRITICAL **: file gobject.c: line 1307 (g_object_unref): assertion `G_IS_OBJECT (object)' failed (pan:2381): GLib-GObject-CRITICAL **: file gobject.c: line 1307 (g_object_unref): assertion `G_IS_OBJECT (object)' failed ** (pan:2381): CRITICAL **: file pango-context.c: line 509 (fallback_engine_shape): assertion `font != NULL' failed ** ERROR **: file shape.c: line 74 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting... Aborted [end of output] Any ideas?
you have fonts available (fc-list) ?
fc-cache had to be run and fixed the problem.
After emerging xft-2.0-r1 / pango-1.1.3 on 7/12, I can't seem to compile anything related to Xft anymore. This applies to avifile and freesci, which I remember right now: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src/include -I/usr/X11R6/include -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -I/usr/include/SDL -D_REENTRANT -c `test -f ggi_driver.c || echo './'`ggi_driver.c In file included from xlib_driver.c:46: /usr/X11R6/include/X11/Xft/Xft.h:52: parse error before "_XftFTlibrary" /usr/X11R6/include/X11/Xft/Xft.h:52: warning: data definition has no type or storage class /usr/X11R6/include/X11/Xft/Xft.h:86: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:86: warning: no semicolon at end of struct or union /usr/X11R6/include/X11/Xft/Xft.h:89: parse error before '}' token /usr/X11R6/include/X11/Xft/Xft.h:89: warning: data definition has no type or storage class /usr/X11R6/include/X11/Xft/Xft.h:93: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:93: warning: no semicolon at end of struct or union /usr/X11R6/include/X11/Xft/Xft.h:96: parse error before '}' token /usr/X11R6/include/X11/Xft/Xft.h:96: warning: data definition has no type or storage class /usr/X11R6/include/X11/Xft/Xft.h:190: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:256: parse error before "XftGlyphSpec" /usr/X11R6/include/X11/Xft/Xft.h:262: parse error before "XftGlyphFontSpec" /usr/X11R6/include/X11/Xft/Xft.h:295: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:343: parse error before "XftLockFace" /usr/X11R6/include/X11/Xft/Xft.h:343: warning: data definition has no type or storage class /usr/X11R6/include/X11/Xft/Xft.h:380: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:386: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:395: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:405: parse error before "XftCharIndex" /usr/X11R6/include/X11/Xft/Xft.h:407: warning: data definition has no type or storage class /usr/X11R6/include/X11/Xft/Xft.h:448: parse error before "FT_UInt" /usr/X11R6/include/X11/Xft/Xft.h:459: parse error before "XftGlyphSpec" /usr/X11R6/include/X11/Xft/Xft.h:480: parse error before "XftGlyphFontSpec" make[4]: *** [xlib_driver.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/var/tmp/portage/freesci-0.3.3/work/freesci-0.3.3/src/gfx/drivers' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/freesci-0.3.3/work/freesci-0.3.3/src/gfx' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/freesci-0.3.3/work/freesci-0.3.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/freesci-0.3.3/work/freesci-0.3.3' make: *** [all] Error 2 !!! ERROR: app-emulation/freesci-0.3.3 failed. !!! Function src_compile, Line 23, Exitcode 2 !!! (no error message)
Anything is a bit broad (your pango compiles with it). but i think these should be easy to fix. If you find anthing more, let me know.
I might have done something wrong, but after I set the "x86" keyword, many emerges died on their Xft dependency bacause the linker doesn't include the Xrender library. The emerge would fail on an unresolved variable in Xft. I fixed it by modifying xft emerge so that the Xft library is created with a rpath linker directive to Xrender. This fixed the other failures.
freesci breaks on alsa anyway, needs a good look at (i can't test it like this).
I encountered a weird bug when emerging pango 1.2.0: I had to add these lines to pango/pangoft2.c in order to get it to stop giving me undeclared variable errors. The funny thing was, the declarations are from /usr/include/fontconfig/fontconfig.h, which was included by pangoft2.h, which this file included. I added the below #include line, too, but it wasn't sufficient to solve the problem. Any ideas as to what might cause this problem? > // Attempt to fix weird precompiler omission. Mark McKenna > // Below defines imported straight from /usr/include/fontconfig/... > #include <fontconfig/fontconfig.h> > #define FC_HINT_STYLE "hintstyle" /* Int */ > #define FC_HINT_NONE 0 > #define FC_HINT_SLIGHT 1 > #define FC_HINT_MEDIUM 2 > #define FC_HINT_FULL 3 > > // End attempt.
This has come up before and this is not really the right bugreport to put it in, but see bug #13495 that most likely will give a good reason to why you have a problem and how to solve it. On this bug, i think it can be closed ? Xft2 is in by now.
xft2 is in portage, all is fine by me. i'll close this bug.
