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
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
On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal jrosent...@jhu.edu 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
On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
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
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
On Sun, 05 Jun 2011 17:35:40 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org wrote:
From a quick rebase of your release-candidate branch and a comparison
with what I have queued it looks like only the following
On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth cwo...@cworth.org 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
On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org 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
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
On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
jroll...@finestructure.net 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
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
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
On Mon, 16 May 2011 13:59:51 -0700, Carl Worth cwo...@cworth.org 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
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
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
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
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
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
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
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]
On Fri, 13 May 2011 01:07:08 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
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
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net 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
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
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net 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
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
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
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth cwo...@cworth.org 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
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
On Thu, 12 May 2011 15:36:43 -0700, Carl Worth cwo...@cworth.org 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
On Tue, 10 May 2011 09:42:39 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
On Thu, May 12, 2011 at 8:22 AM, Pieter Praet pie...@praet.org 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
On Thu, 12 May 2011 09:18:48 -0400, Austin Clements amdra...@mit.edu wrote:
On Thu, May 12, 2011 at 8:22 AM, Pieter Praet pie...@praet.org 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
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
On Mon, 09 May 2011 10:20:18 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
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
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Fri, 06 May 2011 19:56:30 -0400, James Vasile ja...@hackervisions.org
wrote:
I sent two patches to the list on March 16. They were a bug fix to
allow notmuch to correctly handle some poorly
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
On Sat, 07 May 2011 01:51:25 +0200, Florian Friesdorf f...@chaoflow.net 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
On Fri, 06 May 2011 19:56:30 -0400, James Vasile ja...@hackervisions.org
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
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
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
On Sun, 08 May 2011 21:24:52 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net 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
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
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
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins
jroll...@finestructure.net 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
50 matches
Mail list logo
