Re: Debug output etc, cluttering the terminal
Christoph Egger christ...@debian.org writes: Neil Williams codeh...@debian.org writes: On Sun, 15 Aug 2010 02:23:32 + brian m. carlson sand...@crustytoothpaste.net wrote: On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote: Redirect stderr when opening the file or work out why okular was selected in the first place. Moaning in the general direction of all developers everywhere isn't helpful. Do something to identify the problem, not the symptom. BTW evince produces debug messages when loading some PDF files too, so this isn't just an okular thing. Yeah but I've never seen scramblings on my terminals long after evince has quit as these kde stuff does with some backgrounded helpers still running (and not ever terminating) and continuously writing to some terminal that happens to have started the first KDE app or so. Full ACK. Those are DEBUG messages. They are not relevant or usefull for 99.9% of all users and the only thing they do is annoy. Some of them have been around for years so clearly they are not something anyone is working on. And no, I'm not talking about the specific messages posted before. This is a general problem of KDE and somewhat less gtk apps. Neil: I'm sorry but your proposed solution is also stupid. If the user redirects 2/dev/null then actual errors will also not be shown and then users will come complaining why something doesn't work while the error message would have told them. There is a reason behind the unix philosophy for programs to shut up when there is no error. The reason is so that when there is an error it shows and will be read. Spewing tons of debug messages per default just makes people not read the output and hides any real errors. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj84e1nv@frosties.localdomain
Re: Debug output etc, cluttering the terminal
Hello, Lars Wirzenius l...@liw.fi writes: On su, 2010-08-15 at 14:19 +0200, Tollef Fog Heen wrote: I would guess they still fill up the .xsession-errors file, though? At least for me, that file is mostly useless due to: « ...Too much output, ignoring rest... » as the last line. It's pretty clear to me that both .xsession-errors and the stderr of GUI apps are lousy ways of logging debugging messages. Something similar to syslog for a per-user/per-session would be a very useful thing to have, in my opinion. after I had thought about the topic a little bit more I'm not sure if one would like to go that way. If it becomes common pratice that every application logs more or less random stuff -via log file, a syslog equivalent or other means- per default, we might waste tons of io ops and cpu cycles with often can be used in a better way. It's better to switch on logging in a more finegrained way. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrro473i@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
Ben Hutchings b...@decadent.org.uk writes: On Sun, 2010-08-15 at 17:02 +0100, Neil Williams wrote: [...] Most of the stuff in ~/.xsession-errors which has been mentioned here, are exactly these kind of assertion failure errors: (gnome-power-manager:2346): GLib-GObject-WARNING **: value -nan of type `gdouble' is invalid or out of range for property `percentage' of type `gdouble' (polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed Those are BUGS. It might not cause symptoms now but it is still relevant to how other bugs in that application are triaged. The upstream code needs to be fixed to check these values before passing them to the relevant function. I mostly agree with this. These are warnings, not simply debug information, and the application author should fix them. However, each specific warning should only be printed once, since that's enough to indicate the existence of the bug. The problem is that those bugs are not going to be fixed, not in a stable release and often not for years in the developement release. At least I've seen those GLib-CRITICAL warnings for years now in some apps. The app works so I, as user, simply don't care. Some developers also seem to not care and software is released with those errors. The checks in glib seem good enough to handle such cases sanely so maybe the glib could be shut up about them for stable releases (or where users just don't care). Maybe something like setting GLIB_BE_SILENT or so if recompiling the lib silent is out of the question. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eidwe0y1@frosties.localdomain
Re: Debug output etc, cluttering the terminal
On 18/08/10 11:15, Goswin von Brederlow wrote: The checks in glib seem good enough to handle such cases sanely so maybe the glib could be shut up about them for stable releases (or where users just don't care). Maybe something like setting GLIB_BE_SILENT or so if recompiling the lib silent is out of the question. No. As you said those are not stupid debug output, but real problems, and should be fixed. We're not going to hide them. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6bc622.20...@debian.org
Re: Debug output etc, cluttering the terminal
On Wed, 2010-08-18 at 13:38 +0200, Emilio Pozuelo Monfort wrote: those are not stupid debug output, but real problems, and should be fixed. We're not going to hide them. So have gtk_assert (or whatever it is) actually call abort() and make the offending applications crash, so the offending developers *have* to fix them. But until you do that, give me a way to Shut Them Off, and without silencing *real* error messages, either. You can't have it both ways, they are either dire imminent bugs, or they are noise. As a user, from where I sit, they are noise. On the logs issue, have you ever had .xsession-errors fill your /home disk? I have. It was a very painful experience. I turns out that Evolution will utterly trash your email storage when it runs out of disk space. Why are you forcing me to restore from backup because my disk filled up with (something indistinguishable from) noise from GUI applications? A simple silence unless asked for debug aka the unix golden rule official Policy seems like (a) a great idea, (b) simple to explain, and (c) simple to implement. -- Peter Miller pmil...@opensource.org.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282136010.19303.43.ca...@hawk
Re: Debug output etc, cluttering the terminal
Emilio Pozuelo Monfort po...@debian.org writes: On 18/08/10 11:15, Goswin von Brederlow wrote: The checks in glib seem good enough to handle such cases sanely so maybe the glib could be shut up about them for stable releases (or where users just don't care). Maybe something like setting GLIB_BE_SILENT or so if recompiling the lib silent is out of the question. No. As you said those are not stupid debug output, but real problems, and should be fixed. We're not going to hide them. Emilio s/problems/misuse of the lib/ If they are really critical problems then exit(1). As long as they do not affect the functionality of the app they aparently will just keep being ignored. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp90cbkt@frosties.localdomain
Re: Debug output etc, cluttering the terminal
On 18/08/10 14:53, Peter Miller wrote: So have gtk_assert (or whatever it is) actually call abort() and make the offending applications crash, so the offending developers *have* to fix them. But until you do that, give me a way to Shut Them Off, and without silencing *real* error messages, either. Ask upstream to make that change. Hint: they won't do it. You can't have it both ways, they are either dire imminent bugs, or they are noise. As a user, from where I sit, they are noise. No. They are bugs. And they may, or may not, have visual effects to you. If they don't, good for you, but that doesn't mean they are less buggy. If you're calling foo_do_bar(), which says you shouldn't call it with a NULL argument, and you do so, then it's a bug, no matter if your application crashes or not. I won't hide them. kthxbye. A simple silence unless asked for debug aka the unix golden rule official Policy seems like (a) a great idea, (b) simple to explain, and (c) simple to implement. Those are not debug messages. g_criticals and g_warnings are bugs. I'm perfectly fine with hiding normal debug output, but that's not what we're discussing wrt GLib. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6bd94e.2090...@debian.org
Re: Debug output etc, cluttering the terminal
Le mercredi 18 août 2010 à 22:53 +1000, Peter Miller a écrit : On Wed, 2010-08-18 at 13:38 +0200, Emilio Pozuelo Monfort wrote: those are not stupid debug output, but real problems, and should be fixed. We're not going to hide them. So have gtk_assert (or whatever it is) actually call abort() and make the offending applications crash, so the offending developers *have* to fix them. Note that this is what upstream does in development versions of gnome-session. However we have to disable this behavior in Debian because way too many things are crashing in this case. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282138981.5689.47.ca...@meh
Re: Debug output etc, cluttering the terminal
In data mercoledì, 18. di agosto 2010 11:00:04, Goswin von Brederlow ha scritto: Those are DEBUG messages. They are not relevant or usefull for 99.9% of all users and the only thing they do is annoy. Some of them have been around for years so clearly they are not something anyone is working on. And no, I'm not talking about the specific messages posted before. This is a general problem of KDE and somewhat less gtk apps. Enough KDE bashing, discussion continues here as proposed by me before: #593469 Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008181605.13869.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
Good morning (at least in my time zone ;)), Christian PERRIER bubu...@debian.org writes: Quoting Michael Welle (mwe012...@gmx.net): Hello, what is the reason that many applications clutter the terminal with output that is obvisously debug output? Lets take digikam as an example: (I read most other comments in this thread before writing this) tough guy ;). I have to concur to everything that was brought by poeple who *don't* want this debug gibberish to appear either in their terminal or in their ~/.xsession-errors: Here's mine, started yesterday morningand I barely did nothing since then as I'm more travelling around Vermont that playing with my KDE apps: bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite ls -l ~/.xsession-errors -rw--- 1 bubulle bubulle 2511641 15 août 18:28 /home/bubulle/.xsession-errors [...] And, finally, as someone who often leaves his own desktop environment opened for months in the same session, at work, I deeply concur to Holger's comment about wasting space in home directories (mine being constrained to a few gigabytes). Try to delete it ;-). Thankfully, there, I'm not using KDE Neither do I. and not even Debian, indeed..:-) And there goes another hero down the drain ;). Sorry for only kidding in this posting. I'd just returned from a wasted morning with my government and need to recover. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrrr57b3@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
]] Lars Wirzenius | On su, 2010-08-15 at 14:19 +0200, Tollef Fog Heen wrote: | I would guess they still fill up the .xsession-errors file, though? At | least for me, that file is mostly useless due to: | | « ...Too much output, ignoring rest... » | | as the last line. | | It's pretty clear to me that both .xsession-errors and the stderr of GUI | apps are lousy ways of logging debugging messages. Something similar to | syslog for a per-user/per-session would be a very useful thing to have, | in my opinion. FWIW, systemd (which can work both as an init replacement as well as a session manager) handles this by forwarding those to syslog (by default), which at least partially works around the problem of disks filling up. Priority is then set by the same convention as printk, that is, you do 4 Foo to log «Foo» at log level 4, aka warning. It'd be neat to have a way to post-mortem get at the logged output of an application and have that appear if you submit a bug report or similar. (Think bug-buddy in gnome or apport in Ubuntu.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hjqalv6@qurzaw.linpro.no
Re: Debug output etc, cluttering the terminal
On Sun, 2010-08-15 at 17:02 +0100, Neil Williams wrote: [...] Most of the stuff in ~/.xsession-errors which has been mentioned here, are exactly these kind of assertion failure errors: (gnome-power-manager:2346): GLib-GObject-WARNING **: value -nan of type `gdouble' is invalid or out of range for property `percentage' of type `gdouble' (polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed Those are BUGS. It might not cause symptoms now but it is still relevant to how other bugs in that application are triaged. The upstream code needs to be fixed to check these values before passing them to the relevant function. I mostly agree with this. These are warnings, not simply debug information, and the application author should fix them. However, each specific warning should only be printed once, since that's enough to indicate the existence of the bug. [...] Not a default across all packages and all debug output but there are situations where *some* debug output needs to be part of the default output of the application in order to actually capture the data necessary to fix the bugs. Some applications, even some mature applications, need to be able to output debug information to the controlling terminal as a matter of course in order to fix unreproducible and/or intermittent bugs. [...] This is nonsense. What the application authors need in this case is logging, and writing to stderr is not logging (modulo use of e.g. systemd to capture stderr). They need to open an application- and user-specific log file and write to that instead. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Debug output etc, cluttering the terminal
On 16/08/10 02:01, Russ Allbery wrote: gregor herrmann gre...@debian.org writes: Among the contents are e.g. ~20.000 lines saying: (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead I tracked this down at one point and decided that this was the fault of Adobe's Flash player rather than anything the Mozilla folks had any control over. I now just redirect the output of Iceweasel to /dev/null where I have to run the Flash player. That may actually be X's fault, see http://bugs.freedesktop.org/show_bug.cgi?id=21583 Regards, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c69b107.8090...@debian.org
Re: Debug output etc, cluttering the terminal
Hello, Neil Williams codeh...@debian.org writes: On Sat, 14 Aug 2010 19:59:50 +0200 Michael Welle mwe012...@gmx.net wrote: what is the reason that many applications clutter the terminal with output that is obvisously debug output? It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. It's not clutter. If you don't want to see it, run the command and redirect stderr. I agree with your opinion about the usefulness of debug output. And -as one might guess- I disagree with your opinion about how debug output should be handled. Do Debian distribute programmes to its user base, that are still in debug phase? Aren't debug switches sold anymore? One can forget to switch debug output off. That's no biggy, mistakes happen. But have it switched on per default is strange and embarassing. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5i08j2u@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
Hello, Paul Wise p...@debian.org writes: [...] debug output should certainly not be output by default in released versions without a command-line or configuration option turning it on. l for one don't want ls doing something like this: ls: starting up ls: checking for bad filesystems ls: searching for files in /home/foo/some/path foo bar/ baz/ ls: 1 file found ls: 2 directories found thank you for this brilliant example, but please add to the output how much time the steeps consumed ;). My feeling is that many developers don't care because most users might not be aware of what is happening. They may start the application by mouse clicking and so they don't know about stdout and stderr. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxso8irv@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
Hello, brian m. carlson sand...@crustytoothpaste.net writes: On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. The Unix tradition is for programs to run silently unless there's a problem. Taking 64ms to complete some operation is not, in general, a problem. Yepp, citing the rule of silence from TAOUP: '...when a program has nothing interesting or surprising to say, it should shut up.' Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbiw8imd@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 08:51:21 +0200 Michael Welle mwe012...@gmx.net wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. It's not clutter. If you don't want to see it, run the command and redirect stderr. I agree with your opinion about the usefulness of debug output. And -as one might guess- I disagree with your opinion about how debug output should be handled. Do Debian distribute programmes to its user base, that are still in debug phase? Yes and will continue to do so. All software is susceptible to bugs and all software needs to have debug support. Mature software needs more debug support than pre-alpha software because bugs in mature packages tend to be corner-cases and obscure use cases, i.e. harder to identify. Every software package is constantly being debugged. Even the kernel produces debug output in the case of particular errors - including messages which appear on every terminal on the machine and sound a fixed volume beep. Depending on the circumstances, this can be something as simple as not taking a USB networking interface down before removing the USB cable. Depends which module is in use. Aren't debug switches sold anymore? sold ??? Programs support --debug or --verbose options on the command line for debugging of errors which are not often seen. One can forget to switch debug output off. That's no biggy, mistakes happen. But have it switched on per default is strange and embarassing. Nothing of the sort. Programs that do not provide debug output should make log files containing debug output. When bugs are hard to reproduce, having debug output on by default is extremely important for many mature packages. This isn't about forgetting to switch debugging off, this is about helping users and developers actually fix bugs. Difficult bugs can appear as a subtle change in the debug output, even if the program continues to operate normally (or close to normally), only to fail later. e.g. a package can develop a bug which corrupts the data storage format used by the package, the debug output includes a line that a variable of type foo has been written out as type bar but is still of type foo inside the program. Close the program, try to reload the exported data, containing the type bar, and the program fails. The only way to debug this is to have the debug output available by default and then include the details of how that data was obtained into the bug report. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpy7zWCm7M5V.pgp Description: PGP signature
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 12:44:59 +0800 Paul Wise p...@debian.org wrote: On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams codeh...@debian.org wrote: It's not clutter. If you don't want to see it, run the command and redirect stderr. debug output should certainly not be output by default in released versions without a command-line or configuration option turning it on. On the contrary, I've outlined some situations where on-by-default is the best way to identify the bug itself. l for one don't want ls doing something like this: ls: starting up ls: checking for bad filesystems ls: searching for files in /home/foo/some/path foo bar/ baz/ ls: 1 file found ls: 2 directories found But if that software starts misbehaving in circumstances which are not easily identified, then debug output can be essential. If the above is actually: stderr ls: starting up stderr ls: checking for bad filesystems stderr ls: searching for files in /home/foo/some/path stdout foo bar/ baz/ stderr ls: 1 file found stderr ls: 2 directories found then this could be useful. Done correctly, (and the above wouldn't be nice from something like 'ls' but for other command line programs it could be necessary), debug-on-by-default is very important to actually debugging hard-to-reproduce bugs. Even coreutils has bugs. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp29K5Ldh5Yn.pgp Description: PGP signature
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 08:57:56 +0200 Michael Welle mwe012...@gmx.net wrote: Paul Wise p...@debian.org writes: [...] debug output should certainly not be output by default in released versions without a command-line or configuration option turning it on. l for one don't want ls doing something like this: ls: starting up ls: checking for bad filesystems ls: searching for files in /home/foo/some/path foo bar/ baz/ ls: 1 file found ls: 2 directories found thank you for this brilliant example, but please add to the output how much time the steeps consumed ;). Debug output, to be useful, must take as little time as possible. This is particularly important when considering bugs in programs using threads and thread-locking or trying (possibly wrongly) to use file-locking. My feeling is that many developers don't care because most users might not be aware of what is happening. That is a very cavalier attitude to how developers manage their software. If you have any basis for that accusation I suggest you be open and name names. They may start the application by mouse clicking and so they don't know about stdout and stderr. Users may but developers will be looking for that debug output and starting the program from the command line explicitly to be able to collect it. (Filing a bug will usually result in the user being asked to start the program from the command line too.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpZdWCvZApnK.pgp Description: PGP signature
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 02:23:32 + brian m. carlson sand...@crustytoothpaste.net wrote: On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. The Unix tradition is for programs to run silently unless there's a problem. Just because you don't see the bug on your system does not mean that the bug does not occur on slightly different systems. I have no problem with programs taking an environment variable or a command line option in order to produce debugging output, but it shouldn't be the default. Sometimes that is necessary. Perhaps it is worth considering that developers do actually care and do such things for very good reasons and that maybe you just haven't realised why this happens. It's not clutter. If you don't want to see it, run the command and redirect stderr. It is clutter. In my case, I opened a PDF in mutt. mutt used okular instead of evince (why, I'm not sure) and therefore the terminal in which I run my mutt session now has KDE daemons screaming at me when I update my system. This is not desirable. Redirect stderr when opening the file or work out why okular was selected in the first place. Moaning in the general direction of all developers everywhere isn't helpful. Do something to identify the problem, not the symptom. BTW evince produces debug messages when loading some PDF files too, so this isn't just an okular thing. If you want the debug output to go away, help the developers fix the bugs which are either causing the output or causing the developers to need the output. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpFNNUzn7gRF.pgp Description: PGP signature
Re: Debug output etc, cluttering the terminal
* Neil Williams codeh...@debian.org [100815 10:55]: When bugs are hard to reproduce, having debug output on by default is extremely important for many mature packages. Which does not change the fact that a graphical program which outputs stuff to the terminal is very annoying and looks very immature. But I guess opinions differ. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100815092606.ga17...@pcpool00.mathematik.uni-freiburg.de
Re: Debug output etc, cluttering the terminal
Am Samstag, 14. August 2010, 19:59:50 schrieb Michael Welle: Hello, what is the reason that many applications clutter the terminal with output that is obvisously debug output? Lets take digikam as an example: In the specific case of Digikam and other KDE applications, you can run kdebugdialog to control the debugging messages. In particular, there is a convenient switch to turn them off completely. There are only two catches: - The netlib_connectsock() messages probably come from a dependency library, they don't adhere to kdebug policies. - In some apps like Gwenview, some debug messages about kdeui still pass the filter. If you experience the same issue, I suggest you file a bug report against kdebugdialog. When KDE applications are run in a KDE environment, the debug output is normally not an issue because even terminal-using people prefer KRunner's autocompletion over bash's and hence don't see the debug messages. However, it is certainly an upstream goal to make KDE applications play nice in other environments both visually and behaviourally. I see your point in bringing this up on this list to end up with distribution- wide guidelines, but for pragmatic reasons I think you're better off contacting the application or framework maintainers directly. KDE has one debugging system, Mozilla has another one, the Linux kernel has yet another one for the primary terminal, Java apps have their own local logging policies and so on. It would be a huge task trying to unify the policies. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008151129.00477.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
Hi, On Sonntag, 15. August 2010, brian m. carlson wrote: The Unix tradition is for programs to run silently unless there's a problem. [...] I have no problem with programs taking an environment variable or a command line option in order to produce debugging output, but it shouldn't be the default. Amen. When you run these programs outside of a terminal, the output goes to .xsession-errors. Logging a lot of useless debugging information makes finding actual problems in .xsession-errors a lot less likely. That, and it also fills up the homedirectory (and iceweasel+flash does this rather quickly). In environments where home is limited to something low as one or two GB (which is a reallife example as there were a lot of of homedirectories and they should be backuped) this leads to a denial of service, home is full and the user cant log in. IIRC we've used rm'ing .xsession-errors on login as a workaround. Which is as useful for debugging as linking it to /dev/null would be. So I'm all for a policy demanding silent output as default. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Debug output etc, cluttering the terminal
On Sun, Aug 15, 2010 at 10:02:15AM +0100, Neil Williams wrote: On Sun, 15 Aug 2010 12:44:59 +0800 Paul Wise p...@debian.org wrote: On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams codeh...@debian.org wrote: It's not clutter. If you don't want to see it, run the command and redirect stderr. debug output should certainly not be output by default in released versions without a command-line or configuration option turning it on. On the contrary, I've outlined some situations where on-by-default is the best way to identify the bug itself. If you're not specifically debugging, it's useless noise that masks more important stuff. Just add a --debug option or a DEBUG environment variable and you then have a well-behaved program rather than one which spews irrelevant crap all over your work. This is a beef I have with all KDE-based programs, as well a a large number of GTK+-based programs. These messages add zero value, and should not be enabled in a production release--their developers should have noticed and fixed them prior to release. In most cases they aren't even debugging output--they are pointless chatter that noone except the developers would care about. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Debug output etc, cluttering the terminal
Hello, Neil Williams codeh...@debian.org writes: On Sun, 15 Aug 2010 08:51:21 +0200 Michael Welle mwe012...@gmx.net wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. It's not clutter. If you don't want to see it, run the command and redirect stderr. I agree with your opinion about the usefulness of debug output. And -as one might guess- I disagree with your opinion about how debug output should be handled. Do Debian distribute programmes to its user base, that are still in debug phase? Yes and will continue to do so. All software is susceptible to bugs and all software needs to have debug support. Mature software needs more debug support than pre-alpha software because bugs in mature packages tend to be corner-cases and obscure use cases, i.e. harder to identify. Every software package is constantly being debugged. Even the kernel produces debug output in the case of particular errors - including ^ I haven't seen that the kernel is constantly filling my terminals or the log files with that kind of messages that I have quoted in my first posting. If an application traps into an error condition and then dumps its state I'm fine with that. messages which appear on every terminal on the machine and sound a fixed volume beep. Depending on the circumstances, this can be something as simple as not taking a USB networking interface down before removing the USB cable. Depends which module is in use. Aren't debug switches sold anymore? sold ??? Programs support --debug or --verbose options on the command line for debugging of errors which are not often seen. I have the feeling (again, no numbers here) that the number of cases were such output is grabbed, attached to a proper bug report and then results in a solution of the bug is virtualy zero. Why? Well, one starts the application, the application crashes. One wonders, starting the application again to see what happens. Now the application might work or it had eaten the data base. In both cases it is unlikely that you can find the relevant output in your terminal, if it is still open. One can forget to switch debug output off. That's no biggy, mistakes happen. But have it switched on per default is strange and embarassing. Nothing of the sort. Programs that do not provide debug output should make log files containing debug output. That is the point. I work at an application that can produce gigbytes of logs per day. From the logs you can reconstruct everything the system had done, even the data that flowed between the server and its clients. But it uses files for logging and a sane default log level. Potential customers would kick my ass if the system would behave different ;). When bugs are hard to reproduce, having debug output on by default is extremely important for many mature packages. Why don't clutter Emacs, gv, X, sed, perl, openoffice (I don't know for sure) etc. pp. the terminals with such debug messages? This isn't about forgetting to switch debugging off, this is about helping users and developers actually fix bugs. No. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd7c6um9@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
Neil Williams codeh...@debian.org writes: On Sun, 15 Aug 2010 02:23:32 + brian m. carlson sand...@crustytoothpaste.net wrote: On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote: Redirect stderr when opening the file or work out why okular was selected in the first place. Moaning in the general direction of all developers everywhere isn't helpful. Do something to identify the problem, not the symptom. BTW evince produces debug messages when loading some PDF files too, so this isn't just an okular thing. Yeah but I've never seen scramblings on my terminals long after evince has quit as these kde stuff does with some backgrounded helpers still running (and not ever terminating) and continuously writing to some terminal that happens to have started the first KDE app or so. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tymw6x4o@chillida.ipv6.sieglitzhof.net
Re: Debug output etc, cluttering the terminal
Hello, Neil Williams codeh...@debian.org writes: On Sun, 15 Aug 2010 08:57:56 +0200 Michael Welle mwe012...@gmx.net wrote: [...] My feeling is that many developers ^^ don't care because most users might not be aware of what is happening. That is a very cavalier attitude to how developers manage their software. If you have any basis for that accusation I suggest you be open and name names. I thought that the used phrase implied that I can't come up with exact numbers. But you are right, the above statement is a bit broad. Let's say that some developers don't seem care. They may start the application by mouse clicking and so they don't know about stdout and stderr. Users may but developers will be looking for that debug output and starting the program from the command line explicitly to be able to collect it. (Filing a bug will usually result in the user being asked to start the program from the command line too.) If developers want to do so, they should use the debug switch. If users find a possible bug or are just interested into the output they can use this switch, too. If the developer has the feeling that it could be helpful to log every cruft she should use some logging facility. One, that can be switched off ;). Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5i06u7u@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
Hello, Josef Spillner 2...@kuarepoti-dju.net writes: Am Samstag, 14. August 2010, 19:59:50 schrieb Michael Welle: Hello, what is the reason that many applications clutter the terminal with output that is obvisously debug output? Lets take digikam as an example: In the specific case of Digikam and other KDE applications, you can run kdebugdialog to control the debugging messages. In particular, there is a convenient switch to turn them off completely. as said earlier in this thread, switching debug msg off with this dialog changed (nearly?) nothing for me, except that the changes are reflected in ~/.kde/share/config/kdebugrc. [...] When KDE applications are run in a KDE environment, the debug output is normally not an issue because even terminal-using people prefer KRunner's autocompletion over bash's and hence don't see the debug messages. However, it is certainly an upstream goal to make KDE applications play nice in other environments both visually and behaviourally. That's what I mean as I stated that some developers don't seem to care. 'Aus den Augen, aus dem Sinn' so to speak ;). I see your point in bringing this up on this list to end up with distribution- wide guidelines, but for pragmatic reasons I think you're better off contacting the application or framework maintainers directly. KDE has one debugging system, Mozilla has another one, the Linux kernel has yet another one for the primary terminal, Java apps have their own local logging policies and so on. It would be a huge task trying to unify the policies. Jepp, you are right. But I guess I'm not passionated enough with this topic, to push the thing. The output annoys me every time I see it and I brought it up on this list to see what others think about it and perhaps make them thinking about it. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4ns6ti4@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
]] Josef Spillner | When KDE applications are run in a KDE environment, the debug output is | normally not an issue because even terminal-using people prefer KRunner's | autocompletion over bash's and hence don't see the debug messages. However, it | is certainly an upstream goal to make KDE applications play nice in other | environments both visually and behaviourally. I would guess they still fill up the .xsession-errors file, though? At least for me, that file is mostly useless due to: « ...Too much output, ignoring rest... » as the last line. [...] | It would be a huge task trying to unify the policies. Sure, but so is making a distro, and having unified policies is a fairly big part of making a distro. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwyg9ih2@qurzaw.linpro.no
Re: Debug output etc, cluttering the terminal
On Sun, Aug 15, 2010 at 10:05:17AM +0100, Neil Williams wrote: Users may but developers will be looking for that debug output and starting the program from the command line explicitly to be able to collect it. (Filing a bug will usually result in the user being asked to start the program from the command line too.) Sure. And there is no reason why such a request could not include something along the lines of 'please run the application with the -d option so that it produces debug output'. Neil, nobody is disclaiming that debug output can be useful for a developer. But an application that has nothing useful to say should not say anything. The default for _any_ application should be to _not_ produce any output until there is a problem. This debugging output does cause problems: it slows down the application (doing 'cout' or 'printf' when they are not needed *does* take up some amount of CPU time, which becomes significant when the amount of output gets rather large), it generates huge .xsession-errors files that can cause problems for people with low quotas or for people who actually need the *useful* information in those files, and (in the case of KDE applications) it pollutes random unrelated terminals with output long after the application that was started on that terminal has exited, just because KDE applications like to start background daemons. There is no good reason why doing debugging output should be the *default*. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100815150857.gl27...@celtic.nixsys.be
Re: Debug output etc, cluttering the terminal
Am Sonntag, 15. August 2010, 14:19:05 schrieb Tollef Fog Heen: I would guess they still fill up the .xsession-errors file, though? At least for me, that file is mostly useless due to: « ...Too much output, ignoring rest... » as the last line. Yes they would, because the applications still see their stderr channel and happily write to it. What I meant with not an issue anymore was the issue of intermixed useful and useless terminal output; of course the issue of wasting CPU and perhaps harddisk resources remains when debugging is not disabled. Considering Holger's comment about disks filling up, the scope of this issue in the context of resource saving and energy-efficient computing then extends to /var/log and logging in general and includes the question of necessity and longevity of logfiles bound to system and user sessions. It also touches on badly written default cron jobs which are just as resource- wasting and user-annoying for little gain, for example non-incremental index updates. When you run a system on battery, maybe even from USB stick or SD card, all of this equally matters. I'm all for solving these problems, but optimistically spoken I'd be positively surprised if Debian could turn no user annoyance by default into a universally accepted, enforceable and release-goal-timed policy before 2020. Therefore, I suggested tracking this at the per-package/per-originator level to try getting rid of the biggest offenders first. By doing so, the motives of the KDE-Qt/Gtk+/WINE/ALSA/... maintainers, for example, for having the debug output enabled by default can be found out and serve as input for a decision about a policy. I'm sure the debug areas are not enabled by default to annoy users, this is merely a side effect :-) Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008151730.05706.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
On su, 2010-08-15 at 14:19 +0200, Tollef Fog Heen wrote: I would guess they still fill up the .xsession-errors file, though? At least for me, that file is mostly useless due to: « ...Too much output, ignoring rest... » as the last line. It's pretty clear to me that both .xsession-errors and the stderr of GUI apps are lousy ways of logging debugging messages. Something similar to syslog for a per-user/per-session would be a very useful thing to have, in my opinion. A systematic way of doing that would help with log rotation (thus saving disk space), and bug reporting (automatically attach logs for the crashed process), etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281888093.5840.109.ca...@havelock
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 08:08:57 -0700 Wouter Verhelst wou...@debian.org wrote: On Sun, Aug 15, 2010 at 10:05:17AM +0100, Neil Williams wrote: Users may but developers will be looking for that debug output and starting the program from the command line explicitly to be able to collect it. (Filing a bug will usually result in the user being asked to start the program from the command line too.) Sure. And there is no reason why such a request could not include something along the lines of 'please run the application with the -d option so that it produces debug output'. Unreproducible bugs will, by their nature, not be fixable if that is applied rigorously or as a change in Policy, which some were suggesting here. Neil, nobody is disclaiming that debug output can be useful for a developer. But an application that has nothing useful to say should not say anything. The default for _any_ application should be to _not_ produce any output until there is a problem. The amount of debug output has to be controlled, yes - it should only relate to areas where bugs are likely to be hard to reproduce without such output - and there are applications (I'm looking at you epiphany-browser and you, iceweasel) which seem to pay little attention to the notices produced by g_return_if_fail statements which result from errors in their own code. I won't defend that because if a library or function call fails an assertion, then whatever you're doing to call that function is *wrong*, so fix the code. ;-) (Even if only to do whatever error checking the function does before actually calling the function. The process of identifying WHY an assertion fails is itself bug fixing. Passing NULLs to functions which cannot accept NULLs without failing an assertion is a BAD habit. Stop it, check your pointers BEFORE making the call.) Most of this is upstream stuff - that's why I care about Debian not mandating that all this stuff should disappear, it isn't about just us, it's about helping upstream fix bugs. Most of the stuff in ~/.xsession-errors which has been mentioned here, are exactly these kind of assertion failure errors: (gnome-power-manager:2346): GLib-GObject-WARNING **: value -nan of type `gdouble' is invalid or out of range for property `percentage' of type `gdouble' (polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed Those are BUGS. It might not cause symptoms now but it is still relevant to how other bugs in that application are triaged. The upstream code needs to be fixed to check these values before passing them to the relevant function. I spend a lot of time tracking down just these kind of assertion failures in my own upstream code. It is an irksome task at times but that is no excuse for not fixing these things. Indeed, it is a prime motivation for working out exactly where more of such assertion tests need to be implemented. Debug output needs to be retained but it also needs to be managed and not ignored. This debugging output does cause problems: it slows down the application (doing 'cout' or 'printf' when they are not needed *does* take up some amount of CPU time, which becomes significant when the amount of output gets rather large), ... when abused, yes. There are ways to avoid this problem (e.g. when debugging thread-locking issues which are always time-sensitive) IF the debug calls themselves are carefully managed. it generates huge .xsession-errors files that can cause problems for people with low quotas or for people who actually need the *useful* information in those files, and (in the case of KDE applications) it pollutes random unrelated terminals with output long after the application that was started on that terminal has exited, just because KDE applications like to start background daemons. There is no good reason why doing debugging output should be the *default*. Not a default across all packages and all debug output but there are situations where *some* debug output needs to be part of the default output of the application in order to actually capture the data necessary to fix the bugs. Some applications, even some mature applications, need to be able to output debug information to the controlling terminal as a matter of course in order to fix unreproducible and/or intermittent bugs. Debian should not prevent this behaviour but encourage upstreams to *moderate* their use of default debug output by getting them to fix their own code where it causes assertion failures in other code and by prompting upstream to consider downgrading certain debug output to the non-default output level. Manage the debug output and everyone wins because the output itself becomes easier to understand. Remove the debug output completely and everybody loses, especially users. It is not clutter but it does need to be managed to contain only useful and relevant debug data. It is simply not helpful to mandate
Re: Debug output etc, cluttering the terminal
Wouter Verhelst wou...@debian.org writes: gets rather large), it generates huge .xsession-errors files that can cause problems for people with low quotas or for people who actually Indeed. I often find the SD card of my PDA (openmoko) filled with a useless .xsession-errors. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84tymval4d@sauna.l.org
Re: Debug output etc, cluttering the terminal
Quoting Michael Welle (mwe012...@gmx.net): Hello, what is the reason that many applications clutter the terminal with output that is obvisously debug output? Lets take digikam as an example: (I read most other comments in this thread before writing this) I have to concur to everything that was brought by poeple who *don't* want this debug gibberish to appear either in their terminal or in their ~/.xsession-errors: Here's mine, started yesterday morningand I barely did nothing since then as I'm more travelling around Vermont that playing with my KDE apps: bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite ls -l ~/.xsession-errors -rw--- 1 bubulle bubulle 2511641 15 août 18:28 /home/bubulle/.xsession-errors That's 2 megabytes ofcrap: startkde: Starting up... kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_klauncher.so Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_kded4.so .../... kephald starting up XRANDR error base: 163 RRInput mask is set!! RandRScreen::loadSettings - adding mode: 73 1280 x 800 RandRScreen::loadSettings - adding mode: 74 1280 x 800 .../... And this for gazillion of linesI should try some day to check ~/.xsession-errors just after I open a session. GNOME zealots will of course laugh and they might be right (at least about thisapart from that, I still favor KDE as desktop environment)...so I really hope there's a way to fix this. I equally hate what clutters my konsole window when I happen to manually launch a KDE app. And, finally, as someone who often leaves his own desktop environment opened for months in the same session, at work, I deeply concur to Holger's comment about wasting space in home directories (mine being constrained to a few gigabytes). Thankfully, there, I'm not using KDE and not even Debian, indeed..:-) signature.asc Description: Digital signature
Re: Debug output etc, cluttering the terminal
On Sun, 15 Aug 2010 18:34:56 -0400, Christian PERRIER wrote: Here's mine, started yesterday morningand I barely did nothing since then as I'm more travelling around Vermont that playing with my KDE apps: bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite ls -l ~/.xsession-errors -rw--- 1 bubulle bubulle 2511641 15 août 18:28 /home/bubulle/.xsession-errors That's 2 megabytes ofcrap: gre...@belanna:~$ ls -l ~/.xsession-errors -rw--- 1 gregoa gregoa 6946783 Aug 16 00:00 /home/gregoa/.xsession-errors Almost 7 MB ... GNOME zealots will of course laugh and they might be right (at least about thisapart from that, I still favor KDE as desktop environment)...so I really hope there's a way to fix this. ... and I'm neither using GNOME nor KDE. The X session was started ~ 5 hours ago. Among the contents are e.g. ~20.000 lines saying: (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead and ~20.000 lines: info: 0, warning: 0, error: 0 Done which are also from iceweasel if I'm not mistaken. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Schmetterlinge: Otto Bauer Originalzitat signature.asc Description: Digital signature
Re: Debug output etc, cluttering the terminal
gregor herrmann gre...@debian.org writes: Among the contents are e.g. ~20.000 lines saying: (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead I tracked this down at one point and decided that this was the fault of Adobe's Flash player rather than anything the Mozilla folks had any control over. I now just redirect the output of Iceweasel to /dev/null where I have to run the Flash player. However awful that one might think Adobe's Flash code is, it's actually worse than that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874oeve87f@windlord.stanford.edu
Debug output etc, cluttering the terminal
Hello, what is the reason that many applications clutter the terminal with output that is obvisously debug output? Lets take digikam as an example: kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_klauncher.so Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(Q kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_kded4.so kdeinit4: preparing to launch /usr/bin/kbuildsycoca4 kbuildsycoca4 running... kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_kconf_update Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(Q Time elapsed: 29 ms close(34) in netlib_connectsock() Time elapsed: 9 ms Model: Time elapsed: 64 ms TextureColorizer: Time elapsed: 19 ms Time elapsed: 5 ms close(42) in netlib_connectsock() And about 50 more lines are following just to start the application. Or take iceweasel. After some time hundreds of gdk warnings are filling your terminal. What is the reason for this kind of output? A typical end user don't understand the output. Furthermore it shadows useful messages or edge them out of the history list. That behaviour puzzles me for some time now. It doesn't seem to be very unix-like. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6c98489@stella.c0t0d0s0.de
Re: Debug output etc, cluttering the terminal
On Sat, 14 Aug 2010 19:59:50 +0200 Michael Welle mwe012...@gmx.net wrote: what is the reason that many applications clutter the terminal with output that is obvisously debug output? It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. It's not clutter. If you don't want to see it, run the command and redirect stderr. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpqYvHAXxDLg.pgp Description: PGP signature
Re: Debug output etc, cluttering the terminal
On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. The Unix tradition is for programs to run silently unless there's a problem. Taking 64ms to complete some operation is not, in general, a problem. I have no problem with programs taking an environment variable or a command line option in order to produce debugging output, but it shouldn't be the default. When you run these programs outside of a terminal, the output goes to .xsession-errors. Logging a lot of useless debugging information makes finding actual problems in .xsession-errors a lot less likely. It's not clutter. If you don't want to see it, run the command and redirect stderr. It is clutter. In my case, I opened a PDF in mutt. mutt used okular instead of evince (why, I'm not sure) and therefore the terminal in which I run my mutt session now has KDE daemons screaming at me when I update my system. This is not desirable. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debug output etc, cluttering the terminal
On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams codeh...@debian.org wrote: It's debug output, it is useful when debugging and you need the output, e.g. when fixing bugs and the user can just be asked to run the command from the terminal and post the output to help in debugging the bug report. Generally, the debug output for a particular release tends to reflect the issues which upstream were working on most intensively before that release and therefore can have a direct impact on the likelihood of new bugs or regressions in old bugs. It's not clutter. If you don't want to see it, run the command and redirect stderr. debug output should certainly not be output by default in released versions without a command-line or configuration option turning it on. l for one don't want ls doing something like this: ls: starting up ls: checking for bad filesystems ls: searching for files in /home/foo/some/path foo bar/ baz/ ls: 1 file found ls: 2 directories found -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfhpe+k8oknb0_mz7alkhbamz2-j6nk5hsz...@mail.gmail.com
