Re: [PATCH] gnu: Add stellar-core.

[Christopher Allan Webber]

Leo Famulari writes:

> On Fri, Feb 19, 2016 at 02:37:38PM -0800, Christopher Allan Webber wrote:
>> I forgot that I *did* make a nicer workaround, and thus the comment in
>> the middle of the package definition was unnecessary.
>> 
>
>> From 056400626d070fd8653cdc03a9b0fbcdc49be5df Mon Sep 17 00:00:00 2001
>> From: Christopher Allan Webber <address@hidden>
>> Date: Fri, 19 Feb 2016 13:47:19 -0800
>> Subject: [PATCH] gnu: Add stellar-core.
>> 
>> * gnu/packages/finance.scm (stellar-core): New variable.
>> * gnu/packages/patches/stellar-core-find-mk-files.patch: New file.
>
> Please remember to register the patch in gnu-system.am (dist_patch_DATA).

Done.  I keep forgetting to do that!  When things build, I forget to do
the other steps that aren't just building things! ;)

>> ---
>>  gnu/packages/finance.scm                           | 60 
>> ++++++++++++++++++++++
>>  .../patches/stellar-core-find-mk-files.patch       | 33 ++++++++++++
>>  2 files changed, 93 insertions(+)
>>  create mode 100644 gnu/packages/patches/stellar-core-find-mk-files.patch
>> 
>> diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
>> index e9487d4..e208791 100644
>> --- a/gnu/packages/finance.scm
>> +++ b/gnu/packages/finance.scm
>> @@ -1,6 +1,7 @@
>>  ;;; GNU Guix --- Functional package management for GNU
>>  ;;; Copyright © 2015 Andreas Enge <address@hidden>
>>  ;;; Copyright © 2016 Efraim Flashner <address@hidden>
>> +;;; Copyright © 2016 Christopher Allan Webber <address@hidden>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -21,9 +22,15 @@
>>   #:use-module ((guix licenses) #:prefix license:)
>>   #:use-module (guix packages)
>>   #:use-module (guix download)
>> + #:use-module (guix git-download)
>>   #:use-module (guix build utils)
>>   #:use-module (guix build-system gnu)
>> + #:use-module (gnu packages)
>> + #:use-module (gnu packages autogen)
>> + #:use-module (gnu packages autotools)
>>   #:use-module (gnu packages boost)
>> + #:use-module (gnu packages bison)
>> + #:use-module (gnu packages flex)
>>   #:use-module (gnu packages databases)
>>   #:use-module (gnu packages linux)
>>   #:use-module (gnu packages pkg-config)
>> @@ -81,3 +88,56 @@ collectively by the network.  Bitcoin Core is the 
>> reference implementation
>>  of the bitcoin protocol.  This package provides the Bitcoin Core command
>>  line client and a client based on Qt.")
>>      (license license:expat)))
>> +
>> +(define-public stellar-core
>> +  (package
>> +    (name "stellar-core")
>> +    (version "0.4.1")
>> +    (source (origin
>> +              (method git-fetch)
>> +              (uri (git-reference
>> +                    (url "https://github.com/stellar/stellar-core.git";)
>> +                    (commit "v0.4.1")
>> +                    (recursive? #t)))
>
> I had to look up this property. A first time for everything!

Indeed, and afaict, stellar-core would be the second use!

>> +              (sha256
>> +               (base32
>> +                "15mm1jk2kk5x34vn9gqwp7ijhsmhm6dwymznz7hqvjj8kjd088fi"))
>> +              (patches (list (search-patch
>> +                              "stellar-core-find-mk-files.patch")))))
>> +    (arguments
>> +     '(#:phases (modify-phases %standard-phases
>> +                  (add-before 'configure 'autogen-self-and-submodules
>> +                    (lambda _
>> +                      (and (zero? (system* "sh" "autogen.sh"
>> +                                           ;; we'll handle submodules 
>> manually
>> +                                           "--skip-submodules"))
>> +                           ;; Run autogen on libsodium too.
>
> Upstream bundles libsodium? What's their security policy / practices?
> Their libsodium submodule was last updated in July 2015, if I understand
> correctly (I have no hands-on experience with submodules), but libsodium
> has released 5 minor versions since then.
>
> Is it possible to use our libsodium package?

I don't know whether it's possible to use our libsodium package.
Frankly, I don't understand enough about C packaging to understand what
to do.

"5 minor versions since then" does sound like a concern... it would be
nice to use our version rather than the bundled one, because we can
likely keep it up to date more easily.  However, I don't really
understand how their bundling works, and if un-bundling is possible.
I'll ask them.

>> +       ;; Tries to run tests with a running postgres server...
>> +       ;; well, sorry, we can't do that!
>> +       #:tests? #f))
>
> Is the Postgres server required for the entire test suite, or is it just
> a small subset of the tests that could be disabled individually?

There's a src/test/selftest-nopg and a src/test/selftest-pg.  If we
could maybe run the former and not the latter, we could at least run
some tests.  We *do* want to build postgres support in though, almost
certainly.

I'll try to ask them if there's any simple way to do this.

>> +                           ;; In the future, we might also have to manually
>> +                           ;; run this on other git submodules which are
>> +                           ;; introduced
>> +                           (begin (chdir "lib/libsodium") #t)
>> +                           (zero? (system* "sh" "autogen.sh"))
>> +                           (begin (chdir "../..") #t)))))
>
> This is just me asking a question for my own knowledge:
>
> What is the difference between (begin (chdir "foo") #t) and
> (chdir "foo")?

One of them returns #t, and one of them returns undefined :) This is so
that the (and) can aggregate the results of the (zero?) calls.  (chdir)
will error out.

This was the easiest way to do those consectuive calls and have the
return status passed back.

>> +    (build-system gnu-build-system)
>> +    (native-inputs
>> +     `(("pkg-config" ,pkg-config)
>> +       ("autoconf" ,autoconf)
>> +       ("automake" ,automake)
>> +       ("autogen" ,autogen)
>> +       ;; used by libsodium git submodule
>> +       ("libtool" ,libtool)))
>> +    (inputs
>> +     `(("bison" ,bison)
>> +       ("flex" ,flex)
>> +       ("postgresql" ,postgresql)))
>> +    (home-page "https://www.stellar.org/";)
>> +    (synopsis "Communicate with the Stellar peer-to-peer network")
>> +    (description "Stellar-core is a replicated state machine that
>> +maintains a local copy of a cryptographic ledger and processes
>> +transactions against it, in consensus with a set of peers.
>> +It implements the Stellar Consensus Protocol, a federated consensus
>> +protocol.")
>> +    (license license:asl2.0)))
>> diff --git a/gnu/packages/patches/stellar-core-find-mk-files.patch 
>> b/gnu/packages/patches/stellar-core-find-mk-files.patch
>
> "Interesting" upstream packaging...
>
> [...]

Yes... I don't really understand why the make-mks things are done.  But
I don't know much about autotools, though it seems like they're doing
some clever things related to it.  Nonetheless, my hacky patch seems to
set things working in our git-less git-checkout environment.

Okay, it looks like there are a couple things to look into.  The
unbundling bit seems like the most important thing... the tests would be
a nice-to-have.

 - Chris