200-r3 ran fine, but 204 won't start under stable xfce (4.2). it just loads the cpu and no window appears. Reproducible: Always Steps to Reproduce: 1. 2. 3. $ emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.pair.com http://gentoo.ccccom.com" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X aalib alsa avi cdr cups divx4linux dvd dvdr encode fbcon gif gpm gtk gtk2 jpeg mad mikmod mmx mpeg ncurses nls nptl oggvorbis opengl oss perl png python readline sdl slang spell sse ssl tcpd truetype unicode xml2 xprint xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS $ cat .Xdefaults | grep XTerm XTerm*termName: xterm-color XTerm*background: Black #XTerm*foreground: WhiteSmoke XTerm*foreground: #17C485 XTerm*color0: Black XTerm*color1: OrangeRed1 XTerm*color2: OliveDrab3 XTerm*color3: yellow3 XTerm*color4: blue3 XTerm*color5: magenta3 XTerm*color6: cyan3 XTerm*color7: gray90 XTerm*color8: gray50 XTerm*color9: red XTerm*color10: green XTerm*color11: yellow2 XTerm*color12: lightslateblue XTerm*color13: magenta XTerm*color14: cyan XTerm*color15: white XTerm*colorBD: lightyellow XTerm*colorUL: lightblue XTerm*cursorColor:grey XTerm*dynamicColors:on XTerm*highlightSelection: true XTerm*eightBitInput:false XTerm*eightBitOutput:true XTerm*internalBorder:3 XTerm*modifier:alt XTerm*scrollBar:false XTerm*titleInhibit:true XTerm*visualBell:true XTerm*loginShell:true XTerm*cutNewline:false XTerm*cutToBeginningOfLine:false XTerm*utf8: 1 XTerm*renderFont: true XTerm*VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 XTerm*VT100*wideFont: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 XTerm*boldFont: -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso10646-1
Yep ! Actually, for me the problem is much more severe! Under gnome and fluxbox, at launch, xterm-204 spends 30 and more seconds querying the font server (xfs) like crazy then displays: "Warning: Missing charsets in String to FontSet conversion" Then starts but, most of the font related items in the menu are grayed out. Under Xfce42, it does the same thing but, instead of starting, it dies saying: "Broken pipe" (in addition to the above warning). In desperation (my gentoo isn't very useful without xterm) I got and compiled the latest xterm-205 directly from dickey's page and it works, however, if I compile 205 with the same flags used by Portage (see below) the problem is the same of xterm-204. WORKAROUND: Unmerge xterm and put in your /etc/portage/package.use the line: x11-terms/xterm -toolbar and re-emerge it. Problem goes away but, of course, you lose the menu. SUSPECT: Fonts used in the menu, maybe connected with a gentoo configured for UTF-8 (like mine, done according to Gentoo UTF-8 docs). I have all the Gentoo fonts packages + xfs correctly working, and I know that because all the other unicode aware applications work perfectly (including other terminal emulators). This is an Xterm-204 specific problem. And yes, before the upgrade, the previous Xterm-2** (forgot what it was!) was working just fine, but I do not recall whether it had menus or not. PORTAGE CONFIGURATION FLAGS: ./configure --prefix=/usr --host=i586-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/etc --with-x --with-utempter --disable-setuid --disable-full-tgetent --disable-imake --enable-ansi-color --enable-88-color --enable-256-color --enable-broken-osc --enable-broken-st --enable-load-vt-fonts --enable-i18n --enable-wide-chars --enable-doublechars --enable-warnings --enable-tcap-query --enable-logging --enable-dabbrev --enable-toolbar --enable-freetype --enable-luit --enable-mini-luit --with-Xaw3d --build=i586-pc-linux-gnu Of course, the culprit is that --enable-toolbar. Pls, note that 'toolbar' USE flag is enabled by the xterm-204 package itslelf (http://www.gentoo-portage.com/x11-terms/xterm/USE) so you get it even if you do not have 'toolbar' defined in your /etc/make.conf USE section (Philip's case?). For the time being, I would suggest to create a new ebuild with '-toolbar' USE flag and change the severity level to major. Regards to all, el fabre
we have several things in common here: we both run utf-8 systems and we both use the font server xfs...
I'm not seeing anything close to that on Debian. Starting uxterm, I see it taking 3-4 seconds to come up, no noticeable CPU usage. It does sound as if there's some problem with UTF-8 fonts in the Athena widget's menus. As noted, compiling in support for the toolbar makes xterm initialize some extra widgets - but since those are outside the "VT100" widget, and I don't see it in the resources, it's possible that the global "*font" is causing the font server to deliver some fonts to xterm that are exposing the problem. (The various desktops rely heavily on xrdb to set global resource values - that doesn't show up when using "appres XTerm" or just looking at .Xdefaults).
I don't see this on Debian. But it's likely that running in a given desktop environment (which loads lots of global settings with xrdb), that the font that the toolbar and popup menus are seeing is the issue. The contents of .Xdefault isn't showing what font those would use since they're outside the vt100 widget. I'd try setting the fonts for xterm to "fixed", e.g., XTerm*font: fixed
more information. i let xterm 204 continue to run a little longer using my original .Xdefaults and, after about 20 secs I got this: phil@porthos ~ $ xterm _XF86BigfontQueryFont: could not attach shm segment X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 67715 Current serial number in output stream: 67719 Now, commenting out the unicode font lines in my .Xdefaults: XTerm*VT100*font:-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 XTerm*VT100*wideFont: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 XTerm*boldFont: -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso10646-1 and replacing them with just: XTerm*font: fixed does cause xterm 204 to start immediately and normally, however the xterm cannot display many UTF-8 glyphs, whereas, before, I think it did. Reference the attached UTF-8 test file. uxterm looks fine, but there was never a problem there.
Created attachment 69095 [details] UTF-8-demo.txt not sure if attaching this as plain text will be lossy, so i am attaching it as a binary file.
That sounds consistent. Normally xterm initializes menus on the first time they are used. Before #203 the toolbar configuration would initialize all 3 menus and the toolbar on startup. Now it only initializes the toolbar (in addition to the vt100 widget). But if there is a problem with UTF-8 fonts versus the Athena widgets, it seems that even the small toolbar is a problem. The workaround is to add resource settings for the font in the toolbar.
I had more time spent on this. Sorry, but now it is clear; we are talking about 2 completely different problems. Philip's one, first. Sake of curiosity, I entered Philip's .Xdefaults (I was using the one at http://dickey.his.com/xterm/xterm.faq.html#my_xdefaults). Then, I launched Xterm (the one compiled without toolbar, the only one that actually works for me) and bingo, after around 30s, I got practically the same error of Philip (numbers differs): _XF86BigfontQueryFont: could not attach shm segment X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 67657 Current serial number in output stream: 67661 A little more playing shows that the offending line is definitely the one b4 the last one: ... XTerm*VT100*wideFont: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 ... It is enough to comment that line only, to have the problem going away (no need to add "XTerm*font: fixed" at all ). If I launch uxterm (opposed to xterm) it seems not using the .Xdefaults at all (I can tell from the colors/size) so logic suggests that no .Xdefaults -> no offending line -> no problem. I am not sure why uxterm ignores .Xdefaults or whether this is correct or not (I have bigger problems at the moment). Glyphs in the UTF-8demo are displayed correcty in both xterm or uxterm, of course, provided that the offending line in .Xdefaults is removed and that there is no toolbar compiled in (otherwise it won't even start). Back to my problem instead, for me, no matter what I launch, xterm or uxterm, or what .Xdefaults I use (even no .Xdefaults at all), or if I use XFS or define font paths directly in xorg.conf (yep, tried that one, too), if I compiled it with toolbar, I just does not start under xfce4.2.2, or hogs the CPU for 30s b4 starting in other WMs, always with the same warning message (which is differnent from Philip's one): "Warning: Missing charsets in String to FontSet conversion" However, I am totally indebted with Mr. Dickey's on the hint on the Athena widgets. It prompted me to launch little used programs (at least by me) like viewres, xedit, xcalc, xclipboard, xditview, xfontsel, xman and yep; b4 starting, they all hog the CPU for 30s and then spat the same Xterm warning: "Warning: Missing charsets in String to FontSet conversion" and eventually, I got directed to the real problem that is an Xorg/Gentoo one, not in Xterm (see bug 1325 on freedesktop.org https://bugs.freedesktop.org/show_bug.cgi?id=1325). I am out of this bug, thanks a lot. El Fabre
Yes, commenting out: XTerm*VT100*wideFont: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1 from my .Xdeafults does prevent the error and allows xterm to start normally! Thanks for working with my config and trying out some combinations. Good luck with your freedesktop bug! Phil
resolving: upstream added x11 team to cc, so they can keep track of things, if they like
