Arch Linux User Repository

Using an AUR helper such as yay to build packages including backintime is HIGHLY discouraged. The recommended build method is to use a clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.

Please stop posting build failures because you insist on building with yay or other AUR helpers.

@graysky I'm not using makepkg/pacman, I'm using the excellent "yaourt" tool (check https://wiki.archlinux.org/index.php/yaourt ) that includes the full functionalities of pacman, plus automatizes compilation/installation of AUR packages. yaourt builds the packages, and installs every produced package it finds. If the build produced several final packages, it installs them all. If the build produced mutually-incompatible packages, then it breaks. Also, backintime-kde4 and backintime-gnome were *not* incompatible in previous packages versions, and I'd like to have both installed, because I have both environments on my systems, and different users use different environments, so having both backintime versions installed is great. What used to work 3 days ago, doesn't work anymore, that's why I say it's now broken.

Oh, I forgot an other option: I could just catch the exception that is thrown on 'import keyring' and deactivate storing passwords in keyring in that case (there would still be a ~30sec timeout). While root normally doesn't have a Keyring (and so 'gksu backintime' neither) this wouldn't make any difference. I think I would preferred this option ;)

@graysky you're right. This has nothing to do with the package split. It is a bug in python2-secretstorage (upstream, not in Runiq's AUR package). I don't know how to fix this by now. But I would like to discus the options: With python2-keyring 3.X the python2-gnomekeyring fail silently and refuse to work. This is because BIT statically import gtk with 'import gtk' (old variant with gtk 2.0) and python2-gnomekeyring dynamically import Gtk with 'from gi.repository import Gtk' (new variant with Gtk+ 3.0). As a workaround in the fix I provided for 1.0.26 I imported 'keyring' before 'gtk'. So gnomekeyring was working again but there was 'Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed' during every start of BIT and I was afraid this could cause a segfault in BIT. So I decide to remove 'import keyring' before 'import gtk' again and let gnomekeyring fail silently. python2-secretstorage does the same and should replace python2-gnomekeyring. If all would have went well you could remove python2-gnomekeyring. As long as the bug in python2-secretstorage isn't fixed we could go back like it was done in the fix (just add 'import keyring' at the start of gnome/app.py, remove python2-secretstorage but keep python2-gnomekeyring) and risk a segfault. An other fix would be to port BIT from gtk 2.X to Gtk+ 3.0 which would take enormous effort. And in long terms I'm actually thinking about removing backintime-gnome completely and only provide a pure backintime-qt4 (didn't discus this with anyone yet). The current backintime-kde4 uses lots of KDE bindings but I think they could be transformed to pure Qt4 with relative low effort. This would make future dev lot easier because we don't need to handle two GUI's anymore. The Gnome GUI is quite a mess in code anyways. KDE GUI was rewritten and is more straight. BTW: the 'backintime-qt4' package name is misleading. As I stated above it uses KDE4 not pure Qt4.

@Germar - Please advice on a solution since this seems to be an upstream bug. Also, you wrote, "python-keyring changed from 1.6.1 to 3.X and we added python2-secretstorage dependencies as replacement for python-gnomekeyring." That is not totally accurate since the pkg depends on both: * python2-secretstorage * python2-gnomekeyring Is this correct or is python2-secretstorage meant to actually replace python2-gnomekeyring? In other words, should I modify the dependency array?

@orschiro - I don't think that statement is accurate, in other words, the split package has nothing to do with this error. I have old versions of my packages (or you too may download one from the aur-mirror.git[1] for this package). I can verify that indeed 1.0.26-6 can reproduce this bug: % gksu backintime-gnome Traceback (most recent call last): File "/usr/share/backintime/gnome/app.py", line 23, in <module> import keyring File "/usr/lib/python2.7/site-packages/keyring/__init__.py", line 12, in <module> from .core import (set_keyring, get_keyring, set_password, get_password, File "/usr/lib/python2.7/site-packages/keyring/core.py", line 141, in <module> init_backend() File "/usr/lib/python2.7/site-packages/keyring/core.py", line 63, in init_backend keyrings = backend.get_all_keyring() File "/usr/lib/python2.7/site-packages/keyring/util/__init__.py", line 24, in wrapper func.always_returns = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/keyring/backend.py", line 127, in get_all_keyring exceptions=TypeError)) File "/usr/lib/python2.7/site-packages/keyring/util/__init__.py", line 35, in suppress_exceptions for callable in callables: File "/usr/lib/python2.7/site-packages/keyring/backend.py", line 119, in is_class_viable keyring_cls.priority File "/usr/lib/python2.7/site-packages/keyring/util/properties.py", line 20, in __get__ return self.fget.__get__(None, owner)() File "/usr/lib/python2.7/site-packages/keyring/backends/SecretService.py", line 28, in priority secretstorage.Collection(bus) File "/usr/lib/python2.7/site-packages/secretstorage/collection.py", line 35, in __init__ collection_obj = bus_get_object(bus, SECRETS, collection_path) File "/usr/lib/python2.7/site-packages/secretstorage/util.py", line 42, in bus_get_object return bus.get_object(name, object_path) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 241, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 248, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 180, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 278, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. 1. http://pkgbuild.com/git/aur-mirror.git/log/backintime

python-keyring changed from 1.6.1 to 3.X and we added python2-secretstorage dependencies as replacement for python-gnomekeyring

@Germar The gksu bug is interesting because it worked flawlessly before the package splitting. Now idea what changed since then though.

Regarding backintime-askpass: this is bad coding by me (shame on me ;) ). backintime-askpass is missing environs ASKPASS_PROFILE_ID and ASKPASS_MODE. But you don't need to start backintime-askpass at all. It is used by ssh-add and encfs and in that time Backintime set those environs by it self. You don't need to report this upstream. I'm aware of now and will take care. regarding gksu backintime-gnome: I got a hint about this bug some month ago on Xubuntu and reported that on https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1181344. No response yet. Maybe that wasn't the right place for the bug. I'll try to bump that bug. Kind regards, Germar, BIT-Team PS: I'd appreciate some feedback about new udev schedule.

Nothing is badly broken; stop using AUR helper scripts if you don't understand the basics of makepkg/pacman. 1) makepkg -src 2) pacman -U name.pkg.tar.xz Where name is one of the following: backintime = cli only backintime-gtk = gtk client+cli backintime-gnome = gnome client+cli (only difference here is more deps) backintime-qt4 = kde4 client+cli

Latest version is badly broken: - Cannot install using "yaourt" as it generates 4 mutually-incompatible packages (which wasn't previously the case) - Now impossible to run and backup as root, both the -kde4 version with kdesudo, or gnome version with gksu, bail out in error complaining about a Dbus issue. ...And I badly need to be able to continue performing my system's backups as root...