tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins  wrote:
> Did you guys try to address the issue of tag removal at all?  I've been
> trying to decide if this is something we need to worry about or not.
> For instance, if cworth pushed a tag ".needs-review", you would probably
> want to have that tag removed if cworth removed it.  I guess
> alternatively he could just push the tag ".reviewed" to nullify the
> meaning of the previous one.  I'm not sure that would work in all cases,
> though.

Yes, if he deletes the tag "public.needs-review" in his notmuch, and
then pushes it, it will delete the tag "cworth.needs-review" from yours.

A couple points about this:

1. If you added your own "needs-review" tag to things that have a
"cworth.needs-review" tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins 
 wrote:
> Did you guys try to address the issue of tag removal at all?  I've been
> trying to decide if this is something we need to worry about or not.
> For instance, if cworth pushed a tag ".needs-review", you would probably
> want to have that tag removed if cworth removed it.  I guess
> alternatively he could just push the tag ".reviewed" to nullify the
> meaning of the previous one.  I'm not sure that would work in all cases,
> though.

Yes, if he deletes the tag "public.needs-review" in his notmuch, and
then pushes it, it will delete the tag "cworth.needs-review" from yours.

A couple points about this:

1. If you added your own "needs-review" tag to things that have a
"cworth.needs-review" tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal  wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes to a http-accessable location. And you could
> associate the namespace "cworth" with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

> You type `whatevercommand pull cworth` and the tags come down from that
> URL as "cworth.*".
> 
> So what he has as "public.to-push" comes down to your notmuch as
> "cworth.to-push".

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag ".needs-review", you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag ".reviewed" to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.


pgpOt4bxk6pSj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal  
wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes to a http-accessable location. And you could
> associate the namespace "cworth" with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

> You type `whatevercommand pull cworth` and the tags come down from that
> URL as "cworth.*".
> 
> So what he has as "public.to-push" comes down to your notmuch as
> "cworth.to-push".

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag ".needs-review", you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag ".reviewed" to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins  wrote:
> I've been thinking about this more and it really seems we need a way to
> just share tags.  What if we had a way to export all the tags for a set
> of messages as a notmuch dump file, that could just be piped into
> notmuch to modify tags?  This would be a great way for lots of people to
> keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace "public" with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace "cworth" with those same tags.

He types `whatevercommand push public` and all tags "public.*" go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as "cworth.*".

So what he has as "public.to-push" comes down to your notmuch as
"cworth.to-push".

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:"m1k4rkkchy.fsf at watt.gilman.jhu.edu"
id:"m1hbmokbxj.fsf at watt.gilman.jhu.edu"

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

Best,
Jesse

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins 
 wrote:
> I've been thinking about this more and it really seems we need a way to
> just share tags.  What if we had a way to export all the tags for a set
> of messages as a notmuch dump file, that could just be piped into
> notmuch to modify tags?  This would be a great way for lots of people to
> keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace "public" with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace "cworth" with those same tags.

He types `whatevercommand push public` and all tags "public.*" go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as "cworth.*".

So what he has as "public.to-push" comes down to your notmuch as
"cworth.to-push".

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:"m1k4rkkchy@watt.gilman.jhu.edu"
id:"m1hbmokbxj@watt.gilman.jhu.edu"

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

Best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth  wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like "signed" and "encrypted", since it would allow for
tagging messages that were indexed before the "signed"/"encrypted"
tagging was a feature.


pgp5zi4sZlKn7.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth  wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like "signed" and "encrypted", since it would allow for
tagging messages that were indexed before the "signed"/"encrypted"
tagging was a feature.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Carl Worth]

On Sun, 05 Jun 2011 17:35:40 -0700, Jameson Graef Rollins 
 wrote:
> On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> > From a quick rebase of your release-candidate branch and a comparison
> > with what I have queued it looks like only the following commits are
> > left on your branch and not in my email queue:
> > 
> > emacs: update notmuch-crypto-process-mime config variable documentation.
> 
> Hey, Carl.  This is actually a five-patch series that starts at:
> 
>  emacs: add notmuch-show-refresh-view function
>   id:"1306627784-3401-1-git-send-email-jroll...@finestructure.net"

OK, good. That is actually part of my queue.

> You should also look at the following two patch series to fix the
> message/rfc822 part handling:
> 
>  Do not attept to output part raw if part is not GMimePart.
>   id:"1307120466-4980-1-git-send-email-jroll...@finestructure.net"
> 
>  improving message/rfc822 part handling
>   id:"1307320169-29905-1-git-send-email-jroll...@finestructure.net"

OK. These are also already queued.

Hopefully, someone will provide me with a good way to publish my queue
soon, ("notmuch search --output=html" ?), and then communication like
this will be a bit easier. ;-)

-Carl

-- 
carl.d.wo...@intel.com


pgp97VBjumIaN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Carl Worth]

On Sun, 05 Jun 2011 17:35:40 -0700, Jameson Graef Rollins  wrote:
> On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> > From a quick rebase of your release-candidate branch and a comparison
> > with what I have queued it looks like only the following commits are
> > left on your branch and not in my email queue:
> > 
> > emacs: update notmuch-crypto-process-mime config variable documentation.
> 
> Hey, Carl.  This is actually a five-patch series that starts at:
> 
>  emacs: add notmuch-show-refresh-view function
>   id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

OK, good. That is actually part of my queue.

> You should also look at the following two patch series to fix the
> message/rfc822 part handling:
> 
>  Do not attept to output part raw if part is not GMimePart.
>   id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"
> 
>  improving message/rfc822 part handling
>   id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

OK. These are also already queued.

Hopefully, someone will provide me with a good way to publish my queue
soon, ("notmuch search --output=html" ?), and then communication like
this will be a bit easier. ;-)

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
> 
> emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:"1306627784-3401-1-git-send-email-jroll...@finestructure.net"

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:"1307120466-4980-1-git-send-email-jroll...@finestructure.net"

 improving message/rfc822 part handling
  id:"1307320169-29905-1-git-send-email-jroll...@finestructure.net"

jamie.


pgpw9OBIslcuw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
> 
> emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"

 improving message/rfc822 part handling
  id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Carl Worth]

On Tue, 31 May 2011 11:43:31 -0700, Jameson Graef Rollins 
 wrote:
> Hi, folks.  I have pushed a new version of the release-candidate/0.6
> branch to my repo [0].  It is all reworked on top of notmuch/master [1],
> and includes:
...
> cworth: do you want to review this for the new release?  We're very close!
> One last push and we can get this thing out.

I've been going through it, but trying to focus more on the emails I
have queued up (which is currently 58 messages).

From a quick rebase of your release-candidate branch and a comparison
with what I have queued it looks like only the following commits are
left on your branch and not in my email queue:

emacs: update notmuch-crypto-process-mime config variable documentation.
bump debian standards version
Increment library version to 1.4.0
Increment notmuch version to 0.6
debian: update list of symbols for libnotmuch
debian: separate build dependency entries on to separate lines
debian: update changelog for 0.6

That's mostly just the release bookkeeping, which is good---that means
I've been through most of the "meat" of the patches on your branch.

I'll now work through what I still have in my queue (Austin's atomicity
work is the only big piece) and then look at the above, at which point
we should be there. (And yes, I know I sound like I'm talking along the
lines of a feature-based release rather than a time-based release.)

-Carl


pgpPvUn7egUVi.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Carl Worth]

On Tue, 31 May 2011 11:43:31 -0700, Jameson Graef Rollins  wrote:
> Hi, folks.  I have pushed a new version of the release-candidate/0.6
> branch to my repo [0].  It is all reworked on top of notmuch/master [1],
> and includes:
...
> cworth: do you want to review this for the new release?  We're very close!
> One last push and we can get this thing out.

I've been going through it, but trying to focus more on the emails I
have queued up (which is currently 58 messages).

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

Hi, folks.  I have pushed a new version of the release-candidate/0.6
branch to my repo [0].  It is all reworked on top of notmuch/master [1],
and includes:

* the miscellaneous fixes/improvements patch series starting at
  id:"1306619520-25730-2-git-send-email-jroll...@finestructure.net"
* the notmuch-show refresh patches
* Austin's atomicity patches
* Felipe's vim patches
* updates to the debian packaging

cworth: do you want to review this for the new release?  We're very close!
One last push and we can get this thing out.

bremner: do you want to reconcile this with what you've already pushed
to Debian experimental, and then push another version?

jamie.

[0] git://finestructure.net/notmuch [release-candidate/0.6]
[1] cb8418784c21155ffea79cce8409a7ea3c546937


pgpzTvq91w1OQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Jameson Graef Rollins]

Hi, folks.  I have pushed a new version of the release-candidate/0.6
branch to my repo [0].  It is all reworked on top of notmuch/master [1],
and includes:

* the miscellaneous fixes/improvements patch series starting at
  id:"1306619520-25730-2-git-send-email-jrollins at finestructure.net"
* the notmuch-show refresh patches
* Austin's atomicity patches
* Felipe's vim patches
* updates to the debian packaging

cworth: do you want to review this for the new release?  We're very close!
One last push and we can get this thing out.

bremner: do you want to reconcile this with what you've already pushed
to Debian experimental, and then push another version?

jamie.

[0] git://finestructure.net/notmuch [release-candidate/0.6]
[1] cb8418784c21155ffea79cce8409a7ea3c546937
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110531/b777c53e/attachment.pgp>

release-candidate/0.6 redux

[Austin Clements]

On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
 wrote:
> Austin: speaking of which, would you mind rebasing that patch series
> against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
> sending that to the list again? ?That might help push Carl to merge that
> stuff sooner. ?I think the conflicts are very minor.

Done.  The only conflicts were the usual suspects (lists in the test
suite).  I pulled in the GDB dependency in the test suite and the
corresponding tweaks to test-lib that were on the list previously
(id:"1305206080-17461-1-git-send-email-amdragon at mit.edu" and
id:"1305206110-17511-1-git-send-email-amdragon at mit.edu").  It's on
for-review/atomic-new-v4 at the usual,
  http://awakening.csail.mit.edu/git/notmuch.git

Re: release-candidate/0.6 redux

[Austin Clements]

On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
 wrote:
> Austin: speaking of which, would you mind rebasing that patch series
> against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
> sending that to the list again?  That might help push Carl to merge that
> stuff sooner.  I think the conflicts are very minor.

Done.  The only conflicts were the usual suspects (lists in the test
suite).  I pulled in the GDB dependency in the test suite and the
corresponding tweaks to test-lib that were on the list previously
(id:"1305206080-17461-1-git-send-email-amdra...@mit.edu" and
id:"1305206110-17511-1-git-send-email-amdra...@mit.edu").  It's on
for-review/atomic-new-v4 at the usual,
  http://awakening.csail.mit.edu/git/notmuch.git
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins 
 wrote:
> So what follows is a patch series for a bunch of miscellaneous patches
> that should be included in 0.6.  Most of them were originally part of
> the release-candiate/0.6 branch, and they are here rebased on top of
> notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
> includes all the multipart and crypto rework.

I forgot to mention that the other two things that were in the original
release-candidate/0.6 that really need to be included before 0.6 is
released are

* Austin Clements's atomicity patches
* Felipe Contreras's vim patches

both of which have been sent to the list previously, although I believe
that Austin might have a couple extra patches in his atomic-new-v3
branch.

Austin: speaking of which, would you mind rebasing that patch series
against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
sending that to the list again?  That might help push Carl to merge that
stuff sooner.  I think the conflicts are very minor.

jamie.


pgpx7fw0osdyJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Jameson Graef Rollins]

On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins  wrote:
> So what follows is a patch series for a bunch of miscellaneous patches
> that should be included in 0.6.  Most of them were originally part of
> the release-candiate/0.6 branch, and they are here rebased on top of
> notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
> includes all the multipart and crypto rework.

I forgot to mention that the other two things that were in the original
release-candidate/0.6 that really need to be included before 0.6 is
released are

* Austin Clements's atomicity patches
* Felipe Contreras's vim patches

both of which have been sent to the list previously, although I believe
that Austin might have a couple extra patches in his atomic-new-v3
branch.

Austin: speaking of which, would you mind rebasing that patch series
against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
sending that to the list again?  That might help push Carl to merge that
stuff sooner.  I think the conflicts are very minor.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110528/5b65612c/attachment-0001.pgp>

release-candidate/0.6 redux

[Jameson Graef Rollins]

So what follows is a patch series for a bunch of miscellaneous patches
that should be included in 0.6.  Most of them were originally part of
the release-candiate/0.6 branch, and they are here rebased on top of
notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
includes all the multipart and crypto rework.

Some of these patches are cleanup, but some are important bug fixes,
some previously sent to the list by others that I have signed off on,
and some by me that were not previously sent to the list.  I highly
recommend that this entire series be incorporated before 0.6 is
released.

jamie.

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Jameson Graef Rollins]

So what follows is a patch series for a bunch of miscellaneous patches
that should be included in 0.6.  Most of them were originally part of
the release-candiate/0.6 branch, and they are here rebased on top of
notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
includes all the multipart and crypto rework.

Some of these patches are cleanup, but some are important bug fixes,
some previously sent to the list by others that I have signed off on,
and some by me that were not previously sent to the list.  I highly
recommend that this entire series be incorporated before 0.6 is
released.

jamie.

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 13:59:51 -0700, Carl Worth  wrote:
> So what I'd love to see from here is a commit with a description like
> the above, and then a test case looking like your example.
> 
> From there, I'd next like a new version of the commit that gets the
> intended behavior with less code duplication.
> 
> I'll work on each of the above unless someone beats me to any of it. Let
> me know.

I've now pushed out my own version of the MIME restructuring feature.

It differs from what was presented here in avoiding the code
duplication.

It also provides properly nested mutlipart/* output for the
--format=text case. That's not that I expect anybody to *do* anything
with that nested output, just that it was cleaner and easier to fix both
text/json at the same time, (and avoiding doing that is perhaps what led
to the original code duplication).

I also cherry-picked in a piece of later patch from Jamie so that the
existing emacs tests still pass. And I updated the documentation for
this new feature.

So I'm happy with this new feature now, (which I know provides an
essential part of the basis for the rest of the crypto branch).

From here, I'm hoping that my review of the rest of Jamie's
release-candidate branch goes faster. The general shape of the commits
and commit messages looks pretty good to me, so I think it will.

I think there are still features added here and there without
corresponding test cases (multipart/alternative is one that comes to
mind) and perhaps without updated documentation (--decrypt is at least
documented---but I do think it's strange that it's documented to only
work for json output).

More from me tomorrow.

-Carl


pgpzsmwWIBXKT.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 13:59:51 -0700, Carl Worth  wrote:
> So what I'd love to see from here is a commit with a description like
> the above, and then a test case looking like your example.
> 
> From there, I'd next like a new version of the commit that gets the
> intended behavior with less code duplication.
> 
> I'll work on each of the above unless someone beats me to any of it. Let
> me know.

I've now pushed out my own version of the MIME restructuring feature.

It differs from what was presented here in avoiding the code
duplication.

It also provides properly nested mutlipart/* output for the
--format=text case. That's not that I expect anybody to *do* anything
with that nested output, just that it was cleaner and easier to fix both
text/json at the same time, (and avoiding doing that is perhaps what led
to the original code duplication).

I also cherry-picked in a piece of later patch from Jamie so that the
existing emacs tests still pass. And I updated the documentation for
this new feature.

So I'm happy with this new feature now, (which I know provides an
essential part of the basis for the rest of the crypto branch).

MIME restructuring [was: Re: release-candidate/0.6]

[Simon Hürlimann]

lol, made my day!

Simon
On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote:
> On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
>> So a message like this:
>>
>> A???multipart/signed 355339 bytes
>> B ???multipart/mixed 353462 bytes
>> C ???text/plain 235 bytes
>> D ???image/jpeg attachment [foo.jpg] 352752 bytes
>> E ??application/pgp-signature attachment [signature.asc] 1030 bytes
>>
>> would come out with three parts:
>>
>>   1) C
>>   2) D
>>   3) E
>>
>> the new code assigns this message to 5 parts:
>>
>>   1) A
>>   2) B
>>   3) C
>>   4) D
>>   5) E
>
> This message should itself be a comparably complex message, with a tiny
> attached image of a geek with a bike.  Feel free to use this in the test
> suite (the picture and this message are hereby released under the same
> license as notmuch itself).
>
> Note that if the mailing list attaches a footer, the MIME tree will be
> even more delightfully complicated, for added fun and games.
>
>   --dkg
>
>
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins 
 wrote:
> See mml-secure-message-sign-pgpmime to sign an entire message, as
> opposed to just a single part.

Thanks! That's good to know. (Trying here.)

> I think the two paths reconverge later in the series.  Can you look
> ahead a bit to see if that concern is addressed?

Daniel did point me to later in the series where the numbers are at
least the same in text and json output. I've grabbed that state for
generating a test case, (also with Daniels test message). And I'm now
cooking up a new commit that will pass that test but with less code
duplication than the current patch.

-Carl


pgpyr1d2eo38O.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins  wrote:
> See mml-secure-message-sign-pgpmime to sign an entire message, as
> opposed to just a single part.

Thanks! That's good to know. (Trying here.)

> I think the two paths reconverge later in the series.  Can you look
> ahead a bit to see if that concern is addressed?

Daniel did point me to later in the series where the numbers are at
least the same in text and json output. I've grabbed that state for
generating a test case, (also with Daniels test message). And I'm now
cooking up a new commit that will pass that test but with less code
duplication than the current patch.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 05:20 PM, Carl Worth wrote:
> Interestingly, this is not quite the behavior I get (with commit
> 373f352). With --format=text I'm now seeing:
> 
> 2) C
> 3) D
> 4) E

--format=text should only show the parts that are readable in text.

the ultimate goal is to get the part numbers aligned across all --format
choices, regardless of the ability of the format to show the actual nesting.

> So that explains some of my confusion. The behavioral change of this
> commit is really only impacting the json format, and not the text. That
> wasn't clear from the commit message (and I had only been doing my
> testing with the text backend).

It should ultimately affect the numbering in all parts.  There's no way
for the text part to do anything like the nesting that we're doing in
json, though, due to the output format.

> This seems to be justifying my fears about the code duplication---the
> two code paths are already divergent, (which means that things like
> notmuch part-number identifiers cannot be used between the different
> formats). I'd like to fix that by preventing the code duplication.
> 
> Also, both paths seem to be suffering from some excess part-number
> incrementing somewhere.

The confusions you outline were fixed (by me, iirc) somewhere later in
the crypto tree.  I did not want to tamper with dme's crypto branch
directly (though i now suspect that's what i should have done).

i'd give you a commit ID, but i suspect you're sufficiently rebased that
this wouldn't be helpful.

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 

MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
> So a message like this:
> 
> A???multipart/signed 355339 bytes
> B ???multipart/mixed 353462 bytes
> C ???text/plain 235 bytes
> D ???image/jpeg attachment [foo.jpg] 352752 bytes
> E ??application/pgp-signature attachment [signature.asc] 1030 bytes
> 
> would come out with three parts:
> 
>  1) C
>  2) D
>  3) E
> 
> the new code assigns this message to 5 parts:
> 
>  1) A
>  2) B
>  3) C
>  4) D
>  5) E

This message should itself be a comparably complex message, with a tiny
attached image of a geek with a bike.  Feel free to use this in the test
suite (the picture and this message are hereby released under the same
license as notmuch itself).

Note that if the mailing list attaches a footer, the MIME tree will be
even more delightfully complicated, for added fun and games.

--dkg
-- next part --
A non-text attachment was scrubbed...
Name: dkg-tiny.png
Type: image/png
Size: 15893 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 

MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 04:42 PM, Carl Worth wrote:
>   Meanwhile, I still can't tell exactly what the behavioral change
>   intended is. The commit message talks about "fully recursing"
>   and "match[ing] the MIME structure of the message". Was it not
>   fully recursing before? In what way did the output not match the
>   MIME structure before?

before, the output was a linearized version of the mime tree, in
particular removing the multipart pieces and only enumerating the leaves
in a depth-first walk of the tree.

So a message like this:

A???multipart/signed 355339 bytes
B ???multipart/mixed 353462 bytes
C ???text/plain 235 bytes
D ???image/jpeg attachment [foo.jpg] 352752 bytes
E ??application/pgp-signature attachment [signature.asc] 1030 bytes

would come out with three parts:

 1) C
 2) D
 3) E

the new code assigns this message to 5 parts:

 1) A
 2) B
 3) C
 4) D
 5) E

This change is critical to be able to properly delineate which parts of
a message were signed and/or encrypted.

hth,

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Jameson Graef Rollins]

On Mon, 16 May 2011 14:20:07 -0700, Carl Worth  wrote:
> I'll have to learn better how to control the emacs mail composer in
> order to understand how to get signatures to cover attachments if I want
> to do that kind of thing.

See mml-secure-message-sign-pgpmime to sign an entire message, as
opposed to just a single part.

> This seems to be justifying my fears about the code duplication---the
> two code paths are already divergent, (which means that things like
> notmuch part-number identifiers cannot be used between the different
> formats). I'd like to fix that by preventing the code duplication.
> 
> Also, both paths seem to be suffering from some excess part-number
> incrementing somewhere.

I think the two paths reconverge later in the series.  Can you look
ahead a bit to see if that concern is addressed?

jamie.


pgpWdZACwWbe8.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

MIME restructuring [was: Re: release-candidate/0.6]

[Jameson Graef Rollins]

On Mon, 16 May 2011 14:20:07 -0700, Carl Worth  wrote:
> I'll have to learn better how to control the emacs mail composer in
> order to understand how to get signatures to cover attachments if I want
> to do that kind of thing.

See mml-secure-message-sign-pgpmime to sign an entire message, as
opposed to just a single part.

> This seems to be justifying my fears about the code duplication---the
> two code paths are already divergent, (which means that things like
> notmuch part-number identifiers cannot be used between the different
> formats). I'd like to fix that by preventing the code duplication.
> 
> Also, both paths seem to be suffering from some excess part-number
> incrementing somewhere.

I think the two paths reconverge later in the series.  Can you look
ahead a bit to see if that concern is addressed?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 05:20 PM, Carl Worth wrote:
> Interestingly, this is not quite the behavior I get (with commit
> 373f352). With --format=text I'm now seeing:
> 
> 2) C
> 3) D
> 4) E

--format=text should only show the parts that are readable in text.

the ultimate goal is to get the part numbers aligned across all --format
choices, regardless of the ability of the format to show the actual nesting.

> So that explains some of my confusion. The behavioral change of this
> commit is really only impacting the json format, and not the text. That
> wasn't clear from the commit message (and I had only been doing my
> testing with the text backend).

It should ultimately affect the numbering in all parts.  There's no way
for the text part to do anything like the nesting that we're doing in
json, though, due to the output format.

> This seems to be justifying my fears about the code duplication---the
> two code paths are already divergent, (which means that things like
> notmuch part-number identifiers cannot be used between the different
> formats). I'd like to fix that by preventing the code duplication.
> 
> Also, both paths seem to be suffering from some excess part-number
> incrementing somewhere.

The confusions you outline were fixed (by me, iirc) somewhere later in
the crypto tree.  I did not want to tamper with dme's crypto branch
directly (though i now suspect that's what i should have done).

i'd give you a commit ID, but i suspect you're sufficiently rebased that
this wouldn't be helpful.

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Simon Hürlimann]

lol, made my day!

Simon
On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote:

On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:

So a message like this:

A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
E └╴application/pgp-signature attachment [signature.asc] 1030 bytes

would come out with three parts:

  1) C
  2) D
  3) E

the new code assigns this message to 5 parts:

  1) A
  2) B
  3) C
  4) D
  5) E


This message should itself be a comparably complex message, with a tiny
attached image of a geek with a bike.  Feel free to use this in the test
suite (the picture and this message are hereby released under the same
license as notmuch itself).

Note that if the mailing list attaches a footer, the MIME tree will be
even more delightfully complicated, for added fun and games.

--dkg



___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor 
 wrote:
> So a message like this:
> 
> A└┬╴multipart/signed 355339 bytes
> B ├┬╴multipart/mixed 353462 bytes
> C │├╴text/plain 235 bytes
> D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
> E └╴application/pgp-signature attachment [signature.asc] 1030 bytes

I tried creating a message like that but mine came out slightly
differently:

> A└┬╴multipart/mixed
> B ├┬╴multipart/signed
> C │├╴text/plain
> D │└╴application/pgp-signature
> E └╴application/octet-stream

I'll have to learn better how to control the emacs mail composer in
order to understand how to get signatures to cover attachments if I want
to do that kind of thing.

> would come out with three parts:
> 
>  1) C
>  2) D
>  3) E

That is indeed the behavior I see with master (for both text and json
output).

> the new code assigns this message to 5 parts:
> 
>  1) A
>  2) B
>  3) C
>  4) D
>  5) E

Interestingly, this is not quite the behavior I get (with commit
373f352). With --format=text I'm now seeing:

2) C
3) D
4) E

and with --format=json I'm seeing (I think this structure is right):

1) A
  3) B
5) C
7) D
  9) E

So that explains some of my confusion. The behavioral change of this
commit is really only impacting the json format, and not the text. That
wasn't clear from the commit message (and I had only been doing my
testing with the text backend).

This seems to be justifying my fears about the code duplication---the
two code paths are already divergent, (which means that things like
notmuch part-number identifiers cannot be used between the different
formats). I'd like to fix that by preventing the code duplication.

Also, both paths seem to be suffering from some excess part-number
incrementing somewhere.

All of this should be easy to get right with a careful test case or two.

-Carl


pgpi20C4xluPG.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor  wrote:
> So a message like this:
> 
> A???multipart/signed 355339 bytes
> B ???multipart/mixed 353462 bytes
> C ???text/plain 235 bytes
> D ???image/jpeg attachment [foo.jpg] 352752 bytes
> E ??application/pgp-signature attachment [signature.asc] 1030 bytes

I tried creating a message like that but mine came out slightly
differently:

> A???multipart/mixed
> B ???multipart/signed
> C ???text/plain
> D ???application/pgp-signature
> E ??application/octet-stream

I'll have to learn better how to control the emacs mail composer in
order to understand how to get signatures to cover attachments if I want
to do that kind of thing.

> would come out with three parts:
> 
>  1) C
>  2) D
>  3) E

That is indeed the behavior I see with master (for both text and json
output).

> the new code assigns this message to 5 parts:
> 
>  1) A
>  2) B
>  3) C
>  4) D
>  5) E

Interestingly, this is not quite the behavior I get (with commit
373f352). With --format=text I'm now seeing:

2) C
3) D
4) E

and with --format=json I'm seeing (I think this structure is right):

1) A
  3) B
5) C
7) D
  9) E

So that explains some of my confusion. The behavioral change of this
commit is really only impacting the json format, and not the text. That
wasn't clear from the commit message (and I had only been doing my
testing with the text backend).

This seems to be justifying my fears about the code duplication---the
two code paths are already divergent, (which means that things like
notmuch part-number identifiers cannot be used between the different
formats). I'd like to fix that by preventing the code duplication.

Also, both paths seem to be suffering from some excess part-number
incrementing somewhere.

All of this should be easy to get right with a careful test case or two.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
> So a message like this:
> 
> A└┬╴multipart/signed 355339 bytes
> B ├┬╴multipart/mixed 353462 bytes
> C │├╴text/plain 235 bytes
> D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
> E └╴application/pgp-signature attachment [signature.asc] 1030 bytes
> 
> would come out with three parts:
> 
>  1) C
>  2) D
>  3) E
> 
> the new code assigns this message to 5 parts:
> 
>  1) A
>  2) B
>  3) C
>  4) D
>  5) E

This message should itself be a comparably complex message, with a tiny
attached image of a geek with a bike.  Feel free to use this in the test
suite (the picture and this message are hereby released under the same
license as notmuch itself).

Note that if the mailing list attaches a footer, the MIME tree will be
even more delightfully complicated, for added fun and games.

--dkg
<>

signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor 
 wrote:
> before, the output was a linearized version of the mime tree, in
> particular removing the multipart pieces and only enumerating the leaves
> in a depth-first walk of the tree.
> 
> So a message like this:

[snip example of change]

Thanks, Daniel! That does make things much more clear.

So what I'd love to see from here is a commit with a description like
the above, and then a test case looking like your example.

From there, I'd next like a new version of the commit that gets the
intended behavior with less code duplication.

I'll work on each of the above unless someone beats me to any of it. Let
me know.

-Carl


pgpMZOFRqBDEc.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

MIME restructuring [was: Re: release-candidate/0.6]

[Carl Worth]

On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor  wrote:
> before, the output was a linearized version of the mime tree, in
> particular removing the multipart pieces and only enumerating the leaves
> in a depth-first walk of the tree.
> 
> So a message like this:

[snip example of change]

Thanks, Daniel! That does make things much more clear.

So what I'd love to see from here is a commit with a description like
the above, and then a test case looking like your example.

MIME restructuring [was: Re: release-candidate/0.6]

[Daniel Kahn Gillmor]

On 05/16/2011 04:42 PM, Carl Worth wrote:
>   Meanwhile, I still can't tell exactly what the behavioral change
>   intended is. The commit message talks about "fully recursing"
>   and "match[ing] the MIME structure of the message". Was it not
>   fully recursing before? In what way did the output not match the
>   MIME structure before?

before, the output was a linearized version of the mime tree, in
particular removing the multipart pieces and only enumerating the leaves
in a depth-first walk of the tree.

So a message like this:

A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
E └╴application/pgp-signature attachment [signature.asc] 1030 bytes

would come out with three parts:

 1) C
 2) D
 3) E

the new code assigns this message to 5 parts:

 1) A
 2) B
 3) C
 4) D
 5) E

This change is critical to be able to properly delineate which parts of
a message were signed and/or encrypted.

hth,

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Carl Worth]

On Fri, 13 May 2011 01:07:08 -0700, Jameson Graef Rollins 
 wrote:
> Hi, Carl.  I went through dme's multipart patch series and cleaned
> things up.
...
> The result is the new
> 
> release-candidate/0.6+mpmfix

Thanks so much! This looks much better than before.

I'm still hitting some snags quite early in the review process, (I'm
hoping that real soon we'll be able to just start merging like crazy).

Here at the things I've seen so far:

d3e7415d "add argument to part format function to indicate initial part"

This one fails to build due to a simple missing argument, (easy
mistake with the recent splitting of patches).

373f352b "Have output structure fully reflect message MIME structure"

I'm not comfortable with this commit. Previously there was
recursion in one function, (show_message_part), and afterwards
there is duplicated code performing recursion in both
format_part_text and format_part_json.

Similarly, the code adds header formatting code that duplicates
functionality in the existing format_headers_text and
format_headers_json functions.

Meanwhile, I still can't tell exactly what the behavioral change
intended is. The commit message talks about "fully recursing"
and "match[ing] the MIME structure of the message". Was it not
fully recursing before? In what way did the output not match the
MIME structure before?

It would probably be easier to tell what was going on if the
test suite were updated at the same time (or in a subsequent
commit at least). As is, this commit introduces test suite
failures, (re-ordering of MIME part ID numbers and then
emacs-client confusion), which remain until commit 7ee6aaa1

But what does the rest of the series really need from this
commit? Is there some structural change to the json output aside
from the part ID? If so, we're definitely missing a test for
that directly, (other than the indirect testing we get with the
emacs tests).

28ab74e0 "clean up expected emacs output to reflect cleaner from lines 
introduced in 78d6c196d90"

This commit message refers to a stale (now non-existent) commit
ID. I presume it's attempting to reference the commit with a
message of "emacs: Show cleaner `From:' addresses in the summary
line.".

Granted, it's hard to keep commit IDs valid in a branch that's
getting continually rebuilt. One fix is to not use the commit
identifiers. Another help would be to have the test-suite
cleanups occurring more closely after the commits that changed
things.

I'm happy to help work on cleaning up some of these issues if that would
be useful. Let me know.

-Carl


pgpT3nil5FBZU.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Carl Worth]

On Fri, 13 May 2011 01:07:08 -0700, Jameson Graef Rollins  wrote:
> Hi, Carl.  I went through dme's multipart patch series and cleaned
> things up.
...
> The result is the new
> 
> release-candidate/0.6+mpmfix

Thanks so much! This looks much better than before.

I'm still hitting some snags quite early in the review process, (I'm
hoping that real soon we'll be able to just start merging like crazy).

Here at the things I've seen so far:

d3e7415d "add argument to part format function to indicate initial part"

This one fails to build due to a simple missing argument, (easy
mistake with the recent splitting of patches).

373f352b "Have output structure fully reflect message MIME structure"

I'm not comfortable with this commit. Previously there was
recursion in one function, (show_message_part), and afterwards
there is duplicated code performing recursion in both
format_part_text and format_part_json.

Similarly, the code adds header formatting code that duplicates
functionality in the existing format_headers_text and
format_headers_json functions.

Meanwhile, I still can't tell exactly what the behavioral change
intended is. The commit message talks about "fully recursing"
and "match[ing] the MIME structure of the message". Was it not
fully recursing before? In what way did the output not match the
MIME structure before?

It would probably be easier to tell what was going on if the
test suite were updated at the same time (or in a subsequent
commit at least). As is, this commit introduces test suite
failures, (re-ordering of MIME part ID numbers and then
emacs-client confusion), which remain until commit 7ee6aaa1

But what does the rest of the series really need from this
commit? Is there some structural change to the json output aside
from the part ID? If so, we're definitely missing a test for
that directly, (other than the indirect testing we get with the
emacs tests).

28ab74e0 "clean up expected emacs output to reflect cleaner from lines 
introduced in 78d6c196d90"

This commit message refers to a stale (now non-existent) commit
ID. I presume it's attempting to reference the commit with a
message of "emacs: Show cleaner `From:' addresses in the summary
line.".

Granted, it's hard to keep commit IDs valid in a branch that's
getting continually rebuilt. One fix is to not use the commit
identifiers. Another help would be to have the test-suite
cleanups occurring more closely after the commits that changed
things.

I'm happy to help work on cleaning up some of these issues if that would
be useful. Let me know.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110516/7437e239/attachment.pgp>

Re: release-candidate/0.6

[Jameson Graef Rollins]

On Thu, 12 May 2011 15:36:43 -0700, Carl Worth  wrote:
> Does anyone want to attempt to fix up this first patch? (It doesn't
> necessarily have to be David).

Hi, Carl.  I went through dme's multipart patch series and cleaned
things up.  I split up that first commit into a couple of separate ones,
and then combined a couple of patches together and cherry-picked through
the rest of the series to make the overall series a little cleaner.  I
also let out some stuff that was in the originally series
(ie. extraneous json newlines).  I then cherry-picked the entire rest of
the release-candidate/0.6 branch on top of that.  The result is the new

release-candidate/0.6+mpmfix

branch, which I have pushed to my repo.

jamie.[!]

[!] yes, it's been a year!


pgp2rO99CwgpA.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

On Thu, 12 May 2011 15:36:43 -0700, Carl Worth  wrote:
> Does anyone want to attempt to fix up this first patch? (It doesn't
> necessarily have to be David).

Hi, Carl.  I went through dme's multipart patch series and cleaned
things up.  I split up that first commit into a couple of separate ones,
and then combined a couple of patches together and cherry-picked through
the rest of the series to make the overall series a little cleaner.  I
also let out some stuff that was in the originally series
(ie. extraneous json newlines).  I then cherry-picked the entire rest of
the release-candidate/0.6 branch on top of that.  The result is the new

release-candidate/0.6+mpmfix

branch, which I have pushed to my repo.

jamie.[!]

[!] yes, it's been a year!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110513/cd3cbe1b/attachment.pgp>

release-candidate/0.6

[Pieter Praet]

On Thu, 12 May 2011 09:18:48 -0400, Austin Clements  wrote:
> On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
> > The atomicity tests were failing here because I didn't have GDB
> > installed, so I've added it as a prereq.
> 
> Sorry, I've had a patch to address that sitting around, but hadn't
> sent it out (and I only fixed that one test).  I would suggest a
> somewhat gentler approach than "error", though:
> 
> if test_expect_success "prereq: gdb is present" "which gdb"; then
> test_set_prereq GDB
> fi
> 
> (Plus the two test-lib patches I just sent:
> id:1305206080-17461-1-git-send-email-amdragon at mit.edu and
> id:1305206110-17511-1-git-send-email-amdragon at mit.edu).
> 
> "error" has the disadvantage that it doesn't get counted as a failed
> test in the final tally (because, indeed, it's not a failed test) and
> also that it immediately terminates the test script so it's not
> actually using the prereq system (which is fine for the atomicity test
> since all of the test cases depend on GDB, but the pattern I'm
> proposing works for finer-grained prerequisites).  Plus, with the
> above approach, if you don't have a prerequisite, the final tally
> shows one failed test plus some number of skipped tests (and the total
> number of tests never changes), which I would argue is cleaner.

Much obliged for the correction!


Peace


[0] git://github.com/praet/notmuch.git
for-review/test-prereqs-v2
c9a785fc5c48db13

-- 
Pieter

Re: release-candidate/0.6

[Carl Worth]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
 wrote:
> Hi, folks.  As some of you already know, I am trying to put together a
> release candidate for a 0.6 release that we can present to cworth for
> approval.

Hi Jameson,

This is really great! I appreciate you collecting useful patches for
review like this. I hope this helps us get things moving once again.

> So far, this release candidate includes a couple of patch series that
> are not currently on cworth's master branch:
> 
> json structure now replicates mime structure
> * dme's json-fully-reflects-MIME-structure improvements

I got stalled on the first commit on this branch:

commit 5a5aae66bf41d3c621c412da711fec9b33f37dcc
Author: David Edmondson 
Date:   Mon May 10 10:25:15 2010 +0100

Improved MIME support.

Signed-off-by: Jameson Rollins 

It's probably the same issue that stalled me when David first sent this
patch series for review over a year ago[!]. I'm guessing I didn't do a
good job of stating the issue then, so I'll try to do a better job here.

This first patch appears to be doing multiple things:

   * It changes how the emacs code inserts MIME parts when constructing
 a mail view.

   * It changes something in the json formatting. (Just extra newlines?)

   * It changes something about the MIME part counting.

   * It appears to be doing new emission of multipart part when doing
 json output, (and for this has some hard-coded printf("]}\n") stuff
 rather than using the formatter).

   * It has new explicit support for an embedded Message as a MIME part,
 (inserting the headers of the enclosed message).

So that's five seemingly independent changes. I'd really like to see
those split up into separate commits as much as possible. Or, excepting
that, there should be some explanation/justification in the commit
message for why some must be combined.

The worst part is that not a single change is actually described in the
commit message. All we have is "Improved MIME support". Improved how?
What changed? Why? What impact does it have? Does it fix bugs? Lay
groundwork for future changes?

What's really changing here and why?

If the patch series were sufficiently-well described in the commit
message, then my review process could be more or less:

  * Read the commit message. Does it describe a desirable change?

  * If so, read the patch content. Does it do what the commit message
describes? Accurately? Without doing unrelated things?

  * If so, accept the patch.

Does anyone want to attempt to fix up this first patch? (It doesn't
necessarily have to be David).

From a quick skim, many later patches in the series appear to be better
in this regard.

-Carl

[!] Has it really been that long?


pgphILpQnBAAa.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Carl Worth]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
> Hi, folks.  As some of you already know, I am trying to put together a
> release candidate for a 0.6 release that we can present to cworth for
> approval.

Hi Jameson,

This is really great! I appreciate you collecting useful patches for
review like this. I hope this helps us get things moving once again.

> So far, this release candidate includes a couple of patch series that
> are not currently on cworth's master branch:
> 
> json structure now replicates mime structure
> * dme's json-fully-reflects-MIME-structure improvements

I got stalled on the first commit on this branch:

commit 5a5aae66bf41d3c621c412da711fec9b33f37dcc
Author: David Edmondson 
Date:   Mon May 10 10:25:15 2010 +0100

Improved MIME support.

Signed-off-by: Jameson Rollins 

It's probably the same issue that stalled me when David first sent this
patch series for review over a year ago[!]. I'm guessing I didn't do a
good job of stating the issue then, so I'll try to do a better job here.

This first patch appears to be doing multiple things:

   * It changes how the emacs code inserts MIME parts when constructing
 a mail view.

   * It changes something in the json formatting. (Just extra newlines?)

   * It changes something about the MIME part counting.

   * It appears to be doing new emission of multipart part when doing
 json output, (and for this has some hard-coded printf("]}\n") stuff
 rather than using the formatter).

   * It has new explicit support for an embedded Message as a MIME part,
 (inserting the headers of the enclosed message).

So that's five seemingly independent changes. I'd really like to see
those split up into separate commits as much as possible. Or, excepting
that, there should be some explanation/justification in the commit
message for why some must be combined.

The worst part is that not a single change is actually described in the
commit message. All we have is "Improved MIME support". Improved how?
What changed? Why? What impact does it have? Does it fix bugs? Lay
groundwork for future changes?

What's really changing here and why?

If the patch series were sufficiently-well described in the commit
message, then my review process could be more or less:

  * Read the commit message. Does it describe a desirable change?

  * If so, read the patch content. Does it do what the commit message
describes? Accurately? Without doing unrelated things?

  * If so, accept the patch.

Does anyone want to attempt to fix up this first patch? (It doesn't
necessarily have to be David).

release-candidate/0.6

[Pieter Praet]

On Tue, 10 May 2011 09:42:39 -0700, Jameson Graef Rollins  wrote:
> Arg.  One last bit of churn.
> 
> dkg found a bug in the new sanitize_string function that was causing
> segfaults on messages with empty headers.  This is obviously an imprtant
> thing to fix.
> 
> After chatting with some folks on #notmuch, we decided that the debian
> build dependency on libgmime 2.4.24 is a bit too extreme, particularly
> since it will actually prevent the package from being uploaded to
> debian.  I therefore rolled-back the stricter build dependency.
> 
> A new version of release-candidate/0.6 is pushed.

The atomicity tests were failing here because I didn't have GDB
installed, so I've added it as a prereq.

While I was at it, I "fixed" the crypto and emacs tests as well.

> jamie.
> 
> [0] git://finestructure.net/notmuch
> release-candidate/0.6
> aac1936bc9f878bd9ad2e097c5a686e146b73143
Non-text part: application/pgp-signature
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace


[0] git://github.com/praet/notmuch.git
for-review/test-prereqs
a845ca793873b6ab637a

-- 
Pieter

release-candidate/0.6

[Austin Clements]

Nifty.  I was afraid to go romping through all of the other test
dependencies; I'm glad somebody wasn't.  ]:--8)

It should be noted that these patches depend on
id:1305206110-17511-1-git-send-email-amdragon at mit.edu for correctness
and id:1305206080-17461-1-git-send-email-amdragon at mit.edu for sanity.

Given that these patches aren't specifically 0.6-related and that it's
good practice to send patches to the list, perhaps you could git
send-email these patches as a new thread to the list?

On Thu, May 12, 2011 at 10:09 AM, Pieter Praet  wrote:
> On Thu, 12 May 2011 09:18:48 -0400, Austin Clements  
> wrote:
>> On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
>> > The atomicity tests were failing here because I didn't have GDB
>> > installed, so I've added it as a prereq.
>>
>> Sorry, I've had a patch to address that sitting around, but hadn't
>> sent it out (and I only fixed that one test). ?I would suggest a
>> somewhat gentler approach than "error", though:
>>
>> if test_expect_success "prereq: gdb is present" "which gdb"; then
>> ? ? test_set_prereq GDB
>> fi
>>
>> (Plus the two test-lib patches I just sent:
>> id:1305206080-17461-1-git-send-email-amdragon at mit.edu and
>> id:1305206110-17511-1-git-send-email-amdragon at mit.edu).
>>
>> "error" has the disadvantage that it doesn't get counted as a failed
>> test in the final tally (because, indeed, it's not a failed test) and
>> also that it immediately terminates the test script so it's not
>> actually using the prereq system (which is fine for the atomicity test
>> since all of the test cases depend on GDB, but the pattern I'm
>> proposing works for finer-grained prerequisites). ?Plus, with the
>> above approach, if you don't have a prerequisite, the final tally
>> shows one failed test plus some number of skipped tests (and the total
>> number of tests never changes), which I would argue is cleaner.
>
> Much obliged for the correction!
>
>
> Peace
>
>
> [0] git://github.com/praet/notmuch.git
> ? ?for-review/test-prereqs-v2
> ? ?c9a785fc5c48db13
>
> --
> Pieter
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>

Re: release-candidate/0.6

[Austin Clements]

Nifty.  I was afraid to go romping through all of the other test
dependencies; I'm glad somebody wasn't.  ]:--8)

It should be noted that these patches depend on
id:1305206110-17511-1-git-send-email-amdra...@mit.edu for correctness
and id:1305206080-17461-1-git-send-email-amdra...@mit.edu for sanity.

Given that these patches aren't specifically 0.6-related and that it's
good practice to send patches to the list, perhaps you could git
send-email these patches as a new thread to the list?

On Thu, May 12, 2011 at 10:09 AM, Pieter Praet  wrote:
> On Thu, 12 May 2011 09:18:48 -0400, Austin Clements  wrote:
>> On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
>> > The atomicity tests were failing here because I didn't have GDB
>> > installed, so I've added it as a prereq.
>>
>> Sorry, I've had a patch to address that sitting around, but hadn't
>> sent it out (and I only fixed that one test).  I would suggest a
>> somewhat gentler approach than "error", though:
>>
>> if test_expect_success "prereq: gdb is present" "which gdb"; then
>>     test_set_prereq GDB
>> fi
>>
>> (Plus the two test-lib patches I just sent:
>> id:1305206080-17461-1-git-send-email-amdra...@mit.edu and
>> id:1305206110-17511-1-git-send-email-amdra...@mit.edu).
>>
>> "error" has the disadvantage that it doesn't get counted as a failed
>> test in the final tally (because, indeed, it's not a failed test) and
>> also that it immediately terminates the test script so it's not
>> actually using the prereq system (which is fine for the atomicity test
>> since all of the test cases depend on GDB, but the pattern I'm
>> proposing works for finer-grained prerequisites).  Plus, with the
>> above approach, if you don't have a prerequisite, the final tally
>> shows one failed test plus some number of skipped tests (and the total
>> number of tests never changes), which I would argue is cleaner.
>
> Much obliged for the correction!
>
>
> Peace
>
>
> [0] git://github.com/praet/notmuch.git
>    for-review/test-prereqs-v2
>    c9a785fc5c48db13
>
> --
> Pieter
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Austin Clements]

On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
> The atomicity tests were failing here because I didn't have GDB
> installed, so I've added it as a prereq.

Sorry, I've had a patch to address that sitting around, but hadn't
sent it out (and I only fixed that one test).  I would suggest a
somewhat gentler approach than "error", though:

if test_expect_success "prereq: gdb is present" "which gdb"; then
test_set_prereq GDB
fi

(Plus the two test-lib patches I just sent:
id:1305206080-17461-1-git-send-email-amdragon at mit.edu and
id:1305206110-17511-1-git-send-email-amdragon at mit.edu).

"error" has the disadvantage that it doesn't get counted as a failed
test in the final tally (because, indeed, it's not a failed test) and
also that it immediately terminates the test script so it's not
actually using the prereq system (which is fine for the atomicity test
since all of the test cases depend on GDB, but the pattern I'm
proposing works for finer-grained prerequisites).  Plus, with the
above approach, if you don't have a prerequisite, the final tally
shows one failed test plus some number of skipped tests (and the total
number of tests never changes), which I would argue is cleaner.

Re: release-candidate/0.6

[Pieter Praet]

On Thu, 12 May 2011 09:18:48 -0400, Austin Clements  wrote:
> On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
> > The atomicity tests were failing here because I didn't have GDB
> > installed, so I've added it as a prereq.
> 
> Sorry, I've had a patch to address that sitting around, but hadn't
> sent it out (and I only fixed that one test).  I would suggest a
> somewhat gentler approach than "error", though:
> 
> if test_expect_success "prereq: gdb is present" "which gdb"; then
> test_set_prereq GDB
> fi
> 
> (Plus the two test-lib patches I just sent:
> id:1305206080-17461-1-git-send-email-amdra...@mit.edu and
> id:1305206110-17511-1-git-send-email-amdra...@mit.edu).
> 
> "error" has the disadvantage that it doesn't get counted as a failed
> test in the final tally (because, indeed, it's not a failed test) and
> also that it immediately terminates the test script so it's not
> actually using the prereq system (which is fine for the atomicity test
> since all of the test cases depend on GDB, but the pattern I'm
> proposing works for finer-grained prerequisites).  Plus, with the
> above approach, if you don't have a prerequisite, the final tally
> shows one failed test plus some number of skipped tests (and the total
> number of tests never changes), which I would argue is cleaner.

Much obliged for the correction!


Peace


[0] git://github.com/praet/notmuch.git
for-review/test-prereqs-v2
c9a785fc5c48db13

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Austin Clements]

On Thu, May 12, 2011 at 8:22 AM, Pieter Praet  wrote:
> The atomicity tests were failing here because I didn't have GDB
> installed, so I've added it as a prereq.

Sorry, I've had a patch to address that sitting around, but hadn't
sent it out (and I only fixed that one test).  I would suggest a
somewhat gentler approach than "error", though:

if test_expect_success "prereq: gdb is present" "which gdb"; then
test_set_prereq GDB
fi

(Plus the two test-lib patches I just sent:
id:1305206080-17461-1-git-send-email-amdra...@mit.edu and
id:1305206110-17511-1-git-send-email-amdra...@mit.edu).

"error" has the disadvantage that it doesn't get counted as a failed
test in the final tally (because, indeed, it's not a failed test) and
also that it immediately terminates the test script so it's not
actually using the prereq system (which is fine for the atomicity test
since all of the test cases depend on GDB, but the pattern I'm
proposing works for finer-grained prerequisites).  Plus, with the
above approach, if you don't have a prerequisite, the final tally
shows one failed test plus some number of skipped tests (and the total
number of tests never changes), which I would argue is cleaner.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Pieter Praet]

On Tue, 10 May 2011 09:42:39 -0700, Jameson Graef Rollins 
 wrote:
> Arg.  One last bit of churn.
> 
> dkg found a bug in the new sanitize_string function that was causing
> segfaults on messages with empty headers.  This is obviously an imprtant
> thing to fix.
> 
> After chatting with some folks on #notmuch, we decided that the debian
> build dependency on libgmime 2.4.24 is a bit too extreme, particularly
> since it will actually prevent the package from being uploaded to
> debian.  I therefore rolled-back the stricter build dependency.
> 
> A new version of release-candidate/0.6 is pushed.

The atomicity tests were failing here because I didn't have GDB
installed, so I've added it as a prereq.

While I was at it, I "fixed" the crypto and emacs tests as well.

> jamie.
> 
> [0] git://finestructure.net/notmuch
> release-candidate/0.6
> aac1936bc9f878bd9ad2e097c5a686e146b73143
Non-text part: application/pgp-signature
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace


[0] git://github.com/praet/notmuch.git
for-review/test-prereqs
a845ca793873b6ab637a

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Jameson Graef Rollins]

Arg.  One last bit of churn.

dkg found a bug in the new sanitize_string function that was causing
segfaults on messages with empty headers.  This is obviously an imprtant
thing to fix.

After chatting with some folks on #notmuch, we decided that the debian
build dependency on libgmime 2.4.24 is a bit too extreme, particularly
since it will actually prevent the package from being uploaded to
debian.  I therefore rolled-back the stricter build dependency.

A new version of release-candidate/0.6 is pushed.

jamie.

[0] git://finestructure.net/notmuch
release-candidate/0.6
aac1936bc9f878bd9ad2e097c5a686e146b73143


pgpIu7RYvVVfx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

Arg.  One last bit of churn.

dkg found a bug in the new sanitize_string function that was causing
segfaults on messages with empty headers.  This is obviously an imprtant
thing to fix.

After chatting with some folks on #notmuch, we decided that the debian
build dependency on libgmime 2.4.24 is a bit too extreme, particularly
since it will actually prevent the package from being uploaded to
debian.  I therefore rolled-back the stricter build dependency.

A new version of release-candidate/0.6 is pushed.

jamie.

[0] git://finestructure.net/notmuch
release-candidate/0.6
aac1936bc9f878bd9ad2e097c5a686e146b73143
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110510/d2eb6b6a/attachment.pgp>

Re: release-candidate/0.6

[Jameson Graef Rollins]

On Mon, 09 May 2011 10:20:18 -0700, Jameson Graef Rollins 
 wrote:
> ***I hereby declare that release-candidate/0.6 is ready for release.***

After all of that pomp, I take it all back!

Fully fearful of further delaying release of 0.6, I decided I wanted to
slip in a couple last-minute patches, most of which are really bug
fixes:

I told Felipe I would include his vim patches, so I wanted to follow
through on that.

Dmitry submitted a patch to fix sporadic seg faults in one of the emacs
tests.

I built release-candidate/0.6 against the Ubuntu package of
libgmime-2.4-dev, version 2.4.24-0ubuntu1 [0].  This fixed all but one
of the failing crypto tests, and the delinquent test only needed to be
updated to expect libgmime's improved error reporting.  This means that
all 184 tests now consistently cleanly pass (after 100 runs).  This
persuaded me to decide that 0.6 really should depend on this newly
released 2.4.24 version of libgmime-2.4-2, and I updated the debian
packaging accordingly.

If people think this is not the way to go, I'm open to arguments.  I
think this /will/ create a bit of a snag for debian users.  libgmime's
dependency is not currently available in debian, so declaring notmuch
0.6 dependent on libgmime-2.4-2 2.4.24 will render the debian package of
0.6 uninstallable (and maybe even unbuildable).  But I'm hoping we can
use this to convince the debian maintainer of libgmime to release 2.4.24
concurrently with notmuch 0.6.  If this sounds ridiculous, please let me
know and we can look at a different solutions.

Again, sorry for the last minute churn, but I think it's worth it [1].

jamie.

[0] https://launchpad.net/ubuntu/+source/gmime2.4/2.4.24-0ubuntu1/
[1] git://finestructure.net/notmuch
release-candidate/0.6
f357eafd3c315c7b59abe3088479a3b4e68a4d11


pgpvwK5Y1KdPA.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

On Mon, 09 May 2011 10:20:18 -0700, Jameson Graef Rollins  wrote:
> ***I hereby declare that release-candidate/0.6 is ready for release.***

After all of that pomp, I take it all back!

Fully fearful of further delaying release of 0.6, I decided I wanted to
slip in a couple last-minute patches, most of which are really bug
fixes:

I told Felipe I would include his vim patches, so I wanted to follow
through on that.

Dmitry submitted a patch to fix sporadic seg faults in one of the emacs
tests.

I built release-candidate/0.6 against the Ubuntu package of
libgmime-2.4-dev, version 2.4.24-0ubuntu1 [0].  This fixed all but one
of the failing crypto tests, and the delinquent test only needed to be
updated to expect libgmime's improved error reporting.  This means that
all 184 tests now consistently cleanly pass (after 100 runs).  This
persuaded me to decide that 0.6 really should depend on this newly
released 2.4.24 version of libgmime-2.4-2, and I updated the debian
packaging accordingly.

If people think this is not the way to go, I'm open to arguments.  I
think this /will/ create a bit of a snag for debian users.  libgmime's
dependency is not currently available in debian, so declaring notmuch
0.6 dependent on libgmime-2.4-2 2.4.24 will render the debian package of
0.6 uninstallable (and maybe even unbuildable).  But I'm hoping we can
use this to convince the debian maintainer of libgmime to release 2.4.24
concurrently with notmuch 0.6.  If this sounds ridiculous, please let me
know and we can look at a different solutions.

Again, sorry for the last minute churn, but I think it's worth it [1].

jamie.

[0] https://launchpad.net/ubuntu/+source/gmime2.4/2.4.24-0ubuntu1/
[1] git://finestructure.net/notmuch
release-candidate/0.6
f357eafd3c315c7b59abe3088479a3b4e68a4d11
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110510/da69a3e9/attachment.pgp>

release-candidate/0.6

[James Vasile]

On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins  wrote:
> On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
> wrote:
> > I sent two patches to the list on March 16.  They were a bug fix to
> > allow notmuch to correctly handle some poorly formatted email.  Nobody
> > ever replied, but I'd like to see the bug fixed nonetheless, as it
> > results in unreadable mail.  Since I've actually seen such mail in the
> > wild, I'd like to see Notmuch handle it.
> 
> Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
> notmuch search, which I think is the issue that you're patches were also
> dealing with.  Florian's patch has be pushed to my
> release-candidate/0.6.  Can you see if your issue is fixed there?  If
> not maybe you could try submitting a new patch that would apply to the
> release-candidate/0.6 head.
> 
> Thanks.

I'll take a look at it this week.  Thanks much.

release-candidate/0.6

[micah anderson]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
>
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

micah
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/a99fc56d/attachment.pgp>

Re: release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  I have pushed a couple of more patches to
release-candidate/0.6 [0]:

* Dmitry's fix for emacs fcc
* Anton Khirnov's memleak fixes

I think that everything else can wait for later releases.

***I hereby declare that release-candidate/0.6 is ready for release.***

I think the only remaining release tasks would be to update the NEWS
file, and then possibly debian/changelog if we want to expand the 0.6
entries a bit.

Carl: what do you think?  Are you willing to push this out as a new
release?  Please let me know if there's anything else I/we can do to
facilitate that.  Thanks!

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6
(commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db)


pgpcOqsSsvVSz.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  I have pushed a couple of more patches to
release-candidate/0.6 [0]:

* Dmitry's fix for emacs fcc
* Anton Khirnov's memleak fixes

I think that everything else can wait for later releases.

***I hereby declare that release-candidate/0.6 is ready for release.***

I think the only remaining release tasks would be to update the NEWS
file, and then possibly debian/changelog if we want to expand the 0.6
entries a bit.

Carl: what do you think?  Are you willing to push this out as a new
release?  Please let me know if there's anything else I/we can do to
facilitate that.  Thanks!

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6
(commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/e2a6e77d/attachment.pgp>

Re: release-candidate/0.6

[James Vasile]

On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins 
 wrote:
> On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
> wrote:
> > I sent two patches to the list on March 16.  They were a bug fix to
> > allow notmuch to correctly handle some poorly formatted email.  Nobody
> > ever replied, but I'd like to see the bug fixed nonetheless, as it
> > results in unreadable mail.  Since I've actually seen such mail in the
> > wild, I'd like to see Notmuch handle it.
> 
> Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
> notmuch search, which I think is the issue that you're patches were also
> dealing with.  Florian's patch has be pushed to my
> release-candidate/0.6.  Can you see if your issue is fixed there?  If
> not maybe you could try submitting a new patch that would apply to the
> release-candidate/0.6 head.
> 
> Thanks.

I'll take a look at it this week.  Thanks much.

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[micah anderson]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
 wrote:
>
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

micah


pgp79r76nep6I.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Florian Friesdorf]

On Sat, 07 May 2011 01:51:25 +0200, Florian Friesdorf  
wrote:
> (..)
> An open issue (also with gmime 2.4.24) is the extraction of a PDF from
> an encrypted message via emacs (discussed on irc before, mentioned here
> for completeness of the 

In the current release candidate this got fixed by Jamie.

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

release-candidate/0.6

[Daniel Kahn Gillmor]

On 05/08/2011 09:03 PM, Jameson Graef Rollins wrote:
> Hi, folks.  I've pushed some more patches to the release-candidate/0.6
> branch [0] (which should now be at commit id
> 89ca01b6104dd732903104e50777a7b4a211e1f4):
> 
> * support for decryption of parts with notmuch show --format=part
> * emacs support for retrieving parts (like attachments) from encrypted
>   messages
> * Dmitry Kurochkin's patch to include filenames for inline attachments
> * Andreas Amann and Florian's patch for sanitizing search text output
> * various other cleanups

I'm running this now.  It's great.  Thank you, Jamie!

One new feature that you didn't mention is that --decrypt is passed
through to notmuch reply based on the state of the current buffer.

That is: it used to be that you had to remember whether you'd viewed a
thread with M-RET or RET (to trigger decryption+verification) and adjust
your reply invocation to match if you wanted proper quoting and
attribution when replying to encrypted mail.

Now it Just Works?.  Excellent Work.

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110508/c8722d51/attachment.pgp>

Re: release-candidate/0.6

[Jameson Graef Rollins]

On Sun, 08 May 2011 21:24:52 -0400, Daniel Kahn Gillmor 
 wrote:
> One new feature that you didn't mention is that --decrypt is passed
> through to notmuch reply based on the state of the current buffer.
> 
> That is: it used to be that you had to remember whether you'd viewed a
> thread with M-RET or RET (to trigger decryption+verification) and adjust
> your reply invocation to match if you wanted proper quoting and
> attribution when replying to encrypted mail.

Thanks for point that out, dkg.  I did forget to mention that.

Now we just need to figure out how to auto-encrypt replies to encrypted
messages...

jamie.


pgpHIViE8shSH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

On Sun, 08 May 2011 21:24:52 -0400, Daniel Kahn Gillmor  wrote:
> One new feature that you didn't mention is that --decrypt is passed
> through to notmuch reply based on the state of the current buffer.
> 
> That is: it used to be that you had to remember whether you'd viewed a
> thread with M-RET or RET (to trigger decryption+verification) and adjust
> your reply invocation to match if you wanted proper quoting and
> attribution when replying to encrypted mail.

Thanks for point that out, dkg.  I did forget to mention that.

Now we just need to figure out how to auto-encrypt replies to encrypted
messages...

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: release-candidate/0.6

[Daniel Kahn Gillmor]

On 05/08/2011 09:03 PM, Jameson Graef Rollins wrote:
> Hi, folks.  I've pushed some more patches to the release-candidate/0.6
> branch [0] (which should now be at commit id
> 89ca01b6104dd732903104e50777a7b4a211e1f4):
> 
> * support for decryption of parts with notmuch show --format=part
> * emacs support for retrieving parts (like attachments) from encrypted
>   messages
> * Dmitry Kurochkin's patch to include filenames for inline attachments
> * Andreas Amann and Florian's patch for sanitizing search text output
> * various other cleanups

I'm running this now.  It's great.  Thank you, Jamie!

One new feature that you didn't mention is that --decrypt is passed
through to notmuch reply based on the state of the current buffer.

That is: it used to be that you had to remember whether you'd viewed a
thread with M-RET or RET (to trigger decryption+verification) and adjust
your reply invocation to match if you wanted proper quoting and
attribution when replying to encrypted mail.

Now it Just Works™.  Excellent Work.

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  I've pushed some more patches to the release-candidate/0.6
branch [0] (which should now be at commit id
89ca01b6104dd732903104e50777a7b4a211e1f4):

* support for decryption of parts with notmuch show --format=part
* emacs support for retrieving parts (like attachments) from encrypted
  messages
* Dmitry Kurochkin's patch to include filenames for inline attachments
* Andreas Amann and Florian's patch for sanitizing search text output
* various other cleanups

Dmitry Kurochkin have also asked for some patches to be applied dealing
with fcc paths.  I haven't dealt with that yet, since it doesn't apply
cleanly against the branch head and the patch is too large for me to
resolve easily.  If someone ones to take a crack at fixing those issues
up for the next release that would be great.

Please keep using the head of this branch, and report any issues, and
hopefully we'll be able to push it out soon.

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6


pgpcqw1syIAmQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  I've pushed some more patches to the release-candidate/0.6
branch [0] (which should now be at commit id
89ca01b6104dd732903104e50777a7b4a211e1f4):

* support for decryption of parts with notmuch show --format=part
* emacs support for retrieving parts (like attachments) from encrypted
  messages
* Dmitry Kurochkin's patch to include filenames for inline attachments
* Andreas Amann and Florian's patch for sanitizing search text output
* various other cleanups

Dmitry Kurochkin have also asked for some patches to be applied dealing
with fcc paths.  I haven't dealt with that yet, since it doesn't apply
cleanly against the branch head and the patch is too large for me to
resolve easily.  If someone ones to take a crack at fixing those issues
up for the next release that would be great.

Please keep using the head of this branch, and report any issues, and
hopefully we'll be able to push it out soon.

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110508/0154722e/attachment-0001.pgp>

Re: release-candidate/0.6

[Jameson Graef Rollins]

On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
wrote:
> I sent two patches to the list on March 16.  They were a bug fix to
> allow notmuch to correctly handle some poorly formatted email.  Nobody
> ever replied, but I'd like to see the bug fixed nonetheless, as it
> results in unreadable mail.  Since I've actually seen such mail in the
> wild, I'd like to see Notmuch handle it.

Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
notmuch search, which I think is the issue that you're patches were also
dealing with.  Florian's patch has be pushed to my
release-candidate/0.6.  Can you see if your issue is fixed there?  If
not maybe you could try submitting a new patch that would apply to the
release-candidate/0.6 head.

Thanks.

jamie.


pgpqYXFj9fIal.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
wrote:
> I sent two patches to the list on March 16.  They were a bug fix to
> allow notmuch to correctly handle some poorly formatted email.  Nobody
> ever replied, but I'd like to see the bug fixed nonetheless, as it
> results in unreadable mail.  Since I've actually seen such mail in the
> wild, I'd like to see Notmuch handle it.

Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
notmuch search, which I think is the issue that you're patches were also
dealing with.  Florian's patch has be pushed to my
release-candidate/0.6.  Can you see if your issue is fixed there?  If
not maybe you could try submitting a new patch that would apply to the
release-candidate/0.6 head.

Thanks.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110508/d131916c/attachment.pgp>

Re: release-candidate/0.6

[Florian Friesdorf]

On Sat, 07 May 2011 01:51:25 +0200, Florian Friesdorf  wrote:
> (..)
> An open issue (also with gmime 2.4.24) is the extraction of a PDF from
> an encrypted message via emacs (discussed on irc before, mentioned here
> for completeness of the 

In the current release candidate this got fixed by Jamie.

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC


pgpTTNLEBFVIg.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Jameson Graef Rollins]

On Fri, 6 May 2011 22:31:09 -0400, Tim Gray  wrote:
> Ditto with the very very simple patch I sent about OS X compiling.  I 
> take it there are few users of OS X on this list, so every little bit 
> could help.

Hi, Tim.  Have you tried compiling the release-candidate/0.6 on OS X
without this patch?  I fixed an issue with the library linking that
could have also been the source of the issue you're seeing.

If release-candidate/0.6 still requires your patch to build, if you
could rebase your patch against the head of release-candidate/0.6 I'll
look at applying it again (it wasn't applying cleanly against the
current head of that branch).

Thanks.

jamie.


pgpBPMlBt8flX.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

On Fri, 6 May 2011 22:31:09 -0400, Tim Gray  wrote:
> Ditto with the very very simple patch I sent about OS X compiling.  I 
> take it there are few users of OS X on this list, so every little bit 
> could help.

Hi, Tim.  Have you tried compiling the release-candidate/0.6 on OS X
without this patch?  I fixed an issue with the library linking that
could have also been the source of the issue you're seeing.

If release-candidate/0.6 still requires your patch to build, if you
could rebase your patch against the head of release-candidate/0.6 I'll
look at applying it again (it wasn't applying cleanly against the
current head of that branch).

Thanks.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110508/9c5d7417/attachment.pgp>

release-candidate/0.6

[Dmitry Kurochkin]

Hi Jameson.

First of all, thank you for your effort on notmuch.  It is a great
project and I am happy to see it going forward (again)!

Can we include FCC fix in the 0.6 please?  It was broken in 0.5 (IIRC)
because of old configuration check.  There are two patches on the ML to
address it.  The first one is from Carl
id:"1290632444-10046-1-git-send-email-cworth at cworth.org" where the check
is just commented out.  Another one is a proper fix from David
id:"1290682750-30283-2-git-send-email-dme at dme.org".  It is part of a
patch series that adds some ERT (Emacs Lisp Regression Testing) support.
I see few options: apply a "fix" from Carl, apply ERT patch series from
David, or factor out the proper fix from David's series and apply it
separately.  Not sure what is the best.  Perhaps David can comment about
the ERT stuff.  I am fine with any option, just do not leave it as is,
i.e. broken.  I am ready to help with the factoring out the proper fix,
if all agree it is the best solution and no one (David?) volunteers for
it.

Thank you,
  Dmitry

Re: release-candidate/0.6

[Dmitry Kurochkin]

Hi Jameson.

First of all, thank you for your effort on notmuch.  It is a great
project and I am happy to see it going forward (again)!

Can we include FCC fix in the 0.6 please?  It was broken in 0.5 (IIRC)
because of old configuration check.  There are two patches on the ML to
address it.  The first one is from Carl
id:"1290632444-10046-1-git-send-email-cwo...@cworth.org" where the check
is just commented out.  Another one is a proper fix from David
id:"1290682750-30283-2-git-send-email-...@dme.org".  It is part of a
patch series that adds some ERT (Emacs Lisp Regression Testing) support.
I see few options: apply a "fix" from Carl, apply ERT patch series from
David, or factor out the proper fix from David's series and apply it
separately.  Not sure what is the best.  Perhaps David can comment about
the ERT stuff.  I am fine with any option, just do not leave it as is,
i.e. broken.  I am ready to help with the factoring out the proper fix,
if all agree it is the best solution and no one (David?) volunteers for
it.

Thank you,
  Dmitry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Darren McGuicken]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
> However, the current version of libgmime-2.4 in testing and unstable
> (2.4.23-1) unfortunately breaks signature verification, which means
> that many of the crypto tests will fail.  The issue has been fixed
> upstream, and we've been pushing on the libgmime maintainer to push a
> new release.  Hopefully a release of notmuch 0.6 into debian will put
> extra pressure on getting this issue resolved.

Another +1.  RC continues to work well (I've been running the crypto
branch since its creation), and I'm now using it with gmime-2.4.24.  No
issues with signature verification that I can see, including viewing
threads previously borked under gmime-2.4.14.

Thanks for this!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: release-candidate/0.6

[Darren McGuicken]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
 wrote:
> However, the current version of libgmime-2.4 in testing and unstable
> (2.4.23-1) unfortunately breaks signature verification, which means
> that many of the crypto tests will fail.  The issue has been fixed
> upstream, and we've been pushing on the libgmime maintainer to push a
> new release.  Hopefully a release of notmuch 0.6 into debian will put
> extra pressure on getting this issue resolved.

Another +1.  RC continues to work well (I've been running the crypto
branch since its creation), and I'm now using it with gmime-2.4.24.  No
issues with signature verification that I can see, including viewing
threads previously borked under gmime-2.4.14.

Thanks for this!


pgpqC6Xa8An9B.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Florian Friesdorf]

On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
wrote:
> Thanks for pulling this together.
> 
> I sent two patches to the list on March 16.  They were a bug fix to
> allow notmuch to correctly handle some poorly formatted email.  Nobody
> ever replied, but I'd like to see the bug fixed nonetheless, as it
> results in unreadable mail.  Since I've actually seen such mail in the
> wild, I'd like to see Notmuch handle it.
> 
> Those messages were:
> 
> Message-ID: <87ipvifrlv.fsf at softwarefreedom.org>
> Message-ID: <87fwqmfr2x.fsf at softwarefreedom.org>

The first seems to be damaged, the second I did not try:

~/dev/notmuch]$ cat $(notmuch search --output=files id:87ipvifrlv.fsf at 
softwarefreedom.org) |patch -p1
patching file lib/thread.cc
Hunk #1 FAILED at 266.
patch:  malformed patch at line 153: hread,

But it sounds like a different approach to:
id:8739ljwy7z.fsf at msstf091.ucc.ie,
id:1304723846-29134-1-git-send-email-flo at chaoflow.net

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

release-candidate/0.6

[Florian Friesdorf]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
> Hi, folks.  As some of you already know, I am trying to put together a
> release candidate for a 0.6 release that we can present to cworth for
> approval.  This branch can be found in my public notmuch repository in
> the "release-candidate/0.6" branch:
> 
> git remote add jrollins git://finestructure.net/notmuch
> git remote update
> git checkout -t -b release-candidate/0.6 jrollins/release-candidate/0.6
> 
> So far, this release candidate includes a couple of patch series that
> are not currently on cworth's master branch:
> 
> json structure now replicates mime structure
> * dme's json-fully-reflects-MIME-structure improvements
> * dkg/jrollins's PGP/MIME cryptographic support
> * amdragon's atomicity improvements
> * a couple other small improvements

I'm delighted! 

> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I did already run this combination for quite a while with general
satisfaction.

Problems in emacs (i.e. the json format) with displaying certain mime
messages are solved by using gmime 2.4.24 (thx dkg for the debugging
support). Problems were: notmuch show consuming 100% CPU without a result
and "EOF while reading message".

An open issue (also with gmime 2.4.24) is the extraction of a PDF from
an encrypted message via emacs (discussed on irc before, mentioned here
for completeness of the archive).

> PS: note to Debian users:
> 
> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch
> 
> However, the current version of libgmime-2.4 in testing and unstable
> (2.4.23-1) unfortunately breaks signature verification, which means that
> many of the crypto tests will fail.  The issue has been fixed upstream,
> and we've been pushing on the libgmime maintainer to push a new release.
> Hopefully a release of notmuch 0.6 into debian will put extra pressure
> on getting this issue resolved.

An option for these systems:

- Linux (particularly on x86, x86_64, and PowerPC).
- Mac OS X, both on Intel and PowerPC.
- FreeBSD (only tested on Intel).
- Windows through Cygwin.

is using nix to install emacs and notmuch from nixpkgs. It does not
interfere with other software installed on the system but installs into
/nix and creates links of installed software into a profile which can be
included in the PATH.

Current release candidate and gmime 2.4.24 are packaged in nixpkgs.

Installation instructions at [1]. For simplicity I recommend the single
user install.

In case of question, I and #nixos are happy to help.

Nix/Nixpkgs is not an alternative to debian, but helps in having some
newer things independent of the system. However, there is no security
team yet ensuring timely updates.

regards
florian

[1] http://hydra.nixos.org/build/1069287/download/1/manual/#chap-installation
-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110507/0bc1266a/attachment.pgp>

release-candidate/0.6

[Sebastian Spaeth]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

+1, thanks for doing this Jameson

Used-and-approved-by-a-happy: Sebastian Spaeth 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

release-candidate/0.6

[Tim Gray]

On May 06, 2011 at 07:56 PM -0400, James Vasile wrote:
>Thanks for pulling this together.
>
>I sent two patches to the list on March 16.  They were a bug fix to
> 
>allow notmuch to correctly handle some poorly formatted email.  Nobody
>ever replied, but I'd like to see the bug fixed nonetheless, as it
>results in unreadable mail.  Since I've actually seen such mail in the
>wild, I'd like to see Notmuch handle it.

Ditto with the very very simple patch I sent about OS X compiling.  I 
take it there are few users of OS X on this list, so every little bit 
could help.

I'm running the release candidate.  My simple patch still applied 
cleanly and worked.

The message-id was:
<20110403070333.GA71620 at selenium.125px.com>

release-candidate/0.6

[James Vasile]

Thanks for pulling this together.

I sent two patches to the list on March 16.  They were a bug fix to
allow notmuch to correctly handle some poorly formatted email.  Nobody
ever replied, but I'd like to see the bug fixed nonetheless, as it
results in unreadable mail.  Since I've actually seen such mail in the
wild, I'd like to see Notmuch handle it.

Those messages were:

Message-ID: <87ipvifrlv.fsf at softwarefreedom.org>
Message-ID: <87fwqmfr2x.fsf at softwarefreedom.org>

Thanks,
James

Re: release-candidate/0.6

[Tim Gray]

On May 06, 2011 at 07:56 PM -0400, James Vasile wrote:

Thanks for pulling this together.

I sent two patches to the list on March 16.  They were a bug fix to

allow notmuch to correctly handle some poorly formatted email.  Nobody
ever replied, but I'd like to see the bug fixed nonetheless, as it
results in unreadable mail.  Since I've actually seen such mail in the
wild, I'd like to see Notmuch handle it.


Ditto with the very very simple patch I sent about OS X compiling.  I 
take it there are few users of OS X on this list, so every little bit 
could help.


I'm running the release candidate.  My simple patch still applied 
cleanly and worked.


The message-id was:
<20110403070333.ga71...@selenium.125px.com>
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Florian Friesdorf]

On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
wrote:
> Thanks for pulling this together.
> 
> I sent two patches to the list on March 16.  They were a bug fix to
> allow notmuch to correctly handle some poorly formatted email.  Nobody
> ever replied, but I'd like to see the bug fixed nonetheless, as it
> results in unreadable mail.  Since I've actually seen such mail in the
> wild, I'd like to see Notmuch handle it.
> 
> Those messages were:
> 
> Message-ID: <87ipvifrlv@softwarefreedom.org>
> Message-ID: <87fwqmfr2x@softwarefreedom.org>

The first seems to be damaged, the second I did not try:

~/dev/notmuch]$ cat $(notmuch search --output=files 
id:87ipvifrlv@softwarefreedom.org) |patch -p1
patching file lib/thread.cc
Hunk #1 FAILED at 266.
patch:  malformed patch at line 153: hread,

But it sounds like a different approach to:
id:8739ljwy7z@msstf091.ucc.ie,
id:1304723846-29134-1-git-send-email-...@chaoflow.net

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC


pgppEyf2ZXgJf.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[James Vasile]

Thanks for pulling this together.

I sent two patches to the list on March 16.  They were a bug fix to
allow notmuch to correctly handle some poorly formatted email.  Nobody
ever replied, but I'd like to see the bug fixed nonetheless, as it
results in unreadable mail.  Since I've actually seen such mail in the
wild, I'd like to see Notmuch handle it.

Those messages were:

Message-ID: <87ipvifrlv@softwarefreedom.org>
Message-ID: <87fwqmfr2x@softwarefreedom.org>

Thanks,
James
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Florian Friesdorf]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
 wrote:
> Hi, folks.  As some of you already know, I am trying to put together a
> release candidate for a 0.6 release that we can present to cworth for
> approval.  This branch can be found in my public notmuch repository in
> the "release-candidate/0.6" branch:
> 
> git remote add jrollins git://finestructure.net/notmuch
> git remote update
> git checkout -t -b release-candidate/0.6 jrollins/release-candidate/0.6
> 
> So far, this release candidate includes a couple of patch series that
> are not currently on cworth's master branch:
> 
> json structure now replicates mime structure
> * dme's json-fully-reflects-MIME-structure improvements
> * dkg/jrollins's PGP/MIME cryptographic support
> * amdragon's atomicity improvements
> * a couple other small improvements

I'm delighted! 

> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I did already run this combination for quite a while with general
satisfaction.

Problems in emacs (i.e. the json format) with displaying certain mime
messages are solved by using gmime 2.4.24 (thx dkg for the debugging
support). Problems were: notmuch show consuming 100% CPU without a result
and "EOF while reading message".

An open issue (also with gmime 2.4.24) is the extraction of a PDF from
an encrypted message via emacs (discussed on irc before, mentioned here
for completeness of the archive).

> PS: note to Debian users:
> 
> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch
> 
> However, the current version of libgmime-2.4 in testing and unstable
> (2.4.23-1) unfortunately breaks signature verification, which means that
> many of the crypto tests will fail.  The issue has been fixed upstream,
> and we've been pushing on the libgmime maintainer to push a new release.
> Hopefully a release of notmuch 0.6 into debian will put extra pressure
> on getting this issue resolved.

An option for these systems:

- Linux (particularly on x86, x86_64, and PowerPC).
- Mac OS X, both on Intel and PowerPC.
- FreeBSD (only tested on Intel).
- Windows through Cygwin.

is using nix to install emacs and notmuch from nixpkgs. It does not
interfere with other software installed on the system but installs into
/nix and creates links of installed software into a profile which can be
included in the PATH.

Current release candidate and gmime 2.4.24 are packaged in nixpkgs.

Installation instructions at [1]. For simplicity I recommend the single
user install.

In case of question, I and #nixos are happy to help.

Nix/Nixpkgs is not an alternative to debian, but helps in having some
newer things independent of the system. However, there is no security
team yet ensuring timely updates.

regards
florian

[1] http://hydra.nixos.org/build/1069287/download/1/manual/#chap-installation
-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: f...@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC


pgp8YrRKl7sFN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6

[Sebastian Spaeth]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
 wrote:
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

+1, thanks for doing this Jameson

Used-and-approved-by-a-happy: Sebastian Spaeth 



pgprPNA77gVqb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  As some of you already know, I am trying to put together a
release candidate for a 0.6 release that we can present to cworth for
approval.  This branch can be found in my public notmuch repository in
the "release-candidate/0.6" branch:

git remote add jrollins git://finestructure.net/notmuch
git remote update
git checkout -t -b release-candidate/0.6 jrollins/release-candidate/0.6

So far, this release candidate includes a couple of patch series that
are not currently on cworth's master branch:

json structure now replicates mime structure
* dme's json-fully-reflects-MIME-structure improvements
* dkg/jrollins's PGP/MIME cryptographic support
* amdragon's atomicity improvements
* a couple other small improvements

I might try to add a couple of more things before declaring the
candidate release-ready, but this is more-or-less it.  Please start
using this branch "in production" as much as possible, so that we can
build up a chorus of support for pushing this release out.  Once you
have build, tested, and started using the branch, please reply to this
email thread to express your support for it's release.

jamie.

PS: note to Debian users:

The release-candidate/0.6 branch also includes debian package updates,
so you should be able to easily build debian packages from the branch:

git buildpackage -uc -us --git-ignore-branch

However, the current version of libgmime-2.4 in testing and unstable
(2.4.23-1) unfortunately breaks signature verification, which means that
many of the crypto tests will fail.  The issue has been fixed upstream,
and we've been pushing on the libgmime maintainer to push a new release.
Hopefully a release of notmuch 0.6 into debian will put extra pressure
on getting this issue resolved.


pgpiytw3wD3fu.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6

[Jameson Graef Rollins]

Hi, folks.  As some of you already know, I am trying to put together a
release candidate for a 0.6 release that we can present to cworth for
approval.  This branch can be found in my public notmuch repository in
the "release-candidate/0.6" branch:

git remote add jrollins git://finestructure.net/notmuch
git remote update
git checkout -t -b release-candidate/0.6 jrollins/release-candidate/0.6

So far, this release candidate includes a couple of patch series that
are not currently on cworth's master branch:

json structure now replicates mime structure
* dme's json-fully-reflects-MIME-structure improvements
* dkg/jrollins's PGP/MIME cryptographic support
* amdragon's atomicity improvements
* a couple other small improvements

I might try to add a couple of more things before declaring the
candidate release-ready, but this is more-or-less it.  Please start
using this branch "in production" as much as possible, so that we can
build up a chorus of support for pushing this release out.  Once you
have build, tested, and started using the branch, please reply to this
email thread to express your support for it's release.

jamie.

PS: note to Debian users:

The release-candidate/0.6 branch also includes debian package updates,
so you should be able to easily build debian packages from the branch:

git buildpackage -uc -us --git-ignore-branch

However, the current version of libgmime-2.4 in testing and unstable
(2.4.23-1) unfortunately breaks signature verification, which means that
many of the crypto tests will fail.  The issue has been fixed upstream,
and we've been pushing on the libgmime maintainer to push a new release.
Hopefully a release of notmuch 0.6 into debian will put extra pressure
on getting this issue resolved.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110506/2f846e24/attachment.pgp>