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
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
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
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
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
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
6 matches
Mail list logo
