The screen doesn't seem to be cleared when it is rendering the fonts. Also, I get the following warning: XFTE Warning: unable to open font "*-fixed-bold-*-15*,*-fixed-bold-*-16*": Missing count: 17 ISO8859-1 ISO8859-1 ISO8859-2 ISO8859-3 ISO8859-4 ISO8859-5 KOI8-R ISO8859-7 ISO8859-9 ISO8859-13 ISO8859-14 ISO8859-15 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 ISO10646-1
Maybe should be treecleaned in favor of efte (that looks its successor)
I strongly urge you NOT to remove this. At least there is a version considered stable for this package (unlike efte which is a fork rather than a successor, undoubtedly created due to lack of activity of the original). And having it does not break other packages (at least AFAIK). What version does the report refer to? What is meant by ``screen'', does this refer to the console version or the X version? Could it be that the warning mentioned (and maybe even the observed rendering problem) is only due to bad configuration (or possibly a missed dependency in the ebuild) as the string "*-fixed-bold-*-15*,*-fixed-bold-*-16*" occurs in one of the configuration source files (/usr/share/fte/main.fte which has to be compiled using cfte to the actual configuration file to be stored in /etc or the user's home)? Could the rendering problem be related to using Unicode somewhere? I cannot confirm either for the stable ebuild (20051115-r3) on my mostly Unicode-free, mostly stable amd64 system, although there certainly are some minor glitches (xfte from remote via "ssh -X" segfaults; X clipboard cannot be copied into editor using Shift-Ins, only using middle click, probably some misconfiguration of my own; note that I have no intention of hijacking this bug!).
It's referring to app-misc/screen What is wrong with efte? (looks a bit more maintained than this one)
(CCing you to be sure you ready the replies :))
Slightly confused. Emerging fte yields two executables, vfte and xfte (plus script fte to auto-select one of these). With use flag slang a third named sfte can be created (haven't tried that yet). Neither of the first two is even supposed to run in a terminal as provided by app-misc/screen, only on virtual consoles or within X. So once again, is this report about vfte or xfte? And is it about version 20051115-r3 (considered stable, on my system not exposing the behaviour this bug is about, only others I mentioned above) or 20110708 (not considered stable)? I don't claim anything is wrong with efte, except there is no stable ebuild. I have only now made an effort to install it (by accept_keywording it) and a first test shows it seems to work, but I have yet to see if it is compatible with my fte configurations (and where configuration files go as efte does not use the binary format of fte) and does not have features that make it unbearably hard to switch. I would once again like to emphasize that I see no reason for removal of fte as its stable version works reasonably well and its existence does not cause problems for any other software I know of. It is quite ridiculous if all those interested in using some ``old'' software have to keep ebuilds in local overlays (and finding those first if they only came across that software after it had been removed from portage). Not having been changed upstream in quite a while is not necessarily a problem (though undoubtedly there are still bugs in fte to be fixed), actually there is software that would rather be left alone (with some bugs remaining) than maintained the annoying way it is.
(In reply to Ulrich Fieseler from comment #5) > So once again, is this report about vfte or xfte? I don't remember, but apparently it's part of the warning message; XFTE. :) > And is it about version 20051115-r3 (considered stable, on my system > not exposing the behaviour this bug is about, only others I mentioned above) > or 20110708 (not considered stable)? The version bump, unstable 20110708. > I don't claim anything is wrong with efte, except there is no stable ebuild. I suppose this will be stabilized by the time fte has been treecleaned; maybe, if thirty days without bugs have already passed for that we could file a stabilization bug for this. > I would once again like to emphasize that I see no reason for removal of fte as its stable version works reasonably well and its existence does not cause problems for any other software I know of. Not my take, I'll let Pacho reconsider; maybe we can salvage it by removing xfte from newer versions. A package being broken is a reason for removal; but well, given that the old version works and the new version can be salvaged I agree it's not entirely broken.
Will try to stabilize efte. The additional problem is that both packages are orphan :(
(In reply to Pacho Ramos from comment #7) > Will try to stabilize efte. The additional problem is that both packages are > orphan :( efte stabilized
OK, will be kept. I have masked the bogus version only
