<paroneayea>it's automake though I'm sure where it decides that prefix <daviid>paroneayea: also, i don't know guix yet but you should never have to create share/guile/site right? since guile-dbi depends on guile <paroneayea>daviid: well, it shouldn't be writing to guile's store directory <paroneayea>autotools often defies my ability to grok it :\\ <daviid>ah ok, then guile-dbi prob looks for this dir and you'll have to change it to its own store i guess <daviid>oh no, right channel, man i'm tired i guess :) <daviid>paroneayea: guile-dbi Makefile.am must define somewhere that it wants to install in share/guile/site, since it is not 'standard' ***init is now known as exio4
<daviid>or some file Makefile.am includes <ewemoa>to any interested parties: guix 0.8.2 armhf seems to work on an rpi 2 (tried on top of arch linux arm) -- have installed and run 'hello', now waiting for tmux to install <davexunit>I have a Novena that I need to bootstrap Guix on <davexunit>but without armhf build slaves I fear the amount of full system rebuilds I need to do. <ewemoa>davexunit: it did take quite some number of hours to get 'hello' installed :) <davexunit>I haven't used it as much as I would like to yet. <efraim>ewemoa: did you get a "guix package: error: build failed: unable to fork: Invalid argument" error? thats what i'm getting on my armhf marsboard ontop of debian <efraim>at some point before you got hello installed <ewemoa>efraim: i don't have the output of guix package recorded so i don't know, sorry -- one thing i needed to do was change permissions of some directories, but apart from that atm i don't recall having other difficulties <ewemoa>efraim: ah, i remember having to reconfigure /tmp to not live in ram, but perhaps that's not so relevant <efraim>ewemoa: mine's already not in ram <efraim>ewemoa: i have my 1gb of ram and i tried increasing swap to 1.5gb. <ewemoa>efraim: ah. hmmm, marsboard, looks interesting, if you don't mind me asking, which one? <efraim>ewemoa: did you enable substitutes from hydra.gnu.org? <efraim>fun error on building hello: hook reply is `decline' <efraim>`guix build` with --no-build-hook got rid of that error, still no build <rekado>an application I want to package bundles libraries. I've been packaging each of these libs separately and now run into a problem linking the final executable. <rekado>the library is withershins and it links with libbdf and libiberty. <rekado>when I link against my version of withershins the executable cannot be linked because symbols referring to libbdf cannot be resolved. <rekado>so I'm now trying to link with libbfd as well. <rekado>at link time I get this error, though: /gnu/store/2gnamrvrs686i93njmw9a07hvqk8zi5x-binutils-2.25/bin/ld: /gnu/store/2gnamrvrs686i93njmw9a07hvqk8zi5x-binutils-2.25/lib/libbfd.a(plugin.o): undefined reference to symbol 'dlsym@@GLIBC_2.2.5' <rekado>I don't know what this means and why it happens. <rekado>does this mean that the lib expects a different version of glibc? <rekado>I think it's because ld from binutils is used instead of ld-wrapper. <rekado>trying again with gcc-toolchain as input, even though this all seems wrong... <efraim>having trouble with building on a local machine, output from verbosity=5 here: flashner.co.il/~efraim/hello.log. getting `hook reply is declined` on local build near the end and then it fails <rekado>efraim: what command gives you this error? <efraim>/root/...../guix-daemon --build-users-group=guix-builder <rekado>and you actually want to build everything locally, right? No binary substitutes? <efraim>I could go either way, but hydra doesn't have substitutes for armhf <efraim>after it finds guix-builder{1..10} the next couple of lines confuse me where it looks like it sees uid 999 and fails <davexunit>docker container discussion, thanks to paroneayea for posting about it <jackdaniel>what is a correct emacs mode for defining packages in buffer? (to have autocompletions etc?) <jackdaniel>geiser-mode with guile set as used implementation doesn't seem to attach itself to running guix repl <davexunit>jackdaniel: you would start your own guile repl <jackdaniel>hm, but now guile doesn't see modules '((guix packages) (guix download) …) <davexunit>you have to include those modules at the repl <davexunit>and the guix modules need to be on the guile load path <paroneayea>wow, git is a much bigger program than I remember it being. *davexunit wonders if we should be splitting git into multiple outputs <paroneayea>my package for guile-gdbm-ffi doesn't work because the ffi can't actually find gdbm.. <paroneayea>yep right here (define libgdbm (dynamic-link "libgdbm")) <davexunit>that needs to be replaced by (dynamic-link "/gnu/store/...-libgdbm/lib/libgdbm.so") or whatever <davexunit>the guile.scm directory should have some examples <davexunit>perhaps a guile-build-system should be created which is like the gnu-build-system but with an additional phase to make this substitute* call <davexunit>without editing the source like this, you'd have to set $LD_LIBRARY_PATH in order for libgdbm to be found in the store <davexunit>before running an application that used guile-gdbm <daviid>wiredtiger has been purchased by mongodb though, i don't know about the license <paroneayea>I wish it was or later, but still looks promising <daviid>np, but you wish what? did not get that wish :) <samuel>hi, i just installed guix and I'm wondering where the /etc/fstab is, I want to set the discard flag <daviid>we should better keep track of those bindings in guile's app/lib webpage by the way <paroneayea>davexunit: I'm a little bit confused as to what happens with substitute* <paroneayea>I'm using trivial-build-system here rather than the gnu one since it's just copying a file <paroneayea>I assume it's not changing the input, since that's not allowed <daviid>paroneayea: i would not call ijp's binding guile-gdbm-ffi in guix, why not just guile-gdbm? [i'd rather call the other guile-gdbm-<something> <paroneayea>daviid: I don't know, one of them uses the ffi and one doesn't, and I'm not really stuck on a name <davexunit>paroneayea: your build script would call substitute* <paroneayea>davexunit: right. Does it override the file? or does it write out a new one? or just return the string? <daviid>well, ijp's is recent, likely to be wel maintained and people looking for a package will hit guile-gdbm first, i'd call it the other guile-gdbm-vola or something... <davexunit>paroneayea: it modifies the files that have regexp matches <paroneayea>daviid: the other one has more recnet work, though I have a preference towards ijp's because it's a lot simpler <paroneayea>davexunit: I see... I thought that was forbidden on inputs <davexunit>paroneayea: the source code is copied to a temporary build directory <daviid>the other more recent? the NEWS says 2013 <samuel>I know that I can change the file-system configuration with huix but how can I get the current filesystem configuration? <davexunit>getting closer and closer to having a containerized guix <davexunit>for knowing which file systems to mount where and with what options <paroneayea>that I had a nice way to jumping straight to a debugger <paroneayea>or, for a way to insert a breakpoint right into the package I'm working on's build code <davexunit>but it requires some IPC between the client and daemon to make it work <civodul>davexunit: i'm not sure exactly how to do that, beyond -K <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, phant0mas says: I found what the problem was, patched gcc-4.8, waiting for the build to finish and I will report back. <davexunit>civodul: I imagine it would require some daemon changes <davexunit>or *something* that allowed us to connect to a guile REPL (or perhaps any process) from within the build container <davexunit>setns() could be used to join the namespaces of the container and launch a shell, for example. <davexunit>though of course the results of this build would have to be thrown out <civodul>we could do something like that, but i wonder how much it would improve the situation <civodul>situations where "guix build -K" is not enough is for test suites that break exclusively when run in the container, and not outside <davexunit>civodul: then maybe what's needed is a tool to spawn a similar container <davexunit>like how there's an environment variables file <davexunit>there could be a script that would launch a process in a similar container. <civodul>or basically, we could have the container with bind-mounting facility librarified <civodul>and so we could have 'guix environment --container' *davexunit has been hacking on pure Guile container modules <civodul>yes, so how's your (container ...) module set? :-) <davexunit>I just got dmd to boot inside a container, but a bunch of stuff still isn't working. <davexunit>the Docker specification file has been really helpful. I now know which file systems I need to mount, which things to symlink, etc. <davexunit>I got just past the point where a service creates all the user and group accounts successfully <paroneayea>davexunit: see? docker's helpful for following how to do things right ;) <davexunit>and then the term-tty* services failed because I'm missing device nodes and such. <civodul>so it's mostly a bit of additional plumbing <civodul>build.cc (the reference ;-)) just bind mounds individual /dev nodes <davexunit>civodul: some things are bind mounted, others are not <rekado>blerg, CMake with RUNPATH is something I can't get to work. <davexunit>also, I was finally able to write a wrapper for the clone() syscall that doesn't do any of that stack craziness like in the glibc wrapper. <civodul>davexunit: in build.cc it's around line 2047 ;-) i guess i'm used to browsing this file as a "spec" <civodul>rekado: CMake with RUNPATH is terrible <civodul>but apparently cmake-build-system does the right thing, doesn't it? <davexunit>pflask is very straightforward C code, so it's been a good resource <davexunit>the docker/libcontainer project has been occasionally helpful <davexunit>anyway, I'll stop rambling. I'm just excited. :) <rekado>civodul: I've got two different packages now that are stuck because of that. (Maybe I just don't get CMake. Am I weird in preferring Automake?) <civodul>that opens the way for a whole bunch of things <paroneayea>davexunit: (call-with-container) is a great name <davexunit>my current target is a 'guix system container' command that will spawn a one-off container. in a certain glorious future, a daemon could manage containers on behalf of unprivileged users, even. <civodul>rekado: so they use cmake-build-system but somehow some binaries don't get the RUNPATH? <rekado>In particular it's boost and qt5 libs that are not found in the RUNPATH. <rekado>gcc libs are found, however, so the RUNPATH isn't empty. <civodul>rekado: is there an explicit -lqt5 or /foo/libQt5.so on the command line? <civodul>or could you paste the build log somewhere? <rekado>the full paths to the libraries are in the build log. <paroneayea>civodul: btw how would you feel about if I refactored guix's canonical sexp implementation and submitted to be included in guile proper? <paroneayea>maybe there could be a nicer more guile'y canonical sexp implementation <rekado>after reading CMake docs I guess I could just specify CMAKE_INSTALL_RPATH, a semicolon-separated list of directories. <rekado>LIBRARY_PATH should contain the right directories already. <davexunit>civodul: is there any signal that I can send dmd to reliably kill it? <civodul>rekado: i wonder why the ld-wrapper doesn't DTRT directly since the command line looks OK <civodul>you probably need to use cgroups to make sure no process is left behind, no? <davexunit>civodul: for some reason 'kill -9' ain't working for a dmd that is PID 1 in a new namespace <davexunit>I'm trying to kill it from outside the namespace, where it of course has a different process id. <davexunit>civodul: if the init process dies, so do the others <rekado>even when passing a long list of paths as CMAKE_INSTALL_RPATH, the effective RUNPATH still only contains the lib directories of gcc and glibc. <mark_weaver>well, I just tried building 'libreoffice' twice. Both times (while building altas I believe) my Libreboot X200 abruptly turned off (all lights off), and I had to take the battery out to get it to come back on again. <fchmmr>mark_weaver, it could just be overheating. <fchmmr>and run "xsensors" to get the temperature <fchmmr>80C or less for CPU, this is desirable (it will get to a max temperature, and then stop rising eventually. 80 or less is ok) <mark_weaver>fchmmr: is that how the Libreboot X200 reacts to overheating? My X60 acted differently. <mark_weaver>I've built a lot of software on this machine, and it has never gotten anywhere near as hot as my X60 was <fchmmr>I'm not sure why you experienced this. <fchmmr>I'd have to try and reproduce it on my end. <fchmmr>mark_weaver, write a bash script for me, which does the following in trisquel 7: <fchmmr>* downloads and installs all of the build dependencies for libreoffice (these could be pulled from apt-get) <fchmmr>* downloads and builds the libreoffice source code <fchmmr>for the version that you are trying to build <fchmmr>I will run this on my X200, and try to reproduce the issue <mark_weaver>fchmmr: that would be a lot of work, and I don't have a Trisquel system on which to test. <fchmmr>could you try it on another X200? <fchmmr>I need to rule out that this is a problem affecting all X200 laptops <fchmmr>you live near the FSF office, don't you? <mark_weaver>it would be a lot less work for you to try building altas on guix <fchmmr>ok, mail me the instructions for what you want me to do <mark_weaver>which is what was being built when the poweroff happened, at least the second time. <fchmmr>I need a detailed list of steps, to try and reproduce the same issue <fchmmr>mark_weaver, note, I often have very little time. so there may be a delay for me actually doing it. but I will do it, if you need me to. <mark_weaver>fchmmr: that's fine, I appreciate it. actually, this is a low priority compared with many other things. <fchmmr>next week is extreme. I'm going to be very very^2 busy <fchmmr>(that could be simplified to very^3) <fchmmr>none yet. I still need to pay customs for it <fchmmr>also, I still need to buy everything else (heatsink, fan, case, psu, plcc chip extractor, spare plcc chips) <fchmmr>next week I have the following work planned: <fchmmr>* gluglug work (a lot of it), plus I have to update my records and so on (been getting a bit behind lately) <-- first priority <fchmmr>* libreboot work (documentation changes, improvements, bug fixes): <fchmmr> ---> rebase on latest coreboot. I have about 20 patches to rebase, some of which are from other people so I need to get the rebases upstream too <fchmmr> ---> git bisect on the X200, to find what commit broke text-mode graphics init <fchmmr> ---> try to find out why certain screens don't work on certain laptops (probably EDID related) <fchmmr> ----> try to add R500 and W500 to libreboot <fchmmr>---> fix memtest86+ in libreboot (doesn't work at the moment. no idea why) <fchmmr> ---> finish implementing i18n on libreboot site and docs, split docs into a separate repo <fchmmr>the ones I listed are my priorities next week.... <fchmmr>* get new internet connection running. I bought a new internet connection a while ago, but haven't set it up yet. I need to set that up, with this configuration: <fchmmr>note: the main router will actually be librecmc, not an X60. <fchmmr>I want to do all of that next week ;) <fchmmr>some of it I was supposed to do this week, and the week before <jackdaniel>if I want to import some package, correct command woud be ie `guix import gnu linux-libre`, right? <jackdaniel>it throws an ftp-error "failed to change directory <mark_weaver>jackdaniel: we already have linux-libre in guix. what do you mean by "import" it? <jackdaniel>I'm reading documentation, and guix import is supposed to download scm as far as I understand <mark_weaver>jackdaniel: 'guix import gnu' is to automatically create a simple package definition that will work for basic GNU packages. 'linux-libre' is already in Guix, so it doesn't make sense to import it. also, it's not handled like most GNU packages, and has complications, so 'guix import gnu' wouldn't work anyway. <jackdaniel>hm, I tought it will just download scm file (I can navigate to it via emacs) <mark_weaver>and that's the reason for the 'ftp-error', but it would have failed for other reasons later anyway. <mark_weaver>jackdaniel: no, the *.scm files are already included in the guix tarball package. <jackdaniel>ok, so guix import actually tries to convert build instructions from other packaging format? *mark_weaver goes offline, back in a bit... <civodul>davexunit: you want to kill dmd without killing its child processes? <civodul>rekado: if you have the failed build tree, could you try setting GUIX_LD_WRAPPER_DEBUG=yes and force a rebuild of the faulty binaries? <civodul>it might also be that CMake overrides the RUNPATH later on <davexunit>civodul: no, just kill it all. killing dmd is enough to kill everything else. I ended up getting it done. 