<fps>about this whole guix pull thing: when i cloned guix i wondered already why the package definitions were part of the tools source <rekado>that's a feature. Packages are just scheme values, so we can treat them like any other scheme value. <taylan>fps: it prevents backwards compatibility burden. if a new guix version slightly changes the package definition syntax, it can just update all relevant package definitions in the same commit. <fps>taylan: wouldn't API versioning solve that? ***C_Keen is now known as C-Keen
<fps>rekado: a scheme program is also just computes scheme values. no need to bundle it with scheme ;) <taylan>sounds like burden :) maybe after 1.0 something else can be done, dunno. not really necessary though. <fps>isn't that the source of the hash dilemma i talked about with davexunit yesterday? <fps>i'm still poking around. so forgive my ignorance.. <taylan>fps: if you mean the problem with guix not being able to package itself (i.e. the same version), that wouldn't really be solved; you'd have the same issue with the package database (unless you don't make that a guix package, but you probably want to) <rekado>fps: oh, I misunderstand what you were trying to say. <taylan>but I guess it would allow for a bit more granularity in how to handle the issue. currently we somehow need to special-case the whole guix package to work around that problem; if it were separated we'd only need to special-case the package-database package. <efraim>i ran `time guix pull` last night after I went to bed and it took 80 minutes <fps>efraim: precisely why i wonder about this whole thing ;) <fps>i'm also still confused about this "bootstrapping" issue davexunit mentioned yesterday. <fps>the question i asked why it wouldn't be possible to ship a substitution of the result of guix pull via hydra <fps>i'm still not 100% certain that i grokked the problem with that.. <efraim>i think that one came out to how much trust we put in hydra <efraim>and i didn't fully understand why we couldn't do deltas <fps>efraim: the trust issue is solved by having the user be able to verify hydra's substitution himself if he so desires <fps>the same as with all other binary substitutions: if you don't trust hyra, rebuild from source and compare hashes <fps>there was another point about different guix versions producing different hashes for the same binary build <fps>i suppose i don't understand how that comes to be.. <efraim>different input values from the different starting hashes of the guix binary? <fps>just to clarify; let's say i have two guix versions with an identical package definition for package foo <fps>the guix versions differ somewhere else, but the binaries produced for foo are identical <fps>how does the difference in hash creep in? <fps>are the hashes seeded by the hash of guix? <fps>if that were so, the chain of trust [ala blockchains] would already be built in in some sense.. <fps>or is it just that store paths are baked into the binaries and that's what causes the difference in the foo binary outputs? <fps>damn, need to shower.. brb <taylan>splitting the package database wouldn't help all that much with 'guix pull' time because most of the time is spent on compiling the package modules <taylan>you would only be saving the time associated with building the non-package bits of guix, which isn't that short either, but only a fraction of the total time <fps>taylan: but you coud ship a binary substitute for the compiled package definitions, no? <fps>even if you couldn't substitute guix itself <efraim>can the compiling part of guix pull be offloaded like in guix build <taylan>fps: no, because the client would need to know of the package first, but the client has an older package database which couldn't possibly contain a newer package database as a package <taylan>one might be able to solve that problem by creating a special-case substitution functionality just for the package db, so that it doesn't need to be known by the client as a package in their db. but then the same could be done with the whole guix package, so that's kind of orthogonal to whether the tool and package db are split or not. <fps>just a random ill-conveived thought: what stops a commiter to the guix repo from putting in the compilation products, too? <fps>[assuming there's only a single target architecture] <fps>damn, i shouldn't have started this subject when i have to leave so soon :( <fps>[compilation products -> .go files for package definitions] <civodul>efraim: yes, offloading works for all derivation builds <fps>then a guix pull just pulls in all the .go files, too.. not a practical idea for obvious reasons, <fps>but maybe the reason this cannot work can lift my confusion a bit more <fps>taylan: i see your point about one special package in that case, yes.. [substituting the package definitions as their own package] <fps>still i wonder about putting the .go files into the repo [as a hack to make guix pull quicker ;) and as illustrative thought experiment] <civodul>but don't worry about 'guix pull', there are better options to try out :-) <fps>civodul: it's an interesting question though. but i have to run anyways.. ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.9.0 is out! | FOSDEM: https://lists.fosdem.org/pipermail/fosdem/2015-October/002273.html | https://libreplanet.org/wiki/Group:Guix/TalkProposals | This channel is logged, see <https://gnunet.org/bot/log/guix>.'
<civodul>it's official, 0.9.0 is out now! :-) <civodul>ACTION will post the announcement on the blog ASAP <toothbrush0>Would i be stepping on any toes if i submit the 0.9.0 release news to Hacker News? <civodul>i guess davexunit would do it when he wakes up, but it's probably fine if you do it <toothbrush0>and perhaps it's best to do that when the US has woken up anyway <toothbrush0>i guess it's unavoidable that the 0.9.0 version when doing `guix system reconfigure` wants to pull in and *build from source* guix-0.8.3.5d09263.drv? <toothbrush0>and last night, on my VM, it failed the tests after building :( <toothbrush0>but because i didn't think to add --keep-failed i cannot look at the log, i think :( <Gxsdnewb>Back to finishing bootstrapping! Still booted in live usbmode. <rekado>oh, sorry, I just submitted to HN when I read the email and saw it's not on HN yet. Didn't check IRC first. <Gxsdnewb>I ran guix build xfce over the night, which installed it and all xorg deps etc. into the live env /gnu/store but not my installed system at /mnt <rekado>did you start the cow-store service? <rekado>and why did you boot the live medium again when the system had already been installed? <Gxsdnewb>should i just add xfce to (use-package-modules admin xfce) in my system.scm and rerun guix system init system.scm /mnt ? <Gxsdnewb>rekado: the cow-store has been on this whole time <civodul>toothbrush0: the 0.9.0 GuixSD image wants to build Guix 0.9.0, literally <civodul>and substitutes for that are available on hydra.gnu.org, i think <toothbrush0>hm, the first bit makes sense then, but the substitutes aren't found by my version <toothbrush0>argh, and i'm struggling with w3m which seems to have /usr/bin/vi hard-coded :/ <Gxsdnewb>I see all of the derivations and compiled packages in TMPDIR as well as the live system's /gnu/store/ but not the installed system's /gnu/store/ <civodul>toothbrush0: maybe you were using 0.9.0pre or something? <Gxsdnewb>rather they are missing from /mnt/gnu/store <civodul>toothbrush0: that one couldn't use 0.9.0 since it wasn't released yet, but still, i guess this shouldn't have failed <civodul>toothbrush0: and you reported success with 0.9.0pre yesterday, no? <toothbrush0>well, success until i wanted to do `guix system reconfigure` <toothbrush0>but even so it wanted to rebuild a bunch of things (including dmd, sudo, xlock, etc) <civodul>it could be that some substitutes were missing from hydra at the time <toothbrush0>"at that time" is still true this morning, mind you ;) <Gxsdnewb>i guess i should not run guix system reconfigure while still in live usb boot? <rekado>"The future is what we make it" <-- +1 <civodul>it seems a lot of the software community is just sitting there and watching <civodul>whereas free software is about building things <Gxsdnewb>guix system init does not install xfce/xorg packages when i write (use-package-modules admin xfce) <rekado>Gxsdnewb: this just makes the package variables available. <civodul>also available on tty2 on the installation image <Gxsdnewb>right, sorry, i just can never get the packages section onf the maschine scm to work <Gxsdnewb>this makes guix system fail with the wrong number of arguements <civodul>yes, please check how the examples above do it :-) <Gxsdnewb>and why does the desktop example install ratpoison? does xfce not install a wm? <taylan>civodul: I sorta kinda got gnu/packages/*.scm to build in 2 minutes, but my solution may be too hacky to be acceptable. it does (load-compiled go-file) for each .go file it writes, to work around the issue you had explained. <civodul>taylan: so it relies on auto-compilation, right? <civodul>that's an acceptable hack for that reward <toothbrush0>taylan: that's great, my electricity bill thanks you :P <taylan>make -j4 with the old makefile took about 15 minutes <taylan>anyway, will post on the ML so we can see how to maybe clean it up a bit (I'm a total Makefile noob) <civodul>taylan: this should go in build-self.scm first (the thing that is used by 'guix pull') <Gxsdnewb>wkarhunguixi: are you around? i would be very greatful to see your libreboot grub conf for booting guixsd <rekado>"guix system {vm,container}" both complain about wrong number of arguments, but appending "--help" doesn't tell me what arguments they take. Instead the generic help for "guix system" is shown. <wkarhunguixi>Gxsdnewb, i don't have it on this computer. But i just have Libreboot decrypt the partition and then switch config file <wkarhunguixi>Gxsdnewb, i use "cryptomount <partition>" (without parentheses), and then "configfile (crypto0)/boot/grub/grub.cfg" <toothbrush0>RFC: w3m turns out to require setting --with-editor=.. at configure time <toothbrush0>should i perhaps add nano or something as a dependency? that's really ugly though :/ <toothbrush0>or somehow write a patch to respect the $EDITOR environment variable... <wkarhunguixi>Gxsdnewb, it should be possible to skip the second configfile, but i'll do it like this until i'm more comfortable with GuixSD. <Gxsdnewb>wkarhunguixi: so when you generated the system, wahat did you put in the scm for the bootloader line? with encrypted /boot then guix system fails, so i ran it with the --no-grub switch <Gxsdnewb>wkarhunguixi: so your entry in libreboot only decrypts an loads a grub.cfg on a grub installation in guixsd? <wkarhunguixi>Gxsdnewb, I wanted grub.cfg generated, but not GRUB installed. So, I put in something the script accepted (i used a partition). It would then configure the system, generate grub.cfg, but fail at installing GRUB. Which worked out fine for me. <wkarhunguixi>Gxsdnewb, yes. It just hands the process over to the GuixSD grub.cfg <Gxsdnewb>wkarhunguixi: okay, but your guixsd grub.cfg does not need the insmod luks and cryptmount lines, you just use it as exactly generated by guix system? <rekado>toothbrush0: IIRC visudo also has a path hardcoded. <civodul>it would make sense to remove visudo since it is not sensible on GuixSD <Gxsdnewb>wkarhunguixi: thank you! i can boot into GuixSD now and i get to the 2nd passphrase entrypoint <wkarhunguixi>i haven't looked into having the GuixSD boot process use the LUKS passphrase from a file yet, and thus avoid typing it twice. But i think this should be possible. <Gxsdnewb>Now my installed GuixSD has device-mapper errors <Gxsdnewb>oh i forgot to add cryptmount to the grub.cfg on disk <davexunit>nice to wake up to a release announcement on the HN front page. <Gxsdnewb>Yes, congratulations to all who contributed to this release! <Gxsdnewb>Yes i cannot decrypt unfortunately. device-mapper: table: 253:0: crypt: Error allocating crypto tfm <Gxsdnewb>device-mapper: ioctl: error adding target to table <Gxsdnewb>device-mapper: reload ioctl on failed: No such file or directory <toothbrush0>silly question perhaps; on a GuixSD system, how can i do the equivalent of `guix pull` but from my local, modified, git checkout of guix? I've done `sudo make install` but that doesn't seem to do the trick. <paroneayea>toothbrush0: you probably want to go the route of "run guix from git" <toothbrush0>paroneayea: thanks! I was a bit silly, i just needed to do ./pre-inst-env guix system reconfigure .. to be able to use my locally-defined package in my system-wide config. <toothbrush0>does anyone here use XMonad on GuixSD? Because i'm having trouble using modules from ghc-xmonad-contrib <taylan>civodul: a comment says consuming memory proportional to the number of modules is unacceptable. I observed how much it consumes and it reached around 225MB at the end. is that really too much? <taylan>if so, I guess we could split the files into groups of n for some value of n, thus still keep most of the benefit <taylan>to clarify, I'm talking about the comment in guix/build/pull.scm, above the final p-for-each <civodul>taylan: we'd need to compare to a sequential build of a single file <civodul>the comment there is about an earlier attempt to build sequentially and in a single process, but in a way that wasted lots of memory <davexunit>he did a good job since we're on the front page with over 100 upvotes <davexunit>probably the best a guix release announcement has ever done <civodul>rekado: Guix won't be ported to MacOS, i think <sirgazil>Thank you all for working on the project. I'm glad about the new release <paroneayea>civodul: btw, any thoughts on why OSX does not seem likely? <paroneayea>is it mostly because the Guix world is not interested in porting? <civodul>paroneayea: porting is a *lot* of work <civodul>glibc doesn't work on OSX, so we'd need a separate libc <civodul>and it's not even clear that OSX's libc can be built from source <civodul>it just uses the available compiler and libc <paroneayea>civodul: huh, I didn't know glibc doesn't work on OSX <davexunit>I've come to learn that there's lots of cheating in nixpkgs <paroneayea>davexunit: yes seeing the jquery example on Nix made me question how much you can truch Nix's reproducibility promise <kmicu>paroneayea: Parts responsible for ‘reproducibility’ are the same for Guix and Nix; it would be useful to know why you are saying something is different? In that blog “Nix just downloads the prebuilt binary and installs that” sentence refers to .js text file… and how that even affects reproducibility if hash must be correct? <paroneayea>kmicu: I mean that it can be built reproducibly, from source <civodul>kmicu: paroneayea was referring to this part of the post, i think: “Nix just downloads the prebuilt binary and installs that, which in the world of functional package management is kind of like saying "fuck it, I'm out."” <paroneayea>and here, in Nix, there is no building from source <civodul>i think kmicu thought you were referring to Nix-the-package-manager <paroneayea>in Guix we kind of mix the packages right in so ;) <wkarhunguixi>Gxsdnewb, your cryptomount looks wrong to me. I'd expect ahci0,gpt1 or ahci0,msdos1 <Gxsdnewb>wkarhunguixi: strange, ahci0,1 worked in libreboot's grub... but to be safe i also tried ahci0,msdos1 and it did not work <Gxsdnewb>I get dropped to a scheme@(guile-user) prompt which i do not know how to use <wkarhunguixi>I got dropped to that prompt when i was on unmodified 0.8 <Gxsdnewb>Well, i installed from 0.9.0pre but then i had to guix pull in the live env in order to install <Gxsdnewb>then i noticed that the guix-master dir did not copy to the cow-store, so the installed version of guix itself is 0.8.3 with another version string after <francis7>Gxsdnewb, probably because you were using gpt partitioning instead of mbr partitioning <francis7>X is better, since it means grub will work with that partition whether it's mbr or gpt <Gxsdnewb>after all of the device-mapper errors it gives the errors: <francis7>this is why libreboot doesn't assume anything, and just does ahci0,X <wkarhunguixi>(here's a way to upload config.scm with curl: curl -F 'sprunge=@/etc/config.scm' sprunge.us ) <Gxsdnewb>francis7: but my ssd uses mbr and not gpt.. i used fdisk to make a fresh msdos partition table before install <Gxsdnewb>francis7: anyway i do not think the problem is libreboot, because with manually inserting insmod luks and crytptomount ahci0,1 it works great to find the libreboot-grub.cfg that is on the disk <wkarhunguixi>and i assume GuixSD's GRUB should understand that format as well. (It was unknown to me) <Gxsdnewb>the kernel in GuixSD loads and it asks for my crypt passphrase a second time, but something about my GuixSD config has a nonfunctional device-mapper <Gxsdnewb>The guix version on my install is ...-guix-0.8.3.b485f75 <Gxsdnewb>Could that be causing a device-mapper failure? my kernel is ...-linux-libre-4.2.5 <wkarhunguixi>i have specified file-system title, that's the only thing that i can spot. I have (title 'device), but i believe it's default. So, it shouldn't matter <wkarhunguixi>Gxsdnewb, it will explicitly enable the necessary crypto modules. <wkarhunguixi>maybe there's an issue because you use the barebone config, i don't know. <wkarhunguixi>Gxsdnewb, or maybe you could replace your use-modules line with that from the desktop config, (use-modules (gnu) (gnu system nss)) <taylan>'./pre-inst-env guix pull' doesn't seem to use my modified guix/build/pull.scm, what am I doing wrong? <taylan>oh, build-self.scm is used literally to build the tarball itself if I'm reading this right O_o <davexunit>but you can give a file:// URI or something with your tweaked code. <taylan>yeah... or I could just run build-self.scm manually maybe <Gxsdnewb>hrmm i tried putting the 0.9.0 usb image on my usb stick but can not boot from it due to ERROR: In procedure open-file: No such file or directory: "/gnu/store/xl9cf...-activate" <taylan>Sleep_Walker: seems you're missing the json module... <civodul>it was meant to be an optional dependency though <taylan>civodul: what's the easiest way to test a modified guix/build/pull.scm? <civodul>taylan: ./pre-inst-env guix pull --url=file://$PWD/foo.tar.gz <civodul>but beware, it’ll modify ~/.config/guix/latest <taylan>civodul: foo.tar.gz is the result of 'make dist'? <Sleep_Walker>civodul: in that case I'm afraid it is not optional - it failed this way even though guile-json was not found ***jonsger1 is now known as jonsger
<Gxsdnewb>nevermind, i reflashed the usb and it works <Gxsdnewb>civodul: trying to run guix challenge on live usbenv, for example guix challenge sqlite <Gxsdnewb>But it reports no local build for /gnu/store/ygg5...-sqlite-3.8.11.1 <Gxsdnewb>Is this warning because this package was not compiled locally? <Gxsdnewb>otherwise, guix challenge bzip2 reports the same warning but with a different hash than exists on the usb 0.9.0 usbimg <taylan>Gxsdnewb: AFAIUI, yes, guix challenge requires you to have a locally built version, and then compares that to what the server provides <Gxsdnewb>So how does guix challenge work exactly? It checks the hash of the most recent build on hydra, so if there is a new version on hydra then those with 0.9.0 packages have no way to challenge if there is an update? <taylan>well, one might expect it to just do the local building when it wasn't already done; or maybe there's a CLI switch to enable that? <taylan>nope, seems pretty barebones ATM <davexunit>Gxsdnewb: not the most recent build, but the precise build corresponding to the hash of the package. <Gxsdnewb>what data does guix use to determine if a package was compiled? <davexunit>Gxsdnewb: if a store item exists for the package, a directory in /gnu/store <taylan>davexunit: but substitutes also land there. I'd guess it checks for a derivation file or so? (to this day I don't know what exactly derivation files are.) <davexunit>taylan: yes, there's a trick that civodul used to determine if something was substituted or not. <civodul>taylan: ‘guix challenge’ checks whether there’s a build log locally <civodul>if there’s one, it assumes it’s a local build <Gxsdnewb>civodul: so it checks the derivation file, looks in the appropriate directory in /var/log/guix/drv/ to find a build log, and if it is there it will not give this warning? <civodul>remi`bd: i autotoolified your GNUnet bindings <civodul>remi`bd: there’s a couple of test failures (“make check”) due to a syntax error of ‘test-error’ (SRFI-64) <civodul>seen on HN: “GNU seems like the China of software. They write their own version of all existing tools, simply so they can have a copy of it that completely adheres to their principles.” <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs <davexunit>civodul: rolled my eyes at that comment awhile ago <rekado>I typed out a reply three times and removed it again. <Gxsdnewb>So does guix-daemon delete the tmpdir used for compilation even when --gc-keep-outputs=yes ? <Gxsdnewb>I had a log of compiled data and source tarballs in that dir and i rebooted and it is empty :( <Gxsdnewb>does that happen during startup or shutdown, and where can i change that behavior? <civodul>currently it’s hardcoded but we could change that ***Steap_ is now known as Steap
<Gxsdnewb>when running guix system init with --no-substitutes, is there anywhere else guix checks to see if it should rebuild a package besides /var/log/guix/? <Gxsdnewb>or both guix system and guix challenge look exclusively in this specific log dir *only*? ***francis7 is now known as aoeuidhtns
***aoeuidhtns is now known as francis7
<fps>btw: does guix pull check if it needs upgrading at all first? <Gxsdnewb>Anything i modify it gives me ice-9 end of file error <serhart>Looks like you are forgetting about 3 closing parens at the end of the file <alezost>Gxsdnewb: yes, missed parentheses; also you shouldn't use %desktop-services before (modify-services %desktop-services ...) <alezost>also tcpdump is from (gnu packages admin) module which is not used <octe>i installed guixsd and used the desktop configuration example which created a user, but did it specify a password? can't remember seeing one <alezost>Gxsdnewb: also if you are not comfortable with scheme, I would suggest to use an existing example (desktop or bare-bones) for 'guix system init'; and when you'll have a working system then you may modify your config and use 'guix system reconfigure' <alezost>octe: last time I tried, you have a root without password <serhart>octe: you need to use the passwd command as root <octe>heh, windowmaker, the nostalgia :) <paroneayea>always feel good after submitting another package <paroneayea>ACTION notices that gtk icon cache things run after installing some things now <__night__>Hi! Everyone! I'd like to know is there anybody tried gnu guix on arm device? <avoine>not yet but I have a imx6 I could use <__night__>Ok. Well, would it be difficult to port it to arm? <davexunit>and we have machines that build binaries for ARMv7 <bavier>note that guixsd doesn't yet run natively on arm <__night__>Sorry, haven't seen them on the site. Could you provide some links? <avoine>what would be the best way to test patches to guix before sending them? <avoine>I have modified .config/guix/latest to be a symlink to my git repos, compile everything <avoine>but ./pre-inst-env guix environment [...] give the error: substitute: error: executing `/usr/local/libexec/guix/substitute': No such file or directory <detrout>I think I have successfuly made a guix package. <detrout>can i submit it somewhere and not commit to supporting it? <detrout>probably the person managing the bioinformatics tree <bavier>detrout: send it to the mailing list <fps>hmmm, i should, in principle, be able to dd the contents of my qemu qcow2 image (connecting to it throut qemu-nbd) to a usb stick and boot the sucker? <fps>to test it on bare metal? <fps>hmm, ok, not quite so easy <fps>[ 1196.823019] sdg: detected capacity change from 32015679488 to 0 <fps>i wonder how that came about ;) <fps>sudo modprobe nbd max_part=8 <fps>sudo qemu-nbd --connect=/dev/nbd0 guix-0.9pre.qcow2 <fps>that should give me the qcow2 image as block device <fps>sudo dd if=/dev/nbd0 of=/dev/sdg bs=80192 <fps>sudo dd if=/dev/nbd0 of=/dev/sdg1 bs=8192 <fps>that maybe did work. let's see <fps>ok, i can convert it to a raw image with qemu-img. awesome <fps>oh and even simpler qemu-img guis.qcow2 -O raw /dev/sdg <fps>let's see if that works.. <fps>no wifi, of course ;) <fps>ok, partial success i'd say.. <fps>civodul: um, i had a 0.9.0pre image, that i guix pull'ed sometime this day <fps>guix reports version 0.9 <fps>i just dd'ed to a usb stick and booted it in my laptop <fps>civodul: ok, i was imprecise again: 1] install 0.9pre onto a qemu, 2] guix pull'ed sometime this day 3] dd'ed it to my usb stick 4] booted it <fps>wireless is intel wireless-n according to lspci <fps>i do have ethernet cables lying around though <civodul>fps: yeah for wifi you'll need something for which free drivers and firmware exist <fps>hmm, this mentions wireless-n <fps>maybe not that particular model <arianvp>yo guys =) Is there an iso image available for guix? I've succesfully booted the image with -usb -usbdevice flags in qemu, but I'm now trying to boot it using virt-manager and libvirt which doesn't allow me to set this option. Only a Disk image <fps>arianvp: i guess you can convert it to qcow2 <fps>i just did it the other way around ;) <fps>qemu-img convert guix-0.9pre.qcow2 -O raw guix-0.9pre.img <fps>should be possible to do it the other wa around.. <fps>arianvp: but the image you downloaded is just a raw disk image.. <fps>arianvp: so you should be able to use that in libvirt.. <arianvp>it's saying "Failed. no bootable disk" <fps>arianvp: what image formats does libvirt support? <fps>hmmm, i wonder if it's worth the effort of forking guixsd to support non-free stuff ;) but i suppose this is not the right channel to even mention that ;) <avoine>I'm done with the btrfs-progs package, but I still have the error with fsck.btrfs not being found at boot. Maybe it needs to be in the initrd? <arianvp>Hmm. it's complaining Could not read from CD-ROM (code 0004) <fps>arianvp: it's not a cd image.. it's a disk image.. <fps>arianvp: cd's work differently iirc.. <fps>arianvp: so you should be able to attach two virtual disks to your vm, one being the target disk image and the other being the guixsd image <avoine>yeah you need to use mkisofs and have boot loader, etc <arianvp>fps: okay that worked.. sort of. I got grub menu <arianvp>but getting error "device /dev/vdb1 not found" in guix <arianvp>"Waiting for gnu-disk-image to appear" <fps>arianvp: you could also just do qemu -hda target.qcow2 -hdb guix-image -boot menu=on -m 4096 <fps>install it to your qcow and then use that in libvirt <fps>make sure to press f12 and select disk 1 and not disk 0 <arianvp>fps: yeh. I did It got into Guix's grub <arianvp>it then boots and complains /dev/vdb1 is not found and halts <fps>if you do it that way, the target will be /dev/sda1 <fps>did you run qemu-kvm like i wrote? <fps>then mkfs.ext4 -L root /dev/sda1 <arianvp>no no this was still in libvirt. lemme try qemu-kvm <fps>copy over a config and change sdX to sda <fps>and then install [deco start cow-store /mnt/config.scm /mnt <fps>and then install [deco start cow-store /mnt] <fps>and guix system init /mnt/config.scm /mnt <fps>something like that.. <fps>oops, also forgot to mount /dev/sda1 to /mnt and fdisk, but you caught my drift i suppose <arianvp>(qemu booted) time to install to the qcow image <fps>oh possibly booting the resulting installed target disk might fail in libvirt, since it's then not sda anymore.. <fps>but that depends on libvirt settings which i'm not an expert in at all <Gxsdnewb>it seems that guix system init is not scanning /mnt/gnu/store for packages with the same hash that already exist on the target to install to. <arianvp>I wanted to install it on my laptop first. But then I need a nonfree kernel first because my laptop is horrible and wasn't sure how to do that. <arianvp>so now running in a vm instead. Really like guix so far for what I've read <fps>guixsd is very gnu... <fps>which is good and bad :) <arianvp>I'll have to dig in to guile a bit. I guess i can probably write a package for linux-nonfree. <arianvp>yeh I like that it's GNU. I just need a more GNU laptop <fps>no wifi for me, showstopper for a bare metal install <arianvp>yeh I got an intel wifi card. those tend to not work without blobs right? <fps>there's some that do have free drivers <fps>that lists 2230 though <fps>not sure why it's not supported in guixsd <fps>not sure.. maybe there's a reason that iwlwifi is not shipped with it <fps>i just modprobe'd it in qemu <fps>let's boot the lappy again <arianvp>wait are you telling me I can run linux-libre on my laptop? awesome <fps>also i have wireless-n 2230 <fps>ooh, maybe it needs a blob <fps>modprobe'd it and iwconfig still shows no wifi devices <avoine>anyone else have a file named "[" in profile/bin/ from coreutils? <fps>arianvp: i think you need firmware blobs <fps>arianvp: no idea if it's possible to just download it and then make it work.. if you figure out, how, let me know <karhunguixi>avoine, there's [, [[, and 'test' that does roughly the same thing <fps>yeah,some shells might not have [ as built in? <fps>arianvp: ifconfig -a <fps>then ifconfig your_interface up <fps>then dhclient your_interface <arianvp>wait I need to add a network device to qemu first I think <fps>qemu-kvm worked out of the box for me with that.. <fps>it has a default network adapter [possibl NAT'ed?] <arianvp>forgot to use kvm. explains why it was so sluggish. hehe <arianvp>oh noes. there is no vim on the installer image.I feel handicapped <fps>if i understand it right you should be able to install it with guix -i vim maybe <brainproxy>rekado: thanks for your replies on HN :-) re: guix <brainproxy>I barely know anything about it, just so busy, trying to ask the "right questions" to see if it's something I should spend time investigating <davexunit>let us know what was good and what sucked. ;) <paroneayea>we should try to get some guix talks into the distro room as well <paroneayea>spread the guix mindshare beyond just the guix room <davexunit>hopefully civodul will be proposing a talk in the distro room? <civodul>i agree we have to be present in other rooms <civodul>though it would be the third time in a row in the distro room <civodul>maybe i need to find another room now? ;-) <brainproxy>davexunit: i would be very interested in being able to use the guix command-line clients on my mac, directly, with the daemon running on a linux host <brainproxy>that's how I presently use docker-machine, docker-compose and docker client command-line tools <paroneayea>maybe rekado could give a talk at the "HPC, Big Data and Data Science" room <arianvp>oh oh I'm getting a lot of errors :( <arianvp>"Failed to create path for auto-compiled file" <fps>oh is that the 0.8.3 image still? <davexunit>brainproxy: that would be interesting. how do you envision such a setup working? would you create the VM or would you expect a guix program to do it? ***aeva` is now known as aeva
<davexunit>there's a bootstrapping problem in the latter case, but it could be done somehow. <arianvp>I downloaded it yesterday. didnt know there was a 0.9 release coming :P <davexunit>and if that's the flow that docker or a similar tool uses, then we should try to meet that level of ease. it's just hard because we can't use any of our package builds because we have no OS X port. <brainproxy>davexunit: well, w.r.t. to my current dev and ops workflows, I used docker-machine to spin up VMs under virtualbox running on my mac -and/or- on hosting providers like Amazon, Rackspace, DigitalOcean <brainproxy>I don't have to think about it, docker-machine just spins up a linux host that is purpose-built to run the Docker daemon <davexunit>is there a fully free virtual machine platform available for OS X? <brainproxy>what's the stance on such a hypothetical "system vm" client spinning up a vm on a hosting provider like Amazon, et al. <keverets>the kernel (Darwin?) used to be open, but I don't think that's the case anymore <davexunit>brainproxy: I am (slowly) working on a 'guix deploy' tool, and I intend to add support for private cloud APIs for which there are fully free software platforms. <brainproxy>installing qemu on os x is as easy as `brew install qemu` <davexunit>OpenStack and Eucalyptus come to mind. those are self-hostable. <davexunit>so an OpenStack and EC2 client would be needed. <davexunit>tl;dr - I would support the EC2 API, but we would *not* bake in anything that recommends AWS <brainproxy>right, so I'm only pointing out by analogy, not trying to attract people to docker, it's just what I use/know <brainproxy>but docker-machine has a pluggable "driver" architecture <arianvp>I'm actually buying some libreboot server motherboards soon <davexunit>brainproxy: we can talk more at another time <arianvp>so maybe I'll be a free provider really soon :P <lfam>The only file in /root/.guix-profile/sbin is guix-register. Do I need that on root's PATH? <lfam>It's not mentioned in the manual, but it was described as an "internal command" in the Guix 0.8 release announcement. I'll use the source if necessary but it would be good to have some advice :P <civodul>lfam: it's indeed an internal command, you can ignore it