From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Woodcroft Subject: Re: Update mafft to 7.245. Date: Fri, 18 Dec 2015 09:27:59 +1000 Message-ID: <567344FF.6050906@uq.edu.au> References: <5641E082.90801@uq.edu.au> <20151110151207.6c5e4693@debian-netbook> <56426E2B.10405@uq.edu.au> <567001F0.7060206@uq.edu.au> <567314B7.7070605@uq.edu.au> <87poy4lndw.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9hxx-0002kG-5Y for guix-devel@gnu.org; Thu, 17 Dec 2015 18:28:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9hxt-0006Vq-VL for guix-devel@gnu.org; Thu, 17 Dec 2015 18:28:09 -0500 Received: from mailhub2.soe.uq.edu.au ([130.102.132.209]:48134 helo=newmailhub.uq.edu.au) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9hxt-0006VZ-Bz for guix-devel@gnu.org; Thu, 17 Dec 2015 18:28:05 -0500 In-Reply-To: <87poy4lndw.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ricardo Wurmus Cc: "guix-devel@gnu.org" Hi, >>> Other than that the patch does look fine. If you confirm that this i= s >>> what you intended then I=E2=80=99ll push it as is. >> Thanks, if you are happy. This was just supposed to be a simple update= .. > Sorry for the delay! It just never feels good to me to propagate > inputs. If ever this can be avoided with a bit of patching I=E2=80=99d= like to > try that first. Oh you misunderstand. I just meant when I started out I figured this=20 would be a simple version bump, but things got a bit more complicated.=20 The package is much better for your review. >> I tried adding a check procedure but this didn't work: mafft refused t= o >> run, when it runs just fine from the store. I was loath to debug that. >> Instead, I was wondering if there was a way to test after installation= ? >> If these tests could be run in a container that excluded native-inputs >> (but perhaps some extra test-specific dependencies if required), then = I >> think such a procedure could be generally quite useful. It would catch >> the errors I made in the original patch, for instance. > You could reorder the phases such that the check phase runs after > installation. We do this for some Python packages as well. It=E2=80=99= s just a > matter of > > (delete 'check) > (add-after 'install 'check > (lambda ...)) Sure, but this lambda will be run with the native-inputs present, no? > Do you want to give this a try or shall I just apply the latest patch > you sent, leaving this for some time later? Let's just push if you don't mind. The test themselves also fail,=20 presumably because they are out of date, with some minor alignment=20 issues. I'll talk to upstream and maybe snag a check target in the proces= s. Thanks, ben