IRC channel logs


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
<davexunit>good evening #guix
<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.
<civodul>Hello Guix!
<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.
<efraim>rekado_: ok, thanks
<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?
<civodul>or maybe you already did?
<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
<civodul>what kernel version does it run?
<davexunit>good morning, #guix.
<mthl>davexunit: good morning america :)
<efraim>civodul: its listed as 3.0.36+
<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>civodul: yup
<davexunit>more details for those interested
<efraim>civodul: sure. the last time I ran guix build hello I added --verbose=5 and put the output at
<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!
<paroneayea>hey great!
<davexunit>interesting socket option (SO_REUSEPORT) that I did not know about:
<grothoff>davexunit: it would be really great if the Linux people finally supported SO_REUSEPORT for AF_UNIX...
<grothoff>That's where we really need it...
<davexunit>grothoff: has there been any work in that direction?
<davexunit>I admittedly don't know much about this stuff
<grothoff>not AFAIK.
<akfoss`>i wanna install GuixSD on a my Thinkpad X200, but I cannot setup my network connection. Pinging gives me this message 'unknown host'
<davexunit>akfoss`: ethernet or wireless network connection?
<akfoss`>This is my kernel module: e1000e
<davexunit>okay so this should be easy
<davexunit>what does 'ifconfig -a' output?
<davexunit>ifconfig enp0s25 up
<davexunit>dhclient ep0s25
<akfoss`>runnig 'dhclient ep0s25' outputs this message: 'ifconfig: SIOCSIFFADDR failed: No such device'
<akfoss`>But I can ping successfully.
<rekado_>akfoss`: note that davexunit mistyped "enp0s25" as "ep0s25"
<rekado_>try "dhclient enp0s25".
<akfoss`>yup, you're right.
<civodul>efraim: could you email 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>ok, np!
<civodul>(and also the Guix version or commit)
<paroneayea> boo sourceforge
<efraim>is gnunet supposed to include gnunet-gtk? I didn't get it from hydra
<paroneayea>I just ran gnunet-gtk yesterday
<paroneayea>I was surprised that the UI went from this to this
<paroneayea>pretty weird change
<wingo>does meta/gdb-uninstalled-guile work for people using guix?
<wingo>for me i get some bizarre error
<wingo>this is in guile itself btw
<wingo>maybe the error is only when running in an environment that has guile 2.0, but that would be strange
<davexunit>paroneayea: wat that is terrible
<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>whereas meta/uninstalled-env guile works
<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.
<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 think it's something else
<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>that is hard tho :)
<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.
<wingo>that is a nice idea
<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>installed or not
<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
<wingo>it's a puzzler
<wingo>i wonder what python does
<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
<paroneayea>but yeah I don't know really
<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
<wingo>sure, that could work too
<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
<mark_weaver>independently of gdb
<wingo>if they were the same versoin
<wingo>but i guess that's really just a case when developing guile
<paroneayea>start a new guix profile with only guile 2.2 ;)
<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
<wingo>mark_weaver: sure.
<wingo>make sense to me
<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
<paroneayea>more like general global variables
<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
<wingo>anyway :)
<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>good points mark_weaver
<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
<efraim>i normally set mine to en_US so that should work
<paroneayea>as an aside, guile master should totally have a package.scm ;)
<paroneayea>(not that it's too hard to build)
<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 nods
<paroneayea>on another note, I think I'm really truly going to get the mediagoblin release out tomorrow
<paroneayea>the packaging still sucks but
<paroneayea>then a week or so from the release I'll finally get my sabattical
<paroneayea>and I can help on guixops
<civodul>efraim: ooh, while merging bits from the Nix daemon, i noticed a comment that its use of clone(2) requires Linux 3.13+
<civodul>for PID name spaces
<davexunit>hmm, I thought those were in earlier than that.
<davexunit>do you mean user namespaces?
<civodul>actually no, false alarm
<civodul>we don't use CLONE_PARENT (yet) in our daemon
<civodul>yeah, and we won't do that
<davexunit>we won't use CLONE_PARENT?
<davexunit>I love that edolstra's avatar is Dexter from Dexter's Laboratory.
<civodul>we don't have to use it, AIUI
<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 code will slowly diverge
<civodul>and *then*, we'll use your container code to write the new daemon :-)
<davexunit>civodul: hehe aye aye captain!
<bavier>I was looking at packaging git-annex, and ooo the dependencies.
<civodul>bavier: it's Haskell, right?
<bavier>civodul: yes
<bavier>the hackage importer should help considerably