Search Criteria
Package Details: yabsnap 2.4.1-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/yabsnap.git (read-only, click to copy) |
|---|---|
| Package Base: | yabsnap |
| Description: | Btrfs automated snapshot manager. |
| Upstream URL: | https://github.com/hirak99/yabsnap |
| Licenses: | Apache |
| Submitter: | hirak99 |
| Maintainer: | hirak99 |
| Last Packager: | hirak99 |
| Votes: | 17 |
| Popularity: | 0.92 |
| First Submitted: | 2022-10-08 18:00 (UTC) |
| Last Updated: | 2026-06-15 10:37 (UTC) |
Dependencies (6)
- bash (bash-gitAUR, bash-devel-gitAUR)
- btrfs-progs (btrfs-progs-gitAUR, btrfs-progs-experimental-gitAUR)
- python
- tar (tar-gitAUR, uutils-tar-gitAUR) (make)
- python-textual (python-textual-gitAUR) (optional) – for the TUI interface
- rsync (rsync-gitAUR) (optional) – rsync based snapshot support
Latest Comments
1 2 Next › Last »
hirak99 commented on 2026-06-15 10:30 (UTC)
Pushed v2.4.1. It should fix this error now and in the future.
PYTHONDONTWRITEBYTECODE=1to yabsnap.sh to stop runtime generation of bytecode files as root; since they are part of the package.hirak99 commented on 2026-06-15 09:27 (UTC)
Ack. It is likely because of Python version change inbetween. The current PKGBUILD does not seem to handle it. Let me look into fixing it.
Itmw, a workaround is to uninstall and reinstall.
e_Irbis commented on 2026-06-15 09:13 (UTC)
After the latest update, the installation fails with an error.
hirak99 commented on 2025-08-03 20:02 (UTC)
Made the change - update should work without breaking, switched to -O, took ownership, also added a .install line to delete previous .pyc files after the upgrade.
I think I pulled it off. Please LMK if you encounter anything bad! 🤞
hirak99 commented on 2025-08-03 19:33 (UTC)
Sorry I didn't see your note - But using
--overwritealso requires user's action, essentially similar to 1.I'd like to avoid breaking this for unsuspecting users if I can save it.
hirak99 commented on 2025-08-03 19:30 (UTC)
I see two ways -
Post a note and ask users to remove yabsnap and reinstall it. Does not seem like a good idea.
We could start owning optimized files (.opt-1.pyc). We can also switch the yabsnap script to
python -O ...so that they are actually used (and also .pyc are not automatically created). The issue with this is assert's are lost, which I don't think is as bad as 1. And after enough time has passed, we should be able to turn off -O and take ownership of unoptimized .pyc, if we want to.JMHoffmann commented on 2025-08-03 19:04 (UTC)
pacman has the --overwrite option. You can use a glob to allow all files that have the same prefix to be overwritten.
hirak99 commented on 2025-08-03 18:48 (UTC) (edited on 2025-08-03 18:52 (UTC) by hirak99)
Yes, but if I do that, since the
__pycache__dirs were not previously owned, it creates a conflict. What's the best way around it?JMHoffmann commented on 2025-08-03 17:47 (UTC)
Can you please precompile the python files so they don't have to be compiled on first use.
Currently it only works incidentally as yabsnap is commonly run as root so files can be written into /usr/share/yabsnap/code/. Secondly these pyc files are not associated with a package and show up as lost files and are also not cleaned up on package removal.
To do this you can use the build-in python module "compileall" on the yabsnap python package root in the PKGBUILD.
hirak99 commented on 2025-04-11 11:48 (UTC)
Interesting. I made a small change and pushed 2.2.5-2. Would you kindly retry?
1 2 Next › Last »