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 2825C431FAF for ; Thu, 2 Aug 2012 03:18:40 -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 XpYVa48P0qyk for ; Thu, 2 Aug 2012 03:18:38 -0700 (PDT) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by olra.theworths.org (Postfix) with ESMTP id 1A7B2431FAE for ; Thu, 2 Aug 2012 03:18:38 -0700 (PDT) Received: by guru.guru-group.fi (Postfix, from userid 501) id 2D1D7100372; Thu, 2 Aug 2012 13:18:47 +0300 (EEST) From: Tomi Ollila To: Jameson Graef Rollins , David Bremner , 683505@bugs.debian.org, Jakub Wilk Subject: Re: Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source In-Reply-To: <87txwmt2ev.fsf@servo.finestructure.net> 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> 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: notmuch@notmuchmail.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 10:18:40 -0000 On Thu, Aug 02 2012, Jameson Graef Rollins wrote: > 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? 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 > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch