IRC channel logs


back to list of logs

<tadni>ArneBab: Are we porting Guix to Wisp now. :^)
<ArneBab>tadni: I wouldn’t say that I would not like that, but practically I guess the scheme community is still bigger than the (nonexisting) wisp community :)
<tadni>ArneBab: Joking aside, I do think the fact that parens really scare that many people off is very weird.
<ArneBab>tadni: they scared me off in the beginning and still look a bit strange.
<ArneBab>tadni: I think the reason is simply that we recognize words by the first letter.
<ArneBab>and with scheme that’s always a paren.
<tadni>ArneBab: Yeah, but after like 10 minutes my first time using Lisps, I just started to skip over it.
<tadni>Like didn't even ever thing of it.
<tadni>think* :^P
<ArneBab>tadni: for me that was different
<ArneBab>and still is…
<tadni>ArneBab: Well, evidently.
<ArneBab>(there’s a reason why I work on wisp ☺)
<tadni>I'm weird though.
<tadni>ArneBab: :^)
<ArneBab>tadni: on the other hand, if you ignore parens, lisps are a lot better than other languages at looking like prose.
<tadni>Propose prose, that poses.
<cmhobbs>i just installed 0.8 and tried installing hello:
<cmhobbs>does this mean guix is falling back to building from source?
<davexunit>cmhobbs: nope
<davexunit>just means that is slow
<davexunit>(our build farm needs more resources)
<cmhobbs>also it tells me to please consider upgrading guile to get some report
<cmhobbs>i'm on debian wheezy, i think my guile is at 2.0
<cmhobbs>which is what the installation guide recommends, no?
<davexunit>what is the output of guile --version
<davexunit>on wheezy it's likely 2.0.5 or something
<cmhobbs>" GNU Guile, version 2.0.5 or later; "
<cmhobbs>guile (GNU Guile) 2.0.5-deb+1-3
<davexunit>which is supported by guix, but I highly recommend upgrading
<cmhobbs>is what i have installed
<cmhobbs>i suppose i'll have to build guile from source
<cmhobbs>stable is a bit outdated
<davexunit>if you want the best results, guile 2.0.11 is recommened.
<cmhobbs>i'd rather not run jessie though
<cmhobbs>i'll add that to my long line of "build from source" stuff :D
<cmhobbs>i'll have to rebuild guix after building guile, yes?
<davexunit>I think so, anyway.
<davexunit>but maybe not.
<cmhobbs>i think i will
<cmhobbs>but that's not a problem
<davexunit>thanks for trying things out
<cmhobbs>no worries!
<cmhobbs>i'm excited about guix
<davexunit>me too
<cmhobbs>i've been tracking it so far
<cmhobbs>wish i knew guile
<davexunit>I finally got the standalone system running on my desktop computer
<cmhobbs>i need to sit down this weekend and absorb it
<davexunit>are you familiar with any lisps
<cmhobbs>i was going to travel to vegas this weekend but my son got sick so we're staying home
<davexunit>oh no :(
<cmhobbs>what better thing to do on a quiet weekend but hack?
<cmhobbs>didn't mean to bring the mood down, just saying i have a pile of spare time
<davexunit>nothing better
<cmhobbs>he's fine
<davexunit>oh good :)
<cmhobbs>just has a gnarly cough. doc got him some meds and he's content
<cmhobbs>i used to use sbcl pretty regularly
<cmhobbs>and i wrote a couple of things at work in clojure
<cmhobbs>ruby pays my bills, unfortunately
<cmhobbs>there are worse languages to write for wages, though
<cmhobbs>i started in on a guile tutorial after the hackathon and it felt familiar
<cmhobbs>i've never schemed
<davexunit>ruby is one of the better mainstream languages, imo
<davexunit>I was a professional ruby dev for the past 2 years
<davexunit>before I left for the FSF
<davexunit>I've written some Ruby at the FSF, but mostly PHP (ew)
<cmhobbs>it's possible to write "good" php
<cmhobbs>i've not used it much
<cmhobbs>what do you do at the fsf?
<davexunit>I'm the web developer
<davexunit>I work mainly on CiviCRM things
<cmhobbs>was it rough getting guix on your desktop?
<davexunit>not that bad, honestly.
<cmhobbs>i've not yet tried the full os
<cmhobbs>i don't have a spare machine for it right now
<cmhobbs>all my machines are spoken for
<davexunit>there's just no fancy UI to guide you through the process
<davexunit>I freed up a machine to do it
<cmhobbs>i think my hurdle with guile is not really having a pet project to use it with
<cmhobbs>and not knowing much about the gnu build tools
<davexunit>yeah, I got into guile because of my pet project
<davexunit>and then learned that someone was using it to build an OS!
<cmhobbs>lately i've been thinking about building a Libre go server (the game), lisp might be a fun way to do that
<cmhobbs>i'm a little annoyed by the lack of free software environments for playing the game online
<cmhobbs>and not enough people to play with locally
<davexunit>it certainly has the features needed to write such a server
<cmhobbs>the best pet projects scratch one's own itch
<davexunit>and the expressiveness
<davexunit>lisps are very liberating.
<cmhobbs>building guile 2.0.11 now
<cmhobbs>yeah, i love common lisp
<davexunit>they give you 'practical software freedom'
<davexunit>anything can be changed.
<cmhobbs>well, hello failed
<cmhobbs>yeah, standby. gotta help the kid
<cmhobbs>i'll paste it
<davexunit>I know how that is.
<davexunit>does anyone know if guix pull is intended to be run mainly by the root user?
<cmhobbs>alright, looking now
<cmhobbs>guix package: error: build failed: builder does not have write permission to `/gnu/store'; try `chgrp 1001 /gnu/store; chmod 1775 /gnu/store'
<davexunit>run those shell commands
<davexunit>your store directory doesn't have the proper permissions
<cmhobbs>well, i'm done
<davexunit>it's fine, I made the same mistake. luckily guix package is nice enough to tell you what to do
<cmhobbs>yeah, i didn't pay enough attention
<cmhobbs>just noticed i missed the call for proposals for libreplanet
<cmhobbs>been too busy prepping a talk here
<cmhobbs>retrying the hello install
<cmhobbs>while building guile
<cmhobbs>my little netbook is going to get warm
<davexunit>it sure will!
<davexunit>time to put 'guix environment' to the test with 'guix environment guix && ./bootstrap && ./configure && make'
<cmhobbs>good luck!
<cmhobbs>after looking at the guile docs a bit, i think i might use it to try to make a go server of some kind
<cmhobbs>maybe a naive implementation to start
<davexunit>go for it!
<davexunit>I want to try to write a client/server thing in guile sometime
<davexunit>I typically only write one or the other depending on what I'm doing
<davexunit>I'd like to write an example multiplayer game using my game engine
<cmhobbs>i've also got to make a secret santa picker again this year. i may use guile for that as well
<cmhobbs>my free-time hacking will end early next year though. going to be trying to build my business back up and leave my current company
<cmhobbs>growing tired of writing proprietary software and ecommerce
<cmhobbs>so i need to get those projects in over the holidays
<cmhobbs>i think i'm going to have a couple of solid weeks to just tinker
<davexunit>what does your company do?
<cmhobbs>may focus on guile at that point
<cmhobbs>we're an ecommerce shop
<cmhobbs>we have and
<cmhobbs>we do throw some software over the wall but they're uncomfortable with copyleft and prefer permissive licenses
<davexunit>what's your personal business?
<cmhobbs>i was a freelance consultant for a long time
<davexunit>pertty all businesses do not like copyleft
<davexunit>pretty much all*
<cmhobbs>just building software and working on clients' environments
<davexunit>(not sure what I was thinking when I typed that)
<cmhobbs>mostly data mangling
<nebuli>cmhobbs: if you want to write web application in scheme take a look at hop (though it's bigloo not guile)
<cmhobbs>aggregating/analyzing data, building various interfaces for it, building networked tools
<cmhobbs>nebuli, the go server wouldn't end up being a webapp, but the secret santa generator could stand a web interface
<cmhobbs>i'll dig up bigloo, too
<cmhobbs>scheme is a side of lisp i never investigated
<davexunit>I'm not a good business person, but part of me thinks that I need to make my own business in order to work with the technologies I really want to work with.
<nebuli>cmhobbs: hop and bigloo is packaged in guix
<cmhobbs>nebuli, awesome! that's a perfect place to start
<davexunit>I wish someone would pay me to hack on guile programs.
<cmhobbs>davexunit, running a business isn't too hard if you don't have caviar dreams
<cmhobbs>well, running a business with free software
<cmhobbs>taxes are murder in the US but i just put back a third of all my earnings to prepare for that
<davexunit>I don't, but it would have to beat the 6 figures I could already get if I went back into the proprietary software wold.
<cmhobbs>whatever is left after taxes is just gravy
<cmhobbs>i know that feeling. it sounds crazy but i told them to not give me another raise in my last review. i'm doing my best not to hit that mark so i can continue doing the things i love and not be disappointed
<davexunit>or at least match it. I would hate to work really hard on a business and have horrible income.
<cmhobbs>also, sorry to take the channel way off topic
<davexunit>heh, yeah. apologies as well.
<cmhobbs>if it's a labor of love, it's not so bad as long as your needs are met
<nebuli>hop has a scheme2js compiler for that web2.0 hoopla, but staying with one language (scheme) for both server and client side
<cmhobbs>nebuli, that sounds fun
<cmhobbs>oh hell
<davexunit>maybe some company will want to use guix one day and pay me to hack on it. </pipedream>
<cmhobbs>where does guix install binaries?
<cmhobbs>gotta have a viable income stream for guix to be paid to write it ;)
<cmhobbs>because capitalism
<davexunit>$HOME/.guix-profile by default
<davexunit>cmhobbs: I think guix has real potential to overtake docker, puppet, etc.
<cmhobbs>man, my .profile is a ghetto
<cmhobbs>great success
<cmhobbs>christopher@dissentio:~/src/guix-0.8$ hello
<cmhobbs>Hello, world!
<cmhobbs>well 0.8 works
<cmhobbs>once guile finishes building, i'll rebuild 0.8
*cmhobbs queues up jeopardy music
<cmhobbs>you guys going to libreplanet?
<nebuli>davexunit: btw, guix pull merely places latest guix into user's ~/.config
<cmhobbs>davexunit, i guess i haven't seen enough of the os version of guix to get that. aren't docker and puppet two very different things?
<cmhobbs>puppet is a configuration automation platform, docker is some kind of wacky application level virtualization?
<_`_>docker automates the creation of operating system level virtualization guests.
<cmhobbs>ah right
<_`_>its backend, “libcontainer”, supports various mechanisms on various OSes iirc (Solaris Zones, FreeBSD jails, and the Linux kernel container API)
<nebuli>fsck puppet/docker/whateva; i want my lisp machine, NOW!
<cmhobbs>isn't the guix os just gnu/linux?
<cmhobbs>or does it have a functional kernel?
<cmhobbs>i'm glad i took guix build notes on my wiki during the hackathon
<cmhobbs>it was nice to have a quick reference for installing
<nebuli>all those virtualisation mambojumbos are just corporations way to cut corners and freeload on open source (withou even properly supporting security infrastructure, vide openssl debacle)
<cmhobbs>just one way, anyhow
<_`_>huh? how so?
<davexunit>cmhobbs: re puppet/docker: yes, they are different. however, guix has the features to replace both. :)
<_`_>If you mean docker, sure, but it's not like docker is taken seriously on platforms where people already used their OSes tools to create “containers” (i.e. FreeBSD users aren't going to stop using jail(8) and start using docker, same with people running illumos).
<davexunit>_`_: sure. docker is just an example.
<davexunit>I would like to extend 'guix system' so that it can create containers in addition to vms
<_`_>davexunit: I meant that reply towards nebuli statement, apologies.
<davexunit>oh sorry
<nebuli>_`_: automation "magic" and making one person manage hundreds of boxes with a gui wizards; it's almost the same argument as with systemd making linux into embrace and extend RH windows like move
<davexunit>I intend for the 'guix environment' tool to be a Vagrant (or other such tool) replacement
<_`_>I can't believe I'm going to defend docker since I dislike go… but nebuli, I'm pretty sure one can bind libcontainer. I'm failing to understand your statements.
<davexunit>signing off. happy hacking all.
<nebuli>anyway, i don't really care. /me never liked debian (in spite of it's awesomeness); the source based nature of guix is the killer argument for me.
<cmhobbs>i'll use guix if it matures
<cmhobbs>mostly due to fsf endorsement
<cmhobbs>i just switched to debian stable from trisquel though
<cmhobbs>due to some problems post-upgrade with trisquel 7
<cmhobbs>also, my machine runs a little faster with debian (which i still don't understand)
*nebuli was a long time slacker/archer (with some gentoo in between)
<_`_>I'm interested in guix as a local package manager in environments where the system isn't my concern or the package manager is pita. I tried nix and it really didn't work elegantly as one.
<nebuli>had to switch to debian (for some off-line life) and been painfully reminded how rigid dep system and strict binary nature of this distribution makes life painful/inflexible
<nebuli>if debian and other "modern" distros are order of magnitude better then 1990's slackware then i'd dare to say that guix makes for another order of magnitude over all those "modern" imperative ways of …
<nebuli>…managing OS
<cmhobbs>debian does an alright job
<cmhobbs>it depends on what you consider better
<cmhobbs>the average user is probably going to hit whatever distro has a slick interface first
<cmhobbs>they don't care much about packaging
<cmhobbs>i'm excited about a functional package manager, though
<cmhobbs>is there a package list or package search in guix?
<cmhobbs>also, just discovered the emacs interface
<nebuli>yes yes
<oitofelix>Hello Guix world!
<jmd>Considering packaging libvisual. Where should it go? games.scm ?
<oitofelix>After running 'guix package -i windowmaker' I'm getting:
<oitofelix>guix package: error: build failed: derivation `/gnu/store/pxyjsl5xv387kbx55lw97pjrlfzfxpcp-guile-bootstrap-2.0.drv' has incorrect output `/home/felix/gnu/store/ka1kwmxk2ffkjhfp84y4s192kximrxfz-guile-bootstrap-2.0', should be `/gnu/store/3pxvfkc3fca9cdpp5fqci8dy6r4s5cph-guile-bootstrap-2.0'
<oitofelix>Any idea why?
<taylanub>is it normal that something like this would happen when I modify a package recipe and try to rebuild it from the source tree? (I previously installed the recipe via make install; Guix doesn't have it yet) after that I simply re-executed the command and it works fine :\\
<taylanub>again, might be because I'm using a non-release version of Guile. I'll ask in #guile too
<nkar>taylanub: never seen this. though, I haven't been using the substitutes much
<jmd>Suddenly, guix build is claiming guix build: error: xxxxx: unknown package
<jmd>for any package I give it.
*davexunit tries to figure out how to make windowmaker run a script on startup
<davexunit>.xsession doesn't seem to be it
<taylanub>davexunit: hi! can I use guile-2d with a released version of guile-opengl, or should I use the gitorious figl repo?
<davexunit>taylanub: you should be able to use guile-opengl.
<davexunit>that's what I use
<davexunit>guix has *all* the packages needed
<davexunit>the sly repo is in a bit of disarray
<davexunit>I don't know the exact state of master. I think it works. :)
<taylanub>my intention is to test the r7rs branch of guile, so I run the test suites of all kinds of guile libraries
<davexunit>I don't have a test suite yet
<taylanub>oh ok
<davexunit>when I started my work, guile didn't have srfi-64
<taylanub>guile-2d = sly?
<davexunit>that's the new name
<davexunit>as of a few months ago
<davexunit>I can do 3D now
<taylanub>by the way figl (master)'s 'make check' gives me: maybe you've seen this before...
<davexunit>try with the guile-opengl repo, figl is outdated.
<davexunit>haven't seen that error
<taylanub>oh ok, I thought it was the dev repo
<davexunit>I think all dev is on savannah now
<taylanub>I see
<davexunit>hmmmm, geiser is behaving strangely on guix
<davexunit>I ran an ,apropos and then I was somehow 12 debuggers deep
<jmd>Is find-files a guile thing or is it guix specific ?
<alezost>jmd: it is defined in (guix build utils)
<davexunit>I would love for some of the guix util procedures to make it into guile core
<davexunit>some of them would be useful to everyone
<jmd>I want a find-files which is limited by depth
<davexunit>should be easy to extend file-files to do that
<jmd>In fact, right now, I need one that limits to depth 0
<jmd>Oh, but I want to find a directory.
<davexunit>my guix.el isn't working, even when I fix the geiser load path...
<taylanub>anyone have an idea how I could make these nmap tests pass? some dependency for making domain name resolution work perhaps?
<alezost>davexunit: in what way is it not working? any error?
<rgrau_>After installing slim service, I'd like to change window maker to another window manager. "echo 'exec ratpoison' > ~/.xsession" is not working.
<rgrau_>i created /etc/xinitrc with the same content and didn't work either...
<davexunit>alezost: yeah one sec
<davexunit>(pardon me in advance)
<davexunit>if: Error in evaluating guile expression: Unknown meta command: geiser-eval
<davexunit>$6 = #f
<davexunit>;;; <unknown-location>: warning: possibly unbound variable `%guix-dir'
<davexunit>ERROR: In procedure #<procedure 1e2f460 ()>:
<davexunit>ERROR: In procedure module-lookup: Unbound variable: %guix-dir
<davexunit>I thought I had resolved all of my geiser issues, but perhaps not
<davexunit>hmmm, the guix manual isn't on my info path...
<alezost>davexunit: AFAIU it is from REPL. Is it alive?
<davexunit>ahhh, my environment is much different when I boot emacs from windowmaker vs xterm
<davexunit>alezost: yeah the repl is alive
<davexunit>but it's all screwed up. ,use (guix packages) doesn't work
<alezost>davexunit: could you check the value of '%load-path' in the REPL
<davexunit>I don't see anything guix related on it
<davexunit>I have some code in my .guile file that adds /run/current-system/profile/share/guile/site/2.0 to the load path
<davexunit>I guess geiser ignores that?
<alezost>perhaps guix.el code ignores that. Could you try "M-x switch-to-guile" and see %load-path there
<davexunit>that has the things I expect
<alezost>also check some vars in emacs (with "C-h v" or "M-:"): geiser-scheme-dir, guix-load-path, guix-default-profile
<davexunit>geiser-scheme-dir is messed up
<davexunit>it should be: /home/dave/.guix-profile/share/geiser/guile
<alezost>it's probably not set properly in "geiser.el". Try to set it to the right value and check guix.el again
<alezost>I think "/home/dave/.guix-profile/share/geiser/guile" is not the right path. geiser has "scheme" dir with "guile" and "racket" inside
<alezost>(but that's for geiser installed with emacs package system) I think (setq geiser-scheme-dir "/home/dave/.guix-profile/share/geiser/") would be it. Could you evaluate it, quit the repl and "M-x guix-installed-packages" (or another command) again, please
<alezost>davexunit: I think I found: for the "make"-d Geiser, geiser-scheme-dir is set properly in "geiser-install.el": "M-x find-library geiser-install"
<alezost>davexunit: so if it contains the right value you could put (require 'geiser-install) in your emacs config
<jmd>So here is my current plan to get guix running on an arm system:
<jmd>1. Cross build as much as possible.
<jmd>2. Clone /gnu and /var/guix onto a disk and mount on the target system.
<jmd>3. Manually construct a profile containing the essential build tools.
<jmd>4. Copy the guix tarball onto the target and build using the manually constructed profile.
<cmhobbs>jmd, with what little i know about the architecture, that sounds reasonable to me
<davexunit>alezost: I'm using the geiser guix package, fwiw
<alezost>davexunit: I understood, so does (require 'geiser-install) fix the issue?
<davexunit>it helps!
<davexunit>%guix-dir is undefined now
<davexunit>what does geiser-install do?
<jmd>What timezone are the reported times on ?
<alezost>davexunit: "M-x find-library geiser-install": it sets geiser-scheme-dir and requires "geiser" with some autoloads
<davexunit>jmd: US east coast I believe
<davexunit>the server is located at MIT
<davexunit>alezost: oh, cool.
<jmd>Why is it then always so slow? I thought MIT had 97% of the bandwidth in the entire world.
<cmhobbs>man, removing system guile is hard... i'm never going to get guix rebuilt :/
<davexunit>jmd: because it's a VM on a machine with limited resources.
<jmd>man is not supposed to be used for that purpose.
<alezost>davexunit: %guix-dir is defined in "guix-helper.el". What is the value of `guix-load-path' Emacs variable?
<jmd>davexunit: The builds shouldn't be done there. Just the distribution.
<alezost>davexunit: I meant "guix-helper.scm". Does `guix-helper-file' (emacs var) exist?
<davexunit>oh, one sec
<jmd>davexunit: Hmm. Anyway it seems that you're wrong.
<jmd>It seems to be reporting UTC+1
<davexunit>oh okay
<davexunit>I just took a wild guess
<jmd>(which happens to be my localtimezone, so perhaps somehow the UI knows that)
<davexunit>guix-helper-file is "/run/current-system/profile/share/emacs/site-lisp/guix-helper.scm"
<alezost>davexunit: Are you getting "%guix-dir is undefined" in the repl when you do "M-x guix-..."?
<davexunit>now I'm getting: socket:28:16: In procedure module-lookup: Unbound variable: entries
<davexunit>probably a geiser thing
<alezost>does "/run/current-system/profile/share/emacs/site-lisp/" contain "guix-helper.scm" and "guix-main.scm"?
<davexunit>hmm, actually... it doesn't!
<davexunit>it has other guix-*.el files, though
<alezost>davexunit: where are the usual guile modules placed?
<alezost>those files should be in "{guilemoduledir}/guix/emacs"
<davexunit>I added that directory to my geiser-guile-load-path
<davexunit>to no avail, apparently
<alezost>davexunit: (setq guix-load-path "/run/current-system/profile/share/guile/site/2.0/guix/emacs") should help
<alezost>but doesn't guix-init.el contain that path? Could you look at it: "M-x find-library guix-init"
<davexunit>yes, it does have that path
<cmhobbs>i'm about to rebuild guix with guile-2.0.11 now that i've got it built
<davexunit>problem is:
<davexunit>guix-load-path is a variable defined in `guix-backend.el'.
<davexunit>Its value is "/run/current-system/profile/share/emacs/site-lisp/"
<davexunit>this is what C-h v guix-load-path tells me
<alezost>davexunit: so you didn't require guix-init (as the manual suggests)?
<davexunit>hmm, guess not
<davexunit>my guix manual isn't available for some strange reasonm
<davexunit>the result is the same after requiring guix-init
<alezost>davexunit: could you add (require 'guix-init) to you emacs config and restart emacs?
<davexunit>that means I have to sign off IRC
<alezost>davexunit: stop!
*davexunit stops
<alezost>davexunit: what other settings of "guix.el" do you have in your emacs config?
*davexunit double checks
<alezost>davexunit: ok then, (require 'geiser-install) and (require 'guix-init) should hopefully work
<cmhobbs>well, rebuilding emacs first... i'm not sure why i decided to do all this nonsense on my local machine
<cmhobbs>i should really build guile and friends on my home server
<davexunit>alezost: does the order matter?
<alezost>davexunit: I think not, but keep geiser-install in the first place for now (just in case)
<davexunit>should I try restarting emacs at this point?
<nully>erc users make me giggle when that happens
<jmd>The libreoffice build is currently in progress!
<nully>only 5mins
<nully>a new record :D
<nully>ohai davexunit =P
<davexunit>hey nully
<nully>just commenting on how long it took you to restart emacs and get back into erc
*nully giggle snorts
<davexunit>I was messing around with things before I rejoined
<davexunit>alezost: I get a new error now!
<nully>yayaya, i've heard it all before!
<davexunit>error in process sentinel: sleep-for: Text is read-only
<davexunit>error in process sentinel: Text is read-only
<davexunit>geiser-repl--wait-for-prompt: No prompt found!
<davexunit>jmd: exciting. looks like the build is working!
<jmd>I suspect it will fail somewhere, but we will see.
<alezost>davexunit: what is in *Guix REPL* buffer?
<davexunit>a-ha! it's missing the guix modules on the load path
<davexunit>ERROR: Unbound variable: fold-packages
<davexunit>also troubling:
<davexunit>;;; compiling /gnu/store/v4gwzhf74mbvysj60645avnik1d9ki6i-guix-0.8.47739f5/share/guile/site/2.0/guix/emacs/guix-main.scm
<davexunit>;;; WARNING: compilation of /gnu/store/v4gwzhf74mbvysj60645avnik1d9ki6i-guix-0.8.47739f5/share/guile/site/2.0/guix/emacs/guix-main.scm failed:
<davexunit>;;; ERROR: In procedure dirname: Wrong type argument in position 1 (expecting string): #f
<cmhobbs>finally rebuilding guix.. hopefully guile-2.0.11 gets me a little further
<cmhobbs>will i need to reinstall any packages after updating guix?
<davexunit>cmhobbs: no
<davexunit>your installed software is okay regardless of which version of the guix code you have
<cmhobbs>i figured they'd be isolated
<cmhobbs>just making sure
<alezost>davexunit: is repl dead?
<alezost>davexunit: sorry, I have no idea about that compilation error: dirname is not even used in "guix-main.scm" :-(
<alezost>perhaps sending a full log to guix-bug would be the best for now
<davexunit>alezost: thanks for the help
<davexunit>I was able to load guix-helper and guix-main from a regular geiser repl after adding guix-load-path to %load-path
<davexunit>so I don't know what's up with the actual guix repl
<davexunit>I'm going to stop working on this for now
<davexunit>it seems there's a bug in guix environment...
<davexunit>and I want to squash it
<alezost>davexunit: ok, good luck with that :)
<davexunit>turns out it's not a bug :)
<davexunit>I tried to 'guix environment guix', but it didn't use the guix-devel package like I wanted
<davexunit>so I was missing autoconf, automake, gettext, etc.
<jmd>Viewing makes iceweasel chew up 100% of the CPU
<cmhobbs>how can i list packages available with guix?
<davexunit>guix package -A
<davexunit>the more verbose, readable version is: guix package --list-available
<davexunit>optionally, you can use a regexp to filter
<davexunit>like: guix package -A emacs
<davexunit>jmd: Run: 484 Failure total: 1 Failures: 0 Errors: 1
<davexunit>1 failing libreoffice test! bah!
<jmd>davexunit: YEah. So I see.
<davexunit>so close
<jmd>I will set that environment variable like it says and push again.
<civodul>jmd: seems you're almost there, congrats!
<davexunit>after doing a guix pull as root, how do I make it such that my unprivileged user can use that version?
<civodul>davexunit: you don't, it's per-user
<davexunit>didn't realize that each user can use a different guix
<civodul>users are liberated!
<davexunit>well I should rephrase, I knew they could, but I thought there was something about the root user's guix that got propagated to the system
<jmd>civodul: Often its the last few metres which are the hardest.
<civodul>davexunit: no, there's no such thing
*davexunit corrects brain
<davexunit>civodul: I noticed that starting programs via windowmaker doesn't yield the same environment as when I start them from an xterm or something
*davexunit tries out 'guix environment guix'
<davexunit>so meta
<civodul>davexunit: yes, because xterm runs bash which source ~/.bashrc
<civodul>whereas the thing that starts X doesn't
<civodul>my ~/.xsession sources ~/.bashrc to get the effect you'd like
<davexunit>civodul: okay, I'll try that.
<davexunit>although I haven't had luck getting .xsession to work
<davexunit>I tried earlier today to have it call xmodmap
<davexunit>I'll figure it out. probably some silly error
<civodul>.xsession needs to be executable
<taylanub>I get "configure: WARNING: cannot determine packet capture interface" from building nmap, and later some TCP tests fail. do I somehow need to enable networking for the build process?
<civodul>does "packet capture interface" mean an API, like libpcap?
<civodul>it would be good to check config.log for details on what it means
<civodul>the build process doesn't have network access, indeed
<civodul>so if tests rely on that, they'll have to be skipped
<taylanub>it seems network access is indeed needed and that's why the tests fail, so I disabled them
<taylanub>apparently one can link to lua dynamically, or if one leaves it out then it statically links with a lua which nmap ships itself; I presume it's fine to add a run-time dependency?
<taylanub>Lua is pretty small anyway...
<taylanub>from #Nmap: <bonsaiviking> Libs we ship, but can be replaced with system versions: libpcre, libpcap, liblua, liblinear
<taylanub>should I add all these as inputs?
<cmhobbs>is there a best practice for keeping the guix daemon running?
<taylanub>(well, I'll leave out liblinear; it's not packaged yet and I don't feel like bothering to be honest)
<cmhobbs>guix.el is pretty amazing
<civodul>taylanub: yes, better add these as inputs
<civodul>cmhobbs: on the standalone system it's always running; on other distros, you might be able to use <>
<cmhobbs>thank you