[PATCH] doc: 'rm -f' potential doxygen temporary output file
Some (older) Doxygen versions do not create such a temporary file. --- I was crafting somewhat larger patch where doxygen outputs to _build/.wip... and then the final would be sed(1)'d to the target. But as that would not be the ultimate solution (i.e. sed(1) to yet another intermediate and mv(1) that to the target -- for it to be atomic -- and we don't do that elsewhere, either) I dropped that for this simpler alternative. doc/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Makefile.local b/doc/Makefile.local index 0887413997e6..e7d0bac8f3fb 100644 --- a/doc/Makefile.local +++ b/doc/Makefile.local @@ -70,7 +70,7 @@ install-apidocs: apidocs $(APIMAN): $(dir)/config.dox $(srcdir)/$(dir)/doxygen.cfg $(srcdir)/lib/notmuch.h mkdir -p $(DOCBUILDDIR)/man/man3 doxygen $(DOXYFILE) - rm $(DOCBUILDDIR)/man/man3/_*.3 + rm -f $(DOCBUILDDIR)/man/man3/_*.3 perl -pi -e 's/^[.]RI "\\fI/.RI "\\fP/' $(APIMAN) else apidocs: -- 2.0.0
[PATCH] lib: Fix endless upgrade problem
48db8c8 introduced a disagreement between when
notmuch_database_needs_upgrade returned TRUE and when
notmuch_database_upgrade actually performed an upgrade. As a result,
if a database had a version less than 3, but no new features were
required, notmuch new would call notmuch_database_upgrade to perform
an upgrade, but notmuch_database_upgrade would return immediately
without updating the database version. Hence, the next notmuch new
would do the same, and so on.
Fix this by ensuring that the upgrade-required logic is identical
between the two.
---
lib/database.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/database.cc b/lib/database.cc
index 5116188..a3a7cd3 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
target_features = notmuch->features | NOTMUCH_FEATURES_CURRENT;
new_features = NOTMUCH_FEATURES_CURRENT & ~notmuch->features;
-if (! new_features)
+if (! notmuch_database_needs_upgrade (notmuch))
return NOTMUCH_STATUS_SUCCESS;
if (progress_notify) {
--
2.0.0
How to debug 'ignoring non-mail file' issues
On Mon, Sep 01 2014, Perttu Luukko wrote: > On 2014-08-31 07:41:42, David Bremner wrote: >> Perttu Luukko writes: >> > The vast majority of these ignored mails are not ignored after I >> > transfer them with offlineimap to another computer. I can non-ignore >> > these files probably by copying the renamed file back to the mail >> > server, so this is fixable. Offlineimap shouldn't mess with the file's >> > contents, so is there something that can cause notmuch to ignore a file >> > based on its name? >> >> The most likely cause is that the files are mboxes, whether intentional >> or not. In particular if they start with a "From " (note the lack of :) >> and contain a second "From " at the beginning of a line later in the >> file. In this case something like sed can replace the initial >> "From " with "X-Envelope-From: ". >> >> I agree that the error message could be more informative in this case. > > No, the mails do contain "From: " with the appropriate colon. If I > understood correctly notmuch returns the same "not mail" return code The question here is whether the very first line of the mail file begins with 'From ', not whether *any* of the actual header line starts with 'From: ' IIRC the mails get accepted even the 'From:' header were missing... > both when the essential headers are missing (so the file probably really > isn't mail) and when GMime fails to parse the message. I think it would > be a good idea to give a different warning in the latter case. Sure... :D > > If the files really are ignored because of GMime it also explains why so > much more files are ignored on my mail provider's server than on my > laptop. The server probably has an older version of GMime. I'll upgrade > and see if that makes a difference. > > -- > Perttu Tomi
How to debug 'ignoring non-mail file' issues
On 2014-09-01 09:52:20, Perttu Luukko wrote: > If the files really are ignored because of GMime it also explains why so > much more files are ignored on my mail provider's server than on my > laptop. The server probably has an older version of GMime. I'll upgrade > and see if that makes a difference. Yes, upgrading to GMime 2.6.20 caused all the messages on my server classified as mail. Even more reason to give a separate warning for GMime parse errors. I'll see if my archive of older emails still contains some ignored files. -- Perttu
How to debug 'ignoring non-mail file' issues
On 2014-08-31 07:41:42, David Bremner wrote: > Perttu Luukko writes: > > The vast majority of these ignored mails are not ignored after I > > transfer them with offlineimap to another computer. I can non-ignore > > these files probably by copying the renamed file back to the mail > > server, so this is fixable. Offlineimap shouldn't mess with the file's > > contents, so is there something that can cause notmuch to ignore a file > > based on its name? > > The most likely cause is that the files are mboxes, whether intentional > or not. In particular if they start with a "From " (note the lack of :) > and contain a second "From " at the beginning of a line later in the > file. In this case something like sed can replace the initial > "From " with "X-Envelope-From: ". > > I agree that the error message could be more informative in this case. No, the mails do contain "From: " with the appropriate colon. If I understood correctly notmuch returns the same "not mail" return code both when the essential headers are missing (so the file probably really isn't mail) and when GMime fails to parse the message. I think it would be a good idea to give a different warning in the latter case. If the files really are ignored because of GMime it also explains why so much more files are ignored on my mail provider's server than on my laptop. The server probably has an older version of GMime. I'll upgrade and see if that makes a difference. -- Perttu
How to debug 'ignoring non-mail file' issues
On 2014-08-31 09:46:12, David Bremner wrote:
> Perttu Luukko writes:
>
> > I understand that the list of non-mail files is stored in the
> > notmuch database and the files are completely ignored from there on.
> > This actually makes it harder to debug these kind of issues since
> > the list of ignored mails is only visible on the first invocation of
> > 'notmuch new', unless the files are moved around. Is there some way
> > to extract the list of ignored files from the database for
> > inspection? Maybe 'notmuch new' could have some kind of
> > --unignore-non-mail switch that would reconsider previously ignored
> > files.
>
> I _think_ it should suffice to do something like
>
>find Maildir -type d -exec touch {} \;
>
> to force a rescan
Yes, that indeed works. I'll probably move these ignored files to a
separate folder for inspection.
--
Perttu
Re: How to debug 'ignoring non-mail file' issues
On 2014-08-31 07:41:42, David Bremner wrote: Perttu Luukko perttu.luu...@iki.fi writes: The vast majority of these ignored mails are not ignored after I transfer them with offlineimap to another computer. I can non-ignore these files probably by copying the renamed file back to the mail server, so this is fixable. Offlineimap shouldn't mess with the file's contents, so is there something that can cause notmuch to ignore a file based on its name? The most likely cause is that the files are mboxes, whether intentional or not. In particular if they start with a From (note the lack of :) and contain a second From at the beginning of a line later in the file. In this case something like sed can replace the initial From with X-Envelope-From: . I agree that the error message could be more informative in this case. No, the mails do contain From: with the appropriate colon. If I understood correctly notmuch returns the same not mail return code both when the essential headers are missing (so the file probably really isn't mail) and when GMime fails to parse the message. I think it would be a good idea to give a different warning in the latter case. If the files really are ignored because of GMime it also explains why so much more files are ignored on my mail provider's server than on my laptop. The server probably has an older version of GMime. I'll upgrade and see if that makes a difference. -- Perttu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: How to debug 'ignoring non-mail file' issues
On 2014-09-01 09:52:20, Perttu Luukko wrote: If the files really are ignored because of GMime it also explains why so much more files are ignored on my mail provider's server than on my laptop. The server probably has an older version of GMime. I'll upgrade and see if that makes a difference. Yes, upgrading to GMime 2.6.20 caused all the messages on my server classified as mail. Even more reason to give a separate warning for GMime parse errors. I'll see if my archive of older emails still contains some ignored files. -- Perttu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: How to debug 'ignoring non-mail file' issues
On Mon, Sep 01 2014, Perttu Luukko perttu.luu...@iki.fi wrote: On 2014-08-31 07:41:42, David Bremner wrote: Perttu Luukko perttu.luu...@iki.fi writes: The vast majority of these ignored mails are not ignored after I transfer them with offlineimap to another computer. I can non-ignore these files probably by copying the renamed file back to the mail server, so this is fixable. Offlineimap shouldn't mess with the file's contents, so is there something that can cause notmuch to ignore a file based on its name? The most likely cause is that the files are mboxes, whether intentional or not. In particular if they start with a From (note the lack of :) and contain a second From at the beginning of a line later in the file. In this case something like sed can replace the initial From with X-Envelope-From: . I agree that the error message could be more informative in this case. No, the mails do contain From: with the appropriate colon. If I understood correctly notmuch returns the same not mail return code The question here is whether the very first line of the mail file begins with 'From ', not whether *any* of the actual header line starts with 'From: ' IIRC the mails get accepted even the 'From:' header were missing... both when the essential headers are missing (so the file probably really isn't mail) and when GMime fails to parse the message. I think it would be a good idea to give a different warning in the latter case. Sure... :D If the files really are ignored because of GMime it also explains why so much more files are ignored on my mail provider's server than on my laptop. The server probably has an older version of GMime. I'll upgrade and see if that makes a difference. -- Perttu Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] doc: 'rm -f' potential doxygen temporary output file
Some (older) Doxygen versions do not create such a temporary file. --- I was crafting somewhat larger patch where doxygen outputs to _build/.wip... and then the final would be sed(1)'d to the target. But as that would not be the ultimate solution (i.e. sed(1) to yet another intermediate and mv(1) that to the target -- for it to be atomic -- and we don't do that elsewhere, either) I dropped that for this simpler alternative. doc/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Makefile.local b/doc/Makefile.local index 0887413997e6..e7d0bac8f3fb 100644 --- a/doc/Makefile.local +++ b/doc/Makefile.local @@ -70,7 +70,7 @@ install-apidocs: apidocs $(APIMAN): $(dir)/config.dox $(srcdir)/$(dir)/doxygen.cfg $(srcdir)/lib/notmuch.h mkdir -p $(DOCBUILDDIR)/man/man3 doxygen $(DOXYFILE) - rm $(DOCBUILDDIR)/man/man3/_*.3 + rm -f $(DOCBUILDDIR)/man/man3/_*.3 perl -pi -e 's/^[.]RI \\fI/.RI \\fP/' $(APIMAN) else apidocs: -- 2.0.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib: Fix endless upgrade problem
48db8c8 introduced a disagreement between when
notmuch_database_needs_upgrade returned TRUE and when
notmuch_database_upgrade actually performed an upgrade. As a result,
if a database had a version less than 3, but no new features were
required, notmuch new would call notmuch_database_upgrade to perform
an upgrade, but notmuch_database_upgrade would return immediately
without updating the database version. Hence, the next notmuch new
would do the same, and so on.
Fix this by ensuring that the upgrade-required logic is identical
between the two.
---
lib/database.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/database.cc b/lib/database.cc
index 5116188..a3a7cd3 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
target_features = notmuch-features | NOTMUCH_FEATURES_CURRENT;
new_features = NOTMUCH_FEATURES_CURRENT ~notmuch-features;
-if (! new_features)
+if (! notmuch_database_needs_upgrade (notmuch))
return NOTMUCH_STATUS_SUCCESS;
if (progress_notify) {
--
2.0.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: Fix endless upgrade problem
On Tue, Sep 02 2014, Austin Clements amdra...@mit.edu wrote:
48db8c8 introduced a disagreement between when
notmuch_database_needs_upgrade returned TRUE and when
notmuch_database_upgrade actually performed an upgrade. As a result,
if a database had a version less than 3, but no new features were
required, notmuch new would call notmuch_database_upgrade to perform
an upgrade, but notmuch_database_upgrade would return immediately
without updating the database version. Hence, the next notmuch new
would do the same, and so on.
Fix this by ensuring that the upgrade-required logic is identical
between the two.
LGTM
Tomi
---
lib/database.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/database.cc b/lib/database.cc
index 5116188..a3a7cd3 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
target_features = notmuch-features | NOTMUCH_FEATURES_CURRENT;
new_features = NOTMUCH_FEATURES_CURRENT ~notmuch-features;
-if (! new_features)
+if (! notmuch_database_needs_upgrade (notmuch))
return NOTMUCH_STATUS_SUCCESS;
if (progress_notify) {
--
2.0.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail
On 08/30/2014 03:37 AM, Jani Nikula wrote: I'm inclined to think this is a bug in message-mode. I agree it's a bug in message-mode, not in notmuch itself. As a workaround of sorts, I'd suggest not messing with the #secure tag manually. Instead, you can use mml-secure-message-sign and mml-secure-message-sign-encrypt to change the mode. the keybindings for those are usually: C-c RET s p C-c RET c p hth, --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
