GNU bug report logs - #41387
"Building from Git" on foreign distro starting with NO guix?

Previous Next

Package: guix;

Reported by: Bengt Richter <bokr <at> bokr.com>

Date: Tue, 19 May 2020 03:09:02 UTC

Severity: normal

To reply to this bug, email your comments to 41387 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#41387; Package guix. (Tue, 19 May 2020 03:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bengt Richter <bokr <at> bokr.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 19 May 2020 03:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: New-Bug <bug-guix <at> gnu.org>
Subject: "Building from Git" on foreign distro starting with NO guix?
Date: Tue, 19 May 2020 05:07:42 +0200
Hi,

Playing with guix-install.sh, which is binary installation,
I got into reading a bit at [1], and decided I'd like to try it.

[1] https://guix.gnu.org/manual/en/html_node/Building-from-Git.html#Building-from-Git

Is there anyone here who has succeeded installing guix following the
directions at "14.1 Building from Git" on a "foreign distro"
WITH NO TRACE OF GUIX on it to start?
^^^^^^^^^^^^^^^^^^^^^

I read,
--8<---------------cut here---------------start------------->8---
14.1 Building from Git

If you want to hack Guix itself, it is recommended to use the latest version from the Git repository:

git clone https://git.savannah.gnu.org/git/guix.git
--8<---------------cut here---------------end--------------->8---
Great, my foreign /usr/bin/git cloned that handily (that was the intent right?)

Onwards,
--8<---------------cut here---------------start------------->8---
How do you ensure that you obtained a genuine copy of the repository? Guix itself provides a tool to authenticate your checkout, but you must first make sure this tool is genuine in order to “bootstrap” the trust chain. To do that, run:

git verify-commit `git log --format=%H build-aux/git-authenticate.scm`
--8<---------------cut here---------------end--------------->8---
Guix itself? How is that meant? Really looks like my git again, albeit showing info probably from guix :)

Anyway, it worked. At least I counted 19 or so repeat outputs of this:
--8<---------------cut here---------------start------------->8---
gpg: Signature made Fri 27 Dec 2019 01:52:49 PM CET
gpg:                using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
gpg: Good signature from "Ludovic Court\u00e8s <ludo <at> gnu.org>" [unknown]
gpg:                 aka "Ludovic Court\u00e8s <ludo <at> chbouib.org>" [unknown]
gpg:                 aka "Ludovic Court\u00e8s (Inria) <ludovic.courtes <at> inria.fr>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
--8<---------------cut here---------------end--------------->8---
I don't know what in the repo was signed, but I recognize the name ;-)

Ok, next step. No brick wall yet ;-)
--8<---------------cut here---------------start------------->8---

From there on, you can authenticate all the commits included in your checkout by running:

make authenticate

The first run takes a couple of minutes, but subsequent runs are faster.

    Note: You are advised to run make authenticate after every git pull invocation. This ensures you keep receiving valid changes to the repository 
--8<---------------cut here---------------end--------------->8---

First bump, misunderstood that it wasn't time *right now* to do "make authenticate":
--8<---------------cut here---------------start------------->8---
[21:17 ~/wb/guix110git/guix]$ make authenticate
make: *** No rule to make target 'authenticate'.  Stop.
--8<---------------cut here---------------end--------------->8---

After being distracted and feeling a bit teased reading about what I could do easily
if I already had guix installed I overlooked the "(see Requirements)" and
just checked on the list following. (Gettext needed unmentioned Autopoint, BTW, but NBD :)

on to ./bootstrap ... mostly ok 
--8<---------------cut here---------------start------------->8---
If you are unable to use Guix when building Guix from a checkout, the following are the required packages in addition to those mentioned in the installation instructions (see Requirements).

    GNU Autoconf;
    GNU Automake;
    GNU Gettext;
    GNU Texinfo;
    Graphviz;
    GNU Help2man (optional). 

On Guix, extra dependencies can be added by instead running guix environment with --ad-hoc:

guix environment guix --pure --ad-hoc help2man git strace

Run ./bootstrap to generate the build system infrastructure using Autoconf and Automake. If you get an error like this one:

configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
--8<---------------cut here---------------end--------------->8---

Well, didn't get that one, but did get
--8<---------------cut here---------------start------------->8---
configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
--8<---------------cut here---------------end--------------->8---
and
--8<---------------cut here---------------start------------->8---
Makefile.am:649: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
--8<---------------cut here---------------end--------------->8---

So, onwards again :)
--8<---------------cut here---------------start------------->8---
Then, run ./configure as usual. Make sure to pass --localstatedir=directory where directory is the localstatedir value used by your current installation (see The Store, for information about this). We recommend to use the value /var. 
--8<---------------cut here---------------end--------------->8---
My "current installation" ?? I don't have one yet ;-(

Ok, run ./configure in any case:
I decided to make a test directory for --prefix
Fumbled the absolute directory, but then it ran ...
--8<---------------cut here---------------start------------->8---
[~/wb/guix110git/guix]$ mkdir -p mybuild/var
[~/wb/guix110git/guix]$ ./configure --prefix=./mybuild
configure: error: expected an absolute directory name for --prefix: ./mybuild
[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild)
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...
...
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 3.0
configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... /usr/bin/guild-2.2
checking for guile-config-2.2... /usr/bin/guile-config-2.2
checking for GUILE... yes
checking if (gnutls) is available... no
configure: error: The Guile bindings of GnuTLS are missing; please install them.
--8<---------------cut here---------------end--------------->8---

Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4
--8<---------------cut here---------------start------------->8---
guile (GNU Guile) 2.2.4
Packaged by Debian (2.2.4-deb+1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
--8<---------------cut here---------------end--------------->8---
which it seemed ok with, but I don't seem to be able get my distro's GnuTLS
hooked up with this installation procedure, and suspect a GnuTLS/Guile version
mismatch problem or such, but then I ran out of enthusiasm :)

Debian's packages on my system matching tls are:
[~/bs]$ dpkg -l '*tls*'
--8<---------------cut here---------------start------------->8---
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                    Version          Architecture Description
+++-=======================-================-============-=============================================================
un  exim-tls                <none>           <none>       (no description available)
ii  gnutls-bin              3.6.7-4+deb10u3  amd64        GNU TLS library - commandline utilities
ii  gnutls-doc              3.6.7-4+deb10u3  all          GNU TLS library - documentation and examples
ii  libcurl3-gnutls:amd64   7.64.0-4+deb10u1 amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
un  libcurl4-gnutls-dev     <none>           <none>       (no description available)
ii  libgnutls-dane0:amd64   3.6.7-4+deb10u3  amd64        GNU TLS library - DANE security support
ii  libgnutls30:amd64       3.6.7-4+deb10u3  amd64        GNU TLS library - main runtime library
ii  libneon27-gnutls:amd64  0.30.2-3         amd64        HTTP and WebDAV client library (GnuTLS enabled)
ii  libxmlsec1-gnutls:amd64 1.2.27-2         amd64        Gnutls engine for the XML security library
un  rsyslog-gnutls          <none>           <none>       (no description available)
--8<---------------cut here---------------end--------------->8---

I thought maybe I could cheat and find a path into the cloned repo, since
all the magic has to be there somehow, but that way seems pretty kludgey.

Any help past this GnuTLS obstacle is welcome!

BTW, could I check out at a commit prior to the guile3 introduction
so that my distro might have a matching GnuTLS for that?
If so, which commit would be best?

In the meanwhile, back to hacking guix-install.sh :)

Thanks for reading.

--
Regards,
Bengt Richter




Information forwarded to bug-guix <at> gnu.org:
bug#41387; Package guix. (Tue, 19 May 2020 12:04:01 GMT) Full text and rfc822 format available.

Message #8 received at 41387 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Bengt Richter <bokr <at> bokr.com>,41387 <at> debbugs.gnu.org
Subject: Re: bug#41387: "Building from Git" on foreign distro starting with NO
 guix?
Date: Tue, 19 May 2020 08:03:37 -0400
Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter <bokr <at> bokr.com> a écrit :
>Hi,
>
>[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild)
>checking for a BSD-compatible install... /usr/bin/install -c
>checking whether build environment is sane... yes
>...
>...
>checking pkg-config is at least version 0.9.0... yes
>configure: checking for guile 3.0
>configure: checking for guile 2.2
>configure: found guile 2.2
>checking for guile-2.2... /usr/bin/guile-2.2
>checking for Guile version >= 2.2... 2.2.4
>checking for guild-2.2... /usr/bin/guild-2.2
>checking for guile-config-2.2... /usr/bin/guile-config-2.2
>checking for GUILE... yes
>checking if (gnutls) is available... no
>configure: error: The Guile bindings of GnuTLS are missing; please
>install them.
>--8<---------------cut here---------------end--------------->8---
>
>Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4
>--8<---------------cut here---------------start------------->8---
>guile (GNU Guile) 2.2.4
>Packaged by Debian (2.2.4-deb+1-2)
>Copyright (C) 2018 Free Software Foundation, Inc.
>--8<---------------cut here---------------end--------------->8---
>which it seemed ok with, but I don't seem to be able get my distro's
>GnuTLS
>hooked up with this installation procedure, and suspect a GnuTLS/Guile
>version
>mismatch problem or such, but then I ran out of enthusiasm :)

As you can see, configure looks for guile 3.0, fails and falls back to guile 2.2, which it finds as /usr/bin/guile-2.2.

Gnutls provides guile bindings, but they are not necessarily built by your distribution. From my experiments with debian/hurd, the bindings were not present, so probably the same with debian/linux? You'll probably have to checkout gnutls and build the bindings.

The configure script only checks that the guile it found (your 2.2) can load the (gnutls) module, so there cannot be a version mismatch, unless debian built the gnutls module with guile 3.0. Check with your distribution what files are installed with the gnutls package. There should be some in /usr/lib/guile/.

You'll need to look at the dependencies, some of them are probably not provided by debian yet. I remember some discussions about creating a debian package of guix. If this was accepted, then the dependencies must be available at least in unstable. You might want to check.

>I thought maybe I could cheat and find a path into the cloned repo,
>since
>all the magic has to be there somehow, but that way seems pretty
>kludgey.
>
>Any help past this GnuTLS obstacle is welcome!
>
>BTW, could I check out at a commit prior to the guile3 introduction
>so that my distro might have a matching GnuTLS for that?
>If so, which commit would be best?
>
>In the meanwhile, back to hacking guix-install.sh :)
>
>Thanks for reading.
>
>--
>Regards,
>Bengt Richter





Information forwarded to bug-guix <at> gnu.org:
bug#41387; Package guix. (Tue, 19 May 2020 18:21:02 GMT) Full text and rfc822 format available.

Message #11 received at 41387 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 41387 <at> debbugs.gnu.org
Subject: Re: bug#41387: "Building from Git" on foreign distro starting with
 NO guix?
Date: Tue, 19 May 2020 20:15:24 +0200
Hi Julien,

On +2020-05-19 08:03:37 -0400, Julien Lepiller wrote:
> Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter <bokr <at> bokr.com> a écrit :
> >Hi,
> >
> >[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild)
> >checking for a BSD-compatible install... /usr/bin/install -c
> >checking whether build environment is sane... yes
> >...
> >...
> >checking pkg-config is at least version 0.9.0... yes
> >configure: checking for guile 3.0
> >configure: checking for guile 2.2
> >configure: found guile 2.2
> >checking for guile-2.2... /usr/bin/guile-2.2
> >checking for Guile version >= 2.2... 2.2.4
> >checking for guild-2.2... /usr/bin/guild-2.2
> >checking for guile-config-2.2... /usr/bin/guile-config-2.2
> >checking for GUILE... yes
> >checking if (gnutls) is available... no
> >configure: error: The Guile bindings of GnuTLS are missing; please
> >install them.
> >--8<---------------cut here---------------end--------------->8---
> >
> >Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4
> >--8<---------------cut here---------------start------------->8---
> >guile (GNU Guile) 2.2.4
> >Packaged by Debian (2.2.4-deb+1-2)
> >Copyright (C) 2018 Free Software Foundation, Inc.
> >--8<---------------cut here---------------end--------------->8---
> >which it seemed ok with, but I don't seem to be able get my distro's
> >GnuTLS
> >hooked up with this installation procedure, and suspect a GnuTLS/Guile
> >version
> >mismatch problem or such, but then I ran out of enthusiasm :)
> 
> As you can see, configure looks for guile 3.0, fails and falls back to guile 2.2, which it finds as /usr/bin/guile-2.2.
> 
> Gnutls provides guile bindings, but they are not necessarily built by your distribution. From my experiments with debian/hurd, the bindings were not present, so probably the same with debian/linux? You'll probably have to checkout gnutls and build the bindings.
> 
> The configure script only checks that the guile it found (your 2.2) can load the (gnutls) module, so there cannot be a version mismatch, unless debian built the gnutls module with guile 3.0. Check with your distribution what files are installed with the gnutls package. There should be some in /usr/lib/guile/.
> 
> You'll need to look at the dependencies, some of them are probably not provided by debian yet. I remember some discussions about creating a debian package of guix. If this was accepted, then the dependencies must be available at least in unstable. You might want to check.
>

Thanks for your tips!
I also went on to read Pjotr Prins' extensive notes on installing [1].

Looks like he can say "Been there, done that" re most install travails,
and IIUC he recommends against "Building from Git" as step 1, advising
to use a binary install first, and then use guix tools to hack further in a full repo.

BTW, he suggests a recursive clone, but I didn't see what that really does or entails.
Not sure I want to download the entire history of all development branches of guix,
if that's what it means :)

(re that: it would be nice to see an approximate download size when advice to download
appears in docs, for those who pay for GBs ;-)

Perhaps 14.1 in the docs should be updated with a reference to [1] and to suggest (emphatically?)
there in 14.1 (as it does elsewhere) that the easier path will be to do a binary install first?
And also un-mix directions for the two kinds of install activities!

Leading people into frustrating experiences can't be good PR for guix. Cui bono?

Anyway, I think I'll give up on Building from Git for now, and go back to monkeying with
guix-install.sh (making it incrementally restartable to avoid re-downloading etc. and
seeing how far I can factor out root both in the script and the resulting guix daemonium) :)

[1] https://gitlab.com/pjotrp/guix-notes/-/blob/master/INSTALL.org

Thanks again.

-- 
Regards,
Bengt Richter




This bug report was last modified 5 years and 24 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.