"Building from Git" on foreign distro starting with NO guix?

  • Open
  • quality assurance status badge
Details
2 participants
  • Bengt Richter
  • Julien Lepiller
Owner
unassigned
Submitted by
Bengt Richter
Severity
normal
B
B
Bengt Richter wrote on 19 May 2020 05:07
(name . New-Bug)(address . bug-guix@gnu.org)
20200519030742.GA16910@LionPure
Attachment: file
J
J
Julien Lepiller wrote on 19 May 2020 14:03
1FCE7BDD-371F-45B1-9D9E-4C4E0D8531BD@lepiller.eu
Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter <bokr@bokr.com> a écrit :
Toggle quote (33 lines)
>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.

Toggle quote (18 lines)
>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
B
B
Bengt Richter wrote on 19 May 2020 20:15
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 41387@debbugs.gnu.org)
20200519181524.GA3150@LionPure
Hi Julien,

On +2020-05-19 08:03:37 -0400, Julien Lepiller wrote:
Toggle quote (43 lines)
> 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) :)


Thanks again.

--
Regards,
Bengt Richter
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 41387@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 41387
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch