From: Tomi Ollila Date: Thu, 2 Aug 2012 10:18:47 +0000 (+0300) Subject: Re: Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to... X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=039717492707369b6db3f645d4e2aac20a8109dd;p=notmuch-archives.git Re: Bug#683505: notmuch: FTBFS if built twice in a row: unrepresentable changes to source --- diff --git a/27/7d085c33f0aa2b704b24b8a5a623ab6599b02f b/27/7d085c33f0aa2b704b24b8a5a623ab6599b02f new file mode 100644 index 000000000..a0cbe2414 --- /dev/null +++ b/27/7d085c33f0aa2b704b24b8a5a623ab6599b02f @@ -0,0 +1,156 @@ +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 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