Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging

[Philip Withnall]

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
>