IRC channel logs

2015-11-06.log

back to list of logs

<detrout>hi paroneayea, i was following your Guix package manager without "make install" post, and it seems pkg-config, guile-2.0-dev, and libsqlite3-dev are all now required dependencies
<paroneayea>detrout: heya! thanks, I'll add that
<paroneayea>detrout: hey I noticed your patch to the list
<paroneayea>super awesome to have you aboard :)
<detrout>you're welcome.
<detrout>though i'm also torn because the Debian devs have all been nice to me too
<detrout>also it looks like i need guile-json and that may not exist yet
<detrout>or something
<paroneayea>detrout: there's no need to be partisan towards Debian vs Guix, I'm running Guix on top of Debian :)
<detrout>what packages are you managing with which system?
<detrout>are you mostly using guix for managing your development environments?
<paroneayea>detrout: mostly, and also a lot of bleeding edge things. eventually when I have all the things I need I might switch to guixsd for my desktop
<paroneayea>detrout: also trying to switch to it for servers, which guix as a deployment platform is my real main goal
<paroneayea>accidentally pushed my irregex branch to origin btw, but I just deleted it
<paroneayea>in case anyone's wondering what's going on
<paroneayea>sorry about that, *
<detrout>so does guix have a way of stacking etc configurations?
<detrout>because in thinking about your deployment thoughts it seems like that's one of the pain points
<paroneayea>detrout: kind of, there's a services thing, and I think that it'll be one of its future strengths once enough is there
<paroneayea>detrout: because you'll be able to wholly test, deploy, and roll back a system including its configuration
<paroneayea>but we have some ways to go there
<detrout>One of the things I've occasionally done with debian is build a mini debian config package that installs some confiugration files to deploy a service
<detrout>works best when things read from directories like apache or condor does
<detrout>sadly fstab.d just taunted me.
<detrout>someday you man manage your clusters NFS shares by package... but not yet.
<arianvp>heya
<arianvp>how would I set an alternative shell in the users section in system configuration?
<arianvp>I added fish as a package to packages in my system config file
<arianvp>just not sure how to get the path to the exectuable to set in (shell "blah") in the (users) section
***jonsger1 is now known as jonsger
<arianvp>I tried (shell fish) but then it says "dladsadad-fish-2.2.0 is a directory"
<arianvp>How can I contribute to the packages by the way? fish should depend on sed but it currently doesn't
<arianvp>wait no nvm. seems to be another bug actually
<detrout>oh and paroneayea at least for todays guix you also need guile-json, which isn't currently in debian
<detrout>should it be?
<anthk_>Hello. How can I upgrade GUIX to 0.9.0 from 9.8.3, being installed on top of Trisquel?
<Xe>Is there a guix package made for GNU Artanis?
<jonsger>Xe: look here https://www.gnu.org/software/guix/packages/
<Xe>i didn't see it there
<jonsger>so there is no package for artanis
<Xe>is there a way to make a guix system installed into a folder for a chroot?
<Gxsdnewb>to add kernel modules into initrd, is it enuf to write (define %linux-modules '("dm-crypt.ko")) for example?
<Gxsdnewb>or do i need a part of my scm inside the (operating-system) section like (initrd (lambda (fs . args) (apply base-initrd fs #:extra-modules %linux-modules args))
<Xe>argh, why does the guix builder need CAP_SYS_ADMIN to do things?
***jonsger1 is now known as jonsger
<wobble>dont I need a public key to verify the source tarball against associated '.sig' file? I cant find any on http://www.gnu.org/software/guix/help/
<davexunit>wobble: import the key for ludo@gnu.org
<wobble>davexunit: thx
<Gxsdnewb>I think i figured out why my fresh install could not decrypt itself at boot: no cryptsetup was installed!
<Gxsdnewb>also, after a fresh install, a guix package -i emacs as root downloads the emacs substitute and dependencies
<Gxsdnewb>but the same guix package command as nonroot user wants to bootstrap the entire toolchain by compiling gcc, glibc, etc
<Gxsdnewb>Is this something to do with tools missing from this users' profile?
<Gxsdnewb>what is rthe recommended way to refresh a user's profile to access all binaries of packages on the system?
<Gxsdnewb>and most importantly: how should i go about installing cryptsetup onto the guixsd install that cant decrypt itself? i can just copy the package output dir from another imstall or usb, but how would the kernel+initrd lknow where to find the cryptsetup binary?
<lfam>warning from `guix lint`: luasocket-3.0-rc1: the source file name should contain the package name
<lfam>I agree. But is this a purely stylistic warning or should I do something about it? I could ask upstream to change the tarball filename but it's not a priority for me.
<karhunguixi>Gxsdnewb, you didn't encrypt your partition in the installer?
<karhunguixi>Gxsdnewb, i would have just reinstalled. There obviously could be niftier ways, but i don't know them.
<Gxsdnewb>karhunguixi, i encrypted it manually with cryptsetup luksFormat in the live usbenv, then mounted and ran guix system init on a config.scm with appropriate mapped-devices settings
<karhunguixi>also with cow-store?
<Gxsdnewb>i tried installing again, and that install *also* did not have a cryptsetup binary, which is how i noticed why the first install is not booting
<karhunguixi>do you run this before installing? deco start cow-store /mnt
<Gxsdnewb>yes i did, but it is always very frustrating that cow-store deletes all the data when it stops
<karhunguixi>deletes all the data when it stops?
<Gxsdnewb>well yes, it populates /mnt/tmp/guix-inst/ while guix system init is running, but on shutdown (or deco stop cow-store) the dir is deleted
<karhunguixi>hopefully some of the data in /gnu/store is preserved though ;)
<karhunguixi>what's in /mnt/tmp/guix-inst/? Logs?
<Gxsdnewb>nada. and all the build logs go to /var/log/guix
<karhunguixi>i mean, what's in there before cow-store is stopped?
<Gxsdnewb>derivation files, guile builder files, patches, some .scm files, tarball downloads, package dirs...
<karhunguixi>aha
<karhunguixi>and with this preserved it would be quick to adjust your setup i take it
<Gxsdnewb>i am still not sure why cryptsetup was not installed when a mapped-devices section was added. is there a standard way to enable luks support in a system.scm for guix system?
<karhunguixi>there's only the "type luks-device-mapping" as far as i know
<Gxsdnewb>i had type luks-device-mapping specified, but cryptsetup was not installed in the target
<Gxsdnewb>what is the best way to install it when i am booted into an unencrypted guixsd install and i have the crypted one mounted on /mnt
<karhunguixi>i don't know
<Gxsdnewb>simply copying the ...-cryptsetup-1.6.1 dir should not work because the db.sqlite needs to be updated
<karhunguixi>you could always fall back to reinstalling, but i take it you want to hack it instead
<Gxsdnewb>My question is: what else besides the db.sqlite file in /var needs to be updated to indicate to the rest of the os that a package is installed in the store?
<karhunguixi>i assume you would need to update your profile
<karhunguixi>i have this, http://sprunge.us/KhgJ maybe it's helpful.
<karhunguixi>i'm not familiar with these things, so i'm just throwing ideas at the wall
<karhunguixi>err, this is my user's profile though. It shouldn't be used during the booting process.
<karhunguixi>but maybe you need this for root's profile
***pyfgcrl is now known as sanctuary
<fps>hmm, for some reason the xserver chooses a resolution higher than what qemu-kvm seems to be able to deliver. so i got this "workspace bigger than physical screen thing" which people thought was a good idea somewhere in the 80s
<fps>note to other qemu-kvm users: use -vga qxl to get larger console on ttys and not get this thing from the 80s :)
<fps>oh man, Y U NO HAVE A WIKI?
<fps>shall i set up one?
<fps>;)
<fps> https://github.com/fps/guixsd-wiki/wiki
<rekado>fps: this came up a couple of times before. We prefer to fix the manual rather than encourage a wiki.
<fps>rekado: yeah, that process is flawed though
<rekado>all processes are flawed.
<fps>rekado: that's true.. not having a place to collect snippets of wisdom besides from trying to get super polished changes into the manual is more flawed than having one though
<rekado>you can post those little snippets of wisdom to guix-devel and ask where in the manual would be a good place for it.
<rekado>I'd much rather have a manual that's correct and up-to-date than a wiki. There are only few really good wikis.
<fps>rekado: you are right about the first point, though it should not be the only option -> many roads lead to rome
<fps>the most important thing about getting contributions from people is to make the process easy. Every extra action required loses you people and possibly valuable input
<toothbrush0>sending an email to the ML is IMHO easier than creating an account on some website and messing about with wiki syntax...
<toothbrush0>but that's just my €0.02
<fps>different strokes for different folks..
<fps>oh this reminds me
<fps>i wanted to create a wiki without signup that would have you do proof of work in the browser to avoid spam ;)
<fps>i.e. the server sends you a hash prefix and your browser starts hasing random numbers until you have the prefix. then you can submit your change..
<fps>*hashing
<fps>[sending along your found random number]
<fps>no more freaking capchas
<fps>*shudder*
<taylan>this program versions itself like "v095". what would our conventions say? should I use "095"?
<toothbrush0>I guess i'm being a grumpy old man when i say that this probably won't work in elinks or in my NoScript-enhanced browser of choice? :P
<fps>toothbrush0: those people can still use the damn ML or create an account ;)
<fps>i'll make sure to publish the underlying js code as free software though
<toothbrush0>yeah, i understand that JS ≠ evil by definition. :)
<toothbrush0>it's a cool idea though
<fps>this is a general principle and can be used for all kinds of services that you want to protect from abuse
<toothbrush0>although i wonder what the environmental impact is of burning cpu cycles uselessly
<fps>like make a submit form that can send mails to the ML and protect it by the same POF mechanism
<fps>toothbrush0: well, you can disable it for people that you trust
<toothbrush0>much as i hate the idea that i'm working for a private company when i fill in a CAPTCHA, at least it's "a little bit useful"
<fps>it doesn't have to be on for everything..
<toothbrush0>fair enough i guess
<fps>toothbrush0: that's a good point :)
<fps>save the calculated hashes.. they might come in handy later..
<toothbrush0>:P
<fps>oh drats, now i spilled an idea i actually wanted to keep for myself ;)
<toothbrush0>i'll put them next to the tins of peas in my basement :P
<fps>cause it has economic impact
<fps>*POW [proof of work, not POF - proof of fork? :)]
<fps>needs a catchy name though..
<fps>capchow ;)
<fps>powow? catchow?
<toothbrush0>Greetings civodul !
<civodul>Hello Guix! :-)
<efraim>hi!
<fps> https://github.com/fps/catchow/blob/master/README.md
<toothbrush0>I have a weird thing going on after compiling guix from core-updates. The first operation i try (`./pre-inst-env guix package -r ghc` in this case) wants to download (and build) a whole bunch of things, including the curiously-named "/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0".
<toothbrush0>it fails on the download, with a 410 Gone. Does anyone know if this is correct behaviour?
<taylan>that sounds like a case where a 'file-name' entry is missing in the source description, though it should still work.
<taylan>yeah, grepped the latter hash, it's the source for some patch in the coreutils recipe in gnu/packages/base.scm
<taylan>it has a file-name though. maybe fixed in master but not core-updates, dunno
<toothbrush0>i guess i'd have to do --no-substitutes to get around it?
<toothbrush0>but that's going to cause an already insanely large list of packages to build to become twice as long...
<civodul>toothbrush0: the thing curiously named is a git commit i suppose, in an origin lacking a 'file-name'
<civodul>i see it in coreutils but it does have a file name
<civodul>and it's not 410: http://git.savannah.gnu.org/cgit/coreutils.git/patch/?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0
<civodul>weird
<toothbrush0>yeah um, how can i explain
<civodul>maybe something's different there?
<toothbrush0>i've also managed to download that file
<toothbrush0>but hydra promises that it has a substituted derivation (or whatever the terminology is)
<toothbrush0>and *that* is 410
<toothbrush0>so i'm trying to use --no-substitutes to get it to download the patch directly, at which point i'll go back to substituting, but murphy's law is that now of course it's not building coreutils, the package needing the patch
<civodul>ooh!
<civodul>ACTION tries
<toothbrush0>and i can't seem to C-c the build either
<toothbrush0>that's just annoying
<civodul>shell issue?
<civodul>it could be that your local substitute cache is stale
<toothbrush0>hm, i'd tell you if i knew how to check :p
<civodul>maybe try: sudo rm -rf /var/guix/substitute/cache/
<toothbrush0>okay
<civodul>or browse that directory to find the info for this derivation
<toothbrush0>already blew it away, sorry
<toothbrush0>but what's weird is that now everything needs to be built, no substitutes proposes
<toothbrush0>*proposed
<toothbrush0>oh well
<toothbrush0>ugh, building the world is going to take a long time on a VM i'm afraid
<toothbrush0>i guess it's normal that core-updates hasn't been built on hydra yet?
<civodul>that's not weird
<civodul>it's just that you were in the unlikely case of having an outdated hit cached
<civodul>core-updates is not being built, indeed
<toothbrush0>okay
<toothbrush0>then it's not weird, indeed.
<toothbrush0>oh well
<toothbrush0>brb compiling for a few hours :P
<civodul>:-)
<civodul>building GHC from core-updates?
<toothbrush0>not ghc, but bash, guile, etc etc etc
<civodul>yes, but what's your target package?
<toothbrush0>um, i want to try out bavier's patch to fix .profile.conf.d for GHC indeed
<toothbrush0>so probably you're right, i'll have to rebuild ghc-*
<civodul>that's courageous ;-)
<civodul>beware that core-updates is going to move a lot
<toothbrush0>i don't have much choice do i?
<civodul>depends on what you want to do!
<civodul>:-)
<civodul>if you want to test the patch, indeed
<toothbrush0>try bavier's patch to see if it fixes xmonad for me
<civodul>if you want to use the thing, you'd better wait for the branch to be merged in master
<toothbrush0>oh
<toothbrush0>is that on the agenda any time soon?
<civodul>not really soon :-)
<toothbrush0>right
<civodul>no ETA
<toothbrush0>so if i want to use Xmonad in the meantime :p
<civodul>well...
<civodul>no good solution here :-/
<toothbrush0>that's fine. i'll see if building the world makes any progress...
<taylan>this tarball contains no license info whatsoever, only a text aside the download link says GPLv3. can this be trusted? (and I won't even be using the same URL for the download)
<civodul>which tarball?
<taylan>for the SNES emulator higan
<taylan> http://byuu.org/emulation/higan/
<taylan>I'll use a git tag tarball from gitlab to download it, since the one linked there is .7z and the developer doesn't want systems to auto-download from their website
<civodul>if there's no explicit license statement in the source, that's effectively non-free in my book
<taylan>I'll pester the developer a bit then
<civodul>pester respectfully of course ;-)
<FlibberTGibbet>hi, what init system does guix use please?
<eiz>dmd
<FlibberTGibbet>thanks eiz. just saw a systemd directory on the usb installer, so was wondering :)
<cehteh>puh .. you gave me a shock :)
<FlibberTGibbet>sorry, didn't mean to!
<toothbrush0>civodul: okay, no building of the world for me, perl failed :(
<rekado>FlibberTGibbet: Guix comes with a systemd unit file for those users running Guix as a package manager on top of another variant of the GNU system.
<FlibberTGibbet>rekado: thanks for explaining. btw, is it feasible/sensible to test guixsd in a vm on a linux host?
<arianvp>fps: thanks for the help yesterda
<fps>arianvp: you're very welcome
<arianvp>got another question though :D
<arianvp>So i'm trying to set up a different login shell in my system configuration
<arianvp>I got: (define fish-location #~(string-append #$fish "/bin/fish"))
<arianvp>and then (user-account (name "arian") (shell fish-location))
<arianvp>which works. and succesfully starts up the fish shell when I login
<arianvp>but for some reason PATH isn't set correctly I think
<arianvp>because it can't find any commands
<arianvp>all commands result in "Command not found"
<fps>yeah, commands are located in the gnu-store and possibly symlinked to something like /var/run/current-system/bin or something.. hold on..
<arianvp>I've been looking for the bash gexpr in the source code but I couldn't find it
<fps> https://www.gnu.org/software/guix/manual/html_node/User-Accounts.html#User-Accounts
<fps>just looking around. i'm a noob, too
<arianvp>Yeh I followed that. (shell takes a gexpr (derivation) as an argument
<fps>oh right
<fps>my bad :)
<arianvp>which I created with #~ quasiquoter
<fps>for some reason my install in qemu now doesn't show the login screen
<fps>ugh
<arianvp>hehe
<fps>oh it's there, but brokenm
<fps>lalala
<fps>hitting enter made the display manager redraw. ok
<karhunguixi|w>maybe you just need a .fishrc or some such, where PATH etc. is set
<fps>oh, it's /current-system/profile/bin
<arianvp>yeh probably. but how do I automagically do that?
<fps> /run/current-system/...
<karhunguixi|w>i don't know
<arianvp>sec I think I know
<arianvp>sourcing /etc/profile should work I think
<arianvp>which of course doesn't work because fish doesn't support bash syntax. yay
<arianvp>haha
<arianvp>okay i'll try zsh
<arianvp>if I fix it i'll blog about it. I think it's useful to know
<fps>see? people don't like mailing lists :)
<fps>q.e.d
<fps>sample size of two. super significant result.. but i'd declare it representative from prior knowledge
<karhunguixi|w>i löve mailing lists :)
<fps>i used to, too. i still do, but i used to, too
<fps>[mitch hedberg paraphrase]
<karhunguixi|w>hehehe
<fps>they are a hassle to use though
<arianvp>I hate email. Because I suck at maintaining my mailbox
<fps>since you also have to setup a filter in your email client, yadayada
<arianvp>^
<fps>when it comes to motivating people to contribute, every single click or action counts
<fps>it's like in the advertisement business
<karhunguixi|w>you can search here, https://lists.gnu.org/archive/html/guix-devel/
<fps>oh mailman archives.. soo 20th century
<fps>;)
<karhunguixi|w>;)
<fps>it does have a search function?
<fps>wow, it has moved forward in the last 20 years
<arianvp>Okay it worked perfectly! :D
<fps>figure me impressed
<arianvp>got alternative shell working
<arianvp>awesome
<arianvp>I really like my current guix workflow
<karhunguixi|w>ACTION makes a note in the margin that fps is impressed
<fps>;)
<arianvp>everything in a git repo. And only commit after reconfigure succeeded and after reboot nothing is broken
<arianvp>it's like... continous delivery.. for my OS
<arianvp>if stuff breaks, go to previous version in grub menu
<arianvp>and git checkout -- *
<arianvp>it's aweosme
<karhunguixi|w>how is it different from the list of previous GRUB entries other people have?
<arianvp>I do exactly that
<Gxsdnewb>how should i go about installing cryptsetup onto a guixsd install that cant decrypt itself at boot? i can just copy the package output dir from another imstall or usb, but how would the kernel+initrd lknow where to find the cryptsetup binary?
<arianvp>but I also keep the code in version control
<xd1le>arianvp: yes exactly, declarative configuration is great
<karhunguixi|w>Gxsdnewb, why don't you reinstall?
<Gxsdnewb>doesnt the db.sqlite need updating? can i install cryptsetup by chrooting to my mounted guixsd partition from another install (unencrypted) that is working?
<fps>put the VB installation snippets here.. https://github.com/fps/guixsd-wiki/wiki/VirtualBox-installation
<fps>if i ever need to refer to it again -> it won't make it into the manual anyways ;)
<fps>arianvp: btw: did you research loading the firmware blob for your wireless further?
<Gxsdnewb>because if i dont understand the problem, it may not go away. and knowing how to install packages into a mounted chroot of another install seems useful and i should know how to do this if possible.
<arianvp>fps: no not yet
<karhunguixi|w>ok, good cause
<arianvp>Friend shared me his config on how to get linux-nonfree working on guix
<fps>ok, might look into it some more later.. i have a hunch that's it's impossible with linux-libre, just making assumptions about gnu people in general though ;)
<arianvp>which i'll try tomorrow
<fps>arianvp: if you have a github account, feel free to add it to the wiki i set up..
<arianvp>I have one. which github?
<rekado>Gxsdnewb: I don't really understand what you've tried and what your situation is right now. How would it help you if you had cryptsetup installed on an encrypted disk?
<fps> https://github.com/fps/guixsd-wiki
<arianvp>i'll add the zsh snippet in there as well
<Gxsdnewb>and two installations in a row with luks-device-mapping mapped-device fail to decrypt at boot
<fps>oops, i screwed up the home page. fixed it. maybe reload
<arianvp>ugh
<Gxsdnewb>rekado: my guixsd installation to encrypted LUKS partition ask for a passphrase at boot but then fail to boot quickly after typing in the passphrase
<arianvp>Welp. im now the owner of a 24 core 128GB RAM libreboot server
<arianvp>now just need to colocate somewhere
<arianvp>:D
<karhunguixi|w>Nice! :)
<rekado>Gxsdnewb: after you input the passphrase does it successfully decrypt the partition?
<arianvp>And write a guix-ops tool so people can deploy guix servers to the cloud >:)
<arianvp>and then... world domination
<fps>haha
<arianvp>(there's probably already someone working on a guix-ops tool right?)
<Gxsdnewb>no rekado it fails.
<fps>world domination is too much responsibilit for my taste ;)
<arianvp>well idk how much of the world you can dominate with one server
<arianvp>but it's a start
<Gxsdnewb>i notice by decrypt and mount from another install that there is no cryptsetup package in the store
<rekado>I have a faint memory about cryptsetup having to be part of the initrd.
<fps>arianvp: i also thought about having a github repo for non-free packages. but i'll figure that out when i get into that a little more ;) maybe it's not feasible at all.. we'll see..
<Gxsdnewb>rekado: the errors i get at boot indicate missing functionality in the initrd
<karhunguixi|w>Gxsdnewb, did you try adding the crypto modules in the configuration? %linux-modules
<arianvp>fps: sure it's feasible
<arianvp>we could even set up our own hydra build farm for it
<arianvp>not sure how happy people here would be about that though :P
<Gxsdnewb>karhunguixi: yes, i tried following your modules snippets of your system's scm, but the placement or syntax was wrong
<karhunguixi|w>did you copy+paste it, or type it by hand?
<arianvp>I added the snippet to the wiki, fps.
<arianvp>I'll add how I got it working on libvirt as well later
<arianvp>=)
<civodul>toothbrush0: could you paste the build log?
<rekado>Gxsdnewb: did Guix complain about the syntax or did it just not make any difference?
<civodul>fps: the qemu instructions at https://github.com/fps/guixsd-wiki/wiki look useful!
<Gxsdnewb>civodul: can we PLEASE not host anything on github
<Gxsdnewb>lets make the wiki somewhere else
<toothbrush0>civodul: http://paste.lisp.org/display/158630
<toothbrush0>the second time it failed elsewhere
<toothbrush0>it seems like something else is wrong
<toothbrush0>it's not diskspace in any case..
<fps>sure, let's host the wiki somewhere else :) any takers? ;)
<civodul>Gxsdnewb: i agree with you, but i don't get to dictate what fps does
<civodul>fps: we have https://libreplanet.org/wiki/Group:Guix
<civodul>if you want, you can add material there
<civodul>but as discussed a while back on the mailing list, i would strongly encourage you to contribute documentation to the manual instead
<civodul>toothbrush0: it's GCC failing, due to the bootstrap Bash segfaulting
<fps>no worries, i'm just pushing ahead and see what good falls out of it ;)
<civodul>toothbrush0: this is weird: bootstrap binaries have not changed in ages
<fps>the ideal case is to have a signup free wiki anyways, but that'll require some more work..
<fps>and then if someone thinks content is worth moving to the manual, they are free to do so
<fps>cause i'm free, to do what i want, lalalala [cue music]
<toothbrush0>civodul: ah, okay, the error didn't make much sense to me.
<civodul>toothbrush0: could you fiddle with /gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/bash and see if anything obvious is wrong with it?
<toothbrush0>okay, lemme try.
<toothbrush0>seems reasonable? bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped
<toothbrush0>1.4M
<civodul>and if you actually run it, everything alright?
<civodul>was the build performed in a VM?
<civodul>people say bad things about the Guix web sites at https://news.ycombinator.com/item?id=10512772
<civodul>this comes as a surprise to me
<civodul>esp. https://news.ycombinator.com/item?id=10517719
<toothbrush0>VM indeed
<toothbrush0>yeah, the prompt just says "I have no name!" but otherwise at first glance it seems okay
<civodul>ok
<civodul>would be interesting to see if the same derivation succeeds outside the VM
<Gxsdnewb>So gc-keep-outputs only saves .drv files? what about guile-builder files and .scm files and patches that show up in cow-store during installation?
<toothbrush0>ACTION is scared of blowing up my host's Guix installation :p
<toothbrush0>s/my/their/
<civodul>toothbrush0: by just running 'guix build'?
<civodul>sounds unlikely :-)
<toothbrush0>proooobably not indeed.
<toothbrush0>i'm a nervous type okay? :P
<Gxsdnewb>I would like an option to save everything used during the build process, and not have it deleted after the cow-store is disabled
<toothbrush0>civodul: what exactly should i try and build on core-updates? gcc?
<toothbrush0>that's what seemed to fail in the VM
<francis7><arianvp> Welp. im now the owner of a 24 core 128GB RAM libreboot server
<francis7>kgpe-d16?
<francis7>cool
<civodul>toothbrush0: try to build anything; what failed here is one of the first packages that gets built
<civodul>(hence "boot0")
<toothbrush0>okay, busy making guix, will report back
<toothbrush0>and yeah, that comment is rather ascerbic
<toothbrush0>although maybe the "selling points" of Guix aren't clear enough? i don't know, i'm too invested to be able to judge that.
<toothbrush0>and yeah, i guess aesthetics are down to personal taste, so w/e
<Gxsdnewb>civodul: is there a way to keep all of this data without just copying it from the cow-store to another dir to prevent autodeletion? it seems gc-keep-outputs only saves .drv files whichis not everything
<civodul>toothbrush0: i don't know, i'd say freedom + transactions + APIs differentiates it from both Debian and NixOS, but then i'm biased
<civodul>Gxsdnewb: cow-store is only for the installation image
<civodul>Gxsdnewb: are you done installating GuixSD?
<civodul>hey, davexunit!
<civodul>davexunit: what's your take on the negative comments on the web site at https://news.ycombinator.com/item?id=10512772 ? :-)
<toothbrush0>the HN crowd seems to think freedom isn't worth mentioning (i can perhaaaaps understand the point, since it's @gnu.org, so you can already assume that) but yeah.
<civodul>does the "HN crowd" know what GNU is?
<civodul>i'm not sure
<civodul>i mean it's a diverse crowd obviously, but a large part of it is web developers, AIUI
<civodul>i don't think user freedom is a common denominator
<toothbrush0>yeah they certainly seem more like the "let's hack something together and sell it for $$$$$$" than super libre-oriented
<xd1le>> but a large part of it is web developers
<civodul>yeah
<xd1le>yes that's how i understand it as well
<toothbrush0>wow, somehow today is requiring more coffee than usual, brb.
<civodul>and entrepreneurs-to-be maybe, because that's what Y Combinator is about, after all
<xd1le>so no, /at least/ a significant minority of them may not even know what GNU is...
<davexunit>civodul: people know GNU for sure. most of them are not fans, however.
<toothbrush0>yeah there's a weird anti-sentiment i keep feeling. it's not even explicit sometimes, more like disdain
<davexunit>civodul: and you meant negative comments about the guix site, right?
<civodul>davexunit: some have this viewpoint sure, but others just know "Linux"
<toothbrush0>maybe because we're not driving around in Porsches?
<civodul>davexunit: yes
<davexunit>people overall liked the Guile site, but seemed turned off by the Guix site.
<civodul>yes
<davexunit>which was intriguing. I think there's something to fix there.
<Gxsdnewb>fps: instead of useless POW hashes for anonymous wiki edits, have the clients build packages to verify hashes of outputs in a distributed manner
<rekado>compared to the Guile website the Guix website is slightly inferior, in my opinion.
<civodul>davexunit: probably! which is why i'm asking for feedback
<rekado>which is not to say that it's "ugly" as some have put it on HN.
<toothbrush0>i can understand that the guix site comes off as l33t h4x0r, if you'll pardon my speek
<toothbrush0>with the black background
<davexunit>maybe we should ligten that up
<davexunit>remove the "carbon fiber" background
<toothbrush0>i don't really mind, but i can see that being against the modern bootstrap-like tasted
<toothbrush0>*tastes
<xd1le>which of course constrasts with the friendly drawings on the guile site
<toothbrush0>yeah
<davexunit>and somehow change the bullet points
<davexunit>people seemed to not understand what Guix is about from them as well as we thought they would.
<toothbrush0>and what about the perception that guix is a guile wrapper around nix?
<davexunit>yeah that needs to be fixed
<davexunit>because it's entirely wrong
<toothbrush0>maybe the relationship/heritage should be clarified
<xd1le>toothbrush0: is it actually a guile wrapper around nix?
<xd1le>(idk)
<davexunit>maybe some real straightforward text "Guix is a package manager" "GuixSD is a GNU/Linux distribution"
<toothbrush0>i'm going to defer to the experts on that one xd1le
<toothbrush0>davexunit: that would be a good start
<Gxsdnewb>civodul: i have guixsd installed to encrypted luks, but decryption completely fails so i installed a second guixsd to unncrypted partition to debug it and discovered that cryptsetup was never installed! Now i am not sure how to install cryptsetup from a secondary install (can i chroot and guix package -i)??
<davexunit>calling it a "wrapper" is doing the project a disservice.
<toothbrush0>many were confusing them in the HN thread yesterday
<xd1le>toothbrush0: okay, no i just thought it would be interested to know what's
<xd1le>going on at a lower level
<xd1le>yeah
<toothbrush0>i am too, but i'm not confident i can explain exactly what's compatible and what's not
<davexunit>it's a "wrapper" in the sense that we put a different interface on the low-level tools.
<rekado>with the screenshots, the differntly coloured buttons (blue "TEST", violet "CONTRIBUTE", orange "Help us improve Guix", red "Report"), and the four different backgrounds (blue, graphite, gray, white, light gray) the Guix website is no longer as clear as it felt on the mockups --- I think it would be nice if it were simplified a little.
<davexunit>yeah
<xd1le>davexunit: as i understand it (without reading any source code), it's an
<xd1le>implementation of functional package management in guile
<davexunit>yes
<xd1le>whereas nix is an implementation in nixlang
<toothbrush0>how compatible are the build daemons?
<toothbrush0>not at all? i had the impression that /{gnu,nix}/store/ had some shared heritage
<davexunit>it's not a wrapper because, for example, Guix package expressions aren't just Nix expressions in Guile.
<davexunit>they are very different.
<rekado>the daemon is quite similar.
<davexunit>we use the same daemon
<toothbrush0>okay
<davexunit>so we speak the same low-level protocol and use the same low-level file formats.
<toothbrush0>right
<davexunit>but *everything else* is different.
<davexunit>substantially so.
<davexunit>if Guix were just a thin wrapper over Nix it wouldn't be worth using.
<toothbrush0>sure
<rekado>"same" in that the origin is the same, but we don't use the latest "upstream" version and the daemon code may diverge a little to add stuff we need.
<xd1le>rekado: yes i think i agree with that
<toothbrush0>i wonder if a carefully-worded sentence to that effect would be useful
<xd1le>(website design)
<toothbrush0>i.e. acknowledging the heritage but clearing the confusion
<davexunit>yeah
<toothbrush0>(apart from the fact that they don't seem to care much for Libre, which is a pretty important point, but separate from the technical one.
<toothbrush0>)
<davexunit>change the messaging + change the colors
<xd1le>hey about this, just wondering, anyone have an article or link or something
<xd1le>about why use guix at all (why not just nix)?
<toothbrush0>lol, "starts open source project to solve packaging woes, ends up on PR campaign"
<xd1le>would help answer that question on pr campaigns
<xd1le>like i know software freedom for one
<xd1le>and guile for another
<xd1le>but like what if they don't care about those points that much
<toothbrush0>"sandboxing" of software packages?
<toothbrush0>rekado posted a cool poster yesterday
<toothbrush0>that was rather convincing imho
<xd1le>on irc?
<davexunit>addressing the "why not just use nix?" question is important, but it needs to be framed to not be hostile towards Nix.
<davexunit>because we're friends with different opinions, not enemies.
<xd1le>davexunit: yes true.
<toothbrush0>xd1le: no HN, i'm searching
<toothbrush0>davexunit: sure
<xd1le>toothbrush0: ah cause i was grepping the logs
<toothbrush0>i did say "carefully-worded"
<toothbrush0>:PP
<davexunit>yes
<davexunit>indeed
<toothbrush0>xd1le: http://elephly.net/downies/poster-v3.pdf
<toothbrush0>we're the smug sandal-wearing vegetarian cousin, or something like that? :P
<eiz>The bullet points are interesting facts, but they don't really explicitly say "here's why you should care about this." What's better about using Guile instead of nix? As a 100% newcomer, I'd heard of both, but I don't have enough experience to compare them.
<xd1le>rekado: wow, that is an amazing poster, nice work. :D
<xd1le>but yes, as eiz says, all these points work for nix too i think.
<xd1le>although
<xd1le>guix does have a manifest file feature
<davexunit>sure, but we don't need to conflate explaining what Guix is with differentiating from Nix
<xd1le>i don't think nix has that
<civodul>toothbrush0: re wrapper, the problem is that there's only a handful of people who know/understand the differences
<civodul>and i agree with davexunit, i prefer a positive description ("this is foo and bar") than a negative description ("this is like Nix, except foo and bar")
<davexunit>I think addressing the Nix heritage somewhere is important, because civodul had very good reasons for going his own way.
<xd1le>well for me personally, software freedom is a good enough reason anyway
<davexunit>but yes, a positive description displayed prominently on the home page is good.
<civodul>xd1le: Nix doesn't have --search-paths, for instance, --search, etc.
<xd1le>as long as the man power to maintain it exists
<civodul>davexunit: Nix is mentioned in "About" and other places, not sure what we should do
<toothbrush0>civodul: sure, but from a naive point of view it may look like we're pretending nix doesn't exist
<xd1le>but yes people will be more interested in technical differences in general
<civodul>toothbrush0: so what do you think should be done about it?
<civodul>(all the announcements mention it, BTW)
<davexunit>civodul: maybe on that page we could expound a bit, in a nice way, about what makes our project different.
<xd1le>civodul: what does --search-parts do?
<rekado>I really don't think we need to explain the relationship to Nix more prominently than what's already there on the About page.
<davexunit>we do mention Nix plenty.
<xd1le>*paths
<rekado>xd1le: --search-paths prints environment variables you may need to set.
<rekado>e.g. when you have a python package installed it'll tell you to set PYTHONPATH to *something*.
<civodul>xd1le: see http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
<xd1le>interesting, i wonder why nix does not have that, would be rpetty handy
<civodul>xd1le: because there's no package abstraction in Nix
<civodul>only derivations
<toothbrush0>civodul: i personally think we're fine, but i can see external people wondering if we're hiding the nix heritage (just looking at the website)
<civodul>toothbrush0: how could we address that concern?
<toothbrush0>concretely, i'd say have at least one link to nixos.org with the above-discussed carefully-worded sentence explaining the divergence
<xd1le>civodul: ahh i see.
<rekado>has this concern ever been voiced? Repeatedly?
<toothbrush0>rekado: maybe i'm overreacting, but the HN thread gave me that impression
<civodul>rekado: Nix people raise this concern
<civodul>toothbrush0: more than https://www.gnu.org/software/guix/about/ ? elsewhere?
<rekado>all discussions about Guix on HN have been in response to release announcements and they do mention Nix more than I think is warranted.
<toothbrush0>ah okay, i just grepped the landing page
<toothbrush0>perhaps.
<civodul>it's really weird
<toothbrush0>yeah maybe it's fine the way it is, i understand we of course don't need to slavishly bow to them till the end of time
<civodul>i mean Nix is pretty much our compiler back-end at this point
<civodul>it's as if people were screaming at $somecompiler because it doesn't mention LLVM on its front page
<davexunit>hahaha
<toothbrush0>civodul: true, perhaps we should let the screamers scream :). i'm just relatively sensitive to that i think, so don't necessarily listen to me :)
<civodul>toothbrush0: on the contrary, i find it useful feedback!
<civodul>but i'd like concrete suggestions :-)
<kmicu>If Nix leftovers are ‘pretty much’ only compiler than you don’t need to libstore/NARs/libutils/etc… remove them.
<civodul>kmicu: compiler *back-end* :-)
<toothbrush0>sure, so, there's mine. The single-sentence description with a link to nixos.org saying "originally inspired by nix but ...." or something? maybe more oblique, even.
<civodul>kmicu: with libexpr being the front-end
<rekado>civodul: do you intend to continue to sync the daemon code to keep it from diverging too much?
<civodul>rekado: i don't know, there's more churn in there than i'd like
<davexunit>we may need to start considering a rewrite in Guile
<rekado>or should someone™ begin rewriting the daemon in Guile and settle the issue this way
<rekado>ACTION types too slowly
<toothbrush0>davexunit: rekado: sounds great, but is it a very complex daemon? honest question, i've never looked.
<civodul>i'm also tempted to take the LibreSSL approch and get rid of everything we don't need
<davexunit>toothbrush0: somewhat complex yes, but seems doable.
<civodul>part of it is container management, which we now have with call-with-container
<davexunit>yeah that part won't be too hard now.
<civodul>part of it is derivations, nars, serialization, which we've had from day 1
<civodul>and the other part is tasks scheduling, which we don't have
<davexunit>I wish the protocol was sexp based :)
<davexunit>but maybe we can fix that some other day ;)
<civodul>heh
<fps>Gxsdnewb: haha, good idea ;)
<fps>Gxsdnewb: you'd have to compile guile to js though [using e.g. emscripten] and ship it and the package definition to the client first.. they might not run guixsd yet ;)
<Gxsdnewb>it would not for for guix users on other distros?
<kmicu>civodul: any plans for a lisp driven continues build system? Hydra (and nox–based Travis for PRs) sucks badly.
<rekado>Gxsdnewb: to install something into an existing store I think you could stop the daemon, chroot, start the daemon to work on the /gnu directory in the chroot, and then install packages.
<rekado>Gxsdnewb: but just installing cryptsetup would not help you much.
<rekado>you'd need to reconfigure the system as you want it to be part of the initrd.
<rekado>the existence of a store item is insufficient.
<Gxsdnewb>rekado: yes i think my error is initrd not supporting the disk crypto, which should be included when i initially ran guix system init! that is a huge bug i think.
<Gxsdnewb>I specified the luks-device-mapping dev in the system.scm
<rekado>specifying the device alone is not enough. The manual also says that you need to add stuff to the initrd, doesn't it?
<Gxsdnewb>rekado: should i run the guix-daemon from within the chroot so it is the copy of the binary on my target?
<rekado>Gxsdnewb: that's what I would do, yes.
<Gxsdnewb>karhunguixi: does your working luks setup have an uncommented initrd section? i looked at your scm and saw all mention to initrd commented out
<taylan>asking for opinions again: mupen64plus seems unreasonably difficult to get working out of the box on guix ('guix package -i' and run command), needing a bit of user configuration first instead. is there a place I can document the needed configuration to make this situation acceptable?
<davexunit>taylan: is it just setting env vars or more?
<karhunguixi|w>Gxsdnewb, no, it's commented/disabled
<taylan>davexunit: ini files, not env vars :(
<davexunit>hmmm
<taylan>the emulator community seems a bit weird in their programming practices. probably more Windows oriented. they all don't use any ./configure scripts either (seen in Nestopia, higan, and Mupen64Plus so far)
<Gxsdnewb>taylor: is it also not an ethical issue that these applications are almost exclusively used for running nonlibre software?
<Gxsdnewb>karhunguixi|w: and when you booted, it asked for decryption pw and loaded everything without error? what cipher and mode are you using?
<taylan>well I hope that won't be a blocker. we also have MS-DOS emulators though.
<civodul>kmicu: a Hydra "replacement" would be nice, but in the longer term; 'guix publish' provides part of the needed functionality, that's a start ;-)
<Gxsdnewb>taylor: DOSBox can run FreeDOS. But yes, technically a FLOSS emulator of a closed hardware platform can be used to develop and execute libre code on said platform, so they should be allowed
<Gxsdnewb>rekado: how can i examine if a specific initrd file has support for specific crypto algorithms i chose (or support for cryptsetup at all)?
<taylan>Gxsdnewb: it's taylan, not taylor :)
<rekado>Gxsdnewb: sorry, I don't know. I haven't done any initrd stuff in a long time.
<toothbrush0>civodul: i'm hesitant to give a final answer, but it looks like the build of core-updates is going better outside the VM
<civodul>Gxsdnewb: you can run "gunzip -c < $(guix system build yourconfig.scm)/initrd | cpio -tv"
<toothbrush0>time for me to learn about `guix publish` then :)
<fps>taylan: if you have a github account, you can drop it here until we have a better wiki: https://github.com/fps/guixsd-wiki/wiki
<fps>[re: "is there a place I can document the needed configuration to make this situation acceptable?"]
<Gxsdnewb>Is there a way to scan all items in the store, find which ones were downloaded as substitutes, then compile locally if they are?
<fps>bbl
<civodul>taylan: does the issue with Mupen64Plus come from packaging, or does it exist upstream?
<civodul>Gxsdnewb: problem is, you can't build them if they're already available
<Gxsdnewb>civodul: great! i should probably stop guix-daemon, chroot to the encrypted install, then run guix-daemon from there before executing that, right?
<civodul>hmm, dunno
<Gxsdnewb>civodul: that is a bug
<civodul>i'm not sure what your current setup is
<taylan>civodul: it's a mix of our isolation of packages and their lack of support for search paths of multiple directories
<Gxsdnewb>i have an encrypted guixsd install that can not boot because the initrd does not have the right modules, and there is also no cryptsetup installed. so i installed guixsd a 2nd time unencrypted and mounted the 1st install at /mnt
<Gxsdnewb>civodul: i noticed that a default desktop install does not install cryptsetup or gpg which i think is a big mistake
<taylan>hmm, maybe I can do something involving propagated inputs and patching the default (generated) config file, though said config file will need to contain an absolute file name in the user's $HOME...
<civodul>Gxsdnewb: these are things i install in my profile, with 'guix package -i'
<civodul>but you can add them to the 'packages' field if you prefer
<wingo>i tried to run brasero but it traps immediately, claiming it can't find its gsettings schema
<wingo>i wonder what the deal is
<wingo>is there some weird gsettings package i need to install, i wonder
<Gxsdnewb>civodul: but the packages are not even installed to /gnu/store ... i had to download substitutes post-install
<Gxsdnewb>I dont think i have ever used a GNU/Linux distro in the past several years that did not at least include GnuPG by default.
<bavier>Gxsdnewb: if you add gpg to your system config.scm, it will be installed during system init or reconfigure
<bavier>alternatively, you can install it as a user, like civodul mentioned
<wingo>maybe brasero just needs to be built with glib-or-gtk-build-system...
<toothbrush0>civodul: okay, twice in a row now outside the VM building has failed
<toothbrush0> http://pastebin.com/i39xUKhd
<rekado>Gxsdnewb: You can think of /gnu/store as a cache for builds. The base system doesn't require gpg nor cryptsetup. What exactly will be built/installed depends on the configuration. This is very flexible.
<toothbrush0>civodul: i think that it's perl that it's failing on.
<rekado>toothbrush0: please use a different paste site, such as paste.lisp.org.
<toothbrush0>rekado: i actually tried that one first, but it rejected it for being too big
<toothbrush0>and for curiosity: why?
<toothbrush0>i'm happy to oblige though
<Gxsdnewb>rekado: isn't gpg used for verifying sigs of substitute servers?
<rekado>toothbrush0: pastebin doesn't work for TOR users.
<wingo>indeed, brasero just needed glib-or-gtk treatment, neat
<civodul>wingo: i get SIGTRAP if Brasero is not installed in a profile, but it works well if Brasero is installed in a profile
<wingo>civodul: i had installed it using guix package -i
<wingo>on guix under nixos
<wingo>dunno, i am a week behind or so
<civodul>maybe XDG_DATA_DIRS and XDG_CONFIG_DIRS do not point to your profile?
<wingo>civodul: yes that is true
<wingo>but should they?
<civodul>yes, they do on GuixSD
<wingo>isn't the point of the glib-or-gtk-build-system to wrap the program and set them?
<taylan>hm, the user might install mupen somewhere else than $HOME/.guix-profile, so I see no way to patch the code such that it will generate a config file pointing to the right place (path of the profile the package will be installed to)
<rekado>toothbrush0: they say they are not actively blocking TOR, but any IP "that is causing way too much suspicious browsing behavior"; they don't say what "suspicious browsing behavior" is and TOR users often cannot use pastebin at all.
<wingo>civodul: actually in my case XDG_DATA_DIRS and XDG_CONFIG_DIRS point to nix things
<wingo>as 'globals'
<civodul>wingo: yes, but i think glib-or-gtk-build-system is partly redundant with what happens in the profile
<wingo>civodul: setting XDG_DATA_DIRS doesn't happen in my .guix-profile/etc/profile
<wingo>i.e. there is no such variable being set
<civodul>yes, that's unfortunate but expected ;-)
<toothbrush0>i'm still trying to find how small to make the paste for lisp.org :P pity they don't say "it's 50% too big" or something useful like that. i'm monte carlo'ing it now.
<wingo>civodul: wow :)
<wingo>that's terrible :)
<taylan>can a package definition arrange for notices to be printed when the package is installed, just like the "you might want to set these env vars..." notice?
<davexunit>taylan: no
<davexunit>that way lies craziness, I think.
<toothbrush0>civodul: okay, here it is http://paste.lisp.org/display/158636
<wingo>i just searched for XDG_DATA_DIRS in guix.info and it found glib-or-gtk-build-system as the first result
<wingo>that's why i did that
<wingo>if there is another 'solution' to this problem... well :)
<taylan>yeah, I think this is a really pathological case. I guess I might look into improving mupen to fix this craziness.
<wingo>i honestly don't know why these vars are not being set in the profile :)
<wingo>unless it's another case of 'package A doesn't work because package B which defines the environment variable isn't installed'
<civodul>because they belong to a library that's not explicitly installed in the profile
<civodul>right
<wingo>this is really terrible ux, civodul :)
<civodul>but you can help! :-)
<wingo>i am happy to do so but i don't understand why glib-or-gtk-build-system isn't the answer :)
<civodul>maybe it is, but i never fully grasped all the ins and outs :-)
<wingo>heh
<wingo>ok :)
<civodul>iyzsong: thoughts? ↑
<davexunit>we'd like to avoid wrapper scripts as much as possible, no?
<wingo>we clearly need a wiki so that idiots like me can post incorrect information that will bitrot amazingly :)
<davexunit>clobbering env vars isn't good.
<wingo>(that last bit was just me being silly)
<wingo>fml, i try to actually burn the disk and it asks me to install cdrecord
<wingo>all this is because a technician replaced the keyboard the other day, probably forgot to recable the mouse, i re-contacted warranty service, they want me to update the bios
<wingo>a pretty intense yakshave :P
<civodul>:-)
<civodul>for cdrecord, we could add a wrap-program call
<alezost>anthk_: re "How can I upgrade GUIX to 0.9.0 from 0.8.3": all you need is "guix pull"
<wingo>fml!!!!
<civodul>wingo: i filed a bug for the other issue, Cc'ing the experts ;-)
<wingo>i install xorisso
<wingo>$ xorriso-tcltk
<wingo>bash: /home/wingo/.guix-profile/bin/xorriso-tcltk: /usr/bin/wish: bad interpreter: No such file or directory
<civodul>file bugs! :-)
<anthk_>alezost: as a root user will work for the whole GUIX installation?
<alezost>anthk_: also as a user
<davexunit>anthk_: every user may use their own version of guix
<davexunit>so each user can choose when to upgrade
<alezost>anthk_: btw it is not GUIX, it is Guix
<alezost>anthk_: I think you don't even need to run "guix pull" as root, if you use guix only for your own user
<bavier>unless you want to update the guix that is used for `sudo system reconfigure`
<davexunit>ACTION does 'sudo ./pre-inst-env' from his git repo
<wingo>ffs there are no examples in xorisso's info file
<wingo>oh, they are later
<wingo>weirdest program ever
<Gxsdnewb>so i try to chroot --userspec=root:root /mnt but then it fails to log in as root in the chroot. this is my bash prompt:
<Gxsdnewb>I have no name!@host /#
<Gxsdnewb>and most commands are not available
<davexunit>Gxsdnewb: did you set PATH or anything?
<davexunit>the "I have no name!" thing is because there's no /etc/passwd or /etc/group
<davexunit>'guix environment --container' will display the same thing, for example.
<Gxsdnewb>davexunit: no, but echo $PATH returns a list of 5 directories
<davexunit>are they valid in the chroot?
<davexunit>your env is inherited from the process that did the chroot.
<davexunit>which probably includes things like your profile that certainly aren't in the chroot
<Gxsdnewb>davexunit: no it seems i am not seeing the fileystem contents of where i was tryking to chroot to
<Gxsdnewb>the /root is empty and / is just a handful of binaries. ls is not available
<alezost>bavier: anthk_ was asking about Guix installed on top of another distro, so I think he doesn't want want to use "guix system"
<bavier>alezost: got it. I missed that part of the context.
<zacts>hello
<zacts>what is the status of full disk encryption + lvm2?
<zacts>can I put lvm2 on-top of a fully encrypted gnu guix install?
<zacts>my setup is like |lvm2-swap + lvm2-root| <-- this all on top of a cryptsetup encrypted partition
<civodul>zacts: not yet, unfortunately
<zacts>ok
<zacts>so it's still the same issue?
<civodul>it's a different one ;-)
<zacts>I guess I may try to get around to looking further into it
<zacts>oh yeah? :-)
<civodul>namely, our grub.cfg doesn't contain the right insmod and so on
<zacts>well that shouldn't be too difficult to fix right?
<zacts>is it just a config issue, or is it something to do with dmd?
<zacts>or is your version of grub a fork?
<civodul>see https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00096.html for the report
<civodul>basically, we need to fix (gnu system grub) to generate grub.cfg containing the right things
<Gxsdnewb>civodul: not only that, but the initrd generation needs support for the ciphers, modes and hash algorithms
<civodul>Gxsdnewb: that part is OK AFAIK
<Gxsdnewb>hmm, well i think we should make a template file based on desktop.scm that includes luks support for nonlibre bios systems (needs separate unencrypted /boot) and a specific scm for libreboot systems
<taylan>so I added a little guix-specific patch to the mupen64plus-ui-console package which makes it print a big flashy notice with instructions for guix users when it fails to find plugins. this should be good enough I think.
<lfam>I am working on a package that some tests, but they have to run manually on the command line because they do not have a target in the Makefile? For example, after building I have to `cd tests && ./test`. Are there any packages I can look to as an example of how to use these tests?
<lfam>*I am working on a package that has some tests
<lfam>Sorry, that message made no sense. I will try again
<rekado>lfam: you can just replace the 'check phase and run them with (zero? (system* "./test"))
<lfam>rekado: Thanks for understanding my pre-coffee gibberish
<avoine>Is there is a way to I get my patched guix to be in the guix environment I'm building with it?
<avoine>ACTION is still trying to get btrfs file system to work
<paroneayea>woooo
<paroneayea>davexunit: guile-irregex now in guix master :)
<paroneayea>davexunit: would love to know if it proves useful to you
<lfam>I'm packaging a bunch of Lua libraries that work with different versions of Lua. What about the case where the program loading the library needs a specific version of Lua? While the program has the correct Lua in its environment, how to make sure that the library gets loaded by the correct Lua version? I'm afraid I don't understand how all these pieces come together.
<paroneayea>lfam: hello!
<paroneayea>lfam: oh, lua's specific path stuff is beyond my knowledge so I can't say
<lfam>paroneayea: Hi! It is currently beyond my knowledge as well. I am going to just build the libraries against the specific Lua version for now, and try to make them more flexible later. I guess I could adopt the Guix-Python convention of "python-program" "python2-program".
<Gxsdnewb>civodul: thank you for the command to examine initrd, i was able to find which kernel modules i am missing
<paroneayea>figured it out
<paroneayea>oops
<paroneayea>wrong channel
<Gxsdnewb> http://paste.lisp.org/+3EEW
<Gxsdnewb>I am not sure this is the correct syntax for my modified .scm for adding linux kernel modules. can someone familiar with Scheme syntax proofread it?
<Gxsdnewb>I am also unsure how much the order matters within the (operating-system) function, for example should the initrd section be before the mapped-devices and file-systems sections, or does that not matter?
<alezost>sneek: later tell Gxsdnewb in your system config you messed up the parentheses again: remove the closing one after "(apply base-initrd fs"
<sneek>Got it.
<alezost>sneek: later tell Gxsdnewb the order of fields in 'operating-system' declaration doesn't matter
<sneek>Will do.
<arianvp>francis7: kgpe-d16 yes
<arianvp>fps, civodul: hosting the wiki somewhere else sounds good to me as well. Also I'd love to contribute to documentation
<arianvp>any pointers on how contributing works?
<Gxsdnewb>arianvp: the recommended way is to write changes to the manual and submit a diff to the mailing list, i think
<sneek>Welcome back Gxsdnewb, you have 2 messages.
<sneek>Gxsdnewb, alezost says: in your system config you messed up the parentheses again: remove the closing one after "(apply base-initrd fs"
<sneek>Gxsdnewb, alezost says: the order of fields in 'operating-system' declaration doesn't matter
<Gxsdnewb>oh well that is a nice bot, thank you sneek and alezost!
<alezost>yw!
<alezost>sneek: good bot
<Gxsdnewb>guix refresh fails with error: no source release found for pypi package "pybedtools" "0.7.3"
<rekado>why do you use "guix refresh"?
<arianvp>That sounds tedious. but alright
<Gxsdnewb>ah, i guess i dont want to run that if want to compile locally to challenge against hydra
<arianvp>Gxsdnewb: I responded to your pm ;)
<paroneayea>nice job detrout !
<paroneayea>a new package in already! You're fast!
<detrout>well someone helped
<detrout>made significant improvements
<paroneayea>detrout: I had a lot more help than you on my first one :)
<paroneayea>mark_weaver had to hand hold me through a lot of stuff :)
<detrout>i made it to being a debian dev
<detrout>so ... i know somethings about packaging in general
<paroneayea>detrout: awesome
<detrout>just don't know a lot about scheme
<detrout>talking to coworker
<paroneayea>detrout: well that's even doubly great to have you on board then, your knowledge as a debian developer could be really helpful! :)
<paroneayea>yay for more community members!
<arianvp>detrout: I learned scheme... yesterday night
<arianvp>well sorta. I was able to read through the entire specification quickly in a day
<arianvp>(didn't remember all the details)
<arianvp>but I know enough now to read most stuff. The only thing that overwelms me is the amount of extesnibility the syntax has which is a bit overwhelming to me
<arianvp>(use-package-modules, vs use-service-modules, etc etc etc)
<paroneayea>some day soon while I'm procrastinating on something else
<paroneayea>maybe I'll write up that guile intro for the new site :)
<Gxsdnewb>hmm, so why when i su to root i cannot run commands in the profile of root? says ls is not found
<davexunit>did you set the appropriate env vars?
<Gxsdnewb>hmm it seems my PATH is totally wrong. even has refs to /usr/
<Gxsdnewb>it works on normal logins but not via su
<davexunit>is su creating a login shell?
<Gxsdnewb>no i dont think so
<Gxsdnewb>hmm, guix system init wants to download three different guile-2.0.9 files. strange!
<Gxsdnewb>iit also downloads guix 0.8.3...
<davexunit>Gxsdnewb: it's not the 0.8.3 release
<davexunit>it's a post-0.8.3 snapshot
<davexunit>probably extremely close to the 0.9.0 release
<davexunit>there's surely a commit SHA that is part of that version number
<rekado>has anyone here set up a pre-push hook to automatically run guix lint and reject pushing when the linter reports warnings?
<rekado>I'd like something like this.
<davexunit>rekado: how would you know what to lint?
<rekado>checking the commit message.
<rekado>the summary line.
<civodul>we could provide a commit hook
<civodul>coreutils has something for that
<detrout>I was wondering... how does guix deal with applications that want to do dbus activation?
<civodul>detrout: you add the service in the GuixSD configuration, and then D-Bus knows how to activate it
<civodul>this is used for polkit, geoclue, and some others
<detrout>ah... /me goes to read desktop.scm
<civodul>this is fairly new stuff
<civodul>partly explained in https://www.gnu.org/software/guix/manual/html_node/Service-Composition.html
<Gxsdnewb>karhunguixi: I am verry close to a working libreboot+ encrypted b/boot setup, but im not passing the correct root= switch to the kernel in the libreboot_grub.cfg
<karhunguixi>Gxsdnewb, oh, you've decryption nailed now?
<Gxsdnewb>i tried root=/dev/mapper/mountname and root=/dev/sda1
<karhunguixi>*hm, you have
<karhunguixi>i don' use any boot parameters
<Gxsdnewb>i think so, i loaded the correct kernel modules into initrd via your config example
<karhunguixi>i mean, i haven't specified any boot parameters
<karhunguixi>oh, so that's required on first boot it seems then
<karhunguixi>what kind of issue have you run into now?
<Gxsdnewb>i do not know where else in the system the title of the device mapper file is specified
<Gxsdnewb>for example, in my desktop.scm my mapped-device is /dev/mapper/guixcrypt so in the grub conf on the linux line there is --root=/dev/mapper/guixcrypt
<Gxsdnewb>..but both that AND --root=/dev/sda1 fail to boot, as it cannot find the ext4 filesystem
<karhunguixi>weird, i haven't had any issues with that
<karhunguixi>do you have a link to your config?
<Gxsdnewb> http://paste.lisp.org/+3EEW
<Gxsdnewb>do you have a link to your libreboot_grub.cfg?
<karhunguixi>why have you changed the %linux-modules modules?
<Gxsdnewb>That part is good, i need those modules to decrypt. the part that is not working is passing the root device name to the kernel
<karhunguixi>the modules initrd needs to decrypt are "dm-crypt.ko" and "xts.ko". So, if the problem is you don't have the updated initrd code where it's enabled by default you need these.
<sirgazil>Hi :)
<sirgazil>Does gpg --keyserver keys.gnupg.net --recv-keys 3D9AEBB4 work for you?
<sirgazil>I alway have to indicate another key server...
<sirgazil>I'm preparing to install Guix 0.9.0 binary.
<sirgazil>I remember that getting the public key from keys.gnupg.net failed as well when I installed Guix on another machine several months ago.
<karhunguixi>Gxsdnewb, i don't have a Libreboot grub.cfg yet. I still just type it in manually. I do it to rehearse on the commands.
<karhunguixi>But you're getting past this point, so i can't see there's a problem in this phase.
<Gxsdnewb>sirgazil: please never use short keyid format, as it is not considered cryptographically safe due to collisions
<sirgazil>I'm following this instructions: https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00131.html
<Gxsdnewb>sirgazil: you should use --keyid-format long where you can, and query for 64 bit keyids
<Gxsdnewb>karhunguixi: i looked inside my initrd and both xts.ko and dm-crypt.ko are included
<Gxsdnewb>you type the lines specifying linux and initrd manually?
<karhunguixi>no, for loading the GuixSD grub.cfg
<karhunguixi>"cryptomount ahci,gpt1" and "configfile (crypto0)/boot/grub/grub.cfg"
<Gxsdnewb>ah ok well can you paste your grub.cfg on your libreboot system then?
<karhunguixi>sure
<karhunguixi> http://sprunge.us/cUWN
<karhunguixi>my config.scm: http://sprunge.us/bVZi
<Gxsdnewb>sirgazil: try this: gpg --keyserver keyserver.mozilla.org --recv-key 0x090B11993D9AEBB5
<Gxsdnewb>sirgazil: in the future, only trust key IDs at least 64 bits long like that one
<sirgazil>Gxsdnewb: thanks, I will. I can download the public key from other servers, but I still wonder if keys.gnupg.net works at all, because that's the server used in the instructions...
<sirgazil>And the short key id too :)
<Gxsdnewb>the public keyservers share keys with each other in a federated fashion using the hkp protocol
<sirgazil>Yeah I know.
<Gxsdnewb>karhunguixi: takk! i think i found the problem.
<Gxsdnewb>did you pass --no-grub to guix system init ?
<karhunguixi>Gxsdnewb, konge! :) No, i just have an invalid bootloader device
<karhunguixi>so, what is the path you're pursuing now?
<karhunguixi>hm, "pursuing path" doesn't make sense. Let's pretend i wrote something that makes sense instead.
<Gxsdnewb>no luck. ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/mapper/guixcrypt is mounted.
<Gxsdnewb>The dm device is not being created
<karhunguixi>(looks like pursuing path is ok after all, i'll retract my previous comment)
<karhunguixi>Gxsdnewb, do you check this in the guile prompt?
<Gxsdnewb>no, i dont know what to type there, heh
<Gxsdnewb>it is the error messages
<karhunguixi>ok