From 1e5787fe6b478b8f6a1a9bbd810012e3804b93cb Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Fri, 3 Aug 2012 00:12:28 +0300 Subject: [PATCH] Re: Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source --- f9/b3d1da6ca31b044b614f8a3497a448dfd9a7c8 | 115 ++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 f9/b3d1da6ca31b044b614f8a3497a448dfd9a7c8 diff --git a/f9/b3d1da6ca31b044b614f8a3497a448dfd9a7c8 b/f9/b3d1da6ca31b044b614f8a3497a448dfd9a7c8 new file mode 100644 index 000000000..e78b58e8f --- /dev/null +++ b/f9/b3d1da6ca31b044b614f8a3497a448dfd9a7c8 @@ -0,0 +1,115 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +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 -- 2.26.2