New Ko/pi Alarm Solution

[Zumi]

Just install this package and your Z will be resumed before and alarm event if it was suspended, so KO/Pi can use it's own built-in alarm.

Get it from the contrib feed along with a good version of kdepim:
kopi-apm_1.1 and kdepimpi_2.2.7 or add http://mail.pdaxrom.org/contrib/rc11+-armv5tel/ to the feed list in the Package manager!

• You need atd for this package, but it's a dependency, so it should be installed along with this. atd is in the stable feed of 1.1.0beta1 release of pdaXrom.
• You need a custom compiled kdepim to have alarm sounds (it doesn't play them in the feed version). Cattin compiled the one I'm using and it's also a dependency.
• KO/Pi needs to be running if you want alarms

Mainly it's based on Cattin ideas, so thanks for them, minus the atd daemon, thanks Sashz for that.

Important note: atd is automatically started after a reboot, but to start it without reboot, please execute the following command:

Code: [Select]

etc/rc.d/init.d/atd startThanks gromituk, for pointing this out!

Happy alarming,
Zumi

EDIT: the download path for the files has been changed, and there's a new, 1.1 version along with that. Sorry for the inconvenience about the mess with the filenames.

[gromituk]

On my 860, with a virgin installation of 1.1.0beta1, I installed atd on /mnt/card, then kdepimpi on /mnt/card, then kopi-apm on /mnt/card, at which point the package manager log reported 'Package "kopi" not found on external storages.'
Is kdepimpi the right package, or should kopi-apm look for kdepimpi as an alternative to kopi, or am I just confused?  Kopi plays a sound for the alarm, but of course doesn't wake up the Z for this.

PS 'at' usually comes with 'atq' to show what is awaiting processing, and 'atrm' to remove stuff from the queue.  Not necessary for this application but could be quite useful in general.

[Zumi]

Install at least kopi-apm and atd in the root folder; They eat about... 10k space on it. Tell it if it was wrong that way too. And the package manager output is strange, because I haven't made this kopi-apm dependent on kdepim (or kopi) so it shouldn't say something like that.

Zumi

[pgas]

is it kopi_apm or kopi-apm?

underscores in package name confuse ipkg.

[Zumi]

is it kopi_apm or kopi-apm?

underscores in package name confuse ipkg.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110007\"][{POST_SNAPBACK}][/a][/div]

It's "kopi-apm_1.0_armv5tel.ipk" here for me, but it's getting downloaded as "kopi_apm_1.0_armv5tel.ipk", so f*ck. This forum attachment system is a pain in the... neck.

EDIT: Okay, for now: please rename the package to kopi-apm, this way:

Code: [Select]

mv kopi_apm_1.0_armv5tel.ipk kopi-apm_1.0_armv5tel.ipkwhen you downloaded it.

Zumi

[gromituk]

is it kopi_apm or kopi-apm?

underscores in package name confuse ipkg.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110007\"][{POST_SNAPBACK}][/a][/div]

It's "kopi-apm_1.0_armv5tel.ipk" here for me, but it's getting downloaded as "kopi_apm_1.0_armv5tel.ipk", so f*ck. This forum attachment system is a pain in the... neck.

Yes - I've removed kopi_apm and atd as you suggest, and when re-installing kopi_apm the log says "Installing kopi...", then Kopi can no longer play sounds because it can't find /mnt/card/opt/kdepim-2.2.7/kdepim/korganizer where the default wav file is.

EDIT: Okay, for now: please rename the package to kopi-apm, this way:

Code: [Select]

mv kopi_apm_1.0_armv5tel.ipk kopi-apm_1.0_armv5tel.ipkwhen you downloaded it.

Zumi
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110017\"][{POST_SNAPBACK}][/a][/div]

OK - done that, installed it and atd in /, reinstalled kde-pimpi in /mnt/card, and... kopi dies when an alarm occurs during suspend (without waking up the Z).  Now running it from the command line to see what's going on.

PS Has anyone else noticed Kopi's propensity to put extra carats in the event dialogue?  I've just had three flashing merrily away at different phases in different fields!

[Zumi]

[...]
PS Has anyone else noticed Kopi's propensity to put extra carats in the event dialogue?  I've just had three flashing merrily away at different phases in different fields!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110024\"][{POST_SNAPBACK}][/a][/div]

OK, now try to remove kopi-apm, atd and kdepim completely and install them from the places I altered in the first post! Thanks for the testing! It was good that this underscore error was found out...

Zumi

[scheck.r]

Good news !

It works perfectly on my C1000.
I just needed to reboot for it to work otherwise it couldn't wake up the Z.

Congrats Zumi

EDIT: I used kopi_apm_1.0, now I see that there's a new version 1.1

[gromituk]

Now running it from the command line to see what's going on.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110024\"][{POST_SNAPBACK}][/a][/div]

Exits with "Illegal instruction"   , and it leaves the mail light flashing.

Reinstalled kdepimpi on / - still didn't wake up - but then I realised I hadn't started the atd.    Now all is sweetness and light!!!        

[Zumi]

It's good to see that it's really working.
1.0->1.1 only difference is that I made it dependent on kdepim too. Now it pulls that from the feed if you just install kopi-apm. Just a bit of userfriendliness, and to avoid confusion, I made a new version from it.

Zumi

[gromituk]

Really brilliant work, all of you.  Haven't used alarms on kopi before and they're quite sophisticated, warning you if you've missed any, etc.  I can confirm that it works with the lid closed, too - being able to press the button on the back to silence the alarm is good for panic situations!

Could the atd package be updated to call '/etc/rc.d/init.d/atd start' once it's installed?  Otherwise it's a bit confusing that it won't work initially.  We don't want a Windows-style "please reboot now" situation!    In the mean time, maybe you could edit your original post to include this instruction?

[desertrat]

Thanks for the excellent work Zumi and Cattin.

However I think it ought to be pointed out that this solution pim only works for the root user. As Cattin notes:

My solution doesn't scan ko/pi's data file for the next alarm, but uses the two files (/home/root/.kopi_next_alarm & .kopi_suspend_alarm)

That is the alarm info is hardcoded to be written in root's home directory, thus if you're running as a non-root user (as I was originally doing) you're not going to get any alarms

Maybe a more general solution can be found? Like writing alarm info into /var/spool or something so that users other than root can be catered for?

-- cheers

[Zumi]

The whole pdaXrom is root centered at the moment, nothing is refined from this point of view (mainly file/directory ownerships), so I don't bother making a user-friendly solution for this reason.
It's not strictly root dependent, for example this can be easily solved by chowning the /var/spool/atd directory to root:somegroup, chmod it to 775 and adding the user to somegroup. It should work after that, 'cause the script is looking for ~/.kopi* files, which is not root dependent.

Zumi

[desertrat]

The whole pdaXrom is root centered at the moment, nothing is refined from this point of view (mainly file/directory ownerships), so I don't bother making a user-friendly solution for this reason.

Understood, but going forward that is something that ought to be addressed. After all we are running a full linux system and are subject to the same vulnerabilities. The reason I started to use a non-root user was when I tried out xscreensaver and it complained that it's going to refuse to run as root.

It's not strictly root dependent, for example this can be easily solved by chowning the /var/spool/atd directory to root:somegroup, chmod it to 775 and adding the user to somegroup. It should work after that, 'cause the script is looking for ~/.kopi* files, which is not root dependent.

Unfortunately kdepim seems to be. When I tried it using a non-root user no .kopi* files were created.

BTW I am curious as to why your script "manually" creates the files that at itself should create. That is, why don't you call at directly?


-- cheers

[iamphet]

It should work after that, 'cause the script is looking for ~/.kopi* files, which is not root dependent.

Aren't suspend/wakeup scripts always executed under root?