IRC channel logs

2015-10-06.log

back to list of logs

<codemac>question - anyone here run guix beneath another OS?
<codemac>the bin vs. sbin thing is really annoying me with guix, but I can't put my finger on exactly why. I don't want to use the guix installed "reboot" command or whatever, but then bitlbee is in sbin as well so it needs to be in my path. I'd rather we unified them all into one directory.. but then that breaks my case where I don't want halt / reboot to be dmd commands but my normal systemd commands
<amz3>beneath?
<codemac>along side?
<codemac>I run arch on my root, and guix for my user
<codemac>and so I didn't put guix's sbin in my path because I didn't want to accidentally run deco commands or things that wouldn't work.
<amz3>I tink you can create a bash script to source when you want to work on guix stuff
<amz3>no?
<codemac>I just want to be able to run bitlbee without having `halt` in my path. I have installed dmd to use as a user, but this means I also have poweroff commands and whatnot in my user's .guix-profile
<codemac>Ideally, guix would just dump everything into a single path (since it's managing the symlinks anyways) and then I could just split up the dmd package or something locally to not include the halt / reboot scripts.
<codemac>I guess I could still split up the dmd script for now, but I'm curious what guix people think about getting rid of the difference between sbin and bin
<bavier1>I think we should have an additional 'develop-inputs' field for packages
<bavier1>so that e.g. `guix environment guix` actually provides the software required for building guix from a git checkout
<davexunit>bavier1: 'guix environment guix' already does this
<bavier1>currently one has to add all sorts of other packages manually: automake autoconf graphviz help2man
<davexunit>those are already inputs to the guix-devel package.
<bavier1>davexunit: ahh, I hadn't thought to 'guix environment guix-devel'
<davexunit>well 'guix environment guix' does that
<davexunit>guix-devel is just the variable name
<davexunit>develop-inputs would not make sense
<bavier1>davexunit: no?
<davexunit>no.
<bavier1>:P
<davexunit>because packages that need those things to build should have them in native-inputs or whatever.
<davexunit>my development packages for my personal projects do this
<davexunit>the packages can build from a git snapshot, which makes them suitable for 'guix environment' to use so that you can do development
<bavier1>but most of our packages assume building from distribution tarballs, which usually require a subset of the software that's necessary to build from a VCS checkout
<bavier1>e.g. any autotool-based software
<davexunit>you're getting confused.
<davexunit>those packages aren't for building from VCS checkouts
<davexunit>they are for building from tarballs
<davexunit>and thus their environments are for the same
<davexunit>this is good.
<davexunit>'guix environment' is supposed to reproduce the build container environment as closely as possible.
<davexunit>the upcoming --container flag takes this another step further
<bavier1>yes, I see
<bavier1>and for development from VCS one would be expected to provide such a package themselves
<bavier1>if not already available
<davexunit>yes
<davexunit>since such packages have different requirements
<bavier1>but it would seem useful to me to provide some way to reduce such duplicated efforts
<davexunit>for example, I supply such a package with one of my pieces of software: https://git.dthompson.us/haunt.git/blob/HEAD:/package.scm
<davexunit>users can checkout my git repo and choose to install the package within or make a dev environment from it.
<davexunit>the effort isn't really that duplicated because to actually build from a git checkout typically requires several special steps that aren't needed when building from a tarball
<davexunit>and the source is also different
<davexunit>since it's a git checkout or whatever and not a tarball
<bavier1>yeah, synchronization of the devel package with upstream would become difficult
<davexunit>yeah, they ought to remain separate things. they are different beasts.
<bavier1>if only everyone would provide a package recipe in their repos :)
<davexunit>we can encourage it :)
<davexunit>I will be submitting one to include with Geiser at some point, for example.
<bavier1>cool
<bavier1>thanks for the thought-share
<davexunit>np
<bavier1>I was just feeling a bit frustrated, which I think now is due more to my 'guix environment' being out-of-date
<davexunit>yeah I think that's the case.
<davexunit>since I haven't experienced any issue
<davexunit>and I see that guix-devel clearly has graphviz and co. as inputs
***anthk_ is now known as anthk
<bavier1>ergh, imagemagick's 'convert' fails with cryptic error messages if its delegate programs aren't installed
<civodul>Hello Guix!
<civodul>NixOS & Guix at http://youbroketheinternet.org/map
<chil>In guixsd, I need to edit config.scm and do a 'guix system reconfigure' instead of editing /etc files?
<civodul>chil: yes, exactly
<chil>and to update the base os I also need to run 'guix system reconfigure'?
<civodul>chil: yes, it does both
<civodul>it can be thought as a way to update the OS configuration, and part of that configuration is the set of installed packages
<chil>ok, thanks civodul :)
<civodul>yw!
***anthk_ is now known as anthk
***francis7 is now known as guest1
***guest1 is now known as francis7
<paroneayea>hello, *!
<davexunit>civodul: I realized that 'guix environment' builds the source derivation for packages. d'oh!
<civodul>davexunit: yeah i noticed as well :-)
<civodul>i think we'll have to make it build a profile
<davexunit>that would defeat the tool :(
<civodul>that would also address http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19816
<civodul>no, i mean build a profile, but not add it to ~/.guix-profile or whatever
<civodul>just build it and use it on the fly
<civodul>see what i mean?
<davexunit>okay
<civodul>thoughts? :-)
<davexunit>then from there I guess it would easy to make wingo and rekado happy and provide an option to put a link to that profile somewhere accessible
<davexunit>for long-lived profiles
<davexunit>but then it would have to be a gc root
<civodul>yes, right
<civodul>like 'guix environment --save=/foo'
<davexunit>yeah
<davexunit>civodul: do you know if there's a way to convince pkg-config (or other autoconf thing) to create a variable with the absolute file name of a shared library?
<davexunit>I wish that we didn't need --with-libgcrypt-prefix, and I'm at a similar crossroads in one of my FFI using projects.
<civodul>davexunit: i don't know any nice way to do that :-/
<davexunit>for Sly, my dev packages adds a native search path for LD_LIBRARY_PATH to circumvent the issue
<davexunit>civodul: okay, bummer. :(
<davexunit>PKG_CHECK_MODULES does create a variable like FOO_LIBS, in which there may be a -L flag that can be parsed.
<civodul>you could set LTDL_LIBRARY_PATH, which is "less bad"
<davexunit>er, that's what I meant.
<civodul>right, FOO_LIBS contains -L flags
<davexunit>yes that one is less bad.
<civodul>i guess one could simply write a function equivalent to 'which' but for shared libraries
<davexunit>yeah
<davexunit>I may try that
<iyzsong>I always use --with-libgcrypt-prefix=`libgcrypt-config --prefix`, how about add it to guix's configure.ac as the default fallback?
<civodul>iyzsong: yes, that sounds good!
<davexunit>iyzsong: awesome, that works for my other projects, too!
<davexunit>you saved the day!
<iyzsong>cool :-)
<civodul>iyzsong: or even: libgcrypt-config --libs | sed -es'/.*-L\\([^ ]\\+\\)[[:blank:]]\\+-lgcrypt.*/\\1/g'
<civodul>iyzsong: could you send a patch? :-)
<davexunit>civodul: what's the advantage to that one?
<civodul>davexunit: LIBDIR can be different from PREFIX/lib
<davexunit>okay
<davexunit>interested to see what that patch will look like so I can copy it to my new guile-sdl2 project.
<civodul>oh!
<civodul>guile-sdl2!
<davexunit>just trying to get the build system bootstrapped so I can encourage other people to help with it.
<civodul>does it use the FFI?
<davexunit>of course :)
<davexunit>pure Scheme
<civodul>heheh :-)
<davexunit>as $DEITY intended.
<mark_weaver><davexunit> civodul: I realized that 'guix environment' builds the source derivation for packages. d'oh!
<civodul>davexunit: does it intend to be compatible with guile-sdl?
<mark_weaver>davexunit: I would think that's the proper thing to do, no?
<mark_weaver>oh, maybe not, sorry I was confused.
<davexunit>civodul: SDL2 is almost entirely a new API, so no.
<serhart>when running 'guix refresh -u' I get the following error
<civodul>oh, so guile-sdl is for SDL1, and guile-sdl2 is for SDL2? i see
<serhart> guix refresh: error: mkstemp!: Read-only file system
<davexunit>civodul: yes.
<civodul>serhart: could it be that /tmp is read-only?
<civodul>or $TMPDIR
<davexunit>mark_weaver: np!
<serhart>makes sense :]
<serhart>dosn't seem like guix had problems writing to it before
<serhart> drwxrwxrwt 5 root root 4096 Oct 6 04:55 tmp/
<civodul>serhart: are you running "./pre-inst-env guix refresh -u" or just "guix refresh -u"?
<serhart>i'm running guixsd
<serhart>and just going guix refresh -u
<serhart>doing*
<civodul>ok, that's why it doesn't work
<civodul>this tool is meant to be used by developers and to be spawned from a source tree, with pre-inst-env
<civodul> http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-refresh.html
<serhart>doh
<civodul>probably that part of the manual should be clarified
<serhart>I definitely didn't read carefully enough
<civodul>np, that happens ;-)
<davexunit>civodul: btw, Gerald Sussman asked me to send him the URL for the Guix home page so I did. hopefully he finds it to be a nice project. :)
<mark_weaver>cool! :)
<civodul>damn, this is intimidating!
<civodul>what if he sends patches?!
<civodul>:-)
<davexunit>civodul: how fantastic would that be? unlikely, but would be cool!
<C-Keen>you will get a famous contributor :)
<davexunit>he asked me something along the lines of: take half of ubuntu and the corresponding half of red hat and put them together, will you get a working OS?
<davexunit>to which I answered "no, of course not"
<mark_weaver>civodul: unlikely :)
<davexunit>and he said something like: "why can nature do this but we can't? that's the real problem!"
<mark_weaver>bah, I wish I had been around for those conversations.
<civodul>composability!
<mark_weaver>I chatted with him for a couple of minutes, but nothing too deep.
<davexunit>mark_weaver: I couldn't find you at the time, sorry. :(
<mark_weaver>no need to apologize
<davexunit>paroneayea was already talking to him, so I just jumped in!
<rekado>He mentioned something like that during a talk, speaking of salamanders and experiments of severing and reattaching limbs.
<rekado>I think the talk was called "we really don't know how to compute"
<davexunit>yes
<davexunit>that's what he was talking about here
<davexunit>and he recommended that I read a paper he co-authored in 2008 called "The Art of the Propagator"
<davexunit>it's a very interesting paper
<rekado>ACTION takes notes
<davexunit>I'd like to implement the proof-of-concept system in Guile to better understand how it all works
<mark_weaver>yeah, he's been working on that with Alexey Radul. I looked at it a couple of years ago. interesting stuff!
<mark_weaver>an interesting approach to concurrency
<davexunit>it allows for systems that have contradictions to keep on goign
<davexunit>going*
<davexunit>and to retain information about *why* the cells of the network have the information they have
<davexunit>mark_weaver: getting off-topic, but Sussman told Chris and I that his office is like a science club and invited us to come by. that was pretty awesome.
<rekado>heh: "good-enuf?"
<mark_weaver>davexunit: nice! yeah, he invited me to come by sometime also. he's a nice guy.
<davexunit>rekado: btw, a simple intro to propagators can be found in SICP Chapter 3
<civodul>rekado: yeah i found that funny too ;-)
<mark_weaver>davexunit: you should take him up on it!
<paroneayea>davexunit: I spent most of the trip back reading up on propagators stuff
<mark_weaver>davexunit: if you asked to sit in on one of his classes, he'd almost certainly say "yes".
<mark_weaver>paroneayea: same for you, but I know that's not practical for you since you don't live in the area.
<paroneayea>mark_weaver: yeah
<paroneayea>I may send him a followup
<mark_weaver>paroneayea: but the next time you're in the area you should totally visit his office, as he invited you to :)
<paroneayea>mark_weaver: yeah :)
<paroneayea>davexunit: I've half written up a blogpost about what he was saying about AI
<mark_weaver>paroneayea: btw, I'd love to see whatever notes you have to share on your conversation with sussman, since you mentioned already having written something up for your brother
<paroneayea>mark_weaver: yeah, here's the thing I wrote up for my brother, turning into a real blogpost
<mark_weaver>cool! no rush, I can wait
<paroneayea>mark_weaver: http://pamrel.lu/ae1e2/ preview edition ;)
<mark_weaver>thanks!
<mark_weaver>ACTION looks
<paroneayea>but having read the propagators paper now
<paroneayea>I *totally* understand what he means about accountable software and how this tries to expose the AI's symbolic reasoning
<davexunit>mark_weaver: I've heard from my boss that he doesn't mind people sitting in on his lectures, too. I guess it's true!
<paroneayea>excitingly, propagators both serve as an asynchronous programming model, *and* a basis for AI with symbolic reasoning
<davexunit>paroneayea: I finished reading the paper yesterday. overall, I get it, but I need to sit down and write some code to internalize it.
<paroneayea>davexunit: did you check out the code?
<davexunit>paroneayea: just the code in the paper
<paroneayea>there's a gnu/mit scheme implementation
<paroneayea>gplv3
<paroneayea>thinking of porting to guile
<davexunit>awesome
<paroneayea>would be cool to play with...
<davexunit>yeah I'd like to port to Guile as well
<paroneayea>davexunit: especially since you, mark_weaver and I are all talking about bringing async stuff to guile more
<davexunit>and use SRFI-9 and (ice-9 match)
<paroneayea>davexunit: ah, to replace the datastructures?
<davexunit>to make them a little more friendly, yeah, but I need to see what the real code is that you've looked at.
<paroneayea>davexunit: http://groups.csail.mit.edu/mac/users/gjs/propagators/propagator.tar
<mark_weaver>paroneayea, davexunit: he let me sit in on his classic mechanics class about 12 years ago.
<paroneayea>also if you haven't seen, there's two articles, this one's maybe a bit more manually http://groups.csail.mit.edu/mac/users/gjs/propagators/
<paroneayea>goes with that tarball
<davexunit>in the paper, there are no macros used, but in slides from a lecture he gave, there's some nice macros like a 'let' for defining propagators
<davexunit>which I assume works like letrec, since propagators may be recursive
<paroneayea> http://groups.csail.mit.edu/mac/users/gjs/propagators/revised-html.html#SECTION00087000000000000000 this part reaaaaaally interest me
<paroneayea>interests
<davexunit>cool
<davexunit>want to move discussion to #guile?
<mark_weaver>btw, truth maintenance systems were introduced in a paper co-written by RMS and sussman, long ago
<davexunit>yeah, in the late 70s, right?
<mark_weaver>sounds about right
<davexunit>these ideas have been iterated upon for quite some time
<rekado>mark_weaver: do you happen to have a link to a copy of such paper?
<rekado>or the title?
<mark_weaver>"dependency-directed backtracking"
<mark_weaver>let me find it..
<mark_weaver>I think this is probably the one: http://dspace.mit.edu/handle/1721.1/6255
<mark_weaver>I confess I haven't yet taken the time to read up on it myself
<paroneayea>damn, 1976!
<mark_weaver>but I really should
<rekado>mark_weaver: thank you!
<mark_weaver>np!
<davexunit>paroneayea: implementation-wise, I think GOOPS could be used to make the generic operations nicer.
<mark_weaver>I have to go afk for a while. ttyl!
<davexunit>"Note: floating point numbers are compared by approximate numerical equality; this is guaranteed to screw you eventually, but we don't know how to do better."
<davexunit>hehe
<mark_weaver>:)
<davexunit>"Scheme-Propagators is a work in progress. Be aware that we will continue to hack it. Likewise, feel free to hack it as well -- let us know if you invent or implement something interesting. May the Source be with you."
<davexunit>:)
<nextos>hello, is guixsd stable enough for daily usage (non-production)?
<davexunit>nextos: yes, provided the packages you require are available.
<davexunit>I use it exclusively on a couple of computers.
<nextos>davexunit: thanks, thats reassuring
<rekado>nextos: I use it on three computers. Some annoyances remain, but it certainly is stable.
<nextos>any major limitations at this point
<nextos>?
<rekado>no GNOME.
<nextos>that's fine, i use no DE
<nextos>how about networking, as many things are tied to systemd
<rekado>GuixSD does not use systemd but dmd.
<nextos>i know
<rekado>networking works, but we don't have NetworkManager
<rekado>a GUI for network management is wicd, which I use.
<rekado>it's ... okay.
<nextos>is connman integrated? its a very good choice, albeit somehow tied to systemd
<davexunit>wicd kind of sucks, but it was easier than other options. we'll have NetworkManager eventually.
<nextos>but it might be portable to dmd
<davexunit>nextos: someone was working on connman
<nextos>yeah, i had heard about that
<davexunit>I don't remember details, but there seemed to be difficulties.
<davexunit>there's no need to *port* connman to dmd, dmd simply doesn't care.
<davexunit>but if connman requires systemd APIs, then we have to deal with that.
<civodul>nextos: see also http://www.gnu.org/software/guix/manual/html_node/System-Installation.html#Limitations
<nextos>ok
<nextos>davexunit: maybe wpa_supplicant is kind of easy to adopt?
<davexunit>nextos: we have that
<davexunit>if you want to use it
<davexunit>interesting development: Matthew Garrett has forked Linux http://mjg59.dreamwidth.org/38136.html
<iyzsong>oh! I must start reading SICP :-)
<davexunit>iyzsong: best CS book I've ever come across.
<nextos>davexunit, iyzsong: CTM is also a worthy sequel
<iyzsong>nextos: what's CTM?
<iyzsong>get it, 'Concepts, Techniques, and Models ..', right?. @nextos, thanks.
<nextos>iyzsong: yep, its a very nice book
<civodul>davexunit: nice, at last someone dares to speak up
<civodul>McGrath was so happy to quite kernel development when he did
<davexunit>civodul: more and more people are speaking up.
<civodul>it's high time
<civodul>that's good
<civodul>this "boy's club" must really end
<civodul>that's often the first community that newcomers to free software encounter, and it's really bad
<rekado>I never understood why some people think this behaviour is necessary, calling it "brutal honesty".
<civodul>yeah, me neither
<rekado>I'm so happy with the Guix and Guile communities. So much encouragement.
<davexunit>:D
<paroneayea>davexunit: glad matthew is forking. I think it'll force some consideration of how that community is structured, at least.
<davexunit>paroneayea: yeah, will be interesting to see how it plays out.
***davi_ is now known as Guest93600
<mazde>Hi guys. Thanks for the great work :)
<mazde>Does guix sd come with a gui installer ?
<bavier>mazde: no
<mazde>Ok, the manual looks good
<davexunit>mazde: we'd like to have a friendly installer at some point, but we haven't reached that point.
<mazde>Is GPT good to format a partition for guix sd ?
<karhunguixi>as a partition Table, it works fine
<mark_weaver>karhunguixi: does your guixsd installation use gpt?
<karhunguixi>mark_weaver, yes
<mark_weaver>ah, good.
<karhunguixi>i'm unable to install packages since yesterday, with or without ./pre-inst-env i get: http://sprunge.us/CXSW
<karhunguixi>seems like it finds an empty file, but i can't work out any remedies yet
<mark_weaver>ACTION looks
<karhunguixi>i'm pretty sure the problems started when i did a ./pre-inst-env guix system reconfigure which didn't finish
<mark_weaver>karhunguixi: looks like you might have an empty *.go file somewhere
<karhunguixi>git status says nothing about a missing file, somewhere else then?
<mark_weaver>maybe guix/build/utils.go ?
<mark_weaver>*.go files are not checked into the git repository, so git status won't say anything about it, and anyway this is not a case of a missing file, but a zero-length file.
<karhunguixi>i don't have the file you said in my git repo
<karhunguixi>is it made during compilation?
<karhunguixi>i don't have any .go files in git repo
<mark_weaver>if there are no .go files in your git repo, then it sounds like you never ran "make". but I thought you did?
<karhunguixi>yeah, i thought i did.. hm, trying again
<mark_weaver>anyway, this is more likely a zero-length file in your /gnu/store/ somewhere, which can happen sometimes with ext3/4 filesystems if they crash at the wrong time, unfortunately.
<mark_weaver>anyway, I have to go afk for a while, sorry.
<karhunguixi>hey, no problem. I appreciate your help whenever you find the time :)
<karhunguixi>yeah, "make" fails. I apparently didn't notice that the last time :/
<alezost>karhunguixi: how does it fail?
<karhunguixi>(but i've since made bash print out non-zero exit statuses)
<karhunguixi>alezost, it's missing makeinfo
<alezost>karhunguixi: you need to install texinfo
<karhunguixi>i've been trying to for some time now, this is what the reconfigure complained about as well
<alezost>what "reconfigure" do you mean?
<karhunguixi>i tried a "./pre-inst-env guix system reconfigure" yesterday. With apparently a git repo i hadn't run "make" successfully in
<alezost>you don't need to reconfigure the system; just "guix package -i texinfo"
<karhunguixi>i need texinfo to complete the reconfigure and make. But now i can't install texinfo.
<alezost>why?
<karhunguixi>"guix package -i texinfo" and "./pre-inst-env guix package -i texinfo" gives me this: http://sprunge.us/CXSW
<alezost>forget about "./pre-inst-env guix" for now
<alezost>is ~/.config/guix/latest a link to the store?
<karhunguixi>$ readlink ~/.config/guix/latest
<alezost>and "which guix"
<karhunguixi> /gnu/store/68kadia1cz5vc0j3y19q7g2z6q438a0g-guix-latest
<karhunguixi>which guix: /run/current-system/profile/bin/guix
<alezost>ok, so "guix package -i texinfo" still errors?
<karhunguixi>yes, http://sprunge.us/DEjR
<alezost>hm, what about "guix build texinfo"?
<karhunguixi>that gives: /gnu/store/0pdc8b9brv43g9kzz6hj0z8nlp9gkhmy-texinfo-6.0
<karhunguixi>i don't understand why the normal "guix package -i" would be broken by me messing up in the git repo
<alezost>perhaps your store is corrupted, as mark_weaver said
<alezost>or maybe just your profile, try "guix package -i texinfo -p /tmp/p1"
<alezost>now it's clear that this error is not related to "messing up in the git repo"
<karhunguixi>this succeeded!
<alezost>did a new profile (/tmp/p1) appear?
<karhunguixi>i added /tmp/p1/bin to my PATH and now "make" is doing its thing
<mark_weaver>karhunguixi: can you find the /gnu/store/...-guile* directory included in /gnu/store/nfn2l287ahd228hzqbmgl312c5h8igs7-gtk-icon-themes.drv ?
<mark_weaver>(the .drv file is just a text file)
<alezost>it looks like your profile is somehow corrupted
<mark_weaver>alezost: the error happens while building the derivation I gave above
<mark_weaver>I don't think that indicates a corrupted profile, but rather that the /tmp/p1 profile doesn't need to build gtk-icon-themes
<alezost>ah, yes, that's it
<mark_weaver>I still think there's a zero-length file somewhere in /gnu/store/...-guile-*
<mark_weaver>probably guix/build/utils.go
<alezost>maybe "restarting" with a fresh profile will help. I mean removing (or renaming) ~/.guix-profile, and install everything again
<mark_weaver>I doubt it
<mark_weaver>I think the same problem would show up as soon as he tried to build another profile that needs gtk-icon-themes
<mark_weaver>and probably lots of other builds would fail as well
<karhunguixi>in that .drv i have this /gnu/store/4xqmz0zzkv1n09fqqckql2p8xv30hn1k-guile-2.0.11 which has bin/ include/ lib/ and share/
<mark_weaver>karhunguixi: please run this: find /gnu/store/4xqmz0zzkv1n09fqqckql2p8xv30hn1k-guile-2.0.11 -size 0
<mark_weaver>does it list any files?
<karhunguixi>no
<mark_weaver>hmm
<karhunguixi>this is that .drv by the way: http://sprunge.us/YWYa
<mark_weaver>how about this: find /gnu/store/xxvsp1sdqqw2y4hh124mimivcpv6x9pf-guile-2.0.11 -size 0
<mark_weaver>(that's another guile referenced from that *.drv file)
<karhunguixi>no, no files
<karhunguixi>i did a search for empty .go files: http://sprunge.us/UGSD found 3
<mark_weaver>ah, that's it
<mark_weaver>try this: guix gc -d /gnu/store/c47cs4zkxmzjc51ln6p2dd461ki2qn9s-module-import-compiled
<karhunguixi>is it fine to run this while "make" is working?
<mark_weaver>yes
<karhunguixi>result: http://sprunge.us/aSLF
<codemac>Is there a standard name for the guix profile projects use? I've been doing guix.scm in random side projects, curious if there are any obvious defaults.
<mark_weaver>karhunguixi: good. I suspect things will now work again.
<mark_weaver>codemac: I don't understand your question
<karhunguixi>Great, i'll remove alezost tmp profile trick and see how it goes.
<mark_weaver>projects don't use guix profiles. people do.
<karhunguixi>Thanks guys! :)
<mark_weaver>yw!
<davexunit>codemac: are you referring to the pattern I've started where you place a file in the root of source tree for use with 'guix environment' and 'guix package'?
<mark_weaver>your system must have crashed soon after that item was added to the store, and unfortunately ext4 filesystems are prone to leaving empty files around in such cases :-(
<davexunit>I've been calling them 'package.scm', but someone suggested that 'guix.scm' would be a better name for such files, and I'm inclined to agree.
<mark_weaver>codemac, davexunit: ah, right, nevermind me :)
<karhunguixi>i see, i've had several crashes trying "guix system vm" and vm-image
<davexunit>mark_weaver: it's okay, I'm probably the only person who could have understood the question given the way it was written. ;)
<mark_weaver>davexunit: heh, I'm glad you're here :)
<karhunguixi>by the way, is there another filesystem "more" recommended?
<mark_weaver>karhunguixi: not really. I guess btrfs may be a good choice at some point, when it's really ready. last I checked, it had some issues. maybe they're resolved by now, dunno!
<karhunguixi>ok
<mark_weaver>I read that facebook started using btrfs and recently contributed a bunch of fixes upstream. maybe it's all good now, but I haven't yet heard confirmation.
<mark_weaver>or maybe it's just that they're preparing to use btrfs
<karhunguixi>i can try it on my /home partition, and at least see if it's very immature (which i doubt)
<karhunguixi>hm, but i wouldn't run into these problems there though..
<codemac>mark_weaver: :) no problem. I could have been more specific with the question. Thanks davexunit, I'll stick with guix.scm for now.
<codemac>btrfs has been a nightmare for me. I tried using it at work once, and it used *70%* of diskspace for metadata allocations
<codemac>That was in Feb 2015, so old data point.
<karhunguixi>hm, maybe i'll just keep using ext4 and stop crashing my system instead... ;)
<karhunguixi>i just did a "./pre-inst-env guix system reconfigure /etc/config.scm" and rebooted. It failed to start X for some reason, but i got to the bash prompt.
<karhunguixi>I don't see anything really useful in the logs, the only vaguely interesting is in dmd.log. It's respawning xorg-server quite a lot, then it says "(Respawning too fast.)"
<karhunguixi>And Xorg.log says it terminated successfully... so that's something i guess
<codemac>how do I get the `guix` command to print what environment variables I should have set?
<davexunit>codemac: guix package --search-paths
***fchmmr is now known as Guest21084
<efraim>could you pipe that into bash? assuming you didn't have the "failed to install locale" warning?
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<davexunit>efraim: that warning is written to stderr, I think, so that wouldn't affect anything
<davexunit>you can eval it
<davexunit>eval $(guix package --search-paths)
<davexunit>gotta go