Package Details: alarm-clock-applet 1.0.1-5

Git Clone URL: (read-only, click to copy)
Package Base: alarm-clock-applet
Description: A fully-featured alarm clock for GTK panel
Upstream URL:
Keywords: alarm applet clock desktops for gtk
Licenses: GPL2
Submitter: gwash
Maintainer: linuxergr
Last Packager: linuxergr
Votes: 97
Popularity: 0.26
First Submitted: 2008-08-23 19:27
Last Updated: 2020-12-16 11:55

Latest Comments

1 2 3 Next › Last »

linuxergr commented on 2020-12-16 11:49

Hi @mrpg,

Added as an optional dependency, because not all users use those sounds.


mrpg commented on 2020-12-16 08:32

I figured it out. gnome-control-center provides the sounds and should be added as a (maybe optional) dependency.

mrpg commented on 2020-12-16 08:24

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

@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

But, in any case namcap should provide that info, if it is a strict line, otherwise is considered as a soft one.


IrvineHimself commented on 2020-11-22 13:17

I think what people are trying to say is that:

1) /usr        ->   all resources managed by pacman

2) /usr/local  ->   all resources *not* managed by pacman

For example, an overview of the contents of my /usr/local dir:

a) /usr/local/bin             ->  symlinks to my own executables and scripts in /usr/local/lib

b) /usr/local/bin/FjSymlinks  ->  symlinks to automatically enable firejail

c) /usr/local/lib             ->  folders containing my own executables

d) /usr/local/share           ->  shared non-executable resources, eg wallpapers, icons, audio alarms... etc

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


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

What is the difference between manual build and my PKGBUILD? No need to change it.

kyechou commented on 2020-11-22 07:29

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

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

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.

mojo-hakase commented on 2020-11-21 23:15

The package installs all files under /usr/local which it shouldn't. The call to configure should be changed to ./configure --prefix=/usr