Package Details: backintime-cli 1.5.3-2

Git Clone URL: https://aur.archlinux.org/backintime.git (read-only, click to copy)
Package Base: backintime
Description: Simple backup system inspired from the Flyback Project and TimeVault. CLI version.
Upstream URL: https://github.com/bit-team/backintime
Licenses: GPL
Submitter: None
Maintainer: graysky
Last Packager: graysky
Votes: 299
Popularity: 2.20
First Submitted: 2009-01-09 20:46 (UTC)
Last Updated: 2024-11-13 15:34 (UTC)

Pinned Comments

graysky commented on 2023-10-07 12:15 (UTC)

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.

Latest Comments

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 73 Next › Last »

orschiro commented on 2013-11-05 12:53 (UTC)

@Germar It raises the exception: ~ $ gksu -- python2 -c "import keyring" [...] 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. I have no idea what caused the delay in the first place, but I think it is working now responsively. In case I have this issue again, I will report again. Thanks!

Germar commented on 2013-11-04 22:18 (UTC)

Hmm, strange. My last patch should set 'BIT_USE_KEYRING=false' automatically after 'import keyring' first time raised an exception and block subsequent 'import keyring'. Looks like this doesn't work on your system. Please post the output of 'gksu -- python2 -c "import keyring" ' This should normally raise dbus.exceptions.DBusException

orschiro commented on 2013-11-04 21:45 (UTC)

@Germar I did not patch it manually but installed the updated PKGBUILD. Yet I can confirm that your first hack is working like a charm. The GUI is responsive and startup fast as hell. :) ~ $ BIT_USE_KEYRING=false gksu backintime-gnome gksu-run: :0 gksu-run: gksu/backintime-gnome/7765-0-thinkpad_TIME0 gksu-run: d2939297000f65e4dbf60514332d3568 WARNING: import keyring failed

Germar commented on 2013-11-04 20:32 (UTC)

@orschiro did you manually patch /usr/lib/python2.7/site-packages/keyring/backends/SecretService.py to not throw an exception anymore? Please try to run 'BIT_USE_KEYRING=false gksu backintime-gnome' (this should start BIT immediately without timeout on start). If that will still give you an unresponsive GUI please comment out lines 28-32 in /usr/share/backintime/common/tools.py (starting from 'try:' to 'os.putenv(...)' including those lines) If this both doesn't fix it I'd say there is an other problem on your system ;-)

orschiro commented on 2013-11-04 07:16 (UTC)

@Germar Thanks for the patch. However, the GUI is still very unresponsive. One example is profile switching which takes ~45 seconds. But never mind. Can be also a problem on my system only.

graysky commented on 2013-11-04 00:58 (UTC)

Bump to v1.0.28-6 Changelog: Applied upstream patch #2 to fix gksu issues. Commit: http://pkgbuild.com/git/aur-mirror.git/commit/backintime?id=e83d55b1cdf14fd1d0a361c9d9956c2709a74001

Germar commented on 2013-11-03 20:06 (UTC)

@graysky please replace gksu_backintime-gnome.patch with the one in http://pastebin.com/hPAk2JXt This will fix the unresponsive GUI reported by orschiro.

Germar commented on 2013-10-31 20:40 (UTC)

@orschiro I can confirm the unresponsive GUI now. There is something repeatedly trying to 'import keyring' again and again and always running into the same timeout. That shouldn't happen. I'll have a look.

orschiro commented on 2013-10-31 20:08 (UTC)

@Germar Sorry for having been sloppy. The ~30sec startup time for the GUI to come up is totally fine for me. And I thought your workaround referred only to this. Yet the unresponsive GUI is slightly annoying since I can never be sure if my button clicks where already recognised and simply take time to be processed. Thus I wanted to make sure if it is related to the workaround as well or another problem on my system.

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 73 Next › Last »