Buster => Bullseye: packages kept back

[Jesper Dybdal]

Yesterday, I upgraded Buster => Bullseye.

This morning, I got a mail from unattended-upgrades, which said:

> Packages with upgradable origin but kept back:
> Debian stable:
> guile-2.2-libs w3m

and
> Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
> Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
What does this mean?  I have what I believe to be a clean install, I
have never used apt_preferences, and until now, I had never heard of
guile or w3m.  And I don't quite understand why I have them installed at
all.  My sources.list contains only bullseye and bullseye-backports.

What do I do?

apt list says:
> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
> 2.2.7+1-6]
>
> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
Thanks,
Jesper

--
Jesper Dybdal
https://www.dybdal.dk

[Jeffrey Walton]

I would install aptitude, and then run `aptitude safe-upgrade`.
Aptitude's solver can usually determine the upgrade path that avoids
breaking the machine.

Jeff

[davidson]

On Sun, 26 Mar 2023 Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.

Release notes for Debian 11 (bullseye)
Upgrades from Debian 10 (buster) :: section 4.8 Obsolete Packages
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete

> This morning, I got a mail from unattended-upgrades, which said:
>
>> Packages with upgradable origin but kept back:
>> Debian stable:
>> guile-2.2-libs w3m
>
> and
>
>> Package guile-2.2-libs is kept back because a related package is
>> kept back or due to local apt_preferences(5).
>>
>> Package w3m is kept back because a related package is kept back or
>> due to local apt_preferences(5).
>
> What does this mean?

My guess is that you have packages from Buster still installed, which
are now obsolete (ie, not packaged for Bullseye). I speculate that
these obsolete packages depend on guile-2.2-libs and w3m, and that
this somehow (*waves hands around vaguely*) causes guile-2.2-libs and
w3m to be held back.

I "guess" and "speculate", and I confess I don't really know.

(But in the remainder of my reply, I foolishly pretend that I do.)

> I have what I believe to be a clean install, I have never used
> apt_preferences,

The message says

...because a related package is kept back OR due to local
apt_preferences(5).

That is, kept back (for whatever reason), OR because of
apt_preferences. It need not have anything to do with apt_preferences.

> and until now, I had never heard of guile or w3m.

$ apt-cache show guile-2.2-libs w3m

> And I don't quite understand why I have them installed at all.

$ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m'

If they show up in the output of "apt-mark showauto", they were
automatically installed (I'd guess in order to satisfy dependencies,
recommends, etc)

> My sources.list contains only bullseye and bullseye-backports.

Today it does.

But the day before yesterday, I gather it was Buster's Last Stand.

> What do I do?

Two options come to mind.

FIRST OPTION:

>From the section of the Bullseye release notes I linked above...

Some package management front-ends provide easy ways of finding
installed packages that are no longer available from any known
repository. The aptitude textual user interface lists them in the
category “Obsolete and Locally Created Packages”, and they can be
listed and purged from the commandline with:

# aptitude search '~o'
# aptitude purge '~o'

I guess you could try that search command above, first. And then if
you don't care about purging the obsolete packages it lists, then I
guess you could purge them, to see if that permits you to upgrade
these two packages that you never knew you had installed, and never
explicitly asked for.

SECOND OPTION:

Since you have no explicit desire for either w3m or guile-2.2-libs,
you could pretend to remove them, and see what your package manager
thinks that entails.

With apt-get, I would do

$ apt-get -Vs remove w3m

and

$ apt-get -Vs guile-2.2-libs

The -s makes it just for pretend, and the -V makes the packages apt
threatens to remove show up in a nice column, instead jammed into one
long hard-to-read row.

If the removals don't look threatening to you, you know what to do.

And if they do look threatening to you, then don't do it for real!

> apt list says:
>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
>> 2.2.7+1-6]
>>
>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

I notice that the installed versions listed above are in buster. This
seems consistent with them being dependencies of buster packages that
are now obsolete in bullseye.

--
It is wisdom to recognize necessity, when all other courses have been
weighed, though as folly it may appear to those who cling to false hope.
-- Gandalf

[Jesper Dybdal]

Thanks a lot for the responses.  I'm still in doubt as to what to do.

One thing I forgot to mention yesterday, but which I now think may be
correlated with this problem, is that yesterday's upgrade mysteriously
removed roundcube.  I have no idea why, and I want it back, but that is
not particularly urgent.  I wonder if roundcube could have some
dependencies that influence the other problem.

I have saved the responses to some of your suggested commands; they may
not be interesting, but just in case, they are available at
    https://www.dybdal.dk/bullseye
with links in the text below.

guile-2.2-libs do show up, w3m does not.
Response in https://www.dybdal.dk/bullseye/apt-mark-show-auto.txt

>
>> My sources.list contains only bullseye and bullseye-backports.
>
> Today it does.
>
> But the day before yesterday, I gather it was Buster's Last Stand.

Indeed.  And at that time, sources.list contained just buster and
buster-backports.

>
>> What do I do?
>
> Two options come to mind.
>
> FIRST OPTION:
>
>> From the section of the Bullseye release notes I linked above...
>
>   Some package management front-ends provide easy ways of finding
>   installed packages that are no longer available from any known
>   repository. The aptitude textual user interface lists them in the
>   category “Obsolete and Locally Created Packages”, and they can be
>   listed and purged from the commandline with:
>
>      # aptitude search '~o'
>      # aptitude purge '~o'
>
> I guess you could try that search command above, first. And then if
> you don't care about purging the obsolete packages it lists, then I
> guess you could purge them, to see if that permits you to upgrade
> these two packages that you never knew you had installed, and never
> explicitly asked for.

The search command gives a list of 108 packages, which I'm somewhat
reluctant to purge.
Output in https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

>
> SECOND OPTION:
>
> Since you have no explicit desire for either w3m or guile-2.2-libs,
> you could pretend to remove them, and see what your package manager
> thinks that entails.
>
> With apt-get, I would do
>
>  $ apt-get -Vs remove w3m

That gives a list of 129 packages that "were automatically installed and
are no longer required" but  as I understand it, it will remove only
w3m, not those 129 packages.
Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt

> and
>
>  $ apt-get -Vs guile-2.2-libs

That gives first a list of 134 packages, and then:
The following packages will be REMOVED:
   guile-2.2-libs (2.2.7+1-6)
   libmailutils7 (1:3.10-3+b1)
   mailutils (1:3.10-3+b1)

I am not quite certain that I do not use or will use mailutils.
Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-guile.txt

>
> The -s makes it just for pretend, and the -V makes the packages apt
> threatens to remove show up in a nice column, instead jammed into one
> long hard-to-read row.
>
> If the removals don't look threatening to you, you know what to do.
>
> And if they do look threatening to you, then don't do it for real!
>
>> apt list says:
>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>>> 2.2.4+1-2+deb10u1]
>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
>>> 2.2.7+1-6]
>>>
>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> I notice that the installed versions listed above are in buster. This
> seems consistent with them being dependencies of buster packages that
> are now obsolete in bullseye.
>

I'm leaning towards removing those packages.  And when I lose mailutils,
then I can reinstall it when I need it.
But perhaps I will try to install the lost roundcube again first, and
see if it changes the state.

Does that sound sensible?

Again thanks for your help,

[Cindy Sue Causey]

DISCLAIMER: The subject line indicates a distribution upgrade, but it
looks like your sources.list is only Bullseye. My response is based on
a stabilized single

Hi.. There's a long response attached below, but first I'm wondering
if this is an appropriate instance for using:

apt-get dist-upgrade

I just searched the standing emails and didn't see it mentioned yet.
It comes to mind to ask because of the subject line here.

The rest of what I wrote.........

If this had been my upgrade, my now several years long method of
attack is to try:

apt-get upgrade guile-2.2-libs

I changed to that method after seeing it mentioned on Debian-User.
Prior to that, I *used to* do "apt-get install <held-package-name>".
Don't do that. That messes with how apt labels packages as "manual"
and "auto" with respect to how they came to be installed.

The following might work if one is nervous about the outcome, but I
don't have a way to test it to prove as fact right now:

apt-get upgrade -s guile-2.2-libs

That's a simulated upgrade that theoretically shows most of what will
occur if the user decides to follow through.

Every time I've ever chosen to upgrade a package that's been held, the
situation has been one or more of the following:

1) A package's numbering sequence has been raised a significant step
2) One or more new packages will be installed as part of the newest upgrade
3) One or more old packages will be removed as part of the newest upgrade.

Step 1 usually runs in tandem with Step 3. Not always, though. Python2
and Python3 come to mind as an exception. They can both be installed
together in cases of dire necessity. I'm not totally comfortable
highlighting Python as an example, but I am seeing them called
"different versions of" instead of "different programs based on"
Python out on the Net.

The kernel is an example of where holds occur on regular occasion. The
kernel affects almost everything else. Developers keeping it on hold
helps system administrators manually address its upgrade. That gives
sysadmins the opportunity to review the kernel's changelog and verify
that their production machines will continue to work as flawlessly as
possible after each upgrade.

For my usage of Sid, I would look at:

https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog

That was found by following a path starting at:

https://packages.debian.org/search?keywords=linux-image-amd64

Cindy :)

Side Note: I say "kernel affects _almost_ everything else" because
installation of the kernel is not the first step in the debootstrap
process. The kernel's installation occurs a few steps in after e.g.
the time settings, HOSTNAME, keyboard configuration, apt's
personalized repositories, limited sysadmin type package
installations, and /dev's base ("generic") devices have been
established. The steps to perform those actions operate successfully
with no kernel on board yet.

--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

[Jesper Dybdal]

On 2023-03-26 17:37, Cindy Sue Causey wrote:
> On 3/26/23, Jesper Dybdal <jd-debi...@dybdal.dk> wrote:
>
>>> Packages with upgradable origin but kept back:
>>> Debian stable:
>>> guile-2.2-libs w3m
>>

> DISCLAIMER: The subject line indicates a distribution upgrade, but it
> looks like your sources.list is only Bullseye. My response is based on
> a stabilized single

It was a clean Buster with a few backports, and I upgraded it following
the instructions in the Bullseye release notes. Basically:

* apt update
* apt upgrade --without-new-pkgs
* apt full-upgrade

>
> Hi.. There's a long response attached below, but first I'm wondering
> if this is an appropriate instance for using:
>
> apt-get dist-upgrade
>
> I just searched the standing emails and didn't see it mentioned yet.
> It comes to mind to ask because of the subject line here.
>
> The rest of what I wrote.........
>
> If this had been my upgrade, my now several years long method of
> attack is to try:
>
> apt-get upgrade guile-2.2-libs
> I changed to that method after seeing it mentioned on Debian-User.
> Prior to that, I *used to* do "apt-get install <held-package-name>".
> Don't do that. That messes with how apt labels packages as "manual"
> and "auto" with respect to how they came to be installed.
>
> The following might work if one is nervous about the outcome, but I
> don't have a way to test it to prove as fact right now:
>
> apt-get upgrade -s guile-2.2-libs

Doing that gives:

The following packages will be REMOVED:

  libgc1c2
The following NEW packages will be installed:
  libgc1
The following packages will be upgraded:
  guile-2.2-libs libdatetime-timezone-perl tzdata w3m

I think I will either do that or try to remove them

If I try "apt-get -s upgrade" (i.e., without the package name) it says:
The following packages have been kept back:
  guile-2.2-libs w3m
The following packages will be upgraded:
  libdatetime-timezone-perl tzdata

So I'm beginning to suspect that the libgc1/libgc1gc2 packages have
something to do with it.

Thanks a lot! - also for the more general information quoted below.
Jesper

Jesper Dybdal
https://www.dybdal.dk

[David Wright]

On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.
>
> This morning, I got a mail from unattended-upgrades, which said:
>
> > Packages with upgradable origin but kept back:
> > Debian stable:
> > guile-2.2-libs w3m
>
> and
> > Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
> > Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
> What does this mean?  I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m.  And I don't quite understand why I have them installed
> at all.  My sources.list contains only bullseye and
> bullseye-backports.

It's a little odd that, the day after upgrading releases, you
already have backports in your sources list. Is there a specific
reason for that?

Your system seems to have some old packages on it; for example,
heirloom-mailx and ripole are both from stretch. If you need them,
check trhat you still have access to local copies of those packages
and then try removing them to see whether they're causing a logjam.

> apt list says:
> > guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> > guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
> > to: 2.2.7+1-6]
> >
> > w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> > w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

If you read the Release Notes that come with each release, you'll
find instructions on "cleaning" a system before upgrading. A useful
tool to help with that is, for example:

$ aptitude why w3m
i imagemagick-6-doc Recommends www-browser
i w3m Provides www-browser
$

which would mean, on my system in similar circumstances, that I could
remove w3m without ill effects, and then reinstall it later, after
things have unjammed. Similarly:

$ aptitude why guile-2.2-libs
i emacs-gtk Depends emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils
i A mailutils Depends libmailutils7
i A libmailutils7 Depends guile-2.2-libs
$

Here I could remove mailutils, though in this case certain commands
could temporarily fail, eg a cron job that sends an email.

$ apt-get -s purge mailutils
[ … ]
The following packages were automatically installed and are no longer required:
gsasl-common guile-2.2-libs libgsasl7 libmailutils7 libntlm0 mailutils-common
Use 'apt autoremove' to remove them.

The following packages will be REMOVED:

mailutils*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
$

One of those no longer required packages may be what's causing the
problem. They can be reinstalled after you get a clean upgrade.

If things don't turn out as simple as that, then I would have an
in-depth read of man aptitude which can test (aptitude -s)
various paths for fixing the problem. It has the patience to
figure out all the dependency/recommendation chains for any
package on the system. (My system has 56 reasons to install
guile-2.2-libs though, as we know, none is entirely based on
dependencies.)
$ aptitude -v --show-summary=all-packages why guile-2.2-libs | less

Not /every/ package on a system has to come from the same release
version, but you should know which are the exceptions, why they're
installed, and what their dependencies are. So, for example, I have
squeeze's xtoolwait, whose dependencies, libc6 (>= 2.2.5), libx11-6,
and libxext6, are straightforward to satisfy.

One configuration change I always make is:

$ cat /etc/logrotate.d/apt
/var/log/apt/term.log {
rotate -1
monthly
compress
missingok
notifempty
}
/var/log/apt/history.log {
rotate -1
monthly
compress
missingok
notifempty
}
$

which keeps a perpetual log of what gets installed on a system, when,
and hints as to why. This helps to answer the questions implied in
your opening paragraphs. (I don't install with aptitude, but that
has a similar configuration parameter.)

Cheers,
David.

[Jeffrey Walton]

On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debi...@dybdal.dk> wrote:
>

> Yesterday, I upgraded Buster => Bullseye.

For completeness, here is the Debian procedure for a release upgrade:
https://wiki.debian.org/DebianUpgrade .

Jeff

[Jesper Dybdal]

Thanks.  Interesting that the Wiki recommends using apt-get, while the
Bullseye release notes recommend apt.

[Jesper Dybdal]

On 2023-03-26 20:15, David Wright wrote:
> On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
>> Yesterday, I upgraded Buster => Bullseye.
>>
>> This morning, I got a mail from unattended-upgrades, which said:
>>
>>> Packages with upgradable origin but kept back:
>>> Debian stable:
>>> guile-2.2-libs w3m
>> and
>>> Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
>>> Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
>> What does this mean?  I have what I believe to be a clean install, I
>> have never used apt_preferences, and until now, I had never heard of
>> guile or w3m.  And I don't quite understand why I have them installed
>> at all.  My sources.list contains only bullseye and
>> bullseye-backports.
> It's a little odd that, the day after upgrading releases, you
> already have backports in your sources list. Is there a specific
> reason for that?

No.  The reason is only that experience shows that during the lifetime
of a stable release, I will install a few backports.  So the list might
just as well be ready from start.  And currently, there is no backported
packages installed.

>
> Your system seems to have some old packages on it; for example,
> heirloom-mailx and ripole are both from stretch. If you need them,
> check trhat you still have access to local copies of those packages
> and then try removing them to see whether they're causing a logjam.
>
>> apt list says:
>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
>>> to: 2.2.7+1-6]
>>>
>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
> If you read the Release Notes that come with each release, you'll
> find instructions on "cleaning" a system before upgrading. A useful
> tool to help with that is, for example:
>
> $ aptitude why w3m
> i imagemagick-6-doc Recommends www-browser
> i w3m Provides www-browser
> $

Thanks.  The release notes do not mention aptitude why, which seems a
good tool.

I have not yet decided exactly what I'll do, but each answer to my
original post has significantly improved my understanding of the install
system.
Many thanks to everybody who answered!

[davidson]

On Sun, 26 Mar 2023 Jesper Dybdal wrote:
> Thanks a lot for the responses.

It is a confusing mystery!

> I'm still in doubt as to what to do.

I notice that according to your posted output from the commands,

apt-get -Vs remove {w3m,guile-2.2-libs}

that both packages now appear to be up-to-date, relative to the
versions current in bullseye:

https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt
[...]

The following packages will be REMOVED:

w3m (0.5.3+git20210102-6)

https://www.dybdal.dk/bullseye/apt-get-Vs-remove-guile.txt
[...]

The following packages will be REMOVED:
guile-2.2-libs (2.2.7+1-6)
libmailutils7 (1:3.10-3+b1)
mailutils (1:3.10-3+b1)

> One thing I forgot to mention yesterday, but which I now think may
> be correlated with this problem, is that yesterday's upgrade
> mysteriously removed roundcube.  I have no idea why, and I want it
> back, but that is not particularly urgent.  I wonder if roundcube
> could have some dependencies that influence the other problem.

Even on my good days, your guess is probably better than mine. And in
my present state of confusion, I will decline to speculate. :D

> I have saved the responses to some of your suggested commands; they
> may not be interesting,

They were.

> but just in case, they are available at
>     https://www.dybdal.dk/bullseye
> with links in the text below.

Yes, I was curious. Thank you.

> On 2023-03-26 13:17, davidson wrote:
>> On Sun, 26 Mar 2023 Jesper Dybdal wrote:

[trimmed]

>>  $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m'

By the way, I learned today that the same output can be had more
simply with

$ apt-mark showauto guile-2.2-libs w3m

[trimmed]

>>> My sources.list contains only bullseye and bullseye-backports.
>>
>> Today it does.
>>
>> But the day before yesterday, I gather it was Buster's Last Stand.
>
> Indeed.  And at that time, sources.list contained just buster and
> buster-backports.

By the way, does your sources.list really have no line for security
updates? Nothing like this one?

deb http://security.debian.org/debian-security bullseye-security main non-free

[trimmed]
>> FIRST OPTION:
[trimmed]

>>      # aptitude search '~o'
>>      # aptitude purge '~o'
>>
>> I guess you could try that search command above, first. And then if
>> you don't care about purging the obsolete packages it lists, then I
>> guess you could purge them, to see if that permits you to upgrade
>> these two packages that you never knew you had installed, and never
>> explicitly asked for.
>
> The search command gives a list of 108 packages, which I'm somewhat
> reluctant to purge.
>
> Output in https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

I do not use aptitude at all, and therefore know nothing about it. So
do not construe the next bit as advice.

In the absence of a particular reason to keep around a package which
won't receive updates (security or otherwise) during a system
release's lifetime, I am personally inclined to purge it, one way or
another. (Not with aptitude, though, because I don't know the first
thing about how to keep it from doing things I don't want done.)

Sometimes there are reasons to keep them, of course.

And I hear that some people don't even need reasons, if you can
believe this. They just do whatever they want!

>> SECOND OPTION:
[trim]

>>
>>  $ apt-get -Vs remove w3m
>
> That gives a list of 129 packages that "were automatically installed
> and are no longer required" but  as I understand it, it will remove
> only w3m, not those 129 packages.

True. APT is just keeping you informed.

> Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt

Comparing the autoremoval list in the output above to your list of
obsolete packages

https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

it looks like among those 129 packages, that

# apt-get autoremove

would remove many (about 46?) of the obsolete packages.

You can use

# apt-mark manual favorite-package1 favorite-package2 ...

to keep favorite-packages from being autoremoved.

>> and
>>
>>  $ apt-get -Vs guile-2.2-libs

I have resisted the compulsion to correct my own typo in the above
command.

> That gives first a list of 134 packages, and then:

It baffles me that the number of packages suggested for autoremoval is
different, between guile-2.2-libs and w3m.

> The following packages will be REMOVED:
>    guile-2.2-libs (2.2.7+1-6)
>    libmailutils7 (1:3.10-3+b1)
>    mailutils (1:3.10-3+b1)
>
> I am not quite certain that I do not use or will use mailutils.

To me, those mailutils package versions look up-to-date for bullseye
now, as does guile-2.2-libs!

[trim]

>>> apt list says:
>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>>>> 2.2.4+1-2+deb10u1]
>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
>>>> 2.2.7+1-6]
>>>>
>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

(Above excerpt left untrimmed for easy comparison with more recent output.)

[trimmed discussion of mailutils]

> But perhaps I will try to install the lost roundcube again first,
> and see if it changes the state.
>
> Does that sound sensible?

Sure.

> Again thanks for your help,

It's been very interesting. Have a good week.

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[Jesper Dybdal]

On 2023-03-27 10:59, davidson wrote:
>
> By the way, does your sources.list really have no line for security
> updates? Nothing like this one?
>
>   deb http://security.debian.org/debian-security bullseye-security
> main non-free

Yes, it does: https://www.dybdal.dk/bullseye/sources.list

I currently do not use contrib, non-free, or backports, but I like to
have them in sources.list when I may some day need them.  But only the
Bullseye (or backport) versions.

> # apt-get autoremove
> would remove many (about 46?) of the obsolete packages.
>
> You can use
>
>   # apt-mark manual favorite-package1 favorite-package2 ...
>
> to keep favorite-packages from being autoremoved.

I will probably do an autoremove when everything seems stable and I have
a few backups.

>
> It baffles me that the number of packages suggested for autoremoval is
> different, between guile-2.2-libs and w3m.

Me too.

>
> [trim]
>>>> apt list says:
>>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>>>>> 2.2.4+1-2+deb10u1]
>>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
>>>>> to: 2.2.7+1-6]
>>>>>
>>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> (Above excerpt left untrimmed for easy comparison with more recent
> output.)
>
> [trimmed discussion of mailutils]
>> But perhaps I will try to install the lost roundcube again first,
>> and see if it changes the state.
>>
>> Does that sound sensible?
>
> Sure.
>
>> Again thanks for your help,
>
> It's been very interesting. Have a good week.

Thanks!

[Vincent Lefevre]

Probably because "apt" is newer and the wiki hasn't been updated yet.
It seems that they are very similar. The only difference I could see
is that apt adds coloring.

--
Vincent Lefèvre <vin...@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)

[Greg Wooledge]

On Mon, Mar 27, 2023 at 01:20:32PM +0200, Vincent Lefevre wrote:
> On 2023-03-27 00:21:18 +0200, Jesper Dybdal wrote:
> > On 2023-03-26 23:12, Jeffrey Walton wrote:
> > > On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debi...@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.
>
> Probably because "apt" is newer and the wiki hasn't been updated yet.
> It seems that they are very similar. The only difference I could see
> is that apt adds coloring.

>From an end user's point of view, the three main differences between
"apt-get" and "apt" are:

1) Upgrades done with apt-get retain the .deb files in
/var/cache/apt/archives by default, whereas apt removes these .deb
files by default. (This is configurable.)

2) "apt-get upgrade" does not install new packages unless you supply the
--with-new-pkgs option. "apt upgrade" acts as if you had supplied it.
(This is configurable.)

3) apt uses a horrible yellow color that is nigh-unreadable on a white
background. (This is not configurable.)

In terms of package conflict resolution and so on, they both call the
same library routines, so they both "work" the same way. It's just
these front-end issues that change.

For actually configuring apt/apt-get, the options are somewhat hard to
find. The configuration element for removing the .deb files appears to
be named "Clean" in apt.conf(5) (do not confuse it with Clean-Installed).

The configuration element for --with-new-pkgs is identified in apt-get(8)
at the end of the description of --with-new-pkgs. This element does not
appear AT ALL in apt.conf(5).

Finally, there's one obscure but important difference that only arises in
specific situations. Quoting from <https://wiki.debian.org/NewInBuster>:

If you previously ran buster during its time as "testing", you may
see this error when you run apt-get update:

E: Repository 'http://ftp.us.debian.org/debian buster InRelease' changed
its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository
can be applied. See apt-secure(8) manpage for details.

In order to accept this change, you should run apt update instead,
at least one time. apt will prompt you for confirmation, and then
everything proceeds normally.

I.e. there are some situations where apt will prompt you for something
whereas apt-get will just fail without prompting you (and gives you a
bogus reference to lead you on a wild goose chase). I don't know what
all those possible situations are, but the above is one of them.

[Vincent Lefevre]

On 2023-03-27 07:49:13 -0400, Greg Wooledge wrote:
> 2) "apt-get upgrade" does not install new packages unless you supply the
> --with-new-pkgs option. "apt upgrade" acts as if you had supplied it.
> (This is configurable.)

FYI, I prefer to do the upgrades of my Debian/unstable machines with
aptitude (via its TUI): that way, new packages are automatically
installed when needed, and automatically installed packages are
removed when they are no longer used (but if one wants to keep such
a package, one can mark it as manually installed). This seems to be
what makes most sense.

[...]

> Finally, there's one obscure but important difference that only arises in
> specific situations. Quoting from <https://wiki.debian.org/NewInBuster>:
>
> If you previously ran buster during its time as "testing", you may
> see this error when you run apt-get update:
>
> E: Repository 'http://ftp.us.debian.org/debian buster InRelease' changed
> its 'Suite' value from 'testing' to 'stable'
> N: This must be accepted explicitly before updates for this repository
> can be applied. See apt-secure(8) manpage for details.
>
> In order to accept this change, you should run apt update instead,
> at least one time. apt will prompt you for confirmation, and then
> everything proceeds normally.
>
> I.e. there are some situations where apt will prompt you for something
> whereas apt-get will just fail without prompting you (and gives you a
> bogus reference to lead you on a wild goose chase). I don't know what
> all those possible situations are, but the above is one of them.

This seems similar to aptitude:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033359

[Greg Wooledge]

On Mon, Mar 27, 2023 at 02:17:11PM +0200, Vincent Lefevre wrote:
> FYI, I prefer to do the upgrades of my Debian/unstable machines with
> aptitude

aptitude is VERY different from apt/apt-get. It uses an entirely
different pacakge conflict resolution.

Using aptitude for release upgrades (in place of "apt full-upgrade"
or "apt-get dist-upgrade") is not supported. It can get stuck, or do
weird things. This is why the release notes never say to use it.

Since you're on unstable, you're on your own anyway, so do whatever
works for you.

[Dan Ritter]

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-

[Nicolas George]

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

[gene heskett]

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/>

[Greg Wooledge]

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.

[Jesper Dybdal]

On 2023-03-27 10:59, davidson wrote:
>

>>>> apt list says:
>>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>>>>> 2.2.4+1-2+deb10u1]
>>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
>>>>> to: 2.2.7+1-6]
>>>>>
>>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> (Above excerpt left untrimmed for easy comparison with more recent
> output.)

I decided to try "apt-get  upgrade guile-2.2-libs".  That seems to have
worked.  Now the situation is:
> root@nuser:~# apt list guile-2.2-libs w3m -a
> Listing... Done
> guile-2.2-libs/stable,now 2.2.7+1-6 amd64 [installed,automatic]
> w3m/stable,now 0.5.3+git20210102-6 amd64 [installed]

So now I suspect everything is ok.

Again: thanks! to all the many helpful participants in this thread.

[David Wright]

On Mon 27 Mar 2023 at 07:49:13 (-0400), Greg Wooledge wrote:
> On Mon, Mar 27, 2023 at 01:20:32PM +0200, Vincent Lefevre wrote:
> > On 2023-03-27 00:21:18 +0200, Jesper Dybdal wrote:
> > > On 2023-03-26 23:12, Jeffrey Walton wrote:
> > > > On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debi...@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.
> >
> > Probably because "apt" is newer and the wiki hasn't been updated yet.
> > It seems that they are very similar. The only difference I could see
> > is that apt adds coloring.
>

> >From an end user's point of view, the three main differences between
> "apt-get" and "apt" are:

A fourth is that apt-get is recommended for scripting as its CLI
is stable, whereas apt's may well change.

> For actually configuring apt/apt-get, the options are somewhat hard to
> find.

Most, but not all, are in /usr/share/doc/apt/examples/configure-index.
Those ANSI colours haven't yet made it in, for example.

> The configuration element for --with-new-pkgs is identified in apt-get(8)
> at the end of the description of --with-new-pkgs. This element does not
> appear AT ALL in apt.conf(5).

AIUI you're expected to add a file, say, 90-my-opts into apt.conf.d/
with Upgrade-Allow-New "true"; in it.

On Sun 26 Mar 2023 at 14:50:45 (+0200), Jesper Dybdal wrote:
> Thanks a lot for the responses.  I'm still in doubt as to what to do.

>
> One thing I forgot to mention yesterday, but which I now think may be
> correlated with this problem, is that yesterday's upgrade mysteriously
> removed roundcube.  I have no idea why, and I want it back, but that
> is not particularly urgent.  I wonder if roundcube could have some
> dependencies that influence the other problem.

[ … ]

> I'm leaning towards removing those packages.  And when I lose
> mailutils, then I can reinstall it when I need it.

> But perhaps I will try to install the lost roundcube again first, and
> see if it changes the state.
>
> Does that sound sensible?

The downside is the more high-level packages you have installed,
the more dependencies, and a more difficult path to resolution.

On Mon 27 Mar 2023 at 11:27:31 (+0200), Jesper Dybdal wrote:
> On 2023-03-27 10:59, davidson wrote:
> > It baffles me that the number of packages suggested for autoremoval is
> > different, between guile-2.2-libs and w3m.
> Me too.

On my system, w3m is only Recommended for installation, so it's
effectively top-level. It has few dependencies, and those it has
are the sort used by many packages. So removing w3m has liitle
effect on the rest of the system:

$ apt-get -s purge w3m
[ … ]

The following packages will be REMOVED:

w3m*

0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.

Purg w3m [0.5.3+git20210102-6]
$

OTOH, if you remove guile-2.2-libs, you must also lose mailutils and
libmailutils7, which depend on it. Having removed them, apt finds
that there were other packages only installed to satisfy mailutils,
so these are no longer necessary either:

$ aptitude why gsasl-common

i emacs-gtk Depends emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils

i A mailutils Depends libgsasl7 (>= 1.1)
i A libgsasl7 Depends gsasl-common (= 1.10.0-4+deb11u1)
$ aptitude why libntlm0

i emacs-gtk Depends emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils

i A mailutils Depends libgsasl7 (>= 1.1)
i A libgsasl7 Depends libntlm0 (>= 1.2)
$

So it can get rid of the lot:

$ apt-get -s purge guile-2.2-libs
[ … ]
The following packages were automatically installed and are no longer required:
gsasl-common libgsasl7 libntlm0 mailutils-common

Use 'apt autoremove' to remove them.

The following packages will be REMOVED:

guile-2.2-libs* libmailutils7* mailutils*
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
Purg libmailutils7 [1:3.10-3+b1]
Purg guile-2.2-libs [2.2.7+1-6]
$ apt-get --purge autoremove
[ … check the list carefully … ]

Cheers,
David.

[to...@tuxteam.de]

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

[gene heskett]

On 3/27/23 11:31, to...@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.

[to...@tuxteam.de]

On Mon, Mar 27, 2023 at 02:02:43PM -0400, gene heskett wrote:
> On 3/27/23 11:31, to...@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

[davidson]

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.

[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

[davidson]

On Mon, 27 Mar 2023 Jesper Dybdal wrote:
> On 2023-03-27 10:59, davidson wrote:
>> It baffles me that the number of packages suggested for autoremoval is
>> different, between guile-2.2-libs and w3m.
> Me too.

The two packages depend on different collections of supporting
packages.

And so, depending on which package you remove --- guile-2.2-libs or
w3m --- a different set of automatically-installed packages will be
left installed for no apparent purpose (because the package they were
installed to support is now gone), and eligible for autoremoval.

This mostly obvious fact (which wasn't obvious to me yesterday) is
obscured by the sheer number of packages *already* eligible for
autoremoval on the system, before removing either of the two packages
in question.

--
MS CLINTON: If you google up what the Chinese claim is, it's the entire South China sea.
MR BLANKFEIN: An unfortunate name.
MS CLINTON: Which one?
MR BLANKFEIN: The South China sea.

[Anssi Saari]

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.

[Jesper Dybdal]

On 2023-03-28 10:56, davidson wrote:
> On Mon, 27 Mar 2023 Jesper Dybdal wrote:
>> On 2023-03-27 10:59, davidson wrote:
>>> It baffles me that the number of packages suggested for autoremoval is
>>> different, between guile-2.2-libs and w3m.
>> Me too.
>
> The two packages depend on different collections of supporting
> packages.
>
> And so, depending on which package you remove --- guile-2.2-libs or
> w3m --- a different set of automatically-installed packages will be
> left installed for no apparent purpose (because the package they were
> installed to support is now gone), and eligible for autoremoval.
>
> This mostly obvious fact (which wasn't obvious to me yesterday) is
> obscured by the sheer number of packages *already* eligible for
> autoremoval on the system, before removing either of the two packages
> in question.
>

The large number is probably primarily packages that roundcube depends
upon - but roundcube disappeared during the upgrade.  When I've seen the
system being stable for a while, I'll reinstall roundcube - and it that
goes well, do an autoremove.

Thanks,

[davidson]

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

[gene heskett]

On 3/28/23 01:02, to...@tuxteam.de wrote:
> On Mon, Mar 27, 2023 at 02:02:43PM -0400, gene heskett wrote:
>> On 3/27/23 11:31, to...@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.

[gene heskett]

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.

[gene heskett]

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.

[to...@tuxteam.de]

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

[to...@tuxteam.de]

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

[davidson]

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

[Charlie Gibbs]

On Wed Mar 29 08:56:04 2023 davidson <davi...@freevolt.org> wrote:

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

<applause>

If I write my essay first, I might have to steal that
(properly attributed, of course).

> 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.

<more applause>

Stop it. My hands are getting sore.

Let them waste their time. I draw the line when they waste _my_ time.

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgi...@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert the green consultant

[davidson]

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_

[Vincent Lefevre]

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.