Search Criteria
Package Details: alarm-clock-applet 1:0.4.1-4
Package Actions
Git Clone URL: | https://aur.archlinux.org/alarm-clock-applet.git (read-only, click to copy) |
---|---|
Package Base: | alarm-clock-applet |
Description: | A fully-featured alarm clock for use with an AppIndicator implementation. |
Upstream URL: | https://alarm-clock-applet.github.io/ |
Keywords: | alarm applet clock desktops for gtk |
Licenses: | GPL2 |
Conflicts: | alarm-clock-applet-git |
Submitter: | gwash |
Maintainer: | linuxergr (tatokis) |
Last Packager: | tatokis |
Votes: | 106 |
Popularity: | 0.000119 |
First Submitted: | 2008-08-23 19:27 (UTC) |
Last Updated: | 2024-08-29 21:38 (UTC) |
Dependencies (16)
- gettext (gettext-gitAUR)
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR)
- gst-plugins-base (gst-plugins-base-gitAUR)
- gst-plugins-good (gst-plugins-good-gitAUR)
- gstreamer (gstreamer-gitAUR)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classicAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR)
- libayatana-appindicator
- libnotify (libnotify-gitAUR)
- cmake (cmake-gitAUR) (make)
- glib2-devel (make)
- gzip (dxcompress-gitAUR, dxcompressAUR, gzip-gitAUR, busybox-coreutilsAUR) (make)
- perl (perl-gitAUR) (make)
- pkgconfig (pkgconf-gitAUR, pkg-config-gitAUR, pkgconf) (make)
- gconfAUR (optional)
- gnome-control-center (gnome-control-center-gitAUR, gnome-control-center-x11-scalingAUR) (optional)
- playerctl (playerctl-gitAUR) (optional)
Latest Comments
« First ‹ Previous 1 2 3 4 Next › Last »
LeSnake commented on 2021-04-12 08:26 (UTC) (edited on 2021-04-12 08:31 (UTC) by LeSnake)
libunique was removed from AUR :/ There is a libunique3 but also the code wants libunique, so just fixing the pkgbuild doesnt work
linuxergr commented on 2020-12-16 11:49 (UTC) (edited on 2020-12-16 12:10 (UTC) by linuxergr)
Hi @mrpg,
Added as an optional dependency, because not all users use those sounds.
Regards
<deleted-account> commented on 2020-12-16 08:32 (UTC)
I figured it out.
gnome-control-center
provides the sounds and should be added as a (maybe optional) dependency.<deleted-account> commented on 2020-12-16 08:24 (UTC)
Thanks for this wonderful application!
One quick question though: After I reinstalled my system, I no longer have access to the sounds (such as the bark, etc.). Which package provides these sounds, and could this package be added as a dependency? Thanks.
linuxergr commented on 2020-11-22 13:59 (UTC)
@irvineHimselh, thanks for the detailed explanation.
I use namcap as a linter for my PKGBUILDs, and such an issue was never reported from it.
In any case, and ever since is not hard for me to shift it from /usr/local to /usr, I provide an updated PKGBUILD https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=alarm-clock-applet
But, in any case namcap should provide that info, if it is a strict line, otherwise is considered as a soft one.
Regards
IrvineHimself commented on 2020-11-22 13:17 (UTC) (edited on 2020-11-22 13:50 (UTC) by IrvineHimself)
I think what people are trying to say is that:
For example, an overview of the contents of my /usr/local dir:
The reason for this arrangement is because it is more secure than keeping these resources in my ${HOME} dir, and makes for easy maintenance.
To the best of my knowledge, this is the intended use of /usr/local, and, as such, installing externally maintained packages here seriously screws up the structure.
A point to note is that, if I was to publish my own executables and was careless with the pre-publication clean up, then the package would point to /usr/local :)
Hope this helps
Irvine
EDIT: A further point to note is that, since /usr/local/bin is the first item in the ${PATH}, it is fairly easy to intercept a call to a pacman maintained binary. This is not the case if said binary is not installed to /usr/bin.
linuxergr commented on 2020-11-22 10:59 (UTC)
What is the difference between manual build and my PKGBUILD? No need to change it.
kyechou commented on 2020-11-22 07:29 (UTC) (edited on 2020-11-22 07:45 (UTC) by kyechou)
Also, I don't think /usr/local is any safer than /usr if all packages are managed by pacman. Please correct me if I misunderstood.
kyechou commented on 2020-11-22 07:25 (UTC)
I think for Arch, /usr/local is supposed to be used for manually-built applications, as indicated in the link provided by @mojo-hakase, and /usr for pacman-managed packages.
linuxergr commented on 2020-11-22 01:02 (UTC)
Why it should not?
/usr/local is safer than /usr and is the default of alarm-clock-applet installation
check the build() function which is the default one.
« First ‹ Previous 1 2 3 4 Next › Last »