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

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

Buster => Bullseye: packages kept back

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

Contents

  Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 11:20 +0200
    Re: Buster => Bullseye: packages kept back Jeffrey Walton <noloader@gmail.com> - 2023-03-26 11:30 +0200
    Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-26 13:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 15:00 +0200
        Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-27 11:10 +0200
          Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 11:30 +0200
            Re: Buster => Bullseye: packages kept back David Wright <deblis@lionunicorn.co.uk> - 2023-03-27 16:50 +0200
            Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-28 11:00 +0200
              Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-28 12:30 +0200
          Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 16:50 +0200
    Re: Buster => Bullseye: packages kept back Cindy Sue Causey <butterflybytes@gmail.com> - 2023-03-26 17:40 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 19:30 +0200
    Re: Buster => Bullseye: packages kept back David Wright <deblis@lionunicorn.co.uk> - 2023-03-26 20:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 00:30 +0200
    Re: Buster => Bullseye: packages kept back Jeffrey Walton <noloader@gmail.com> - 2023-03-26 23:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 00:30 +0200
        Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-03-27 13:30 +0200
          Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 13:50 +0200
            Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-03-27 14:20 +0200
              Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 14:30 +0200
            Re: Buster => Bullseye: packages kept back Dan Ritter <dsr@randomstring.org> - 2023-03-27 15:10 +0200
              Re: Buster => Bullseye: packages kept back Nicolas George <george@nsup.org> - 2023-03-27 15:20 +0200
                Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-27 16:10 +0200
                  Re: Buster => Bullseye: packages kept back <tomas@tuxteam.de> - 2023-03-27 17:40 +0200
                    Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-27 20:10 +0200
                      Re: Buster => Bullseye: packages kept back <tomas@tuxteam.de> - 2023-03-28 07:10 +0200
                        Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-28 17:10 +0200
                  alternative views of PNG (was Re: Buster => Bullseye: packages kept  back) davidson <davidson@freevolt.org> - 2023-03-28 13:00 +0200
                    Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) gene heskett <gheskett@shentel.net> - 2023-03-28 17:40 +0200
                    Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) gene heskett <gheskett@shentel.net> - 2023-03-28 18:50 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) <tomas@tuxteam.de> - 2023-03-28 20:00 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) <tomas@tuxteam.de> - 2023-03-28 20:00 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) davidson <davidson@freevolt.org> - 2023-03-29 09:30 +0200
                Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-04-03 13:50 +0200
              Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 16:10 +0200
                Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-28 08:30 +0200
                  apt colored output (was Re: Buster => Bullseye: packages kept  back) davidson <davidson@freevolt.org> - 2023-04-03 08:00 +0200
        Re: Buster => Bullseye: packages kept back Anssi Saari <as@sci.fi> - 2023-03-28 11:30 +0200

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

#256416

Greg Wooledge wrote: 
> >From an end user's point of view, the three main differences between
> "apt-get" and "apt" are:
> 
> 3) apt uses a horrible yellow color that is nigh-unreadable on a white
>    background.  (This is not configurable.)

It appears that it is, just badly documented.

In /etc/apt/apt.conf, you can specify the escape sequences for
colors like this:

APT::Color::Yellow "ESC[33m";


changing 33 to 30 will get you black. ANSI color escapes are on
the web in many places.

-dsr-

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

#256417

Dan Ritter (12023-03-27):
> changing 33 to 30 will get you black. ANSI color escapes are on
> the web in many places.

Also, decent terminal emulators let users tweak the colors, and making
sure all main colors are readable on the default background would
probably be a good use of that ability.

Regards,

-- 
  Nicolas George

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

#256419

On 3/27/23 09:18, Nicolas George wrote:
> Dan Ritter (12023-03-27):
>> changing 33 to 30 will get you black. ANSI color escapes are on
>> the web in many places.
> 
> Also, decent terminal emulators let users tweak the colors, and making
> sure all main colors are readable on the default background would
> probably be a good use of that ability.
> 
> Regards,
> 
This is a sore point with something I'm fighting with. Chinese 
electronics makers are in the habit of publishing .pngs of their 
products, with the most valuable info one needs to properly hook it up, 
in a putrid yellow on a white background.

Would it be practical to put a filter in the path cups put things headed 
to a printer thru, to change just that esc sequence to make those boxes 
and their text content into something more readable.

For an example of such an unhelpful document, find a copy of 
"MKS-Robin-Nano-V3.X-main.zip", unpack it, cd to Image-V3, and look at 
"MKS_Robin_Nano_V3_PIN.png" on-screen or better yet print it.

I rest my case. Take care and stay well all.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

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

#256423

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 27, 2023 at 10:00:48AM -0400, gene heskett wrote:

[...]

> Would it be practical to put a filter in the path cups put things headed to
> a printer thru, to change just that esc sequence to make those boxes and
> their text content into something more readable.

If they are actually PNGs you'll be out of luck with esc sequences.
You might get away by fumbling the image's palette (if it has one)
or postprocessing it with your favourite image manipulation program
(with enough dedication you even might come up with some ImageMagick
script to automate this).

Or you could try to shuffle the ink tanks of your printer ;-D

Cheers
-- 
t

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

#256427

On 3/27/23 11:31, tomas@tuxteam.de wrote:
> On Mon, Mar 27, 2023 at 10:00:48AM -0400, gene heskett wrote:
> 
> [...]
> 
>> Would it be practical to put a filter in the path cups put things headed to
>> a printer thru, to change just that esc sequence to make those boxes and
>> their text content into something more readable.
> 
> If they are actually PNGs you'll be out of luck with esc sequences.
> You might get away by fumbling the image's palette (if it has one)
> or postprocessing it with your favourite image manipulation program
> (with enough dedication you even might come up with some ImageMagick
> script to automate this).
> 
Begs the question, do we have a gfx editor that can do that? Fix it 
once, at the src. I'd be in hog heaven!

> Or you could try to shuffle the ink tanks of your printer ;-D
> 
> Cheers

Shirley you jest Tomas. ;o)>

How much good would that do when there is half an hours ink in the 
plumbing it would have to flush to even get the new color into the 
nozzles? My ink squirter is a brother MFC-J6920-DW, probably a foot or 
more of hose between the tank sockets on the right front, and the actual 
printhead. Even the heads motion is odd, scanning normal letter paper 
sideways. It is monster sized, able to take tabloid sized paper even in 
its scanner, but is a pita to feed it straight by hand for printing thru 
a slot it the rear. I made a feed tray cuz I do use the big paper when 
printing rockhopper's output. Its output is the logic diagram of the hal 
mapping of a linuxcnc driven machine, converted to .svg, and may take 
quite a few sheets, pasted/taped together on a 4x8 foot sheet of plywood 
paneling to display it big enough to read. .svg is truly capable of fine 
detail. And this printer is able to do legible text at microscopic scales.

Thanks for the grin, take care & stay well Tomas.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

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

#256454

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 27, 2023 at 02:02:43PM -0400, gene heskett wrote:
> On 3/27/23 11:31, tomas@tuxteam.de wrote:
> > On Mon, Mar 27, 2023 at 10:00:48AM -0400, gene heskett wrote:
> > 
> > [...]
> > 
> > > Would it be practical to put a filter in the path cups put things headed to
> > > a printer thru, to change just that esc sequence to make those boxes and
> > > their text content into something more readable.
> > 
> > If they are actually PNGs you'll be out of luck with esc sequences.
> > You might get away by fumbling the image's palette (if it has one)
> > or postprocessing it with your favourite image manipulation program
> > (with enough dedication you even might come up with some ImageMagick
> > script to automate this).
> > 
> Begs the question, do we have a gfx editor that can do that? Fix it once, at
> the src. I'd be in hog heaven!

You mean at Alibaba? Or in your copies of the images?

In the second case, I'd recommend Gimp if you are more
the clickey type or the ImageMagick suite (specifically
convert) if you are up to figuring out a script which
might do it automatically for you henceforth.

> > Or you could try to shuffle the ink tanks of your printer ;-D
> > 
> > Cheers
> 
> Shirley you jest Tomas. ;o)>

;-)

> How much good would that do when there is half an hours ink in the plumbing
> it would have to flush to even get the new color into the nozzles? [...]

Sounds a bit like my shower. Except that most of the time the stuff
coming out of it is colourless. Luckily.

> Thanks for the grin, take care & stay well Tomas.

Likewise, cheers
-- 
t

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

#256474

On 3/28/23 01:02, tomas@tuxteam.de wrote:
> On Mon, Mar 27, 2023 at 02:02:43PM -0400, gene heskett wrote:
>> On 3/27/23 11:31, tomas@tuxteam.de wrote:
>>> On Mon, Mar 27, 2023 at 10:00:48AM -0400, gene heskett wrote:
>>>
>>> [...]
>>>
>>>> Would it be practical to put a filter in the path cups put things headed to
>>>> a printer thru, to change just that esc sequence to make those boxes and
>>>> their text content into something more readable.
>>>
>>> If they are actually PNGs you'll be out of luck with esc sequences.
>>> You might get away by fumbling the image's palette (if it has one)
>>> or postprocessing it with your favourite image manipulation program
>>> (with enough dedication you even might come up with some ImageMagick
>>> script to automate this).
>>>
>> Begs the question, do we have a gfx editor that can do that? Fix it once, at
>> the src. I'd be in hog heaven!
> 
> You mean at Alibaba? Or in your copies of the images?
> 
In my copies stored here, alibaba likely has a reason for their choice, 
made no doubt by the 7 figure legal people.  Cheating on the gpl while 
appearing to meet the terms.

> In the second case, I'd recommend Gimp if you are more
> the clickey type or the ImageMagick suite (specifically
> convert) if you are up to figuring out a script which
> might do it automatically for you henceforth.
> 
That would be a likeable, usable solution.  As for gimp, I use it mainly 
to squeeze pix, making a 20 meg pix out of my canon camera into 
something I can email at sub 300k.  Expert, not in your wildest dreams...

Take care and stay well Tomas.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

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

#256465 — alternative views of PNG (was Re: Buster => Bullseye: packages kept back)

On Mon, 27 Mar 2023 gene heskett wrote:
> On 3/27/23 09:18, Nicolas George wrote:
>> Dan Ritter (12023-03-27):
>>> changing 33 to 30 will get you black. ANSI color escapes are on
>>> the web in many places.
>> 
>> Also, decent terminal emulators let users tweak the colors, and making
>> sure all main colors are readable on the default background would
>> probably be a good use of that ability.
>> 
>> Regards,
>> 
> This is a sore point with something I'm fighting with. Chinese electronics 
> makers are in the habit of publishing .pngs of their products, with the most 
> valuable info one needs to properly hook it up, in a putrid yellow on a white 
> background.
>
> Would it be practical to put a filter in the path cups put things headed to a 
> printer thru, to change just that esc sequence to make those boxes and their 
> text content into something more readable.
>
> For an example of such an unhelpful document, find a copy of 
> "MKS-Robin-Nano-V3.X-main.zip", unpack it, cd to Image-V3, and look at 
> "MKS_Robin_Nano_V3_PIN.png" on-screen or better yet print it.

Like this?

  https://raw.githubusercontent.com/makerbase-mks/MKS-Robin-Nano-V3.X/main/hardware/Image-V3/MKS_Robin_Nano_V3_PIN.png

I can't help you with the printing.

I use xli to view images. I like it primarily because it requires no mouse.

It also has a lot of command line options that I don't understand, but
they are fun to play with.

  $ xli MKS_Robin_Nano_V3_PIN.png # I see what Gene complains about

  $ xli -gamma 7 MKS_Robin_Nano_V3_PIN.png # Colors appear much darker

  $ xli -gray  MKS_Robin_Nano_V3_PIN.png # Yellow is now gray. Lighter content is too light

  $ xli -gray -gamma 5  MKS_Robin_Nano_V3_PIN.png # Yellow is still gray. But\
                                                    Lighter content is more legible

  $ xli -colors 2 MKS_Robin_Nano_V3_PIN.png # Only ONE shade of gray (obscures some info)

-- 
We might not find the sun, but I don't mind
We've got to look for things that we may never find
-- The Bats, Just for the Ride

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

#256478 — Re: alternative views of PNG (was Re: Buster => Bullseye: packages keptback)

On 3/28/23 06:53, davidson wrote:
> On Mon, 27 Mar 2023 gene heskett wrote:
>> On 3/27/23 09:18, Nicolas George wrote:
>>> Dan Ritter (12023-03-27):
>>>> changing 33 to 30 will get you black. ANSI color escapes are on
>>>> the web in many places.
>>>
>>> Also, decent terminal emulators let users tweak the colors, and making
>>> sure all main colors are readable on the default background would
>>> probably be a good use of that ability.
>>>
>>> Regards,
>>>
>> This is a sore point with something I'm fighting with. Chinese 
>> electronics makers are in the habit of publishing .pngs of their 
>> products, with the most valuable info one needs to properly hook it 
>> up, in a putrid yellow on a white background.
>>
>> Would it be practical to put a filter in the path cups put things 
>> headed to a printer thru, to change just that esc sequence to make 
>> those boxes and their text content into something more readable.
>>
>> For an example of such an unhelpful document, find a copy of 
>> "MKS-Robin-Nano-V3.X-main.zip", unpack it, cd to Image-V3, and look at 
>> "MKS_Robin_Nano_V3_PIN.png" on-screen or better yet print it.
> 
> Like this?
> 
>   https://raw.githubusercontent.com/makerbase-mks/MKS-Robin-Nano-V3.X/main/hardware/Image-V3/MKS_Robin_Nano_V3_PIN.png
> 
> I can't help you with the printing.
> 
> I use xli to view images. I like it primarily because it requires no mouse.
> 
> It also has a lot of command line options that I don't understand, but
> they are fun to play with.
> 
>   $ xli MKS_Robin_Nano_V3_PIN.png # I see what Gene complains about
> 
>   $ xli -gamma 7 MKS_Robin_Nano_V3_PIN.png # Colors appear much darker
> 
>   $ xli -gray  MKS_Robin_Nano_V3_PIN.png # Yellow is now gray. Lighter 
> content is too light
> 
>   $ xli -gray -gamma 5  MKS_Robin_Nano_V3_PIN.png # Yellow is still 
> gray. But\
>                                                     Lighter content is 
> more legible
> 
>   $ xli -colors 2 MKS_Robin_Nano_V3_PIN.png # Only ONE shade of gray 
> (obscures some info)

xli -gamma 5  MKS_Robin_Nano_V3_PIN.png shows me a much more readable 
image, how do I make it save that version? Can it pipe to a new, 
modified file?

Thanks.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

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

#256481 — Re: alternative views of PNG (was Re: Buster => Bullseye: packages keptback)

On 3/28/23 06:53, davidson wrote:
> On Mon, 27 Mar 2023 gene heskett wrote:
>> On 3/27/23 09:18, Nicolas George wrote:
>>> Dan Ritter (12023-03-27):
>>>> changing 33 to 30 will get you black. ANSI color escapes are on
>>>> the web in many places.
>>>
>>> Also, decent terminal emulators let users tweak the colors, and making
>>> sure all main colors are readable on the default background would
>>> probably be a good use of that ability.
>>>
>>> Regards,
>>>
>> This is a sore point with something I'm fighting with. Chinese 
>> electronics makers are in the habit of publishing .pngs of their 
>> products, with the most valuable info one needs to properly hook it 
>> up, in a putrid yellow on a white background.
>>
>> Would it be practical to put a filter in the path cups put things 
>> headed to a printer thru, to change just that esc sequence to make 
>> those boxes and their text content into something more readable.
>>
>> For an example of such an unhelpful document, find a copy of 
>> "MKS-Robin-Nano-V3.X-main.zip", unpack it, cd to Image-V3, and look at 
>> "MKS_Robin_Nano_V3_PIN.png" on-screen or better yet print it.
> 
> Like this?
> 
>   https://raw.githubusercontent.com/makerbase-mks/MKS-Robin-Nano-V3.X/main/hardware/Image-V3/MKS_Robin_Nano_V3_PIN.png
> 
> I can't help you with the printing.
> 
I installed xli, works great, and is fast, but apparently has no output 
redirection ability. I made several 0 length files trying.

gimp could probably do it, but I get lost in endless menu's.

imagemagick won't run from the cli, from the pulldowns, its file 
selector is not controllable to navigate to the file.  Trying to wade 
thru home/src/MKS_nano_v3_main/hardware/Images-V3/ to that file was a 
hopeless waste of time.  Any attempt to scroll thru the presented very 
busy file list with the mouse wheel was always interpreted as load the 
first file.  IOW its file selector is busted afaiac.

libreoffice loaded it, replaced the putrid yellow with black, and then 
printed me a copy on photo paper, a copy I can actually read!

Mark it problem solved.

Thanks to all who responded.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

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

#256483 — Re: alternative views of PNG (was Re: Buster => Bullseye: packages keptback)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 28, 2023 at 07:54:07PM +0200, tomas wrote:

> [...] It has an extensive man page. Here [1] [2] you might
> draw some inspiration on what you can do.

Gah. Forgot the links:

[1] https://www.imagemagick.org/Usage/color_mods/#level-colors
[2] https://www.imagemagick.org/Usage/color_basics/#replace

Cheers
-- 
t

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

#256484 — Re: alternative views of PNG (was Re: Buster => Bullseye: packages keptback)

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 28, 2023 at 12:48:48PM -0400, gene heskett wrote:

[...]

> gimp could probably do it, but I get lost in endless menu's.

You can batch gimp and then use one of its embedded languages
(script-fu, python, there might be more). But I never tried.
> 
> imagemagick won't run from the cli, from the pulldowns, its file selector is
> not controllable to navigate to the file [...]

The CLI image "transformer" of the ImageMagick suite is called
"convert". It has an extensive man page. Here [1] [2] you might
draw some inspiration on what you can do.

> libreoffice loaded it, replaced the putrid yellow with black, and then
> printed me a copy on photo paper, a copy I can actually read!
> 
> Mark it problem solved.

Nice if it floats your boat. The upside of Magick is that once
you've figured out the magic (heh) incantation, it's hands-off.

I'm kinda a lazy guy.

Cheers
-- 
t

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

#256503 — Re: alternative views of PNG (was Re: Buster => Bullseye: packages keptback)

[Multipart message — attachments visible in raw view] — view raw

On Tue, 28 Mar 2023 gene heskett wrote:
> On 3/28/23 06:53, davidson wrote:
>> On Mon, 27 Mar 2023 gene heskett wrote:
>>> On 3/27/23 09:18, Nicolas George wrote:
>>>> Dan Ritter (12023-03-27):
[Dan suggests googling ANSI color escapes]
>>>>> changing 33 to 30 will get you black. ANSI color escapes are on
>>>>> the web in many places.
[Nicolas touts the benefits of readable terminal colors]
>>>> Also, decent terminal emulators let users tweak the colors, and making
>>>> sure all main colors are readable on the default background would
>>>> probably be a good use of that ability.
[Gene curses poorly contrasting colors in documentary illustrations]
>>> This is a sore point with something I'm fighting with. Chinese electronics 
>>> makers are in the habit of publishing .pngs of their products, with the 
>>> most valuable info one needs to properly hook it up, in a putrid yellow on 
>>> a white background.
[Gene contemplates an alchemical solution]
>>> Would it be practical to put a filter in the path cups put things headed 
>>> to a printer thru, to change just that esc sequence to make those boxes 
>>> and their text content into something more readable.
>>> 
>>> For an example of such an unhelpful document, find a copy of 
>>> "MKS-Robin-Nano-V3.X-main.zip", unpack it, cd to Image-V3, and look at 
>>> "MKS_Robin_Nano_V3_PIN.png" on-screen or better yet print it.
>> 
>> Like this?
>>
>>   https://raw.githubusercontent.com/makerbase-mks/MKS-Robin-Nano-V3.X/main/hardware/Image-V3/MKS_Robin_Nano_V3_PIN.png
>> 
>> I can't help you with the printing.
>> 
> I installed xli, works great, and is fast, but apparently has no output 
> redirection ability. I made several 0 length files trying.

The netpbm package contains, among other things, routines "pngtopnm"
and "pnmtopng" which do produce standard output that can be redirected
to a file:

  $ pngtopnm -gamma 0.45 RobinNano.png | pnmtopng -gamma 0.45 > RobinNano_darker.png

Took a while, and a few detours, for me to remember this. But I
believe it will write you a more legible png.

> gimp could probably do it, but I get lost in endless menu's.

If I wrote an essay about the undignified interfaces I have no time
for, I would call it "Of Mice and Menus".

> imagemagick won't run from the cli, from the pulldowns, its file
> selector is not controllable to navigate to the file.  Trying to
> wade thru home/src/MKS_nano_v3_main/hardware/Images-V3/ to that file
> was a hopeless waste of time.  Any attempt to scroll thru the
> presented very busy file list with the mouse wheel was always
> interpreted as load the first file.  IOW its file selector is busted
> afaiac.

Who needs an essay? You see what I mean already.

> libreoffice loaded it, replaced the putrid yellow with black, and
> then printed me a copy on photo paper, a copy I can actually read!
>
> Mark it problem solved.

Glad you got it done.

-- 
People want to waste their time. If you get in the way of that, if you
suggest they should do something else, they will hate you forever.
-- Tim Dillon

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

#256683

On 2023-03-27 15:17:45 +0200, Nicolas George wrote:
> Dan Ritter (12023-03-27):
> > changing 33 to 30 will get you black. ANSI color escapes are on
> > the web in many places.
> 
> Also, decent terminal emulators let users tweak the colors, and making
> sure all main colors are readable on the default background would
> probably be a good use of that ability.

The issue is that when colors are used for the background, this can
make text unreadable. The output also depends on the font rendering
library, and the color readability can change after an upgrade.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

#256420

On Mon, Mar 27, 2023 at 08:52:10AM -0400, Dan Ritter wrote:
> Greg Wooledge wrote: 
> > 3) apt uses a horrible yellow color that is nigh-unreadable on a white
> >    background.  (This is not configurable.)
> 
> It appears that it is, just badly documented.
> 
> In /etc/apt/apt.conf, you can specify the escape sequences for
> colors like this:
> 
> APT::Color::Yellow "ESC[33m";

unicorn:~$ man apt.conf | grep -i -e color -e colour
unicorn:~$ man apt-config | grep -i -e color -e colour
unicorn:~$ 

Yeah, that's "badly documented" i.e. "not documented at all".

Here are some other things one might find by poking around the web or
various commands:

apt-config(8)
        dump
            Just show the contents of the configuration space.

unicorn:~$ apt-config dump | grep -i -e color -e colour
Binary::apt::APT::Color "1";

So, there's a quasi-visible configuration element that lets you turn off
apt's use of colors completely.  Undocumented, obviously.

Your APT::Color::Yellow is not even visible in the dump of all the
configuration elements.

<https://salsa.debian.org/apt-team/apt/-/blob/main/doc/examples/configure-index>
contains:

    apt::moo::color "<BOOL>";

    apt::color::highlight "<STRING>";
    apt::color::neutral "<STRING>";

    APT::Color "<BOOL>";

I have no idea how out of date or inaccurate these may be.

It's also incredibly difficult to TEST any changes to apt's color
configuration, because the parts I care about are circumstantial.
The yellow color is used on the progress/status line while apt
is downloading stuff -- and if you've already run "apt update" earlier
today, chances are there won't be any new data to download when you run
it a second time.

If I use "apt search google-chrome-stable" I get the following text:

unicorn:~$ apt search google-chrome-stable
Sorting... Done
Full Text Search... Done
google-chrome-stable/stable,now 111.0.5563.110-1 amd64 [installed]
  The web browser from Google

where the package name (google-chrome-stable) appears green.  So...
can I test using that?  It appears I cannot.

If I put Binary::apt::APT::Color "0"; in my /etc/apt/apt.conf.d/99local
file, and re-run the apt search command, it's still green.

If I put APT::Color::Green "ESC[33m"; in there and re-run the apt search
command, it's also still green.  Is "ESC" supposed to be exactly that,
the capital letters E, S and C?  Or is it supposed to be a raw ASCII Esc
character?  If I change it to a raw Esc character and re-run the apt search
command ... the package name is still green.

More web searching... here's another page,
<https://unix.stackexchange.com/questions/392791/apt-configure-the-colors>.
One of the answers says:

    Despite defining several colours, apt currently (1.8.2) doesn't
    use most of them. Highlight and Neutral are used in a few places,
    but none of the colours are except Yellow. It appears in one line
    in acqprogress.cc as the output colour for status.

So, if I put APT::Color::Highlight "ESC[33m"; in my file and re-run the
command, I get:

unicorn:~$ apt search google-chrome-stable
Sorting... Done
Full Text Search... Done
ESC[33mgoogle-chrome-stable/stable,now 111.0.5563.110-1 amd64 [installed]
  The web browser from Google

Aha!  So it does use that particular configuration element, and it does
expect a raw Esc character.  But just to be absolutely sure, I'll try
a backslash+e first:

unicorn:~$ apt search google-chrome-stable
Sorting... Done
Full Text Search... Done
\e[33mgoogle-chrome-stable/stable,now 111.0.5563.110-1 amd64 [installed]
  The web browser from Google

Nope.  Raw it must be.  Unfortunately, I can't test APT::Color::Yellow
because it depends on ephemeral state.

It's also quite curious that "apt search" uses the Highlight color even
when Binary::apt::APT::Color is set to "0".  Bug?  Well, it can't be a
bug if it's not documented.  But it's really stupid.  And it makes me
wonder just what Binary::apt::APT::Color actually controls.

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

#256455

On Mon, 27 Mar 2023 Greg Wooledge wrote:
> On Mon, Mar 27, 2023 at 08:52:10AM -0400, Dan Ritter wrote:
>> Greg Wooledge wrote:
>>> 3) apt uses a horrible yellow color that is nigh-unreadable on a white
>>>    background.  (This is not configurable.)

I use exclusively apt-hyphenated commands (apt-{get,cache,etc}), and
don't plan to change.

I have

  $ cat /etc/apt/apt.conf.d/90no_color
  APT::Color "false";

So I am surprised to learn that the newfangled bare "apt" ignores that
preference. Not a pleasant surprise.

Like I said though, I don't plan to start using it.

>> It appears that it is, just badly documented.
>>
>> In /etc/apt/apt.conf, you can specify the escape sequences for
>> colors like this:
>>
>> APT::Color::Yellow "ESC[33m";

This seems less general a solution than warranted. If the user can't
see yellow, they don't only want *apt* to use an alternate color for
yellow.

I would instead want to tweak the whole console color scheme along
these lines,

   https://nethackwiki.com/wiki/Colors#Linux_console

so that the colors were more sensible across all applications.

> unicorn:~$ man apt.conf | grep -i -e color -e colour
> unicorn:~$ man apt-config | grep -i -e color -e colour
> unicorn:~$
>
> Yeah, that's "badly documented" i.e. "not documented at all".
>
> Here are some other things one might find by poking around the web or
> various commands:
>
> apt-config(8)
>        dump
>            Just show the contents of the configuration space.
>
> unicorn:~$ apt-config dump | grep -i -e color -e colour
> Binary::apt::APT::Color "1";
>
> So, there's a quasi-visible configuration element that lets you turn off
> apt's use of colors completely.  Undocumented, obviously.

Doesn't work for me.

  # apt -o "Binary::apt::APT::Color=0" update

"N% [Working]" etc output is still colorised.

> Your APT::Color::Yellow is not even visible in the dump of all the
> configuration elements.
>
> <https://salsa.debian.org/apt-team/apt/-/blob/main/doc/examples/configure-index>
> contains:
>
>    apt::moo::color "<BOOL>";
>
>    apt::color::highlight "<STRING>";
>    apt::color::neutral "<STRING>";
>
>    APT::Color "<BOOL>";
>
> I have no idea how out of date or inaccurate these may be.
>
> It's also incredibly difficult to TEST any changes to apt's color
> configuration, because the parts I care about are circumstantial.
> The yellow color is used on the progress/status line while apt
> is downloading stuff -- and if you've already run "apt update" earlier
> today, chances are there won't be any new data to download when you run
> it a second time.
>
> If I use "apt search google-chrome-stable" I get the following text:
>
> unicorn:~$ apt search google-chrome-stable
> Sorting... Done
> Full Text Search... Done
> google-chrome-stable/stable,now 111.0.5563.110-1 amd64 [installed]
>  The web browser from Google
>
> where the package name (google-chrome-stable) appears green.  So...
> can I test using that?  It appears I cannot.
>
> If I put Binary::apt::APT::Color "0"; in my /etc/apt/apt.conf.d/99local
> file, and re-run the apt search command, it's still green.
[rest trimmed]

Would you like blinking text instead? (Or whatever your terminal does
instead of blinking text.)

  # apt -o "APT::Color::Highlight=^[[5m" search nethack
                                  ^^
                                  (raw escape)
                (entered with Ctrl-V followed by hitting Esc key)
          (explained for benefit of readers as clueless as myself)

I got the blinking text thing from console_codes(4), under section
"ECMA-48 Set Graphics Rendition".

According to that same section, replacing "5" with "25" sets "blink
off"

  # apt -o "APT::Color::Highlight=^[[25m" search nethack

For me, this produces text in the default style (no highlights, no
colors).

-- 
Believe you do in the church, not infront of the computer, when we see
the output we can conclude ourself. -- deloptes

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

#256674 — apt colored output (was Re: Buster => Bullseye: packages kept back)

On Tue, 28 Mar 2023 davidson wrote:

Replying to myself.

> According to [console_codes(4), under section ECMA-48 Set Graphics
> Rendition], [this value] sets "blink off"
>
> # apt -o "APT::Color::Highlight=^[[25m" search nethack
>
> For me, this produces text in the default style (no highlights, no
> colors).

This surprised me.

But it should not have, since the config option specified above just
tells apt to prefix the package name with a different PRETTIFY escape
sequence in output like

   <PRETTIFY>slashem-x11<RESET ATTRIBS>/stable 0.0.7E7F3-10 amd64
     variant of Nethack (X11 window port)

One that happens to set the blink display attribute off. Vacuously, of
course, unless you happen to have "blink on" set.

Might as well replace 25 ("blink off") with any of

   22        set normal intensity
   24        underline off
   25        blink off
   27        reverse video off

or just

   0         reset all attributes to their defaults

or nothing at all, ie

  APT::Color::Highlight=^[[m

which is equivalent to

  APT::Color::Highlight=^[[0m # reset all attributes to their defaults

This solves the problem of undesired colors, but not the emission of
unwanted escape sequences. And so there are bug reports like this:

   #1010806 - apt: Avoid color output on monochrome terminals
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010806

-- 
"What is your pronoun?" he inquired. "I have no pronoun," I answered,
hoping I knew his meaning. "What is your cog?" "My cog?" "Your sur
noun." "I haven't got that either."
-- Flann O'Brien, _The Third Policeman_

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

#256461

Jesper Dybdal <jd-debian-user@dybdal.dk> writes:

> On 2023-03-26 23:12, Jeffrey Walton wrote:
>> On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
>>> Yesterday, I upgraded Buster => Bullseye.
>> For completeness, here is the Debian procedure for a release upgrade:
>> https://wiki.debian.org/DebianUpgrade .
> Thanks.  Interesting that the Wiki recommends using apt-get, while the
> Bullseye release notes recommend apt.

The wiki actually says "Upgrading from one stable release to the next
(e.g. buster to bullseye) is done by following the release notes for
your architecture." You did the right thing if you followed those.

For sure, many ways work for upgrading Debian. The best tested way is
the one in the release notes.

[toc] | [prev] | [standalone]

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

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

csiph-web