Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-14 at 07:09:19, Philip Withnall wrote: > In every situation where I’ve seen warnings (compile time, or run time) > hidden from developers, those warnings have very rarely been fixed. > Making them visible has increased the number of warnings which have > been fixed. > > Filing bugs against applications, which point out specific warnings > which need fixing is, I feel, a much better use of people’s time than > inventing new and innovative ways to hide those warnings. I've filed bugs #934790 through #934792 for some of the issues I've seen. From what I understand of the situation, #934791 and #934792 are likely bugs in GTK or GDK. As previously mentioned, I'm happy if GLib learns a way to suppress or redirect logging and that will meet my needs adequately. However, if that's not something the GNOME developers want to do, then I'm happy to keep sending any issues I see with GTK or GDK their way. I'm also suggesting to maintainers of relevant bugs that g_return*_if_fail could be patched to not warn to standard error, which would fix the majority of these issues, and would also be a satisfactory solution from the GLib side, although GTK would still need some additional patching. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-14 at 07:09:19, Philip Withnall wrote: > Sorry, I think you’re conflating two different types of programs here. > Command line applications like git have very different output > requirements on stderr/stdout from graphical programs. Command line > programs don’t normally use GTK, so shouldn’t see any of the warnings > you mention above. I would be very surprised if command line programs > using GLib (not GTK) emitted different warnings with different versions > of GLib. If they do, can you please provide me with concrete examples > and I can advise you about how to eliminate them. Lots of people run GTK+ programs from the command line. I do this all the time, and that's why this is an issue. I agree that many people do not, but those people who do are often heavy terminal users and this really bites them. Debian systems also invoke GUI programs from mailcap files and xdg-open, both of which are frequently used from the command line and command line tools. > GTK and GLib are separate libraries. They are indeed separate libraries, but they are developed as a set and are highly intertwined. GTK+ programs use the GLib logging functions for API misuse warning messages. Other libraries that are used with GTK+ also use these logging functions for the same purpose, which necessitates a change in GLib, or an agreement by GTK+ and the other UI libraries about how to honor the user's wishes not to receive these messages. If there were a simple solution where GTK+ and Clutter and all of the other libraries just called something like g_report_api_misuse, then there could be an environment variable or setting just for that, but I don't believe such a function exists. Since it's currently impossible to distinguish between GTK+'s warning messages and other messages, a bigger hammer is required. If you're willing to add such a function and allow users to suppress or redirect the output, I'm happy to reassign this bug to GTK+. > > Ultimately, I think it's most appropriate to let users decide for > > themselves if they would like to see non-user-visible issues on their > > terminal. I'm not even asking for this to be the default, just an > > option > > users can turn on. > > If it’s not on by default, almost all users will never find out about > it. If your argument is that seeing the warnings is only useful for > developers, then such an option should be on by default and developers > would have to explicitly turn it off. I'm not even requesting that they be disabled by default, although I do feel that they should be. I'm requesting an environment variable users can set to disable GLib logging while keeping it on by default. Alternatively, an environment variable directing GLib logging to a file would meet my needs, provided it supported character specials. I'd also be happy with just reporting these errors when developer mode is turned on during the build, or when -Werror is passed as a flag to the compiler. These are settings that will be turned on in development, but will not be enabled for non-development uses. I'm happy to look for solutions that solve the problem for me and all the other users that are acceptable to upstream. > Filing bugs against applications, which point out specific warnings > which need fixing is, I feel, a much better use of people’s time than > inventing new and innovative ways to hide those warnings. You seem to have ignored the part of my previous mail where I stated that this is not an effective solution to the problem. Some projects have a much longer release cycle than GLib, meaning even the latest versions of a release may acquire new warnings as new GLib and GTK+ releases come out. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On Tue, 2019-08-13 at 23:16 +, brian m. carlson wrote: > On 2019-08-13 at 06:12:30, Philip Withnall wrote: > > Hi, > > > > I can’t speak for the Debian project, but as an upstream GLib > > developer > > I can say such an environment variable would not be welcome > > upstream. > > > > Hiding such warnings makes them less likely to be fixed. It’s a way > > of > > sweeping bugs under the carpet which I don’t want to encourage. > > Each > > warning emitted by GTK or GLib indicates a non-trivial bug in the > > code > > which is calling it, which should be fixed. > > Unfortunately, it's often impossible to write code which works on > multiple versions of GTK+ without warnings. I took a version of GVim > which worked fine on Debian unstable with GTK+3 but produced copious > warnings on CentOS 7. This makes it difficult for folks who would > like > to upgrade one single component on a system without rebuilding the > entire GTK+ stack. In addition, an upgrade of GTK+ can cause > previously > working programs to produce errors where they did not before, causing > problems for users. I can believe that might be true in some cases, but I doubt it is *often* the case. Regardless, I encourage you to ask specific questions about the warnings you are encountering on https://discourse.gnome.org/ , and the GTK developers should be able to advise appropriately for each case. > In addition, Unix programs typically produce output to standard error > to > reflect a user-relevant error: something that the user has done wrong > or > that prevents the program from functioning in the way the user > requested. These warnings are not user relevant: they reflect a > developer error, not a problem that reflects a user-visible failure. > From the user perspective, everything is functioning as intended, so > output to standard error is not appropriate. > > And finally, overwhelmingly, developers take a long time to fix > warnings > like this, if they get fixed at all. Perhaps they don't see the use > case > of running graphical programs like PDF viewers from the command line. > More likely, they are overwhelmed with other issues and consider this > low priority. > > I appreciate that these reflect a defect in the program that should > be > fixed, but it isn't fair to force users to either fix these defects > for > themselves or deal with terminal junk. As a Git developer, I can tell > you people would be extremely unhappy if libpcre or libcurl produced > errors on their terminals when they ran Git, even if those were bugs > in > Git itself. I'm not sure why GLib should be different in this regard. Sorry, I think you’re conflating two different types of programs here. Command line applications like git have very different output requirements on stderr/stdout from graphical programs. Command line programs don’t normally use GTK, so shouldn’t see any of the warnings you mention above. I would be very surprised if command line programs using GLib (not GTK) emitted different warnings with different versions of GLib. If they do, can you please provide me with concrete examples and I can advise you about how to eliminate them. GTK and GLib are separate libraries. > Ultimately, I think it's most appropriate to let users decide for > themselves if they would like to see non-user-visible issues on their > terminal. I'm not even asking for this to be the default, just an > option > users can turn on. If it’s not on by default, almost all users will never find out about it. If your argument is that seeing the warnings is only useful for developers, then such an option should be on by default and developers would have to explicitly turn it off. In every situation where I’ve seen warnings (compile time, or run time) hidden from developers, those warnings have very rarely been fixed. Making them visible has increased the number of warnings which have been fixed. Filing bugs against applications, which point out specific warnings which need fixing is, I feel, a much better use of people’s time than inventing new and innovative ways to hide those warnings. Philip
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
On 2019-08-13 at 06:12:30, Philip Withnall wrote: > Hi, > > I can’t speak for the Debian project, but as an upstream GLib developer > I can say such an environment variable would not be welcome upstream. > > Hiding such warnings makes them less likely to be fixed. It’s a way of > sweeping bugs under the carpet which I don’t want to encourage. Each > warning emitted by GTK or GLib indicates a non-trivial bug in the code > which is calling it, which should be fixed. Unfortunately, it's often impossible to write code which works on multiple versions of GTK+ without warnings. I took a version of GVim which worked fine on Debian unstable with GTK+3 but produced copious warnings on CentOS 7. This makes it difficult for folks who would like to upgrade one single component on a system without rebuilding the entire GTK+ stack. In addition, an upgrade of GTK+ can cause previously working programs to produce errors where they did not before, causing problems for users. In addition, Unix programs typically produce output to standard error to reflect a user-relevant error: something that the user has done wrong or that prevents the program from functioning in the way the user requested. These warnings are not user relevant: they reflect a developer error, not a problem that reflects a user-visible failure. From the user perspective, everything is functioning as intended, so output to standard error is not appropriate. And finally, overwhelmingly, developers take a long time to fix warnings like this, if they get fixed at all. Perhaps they don't see the use case of running graphical programs like PDF viewers from the command line. More likely, they are overwhelmed with other issues and consider this low priority. I appreciate that these reflect a defect in the program that should be fixed, but it isn't fair to force users to either fix these defects for themselves or deal with terminal junk. As a Git developer, I can tell you people would be extremely unhappy if libpcre or libcurl produced errors on their terminals when they ran Git, even if those were bugs in Git itself. I'm not sure why GLib should be different in this regard. Ultimately, I think it's most appropriate to let users decide for themselves if they would like to see non-user-visible issues on their terminal. I'm not even asking for this to be the default, just an option users can turn on. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
Hi, I can’t speak for the Debian project, but as an upstream GLib developer I can say such an environment variable would not be welcome upstream. Hiding such warnings makes them less likely to be fixed. It’s a way of sweeping bugs under the carpet which I don’t want to encourage. Each warning emitted by GTK or GLib indicates a non-trivial bug in the code which is calling it, which should be fixed. Philip On Mon, 2019-08-12 at 23:31 +, brian m. carlson wrote: > Package: libglib2.0-0 > Version: 2.60.6-1 > Severity: normal > > Currently, GLib and various other GTK+-related software provide > logging, > which goes to stdout or stderr. Much of this logging is developer > focused and basically warns developers that they are doing > questionable > things that one or another toolkit is unhappy with. > > While this is great for debugging and developer visibility, it's not > great for end users who invoke GTK+-based programs from the terminal, > where the messages obscure previous output, sometimes scrolling the > screen significantly. In the past, GVim has been bitten by this > prominently, but various other software, including atril (a PDF > viewer) > and other tools commonly run from the command line, have fallen > victim > to it as well. The most inconvenient part for users is that upgrading > one of the shared libraries a piece of software uses can cause it to > emit many more warnings than before, with little recourse. > > Asking individual packages to fix these issues is not effective, > because, as is the nature with open source, developers lack the time > to > effectively fix all issues, and these issues are seen as purely > cosmetic. I've asked several packages to do so, and the turnaround > time > for fixing these issues is usually measured in years, if they are > fixed > at all. > > GLib should learn an environment variable to either suppress non- > fatal > messages (i.e., those that do not cause the program to abort) or > redirect them to a file (e.g., /dev/null). Even if upstream does not > want this feature, Debian should provide it. > > This is a common issue with multiple questions online, and would > provide > a large amount of value to users. > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, > 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libglib2.0-0 depends on: > ii libc62.28-10 > ii libffi6 3.2.1-9 > ii libmount12.34-0.1 > ii libpcre3 2:8.39-12+b1 > ii libselinux1 2.9-2+b2 > ii zlib1g 1:1.2.11.dfsg-1+b1 > > Versions of packages libglib2.0-0 recommends: > ii libglib2.0-data 2.60.6-1 > ii shared-mime-info 1.10-1 > ii xdg-user-dirs 0.17-2 > > libglib2.0-0 suggests no packages. > > -- no debconf information >
Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging
Package: libglib2.0-0 Version: 2.60.6-1 Severity: normal Currently, GLib and various other GTK+-related software provide logging, which goes to stdout or stderr. Much of this logging is developer focused and basically warns developers that they are doing questionable things that one or another toolkit is unhappy with. While this is great for debugging and developer visibility, it's not great for end users who invoke GTK+-based programs from the terminal, where the messages obscure previous output, sometimes scrolling the screen significantly. In the past, GVim has been bitten by this prominently, but various other software, including atril (a PDF viewer) and other tools commonly run from the command line, have fallen victim to it as well. The most inconvenient part for users is that upgrading one of the shared libraries a piece of software uses can cause it to emit many more warnings than before, with little recourse. Asking individual packages to fix these issues is not effective, because, as is the nature with open source, developers lack the time to effectively fix all issues, and these issues are seen as purely cosmetic. I've asked several packages to do so, and the turnaround time for fixing these issues is usually measured in years, if they are fixed at all. GLib should learn an environment variable to either suppress non-fatal messages (i.e., those that do not cause the program to abort) or redirect them to a file (e.g., /dev/null). Even if upstream does not want this feature, Debian should provide it. This is a common issue with multiple questions online, and would provide a large amount of value to users. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglib2.0-0 depends on: ii libc62.28-10 ii libffi6 3.2.1-9 ii libmount12.34-0.1 ii libpcre3 2:8.39-12+b1 ii libselinux1 2.9-2+b2 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages libglib2.0-0 recommends: ii libglib2.0-data 2.60.6-1 ii shared-mime-info 1.10-1 ii xdg-user-dirs 0.17-2 libglib2.0-0 suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
