From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id B4CB5431FAF for ; Thu, 2 Aug 2012 14:12:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2L6cYmNuHZg for ; Thu, 2 Aug 2012 14:12:19 -0700 (PDT) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by olra.theworths.org (Postfix) with ESMTP id 85A55431FAE for ; Thu, 2 Aug 2012 14:12:19 -0700 (PDT) Received: by guru.guru-group.fi (Postfix, from userid 501) id 3F792100372; Fri, 3 Aug 2012 00:12:28 +0300 (EEST) From: Tomi Ollila To: Austin Clements , Jameson Graef Rollins 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) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jakub Wilk , notmuch@notmuchmail.org, 683505@bugs.debian.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:12:20 -0000 On Thu, Aug 02 2012, Austin Clements wrote: > Quoth Jameson Graef Rollins on Aug 01 at 8:10 pm: >> On Wed, Aug 01 2012, David Bremner 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-/ 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