Bug 8169 (int-153516)

Summary: exported .ics calendars have bad line format (LF for empty lines)
Product: [Maemo Official Applications] Calendar Reporter: Vincent Lefevre <vincent-maemo>
Component: GeneralAssignee: unassigned <nobody>
Status: RESOLVED FIXED QA Contact: calendar-general-bugs
Severity: normal    
Priority: Unspecified CC: andre_klapper, maemo
Version: 5.0/(2.2009.51-1)   
Target Milestone: 5.0/(10.2010.19-1)   
Hardware: N900   
OS: Maemo   

Description Vincent Lefevre (reporter) 2010-01-18 03:33:40 UTC
SOFTWARE VERSION:
2.2009.51-1.002

EXACT STEPS LEADING TO PROBLEM: 
1. Open Calendar.
2. In Settings, Edit calendars.
3. Select a calendar and click Export.
4. Look at the exported .ics file with a text editor (that can shows
end-of-lines, such as Emacs).

EXPECTED OUTCOME:
All ends of line should be CRLF (see OTHER COMMENTS).

ACTUAL OUTCOME:
Empty lines following END:VCALENDAR have a LF only.

REPRODUCIBILITY:
always

OTHER COMMENTS:
http://tools.ietf.org/html/rfc5545#section-3.1 says:
   The iCalendar object is organized into individual lines of text,
   called content lines.  Content lines are delimited by a line break,
   which is a CRLF sequence (CR character followed by LF character).

Note: this bug prevents from managing exported .ics files with Subversion
(error "svn: Inconsistent line ending style").
Comment 1 Lucas Maneos 2010-01-18 05:10:05 UTC
Thanks for the report.   Confirming, all END:VCALENDAR lines in the exported
file are terminated with <CR><LF><LF>.

The relevant RFC 5545 section is 3.4:

>   [...] The first line and last line of the
>   iCalendar object MUST contain a pair of iCalendar object delimiter
>   strings.  The syntax for an iCalendar stream is as follows:
> 
>       icalstream = 1*icalobject
> 
>       icalobject = "BEGIN" ":" "VCALENDAR" CRLF
>                    icalbody
>                    "END" ":" "VCALENDAR" CRLF
Comment 2 Andre Klapper maemo.org 2010-02-12 13:16:17 UTC
This has been fixed in package
calendar-backend 0.6-18+0m5
which is part of the internal build version
10.2010.06-3
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 3 Andre Klapper maemo.org 2010-03-15 20:51:24 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).