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 +0000, 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 libc6 2.28-10 > ii libffi6 3.2.1-9 > ii libmount1 2.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 >
