IRC channel logs


back to list of logs

<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>it should be writing to its own
<paroneayea>why it isn't doing that, I don't know
<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>source code is on gna?
<daviid>sorry, wrong channel!
<daviid>oh no, right channel, man i'm tired i guess :)
<arescorpio>ERROR continuous taking from Thursday 5/28/15 until today: #### Continuo teniendo ERROR desde el jueves 28/5/15 hasta hoy :
<daviid>paroneayea: guile-dbi 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 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>ewemoa: wow awesome
<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 :)
<ewemoa>mmm, a novena...sounds nice!
<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: marsboard rk3066
<efraim>ewemoa: did you enable substitutes from
<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
<ewemoa>efraim: if you mean step 5 from here: - then yes
<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>Any ideas?
<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: getting `hook reply is declined` on local build near the end and then it fails
<efraim> doesn't try to download for local reading
<rekado>efraim: what command gives you this error?
<efraim>guix build --verbosity=5 hello
<efraim>on a fresh untarring
<rekado>how do you run the guix-daemon?
<efraim>as root
<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>so local it is
<rekado>oh, it's on ARM
<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 reads
<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>davexunit: thanks
<jackdaniel>hm, but now guile doesn't see modules '((guix packages) (guix download) …)
<davexunit>you have to include those modules at the repl
<davexunit>,use (guix packages)
<davexunit>and the guix modules need to be on the guile load path
<jackdaniel>./share/guile/site/2.0/guix.scm ?
<davexunit>are you using guixsd?
<jackdaniel>no, running on top of void linux
<jackdaniel>ok, this path seems to work
<paroneayea>jackdaniel: ./pre-inst-env guile --listen
<paroneayea>M-x connect-to-guile
<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..
<davexunit>paroneayea: you need to patch the source
<paroneayea>davexunit: :O
<davexunit>there will likely be some code like:
<davexunit>(dynamic-link "libgdbm")
<paroneayea>yep right here (define libgdbm (dynamic-link "libgdbm"))
<paroneayea>how do I patch it? any existing examples?
<davexunit>that needs to be replaced by (dynamic-link "/gnu/store/...-libgdbm/lib/") or whatever
<davexunit>the guile.scm directory should have some examples
<paroneayea>gotcha... ok
<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
<paroneayea>patching sounds way better :)
<davexunit>it's a hackier RUNPATH ;)
<daviid>paroneayea: wrt to your db quiz, i also found this
<paroneayea>very cool
<paroneayea>ohnoessss wiredtiger was "accquired" by mongodb
<daviid>wiredtiger has been purchased by mongodb though, i don't know about the license
<paroneayea>hm, gpl v2 or v3
<paroneayea>no explicit or later
<paroneayea>just 2 or 3
<daviid>sounds good to me
<paroneayea>wiredtiger looks really cool though.
<paroneayea>daviid: thanks for pointing me to that
<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
<samuel>samuel: rtfm
<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
<paroneayea>I initially called it guile-gdbm-ijp ;P
<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...
<daviid>my 2c
<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
<paroneayea>maybe it is still
<davexunit>paroneayea: the source code is copied to a temporary build directory
<davexunit>nothing would work otherwise
<paroneayea>ok :)
<paroneayea>thanks for your help davexunit
<paroneayea>sorry to bug you so much
<daviid>the other more recent? the NEWS says 2013
<paroneayea>daviid: ijp's is last commit 2012
<paroneayea>so even older ;p
<daviid>ah, too bad
<samuel>I know that I can change the file-system configuration with huix but how can I get the current filesystem configuration?
<davexunit>paroneayea: np!
<davexunit>getting closer and closer to having a containerized guix
<davexunit>but no cigar yet.
<davexunit>this docker specification document is really helpful, actually:
<davexunit>for knowing which file systems to mount where and with what options
<paroneayea>one thing I wish is that if an install failed
<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>yeah, I want the same thing.
<davexunit>but it requires some IPC between the client and daemon to make it work
<davexunit>civodul: thoughts? ;)
<paroneayea>guile-gdbm-ffi packaged
<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
<davexunit>so maybe it wouldn't be worth it anyway.
<civodul>yeah, dunno
<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>oh yes, that would be great
<civodul>or basically, we could have the container with bind-mounting facility librarified
<civodul>and so we could have 'guix environment --container'
<civodul>something like that
*davexunit has been hacking on pure Guile container modules
<civodul>yes, so how's your (container ...) module set? :-)
<civodul>that's really great stuff
<davexunit>I just got dmd to boot inside a container, but a bunch of stuff still isn't working.
<davexunit>getting there, though.
<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
<civodul>sounds promising :-)
<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>ah ok
<civodul>so it's mostly a bit of additional plumbing
<civodul> (the reference ;-)) just bind mounds individual /dev nodes
<civodul>perhaps you could do the same?
<civodul>*mounts, even
<davexunit>civodul: some things are bind mounted, others are not
<davexunit>civodul: see
<davexunit>I haven't pushed my code to any remote git repo yet, but here's a snippet of my 'call-with-container' procedure:
<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 it's around line 2047 ;-) i guess i'm used to browsing this file as a "spec"
<davexunit>civodul: that file is also very helpful.
<civodul>davexunit: nice!
<davexunit>as is
<civodul>oh right
<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. :)
<civodul>it *is* exciting!
<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
<paroneayea>davexunit: and I'm very excited for this :)
<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/ 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.
<rekado>this is the last command to be run:
<davexunit>paroneayea: current hacky usage of that procedure
<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>I have other uses for it, outside of guix
<rekado>and these are the errors:
<paroneayea>davexunit: fun :)
<davexunit>paroneayea: look mom, no initrd!
<paroneayea>oh I see
<paroneayea>the canonical sexps are from libgcrypt
<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.
<civodul>paroneayea: the libgcrypt bindings?
<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>davexunit: SIGKILL? :-)
<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.
<mark_weaver>this has never happened before to me.
<mark_weaver>fchmmr: have you seen anything like that? ^^
<fchmmr>I haven't.
<fchmmr>mark_weaver, it could just be overheating.
<fchmmr>Try to run a stress test on it.
<fchmmr>stress -c 2
<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
<fchmmr>(I don't know how to use guix)
<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>(if possible)
<fchmmr>I need to rule out that this is a problem affecting all X200 laptops
<mark_weaver>I don't have another X200
<fchmmr>you live near the FSF office, don't you?
<fchmmr>so you do have another X200 ;)
<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
<mark_weaver>fchmmr: okay, sounds good. thanks!
<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)
<mark_weaver>fchmmr: any progress on the Asus KFSN-DRE4 ?
<fchmmr>The KFSN4-DRE
<fchmmr>none yet. I still need to pay customs for it
<mark_weaver>ah, right :)
<fchmmr>I'll do that tomorrow
<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>those are from
<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?
<mark_weaver>what are you trying to do?
<jackdaniel>I'm reading documentation, and guix import is supposed to download scm as far as I understand
<jackdaniel>with package definition
<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.
<mark_weaver>e.g. its source code is not in<package-name>/ like most GNU packages
<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.
<davexunit>it was just weird.