After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 578945 - [pst-import] Adapt to changes in libpst 0.6.41
[pst-import] Adapt to changes in libpst 0.6.41
Product: evolution
Classification: Applications
Component: Plugins
2.26.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Bharath Acharya
Evolution QA team
Depends on:
Reported: 2009-04-14 16:34 UTC by Matthew Barnes
Modified: 2009-07-27 05:14 UTC
See Also:
GNOME target: ---
GNOME version: ---

compatible with 0.6.35 (23.82 KB, patch)
2009-04-15 05:11 UTC, Bharath Acharya
none Details | Review
compatible with 0.6.37 (26.85 KB, patch)
2009-04-17 04:08 UTC, Bharath Acharya
needs-work Details | Review
Compatible with libpst-0.6.41 (26.12 KB, patch)
2009-07-24 05:13 UTC, Bharath Acharya
committed Details | Review

Description Matthew Barnes 2009-04-14 16:34:29 UTC
Corresponded with Carl Byington over upcoming changes to his libpst:

  "The major change is that almost all the char* fields in the mapi items
   (email, contact, etc) have changed to PST_STRING to properly handle code
   pages vs. utf8. The 64bit pst files can contain items with some strings in
   utf8, and other strings in the item's code-page. The PST_STRING type saves
   that information. For any given element, you can pst_convert_utf8() to
   force that element into utf8, and it will use iconv to convert the data if
   it is not already in utf8 format."

Sounds like we have some work to do.
Comment 1 Bharath Acharya 2009-04-15 04:44:56 UTC
I made a patch for .35 but seems Carl already has made the changes needed for .36 to the plugin. Would be attaching the patch once he's done with it.
Comment 2 Bharath Acharya 2009-04-15 05:11:29 UTC
Created attachment 132675 [details] [review]
compatible with 0.6.35

pst_attach_to_mem missing from libpst. Need to find an equivalent for it. maybe use pst_attach_to_file?
Comment 3 Bharath Acharya 2009-04-17 04:08:58 UTC
Created attachment 132804 [details] [review]
compatible with 0.6.37

.37 has some changes required for the plugin
Comment 4 Bharath Acharya 2009-04-17 04:11:01 UTC is the pre-release tarball.
Comment 5 Matthew Barnes 2009-04-18 19:18:52 UTC
I realize libpst is still < 1.0, but does the API show signs of stabilizing any time soon?  It seems to be changing awfully fast.
Comment 6 Bharath Acharya 2009-04-20 05:00:40 UTC
Yes the changes are too frequent and many off late. What I hear from the maintainer is, he'll make sure the Evolution plugin gets all it needs and then he'll stabilize the libpst code.

Review comments from the libpst maintainer for my patch.

+       if (attach-> != NULL) {
+               camel_mime_part_set_content (part, attach->,
strlen (attach->, mimetype);

attach->data is of type pst_binary, with fields size_t size, and char *
data. The is not necessarily null terminated, so
strlen(attach-> should be replaced by attach->data.size in
all cases.

+       if (item->file_as.str != NULL) {
+               m->folder_name = foldername_to_utf8

Any time you need a pst_string converted to utf8, it should be done via
pst_convert_utf8() or pst_convert_utf8_null() depending on whether you
want to preserve NULL strings. That will use the default character set
of the containing item, unless the pst_string came from a unicode mapi
element, in which case it is already in utf8.

+       if (item->email->outlook_sender_name.str != NULL &&
item->email->outlook_sender.str != NULL) {
+               camel_internet_address_add (addr,
item->email->outlook_sender_name.str, item->email->outlook_sender.str);

Any time you use a pst_string.str, you need to be aware that the data
in that string might be in any of a variety of character sets. In most
cases, you want to normalize it to utf8 before using it. In other
cases, you might want to get pst_default_charset(containing item). 
Comment 7 Akhil Laddha 2009-05-15 03:51:26 UTC
we are targeting patch only for master (2.27.x) or stable (2.26.x) also as we have 2.26.2 tarballs pending on May 18.
Comment 8 Matthew Barnes 2009-07-03 01:54:43 UTC
Plugin appears to be broken again when building against libpst 0.6.41.
Comment 9 Milan Crha 2009-07-13 10:33:14 UTC
(In reply to comment #8)
> Plugin appears to be broken again when building against libpst 0.6.41.

I believe Matt is on this, and tried with the patch from comment #3, thus marking it as needs-work. I wonder whether it'll has some value to re-attach here patches for each libpst release, and not rather wait for API stabilize there. Though I see Bharath talking about their willing to change API based on evo needs, thus it makes sense from this point of view.
Comment 10 Matthew Barnes 2009-07-21 15:47:40 UTC
I emailed Carl about his plans for libpst and strongly suggested he defer any further API/ABI breaks to 0.7 and keep 0.6 stable from here out.  Distros can't keep up with the current rate of breakage.
Comment 11 Bharath Acharya 2009-07-24 05:13:58 UTC
Created attachment 139130 [details] [review]
Compatible with libpst-0.6.41

The importer was broken on master. This works well for me. I have made the first change mentioned in the previous review, but I'll change the utf8 string handling for later. That needs more testing with the change. The attached patch should work well with the latest version
Comment 12 Bharath Acharya 2009-07-27 05:14:47 UTC
Committed to master for 2.27.5

Reopen the bug for any issues with this version update.