Resuming sessions without the proper Activity makes life interesting
There is an exodus of interns. Brian Jordan left for Rwanda this morning; Dan Drake is already in Ethiopia. Both are helping out at pilots. We are demanding stories and pictures upon their return.
While doing my bug report could be better). The test was to check whether Activity sessions started before an upgrade could be resumed after that upgrade (so far it looks like the answer is yes for core Activities, which is great). The bug isn't in that; it's in what happens when you don't have the proper Activity to resume a session with.
One upgrade from 656 (what shipped with G1G1 machines) to 760 (current release candidate) ended up with no core Activities in Sugar. Of course, without Activities to run them in, the sessions couldn't resume. They showed up as generic file icons in the Journal instead and you couldn't do anything with them.
When the Activities were reinstalled, the old sessions still showed up as generic file icons in the Journal (instead of having the proper Activity icon next to them), but they could now be resumed. The curious bit is that when you resumed one of those sessions, you ended up with two separate Journal entries - one with a recent timestamp and the correct Activity icon by it, the other with the file icon and an old, unchanged timestamp. It was as if you'd created a new session that happened to have old data, and the old session hadn't been touched at all.
Weird. Now to chase this down and reproduce it...
While automating what used to be a manual test (running a logging script beats the heck out of getting up every few minutes to see if a battery has died), I also learned something about OHM today, thanks to Richard. (Warning: Acronym alert. I've tried to link to relevant wiki pages when possible.) When there's output to the VT, OHM won't suspend the XO (and the battery will run down way, way faster).
In today's case, it meant that if I ran olpc-pwr-log (the battery monitoring script, and a useful tool to know about) in the VT, the XO wouldn't suspend; if I ran olpc-pwr-log in the Terminal activity, the XO (and the script) would suspend (but thanks to wireless, it would wake up frequently enough to give us some battery drainage data, which was enough). Since we were trying to drain the batteries as fast as possible (Richard needed drained batteries to test the multi-battery charger), we ran the script in the VT.
Phew. A lot of testing stuff going down tomorrow, so tomorrow's post will be far more interesting, I promise.