--- /dev/null
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 2825C431FAF\r
+ for <notmuch@notmuchmail.org>; Thu, 2 Aug 2012 03:18:40 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id XpYVa48P0qyk for <notmuch@notmuchmail.org>;\r
+ Thu, 2 Aug 2012 03:18:38 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id 1A7B2431FAE\r
+ for <notmuch@notmuchmail.org>; Thu, 2 Aug 2012 03:18:38 -0700 (PDT)\r
+Received: by guru.guru-group.fi (Postfix, from userid 501)\r
+ id 2D1D7100372; Thu, 2 Aug 2012 13:18:47 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
+ David Bremner <david@tethera.net>, 683505@bugs.debian.org,\r
+ Jakub Wilk <jwilk@debian.org>\r
+Subject: Re: Bug#683505: notmuch: FTBFS if built twice in a row:\r
+ unrepresentable changes to source\r
+In-Reply-To: <87txwmt2ev.fsf@servo.finestructure.net>\r
+References: <20120801103707.GA668@jwilk.net>\r
+ <87pq7aabl8.fsf@convex-new.cs.unb.ca>\r
+ <878vdyvdjg.fsf@servo.finestructure.net>\r
+ <87ipd29tu4.fsf@convex-new.cs.unb.ca>\r
+ <87txwmt2ev.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.13.2+103~g9610d35 (http://notmuchmail.org) Emacs/23.1.1\r
+ (x86_64-redhat-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Thu, 02 Aug 2012 13:18:47 +0300\r
+Message-ID: <m28vdx7g1k.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 02 Aug 2012 10:18:40 -0000\r
+\r
+On Thu, Aug 02 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
+\r
+> On Wed, Aug 01 2012, David Bremner <david@tethera.net> wrote:\r
+>> As I mentioned on IRC, the test only fails on the Debian build machines\r
+>> (building in a clean chroot using sbuild is not enough) so it isn't\r
+>> really clear how to duplicate the it. Perhaps building in a clean\r
+>> virtual machine without networking would do it. For which tests fail,\r
+>> see\r
+>>\r
+>> https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=i386&ver=0.13.2-1&stamp=1338740444\r
+>>\r
+>> I think the first things to fail are emacs tests. At a wild guess, it\r
+>> looks like all of the failing tests are related to emacs.\r
+>\r
+> From a cursory look that does appear to be the case. The non-emacs\r
+> tests that are also failing (json and crypto) are using\r
+> emacs_deliver_message. Do we have any idea what's going on here?\r
+\r
+is this related (still in my personal patches pool):\r
+\r
+diff --git a/test/test-lib.el b/test/test-lib.el\r
+index 6271da2..503a130 100644\r
+--- a/test/test-lib.el\r
++++ b/test/test-lib.el\r
+@@ -35,6 +35,16 @@\r
+ "Disable yes-or-no-p before executing kill-emacs"\r
+ (defun yes-or-no-p (prompt) t)))\r
+ \r
++;; Work around a problem with\r
++;; GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu) of 2011-03-26 on sl6.fnal.gov\r
++;; where get-buffer-process doesn't return nil without (list-processes)\r
++;; (value of delete-exited-process is t)\r
++\r
++(if (string= emacs-version "23.1.1")\r
++ (defadvice get-buffer-process (before run-list-processes activate)\r
++ "run (list-processes) before executing get-buffer-process"\r
++ (list-processes)))\r
++\r
+ (defun notmuch-test-wait ()\r
+ "Wait for process completion."\r
+ (while (get-buffer-process (current-buffer))\r
+\r
+\r
+I also have a commit message:\r
+\r
+Subject: [PATCH] test: emacs: run list-processes before get-buffer-process in emacs 23.1.1\r
+\r
+The function get-buffer-process does not return nil when process has\r
+exited in some (if not every) emacs 23.1.1 versions, even the value\r
+of delete-exited-process is t. Particularly, GNU Emacs 23.1.1\r
+(x86_64-redhat-linux-gnu) of 2011-03-26 on sl6.fnal.gov has this\r
+problem -- the execution halts when running emacs tests.\r
+\r
+In this emacs version, when defadvice is used to run list-processes\r
+before get-buffer-process the problem seems to be fixed -- emacs\r
+tests run fine.\r
+\r
+To fix this permanently, this defadvice is added to the starting\r
+emacs when emacs-version equals "23.1.1".\r
+\r
+---\r
+\r
+It took me a while to get tests running on Scientific Linux 6 which\r
+has this particular emacs version. I tried all kinds of hacks to get\r
+it working -- this works best (or, actually, is the only one that works).\r
+I just don't understand why... Maybe the emacs-server -interaction brings\r
+some hard-to-spot interferences into equation...\r
+\r
+In the above 'buildd' output emacs 23.4 is used and therefore this patch\r
+in the current format would be no-op there.\r
+\r
+In the buildd environment, just adding the follwing lines to test/test-lib.el\r
+\r
+(defadvice get-buffer-process (before run-list-processes activate)\r
+ "run (list-processes) before executing get-buffer-process"\r
+ (list-processes))\r
+\r
+could be tried.\r
+\r
+Tomi\r
+\r
+>\r
+>> I don't think failing the build is the right thing to do, since there\r
+>> does not actually seem to be anything wrong with the resulting\r
+>> packages. So removing them from Debian because of some problems with\r
+>> running the test suite seems a bit extreme. People not using\r
+>> notmuch-emacs would probably be especially annoyed ;).\r
+>\r
+> But it also doesn't make much sense to me to run the tests as part of\r
+> the build only to ignore the result. How do we know that the failing\r
+> tests aren't actually affecting the distributed packages? The emacs\r
+> failures could be masking real failures of the emacs interface (which\r
+> users of notmuch-emacs would probably also find really annoying!).\r
+>\r
+> jamie.\r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
projects / notmuch-archives.git / commitdiff