<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 <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 <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>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 <davexunit>those packages aren't for building from VCS checkouts <davexunit>and thus their environments are for the same <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>and for development from VCS one would be expected to provide such a package themselves <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>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>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>I will be submitting one to include with Geiser at some point, for example. <bavier1>I was just feeling a bit frustrated, which I think now is due more to my 'guix environment' being out-of-date <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 <chil>In guixsd, I need to edit config.scm and do a 'guix system reconfigure' instead of editing /etc files? <chil>and to update the base os I also need to run 'guix system reconfigure'? <civodul>it can be thought as a way to update the OS configuration, and part of that configuration is the set of installed packages ***anthk_ is now known as anthk
***francis7 is now known as guest1
***guest1 is now known as francis7
<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 <civodul>no, i mean build a profile, but not add it to ~/.guix-profile or whatever <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>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>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" <civodul>i guess one could simply write a function equivalent to 'which' but for shared libraries <iyzsong>I always use --with-libgcrypt-prefix=`libgcrypt-config --prefix`, how about add it to guix's configure.ac as the default fallback? <davexunit>iyzsong: awesome, that works for my other projects, too! <civodul>iyzsong: or even: libgcrypt-config --libs | sed -es'/.*-L\\([^ ]\\+\\)[[:blank:]]\\+-lgcrypt.*/\\1/g' <civodul>iyzsong: could you send a patch? :-) <civodul>davexunit: LIBDIR can be different from PREFIX/lib <davexunit>interested to see what that patch will look like so I can copy it to my new guile-sdl2 project. <davexunit>just trying to get the build system bootstrapped so I can encourage other people to help with it. <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? <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 <civodul>serhart: could it be that /tmp is read-only? <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"? <civodul>this tool is meant to be used by developers and to be spawned from a source tree, with pre-inst-env <civodul>probably that part of the manual should be clarified <serhart>I definitely didn't read carefully enough <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. :) <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>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. <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. :( <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>and he recommended that I read a paper he co-authored in 2008 called "The Art of the Propagator" <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! <davexunit>it allows for systems that have contradictions to keep on goign <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. <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 ;-) <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. <mark_weaver>paroneayea: but the next time you're in the area you should totally visit his office, as he invited you to :) <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 <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: especially since you, mark_weaver and I are all talking about bringing async stuff to guile more <davexunit>to make them a little more friendly, yeah, but I need to see what the real code is that you've looked at. <mark_weaver>paroneayea, davexunit: he let me sit in on his classic mechanics class about 12 years ago. <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 <mark_weaver>btw, truth maintenance systems were introduced in a paper co-written by RMS and sussman, long ago <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? <mark_weaver>I confess I haven't yet taken the time to read up on it myself <davexunit>paroneayea: implementation-wise, I think GOOPS could be used to make the generic operations nicer. <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>"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." <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>how about networking, as many things are tied to systemd <rekado>GuixSD does not use systemd but dmd. <rekado>networking works, but we don't have NetworkManager <rekado>a GUI for network management is wicd, which I use. <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. <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. <nextos>davexunit: maybe wpa_supplicant is kind of easy to adopt? <davexunit>iyzsong: best CS book I've ever come across. <nextos>davexunit, iyzsong: CTM is also a worthy sequel <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>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". <rekado>I'm so happy with the Guix and Guile communities. So much encouragement. <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 ? <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>seems like it finds an empty file, but i can't work out any remedies yet <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>*.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. <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? <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. <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 :/ <karhunguixi>(but i've since made bash print out non-zero exit statuses) <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 <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>forget about "./pre-inst-env guix" for now <alezost>is ~/.config/guix/latest a link to the store? <karhunguixi> /gnu/store/68kadia1cz5vc0j3y19q7g2z6q438a0g-guix-latest <alezost>ok, so "guix package -i texinfo" still errors? <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>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 ? <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 <mark_weaver>I still think there's a zero-length file somewhere in /gnu/store/...-guile-* <alezost>maybe "restarting" with a fresh profile will help. I mean removing (or renaming) ~/.guix-profile, and install everything again <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>how about this: find /gnu/store/xxvsp1sdqqw2y4hh124mimivcpv6x9pf-guile-2.0.11 -size 0 <mark_weaver>(that's another guile referenced from that *.drv file) <mark_weaver>try this: guix gc -d /gnu/store/c47cs4zkxmzjc51ln6p2dd461ki2qn9s-module-import-compiled <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. <karhunguixi>Great, i'll remove alezost tmp profile trick and see how it goes. <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. <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. ;) <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! <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? ***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