Bug 1227295 - no qDebug output
Summary: no qDebug output
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-settings
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1233280 (view as bug list)
Depends On: qt-5.6
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-02 11:11 UTC by Ivan Romanov
Modified: 2021-01-25 00:01 UTC (History)
20 users (show)

Fixed In Version: kde-settings-23-11.fc23.1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-15 07:21:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ivan Romanov 2015-06-02 11:11:03 UTC
qDebug works fine on Fedora 20 and Fedora 21 but on Fedora 22 no any output. Seems that QLoggingCategory::defaultCategory()->setEnabled(QtDebugMsg, false) by default. If explicity enable debug output in ~/.config/QtProject/qtlogging.ini it works.

Atm when qDebug no ouput qWarning and qCritical work fine.

Comment 1 Kevin Kofler 2015-06-02 12:00:52 UTC
This is by design. Our users do not want to get spammed with debugging output by default. It is easy for developers to enable it. (We are also working on packaging the GUI KDE now ships for editing qtlogging.ini to make it even easier.)

Comment 2 Rex Dieter 2015-06-02 13:31:19 UTC
See also 
https://admin.fedoraproject.org/updates/FEDORA-2015-8875/kde-settings-22-10.fc22

where qtlogging.ini landed

Comment 3 Kevin Kofler 2015-06-18 17:41:08 UTC
*** Bug 1233280 has been marked as a duplicate of this bug. ***

Comment 4 Rex Dieter 2015-06-18 17:49:49 UTC
Lemme re-open this (at least for awhile), while we take more feedback.

Comment 5 Kai Koehne 2015-06-19 06:44:52 UTC
One of the issues with this is that it not only affects the system Qt, but other Qt versions (e.g. compiled by the user), too ...

Would it help if Qt would look up qtlogging.ini in QT_INSTALL_DATA -> /usr/share/qt5/ ?

Comment 6 Rex Dieter 2015-06-19 11:13:36 UTC
Yes, that could help (assuming that would limit the affect to only the system Qt as desired).

Comment 7 Rex Dieter 2015-08-26 19:23:55 UTC
rebasing to rawhide/FutureFeature, while waiting for better solution

Comment 8 Kai Koehne 2015-08-27 06:00:05 UTC
With Qt 5.6 onwards, you'll be able to store a qtlogging.ini in $[QT_INSTALL_DATA] : https://codereview.qt-project.org/#/c/114805/4

Comment 9 Rex Dieter 2015-08-27 16:49:36 UTC
Thanks, I'll see if we can backport that to include in our 5.5 packaging.

Comment 10 Georg Sauthoff 2015-12-06 21:35:48 UTC
I can confirm this issue on Fedora 23.

I noticed it when adding a qDebug() statement to a program I was developing, when it didn't produce the expected output.

(I then first reviewed my build files because I suspected that some compile flag disabled the qDebug() output - only later I looked into qtlogging configuration files.)

Perhaps it is also an option to ship a more fine-grained system-wide qtlogging.ini file.

For example, instead of the current 

$ cat /etc/xdg/QtProject/qtlogging.ini
[Rules]
*.debug=false

one could use something like this:

[Rules]
*.debug=true
qt.*.debug=false


With that I get the qDebug() output from my own programs, but I don't get spammed with messages from Qt itself.

Comment 11 Rex Dieter 2015-12-07 12:43:55 UTC
OK, now that 5.6.0 is landing in rawhide, I'll take a closer look at this, for both utilizing $[QT_INSTALL_DATA] , and possibly restricting the config to only
[Rules]
qt.*.debug=false

Comment 12 Kai Koehne 2015-12-07 12:53:35 UTC
Please do so, ideally before 5.6.0 is released :)

Btw, "*.debug=true,qt.*.debug=false" is already the default if you don't specify any rules.

Comment 13 Rex Dieter 2015-12-07 13:04:52 UTC
Oh yay, for excellent defaults too.  In that case, we could consider dropping the custom qtlogging.ini altogether.

Comment 14 Kevin Kofler 2015-12-07 14:02:32 UTC
I think the only sane distro default for qDebug is globally off by default.

qt.*.debug=false is not sufficient because it does not even cover KF5 libraries, let alone (distro-packaged) applications.

Comment 15 Rex Dieter 2016-02-25 15:26:10 UTC
qtbase changes landed:

%changelog
* Thu Feb 25 2016 Rex Dieter <rdieter> 5.6.0-0.33.rc
- ship $$[QT_INSTALL_DATA]/qtlogging.ini for packaged logging defaults (#1227295)

http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/commit/?id=a09edb40e5587bd34d73aaec637d89d049ebbb0e


When/if qt-5.6.0 lands in f22/f23, we can then remove /etc/xdg/QtProject/qtlogging.ini from qt-settings

Comment 16 Raphael Groner 2016-02-26 10:00:33 UTC
Now, we get in build.log:

qt.core.logging: Ignoring malformed logging rule: '#distrodefaults,seealsohttps://bugzilla.redhat.com/show_bug.cgi?id=1227295'

It seems you can not use comments.

Comment 17 Kai Koehne 2016-02-26 10:24:42 UTC
(In reply to Raphael Groner from comment #16)
> Now, we get in build.log:
> 
> qt.core.logging: Ignoring malformed logging rule:
> '#distrodefaults,seealsohttps://bugzilla.redhat.com/show_bug.cgi?id=1227295'
> 
> It seems you can not use comments.

You can, but the magic character is ';'

  ; distrodefaults see also https://bugzilla.redhat.com/show_bug.cgi?id=1227295

should work

Comment 18 Fedora Update System 2016-03-25 14:15:52 UTC
kde-settings-23-11.fc23.1 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d8dbbc4b73

Comment 19 Fedora Update System 2016-03-26 15:19:27 UTC
kde-settings-23-11.fc23.1 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d8dbbc4b73

Comment 20 Fedora Update System 2016-04-15 07:21:14 UTC
kde-settings-23-11.fc23.1 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 madcatx 2016-05-01 16:43:01 UTC
I might have misunderstood the issue but my up-to-date F23 installation still does not display any qDebug() output messages unless I apply the fix mentioned in Comment 10. Accodrding to dnf info I have "kde-settings-11.fc23.1" installed.

At least for me the issue still persists.

Comment 22 madcatx 2016-05-01 16:47:29 UTC
* I obviously mean kde-settings-23-11.fc23.1

Comment 23 Rex Dieter 2016-05-02 02:05:47 UTC
See comment #1 and comment #2 , the no debug policy applies only to the system copy of Qt5 now

Comment 24 madcatx 2016-05-02 13:14:04 UTC
So the expected result is to get no qDebug() output from applications that are built against the Qt5 libraries shipped by Fedora and I am expected to either override the default setup or use my own build of Qt if I need to use qDebug()?

Comment 25 Rex Dieter 2016-05-02 13:23:02 UTC
Yes

Comment 26 madcatx 2016-05-02 13:53:31 UTC
Okay, fair enough. It's somewhat annoying for those who develop Qt-based apps but at least its now a documented behavior. Thanks for explaining this...

Comment 27 Jack 2016-07-08 11:32:39 UTC
This bug is still exist in Fedora24 Qt-5.6.0. And setting qtlogging.ini did not work!

Comment 28 Rex Dieter 2016-07-08 13:50:50 UTC
Jack, can you file a new bug please, including the contents of your qtlogging.ini and a test-case that didn't work as expected?  Thanks.

Comment 29 Fredy Neeser 2016-10-13 15:29:59 UTC
(In reply to Jack from comment #27)
> This bug is still exist in Fedora24 Qt-5.6.0. And setting qtlogging.ini did
> not work!

I wanted to look at Plasma debug messages but had the same problem on Fedora24 with Qt-5.6.1 - the settings in
    ~/.config/QtProject/qtlogging.ini
hat no effect whatsoever, and no debug messages were shown.

Finally I figured out that a line with '*.debug=false' in
    /usr/share/qt5/qtlogging.ini
was the culprit -- this line overrides any *.debug settings in
    ~/.config/QtProject/qtlogging.ini

So I ended up simply removing
    /usr/share/qt5/qtlogging.ini
and now my settings in ~/.config/QtProject/qtlogging.ini are respected.

Note that
  http://doc.qt.io/qt-5/qloggingcategory.html
documents the Qt Logging Rules and the Order of evaluation for various sources of logging rules, particularly for files QtProject/qtlogging.ini. It mentions /etc/xdg, which implies that providing /etc/xdg/QtProject/qtlogging.ini might be necessary, but adding that file had NO effect.  It does not (or not clearly) mention
  /usr/share/qt5/qtlogging.ini
which was loaded in my case.  I only found out by setting the QT_LOGGING_DEBUG=1
environment variable (see below).

I do understand that normal users don't want to get spammed with Qt and Plasma debug messages, but the use of an undocumented /usr/share/qt5/qtlogging.ini with *.debug=false (which cannot be overridden) is very confusing for someone who actually wants to enable debug messages.


B.t.w., I find it useful for debugging to create a file

$ cat .config/plasma-workspace/env/debug.sh 
# QT_LOGGING_DEBUG=1 causes loadRulesFromFile to show files loaded
export QT_LOGGING_DEBUG=1

export QT_MESSAGE_PATTERN='%{function}: %{message}'

Comment 30 Rex Dieter 2016-10-13 20:12:35 UTC
If comment #29 is true, that /usr/share/qt5/qtlogging.ini takes priority, I'd argue this is an Qt5 bug.  Stuff under ~/.config/ should take priority, it's a clearly documented in the xdg spec,
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
wrt XDG_CONFIG_DIRS vs XDG_CONFIG_HOME

"The base directory defined by $XDG_CONFIG_HOME is considered more important than any of the base directories defined by $XDG_CONFIG_DIRS."

Comment 31 Rex Dieter 2016-10-13 20:19:06 UTC
anyone interested in filing an upstream bug @ https://bugreports.qt.io ?  Feel free to quote my comment #30 , along with including a minimal test case (comment #29 content may be sufficient)

Comment 32 Fredy Neeser 2016-10-17 09:58:55 UTC
Sorry for the noise regarding /usr/share/qt5/qtlogging.ini -- I restored it
(with its line *.debug=false) to double check my claims in comment #29 but found that debug messages are in fact shown with the following contents in my own qtlogging.ini:

$ cat ~/.config/QtProject/qtlogging.ini
[Rules]
*.debug=true
qt.*.debug=false

*.warning=true
*.critical=true

kscreen.*=true
; <EOF>

so the ordering rule mentioned by Rex in comment #30 is in fact respected.

It's worth mentioning that if you have both general (wildcarded) rules and module-specific rules for the same module/severity in qtlogging.ini, then rules loaded later (typically the more specific ones) will replace rules loaded earlier.

Particularly if kdebugsettings is used to edit ~/.config/QtProject/qtlogging.ini and custom rules are also added manually, one should pay attention to rules loaded later, which may inhibit rules placed at the top of the file.

It now seems that doing the changes manually is safer than using kdebugsettings ...

Comment 33 Shadders 2016-12-09 19:48:47 UTC
Hi,

On fedora 24, and the following error presented :

qt5-qtbase-5.6.2-1.fc24.x86_64: Delta RPM rebuild failed

This was due to the /usr/share/qt5/qtlogging.ini which i had changed previously to be :

[Rules]
*.debug=true

Since this overrides local qtlogging.ini. (~/.config/QtProject/qtlogging.ini)

Error seemed to be due to the file ending before the 22 characters expected to be within the file for the drpm build. 

Regards,

Richard.

Comment 34 Be 2018-07-12 22:38:32 UTC
> I think the only sane distro default for qDebug is globally off by default.
> qt.*.debug=false is not sufficient because it does not even cover KF5 libraries, let alone (distro-packaged) applications.

I disagree. With the current packaging, every Qt application has to either define its own logging category or restore Qt's defaults with:

QLoggingCategory::setFilterRules("*.debug=true\n"
"qt.*.debug=false");

to work around this bug. KDE libraries use their own logging category with debug level messages turned off in that category by default, so there is no need for the distribution to do anything to hide those. Debian and Ubuntu have already fixed this by removing the custom filter rules and reverting to Qt's defaults:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886437
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646

Comment 35 Be 2018-07-12 23:01:43 UTC
This does not only affect the developer experience. It also interferes with Qt application developers getting useful logs from users.

Comment 36 Kevin Kofler 2018-07-13 00:09:47 UTC
(In reply to Be from comment #34)
> I disagree. With the current packaging, every Qt application has to either
> define its own logging category or restore Qt's defaults with:
> 
> QLoggingCategory::setFilterRules("*.debug=true\n"
> "qt.*.debug=false");

No. Any application doing something like this is broken. Debugging output must NOT be displayed to the user in release builds.

> to work around this bug.

There is no bug. Debugging output is opt-in as it should be. Users do NOT want their terminals spammed with debugging junk. (In fact, I would go much farther than the current Fedora default and also silence qWarning by default.)

Comment 37 Be 2018-07-13 00:22:54 UTC
What is the harm of having debugging messages on by default? Qt is for GUI applications which are not typically run from terminals unless debugging output is specifically desired. Perhaps some applications misbehave by dumping debugging messages into an endlessly growing log, but that would be a bug in the application which should be fixed in that application.

Disabling debugging globally makes it difficult for Qt application developers to support users and fix bugs. If you choose to keep this policy, Mixxx will use QLoggingCategory::setFilterRules to restore Qt's defaults.

Comment 38 Uwe Klotz 2018-07-13 08:32:02 UTC
I also disagree with the decision to tamper with the configuration of a commonly used library in this way.

Please remember that Fedora is used by many developers (like us) that expect to see debug messages during development. Both the developers and package managers of an application should be responsible for ensuring that logging is used and configured appropriately in the package that finally will be installed by end users.

Otherwise each and every application needs to include a development mode hack in their code to restore the bent default configuration during development. As a multi-platform application we are already struggling with platform-dependent behaviour a lot! Please don't make our lives even harder by introducing more platform variations.

PS: One of the reasons I'm using Fedora is because I expect to get an almost vanilla configuration that just works without any distribution specific bells and whistles.

Comment 39 Kevin Kofler 2018-07-13 08:58:26 UTC
(In reply to Be from comment #37)
> Disabling debugging globally makes it difficult for Qt application
> developers to support users and fix bugs. If you choose to keep this policy,
> Mixxx will use QLoggingCategory::setFilterRules to restore Qt's defaults.

Then the package will have to be patched to remove this junk.

Comment 40 Kevin Kofler 2018-07-13 09:07:18 UTC
The issue that we have is: If I have a terminal open, and then start some KDE app in it, say, a text editor (KWrite/Kate, but that is in no way an issue specific to those 2 applications!), then I get loads and loads of debugging messages spamming my terminal. Even now, there are still way too many qWarnings (which is why I keep arguing for also silencing those, but Rex Dieter argues that that would go too far), but with qDebug enabled, even things like mouse movements (!) get spammed to the terminal. This is just not practicable.

As for applications started outside of a terminal, they log to .xsession-errors, which was growing really huge back when qDebug was enabled. So arguably, the issue is even worse there, because terminal spam goes away as soon as you close the terminal, or even scrolls off the terminal's backbuffer, but .xsession-errors spam fills up persistent storage (HDD/SSD).

It is an established *nix policy that programs should be silent on success and only print terminal output if an error occurs.

Comment 41 Georg Sauthoff 2018-07-13 09:08:55 UTC
@Be, @Uwe - I'm using Fedora also for development and I usually have a terminal with `journalctl -f` running. Enabling Qt debug output for all installed Qt applications, by default, would make that quite useless because of all the noise.

Getting the debug output when you are developing Qt applications is really simple, though. Just put another dotfile in your $HOME, e.g.:

$ cat ~/.config/QtProject/qtlogging.ini
[Rules]
*.debug=true
qt.*.debug=false

A one-time change and after that you get debug output for all the Qt applications you are developing.

No need to do questionable stuff like calling QLoggingCategory::setFilterRules() in your program.

Comment 42 Rex Dieter 2018-07-13 18:07:46 UTC
Given:
* this bug is closed
* bugzilla isn't well-suited for discussion

I encourage those you want to engage in a constructive discussion to consider changing things to do so on our mailing list:
https://lists.fedoraproject.org/admin/lists/kde.lists.fedoraproject.org/

Thank you.

Comment 43 Rex Dieter 2018-07-13 18:55:12 UTC
In particular, personally, I'm open to considering alternatives that can satisfy requirement:
* software built by/for the distribution defaults to no debug output.

I understand the current implementation applies that to more than just distro-built stuff only.  

Too bad that qCDebug doesn't follow qDebug behavior of being disabled in Release builds.

If there are any other options, I'd love to hear of them (onlist)


Note You need to log in before you can comment on or make changes to this bug.