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.
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.)
See also https://admin.fedoraproject.org/updates/FEDORA-2015-8875/kde-settings-22-10.fc22 where qtlogging.ini landed
*** Bug 1233280 has been marked as a duplicate of this bug. ***
Lemme re-open this (at least for awhile), while we take more feedback.
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/ ?
Yes, that could help (assuming that would limit the affect to only the system Qt as desired).
rebasing to rawhide/FutureFeature, while waiting for better solution
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
Thanks, I'll see if we can backport that to include in our 5.5 packaging.
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.
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
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.
Oh yay, for excellent defaults too. In that case, we could consider dropping the custom qtlogging.ini altogether.
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.
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
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.
(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
kde-settings-23-11.fc23.1 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d8dbbc4b73
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
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.
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.
* I obviously mean kde-settings-23-11.fc23.1
See comment #1 and comment #2 , the no debug policy applies only to the system copy of Qt5 now
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()?
Yes
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...
This bug is still exist in Fedora24 Qt-5.6.0. And setting qtlogging.ini did not work!
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.
(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}'
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."
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)
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 ...
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.
> 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
This does not only affect the developer experience. It also interferes with Qt application developers getting useful logs from users.
(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.)
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.
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.
(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.
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.
@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.
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.
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)
I started a discussion thread, https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/LW37ZDF5IHNIIZO3V3ODXKGUDCH2UTTQ/