IRC channel logs
2015-06-03.log
back to list of logs
<fingers>i am relatively new with gnu/linux. will guix be simple enough for me to use conventionally, but advanced enough for me to use and "grow into" as I get better at gnu/linux computing? <bavier>fingers: Guix and GuixSD are currently "alpha" software <bavier>fingers: that being said, we'd love for you to give it a try and report back to us <rekado>I've got this package that segfaults when /dev/snd/seq doesn't exist. It's working fine after loading the kernel modules snd-seq-device and snd-seq. <efraim>installing guix from source is ./configure && make && sudo make install? <rekado_>efraim: you also need ./boostrap first IIRC. <rekado_>see HACKING in the git checkout for more info. <civodul>./boostrap is only when building from a git checkout <efraim>thats what I'm trying on my armhf board, building from a git checkout <civodul>oh, you don't want to use the binary tarball? <efraim>i tried the binary tarball and I got some error about being unable to fork <efraim>i don't remember the exact error, not in front of the machine atm <civodul>oh that was about name space flags for clone(2) no? <civodul>you'll probably have the same issue here <mthl>davexunit: good morning america :) <civodul>hmm i would expect it to be recent enough, dunno <davexunit>mthl: good morning america, indeed. I learned this morning that there's been a FBI spy plane circling Boston for awhile now. <civodul>efraim: could you try running it again and strace'ing it to see what happens? <davexunit>the plane is registered to a made-up company. *civodul goes afk for a while <civodul>davexunit: and the company happens to be a fake? <davexunit>the one in Boston is registered to "RKT Productions" <paroneayea>see, I knew I was using Guile over Racket for a reason! <rekado_>woo, Rémi wrote an email about the status of the GNUnet GSoC project! Yay! <grothoff>davexunit: it would be really great if the Linux people finally supported SO_REUSEPORT for AF_UNIX... <davexunit>grothoff: has there been any work in that direction? <davexunit>I admittedly don't know much about this stuff <akfoss`>i wanna install GuixSD on a my Thinkpad X200, but I cannot setup my network connection. Pinging www.google.com gives me this message 'unknown host' <davexunit>akfoss`: ethernet or wireless network connection? <akfoss`>runnig 'dhclient ep0s25' outputs this message: 'ifconfig: SIOCSIFFADDR failed: No such device' <akfoss`>But I can ping google.com successfully. <rekado_>akfoss`: note that davexunit mistyped "enp0s25" as "ep0s25" <civodul>efraim: could you email bug-guix@gnu.org with the output of "uname -a" and "ldd --version", as well as the file 'log' produced by 'sudo strace -o log guix-daemon --build-users-group=guixbuild' when running something like 'guix build hello'? <efraim>civodul: sure. right now I'm still at school but I can try to do it in a couple of hours <civodul>(and also the Guix version or commit) <efraim>is gnunet supposed to include gnunet-gtk? I didn't get it from hydra <wingo>does meta/gdb-uninstalled-guile work for people using guix? <wingo>for me i get some bizarre error <wingo>maybe the error is only when running in an environment that has guile 2.0, but that would be strange <wingo>or would it be that gdb in guix is linked against guile? <wingo>but using some strange incantation that mucks with an inferior guile's enviroment variables? <mark_weaver>wingo: for me, it works on stable-2.0 but not on master. <mark_weaver>on master I get this: Throw to key misc-error with args ("make_objcode_from_file" "bad header on object file: ~s" ("\\x7fELF\\x02\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00") #f)Aborting. <mark_weaver>I see that we don't wrap 'gdb' (with a script that sets environment variables) <mark_weaver>wingo: my guess is that it's the other way around: all the environment variables we set in meta/uninstalled-env is messing up the guile-2.0-linked gdb. <mark_weaver>notably: GUILE_LOAD_PATH, GUILE_LOAD_COMPILED_PATH, LTDL_LIBRARY_PATH, and maybe GUILE <wingo>mark_weaver: yes i get the same on master <wingo>i think GUILE probably shouldn't have anything to do with anything because gdb doesn't use the guile binary <wingo>but everything else could be an issue <wingo>i wonder what the right thing to do is <davexunit>LTDL_LIBRARY_PATH sounds like a possible culprit <wingo>i mean, probably the GUILE_LOAD{,_COMPILED}_PATH <wingo>because the error is from a guile 2.0 routine <wingo>expecting a guile 2.0 .go file <wingo>and getting a guile 2.2 .go file <mark_weaver>ideally, we would postpone setting those variables until gdb is running, and set them only in the inferior (debugged) guile process. <wingo>and it's not a thing that you have to do with any other piece of software <mark_weaver>I don't know how hard it is. my knowledge of gdb is weak, but I suspect a gdb expert could come up with something. <wingo>but do you think it's the right thing? <wingo>i mean, you don't want GDB messing up because you have an environment variable set. <wingo>that's not a failure mode i have had to consider in the past at least <mark_weaver>well, someone might also want to customize the load path of the guile used in gdb. <mark_weaver>so it's not clear to me that gdb should wipe those environment variables. <mark_weaver>but maybe they should be given different names, like GDB_GUILE_LOAD_PATH et al <mark_weaver>in such a scheme, gdb would copy GDB_GUILE_LOAD_PATH to GUILE_LOAD_PATH (and others) within its own process before initializing libguile, but propagate the inherited environment as-is to the debugged process. <mark_weaver>(and if GDB_GUILE_LOAD_PATH doesn't exist, then GUILE_LOAD_PATH would be removed from the gdb process) <mark_weaver>but this might be less convenient for people who use the guile-gdb extensions with custom load path, but mostly work on debugging other software. <mark_weaver>it's not clear to me that this GDB_GUILE_LOAD_PATH idea is better than hacking 'gdb-uninstalled-guile'. <wingo>well, i guess there is a general case of gdb foo where foo uses guile <wingo>if the user specified a GUILE_LOAD_PATH, which should it apply to? <wingo>also it appears that somehow there is a GUILE_LOAD_PATH being set because of guix <mark_weaver>actually, even apart from gdb, this will be problematic in environments using both guile-2.0 and guile-2.2. <mark_weaver>how do you set your GUILE_LOAD_PATH when you're using some software linked with libguile-2.0 and some using 2.2 ? <paroneayea>usually for python, each python version "knows" its path of things it loads from <paroneayea>if users are doing development with, say, a virtualenv <paroneayea>that virtualenv will set a PYTHONPATH, but the virtualenv is also bound to a particular python version <mark_weaver>this is why I dislike environment variables, and fluids/parameters, even though I don't know a better solution in many cases. <wingo>paroneayea: yeah but what about gdb <wingo>i mean, gdb has python extensions <wingo>and can debug programs linked to python <wingo>and python has environment variables <wingo>so surely they have come to some kind of solution <paroneayea>wingo: I suspect gdb is linked to just one python version right? <wingo>paroneayea: dunno, seems similar to my case <wingo>guix gdb is linked against guile 2.0, i am working on guile 2.0 <wingo>guix gdb is linked against guile 2.0, i am working on guile 2.2 <wingo>s/guile 2/python 3/ and it could be the same issue <mark_weaver>on typical systems with software installed in fixed places on the filesystem, these kinds of environment variables are often not needed, so most users probably manage to avoid these problems. <mark_weaver>one solution would be to support additional per-guile-major-version environment variables such as GUILE_2_2_LOAD_PATH <wingo>yeah but i suspect with gdb that's a not-uncommon thing <mark_weaver>so GUILE_LOAD_PATH would be consulted by any version of guile <mark_weaver>I think that we'll probably need something like that anyway <wingo>would be irritating to have an installed gdb start loading uninstalled files tho <wingo>if they were the same versoin <wingo>but i guess that's really just a case when developing guile <wingo>paroneayea: i just removed guile from my profile :) *wingo not used to being able to just invoke guile <wingo>paroneayea: but i would need to update gdb too :) <mark_weaver>wingo: I still think it would be worthwhile to have 'gdb-uninstalled-guile' be more focused in where it sets the environment variables <wingo>anyway, guile 2.2 isn't stable so i wouldn't want to build it with guix <paroneayea>maybe building the tools you're using to hack guix in a guix environment would help? <mark_weaver>this is a fundamental problem with environment variables / fluids / parameters: they end up propagating to places where you don't really want them to go. anything we can do to make that more focused is a good thing, IMO. <wingo>i wonder if we will run against libtools abstractions tho <wingo>given that libguile/guile is a libtool wrapper <paroneayea>environment variable seem a lot worse than fluids/parameters <mark_weaver>paroneayea: they are fundamentally the same concept, iiuc <paroneayea>I guess you can start up subshells as a kind of dynamic-wind <wingo>parameters do have some lexical scope tho <wingo>i mean, their identity isn't their name <mark_weaver>right, fluids/parameters essentially have two names: the name in the code is looked up lexically, and that is bound to a sort of internal name (an integer) that is used to look it up in the dynamic environment. <mark_weaver>wingo: so, gdb allows you to set the environment for the debugged process using commands like "set environment VARNAME [=VALUE]", without setting them in the gdb process itself. <mark_weaver>wingo: and there are -init-command and -init-eval-command options to gdb. <mark_weaver>combining those two, I think it would be pretty easy to do it. <efraim>how do I set my locale if I installed using the guix binary? <efraim>I keep on getting: warning: failed to install locale: Invalid argument <davexunit>efraim: install glibc-utf8-locales and set $LOCPATH to $HOME/.guix-profile/lib/locale <mark_weaver>glibc-utf8-locales has only a few locales, but maybe the ones you need. <mark_weaver>if you need other locales, one option is to create a 'locale' directory somewhere in your home dir, and use 'localedef' to generate locales in there. <mark_weaver>(on GuixSD we handle creating a directory with your chosen locales automatically) <mark_weaver>alternatively, we have a more extensive 'glibc-locales' package that is quite large. <davexunit>I went for glibc-utf8-locales because it was much smaller in size <davexunit>and then name made me feel like it was the "right thing" <mark_weaver>yeah, that package is fine for those of us in the major imperalist countries <paroneayea>as an aside, guile master should totally have a package.scm ;) <davexunit>paroneayea: perhaps I'll submit a patch for one, though not being able to actually build the software with guix from that package definition is the current bummer. <davexunit>since I currently have no way to tell guix "use this directory as the source origin, but only copy the version controlled files" <paroneayea>on another note, I think I'm really truly going to get the mediagoblin release out tomorrow <paroneayea>then a week or so from the release I'll finally get my sabattical <civodul>efraim: ooh, while merging bits from the Nix daemon, i noticed a comment that its use of clone(2) requires Linux 3.13+ <davexunit>hmm, I thought those were in earlier than that. <civodul>we don't use CLONE_PARENT (yet) in our daemon <davexunit>I love that edolstra's avatar is Dexter from Dexter's Laboratory. <civodul>that's because the Nix daemon mixes threads + fork/clone <civodul>the git log is full of try this/revert that in that area ;-) <civodul>so we'll stay away from that and a couple of other things <civodul>and *then*, we'll use your container code to write the new daemon :-) <bavier>I was looking at packaging git-annex, and ooo the dependencies. <bavier>the hackage importer should help considerably 
