From: Tomi Ollila <tomi.ollila@iki.fi>
To: Austin Clements <amdragon@MIT.EDU>,
	Jameson Graef Rollins <jrollins@finestructure.net>
Subject: Re: Bug#683505: notmuch: FTBFS if built twice in a row:
	unrepresentable changes to source
In-Reply-To: <20120802143222.GI8502@mit.edu>
References: <20120801103707.GA668@jwilk.net>
	<87pq7aabl8.fsf@convex-new.cs.unb.ca>
	<878vdyvdjg.fsf@servo.finestructure.net>
	<87ipd29tu4.fsf@convex-new.cs.unb.ca>
	<87txwmt2ev.fsf@servo.finestructure.net>
	<20120802143222.GI8502@mit.edu>
User-Agent: Notmuch/0.13.2+103~g9610d35 (http://notmuchmail.org) Emacs/23.1.1
	(x86_64-redhat-linux-gnu)
Date: Fri, 03 Aug 2012 00:12:28 +0300
Message-ID: <m2ehnpdmmb.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jakub Wilk <jwilk@debian.org>, notmuch@notmuchmail.org,
	683505@bugs.debian.org
Precedence: list

On Thu, Aug 02 2012, Austin Clements <amdragon@MIT.EDU> wrote:

> Quoth Jameson Graef Rollins on Aug 01 at  8:10 pm:
>> On Wed, Aug 01 2012, David Bremner <david@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=notmuch&arch=i386&ver=0.13.2-1&stamp=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