Debian Bug report logs - #708830
dpkg: colourise dpkg output

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg: colourise dpkg output

Date: Sat, 18 May 2013 23:08:37 +0200

Package: dpkg
Version: 1.16.10
Severity: wishlist


Hi.

May I suggest to add optional colourisation of dpkg's output (perhaps even making the
colours configurable per category).

Non only on dist-upgrades but also on day-to-day's upgrades (especially for those people
using sid) one sees countless of lines of "standard dpkg output", most prominently things
like:
- Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
  Unpacking replacement foo ...
- Setting up foo (2.0-1) ...

but also the less oftem messages like:
- (Reading database ... ?%
- Processing triggers for ?


Quite frankly, these are usually boring... as (usually) nothing interesting happens on
them.
So I'd suggest to take a "less visible" colour for like grey.
I could however imagine to emphasise some of the information of these lines, which are
at least a bit interesting in normal cases, like for:
- Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
  Unpacking replacement foo ...
- Setting up foo (2.0-1) ...
=> the package name and version (not the deb file path)

or for
- Processing triggers for ?
=> the kind of triggers (e.g. man-db, doc-base or whatever)

For these I'd use bold or a bit lighter (or darker grey).



Now back to the main problem,... as all these messages from above have the same colour
right now, than everything else,... it can easily happen, that really important and/or
interesting messages are overseen in them.
Examples:
1) Output from the maintainer scripts:
   ...
   Setting up openjdk-7-doc (7u21-2.3.9-4) ...
   Setting up openjdk-7-jre-headless:amd64 (7u21-2.3.9-4) ...
   update-binfmts: warning: current package is openjdk-7, but binary format already installed by openjdk-6
   Setting up openjdk-7-jre-lib (7u21-2.3.9-4) ...
   Setting up openjdk-7-jre:amd64 (7u21-2.3.9-4) ...
   Setting up openjdk-7-demo (7u21-2.3.9-4) ...
   ...
   or
   ...
   Setting up librpmsign1 (4.10.3.1-1) ...
   Setting up rpm (4.10.3.1-1) ...
   Setting up man-db (2.6.3-5) ...
   Updating database of manual pages ...
   Setting up libgmpxx4ldbl:amd64 (2:5.1.1+dfsg-3) ...
   Setting up libppl12:amd64 (1:1.0-6) ...
   Setting up libppl-c4:amd64 (1:1.0-6) ...
   ...
2) config files changes
   Setting up libreoffice-style-tango (1:4.0.3-1) ...
   Setting up libreoffice-common (1:4.0.3-1) ...
   Installing new version of config file /etc/libreoffice/sofficerc ...
   Setting up libreoffice-java-common (1:4.0.3-1) ...
   Setting up libreoffice-base (1:4.0.3-1) ...
3) files that couldn't be created/removed/etc.
   Preparing to replace python2.7-minimal 2.7.3-8 (using .../python2.7-minimal_2.7.5-1_amd64.deb) ...
   Unpacking replacement python2.7-minimal ...
   dpkg: warning: unable to delete old directory '/etc/python2.7': Directory not empty
   Selecting previously unselected package libpython2.7-minimal.
   Unpacking libpython2.7-minimal (from .../libpython2.7-minimal_2.7.5-1_amd64.deb) ...
4) newly installed packages and package removals
  ...
  Selecting previously unselected package libxtables10.
  Unpacking libxtables10 (from .../libxtables10_1.4.18-1_amd64.deb) ...
  ...
  respectively
  ...
  Removing libprocps0:amd64 ...
  Purging configuration files for libprocps0:amd64 ...
  ...
  => Well in principle these are the same "boring" standard messages than those from upgrade,
     the difference is that (usually) there are far less packages removed/installed than
     upgraded. So it might be a good idea to allow thes lines be coloursed (at best via some
     configuration, whether or not)... maybe it's also good to just colourise the important
     words like "Removing" and/or "Purging" instead of the whole lines


So if that was ever implemented, I'd perhaps suggest the following general ideas:
- The "boring" output should be grey per default, with the more interesting parts of them
  (package names, version numbers - see above) some very similar grey (darker, lighter, bold or
  something like that).
- Output from the maintainer scripts to stdout, should be (per default) the default colour,
  i.e. not changing the colour of that at all. This is usefull, as that might be even already
  colourised.
- Output from the maintainer scripts to stderr should be red.
- Error ouput from dpkg (like (3) above) should be perhaps purple.
- Informational output like e.g. (2) above should perhaps be cyan.
- etc. pp..
- output that is not categorized should be considered "interesting" and get perhaps the colour
  orange (or I guess brown is the most similar colour on the console).


Cheers,
Chris.

Message #10 received at 708830@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 708830@bugs.debian.org

Subject: Re: dpkg: colourise dpkg output

Date: Sun, 19 May 2013 23:50:56 -0700

Hi,

Christoph Anton Mitterer wrote:

> - Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
>   Unpacking replacement foo ...
> - Setting up foo (2.0-1) ...
>
> but also the less oftem messages like:
> - (Reading database ... ?%
> - Processing triggers for ?
>
> Quite frankly, these are usually boring... as (usually) nothing interesting happens on
> them.

I wonder if this is a sign that dpkg is too noisy.  It's often hard to
see real warnings from maintainer scripts admid the normal dpkg noise.
Would it make sense to skip the "Unpacking" message, for example,
since it is not necessary for figuring out which maintainer script
produced a given message?

I also wonder if frontends have enough information to do the
coloration you're asking for without parsing output lines.  Can
frontends pass an argument to suppress messages that are redundant
next to information that was sent to the --status-fd?

Curious,
Jonathan

Message #15 received at 708830@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 708830@bugs.debian.org

Cc: Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#708830: dpkg: colourise dpkg output

Date: Mon, 20 May 2013 09:19:35 +0200

On Sun, 2013-05-19 at 23:50:56 -0700, Jonathan Nieder wrote:
> Christoph Anton Mitterer wrote:
> > - Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
> >   Unpacking replacement foo ...
> > - Setting up foo (2.0-1) ...
> >
> > but also the less oftem messages like:
> > - (Reading database ... ?%
> > - Processing triggers for ?
> >
> > Quite frankly, these are usually boring... as (usually) nothing interesting happens on
> > them.
> 
> I wonder if this is a sign that dpkg is too noisy.  It's often hard to
> see real warnings from maintainer scripts admid the normal dpkg noise.
> Would it make sense to skip the "Unpacking" message, for example,
> since it is not necessary for figuring out which maintainer script
> produced a given message?

I think there's already a request to add support for --quiet, which
would get rid of most of the point of this bug report.

> I also wonder if frontends have enough information to do the
> coloration you're asking for without parsing output lines.  Can
> frontends pass an argument to suppress messages that are redundant
> next to information that was sent to the --status-fd?

Hmm, perhaps with some smart interception. It would be easier to do it
from dpkg itself. Although if this is to be implemented it really does
will have very low priority. I'll have to think about it in any case.

Thanks,
Guillem

Message #20 received at 708830@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 708830@bugs.debian.org

Subject: Re: dpkg: colourise dpkg output

Date: Mon, 20 May 2013 16:27:52 +0200

[Message part 1 (text/plain, inline)]

On Sun, 2013-05-19 at 23:50 -0700, Jonathan Nieder wrote:
> I wonder if this is a sign that dpkg is too noisy.  It's often hard to
> see real warnings from maintainer scripts admid the normal dpkg noise.
Well... colourisation would be a good approach between --quiet and what
we have now...


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Send a report that this bug log contains spam.