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
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 cal
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,
Emilio Pozuelo Monfort 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_SILE
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 dev
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 silen
Ben Hutchings 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
>> t
Hello,
Lars Wirzenius 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
Christoph Egger writes:
> Neil Williams writes:
>> On Sun, 15 Aug 2010 02:23:32 +
>> "brian m. carlson" 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 th
On 16/08/10 02:01, Russ Allbery wrote:
> gregor herrmann 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 rath
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 o
]] 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 pre
Good morning (at least in my time zone ;)),
Christian PERRIER 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 mos
gregor herrmann 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
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
> ~/
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
Wouter Verhelst 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 debia
On Sun, 15 Aug 2010 08:08:57 -0700
Wouter Verhelst 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 w
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-er
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
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 fr
]] 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
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 spec
Hello,
Neil Williams writes:
> On Sun, 15 Aug 2010 08:57:56 +0200
> Michael Welle 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
> sof
Neil Williams writes:
> On Sun, 15 Aug 2010 02:23:32 +
> "brian m. carlson" 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
> deve
Hello,
Neil Williams writes:
> On Sun, 15 Aug 2010 08:51:21 +0200
> Michael Welle 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
On Sun, Aug 15, 2010 at 10:02:15AM +0100, Neil Williams wrote:
> On Sun, 15 Aug 2010 12:44:59 +0800
> Paul Wise wrote:
>
> > On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams
> > wrote:
> >
> > > It's not clutter. If you don't want to see it, run the command and
> > > redirect stderr.
> >
> > deb
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
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
kdebu
* Neil Williams [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 gues
On Sun, 15 Aug 2010 02:23:32 +
"brian m. carlson" 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 termin
On Sun, 15 Aug 2010 08:57:56 +0200
Michael Welle wrote:
> Paul Wise 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:
> >
On Sun, 15 Aug 2010 12:44:59 +0800
Paul Wise wrote:
> On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams
> 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
On Sun, 15 Aug 2010 08:51:21 +0200
Michael Welle 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. Genera
Hello,
"brian m. carlson" 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 hel
Hello,
Paul Wise 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: searchin
Hello,
Neil Williams writes:
> On Sat, 14 Aug 2010 19:59:50 +0200
> Michael Welle 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 f
On Sun, Aug 15, 2010 at 7:09 AM, 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 d
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
On Sat, 14 Aug 2010 19:59:50 +0200
Michael Welle 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
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::serviceOwne
41 matches
Mail list logo
