system debugging - was Re: [luv-talk] Facebook.. Privacy? What privacy?

On Wed, 10 Jul 2013, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Jason White wrote:
read ~/.xsession-errors and consider all of the messages from components one didn't even know existed. One is then faced with the practical question: against which package to submit a bug report.
Um, you make an educated guess, and if you filed it against the wrong package, it's the Debian maintainer's responsibility to reassign it.
A large portion of those error messages (probably the vast majority on most systems) will be from applications such as kmail and chromium which can be run from a terminal. To solve the problem of excess error messages you could run all such programs separately to identify their logs and then after those are identified (and hopefully fixed) the rest would be known to be due to the desktop environment. The messages which are known to be due to the desktop environment can have bugs reported against a meta-package for KDE, GNOME, or whatever desktop environment is in use and whoever maintains that will be well qualified to triage them. It's not the DD's responsibility to determine the source of a random error message. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Russell Coker wrote:
On Wed, 10 Jul 2013, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Jason White wrote:
read ~/.xsession-errors and consider all of the messages from components one didn't even know existed. One is then faced with the practical question: against which package to submit a bug report.
Um, you make an educated guess, and if you filed it against the wrong package, it's the Debian maintainer's responsibility to reassign it.
A large portion of those error messages (probably the vast majority on most systems) will be from applications such as kmail and chromium which can be run from a terminal. To solve the problem of excess error messages you could run all such programs separately to identify their logs and then after those are identified (and hopefully fixed) the rest would be known to be due to the desktop environment. The messages which are known to be due to the desktop environment can have bugs reported against a meta-package for KDE, GNOME, or whatever desktop environment is in use and whoever maintains that will be well qualified to triage them.
Oh, sorry, that's what I meant by "educated guess".
It's not the DD's responsibility to determine the source of a random error message.
I was thinking more like when I was midori's maintainer, and I would handball not-specific-to-midori issues on to libwebkitgtk. When you have an error line like (midori:16413): GLib-GObject-WARNING **: g_object_set_valist: object class `SoupSessionAsync' has no property named `ssl-use-system-ca-file' and you were running midori as one of the things you do, it'd be reasonable to start by filing a bug against it, even though that's probably actually a problem in libsoup or something. Something like this is a bit harder, but again, it shouldn't be hard to work out what WM you're running. 7569 Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0. This shouldn't happen! 7634 Window manager warning: CurrentTime used to choose focus window; focus window may not be correct. The ones I see most often look like this, i.e. something in the glib/gtk stack having a hissy fit. That's what I was talking about WRT slack GUI devs. 2162 (rhythmbox:1310): RhythmDB-CRITICAL **: rhythmdb_entry_get_string: assertion `entry != NULL' failed 2162 (rhythmbox:1310): RhythmDB-CRITICAL **: rhythmdb_entry_get_ulong: assertion `entry != NULL' failed 3758 (rhythmbox:2355): Gtk-CRITICAL **: gtk_tree_row_reference_get_path: assertion `reference != NULL' failed PS: those numbers on the left are from uniq -c. So... yeah. Lame.
participants (2)
-
Russell Coker
-
Trent W. Buck