All those are warnings, not garbage or debug output. File bugs about
those,
there should be zero warnings in normal usage.
Shouldn't they trigger abrt then? more importantly, is it possible to capture
that in the QA process during distribution composition? I believe a lot of
those
On 27 January 2015 at 19:10, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
On 01/27/2015 07:03 AM, Bastien Nocera wrote:
All those are warnings, not garbage or debug output. File bugs about
those, there should be zero warnings in normal usage.
Shouldn't they trigger abrt then? more
On 01/27/2015 07:03 AM, Bastien Nocera wrote:
All those are warnings, not garbage or debug output. File bugs about
those,
there should be zero warnings in normal usage.
Shouldn't they trigger abrt then?
Yes, that would be a great help towards making the warnings filed and fixed.
Care
The warnings only happen when using development versions of GTK+. So it
shouldn't happen in F21, or in the future in F22, just in rawhide.
So when I talked about GTK, I meant the whole GNOME stack, like GLib, gvfs, st,
clutter, mutter, gnome-shell, gstreamer, etc. I guess not all of these
On 01/27/2015 07:03 AM, Bastien Nocera wrote:
All those are warnings, not garbage or debug output. File bugs about those,
there should be zero warnings in normal usage.
Shouldn't they trigger abrt then? more importantly, is it possible to
capture that in the QA process during distribution
All those are warnings, not garbage or debug output. File bugs about those,
there should be zero warnings in normal usage.
- Original Message -
The warnings only happen when using development versions of GTK+. So it
shouldn't happen in F21, or in the future in F22, just in rawhide.
Thanks for the encouragement. For the record, I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1184038 (GTK apps)
https://bugzilla.redhat.com/show_bug.cgi?id=1184868 (evince)
I very much recommend you to report these issues (also) to GNOME Bugzilla.
GNOME/GTK developers don't follow Red
The warnings only happen when using development versions of GTK+. So it
shouldn't happen in F21, or in the future in F22, just in rawhide.
- Original Message -
Thanks for the encouragement. For the record, I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1184038 (GTK apps)
Pete Zaitcev writes:
On Wed, 14 Jan 2015 11:22:57 +0100
Marcel Oliver m.oli...@jacobs-university.de wrote:
Are these considered bugs that I should file against the package? Is
there a policy that applies?
I think you should file. I had in the past made maintainers of gvim
On Wed, 14 Jan 2015 11:22:57 +0100
Marcel Oliver m.oli...@jacobs-university.de wrote:
Are these considered bugs that I should file against the package? Is
there a policy that applies?
I think you should file. I had in the past made maintainers of gvim
(vim-X11) and evince take action to fix
Björn Persson wrote:
Except when they have really serious errors.
I once had an X problem that prevented Openoffice from working. It
showed no window, output nothing, and terminated immediately with an
exit code of zero. In other words it behaved just like the command
true. That's going a
Orion Poplawski wrote:
Sounds good to me - my users (old unix folks who always use the command
line) are always complaining about this. Where do we tweak that?
Unfortunately, it can't really be done without modifications to either Qt or
the Qt applications. Either we build the applications
Kevin Kofler wrote:
I'm with you, debugging spam needs to go away, GUI applications have
no business writing anything at all to the console, ever.
Except when they have really serious errors.
I once had an X problem that prevented Openoffice from working. It
showed no window, output nothing, and
Am 16.01.2015 um 10:50 schrieb Björn Persson:
Kevin Kofler wrote:
I'm with you, debugging spam needs to go away, GUI applications have
no business writing anything at all to the console, ever.
Except when they have really serious errors.
I once had an X problem that prevented Openoffice
On 01/15/2015 03:23 PM, Kevin Kofler wrote:
Jaroslav Reznik wrote:
So it's kWarning, not kDebug and it can't be ignored by using kdebugdialog
settings. There are two options - fix the underlying issue or change
kWarning to kDebug - it just depends on how important it is and it seem
as Harald
Reindl Harald wrote:
the same for broken desktop-files and what not reported again and again
in that context and nobody cares about - so why annoy the ordinary user
with that debug informations all day long?
I'm with you, debugging spam needs to go away, GUI applications have no
business
Jaroslav Reznik wrote:
So it's kWarning, not kDebug and it can't be ignored by using kdebugdialog
settings. There are two options - fix the underlying issue or change
kWarning to kDebug - it just depends on how important it is and it seem
as Harald already pointed out - nobody really cares. I
Am 15.01.2015 um 23:23 schrieb Kevin Kofler:
Jaroslav Reznik wrote:
So it's kWarning, not kDebug and it can't be ignored by using kdebugdialog
settings. There are two options - fix the underlying issue or change
kWarning to kDebug - it just depends on how important it is and it seem
as Harald
Reindl Harald h.rei...@thelounge.net wrote:
Am 15.01.2015 um 00:36 schrieb Zbigniew Jędrzejewski-Szmek:
the real problem with that crap messages is that if you are about
writing a longer command line and the in background mode started GUI
app decides to blow out it's helpful messages they
- Original Message -
On Wed, Jan 14, 2015 at 11:22:57AM +0100, Marcel Oliver wrote:
When I run okular I see:
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
okular(16844) KMimeTypeRepository::parents:
- Original Message -
- Original Message -
So it's kWarning, not kDebug and it can't be ignored by using kdebugdialog
settings. There are two options - fix the underlying issue or change
kWarning to kDebug - it just depends on how important it is and it seem
as Harald already
- Original Message -
- Original Message -
On Wed, Jan 14, 2015 at 11:22:57AM +0100, Marcel Oliver wrote:
When I run okular I see:
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se wrote:
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be very difficult to troubleshoot such a
program, should an actual bug come along, because you
On Thu, Jan 15, 2015 at 12:35:02AM +0100, Reindl Harald wrote:
Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos:
On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se
mailto:Bjorn@rombobjörn.se wrote:
If they don't have such a build-time option, then what I'm saying is
Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos:
On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se
mailto:Bjorn@rombobjörn.se wrote:
If they don't have such a build-time option, then what I'm saying is
that if one were to suppress the messages, then one should do
Alexander Ploumistos wrote:
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se
wrote:
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be very difficult to troubleshoot such a
program, should an actual
Am 15.01.2015 um 00:36 schrieb Zbigniew Jędrzejewski-Szmek:
the real problem with that crap messages is that if you are about
writing a longer command line and the in background mode started GUI
app decides to blow out it's helpful messages they appear unasked in
the middle of your input and so
Am 15.01.2015 um 00:13 schrieb Reindl Harald:
Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos:
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote:
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be
Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos:
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote:
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be very difficult to troubleshoot such a
On Thu, Jan 15, 2015 at 12:36:27AM +0200, Alexander Ploumistos wrote:
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se wrote:
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be very difficult to
On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se wrote:
If they don't have such a build-time option, then what I'm saying is
that if one were to suppress the messages, then one should do it with a
run-time option, not a build-time option. Then no different build would
be
Alexander Ploumistos wrote:
On the other hand, if every message that was not meant for the user
were suppressed, it would be very difficult to troubleshoot such a
program, should an actual bug come along, because you would need a
different build to get useful output in the console or a logging
On Wed, Jan 14, 2015 at 12:22 PM, Marcel Oliver
m.oli...@jacobs-university.de wrote:
Some of the main culprints for me are nemo, evince, and okular;
The applications that you mention are parts of specific desktop
environments. The messages that you see are not meant to be visible to the
user,
On Wed, Jan 14, 2015 at 11:22:57AM +0100, Marcel Oliver wrote:
Hallo,
there is one more thing which I found really annoying after upgrading
to F21. I like to launch GUI applications from the command line (I
know there is some debate on whether this habit makes me a target user
of Fedora,
Hello,
On Wed, Jan 14, 2015 at 11:22 AM, Marcel Oliver
m.oli...@jacobs-university.de wrote:
Many GUI applications write garbage to either stdout or stderr, making
the terminal windows difficult to view and navigate.
(...)
Some of the main culprints for me are nemo, evince, and okular; if I
35 matches
Mail list logo
