From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: [PATCH] gnu: Add stellar-core. Date: Fri, 19 Feb 2016 21:19:43 -0800 Message-ID: <87si0olzkt.fsf@dustycloud.org> References: <874md4pdai.fsf@dustycloud.org> <871t88pbqc.fsf@dustycloud.org> <20160220045628.GD14995@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX06Q-00012R-KQ for guix-devel@gnu.org; Sat, 20 Feb 2016 00:29:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX06O-0005Hu-VM for guix-devel@gnu.org; Sat, 20 Feb 2016 00:29:10 -0500 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:50708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX06O-0005Hq-IA for guix-devel@gnu.org; Sat, 20 Feb 2016 00:29:08 -0500 In-reply-to: <20160220045628.GD14995@jasmine> 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: Leo Famulari Cc: guix-devel@gnu.org Leo Famulari writes: > On Fri, Feb 19, 2016 at 02:37:38PM -0800, Christopher Allan Webber wrot= e: >> I forgot that I *did* make a nicer workaround, and thus the comment in >> the middle of the package definition was unnecessary. >>=20 > >> From 056400626d070fd8653cdc03a9b0fbcdc49be5df Mon Sep 17 00:00:00 2001 >> From: Christopher Allan Webber >> Date: Fri, 19 Feb 2016 13:47:19 -0800 >> Subject: [PATCH] gnu: Add stellar-core. >>=20 >> * 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.pa= tch >>=20 >> 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 =C2=A9 2015 Andreas Enge >> ;;; Copyright =C2=A9 2016 Efraim Flashner >> +;;; Copyright =C2=A9 2016 Christopher Allan Webber >> ;;; >> ;;; 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 r= eference implementation >> of the bitcoin protocol. This package provides the Bitcoin Core comm= and >> 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 understan= d > correctly (I have no hands-on experience with submodules), but libsodiu= m > 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 jus= t > 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 ma= nually >> + ;; 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/g= nu/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