Package Details: yabsnap 2.2.10-1

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)

Required by (0)

Sources (1)

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 -

  1. Post a note and ask users to remove yabsnap and reinstall it. Does not seem like a good idea.

  2. 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?

error: failed to commit transaction (conflicting files)
yabsnap: /usr/share/yabsnap/code/__pycache__/__init__.cpython-313.pyc exists in filesystem
yabsnap: /usr/share/yabsnap/code/__pycache__/auto_cleanup_without_ttl.cpython-313.pyc exists in filesystem
...

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:

install: cannot stat 'yabsnap.1.gz': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

I can't say I know much about how PKGBUILDs work, but it looks as though package() is being called before check(), therefore install -Dm 644 "$pkgname".1.gz [...] is being called before gzip -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).