bug#41387: "Building from Git" on foreign distro starting with NO guix?

bug#41387: "Building from Git" on foreign distro starting with NO guix?

[Bengt Richter]

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@gnu.org>" [unknown]
gpg:                 aka "Ludovic Court\u00e8s <ludo@chbouib.org>" [unknown]
gpg:                 aka "Ludovic Court\u00e8s (Inria) <ludovic.courtes@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

bug#41387: "Building from Git" on foreign distro starting with NO guix?

[Julien Lepiller]

Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter <bokr@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

bug#41387: "Building from Git" on foreign distro starting with NO guix?

[Bengt Richter]

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@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