From: Tomi Ollila <tomi.ollila@iki.fi>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
	David Bremner <david@tethera.net>, 683505@bugs.debian.org,
	Jakub Wilk <jwilk@debian.org>
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)
Date: Thu, 02 Aug 2012 13:18:47 +0300
Message-ID: <m28vdx7g1k.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list

On Thu, Aug 02 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:

> 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?

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