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.

Code:

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:

Code:

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:

Code:

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:

you need to install

Code:

   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 :

Code:

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

Code:

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

alarm clock

nedry

scottro

SirDice

Administrator

Anglican

nedry

marino

tobik@

SirDice

Administrator

marino

marino

marino

ASX

Guest

marino

ASX

Guest

marino

ASX

Guest

kpa

marino

ASX

Guest

nedry

marino

Deleted member 48958

Guest

marino

nedry

Deleted member 48958

Guest