Comment 2 for bug 988312

Ah, didn't realize that 0.5 didn't already include all these changes. Yes they're all quite necessary. In fact the fix_time() function is so critical that the current 0.5 release included in precise probably doesn't work at all. It's a fix for an unannounced Launchpad API change that hit us a few months back. There is some cleanup included which is unnecessary of course but corrects some rather stupidly lazy packaging work on my part.

I've updated the changelog to itemize all the changes. Mostly everything is to fix problems people have run into, although there's also a new script and a couple new routines added; all quite safe but if they bug you I can revert them, they're not critical. To date most people have been running lpltk from bzr, so we don't have bug reports on the problems - we would just fix bzr and users would re-pull. We're planning to change to a more formal model with releases and tests and actual version numbers going forward. If we can get this SRU in we can baseline this from precise; if not, we'll just rein things back in and wait for quantal.

Due to the cleanup cruft you might find it easier to review the changes via the bzr log, which can be obtained via:
  https://code.launchpad.net/~arsenal-devel/lpltk/1.x
Revision 139 should match the 0.5 release included in precise currently.