It means that at least me is busy packing stuff and heading for Frankfurt in 3hrs... so, no real testing time for the next two weeks.

I had the new alarmui on my testing device and it worked well.
So I decided to install it on my main one 2 days ago.

That device has a bit of an issue when booting. It ill only boot properly when connected to the charger, and sometimes it takes 2 or 3 attempts.

If there's no charger connected it will end up in some kind of boot loop. I never tried to figure out what exactly happens there... Maybe it's time to do that now, because...:

I switch the device off at night and charge the battery. With the new alarmui it wakes up a minute or so before the scheduled alarm as it is supposed to. But then it enters into that ugly boot loop and the alarm never sounds.

I'm not calling it a bug with the new larmui, as clearly that device's boot behavior is somewhat wrong. However, this used to work with the stock alarmui, so something IS different.

R&D flag (not necessary full R&D mode), that forces every reboot to be of "power button" reason, would fix your problem, at least, when it comes to booting without charger, and vanilla alarm UI. It seems, that your device is entering act_dead charging in every boot, so it shuts itself down, when no charger is connected.

No idea, how it behaves with replacement alarm-ui.

@foobar - could you install syslog and PM me your system.log. After recreating the problem of course

In my case, it's hardware'ish. Screwed something during soldering down USB port. Side effect: devices boots itself up upon putting battery inside, instead of waiting for power button. When shut down without removing battery, it doesn't boot on its own, though.

Interesting, my device does that, too (boot upon inserting battery, then enters that boot loop), though that particular machine's USB port has never been fiddled with.

Maybe it's worth opening separate thread for this, as we've already gone off-topic? [1]

As for on-topic, what was changed in replacement alarm-ui (as compared to stock one), that could result in no alarms, when device boot reason is always pwr_button? Maybe replacement's author could fix it, to mimic stock behavior?

[1]
I, for one, would be very interested, to find reason for it. Checked device zillion times, hardware and software wise, yet still have no idea, what is causing this. One thing that I'm sure, though, is that it started to happen just after soldering down USB port.

OTOH, initially, only side-effect was device turning on, when battery inserted. Over time, it entered act_dead on power button boot, from time to time. It went worse over time, resulting in false charging act_dead on every boot, requiring countless battery removal and insertions + attempts to hit power button super-fast, to boot without charger.

Setting mentioned R&D flag "fixed" it, without any ill side effects. Only one thing to consider is, that now, when device is off and you plug charger in, N900 will turn itself ON, instead of entering charging act_dead. Also, you won't ever see "building up" light of diode, when you push power button - device turns on instantly. Benefits of being able to turn device ON without charger overweight those small changes in habits, still.

Vanilla alarms are working fine, though even when device is turned off.

I hope, that it's going to help with sandboxing, where replacement alarm-ui acts differently than stock one.

continued this way -----> Wierd n900 turning on when inserting battery issue.

@foobar - did you receive my PM?

In case you are not - sysemui segfaults, that is why your device enters reboot loop.

Now, make sure you have the latest (v 3.2) alarmui installed. If you have the issue with the latest alarmui, please install sp-rich-core from SDK repo, recreate the problem and send me the coredump.

Yes, I just didn't get around to answering yet.
I have sp-rich-core installed (because of http://talk.maemo.org/showthread.php...76#post1286276), but it took me a while to figure out that one has to create MyDocs/core-dumps manually (as opposed to what's written on the wiki - needs fixing once it's back up).

Anyway, in my tests with latest alarmui there were no cores dumped, possibly because systemui crashes before sp-rich-core is started? Need to investigate further.