***francis7 is now known as francis8
***francis8 is now known as francis7
<sunnymilk>i tried running guix system init and it worked except for the very last part, where it tried to install grub <sunnymilk>i believe i fixed the problem, but when i run it again it complains that a file already exists <mbuf>is it possible to run guix on a virtual machine? <isd>mbuf: it is. are you having trouble? <mbuf>isd, how do I install that in VirtualBox? <mbuf>isd, I have seen the USB image installer, but, how do I try it in VB? <isd>mbuf: I *believe* VirtualBox has an option for hooking up a disk image as a usb device. It's been a while since I've used it. <isd>I mostly end up using kvm these days <mbuf>isd, will try it out; thanks! <mbuf>isd, do you have documentation on how to run it with kvm? <isd>mbuf: so to be clear, I'm not a core developer and don't really have a full index of the docs in my head. <isd>If I'm launching a guix vm, I'm probably building it with `guix system vm` which gives you a disk image and a script, but I don't know about the usb image <isd>I feel like I've gotten the usb image to work just by presenting it as another (secondary) hard drive, but I'm not 100% on that. <amz3>mbuf: do the same with VB <amz3>I mean, add the usb disk image as another hard disk <mechanical>I have not read the GUIX manual yet, but I have one quick question, if that's okay. <mechanical>There's nothing in particular stopping GUIX from being run on any UNIX-like system, such as a BSD, is there? ***cirno is now known as Guest6045
***Guest6045 is now known as cirno9
<cirno9>How do I get started with compiling on guix? guix package -i make gcc was not enough <alezost>cirno9: do you mean on GuixSD? You need to install gcc-toolchain package <alezost>("gcc-toolchain" instead of "gcc"); for the usual gnu build system you may also need "autoconf" and "automake", perhaps some other things <cirno9>Is there a way to searchfor a particular header file in the list of guix packages? I found xproto using guix package -s Xlib but now I need something with X11/Xlib.h <cirno9>I found that in libx11 nbut now I have the same problem with asm/socket.h <rekado->there is no searchable metadata. I usually have a lot of stuff in the store already, so I just run 'find /gnu/store -name "socket.h"'. <rekado->does anyone else see "bash: words: bad array subscript" when hitting tab at a shell prompt in xfce-terminal? <cirno9>"This public key is installed along with Guix, in prefix/share/guix/hydra.gnu.org.pub, where prefix is the installation prefix of Guix" - how do I find prefix? <iyzsong>cirno9: it's the install location, suppose `which guix` return /xxx/bin/guix, then /xxx is the prefix. <cirno9>If I have: guix archive --authorize < /run/current-sys <cirno9>my computer heats up and stalls for a sec, like its working really hard <cirno9>it might be related to the other tab thing <iyzsong>yeah, I have same issue with the bash completion for guix too. <alezost>cirno9: I think it's because of bash autocompletion for guix commands: often when you hit TAB, "guix package -I" is ivoked under the scenes to receive a list of packages: try "guix package -i wg<TAB>" for example <amz3>I am the only the find guix slow ? <alezost>a list of packages is received every time when the package name is required and you hit TAB. autocompletion in emacs (M-x shell) is faster because the list of packages is received only once <amz3>st terminal for instance should open instant, it's the case on my laptop running debian <alezost>ACTION has not noticed any particular slowness-es comparing GuixSD with "Arch Linux" <amz3>then it's just a feeling <davexunit>sneek: later tell civodul you forgot the patch that goes with the CRDA package, which prevents me from reconfiguring my system. <davexunit>hmm, we don't seem to have avr-gcc, could've sworn we had that. <alezost>davexunit: I've already sent a mail about crda patch :-) <cirno9>what is your preferred image host? <davexunit>cirno9: your personal medgiagoblin instance ;) <davexunit>a-ha, we *do* have avr-gcc, but it's not exposed as a public package. I will change this. <cirno9>this is my fresh install of guix (im really happy to have it!) but very few icons show up <davexunit>cirno9: one sec, I installed a set of icons that made that better <cirno9>It might be nice for people checking out guix for the first time fi the icons are all there <davexunit>we don't make any decisions as far as look-and-feel goes at this time <cirno9>could maybe include that in the desktop basic config? <davexunit>well, the user still needs to elect to use whatever icon theme that we'd include. <davexunit>unless there's a way to set it as the system default. <davexunit>if there's a way to globally set the default theme for XFCE, I think including the gnome icons would be a good idea. <davexunit>but I would need someone familiar enough with xfce to confirm/deny <cirno9>sorry if im asking too much basic questions <cirno9>but I got a bit stuck, I want to change my login shell to rc <cirno9>the obvious thing (instlling shadow, then using usermod -s `which rc`) stopped me being able to log in <iyzsong>cirno9: I think you need to set some thing like: '(users (shell #~(string-append #$rc "/bin/rc")))' in os config. <avshalom>hi all, pardon the noob question, which may be an faq. does guix install over the top of nix? I have a nix install in a non-root "proot" <iyzsong>cirno9: then do a `guix system reconfigure', which should modify '/etc/shells' and '/etc/passwd' accordingly. <iyzsong>avshalom: never tried a non-root setup, but I use both nix and guix, their files are total seperated. <cirno9>ooh thanks a lot ill research into that <avshalom>iyzsong: i guess i'm wodnering why is se guix-0.3 as a nix package <avshalom>that seems like an older version of guix <davexunit>avshalom: because guix is a regular piece of software like anything else, and thus can be packaged for other package managers <iyzsong>avshalom: yes, we have guix package in nixpkgs, and nix package in guix :-) <avshalom>ok, not sure how to proceed. i would like to install guix, but not involve the sysadmin <davexunit>avshalom: you can run guix without being root, but you make the same compromises that you make with nix: no build isolation, no pre-built binaries. <avshalom>davexunit: thanks, that should be no problem. 40 cores just ready and waiting to compile software :-) <avshalom>i will try to install the guix binary and see if non-root option presents itself <davexunit>avshalom: you'll have to install from source <davexunit>our binary tarball does the typical root installation <avshalom>davexunit: ok, thanks. i will try source intsall <davexunit>avshalom: good luck. it's the path less traveled. ***exio4 is now known as init
<yenda>I tried to install guixsd and got a kernel panic http://imgur.com/42vid7y. It dropped a scheme prompt at first and I ,quit it to end up with this kernel parnic. I restarted and now I have the expected tty the manual is talking about. <davexunit>yenda: a backtrace (,bt at the REPL prompt) would help us understand what's going on <yenda>ok if I get that screen again I'll run it. Is it a better way to take a screenshot than take a picture ? ***nick is now known as Guest34686
<yenda>If ifconfig returns nothing should I assume my network interface is not recognized ? <yenda>sorry stupid question I forgot the flag <davexunit>yenda: whatever you can do to get the backtrace works <cirno9>I tried adding rc to my system configuration, doing a full reconfigure and that gets me rc in /bin/shells - but still if I try to set my login shell to /bin/rc i cannot log in <yenda>davexunit: ok, no more troubles atm it's compiling. <cirno9>just wondering if there's a trick to set my login shell correctly? <yenda>If I want to be able to use the sudo command is adding "sudo" to the package list and the complementary group in the config file the right way to go ? <alezost>yenda: I think it's not necessary - "sudo" should be available (in /run/setuid-programs) without installing <yenda>Is there a way to check config file syntax ? Because I guet an unexcpected EOF reading aline when running guix system init <yenda>alezost: ok thanks, that was a premature concern then <paroneayea>ugh, I had the vague idea that separating / and /home would be convenient for possible migration to guixsd later since I was already reinstalling my OS in an encrypted LVM <paroneayea>but now I need to resize /home which is going to be a pain in the butt <yenda>I found my mistake it was "label" instead of 'label. <yenda>I still get the following error running guix system init : "guix substitute: warning: failed to look up host 'hydra.gnu.org' (name or service not known), substituter disabled" "guix system: error: build failed: unexpected EOF reading a line". <yenda>Is it because I have a typo in my config file (but I couldn't find it) ? <cirno9>maybe you don't have internet set up yet? ping hydra.gnu.org could help test that <yenda>I already tried it worked. Also I ran guix pull first and it downloaded and compiled some packages without trouble <mark_weaver>avshalom, davexunit: I have doubts that a non-root install will work in practice. A few caveats to mention right off the top: <mark_weaver>(1) if you can't use /gnu/store as the store prefix, then you can't use any binary substitutes from hydra, so you'll have to compile everything yourself, including bootstrapping the toolchain, etc, which is quite a lot. <mark_weaver>(2) I have doubts that our packages will build properly outside of a chroot environment, where the configure scripts will be able to find things from the host system in standard places like /usr, /bin, and /lib <davexunit>I would like to address #2 at some point by using a user namespace (on Linux) <mark_weaver>(3) if your store prefix (normally /gnu/store) is not sufficiently short, you will run into probably because in linux (the kernel) the shebang lines at the top of scripts are limited to ~127 bytes. <mark_weaver>maybe we should ask the linux developers to increase it. I wonder how hard we'll get flamed :) <paroneayea>ACTION wonders how much he really trusts shrinking ext4 partitions and lvm volumes to preserve data :X <paroneayea>I have backups, but will errors really be caught? or will I have silent corruption... <paroneayea>maybe it's best to resinstall with just a "big root" <paroneayea>otherwise I can't really reuse guix alongside debian right now <davexunit>grr avr-ld seems to completely ignore LIBRARY_PATH <paroneayea>mark_weaver: hm yeah I could symlink it into /home/ <mark_weaver>but I'm not sure if it's really needed or not, just a vague memory <mark_weaver>paroneayea: fwiw, I would probably not be afraid of the ext4 shrinking code. the filesystem developers tend to be careful about data loss. <avshalom>mark_weaver: thanks for the insight. might save me from a futile endeavour <yenda>even when rewriting the config file I get this EOF errori <rekado->yenda: hydra is sometimes too slow to respond. Can you reproduce the exact error at a particular time? Or does it appear random? <yenda>rekado-: it appears every single time. It's my first install I'm running guix system init <mark_weaver>yenda: can you try again now? I did something on our build farm that might help <mark_weaver>the postgresql process seems to have a memory leak, and eventually gets quite bloated (almost 1 GB of memory), and that tends to slow everything down. I just restarted it. <yenda>mark_weaver: ok i'll try as soon as guix pull is done it's been running for an hour <yenda>it's wierd the first time it only took 10 min <mark_weaver>guix pull is an expensive operation. it needs to compile all of guix. <mark_weaver>there's another method: build guix from git, and then do "git pull && make", which is vastly faster and more flexible, but takes a bit more effort to set up. <mark_weaver>(and every once in a while you need to "make clean-go && make") <yenda>mark_weaver: is it possible that it went so much faster the first time because it failed somewhere ? <yenda>no error message displayed at the end as far as I remember though <mark_weaver>to be honest, I've literally *never* use "guix pull". <yenda>I cancelled it to retry guix system init <yenda>mark_weaver: is it possible that this EOF comes from my config file ? <yenda>mark_weaver: might be a noobie question but how do I extract it from the system ? The only idea would be to redirect output to a file with > and copy it to the usb key <mark_weaver>yenda: the config file is not included in the built system. if you didn't save it anywhere, it's gone. <cirno9>I'm very stuck on how to start lsh ssh server with dmd <cirno9>I managed to find a service file and did deco load dmd /gnu/store/....-guix-latest/gnu/services/ssh.scm <cirno9>but now im not sure what to do, none of deco start ssh or lsh or lsh-service worked (it says no service provides) <mark_weaver>cirno9: you need to add 'lsh-service' to the 'services' field of your OS config. <mark_weaver>and then "guix system reconfigure <os-config>" and reboot. <yenda>mark_weaver: I mean I'm not installing in a virtual machine or a server I'm on a desktop <mark_weaver>(obviously we plan to eliminate the "reboot" requirement there) <mark_weaver>yenda: did you read my last message? 'guix' doesn't copy your config file anywhere. if you didn't save it somewhere that you can get it now, then that config file is lost. <yenda>mark_weaver: yes but I'm not sure I understand, my config file is in /mnt/config.osm it's saved on the harddrive <mark_weaver>yenda: ah, okay. so I guess I don't understand your question "how do I extract it from the system ?" <yenda>mark_weaver: yes my question was poorly worded, and yes that's what I meant <mark_weaver>well, I guess copying it to a USB drive would be one way. <mark_weaver>and to capture the output of 'guix system init', I would run the "script" command. <mark_weaver>so you run "script <filename>" from a shell, and that spawns a subshell. everything in that subshell is saved to the file until you quit the subshell. <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, davexunit says: you forgot the patch that goes with the CRDA package, which prevents me from reconfiguring my system. <civodul>i was so happy to be done with that CRDA thing ;-) <civodul>yes, something to display good faith wrt. respecting local frequency regulations <cirno9>now I got lsh starting on boot and im able to ssh in from another computer! <civodul>davexunit: BTW, did i do the right thing wrt. #:gem-flags? <davexunit>pjotr apparently wasn't aware that I was AFK this week <davexunit>I've spent a good portion of my day figuring out how to compile some firmware for an AVR device of mine. our AVR toolchain is messed up. <civodul>mark_weaver: yes, i'll look into that <mark_weaver>In file included from ../../../../gcc-4.9.3/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:20:0: <mark_weaver>../../../../gcc-4.9.3/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:257:72: error: size of array ‘assertion_failed__70’ is negative <mark_weaver> typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] <civodul>mark_weaver: what was the problem with ninja's build system? <mark_weaver>civodul: sorry, I didn't investigate, I only observed that it worked when I avoided 'patch-and-repack'. <mark_weaver>I guess my thinking was to get core-updates merged soon, and more proper fixes to the build systems could be done later; or alternatively, that 'patch-and-repack' could be made to mostly preserve the timestamps. <davexunit>avr-ld: skipping incompatible /gnu/store/icsmkqdzhrg6dfjadn02mxrsfl8jlb7c-avr-libc-1.8.1/avr/lib/libm.a when searching for -lm <civodul>mark_weaver: getting it merged soon is indeed a worthy goal :-) <civodul>i was just surprised that this could confuse the build system, but no big deal <mark_weaver>yes, I'm surprised how many build systems are unable to cope with zeroed source timestamps. <mark_weaver>if we had the ability to make a deterministic clock within the build container, that would be very helpful. <mark_weaver>the hurd would be a much better fit for guix-daemon's needs. <mark_weaver>maybe some day we can patch our linux to support some of these things (assuming they're not already supported) <civodul>i'm not sure what "deterministic clock" could mean <civodul>some people talk about using 'faketime' <mark_weaver>yeah, I'm not exactly sure how it would work either. in the absence of parallelism, a deterministic clock could start at a fixed value and advance by a fixed amount on every query. <rekado->portaudio doesn't seem to work with JACK even though it's built against jack-2. <mark_weaver>but it might be better to just fix all the build systems to cope with zeroed timestamps, if there aren't too many of them. <rekado->I think that's a problem; it should be built against jack-1. <civodul>rekado-: you're the expert on that :-) <civodul>mark_weaver: yes but we need to understand why they can't cope with zeroed timestamps <rekado->rebuilt portaudio with jack-1, (and rebuilt jack-1 to propagate "bdb"), and now it works. <davexunit>phant0mas: hey, I noticed that you were the one that added avr-libc. did you happen to successfully build any AVR firmwares using a guix-built toolchain? <civodul>mark_weaver: the failed assertion is: COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat)); <civodul>and ...limits.h does: struct_kernel_stat_sz = 64; <civodul>mark_weaver: can you check in gdb on arm if that is correct? <davexunit>phant0mas: all of my builds fail during the linking phase, when avr-ld spits "skipping incompative <file-name> when searching for -lm" messages <civodul>davexunit: you should check 'file .../faulty/libm.a', to make sure it really contains AVR objects <davexunit>civodul: I'm trying to learn how to know that <davexunit>I've never had to inspect a binary this closely <davexunit>'avr-nm .../fault/libm.a' outputs a bunch of stuff <civodul>just 'mkdir t; cd t; ar x ../libm.a; file *.o' <phant0mas>hey davexunit, I haven't used it for some time now, but I remember building AVR firmwares succesfully when I packaged it <davexunit>phant0mas: for context, I'm trying to compile the firmwares for my custom arcade controller, and I'm preparing patches that expose public packages for avr-gcc and avr-binutils <davexunit>civodul: file reports "ELF 32-bit LSB relocatable, Atmel AVR 8-bit, version 1 (SYSV), not stripped" for all files <paroneayea>now I can show off guix while at OSCON to people! <yenda>In ./gnu/nuilf/linux-boot.scm: 403:35 1 (#<procedure 2b272a0 at ./gnu/build/linux-boot.scm:369:3[square]>) <civodul>paroneayea: any plans to give a talk? <paroneayea>I'm there for other reasons this year but I'm not supposed to say yet :) <yenda>(it's copied manually the [square] is a square symbol <yenda>it worked fine after reboot though <civodul>yenda: are you trying to install 0.8.2, or from master? <yenda>I'm installing from the distro available on the website so 8.2 <yenda>the manual on tty2 is brilliant idea <civodul>i'd seen it in nixos, and i think it's handy indeed <civodul>the backtrace corresponds to a failure in mount-root-file-system <yenda>civodul: yes, do you think it's hardware ? <civodul>probably not, but without more details it's hard to tell <civodul>yenda: if that happens again, it would be good to try ",locals" as well, to see the value of locals vars <civodul>maybe we could debug interactively on IRC, even <yenda>civodul: ok thanks, atm I'm trying to install again because last time I had an EOF error with guix system init <phant0mas>rebased wip-hurd on core-updates fails to build on gcc-cross-i586-pc-gnu-4.9.3 with gcc-4.9.3/libcilkrts/runtime/os-unix.c:386:2: error: #error "Unknown architecture" <mark_weaver>phant0mas: one new change in core-updates is that --build=<triplet> is passed to ./configure in the default 'configure' phase of gnu-build-system. <mark_weaver>phant0mas: where <triplet> defaults to (nix-system->gnu-triplet (%current-system)) <mark_weaver>you can override the value of <triplet> by including #:build <triplet> in the package 'arguments', or inhibit passing --build by including #:build #f <mark_weaver>but maybe --disable-libcilkrts is the right thing here <civodul>normally passing --build should make no difference here <civodul>mark_weaver: could you check sizeof(struct stat) on armhf? <mark_weaver>(I installed guix from scratch when I replaced my Novena's hard drive) <mark_weaver>civodul: btw, what's the easiest way to do that? just run gdb on some random executable, and put a breakpoint in some file that included stat.h? <civodul>mark_weaver: actually it might be easier to compile a program that does printf ("%i\\n", sizeof(struct stat)) <civodul>now qt-5 fails with: ninja: error: '../../../src/3rdparty/chromium/tools/json_schema_compiler/util.cc', needed by 'obj/src/3rdparty/chromium/tools/json_schema_compiler/api_gen_util.util.o', missing and no known rule to make it <civodul>but at the beginning of the log, that file is unpacked as expected <mark_weaver>civodul: on GuixSD armhf from core-updates, sizeof (struct stat) is 88 <yenda>mark_weaver: I retried the install from scratch, it's taking way longer than previously so I guess the error is gone <civodul>mark_weaver: does that natively-built gcc-4.9.3 on armhf include asan? <civodul>i would expect the same problem to arise when compiling natively <mark_weaver>civodul: what do you suppose is the best way to find out? i could look at the build logs. <civodul>mark_weaver: you could check the libraries available in the "lib" output <mark_weaver>and I can also see where it compiled the same file that failed in the cross build (sanitizer_platform_limits_linux.cc_ <civodul>another possibility is that my "fix" in cross-base led to a confusion between the native and the target linux-headers <yenda>mark_weaver: taking forever though <mark_weaver>yenda: did you enable binary substitutes from hydra.gnu.org? <yenda>mark_weaver: looks like its compiling from scratch indeed. I used the command in the manual <mark_weaver>yenda: so hydra's key is in /etc/guix/acl on the system that you run 'guix' from? <yenda>mark_weaver: I ls into /etc/guix/acl there is nothing