IRC channel logs

2014-11-21.log

back to list of logs

<civodul>Hello Guix!
<mongrol>not having much luck with the 0.8 installer
<civodul>mongrol: what's going on?
<mongrol>some disk error when runnign deco start cow-store /mnt
<mongrol>fuse: bad mount point '/.rw-store":
<mongrol>sorry, I have to type it out since i can copy paste
<mongrol>and also system-error("mount ~S on ~S: ~A" ("/.rw-store" "/gnu/store" "Invalid argument") (22))
<mongrol>I'm using qemu but didn't have this with 0.7
<str1ngs>do you have a block devices mounted to /mnt ?
<mongrol>yes
<str1ngs>what FS is it?
<mongrol>a ext3 volume /dev/sda1
<str1ngs>what does touch /foo do ?
<str1ngs>does it error?
<mongrol>no, create foo in /
<mongrol>it succeeds
<mongrol>the /mnt filesystem is also writeable
<str1ngs>does /mnt/gnu/store exist?
<mongrol>no
<str1ngs>mkdir -p /mnt/gnu/store
<str1ngs>and try again
<mongrol>service started, its given me the fuse error above
<mongrol>bad mount point `/.rw-store': No such file or directory
<str1ngs>guix --version is 0.8 ?
<mongrol>yep, this is the 0.8 usb installer image
<str1ngs>let me see if I can replicate this
<mongrol>stopping cow-store and restarting gives both errors again
<str1ngs>I'd love to know what cow-store does
<str1ngs>other then forcing writing to disk and not using memory. just wonder how it goes about it
<str1ngs>did you create the image yourself?
<mongrol>no, its from ftp.gnu.org
<mongrol>sudo qemu-system-x86_64 -hda guix.img -hdb gnu-usb-install-0.8.x86_64-linux -boot menu=on -vga std
<str1ngs>I'll try that then
<mongrol>running it like that
<mongrol>guix.img is a qcow2 format
<str1ngs>whats on quix.img?
<str1ngs>oh nvm
<civodul>weird
*civodul tries the same command
<mongrol>I suppose I could just manually move .rw-store to /mnt myself
<civodul>it's damn slow without -enable-kvm, BTW
<mongrol>ah, didn't notice :)
<civodul>hmm i can't reproduce it
<mongrol>I
<mongrol>I'll wipe everything and start again
<civodul>could you make sure you're starting from the pristine installation image?
<civodul>it could have been altered somehow, perhaps
<mongrol>will redownload
<mongrol>thanks
<civodul>ok
<str1ngs>with out kvm its not use VT extentions
<civodul>(or just check the SHA1)
<str1ngs>I cant replicate it either :(
<mongrol>np, I'll redo everything
<str1ngs>you broke it real good ! :P
<davexunit>morning #guix
<davexunit>I can't run emacs from X! :(
<davexunit>I get some error about dbus
*davexunit found the issue
<davexunit>needed the avahi service and dbus service running
<rgrau>hi. So there's "just" emacs 24.4 in our repos?
<davexunit>rgrau:
<davexunit>oops
<davexunit>rgrau: yes
<rgrau>oks, it seemed strange, just double checking that I'm up to date :)
<civodul>rgrau: what else do you want? :-)
<rgrau>oh... I got confused... thought the newly released one was 24.5
<rgrau>after installing 'guixOS' (or, what's the name of the distro?), I installed xorg-server, but when I try to run 'X'it fails to start (I guess it's because I haven't configured anything...) any pointers to what to do to configure X?
<rgrau>years ago there was a tool that generated Xorg.conf file (which I forgot it's name), but anyway, AFAIK nowadays xorg.conf file is obsolete, no?
<davexunit>rgrau: I don't start X manually, but use the slim-service in my OS config file
<rgrau>oks, I see there's a section in the manual for it... when I installed guix distro I did it with the exact minimal example file that came with it
<rgrau>I guess there's a way to update the file and say 'update to this state' ... (blind guessing)
<davexunit>yes
<davexunit>you can update your config file
<davexunit>then run 'guix system reconfigure /path/to/config.scm' as root
<rgrau>reconfigure I see
<davexunit>from there, I have been rebooting... but surely there's a better way...
<rgrau>good enough for me :)
<rgrau>thanks, will try
<davexunit>yw
*davexunit has a pretty decent guix setup now
<davexunit>doing some of my FSF work on it today
<civodul>yay!
<civodul>now we can say: "the FSF supports Guix"! :-)
<davexunit>:)
<davexunit>thing to package: pidgin
<rgrau>a more complete config.scm (with X and slim) on the page would be quite helpful (maybe there's one already)
<civodul>rgrau: oh you're right, that's a good idea
<davexunit>yeah
<davexunit>I was thinking the same thing
<davexunit>also, with dbus and avahi!
<rgrau>I collected a few ideas when I was installing guixos for the first time like: include a minimal irc client in the base installation
<rgrau>also, include the hydra.gnu.org.pub there
<davexunit>my emacs didn't work for me at first because I didn't have those services defined
<rgrau>failed to load operating system file 'myconf.scm': ... no code for module (gnu system xorg) ... I clearly have no idea what I'm doing :/
<davexunit>(gnu services xorg)
<Steap_>there is no gnu/system/xorg.scm
<rgrau>oh ffs. I
<rgrau>I'm stupid...
<rgrau>thanks again guys . When you have a cold, don't try new things that require any kind of wit or awareness
<rgrau>:)
<davexunit>it's all good :)
<rgrau>ok, Installing a few services there :). Not sure if it's a typo, but in http://www.gnu.org/software/guix/manual/guix.html#Base-Services
<rgrau>there's the line (cons* (avahi-service) (lshd-service) %base-services)
<rgrau>which I think lshd-service should be lsh-service
<rgrau>one question more: now slim is installed, and when logging in, it jumps into NeXTStep window manager. I'm trying to change it to ratpoison, but the usual locations are empty! :p
<rgrau> /etc, /usr/bin/xsessions
<rgrau>..
<rgrau>couldn't find anything in /var/guix/profiles/per-user....
<mattl>i sent a bug to the guix mailing list -- does that mean it will appear in the bug tracker?
<rgrau>maybe it has to be approved
<davexunit>in debbugs, yeah
<rgrau>if you're not subscribed...
<davexunit>mattl: actually wait, did you send to guix-devel or bug-guix?
<davexunit>bug-guix is the debbugs address
<mattl>bug-guix
<davexunit>okay
<mattl>i'm not subscribed there, obviously.
<davexunit>yeah, you should get an email in return about the bug details
<davexunit>you don't need to be subscribed.
<mattl>ah, it just arrived ;)
<davexunit>afaik
<davexunit>cool
<mattl>now fix my bug ;)
*davexunit waits for the mail to arrive
<mattl> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19144
<nebuli>rgrau: slim uses ~/.xsession
<davexunit>mattl: ah, that's something that has been brought up a few times. it will happen.
<davexunit>I don't know how to do it, though.
<nebuli>rgrau: guix pull & reconfigure if you want X session to see your profile PATH
<mattl>do you know how to unpack the file i download? I unpack the xz file, and i get a single blob... a DOS/MBR boot sector.
<davexunit>^ yes
<davexunit>mattl: yeah, that's right. it's a disk image. from there, you can use dd to copy it to a flash drive or something
<davexunit>that's what I do
<mattl>yeah, but i can't boot a virtual machine from a flash drive, needs to be a file on disk
<rgrau>nice. thx. I'll try to recap all this and make another tut
<rgrau>like the one I did for packaging
<davexunit>some other people have used the guix disk image on a VM... anyone online right now that's done it?
<rgrau>like, for total dumbs :)
<nebuli>2015 will be the year of guix on the desktop, lulz.
<davexunit>it's certainly on my desktop :P
<davexunit>I need to fix up guile-wm to be usable
<nebuli>and it stays forever on my laptop
<davexunit>then I can have a lisp package manager, init system, text editor, AND window manager.
<davexunit>(I know, I know: stumpwm)
<zdavis>mattl: I used the usb drive image along with plpbt to boot the image on vmware
<mattl>zdavis: did you make an ISO?
<zdavis>no, but I've been meaning to add it as a feature
<davexunit>there's gotta be some conversion tool that people can use in the meantime...
<mattl>well, i'll try it out when there's an ISO. i think a lot of people will.
<zdavis>I dumped the usb drive image onto a usb drive and uses plpbt to select the usb drive as boot device
<rgrau>and something along THIS lines https://github.com/pjotrp/guix-notes/blob/master/RUBY
<zdavis>It was fairly round-about...
<rgrau>then I'm sold.
<nebuli>mattl: you can always 'guix system init' from existing linux install
<mattl>nebuli: yeah, i don't want that. i have to keep this machine working and pretty stable.
<nebuli>mattl: if you can spare a parttion on the system the worst thing that will happen is that you'll have to ask grub to use it's config from your original linux system boot parttion at start
<mattl>nebuli: yeah, i really just want a virtual machine.
<mattl>rebooting all the time would be a nightmare
<DusXMT>mattl: you can create a virtual machine image with `qemu system', I don't remember the command off my head though (don't have Guix on this machine)
<mattl>its okay, i'll wait for the ISO now.
*DusXMT somewhat doubts there'll be an ISO in the near future
<mattl>DusXMT: well, an ISO would probably help people actually use this, but whatever.
<DusXMT>mattl: What virtual machine are you using? Virtualbox and Qemu can both work wih the USB image afaik
<mattl>Boxes and VirtualBox
<davexunit>there will be an ISO
<mattl>davexunit: great. thanks.
<davexunit>the reason we don't provide them right now is only because it's more work
<davexunit>but we once we have a process in place to generate them
<davexunit>should be easy
<DusXMT>(But in the case of Virtualbox, I think it needs to be converted into VDMI, which is not hard to do, just google `convert raw image to vdmi' (or is the format called something else?), and add that as a second hard drive and boot from it)
<jmd>Do builds on hydra get triggered by commits or what?
<DusXMT>Yup, it's called VDI, not VDMI
<nebuli>ISO image will help people install guix, but if they want to stay with their old OS install it will not help them actually use guix as their day to day system
<davexunit>jmd: yes. hydra pulls the latest commits periodically
<jmd>So it's polled and not interrupt driven.
<davexunit>yeah, there isn't a git hook for this
<mattl>nebuli: i won't use guix as my day to day system for a while, i suspect, but an ISO would let me try it out and actually see how well it works and how close I could be to actually using it.
<DusXMT>mattl: and what's wrong with my suggestion? https://blog.sleeplessbeastie.eu/2012/04/29/virtualbox-convert-raw-image-to-vdi-and-otherwise will tell you how to convert it to Virtual-box readable format, and then just attach it as a second disk to your VM
<mattl>DusXMT: what's the first disk of my VM?
<DusXMT>The one you want to install it to?
<mattl>okay. maybe i'll try that sometime. i've spent too much time on this now.
*mattl goes back to writing code
<davexunit>see ya mattl
<davexunit>it'll be easy eventually :)
<DusXMT>(said once the hurd developers :)
<davexunit>heh
<mattl>davexunit: at some point, let's talk about getting GNU FM and GNU social into guix
<davexunit>well I mean it :)
<nebuli>guix or death...
<DusXMT>nebuli: I pick guix
*nebuli tries to pick up 'or' and fails.
<jmd>How can I build the package cross-pkg-config ?
<jmd>guix package: error: build failed: the path `/gnu' is a symlink; this is not allowed for the Nix store and its parent directories
<jmd>How Rude!!
<taylanub>does anyone else have it that guix CLI output sometimes misses newlines, writing two messages on the same line like say "http://hydra.gnu.org/nar/...-guile-json-0.4.0 18.1 KiB transferredbuilding path(s) `/gnu/store/...-module-import'"?
<bavier`>might be caused by threading in guix-daemon
<taylanub>I ask before reporting because I'm using a non-release version of Guile from git, so the bug could be there too
<civodul>taylanub: guix-daemon spawns several build processes in parallel, and merges their output, hence the intermingling
<civodul>i agree this is suboptimal, but hard to fix
<taylanub>ok, I see
*nebuli works on adding --max-jobs option to 'guix build' then setting it to 1 might be a temp work-around
<civodul>nebuli: indeed, yes
<bavier`>`guix build` already has --cores option, is that different?
<civodul>yes, see the doc for guix-daemon, which has both
<bavier`>civodul: got it
<civodul>nebuli: actually 'set-build-options' in (guix store) should have it default to 1 in the first place
<bavier`>the docs say the default for guix-daemon's --max-jobs is 1, shouldn't that prevent intermingled output?
<nebuli>civodul: yex, i'm working on more sane defaults
<civodul>yes, but set-build-options (used all around) has it default to nproc
<civodul>nebuli: nice :-)
<nebuli>civodul: atm, n^2 threads is too HOT!
<civodul>oh, because set-build-options-from-command-line sets #:build-cores to 0
<civodul>nice, i had never realized that :-)
<civodul>one day i was like "let's set this one to N and the other one to 1"
<civodul>and the next day it was the opposite
<civodul>and so, N²
<civodul>:-)
*nebuli nods; should have a patch proposal today or tomorrow, making both options available makes for more complex input validation
<mark_weaver>civodul: I was confused about it as well. The "Invoking guix-daemon" node of the manual states that the defaults for --cores and --max-jobs are both 1. That may be true, but it will leave users scratching their heads, I think.
<mark_weaver>It would be helpful to have a way to actually enforce serial builds, one at a time.
<nebuli>o/
<mark_weaver>thanks for working on it, nebuli! :)
<nebuli>in the sanest default i want to have one build job with (- (current-process-total) 1) cores
<mark_weaver>civodul: I would expect the server's default values of --cores and --max-jobs to be used unless I specifically ask the client to override those settings.
<bavier`>mark_weaver: I would expect the same.
<mark_weaver>if the client *always* overrides them, then the server options seem nearly useless.
<mark_weaver>(i.e. except when using some other client, but that seems likely to be quite rare)
<civodul>mark_weaver: yes, you're right
<nebuli>making client not override daemon settings would be good, too, but i'll settle for not frying my laptop as a first step... default guix-daemon settings of unlimited jobs and cores lead to n^2 phenomen…
<nebuli>…on anyway
<civodul>i think initially there *had* to be a set-build-options RPC once the connection had been established
<civodul>or so i thought
<taylanub>what's the quickest way to get the base32 sha256 of a file?
<nebuli>guix download
<taylanub>neat, thanks
<taylanub>apparently nmap uses GPLv2 but its COPYING file has a header with some additional text: https://svn.nmap.org/nmap/COPYING how should I proceed? it talks about special exceptions to the GPL, which I thought were prohibited by the GPL, or is that just v3?
<civodul>good question
<civodul>i would just use "gpl2+" (or "gpl2")
<civodul>seems to me that the top of the file is just a clarification/interpretation of parts of the GPL, which is not supposed to change its meaning
<davexunit>hello #guix, I'm typing this from my standalone guix machine :)
<civodul>yay, congratulations, davexunit! :-)
<civodul>so you must have accumulated a list of things to fix, no?
<davexunit>not really, actually.
<davexunit>haven't run into any issues today.
<bavier`>woohoo!
<davexunit>I need to get my email setup here
<civodul>heh
<nebuli>no issues sucks ;)
<civodul>no issues, no fun
<davexunit>though, I have a feature request in mind: an easy way to reproduce a user profile across machines.
<davexunit>I always want emacs, guile, notmuch, etc.
<davexunit>but those things need not be installed system-wide
<phant0mas>reproducing user profiles would be great
<civodul>currently you can do something like: "guix archive --export $(readlink $(readlink $(readlink ~/.guix-profile))) > foo"
<civodul>and then "guix archive --import < foo" on the other machine
<civodul>and then fix up the symlinks by hand
<civodul>hmm
<civodul>we can do better
<davexunit>yes, we sure can.
<davexunit>guix profile import profile.scm
<davexunit>or something
<mark_weaver>taylanub: if you already have the file, "guix hash <filename>" is a bit simpler
<mark_weaver>davexunit: ooh, congrats on running standalone guix! :)
<taylanub>mark_weaver: ah, thanks
<civodul>davexunit: guix package --export=$HOME/.guix-profile | ssh guix package --import -p /foo/bar
<davexunit>civodul: looks good
<taylanub>how do I depend on g++?
<taylanub>oh, I guess it's covered by the gnu build system in my case