Re: muchsync segfault

2020-09-28 Thread Brian May
David Bremner  writes:

> Generic advice would be to run in gdb and get a backtrace, assuming you
> have debugging symbols.

Somebody else via private reply suggested I try the git version.

So far it looks like that has solved the problem.

Thanks
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


muchsync segfault

2020-09-27 Thread Brian May
Hello all,

muchsync is segfaulting when I run it on a particular box:

$ muchsync -v silverfish.local   
[notmuch] No new mail.
synchronizing muchsync database with Xapian... 0.011202 (+0.011202)
starting scan of Xapian database... 0.011269 (+0.67)
opened Xapian... 0.011611 (+0.000342)
scanned message IDs... 0.162030 (+0.150420)
scanned tags... 0.175126 (+0.013096)
scanned directories in xapian... 0.175315 (+0.000189)
scanned filenames in xapian... 0.175394 (+0.79)
[SERVER] [notmuch] No new mail.
adjusted link counts... 0.226647 (+0.051253)
finished synchronizing muchsync database with Xapian... 0.235871 (+0.009224)
received server's version vector... 0.877723 (+0.641851)
received hashes of new files... 1.176468 (+0.298746)
[1]64563 segmentation fault  muchsync -v silverfish.local

How do I resolve?

I tried

$ notmuch reindex '*'

But this doesn't appear to have helped.

Anything else I should try?

Regards
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: timezone in notmuch

2020-04-15 Thread Brian May
Tomi Ollila  writes:

> I use this:
>
> https://github.com/domo141/nottoomuch/blob/master/build/01-date-local.patch
>
> I've been thinking if some hook could be added to notmuch-emacs so
> that such a custom date mangling can be done outside of the notmuch-emacs
> source...

I would like to see something like this without having to patch notmuch.

As much as I like notmuch-show-relative-dates, occasionally, I just want
to be able to see the exact time an email was sent in my timezone.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Weird tagging issue

2020-03-30 Thread Brian May
Daniel Kahn Gillmor  writes:

> Well, not if they're actually all the same message, right?
>
> Brian, can you confirm whether the body of these 4 messages are the same
> or not?  (e.g. you might have gotten different copies due to receiving
> mail at different e-mail addresses, or through a mailing list, or just
> through an SMTP hiccup)

All emails appear to be different. I think bitbucket stuffed up.

> What about for a message that References: its own Message-ID:?  Do we
> expect to handle that case sensibly?  I'm not sure where i'd look in the
> test suite to confirm that we intend to make that work OK, and i can
> definitely imagine that being a goofy corner case when trying to
> manipulate threads.

I can't help here. I do have a vague recollection that I have seen this
situation in the past (any easy way to search for such emails?), but I
really can't remember how well notmuch copes (the fact I noticed such an
issue might suggest I encountered difficulties - or maybe this was
something else entirely).
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Weird tagging issue

2020-03-29 Thread Brian May
Daniel Kahn Gillmor  writes:

>> "1584434229.8921_0.wspdigital:2,S" -> { 
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" } 
>> "1584434231.8924_0.wspdigital:2,S" -> { 
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>> "1584434232.8927_0.wspdigital:2,S" -> { 
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>> "1584434234.8930_0.wspdigital:2,S" -> { 
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>
> The surprising thing about this output is that there appear to be 4
> copies of message that References: itself!
>
> And, many many other messages also reference that message too.
>
> Would you be willing to send me the full headers from one of the above 4
> files so i can verify that this is correct?

I suspect you only need the Message-ID and the References headers,
right? If not, can send more:

Message-ID: 
References: 

This applies to all 4 of those messages. Yes, they all look like they
have the same Message-ID

Also I am not seeing any duplicate headers or anything like that.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Weird tagging issue

2020-03-22 Thread Brian May
Daniel Kahn Gillmor  writes:

> This sounds really confusing, and i'm not sure how to help you debug. :/
> when you say "recreated the entire database", do you mean you dropped
> all tags and everything, and reindexed the entire datastore?

Yes, that is correct. I basically deleted "~/Maildir/.notmuch" and then
ran "notmuch new". After confirming that the problem still existed, I
then restored the backup of my tags,

> Does the thread that you were working with contain any sensitive or
> private messages?  If not, can you isolate the specific files from the
> maildir that compose the thread (e.g. with a manual grep) and try to
> recreate the failure with a smaller maildir and dedicated notmuch
> database?  I know this is tedious, but if you can do it and share the
> maildir, then it would help other folks reproduce the problem and dig
> into it further.

These are messages associated with a pull request for a private
bitbucket repository owned by my employee, So I probably should not make
them public :-(

> if i was debugging this locally and i had a dedicated maildir that
> demonstrated the problem, i'd probably try to inspect the xapian
> database (e.g. with xapian-delve).  There are several folks on the
> #notmuch channel on freenode that can probably give pointers.

Fortunately that particular pull request has been merged now, I probably
don't have to worry anymore. However would be interested to know what
happened.

My suspicion is that bitbucket generated a bad email - maybe bad headers
or something, which has totally confused things,

The Message-ID values look fine. Although oddly enough there are several
different formats, but this shouldn't be an issue:

=== cut ===
$ grep '^Message-ID' $(grep -ri -l 'Pull request #88: Add webdriver support' 
Maildir)Maildir/cur/1584486508.24564_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584486509.24570_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584487127.27595_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584487437.29402_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584494811.24972_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584494813.25016_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584567341.22359_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584505808.24160_0.wspdigital:2,S:Message-ID: 

Maildir/cur/1584506116.25523_0.wspdigital:2,S:Message-ID: 

[...]
=== cut ===

H. Maybe the References header is bad. I see a number of emails in
this thread referencing "pr-wspdigital/bupaoshc/8...@bitbucket.org", e.g.:

=== cut ===
References: 
 

References: 

References: 
 
=== cut ===

But "pr-wspdigital/bupaoshc/8...@bitbucket.org" doesn't have any
information uniquely identifying a particular message for PR #88, and
furthermore I don't see any message ids that look like this in this
thread.

I could imagine bad references might be confusing notmuch?

I guess I should wait and see if the problem happens again.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Weird tagging issue

2020-03-19 Thread Brian May
Brian May  writes:

> I am having a problem with certain messages, in that I remove the tag
> and it still shows up in search results.

I just recreated the entire database, and I still get the same problem.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Weird tagging issue

2020-03-18 Thread Brian May
Hello,

I am having a problem with certain messages, in that I remove the tag
and it still shows up in search results.

e.g.

$ notmuch search tag:important
[...]
thread:aaff 40 mins. ago [37/38(43)] Lucas Liendo, Ricardo Perez; 
[Bitbucket] Pull request #88: Add webdriver support (wspdigital/bupaoshc) 
(important inbox unread)
[...]

but if I view the thread:

$ notmuch show thread:aaff

I see one message, it has no tags, and it is not the message referenced
in the search results (i.e. it was sent hours ago, not 40 minutes).

It only happens with this thread. Sometimes if I play around enough I
can fix it, but the fix doesn't last. I get similar problems for other
tags, such as inbox and important also. I suspect the root problem is it
isn't showing the entire thread.

I have tried:

$ notmuch reindex thread:aaff
$ notmuch reindex 'Pull request #88: Add webdriver support' 

But it doesn't help.

The emacs reader is getting rather confused as a result. It says the
message has the tags when it doesn't and won't let me see the entire
thread.

Is this a sign my tag database is corrupt? If so how do I fix? Or maybe
there is some problem with the message - it looks OK to me. Was
generated from bitbucket.

It is not 100% important that I preserve my existing tags, but would
like to know what is going on.

This is notmuch version 0.28.4-1 from Debian buster using Maildir.

Thanks
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: proposing "notmuch purge"

2020-01-14 Thread Brian May
Daniel Kahn Gillmor  writes:

> So i'm proposing "notmuch purge", which could be something as simple as
> the equivalent of:

I can't help think it will only be a matter of time before somebody
mistypes the search spec and accidentally deletes all their mail...

Of course, this won't be a drama, because said user will revert to
up-to-date backup, created just before manually entering risky command,
right? ;-)
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Working with 2FA-enabled mail (app password not possible)

2020-01-08 Thread Brian May
Chris Coutinho  writes:

> My company recently made our Office365 mail service 2FA-enabled by
> default and disallowed app-specific passwords. Before this, I used
> Offlineimap to download my mail and index/search it using Notmuch. Now
> that that's no longer possible, I'm looking to the community for
> options.
>
> What do you use for syncing your mail to your local system(s) and
> utilizing the power of Notmuch?

Hmm. Wonder if this is the real reason IMAP suddenly stopped working for
me on my work Office365 domain after updating my password. Although it
does work for some people. Weird.

OAuth is the solution for Google, and I suspect OAuth may be the
solution for Microsoft too. If so, you need a program that supports IMAP
using OAuth.

gemail supports Google OAuth, I suspect it might be possible to get it
to work with Microsoft too. However I don't know anything about how to
register the Oauth app with Microsoft.

http://www.bytereef.org/howto/oauth2/getmail.html

Apparently OfflineIMAP also supports Oauth.

Another option might be davmail.

https://sourceforge.net/p/davmail/bugs/717/
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Google Mail

2019-12-16 Thread Brian May
 and re-add your account.  
When you add it back, select “sign in with Google” to automatically use  
OAuth.

Mac OS iOS

mail app view Mac OS

mail app view iOS

Calendar

If you use CalDAV to give an app or device access to your calendar, switch  
to a method that supports OAuth. We recommend the Google Calendar app  
[Web/iOS/Android] as the most secure app to use with your G Suite account.
If your G Suite account is linked to the calendar app in iOS or MacOS and  
uses only a password to login, you'll need to remove and re-add your  
account to your device. When you add it back, select “sign in with Google”  
to automatically use OAuth. Read more

Contacts

If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and  
uses only a password to login, you'll need to remove your account. When you  
add it back, select “sign in with Google” to automatically use OAuth. Read  
More
If your G Suite account is syncing contacts to any other platform or app  
via CardDAV and uses only a password to login, switch to a method that  
supports OAuth.

Note: If the app you are using does not support OAuth, you will need to  
switch to an app that offers OAuth, or ask your admin to contact the  
supplier of your app and request that they add OAuth as a way of connecting  
your Google account.

Developer instructions

To maintain compatibility with G Suite accounts, update your app to use  
OAuth 2.0 as a connection method. To get started, follow our developer  
guide on using OAuth 2.0 to access Google APIs. You can also refer to our  
guide on OAuth 2.0 for mobile & desktop apps.

How can I get help?

If you have additional questions or need assistance, please contact G Suite  
support. When you call or submit your support case, reference issue number  
145694552.

Thanks for choosing G Suite.

—The G Suite Team

Was this information helpful?
YES NO

© 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043

You have received this important update about your G Suite account because  
you designated this email address as a primary or secondary contact for  
mandatory service communications in your Google Admin console profile.

-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: New Python bindings (was: Crash with Python bindings)

2018-04-04 Thread Brian May
David Bremner <da...@tethera.net> writes:

> That's not an itch I personally have, but as I said in the next
> paragraph, if someone want's to take on the project of maintaining a
> wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS
> package maintainers.  We're happy to look at (reasonable) things we can
> do to make downstream projects life easier.

Fair enough. No problem.

I am going to assume that the notmuch library is reasonable stable, and
backward incompatable changes are kept to a minimum with proper updating
of the shared library SONAME. If this is not the case, ignore the rest
of this email.

Ideally the python bindings should be in a git repository that is
separate from the C library. This means you don't have to release new
python bindings for every new source code release of notmuch. You only
need to make a new release if supporting new features or a new release
that breaks backword compatability. It also will make it easier to build
the python libraries standalone using the installed versions of the C
library, which I suspect might make pypi support a lot easier.

I might be able to get time to look at this sometime myself, if nobody
beats me to it.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Brian May
David Bremner <da...@tethera.net> writes:

> We tried this before, and it didn't work out very well. Bindings tend to
> depend on a strict matching of versions with the underlying library, so
> distributing them seperately doesn't really make sense to me. You need
> the underlying libraries, so why not get the matching bindings from the
> same place?  We found that the situation was exacerbated by the fact
> that no-one cared about updating the bindings on pypi.

I believe that is the purpose of Python Wheels.

https://pythonwheels.com/

pypi is the defecto standard for distributing Python code for use in
Python applications. It means packages that use notmuch just need to
list it as a dependancy in 'requirements.txt' and a 'pip install -r
requirements.txt' will install everything required (if inside a
virtualenv no root access required even).

There are also various solutions to get automatic deploys to pypi, for
example through travis:

https://docs.travis-ci.com/user/deployment/pypi/

Unfortunately, I think many people will not even consider using a python
library unless it has up-to-date bindings available on pypi.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: New Python bindings (was: Crash with Python bindings)

2018-03-28 Thread Brian May
Justus Winter <jus...@sequoia-pgp.org> writes:

>> This is exactly what I have fixed in my alternative bindings which I
>> created around the end of last year [0].  So we do have an idea of how
>> to fix this, at the time I said I do believe that it's possible to also
>> do this for the existing bindings even though it is a lot of work.
>> After some talking between dkg and me we got to a way forward which
>> proposed this, but I must admit that after messing a little with getting
>> a pytest run integrated into the notmuch test-suite instead of using tox
>> I lost momentum on the project and didn't advance any further.
>
> I'm sorry that I didn't speak up when you announced your work.  I'm
> actually excited about a new set of bindings for Python.  I agree with
> using cffi.  I briefly looked at the code, and I believe it is much
> nicer than what we currently have.

I can into this thread late. However, my priorities for python bindings
would be:

* I don't care about anything less then Python 3.5.
* Reliable Python 3.6 support important.
* Packages should be available from pypi.python.org

I have found the current official bindings unreliable with Python 3.x,
and tend to cause aborts on exiting and/or fail to save updates. As
such, for now I have downgraded to Python 2.7 for now.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: searching for multiple tags

2018-03-17 Thread Brian May
David Bremner <da...@tethera.net> writes:

> There is a patch floating around [1] to support
>
> % notmuch search thread:{tag:important} and thread:{tag:unread}
>
> if that's the query you actually want.

I assume this means we search for threads where at least one message is
important and at least one message is unread.

That actually sounds like a very useful feature to have. I would most
definitely have uses for it. Is there any chance of this (or something
like it) being merged into notmuch?

Thanks
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: searching for multiple tags

2018-03-17 Thread Brian May
David Bremner <da...@tethera.net> writes:

> This is a design-choice/quirk of the Xapian query parser, discussed
> under "Operators" in man notmuch-search-terms; terms with a common
> prefix are implicitely combined with an OR.
> I don't think that documentation has changed since 0.23, but you can
> compare with https://notmuchmail.org/manpages/notmuch-search-terms-7/

Ok, now I understand that text. Thanks. I tried using "tag:important and
tag:unread" yesterday, and it didn't work either.

Today I am wondering if maybe I had threads that had some messages
marked important and some marked unread, but no individual messages
marked both unread and important. Oh well, maybe this was the real
reason I was having problems.

Thanks for your response.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


searching for multiple tags

2018-03-16 Thread Brian May
Hello,

How do I search for emails containing multiple tags?

I have tried:

tag:unread tag:important

However, this finds emails that contain either the unread tag or the
important tag. Not emails that contain both.

Am I doing something wrong?

This is version 0.23.7-3 in Debian/stretch.

Thanks
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


emacs email appears empty

2011-10-11 Thread Brian May
On 29 September 2011 21:05, David Bremner  wrote:
> Any chance you could share such a message with us?

Unfortunately the emails with this problem are private, I probably
shouldn't repost without getting permission first from the sender.

I think it might be emails sent with Zimbra web interface. Maybe the
"- Original Message -" text? At least this is what the emails
have in common. Unfortunately, my test messages all work fine. There
is a copy below anyway.

I also have attached an email with nothing but the signature. This
email comes out completely blank without any option to see the
signature. Not sure if this is expected or not.

Fingers crossed gmail isn't going to mess with the line formatting...

=== cut ===
Return-Path: brian at vpac.org
Received: from mail.vpac.org [2001:388:60ac::4]
by aquitard with IMAP (fetchmail-6.3.18)
for  (single-drop); Tue, 11 Oct 2011 09:44:51 +1100 
(EST)
Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by
 mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mail.vpac.org (Postfix) with ESMTP id E23F2C0197372
for ; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
X-Virus-Scanned: amavisd-new at mail.vpac.org
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-10 required=5
tests=[BAYES_00=-1.9, HELO_NO_DOMAIN=0.001, RDNS_NONE=0.793]
autolearn=no
Received: from mail.vpac.org ([127.0.0.1])
by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KeztsuHiXzIh; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Received: from mail.vpac.org (mail.vpac.org [202.158.218.6])
by mail.vpac.org (Postfix) with ESMTP id 3A2D6C0197369;
Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Date: Tue, 11 Oct 2011 09:44:29 +1100 (EST)
From: Brian May <br...@vpac.org>
To: Brian May 
Cc: Brian May 
Message-ID: <1567978915.114359.1318286669223.JavaMail.root at mail.vpac.org>
In-Reply-To: 

Re: emacs email appears empty

2011-10-10 Thread Brian May
On 29 September 2011 21:05, David Bremner da...@tethera.net wrote:
 Any chance you could share such a message with us?

Unfortunately the emails with this problem are private, I probably
shouldn't repost without getting permission first from the sender.

I think it might be emails sent with Zimbra web interface. Maybe the
- Original Message - text? At least this is what the emails
have in common. Unfortunately, my test messages all work fine. There
is a copy below anyway.

I also have attached an email with nothing but the signature. This
email comes out completely blank without any option to see the
signature. Not sure if this is expected or not.

Fingers crossed gmail isn't going to mess with the line formatting...

=== cut ===
Return-Path: br...@vpac.org
Received: from mail.vpac.org [2001:388:60ac::4]
by aquitard with IMAP (fetchmail-6.3.18)
for brian@localhost (single-drop); Tue, 11 Oct 2011 09:44:51 +1100 
(EST)
Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by
 mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mail.vpac.org (Postfix) with ESMTP id E23F2C0197372
for br...@vpac.org; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
X-Virus-Scanned: amavisd-new at mail.vpac.org
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-10 required=5
tests=[BAYES_00=-1.9, HELO_NO_DOMAIN=0.001, RDNS_NONE=0.793]
autolearn=no
Received: from mail.vpac.org ([127.0.0.1])
by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KeztsuHiXzIh; Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Received: from mail.vpac.org (mail.vpac.org [202.158.218.6])
by mail.vpac.org (Postfix) with ESMTP id 3A2D6C0197369;
Tue, 11 Oct 2011 09:44:29 +1100 (EST)
Date: Tue, 11 Oct 2011 09:44:29 +1100 (EST)
From: Brian May br...@vpac.org
To: Brian May br...@microcomaustralia.com.au
Cc: Brian May br...@vpac.org
Message-ID: 1567978915.114359.1318286669223.javamail.r...@mail.vpac.org
In-Reply-To: 
CAA0ZO6Avc1oQjvaXKJpi=vdtusk-4y+moxeewloxtzib-vn...@mail.gmail.com
Subject: Re: test 2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.250.103.200]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - SAF3 (Linux)/6.0.13_GA_2918)



- Original Message -
 This is a test. Proof is not attached.
 --
 Brian May br...@microcomaustralia.com.au

You don't have any proof do you?
-- 
Brian May
=== cut ===

=== cut ===
Return-Path: br...@microcomaustralia.com.au
Received: from mail.vpac.org [2001:388:60ac::4]
by aquitard with IMAP (fetchmail-6.3.18)
for brian@localhost (single-drop); Tue, 11 Oct 2011 09:40:48 +1100 
(EST)
Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by
 mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:40:33 +1100 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mail.vpac.org (Postfix) with ESMTP id C218CC0197370
for br...@vpac.org; Tue, 11 Oct 2011 09:40:33 +1100 (EST)
X-Virus-Scanned: amavisd-new at mail.vpac.org
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-10 required=5 tests=[AWL=0.236,
BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Authentication-Results: mail.vpac.org (amavisd-new); dkim=pass
header.i=@microcomaustralia.com.au
Received: from mail.vpac.org ([127.0.0.1])
by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nF6unVC7D49c for br...@vpac.org;
Tue, 11 Oct 2011 09:40:32 +1100 (EST)
Received: from mail-ww0-f48.google.com (mail-ww0-f48.google.com [74.125.82.48])
by mail.vpac.org (Postfix) with ESMTPS id AB51AC0197369
for br...@vpac.org; Tue, 11 Oct 2011 09:40:31 +1100 (EST)
Received: by wwe32 with SMTP id 32so9383984wwe.29
for br...@vpac.org; Mon, 10 Oct 2011 15:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=microcomaustralia.com.au; s=google;
h=mime-version:x-originating-ip:date:message-id:subject:from:to
 :content-type;
bh=x9j2t6NjG/AVcHxbwM/oIFlLTOFwF3y1ZW22PVeCbT0=;
b=HSCTN2sYz7ixqfK08MeDu/0owkvqzMCzyyGEYuIq4htrxTM5Vlkd/MTkN79okgDWBx
 RpVG7GmIU4jf/xUVut4n002e6nTVRBUcM6VWMhaIZMPrmtHN/N2NobMDIQh2pqYKiO/1
 T5pcHKqFp9TQNumFn/4FH0AGZfxbYLQvD+n58=
MIME-Version: 1.0
Received: by 10.216.131.193 with SMTP id m43mr5932606wei.114.1318286427492;
 Mon, 10 Oct 2011 15:40:27 -0700 (PDT)
Received: by 10.216.179.134 with HTTP; Mon, 10 Oct 2011 15:40:27 -0700 (PDT)
X-Originating-IP: [128.250.103.200]
Date: Tue, 11 Oct 2011 09:40:27 +1100
Message-ID: CAA0ZO6BLHKENNcs1jgC-MRH=weoa4mxbqi54jgqcgd2szqp...@mail.gmail.com
Subject: test only
From: Brian May br...@microcomaustralia.com.au
To: Brian

emacs email appears empty

2011-09-29 Thread Brian May
On 29 September 2011 11:21, Brian May  wrote:
> Have seen several cases now where the message appears blank in the
> emacs interface. With nothing but the headers.
>
> Pushing Shift+V shows the entire raw message. Nothing special, just a
> plain text email without any attachments.

Also replying to this email quotes it correctly. Weird.
-- 
Brian May 


emacs email appears empty

2011-09-29 Thread Brian May
Hello,

Have seen several cases now where the message appears blank in the
emacs interface. With nothing but the headers.

Pushing Shift+V shows the entire raw message. Nothing special, just a
plain text email without any attachments.

MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Any ideas?

Thanks
-- 
Brian May 


emacs email appears empty

2011-09-28 Thread Brian May
Hello,

Have seen several cases now where the message appears blank in the
emacs interface. With nothing but the headers.

Pushing Shift+V shows the entire raw message. Nothing special, just a
plain text email without any attachments.

MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Any ideas?

Thanks
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: emacs email appears empty

2011-09-28 Thread Brian May
On 29 September 2011 11:21, Brian May br...@microcomaustralia.com.au wrote:
 Have seen several cases now where the message appears blank in the
 emacs interface. With nothing but the headers.

 Pushing Shift+V shows the entire raw message. Nothing special, just a
 plain text email without any attachments.

Also replying to this email quotes it correctly. Weird.
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


not much reply multipart/mixed

2011-08-10 Thread Brian May
Hello,

When I reply to a given email, instead of quoting the original text, I see:

=== cut ===
On Tue, 9 Aug 2011 01:39:30 -0600, tivoli_support at ecurep.ibm.com wrote:
Non-text part: multipart/mixed
Non-text part: text/html
=== cut ===

This is with the latest git master version.

Thanks
-- 
Brian May 


not much reply multipart/mixed

2011-08-09 Thread Brian May
Hello,

When I reply to a given email, instead of quoting the original text, I see:

=== cut ===
On Tue, 9 Aug 2011 01:39:30 -0600, tivoli_supp...@ecurep.ibm.com wrote:
Non-text part: multipart/mixed
Non-text part: text/html
=== cut ===

This is with the latest git master version.

Thanks
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Preventing the user shooting themself in the foot

2011-07-01 Thread Brian May
On 30 June 2011 17:50, Pieter Praet  wrote:
> And AFAIK, "Archive" does *not* mark a message as read in GMail.
> (see previous messages suggesting the inverse)

gmail will mark all messages in the thread as read when looking at any
part of the thread - so in practical terms whenever I click "Archive"
the entire thread is marked as read - as I always click archive in the
message view.

Not absolutely convinced this is the best approach. I think it is
important to appreciate the differences that different implementations
have chosen.
-- 
Brian May 


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Brian May
On 30 June 2011 17:50, Pieter Praet pie...@praet.org wrote:
 And AFAIK, Archive does *not* mark a message as read in GMail.
 (see previous messages suggesting the inverse)

gmail will mark all messages in the thread as read when looking at any
part of the thread - so in practical terms whenever I click Archive
the entire thread is marked as read - as I always click archive in the
message view.

Not absolutely convinced this is the best approach. I think it is
important to appreciate the differences that different implementations
have chosen.
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Preventing the user shooting themself in the foot

2011-06-30 Thread Brian May
On 30 June 2011 08:40, Carl Worth  wrote:
> The 'a' keybinding, (in turn), was designed for cases when you *know*
> you don't want to read the rest of the thread.

... in which case it should also mark everything as read. IMHO.

Are there any keyboard bindings to go forwards to the next message or
backwards to the last message without marking anything as archived?

Also, just something I have noticed it isn't really obvious that a
thread has replies without scrolling down, and that takes time. Would
be really good if there could be some big/highlighted visual indicator
that there are still unread messages further down.
-- 
Brian May 


Re: Preventing the user shooting themself in the foot

2011-06-29 Thread Brian May
On 30 June 2011 08:40, Carl Worth cwo...@cworth.org wrote:
 The 'a' keybinding, (in turn), was designed for cases when you *know*
 you don't want to read the rest of the thread.

... in which case it should also mark everything as read. IMHO.

Are there any keyboard bindings to go forwards to the next message or
backwards to the last message without marking anything as archived?

Also, just something I have noticed it isn't really obvious that a
thread has replies without scrolling down, and that takes time. Would
be really good if there could be some big/highlighted visual indicator
that there are still unread messages further down.
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[python] get all messages of a thread

2011-06-02 Thread Brian May
On 2 June 2011 17:05, Sebastian Spaeth  wrote:

> What would be the best way to solve this (besides fixing the C api to
> allow to reset the iterator ;-) ?)
>
>
 I am not really familiar with the code. So am I correct in making the
following assumptions?

* It is not easy to fix the C api to reset the iterator (what about
repeating the search?)

* The only accurate way to get the number of messages is to iterate through
every search result and count them?

If so, then len(...) I think might be very slow if there are a large number
of elements.

Maybe it might be easier/better to implement object.__nonzero__(self)
 instead of the object.__len__(self) method?

http://docs.python.org/reference/datamodel.html

object.__nonzero__(self)
Called to implement truth value testing and the built-in operation bool();
should return False or True, or their integer equivalents 0 or 1. When this
method is not defined, __len__() is called, if it is defined, and the object
is considered true if its result is nonzero. If a class defines neither
__len__() nor __nonzero__(), all its instances are considered true.

object.__len__(self)
Called to implement the built-in function len(). Should return the length of
the object, an integer >= 0. Also, an object that doesn?t define a
__nonzero__() method and whose __len__() method returns zero is considered
to be false in a Boolean context.

-- 
Brian May 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110602/9b854d5c/attachment.html>


Multiple sender identities (composing)

2011-06-02 Thread Brian May
On 1 June 2011 16:42, Thomas Jost  wrote:

> There's a function that changes the signature according to the From
> header in the message I sent on this list yesterday
> (id:"87pqmznczk.fsf at thor.loria.fr", near the end of the message).
>
>
Thanks for the pointer, it seems to work fine.
-- 
Brian May 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110602/c7fceb25/attachment.html>


Re: [python] get all messages of a thread

2011-06-02 Thread Brian May
On 2 June 2011 17:05, Sebastian Spaeth sebast...@sspaeth.de wrote:

 What would be the best way to solve this (besides fixing the C api to
 allow to reset the iterator ;-) ?)


 I am not really familiar with the code. So am I correct in making the
following assumptions?

* It is not easy to fix the C api to reset the iterator (what about
repeating the search?)

* The only accurate way to get the number of messages is to iterate through
every search result and count them?

If so, then len(...) I think might be very slow if there are a large number
of elements.

Maybe it might be easier/better to implement object.__nonzero__(self)
 instead of the object.__len__(self) method?

http://docs.python.org/reference/datamodel.html

object.__nonzero__(self)
Called to implement truth value testing and the built-in operation bool();
should return False or True, or their integer equivalents 0 or 1. When this
method is not defined, __len__() is called, if it is defined, and the object
is considered true if its result is nonzero. If a class defines neither
__len__() nor __nonzero__(), all its instances are considered true.

object.__len__(self)
Called to implement the built-in function len(). Should return the length of
the object, an integer = 0. Also, an object that doesn’t define a
__nonzero__() method and whose __len__() method returns zero is considered
to be false in a Boolean context.

-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Multiple sender identities (composing)

2011-06-01 Thread Brian May
On 16 May 2011 19:29, Stewart Smith  wrote:

> Thought I'd share this bit of my .emacs snippet that may be useful to go
> on the emacs tips page.
>
> This does the following:
> - sets up a list of possible identities to have mail From
> - on composing mail, it prompts you for who you want to send mail from
> - pressing enter will give you the default (first in the list)
> - otherwise you have tab completion
>

Is it possible to have it change the signature per identity also?
-- 
Brian May 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110601/6047500c/attachment.html>


[python] get all messages of a thread

2011-06-01 Thread Brian May
On 28 May 2011 23:18, Patrick Totzke  wrote:

>if r: #because we cant iterate on NoneType
>

I don't understand why, but this line sets r._msgs to None. So it crashes,
because it has no message ids to look for.

If you change it to

if r is not None:

... then it works for me.

Oh, I see, for your code, there is a implied call to __len__, and the
__len__ function is completely broken for the reasons described in the
documentation:

  .. note:: As this iterates over the messages, we will not be able to=
   iterate over them again! So this will fail::

 #THIS FAILS
 msgs = Database().create_query('').search_message()
 if len(msgs) > 0:  #this 'exhausts' msgs
 # next line raises
NotmuchError(STATUS.NOT_INITIALIZED)!!!
 for msg in msgs: print msg

   Most of the time, using the
   :meth:`Query.count_messages` is therefore more
   appropriate (and much faster). While not guaranteeing
   that it will return the exact same number than len(),
   in my tests it effectively always did so.



-- 
Brian May 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110601/226b4f92/attachment.html>


Re: Multiple sender identities (composing)

2011-06-01 Thread Brian May
On 1 June 2011 16:42, Thomas Jost schno...@schnouki.net wrote:

 There's a function that changes the signature according to the From
 header in the message I sent on this list yesterday
 (id:87pqmznczk@thor.loria.fr, near the end of the message).


Thanks for the pointer, it seems to work fine.
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [python] get all messages of a thread

2011-05-31 Thread Brian May
On 28 May 2011 23:18, Patrick Totzke patricktot...@googlemail.com wrote:

if r: #because we cant iterate on NoneType


I don't understand why, but this line sets r._msgs to None. So it crashes,
because it has no message ids to look for.

If you change it to

if r is not None:

... then it works for me.

Oh, I see, for your code, there is a implied call to __len__, and the
__len__ function is completely broken for the reasons described in the
documentation:

  .. note:: As this iterates over the messages, we will not be able to=
   iterate over them again! So this will fail::

 #THIS FAILS
 msgs = Database().create_query('').search_message()
 if len(msgs)  0:  #this 'exhausts' msgs
 # next line raises
NotmuchError(STATUS.NOT_INITIALIZED)!!!
 for msg in msgs: print msg

   Most of the time, using the
   :meth:`Query.count_messages` is therefore more
   appropriate (and much faster). While not guaranteeing
   that it will return the exact same number than len(),
   in my tests it effectively always did so.



-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Multiple sender identities (composing)

2011-05-31 Thread Brian May
On 16 May 2011 19:29, Stewart Smith stew...@flamingspork.com wrote:

 Thought I'd share this bit of my .emacs snippet that may be useful to go
 on the emacs tips page.

 This does the following:
 - sets up a list of possible identities to have mail From
 - on composing mail, it prompts you for who you want to send mail from
 - pressing enter will give you the default (first in the list)
 - otherwise you have tab completion


Is it possible to have it change the signature per identity also?
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


emacs crashes

2011-02-20 Thread Brian May
On 18 February 2011 19:38, Michal Sojka  wrote:
> This should be already fixed -- see http://debbugs.gnu.org/6214. I'm not
> sure whether the fix is available in an emacs release or only in the
> development branch. It seems that Debian includes the fixes in its
> packages (http://bugs.debian.org/586459).

Ok, that says it is fixed in version 23.2+1-5; Should be fixed in the
next release of Ubuntu.

http://packages.ubuntu.com/natty/emacs23

Thanks for the references.
-- 
Brian May 


emacs crashes

2011-02-17 Thread Brian May
Hello,

I have found certain emails, when I try to view them with the emacs
notmuch client, will cause emacs to crash (segmentation fault). Every
time, 100% reproducible.

A theory of have is maybe the emails are too big and the system can't cope, eg:

brian at aquitard:~$ notmuch show thread:000104db | wc --bytes
943897
brian at aquitard:~$ notmuch show thread:fbab | wc --bytes
3262660
brian at aquitard:~$

These are emailed TSM Operational Reports, entirely ASCII (plus some
non-ASCII rubbish), no attachments, with a large number of log
entries.

An alternative theory is perhaps the non-ASCII rubbish (from weird
filenames some of our users have) is causing problems.

Anybody else experienced similar results?

Thanks
-- 
Brian May 


emacs crashes

2011-02-16 Thread Brian May
Hello,

I have found certain emails, when I try to view them with the emacs
notmuch client, will cause emacs to crash (segmentation fault). Every
time, 100% reproducible.

A theory of have is maybe the emails are too big and the system can't cope, eg:

brian@aquitard:~$ notmuch show thread:000104db | wc --bytes
943897
brian@aquitard:~$ notmuch show thread:fbab | wc --bytes
3262660
brian@aquitard:~$

These are emailed TSM Operational Reports, entirely ASCII (plus some
non-ASCII rubbish), no attachments, with a large number of log
entries.

An alternative theory is perhaps the non-ASCII rubbish (from weird
filenames some of our users have) is causing problems.

Anybody else experienced similar results?

Thanks
-- 
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch