IRC channel logs
2013-11-09.log
back to list of logs
<c107>I have Guile 2.0, but `configure` says I don't. <mark_weaver>what does "pkg-config --libs --cflags guile-2.0" output for you? <c107>mark_weaver: not found in search path. no package found. <c107>mark_weaver: None: `sudo apt-get install guile`. <c107>mark_weaver: Oh, I use Trisquel. <mark_weaver>in general, when compiling things from source code, you need the *-dev packages of all build dependencies. <c107>mark_weaver: So, check `README` and make sure I install the `*-dev` versions of the packages, as well? <c107>Will do. Right now, I'm installing the metapackage for the Trisquel system, so I can have a conventional computer system for school. <c107>mark_weaver: Will Guix be aware of already-installed packages? <mark_weaver>Guix neither knows nor cares about packages installed outside of Guix. It uses its own libraries and compilers exclusively. <mark_weaver>Well, you need the outer system to build Guix itself, but all of the software built and installed using Guix is self-contained and doesn't use the outer system at all (except the kernel) <c107>mark_weaver: Ah. So, don't install any software yet. <mark_weaver>Why do you say that? Installing software is the whole point of Guix :) <mark_weaver>it coexists just fine with the outer system, although it is largely independent of it. <c107>mark_weaver: I want some sort of boundary between Guix-installed softwarae and APT-installed software. <c107>I don't want to wonder whether I installed something with Guix or APT. <mark_weaver>yes, they are separately quite well. All the software that Guix installs is in /nix/store/* <c107>Oh, right. It breaks Unix/POSIX compatibility. <mark_weaver>and when you ask to "install" some set of packages, it creates a symlink tree within ~/.guix-profile/ <c107>I'm not sure about such breakage. <mark_weaver>anyway, it doesn't interfere with the outer system at all. all the software it installs is invisible to you unless you add ~/.guix-profile/bin to your PATH. <mark_weaver>well, the guix command itself will be installed in $PREFIX/bin <mark_weaver>(and guix installs some of its libraries in $PREFIX) <mark_weaver>but when you use that guix system to install new software, all of that software is in /nix/store/* and ~/.guix-profile/ <c107>mark_weaver: Is `~/guix-profile/` the directory for user-specific packages and Guix operations? <mark_weaver>well, each user can install packages, and the way that works is by creating a tree of symlinks into /nix/store/*, where the actual software lives. <c107>mark_weaver: I do not yet have the means to play video, but I will watch it ASAP. Unfortunately, I have no way to copy this link. <c107>mark_weaver: That's editing a directory that does not belong to the user. <mark_weaver>/nix/store/ is managed by the guix-daemon, which normally runs as root but builds the software until isolated chroots using unprivileged user ids. <mark_weaver>the idea is that mutually untrusting users can ask the guix-daemon to build software on their behalf. that software goes into /nix/store/* <mark_weaver>and then each user can "install" some subset of the software that has been built. each one has their own symlink tree that contains just the packages they asked for. <c107>mark_weaver: So, if multiple users have identical packages, they need not waste space on duplicates? <mark_weaver>yeah, I remember running into that on my Debian box. <mark_weaver>I don't have access to my debian box from my current location, but as I recall, I had to add --with-gcrypt-prefix=? LIBGCRYPT_LIBS=? LIBGCRYPT_CFLAGS=? to the configure line <mark_weaver>where the '?' bits are exercises for the reader, for now, I'm afraid. <mark_weaver>when I get home in several hours, I can tell you more <mark_weaver>(djbclark has kindly lent me a YeeLoong 8133 to help with the Guix-on-Loongson porting effort) <mark_weaver>(and also another YeeLoong 8101B so that I can send back the faulty machine they recently sent me without losing my main dev machine) <viric>djbclark: one of your fuloong is at service for guix <mark_weaver>at this point, I can safely predict that the new MIPS N32 bootstrap tarballs (based on core-updates) will be ready before tomorrow morning. <mark_weaver>most likely, they'll be ready within about 16 hours from now. <mark_weaver>c107: did you have any luck getting past the gcrypt problem? <mark_weaver>I got mixed up, btw. I didn't have to add any of those gcrypt flags when building on debian. rather, it was when building on my home-grown distro (built from scratch using CLFS) <c107>mark_weaver: No, I think it's what I'm stuck on right now. <c107>mark_weaver: I will paste the result of `./configure`. <mark_weaver>the needed details of what went wrong will be in config.log <c107>mark_weaver: csh@cshlap:~$ whereis libgcrypt-dev <c107>mark_weaver: Neither in repo. <mark_weaver>in general, when searching for things like that on debian-derived systems, "apt-cache pkgnames libgcrypt" or "apt-cache search gcrypt" are helpful. <c107>mark_weaver: I know. I just forget to pipe it to more(1). <c107>mark_weaver: libgcrypt11-dev is already the newest version. <c107>I would have pasted `config.log` by now, but I don't have curl(1). <mark_weaver>okay, then I guess we should look in config.log for details of what went wrong. <mark_weaver>looking in that config.log, it looks like the problem is a lack of sqlite3, not anything to do with libgcrypt <c107>mark_weaver: Oh, right. That was the last message I saw once I fixed libgcrypt issues. <c107>mark_weaver: Oh, okay -- sqlite3 didn't exist. <c107>I'm installing `libsqlite3-dev`. <mark_weaver>remember, I said that in general, when building packages from source, you need the *-dev packages for each build dependency <c107>mark_weaver: I knew, and I tried to find them. I just didn't realize the serious flaws in being so lazy as to not pipe searches to more(1). <c107>mark_weaver: I didn't know about `lib*`. <mark_weaver>apt-cache pkgnames foo | grep dev; apt-cache pkgnames libfoo | grep dev <c107>Why not `apt-cache search`? <mark_weaver>that's probably fine too, but it will cast a much wider net, and probably print a bunch of irrelevant stuff. <c107>Ah, yes; that was my problem to begin with. <mark_weaver>pkgnames foo prints only packages whose names start with foo. <mark_weaver>search foo prints every package whose description (and maybe some other things) contain foo <c107>Okay. So, first try `pkgnames`, then try `search` when looking for packages. <c107>`configure` seemed to exit successfully. Doing `make install clean`. <c107>Erm, `sudo make install clean`. <mark_weaver>it's generally not recommended to do builds as root. <mark_weaver>(I'm not talking about guix in particular, just more generally) <mark_weaver>install has to be done as root, yes, but the build doesn't. <mark_weaver>also, I'm not sure I'd be so anxious to clean right away. <c107>I did it in FreeBSD, as is tradition. *c107 uses "South Park" Canadian voice. <c107>mark_weaver: Unless it's software being installed locally for one user. <mark_weaver>well, Debian derived systems go to great lengths to not only avoid doing builds as root, but even "make install" is not done as root for debian package builds. <c107>mark_weaver: It's just what's generally done. I mean, nobody seems to `cd /usr/ports/editors/emacs; make; su root; make install clean`. <c107>That'd be rather strange. *mark_weaver tries hard to do as little as possible as root <c107>This method is rather logical. It's just not what I'm used to. <c107>mark_weaver: Does this look like a proper termination? `make[1]: Leaving directory `/home/csh/guix-0.4' <c107>So, it is installed. What do I do now? <mark_weaver>you have to create some users and a group and start the daemon <c107>Reading Guix Info document. Command fragment `-s `which nologin`` fails. <c107>Cannot create Guix daemon user. <c107>I am reading Guix's info document. <c107>I'm at "Setting Up the Daemon". The user pool building commands do not work because of `-s `which nologin``. <c107>mark_weaver: Reproducing error message... <c107>mark_weaver: Oh. Now that I placed the commnads in a script file, it simply complains for lack of `useradd`. <c107>Alas, there is neither `useradd` nor `adduser`.