Re: Debian non-free-firmware policy making OS misleading and Free Software unfriendly

[Nate Bargmann]

* On 2024 22 Apr 09:39 -0500, Curt wrote:
> On 2024-04-21, Reid  wrote:
> > You seem to be suggesting that Debian users now need to read XX pages of 
> > release notes and guides in order to learn that what they're installing is 
> > not what the Debian.org homepage "Why Debian", "Our Philosophy", and "Who 
> > We Are / What We Do" pages are currently promoting Debian as.
> 
> How can you be taken seriously when you can't even wrap your lines
> according to our venerable guidelines?
> 
> https://wiki.debian.org/DebianMailingLists
> 
>  Set linewrap to 65-78 characters. 72 is a popular setting. 

Looking at the OP's headers I see:

X-Mailer: MessagingEngine.com Webmail Interface 

User-Agent: Cyrus-JMAP/3.11.0-alpha0-379-gabd37849b7-fm-20240408.001-gabd37849  


It appears our friend is using a Web browser and likely is presented
with a text box that looks all nice and neat with wrapping and all but
hits the list as one long line per paragraph.

> Get a popular setting going, buddy.

Until he sets up a real MUA, I doubt the formatting will improve.

I endure this on many other mailing lists unrelated to Debian,
particularly from groups.io that have a Web interface.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: What use can i give to linux?

[Nate Bargmann]

* On 2024 05 Apr 12:37 -0500, William Torrez Corea wrote:
> My colleague uses Windows, another uses Mac OS while I use Debian Gnu/Linux
> 12.

Choice is good.

> The majority of users use Windows while developers and designers use mac os
> but a little of people use Debian Gnu/Linux 12. So, what is the goal of
> having this distribution?.

https://www.debian.org/intro/why_debian

> I use in Debian Gnu/Linux the following tools:
> 
>1. gdb
>2. gcc
>3. valgrind
>4. git
>5. vim
>6. postgresql

You're using tools provided by Debian to get your work done or to do
things you want to do that work well for you.  Is that the case for your
colleagues?

Understand that some people will only use one computing platform no
matter the benefits of another.  Others will try everything and still
others will seek the absolute best platform to achieve their goals no
matter what it is.  You and your colleagues may well each be in one of
those categories.

Most of the time the platform is dictated by the application(s) a user
wants to run.  Sometimes the platform is dictated by ego.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: NextGov: Linux XZ Utils Backdoor Was Long Con, Possibly With Support

[Nate Bargmann]

* On 2024 05 Apr 11:28 -0500, Cindy Sue Causey wrote:
> Hi, All..
> 
> This just hit my emails seconds ago. It's the most info that I've
> personally read about the XZ backdoor exploit. I've been following
> NextGov as a friendly, plain language resource about government:
> 
> Linux backdoor was a long con, possibly with nation-state support, experts 
> say;
> By David DiMolfetta; 2024.04.05 12:59pm EDT

To be honest, I think better coverage has been done by the F/OSS
community.  The gist I got from this article was government types
speculating that only other government types could possibly be involved,
though there is an allowance for uncertainty.

The article mentions them times that "Jia Tan" apparently made commits
as being consistent with business hours in China or Europe.  Possibly,
but if someone were ever to scrutinize my timelines they would probably
find it consistent with bouts of insomnia!

> Continues to sound like one single perp is destroying the TRUST factor that an
> untold number of future programmers must meet. That's heartbreaking.

The damage to trust is the biggest part of this story, IMO.  A lot of
discussion is centering around tools and performing double checks before
a distribution accepts an updated or new package which are all probably
good steps and which point to the loss of trust.  "Jia Tan" was able to
work with Lasse Collin on the XZ project to the point of gaining commit
privileges and becoming a co-maintainer.  This is nothing new and
projects have been handed off to new maintainers in a more-or-less
similar fashion over the decades.  That in itself would have never
raised an eyebrow.

Committing binary files into a compression utility repository ostensibly
for testing the utility and its library weren't suspicions on the
surface but now the knowledge that compromising code was being linked
into the library from them will now make every binary file suspicious.
Certainly, their use is going to be checked and double-checked.  All of
this reflects the loss of trust.

For all of the other qualities why we have chosen Free Software, the
trust we have placed in Debian and its upstream projects has been
has been the underlying glue that has held this all together.  How this
is addressed going forward will be interesting.  Will upstream project
maintainers be required to have GPG keys signed like Debian requires of
its developers?  Will contributors be subject to the same?  Over the
years projects have received contributions from persons who wished to
remain more or less anonymous.  Will this change?  Will such
contributions become subject to even greater scrutiny by project
maintainers?  I suspect that at a minimum if a maintainer doesn't
clearly understand a patch then it won't get applied, but if the
maintainer is clever enough to work in a non-obvious patch that is
malicious, all bets are off.

It's a mess.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 23:41 -0500, to...@tuxteam.de wrote:
> On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> > * On 2024 01 Apr 14:01 -0500, Andy Smith wrote:
> 
> [...]
> 
> > Until now, who anticipated this?  I'm sure there are security
> > researchers who have and it's likely that I'm not well-read enough on
> > this topic to have seen it discussed.  How many people did it occur to
> > that when A links to B and B links to C that C can create a
> > vulnerability in A?  That is what I understand happened here.
> 
> This pattern has been seen in other contexts. Here [1] is a good review
> of "supply chain attacks", which unsurprisingly happen most often in
> decentrally managed package distributions which at the same time have
> "production environments" where time-to-deploy is the main mover: npm,
> PyPi and RubyGems. If you don't have the time to even consider what the
> hundreds of packages you're ploughing into your app actually do, this
> is no surprise.

If you have Rust and Go in mind, I am hugely skeptical of both, not
because of the languages themselves but because both, from what I see,
do not lend themselves easily to a set of known curated packages that
can be used for development.

Noted Debian developer Ian Jackson wrote a blog post back on 21 March
detailing the extra steps necessary to *only* use Debian Rust packages:

https://diziet.dreamwidth.org/18122.html

> So yes, the pattern was known. It was, up to now, pretty unusual in
> this context. But the deeper "the stack" becomes... (so I think Nate
> had a point. That Andy read that as a "systemd insult" is IMHO
> infortunate, because it clogs a potentially useful discussion. But
> there you are).

I think Andy was responding to Jacob Bachmeyer's use of "katamari" to
describe systemd/libsystemd which he uses again in:

https://lists.gnu.org/archive/html/automake/2024-04/msg00015.html

As far as I know, Jacob is not on this list so discussing his opinion is
a bit unfair to him.

> The next level is using a package phantasized by your trusty "AI" [2]
> counsellor (and whose name was predicted by a malicious actor, because 
> "AI" tends to phantasize names consistently). Note that this one was
> just (yet?) a proof of concept.

I am guessing that the Jia Tan actor(s) are watching the response to
this event carefully.  I doubt they have been deterred.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 16:55 -0500, Charles Curley wrote:
> On Mon, 1 Apr 2024 19:00:29 +
> Andy Smith  wrote:
> 
> > In my view a great example of the "people other than me just need to
> > get good" fallacy merged with the group of people predisposed to
> > hate systemd.
> > 
> > It could have been any direct or indirect dependency of sshd here.
> > I'm quite sure almost none of them have the required resources and
> > processes to detect something like this.
> 
> Easy, now. No-one is attacking systemd, and I don't think anyone wanted
> to start a systemd war. This could also have happened under System V
> initialization.

AIUI (please correct me if I am in error), any dependency chain that
then depends on something else could create a vulnerability.  I am
rather surprised to see that openssh-server has so many dependencies:

Depends: adduser, libpam-modules, libpam-runtime, lsb-base,
openssh-client (= 1:9.2p1-2+deb12u2), openssh-sftp-server, procps, ucf,
debconf (>= 0.5) | debconf-2.0, runit-helper (>= 2.14.0~), libaudit1 (>=
1:2.2.1), libc6 (>= 2.36), libcom-err2 (>= 1.43.9), libcrypt1 (>=
1:4.1.0), libgssapi-krb5-2 (>= 1.17), libkrb5-3 (>= 1.13~alpha1+dfsg),
libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libssl3 (>= 3.0.11),
libsystemd0, libwrap0 (>= 7.6-4~), zlib1g (>= 1:1.1.4)

Not all are libraries, but if IUC, libc6 shows to depend on libgcc-s1,
so if that library could be compromised, then openssh-server could be
vulnerable.  It's quite possible that I am wrong (hopefully) or we have
an even more massive problem.

> I have no doubt that this sort of thing has happened in the past, and I
> fully expect it will happen again in the future. However, the defect
> has been caught and repaired. The system for dealing with
> vulnerabilities is working, if not perfectly. The question now is: what
> lessons can we learn from it.

From what I am seeing right now discussions are centering around
comparing the file list associated with a VCS tag and a release tarball,
and somehow verifying the identity of contributors/committers.  I'm sure
other ideas are being discussed that I've not read.  Suffice it to say,
at the moment this is not being swept under the proverbial rug.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 14:01 -0500, Andy Smith wrote:
> Hi,
> 
> On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> > From what I have read, lzma is not a direct dependency of openssh.  It
> > turns out that it lzma is a dependency of libsystemd and that
> > relationship affected openssh.
> > 
> > Jacob Bachmeyer in analysis
> > (https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
> > says:
> > 
> > Lastly on this topic, some of the blame for this needs to fall on the
> > systemd maintainers and their "katamari" architecture. There is no good
> > reason for notifications of daemon startup to pull in liblzma, but using
> > libsystemd for that purpose does exactly that, and ended up getting
> > xz-utils targeted as a means of getting to sshd without the OpenSSH
> > maintainers noticing.
> > 
> > End quote.
> 
> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.

AIUI, systemd already has patches to limit the use of lzma to only
dlopen when needed: https://lwn.net/Articles/967399/

This action apparently predates this incident and was made for other
considerations.  More than anything, I think this shows in the future
some hard decisions will need to made to prevent unrelated code
affecting other code through linked intermediate code.  AIUI, that would
be a fundamental change to our systems that would likely break
(assuming) a lot of software.

> It could have been any direct or indirect dependency of sshd here.

Or any other daemon but openssh is a very attractive target and systemd
as a service manager is a defacto standard.

> I'm quite sure almost none of them have the required resources and
> processes to detect something like this.

Until now, who anticipated this?  I'm sure there are security
researchers who have and it's likely that I'm not well-read enough on
this topic to have seen it discussed.  How many people did it occur to
that when A links to B and B links to C that C can create a
vulnerability in A?  That is what I understand happened here.

The social part where Jia Tan (individual, group, state actor?) gains
commit privileges, which in a small project are seldom reviewed as some
level of trust has been established before granting such privileges, and
over time begins the process of introducing compromising code bit by
bit.  It is curious that any of the compromise was committed when other
parts were added at the creation of the release tarball.  Perhaps it was
determined that a two-prong approach would garner less suspicion.  I
have also read that this entity began a campaign to get the latest lzma
release into distributions quickly.  That kind of behavior will now
raise suspicions due to this event.  When a developer believes that
distributions should update ASAP they likely better have a CVE issue at
hand or expect their work to be more carefully audited.

> I think anyone buying into systemd-blaming here needs to have a good
> hard look at their biases. Which is another part of this massive
> social problem. It's such a distraction. And here we are in a thread
> that started with a bug in a 30+ year old setgid binary.

We all carry biases.  I've no idea of Jacob Bachmeyer's bias toward
systemd, if any, other than "katamari" apparently refers to a Japanese
video game I know absolutely nothing about. How that relates, good or
bad, I have no idea.  I will say that I have been satisfied with its
implementation over several Debian releases but that is because I trust
Debian more than upstream.

Upstream systemd has not done itself many favors over the years WRT
community interaction.  I think that developers would be wise not to
follow the systemd project's path with their own endeavors.  I do find
systemd useful and even enable some of the optional features on my
Debian systems.  It works well enough and the commonality of
configuration style between the optional components is helpful.

Unavoidably, systemd is going to get a bit of bad press here simply
because of its service manager role that enabled the C creating a
vulnerability in A scenario.  The upshot is that patches to
openssh-portable applied by Debian might move away from linking in
libsystemd if I read that LWN thread correctly.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 31 Mar 20:46 -0500, Andy Smith wrote:
> In the xz case the further you go looking for a root cause the wider
> the implications are:
> 
> Q: Why was there a back door in sshd?
> A: Because some malicious code was linked to it.
> 
> Q: How did malicious code get linked to it?
> A: Its lzma dependency was compromised.

From what I have read, lzma is not a direct dependency of openssh.  It
turns out that it lzma is a dependency of libsystemd and that
relationship affected openssh.

Jacob Bachmeyer in analysis
(https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
says:

Lastly on this topic, some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and ended up getting
xz-utils targeted as a means of getting to sshd without the OpenSSH
maintainers noticing.

End quote.

> Q: Who compromised the lzma dependency?
> A: One of the developers of that project who had full rights to
> commit code to it.
> 
> Q: Why did a persona that no one knows anything about get full
> access rights to a code repository that is linked to openssh?
> A: Because they did some work over a period of years that looked
> genuine and the single other developer who was overwhelmed with work
> decided to give them access based on that
> 
> Q: Why did lzma, a dependency of openssh, have a single overwhelmed
> developer?
> A: Because no one felt the need to pay a team of developers to work
> on it or audit work on it.

As Jacob notes, lzma is apparently not a direct dependency of openssh
which makes this story even more incredible.  Now we have to consider
the implications of patches to software that are related in non-obvious
ways.  Our systems are currently very complex and that complexity leads
to vulnerabilities in software that is not obviously linked.  Pretty
scary stuff, actually.

> Society demands that open source developers work, often for free,
> and that they merge contributions. If they push back and say they
> are unable to due to workload then they are encouraged to seek help
> by adding more committers. That's what apparently happened here: the
> attacker(s) seemingly counting on the pressure that would exist to
> give them rights within the project. It is hammered in to open
> source developers over and over:
> 
> Allow others to contribute, or even to take over, if you are too
> busy. It's the right thing to do.
> 
> We have now seen proof of what has long been theorised: that the
> above way of working is very vulnerable to attackers who are willing
> to put in some effort, and that "enough eyes make all bugs shallow"
> doesn't hold true unless the process is actually providing those
> eyes.

"Jai Tan" was somewhat patient at playing the long game it would appear.
The developer spent a lot of time and effort twisting the Autotools
build system into something that could hide the needed code.

You're absolutely correct, Andy, working its way deep into the project
while simultaneously planning to compromise it enabled the developer to
build a near disastrous back door.  It was also a very clever effort as
apparently the interaction of openssh, systemd and lzma were studied
carefully and understood to the level that choosing lzma as an attack
vector would likely go unnoticed as the relationship is apparently
non-obvious (though I've skimmed through the analysis my hobbyist coding
skills aren't up to the challenge of understanding this in its
entirety).

> I have no answers on how to fix such a deep-rooted societal problem
> but I am not going to start yelling obscenities at people on public
> mailing lists because they are wanting to discuss a CVE or whatever.

At the end of the day this is about trust.  The compromising developer
apparently set out from the start to exploit the trust of the main
maintainer and the overall community.  The sad part is, to me at least,
that the effort to analyze and understand the non-obvious relationship
of openssh, systemd, and lzma and then use that to create a back door
into openssh could have been used to improve security and create better
software.

Another hard lesson is that contributions are not always based on the
ideal of altruism that we in the "western world" hold dear.

BTW, I don't want to start a systemd bashing subthread, but I think it
bears some scrutiny give this latest event (disclaimer, yes I use
systemd as PID 1 on Debian Stable).

Finally, I am still involved with a project (hamlib) that is packaged in
many distributions.  I had to pull back several years ago and turn over
the day to day operations to a developer I came to trust.  For my own
part I became the administrator of the project after the original
developers had moved on and I was almost the most senior active
developer left.  Patches were backing up and someone needed to take
action so I did.

Your 

Re: shellcheck, bashism's and one liners.

[Nate Bargmann]

Hi Tim.

What errors do you get if you use sh instead of bash?  On Debian systems
sh should be a symbolic link to dash.  On Debian dash is preferred for
system shell scripts (perhaps even required now) and I use it for my
personal scripts unless there is some need to use bash instead.  I still
use bash for my login shell.

I've used shellcheck to point me in the right direction and figure that
if dash runs the script without errors then it's close enough to POSIX
compatible for my needs.  I don't anticipate my scripts needing to run
on some ancient Unix shell.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: rec recording, Re: Upgrade to Bookworm, now GNOME keyring dies …

[Nate Bargmann]

* On 2024 21 Feb 12:42 -0600, David Wright wrote:
> On Mon 19 Feb 2024 at 13:26:17 (-0600), Nate Bargmann wrote:
> > 
> > After seeing this twice this morning I recalled that I have a cron entry
> > to kill the 'rec' program.  This was to break up audio files into hourly
> > segments when recording an amateur radio event.  This was the cron
> > command:
> > 
> > # Rotate sound recorder files
> > 00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null
> > 
> > On a hunch I commented that line and Voila! the daemon ran through the
> > next hour change and is still running as expected.  The man page states
> > that the '-f' option matches against the full command line, not just the
> > process name.  So, looking at the gnome-keyring-daemon command line:
> > 
> >1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
> > --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
> > 
> > I see that the 'rec' in 'directory' provided the match!  Confirmed with
> > pgrep:
> > 
> > $ pgrep -f rec
> > 1857
> > 
> > It looks like the solution for the future will be to change the cron
> > line to:
> > 
> > 00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null
> 
> I can't get that to work here. When I kill rec, it just dies. Is pkill
> sending SIGTERM, which appears to be the default? Nor can I find this
> documented—though the sox docs are lengthy, so I might have missed it.
> 
> I can use SIGUSR1 with arecord, and that works perfectly.

It gets restarted by a script called by the 'tlf' amateur radio logging
program.  The script is:

https://github.com/Tlf/tlf/blob/master/scripts/soundlog

It's a hack!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

Well, it appears like most things in life this one was self inflicted.
郎

Yesterday I was working on another project and to verify something was
occurring the 'strace' utility was recommended.  It dawned on me that
this could help me get a clue as to what was happening to the
gnome-keyring-daemon.  Using strace attached to the PID of the daemon
after a reboot showed it was getting the SIGTERM signal at exactly the
top of the hour.  What?!!

After seeing this twice this morning I recalled that I have a cron entry
to kill the 'rec' program.  This was to break up audio files into hourly
segments when recording an amateur radio event.  This was the cron
command:

# Rotate sound recorder files
00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null

On a hunch I commented that line and Voila! the daemon ran through the
next hour change and is still running as expected.  The man page states
that the '-f' option matches against the full command line, not just the
process name.  So, looking at the gnome-keyring-daemon command line:

   1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring

I see that the 'rec' in 'directory' provided the match!  Confirmed with
pgrep:

$ pgrep -f rec
1857

It looks like the solution for the future will be to change the cron
line to:

00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null

When I want to use it next in order to protect other processes.

I certainly hope this is resolved.  OTOH, it forced me to recall a
number of passwords!  藍

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: hexchat being discontinued?

[Nate Bargmann]

* On 2024 10 Feb 22:31 -0600, Dan Ritter wrote:
> Default User wrote: 
> > Well, it seems that hexchat is being discontinued. 
> > IMHO, it is/was the only IRC client that was actually usable. 
> > 
> > Any recommendations for a GOOD alternative?
> 
> I like weechat. Some people like quassel.
> 
> Hexchat is packaged in bookworm, so there's no reason for you to
> panic until it's removed.

Some packages can be kept around for a long time after they've been
removed from 'main'.  The dependency chain and any conflicts with newer
libraries will dictate success or failure.  I've often "held" a package
('=' in the aptitude UI) to keep from losing it and eventually it and
what it depends on are placed in the "Obsolete and Locally Created
Packages" section of the aptitude UI.

When Groff 1.23 hits in Trixie, I know that an included utility called
"groffer" will be removed.  To keep it I will copy it over from the
cloned groff repository I have locally.  Sometimes a man's gotta do what
a man's gotta do...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: what keyboard do you use?

[Nate Bargmann]

* On 2024 04 Feb 11:57 -0600, Michael Kjörling wrote:
> On 4 Feb 2024 11:36 -0600, from n...@n0nb.us (Nate Bargmann):
> >> Unicomp[1] still makes these keyboards, and you can get them for USB.
> > 
> > I don't like their swapping of the right Alt and Menu keys unless the
> > keyboard can be configured to swap them back.
> 
> The keyboard doesn't care what's printed on the key caps; that should
> be purely a software configuration issue.
> 
> If you contact them and ask, they can probably tell you whether the
> key caps are of identical size for the two keys you have in mind for
> the particular keyboard configuration you're interested in, and thus
> can be flipped physically. Past that I expect it involves some Xmodmap
> trickery (or maybe treachery) to flip the mapping of the scan codes.

xmodmap trickery?  I am running GNOME on Wayland.  Maybe this
combination has a way to remap keys but that's not something I've been
inclined to do.  The daskeyboard suits me fine and I plan to just stick
with it.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: what keyboard do you use?

[Nate Bargmann]

* On 2024 04 Feb 04:23 -0600, hw wrote:
> On Fri, 2024-02-02 at 20:09 -0600, Nate Bargmann wrote:
> > [...]
> > I have several of the now classic IBM Model M keyboards I procured in
> > the '90s.  Modern BIOSes don't like them even with a PS/2 to USB
> > adapter so I gave up on them.
> 
> They might work with a so-called active adapter.  IIRC it has
> something to do with the adpater suppling power.  With some research
> and an investment of like $5, you can probably still use your
> keyboards.

As I use GNOME, I need the left menu key as I have the hotspot disabled
to open the overview.  My old Model Ms lack that key.

> Unicomp[1] still makes these keyboards, and you can get them for USB.

I don't like their swapping of the right Alt and Menu keys unless the
keyboard can be configured to swap them back.  Otherwise, I would prefer
the right Menu key in that position be removed and that area given back
to the Space bar.  I don't find any documentation on their Web site
about that capability.

I do like about the Daskeyboard is that instead of being the right Menu
key that key is a Function key much like a laptop and it activates media
control keys on several of the function keys.  It's quite handy to raise
or lower the speaker volume when playing a video full screen.

> I'm using one right now (with 122 keys), and among all the different
> keyboards I used over the last 40 years, I've never found anything
> better than these buckling spring ones.

No question.  The M is the ultimate but unless someone can point me to a
document that shows swapping those two keys, I won't be buying.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: what keyboard do you use?

[Nate Bargmann]

* On 2024 02 Feb 19:26 -0600, Lee wrote:
> I bought a Dell desktop in 2019 and the keyboard just died :(
> 
> ssh in from another machine & do a 'sudo reboot now' and get an alert
> about 'Keyboard not found.'  on power up.  The keyboard also doesn't
> work in another machine so it's really & truly dead.
> 
> I figure there's a high percentage of keyboard jockeys here so ..
> which keyboard do you like and why?

I have several of the now classic IBM Model M keyboards I procured in
the '90s.  Modern BIOSes don't like them even with a PS/2 to USB
adapter so I gave up on them.  The Lenovo KU-0225 is a good keyboard
with the "standard" extra keys that are useful in some desktops.  It is
full size and quiet.

My main keyboard is a daskeyboard I bought several years ago with the
Cherry key switches  It is thick so you might not like it and it is
loud.  It has the same number of keys as the Lenovo, 104, I think.  This
one was not cheap while the Lenovo was considerably less expensive.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone]

[Nate Bargmann]

* On 2024 06 Jan 22:27 -0600, gene heskett wrote:
> On 1/6/24 17:06, Nate Bargmann wrote:
> > * On 2024 06 Jan 14:34 -0600, gene heskett wrote:
> > > On 1/6/24 14:33, John Hasler wrote:
> > > > Try manpages.org .
> > > 
> > > That is downright tasty stuff, bookmarked, thank you John.
> > 
> > For us Debian users a better choice would seem to be:
> > 
> > https://manpages.debian.org/
> 
> The pages at manpages.org are better colored and a larger, much easier to
> read font. Content I believe, was the same on the file I cheked.

If so, you were fortunate to find a page that matched that installed on
your system.  The manpages.org link won't have pages for some third
party packages that manpages.debian.org will.  For example, the former
does not have a page for 'hamlib' and the latter does.  In Debian it is
a bug if a package does not have a man page so you will find many more
at the manpages.debian.org link.

Also, the text size of a Web page can be increased with Ctrl-+ (works on
Firefox and Chromium, likely others).

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone]

[Nate Bargmann]

* On 2024 06 Jan 14:34 -0600, gene heskett wrote:
> On 1/6/24 14:33, John Hasler wrote:
> > Try manpages.org .
> 
> That is downright tasty stuff, bookmarked, thank you John.

For us Debian users a better choice would seem to be:

https://manpages.debian.org/

The only thing is that I don't see a category for oldstable and
oldoldstable, etc.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: tzdata-legacy [was: Re: systemd and timezone]

[Nate Bargmann]

* On 2024 06 Jan 01:00 -0600, Max Nikulin wrote:
> US/Eastern & Co has been moved to tzdata-legacy as well. Currently used
> identifiers are based on cities: America/New_York.

Ugghhh!

I guess I'll be going to the legacy package then until
$WHOEVER_IS_IN_CHARGE issues a decree that it too shall be eliminated.
I really don't get the fascination with some city hundreds of miles
distant defining the time zone.  Why Chicago for US/Central?  There are
any number of cities in US/Central that could be referenced, but no,
pick the most notorious one--rolls eyes.

I could even accept America/Central without complaint.  Yeah, US is a
directory and Central is a symlink to ../America/Chicago that could be
manually added to a system if need be.

Ambles off shaking fist at a cloud...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: systemd and timezone

[Nate Bargmann]

* On 2023 22 Dec 15:34 -0600, Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:
> > 1. https://bugs.debian.org/803144
> > 2. https://bugs.debian.org/346342
> 
> Wow, OK.  Fascinating historical context in there.
> 
> I've updated .  I believe it's
> correct now, for both current and historic systems, although I can't
> swear to the pre-Etch stuff.

At the risk of being a pedant.  I find the text of the paragraph that
begins:

In Debian releases between Etch and Jessie,

in the Check Configured Timezone section to be potentially confusing.
To me the word "between" often means a range that is exclusive of its
end points, e.g. "between the lines".

Would this be better worded as:

In Debian releases beginning with Etch and ending with Jessie,

or would:

In Debian releases between Etch and Jessie (inclusive),

be good enough?

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: IMPORTANT: do NOT upgrade to new stable point release

[Nate Bargmann]

Thanks for the tip.  I updated this morning well before any
announcements and having seen this I rebooted into the 6.1.0-12 (6.1.52)
package.  Good thing old kernels are kept around.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: used vs. unused packages installed

[Nate Bargmann]

For this sort of thing I prefer the aptitude TUI.  Highlight the package
in question and hit 'r' and the list of reverse dependencies appears.
Installed packages will be in bold (also bright white with my terminal
settings).  One can continue up the chain by highlighting one of the
installed reverse dependencies and pressing 'r' again, and so on.

Another trick I have used is to use 'M' to mark the package as
automatically installed, if nothing depends on it then it will be marked
for removal.  Be careful here as a manually installed top level package
you might want to keep such as vim will be marked for removal and all
packages that were automatically installed with it.  To reverse the
proposed removal action, use 'Ctrl-u'.

While I often use apt at the command line, I've been using aptitude
since early 2001 and often prefer its TUI for doing drastic things!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Sunrise and Sunset from terminal

[Nate Bargmann]

If you don't want to scrape a Web page, or want this information when a
network is not available, the hdate package will do (referenced from:
https://unix.stackexchange.com/a/527031).

Here is an example for Topeka, KS:

$ hdate -l N39.034722 -L W95.695556 -s -z -5
Saturday, 23 September 2023, eve of 9 Tishrei 5784
sunrise: 07:10
sunset: 19:18
hdate: ALERT: The information displayed is for today's Hebrew date.
  Because it is now after sunset, that means the data is
  for the Gregorian day beginning at midnight.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

* On 2023 14 Aug 21:29 -0500, Max Nikulin wrote:
> On 14/08/2023 07:30, Nate Bargmann wrote:
> > Now, while typing this email all keyring PIDs have vanished!
> 
> It may be a way to minimize RAM usage.

I don't think so.  It has been persistent in the past in Buster and
Bullseye with GNOME and is persistent on the laptop which is also
running Bookworm and GNOME.  On this desktop it will rather reliably
shutdown/crash about exactly an hour after logging in with no other
desktop activity, i.e. not opening browsers or other apps.

> The agent may be a socket-activated
> process.
>
> systemctl --user list-sockets

The lists are virtually identical between the laptop:

$ systemctl --user list-sockets
LISTEN   UNITACTIVATES  
 
/run/user/1000/bus   dbus.socket 
dbus.service
/run/user/1000/gcr/ssh   gcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngr   dirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extra   gpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/control   gnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native  pipewire-pulse.socket   
pipewire-pulse.service

11 sockets listed.
Pass --all to see loaded but inactive sockets, too.

and the desktop:

$ systemctl --user list-sockets
LISTENUNITACTIVATES 
  
/run/user/1000/busdbus.socket 
dbus.service
/run/user/1000/gcr/sshgcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngrdirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent  gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser  gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extragpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh  gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/controlgnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0 pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket  pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native   pipewire-pulse.socket   
pipewire-pulse.service
/run/user/1000/snapd-session-agent.socket snapd.session-agent.socket  
snapd.session-agent.service

12 sockets listed.
Pass --all to see loaded but inactive sockets, too.

On the desktop gnome-keyring-daemon has not been running for several hours.

> Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue what
> is really happening in your case.

On both systems that environment variable is:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

> I suggest you to add "f" option to "ps" to see process tree. It may help to
> find details concerning starting of particular agent.

At this point I know the agent will be working normally when I first log
into gnome-shell.  This has been a reliable way to get it started. I
posted to the GNOME discourse about this and was advised to open
separate issues in the keyring Gitlab repository.  They are:

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/135
"gnome-keyring-daemon shutting down on Debian 12 shortly after logging
into GNOME Shell "

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/136
"gnome-keyring-daemon fails to restart properly on Debian 12 "

Last night I did some testing with gdb and put my results in issue #135.
In this case the daemon crashed when I logged out of another system,
well short of the hour it will run if left idle.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Safing.io

[Nate Bargmann]

* On 2023 26 Aug 14:27 -0500, Tom Browder wrote:
> I was watching a Linux distro video on YouTube this morning, and one of the
> sponsors was Safin.io which hosts a multi-capability firewall and network
> management device available for download. It looks interesting to me, a
> firewall-challenged sys admin hobbyist.
> 
> Has anyone tried it? It sounds great, even the free version.

I've not heard of it, but that's not surprising.  I prefer OpenWRT as it
is a project similar in the vein of Debian.  I shy away from single
points of failure if at all possible.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Please verify Gnome and KDE wiki articles for correctness

[Nate Bargmann]

* On 2023 26 Aug 07:57 -0500, Greg Wooledge wrote:
> On Sat, Aug 26, 2023 at 07:40:46AM -0500, Nate Bargmann wrote:
> > * On 2023 26 Aug 07:13 -0500, Anssi Saari wrote:
> > > Nate Bargmann  writes:
> > > 
> > > > This Wiki is semi-private in that editing is not open to just everyone
> > > > but may only be done through an account (apparently I have one and now
> > > > have to figure out how to reset my password).
> > > 
> > > Good for you. I tried creating an account but after putting in name
> > > password and email it says no, send email to w...@debian.org instead. I
> > > think I'll pass. While I have KDE on one Debian machine, I don't use it
> > > much so not that much to contribute.
> > 
> > I was able to successfully change my password and update my Wiki home
> > page a little while ago.  It has been a long time since I created the
> > account and don't recall what the process entailed.
> 
> If I recall correctly, it used to be possible to create an account with
> the standard wiki mechanisms, but that was discontinued due to spammers
> abusing it.  So, those of us who happened to create an account in the
> early days got to do it the easy way, but now any new accounts need to
> be approved by the wiki admins.

I think you're right.  Given the text I updated in my profile/Wiki home
page I'm guessing I created the account ten to fifteen years ago.  At
least Firefox still had the username stored with an expired password
otherwise I'd forgotten all about it!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Using the bash shell: determine if the root user used 'sudo -i'

[Nate Bargmann]

* On 2023 26 Aug 11:10 -0500, Tom Browder wrote:
> On Sat, Aug 26, 2023 at 10:57 Greg Wooledge  wrote:
> 
> > On Sat, Aug 26, 2023 at 10:49:45AM -0500, Tom Browder wrote:
> > > I would like to know whether 'sudo -i' or 'sudo -s' was used.
> 
> ...
> 
> > In fact, I suspect "I need to know if the cwd is /root" is STILL an X-Y
> > problem.  It's sounding like "I need to ensure my script's working
> > directory is /foo".  If that's truly the case, just do "cd /foo || exit"
> > at the top of the script.
> 
> ...
> 
> Excellent mind-reading, Greg! So to use your line I will put in that dir:
> 
> "cd /required-dir || exit"

In such cases I prefer specifying the complete paths in the script so as
not to get lost.  If the script needs to work in a specific directory of
root I'll put:

cd /root/dir/dir1

or something like:

cd /home/username/dir

and so on (adding whatever error recovery is needed).

If I need to source a file I just type in the complete path name.  It's
a one time bother and the executing shell doesn't care and as the script
gets more complex it's much easier to keep one's bearings on where the
script is working at various points.

As I see it, relative paths are more for interactive shell use.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Please verify Gnome and KDE wiki articles for correctness

[Nate Bargmann]

* On 2023 26 Aug 07:13 -0500, Anssi Saari wrote:
> Nate Bargmann  writes:
> 
> > This Wiki is semi-private in that editing is not open to just everyone
> > but may only be done through an account (apparently I have one and now
> > have to figure out how to reset my password).
> 
> Good for you. I tried creating an account but after putting in name
> password and email it says no, send email to w...@debian.org instead. I
> think I'll pass. While I have KDE on one Debian machine, I don't use it
> much so not that much to contribute.

I was able to successfully change my password and update my Wiki home
page a little while ago.  It has been a long time since I created the
account and don't recall what the process entailed.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Please verify Gnome and KDE wiki articles for correctness

[Nate Bargmann]

* On 2023 25 Aug 23:57 -0500, Jeffrey Walton wrote:
> On Fri, Aug 25, 2023 at 3:50 PM Greg Wooledge  wrote:
> >
> > On Fri, Aug 25, 2023 at 01:26:29PM -0400, Jeffrey Walton wrote:
> > > Two of the wiki articles that will help with a migration to Debian are
> > >  and .
> > >
> > > It would be helpful if folks with Gnome and KDE experience would look
> > > over the articles and provide corrections and updates.

In order the help the OP since I apparently deleted this thread when it
started, the GNOME page looks reasonably accurate.  I do not have AMD
hardware so I cannot comment on that section.

The mouse cursor theme can be changed through the Tweaks GUI, but that
only takes effect once GNOME Shell actually starts and doesn't affect
gdm, as I understand it.

> > You're kinda asking the wrong crowd.  A significant portion of the
> > active posters on this mailing list use neither of those things.
> >
> > This probably explains the state of the wiki pages as well, if one
> > assumes that the users of this list correlate with the wiki editors
> > to a certain degree, at least in terms of desktop choices.
> 
> Yeah, it's hit or miss.
> 
> But I disagree with your assessment. I am proof by counter-example. I
> use KDE, and I've made some edits to the KDE article. I'm guessing
> there will be other folks on the list who could make edits. Or this is
> an extremely small list.

I've been a Debian user and member of this list for quite a long time,
since the late 1990s at least.  In all that time I don't recall the
Debian Project approaching this list requesting our assistance in
updating/maintaining the Wiki.  This Wiki is semi-private in that
editing is not open to just everyone but may only be done through an account
(apparently I have one and now have to figure out how to reset my
password).

The Wiki front page is rather adamant that addition of content to the
Wiki by everyone is welcome and desired.  In particular solutions are
provided on this list that should make it onto the Wiki.  I'm not
volunteering for that "job" but it is something we might all consider in
the future.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Favicon Firefox

[Nate Bargmann]

* On 2023 21 Aug 06:53 -0500, Greg Wooledge wrote:
> On Mon, Aug 21, 2023 at 01:24:27PM +0200, Hans wrote:
> > Am Montag, 21. August 2023, 13:04:00 CEST schrieb Michael Kjörling:
> > > On 21 Aug 2023 12:31 +0200, from hans.ullr...@loop.de (Hans):
> > > > does someone know, where firefox-esr in debian does store its favicons?
> > > 
> > > Might that be "favicons.sqlite" in the profile?
> > 
> > Hmm, this is not existant. However, I am not sure, this is existant at all. 
> > Other sources claim some files below .mozilla, but all these are related to 
> > Windows. Yes, many settings are equal in linux, but sometimes linux does 
> > handling of files other than in Windows.
> 
> Peculiar.  I have one.
> 
> unicorn:~$ find .mozilla -name favicons.sqlite -ls
>   1047247   6020 -rw-r--r--   1 greg greg  6160384 Aug 20 20:18 
> .mozilla/firefox/0uik3i3z.default/favicons.sqlite

As do my systems.

Taking a wild guess, presumably cleaning the cache removed the icon
files that the DB is still referencing and not requesting being
downloaded.  In all likelihood it is safer for the OP to let the browser
manage the cache rather than a third party app.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Nate Bargmann]

For a proportional font, Verdana, Regular seems to come close with, it
seems to me, good differentiation between l, I, and 1.  O and 0 are a
bit problematic as 0 is not dotted or slashed but is more of an ellipse.

On this GNOME desktop the interface is set to Cantarell, Regular, and
while it has a small serif at the bottom of l, I is simple vertical
line, and 1 has the customary serif at the top.  O and 0 are not well
differentiated except 0 being a slightly narrower oval.

There are times when I've pasted something like a random character
combination password into a terminal just so I could see what the exact
characters are.

In my terminals I have switched to Fira Code, Regular as well as in the
GNOME settings.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: is it unusual that 12.1 is released so soon after 12?

[Nate Bargmann]

* On 2023 17 Aug 05:15 -0500, hlyg wrote:
> Thank  Andrew, Michael and Joe!
> 
> it seems that x.1 are really stable while x are beta release

And .2, .3, etc. are even more stable by that metric.  Best to wait for
12.7 or later then.  In the mean time the rest of us have work to do
with the updated tools.

Sometimes even the first point release will catch us unawares as with
gnome-keyring-daemon crashes/restarts not long after logging into GNOME
on this desktop system.  So far this only affects one system of mine
running Bookworm and not the other.  It could be a glitch of my making
but I'm unaware of anything I did to cause the keyring applet problems
where it was working without issue on Bullseye and Buster previously.

If Bullseye is working for you, then you may want to wait until such
time as it will no longer receive security updates.  Unlike other
systems, Debian doesn't force anyone to upgrade.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Happy 30 Years Debian Project

[Nate Bargmann]

Happy anniversary indeed.

30 years for anything is a significant milestone particularly an all, or
nearly all, volunteer project that doesn't have a single person who is
the benevolent dictator for life but instead has had a number of elected
project leaders over that time.  This is very much an accomplishment and
all involved may take a well deserved bow.

My personal foray into Debian began 24 years ago next month, as I
recall.  I installed Slink from a pile of floppies onto a castoff IBM
Thinkpad 760ED.  Most everything worked except for the internal modem
and sound as both were tied to a proprietary DSP that never had support
added to the kernel.  In January 2000 I replaced the by that time
obsolete libc5 based Slackware '96 installation on my desktop and was
running the soon to be stable Potato in short order.

I wish I could say that those original installations had been upgraded
and migrated uninterrupted over the intervening years but I did distro
hopping yet always came back to Debian and also bumped up to amd64 along
the way.

Here's to many more anniversaries.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

I now have two desktop systems running Bookworm with GNOME.  The laptop
was upgraded last month and I upgraded the desktop this afternoon.  I
have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.

Some time after the upgrade I wanted to SSH into one of the other
systems on my LAN and was greeted with a password prompt for the
corresponding public key that had prior been managed by the keyring
applet.  I noted differences in the running processes between the laptop
where the keyring applet is still working and the desktop where it was
not.

On an off-chance I cold booted this system and found the keyring applet
was working as expected so I went on doing other things for a while.
Then I tried again and was prompted for the public key's password.
Uggh.

Right after rebooting the process list looked like this which mirrors
the laptop:

$ ps ax -u nate | grep "agent\|keyring"
   2037 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
   3802 ?S  0:00 /usr/bin/ssh-agent -D -a 
/run/user/1000/keyring/.ssh
   3922 pts/0S+ 0:00 grep --color=auto agent\|keyring

When I began this mail things looked like this:

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  12324 ?Sl 0:00 /usr/bin/gnome-keyring-daemon --start --foreground 
--components=secrets
  12325 ?Ssl0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
  19308 pts/0S+ 0:00 grep --color=auto agent\|keyring

It appears to me that gnome-keyring-daemon has been restarted for some reason.
As a result PIDs 2037 and 3802 are terminated and also
/run/user/1000/keyring/.ssh is no longer present along with the pkcs11 and ssh
files in the same directory.

I don't see anything out of the ordinary, in fact, these packages are
the same on the desktop and laptop systems:

debian-archive-keyring/stable,stable,now 2023.3 all [installed,automatic]
fasttrack-archive-keyring/stable,stable,now 2020.12.19 all [installed]
gnome-keyring-pkcs11/stable,now 42.1-1+b2 amd64 [installed,automatic]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
gpg-agent/stable,now 2.2.40-1.1 amd64 [installed,automatic]
libpam-gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3 amd64 [installed,automatic]

Now, while typing this email all keyring PIDs have vanished!

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  22418 pts/0S+ 0:00 grep --color=auto agent\|keyring

I am flummoxed.

TIA

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wireless temperature & humidity measurement

[Nate Bargmann]

* On 2023 14 Jul 02:37 -0500, Bruno Kleinert wrote:
> Hello,
> 
> I'm looking for a wireless way to measure temperature and humidity
> indoor with hardware off the shelf and software included in Debian 12
> bookworm.

Off the shelf the Davis Vantage Pro 2 is probably one of the most
popular.  I have one and the Integrated Sensor Suite (ISS) is placed
about 100 meters from the console.  Davis claims nearly 300m (1000 feet)
of distance between the ISS and console, but obstructions will surely
limit that.  The big problem with the Davis is that to get the interface
adapter one must buy their software package.  There are some independent
sources of interfaces (called loggers) which can be found mentioned at
the wxforum.net[1].

> Sensors --> Radio --> Receiver --> Any typical PC interface, e.g., USB,
> Ethernet.
> 
> I don't need a visual interface, but plan to process measured values in
> shell scripts.

For software I use Weewx but it is not part of the Debian repositories
but does have a Debian package available.[2]  I have been using this
package for several years and am running the latest release of 4.10.2.
My data is uploaded to Weather Underground[3], CWOP [4](Citizens Weather
Observation Program) and my own Web host[5][6].  I've customized the
generated pages with additional images.  Weewx also supports supplying
data to other providers as well.  It is quite flexible.

> Do you have any hardware recommendations and can you share experience?

The Davis VP2 is likely among the most turnkey of stations available.
It does not have serial/Ethernet output included so that must be sourced
either through buying the Davis software package or from a third party.
Prior to the Davis I had a Peet Bros wired system but it caused and was
subject to interference to/from my amateur radio operations.  I've had
no interference problems with the Davis.

I recently did a bit of refurbishing of my ISS by replacing the tipping
spoon with a new design and replacing the anemometer sensing cartridge.
Those parts were easily sourced through Scaled Instruments[7].  They
carry complete stations for many brands as well as parts.

The aforementioned wxforum.net is a good place to seek out better
answers to your questions.

HTH,

- Nate

[1] https://www.wxforum.net/index.php?board=59.0
[2] http://weewx.com/
[3] https://www.wunderground.com/dashboard/pws/KKSBREME2?cm_ven=localwx_pwsdash
[4] http://www.findu.com/cgi-bin/wxpage.cgi?call=n0nb
[5] https://www.n0nb.us/weather/
[6] https://www.n0nb.us/weather/seasons/index.html
[7] https://www.scaledinstruments.com/

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: why bookworm isn't called deb12?

[Nate Bargmann]

* On 2023 07 Jul 12:59 -0500, to...@tuxteam.de wrote:
> There is lots of cross-pollination, though. Before the advent of Clang
> there weren't many credible alternatives to the GCC toolchain; I don't
> think any BSD sysadmin worth their salt would renounce using rsync just
> because it's GPL. Conversely, ssh is probably one of the nices gifts
> BSD gave to the GPL folks. PostgreSQL is a wonderful thing and is,
> again, BSD.
> 
> So, thanks to both :)

Oh, absolutely!

What I like about the majority of the Linux ecosystem is that it has a
rather low level of dogma.  To be sure, I prefer Free Software and any
code I've contributed over the years has been under one sort of copyleft
license or another.  Debian, like all of the major distributions, pull
software from many sources.  There is no such thing as a "pure" Linux
distributions as they're all collections from many projects.  Probably
the most dogmatic distributions are Trisquel and Guix but I doubt they
have the NIH attitude I sense from OpenBSD.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: why bookworm isn't called deb12?

[Nate Bargmann]

* On 2023 07 Jul 09:12 -0500, BRN wrote:
> I could be accused of nitpicking here, however; I'd suggest that GNU was
> inspired by the original UNIX rather than being a clone.  A clone in
> the original biological context refers to an exact genetic copy - "byte
> for byte" if you like.

That is probably why the term "bug-for-bug" came about as
"byte-for-byte" would prove quite problematic in a copyright dispute.

> As for the *BSDs; OpenBSD most certainly does *not* rely on a GNU
> framework.

Indeed, most of the work on BSDs these days is to excise as much GNU
from their systems as they can (I don't follow their development
closely, it's just the impression I get).

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: why bookworm isn't called deb12?

[Nate Bargmann]

* On 2023 07 Jul 08:13 -0500, jeremy ardley wrote:
> 
> My error:
> 
> I should have said
> 
> "Linux is a clone of Unix so a derivative. MS is also a derivative but not
> much like Unix. "

If you mean MS Windows NT and later, it apparently owes much to VMS and
OS/2.  Certainly, some POSIX support was added along the way as well,
but I don't think that other than market speak 20+ years ago, Windows
NT+ was intended to be a Unix implementation.

> I should also have noted FreeBSD and other clones of Unix that also rely on
> a GNU framework

Actually, the BSDs have a rightful claim to be true descendants of AT
Unix and not clones or derivatives.

I also have a hard time calling GNU or Linux "clones" as they are
independent work-alike implementations but not bug-for-bug clones of
AT Unix or BSD.

Pedants R Us...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: why bookworm isn't called deb12?

[Nate Bargmann]

* On 2023 07 Jul 06:54 -0500, fxkl4...@protonmail.com wrote:
> > Microsoft for good or bad has made major advances in
> > software and is responsible for a fair fraction of what we experience in
> > our Linux world.
> 
> true
> if microsoft had ever produced a decent product
> linux may not have ever become as popular as it is

What MS has done has never been relevant to the creation of GNU, X, or
the Linux kernel.  GNU has always been a project to develop RMS' vision
of a Unix compatible system.  The Linux kernel came about because even
though Linus had access to Minix, Tanenbaum had no interest in applying
the patches Linus, et. al. wanted to apply to make it a more general
system.  Linus was only interested in a Unix he could afford and since
GNU lacked a kernel that is what he focused on.  MS was never part of
the focus regarding the creation of GNU or Linux.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: bookworm upgrade report: boring

[Nate Bargmann]

* On 2023 14 Jun 03:24 -0500, Vincent Lefevre wrote:
> On 2023-06-13 13:41:23 -0500, Nate Bargmann wrote:
> > I have always chickened out on that option.  Looking at the ucf man page
> > and the description of the three-way merge it looks like the user would
> > have a yes or no option but no edit option.
> 
> One can always run an editor from a shell.

Sure, but one has to carefully note the available file names in case one
is a temp file as the ucf man page discusses.  I don't know enough about
dpkg's handling of such files to know if the correct one will be edited.
Much easier for the package manager/debconf to be extended to handle
this step.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: bookworm upgrade report: boring

[Nate Bargmann]

* On 2023 13 Jun 10:01 -0500, Vincent Lefevre wrote:
> On 2023-06-13 06:41:41 -0500, Nate Bargmann wrote:
> > I've been experimenting with Arch Linux for some time and one thing I
> > like about its pacman package management system is that it has a tool
> > available named 'pacdiff'.  The details are off topic but in a nutshell
> > what it does is identify a locally modified config and the corresponding
> > new config files and can open them in 'vimdiff' giving a nice display of
> > the diff using the vim editor.  Once the editing is complete there is a
> > final step to discard the new config file or replace the current one
> > with it.  I do like that Debian retains the new file with various file
> > name extensions for future reference.
> > 
> > I know that apt allows for viewing a unified diff of the files, but it
> > has been quite some time since I've been presented with that menu that I
> > don't recall if editing based on the diff is an option.  It certainly
> > seems that calling vimdiff in that situation would be quite easy but I
> > realize that not many are comfortable with vim and would want a more
> > universal editor that I might not like.
> 
> This is not apt, but dpkg, which is rather limited:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=32877
> 
> (yes, 1999).

Apparently no developer interest.

> Some packages offer a 3-way merge, which is very useful. I think that
> in this case, the configuration file handling is done via ucf (the
> possibility of a merge is mentioned in its man page).

I have always chickened out on that option.  Looking at the ucf man page
and the description of the three-way merge it looks like the user would
have a yes or no option but no edit option.

I just completed upgrading my Lenovo T-410 laptop to Bookworm and the
only issue was a broken neovim package (I forgot I even had it
installed).  It needed a new runtime package installed as a dependency
so I had to use 'apt --fix-broken install' for the first time ever in
the nearly 24 years of using Debian.  That's an impressive track record.
However, I don't have any system that has done an in-place upgrade
throughout that time.  This laptop was originally installed when Buster
was Testing in late 2018.

My only real concern was the upgrade of Gnu Cash and that appears to
have been flawless (yes, I have off-site backups).

I've already had experience with GNOME 43 from an Arch Linux
installation on another laptop so the changes aren't too massive for me.
I do wonder how things will work with my dual-head desktop as I use an
extension to have separate workspaces on each monitor.  One of these days
I'll feel brave...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: bookworm upgrade report: boring

[Nate Bargmann]

* On 2023 12 Jun 07:51 -0500, Celejar wrote:
> On Sun, 11 Jun 2023 12:31:31 -0400
> Dan Ritter  wrote:
> > Everything's working. In the end, I didn't make any config
> > changes (left everything as "keep current config").
> 
> This is the part that always stresses me out; I often have changes in
> the default config files that I don't want to lose, but I'm also
> worried about not getting the latest versions of the config files. I
> usually try to accept the new files and manually bring in any important
> changes I've made to the old ones, but this takes time and patience to
> do right, and things can break if not done right :)

I've been experimenting with Arch Linux for some time and one thing I
like about its pacman package management system is that it has a tool
available named 'pacdiff'.  The details are off topic but in a nutshell
what it does is identify a locally modified config and the corresponding
new config files and can open them in 'vimdiff' giving a nice display of
the diff using the vim editor.  Once the editing is complete there is a
final step to discard the new config file or replace the current one
with it.  I do like that Debian retains the new file with various file
name extensions for future reference.

I know that apt allows for viewing a unified diff of the files, but it
has been quite some time since I've been presented with that menu that I
don't recall if editing based on the diff is an option.  It certainly
seems that calling vimdiff in that situation would be quite easy but I
realize that not many are comfortable with vim and would want a more
universal editor that I might not like.

Typically, if it appears that there are major changes to a config file
then I will install the maintainer's version, note it, and edit it for
needed local changes later.  I've been bitten by keeping all of my local
configs in the past so I don't do that any more.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Which Diff tool could I use for visually comparing two text files where Word Wrap is possible?

[Nate Bargmann]

I prefer vimdiff.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: good freedom-respecting computer for running Debian

[Nate Bargmann]

* On 2023 22 Mar 14:06 -0500, Lionel Élie Mamane wrote:
> On Wed, Mar 22, 2023 at 05:11:17AM -0500, Nate Bargmann wrote:
> > Why have you ruled out a system with an integrated Intel GPU?
> 
> Well, I was trying to see if one could get reasonable hardware that
> doesn't have untrustable stuff like Intel ME and AMD PSP, and in
> integrated Intel GPU requires an Intel CPU and thus having an Intel
> ME...

I understand.  I know there was a lot of speculation about it a couple
years back or so but has it been conclusively determined that it acts in
any nefarious manner?  After all, complexity is going to exist at some
layer and managing a modern computer is a complex task.  Do I wish the
hardware were more free?  Yes.  Still, the manufacturers don't seem to
find value in that.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: good freedom-respecting computer for running Debian

[Nate Bargmann]

Why have you ruled out a system with an integrated Intel GPU?  I've been
quite satisfied with the integrated Intel GPUs for quite some time.
They work well with the compositors in Xfce and GNOME.  They don't seem
to have any issues with XScreensaver's 3D modules.  This is the extent of
my 3D experience as I am not a gamer.

My main desktop is a Lenovo M73 i5 based tower and I've had it over
seven years bought as an off-lease model.  The GPU has two ports and
supports dual monitors without issue.  When I read all the torment
people put themselves through with Nvidia, I just shake my head.  As far
as I'm concerned Nvidia is banned from my network.

Yes, I do have non-free firmware packages installed.  I can't say that
they're strictly necessary.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: PDF on debian

[Nate Bargmann]

* On 2023 09 Mar 04:41 -0600, Corey Hickman wrote:
> Hello,
> 
> What's the suggested PDF generator in Debian (without desktop)?
> And is there a VIM plugin for that?

If you really want to be "old school" there is roff handled by Groff in
Debian (most man pages are written in roff using the "man" macro
package).  The groff package includes other macro packages such as the
historical "ms" and "mm" and a much newer package called "mom".  Until
Groff 1.23 is released, the package includes the "groffer" program that
will read the roff file and call the PDF viewer for display or printing.
There are also command options to generate and write a PDF from groff
itself, but I like groffer for printing files I don't need to save the
PDF for.

I have letters along with a letterhead written with "mm" macros and
envelope templates for US #10 and #6 3/4 written in raw roff requests
that I use for printing such documents.  I also edit these files in Vim
and find this to be a fast and relatively lightweight way of doing so.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: ipv6 maybe has arrived.

[Nate Bargmann]

* On 2023 11 Feb 21:30 -0600, David Wright wrote:
> I've read that machines give themselves a 169.254.… address when they
> boot up and can't find a DHCP server. But I never see those addresses
> when I boot up a machine, disconnected or connected. All I see is
> localhost on 127.0.0.1, the machine's hostname on 127.0.1.1, and
> if connected, the 192.168.1.NN address handed out by DHCP.

I've never seen a Debian or other Linux distribution self-assign such an
address, but years back at work MS Windows NT 4.0 machines that could
not reach a network would do so routinely.  It made it easy for me to
simply look at the IP address and know there was some connectivity issue
for that machine.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Fixing errors on a BTRFS partition?

[Nate Bargmann]

Well, I didn't fix the errors, but I was able to use 'btrfs replace' to
move the file system to an external HDD.  The SDD I ordered apparently
is ping-ponging its way from Kansas City to various area post offices
and back again before they get it on the right truck.  Sigh...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Fixing errors on a BTRFS partition?

[Nate Bargmann]

* On 2023 15 Jan 10:07 -0600, Andy Smith wrote:
> Hello,
> 
> On Thu, Jan 12, 2023 at 04:57:07PM -0600, Intense Red wrote:
> > > Everything online hints that attempting repair is particularly
> > > dangerous, but what else am I to do?
> > 
> >You sum up my experience with BTRFS. I too was "scared" off from it and 
> > reformatted my BTRFS partitions and went back to ext4 -- it's a  known 
> > quantity fit for humans with tons of advice of how  to handle 
> > problems/errors.
> 
> I too don't have a lot of love for btrfs, but I think it is a bit
> unfair to criticise it in this scenario, which is a failing SD card
> with no redundancy. If there'd been redundancy then btrfs should
> have noticed the problems and got the data from the other
> copy/copies, but here it had no opportunity to do so.
> 
> In the same situation, ext4 would have just carried on until it got
> read/write errors but this wouldn't have been any better. btrfs got
> the same errors and reported more of its own that it noticed from
> the incorrect checksums.
> 
> It sounds like the OP's use case didn't involve redundancy nor did
> it involve any of the other btrfs features such as compression or
> snapshots, so btrfs probably wasn't a good choice here. ext4 or XFS
> may have been better here just because they are simpler. I can
> understand not wanting to have a learning experience when it comes
> to one's data.

Perhaps this needs to be taken up with the Freedom Box Foundation (it
has close ties to Debian) as it is the image they provide that chose
btrfs to be written to the micro-SD card and used as an appliance on the
Freedom Box Pioneer hardware (Olimex A20-OLinuXino-LIME2).

*I* did not choose this filesystem for this application, just to be
clear.  If there is a better choice for what is intended to be an
appliance running from a micro-SD card, then that should be communicated
to the Freedom Box people.

I have an SSD on order and will rebuild with ext4.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Fixing errors on a BTRFS partition?

[Nate Bargmann]

* On 2023 12 Jan 16:58 -0600, Intense Red wrote:
> > Everything online hints that attempting repair is particularly
> > dangerous, but what else am I to do?
> 
>You sum up my experience with BTRFS. I too was "scared" off from it and 
> reformatted my BTRFS partitions and went back to ext4 -- it's a  known 
> quantity fit for humans with tons of advice of how  to handle problems/errors.

I had experimented with BTRFS some years ago as its virtual partitions
feature is attractive for things like tmp, var, and usr where each is
"separate" but is part of a larger fixed partition.  Choosing proper
sizes is eased somewhat.  Other than that its not my choice, usually.
In this case the card came already formatted with the root partition as
BTRFS so I left it alone.

An SSD is on order.  I still have to use a micro-SD card for the boot
partition as the MICRO cannot boot directly to the SSD as far as I know.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Fixing errors on a BTRFS partition?

[Nate Bargmann]

* On 2023 12 Jan 08:15 -0600, Dan Ritter wrote:
> Nate Bargmann wrote: 
> > I have a Freedom Box Pioneer (hardware is an Olimex A20-OLinuXino-LIME2
> > unit with a Samsung 128 GB micro-SD card.  The micro-SD is partitioned
> > into 2GB boot ext2 and the remainder as the root partition as BTRFS.
> > 
> > The thing has been crashing for months
> 
> For the future: don't let things go this long. I know it's
> tempting to say "maybe it won't happen again", but the second
> time should be the last time before you take action.

At one point I replaced another piece of hardware that was on the same
Ethernet switch as this unit and the crashes cleared up for a while.
Then I suspected a flaky power adapted but haven't addressed it and then
I suspected RF from my amateur radio operations and put the power cord
in a ferrite core with no positive results.  It wasn't until the 'apt
update' GPG failure this morning (the Freedom box image is setup to auto
update) in a manual update attempt that the light bulb lit up.

> > and now it started giving GPG
> > signature errors when trying to run 'apt update'.  I copied the entire
> > micro-SD card to an image file with dd so I have a backup.  Running
> > 'btrfs check' resulted in a lot of errors so I ran the check and
> > directed the output to a file which is over 2MB in size!  The following
> > is a small snippet of what it in the file:
> 
> ...
> 
> > Everything online hints that attempting repair is particularly
> > dangerous, but what else am I to do?  At the moment the system is pretty
> > much useless.
> 
> 
> 1: get a new card, or, much better, replace with a SATA
> SSD. (I see the Olimex has a SATA port. Use it!) Here's a 
> https://www.newegg.com/adata-ultimate-su800-128gb/p/N82E16820215015?Item=9SIAJNUBMB4508
> $29 128GB SSD from a reputable manufacturer.
> 
> 2: Reinstall Debian on the new disk. Don't use btrfs on a
> single-drive system; only use btrfs on a mirrored system. In most cases,
> use ext4.
> 
> 3: copy all the data you can from the image file.

Looks like a plan I will do.  I had an SATA drive on it to begin with
but then decided to just use the micro-SD card.  My guess that a quite
large card with much excess capacity would wear level enough for long
life.  Well, maybe 18 months or so is "long life".

For the record, the Freedom Box micro-SD card image formats the root
partition as BTRFS.  It wasn't a choice of mine.  I've used ext2/3/4 for
many years and that system has always done well for me.

Fortunately this isn't a system that is critical, but it does serve some
purposes.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Fixing errors on a BTRFS partition?

[Nate Bargmann]

I have a Freedom Box Pioneer (hardware is an Olimex A20-OLinuXino-LIME2
unit with a Samsung 128 GB micro-SD card.  The micro-SD is partitioned
into 2GB boot ext2 and the remainder as the root partition as BTRFS.

The thing has been crashing for months and now it started giving GPG
signature errors when trying to run 'apt update'.  I copied the entire
micro-SD card to an image file with dd so I have a backup.  Running
'btrfs check' resulted in a lot of errors so I ran the check and
directed the output to a file which is over 2MB in size!  The following
is a small snippet of what it in the file:

[1/7] checking root items
[2/7] checking extents
checksum verify failed on 2337062912 found 0098 wanted 0025
checksum verify failed on 2337062912 found 0098 wanted 0025
Csum didn't match
owner ref check failed [2337062912 16384]
ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space cache
[4/7] checking fs roots
checksum verify failed on 2337062912 found 0098 wanted 0025
checksum verify failed on 2337062912 found 0098 wanted 0025
Csum didn't match
root 11670 inode 1109704 errors 200, dir isize wrong
root 11670 inode 1109705 errors 2001, no inode item, link count wrong
unresolved ref dir 1109704 index 2 namelen 4 name json filetype 1 
errors 4, no inode ref
root 11670 inode 1109706 errors 2001, no inode item, link count wrong
unresolved ref dir 1095383 index 2 namelen 11 name 20-json.ini filetype 
7 errors 4, no inode ref
root 11670 inode 1109707 errors 2001, no inode item, link count wrong
unresolved ref dir 978863 index 4 namelen 7 name apache2 filetype 2 
errors 4, no inode ref
root 11670 inode 1109710 errors 2001, no inode item, link count wrong
unresolved ref dir 1095409 index 2 namelen 11 name 20-json.ini filetype 
7 errors 4, no inode ref
root 11670 inode 1109711 errors 2001, no inode item, link count wrong
unresolved ref dir 978863 index 5 namelen 3 name fpm filetype 2 errors 
4, no inode ref
root 11670 inode 1109714 errors 2001, no inode item, link count wrong
unresolved ref dir 978864 index 30 namelen 4 name json filetype 1 
errors 4, no inode ref
root 11670 inode 1109734 errors 2001, no inode item, link count wrong
unresolved ref dir 45938 index 176 namelen 17 name gschemas.compiled 
filetype 1 errors 4, no inode ref
root 11670 inode 1109735 errors 2001, no inode item, link count wrong
unresolved ref dir 6679 index 36 namelen 15 name giomodule.cache 
filetype 1 errors 4, no inode ref
root 11670 inode 1109771 errors 2001, no inode item, link count wrong
unresolved ref dir 295871 index 242 namelen 24 name 
rsyslog.service.dsh-also filetype 1 errors 4, no inode ref
root 11670 inode 1109784 errors 2001, no inode item, link count wrong
unresolved ref dir 978742 index 31 namelen 12 name readline.ini 
filetype 1 errors 4, no inode ref
.
.
.
ERROR: errors found in fs roots
Opening filesystem to check...
Checking filesystem on /dev/mmcblk0p2
UUID: ea375ed2-d6e7-49d4-9b19-a624ba09b96c
The following tree block(s) is corrupted in tree 11670:
tree block bytenr: 6562955264, level: 1, node key: (1109704, 96, 3)
found 19331854402 bytes used, error(s) found
total csum bytes: 14201108
total tree bytes: 1242775552
total fs tree bytes: 1160757248
total extent tree bytes: 61292544
btree space waste bytes: 327420862
file data blocks allocated: 182356692992
 referenced 113920880640


Everything online hints that attempting repair is particularly
dangerous, but what else am I to do?  At the moment the system is pretty
much useless.

All insights appreciated.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Python curses

[Nate Bargmann]

* On 2023 10 Jan 13:38 -0600, pa...@quillandmouse.com wrote:
> It may be argued that I shouldn't do the import this way. However, I
> prefer to have "curses." in front of things imported. It makes the link
> explicit, and serves to remind me of what's actually going on, when I
> revisit the code in five years.

I agree with your reasoning.  I never liked the "from foo import *"
syntax.  OTOH, it does have its use when wanting to import a subset of a
module.  For example, "from foo import bar" that would make the "bar"
name a part of the main namespace..

Then there is the "import fooBarBaz as fBB" syntax which is useful to
shorten long module names, as I understand it (the name after the "as"
can be any legal Python identifier).  There are some modules with
submodules that make the long name prefix onerous.

As I've poked around the Web over the years its clear that some like the
simplicity of "from foo import *".  I think doing that as an example is
a mistake as it hides the classes, methods, variables module prefix.
Just be aware that when you find an example that imports in this manner
that there is an implicit module name prefix but it isn't used since the
import command made the module's namespace a part of the program's main
namespace.

That's how I understand it, at least.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Python curses

[Nate Bargmann]

* On 2023 09 Jan 22:05 -0600, pa...@quillandmouse.com wrote:
> Folks:

I'm not python curses expert, but is what I found.

> I'm trying to write some code in Python's curses module. I've run into
> common curses items like A_NORMAL which don't exist. When I do a
> print(curses.version), it shows "b 2.2". This tells me that the Debian
> (testing) version of python curses is version 2.2. The documentation
> for python curses at docs.python.org mentions versions up to 3.10.

Presumably you're running Bullseye as am I.  Here is what I show:

Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
>>> print(curses.version)
b'2.2'
>>> dir()
['__annotations__', '__builtins__', '__doc__', '__loader__', '__name__', 
'__package__', '__spec__', 'curses']
>>> dir(curses)
[...(snip lots of stuff), 'A_NORMAL', (snip even more stuff)]

>>> curses.A_NORMAL
0
>>> curses.A_PROTECT
16777216
>>> curses.A_BOLD
2097152
>>> curses.A_COLOR
65280

Do you get similar values for those constants?

> Is it really possible that the latest version of Python in Debian
> testing is linked to (or however it works) the 2.2 version of Python
> curses?

Yes.  I'm not familiar at all with the versioning of such modules.
Perhaps the Python folks have decided to normalize the versions of
modules with the main interpreter version resulting in an apparent
version jump.

The curses module should be a rather old and stable module so I would
expect it to be fully functional and quite well debugged.

> If someone has insights here, I'd be grateful.

Looking at /usr/include/curses.h on Bullseye at line 1059 it can be seen
how ncurses defines A_NORMAL to be 0.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Q. re "Software" on new 11.6 Install

[Nate Bargmann]

* On 2022 28 Dec 09:07 -0600, Kent West wrote:
> I found "Synaptic", which seems to be what I thought "Software" was going
> to be. Perhaps "Synaptic" is Debian-specific, whereas "Software" is
> Cinnamon-specific. Maybe?

Actually, I think "Software" comes from the Gnome Project.  Make of that
what you will.  I use the Gnome desktop but not "Software".  Like you I
found completely inadequate to my needs but it's installed anyway.

I use the Aptitude TUI and apt from the terminal when I don't need the
TUI.  I do a lot in the terminal so it's not a pain point for me.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: colorscheme in vi

[Nate Bargmann]

* On 2022 23 Dec 13:03 -0600, Curt wrote:
> On 2022-12-23, Nate Bargmann  wrote:
> >
> >> Because there is no colorscheme named "white" in Debian's
> >> vim. The colorschemes are in /usr/share/vim/vim82/colors
> >
> > The problem as I see it is that he wants reverse colors in 'vi' but
> > edited '.vimrc'.  Historically those are two different programs but the
> > Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
> > presume that a setting that works in historic 'vi' might not be
> > supported by 'vim.basic'.
> 
> You'd think it would be more a question of the terminal.

That would certainly be another avenue provided the 'vi' program
respects those settings.  I don't think Vim does as it applies the
colorscheme and the background settings or their defaults.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: colorscheme in vi

[Nate Bargmann]

* On 2022 23 Dec 06:54 -0600, David wrote:
> On Fri, 23 Dec 2022 at 23:31, Greg Wooledge  wrote:
> > On Fri, Dec 23, 2022 at 12:36:56PM +0100, Pierre Frenkiel wrote:
> 
> > > I wanted to open vi with a white background and a black fg
> > > to do that, I put in my .vimrc, as recommended, a line
> > > colorscheme white
> 
> "as recommended" by whom?
> 
> Because there is no colorscheme named "white" in Debian's
> vim. The colorschemes are in /usr/share/vim/vim82/colors

The problem as I see it is that he wants reverse colors in 'vi' but
edited '.vimrc'.  Historically those are two different programs but the
Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
presume that a setting that works in historic 'vi' might not be
supported by 'vim.basic'.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Backing up whole Debian installation from laptop to laptop via ssh?

[Nate Bargmann]

* On 2022 14 Nov 09:16 -0600, Ottavio Caruso wrote:
> I have an old Thinkpad on its last legs which I cannot shutdown (long
> story). Then I have a slightly better Thinkpad with similar hard
> drive. Debian is split into three partitions (root. home and swap)/
> 
> I'll recreate a similar partitioning from a live usb on the newer
> laptop, then I'll mount the root partition, connect to the old laptop
> via ssh, copy the data on the new drive, reinstall grub and modify
> fstab.
> 
> Will this work?

Yes.

I've done this many times and documented it:

https://www.n0nb.us/blog/2012/11/ghost-a-partition-contents-with-rsync/

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: gspeaker installation

[Nate Bargmann]

* On 2022 04 Oct 11:55 -0500, Gary L. Roach wrote:
> Hi all,
> 
> Is anyone familiar with gspeaker installation. This program has to be
> compiled from source code. I keep getting the following error when running
> make:
> 
> ***/usr/include/glib-2.0/glib/gtypes.h:29:2:error: #error "Only  can
> be included directly."*
> 
> I have searched the web and have found references to the problem but could
> not find a solution that didn't require modification of the source code.

That's the only solution that I am aware of.  Later versions of glib are
designed to only allow the inclusion of the glib.h header file.  There
is one exception and it has to do with the g_printf (and related)
function which requires that glib/gprintf.h be included specifically.

I don't recall off-hand where I found this requirement in the
documentation, but maybe I got the same error you did on a package I
was porting forward some time back.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: fetchmail

[Nate Bargmann]

* On 2022 10 Sep 16:28 -0500, Gerard ROBIN wrote:
> Hello,
> in Bullseye (stable) fetchmail works fine, but in Bookworm (testing) I
> get:
> 
> fetchmail: can't accept options while a background fetchmail is running.
> argc = 5, arg list:
> arg 1 = "-k"
> arg 2 = "--ssl"
> arg 3 = "--mda"
> arg 4 = "/usr/bin/procmail -d %T"
> 
> No mail arrived since 
> 
> ps ax | grep fetchmail
> 
> 1943 ?Ss 0:00 fetchmail --nodetach --daemon 300
> 4220 pts/1S+ 0:00 grep fetchmail
> 
> how can I prevent the fetchmail daemon from running on startup in
> Bookworm ?

Perhaps you need to do something like (as root):

systemctl stop fetchmail.service
systemctl disable fetchmail.service

On a whim I checked what systemctl reports on this Bullseye system:

$ systemctl status fetchmail.service 
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
 Loaded: loaded (/etc/init.d/fetchmail; generated)
 Active: active (exited) since Sat 2022-09-10 15:37:33 CDT; 52min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1790 ExecStart=/etc/init.d/fetchmail start (code=exited, 
status=0/SUCCESS)
CPU: 6ms

Now, I typically do not run fetchmail as a system wide service so I never
looked at this output but apparently it is harmless as I also see:

$ ps ax | grep fetchmail
  10376 ?Ss 0:00 /usr/bin/fetchmail -aKd 60 --sslcertck
  10818 pts/0S+ 0:00 grep --color=auto fetchmail

which I had just started a few minutes before reading your mail.  I do
not find any kind of default configuration under /etc.  Was one added in
Bookworm?

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: netperf / MIT License is not open source?

[Nate Bargmann]

* On 2022 14 Aug 09:09 -0500, Lee wrote:
> On 8/14/22, David Wright wrote:
> > On Sat 13 Aug 2022 at 19:23:46 (+0100), piorunz wrote:
> >> On 13/08/2022 18:30, Lee wrote:
> >> > I just noticed that the netperf package is in the [non-free] repository
> >> >https://packages.debian.org/bullseye/netperf
> >> > which seems wrong.
>   <.. snip ..>
> >> It seems that this package license has changed from full HP copyright to
> >> MIT, on 20 January 2021.
> >
> > The version in bullseye looks as if it was built on 15 November 2020 …
> >
> >> Perhaps package needs updating in Debian repository :)
> >
> > … and has not yet needed upgrading for bookworm AFAICT (amd64).
> 
> argh.. I keep forgetting how long it takes for new software to migrate
> into the stable branch of Debian :(

Even if the package is updated and put into the Free archive, the only
way it would make it into Bullseye is if it is uploaded to backports and
the user has that repository enabled.  Otherwise, at best it will go
into Bookworm.  At least that is how things usually work out.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Where do you get Virtualbox

[Nate Bargmann]

* On 2022 31 Mar 12:29 -0500, Greg Wooledge wrote:
> I'm not sure exactly why it's even being uploaded to unstable.  But I
> guess if some Debian developer wants to spend their time doing that,
> they're permitted.  Maybe they keep hoping that upstream will change
> their policy some day?  Or that a different corporation will buy the
> rights to it, and change the policy that way?  I don't know.

I have it installed through Bullseye Fast track.  I don't follow how
packages flow, but they get to fasttrack.debian.net by some means.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Can't use mc's editor

[Nate Bargmann]

* On 2022 21 Mar 23:30 -0500, Felix Miata wrote:
> David Wright composed on 2022-03-21 23:07 (UTC-0500):
> 
> > Felix Miata wrote:
> 
> >> IIUC, and assuming standard file/directory permissions, if all instances 
> >> of MC are
> >> closed, and its ini file is then removed, every setting (except for panels
> >> configuration? and hotlist), gets reverted to default on next startup.
> 
> > I've attached the result of that reversion (from buster). The critical
> > line is, of course, line 4. I assume that, like me, a long time ago,
> > you altered it to auto_save_setup=false.
>   
> Actually the first thing I do with any new instance of MC is set the right 
> panel
> listing to long. I follow that with F9, Options, Configuration, where Auto 
> save
> setup gets deselected, among other changes. :)

And I have Autosave selected in all my installations of mc so IME, the
last one to close writes the file.  It's not unusual for me to have half
a dozen instances of mc running at once!  Sometimes I find I had two or
three running in the same terminal session.  Oh dear...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Can't use mc's editor

[Nate Bargmann]

* On 2022 21 Mar 20:56 -0500, David Wright wrote:
> On Mon 21 Mar 2022 at 19:34:46 (-0500), Nate Bargmann wrote:
> > * On 2022 21 Mar 15:19 -0500, Joe wrote:
> > > Probably best try nano unless you're particularly keen on vim. Don't
> > > forget that geany is a GUI IDE, whereas mc is a ncurses application.
> > 
> > Actually, mc and mcedit are linked to libslang, not ncurses.  Visually
> > it's not much difference but otherwise a world of difference, mostly to
> > developers.
> > 
> > One thing that really helped me when working with mcedit is to have this
> > snippet in my ~/.bashrc:
> > 
> > # Modify Midnight Commander editor background color
> > export MC_COLOR_TABLE="$MC_COLOR_TABLE:\
> > editnormal=lightgray,black:\
> > editbold=yellow,black:\
> > editmarked=black,cyan"
> > 
> > There may be more parameters available and it has been many years since
> > I found that somewhere on the 'Net and I failed to note the source.
> 
> man mc ?

Indeed, there is an entire section called "Colors" and lists the
keywords for the editor as:

Editor colors are: editnormal, editbold, editmarked, editwhitespace, 
editlinestate

I probably got the color snippet from mcedit(1) and its COLORS section
which looks suspiciously the same and only contains three of the five
keywords.

I'm not completely ignorant of man pages, having authored a few!  ;-)  I
suppose it just slipped my mind when I typed that mail.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Can't use mc's editor

[Nate Bargmann]

* On 2022 21 Mar 15:19 -0500, Joe wrote:
> Probably best try nano unless you're particularly keen on vim. Don't
> forget that geany is a GUI IDE, whereas mc is a ncurses application.

Actually, mc and mcedit are linked to libslang, not ncurses.  Visually
it's not much difference but otherwise a world of difference, mostly to
developers.

One thing that really helped me when working with mcedit is to have this
snippet in my ~/.bashrc:

# Modify Midnight Commander editor background color
export MC_COLOR_TABLE="$MC_COLOR_TABLE:\
editnormal=lightgray,black:\
editbold=yellow,black:\
editmarked=black,cyan"

There may be more parameters available and it has been many years since
I found that somewhere on the 'Net and I failed to note the source.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Can't use mc's editor

[Nate Bargmann]

In the configuration dialog there is the option to use the internal
editor.  Make sure that option is not selected.

On Debian systems you should get prompted for which editor to use by the
select-editor script.  In my case I chose vim.basic.  This avoids
tinkering with mc's config files directly which can only be done if all
instances of mc are closed.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 16 Mar 01:53 -0500, Emanuel Berg wrote:
> 황병희 wrote:
> 
> >> I tried Wayland some years ago now (might have been when
> >> they first trialled it in Ubuntu) but decided not to stick
> >> with it.
> >
> > Well i don't know my login desktop what it is.
> > WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
> > WAYLAND_DISPLAY=wayland-0
> 
>   echo $XDG_CURRENT_DESKTOP
> 
> Never says anything for me.

It's possible that environment variable is only set by certain desktops:

$ env | grep -i wayland
XDG_SESSION_TYPE=wayland
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.B6TFI1
WAYLAND_DISPLAY=wayland-0
MOZ_ENABLE_WAYLAND=1

$ echo $XDG_CURRENT_DESKTOP
GNOME

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Package cvs2cl no more in Debian?

[Nate Bargmann]

* On 2022 12 Mar 15:57 -0600, Steve Keller wrote:
> On Debian stretch I have installed the cvs2cl package.  In buster
> and bullseye it seems to be missing.  Very sad :(

It shouldn't be a problem to install locally so long as it works with
newer Perl versions:

https://www.red-bean.com/cvs2cl/

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 12 Mar 06:38 -0600, to...@tuxteam.de wrote:
> On Sat, Mar 12, 2022 at 07:22:11AM -0500, The Wanderer wrote:
> > 
> > The other defines multiple separate "desktops", which are logically
> > arranged into a grid for purposes of indexing and access, but which are
> > individually independent; anything sticking off the edge of any one of
> > them is not visible anywhere. That, as I understand matters, is the
> > feature commonly called "virtual desktops". It's my understanding that
> > this feature *is* possible via, and maybe even directly supported by,
> > Wayland.
> 
> And then, there are window managers (Fvwm) which offer "big" desktops
> (where the visible screen is a window into, which can be moved around
> seamlessly) and then several of that "virtual desktops".

That is what I recall from a bit over 25 years ago when I bought a 1.2
GB hard drive to have enough space to install the X disk sets in
Slackware 96.  The default WM was Fvwm95 and I used it with a large
virtual desktop for several years.  Then I chose to try Afterstep, then
IceWM for some time before moving into the desktop world alternating
between KDE and Xfce and now Gnome for the most part and my virtual
desktop equals the screen size.

Gnome calls them "workspaces" and I typically use four per screen.  It's
default is to create them dynamically but I use a fixed number.  This
way I set up my work flow the same as on systems where I used Xfce which
defaults to four desktops.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 11 Mar 15:10 -0600, Nicholas Geovanis wrote:
> That was exactly what I asked here a few days ago. And I was told that I
> was incorrect, that Wayland was simply a better implementation of X. That
> the old implementation X.org was still under active development. Showing
> that I was mistaken.
> 
> But if you read stuff online on this subject, you read exactly what I
> wrote: that the X protocol is old and outdated, the X source is largely
> unused at runtime, no real mindshare for X.org among X developers.
> 
> Here's an example of these views from 2021, at linuxiac.org:
> "Most of the features that the X Server protocol provided were not used
> anymore. Pretty much all of the work that X11 did was redelegated to the
> individual applications and the window manager. And yet all of those old
> features are still there, weighing down on all of these applications,
> hurting performance and security".
> https://linuxiac.com/xorg-x11-wayland-linux-display-servers-and-protocols-explained/
> 
> I'm just trying to find out what the real story is.

Keith Packard, a long time X developer, gave a talk at Linux Conf.au[1]
in early 2020 about X history and politics[2].  As I recall (it's been
two years since I watched it), much of what you wrote above echos
Keith's comments.

- Nate

[1] https://www.keithp.com/blogs/tags/lca/
[2] https://youtu.be/cj02_UeUnGQ

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 11 Mar 14:06 -0600, Emanuel Berg wrote:
> Nate Bargmann wrote:
> 
> > Interesting as no one uses Wayland or X11 directly but
> > through a window manager or quite likely one of the desktop
> > environments.
> 
> I don't know, I think it is fair to say I use X "directly",
> I start it manually (but automatically, the command is in
> a file) in a tty and then in ~/xinitrc launch a compositor and
> WM, then xterm with tmux:
> 
> picom &
> openbsd-cwm &
> 
> xterm   \
> -T 'xterm'  \
> -fullscreen \
> -e 'tmux new-session\; split-window -v\; select-pane -U'

I suspect you're not the target audience for Wayland as it seems to me
to be oriented toward the main desktop projects.  I don't see that your
use case would gain anything moving to Gnome or KDE.

That's the great thing about Free systems, we don't all have to do
things the same way.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 11 Mar 14:10 -0600, Emanuel Berg wrote:
> Nate Bargmann wrote:
> 
> >> No, I understood, but that sounds like too much emulator ...
> >
> > My understanding is that xwayland is an X server that runs
> > under Wayland and the idea is that it handles X protocols
> > but Wayland handles the video drivers and screen drawing.
> >
> > I have used Gnome on Wayland since late 2018. It improved
> > a lot with the release of Bullseye.
> 
> Okay, I'm on Bullseye as well.
> 
> You have commands so I can try?

I had just installed the system with the preselected Gnome desktop task
and everything was put in place.  I simply log into the Gnome desktop
from GDM.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 11 Mar 07:16 -0600, Christian Britz wrote:
> 
> 
> On 2022-03-11 12:47 UTC+0100, Nate Bargmann wrote:
> 
> > I have used Gnome on Wayland since late 2018.  It improved a lot with
> > the release of Bullseye.  I use this setup on two machines, a laptop and
> > a desktop that has two monitors.  So far I have not had any issues with
> 
> And what is the practical _advantage_ over a X11 setup?

Gnome is now native with Wayland and its visual effects only work with
Wayland as I understand it.  I did try Gnome Flashback as it runs on X11
and the visual effects were disabled.  In some cases that's not an
issue and is likely appropriate for some hardware.

> The question is serious. Everytime I tried Wayland, something was not
> working as expected, uncomfortable to use and so on. Yes, Wayland
> support has improved a lot, but I still do not really see what I miss
> because I stick to X11. I know that Wayland has a cleaner design, but
> that bothers me not too much as a user.

Interesting as no one uses Wayland or X11 directly but through a window
manager or quite likely one of the desktop environments.  Debian
packaging seems to sort this out where a DE like Xfce only installs Xorg
packages and Gnome installs Wayland and Xwayland.

That said, if hardware support is not present, then I suspect that any
advanced features will have problems.  Use what works for you.  I am
just providing my experience as I'm not a cheerleader for Wayland or
against Xorg, just a satisfied user of both.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Wayland vs X

[Nate Bargmann]

* On 2022 10 Mar 17:04 -0600, Emanuel Berg wrote:
> didier gaumet wrote:
> 
> >> OK, thanks, I won't switch then I think ... I like feh and
> >> use it a lot.
> > 
> > Just to be clear in case there would be a misunderstanding
> > because my sentence was not accurate enough: what I meant is
> > feh (for example) is not directly compatible with Wayland, but
> > can be run in the X11 compatibility layer of Wayland
> > (Xwayland, the nested X server that can be run inside
> > Wayland)
> 
> No, I understood, but that sounds like too much emulator ...

My understanding is that xwayland is an X server that runs under
Wayland and the idea is that it handles X protocols but Wayland handles
the video drivers and screen drawing.

I have used Gnome on Wayland since late 2018.  It improved a lot with
the release of Bullseye.  I use this setup on two machines, a laptop and
a desktop that has two monitors.  So far I have not had any issues with
any Debian provided packages.  They just work, including feh which I call
from neomutt to display images.  No fuss, no configuration, it just
works.  I've even built and locally installed GTK2 apps without issue.

I did have a display issue with a proprietary third party program that
was built with some older version of Qt, as I recall.  That has been
replaced by a version that is FOSS and it works fine.  On the desktop
with dual monitors I have xscreensaver running and it has the most
issues with detecting events as when I do strictly keyboard work it will
time out and start running a saver.  Moving the mouse wakes it up.  It
also glitches at other times even when using the mouse, but this is not
a show stopper for me.  It also doesn't handle DPMS on Wayland either
which I can live with (I'm sure the built in Gnome blanker works just
fine).

My GPUs are stock Intel on board graphics as I don't game nor do I need
fancy 3D capability.  This hardware is sufficient for displaying the GL
screen savers and for whatever compositing requirements Gnome has.

HTH

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: One user system.

[Nate Bargmann]

* On 2022 01 Feb 14:09 -0600, Bijan Soleymani wrote:
> On 2022-02-01 14:47, pe...@easthope.ca wrote:
> > Thanks.  Still a multi-user system.
> > 
> > Whereas puppy linux has one user, root.
> > 
> > To make debian one-user I think of
> ...
> > 
> > Then proceed as root rather than me.
> 
> Oh! Is your goal to only have root? I assumed you wanted to login as root,
> but didn't configure a password for root at setup.

I must be the odd one out as I interpreted the OP as having set a root
password but now wanting to remove it so as to have just the main user
set to do root's work and that root can no longer log in directly.  I
hope the OP can clarify!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Security

[Nate Bargmann]

I am subscribed to that list and get them too.

I just see that three more messages popped in since this morning from
the security list.

The complaints seem to be only about browsers.  The inference seems to
be that the latest release always fixes security bugs.  While this is
true to an extent, what is seldom acknowledged is that new releases also
bring new and as yet undisclosed bugs that will be fixed next time or
the time after or the time after that or...  I figure it's a gamble
either way and stick with the Debian packages.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: odd question re man pages

[Nate Bargmann]

* On 2022 07 Jan 10:26 -0600, Curt wrote:
> On 2022-01-07, Nate Bargmann  wrote:
> >
> > Did you try Shift + Right-click and select "Open Link" or some such in
> > your terminal?  That is what works for me in Gnome Terminal.
> >
> 
> This is what works for me in gnome-terminal:
> 
>  URL detection[edit]
>  GNOME Terminal parses the output and automatically detects snippets of
>  text that appear to be URLs or email addresses.[2] When a user points
>  to a URL, the text is automatically underlined, indicating that the
>  user may click. Upon clicking, the appropriate application will open to
>  access that resource.
> 
> 
> https://en.wikipedia.org/wiki/GNOME_Terminal
> 
> Of course, the phrase "the appropriate application will open" is kind of a 
> mixture
> of wishful thinking and convenient simplification, though it should
> normally be your default browser. 

I use the Shift + Right-click trick to get the menu in applications that
seem to block Gnome Terminal's handling of the URL.  I've found the
trick useful with Mutt and Midnight Commander.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: odd question re man pages

[Nate Bargmann]

* On 2022 07 Jan 04:01 -0600, gene heskett wrote:
> Greetings all;
> 
> debian 11.1, 64 bit net-install updated yesterday.
>  
> I've noted that there can be links to a web page in a man page that are 
> underscored if you click on them while reading the man page, but clicking 
> the link does not do anything.  Is it supposed to send the default browser 
> to that page? If so, where should I check for the broken linkage?

Did you try Shift + Right-click and select "Open Link" or some such in
your terminal?  That is what works for me in Gnome Terminal.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Firefox ESR EOL

[Nate Bargmann]

* On 2021 09 Dec 15:29 -0600, Michael Castellon wrote:
> all versions:
> https://ftp.mozilla.org/pub/firefox/releases/
> 
> version esr:
> wget -O firefox-esr.tar "
> https://download.mozilla.org/?product=firefox-esr-latest=linux64;
> 
> remember, delete cookies, etc:
> rm -r ~/.mozilla

I agree with Tixy, this dumps too much.  Of course, a profile and other
stuff can be recovered via Firefox sync to an extent but not certain
customizations such as setting zoom to text only.

I suppose the other question is why?  Over the years I've gone back and
forth between Mozilla provided binaries and Debian installed packages
and have never deleted nor modified ~/.mozilla

Perhaps you intended to remove the cache which is found under
~/.cache/mozilla?  FF will rebuild it automatically when it is missing.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emoji fonts in Debian [WAS:] Re: How to NOT automatically mount a specific partition of an external device?

[Nate Bargmann]

* On 2021 02 Dec 01:07 -0600, Jonathan Dowland wrote:
> On Wed, Dec 01, 2021 at 09:31:43PM -0600, David Wright wrote:
> > As for the firefox version, it manages to combine them, but
> > throws the emphasis onto the face, and just looks like a
> > mischievous kid's cartoon character.
> 
> That's exactly what I look like ;)

Close!  Going by your avatar I see when browsing the Planet Debian blog
feed.  :-)

In Mutt running in Gnome Terminal I see a square following the face
(screenshot attached).

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emoji fonts in Debian [WAS:] Re: How to NOT automatically mount a specific partition of an external device?

[Nate Bargmann]

* On 2021 27 Nov 20:09 -0600, Celejar wrote:
> I'm pretty sure Droid Sans Mono Slashed doesn't have the glyphs in
> question, and that you must actually have the noto or similar fonts
> installed, with some part of the Gnome infrastructure finding them when
> you select the glyphs. What does "fc-list | grep noto" show?

$ fc-list | grep noto
/usr/share/fonts/truetype/noto/NotoSansMono-Regular.ttf: Noto Sans 
Mono:style=Regular
/usr/share/fonts/truetype/noto/NotoSansMono-Bold.ttf: Noto Sans Mono:style=Bold
/usr/share/fonts/truetype/noto/NotoMono-Regular.ttf: Noto Mono:style=Regular
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color 
Emoji:style=Regular

> If you have the noto fonts installed, try uninstalling them and then
> see if your system can still display the glyphs.

As I don't really care to mess with a working system, perhaps someone
else without the Noto fonts can post their before and after results.

I see that gnome-core depends on gnome-characters which, in turn,
recommends fonts-noto-color-emoji and I have Aptitude configured to
install Recommends automatically.  So here the noto package shows to be
automatically installed so I guess I got the functionality "for free" by
using Gnome.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emoji fonts in Debian [WAS:] Re: How to NOT automatically mount a specific partition of an external device?

[Nate Bargmann]

* On 2021 26 Nov 11:36 -0600, Celejar wrote:
> On Thu, 25 Nov 2021 10:43:16 +
> Jonathan Dowland  wrote:
> 
> ...
> 
> >   Jonathan Dowland
> > ✎j...@debian.org
> >    https://jmtd.net
> 
> I finally got tired of seeing tofu for some of the glyphs in your sig,
> so I looked up their Unicode codepoints:

Interestingly, I see the glyphs in Mutt running in Gnome Terminal and in
Vim as I edit this in the same Gnome Terminal.  My font is one
installed locally, Droid Sans Mono Slashed which provides the zero
character with a slash.

I know that there is keyboard sequence in Gnome Terminal (Ctl-Shift-E
then Space) to bring up a menu to select Unicode glyphs.



- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Offtopic: Transfer a programm from DOS to Linux

[Nate Bargmann]

I spoke with a friend about this yesterday who was in the area and has
done quite a bit using SDR as a radio amateur.  He passed along these
links:

https://etd.ohiolink.edu/apexprod/rws_etd/send_file/send?accession=wright1608139109925131=inline
https://www.rtl-sdr.com/using-an-rtl-sdr-rf-fingerprinting-and-deep-learning-to-authenticate-rf-devices/
https://www.rtl-sdr.com/identifying-transmitters-with-ctcss-fingerprinting/

The second link is interesting as it focuses on RF devices that are
commonly found such as IoT sensors, keyfobs, and other common RF
transmitting devices beyond two-way radio transmitters.  In other words,
this tech should have applicability in network security, to bring it
back on topic a bit.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Offtopic: Transfer a programm from DOS to Linux

[Nate Bargmann]

Hans, Georgi makes a good point about existing software.  This seems
like it would be a perfect addition to a Software Defined Radio (SDR)
package.  I've not investigated whether any of the existing packages
available in Debian have this capability.  As these programs capture an
arbitrary slice of the RF spectrum, it seems like they would be perfect
for the task.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Offtopic: Transfer a programm from DOS to Linux

[Nate Bargmann]

Interestingly, it appears that the original author was threatened with
patent infringement of US Patent 5,005,210[1].  It seems as though the
patent may have expired in 2008[2].

It appears no patent infringement suit was ever brought against the
author.  The noted rights holder, Motron, apparently doesn't even offer
the product that this software was claimed to infringe upon.

Here is bit more background on the device that Google served up[3].

Here is Mr. Rager's obituary from 2006[4].

As it stands now, IANAL, the patent should be expired, the noted patent
holder does not have a device on the market, the source appears to be
intended to be licensed under the GPL v2 or later, though a copyright
header is not present in the source files themselves, a file containing
the text of the GPL v2 is included as is a file named header.txt that
contains the usual text for source files and may have been included as
part of the Turbo C project.  No traces of a build system are present in
the source archive.

Just glancing at the source and from the comments of others, there is
probably some amount of the source that could be usable.  I suspect the
UI and the sound interface would need to be written from scratch as they
are probably Turbo C and Soundblaster specific, respectively.  Still
this would be a very useful tool for those interested in radio frequency
(RF) work, especially with a laptop or SBC (Raspberry Pi, etc.).

- Nate

[1] https://www.qsl.net/n9zia/xmit_id/legal.html
[2] https://patents.google.com/patent/US5005210A/en
[3] https://wiki.w9cr.net/index.php/Transmitter_Fingerprinting
[4] 
https://www.legacy.com/us/obituaries/dispatch/name/richard-rager-obituary?id=28327105

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Offtopic: Transfer a programm from DOS to Linux

[Nate Bargmann]

* On 2021 21 Nov 05:54 -0600, Hans wrote:
> Hello list,
> 
> I know, there are lots of coders here and I have a question. There is an old 
> DOS application I found, which is open source and GPL.
> 
> As far as I know, this application is written in C, it is running in textmode 
> ("ncurses-mode").
> 
> Since there is no similar linux based application like this, I wondered, ho 
> difficult for an experienced coder it will be, to get a DOS application 
> natively running in linux.

Hi Hans.

I think the difficulty will be whether it was written for the DJGPP[1]
compiler (a port of GCC to DOS, as I recall) and this uses C library
calls and the actual ncurses library.  If it was written using classic
DOS interrupts and direct video hardware access, then the task would be
quite a bit more difficult, I would think (note that I am guessing, not
having done anything like this).

Perhaps the easiest way is to install FreeDOS[2] in a virtual machine
(QEMU[3] is in the archives, Virtualbox[4] requires a slight bit more work)
and run the program from there.  Then tackle development in that
environment while slowly working toward a native Linux build.

> For those, who are interested, this is what this application is for:
> 
> The application is for radio enthusiasts. It can recognize every radio 
> transceiver with its transmission. This is because every radio transceiver 
> has 
> its very personally transient response, just like a fingerprint. This 
> application gets its signal then from the if-module via the souzndcard and 
> shows the very special transient response as a graphic. These graphic can be 
> named and whenever the transceiver is sending again, it will be recognized.
> Very useful to recognize and rerecognize unwanted stations.

As a radio amateur myself, I find the above intriguing.  I don't recall
hearing of this program before.  I am aware that such radio transmitter
fingerprinting has been known for a long time.

> I can send the app wherever you want to (attaching it here, does not allow to 
> send the mail strangely), so everyone can take a look. This app is available 
> in the web, but a little bit hidden, if you do not know its exactly name.

Better would be to send the URL.  What CMS is it in, CVS, SVN, something
else?  I'd be interested in preserving the source code history as much
as possible and then moving that into Git.

- Nate

[1] http://www.delorie.com/djgpp/
[2] https://freedos.org/
[3] https://www.qemu.org/
[4] 
https://wiki.debian.org/VirtualBox#Debian_10_.22Buster.22_and_Debian_11_.22Bullseye.22

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: aboutdebian.com

[Nate Bargmann]

* On 2021 18 Nov 23:00 -0600, A_Man_Without_Clue wrote:
> Does anyone remember the site existed in the past, aboutdebian.com?

I can't say that I do.

> I wonder if the contents are moved to somewhere else or they are not
> available at all?

It looks like the last time it was online with content was approximately
29 Feb 2020:

https://web.archive.org/web/20200229050405/http://www.aboutdebian.com/

I see that as of that date, the site had not been updated for Buster
which by that time had been released nearly half a year earlier.

After that the Web archive shows a blank page and captures from last
month show nothing Debian related.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: why Debian?

[Nate Bargmann]

For me Debian strikes a nice balance between convenience and staying out
of my way and preserving my changes when I want to customize things.  As
mentioned, apt, though I like using aptitude through its TUI mostly,
handles dependencies not just for installing but for removing packages
as well.  When the debconf system detects that a configuration file
(most often found under /etc) has been modified, it will prompt for a
resolution (I have dealt with distributions that weren't so careful).

The Debian developers often set sensible defaults that mesh well with
the system and often modify a package to make it easier to administer.
The security team does a good job of responding to issues and updating
needed packages.  Over the years it has become obvious to me that the
developers care deeply about the distribution and this is reflected in
the quality of the past several releases (all have been good since I
first installed Debian 2.1 (Slink) back in late summer 1999, but past
several have shown the project has the process down pat).

The project is committed to Free Software yet has not forgotten that
sometimes pragmatism dictates that users need to use non-free packages
to accomplish their tasks.  Fortunately, most of the non-free packages
that are needed these days are kernel modules.

HTH,

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Man pages for gcc

[Nate Bargmann]

* On 2021 31 Oct 16:27 -0500, Nicholas Geovanis wrote:
 
> The info command is what you want for gcc. You may need to install the
> package for gcc info files. Another set of commands you might need info
> files for are coreutils. Try "info coreutils".

While info is probably installed, a much better user experience is the
'pinfo' package since it uses Lynx like motion and color highlighting
for hyperlinks.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Then it happened to me...

[Nate Bargmann]

Years back there was an emailed newsletter titled Debian Weekly News.
At some point the author lost motivation as I recall and the newsletter
effectively ceased.  Keep in mind that Debian is an organization that
depends on volunteer effort to accomplish its goals.  I think you have
identified an area where you can help, i.e. the timely dissemination of
project news.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Then it happened to me...

[Nate Bargmann]

* On 2021 10 Oct 07:50 -0500, Gene Heskett wrote:
> On Sunday 10 October 2021 06:36:32 Reco wrote:
> > [2] https://discourse.debian.org/
> This does not resolve.

Good!

I don't care for Discourse.  At. All.  Too much is in control of the
site admins.  It can probably be argued that email has too little
control, however, my main gripe about the Discourse setups I have
registered with are that the admins lock threads after a relatively
short period of time.  I do understand that some don't like old threads
coming back to the top but sometimes it is relevant to revive an old
thread as new information comes available.  Unlike TV, in the real world
solutions aren't always found in 39 1/2 minutes!

One thing about email lists, at least those managed by GNU Mailman, is
that they're archived and often the archive can be obtained by anyone
thereby preserving the content.  Just try to do that with the average
Web forum, and note that I am no stranger to Web forums.

Finally, email lets me use the mail agent and the editor *I* want, not
what is dictated by the forum software.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: "Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

* On 2021 30 Sep 15:15 -0500, Marco Möller wrote:
> SUMMARY:
> I never observed problems with ext4 on my since 4 years heavily used USB
> pen-drive.
> 
> Good Luck!
> Marco

Thanks Marco!

That is a very useful review of your experience.  Your taking the time
to write it up is greatly appreciated.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: "Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

* On 2021 29 Sep 09:47 -0500, Reco wrote:
>   Hi.
> 
> On Wed, Sep 29, 2021 at 07:59:50AM -0500, Nate Bargmann wrote:
> > A test run with KDE Plasma shows that performance is acceptable even
> > with EXT4 as the file system.  I now have some SanDisk Ultra Fit flash
> > drives arriving in 128GB capacity (overkill, oh well).  I am now
> > considering what file system would be proper to use in this case.
> 
> A plain ext4 with the 'discard' mount option will do just fine.

From the ext4(5) man page:

   discard/nodiscard
  Controls whether ext4 should issue discard/TRIM commands to  the
  underlying  block  device when blocks are freed.  This is useful
  for SSD devices and sparse/thinly‐provisioned LUNs,  but  it  is
  off by default until sufficient testing has been done.

LUN?  That's new to me.  Let's see[1]:

"In computer storage, a logical unit number, or LUN, is a number used to
identify a logical unit, which is a device addressed by the SCSI
protocol or by Storage Area Network protocols that encapsulate SCSI,
such as Fibre Channel or iSCSI."

On this desktop I run a cron job twice a month that runs fstrim(8) that
its man page states:

   Running fstrim frequently, or even using mount -o discard, might  nega‐
   tively affect the lifetime of poor‐quality SSD devices.  For most desk‐
   top and server systems a sufficient trimming frequency is once a  week.
   Note  that  not all devices support a queued trim, so each trim command
   incurs a performance penalty on whatever else might be  trying  to  use
   the disk at the time.

That leads me to think that discard could be problematic on some
devices.  Does a USB flash drive fall into that category?  I've no
problem using anacron to run an fstrim(8) job every so often if discard
is thought to be too aggressive.

> > I understand that the journal can be disabled when using EXT4 to save
> > writes which is probably fine (this system will be non-critical).
> 
> It's possible to do, but it is not needed that much.
> If you're trying to conserve drive's resources - just write less on it.
> I.e. redirecting .xsession-errors to /dev/null, removing that annoying
> /var/log/journal directory, adding a good set of filters to rsyslog,
> etc.
> 
> For instance, this low-cost SSD that I use in my laptop endured about
> 1.8 Tb writes over 3.5 year usage, and shows no signs of degradation.

Presumably there is a difference between an SSD which expects a lot of
writes and a USB flash drive that expects relatively few by comparison
used in the role of an SSD/HDD, not?

- Nate

[1] https://en.wikipedia.org/wiki/Logical_unit_number
-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: "Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

* On 2021 29 Sep 16:40 -0500, David Christensen wrote:
> I have several SanDisk UltraFit USB 3.0 Flash Drive 16 GB, and have
> installed Debian onto them using btrfs and ext4.  Both filesystems work.
> btrfs requires periodic re-balancing, which is time consuming.

A few years back I built up a server of sorts using BTRFS on a pair of 1
TB 2.5" spinning drives as a software RAID.  I think it worked okay but
I never got around to really using it as originally conceived.  Some
time down the road one of the drives started a clicking noise and that
was the end of the RAID as I dismantled it.

I have a Freedom Box Pioneer that uses BTRFS on its microSD.  It seems
to be fine.

One of BTRFS' features I really like are subvolumes (IIRC) where each
subvolume can be be treated as a partition but the FS treats them
somewhat like directories and the entire disk is shared between them.
Unfortunately, there are still alleged bugs in BTRFS that give me pause.
For my usage they would likely be inconsequential.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: "Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

* On 2021 29 Sep 12:50 -0500, Brian wrote:
> On Wed 29 Sep 2021 at 11:34:22 -0500, Nate Bargmann wrote:
> 
> > Thanks, Reco.  That is useful to me.
> 
> Your question and Reco's response were also useful to me, if only
> because I had not come across F2FS previously. On a USB device I
> use ext44 without any noticable problems.

I have as well, Brian.  Even so, I'm always looking for "better" as tech
progresses.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: "Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

Thanks, Reco.  That is useful to me.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

"Proper" filesystem for Debian installed on a flash drive

[Nate Bargmann]

Earlier this year I purchased a nice Lenovo Carbon X1 with an NVME SSD
with Win 10 Pro installed.  Ordinarily I would reformat the drive
without a second thought but in this case I really do have occasional
need to use Win 10 (Kenwood radio programming mostly) and since swapping
the NVME is not trivial, I've opted to install Bullseye to a USB flash
drive.

A test run with KDE Plasma shows that performance is acceptable even
with EXT4 as the file system.  I now have some SanDisk Ultra Fit flash
drives arriving in 128GB capacity (overkill, oh well).  I am now
considering what file system would be proper to use in this case.  I
understand that the journal can be disabled when using EXT4 to save
writes which is probably fine (this system will be non-critical).  I've
also seen that F2FS has been available in the kernel since 3.8, but I'm
unsure whether the installer from a Debian live CD will offer it as a
choice.

The Arch Wiki notes some issues with its fsck and the Debian Wiki is
rather short on details.  I found this page[1] that was from 2013 and
updated early last year.  The process is not trivial which hints that
F2FS is not included in the Buster installer, at least.

As this is a non-typical installation for a dual-boot configuration that
intends to use UEFI to choose the OS to run, are there tips and
suggestions for this?  I have already solved the bug where MS places its
boot image in a directory in the ESP that prevents an EFI enabled
removable media from booting[2] (second paragraph).

TIA

- Nate

[1] https://howtos.davidsebek.com/debian-f2fs.html
[2] 
https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: The future of computing.

[Nate Bargmann]

* On 2021 22 Sep 16:14 -0500, harrywea...@tutanota.com wrote:
> For those with an interest:
> 
> https://register.gotowebinar.com/register/5204765206263907088

Hmmm, as a radio amateur when I see QST, I immediately think of the
membership journal of the American Radio Relay League which has been
published since 1915 with a two year break for the Great War from 1917
to 1919.

Maybe IBM bought the rights to the name!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: A bug in Vim, in Mate Terminal or in Debian 11?

[Nate Bargmann]

* On 2021 19 Sep 12:26 -0500, Dedeco Balaco wrote:
> 
> 
> Em 19/09/2021 14:07, Greg Wooledge escreveu:
> > Since your TERM variable begins with "xterm", you can simply copy the
> > case command directly from the Debian .bashrc file into yours:
> > 
> > 
> > # If this is an xterm set the title to user@host:dir
> > case "$TERM" in
> > xterm*|rxvt*)
> > PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
> > ;;
> > *)
> > ;;
> > esac
> > 
> > 
> > Put that chunk of code anywhere in your .bashrc after your PS1 assignment,
> > and it will add a prefix that sets the terminal's title.  You can alter
> > it to suit your own preferences.  Just make sure that whatever you add
> > is surrounded by \[ \] and contains one of the sequences for changing
> > the terminal title.  (There are three of them in xterm, depending on
> > whether you want to set the title, or the icon's name, or both.  Debian
> > is using the one that sets both.)
> > 
> 
> I do not understand you. I have said my prompt is (and always were)
> fancy. Then, you say that this might be the cause of the problem - BUT,
> as a possible try to solve, you tell me to make another fancy prompt.

This is not "another fancy prompt", it is code to set the terminal title
and does not affect nor replace your prompt as it adds code that is not
displayed in the prompt to the PS1 variable.  Any user setting of PS1 is
undisturbed as shown by the $PS1 at the end.

> And do not forget one thing: the tabs' titles are working almost as they
> were before. With vim, sometimes, it does not reset when vim exits, as
> it always did, since around 20 years ago.

I've not used Vim as a main editor until very recently, right about the
time that Bullseye was released.  I don't see Vim changing the tab
titles though I do see Midnight Commander changing them as the directory
and/or panels are switched.

> I check all lines in /etc/skel/.bashrc. It does not show me anything
> new. My prompt contains only things that it has, and sometimes different
> (skel does not use as many colors as i do, for PS1).

My PS1 is very complex (I posted its code here a few weeks back), yet
the path when I cd to a directory is reflected in the tab title (gnome
terminal) as is whatever mc sets it to.

As I cannot say whether Vim formerly set tab titles, I must stop here.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Mutt/Neomutt and mailcap

[Nate Bargmann]

* On 2021 15 Sep 21:36 -0500, David Wright wrote:
> I think what your system is doing is as follows:
> 
> You probably have in your (default) /etc/Muttrc:

In my case, /etc/neomuttrc, and the following does exist.

My assumptions have been that the system RC is ignored when a user's RC
exist.  I am finding this is not entirely true in all cases.

>   # Use mime.types to look up handlers for application/octet-stream. Can
>   # be undone with unmime_lookup.
>   mime_lookup application/octet-stream
> 
> That sends mutt looking in /etc/mime.types where it finds the line:
> 
>   text/x-diff diff patch

> Your attachment had the extension ".patch", so it searches your
> and the system's mailcap files for "text/x-diff", fails to find it,

> and eventually hits the default entry:
> 
>text/*; less '%s'; needsterminal
> 
> which it obeys.

Exactly, and is followed immediately by:

text/*; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; 
needsterminal

which I have now added to  ~/.mailcap as:

text/x-diff; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; 
needsterminal

and now the offending attachment is opened in Vim from the view
attachments screen when I press Enter on it.

> BTW, your shell command,
> 
>   !see --norun application/octet-stream:/dev/null
> 
> will give you an answer in the context of a subshell, and
> not necessarily in the context of mutt itself. For example,
> on my shell:
> 
> $ see --norun text/html:/dev/null
> /usr/bin/sensible-browser /dev/null
> $ 
> 
> but the special mailcap prioritised by my mutt defines:
> 
>   text/html; /usr/bin/lynx -force-html -localhost -stdin
> 
> and any subshell would know nothing about that.
> 
> About the ";", it could also be an accidentally unshifted ":",
> and it might be easy to mis-remember:
> 
> ":" is mutt's keystroke for entering mutt commands, whereas
> "!" is mutt's keystroke for entering shell commands.

Thanks for the helpful pointers through the maze!

The problem is that I visit something like this once about every several
years and it's all new again.  Sigh...

Finally, the Web mailer that assigned application/octet-stream may not
be that far off if it is assuming the recipient's MUA and MIME handling
is configured correctly, which it actually is.  I was just a bit annoyed
at the end result and now I have it set per my preference.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Mutt/Neomutt and mailcap

[Nate Bargmann]

* On 2021 16 Sep 02:35 -0500, Andrei POPESCU wrote:
> For neomutt in buster I have this in .neomuttrc:
> 
> # neomutt disabled viewing text/* as text (except text/plain)
> # re-enable common file types received (requires corresponding .mailcap entry)
> auto_view text/x-diff
> auto_view text/x-patch
> auto_view text/x-gettext
> 
> 
> Corresponding .mailcap entries:
> 
> text/x-diff;nvim %s
> text/x-patch;   nvim %s
> text/x-gettext; nvim %s
> text/x-diff;cat %s; copiousoutput
> text/x-patch;   cat %s; copiousoutput
> text/x-gettext; cat %s; copiousoutput
> 
> 
> As far as I recall the 'auto_view' and the 'copiousoutput' lines are for 
> automatic display in (neo)mutt's pager, the other ones for attachment 
> menu.

Thanks, Andrei.  I can add those for future attachments that are
assigned a proper MIME type.  In this case, the attachment was assigned
the application/octet-stream MIME type by the SourceForge.net Web mailer
(at least that is what I gleaned from the headers).

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Mutt/Neomutt and mailcap

[Nate Bargmann]

* On 2021 15 Sep 14:20 -0500, to...@tuxteam.de wrote:
> On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
> > On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> > > * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > > > What does this command report?
> > > > 
> > > > ;see --norun application/octet-stream:/dev/null
> 
> > Jonathan's message confused me too.  As far as I can tell, "see" is
> > a *shell* command, not a mutt command [...]
> 
> Perhaps the semicolon was intended to be an exclamation mark (!)
> (although, assuming Jonathan has a USish keyboard layout they are
> far apart indeed).

Indeed!  That works.

I missed it in the help list as my mind was fixated on the ;.  Other
programs like Vim use ! as a means to execute a shell command.

It should have been so obvious...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature