Interesting situation:

Since i installed the hildon-desktop update from cssu-devel, as for other guys h-d isn't starting at boot, respectively crashing. Now, with RD mode enabled it stays on, but of course no widgets / shortcuts etc.

Today, it was the 3rd consecutive day since the update that i have no desktop, as well as being greeted with silent alarms in the morning. Every newly created alarm that i test (without reboot in those days) is reliably "silent only".

Maybe there's a link between hildon-desktop and alarm issues too?

EDIT: At least for me, confirmed. Rebooted, freshly created an one-shot alarm - it was silent too (phone was on silent profile. So no vibration either. Created another one-off one (this time being in profile "General"), this one was silent too. Created a third one (now being repeated for 3 days a week, also using Alarm Tone 3 instead of the usual number 1) - same behavior.

So my conclusion; when h-d hangs (like for the widgets / shortcuts not responding issue), this affects alarms too.

Then we are back at hildon-desktop hanging.
What widgets do you have?

Since I removed all external-loaders (and widgets using these loaders, incl statusmenu), for h-d and switched to qbw instead of dcew I haven't experienced a locku-up.

At the moment should be none at all, because h-d isn't loaded. No h-d, no widgets loaded, right? Even before when h-d could be loaded, the alarm issue was sporadically. Now without h-d, it is an permanent issue.

Before, i switched DCEW to QBW versions, didn't help either.

I'm actually short before tossing the N900 in the car as a bluetooth media player or similar, and switching to an Android phone. The shortcomings / unreliabilities are becoming more & more obvious each week.

Now I am interested, have you any loader?

ls /usr/lib/hildon-dekstop/loader

Newsflash:

After downgrading libxml2 and therefore getting my desktop back, i left the widgets unloaded after the reboot and tried another alarm. Nothing, silent popup as ever.

Next, i restored my widgets and did another one-off - nope, nada.

Okee...

Now, i used alarmed to create a one-off, and guess what - that one gave me sound!
Curious, i created another one in Clock / alarmui - and got sound too!
Just to confirm, the next one in alarm-ui was a repeating on. And for the 3rd time in sequence, an alarm sounded.

So, can anyone explain this behavior?

EDIT: also heard an alarm tone this morning, good. Let's see how long (for how many days) this is bound to happen...

(short answer: no)

I guess the cause of your problems is that you're on cssu-devel, which is explicitly described as dangerous. I'm not on CSSU precisely (or partly) because of that. I have the feeling that some programs are updated for update's sake without any stated or expected benefit.

WTF is this libxml2 update?

Stock PR1.3 has version 2.6.32.dfsg-5maemo4+0m5 but somehow extras, testing and devel have libxml2 2.6.27.dfsg-1.maemo1, which (to me) is pretty worrying, and says a lot about this whole autobuilder crap as well as of the testing procedure (who te f**k "voted" for this package to be promoted from testing to extras? and why?).

I guess CSSU has yet-another version, probably with "XML portrait support" (sorry, couldn't resist).

This library (sorry, "package") is used by just about everything in Maemo, so I would think 1e8 times before "updating" it.

I guess your N900 has got into such a messy state that if you were a normal user I would just recommend that you flash your N900 again.

But before you do that, can you post the output of "apt-cache policy libxml2". Thank you.

(I'm fully aware what cssu-devel means, and yes, once in a while i upgrade some of my packages from there. That was not my point, however, i expected some things to break one day. And i won't say it's in a messy state; neither have i changed any system scripts, nor messed with "manually" optifying, nor something else, thank you.)

What is instead my concern, could someone explain this (now even more convoluted) alarm behavior that Maemo is presenting us with? For a while now, several users were reporting silent alarms, and AFAIK we still haven't found the real reason behind. (@freeman?) That's why i documented my findings here; so that maybe the puzzle got some more pieces to link. My silent alarm issue too started way before i touched cssu-devel, just for the record; the symptoms just got more presence during this week.

So, what are the system's dependencies for
- creating / storing
- scheduling
- triggering
alarms, _with_ audio output? What libs / packages are related? How the "pipeline" (in absence of better describing terms) looks like? What are points of failure?

All my findings from this week don't convince me that other than by chance for a long time, how those bits are integrated in the system can considered being stable.

@reinob:

this https://bugs.maemo.org/show_bug.cgi?id=12646
which uses zlib and we'd rather use upstream for both libpng and zlib,
along with this http://git.gnome.org/browse/libxml2/...b3da00249181ff

Please, consider checking the facts next time before announcing "portrait support in libxml2"

I had a look at the alarmui code again (the one in git). Besides being a bit messy for my taste it looks OK.

The clock-alarm sound file is read from (gconf) /apps/clock/alarm-tone. If nothing is there it will use /usr/share/sounds/ui-clock_alarm_default.aac

[ Just to make sure, the next time you get a silent alarm could you check the output of "gconftool -R /apps/clock". alarm-tone should be pointing to a valid file. And just in case check that the default.aac file exists ]

After that it gives control to libnotify (notify_notification_show), which in turns calls the notification server (via DBUS). Now guess who provides the DBUS notification server? yes, hildon-home

For now I stop but [ also to apologize to @freemangordon for my offensive comments regarding CSSU ] I'll try to have a look at h-h's source code (http://maemo.gitorious.org/fremantle...ees/master/src) and see if I spot anything suspect.

Having a quick look at hildon-home I noticed that the /etc/hildon-desktop/home.conf also allows some parameters for tuning when the desktop widgets will be shown or not.

Perhaps it'd be worth a try to add these to home.conf
I assume that way the widgets will always be shown regardless of CPU load or any other heuristics.

@don_falcone and/or @perterleinchen might be good candidates for testing this out.