Bug#1021578: notmuch --config='' setup: "g_rename() failed: No such file or directory"

[Tomi Ollila]

On Tue, Oct 11 2022, Jakub Wilk wrote:

> Package: notmuch
> Version: 0.37-1
> Severity: minor
>
> I did this by accident[*]:
>
> $ notmuch --config='' setup
> Welcome to notmuch!
> [...]
> Your full name [Jakub Wilk]:
> Your primary email address [jwilk@localhost]:
> Additional email address [Press 'Enter' if none]:
> Top-level directory of your email archive [/tmp/tmp.GKlsDiiCm1]:
> Tags to apply to all new messages (separated by spaces) [ unread inbox]:
> Tags to exclude when searching messages (separated by spaces) []:
> Error saving configuration to : Failed to rename file “.IRITT1” to “”: 
> g_rename() failed: No such file or directory
>
> Can we have a more helpful error message?
> Maybe:
>
> "notmuch --config='' setup" does not make sense, you fool.
>
> Or:
>
> --config='' is not supported for "notmuch setup".

Note that --config='', --config="", --config=, '--config=',
'--config=' (and many combinations of these, but not
e.g. --config="''" ;) are the same, when entered from shell
command line  -- so perhaps the error message somehow shows that
empty file is not suitable (nor '.' nor '..', in which case it
should first try something to figure out that the filename is
suitable (but preferably not creating it first...)

Tomi


>
>
> [*] I had no idea what I was doing. What I really wanted was probably 
> "notmuch --config='' new".
>
>
> -- System Information:
> Architecture: i386
>
> Versions of packages notmuch depends on:
> ii  libnotmuch5 0.37-1
> ii  libc6   2.35-3
> ii  libglib2.0-02.74.0-2
> ii  libgmime-3.0-0  3.2.13+dfsg-2
> ii  libtalloc2  2.3.4-1
> ii  zlib1g  1:1.2.11.dfsg-4.1
>
> -- 
> Jakub Wilk
>
> ___
> notmuch mailing list -- notm...@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

Bug#976934: [PATCH] build/docs: move docstring prereq to file targets

[Tomi Ollila]

On Wed, Dec 09 2020, David Bremner wrote:

> Under a sufficiently high level of parallelism [1] there seems to be a
> a race condition that allows sphinx-build to start running before the
> docstrings are extracted. This change moves the docstring stamp from
> the phony targets sphinx-html and sphinx-info to the file targets that
> they depend on. I'm not sure why this makes things better, but I am
> fairly confident it does not make things worse, and experimentally it
> seems to eliminate the race condition.

Good enough for me if this helps. I also don't see reason why that would
make things better (and probably not things worse), just that I got
headache reading that Makefile ;) (and, for example, these particular
targets mentioned would not need to be marked .PHONY...)

I'd suggest to monitor the behaviour for a while and if things are
consistently better then merge -- such a things when we don't know
enough experience may be enough (or someone(tm) could try to parse make
debug logs ;/) -- or someone(tm) may tell us why that heleps :D

Tomi

>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934
> ---
>  doc/Makefile.local | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/Makefile.local b/doc/Makefile.local
> index 60bd7184..f476d1da 100644
> --- a/doc/Makefile.local
> +++ b/doc/Makefile.local
> @@ -43,7 +43,7 @@ INFO_INFO_FILES := $(INFO_TEXI_FILES:.texi=.info)
>   rm -f $@ && gzip --no-name --stdout $^ > $@
>  
>  ifeq ($(WITH_EMACS),1)
> -$(DOCBUILDDIR)/.roff.stamp sphinx-html sphinx-texinfo: docstring.stamp
> +$(DOCBUILDDIR)/.roff.stamp $(DOCBUILDDIR)/.html.stamp 
> $(DOCBUILDDIR)/.texi.stamp : docstring.stamp
>  endif
>  
>  sphinx-html: $(DOCBUILDDIR)/.html.stamp
> -- 
> 2.29.2
> ___
> notmuch mailing list -- notm...@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

Bug#966100: notmuch-mutt: replace shell pipeline with internal pipe processing

[Tomi Ollila]

The shell pipeline used to symlink files based in search results
to "cache" directory for mutt(1) to use was prone to portability
problems (due to /bin/sh differences).

The replacement executes `notmuch search` without intermediate shell
(so shell_quote was removed in this case), reads the filenames from
piped output and symlinks files internally.
---

Now also tested a bit by me (remoteusage provides stale symlinks ;)

 contrib/notmuch-mutt/notmuch-mutt | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/contrib/notmuch-mutt/notmuch-mutt 
b/contrib/notmuch-mutt/notmuch-mutt
index d33223bd..d1e2c084 100755
--- a/contrib/notmuch-mutt/notmuch-mutt
+++ b/contrib/notmuch-mutt/notmuch-mutt
@@ -12,6 +12,7 @@ use strict;
 use warnings;
 
 use File::Path;
+use File::Basename;
 use Getopt::Long qw(:config no_getopt_compat);
 use Mail::Header;
 use Mail::Box::Maildir;
@@ -41,16 +42,17 @@ sub search($$$) {
 my ($maildir, $remove_dups, $query) = @_;
 my $dup_option = "";
 
-$query = shell_quote($query);
-
-if ($remove_dups) {
-  $dup_option = "--duplicate=1";
-}
+my @args = qw/notmuch search --output=files/;
+push @args, "--duplicate=1" if $remove_dups;
+push @args, $query;
 
 empty_maildir($maildir);
-system("notmuch search --output=files $dup_option $query"
-  . " | sed -e 's: : :g'"
-  . " | while IFS= read -r searchoutput; do ln -s \$searchoutput 
$maildir/cur/; done");
+open my $pipe, '-|', @args or die "Running @args failed: $!\n";
+while (<$pipe>) {
+   chomp;
+   my $ln = "$maildir/cur/" . basename $_;
+   symlink $_, "$ln" or warn "Failed to symlink '$_', '$ln': $!\n";
+}
 }
 
 sub prompt($$) {
-- 
2.25.1
___
notmuch mailing list -- notm...@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Bug#841319: test-lib.sh: rename $DTACH_TERM to $SMART_TERM

[Tomi Ollila]

---
 test/test-lib.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index bda8a80..77879c2 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -57,7 +57,7 @@ ORIGINAL_TERM=$TERM
 
 # dtach(1) provides more capable terminal environment to anything
 # that requires more than dumb terminal...
-[ x"${TERM:-dumb}" = xdumb ] && DTACH_TERM=vt100 || DTACH_TERM=$TERM
+[ x"${TERM:-dumb}" = xdumb ] && SMART_TERM=vt100 || SMART_TERM=$TERM
 
 # For repeatability, reset the environment to known value.
 LANG=C
@@ -1171,7 +1171,7 @@ test_emacs () {
# user's TERM (or 'vt100' in case user's TERM is unset, empty
# or 'dumb') is given to dtach which assumes a minimally
# VT100-compatible terminal -- and emacs inherits that
-   TERM=$DTACH_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" \
+   TERM=$SMART_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" \
sh -c "stty rows 24 cols 80; exec 
'$TMP_DIRECTORY/run_emacs' \
--no-window-system \
$load_emacs_tests \
-- 
2.10.0

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

Bug#841319: test: use vt100 as "smart" terminal for known dumb/unknown terminals

[Tomi Ollila]

Otherwise use whatever user environment has set for TERM so
that there is more chance to test on users' actual environments.
---
 test/test-lib.sh | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 77879c2..e7b8339 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -55,9 +55,15 @@ export PS4='+(${BASH_SOURCE}:${LINENO}): 
${FUNCNAME[0]:+${FUNCNAME[0]}(): }'
 # Keep the original TERM for say_color and test_emacs
 ORIGINAL_TERM=$TERM
 
-# dtach(1) provides more capable terminal environment to anything
-# that requires more than dumb terminal...
-[ x"${TERM:-dumb}" = xdumb ] && SMART_TERM=vt100 || SMART_TERM=$TERM
+# Set SMART_TERM to vt100 for known dumb/unknown terminal.
+# Otherwise use whatever TERM is currently used so that
+# users' actual TERM environments are being used in tests.
+case ${TERM-} in
+   '' | dumb | unknown )
+   SMART_TERM=vt100 ;;
+   *)
+   SMART_TERM=$TERM ;;
+esac
 
 # For repeatability, reset the environment to known value.
 LANG=C
@@ -1168,8 +1174,8 @@ test_emacs () {
fi
server_name="notmuch-test-suite-$$"
# start a detached session with an emacs server
-   # user's TERM (or 'vt100' in case user's TERM is unset, empty
-   # or 'dumb') is given to dtach which assumes a minimally
+   # user's TERM (or 'vt100' in case user's TERM is known dumb
+   # or unknown) is given to dtach which assumes a minimally
# VT100-compatible terminal -- and emacs inherits that
TERM=$SMART_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" \
sh -c "stty rows 24 cols 80; exec 
'$TMP_DIRECTORY/run_emacs' \
-- 
2.10.0

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

Bug#810784: [Gaudenz Steinlin] Bug#810784: should match email adress case insensitive when sending encrypted mail

[Tomi Ollila]

On Tue, Feb 09 2016, David Edmondson  wrote:

> On Mon, Feb 08 2016, David Edmondson wrote:
>> On Mon, Feb 08 2016, David Edmondson wrote:
>>> On Fri, Jan 15 2016, Daniel Kahn Gillmor wrote:
 So where is the case-insensitive lookup happening?  Is this a bug in
 mml-mode, or in notmuch-emacs?
>>>
>>> It's caused by behaviour in mml2015.el (hence upstream).
>>>
>>> `mml2015-epg-check-user-id' uses `equal' to compare the recipient from
>>> the composition buffer with the addresses from the matching key.
>>>
>>> The simplest way to get the desired behaviour would be to `downcase'
>>> both strings before comparing.
>>
>> Reported as bug#22603 in emacs.
>
> Fixed in the emacs-25 branch.

We could perhaps add defadvice to **wiki** for those who want to 
do global change in their emacs environment, something like:

(if (< emacs-major-version 25)
  (defadvice mml2015-epg-check-user-id (around downcase activate)
(ad-set-arg 1 (downcase (ad-get-arg 1)))
(ad-set-arg 2 (downcase (ad-get-arg 2)))
ad-do-it))

totally untested -- also now that I finished that 'before might also work.

Bug#567648: Re; dash: please document that set -x in a subshell can cause non-determinism

[Tomi Ollila]

This behaviour is easy to observe with the following command line:

$ rm -f daao.*; strace -ff -o daao dash -c 'set -x; z=`echo | cut -f1 | sort`'

and then

$ grep write daao.*
daao.6716:write(2, + , 2)   = 2
daao.6716:write(2, z=, 2)   = 2
daao.6716:write(2, \n, 1)   = 1
daao.6718:write(2, + , 2)   = 2
daao.6718:write(2, echo, 4) = 4
daao.6718:write(2, \n, 1)   = 1
daao.6718:write(1, \n, 1)   = 1
daao.6719:write(2, + , 2)   = 2
daao.6719:write(2, cut, 3)  = 3
daao.6719:write(2,  -f1, 4) = 4
daao.6719:write(2, \n, 1)   = 1
daao.6719:write(1, \n, 1)   = 1
daao.6720:write(2, + , 2)   = 2
daao.6720:write(2, sort, 4) = 4
daao.6720:write(2, \n, 1)   = 1
daao.6720:write(1, \n, 1)   = 1

The subshells in pipeline prints their own commands before executing
it, using multiple syscalls giving possibility of intermixed output
when context switches happen in between...

For comparison this is what bash gives:

zao.6858:write(2, + z=\n, 5)   = 5
zao.6860:write(2, ++ echo\n, 8)= 8
zao.6860:write(1, \n, 1)   = 1
zao.6861:write(2, ++ cut -f1\n, 11)= 11
zao.6861:write(1, \n, 1)   = 1
zao.6862:write(2, ++ sort\n, 8)= 8
zao.6862:write(1, \n, 1)   = 1


An alternative to concatenate strings to a buffer before writing
one could try using gather write with writev() (I don't know the
SMOP factor there as I did not peek the dash source code :)

Tomi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source

[Tomi Ollila]

On Thu, Aug 02 2012, Jameson Graef Rollins jroll...@finestructure.net wrote:

 On Wed, Aug 01 2012, David Bremner da...@tethera.net wrote:
 As I mentioned on IRC, the test only fails on the Debian build machines
 (building in a clean chroot using sbuild is not enough) so it isn't
 really clear how to duplicate the it. Perhaps building in a clean
 virtual machine without networking would do it.  For which tests fail,
 see

 https://buildd.debian.org/status/fetch.php?pkg=notmucharch=i386ver=0.13.2-1stamp=1338740444

 I think the first things to fail are emacs tests. At a wild guess, it
 looks like all of the failing tests are related to emacs.

 From a cursory look that does appear to be the case.  The non-emacs
 tests that are also failing (json and crypto) are using
 emacs_deliver_message.  Do we have any idea what's going on here?

is this related (still in my personal patches pool):

diff --git a/test/test-lib.el b/test/test-lib.el
index 6271da2..503a130 100644
--- a/test/test-lib.el
+++ b/test/test-lib.el
@@ -35,6 +35,16 @@
 Disable yes-or-no-p before executing kill-emacs
 (defun yes-or-no-p (prompt) t)))
 
+;; Work around a problem with
+;; GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu) of 2011-03-26 on sl6.fnal.gov
+;; where get-buffer-process doesn't return nil without (list-processes)
+;; (value of delete-exited-process is t)
+
+(if (string= emacs-version 23.1.1)
+(defadvice get-buffer-process (before run-list-processes activate)
+  run (list-processes) before executing get-buffer-process
+  (list-processes)))
+
 (defun notmuch-test-wait ()
   Wait for process completion.
   (while (get-buffer-process (current-buffer))


I also have a commit message:

Subject: [PATCH] test: emacs: run list-processes before get-buffer-process in 
emacs 23.1.1

The function get-buffer-process does not return nil when process has
exited in some (if not every) emacs 23.1.1 versions, even the value
of delete-exited-process is t. Particularly, GNU Emacs 23.1.1
(x86_64-redhat-linux-gnu) of 2011-03-26 on sl6.fnal.gov has this
problem -- the execution halts when running emacs tests.

In this emacs version, when defadvice is used to run list-processes
before get-buffer-process the problem seems to be fixed -- emacs
tests run fine.

To fix this permanently, this defadvice is added to the starting
emacs when emacs-version equals 23.1.1.

---

It took me a while to get tests running on Scientific Linux 6 which
has this particular emacs version. I tried all kinds of hacks to get
it working -- this works best (or, actually, is the only one that works).
I just don't understand why... Maybe the emacs-server -interaction brings
some hard-to-spot interferences into equation...

In the above 'buildd' output emacs 23.4 is used and therefore this patch
in the current format would be no-op there.

In the buildd environment, just adding the follwing lines to test/test-lib.el

(defadvice get-buffer-process (before run-list-processes activate)
  run (list-processes) before executing get-buffer-process
  (list-processes))

could be tried.

Tomi


 I don't think failing the build is the right thing to do, since there
 does not actually seem to be anything wrong with the resulting
 packages. So removing them from Debian because of some problems with
 running the test suite seems a bit extreme.  People not using
 notmuch-emacs would probably be especially annoyed ;).

 But it also doesn't make much sense to me to run the tests as part of
 the build only to ignore the result.  How do we know that the failing
 tests aren't actually affecting the distributed packages?  The emacs
 failures could be masking real failures of the emacs interface (which
 users of notmuch-emacs would probably also find really annoying!).

 jamie.
 ___
 notmuch mailing list
 notm...@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source

[Tomi Ollila]

On Thu, Aug 02 2012, Austin Clements amdra...@mit.edu wrote:

 Quoth Jameson Graef Rollins on Aug 01 at  8:10 pm:
 On Wed, Aug 01 2012, David Bremner da...@tethera.net wrote:
  As I mentioned on IRC, the test only fails on the Debian build machines
  (building in a clean chroot using sbuild is not enough) so it isn't
  really clear how to duplicate the it. Perhaps building in a clean
  virtual machine without networking would do it.  For which tests fail,
  see
 
  https://buildd.debian.org/status/fetch.php?pkg=notmucharch=i386ver=0.13.2-1stamp=1338740444
 
  I think the first things to fail are emacs tests. At a wild guess, it
  looks like all of the failing tests are related to emacs.
 
 From a cursory look that does appear to be the case.  The non-emacs
 tests that are also failing (json and crypto) are using
 emacs_deliver_message.  Do we have any idea what's going on here?

 There is one other illuminating tidbit in the buildd log:

 emacs-subject-to-filename: Testing emacs: mail subject to filename
 test-lib.sh: line 187: 30606 Terminated  sleep 1
 FATAL: Unexpected exit with code 1

From a cursory glance, emacs-subject-to-filename appears to be the
 only test that calls test_emacs outside of a subtest and hence without
 stdout/stderr redirection.

 The line number is useless, but, assuming valgrind isn't enabled,
 there's only one place we sleep 1 in test-lib.sh: in the loop in
 test_emacs that waits for the Emacs server to start up.  Furthermore,
 timeout sends SIGTERM by default, suggesting that we're timing out
 while we're spinning in that loop.

The situation sounds strangely familiar... I remember seeing 'sleep 1'
with ascending pid in process list around the same time I had this
(notmuch-test-wait) problem... I think the system was lacking the
server socket in /tmp/emacs-pid/ directory...

Hmm, now I remember something -- there was some error happening
in emacs startup and therefore the (server-start) was never executed
-- the test_emacs '()' in loop can never connect the socket.

In the above case it seems like the first test
test_emacs '(notmuch-hello) (test-output)' couldn't be executed.
and as there is no test/emacs.el file $load_emacs_tests is empty
(instead of --eval '(load $TEST_DIRECTORY/emacs.el) -- so that
cannot break it.

Unfortunately I did not investigate that further (or it was my own
mistake that made emacs fail) -- but if that happens again and
one is monitoring the progress (maybe using larger value than '2m' for
timeout) the failing emacs can be entered by 'dtach -a $socket'.
The $socket can be found by executing 'ps aww | grep dtach'.

Tomi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source

[Tomi Ollila]

On Wed, Aug 01 2012, David Bremner da...@tethera.net wrote:

 Jakub Wilk jw...@debian.org writes:

 | dpkg-source: error: cannot represent change to 
 test/tmp.json/mail/.notmuch/xapian/record.baseB: binary file contents changed
 | dpkg-source: error: add test/tmp.json/mail/.notmuch/xapian/record.baseB in 
 debian/source/include-binaries if you want to store the modified binary in 
 the debian tarball
 -- 
 Jakub Wilk

 I guess the problem here is that the notmuch build process does not
 clean up the test directories in case of failing tests. I guess it
 probably should if the user explicitly runs make clean.

 Any thoughts on that notmuch people? Should we add a list of test/tmp.*
 to be cleaned?

yes.


 d

Tomi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#652359: notmuch-emacs won't display correctly quoted-printable iso-8859-1 mails

[Tomi Ollila]

On Sun, 18 Dec 2011 15:53:26 +0100, Olivier Berger 
olivier.ber...@it-sudparis.eu wrote:
 On Sun, 18 Dec 2011 10:11:37 -0400, David Bremner da...@tethera.net wrote:
  Hi Olivier;
  
  Can you try the following patch? If you apply it to git, you can use
  make debian-snapshot to build new packages (assuming you have the
  pre-reqs).
  
  Or just patch the notmuch-query.el installed by notmuch-emacs and reload
  it.
  
 
 I did that over notmuch-emacs 0.10.2-1 Debian package's version of
 notmuch-query.el, but that doesn't seem change anything, unfortunately :
 the modeline still is '-1:%*-' for the notmuch-show buffer, after
 hitting RET over a message's line in a search result list :-(

I tested the same on terminal configured for latin9 and LC_ALL=fi_FI@euro
and the change worked for me.

The buffer modeline is not supposed to change -- the change makes emacs
read incoming data encoded in utf-8 format (notmuch outputs everything
in utf-8). Before the change emacs expected (in your case) input data being
in latin1 format (guessed from your locale), but as input was in utf-8 the
conversion to emacs internal format went wrong.

When emacs displays something (buffer content, that is) it converts the
internal format to the encoding emacs window is using. 

So, my guess is you did something wrong when trying David's patch and
you did not get the change evaluated.

This what I did:

I opened emacs/notmuch-query.el to another emacs window while 
notmuch-hello open in another window.

Then I added line (coding-system-for-read 'utf-8) in line 35:

  (let  ((args '(show --format=json))
 (json-object-type 'plist)
 (json-array-type 'list)
 (coding-system-for-read 'utf-8)
 (json-false 'nil))

then moved cursor to the end of line 44 which shows: (json-read)
(last line of that function) and entered c-x c-e
(eval-last-sexp) -- that re-evaluates the function definition.

And, as said, after that change my emails render correctly on
latin1 -terminal (as opposed those did not render correctly before)

 Hope this helps.

I hope that I'm right in my guess so we get forward easier... :)

 
 Best regards,
 -- 
 Olivier BERGER 

Tomi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org