<cehteh>the memory sinkhole thing cant be countered by any os/bootloader once its loaded .. but luckily one needs quite high privileges to install it (loading a kernel module or otherwise running some ring-0 code at least)
<sprang>I'm trying to build guix from source on a GuixSD system... when running ./bootstrap I see "possibly undefined macro: GUILE_MODULE_AVAILABLE"
<sprang>I have ACLOCAL_PATH set to the share/aclocal in my profile
<yenda->is there a way to install a program that is not yet packaged on guix in some kind of isolated manner for easy uninstalling ?
<DusXMT>yenda-: what I like doing: stage-installing the compiled package somewhere, like /tmp/stage; creating a list of files (and links) the package contains (find /tmp/stage -type l -print > /path/to/pkg.mf; find /tmp/stage -type f -print >> /path/to/pkg.mf), using that to create a tarball of the package (tar -C /tmp/stage -cjvf /path/to/pkg.tar.bz2 $(cat /path/to/pkg.mf), and then just installing that tarball (tar
<DusXMT> -C / -xjvf /path/to/pkg.tar.bz2). When you need to remove it, just cd /; rm -v $(cat /path/to/pkg.mf)
<DusXMT>(That's the way I manage my packages on MinGW :), I have a script that does all the dirty work though)
<yenda->I would like to install leiningen to use clojure, I'll try your solution
<DusXMT>yenda-: good luck. Just a reminder, to stage-install something using Automake: make DESTDIR=/path/to/stage install
<yenda->it doesn't seem like the emacs build system is handling the dependencies well
<taylanub>elisp libraries tend to just call (require 'dependency-lib-name) and expect the user to arrange for the library to be found in the load-path, right? no pathname that we could patch to point to /gnu/store. the simplest solution would be to propagate all elisp library inputs I suppose.
<taylanub>a more involved solution might patch (provide 'foo) calls to (provide 'foo "/gnu/store/...") since apparently provide takes an optional file name
<yenda->forget what I said it was actually guix import that imported a non existing library
<daviid>ACTION is also a helicopter commercial pilot/instructor, and workded in Miami for almost 3 years ...
<mark_weaver>before the snowden leaks, I was considered paranoid. now, thanks to snowden, I now know that I was not nearly paranoid enough, and that the situation is actually far worse than I imagined.
<xentrac>output path `/gnu/store/dlay97p0qxmas1sz9ag1wys9hvwj3f5l-sqlite-autoconf-3080704.tar.gz' should have sha256 hash `1v2rhgsx27in6dcvxk0pkxc0zrbl38biimjg6c1zxz85jh9hydw6', instead has `04cvydhfrxxjbc8q07k3b3m5hymibrvk9cyizy5zzcbdwyl6d1bg'
<mark_weaver>xentrac: why are you using such an old version of Guix?
<xentrac>because when that old version of Guix tried to compile the current version of Guix, it failed
<mark_weaver>they must have changed the file in place without changing the name.
<xentrac>it seems like SF served me an HTML file actually
<xentrac>it sure looks to me like it does with tar tzvf
<mark_weaver>also, in cases where 'guix download' doesn't work for whatever reason, you can download with a different program and then pass a file URL to 'guix download' to add it to the store, like 'guix download file:///home/mhw/foo.tar.gz'
<mark_weaver>well, I can tell you that you've got a lot of compilation ahead of you. you'll have to bootstrap all of the old toolchain and utilities from 0.8.1, and then you'll need to bootstrap everything again to update to the latest versions of everything.
<mark_weaver>and each of those bootstraps is roughly analogous to what happens in Cross [GNU/]Linux From Scratch.
<xentrac>yeah, but the problem isn't the compilation time; that's not really a concern
<mark_weaver>it takes a bit more work up front, but it's vastly faster to update henceforth, and perhaps more importantly it allows me to make arbitrary modifications to guix, by keeping my own private git branch which I periodically rebase onto upstream master.
<mark_weaver>and in some cases, it turns out to be important that we don't make it easy to get that, because in some cases that original software contains non-free software in it, and making it easy to get that would jeopardize our fully-free status with the FSF.
<mark_weaver>xentrac: I suspect that's in NAR format, but I confess I'm not sure. I've never looked at that part of the system in detail.
<xentrac>It seems like "not putting previous versions of software in the hands of users" is kind of inevitably going to conflict with reproducibility, isn't it, mark_weaver? After all, reproducibility is more or less exactly "putting previous versions of software in the hands of users"
<xentrac>fwiw at the moment I'm just running `guix package -i python-ipython python-numpy`
<mark_weaver>sometimes there is a circular dependency, but one of the deps is optional, and so the circularity can be broken by building a minimal version of one of the packages first and then once you have the other package, build the full version.
<xentrac>yeah, that makes sense. so you have two separate packages that build the same tarball with different configurations?
<mark_weaver>and also, when bootstrapping the system, we need some preliminary versions of tools/libraries that were built against the old bootstrap tarballs, and then later we build another one that's built/linked with the newer versions of those tools/libraries.