IRC channel logs

2014-11-26.log

back to list of logs

<tadni`>So, can I ideally load a whole bunch of packages via (gnu packages '(emacs conkeror ratpoison etc etc etc)) over (gnu packages emacs) (gnu packages conkeror) (gnu packages ratposion) etc etc, in a config file?
<davexunit>no
<tadni`>davexunit: Would this not be a nicer solution than what we currently have?
<davexunit>I don't see it as a problem currently, but that's a feature request for guile, not guix.
<tadni`>It's not really a problem per-se, but once you start trying to load a bunch of package and service modules, it'll look very ugly in-comparison to what we could have.
<davexunit>it would be easy to write a macro
<davexunit>(use-package-modules emacs conkeror ratpoison)
<tadni`>Yeah, just mocking that up -- that looks a lot nicer. I'm going to add a sample and comment it out in my coinfig file. :^P
<davexunit>tadni`: for your own use, try this: (define-syntax-rule (use-package-modules module ...)
<davexunit> (use-modules (gnu packages module) ...))
<davexunit>
<davexunit>and you can define another one for services if you'd like.
<tadni`>Mis-matched parens?
<tadni`>Oh, sorry.
<tadni`>I missed the first comment.
<davexunit>yeah, it got formatted strangely
<davexunit>but yeah, the power of scheme is evident here.
<tadni`>What's with the elipsis?
<davexunit>'module ...' means 'match zero or more sexps and bind them to the syntax variable "module"'
<davexunit>it's part of scheme's macro system
<tadni`>davexunit: Ah, okay.
<davexunit>macros are awesome. now your life is easier and you didn't have to wait for us to do something. :P
<tadni`>Well, that's a crazy easy patch to add nice formating then -- if it's really that easy.
<davexunit>it's that easy. I tested it.
<davexunit>I included the (gnu packages emacs) module with it and inspected the 'emacs' variable
<davexunit>it was what I expected.
<tadni`>davexunit: Playing with it right now. VERY cool, ty. :^)
<davexunit>yw!
<davexunit>enjoy your 'practical software freedom'.
<tadni`>Yeah, in 2015 I really need to hit Lisp hard. I don't think I've even really scratched the surface yet.
<tadni`>Hm, I wonder what I need to load on Guile's end in this config file to get this use-packages-modules working.
<tadni`>Oh well, I'll look into it more tomorrow probably. Bed for now. Peace. o/
*tadni` is afk.
<civodul>Hello Guix!
<nkar>Hello Civodul!
<jmd>Anyone know how to deal with this:
<jmd> 619: 3 [for-each #<procedure 4edda0 at scripts/compile.scm:179:14 (file)> #]
<jmd>In scripts/compile.scm:
<jmd> 182: 2 [#<procedure 4edda0 at scripts/compile.scm:179:14 (file)> "guix/base32.scm"]
<jmd>In system/base/target.scm:
<jmd> 57: 1 [with-target "armv7l-unknown-linux-gnueabihf" ...]
<jmd>In unknown file:
<jmd> ?: 0 [scm-error misc-error #f "~A ~S" ("unknown CPU endianness" "armv7l") #f]
<jmd>
<jmd>
<civodul>yes!
<civodul>jmd: which Guile is giving that?
<civodul>is it the 2.0.9 bootstrap Guile?
<jmd>civodul: I think its the 2.0.11 bootstrap guile
<civodul>hmm
<civodul>oh you're right, this was fixed in 2014-07-04, after 2.0.11
<civodul>damn, we need to release 2.0.12
<civodul>in the meantime, you'll have to apply Guile commit ffd3e55c
<jmd>And then rebuild the bootstrap tarball ?
<civodul>actually, when do you get this error?
<jmd>Building guix
<civodul>ah, ok
<civodul>natively?
<jmd>Yes.
<civodul>damn it, you need to push an ARM branch!
<civodul>:-)
<jmd>I will do that.
<civodul>so in that case, just remove the --target=xxx in Guix's Makefile.am
<jmd>Hmm. Where does that appear in the Makefile ?
<jmd>I don't have automake locally.
<civodul>yes, you can edit the Makefile directly, then
<civodul>or Makefile.in
<jmd>Next issue: ice-9/boot-9.scm:106:20: In procedure #<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: __errno_location
<jmd>Makefile:3874: recipe for target 'guix/pk-crypto.go' failed
<jmd>
<civodul>could you try "objdump -T /lib/libc.so.6 | grep errno_loc"?
<jmd>I dunno if I have objdump but I will try.
<jmd>nitrogen6x:~/guixobjdump -T /lib/libc.so.6 | grep errno_loc
<jmd>
<civodul>ok
<civodul>and guile -c '(pk (dynamic-func "__errno_location" (dynamic-link)))' ?
<civodul>is it a statically-linked Guile?
<jmd>Yes. It's the bootstrap one.
<civodul>ah, that's the reason, then :-/
<jmd>and the solution ?
<civodul>in (guix build syscalls), just replace (dynamic-func ...) with #f
<civodul>for __errno_location
<jmd>presumably a similar problem will occur for every other dynamic-func ?
<civodul>no, just the libc stuff
<civodul>well ok, there are many others
<civodul>let's do this: replace (dynamic-link) with (dynamic "/lib/libc.so.6") in that file
<jmd>Do you mean dymanic-func ?
<civodul>no, i mean the calls to 'dynamic-link' with zero arguments
<civodul>oh yes, (dynamic-link "/lib/libc.so.6")
<jmd>sed -i 's/dynamic-link/dynamic-link "/lib/libc.so.6"/g'
<jmd>In unknown file:
<jmd> ?: 1 [dynamic-link "/lib/libc.so.6"]
<jmd>In ice-9/boot-9.scm:
<jmd> 106: 0 [#<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
<jmd>
<jmd>ice-9/boot-9.scm:106:20: In procedure #<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "/lib/libc.so.6", message: "file not found"
<jmd>Makefile:3874: recipe for target 'guix/pk-crypto.go' failed
<jmd>
<jmd>Odd. /lib/libc.so.6 certainly is there.
<civodul>grr
<civodul>just comment out everything below the define-module form in that file
<civodul>after all, it's not needed for what you want
<jmd>brb
<jmd>basically, you're saying comment out the whole file?
<jmd>ice-9/boot-9.scm:106:20: In procedure #<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: no binding `errno' in module (guix build syscalls)
<jmd>
<civodul>commenting out below the define-module form
<jmd>This is getting too complicated.
<civodul>:-)
<civodul>but i *think* it'll really get further by just commenting out below the define-module form
<jmd>Yes. It got a bit further.
<jmd>Now I'm at ?: 1 [dynamic-func "fcntl" #<dynamic-object #f>]
<jmd>In ice-9/boot-9.scm:
<jmd> 106: 0 [#<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
<jmd>
<jmd>ice-9/boot-9.scm:106:20: In procedure #<procedure 4ef740 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<jmd>ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: fcntl
<jmd>Makefile:3874: recipe for target 'guix/pk-crypto.go' failed
<jmd>
<duncankl>Hello #guix, just did my first usb install of 0.8 and it was a breeze
<civodul>jmd: this time in (guix utils); try commenting it out as well...
<duncankl>previously tried 0.7 but I couldn't get the live usb to boot, so great progress
<civodul>good news, thanks :-)
<civodul>duncankl: did you stumble upon bugs, weird behavior, etc.?
<duncankl>now I'm trying another install with full disk encryption, but it looks like I'm having identical issues to nkar
<jmd>Different problem now :(
<civodul>ok
<jmd>/bin/sh: line 5: 6692 Segmentation fault LC_ALL=C ./pre-inst-env /home/john/bsb/bin/guild compile -L "." -L "." -Wformat -Wunbound-variable -Warity-mismatch -o "guix/pki.go" "guix/pki.scm"
<jmd>
<duncankl>also it would be very handy to have cryptsetup on the install usb :)
<civodul>yes, i fixed that when nkar reported it
<civodul>but yeah, we need to fix that bug
<duncankl>great!
<civodul>jmd: this time it's really getting too complicated :-/
<nkar>duncankl: if you can live with only /home being encrypted, it already works
<duncankl>sounds good enough, is that what you've stuck with?
<duncankl>noticed that wpa-supplicant is in the package list, have people had success with wifi?
<nkar>duncankl: I'm planning to wait a little bit hoping that someone provides some hints. if not, I'll encrypt just /home. also, I now have a motherboard which is compatible with libreboot, which allows to encrypt everything (even /boot), so I'm hoping to try that as well
<civodul>nkar, duncankl: i just replied to the bug report with an idea to get more info
<civodul>would be great if one of you could take the time to try it out
<duncankl>do you have a link?
<duncankl>found it
<civodul>cool
<civodul>re wifi, i use wifi with the ath9k driver + firmware
<civodul>i haven't tried wpa-supplicant, because it's plain old WEP at home :-)
<duncankl>ok, I'll try it out in a while
<jmd>I think I'll have to try getting a proper guile cross-compiled.
<jmd>Last time I tried it was not easy.
<duncankl>I noticed the --cryptdevice=... flag is missing from the kernel parameters when I edit the entry from GRUB
<duncankl>but I get the same result when I add it manually as if I leave it out
<duncankl>maybe it's just needed further along in the boot process
<civodul>--cryptdevice ?
<civodul>i think there are two things here: 1/ the GRUB parameter shown in nkar's bug report, and 2/ getting the initrd that we generate to correctly invoke cryptsetup and all that
<duncankl>on other linux systems I have used it like this: cryptdevice=/dev/sda2:root
<civodul>on the kernel command line?
<duncankl>yep
<civodul>ok
<civodul>i think that's because their initrd parses it that way
<civodul>but that's not the case here, there's just --root
<civodul>and the initrd already knows that it must handle device mapping
<duncankl>I see
*civodul goes afk for a bit
<civodul>nully: it seems that hydra.gnu.org is abnormally slow these days, any idea what it could be?
<guixnoob>hi guys! can someone tell why this warning appears when I try to install some packages: substitute-binary: guix substitute-binary: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
<duncankl>just replied to the cryptsetup bug, hope I got the gnu bug tracker to accept it
<nkar>duncankl: yeah, I got it
<duncankl>cool
<civodul>duncankl, nkar : i replied about the initrd issue
<civodul>guixnoob: it means that "substitutes" cannot be used, because the access control list (ACL) is currently empty
<civodul>guixnoob: see http://www.gnu.org/software/guix/manual/guix.html#Substitutes
<guixnoob>civodul: thanx, seems to work now
<nkar>civodul: so it's not possible to fix it temporarily from the recovery shell, right?
<civodul>nkar: hmm, you could try to get it booting, and then run "guix system reconfigure" from a checkout
<civodul>to get it booting, you'd have to wait until you get the debugger prompt
<civodul>then type ",locals" to see all the arguments passed to 'boot-system'
<civodul>then call 'pre-mount'
<civodul>and then call 'boot-system' with the same arguments that it had, but with #:pre-mount #f
<civodul>see what i mean?
<civodul>that's a bit involved :-)
<nkar>civodul: wait, but how can I run 'guix system reconfigure'? you mean via 'system'?
<civodul>nkar: you'll be able to run it once you've managed to boot the installed system
<civodul>(following the recipe i gave above)
<nkar>ahm, okay
<civodul>the FSF asks for a "writing sample" in its job offer
<civodul>does that mean hand writing?
<tadni`>civodul: I'm assuming just an article.
<civodul>hmm, ok
<tadni`>As in, a typed text written article.
<civodul>that sounded strange to me
<nkar>no no, it's a common term
<tadni`>civodul: They probably want to test your ability to be able to write up a piece for fsf.org if need be.
<davexunit>yeah, I think that's why we ask for it. the outreach person does a lot of writing on our behalf.
<civodul>yeah right, for a "communication" position, it probably makes a lot of sense
<nkar>civodul: thinking of applying? :)
<civodul>do you really think i'd be a good "outreach person"? ;-)
<nkar>definitely
<nkar>though, the job is on-site anyway
<civodul>heh
<davexunit>our old outreach person is going to the EFF
<davexunit>he was awesome. bummed that he's leaving.
<civodul>heh, competition between these two fine organizations
<civodul>wip-arm, yay!
<tadni`>civodul: Oh, neat!
<civodul>thanks to jmd!
<tadni`>davexunit: With that macro you gave me last night, what should I load in-terms of Guile in my use-modules to get it going? :^P
<tadni`>Right now, it complains (unbound-variable #f "Unbound variable: ~S" (use-packages-modules) #f).
<davexunit>tadni`: you shouldn't need anything else. just include the macro in your config file before you use it.
<tadni`>davexunit: Yeah, I JUST figured I needed to append (use-modules (gnu packages)(gnu service) etc) in prior to it.
<davexunit>yeah
<davexunit>well, you only need that for the %base-packages and %base-services variables
<davexunit>that doesn't impact the macro
<tadni`>Hm, now I have an unbound variable for grub-configuration.
<tadni`>Yeah, that makes no sense... grub-configuration works and has a value via the old method, but via this macro it doesn't.
<davexunit>are you missing the (gnu) module?
<tadni`>davexunit: As in, just soley (gnu) no submodule?
<tadni`>Yeah, I don't.
<davexunit>try that
<tadni`>Well, it's not failing right off the back ... so that's a good start!
<tadni`>davexunit: Yup, it suceeded! You're such a sweetheart. :^) Ty, very much.
<davexunit>heh
<davexunit>you're welcome
<tadni`>Sans having the macros in the same source file, I really do think this looks much, much better for the config file and would scale better.
<davexunit>civodul: tadni` proposes that we add a macro or two to make including package/service modules easier (less typing) when writing OS config files.
<davexunit>it was trivial to write a 'use-package-modules' macro that did that. don't know what your thoughts are about including things of that nature in the (gnu) module or something.
<tadni`> http://paste.lisp.org/+33HP
<tadni`>That's what my config.scm looks like currently.
<davexunit>neat :)
<tadni`>But yeah, I'm not sure of an argument against such a thing being included upstream. Especially since you could still do either or, or both in the same config file regardless.
<taylanub>I wonder, has it been considered to call the distribution "Guix GNU", akin to how some GNU/Linux distros call themselves "Foo Linux"? :P
<taylanub>but I guess Felipe López &co. would not be satisfied, because it would get shortened to "Guix" all too often .. which I kind of have to agree with as well; it's somehow insatisfactory.
<tadni`>taylanub: I mean too, an issue there is the software stack for the GNU Distro is not just Guix. Dmd is also a relevant piece of tech. Calling it simply GNU, makes it clear theat the core parts are being maintained by GNU in some way.
<bavier`>so, I've got a source url that appears to send `guix download` into an infinite loop, but wget seems to do just fine. Any ideas?
<nkar>sourceforge?
<bavier`>tigris.org
<nkar>user-agent, maybe?
<bavier`>the given url redirects to a second url, which redirects to the first, and so on. I think `guix download` continues to follow these redirects, whereas wget (and icecat, etc) "reuse [the] existing connection"
<nkar>but why does it redirect guile while allowing wget to download?
<bavier`>they both get redirected
<bavier`> http://delta.tigris.org/files/documents/3103/33566/delta-2006.08.03.tar.gz
<bavier`>^ that's the url
<civodul>davexunit: re use-packages-modules and use-service-modules, yes, that sounds like a good idea
<nkar>civodul: have anything to add to the things mentioned in the reply to my bug report?
<civodul>nkar: i don't think so, should i?
<duncankl>I'm retrying now with all the kernel modules added
<civodul>great, thanks duncankl
<duncankl>I can test a new VM image too
<civodul>bavier`: still there's something wrong with that URL, no?
<civodul>i mean, we could detect cycles, but the end result would be a failure anyway
<nkar>yeah, I'd like to try a new image, too. how do I create it?
<nkar>is it in the manual?
<bavier`>civodul: wget and browsers are able to download the tarball from it
<bavier`>for now I'm using the debian mirror of the tarball, but I think we were trying to avoid that
<nkar>bavier`: wget has a flag to specify the user-agent. try setting it to something weird.
<nkar>maybe they whitelist certain user-agents and block the rest
<civodul>nkar: it's in the manual, under "System Installation", but we first need to update the 'guix-devel' snapshot
<nkar>guix-devel snapshot?
<civodul>in (gnu packages package-management), as i wrote in the report
<civodul>bavier`: could you file a bug? i don't know how this is supposed to work
<civodul>the URL above makes w3m fails, FWIW
<bavier`>nkar: even passing --user-agent=guix, wget is still fine
<nkar>cookies?
<bavier`>civodul: ok, if w3m fails, then sure, I'll file a bug
<civodul>actually, w3m failing would be an argument for *not* filing the bug ;-)
<civodul>wget succeeding means we got something wrong
<bavier`>it looks like a widespread issue with the tarballs on tigris.org
<duncankl>civodul: I got the same result after adding all the modules from the initial bug report
<civodul>uh
<civodul>duncankl: do you have another GNU/Linux system with an encrypted root? :-)
<civodul>would be nice to see which modules are used etc.
<duncankl>hmmm, I'll see if I can find what I'm using currently
<nkar>civodul: I just found out that my store contains only 11 dirs, so there's no cryptsetup. where did I make a mistake?
<civodul>nkar: the store on the encrypted root?
<nkar>yep
<nkar>after running the scandir command that you suggested
<civodul>that's the root of the initrd, not the root of your hard disk
<nkar>ah
<nkar>right
<civodul>but there should be cryptsetup among them
<nkar>civodul: how did you determine the list of linux modules in the first place?
<alezost>civodul: I tried "M-x guix-pull" today and the REPL was restarted successfully (the prompt was "build-self")
<nkar>there's a command that can be used for this; it should be mentioned in the cryptsetup faq
<alezost>civodul: did you modify `guix-after-pull-hook' by any chance?
<duncankl>here are the kernel modules I'm currently using which seem related: dm_crypt dm_mod cryptd aes_x86_64 aesni_intel crc32_pclmul crc32c_intel
<nkar>duncankl: where can I read what each of them does?
<duncankl>not too sure, I usually search around to find each one
<nkar>does cryptsetup luksDump <device> (I hope it's the right command) print anything useful?
<duncankl>just information on the cipher, hash, salt, key slots etc.
<taylanub>guix insists on building g5qcn8c09da8wfg9x5vb37ms8l89spnf-gcc-cross-boot0-4.8.3.drv and won't fetch it from Hydra...
<taylanub>ah wait, this might be my silliness from having this patch to guix/build/utils.scm
<civodul>alezost: no
<civodul>taylanub: yes, indeed; don't apply it locally
<civodul>nkar: i think i looked at the modules my previous distro was using
<civodul>very unscientific :-)
<alezost>civodul: I can't reproduce it, sorry
<nkar>civodul: there's 'modinfo <module>' for a short description
<civodul>yes, sure
<nkar>will you update the snapshot, then?
<civodul>i will, but i want to see how far we get today with what duncankl & you find out
<duncankl>dm_mod looks important, I assume it is included by default?
<duncankl>how can I find the list of loaded modules in the Guile REPL?
<civodul>(call-with-input-file "/proc/modules" get-string-all)
<duncankl>thanks
<civodul>aka. 'cat' ;-)
<civodul>you need to ,use(rnrs io ports)
<duncankl>here is the full list of modules reported from the repl: sha256_ssse3 xcbc pcbc crc32 aes_x86_64 dm_crypt pata_atiixp pata_acpi achi libahci
<nkar>I think we could just try to add the ones you mentioned previously. then figure out which are required
<duncankl>yep, I think I'l try adding cryptd and dm_mod
<nkar>okay, let us know how it goes
<duncankl>hmm, during guix system init: module not found "dm-mod.ko"
<duncankl>"cryptd.ko" gets added happily enough though
<civodul>duncankl: it may be that the real file name is "dm_mod.ko"
<duncankl>I think I tried that too, I'll have another go though
<civodul>the commands accept hyphens and underscores interchangeably
<civodul>but the initrd maker wants the real file name
<civodul>that said, there's nothing matching dm*mod* in my module tree
<duncankl>no luck after adding cryptd, same errors as before
<civodul>duncankl: :-(
<civodul>could you post the list of modules that you've tried to the bug report?
*civodul -> zZz
<duncankl>ok, I'll try a few more then post them
<civodul>thanks a lot
<civodul>good night/day!