# alarm clock



## nedry (Nov 16, 2016)

Does anyone know of a good alarm clock timer program for FreeBSD? I have looked at x11-clocks/ktimer but I need one that sounds an alarm when the countdown is finished. Something like the windows timer app. Yes, I know trying to emulate some windows features it's just I would like to move away from Windows 10 and until I can find some good replacement software I will still have to have some MS.
nedry


----------



## scottro (Nov 16, 2016)

Would something like a cronjob work--that is, at such and such a time every day, have some media player play a sound. More work than clicking a GUI, and I'm sure someone will chime in with a better solution, but it's not that hard to do.


```
0 7 * * * /usr/local/bin/mpv ~scottro/airhorn.mp3
```
Would play an airhorn sound at 7:00 AM every day, assuming it's in $HOME/scottro's directory.


----------



## SirDice (Nov 17, 2016)

It's better to use at(1) for that. Also have a look at leave(1) and calendar(1).

A really poor man's solution is something like `sleep 3600 && wavplay ~/myalarm.wav`


----------



## Anglican (Nov 17, 2016)

I use the alarm-clock applet. It compiles and runs just fine for FreeBSD.

http://alarm-clock.pseudoberries.com/


----------



## nedry (Nov 17, 2016)

Looks like its just what i want!! could someone make a port of this???
thanks nedry


----------



## marino (Nov 17, 2016)

yes, you can.  https://www.freebsd.org/doc/en/books/porters-handbook/own-port.html


----------



## tobik@ (Nov 17, 2016)

ILUXA created one a while back, but nobody has committed it: PR 208160


----------



## SirDice (Nov 17, 2016)

Try the submitted port and if it works (or not) add your findings to the PR. That should make it float back to the top again. Hopefully that's enough to get it back on the radar.


----------



## marino (Nov 17, 2016)

new ports PR are generally difficult, but especially difficult when the submitter fails to show the output of portlint and fails to include poudriere (or synth) logs proving that it builds cleanly.


----------



## marino (Nov 17, 2016)

Did I not just do that?
There are many new port PRs, many never touched.
In general, new ports are a lot more work than maintenance PRs.
Secondly, many people that submit new ports are novices, and their submissions have many many problems with them.
Thirdly, if somebody submits a new port WITHOUT ANY PROOF THAT IT BUILDS CLEANLY AND HAS NO PORTLINT ERRORS then very likely they will be ignored in favor of a new port that did provide that proof.

If there are 300 ports PRs that need claiming, and there's no queue, then it's in the submitter's favor to make their submission appealing.  No poudriere or synth logs is not appealing.  The committer claiming the PR is asking for trouble.


----------



## marino (Nov 17, 2016)

You know the question starting with "If a tree falls in the woods ..." ?

These forums are not communications with freebsd committers, they are with freebsd users.
Something can be discussed extensively and nobody that can affect the outcome is aware of it.

The outcome of that thread was a PR.  That's the correct outcome.   Now the PR is waiting for somebody to look at it.  As I said, it appears that it wasn't tested as evidenced by multiple submissions and lack of build logs.  So it may be waiting a long time.  There are ways to entice a committer to look but I don't want to reveal them in case they get abused.


----------



## ASX (Nov 17, 2016)

marino@ said:


> yes, you can.  https://www.freebsd.org/doc/en/books/porters-handbook/own-port.html



From the *Submitting the new port* section:


> After submitting the port, please be patient. The time needed to include a new port in FreeBSD can vary from a few days * to a few months.*


This is what I would define a "failure by design".



marino@ said:


> new ports PR are generally difficult, but especially difficult when *the submitter fails to show the output of portlint and fails to include poudriere (or synth) logs* proving that it builds cleanly.


I read the handbook, and am unable to see a requirement to include such output/logs.



> If there are 300 ports PRs that need claiming, and there's no queue, then *it's in the submitter's favor to make their submission appealing.* No poudriere or synth logs is not appealing.


This is a *key statement*: I'm sorry, I think exactly the inverse is true: a new port favor the FreeBSD, not the FreeBSD committers do favor a new submitter.
In fact the submitter will be the one having the new port already installed and running on his system without the need to push it into the port tree.



> The committer claiming the PR is asking for trouble.


One committer, or better a "port manager" could simply reject the PR, at least the author will know something is not right, leaving it open/unanswered doesn't help anybody and will only contribute to clutter the PR system.

I will add that the portlint output or build logs aren't enough to assure that a package is OK, a recent example (two days ago or so) come to my mind, about libreoffice building properly but then not running because of an undefined function, therefore being so blindly strict about new port requirements isn't assurance of quality for itself, it would be just an additional bureaucratic barrier.


----------



## marino (Nov 17, 2016)

ASX said:


> This is what I would define a "failure by design".



Don't shoot the messenger.
Would you prefer this honest information be withheld?



> I read the handbook, and am unable to see a requirement to include such output/logs.



Actually I think there is a reference in there somewhere, but even if there is not: This is good advice.  Officially documented or not, that's what is going on.
Think about it.
The committer will have to use poudriere or synth on the submission anyway.
If there is a problem that these builders would have easily caught, the committer is A) going to be annoyed and B) just kick it back to the end of the line, thus wasting all those months.

Also, check out other PRs.  poudriere logs are requested and experienced submitters attach them automatically.
Believe me, if you are a committer that has time to take exactly 1 PR, which do you think they would take?  The apparently tested one or the one with no apparent testing?



> This is a *key statement*: I'm sorry, I think exactly the inverse is true: a new port favor the FreeBSD, not the FreeBSD committers do favor a new submitter.



Then that's your issue.
It is what it is.  You can wish it were different but that doesn't change what it is.



> One committer, or better a "port manager" could simply reject the PR, at least the author will know something is not right, leaving it open/unanswered doesn't help anybody and will only contribute to clutter the PR system.



You are feel to obtain commit status and make this your mission.  It's a volunteer effort and PR handling breaks everyone.  It's extremely thankless.




> I will add that the portlint output or build logs aren't enough to assure that a package is OK, a recent example (two days ago or so) come to my mind, about libreoffice building properly but then not running because of an undefined function, therefore being so blindly strict about new port requirements isn't assurance of quality for itself, it would be just an additional bureaucratic barrier.



percentage of ports that are "OK" if poudriere and portlint logs indicate they are bad: 0%
percentage of ports that are "OK" if poudriere and portlint logs indicate they are good:  No idea, but it's high. (The committer evaluates from a good starting point)

In practice, nobody submits a PR if their poudriere log shows it's bad.  They fix the problem, re-run the poiudriere test until it's good, *THEN* they submit it.  It's in their interest to do so.  Usually the submitters are glad embarrassing mistakes are caught privately.


----------



## ASX (Nov 17, 2016)

marino@ said:


> Don't shoot the messenger.


Of course, I don't, it just happened I felt the need to express my view.



marino@ said:


> Actually I think there is a reference in there somewhere, but even if there is not: This is good advice. Officially *documented or not*, that's what is going on.


To me it would make a difference ... else, it would make no difference if the PR received an answer.



marino@ said:


> You are feel to obtain commit status and make this your mission. It's a volunteer effort and PR handling breaks everyone. It's extremely thankless.


I know what it is, done something similar elsewhere for some time, I know how little rewarding it is, that said I'm not up to the task, not yet at least.



marino@ said:


> Then that's your issue.
> It is what it is. You can wish it were different but that doesn't change what it is.


Thanks for the honest answer, appreciated, however I disagree being "my" issue.


----------



## marino (Nov 17, 2016)

ASX said:


> Thanks for the honest answer, appreciated, however I disagree being "my" issue.



The issue stems from your belief, " I'm sorry, I think exactly the inverse is true."

You're responsible for your belief; nobody else can affect it.  How can it be somebody else's issue?
Nobody is going to be motivated to finish a half-baked port because "everyone in FreeBSD-land benefits".  It's a nice sentiment but doesn't reflect the real world.  Your issue is reconciling the real world with the ideal world.


----------



## ASX (Nov 17, 2016)

marino@ said:


> Your issue is reconciling the real world with the ideal world.


 Accepted!


----------



## kpa (Nov 17, 2016)

There's one fundamental problem with FreeBSD ports that I see all the time. It's the belief among the users that ports that have made it in the tree are somehow actively looked after by the FreeBSD project. This is not true with almost any port, the port QA by the project (mainly the portmgr@ team) is limited to testing whether the ports build in an automated test environment every now and then. It's very disheartening to see that many ports make it into the tree because of the initial effort by a user or users and once the port is working it gets abandoned by the maintainer because of this "defererence to the authority syndrome", "they know better, they should look after the ports we helped create, they owe us that" mentality.


----------



## marino (Nov 17, 2016)

ASX said:


> To me [documenting poudriere log submissions] would make a difference ... else, it would make no difference if the PR received an answer.



IIRC, I and others suggested that a strong suggestion to include poudriere logs be added, but that was contradicted by people that believe it would put up a barrier to submission.

I think such a barrier can only be a good thing, but those that oppose apparently think the "even badly authored ports are a gift to freebsd".

Personally I think it's a disservice because then the PRs just get ignored.  Better to be honest from the beginning.


----------



## ASX (Nov 17, 2016)

kpa said:


> It's very disheartening to see that many ports make it into the tree because of the initial effort by a user


Right! At the same time is also disheartening looking "your" PR lying there for months without any reply.

And, just to clarify my position:


marino@ said:


> IIRC, I and others suggested that a strong suggestion to include poudriere logs be added, but that was contradicted by people that believe it would put up a barrier to submission.
> 
> I think such a barrier can only be a good thing, but those that oppose apparently think the "even badly authored ports are a gift to freebsd".
> 
> Personally I think it's a disservice because then the PRs just get ignored. Better to be honest from the beginning.


Guess we can agree: I'm fine with logs requirements, but please state it in handbook/docs/reply/somewhere. I'm not against QA, I'm against things (unanswered PR) lying around for months.


----------



## nedry (Nov 17, 2016)

I just tried to compile the .gz from the website and i got the following: 
	
	



```
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether to enable debugging... no
checking whether gcc understands -Wall... yes
checking whether gcc understands -Wstrict-prototypes... yes
checking whether gcc understands -Wnested-externs... yes
checking whether gcc understands -Werror=missing-prototypes... yes
checking whether gcc understands -Werror=implicit-function-declaration... yes
checking whether gcc understands -Werror=pointer-arith... yes
checking whether gcc understands -Werror=init-self... yes
checking whether gcc understands -Werror=format-security... no
checking whether gcc understands -Werror=format=2... yes
checking whether gcc understands -Werror=missing-include-dirs... yes
checking what warning flags to pass to the C compiler...  -Wall -Wstrict-prototypes -Wnested-externs -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format=2 -Werror=missing-include-dirs
checking what language compliance flags to pass to the C compiler... 
checking for BASE... yes
checking for GTK... yes
checking for GSTREAMER... yes
checking for GNOME... no

configure: error: Package requirements (gconf-2.0
   gio-2.0
   gnome-icon-theme
   libnotify >= 0.4.1
   libxml-2.0
   unique-1.0) were not met:
```

nedry


----------



## marino (Nov 17, 2016)

ASX said:


> Guess we can agree: I'm fine with logs requirements, but please state it in handbook/docs/reply/somewhere. I'm not against QA, I'm against things (unanswered PR) lying around for months.



Technically it's not a requirement and it's certainly possible to get new port PRs dispositioned successfully without them, but one increases their chances if they do it.


----------



## Deleted member 48958 (Nov 17, 2016)

tobik said:


> ILUXA created one a while back, but nobody has committed it: PR 208160


I almost forgot about this one 
It worked fine for me — I was able to build and install it successfully…
Also there was no errors with portlint by that time (2016-03-20 ).
Anyway thanks for the fix!




nedry said:


> I just tried to compile the .gz from the website and i got the following:
> 
> 
> 
> ...



you need to install 

```
gconf-2.0
   gio-2.0
   gnome-icon-theme
   libnotify >= 0.4.1
   libxml-2.0
   unique-1.0
```

Here is all alarm-clock-applet dependencies :

```
LIB_DEPENDS=		libgtk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20 \
			libpangoft2-1.0.so:${PORTSDIR}/x11-toolkits/pango \
			libnotify.so:${PORTSDIR}/devel/libnotify \
			libgobject-2.0.so:${PORTSDIR}/devel/glib20 \
			libglib-2.0.so:${PORTSDIR}/devel/glib20 \
			libpango-1.0.so:${PORTSDIR}/x11-toolkits/pango \
			libfreetype.so:${PORTSDIR}/print/freetype2 \
			libgconf-2.so:${PORTSDIR}/devel/gconf2 \
			libcairo.so:${PORTSDIR}/graphics/cairo \
			libxml2.so:${PORTSDIR}/textproc/libxml2 \
			libunique-1.0.so:${PORTSDIR}/x11-toolkits/unique \
			libgdk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20 \
			libintl.so:${PORTSDIR}/devel/gettext-runtime \
			libatk-1.0.so:${PORTSDIR}/accessibility/atk \
			libgstreamer-1.0.so:${PORTSDIR}/multimedia/gstreamer1 \
			libgmodule-2.0.so:${PORTSDIR}/devel/glib20 \
			libfontconfig.so:${PORTSDIR}/x11-fonts/fontconfig \
			libgdk_pixbuf-2.0.so:${PORTSDIR}/graphics/gdk-pixbuf2 \
			libgio-2.0.so:${PORTSDIR}/devel/glib20 \
			libpangocairo-1.0.so:${PORTSDIR}/x11-toolkits/pango
```


----------



## marino (Nov 17, 2016)

ILUXA said:


> I almost forgot about this one
> It worked fine for me — I was able to build and install it successfully…



So then you should do this:

put a copy at /usr/ports/deskutils/alarm-clock-applet
install ports-mgmt/synth
execute `synth test deskutils/alarm-clock-applet`
if it builds successfully, attach the build log to the PR (this will ping it)
if it falls to build, fix the problems and attach the final build log to the PR (along with the updated submission)


----------



## nedry (Nov 17, 2016)

I could only find  unique-1.0  in the ports tree.


----------



## Deleted member 48958 (Nov 17, 2016)

Here is all dependencies

```
LIB_DEPENDS=		libgtk-x11-2.0.so:${PORTSDIR}/[b]x11-toolkits/gtk20[/b] \
			libpangoft2-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b] \
			libnotify.so:${PORTSDIR}/[b]devel/libnotify[/b] \
			libgobject-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libglib-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libpango-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b] \
			libfreetype.so:${PORTSDIR}/[b]print/freetype2[/b] \
			libgconf-2.so:${PORTSDIR}/[b]devel/gconf2[/b] \
			libcairo.so:${PORTSDIR}/[b]graphics/cairo[/b] \
			libxml2.so:${PORTSDIR}/[b]textproc/libxml2[/b] \
			libunique-1.0.so:${PORTSDIR}/[b]x11-toolkits/unique[/b] \
			libgdk-x11-2.0.so:${PORTSDIR}/[b]x11-toolkits/gtk20[/b] \
			libintl.so:${PORTSDIR}/[b]devel/gettext-runtime[/b] \
			libatk-1.0.so:${PORTSDIR}/[b]accessibility/atk[/b] \
			libgstreamer-1.0.so:${PORTSDIR}/[b]multimedia/gstreamer1[/b] \
			libgmodule-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libfontconfig.so:${PORTSDIR}/[b]x11-fonts/fontconfig[/b] \
			libgdk_pixbuf-2.0.so:${PORTSDIR}/[b]graphics/gdk-pixbuf2[/b] \
			libgio-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libpangocairo-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b]
```
So you need to install 
`# pkg ins x11-toolkits/gtk20 x11-toolkits/pango devel/libnotify ...`


----------



## Deleted member 48958 (Nov 17, 2016)

marino@ said:


> So then you should do this:
> 
> put a copy at /usr/ports/deskutils/alarm-clock-applet
> install ports-mgmt/synth
> ...


I can build and install it with portmaster






but synth says


----------



## marino (Nov 17, 2016)

the portmaster output is useless based on how it works.   You might as well build it from the command line with `make install`.  There's a reason nobody asks for portmaster logs.

Edit /usr/ports/deskutils/Makefile and add alarm-clock-applet to it.
Sorry about this extra step, but it comes from FreeBSD ports considering only ports in category Makefiles as valid.


----------



## tobik@ (Nov 17, 2016)

ILUXA said:


> but synth says


You need to add an entry for alarm-clock-applet in /usr/ports/deskutils/Makefile so that Synth can find it.  Please see PR 208160 again before you do. I've uploaded a fixed version of the port 3 hours ago that builds in Poudriere.


----------



## marino (Nov 17, 2016)

He should synth test his version first to illustrate a point.


----------



## nedry (Nov 17, 2016)

I checked and x11-toolkits/gtk20  x11-toolkits/pango  devel/libnotify ports are already installed !!!!


----------



## Deleted member 48958 (Nov 17, 2016)

You need to install *ALL* these ports/pkgs!

```
LIB_DEPENDS=		libgtk-x11-2.0.so:${PORTSDIR}/[b]x11-toolkits/gtk20[/b] \
			libpangoft2-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b] \
			libnotify.so:${PORTSDIR}/[b]devel/libnotify[/b] \
			libgobject-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libglib-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libpango-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b] \
			libfreetype.so:${PORTSDIR}/[b]print/freetype2[/b] \
			libgconf-2.so:${PORTSDIR}/[b]devel/gconf2[/b] \
			libcairo.so:${PORTSDIR}/[b]graphics/cairo[/b] \
			libxml2.so:${PORTSDIR}/[b]textproc/libxml2[/b] \
			libunique-1.0.so:${PORTSDIR}/[b]x11-toolkits/unique[/b] \
			libgdk-x11-2.0.so:${PORTSDIR}/[b]x11-toolkits/gtk20[/b] \
			libintl.so:${PORTSDIR}/[b]devel/gettext-runtime[/b] \
			libatk-1.0.so:${PORTSDIR}/[b]accessibility/atk[/b] \
			libgstreamer-1.0.so:${PORTSDIR}/[b]multimedia/gstreamer1[/b] \
			libgmodule-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libfontconfig.so:${PORTSDIR}/[b]x11-fonts/fontconfig[/b] \
			libgdk_pixbuf-2.0.so:${PORTSDIR}/[b]graphics/gdk-pixbuf2[/b] \
			libgio-2.0.so:${PORTSDIR}/[b]devel/glib20[/b] \
			libpangocairo-1.0.so:${PORTSDIR}/[b]x11-toolkits/pango[/b]
```

`# pkg ins <INSERT HERE ALL [b]BOLD[/b] TEXT FROM ABOVE>`

For example
`% sudo pkg ins x11-toolkits/pango  devel/glib20 graphics/gdk-pixbuf2 x11-fonts/fontconfig … … etc, etc, etc`


----------



## Deleted member 48958 (Nov 17, 2016)

marino@ said:


> He should synth test his version first to illustrate a point.


I'm using tobik's updated version with "the appropriate USE_* flags" now.

So it seems that synth is woking fine now, `synth test deskutils/alarm-clock-applet` is running now —




It seems that I need to wait while some ports will be built?
When it will be finished I'll post output here.


----------



## marino (Nov 17, 2016)

we'll, you should expect it to pass because tobik already validated it with poudriere.

It would have been more valuable to check *your* version to illustrate the problems even after you were convinced the port was good.  I mean as a learning experienced.  Build-testing a port that already passes won't prove much unless there's a rare issue that synth can detect and poudriere can't (there aren't many of those).


----------



## marino (Nov 17, 2016)

ILUXA@ by the way, your Synth seems pretty old (The labels "skipped" and "swap" aren't capitalized which indicates an older version).  Are you using a quarterly branch?


----------



## Deleted member 48958 (Nov 17, 2016)

It was installed from pkg's ~30 minutes ago . I'm using ports only when I need to change some build options (Or, sometimes, when I need to install a newer version, what will be done when synth will finish).


----------



## marino (Nov 17, 2016)

well, then your packages are set for the quarterly branch.  Verify with `pkg -vv`.  If that is what you want, fine.


(just because it was installed 30 minutes ago doesn't mean it's not 2 months old)


----------



## Deleted member 48958 (Nov 17, 2016)

I've never realized that I'm using it.
It seems that "quarterly branch" is set by default in FreeBSD 11 by now. 
(I'm googling some info now and it seems that "quarterly branch" is set by default starting with 10.2)
How can I easily switch to 'latest'? I did not find such option in /usr/local/etc/pkg.conf.

UPD:
I found how to change it:

1. `mkdir -p /usr/local/etc/pkg/repos`
2. `cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf`

and in the /usr/local/etc/pkg/repos/FreeBSD.conf :


```
- url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly"
+ url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
```
That's for those, who are like I am  I always thought that it's OK that pkg's from repository are outdated a little.
Huge thanks, marino@ ! If you did not mention about "quarterly branch" I would never realize that I'm using it, I've read A LOT OF forums and mailing lists, but I've never heard about it.


----------



## Deleted member 48958 (Nov 19, 2016)

marino@ said:


> execute `synth test deskutils/alarm-clock-applet`
> if it builds successfully, attach the build log to the PR (this will ping it)


Here is output… (`s` is sudo and `c` is cat)




I don't get it. What I need to do next?


----------



## marino (Nov 19, 2016)

look at the build log.
editors/joe => editors___joe.log
deskutils/alarm-clock-applet => deskutils___alarm-clock-applet.log

the man page describes this too.


----------



## marino (Nov 19, 2016)

in this case, you need to look at log starting with 00_ 
if you list the directory alphabetically, it's at the top.


----------



## marino (Nov 19, 2016)

finally, you can always use a brower to show "/var/log/synth/Report/index.html" which shows a lot. (newest synth versions only)


----------



## Deleted member 48958 (Nov 19, 2016)

marino@ said:


> finally, you can always use a brower to show "/var/log/synth/Report/index.html" which shows a lot. (newest synth versions only)








Here is textproc_py-sphinx.log
http://pastebin.com/mcHSPFdU


----------



## marino (Nov 19, 2016)

You should report the flaw.
Synth detected a missing entry in the plist because you built with "synth test" which invokes QA tests.
After you file a PR (and you should), use `synth just-build textproc/py-sphinx` which skips the tests, then try testing the alarm clock again.


----------



## Deleted member 48958 (Feb 17, 2017)

getopt said:


> Congratulations ILUXA!
> 
> Maybe you want to share some of your experience with us, how you finally made it, and what the reason was that it took so a long time?


Thanks!

I don't know why it took so long, because no answer was given until now.

Also many thanks to tobik@ for the help!


For newcomers: 

Now alarm-clock-applet is available in ports tree !
deskutils/alarm-clock-applet


> Alarm Clock is a fully-featured alarm clock for your GNOME panel or
> equivalent.  It's easy to use yet powerful with support for multiple
> repeatable alarms, as well as snoozing and a flexible notification
> system.  Alarm Clock will notify you of an alarm by either playing a
> sound or starting your favorite music player!


----------

