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 537507 - port to GMime 2.4.x
port to GMime 2.4.x
Status: RESOLVED FIXED
Product: balsa
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Balsa Maintainers
Balsa Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-10 01:43 UTC by Jeffrey Stedfast
Modified: 2015-04-11 23:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gmime-2.4.patch (45.79 KB, patch)
2008-06-10 01:46 UTC, Jeffrey Stedfast
none Details | Review
additional patch (9.85 KB, patch)
2008-06-11 03:06 UTC, Peter Bloomfield
none Details | Review
stack trace (4.87 KB, text/plain)
2008-06-11 20:06 UTC, Peter Bloomfield
  Details
updated-gmime-2.4.patch (59.46 KB, patch)
2008-06-14 13:58 UTC, Jeffrey Stedfast
none Details | Review
incremental patch (486 bytes, patch)
2008-08-03 17:52 UTC, Peter Bloomfield
none Details | Review
gmime-2.3.8.patch (99.62 KB, patch)
2008-09-01 02:24 UTC, Jeffrey Stedfast
none Details | Review
revised patch (127.93 KB, patch)
2008-09-08 02:13 UTC, Peter Bloomfield
none Details | Review
patch for GMime 2.3.9 (130.00 KB, patch)
2008-09-08 02:34 UTC, Peter Bloomfield
none Details | Review
revised patch for Balsa 2.3.26, GMime 2.3.9 (130.31 KB, patch)
2008-09-08 16:32 UTC, Peter Bloomfield
none Details | Review
Patch to compile against gmime-2.4.3 (134.51 KB, patch)
2008-12-18 21:46 UTC, Pawel Salek
none Details | Review
possible patch (157.64 KB, patch)
2008-12-19 17:38 UTC, Peter Bloomfield
none Details | Review
patch for Balsa rev 8057 to GMime-2.4.3 (130.83 KB, patch)
2009-01-20 19:45 UTC, Peter Bloomfield
none Details | Review
replacement patch (131.31 KB, patch)
2009-01-20 21:09 UTC, Peter Bloomfield
none Details | Review
patch for Balsa rev 8058 (131.19 KB, patch)
2009-01-21 21:32 UTC, Peter Bloomfield
none Details | Review
patch against Balsa rev 8064 (131.20 KB, patch)
2009-01-25 22:33 UTC, Peter Bloomfield
committed Details | Review

Description Jeffrey Stedfast 2008-06-10 01:43:58 UTC
port to gmime-2.4
Comment 1 Jeffrey Stedfast 2008-06-10 01:46:03 UTC
Created attachment 112454 [details] [review]
gmime-2.4.patch

This is a patch to port balsa to gmime-2.4 (which is not yet finalized, but figured I'd get a patch going so people can test balsa out with gmime-2.3.3+)

Obviously not worth applying this patch until gmime-2.4.0 is released ;)
Comment 2 Peter Bloomfield 2008-06-11 03:06:29 UTC
Created attachment 112521 [details] [review]
additional patch

Hi Jeff!

Thanks for getting this started!  I had to make a few addtional changes to get Balsa to build and run with GMime from current svn--apply the attached patch after gmime-2.4.patch.  We presumably need some further changes to take advantage of the new capability of handling encrypted signed parts.
Comment 3 Jeffrey Stedfast 2008-06-11 16:00:57 UTC
agh, looks like I forgot all about the pgp stuff (configure check disabled it because I don't have gpgme installed I guess)

Looks like I also missed use of off_t in data structures, good thing you noticed that ;)

There's one thing I think both of our patches missed: in the gpgme GMimeCipherContext implementation, I changed g_mime_cipher_context_sign() to return -1 on error (same as before) or the GMimeCipherHash id on success (rather than just 0).

Probably wouldn't be too hard to fix (I think gpgme has that info).

if no one else gets around to it before I have time, I'll update the patches to do that (might not be until next week, family stuff this weekend).

Anyways, glad the patch was appreciated :)

Also served as a great initial test for my gmime-port-2-2-to-2-4.sh script for which I found a few missing renames ;-)
Comment 4 Peter Bloomfield 2008-06-11 20:06:13 UTC
Created attachment 112575 [details]
stack trace

** gmime:ERROR:(gmime-filter-basic.c:215):filter_complete: assertion failed: (nwritten <= len)

Program received signal SIGABRT, Aborted.
0x00110416 in __kernel_vsyscall ()
Comment 5 Jeffrey Stedfast 2008-06-11 20:39:01 UTC
thanks, I'll take a look.
Comment 6 Peter Bloomfield 2008-06-11 23:45:01 UTC
I believe the issue is that g_mime_encoding_quoted_encode_close, when called with inlen == 0 and *state needs encoding, adds 4 characters to outbuf, but 

#define GMIME_QP_ENCODE_LEN(x)     ((size_t) (((x) + 1) * 3))

evaluates to 3.  I tried

#define GMIME_QP_ENCODE_LEN(x)     ((size_t) ((((x) + 1) * 3) + 1))

to allow for the '\n', and it seems to work.
Comment 7 Jeffrey Stedfast 2008-06-12 12:22:56 UTC
awesome catch, thanks! I've just fixed this in gmime trunk - I'll commit a similar fix to the gmime-2-2 branch as well.
Comment 8 Peter Bloomfield 2008-06-12 15:41:23 UTC
(In reply to comment #3) 
> Looks like I also missed use of off_t in data structures, good thing you
> noticed that ;)

Hmmm...I'm sure you would have noticed it, if we hadn't used an evil cast on a GMimeParserHeaderRegexFunc callback :(

We used a function that replaced the "gpointer user_data" with a data pointer, and cast it to GMimeParserHeaderRegexFunc.  Needless to say, it also used "off_t offset", but because of the explicit cast, gcc didn't complain about the mismatched argument.

Not to worry, the resulting seg fault got it onto the radar screen!  Anyway, it's cleaned up in Balsa's svn trunk, so now the additional patch (id=112521) may fail against svn.
Comment 9 Jeffrey Stedfast 2008-06-14 13:58:00 UTC
Created attachment 112730 [details] [review]
updated-gmime-2.4.patch

Ok, this patch includes both the original gmime-2.4.patch and also Peter's gmime-2.4-extras.patch, plus it also includes some fixes to gmime-gpgme-context to get rid of the need for the micalg member variable (no longer needed because g_mime_cipher_context_sign() now returns the hash algo used so that g_mime_multipart_signed_sign() can properly set the micalg parameter itself)
Comment 10 Peter Bloomfield 2008-08-03 17:52:11 UTC
Created attachment 115783 [details] [review]
incremental patch

Additional patch to accommodate GMimeRecipientType enum.
Comment 11 Jeffrey Stedfast 2008-09-01 02:24:45 UTC
Created attachment 117742 [details] [review]
gmime-2.3.8.patch

updated patch, this builds against gmime-2.3.8 which I just released.

I make no claim to "bug free"ness, but it does compile cleanly ;-)

Some GObject ref stuff has changed in gmime-2.3.8 - I did a quick search and fixed the only spots I could find that were affected, but I may have missed some.

basically, g_mime_*_get_*() where the *'s are both subclasses of GObject no longer returns a ref'd object.
Comment 12 Peter Bloomfield 2008-09-08 02:13:02 UTC
Created attachment 118266 [details] [review]
revised patch

Hi Jeff:

Here's a more extensive patch, for building --with-rubrica and --with-gpgme.  It also takes more advantage of GMime's new api.

Note to testers:  There are likely more cases where Balsa tests for 
InternetAddressList == NULL that should also test for internet_address_list_length == 0, or just assume that InternetAddressList != NULL.  I found some, but more probably exist.  Watch out for CRITICAL messages!
Comment 13 Peter Bloomfield 2008-09-08 02:34:40 UTC
Created attachment 118268 [details] [review]
patch for GMime 2.3.9

Just saw the update to 2.3.9.
Comment 14 Jeffrey Stedfast 2008-09-08 02:55:51 UTC
Peter:

the g_mime_[message,multipart]_foreach() functions have been changed to actually be recursive (altho won't descend into message/rfc822 parts), so you'll likely need to change lbm_mbox_prepare_object() and possibly lbm_try_reassemble_func() too unless I'm reading the patch wrong...
Comment 15 Peter Bloomfield 2008-09-08 16:32:52 UTC
Created attachment 118312 [details] [review]
revised patch for Balsa 2.3.26, GMime 2.3.9

Thanks for the heads-up!

The lbm_try_reassemble_func case seems OK--looking deeper for a wrapped message/partial shouldn't hurt.  In lbm_mbox_prepare_object, we can allow g_mime_multipart_foreach to handle a GMimeMultipart tree; firing it up just once at the top of each tree should do it.
Comment 16 Pawel Salek 2008-12-18 21:46:57 UTC
Created attachment 124974 [details] [review]
Patch to compile against gmime-2.4.3

I think we should release balsa-2.3.26 this year and merge this patch.
Comment 17 Peter Bloomfield 2008-12-19 00:38:34 UTC
Would that mean requiring gmime-2.4?  F10 is still on -2.2.21.
Comment 18 Pawel Salek 2008-12-19 07:24:51 UTC
I know, it is a difficult decision to make. This is why I want to make one final release against 2.0 first. Then, the development in svn would be made against 2.4  We could possibly provide own gmime-2.4 packages to users on older distributions if they want to upgrade. Let's move this discussion to balsa-list.
Comment 19 Peter Bloomfield 2008-12-19 17:38:52 UTC
Created attachment 125012 [details] [review]
possible patch

We could use conditional code to handle both versions, as in the attached patch.  It's ugly, and we'd want to simplify it asap, but it could get us through the transition.
Comment 20 Peter Bloomfield 2009-01-20 19:45:19 UTC
Created attachment 126861 [details] [review]
patch for Balsa rev 8057 to GMime-2.4.3

Updated patch for Balsa rev 8057.
Comment 21 Peter Bloomfield 2009-01-20 19:47:59 UTC
Oops--126861 obsoletes 124974.
Comment 22 Peter Bloomfield 2009-01-20 21:09:41 UTC
Created attachment 126870 [details] [review]
replacement patch

Remove conditioning on HAVE_GMIME_2_2_7.
Comment 23 Peter Bloomfield 2009-01-21 21:32:00 UTC
Created attachment 126948 [details] [review]
patch for Balsa rev 8058
Comment 24 Peter Bloomfield 2009-01-25 22:33:21 UTC
Created attachment 127220 [details] [review]
patch against Balsa rev 8064
Comment 25 Ildar 2009-01-26 03:41:38 UTC
Peter,

why don't you use a branch in SVN or a GIT repo for new patches?
Comment 26 Jeffrey Stedfast 2015-04-11 22:21:34 UTC
I'm assuming that Balsa has been ported to GMime 2.4 (and hopefully 2.6) by now, so this bug can probably be closed.
Comment 27 Peter Bloomfield 2015-04-11 23:25:50 UTC
Yes, looks like it's been at least 3 years, probably more like 6 :)

I'll leave you the pleasure of closing it...
Comment 28 Jeffrey Stedfast 2015-04-11 23:58:30 UTC
Haha, cool ;-)