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? <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>(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>and you can define another one for services if you'd like. <davexunit>but yeah, the power of scheme is evident here. <davexunit>'module ...' means 'match zero or more sexps and bind them to the syntax variable "module"' <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>I included the (gnu packages emacs) module with it and inspected the 'emacs' variable <tadni`>davexunit: Playing with it right now. VERY cool, ty. :^) <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/ <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> ?: 0 [scm-error misc-error #f "~A ~S" ("unknown CPU endianness" "armv7l") #f] <jmd>civodul: I think its the 2.0.11 bootstrap guile <civodul>oh you're right, this was fixed in 2014-07-04, after 2.0.11 <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? <civodul>damn it, you need to push an ARM branch! <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 <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 <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 <civodul>and guile -c '(pk (dynamic-func "__errno_location" (dynamic-link)))' ? <jmd>Yes. It's the bootstrap one. <civodul>in (guix build syscalls), just replace (dynamic-func ...) with #f <jmd>presumably a similar problem will occur for every other dynamic-func ? <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> ?: 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>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>Odd. /lib/libc.so.6 certainly is there. <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>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) <civodul>commenting out below the define-module form <jmd>This is getting too complicated. <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>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 <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>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 :( <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" <duncankl>also it would be very handy to have cryptsetup on the install usb :) <civodul>yes, i fixed that when nkar reported it <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 <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 :-) <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>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>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 *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 <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 <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>and then call 'boot-system' with the same arguments that it had, but with #:pre-mount #f <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>the FSF asks for a "writing sample" in its job offer <tadni`>civodul: I'm assuming just an article. <tadni`>As in, a typed text written article. <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>though, the job is on-site anyway <civodul>heh, competition between these two fine organizations <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>well, you only need that for the %base-packages and %base-services variables <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. <tadni`>davexunit: As in, just soley (gnu) no submodule? <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. <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`>That's what my config.scm looks like currently. <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? <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? <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? <duncankl>I'm retrying now with all the kernel modules added <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? <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 <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 <bavier`>nkar: even passing --user-agent=guix, wget is still fine <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>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>after running the scandir command that you suggested <civodul>that's the root of the initrd, not the root of your hard disk <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>taylanub: yes, indeed; don't apply it locally <civodul>nkar: i think i looked at the modules my previous distro was using <alezost>civodul: I can't reproduce it, sorry <nkar>civodul: there's 'modinfo <module>' for a short description <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>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>could you post the list of modules that you've tried to the bug report?