IRC channel logs

2015-08-18.log

back to list of logs

<ennoausberlin>Thank you and Good night from Germany
<sbidin>How do I build guix from source? I can't find the commands to run anywhere, and INSTALL is missing (contrary to what the docs say).
<sbidin>Ah, ok, found it.
<codemac>hm, looks like bitlbee is broken
<codemac>well, running it from systemd is for some reason
<codemac>can't find libnettle, and exits. Probably something to do with the paths set up in systemd
<sbidin>I cannot build guix. Running ./bootstrap gives me "configure.ac:68: error: possibly undefined macro: GUILE_MODULE_AVAILABLE". Not sure what I'm missing.
<davexunit>you're missing guile m4 macros
<sbidin>Thanks!
<mark_weaver>sbidin: did you get .xsession working?
<mark_weaver>a few notes: it has to be an executable program, and it run *instead* of launching your chosen window manager, not *before* it.
<mark_weaver>so: (1) it has to be executable (chmod +x)
<mark_weaver>(2) if it's a script, it has to have a shebang line at the top
<mark_weaver>(3) it has to run your chosen window manager at the end
<sbidin>mark_weaver: Yes, everything's working now! I've been on xmonad for the past hour or so. :)
<mark_weaver>ah, great!
<sbidin>Also, slim does somehow discover xmonad's desktop file.
<sbidin>No idea how though. So, I'm assuming thing would work even without an .xsession.
<mark_weaver>yes, if there's a desktop file in the right place and xmonad is in the OS 'packages' field, it should just work.
<sbidin>Ah
<mark_weaver>ah, well, if you have .xsession file then I think the desktop file is not used at all.
<mark_weaver>it would be good to test to make sure it works without the xsession file, for the benefit of other users who will use this package.
<mark_weaver>sbidin: any progress building guix
<mark_weaver>?
<sbidin>I will, though first I want to make sure the thing compiles correctly. That's why I'm currently stuck on building guix, as you noticed. :)
<sbidin>I got the macros, but encountered other issues.
<sbidin>Will ping #guix about them soon. :)
<mark_weaver>the easiest way is to run 'guix environment guix', which will spawn a subshell that has everything needed to build guix from the git repo.
<mark_weaver>(assuming you don't set environment variables from .bashrc, which you shouldn't do.
<mark_weaver>)
<mark_weaver>(you should set environment variables from .bash_profile or equivalent: a file that's only loaded for login shells)
<sbidin>I *do* set env vars from .bashrc.
<sbidin>Ah, I'll fix that now.
<mark_weaver>btw, make sure to pass --localstatedir=/var to configure
<sbidin>(P.S. I think I may have crashed the build daemon: "guix environment: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused" when running guix environment guix.)
<mark_weaver>wow, you seem to be having several strange problems. I wonder if you have bad RAM or something.
<mark_weaver>sbidin: what is the output of "deco status guix-daemon" ?
<mark_weaver>(run as root)
<sbidin>I don't think it's bad RAM, things work fine outside guixsd. It's just that I'm probably abusing the system somehow. :)
<sbidin>Started, enabled.
<sbidin>Let me fix the env vars first, possible reason?
<mark_weaver>I don't think so
<mark_weaver>does /var/guix/daemon-socket/socket exist?
<mark_weaver>does "ps -C guix-daemon" show a process?
<mark_weaver>I've literally never heard any report of guix-daemon crashing
<sbidin>socket exists, guix-daemon shows *two* processes
<mark_weaver>pstree -u
<mark_weaver>is one of them a child of the other?
<sbidin>yes
<mark_weaver>well, guix-daemon does fork itself when doing work, so that's expected
<sbidin>oh-oh, i was within a guix environment the entire time.
<mark_weaver>but refusing connections on /var/guix/daemon-socket/socket is certainly *not* expected
<sbidin>ah, okay
<mark_weaver>have you done anything strange to your system that might be helpful for me to know?
<sbidin>well, probably, but i no longer really know. i ran a lot of stuff i found on the docs. :) I don't think I did anything a restart would fix though
<sbidin>*wouldn't*
<mark_weaver>well, you could try "deco restart guix-daemon"
<mark_weaver>what is the output of ls -l /var/guix/daemon-socket/socket ?
<sbidin>Okay, only one of them now.
<sbidin>srw-rw-rw- 1 root root 0 Aug 18 02:07 socket=
<mark_weaver>okay
<mark_weaver>well, I have to go soon
<sbidin>thanks for the help! i think the /var option for localstate was what I was missing
<sbidin>the docs don't specify that
<mark_weaver>that shouldn't have caused the problem you saw
<sbidin>should I also configure with --with-libgcrypt-prefix=$HOME/.guix-profile?
<mark_weaver>yes
<sbidin>(whilst in the environment)
<sbidin>okay
<sbidin>great, so configure is done. should I know just try guix out with ./pre-inst-env or really compile it?
<sbidin>*now
<davexunit>run make
<sbidin>running make check
<mark_weaver>btw, don't run "make install"
<mark_weaver>yeah, just run it via ./pre-inst-env
<mark_weaver>or you can make ~/.config/guix/latest be a symlink to the top directory of your git checkout, and then 'guix' will always use the git version by default.
<sbidin>ah yes, you mentioned that the other day. yes, I'll symlink it
<sbidin>the reason why there were two guix-daemon processes was almost certainly because I ran "sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild" from the 7.2 section in the docs
<sbidin>well, at least that's my hunch
<dmarinoj>Has someone got ssh working with guix?
<sbidin>dmarinoj: how do you mean?
<sbidin>sshd?
<dmarinoj>yeah, or can lsh be used for that?
<davexunit>we have an lsh service
<davexunit>for running an ssh server
<davexunit>someone still needs to write the necessary service definition for openssh
<sprang>I'm defining a new module with 2 packages. the 2nd references the 1st as an input, but it doesn't get built unless I specifically install it
<sprang>what might I be missing?
<sprang>main package is "pass" (http://www.passwordstore.org/) and the needed dependency is "pwgen"
<codemac>mark_weaver: that symlink hack should really be suggested for anyone who wants to write new packages in the gnu namespace, made my life much easier just now :) Are there draw backs to running this way for a user?
<sprang>also, I'm putting these both in "password-utils.scm" suggestions for a better module?
<davexunit>ACTION recently wrote his own password store in guile
<codemac>ACTION uses lastpass because syncing, and it's killing his lil free software heart.
<codemac>davexunit: what route did you go for security?
<davexunit>gpg
<davexunit>it's a very simple program. you can add, edit, list, and show "secrets"
<davexunit>a secret is a unique id with an arbitrary set of key/value pairs
<davexunit>so you can store more than just passwords
<davexunit>'shroud show email password' will show me the value of the key 'password' that has been associated with the 'email' secret
<davexunit>and 'shroud show email' will show me all the key/value pairs
<codemac>neat :)
<codemac>And I like the name
<davexunit>I will release it soon.
<sbidin>sprang: the 1st doesn't get built? maybe you want to use propagate-input?
<sbidin>*propagate-inputs
<sbidin>bah, *propagated-inputs
<codemac>random guix success story: been using extempore recently and needed to use a patched llvm. Of course I can use whatever llvm I want because guix is excellence, so it was a few gnu-build-system's away and I just got it running (though now working out how I need to set up pulseaudio/jackd correctly)
<sprang>sounds like it might be what I want... but if the inputs aren't built by default, I'm not sure what they are specifying exactly?
<sprang>it's just built when package 2 is built, but not installed?
<sbidin>if you want to install dependencies when their parent is installed, the parent should reference them with propagated-inputs instead of inputs. I hope I understood correctly
<sprang>I think I understand now.
<sbidin>not sure about "inputs aren't built by default", I'm new at this so hopefully someone else might know more
<sprang>I think they were probably built, just not installed
<sbidin>that's an issue I bumped into as well, and propagated-inputs fixed it for me
<sprang>yes, it seems to have done the trick, thanks
<sbidin>np
<sprang>I think I was confused because the manual says 'inputs' are for build-time or runtime dependencies
<sprang>so I assumed a run-time dependency would be installed
<sbidin>yes, it probably meant inputs as one of native-inputs, inputs and propagated-inputs. :) I was confused by the same thing only yesterday
<sprang>what's the best way to do a "clean" install when you're working on a package? usually after I've been messing around editing for a while, it just jumps straight to "nothing to be done"
<sprang>I've tried removing/gc'ing but it doesn't seem to work like I expect
<sbidin>sprang: did you delete the last generations?
<sprang>ah, haven't tried that
<sbidin>so, after a guix package -d (watch out, that removes all generations except the last one), do a guix gc again
<sbidin>it's a nuclear option I guess, but it works for me until someone tells me of a better alternative
<davexunit>hmmmm xclip isn't working for me
<sbidin>I've successfully built a custom package against the newest guix, but I also want to run it. Where has ./pre-inst-env guix build bla-bla placed the built binary?
<davexunit>ooh nvm it just didn't go to the clipboard I thought it did
<davexunit>sbidin: the directory is output at the end of the successful build
<sbidin>davexunit: oh wow, didn't even notice
<sbidin>thanks :)
<davexunit>np
<sbidin>bavier, mark_weaver: cabal-install refuses to work if GHC_PACKAGE_PATH is set (it wants a --package-db opt instead), so the env var approach no longer seems like a good idea to me.
<sbidin>Fun: when cabal-install attempts to build something that simultaneously references a lib in /gnu/store and a dirty local lib in .cabal/lib, ld-wrapper errors out with "attempt to use impure library".
<sbidin>I wonder whether that can be disabled (GUIX_LD_WRAPPER_ALLOW_IMPURITIES) just for cabal-install?
<lfam>Do I need to do anything special in order to send emails to guix-devel? I sent a patch 4 hours ago but I don't see it on lists.gnu.org.
<mark_weaver>lfam: you need to subscribe to the list in order for your posts to go through
<lfam>That would be it!
<mark_weaver>sprang: when a user installs 'pass', would they normally expect to be able to run 'pwgen' directly? or it is just that 'pass' uses 'pwgen' behind the scenes?
<mark_weaver>if the latter, then it would be preferable to arrange for 'pass' run 'pwgen' via its absolute file name /gnu/store/.../bin/pwgen
<mark_weaver>usually this requires adding a phase that uses substitute* to embed the absolute pathname directly in the code.
<mark_weaver>although there are other approaches, e.g. making a wrapper that sets PATH while 'pass' is set, or some packages allow you to specify the path to a program via a configure flag or make variable.
<mark_weaver>codemac: the main drawback is that if your git checkout is in a bad state, then 'guix' won't work right.
<mark_weaver>in the worst case you can temporarily remove the symlink
<mark_weaver>sbidin: what is the dirty lib in .cabal/lib? maybe we could arrange for that lib to be in /gnu/store instead?
<mark_weaver>anyway, it would be better to make it easy to import libraries from cabal and make them proper guix packages.
<sprang>mark_weaver: pass uses pwgen behind the scenes
<mark_weaver>sprang: okay, in that case 'pwgen' should just be a normal input, and you should arrange for 'pass' to call 'pwgen' via absolute pathname.
<sprang>ok, I will take a crack at that
<sprang>is there a simple way to have the 'check phase do 'make tests' instead of 'make check'?
<mark_weaver>sprang: yes, add #:test-target "tests" to the arguments.
<sprang>excellent, tx
<mark_weaver>yw!
<marcus_>is there a way to define the keyboard layout in the system configuration?
<sbidin>marcus_: You can do something like (services (cons* (console-keymap-service "croat") %desktop-services)), where you replace "croat" with whatever keymap you want, e.g. "fr".
<sbidin>For X, you should just set it using setxkbmap when X runs.
<sbidin>mark_weaver: The dirty lib is any one of thousands, often too unimportant to package. Basically, I want to continue development for Hackage while using guixsd, and to do that I'd like to run cabal in the same way others do it.
<sbidin>Otherwise there's no reason for someone to even install cabal on guixsd, I think.
<sbidin>This is a more general problem of "I have libs unmanaged by guix and I want to use them alongside /gnu/store ones".
<marcus_>sbidin, can i change this afterwards and re-apply as I already started installation?
<sbidin>marcus_: Yes, after you've installed guixsd you can change the config and reapply it with "sudo guix system reconfigure /path/to/config.scm".
<marcus_>great
<marcus_>if i want to configure a service like ntp, do i need to do that within the system configuration as well?
<phant0mas>having some problems with the rpath, with binaries produced from gcc-boot0
***gamabunta is now known as pikos
<phant0mas>I added an ld-wrapper so as to add the missing rpaths
<marcus_>when it's up to documentation, can i refer to the nixos docs or is guixsd completely different?
<davexunit>completely differetn
<davexunit>different*
<marcus_>hmm
<sbidin>marcus_: ntpd is included as part of %desktop-services, but not sure what you'd have to do in order to configure it via the system config.
<marcus_>yes, it seems to be installed but it listens on 0.0.0.0 which I want to disable
<davexunit>ntp-service is defined in gnu/services/networking.scm
<sbidin>Looks like the only option it accepts is a list of ntp servers.
<marcus_>is gnu/services a directory? as it does not seem to exist here
<davexunit>yes
<davexunit>in the source tree
<marcus_>ok, what's the way to make changes to it? first i guess i need to obtain that file, right?
<sbidin>Yes, it's in the guix source repository. Pull it from git.savannah.gnu.org.
<sbidin>It seems to me ntp-service should start with a saner config: one that blocks every connection except localhost and the allowed ntp servers.
<marcus_>that would be great
<sbidin>i.e. using "restrict default ignore", then as noted here: http://support.ntp.org/bin/view/Support/AccessRestrictions#Section_6.5.1.2.1.
<marcus_>is it that one? http://git.savannah.gnu.org/r/guix.git/
<sbidin>Yes.
<marcus_>after downloading that file, should i combine it with my system configuration?
<sbidin>I've never done that, so hopefully someone else will answer you. I assume that if you take ntp-service from networking.scm and place it in your config (with the corresponding module imports), it would work.
<sbidin>You'd also need to stop using %desktop-services, as that contains a call to the old ntp-service.
<sbidin>Though this would all ideally not be needed -- ntp-service should just be more configurable by default.
<marcus_>but when i reapply the config without desktop-services doesn't it unconfigure all my desktop configuration? as far as i got it now is that it's state based.
<sbidin>Yes, you'd need to remove %desktop-services and in its place put a list of everything %desktop-services used to contain but without ntp-service. (That's my assumption anyway, I'm new.)
<sbidin>%desktop-services is defined in gnu/services/desktop.scm.
<marcus_>ok, i guess i have to do some trial and error
<davexunit>civodul is back in action on the mailing list
<phant0mas>civodul is on overdrive!!
<sbidin>I'm within a guix environment guix, building a new package with ./pre-inst-env. However, an old build is always immediately given with no work having been done.
<sbidin>How do I "force clean" an environment?
<sbidin>I'm sure I've made changes to the package, and I've re-run make.
<mark_weaver>sbidin: ./pre-inst-env guix build <package> prints the old output(s) then you must not have changed anything that affects the build. what did you change?
<sbidin>mark_weaver: Ah, so I can be certain that all is well? I've done minor changes to the package's scm file, such as removing an unused module import.
<mark_weaver>that wouldn't affect the build
<mark_weaver>guix builds a *.drv file, known as the "derivation", which precisely describes the build (and refers to other derivations)
<sbidin>Ah, so only some fields count as a build change. Modify the description also does nothing.
<sbidin>Okay, great!
<mark_weaver>if the derivation is the same as one that has been built before and is in your store, then it just uses that one.
<mark_weaver>right
<sbidin>I've added a gnu/packages/xmonad.scm, and added it to gnu-system.scm. Do I need to do any other housekeeping because of this new module?
<bavier>with all the work on window managers recently, I was surprised to find that we don't have a dedicated module for such packages
<dmarinoj>bavier: that sounds like a cool idea
<sbidin`>I have xmonad and ghc-xmonad-contrib working nicely, but they depend on like 10 other extra packages. Do I need to add each one of those with a separate patch?
<sbidin`>Or may I combine them? They're all ghc-something packages and belong to gnu/packages/haskell.scm.
<bavier>sbidin`: that's cool!
<bavier>typically we'd ask for a separate patch for each
<bavier>did you run across ghc-doctest in getting xmonad up and running?
<sbidin`>Ok, separate patch for each it is.
<sbidin`>bavier: No, I didn't. What is it?
<bavier>sbidin`: just a hackage library that is giving me trouble while trying to package git-annex
<sbidin`>Ah, I see. No, haven't a clue about any problems there.
<sbidin`>Do the tests fail or it fails to compile or?
<sbidin`>If they're a test-suite dependency, consider disabling tests.
<bavier>sbidin`: I think it's a build thing
<bavier>it's been a little while since I looked at it last
<sbidin`>Wow, git-annex is huge. No wonder an issue cropped up.
<bavier>the build tries to do some non-standard things that don't work as well in our haskell-build-system
<sbidin`>Ah
<bavier>sbidin`: yeah, I think I have ~80 local ghc-* packages in limbo
<sbidin`>bavier: That's crazy. :)
<sbidin`>You probably made some of the same packages as I did.
<sbidin`>Which reminds me: we should possibly stick to using Stackage versions when possible?
<sbidin`>The latest LTS anyway
<bavier>sbidin`: I hope not too many. I hadn't realized you were working on xmonad
<sbidin`>Well, the 10 ones I did were small and mostly just guix import.
<sbidin`>So no trouble
<bavier>sbidin`: sticking to stable versions would be nice, yes
<amz3>ahaha, I happen to need guix environment :D
<lfam>Is there a good way to reply to a post on the mailing list that was sent before I was subscribed? Just copy and paste the original post and indent?
<bavier>lfam: from the archive, you can click the "reply via email" button, and copy&paste the text
<davexunit>ooh, TIL
<bavier>davexunit: small typo on line 86 of your nginx-service patch: "CONFIG-FIGLE"
<remi`bd>hey! there’s something strange in guix/ui.scm
<sbidin`>What do I need to install to have git send-email?
<remi`bd>`args-fold*` is a wrapper around srfi-37’s `args-fold`; the signature of the first is: `(args-fold* options func func . seeds)` while the signature of the second is `(args-fold args options func func . seeds)`
<lfam>sbidin`: I've been meaning to file a bug about that. I don't think the packaged git includes it. I think it would be in /var/guix/profiles/per-user/$USER/guix-profile/libexec/git-core
<remi`bd>and, still in (guix ui), the function `parse-command-line` has this `args` parameter and uses args-fold* like that:
<remi`bd> `(apply args-fold* args options func func seeds)`
<remi`bd>source: http://git.savannah.gnu.org/cgit/guix.git/plain/guix/ui.scm
<remi`bd>I believe one parameter is missing, but the use of apply hide that
<sbidin`>lfam: Yes, it's not there.
<sbidin`>Oh well, manual emails it is.
***sbidin` is now known as sbidin
<bavier>sbidin: install the "send-email" output of git
<bavier>sbidin: 'guix package -i git:send-email
<sprang>I want to add a password-utils.scm module, I notice other "util" modules don't have a dash, but some other modules use a dash
<sprang>is there a guideline for that?
<sbidin>bavier: Thanks!
<bavier>sprang: many of the other '*utils' modules are named after packages whose names contain no dash
<bavier>sbidin: np
<sprang>I see
<davexunit>bavier: thanks!
<sbidin>Working on the guix tree via magit is slooow. Every action (staging, commiting, creating patches) takes 20+ seconds. Am I doing something wrong?
<yenda>that is strange I don't have this problem
<taylanub>sbidin: probably. I don't have such a problem, using the latest Magit on on GNU Emacs 24.5 on a ThinkPad T420 (Intel i5, 4G RAM)
<davexunit>yeah that's never happened to me.
<davexunit>using the magit package in guix
<taylanub>thinking of Guix's Scheme code-base and how we have an alist-ref utility function that's used often, it now really bothers me that I couldn't get alist support into SRFI-123. really can't think of a nice way though.
<taylanub>the least bad idea (from tali713 on #emacs) so far is to support 1-element lists to use their element as an alist key, so car/cdr and integers can keep working for pairs and lists
<taylanub>but that's still a very ugly hack :(
<davexunit>the index argument could be tagged in such a way that distinguished regular list references from alist references
<taylanub>davexunit: can you think of a tagging mechanism that's less ugly than wrapping the key in a 1-element list?
<davexunit>that's what I would propose
<davexunit>or use a srfi-9 record
<taylanub>it mostly loses its value though; compare (alist-ref alist key) to (ref alist (list key)) ... not shorter, and has a "wtf" effect. using a record type, I'd need to squat another very-short word as the constructor for the type. using another punctuation symbol for that would make some people mad probably... though (ref alist (@ key)) isn't too bad maybe?
<davexunit>alists are just special, since they aren't a new data type
<davexunit>they're just a particular list shape
<taylanub>yeah. it would be very neat to support (ref alist key), but they just don't play along.
<sbidin>Ok so Magit was slow because it kept track of changes to po/packages/*.po files for some reason. I ignored those and things are fine now.
<sbidin>A commit message style question: I've added a package, but also an additional import. Needs mention?
<sbidin>(additional use module, specifically xorg)
<sbidin>Ok, checked the logs, turns out it's not needed.
<yenda>Even with the following subsitution the python tests are still failing for the same reason
<yenda> https://bpaste.net/show/5ca0ac4372d2
<sbidin>Using the --cover-letter option with git send-email does nothing?
<sbidin>It seems as if it is being ignored.
<sbidin>I expected to be prompted for the contents of an introductory email?
<sbidin>Here's my exact usage: git send-email --cover-letter *.path
<sbidin>Using --compose works, however. But doesn't insert a diffstat.
<sbidin>Using the --cover-letter option with git send-email does nothing?
<sbidin>It seems as if it is being ignored.
<sbidin>I expected to be prompted for the contents of an introductory email?
<sbidin>Here's my exact usage: git send-email --cover-letter *.path
<sbidin>Using --compose works, however. But doesn't insert a diffstat.
<sbidin>Whoops, sorry.
<bavier>sbidin: --cover-letter creates a 0000-* file, correct?
<sbidin>bavier: No.
<bavier>that's strange
<bavier>I think I've used --cover-letter with -o before
<bavier>sbidin: my mistake, 'git format-path --cover-letter'
<bavier>sbidin: format-patch, not send-email
<sbidin>bavier: Ah, okay, it works now. :)
<sbidin>Thanks!
<bavier>sbidin: np
<yenda> I feel totally confortable and safe buying this https://on.google.com/hub/ :D