Search Criteria
Package Details: swaylock-1.5 1.5-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/swaylock-1.5.git (read-only, click to copy) |
---|---|
Package Base: | swaylock-1.5 |
Description: | Screen locker for Wayland with layers support, enabling dynamic compositor blurring |
Upstream URL: | https://github.com/swaywm/swaylock |
Licenses: | MIT |
Conflicts: | swaylock |
Submitter: | Icelk |
Maintainer: | Icelk |
Last Packager: | Icelk |
Votes: | 1 |
Popularity: | 0.000017 |
First Submitted: | 2023-03-15 18:13 (UTC) |
Last Updated: | 2023-11-19 23:14 (UTC) |
Dependencies (9)
- cairo (cairo-gitAUR)
- gdk-pixbuf2 (gdk-pixbuf2-gitAUR)
- libxkbcommon (libxkbcommon-gitAUR)
- pam (pam-selinuxAUR)
- wayland (wayland-gitAUR, wayland-asan-gitAUR, wayland-chromiumAUR)
- git (git-gitAUR, git-glAUR) (make)
- meson (meson-gitAUR) (make)
- scdoc (scdoc-gitAUR) (make)
- wayland-protocols (wayland-protocols-gitAUR) (make)
Latest Comments
Icelk commented on 2023-11-19 23:16 (UTC) (edited on 2023-11-19 23:16 (UTC) by Icelk)
@MarsSeed Sorry for the late response.
I removed it from
provides
. The source is now commit-specific.The dir is still renamed to the package's name. I presume that's what you meant.
Since this is a end-user binary package, dependents aren't expected. It's depended on in my dotfiles: https://github.com/Icelk/dotfiles/blob/78a2d303db1e52ee0523f3bc4c51ffba194e944c/packages/installed.txt#L153
MarsSeed commented on 2023-10-14 09:13 (UTC)
And don't rename the repo directory please.
MarsSeed commented on 2023-10-14 09:12 (UTC)
Hm, also please eliminate using git checkout. Declare the source commit in the source=() array.
MarsSeed commented on 2023-10-14 09:11 (UTC)
On AUR, I don't see any packages that depend specifically on this one. Which are the ones that only work properly with this?
MarsSeed commented on 2023-10-14 09:10 (UTC)
Noted. Thank you for replying.
Is there a bug report about the issues at upstream's GitHub and in Arch bug tracking system?
Also, if this is API-incomlatible, then it shouldn't provide 'swaylock', as it's not a drop-in replacement. Downstream dependents should expect either this, or repo 's swaylock, but not let the user decide which to use with that.
Icelk commented on 2023-10-14 08:46 (UTC)
@MarsSeed please see the comment below
Icelk commented on 2023-10-14 08:46 (UTC)
There has been a delete request to this package. It's still needed, since modern swaylock uses a different API which limits certain use-cases, such as transparent lock screens.