Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #184791 > unrolled thread

disable orange progress running apt

Back to article view | Back to linux.debian.user

Contents

  disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-07 10:20 +0200
    Re: disable orange progress running apt <tomas@tuxteam.de> - 2017-08-07 10:30 +0200
      Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-07 10:50 +0200
        Re: disable orange progress running apt <tomas@tuxteam.de> - 2017-08-07 11:30 +0200
          Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-07 14:00 +0200
            Re: disable orange progress running apt <tomas@tuxteam.de> - 2017-08-07 15:10 +0200
              Re: disable orange progress running apt Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-07 15:20 +0200
                Re: disable orange progress running apt <tomas@tuxteam.de> - 2017-08-07 15:40 +0200
                Re: disable orange progress running apt Gene Heskett <gheskett@shentel.net> - 2017-08-07 17:20 +0200
                Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-08 01:40 +0200
    Re: disable orange progress running apt Darac Marjal <mailinglist@darac.org.uk> - 2017-08-07 12:30 +0200
      Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-07 14:10 +0200
        Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-07 14:40 +0200
          Re: disable orange progress running apt <tomas@tuxteam.de> - 2017-08-07 15:20 +0200
            Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-07 19:10 +0200
          Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-07 21:10 +0200
            Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-07 23:50 +0200
              Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-08 03:10 +0200
                Re: disable orange progress running apt Frank <zuiderduin@gmx.com> - 2017-08-08 10:40 +0200
                  Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-08 11:40 +0200
                    Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-08 15:00 +0200
                      Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-08 20:10 +0200
                        Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-09 19:20 +0200
                          Re: disable orange progress running apt Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-09 19:30 +0200
                            Re: disable orange progress running apt Brian <ad44@cityscape.co.uk> - 2017-08-09 20:40 +0200
        Re: disable orange progress running apt Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-07 14:50 +0200
          Re: disable orange progress running apt Gene Heskett <gheskett@shentel.net> - 2017-08-07 17:10 +0200
            Re: disable orange progress running apt Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-07 17:30 +0200
              Re: disable orange progress running apt Gene Heskett <gheskett@shentel.net> - 2017-08-07 22:20 +0200
                Re: disable orange progress running apt Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-07 22:30 +0200
              Re: disable orange progress running apt Erik Christiansen <dvalin@internode.on.net> - 2017-08-08 08:00 +0200
        Re: disable orange progress running apt Curt <curty@free.fr> - 2017-08-08 10:20 +0200
          Re: disable orange progress running apt Felix Miata <mrmazda@earthlink.net> - 2017-08-08 12:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#184891

On Tue 08 Aug 2017 at 05:32:04 -0400, Felix Miata wrote:

> Frank composed on 2017-08-08 10:31 (UTC+0200):
> 
> > Felix Miata composed:
> 
> >> Brian composed on 2017-08-07 33:42 (UTC+0100):
> 
> >>> Of course they work. They just do not fit your purpose.
> 
> >> Work how? Do what? How do I find evidence that either actually do anything? So
> >> far all I've seen is that you've said so, here, & earlier, 2017-08-07 18:03
> >> (UTC+0100):
> 
> > It's possible some configuration file already has a line which sets 
> > Dpkg::Progress-Fancy and/or Dpkg::Progress-Fancy::Progress-Bg. Did you 
> > check the files in /etc/apt/apt.conf.d? 
> 
> Yes, then I created a new file there just to install Brian's suggestion, and
> after it failed the other permutations I tried.

Apologies. I missed off a ";" when translating the changelog entry to
be used in your 99mono file. Also Progress-Fancy turns out to be not
what you want.

"-o Apt::Color=0" works for me not to see the orange colour in stable
and unstable. In a file it works on stable but not on unstable. There
seems to be a bug here.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184904

Brian composed on 2017-08-08 13:49 (UTC+0100):

> Apologies. I missed off a ";" when translating the changelog entry to
> be used in your 99mono file. Also Progress-Fancy turns out to be not
> what you want.

> "-o Apt::Color=0" works for me not to see the orange colour in stable
> and unstable. In a file it works on stable but not on unstable. There
> seems to be a bug here.

Success in Stretch using

	Apt::Color "false";

:-D

>From what documentation did Curt and you determine Apt::Color was the solution?
Google turns up "Apt::Color "false";" or "Apt::Color 0" nowhere except in this
thread's archive.

Thanks to all who responded!
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#184945

On Tue 08 Aug 2017 at 14:05:10 -0400, Felix Miata wrote:

> Brian composed on 2017-08-08 13:49 (UTC+0100):
> 
> > Apologies. I missed off a ";" when translating the changelog entry to
> > be used in your 99mono file. Also Progress-Fancy turns out to be not
> > what you want.
> 
> > "-o Apt::Color=0" works for me not to see the orange colour in stable
> > and unstable. In a file it works on stable but not on unstable. There
> > seems to be a bug here.
> 
> Success in Stretch using
> 
> 	Apt::Color "false";
> 
> :-D
> 
> >From what documentation did Curt and you determine Apt::Color was the solution?
> Google turns up "Apt::Color "false";" or "Apt::Color 0" nowhere except in this
> thread's archive.

For me - configure-index.gz.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184946

On Wed, Aug 09, 2017 at 06:12:31PM +0100, Brian wrote:
> On Tue 08 Aug 2017 at 14:05:10 -0400, Felix Miata wrote:
> > >From what documentation did Curt and you determine Apt::Color was the solution?
> > Google turns up "Apt::Color "false";" or "Apt::Color 0" nowhere except in this
> > thread's archive.
> 
> For me - configure-index.gz.

It's not there in stretch.

wooledg:~$ cat /etc/debian_version 
9.1
wooledg:~$ zgrep -i color /usr/share/doc/apt/examples/configure-index.gz 
apt::moo::color "<BOOL>";
apt::color::highlight "<STRING>";
apt::color::neutral "<STRING>";

[toc] | [prev] | [next] | [standalone]

#184952

On Wed 09 Aug 2017 at 13:20:26 -0400, Greg Wooledge wrote:

> On Wed, Aug 09, 2017 at 06:12:31PM +0100, Brian wrote:
> > On Tue 08 Aug 2017 at 14:05:10 -0400, Felix Miata wrote:
> > > >From what documentation did Curt and you determine Apt::Color was the solution?
> > > Google turns up "Apt::Color "false";" or "Apt::Color 0" nowhere except in this
> > > thread's archive.
> > 
> > For me - configure-index.gz.
> 
> It's not there in stretch.
> 
> wooledg:~$ cat /etc/debian_version 
> 9.1
> wooledg:~$ zgrep -i color /usr/share/doc/apt/examples/configure-index.gz 
> apt::moo::color "<BOOL>";
> apt::color::highlight "<STRING>";
> apt::color::neutral "<STRING>";

I did what Debian users are renowned for - used my initiative and
guessed. A more competent person would have read the source code.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184806

On Mon, Aug 07, 2017 at 08:05:28AM -0400, Felix Miata wrote:
> Could this somehow be coming from bash rather than apt?

Nope.

Also while I'm here: the garish colors of apt(8) are not the #1 reason
I switched back to apt-get(8), but they are #2.  Whoever chose the colors
clearly doesn't use a terminal with a white background, because yellow
on white is simply unreadable.

[toc] | [prev] | [next] | [standalone]

#184813

On Monday 07 August 2017 08:39:46 Greg Wooledge wrote:

> On Mon, Aug 07, 2017 at 08:05:28AM -0400, Felix Miata wrote:
> > Could this somehow be coming from bash rather than apt?
>
> Nope.
>
> Also while I'm here: the garish colors of apt(8) are not the #1 reason
> I switched back to apt-get(8), but they are #2.  Whoever chose the
> colors clearly doesn't use a terminal with a white background, because
> yellow on white is simply unreadable.

That seems odd, and would tend to make me think of using the educational 
club.

The only machine I have that uses apt as default, is a raspi running 
jessie, and its happy as a clam, either on its full 16 bit color 
framebuffer screen, or on a logged in terminal-4.8 here.

I would first check your "env" output to see if that might be a source of 
odd colors in X. If so, a global grep for the observed string(s) might 
provide a clue for where a color value is miss-set.

The above example machines "env" output contains this:
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:

as a single 1433 byte string that your email agent my line wrap, it is 
not here as I send this. There, sometimes only 2 bytes are used to spec 
a color, but I've no clue how to decode the above as I haven't had to 
look into it. Just scanning the above, it looks to be a way of coloring 
a files name in an ls listing, coloring it by its name extension. And 
the colors are 4 bit, which explains why some apps look washed out on 
the raspi's screen. But thats about all I can determine or infer from 
the above.

Colors are often presented as a 24 bit hex string 2 nibbles per color so 
each can have 256 values in terms of it brightness, with the format 
being name of color=RRGGBB with each nibble haveing a value ranging from 
0 to F, so full brightness red s/b FF0000, green 00FF00, etc.  Yellow 
would be something close to FFFF00 for instance.

No clue if this is helpfull but it's at the basics of how most of this 
stuff works.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#184816

On Mon, Aug 07, 2017 at 11:02:10AM -0400, Gene Heskett wrote:
> On Monday 07 August 2017 08:39:46 Greg Wooledge wrote:
> > Also while I'm here: the garish colors of apt(8) are not the #1 reason
> > I switched back to apt-get(8), but they are #2.  Whoever chose the
> > colors clearly doesn't use a terminal with a white background, because
> > yellow on white is simply unreadable.
> 
> That seems odd, and would tend to make me think of using the educational 
> club.

I don't understand; what part seems odd?  My use of terminals with
white backgrounds?  That's fair.  Most Linux kids these days seem to
prefer black backgrounds.

Or do you dispute the fact that apt uses yellow foreground text when
you do "apt update"?

In TERM=rxvt-unicode, apt uses the escape sequence ESC[33m to produce
yellow text.  I just captured it using "script" and verified this.
This is slightly different from the ESC[38;5;3m that "tput setaf 3"
uses, but they both give me yellow fg text when tested interactively.

> The only machine I have that uses apt as default, is a raspi running 
> jessie, and its happy as a clam, either on its full 16 bit color 
> framebuffer screen, or on a logged in terminal-4.8 here.

The Linux virtual console has a black background by default.
Rxvt has white.  Xterm also used to have a white background, but Debian
seems to have changed that at some point.  (xterm(1) still speaks of
"the X defaults (black text on a white background)" but only in a general
sense.)

> LS_COLORS=rs=0:di=01;34:[...]

Are you suggesting that apt(8) uses LS_COLORS?  That would surprise me.
It's most defintely not in the man page.  Then again, the word "color"
is nowhere in that man page.

It would also surprise me, because LS_COLORS tells ls(1) how to use
colors based on file types and extensions, which are not something that
apt(8) deals with.  apt deals with package names, package descriptions,
retrievals and retrieval failures, etc.

[toc] | [prev] | [next] | [standalone]

#184849

On Monday 07 August 2017 11:26:16 Greg Wooledge wrote:

> On Mon, Aug 07, 2017 at 11:02:10AM -0400, Gene Heskett wrote:
> > On Monday 07 August 2017 08:39:46 Greg Wooledge wrote:
> > > Also while I'm here: the garish colors of apt(8) are not the #1
> > > reason I switched back to apt-get(8), but they are #2.  Whoever
> > > chose the colors clearly doesn't use a terminal with a white
> > > background, because yellow on white is simply unreadable.
> >
> > That seems odd, and would tend to make me think of using the
> > educational club.
>
> I don't understand; what part seems odd?  My use of terminals with
> white backgrounds?  That's fair.  Most Linux kids these days seem to
> prefer black backgrounds.
>
As do I, but at 82 and counting, I am hardly a kid. ;-)

> Or do you dispute the fact that apt uses yellow foreground text when
> you do "apt update"?

I see the link namestring and path in a medium red while its fetching the 
lists, but there is nothing to update ATM, and for me, the most 
important site, buildbot.linuxcnc.org has been down since Saturday,so 
everything else is in medium white.  And I don't recall ever seeing 
anything with yellow characters on that screen.

About time to email Sebastion and advise him the buildbot seems to have 
crashed, I can't even ping it.

> In TERM=rxvt-unicode, apt uses the escape sequence ESC[33m to produce
> yellow text.  I just captured it using "script" and verified this.
> This is slightly different from the ESC[38;5;3m that "tput setaf 3"
> uses, but they both give me yellow fg text when tested interactively.
>
> > The only machine I have that uses apt as default, is a raspi running
> > jessie, and its happy as a clam, either on its full 16 bit color
> > framebuffer screen, or on a logged in terminal-4.8 here.
>
> The Linux virtual console has a black background by default.
> Rxvt has white.  Xterm also used to have a white background, but
> Debian seems to have changed that at some point.  (xterm(1) still
> speaks of "the X defaults (black text on a white background)" but only
> in a general sense.)
>
> > LS_COLORS=rs=0:di=01;34:[...]
>
> Are you suggesting that apt(8) uses LS_COLORS?  That would surprise
> me. It's most defintely not in the man page.  Then again, the word
> "color" is nowhere in that man page.
>
> It would also surprise me, because LS_COLORS tells ls(1) how to use
> colors based on file types and extensions, which are not something
> that apt(8) deals with.  apt deals with package names, package
> descriptions, retrievals and retrieval failures, etc.

I do not believe that apt controls the colors, that is all in the 
processing of the text as its being rendered for display in your native 
language. So it could very well be using LS_COLORS. Doing an "env|
grep .deb" shows that a .deb filename is colored by 
*.tz=01;31:*.deb=01;31:*.rpm=01;31, so are many of the common package 
extensions, which is why I included the ones on either side of 
the '*.deb=' as an example above, but it looks like most if not all of 
the common package names where the files are compressed by any 
compressor, are also colored the same.

I of course don't know that for a fact, but all the clues seem to point 
to that conclusion. However, I have grepped that system without finding 
LS_COLORS. Something is setting that as an env variable, but I cannot 
find it.  There is a /usr/bin/dircolors but its a binary, and more than 
dircolors is being set in the env.

So I've failed, again.  Oldtimers?  Or have I? An hour later, take a look 
at /home/$usr/.themes/PiX/GTK-3.0/README.  I have a headache trying to 
figure it out, but I have a gut feeling it could be related to the 
LS_COLORS env variable.  The PiX part of the path might be different if 
your is not a pi of course.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#184852

On Mon, Aug 07, 2017 at 04:14:28PM -0400, Gene Heskett wrote:
> On Monday 07 August 2017 11:26:16 Greg Wooledge wrote:
> > Or do you dispute the fact that apt uses yellow foreground text when
> > you do "apt update"?
> 
> I see the link namestring and path in a medium red while its fetching the 
> lists

Just checked on the Linux console, and tput setaf 3 gives me a color
that might be described as orange, or red-orange.  I'm not really a
color guy.

tput setaf 3 on rxvt-unicode (with default settings) gives a bright
yellow.  I've actually configured it with

wooledg:~$ cat .Xresources
Rxvt*color3:		goldenrod

which is still somewhat hard to read, but not as bad as yellow-on-white.

> > Are you suggesting that apt(8) uses LS_COLORS?

> I do not believe that apt controls the colors, that is all in the 
> processing of the text as its being rendered for display in your native 
> language.

No, apt definitely chooses the colors, by sending escape sequences to
the terminal.  In this case, it sends the escape sequence for "color 3"
as defined in the terminfo database for each terminal type.  On the
Linux console in Debian 9 amd64, this is a dark orange or red-orange
of some kind.  In rxvt-unicode with defaults, this is yellow.

It's not affected by locale settings, but it may be affected by terminal
settings.

> So it could very well be using LS_COLORS.

If you don't believe me, you can unset that variable and see if it makes
apt change behavior.

Of course, we need to wait for there to be new lists to process, unless
you're also willing to remove your cached package lists to make it have
something to download.

> So I've failed, again.  Oldtimers?  Or have I? An hour later, take a look 
> at /home/$usr/.themes/PiX/GTK-3.0/README.  I have a headache trying to 
> figure it out, but I have a gut feeling it could be related to the 
> LS_COLORS env variable.  The PiX part of the path might be different if 
> your is not a pi of course.

apt is not linked against libgtk.  GTK is a graphical widget library
used by GNOME and web browsers and other applications of that kind.

[toc] | [prev] | [next] | [standalone]

#184869

On 07.08.17 11:26, Greg Wooledge wrote:
> I don't understand; what part seems odd?  My use of terminals with
> white backgrounds?  That's fair.  Most Linux kids these days seem to
> prefer black backgrounds.

For the last 30 odd years I've used yellow and green on DarkSlateGrey
for everything I can, across hp-ux/solaris/linux platforms. It is a balm
for eyes which begin to hurt after an hour or two of the glare of a
white background.

> Or do you dispute the fact that apt uses yellow foreground text when
> you do "apt update"?

That'd work fine with DarkSlateGrey. ;-)

OK, that's DarkSlateGray in hew-hess-hay, but it's in /etc/X11/rgb.txt too.

Erik

[toc] | [prev] | [next] | [standalone]

#184874

On 2017-08-07, Felix Miata <mrmazda@earthlink.net> wrote:
>
>> Try "APT::Color "false";".
> That was the last I tried with Stretch before giving up and posting here, in
> /etc/apt/apt.conf.d/99mono. Also fails in Sid.
>
> Could this somehow be coming from bash rather than apt?

Did you try first at the command line?

 apt update -o Apt::Color=0

I suppose if that worked you could create an alias until someone figures
out where and how to put it.

-- 
“Certitude is not the test of certainty.”
--Oliver Wendell Holmes, Jr.

[toc] | [prev] | [next] | [standalone]

#184880

Curt composed on 2017-08-08 08:17 (UTC):

> On 2017-08-07, Felix Miata wrote:

>>> Try "APT::Color "false";".
>> That was the last I tried with Stretch before giving up and posting here, in
>> /etc/apt/apt.conf.d/99mono. Also fails in Sid.

>> Could this somehow be coming from bash rather than apt?

> Did you try first at the command line? 

No.

>  apt update -o Apt::Color=0 

It works!

> I suppose if that worked you could create an alias until someone figures
> out where and how to put it.

It might if I didn't have so many different installations scattered about and
multiple aliases to create. Better to suffer horri-colors until an Apt config
that works can be found.

In openSUSE we have Zypper as wrapper around rpm more or less the way apt works
with dpkg. Color on/off in Zypper is easy to deal with because of integrated
comments that work so much better than virtually empty config directories, e.g.:

...
## Whether to use colors
##
## Valid values: always, never, or autodetect
## Default value: autodetect
##
 useColors = never
...
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web