I think it merits consideration to devise a mechanism which
closes and reopens a new error log so that _future_ errors
(i.e. errors which occur after the spamming which caused
.xsession-erros to fill in the first place) could be
captured. As it stands, Gtk+ spams this file with
'XID collision' messages until the log fills up
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550352_)
and if another component has a problem that actually
causes an error (i.e. browser crash) the user has no idea
clue as to what might have caused it.
I think it merits consideration to devise a mechanism which bugs.debian. org/cgi- bin/bugreport. cgi?bug= 550352_)
closes and reopens a new error log so that _future_ errors
(i.e. errors which occur after the spamming which caused
.xsession-erros to fill in the first place) could be
captured. As it stands, Gtk+ spams this file with
'XID collision' messages until the log fills up
(http://
and if another component has a problem that actually
causes an error (i.e. browser crash) the user has no idea
clue as to what might have caused it.