[PATCH] [EMACS] Adjust notmuch-crypto gpg call-process function

[John Byrnes]

Hey Notmuchers,

I'm running the latest NixOS and noticed that the system does not
install gpgv1 by default. This means that the only gpg binary available
is the gpg2 binary.

I found that notmuch-crypto.el hardcodes the GnuPG binary as gpg.  I
thought it might make more sense to rely on the setting provided by 
EasyPG to locate the correct GnuPG binary.

The patch is quite simple - it just replaces "gpg" with the
epg-gpg-program variable in each place it's used.

-   (call-process "gpg" nil t t "--list-keys" fingerprint))
+   (call-process epg-gpg-program nil t t "--list-keys" fingerprint))

I tested the changes locally and it seems to work OK. 

Happy New Year!
John

From 88097c2618335bb82b1e1fa197a51f280b5bc15f Mon Sep 17 00:00:00 2001
From: John Byrnes 
Date: Tue, 3 Jan 2017 21:37:49 -0500
Subject: [PATCH] Adjusted notmuch-crypto gpg call-process function to respect
 the GPG program set by the EasyPG epg-gpg-program variable.

This is to correct a problem observed on NixOS where only gpg2 is
installed by default. The Notmuch Emacs frontend fails when trying to
access someone's key to verify their signature when it cannot find the
GPG binary.
---
 emacs/notmuch-crypto.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index 68a7e9f..c5111fd 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -140,7 +140,7 @@ mode."
 (with-selected-window window
   (with-current-buffer buffer
 	(goto-char (point-max))
-	(call-process "gpg" nil t t "--list-keys" fingerprint))
+	(call-process epg-gpg-program nil t t "--list-keys" fingerprint))
   (recenter -1
 
 (defun notmuch-crypto-sigstatus-error-callback (button)
@@ -151,9 +151,9 @@ mode."
 (with-selected-window window
   (with-current-buffer buffer
 	(goto-char (point-max))
-	(call-process "gpg" nil t t "--recv-keys" keyid)
+	(call-process epg-gpg-program nil t t "--recv-keys" keyid)
 	(insert "\n")
-	(call-process "gpg" nil t t "--list-keys" keyid))
+	(call-process epg-gpg-program nil t t "--list-keys" keyid))
   (recenter -1))
 (notmuch-show-refresh-view)))
 
-- 
2.10.0



signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] tests: add compatibility layer

[Mikhail]

On 18:48 03-Jan 2017 Tomi Ollila wrote:


 # Finally, after everything configured, inform the user how to continue.
diff --git a/test/README b/test/README
index 104a120e..8376616f 100644
--- a/test/README
+++ b/test/README
@@ -33,6 +33,12 @@ chosen directory to your PATH before running the tests.

 e.g. env PATH=/opt/gnu/bin:$PATH make test

+For FreeBSD you will need to install coreutils, which provides GNU
+versions of basic utils like 'date' or 'wc'. Also you will need to
+install latest gdb from ports or packages and provide path to it in
+NOTMUCH_GDB variable before executing the tests, native FreeBSD gdb will
+not work.


I think this is a bit too strong statement; one should not *need* to
install such a bloaty beast as a GNU coreutils to use instead of nice
native utils system is shipped with; IMO this should mention that
installing coreutils (in a way that these g-prefixed commands appear
in PATH!) may improve the success of test run... or something.


GNU utils is what developers use and what majority of users are using.
Tests, in my view, have been created to test functionality of notmuch,
and if user want to be sure that notmuch is working as expected - he
should use the tools developers were using. There is not much difference
anyway - mostly spacing in 'wc' or column number in 'base64', or '-i'
handling in 'sed', or 'date' flags.

Improving success rate is not a goal, goal - 100% test passing, as on
Linux. To get closer to 100% - install coreutils, if it isn't 100% -
there is a problem - it has to be investigated.

If you don't want 100% passage - there is a difference in our goals and
we are talking about different things.


+date () { gdate "$@"; }
+base64 () { gbase64 "$@"; }
+gdb () { $NOTMUCH_GDB "$@"; }
+wc () { gwc "$@"; }
+sed () { gsed "$@"; }
+sha256sum () { gsha256sum "$@"; }


The above is currently problematic when one does not install GNU coreutils;
tests will fail more when e.g. `gwc` does not exist but `wc` does. When I
tested with this patch a few days ago, test failure count increased from
~70 to ~140. That was the quickly written mkwrp() for...



I use my freebsd KVM virtual machine for e.g. portability testing; things
that work on freebsd (in addition to linux) have more chance to work on
netbsd, openbsd, macos, solaris, openindiana. With the above applied
verbatim I would always need to remember to dump the "compatibility file"
before running tests...

To fix the above, one could use (possibly better written) mkwrap()
implementation, or do all of those by hand: e.g.

if command -v gdate >/dev/null; then date () { gdate "$@"; }; fi
if command -v gbase64 >/dev/null; then base64 () { gbase64 "$@"; }; fi
...

the gdb wrapper could be dumped completely and have the following in
test-lib-common.sh:

: ${NOTMUCH_GDB:-gdb}

and then replace all (the few) gdb in code with $NOTMUCH_GDB (did not use
quotes like "$NOTMUCH_GDB" so that one can hack args there.

but if the gdb function were there, then the following might work:

gdb () { command ${NOTMUCH_GDB:-gdb} "$@"; }


My only concern is a simplicity, if installing coreutils and "alias'ing"
native 'wc' to 'gwc' solves the problem - why to create more entities?
In real world, if you have gwc - you have gbase64, I can't imagine any
exceptions.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: converting attachments to text

[Brian Sniffen]

Sure!  Here's what I use for docx, and I think it could be adapted to
pdf with pdftotext or whatever you're already using there.  You need a
small shell script that reads from STDIN, writes to a file, and calls
pandoc or pdftotext or whatever, like ~/bin/antiwordx:

#!/bin/sh

tmpfile=$(mktemp /tmp/antiwordx.XX.docx)
trap 'rm -f -- "$tmpfile"' INT TERM HUP EXIT
cat > "$tmpfile"
pandoc --normalize -r docx -w markdown "$tmpfile"

You need a small handler function to call it from Elisp---see attached
file `inline-docx.el`, which assumed you have both the old `antiword`
for old-style .doc files and pandoc for new-style `docx`.

I apologize for the roughness of the code; it should probably use
customizable paths for pandoc and such.

-Brian



inline-docx.el
Description: application/emacs-lisp


Bart Bunting  writes:

> Hi,
>
> Just looking for some pointers.
>
> I have to deal with quite a few emails with attachments in either pdf or
> word format.
>
> I'm on a mac so can use applescript or something pdftotext or similar to
> convert them to text.
>
> I'm blind so use emacspeak as my primary interface.  Having an easy way
> to convert the notmuch attachments to text other than saving to a file
> and processing them would greatly speed up my workflow.
>
> Is there something in existance already to do this sort of thing?
>
> I have a little rudimentary lisp skill so can hack something up if
> someone can give me some pointers on a direction to head in.
>
> Any advice appreciated.
>
> Kind regards
>
> Bart
>
> Kind regards
> Bart
> -- 
>
> Bart Bunting - URSYS
> PH: 02 87452811
> Mbl: 0409560005
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] tests: add compatibility layer

[Tomi Ollila]

On Tue, Jan 03 2017, Tomi Ollila  wrote:

> On Mon, Jan 02 2017, mp39...@gmail.com wrote:
>
>> From: Mikhail 
>>
>> Make test-lib-common.sh load test-lib-<$PLATFORM>.sh to create
>> additional shim for platform specifics.
>>
>> Use test-lib-FREEBSD.sh to call GNU utilities instead of native ones.
>
> Ok, now I've git a bit of time to read and respond; If I'd read earlier
> and not had time to respone, I'd have thought this issue too much in
> between... so let's quickly process this :D
>
>> ---
>>  configure| 3 +++
>>  test/README  | 6 ++
>>  test/test-lib-FREEBSD.sh | 8 
>>  test/test-lib-common.sh  | 5 +
>>  4 files changed, 22 insertions(+)
>>  create mode 100644 test/test-lib-FREEBSD.sh
>>
>> diff --git a/configure b/configure
>> index 72db26df..7ba9b9eb 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1203,6 +1203,9 @@ NOTMUCH_PYTHON=${python}
>>  # Are the ruby development files (and ruby) available? If not skip
>>  # building/testing ruby bindings.
>>  NOTMUCH_HAVE_RUBY_DEV=${have_ruby_dev}
>> +
>> +# Platform we are run on
>> +PLATFORM=${platform}
>
> This change looks good.
>
>>  EOF
>>  
>>  # Finally, after everything configured, inform the user how to continue.
>> diff --git a/test/README b/test/README
>> index 104a120e..8376616f 100644
>> --- a/test/README
>> +++ b/test/README
>> @@ -33,6 +33,12 @@ chosen directory to your PATH before running the tests.
>>  
>>  e.g. env PATH=/opt/gnu/bin:$PATH make test
>>  
>> +For FreeBSD you will need to install coreutils, which provides GNU
>> +versions of basic utils like 'date' or 'wc'. Also you will need to
>> +install latest gdb from ports or packages and provide path to it in
>> +NOTMUCH_GDB variable before executing the tests, native FreeBSD gdb will
>> +not work.
>
> I think this is a bit too strong statement; one should not *need* to
> install such a bloaty beast as a GNU coreutils to use instead of nice
> native utils system is shipped with; IMO this should mention that
> installing coreutils (in a way that these g-prefixed commands appear
> in PATH!) may improve the success of test run... or something. 
>
> Also, IMHO, native FreeBSD gdb does not work is much nicer than stating
> it will not work -- but that may just be my feeling of how it sounds...


What I mean that the IMO the tone should more like suggestive than
impeartive -- it looks more like users have a choice...

>
> ...
>
>> +
>>  Running Tests
>>  -
>>  The easiest way to run tests is to say "make test", (or simply run the
>> diff --git a/test/test-lib-FREEBSD.sh b/test/test-lib-FREEBSD.sh
>> new file mode 100644
>> index ..b8039705
>> --- /dev/null
>> +++ b/test/test-lib-FREEBSD.sh
>> @@ -0,0 +1,8 @@
>> +# Use GNU Coreutils instead of a native BSD utils
>> +
>> +date () { gdate "$@"; }
>> +base64 () { gbase64 "$@"; }
>> +gdb () { $NOTMUCH_GDB "$@"; }
>> +wc () { gwc "$@"; }
>> +sed () { gsed "$@"; }
>> +sha256sum () { gsha256sum "$@"; }
>
> The above is currently problematic when one does not install GNU coreutils;
> tests will fail more when e.g. `gwc` does not exist but `wc` does. When I
> tested with this patch a few days ago, test failure count increased from
> ~70 to ~140. That was the quickly written mkwrp() for...
>
> I use my freebsd KVM virtual machine for e.g. portability testing; things
> that work on freebsd (in addition to linux) have more chance to work on
> netbsd, openbsd, macos, solaris, openindiana. With the above applied
> verbatim I would always need to remember to dump the "compatibility file"
> before running tests...
>
> To fix the above, one could use (possibly better written) mkwrap()
> implementation, or do all of those by hand: e.g.
>
> if command -v gdate >/dev/null; then date () { gdate "$@"; }; fi
> if command -v gbase64 >/dev/null; then base64 () { gbase64 "$@"; }; fi
> ...
>
> the gdb wrapper could be dumped completely and have the following in
> test-lib-common.sh:
>
> : ${NOTMUCH_GDB:=gdb}
>

Sneaky fix ;)

> and then replace all (the few) gdb in code with $NOTMUCH_GDB (did not use
> quotes like "$NOTMUCH_GDB" so that one can hack args there.
>
> but if the gdb function were there, then the following might work:
>
> gdb () { command ${NOTMUCH_GDB:-gdb} "$@"; }
>
>
>> diff --git a/test/test-lib-common.sh b/test/test-lib-common.sh
>> index 03ef1d2d..1c8d7f6e 100644
>> --- a/test/test-lib-common.sh
>> +++ b/test/test-lib-common.sh
>> @@ -66,6 +66,11 @@ export LD_LIBRARY_PATH
>>  # configure output
>>  . $notmuch_path/sh.config || exit 1
>>  
>> +# load OS specifics
>> +if [ -e ./test-lib-$PLATFORM.sh ]; then
>> +. ./test-lib-$PLATFORM.sh
>> +fi
>> +
>
> This change looks good.

actually, the second line, to be consistent:

+   . ./test-lib-$PLATFORM.sh || exit 1

>
> Tomi
>



>>  if test -n "$valgrind"
>>  then
>>  make_symlink () {
>> -- 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/n

Re: [PATCH] tests: add compatibility layer

[Tomi Ollila]

On Tue, Jan 03 2017, Tomi Ollila  wrote:

>
> To fix the above, one could use (possibly better written) mkwrap()
> implementation, or do all of those by hand: e.g.
>
> if command -v gdate >/dev/null; then date () { gdate "$@"; }; fi
> if command -v gbase64 >/dev/null; then base64 () { gbase64 "$@"; }; fi
> ...
>
> the gdb wrapper could be dumped completely and have the following in
> test-lib-common.sh:
>
> : ${NOTMUCH_GDB:-gdb}

Argh, the above would not work, but this: 

: ${NOTMUCH_GDB:=gdb}

emphasis++ ftw \o/ ! ;)

Tomi

>
> and then replace all (the few) gdb in code with $NOTMUCH_GDB (did not use
> quotes like "$NOTMUCH_GDB" so that one can hack args there.
>
> but if the gdb function were there, then the following might work:
>
> gdb () { command ${NOTMUCH_GDB:-gdb} "$@"; }
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] tests: add compatibility layer

[Tomi Ollila]

On Mon, Jan 02 2017, mp39...@gmail.com wrote:

> From: Mikhail 
>
> Make test-lib-common.sh load test-lib-<$PLATFORM>.sh to create
> additional shim for platform specifics.
>
> Use test-lib-FREEBSD.sh to call GNU utilities instead of native ones.

Ok, now I've git a bit of time to read and respond; If I'd read earlier
and not had time to respone, I'd have thought this issue too much in
between... so let's quickly process this :D

> ---
>  configure| 3 +++
>  test/README  | 6 ++
>  test/test-lib-FREEBSD.sh | 8 
>  test/test-lib-common.sh  | 5 +
>  4 files changed, 22 insertions(+)
>  create mode 100644 test/test-lib-FREEBSD.sh
>
> diff --git a/configure b/configure
> index 72db26df..7ba9b9eb 100755
> --- a/configure
> +++ b/configure
> @@ -1203,6 +1203,9 @@ NOTMUCH_PYTHON=${python}
>  # Are the ruby development files (and ruby) available? If not skip
>  # building/testing ruby bindings.
>  NOTMUCH_HAVE_RUBY_DEV=${have_ruby_dev}
> +
> +# Platform we are run on
> +PLATFORM=${platform}

This change looks good.

>  EOF
>  
>  # Finally, after everything configured, inform the user how to continue.
> diff --git a/test/README b/test/README
> index 104a120e..8376616f 100644
> --- a/test/README
> +++ b/test/README
> @@ -33,6 +33,12 @@ chosen directory to your PATH before running the tests.
>  
>  e.g. env PATH=/opt/gnu/bin:$PATH make test
>  
> +For FreeBSD you will need to install coreutils, which provides GNU
> +versions of basic utils like 'date' or 'wc'. Also you will need to
> +install latest gdb from ports or packages and provide path to it in
> +NOTMUCH_GDB variable before executing the tests, native FreeBSD gdb will
> +not work.

I think this is a bit too strong statement; one should not *need* to
install such a bloaty beast as a GNU coreutils to use instead of nice
native utils system is shipped with; IMO this should mention that
installing coreutils (in a way that these g-prefixed commands appear
in PATH!) may improve the success of test run... or something. 

Also, IMHO, native FreeBSD gdb does not work is much nicer than stating
it will not work -- but that may just be my feeling of how it sounds...

...

> +
>  Running Tests
>  -
>  The easiest way to run tests is to say "make test", (or simply run the
> diff --git a/test/test-lib-FREEBSD.sh b/test/test-lib-FREEBSD.sh
> new file mode 100644
> index ..b8039705
> --- /dev/null
> +++ b/test/test-lib-FREEBSD.sh
> @@ -0,0 +1,8 @@
> +# Use GNU Coreutils instead of a native BSD utils
> +
> +date () { gdate "$@"; }
> +base64 () { gbase64 "$@"; }
> +gdb () { $NOTMUCH_GDB "$@"; }
> +wc () { gwc "$@"; }
> +sed () { gsed "$@"; }
> +sha256sum () { gsha256sum "$@"; }

The above is currently problematic when one does not install GNU coreutils;
tests will fail more when e.g. `gwc` does not exist but `wc` does. When I
tested with this patch a few days ago, test failure count increased from
~70 to ~140. That was the quickly written mkwrp() for...

I use my freebsd KVM virtual machine for e.g. portability testing; things
that work on freebsd (in addition to linux) have more chance to work on
netbsd, openbsd, macos, solaris, openindiana. With the above applied
verbatim I would always need to remember to dump the "compatibility file"
before running tests...

To fix the above, one could use (possibly better written) mkwrap()
implementation, or do all of those by hand: e.g.

if command -v gdate >/dev/null; then date () { gdate "$@"; }; fi
if command -v gbase64 >/dev/null; then base64 () { gbase64 "$@"; }; fi
...

the gdb wrapper could be dumped completely and have the following in
test-lib-common.sh:

: ${NOTMUCH_GDB:-gdb}

and then replace all (the few) gdb in code with $NOTMUCH_GDB (did not use
quotes like "$NOTMUCH_GDB" so that one can hack args there.

but if the gdb function were there, then the following might work:

gdb () { command ${NOTMUCH_GDB:-gdb} "$@"; }


> diff --git a/test/test-lib-common.sh b/test/test-lib-common.sh
> index 03ef1d2d..1c8d7f6e 100644
> --- a/test/test-lib-common.sh
> +++ b/test/test-lib-common.sh
> @@ -66,6 +66,11 @@ export LD_LIBRARY_PATH
>  # configure output
>  . $notmuch_path/sh.config || exit 1
>  
> +# load OS specifics
> +if [ -e ./test-lib-$PLATFORM.sh ]; then
> + . ./test-lib-$PLATFORM.sh
> +fi
> +

This change looks good.


Tomi

>  if test -n "$valgrind"
>  then
>   make_symlink () {
> -- 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Ignoring nmh mail files

[Axel Jantsch]

David,
I have uploaded the same email as file to dropbox:

https://www.dropbox.com/s/i95dbadddmekau9/151?dl=0

Best,
Axel

> On Mon, 02 Jan 2017 16:43:30 +, David Edmondson  said:

> On Mon, Jan 02 2017, Axel Jantsch wrote:

>> Hi David,
>> Thanks for your quick response.
>> 
>> The double From lines do not seem to be the problem, because when I
>> remove one of them, no change.
>> 
>> Also, many problem mails do not have double From lines, like the one I
>> attach below

> If I save the attached message and then add it to my database, it works
> fine.

> Could you share an exact copy of the failing message as a file
> somewhere? It's possible that whatever is wrong with it was fixed during
> the attach/detach process.

>> So again, any idea is highly welcome!
>> --Axel
>> 
>>> On Sun, 01 Jan 2017 19:26:07 +, David Edmondson  
said:
>> 
>> > On Thu, Dec 29 2016, Axel Jantsch wrote:
>> >> Hi,
>> >> 
>> >> I try to build a notmuch database from my nmh files.
>> >> 
>> >> I have about 220k emails and about half of them is ignored by
>> >> notmach new with the note, e.g.:
>> >> 
>> >> Note: Ignoring non-mail file: /home/jantsch/Mail/ARTEMIS-MPSOC/1
>> >> 
>> >> Here is the header of that particular email:
>> >> 
>> >> 
=
>> >> From nobody@nowhere  Sun Aug 02 21:21:17 2009
>> >> From nobody@nowhere  Sun Aug 02 21:21:17 2009
>> 
>> > Maybe the double "From " lines?
>> 
>> >> From: "Axel Jantsch" 
>> >> Organization: Royal Institute of Technology
>> >> To: Joe.Someone 
>> >> Subject: Re: Artemis and MPSOC 
>> >> In-Reply-To: Message from Joe.Someone 
>> >> of "Tue, 09 Jan 2007 15:10:34 +0100."
>> >> <009c01c733f7$edea4340$7766e882@amdht> 
>> >> X-Image-URL: http://www.it.kth.se/~axel/axel.png
>> >> X-Mailer: MH-E 7.83; nmh 1.0.4; GNU Emacs 21.2.1
>> >> MIME-Version: 1.0
>> >> Content-Type: text/plain; charset=us-ascii
>> >> Content-Transfer-Encoding: 8bit
>> >> Date: Wed, 10 Jan 2007 15:47:09 +0100
>> >> Sender: a...@bee.imit.kth.se
>> >> 
>> >> 
>> >> Joe, 
>> >> 
>> >> ...
>> >> 
>> >> 
=
>> >> 
>> >> Any idea why so many emails are not recognized by notmuch?
>> >> 
>> >> Best,
>> >> Axel
>> >> 
>> >> 
>> >> -- 
>> >> Axel Jantsch, Prof. of Systems on Chip
>> >> TU Wien
>> >> Gusshausstrasse 27-29/384, 1040 Vienna, Austria
>> >> Phone: +43 1 58801 38415
>> >> Email: axel.jant...@tuwien.ac.at
>> >> Web: www.ict.tuwien.ac.at
>> >> 
>> >> ___
>> >> notmuch mailing list
>> >> notmuch@notmuchmail.org
>> >> https://notmuchmail.org/mailman/listinfo/notmuch
>> 
>> 
>> -- 
>> Axel Jantsch, Prof. of Systems on Chip
>> TU Wien
>> Gusshausstrasse 27-29/384, 1040 Vienna, Austria
>> Phone: +43 1 58801 38415
>> Email: axel.jant...@tuwien.ac.at
>> Web: www.ict.tuwien.ac.at
>> 
>> From: Amir Rahmani 
>> Subject: The Dark Side of Silicon
>> To: axel.jant...@tuwien.ac.at, 'Ahmed Hemani' , 
ha...@kth.se, Pasi Liljeberg 
>> Date: Sat, 31 Dec 2016 14:05:16 -0800
>> 
>> Dear all,
>> 
>> 
>> 
>> The eBook has just become available online from the following link:
>> 
>> 
>> 
>> http://link.springer.com/book/10.1007/978-3-319-31596-6
>> 
>> 
>> 
>> Best regards,
>> 
>> Amir
>> 
>> 
>> 
>> 
>> 
>> Amir M. Rahmani, PhD (Tech.), MBA
>> 
>> 
>> 
>> Marie Curie Global Fellow
>> 
>> University of California Irvine, USA
>> 
>> Vienna University of Technology (TU Wien), Austria
>> 
>> 
>> 
>> Adjunct Professor (Docent)
>> 
>> Department of Information Technology
>> 
>> University of Turku, Finland
>> 
>> 
>> 
>>  http://www.ics.uci.edu/~amirr1/
>> 
>> 


-- 
Axel Jantsch, Prof. of Systems on Chip
TU Wien
Gusshausstrasse 27-29/384, 1040 Vienna, Austria
Phone: +43 1 58801 38415
Email: axel.jant...@tuwien.ac.at
Web: www.ict.tuwien.ac.at

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

Re: Ignoring nmh mail files

[Axel Jantsch]

Hi David,
Thanks for your quick response.

The double From lines do not seem to be the problem, because when I
remove one of them, no change.

Also, many problem mails do not have double From lines, like the one I
attach below

So again, any idea is highly welcome!
--Axel

> On Sun, 01 Jan 2017 19:26:07 +, David Edmondson  said:

> On Thu, Dec 29 2016, Axel Jantsch wrote:
>> Hi,
>> 
>> I try to build a notmuch database from my nmh files.
>> 
>> I have about 220k emails and about half of them is ignored by
>> notmach new with the note, e.g.:
>> 
>> Note: Ignoring non-mail file: /home/jantsch/Mail/ARTEMIS-MPSOC/1
>> 
>> Here is the header of that particular email:
>> 
>> 
=
>> From nobody@nowhere  Sun Aug 02 21:21:17 2009
>> From nobody@nowhere  Sun Aug 02 21:21:17 2009

> Maybe the double "From " lines?

>> From: "Axel Jantsch" 
>> Organization: Royal Institute of Technology
>> To: Joe.Someone 
>> Subject: Re: Artemis and MPSOC 
>> In-Reply-To: Message from Joe.Someone 
>> of "Tue, 09 Jan 2007 15:10:34 +0100."
>> <009c01c733f7$edea4340$7766e882@amdht> 
>> X-Image-URL: http://www.it.kth.se/~axel/axel.png
>> X-Mailer: MH-E 7.83; nmh 1.0.4; GNU Emacs 21.2.1
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=us-ascii
>> Content-Transfer-Encoding: 8bit
>> Date: Wed, 10 Jan 2007 15:47:09 +0100
>> Sender: a...@bee.imit.kth.se
>> 
>> 
>> Joe, 
>> 
>> ...
>> 
>> 
=
>> 
>> Any idea why so many emails are not recognized by notmuch?
>> 
>> Best,
>> Axel
>> 
>> 
>> -- 
>> Axel Jantsch, Prof. of Systems on Chip
>> TU Wien
>> Gusshausstrasse 27-29/384, 1040 Vienna, Austria
>> Phone: +43 1 58801 38415
>> Email: axel.jant...@tuwien.ac.at
>> Web: www.ict.tuwien.ac.at
>> 
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch


-- 
Axel Jantsch, Prof. of Systems on Chip
TU Wien
Gusshausstrasse 27-29/384, 1040 Vienna, Austria
Phone: +43 1 58801 38415
Email: axel.jant...@tuwien.ac.at
Web: www.ict.tuwien.ac.at

--- Begin Message ---
Dear all,

 

The eBook has just become available online from the following link:

 

http://link.springer.com/book/10.1007/978-3-319-31596-6

 

Best regards,

Amir

 



Amir M. Rahmani, PhD (Tech.), MBA

 

Marie Curie Global Fellow

University of California Irvine, USA

Vienna University of Technology (TU Wien), Austria

 

Adjunct Professor (Docent)

Department of Information Technology

University of Turku, Finland

 

  http://www.ics.uci.edu/~amirr1/

 

--- End Message ---
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Ignoring nmh mail files

[Axel Jantsch]

I use notmuch version 0.17
on Ubuntu 15.04 which runs on a Virtual box with Windows as a host OS.

I use libgmime-2.6-0, but no binaries.
What else should I check?

How can I see, which files are included in the database which are not?

Best,
Axel


> On Mon, 02 Jan 2017 19:14:39 +, David Edmondson  said:

> On Mon, Jan 02 2017, Axel Jantsch wrote:

>> David,
>> I have uploaded the same email as file to dropbox:
>> 
>> https://www.dropbox.com/s/i95dbadddmekau9/151?dl=0

> This file also works fine for me.

> What version of notmuch, gmime, etc. are you using?


-- 
Axel Jantsch, Prof. of Systems on Chip
TU Wien
Gusshausstrasse 27-29/384, 1040 Vienna, Austria
Phone: +43 1 58801 38415
Email: axel.jant...@tuwien.ac.at
Web: www.ict.tuwien.ac.at

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

Re: Ignoring nmh mail files

[David Bremner]

David Edmondson  writes:

> On Tue, Jan 03 2017, Axel Jantsch wrote:
>
>> I use notmuch version 0.17
>> on Ubuntu 15.04 which runs on a Virtual box with Windows as a host OS.
>>
>> I use libgmime-2.6-0, but no binaries.
>> What else should I check?
>
> 0.17 is pretty old - it may be that someone will remember having fixed a
> bug since then (we're on 0.23 now!).
>
> Can anyone think of something immediately relevant?
>

Yes, there are several fixes related to mboxes since 0.17. It won't help
with double "From " lines, but it will tolerate a single "From " line in
current notmuch.

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

Re: Ignoring nmh mail files

[David Edmondson]

On Tue, Jan 03 2017, Axel Jantsch wrote:

> I use notmuch version 0.17
> on Ubuntu 15.04 which runs on a Virtual box with Windows as a host OS.
>
> I use libgmime-2.6-0, but no binaries.
> What else should I check?

0.17 is pretty old - it may be that someone will remember having fixed a
bug since then (we're on 0.23 now!).

Can anyone think of something immediately relevant?

> How can I see, which files are included in the database which are not?

I just saw that it was successfully added (by `notmuch new') and then
the message appears in my tag:inbox search.

`notmuch search --output=files "*"' should output all of the files known
to the database.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch