On Mon, 2003-08-04 at 08:07, Daniel Veillard wrote:
On Sun, Aug 03, 2003 at 09:52:28PM -0400, Robert L Cochran wrote:
> It is 27 bytes, and I sent it to you as a separate email from my Severn
> box. I hope I sent it to you correctly. I can't figure out how to get
> Evolution 1.4 to attach a file that has a leading dot '.', and this led
> me into a very inexpert session with mutt.
I got it, will try to reproduce this today. Still I puzzled,
I don't see anything in the code which could explain why the cache
state can influence the rendering, *except* if it is a bug raised
under load condition, then rebuilding the cache generates a lot
of I/O though the rpm database, which added to the load associated to
starting the desktop might create the conditions to raise that problem.
If it's a race condition in the inter-process communication interface
between the applet and the applet container running in the toolbar then
having a lot of I/O might generate proper condition for the problem.
It would be interesting to see if you get the same problem with little
load, for example once in the session, assuming the applet didn't display
correctly, what happen if you kill the applet and restart it with
"killall rhn-applet-gui ; rhn-applet-gui &"
is the display still broken ?
I also get the broken rhn applet display. Since I have only installed
severn today I cannot say if it is intermittent or not. I have a
.rhn-applet.cache file, which has 644 permissions and is of size 243689.
Running "killall rhn-applet-gui ; rhn-applet-gui &" did fix the applet.
I don't seem to be able to get it to break again tho'; I've only tried a
couple of things; logging out/in and rebooting.
This is on a Dell Optiplex GXa 266Mhz processor / 64Mb memory.
BTW, this also happens to me on my Shrike box at home a 333Mhz/192Mb
system. There is is intermittent.
Open Systems, Operations
Common IT Services
Solutions BC, Province of BC
Phone: 250-387-5993 Fax: 250-387-5231
Solutions BC http://www.solutionsbcsharedservices.gov.bc.ca