all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ben Woodcroft <b.woodcroft@uq.edu.au>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Update mafft to 7.245.
Date: Fri, 18 Dec 2015 09:27:59 +1000	[thread overview]
Message-ID: <567344FF.6050906@uq.edu.au> (raw)
In-Reply-To: <87poy4lndw.fsf@elephly.net>

Hi,
>>> Other than that the patch does look fine.  If you confirm that this is
>>> what you intended then I’ll 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’d like to
> try that first.
Oh you misunderstand. I just meant when I started out I figured this 
would be a simple version bump, but things got a bit more complicated. 
The package is much better for your review.
>> I tried adding a check procedure but this didn't work: mafft refused to
>> 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’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, 
presumably because they are out of date, with some minor alignment 
issues. I'll talk to upstream and maybe snag a check target in the process.

Thanks,
ben

  reply	other threads:[~2015-12-17 23:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10 12:18 Update mafft to 7.245 Ben Woodcroft
2015-11-10 13:06 ` Ricardo Wurmus
2015-11-10 13:12 ` Efraim Flashner
2015-11-10 22:22   ` Ben Woodcroft
2015-12-10 16:16     ` Ricardo Wurmus
2015-12-15 12:05       ` Ben Woodcroft
2015-12-17 12:47         ` Ricardo Wurmus
2015-12-17 20:01           ` Ben Woodcroft
2015-12-17 22:29             ` Ricardo Wurmus
2015-12-17 23:27               ` Ben Woodcroft [this message]
2015-12-21 14:17                 ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=567344FF.6050906@uq.edu.au \
    --to=b.woodcroft@uq.edu.au \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.