Your message dated Sat, 12 Jul 2025 23:05:48 +0200
with message-id <ahloljook7h2s...@per.namespace.at>
and subject line Re: Bug#110298: Bug #110298
has caused the Debian Bug report #110298,
regarding Eterm is slooooow to open because of font caching
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
110298: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110298
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: eterm
Version: 0.9.1-0pre2001072201
Severity: important
Hi,
I'm having this probem with Eterm... it is a fresh install so
I don't understand it...
It seems it is getting stuck on this function:
[kov]@[couve] $ Eterm --debug 5
(...)
[998933961] ../../../src/font.c | 325: load_font():
load_font(-*-times-bold-r-normal--14-*-*-*-*-*-iso8859-1, fixed, 1) called.
[998933961] ../../../src/font.c | 348: load_font(): -> Using name ==
"-*-times-bold-r-normal--14-*-*-*-*-*-iso8859-1" and fallback == "fixed"
[998933961] ../../../src/font.c | 277: font_cache_find():
font_cache_find(-*-times-bold-r-normal--14-*-*-*-*-*-iso8859-1, 1) called.
[998933961] ../../../src/font.c | 287: font_cache_find(): No matches found. =(
[998933961] ../../../src/font.c | 156: font_cache_add():
font_cache_add(-*-times-bold-r-normal--14-*-*-*-*-*-iso8859-1, 1, 0x8054568)
called.
[998933961] ../../../src/font.c | 169: font_cache_add(): -> Created new
cachefont_t struct at 0x8056458:
"-*-times-bold-r-normal--14-*-*-*-*-*-iso8859-1", 1, 0x8054568
[998933961] ../../../src/font.c | 175: font_cache_add(): -> Stored as first
font in cache. font_cache == cur_font == font == 0x8056458
[998933961] ../../../src/font.c | 176: font_cache_add(): -> font_cache->next
== cur_font->next == font->next == (nil)
it gets stuck here for a long time... then it opens the window
and gets stuck here:
[998934055] ../../../src/buttons.c | 56: draw_string(): Writing string
"Eterm" (length 5) onto drawable 0x03000095 at 8, 13
[998934055] ../../../src/buttons.c | 56: draw_string(): Writing string "Font"
(length 4) onto drawable 0x03000095 at 45, 13
[998934055] ../../../src/buttons.c | 56: draw_string(): Writing string
"Background" (length 10) onto drawable 0x03000095 at 76, 13
[998934055] ../../../src/buttons.c | 56: draw_string(): Writing string
"Terminal" (length 8) onto drawable 0x03000095 at 140, 13
[998934055] ../../../src/pixmap.c | 665: paste_simage():
paste_simage(0x806c240, image_max, 0x03000040, 0x03000095, 481, 3, 13, 11)
called.
[998934055] ../../../src/pixmap.c | 665: paste_simage():
paste_simage(0x806da88, image_max, 0x03000040, 0x03000095, 459, 3, 13, 11)
called.
[998934055] ../../../src/buttons.c | 148: bbar_init():
bbar_reset_total_height()
[998934055] ../../../src/startup.c | 299: eterm_bootstrap(): init_command()
and I don't get the prompt for lots of time again...
then it goes ok, but if I click the 'background' menu item it
gets stuck on that first message again....
[]s!
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux couve 2.4.6 #5 Ter Ago 21 14:28:15 BRT 2001 i586
Locale: LANG=pt_BR, LC_CTYPE=pt_BR
Versions of packages eterm depends on:
ii libast1 0.3-0pre2001062603 the Library of Assorted Spiffy Thi
hi libc6 2.2.3-10 GNU C Library: Shared libraries an
ii libimlib2 1.0.3-2 Powerful image loading and renderi
ii libttf2 1.4pre.20010424-1 FreeType 1, The FREE TrueType Font
ii ncurses-term 5.2.20010318-3 Additional terminal type definitio
ii xlibs 4.1.0-2 X Window System client libraries
--- End Message ---
--- Begin Message ---
On Mon, Sep 30, 2002 at 12:32:12AM -0400, Michael Jennings wrote:
> If you look at the stats generated by your "time" output, you'll see
> that Eterm's own user/system usage doesn't change much at all between
> the two runs. This should indicate that Eterm itself is not where the
> delay is occuring.
Seems like this should have been closed in 2002, then.
--- End Message ---
