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.

Hello:

Thanks.

That would be great, more than anything to get a user sample number greater than 1.

I have been able to solve the /etc/apt/sources.list problem (wrong syntax) and was able to update/upgrade everything.
Of all the packages to upgrade, 75 were security fixes

I expanded the /ext4 partition from 1.75 to 3.0Gb, installed mc and purged all the vim stuff. 
Once I get all the rest done, I will see about upgrading.

Q: does the the FAT16 partition need resizing?

Thanks for your input.

Best,

A.

Hello:

Welcome to Devuan.
Before I forget, have a read here.

Yes, seen that, been there and solved it.

The problem is that the CUPS archives have been sequestered by the assholes at Apple Corp. and are no longer accessible.
But I found my old CUPS mailing list posts (thanks to rbit) through the Wayback Machine:

https://lists.cups.org/pipermail/cups/2 … 75402.html
https://lists.cups.org/pipermail/cups/2 … 75403.html

TL;DR:
Yes, a package is probably missing.
Read all the links to get the necessary information.

My printer is one of those USB B&W laser M2020W marketed by Samsung / HP but I am confident the solution is probably the same / similar.
I do not use any HP drivers, just the CUPS supplied stuff from the Devuan repositories.     
It may be a good thing to remove anything not downloaded from the Devuan repositories, more so it it did not solve the problem.

Should push come to shove, check the post I linked to at the beginning for a place to ask specific CUPS questions.

Let us know how you fared with this.

Best,

A.