Package Details: alarm-clock-applet 1.0.1-5

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 GTK panel
Upstream URL: http://alarm-clock.pseudoberries.com
Keywords: alarm applet clock desktops for gtk
Licenses: GPL2
Submitter: gwash
Maintainer: linuxergr
Last Packager: linuxergr
Votes: 101
Popularity: 1.18
First Submitted: 2008-08-23 19:27
Last Updated: 2020-12-16 11:55

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

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 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

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

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

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

https://wiki.archlinux.org/index.php/Creating_packages#build%28%29

linuxergr commented on 2020-09-19 21:27

The project is been officially forked and so it is going to be maintained by me, as also the PKGBUILD.

Note that the build has been corrected alone with the code.

I wish that this very nice applet, will keep on existing, as already works with libindicator-gtk3, in our Linux Desktops

Jakeukalane commented on 2020-06-04 02:51

I have the same error as vishnu.

vishnu commented on 2020-05-21 13:35

Getting these errors

/usr/bin/ld: alarm-gconf.o:(.bss+0x0): multiple definition of app_command_map'; alarm-applet.o:(.bss+0x0): first defined here /usr/bin/ld: ui.o:(.bss+0x0): multiple definition ofapp_command_map'; alarm-applet.o:(.bss+0x0): first defined here /usr/bin/ld: alarm-actions.o:(.bss+0x0): multiple definition of app_command_map'; alarm-applet.o:(.bss+0x0): first defined here /usr/bin/ld: alarm-list-window.o:(.bss+0x0): multiple definition ofapp_command_map'; alarm-applet.o:(.bss+0x0): first defined here /usr/bin/ld: alarm-settings.o:(.bss+0x0): multiple definition of app_command_map'; alarm-applet.o:(.bss+0x0): first defined here /usr/bin/ld: prefs.o:(.bss+0x10): multiple definition ofapp_command_map'; alarm-applet.o:(.bss+0x0): first defined here