Search Criteria
Package Details: yabsnap 2.2.10-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: | 11 |
Popularity: | 1.09 |
First Submitted: | 2022-10-08 18:00 (UTC) |
Last Updated: | 2025-08-03 19:59 (UTC) |
Dependencies (5)
- bash (bash-devel-gitAUR, bash-gitAUR)
- btrfs-progs (btrfs-progs-gitAUR)
- python (python37AUR)
- tar (tar-gitAUR) (make)
- rsync (rsync-gitAUR, rsync-reflink-gitAUR, rsync-reflinkAUR) (optional) – rsync based snapshot support
Latest Comments
1 2 Next › Last »
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
--overwrite
also 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?
BlockyPenguin commented on 2025-04-11 11:00 (UTC)
Build fails with this error:
I can't say I know much about how PKGBUILDs work, but it looks as though
package()
is being called beforecheck()
, thereforeinstall -Dm 644 "$pkgname".1.gz [...]
is being called beforegzip -c "$pkgname".manpage > "$pkgname".1.gz
.hirak99 commented on 2023-07-11 07:28 (UTC)
Confirmed it's fixed for paru, https://github.com/hirak99/yabsnap/issues/10
Thanks for reporting it!
hirak99 commented on 2023-07-11 06:58 (UTC)
Ahh that line (without $PKGDIR/) is correct, since the link needs to target the final destination of the file which is outside $PKGDIR and in the actual root.
But the chmod was an error and is unnecessary (since chmod apparently does not do anything on symlinks).
I couldn't reproduce with yay - I believe paru catches the error.
Updated, could you please try once more?
The version should be 2.0.4 now (please wait for the cache to update if you see 2.0.3).
1 2 Next › Last »