Back In Time 1.3.3-4 -> which *-keyring?
Hello: My Linux box runs BiT 1.3.3-4, the latest version available in the repositories. [code] $ apt list | grep installed | grep backintime --- snip --- backintime-common/stable,stable,now 1.3.3-4 all [installed] backintime-qt/stable,stable,now 1.3.3-4 all [installed,automatic] $ [/code] Have used it for the longest time, saved my files more than once. Thanks to all those involved for that. That said, I have something to which I need some insight into: 1. I understand that BiT will use whatever available keyring it finds. 2. For reasons, it turns out that my system has more than one keyring available: [code] $ apt list | grep installed | grep keyring --- snip --- debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed] devuan-keyring/stable,stable,now 2023.05.28 all [installed] gnome-keyring/stable,now 42.1-1+b2 amd64 [installed] python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic] python3-keyrings.alt/stable,stable,now 4.2.0-1 all [installed,automatic] $ [/code] I'm not a fan of gnome 'anything' and as a result I only have one gnome application installed: gnome-disk-utility, which is actually quite handy. Recently, wondering if gnome-keyring was used by gnome-disk-utility, I asked aptitude ... [code] $ 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 $ [/code] ... only to find out that it is (indirectly) used by backintime-common. ie: backintime-common >depends> python3-keyring >depends> python3-secretstorage >recommends gnome-keyring |or| libkf5wallet-bin (>= 5.97) |or| keepassxc As libkf5wallet-bin seems to be a transitional package which can be removed (if it were installed), the only options for BiT would be gnome-keyring or keepassxc. But it happens that if I purge gnome-keyring, BiT won't work and keepassxs is not installed. Q1: why are gnome-keyring and keepassxc 'recommended' packages and not dependencies? Just asking, seems odd. Q2: how could I safely (and not breaking anything) switch from gnome-keyring to keepassxc? The less gnome I have, the better. Thanks in advance. Best, JHM
Hello JMH, Thank you for your message. On 2025-07-10 16:30 sawbona--- via Bit-dev <bit-dev@python.org> wrote:
Q1: why are gnome-keyring and keepassxc 'recommended' packages and not dependencies? Just asking, seems odd.
This is not the case. I am assuming you miss use the apt tools on your shell. Please see this URL for relations to other packages: <https://packages.debian.org/en/sid/backintime-common>
Q2: how could I safely (and not breaking anything) switch from gnome-keyring to keepassxc? The less gnome I have, the better.
I don't know. I am also a keypassxc user, but was not aware that it could act like a keyring. Are you sure this would work? Regards, Christian Buhtz
Hello C.Buhtz: Thank you for getting back to me on this. c.buhtz＠posteo.jp wrote:
This is not the case. I see ... ... assuming you miss use the apt tools on your shell. Yes, most probably. 8^° Sorry about that.
This is what aptitude prints out when I ask about gnome-keyring: [code] $ 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 $ [/code]
<https://packages.debian.org/en/sid/backintime-common> Right ... So no gnome-keyring or keepassxc dependencies for BiT? Good to know.
The thing is that when I saw that gnome-keyring was a *recommends* I purged it. But then BiT would not work, so I had to re-install it and things went back to normal. I do not use gnome-keyring (or any other keyring for that matter). Just don't like the idea of passwords stored in my box so, for the time being, I rely on other, less sophisticated methods I feel more comfortable with. I would then have to re-phrase my original question: How can I get rid my system of gnome-keyring and not screw up the BiT process? BiT is important to me, has saved my files more than once. From what I see in the link you kindly provided, my guess is that python3-keyring would work and be enough (?) but I cannot find out how make the switch. Thanks in advance. Best regards, JHM
Hello C.Buhtz: sawbona＠gmx.net wrote:
my guess is that python3-keyring would work and be enough ... While searching the web for *BiT* and *keyring* related posts/entries I came across this Debian bug report against backintime-qt from 10/2021.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998105> The last entry is from 12/2023 and it would seem (?) to me that the issue I have posted *may* be related to that bug report. ie: as BiT will not work if I purge gnome-keyring, I think we can safely say that it is using gnome-keyring instead of the presently installed python3-keyring. (23.9.3-2) I'd appreciate your comments. Thank you for your time and attention. Best regards, JHM
Hello sawbona, I don't have a clear answer because I am not deep enough into the keyring related details of BIT. Maybe someone else on the list can provide you with an enhanced answer. Please also refer to the FAQ. Please see the projects background information to get an idea about our workflow., priorities and why we sometimes don't have the answers: - Maintenance status: https://github.com/bit-team/backintime#maintenance-status) - The team: https://github.com/bit-team/backintime#the-team - Strategy outline / Roadmap: https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md#strategy-out... Best regards, Christian
Hello: sawbona＠gmx.net wrote:
... issue I have posted *may* be related to that bug report. Yes, it is.
@c.buhtz Thanks for the link to the FAQs. For some reason I thought the problem at hand was of a murkier nature (incompatibility between packages or similar) but it turned out to be quite simple: BiT did not *automagically* choose the available backend to use. It seems that getting that done is a rather complex matter so the solution is to add an option for that to the BiT GUI. That is still a work in progress to be included in the next (?) upstream release. As is usual in a Linux environment, there was a quick, clean and easy alternative: set it up manually, ending the bloody problem in 5'. Could not have been easier. If someone else comes across this same problem, the solution is within the BiT FAQs: <https://github.com/bit-team/backintime/blob/dev/FAQ.md#problems-errors--solu...> TL:DR backintime FAQs wrote: > To diagnose and solve this follow these steps in a terminal: > # Show default backend > python3 -c "import keyring.util.platform_; print(keyring.get_keyring().__module__)" > # List available backends: > keyring --list-backends > # Find out the config file folder: > python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())" > # Create a config file named "keyringrc.cfg" in this folder with one of the available backends (listed above) > [backend] > default-keyring=keyring.backends.kwallet.DBusKeyring As I make it a point to comment generated / modified *.conf files, I found that I *already* had a "keyringrc.cfg" file in my system. I had generated it back in 03/2021 because (the same problem?) of <https://github.com/jaraco/keyring/issues/391>. ie: backintime fails because it cannot make sense of the ChainerBackend <--- * quoting OP by Bentolor Once done, you should get something like this: [code] $ python3 -c "import keyring.util.platform_; print(keyring.get_keyring().__module__)" keyring.backends.chainer $ [code] I have purged gnome-keyring and have only the *necessary* keyrings: [code] $ apt list | grep installed | grep keyring --- snip --- debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed] devuan-keyring/stable,stable,now 2023.05.28 all [installed] python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic] $ [/code] BiT seems to work properly / as expected (manually generated snapshot), will report back if anything is amiss. Thank you very much for your input. Best, A.
On Thu, 2025-07-10 at 16:30 +0000, sawbona--- via Bit-dev wrote:
As libkf5wallet-bin seems to be a transitional package which can be removed (if it were installed), the only options for BiT would be gnome-keyring or keepassxc.
At least for me in Debian Trixie/testing, libkf5wallet-bin is a transitional package because it's the old name for Kwallet (you can see it Depends: kwallet6). So kwallet6 is an option. In Bookworm, it's a fully fledged package rather than a transitional.
But it happens that if I purge gnome-keyring, BiT won't work and keepassxs is not installed.
Q1: why are gnome-keyring and keepassxc 'recommended' packages and not dependencies? Just asking, seems odd.
gnome-keyring, keepassxc, and kwallet6/libkf5wallet-bin provide the D- Bus Secret Service API (for storing secrets) which python3-secretstorage can consume, so it recommends one of them is installed. It's not required though. Note that in Trixie, these were downgraded[1] to suggested packages, so apt does not install one of them by default anymore. This was as a result of discussion[2] on Debian's packaging policy wrt. to libraries that speak to daemons.
Q2: how could I safely (and not breaking anything) switch from gnome-keyring to keepassxc? The less gnome I have, the better.
Theoretically, installing keepassxc and removing gnome-keyring should work? You should also be able to have none of these options installed and it should work fine without. -- Maytham [1] https://tracker.debian.org/news/1493252/ [2] https://lists.debian.org/debian-devel/2024/01/msg00098.html
Hello:
... also be able to have none of these options installed and it should work fine without.
On the dot ... See my last post. ie: BiT works fine without any of those options installed. I purged gnome-keyring and now have only the *necessary* keyrings: [code] $ apt list | grep installed | grep keyring --- snip --- debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed] devuan-keyring/stable,stable,now 2023.05.28 all [installed] python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic] $ [/code] All this is probably due to my system having started as Jesse (or ascii?) and is now, after a seies of dist-upgrades, at Daedalus. No matter, it has remained and probably will remain resilient enough. Probably only needs a bit more housekeeping. Thanks for your input. Best, JHM
participants (3)
-
c.buhtz＠posteo.jp -
Maytham Alsudany -
sawbona＠gmx.net