Hello:

OK ...  8^°

Rare ...
But not unheard of.

Have you tried checking for info in the usual places? eg: here.

That said and with your not wanting to risk a dist-upgrade, you may want to consider having a go at the recently uploaded netinstall.iso (20250809) and see how you fare with it.

Best,

A.

Hello:

Being a virtual package and provided by some other package (NN-polikit), to me* it's a tomayto = tomahto situation.
ie: still a virtual package provided by a real one instead of a real, stand alone package to do just that and only that.
* ymmv, obviously.

So I'll just leave that one as-is and avoid the possibilty of something going south.

With respect to replacing pinentry-gnome3 with pinentry-curses, any ideas as how to do it without screwing up?

Thanks for your input.

Best,

A.

Hello:

Thanks.
But the merit actually goes to a chap going by the handle Bentolor.

He posted about this same issue* back in 2019 and came up with the keyringrc.cfg file for setting the backend.
See https://github.com/jaraco/keyring/issues/391

* BiT fails because it cannot make sense of the ChainerBackend

A chap going by the handle Jaraco (autor of keyring?) explains the process further down.
You may want to give it a read, it may at some point be useful to you.

Best,

A.

Hello:

And so it seems:
---------------------------------------------
Debian Bug report logs - #998105
backintime-qt: Fails to access the keyring with python3-keyring 23.2.0-1
https://bugs.debian.org/cgi-bin/bugrepo … bug=998105
---------------------------------------------

BiT should be able to work properly without gnome-keyring or keepassxc installed.

The problem seems to be (?) with how BiT looks for and finds (or not) a keyring to use.
For whatever reason, it does not find and select the installed python3-keyring, going for whatever else is available to use.

Which is why, instead of using the installed python3-keyring 23.9.3-2, it uses the installed (and otherwise unnecessary) gnome-keyring 42.1-1+b2.
Failing to run if I purge it.

Apparently there is/was (?) a patch but the bottom line is that (two years on)  the bug is still present in backintime-qt 1.3.3-4.

So much for my getting rid of all the gnome crap ...

Best,

A.

Hello:

Interesting.

I have it installed in my system because BackInTime recommends it.
It is a remnant of the time when I did not block recommended packages.

$ aptitude why gnome-keyring
i   backintime-common     Depends    python3-keyring                                       
i A python3-keyring       Depends    python3-secretstorage (>= 3.2)                        
i A python3-secretstorage Recommends gnome-keyring | libkf5wallet-bin (>= 5.97) | keepassxc
$ 

But I don't use it to store passwords, not at all comfortable with that.

But it happens that gnome-keyring is not a dependency for BackInTime but if I purge it, BiT will not run properly.
keepassxc is not a dependency either and it requires network access, so that would be a hard no for me.

See https://packages.debian.org/en/sid/backintime-common

It would seem (?) that BiT should be using python3-keyring instead of gnome-keyring for me to be able to purge it.

Any ideas on how to get that done?

Thanks in advance.

Best,

A.

Hello:

See this thread: https://dev1galaxy.org/viewtopic.php?id=5596
There is a lot of information about /.config and /.cache there.

In my case, I solved it with this ...

# apt purge pulseaudio && apt autoclean && apt autoremove

... and then this: https://dev1galaxy.org/viewtopic.php?id=3904

The end result being this:

$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
$ 

In your case, a bit more digging may be necessary.
Or not.

Please let us know how you fared.

Best,

A.

Hello:

I found some more info on this apport application:

https://nvd.nist.gov/vuln/detail/CVE-2016-9950
https://app.opencve.io/cve/?vendor=apport_project
https://security-tracker.debian.org/tra … -2019-7306

You will notice that Debian refers to all this as a non-issue because apport is not present.
Coming from the creators of systemd, I'll take it with a few grains of salt, low sodium variety.

Paraphrasing the Bard (of Avon, seems there are others):

                           An apport by any other name would still cause damage

So ...

Just to be on the safe side of whatever may be in there, Devuan users may want to consider purging everything in /usr/share/apport/*
But that's just me and my $0.02.

Best,

A.

Hello:

dpkg -S apport/package-hooks

$ dpkg -S apport/package-hooks
lxappearance: /usr/share/apport/package-hooks/source_lxappearance.py
pcmanfm: /usr/share/apport/package-hooks/source_pcmanfm.py
yelp: /usr/share/apport/package-hooks/source_yelp.py
libfm-data: /usr/share/apport/package-hooks/source_libfm.py
openssh-client: /usr/share/apport/package-hooks/openssh-client.py
connman: /usr/share/apport/package-hooks/source_connman.py
lxterminal: /usr/share/apport/package-hooks/source_lxterminal.py
pcmanfm, lxappearance, libfm-data, sudo, synaptic, simple-scan, openssh-client, libmtdev1:amd64, connman, lxterminal, cups-daemon, yelp, grub-common, libmtp-common, conky-all: /usr/share/apport/package-hooks
conky-all: /usr/share/apport/package-hooks/conky.py
grub-common: /usr/share/apport/package-hooks/source_grub2.py
simple-scan: /usr/share/apport/package-hooks/source_simple-scan.py
libmtdev1:amd64: /usr/share/apport/package-hooks/source_mtdev.py
sudo: /usr/share/apport/package-hooks/source_sudo.py
libmtp-common: /usr/share/apport/package-hooks/source_libmtp.py
cups-daemon: /usr/share/apport/package-hooks/source_cups.py
synaptic: /usr/share/apport/package-hooks/source_synaptic.py
$ 

All python scripts.
Fortunately I managed to weed them all out.
Will do the same on all my Devuan installations.

And here we are, still with all this absolutely unneeded shit in a Linux system.
No wonder every new release brings about more and more (and more) code. 
All dirt swept under the rug, festering.

How much more of that is there to be found?

Yes, we is right.
Seems the pronoun does not include most (if not all) Debian devs.
Makes me wonder if they are not some sort of sleeper scripts.

As always, thanks for your input.

Best,

A.

Hello:

Was passing by and tried* it out:

* 128.3.1esr (64-bit) without Pihole or uBlock enabled.

Best,

A.

Hello:

So I gather.

I see.

But I do not want any of that done.
ie: I log in with a specific password as required when required, I have no interest in that being automated.

Then why is it that aptitude prints out this:

$ aptitude why gnome-keyring
i   backintime-common     Depends    python3-keyring                                       
i A python3-keyring       Depends    python3-secretstorage (>= 3.2)                        
i A python3-secretstorage Recommends gnome-keyring | libkf5wallet-bin (>= 5.97) | keepassxc  <- ###
$ 

I understand that python3-secretstorage needs either gnome-keyring or keepassxc.
libkf5wallet-bin seems to be a transitional package that can be removed so it does not count, leaving keepassxc as the only other alternative to gnome-keyring.

The keepassxc web page FAQ says that it does not support pugins.

Further on, it also says that it requires network access and that if you do not want that particular feature, you have to compile it yourself.

Much to my chagrin, I think I will have to stay with the gnome-keyring daemon so that BiT will continue to work as it has up to now.

Thank you very much for your reply.

Best,

A.

Hello:

Really could not say.

I have only seen this a couple of times before but (from what I can recall) never while booting*, I would have noticed it.
* Between [0.000000] and the end of the boot sequence. (see the time stamp on the dmesg printout)

And it is not reported by dmesg as a warning/alert/critical/error, so it is probably (?) harmless.

The BIOS (a POS if there ever was one) in my U24 WS does not have an entry for HPET and I certainly would not roll a kernel because of this.
More so if I cannot reproduce it or see any ill effects related to it.

Not to mention that I haven't a clue as to go about doing it. 8^°

My ca. 2007 U24 WS could be having this issue due to a less optimized HPET implementation, so it may be worthwhile attempting the tsc=nowatchdog kernel command line fix and wait to see what effect that has.

Thanks for your input.

Best,

A.