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 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
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 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
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
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 rel
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 finestructur
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
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.
tmuch/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 at
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
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
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
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 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 s
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
didate/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
Siz
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
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
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
tting 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 versio
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
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
-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
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
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
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 patc
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
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
t; 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
lling 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
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
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
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
, 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
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 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
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
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
d 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:
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
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 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
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
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 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
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
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
>
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 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
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,
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
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://finestr
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
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
84 matches
Mail list logo
