Notices

No, the --sync-calendar won't perform any synchronization yet (its name is awfully misleading...fortunately it's going away with the GUI version). It only creates the bindings for the calendars and creates the needed calendars.

You have to run erminig-ng without any parameter to perform actual sync.

OK, found a possible workaround that XML problem (by the way, thank you Palleman for putting me on the right track!).

Instead of importing xml.utils.iso8601, we can import _xmlplus.utils.iso8601 (and modify all references to the new import)

a not-so-satisfying explanation can be found on this web page:

http://www.amk.ca/diary/2003/03/pyth...plus_hack.html

I have to make a few tests to see if it works as expected, but I'm fairly confident that this is the correct solution. I will update the FAQ immediately and prepare a new package (tomorrow, because it's a bit late around here )

That didn't work for me. It still complained avout the missing module.

I looked into our find results, and we both have _xmlplus in /usr/share/pyshared but you also have /usr/lib/python2.5/site-packages/_xmlplus/ which I don't.

I added a symlink, and that made everything work. I changed the import line and all references in the file, deleted the .db file, reran the --sync-calendars and ran a bare erminig-ng. It is now adding events from Google to the new local calendar.

It is slow and it's eating resources, but I guess that's what you get for running stuff that's not even in a .deb yet, and in addition doing it with a massive data source and output straight to the screen...

I've now tested adding and deleting events both ways, and it seems to work fine. No recurring events though (which is not only bad, since I won't have a couple of hundred birthdays duplicated).

Is there a way to fiddle with the .db to change the binding from the new calendar to the default N900 calendar? Or, is there a way to change which local calendar is the default when adding new events?

waiting for this bad boy. When can we expect a release with a GUI?

That's not an easy question, but let's say that if there are no big issues with the core syncing functionalities a GUI may appear within two weeks (but don't quote me on this, I did not say it )

The main issue at the moment is that xml.utils.iso8601 stuff that is really worrying me since I can't find a proper pattern for the failure. I will probably install all the packages other people installed to see which one is causing grief....

Can you provide the details for this symlink? I want to try this too, to see if it works on my system.

To those who are going to try the symlink to xml.utils.iso8601: please remove the symlink once a proper solution has been found! Creating such a symlink may have unintended side effects on other programs!

The proper workaround is in the works (probably by using another module), I hope to get it done by this evening.

thanks

ln -s /usr/share/pyshared/_xmlplus /usr/lib/python2.5/site-packages/_xmlplus

As always, the one typing the above is the one living with the consequences (although I haven't noticed any side effects so far).

/P

Yes, recurring events are not managed yet. In fact I just discovered that the recurring events support in Fremantle Calendar is very poor (it won't accept "exceptions")....

Not that I know, but this would be very useful!

There's probably a way to coerce Erminig and the local calendar to do that, but I don't think that I'm going to investigate this further, since it doesn't appear to be a common use-case, Next version will allow the user to sync to an already existing calendar, without forcing the creation of a new one.

How massive the data source (how many events)? And from where? (Google or local calendar?).

Concerning the slowness: normally it's only the first sync that may be slow, since it has to fetch quite a lot of information from Google, all subsequent syncs should be faster.

Concerning eating resources: do you mean memory resources or CPU resources?
Memory usage at first sync increases in O(n), with n being the number of events, and more generally it's also O(n) in the subsequent syncs, but here n is the number of modified/new/deleted events (and not the total number of events)

And yes, output of the debug data to the screen will not help. All that output will be removed in the next version, and only a few lines will be logged in an ad-hoc log window.