IRC channel logs


back to list of logs

<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
<civodul>'lo Guix!
<taylan>hi :)
<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>fps: it's not an option
<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 | | 0.9.0 is out! | FOSDEM: | | This channel is logged, see <>.'
<civodul>it's official, 0.9.0 is out now! :-)
<civodul>ACTION will post the announcement on the blog ASAP
<toothbrush0>Hey Guix!
<toothbrush0>Would i be stepping on any toes if i submit the 0.9.0 release news to Hacker News?
<civodul> is the link to submit
<civodul>i guess davexunit would do it when he wakes up, but it's probably fine if you do it
<toothbrush0>that's the one i had in mind indeed
<toothbrush0>nah, he can have the karma i guess :P
<toothbrush0>and perhaps it's best to do that when the US has woken up anyway
<civodul>well let's wait & see, then :-)
<toothbrush0>there was something i wanted to ask about
<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-
<toothbrush0>and last night, on my VM, it failed the tests after building :(
<toothbrush0>tests/build-utils.scm failed
<toothbrush0>but because i didn't think to add --keep-failed i cannot look at the log, i think :(
<toothbrush0>(after 386 seconds no less :P)
<toothbrush0>(+2744 for the build... that was more like it)
<Gxsdnewb>Good morning all!
<toothbrush0>Gxsdnewb: hi!
<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, i think
<toothbrush0>hm, the first bit makes sense then, but the substitutes aren't found by my version
<toothbrush0>not last night anyway
<toothbrush0>i'll retry now
<toothbrush0>argh, and i'm struggling with w3m which seems to have /usr/bin/vi hard-coded :/
<toothbrush0>EDITOR=`which vim` doesn't change it
<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?
<toothbrush0>i was
<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
<toothbrush0>so should i do `guix pull` to solve it?
<civodul>toothbrush0: and you reported success with 0.9.0pre yesterday, no?
<toothbrush0>well, success until i wanted to do `guix system reconfigure`
<civodul>yes, 'guix pull' can't hurt
<toothbrush0>lemme try that again
<civodul>it's even necessary before the first 'reconfigure', see
<toothbrush0>i had done that
<toothbrush0>but even so it wanted to rebuild a bunch of things (including dmd, sudo, xlock, etc)
<civodul>bah, dunno
<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 ;)
<toothbrush0>but anyway, i'll keep quiet and compile: P
<toothbrush0>* :P
<toothbrush0>Woo, we're on the front page of HN :D
<Gxsdnewb>i guess i should not run guix system reconfigure while still in live usb boot?
<civodul>toothbrush0: nice!
<civodul>Gxsdnewb: right, see
<rekado>"The future is what we make it" <-- +1
<civodul>glad you like it ;-)
<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.
<rekado>it does not install them.
<civodul>Gxsdnewb: yes, do read carefully
<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>(packages tcpdump xfce %base-services)
<Gxsdnewb>this makes guix system fail with the wrong number of arguements
<civodul>yes, please check how the examples above do it :-)
<civodul>notice the use 'cons*'
<Gxsdnewb>yes i just see now, sorry to bother you
<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>i wanted to try that actually :-)
<civodul>two minutes you say?
<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')
<paroneayea>hey ho!
<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?
<wkarhunguixi>no, i've added those lines manually
<wkarhunguixi>and yes, i type the LUKS password twice during boot
<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.
<wkarhunguixi>Gxsdnewb, great! :)
<Gxsdnewb>Now my installed GuixSD has device-mapper errors
<wkarhunguixi>can you show us your config?
<Gxsdnewb>oh i forgot to add cryptmount to the grub.cfg on disk
<davexunit>happy release day, everyone!
<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"
<paroneayea>the manual has some info towards that
<paroneayea>if you're looking for a slightly dated tutorial, might help
<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.
<Gxsdnewb>my 2nd grub.cfg on disk:
<Gxsdnewb>wkarhunguixi ^
<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
<civodul>an approach different from yours
<civodul>hey, davexunit
<civodul>rekado took the HN job today :-)
<davexunit>yes I noticed :)
<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
<davexunit>there's a summary up on phoronix as usual
<civodul>aaah :-)
<civodul>rekado: Guix won't be ported to MacOS, i think
<davexunit>hey sirgazil
<sirgazil>Thank you all for working on the project. I'm glad about the new release
<sirgazil>I'm installing on the weekend :)
<davexunit>another convert.
<paroneayea>civodul: btw, any thoughts on why OSX does not seem likely?
<paroneayea>it seems like Nix works there
<paroneayea>is it mostly because the Guix world is not interested in porting?
<paroneayea>or a technical reason I don't know of?
<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
<davexunit>oof, that sounds like a showstopper.
<civodul>Nixpkgs "cheats" there
<civodul>it just uses the available compiler and libc
<civodul>and builds the rest on top of that
<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
<civodul>upstream glibc supports 1.5 kernel
<civodul>(normally 2)
<civodul>Debian glibc supports 3 kernels
<paroneayea>davexunit: yes seeing the jquery example on Nix made me question how much you can truch Nix's reproducibility promise
<toothbrush0>paroneayea: what's the "jquery example"?
<paroneayea>toothbrush0: search for "nix" there
<paroneayea>and read the whole post for context
<toothbrush0>thank you
<paroneayea>toothbrush0: yup!
<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
<paroneayea>yeah civodul has it
<civodul>it’s really Nixpkgs
<paroneayea>ok nixpkgs, yes :)
<civodul>i think kmicu thought you were referring to Nix-the-package-manager
<paroneayea>right, I mean the packages
<kmicu>Nix ≠ nixpkgs.
<paroneayea>ok :)
<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>ok. I guess your cryptomount is good then
<wkarhunguixi>and you have updated guix, right?
<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>msdosX is grub is for mbr
<francis7>gptX is for gpt
<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
<Gxsdnewb>ERROR: In procedure scm-error:
<Gxsdnewb>ERROR: pre-mount actions failed
<wkarhunguixi>hm, can you show us your config scm?
<wkarhunguixi>(here's a way to upload config.scm with curl: curl -F 'sprunge=@/etc/config.scm' )
<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
<wkarhunguixi>hm, scratch that.
<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>I don't know what the problem is, but if you want to try something, you can try copying the two blocks of code with %linux-modules here,
<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))
<wkarhunguixi>I have no other ideas at this point.
<paroneayea>whoa. mit-scheme ships with edwin?
<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>'guix pull' fetches from upstream
<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"
<Sleep_Walker>I've got build failure I don't know what to do about -
<Sleep_Walker>pure 0.9.0 release tarball
<taylan>Sleep_Walker: seems you're missing the json module...
<civodul>Sleep_Walker: you need guile-json, see
<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
<Sleep_Walker>(I just verified that in config.log)
<civodul>yes, that seems to be a bug
<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-
<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>remi`bd: could you look into it?
<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.
<civodul>better this way ;-)
<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 :(
<civodul>yes /tmp is cleaned upon reboot
<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?
<fps>before doing it?
<bavier>fps: it does
<fps>ok, cool
<Gxsdnewb>I am trying to system init with this scm:
<Gxsdnewb>but it fails with this error:
<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
<octe>cool, you're right
<serhart>octe: you need to use the passwd command as root
<octe>heh, windowmaker, the nostalgia :)
<ggoes>windowmaker is for winners!
<fps>xmonad all the way
<paroneayea>\\o/ \\o/
<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?
<davexunit>__night__: I haven't tried yet.
<__night__>Thanks =)
<davexunit>(please give people some time to respond)
<davexunit>I have a Novena that I'm going to try it on
<avoine>not yet but I have a imx6 I could use
<davexunit>currently I run it only on x86_64 machines
<__night__>Ok. Well, would it be difficult to port it to arm?
<davexunit>it's already ported.
<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
<bavier>__night__: see
<davexunit>avoine: ./configure --localstatedir=/var
<__night__>bavier: Got it! thanks!
<detrout>I think I have successfuly made a guix package.
<bavier>detrout: great!
<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>let's try it :)
<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>oh ok, cause i suck
<fps>sudo dd if=/dev/nbd0 of=/dev/sdg bs=80192
<fps>sdg1, too
<fps>sudo dd if=/dev/nbd0 of=/dev/sdg1 bs=8192
<fps>that maybe did work. let's see
<fps>nope, too simple ;)
<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>it boots
<fps>no wifi, of course ;)
<fps>ok, partial success i'd say..
<civodul>fps: you install GuixSD 0.9.0?
<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
<civodul>which mostly means atheros
<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"
<arianvp>for some reason
<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
<fps>arianvp: yay
<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
<arianvp>yeh I'll guess I'll do that
<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>fps: yay success
<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
<arianvp>we'll see.
<arianvp>running in qemu is fine as well
<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>same here..
<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>wireless-n 2230?
<fps>there's some that do have free drivers
<fps>that lists 2230 though
<arianvp>fps: ultimate-n 6300
<fps>not sure why it's not supported in guixsd
<arianvp>so i think im out of luck
<fps>that's supported by
<fps>same driver..
<arianvp>but it's not in guix-sd?
<fps>not sure.. maybe there's a reason that iwlwifi is not shipped with it
<fps>oh it is
<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>not sure yet
<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
<karhunguixi>avoine, likely, it's used in shell scripting
<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?
<arianvp>hm how do I get internets in qemu?
<avoine>oh I see
<fps>arianvp: ifconfig -a
<fps>then ifconfig your_interface up
<fps>then dhclient your_interface
<karhunguixi> "What is the difference between test, [ and [[ ?"
<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>nano ;)
<fps>if i understand it right you should be able to install it with guix -i vim maybe
<fps>haven't tried it
<karhunguixi>and you have zile in the installer
<rekado>zile is great
<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
<arianvp>installing. hype
<davexunit>brainproxy: I hope you enjoy your stay.
<davexunit>let us know what was good and what sucked. ;)
<davexunit>(rough edges abound)
<arianvp>wow just read about guix challenge
<arianvp>sounds exciting
<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
<paroneayea>re: fosdem
<davexunit>hopefully civodul will be proposing a talk in the distro room?
<civodul>yes, why not!
<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? ;-)
<paroneayea>maybe show up to the npm room
<paroneayea>"fix your shit, you guys!"
<davexunit>ACTION drops mic
<paroneayea>okay I don't actually advocate that :)
<paroneayea>there's a room on containers
<paroneayea>and one on testing and automation
<davexunit>they'll laugh me out of the room there
<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>fps: yes
<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>very nice
<davexunit>virtual box is a no go.
<davexunit>as it now relies on nonfree blobs to work.
<keverets>OS X itself is a nonfree blob...
<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.
<brainproxy>i don't want self-hostable :-(
<davexunit>so an OpenStack and EC2 client would be needed.
<brainproxy>except for my dev workflows
<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
<davexunit>anyway, gotta go.
<davexunit>I think we can make something work though
<davexunit>it just needs some thought and planning.
<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
<davexunit>it's an interesting problem
<brainproxy>davexunit: sure, cya, thanks for the feedbck
<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