I've been stuck on a Dec 2004 build of appsuite calendar for some time. I've recently tried to convert to Sunbird, but with no success. I built from cvs yesterday (20051020, checkout at 0400 GMT) and Sunbird works fine *except* that I'm unable to import my moz calendar file. when I try to import my mozilla calendar file: -rw------- 1 calum calum 400840 2005-10-20 20:04 CalendarDataFile.ics nothing happens at all. Nothing on cmdline, nothing in JS console, and nothing whatsoever in the Sunbird main window. I ensured that I had no pre-existing ~/.mozilla before starting, although I do have existing firefox and thunderbird profiles. I used File-Import. This brought up a dialog where I select the above file, clicked OK, the dialog goes, and then nothing. I also tried File-OpenCalendarFile, but this does nothing whatsoever: no dialog, no errors, nothing. I also tried: http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-trunk/sunbird-0.2+.en-US.linux-i686.tar.bz2 exactly the same behaviour as my build, which is good (rules out my clunky build system :) [I also tried the official 0.2 release: http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/0.2/sunbird-0.2-i686-linux-gtk2+xft.tar.gz but it crashes instantly on startup, on my system] I can create new events in my (empty) default Calendar (my build), and all does seem to work well, other than import. As a possibly unrelated aside, on startup (my build), I receive the following on the cmdline, which might possibly be a problem (along with lots of the usual stuff): error creating table cal_calendars -- probably already exists error creating table cal_calendars_prefs -- probably already exists and, immediately after startup I see the following two errors when I open the JS console: Error: subject.function::getBoolPref is not a function Source File: chrome://calendar/content/pref/rootCalendarPref.js Line: 99 Error: mozStorage exception: createStatement failed, statement: 'SELECT version FROM cal_calendar_schema_version LIMIT 1', error: 'no such table: cal_calendar_schema_version' Source File: file:///usr/local/src/mozilla/sunbird/sunbird-200510202004/components/calStorageCalendar.js Line: 128 but this is all before the import. I see nothing on the cmdline, nor in the JS console, when doing the import, or the File-OpenCalendarFile.

(In reply to comment #0) > when I try to import my mozilla calendar file: > > -rw------- 1 calum calum 400840 2005-10-20 20:04 CalendarDataFile.ics > > nothing happens at all. Nothing on cmdline, nothing in JS console, and nothing > whatsoever in the Sunbird main window. Please attach the .ics file to this bug. > I also tried File-OpenCalendarFile, but this does nothing whatsoever: no dialog, > no errors, nothing. bug 306692, not related > [I also tried the official 0.2 release: > > http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/0.2/sunbird-0.2-i686-linux-gtk2+xft.tar.gz > > but it crashes instantly on startup, on my system] Try ./sunbird -calendar for the 0.2 version > error creating table cal_calendars -- probably already exists > error creating table cal_calendars_prefs -- probably already exists Nope, not related. > and, immediately after startup I see the following two errors when I open the JS > console: > > Error: subject.function::getBoolPref is not a function > Source File: chrome://calendar/content/pref/rootCalendarPref.js > Line: 99 Being addressed in bug 313198, not related > Error: mozStorage exception: createStatement failed, statement: 'SELECT version > FROM cal_calendar_schema_version LIMIT 1', error: 'no such table: > cal_calendar_schema_version' > Source File: > file:///usr/local/src/mozilla/sunbird/sunbird-200510202004/components/calStorageCalendar.js > Line: 128 There's a bug somewhere for that, but I can't find it at the moment. It's not related either. So, the main two things are to try and get 0.2 up and running to test there and to attach the .ics file to this bug. (Feel free to 'sanitize' it prior to attaching. Minimizing it to the smallest file that fails would be ideal.

thanks very much for that, Joey. I was able to get 0.2 up with "-calendar", and it's huge progress: I was able to import my calendar no problem. It took a while, and the lack of progress reporting would have been a concern, but I see there's a bug on that already. So, all now working well with 0.2, thanks again. However, this bug remains: unable to import into trunk. I can't upload my calendar to this bug, since it's full of personal detail. It's also large - 1,100 entries - so filleting it down to a reproducible chunk is going to be very hard. Is there anything further I can do here? On a possibly unrelated note, I find that I still can't now switch to the trunk version. If I quit 0.2, and then run yesterday's build, I get a message about old extension not being compatible noting 0.2. Click "don't check for new versions" causes a crash. Clicking "check" comes back to say there are no new versions. Either way, restarting the trunk build then comes up fine, but with an empty calendar, no entries. I can log a separate bug for that, if that would help? thanks again.

I chopped my original calendar file down to just 1 new entry, and then, of course, sunbird trunk imported it fine. But it refuses to import the large file (with 1,100 entries). Since I've no idea what it doesn't like about the file, it's not really possible for me to fillet it down to a small reproducible case :(

I built a new sunbird, from a checkout of 20051021 @ 2048 GMT. This to include a recent fix for "multiple vcalendar components not importing" I heard about. I then tried to import two different calendar files, separately, with a fresh ~/.mozilla profile for each one. 1. My original calendar file that I've used with my mozilla appsuite build from 20041202. 2. The calendar file created by Sunbird 0.2, when I imported file 1), above, into it. The difference between files 1) and 2) above is hard to see - Sunbird seems to have moved things around a bit, but both files have 1214 entries. I tried this file to see if it would be in a more palatable for trunk. Results: 1) as before; nothing at all happens on import, and no entries appear. 2) oddly, with file 2), 19 entries do get imported (out of 1214 entries).

Really, there is nothing we can do without the .ics file. You can try to remove a lot of the items, and obscure the rest if you like. But without anything, this bug is invalid.

Yup, I can see that. However, the entries are personal, so I can't upload them. That there's likely a bug here remains. I *will* try and create an uploadable ics file that shows the problem, but it's proving difficult. My cut-down, sanitised, files import into trunk without problems. I will keep trying. Could it be the size of the file that's the problem? I will try with a manually generated large file. One further test: I exported all my events from 0.2. So I now have a brand new file, created entirely by 0.2, and never touched by appsuite, or anything else, in a brand-new fresh profile. This 350K file has 1215 entries in it (shown by grep DTSTART). On import to trunk, only about 200 entries are imported. When I tried to repeat the test, it crashed in import. sigh. I'll continue trying to get a reproducible test file I can upload. thanks.

Added a sanitised calendar file which reproduces the problem. File has 1,214 entries. I created this file by taking my original file, from moz appsuite 20041202, and overwriting the private data, without otherwise disturbing the file structure. On attempt to import this into Sunbird trunk, from a checkout of 20051021 @ 2048 GMT, nothing seems to happen at all. No errors, no messages, no entries imported. Please let me know if there's anything further I can do to help...

Patch is a port of the patch for bug 308997. The importer is a copy of the provider, and i forgot to update the importer.

Comment on attachment 200465 [details] [diff] [review] import multiple vcalendars r=dmose. Could you also file a bug to remind us in the future to try and make it possible to share this code with the provider, rather than having to cut-n-paste?

patch checked in. Filed bug 313638 for the code-sharing issue.