compile error of current git on F15

compile error of current git on F15

[Dirk Hohndel]

CC -O2 notmuch-reply.o
notmuch-reply.c: In function ‘notmuch_reply_command’:
notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default]
/usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
make: *** [notmuch-reply.o] Error 1

This seems to have been introduced in Jameson's crypto patch series...

./configure shows:

Checking for Xapian development files... Yes (1.2.4).
Checking for GMime development files... Yes (gmime-2.6).
Checking for Glib development files (>= 2.14)... Yes.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: compile error of current git on F15

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> CC -O2 notmuch-reply.o
> notmuch-reply.c: In function ‘notmuch_reply_command’:
> notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
> notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default]
> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
> make: *** [notmuch-reply.o] Error 1
> 
> This seems to have been introduced in Jameson's crypto patch series...
> 
> ./configure shows:
> 
> Checking for Xapian development files... Yes (1.2.4).
> Checking for GMime development files... Yes (gmime-2.6).
> Checking for Glib development files (>= 2.14)... Yes.

Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
never looked at, and it looks like there are API changes.  This of
course doesn't help you, Dirk, but this probably means we should require
libgmime-2.4, at least until we can figure out how to support both
versions, which I'm not sure how to handle.

Dirk, just out of curiosity, what system are you running that is
provides gmime 2.6?

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: compile error of current git on F15

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

i'm CC'ing the upstream lead developer of gmime here to see if he has
any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey!

On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote:
> On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
>> CC -O2 notmuch-reply.o
>> notmuch-reply.c: In function ‘notmuch_reply_command’:
>> notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
>> notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default]
>> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
>> make: *** [notmuch-reply.o] Error 1
>>
>> This seems to have been introduced in Jameson's crypto patch series...
>>
>> ./configure shows:
>>
>> Checking for Xapian development files... Yes (1.2.4).
>> Checking for GMime development files... Yes (gmime-2.6).
>> Checking for Glib development files (>= 2.14)... Yes.
> 
> Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
> never looked at, and it looks like there are API changes.  This of
> course doesn't help you, Dirk, but this probably means we should require
> libgmime-2.4, at least until we can figure out how to support both
> versions, which I'm not sure how to handle.
> 
> Dirk, just out of curiosity, what system are you running that is
> provides gmime 2.6?

F15 probably means Fedora 15.

gmime 2.6 has not been released yet; gmime 2.5 is the development
version (which itself has an unstable API); the project uses the
even=stable/odd=unstable version numbering scheme.

As the dev version, gmime 2.5 identifies itself as 2.6.  I'm not sure i
can justify this decision.  Jeffrey, can you explain?

If F15 does not have gmime 2.4 available in it, it's possible that it
may not be able to build notmuch :/

I don't think that notmuch should attempt to target a library with an
unstable API.  But if anyone is interested in preparing for the gmime
2.6 release (maybe jeffrey can hint at the timeline for us) may want to
prepare changesets that #ifdef the relevant code depending on the API
version.

Once gmime 2.6 is released, we'll need to decide if we want to remain
compatible with the old API as well, or just require gmime 2.6; but i
don't think we need to cross that bridge right now.

Regards,

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1030 bytes --]

Re: compile error of current git on F15

[Dirk Hohndel]

On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Non-text part: multipart/signed
> i'm CC'ing the upstream lead developer of gmime here to see if he has
> any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey!
> 
> On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote:
> > On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> >> CC -O2 notmuch-reply.o
> >> notmuch-reply.c: In function ‘notmuch_reply_command’:
> >> notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
> >> notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default]
> >> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
> >> make: *** [notmuch-reply.o] Error 1
> >>
> >> This seems to have been introduced in Jameson's crypto patch series...
> >>
> >> ./configure shows:
> >>
> >> Checking for Xapian development files... Yes (1.2.4).
> >> Checking for GMime development files... Yes (gmime-2.6).
> >> Checking for Glib development files (>= 2.14)... Yes.
> > 
> > Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
> > never looked at, and it looks like there are API changes.  This of
> > course doesn't help you, Dirk, but this probably means we should require
> > libgmime-2.4, at least until we can figure out how to support both
> > versions, which I'm not sure how to handle.
> > 
> > Dirk, just out of curiosity, what system are you running that is
> > provides gmime 2.6?
> 
> F15 probably means Fedora 15.

Correct
 
> gmime 2.6 has not been released yet; gmime 2.5 is the development
> version (which itself has an unstable API); the project uses the
> even=stable/odd=unstable version numbering scheme.
> 
> As the dev version, gmime 2.5 identifies itself as 2.6.  I'm not sure i
> can justify this decision.  Jeffrey, can you explain?
> 
> If F15 does not have gmime 2.4 available in it, it's possible that it
> may not be able to build notmuch :/

That's where I am right now. But here's the odd thing: gmime-2.6 support
was explicitly added to the configure script last year:
http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html

And it's only a recent change to notmuch that broke the build on F15
(it's one of the patches for the crypto support).

So in my book this is a regression for notmuch!
 
> I don't think that notmuch should attempt to target a library with an
> unstable API.  But if anyone is interested in preparing for the gmime
> 2.6 release (maybe jeffrey can hint at the timeline for us) may want to
> prepare changesets that #ifdef the relevant code depending on the API
> version.
> 
> Once gmime 2.6 is released, we'll need to decide if we want to remain
> compatible with the old API as well, or just require gmime 2.6; but i
> don't think we need to cross that bridge right now.

Given what I wrote above you'll be unsurprised that I don't agree with
this interpretation of the situation.

This used to work and used to be supported and was broken in a recent
notmuch patch.

/D

Re: compile error of current git on F15

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> This used to work and used to be supported and was broken in a recent
> notmuch patch.

Hey, Dirk.  I would actually say that support for gmime 2.6 was merely
coincidental up until now.  For all functionality we had been using, the
API in 2.4 and 2.6 was the same (the patch that you point to only
modifies the config file, not any of the code itself).  But the recent
crypto support uses the gmime 2.4 crypto API, which apparently has
changed in versions of gmime >2.4.

If you don't have access to gmime 2.4, then maybe you could look into
providing patches for gmime 2.6 support, or alternately into disabling
the notmuch functionality that does not work with gmime 2.6 if only 2.6
is available.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: compile error of current git on F15

[Darren McGuicken]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Wed, 01 Jun 2011 09:55:16 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> > This used to work and used to be supported and was broken in a
> > recent notmuch patch.
>
> If you don't have access to gmime 2.4, then maybe you could look into
> providing patches for gmime 2.6 support, or alternately into disabling
> the notmuch functionality that does not work with gmime 2.6 if only
> 2.6 is available.

Hi guys, I assume this is old news, although I haven't seen anything
else mentioned on list since the chain Dirk started - there's a koji
build of 0.9 for rawhide, the source rpm of which contains a gmime 2.6
patch.  I recently moved from Ubuntu to Fedora 16 on the netbook so I
grabbed the patch and spec file, updated it to point to the 0.10 tarball
and can confirm that the patch still applies cleanly and the notmuch
build appears fine (crypto et al).

Assuming this mail sends, of course :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: compile error of current git on F15

[David Bremner]

On Thu, 24 Nov 2011 21:45:20 +0000, Darren McGuicken <mailing-notmuch@fernseed.info> wrote:
> Hi guys, I assume this is old news, although I haven't seen anything
> else mentioned on list since the chain Dirk started - there's a koji
> build of 0.9 for rawhide, the source rpm of which contains a gmime 2.6
> patch.  I recently moved from Ubuntu to Fedora 16 on the netbook so I
> grabbed the patch and spec file, updated it to point to the 0.10 tarball
> and can confirm that the patch still applies cleanly and the notmuch
> build appears fine (crypto et al).

Just confirm, all the crypto tests pass with this patch? In that case,
can we have the patch (preferably as generated by git-send-email)? Or
did I miss it somewhere in this thread?

d

Re: compile error of current git on F15

[Darren McGuicken]

[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

On Fri, 25 Nov 2011 13:43:35 -0500, David Bremner <david@tethera.net> wrote:
> Just confirm, all the crypto tests pass with this patch? In that case,
> can we have the patch (preferably as generated by git-send-email)? Or
> did I miss it somewhere in this thread?

I don't believe the patch ever made it to the list, I can't find it in
my own archive.  From the changelog here:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=269819

  it looks like Karel Klíč of Red Hat created it back in July, I assume
that's when Fedora moved to the later GMime version.

The patch itself looks like it's a straight re-mapping of the 2.4
GMimeSignatureValidity to the 2.5+ equivalent along with some
deprecation of GMimeSession, so just applying the patch will break
compilation for anyone < 2.5.

Also, three of the crypto tests relating to signature validation /do/
fail, although it looks like that may simply be down to changes in the
output format and so just need updated test cases.

I've attached the patch as-is to this mail for reference purposes, but
based on the above it'll need a bit of tweaking before it's useful to
the wider group.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Fedora GMime Patch --]
[-- Type: text/x-patch, Size: 10095 bytes --]

diff -up notmuch-0.6.1/notmuch-client.h.gmime notmuch-0.6.1/notmuch-client.h
--- notmuch-0.6.1/notmuch-client.h.gmime	2011-07-17 16:20:51.000000000 +0200
+++ notmuch-0.6.1/notmuch-client.h	2011-07-28 17:24:16.904949635 +0200
@@ -68,7 +68,7 @@ typedef struct notmuch_show_format {
     void (*part_start) (GMimeObject *part,
 			int *part_count);
     void (*part_encstatus) (int status);
-    void (*part_sigstatus) (const GMimeSignatureValidity* validity);
+    void (*part_sigstatus) (GMimeSignatureList *siglist);
     void (*part_content) (GMimeObject *part);
     void (*part_end) (GMimeObject *part);
     const char *part_sep;
@@ -82,7 +82,7 @@ typedef struct notmuch_show_params {
     int entire_thread;
     int raw;
     int part;
-    GMimeCipherContext* cryptoctx;
+    GMimeCryptoContext* cryptoctx;
     int decrypt;
 } notmuch_show_params_t;
 
diff -up notmuch-0.6.1/notmuch-reply.c.gmime notmuch-0.6.1/notmuch-reply.c
--- notmuch-0.6.1/notmuch-reply.c.gmime	2011-07-17 16:20:51.000000000 +0200
+++ notmuch-0.6.1/notmuch-reply.c	2011-07-28 17:24:16.904949635 +0200
@@ -610,13 +610,10 @@ notmuch_reply_command (void *ctx, int ar
 	    }
 	} else if ((STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
 	    if (params.cryptoctx == NULL) {
-		GMimeSession* session = g_object_new(g_mime_session_get_type(), NULL);
-		if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session, "gpg")))
+		if (NULL == (params.cryptoctx = g_mime_gpg_context_new(NULL, "gpg")))
 		    fprintf (stderr, "Failed to construct gpg context.\n");
 		else
 		    g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
-		g_object_unref (session);
-		session = NULL;
 	    }
 	} else {
 	    fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
diff -up notmuch-0.6.1/notmuch-show.c.gmime notmuch-0.6.1/notmuch-show.c
--- notmuch-0.6.1/notmuch-show.c.gmime	2011-07-17 16:20:51.000000000 +0200
+++ notmuch-0.6.1/notmuch-show.c	2011-07-28 17:24:16.905949620 +0200
@@ -70,7 +70,7 @@ static void
 format_part_encstatus_json (int status);
 
 static void
-format_part_sigstatus_json (const GMimeSignatureValidity* validity);
+format_part_sigstatus_json (GMimeSignatureList *siglist);
 
 static void
 format_part_content_json (GMimeObject *part);
@@ -420,16 +420,14 @@ show_text_part_content (GMimeObject *par
 }
 
 static const char*
-signer_status_to_string (GMimeSignerStatus x)
+signature_status_to_string (GMimeSignatureStatus x)
 {
     switch (x) {
-    case GMIME_SIGNER_STATUS_NONE:
-	return "none";
-    case GMIME_SIGNER_STATUS_GOOD:
+    case GMIME_SIGNATURE_STATUS_GOOD:
 	return "good";
-    case GMIME_SIGNER_STATUS_BAD:
+    case GMIME_SIGNATURE_STATUS_BAD:
 	return "bad";
-    case GMIME_SIGNER_STATUS_ERROR:
+    case GMIME_SIGNATURE_STATUS_ERROR:
 	return "error";
     }
     return "unknown";
@@ -524,59 +522,65 @@ format_part_encstatus_json (int status)
 }
 
 static void
-format_part_sigstatus_json (const GMimeSignatureValidity* validity)
+format_part_sigstatus_json (GMimeSignatureList *siglist)
 {
     printf (", \"sigstatus\": [");
 
-    if (!validity) {
+    if (!siglist) {
 	printf ("]");
 	return;
     }
 
-    const GMimeSigner *signer = g_mime_signature_validity_get_signers (validity);
-    int first = 1;
     void *ctx_quote = talloc_new (NULL);
+    int i;
+    for (i = 0; i < g_mime_signature_list_length (siglist); ++i) {
+	GMimeSignature *signature = g_mime_signature_list_get_signature (siglist, i);
 
-    while (signer) {
-	if (first)
-	    first = 0;
-	else
+	if (i > 0)
 	    printf (", ");
-
 	printf ("{");
 
 	/* status */
+	GMimeSignatureStatus status = g_mime_signature_get_status (signature);
 	printf ("\"status\": %s",
 		json_quote_str (ctx_quote,
-				signer_status_to_string (signer->status)));
+				signature_status_to_string (status)));
 
-	if (signer->status == GMIME_SIGNER_STATUS_GOOD)
+	GMimeCertificate *certificate = g_mime_signature_get_certificate (signature);
+	if (status == GMIME_SIGNATURE_STATUS_GOOD)
 	{
-	    if (signer->fingerprint)
-		printf (", \"fingerprint\": %s", json_quote_str (ctx_quote, signer->fingerprint));
+	    if (certificate)
+		printf (", \"fingerprint\": %s", json_quote_str (ctx_quote, g_mime_certificate_get_fingerprint (certificate)));
 	    /* these dates are seconds since the epoch; should we
 	     * provide a more human-readable format string? */
-	    if (signer->created)
-		printf (", \"created\": %d", (int) signer->created);
-	    if (signer->expires)
-		printf (", \"expires\": %d", (int) signer->expires);
+	    time_t created = g_mime_signature_get_created (signature);
+	    if (created != -1)
+		printf (", \"created\": %d", (int) created);
+	    time_t expires = g_mime_signature_get_expires (signature);
+	    if (expires != -1)
+		printf (", \"expires\": %d", (int) expires);
 	    /* output user id only if validity is FULL or ULTIMATE. */
 	    /* note that gmime is using the term "trust" here, which
 	     * is WRONG.  It's actually user id "validity". */
-	    if ((signer->name) && (signer->trust)) {
-		if ((signer->trust == GMIME_SIGNER_TRUST_FULLY) || (signer->trust == GMIME_SIGNER_TRUST_ULTIMATE))
-		    printf (", \"userid\": %s", json_quote_str (ctx_quote, signer->name));
+	    if (certificate)
+	    {
+		const char *name = g_mime_certificate_get_issuer_name (certificate);
+		GMimeCertificateTrust trust = g_mime_certificate_get_trust (certificate);
+		if (name && (trust == GMIME_CERTIFICATE_TRUST_FULLY || trust == GMIME_CERTIFICATE_TRUST_ULTIMATE))
+		    printf (", \"userid\": %s", json_quote_str (ctx_quote, name));
            }
-       } else {
-           if (signer->keyid)
-               printf (", \"keyid\": %s", json_quote_str (ctx_quote, signer->keyid));
-       }
-       if (signer->errors != GMIME_SIGNER_ERROR_NONE) {
-           printf (", \"errors\": %x", signer->errors);
-       }
+	} else if (certificate) {
+	    const char *key_id = g_mime_certificate_get_key_id (certificate);
+	    if (key_id)
+		printf (", \"keyid\": %s", json_quote_str (ctx_quote, key_id));
+	}
+
+	GMimeSignatureError errors = g_mime_signature_get_errors (signature);
+	if (errors != GMIME_SIGNATURE_ERROR_NONE) {
+	    printf (", \"errors\": %x", errors);
+	}
 
-       printf ("}");
-       signer = signer->next;
+	printf ("}");
     }
 
     printf ("]");
@@ -899,13 +903,10 @@ notmuch_show_command (void *ctx, unused 
 	} else if ((STRNCMP_LITERAL (argv[i], "--verify") == 0) ||
 		   (STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
 	    if (params.cryptoctx == NULL) {
-		GMimeSession* session = g_object_new(g_mime_session_get_type(), NULL);
-		if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session, "gpg")))
+		if (NULL == (params.cryptoctx = g_mime_gpg_context_new(NULL, "gpg")))
 		    fprintf (stderr, "Failed to construct gpg context.\n");
 		else
 		    g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, FALSE);
-		g_object_unref (session);
-		session = NULL;
 	    }
 	    if (STRNCMP_LITERAL (argv[i], "--decrypt") == 0)
 		params.decrypt = 1;
diff -up notmuch-0.6.1/show-message.c.gmime notmuch-0.6.1/show-message.c
--- notmuch-0.6.1/show-message.c.gmime	2011-07-17 16:20:51.000000000 +0200
+++ notmuch-0.6.1/show-message.c	2011-07-28 17:27:12.295304742 +0200
@@ -68,15 +68,16 @@ show_message_part (GMimeObject *part,
 			 g_mime_multipart_get_count (multipart));
 	    } else {
 		GMimeMultipartEncrypted *encrypteddata = GMIME_MULTIPART_ENCRYPTED (part);
-		decryptedpart = g_mime_multipart_encrypted_decrypt (encrypteddata, params->cryptoctx, &err);
+		GMimeDecryptResult *decrypt_result = g_mime_decrypt_result_new ();
+		decryptedpart = g_mime_multipart_encrypted_decrypt (encrypteddata, params->cryptoctx, &decrypt_result, &err);
 		if (decryptedpart) {
 		    if ((selected || state->in_zone) && format->part_encstatus)
 			format->part_encstatus (1);
-		    const GMimeSignatureValidity *sigvalidity = g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
-		    if (!sigvalidity)
-			fprintf (stderr, "Failed to verify signed part: %s\n", (err ? err->message : "no error explanation given"));
+		    GMimeSignatureList *siglist = g_mime_decrypt_result_get_signatures (decrypt_result);
+		    if (!siglist)
+			fprintf (stderr, "Failed to get signatures: %s\n", (err ? err->message : "no error explanation given"));
 		    if ((selected || state->in_zone) && format->part_sigstatus)
-			format->part_sigstatus (sigvalidity);
+			format->part_sigstatus (siglist);
 		} else {
 		    fprintf (stderr, "Failed to decrypt part: %s\n", (err ? err->message : "no error explanation given"));
 		    if ((selected || state->in_zone) && format->part_encstatus)
@@ -92,20 +93,14 @@ show_message_part (GMimeObject *part,
 			 "Error: %d part(s) for a multipart/signed message (should be exactly 2)\n",
 			 g_mime_multipart_get_count (multipart));
 	    } else {
-		/* For some reason the GMimeSignatureValidity returned
-		 * here is not a const (inconsistent with that
-		 * returned by
-		 * g_mime_multipart_encrypted_get_signature_validity,
-		 * and therefore needs to be properly disposed of.
-		 * Hopefully the API will become more consistent. */
-		GMimeSignatureValidity *sigvalidity = g_mime_multipart_signed_verify (GMIME_MULTIPART_SIGNED (part), params->cryptoctx, &err);
-		if (!sigvalidity) {
+		GMimeSignatureList *siglist = g_mime_multipart_signed_verify (GMIME_MULTIPART_SIGNED (part), params->cryptoctx, &err);
+		if (!siglist) {
 		    fprintf (stderr, "Failed to verify signed part: %s\n", (err ? err->message : "no error explanation given"));
 		}
 		if ((selected || state->in_zone) && format->part_sigstatus)
-		    format->part_sigstatus (sigvalidity);
-		if (sigvalidity)
-		    g_mime_signature_validity_free (sigvalidity);
+		    format->part_sigstatus (siglist);
+		if (siglist)
+		    g_object_unref (siglist);
 	    }
 	}
 

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]