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

[Philip Withnall]

On Tue, 2019-08-13 at 23:16 +0000, 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