<roptat>Seems to wwrk anyway, buc line breaks are broken <roptat>And so, the issue might be my cable <Copenhagen_Bram>since wgetpaste doesn't work i'll just install netcat and use termbin <jonsger>roptat: do you know which exact openSUSE version the overdrive runs? <roptat>No, but I'm going to bed. I could access the console after all, so I'll try with a known good ethernet cable tomorrow <jonsger>roptat: if its Leap 15.0 you can just do a "zypper install guix" <jonsger>roptat: and "zypper install libgit2-devel" maybe. If guix has weird issues... <reepca>what's the difference between NIX_STORE and NIX_STORE_DIR if any? <raghavgururajan>So I tried re-installing GuixSD with BIOS Bootloader on the disk. Still booting fails. How can I overcome this? Please and thank you. <raghavgururajan>Moreover, I used x86_64 setup. But there is error that /boot/i686/vm.mod not found. How this is happening? <buhman>if I understood section 2 and section 3.2 correctly, it seems like each of these paths have different symlink targets <buhman>as far as I've read nothing actually cares about the value GUIX_PROFILE, so this seems like a benign documentation bug unless I've misunderstood this? <reepca>buhman: ~/.guix-profile/etc/profile cares about GUIX_PROFILE, since it uses that to figure out where it should set environment variables to (the place ~/.guix-profile symlinks to has no knowledge of where it'll be symlinked to from, and may in fact be symlinked to from multiple places). So that information needs to be supplied at runtime. <buhman>reepca: I see; is it intended that ~/.config/guix/current/etc/profile also uses this same variable? <buhman>it seems that .config/guix/current and .guix-profile are different store paths, unless my installation is broken/incorrect <reepca>buhman: aye, it's also a "guix profile". <buhman>a *different* profile though, right? <buhman>maybe it should have a distinct name? <reepca>not sure what you mean. It is a guix profile in the same sense as ~/.guix-profile is also a guix profile. ~/.guix-profile is where "guix package" operates by default, and ~/.config/guix/current is where "guix pull" operates by default. <reepca>~/.config/guix/current just happens to only have one package installed, namely guix. <buhman>I noticed. I just found it a bit unexpected to write an /etc/profile.d that (re)defines GUIX_PROFILE twice, with different values <reepca>note that defining GUIX_PROFILE isn't strictly necessary, it just tends to make things prettier and work more smoothly. For example, with GUIX_PROFILE defined prior to sourcing ~/.config/guix/current/etc/profile, I get ~/.config/guix/current/bin in my PATH. Without it, I get /gnu/store/irdc83698ifjybd68z4wfz9w85c4h84c-profile/bin in my PATH. <reepca>But then if I run "guix pull", the directory ~/.config/guix/current is symlinked to changes, and I'd need to re-source ~/.config/guix/current/etc/profile to use the new version. <reepca>on Guix System the default /etc/profile handles all of this for me, though. <buhman>(I'm trying to say maybe the /etc/profile could be a little less imperative-looking if each profile used a different environment variable) <buhman>but I also see how it makes sense, maybe, if they are both the same kind of thing, that you would source them with the same "protocol". <reepca>hmm, in my mind the "functional" way of doing things in shell script is to prefix the command with the variable definitions each time (e.g. "PATH=/some/place which emacs"). I wonder if that works when the command is "source"? <reepca>so you could write "GUIX_PROFILE=~/.guix-profile source ~/.guix-profile/etc/profile ; GUIX_PROFILE=~/.config/guix/current source ~/.config/guix/current/etc/profile" <cbaines>Something's gone a bit wrong, this is the error I get when running guix package -s foo <cbaines>Throw to key `parser-error' with args `(#f "Unknown command" defn)'. <olivuser>Hello everyone. Can anyone explain how to install extensions to icecat in guixsd? <cbaines>olivuser, I don't think any icecat extensions are packaged, at least outside of icecat <cbaines>so I'd just install them through the Mozilla addons site or the Free Software Directory which I think lists some <divansantana>Like my nonroot account can't access dockerd by default. Do I run everything as root via sudo? Is that best? <divansantana>adding my user to docker account makes my user root equivelent. <rekado_>cbaines: I can’t reproduce this. What version? *rekado_ goes afk for a while <cbaines>rekado_, I've just pushed a couple of commits to master which I think resolve the issues <cbaines>Try guix package -s on f4f8c23bae3167e16ae29d9f48ca26c39e875613 <raghavgururajan>Hi! Is there a standard list that shows all modules available in GuixSD? <rekado_>I’m doing a merge of master into core-updates and I wonder what to do about the translated manuals. <rekado_>because it looks like most of the changes are unexpected for a merge. <roptat>as long as master has up-to-date manuals, I guess it's fine either way, no? <civodul>rekado_: were there other issues with the merge? i think someone mentioned that in Brussels <rekado_>the big module splits make it a little trickier than usual <rekado_>another source of confusion is patches. <rekado_>I’m trying to verify now that all referenced patches are in fact available. <rekado_>I see this: WARNING: (guix scripts system): `build' imported from both (guix status) and (guix store) <rekado_>make dist doesn’t like the embedded store path in a comment of gnu/packages/patches/binutils-boot-2.20.1a.patch <rekado_>other than that it seems that the merge was successful. <roptat>what is still needed before we can merge staging in master? <rekado_>I’d like to propose using the bug tracker for keeping track of the answer to this question in the future. <rekado_>we should have a bug open for merging staging which references bugs that block the merge. <roptat>I'm trying to see how much of my store has packages which reference themselves. I found that java packages always have self-reference through META-INF/INDEX.LST for instance <janneke>rekado_: ah, oops. that should be removed, can safely be removed because it's in a comment <civodul>roptat: we're missing icecat on x86_64, but apart from that x86_64 is ready (staging) <roptat>does icecat fail, or is not yet built by a build farm? <civodul>it's timed out a couple of times already, so i don't know <civodul>building /gnu/store/56v8rbdvywcpg5fyj8by1c2a7szngpbz-rust-1.24.1 right now <civodul>efraim: did you push to guix-artwork.git yet? <lfam>Do we have a policy on whether or not man pages can be installed from upstream source tarballs or if we have to rebuild them ourselves? <lfam>FSDG discusses the license of documentation but not this exact question <civodul>sneek later tell lfam we don't necessarily rebuild Info and man documents *civodul has a lead for the >>= bug, otherwise know as the info-dir bug <civodul>we should do like for security vulnerabilities <civodul>design a logo, have a web site, etc. <civodul>i seem to have a workaround, and that makes me happy :-) <civodul>chatting with wingo the other day helped a lot! <civodul>it stops right before the first MIME part <rekado_>I thought that was an intentional cliff hanger <wingo>on the plus side, it's not a deep dark VM bug, and not a module system bug <wingo>on the negative side, i am going to look to see why defining a syntax parameter object twice does what it does... <rekado_>(it’s an sxml parse error; debbugs must have mangled the email…) <wingo>i suppose there is a hazard for parallel compilation of any set of modules that contains top-level state (closures, etc) <civodul>it's just that it mutates the run-time env and so there's a chance you get to see the wrong value <wingo>and syntax parameters are just a fancy compile-time box :P <wingo>hum, afaiu that definition will prevent >>= from being redefined later <wingo>i mean if you're doing incremental development <wingo>i think it's a very good workaround for guix and for fundamental things that you won't redefine :) <civodul>but that's a limitation i'm willing to accept :-) <wingo>need to think more about what a general right thing is <civodul>i'll push the workaround here and in (guix gexp) <wingo>it would nice to be able to fix this for all instances of define-syntax-parameter <wingo>btw i didn't notice but ecraven's benchmarks have guile 2.9.1 <civodul>yes, there are only 4 of them in Guix, so we'd only need to duplicate it once <wingo>still some cases where we need to improve generated code <wingo>anyway, off to look at syntax parameters... *civodul goes afk for a while <efraim>civodul: haven't pushed yet, I should be able to later tonight <wingo>civodul: just a brief brain-dump here... <wingo>the thing is that for syntax parameters, the associated "macro" objects (i.e., the things that are bound at top-level) are represented as Macro<StxParameterKind,List<StxTransformer>> <wingo>so defining a new top-level stx parameter is like (define-syntax foo (list f)), in a way <wingo>and syntax-parameterize of a top-level variable fetches that list, at compile-time, and conses on a new transformer on the front <wingo>syntax-parameterize of a lexical variable does the same but obvs the transformer itself is defined in the compilation unit so there's no sharing problem so it's not interesting <wingo>anyway, resolving the actual transformer for a given instance of a syntax parameter is basically "look up the identifier, find its #<macro> object, get the binding, notice it's a syntax parameter thererfore the binding is a list, so the transformer to apply is the first one in the list" <wingo>hence our race for syntax parameter X: thread A: bind X to a new list || thread B: resolve X to corresponding stack, cons on a handler for a lexical extent, then later look up X's binding <wingo>thread A's definition could come between thread B's syntax-parameterize and thread B's use. <raghavgururajan>Hello! Have any one tried Btrfs filesystem instead of ext4 on GuixSD? Is it better?. Looking for new perspectives. <wingo>i think a more reliable solution that would also permit redefinition would be for a syntax-parameterize redefinition to instead do "(set-car! (last-pair stack) new-transformer)" <wingo>requires a bit more work in the expander to get that right both at expand and run-time in all the different expansion modes <wingo>but i think we can do that on 2.2 <efraim>raghavgururajan: I use btrfs, I only use the compression option, and I like the checksumming <raghavgururajan>efraim: Nice! Do I have to use any modules in system.config to make Btrfs's features to work properly? <efraim>raghavgururajan: the kernel is already set up to work correctly. Not sure how it <MaybeDragon>What is the recommend way to set a keyboard layout (per user)? Is setxkbmap available via any package? <Elon_Satoshi>I installed GuixSD on a Lenovo Thinkpad T400 with a Libreboot BIOS, using a GPT partition table and an encrypted root partition. but it won't boot. This is what my setup looks like: http://termbin.com/n06p *janneke checks manual and now sees the guix-support? flag, very nice <pkill9>MaybeDragon: there's a 'setxkbmap' package <raghavgururajan>Urgent! I installed flashrom by executing "guix package -i flashrom". But when I type flashrom in terminal, I am getting " command not found" error. What to do? <pkill9>raghavgururajan: try logging in and out, the flashrom binary is put in the 'sbin' directory f the packag <raghavgururajan>Elon_Satoshi: Same happened to me. Did you pass "--no-bootloader" argument when you executed "guix system init"? <pkill9>so if you haven't installed any packages with that before, it won't have been added to your $PATH in ~/.guix-profile/etc/profile <pkill9>(which is executed on login and sets the $PATH) <efraim>civodul: I pushed the post to the guix-artwork repo <MaybeDragon>pkill9: I guess with setxkbmap available I can simply run that after login <pkill9>it would be good to implement such a setting for the guix configuration though <pkill9>setxkbmap is probably simpler to do <pkill9>i need to change the keymap so that capslock is set the ctrl automatically, since it resets when i unplug the keyboard and plug it back in <jonsger>efraim: nice post and _very_ nice progress :) <roptat>so, it doesn't seem that there is a dhcp client on the overdrive... and the only machine with two interfaces runs haiku ^^' <roptat>of course I can't connect directly to the box with a fixed ip, it seems that there is some security or something *janneke just built mescc-tools for arm *mbakke just built hello for aarch64-unknown-linux-gnu with GCC7 \o/ <mbakke>janneke: Does that mean we can get rid of arm bootstrap binaries too? <Elon_Satoshi>raghavgururajan: Tell me about your problems, maybe we can help each other?? <janneke>mbakke: not just yet...but given the way and speed dannym is hacking right now that may well soon be the case <janneke>i'm just helping him with mes stuff, but he needs very little help ;-) <mbakke>janneke: You are doing truly amazing work, didn't know dannym had joined in :-) *amz3 just wanted to thank the guix community because guix works flawlessly on ubuntu 18.10 cosmic <amz3>installed via the bash script <janneke>mbakke: thanks; yes at the Guix Days, dannym g_bor[m] and i did a "bootstrapping and ARM" session and dannym really got going! <jonsger>janneke: did I already mentioned that I liked your presentation about GNU Mes on the FOSDEM. Do you have the slides already on line? <mbakke>janneke: Great to hear, too bad I missed it -- catch y'all next year :) <roptat>so after all, there was a dhcp client, since it's now working with another ethernet cable... <amz3>Elon_Satoshi: Minimal Equation of Software, it is project that aims at reducing the size of trusted bootstrap binaries <amz3>(and it is also a space program but janneke is still not aware of that) *janneke is still spaced out from fosdem :-P <raghavgururajan>Elon_Satoshi: Because, you wanted /boot to be inside encrypted root partition instead of separate unencrypted boot partition right? <emacsen>so, guix 1.0 just in time for Valentine's Day? <raghavgururajan>Elon_Satoshi: From your config, I could see that you have used efi enabled boot partition. Sorry, I misread your initial message. Yours and my instances are different. Anyway, go to libreboot grub command line, do "cryptomount -a, and <raghavgururajan>Elon_Satoshi: and do "ls". Post here the list of output. I'll try to figure out from that <rekado_>Feb 14 is “I Love Free Software” day. It sure would be nice to have a release by then, but I think early March is more realistic. <civodul>wingo: thanks for the explanation, that clarifies what i had in mind! <civodul>not sure about the set-car! (last-pair stack) bit <civodul>you'd be pushing to the back instead of to the front? <Elon_Satoshi>raghavgururajan: I have done what you said in libreboot, and I will now transcribe the output of ls <Elon_Satoshi>(memdisk) (crypto1) (crypto0) (proc) (cbfsdisk) (ahci0) (ahci0,gpt3) (ahci0,gpt2) (ahci0,gpt1) (usb0) (usb0,gpt4) (usb0,gpt3) (usb0,gpt2,msdos1) (usb0,gpt2) (usb0,gpt1) (usb1) (usb1,msdos1) (ahci1) <Elon_Satoshi>In addition to the hard drive, I also have a USB drive with GuixSD 0.16.0 livecd and an external hard drive with its own LUKS partition <Elon_Satoshi>but it's too late now, that drive is loaded with backups and other things <raghavgururajan>Elon_Satoshi: Okay. That in that case, crypto1 belongs to external drive. <Elon_Satoshi>I really hope I didn't ruin my external drive's data by unplugging it while it was cryptomounted <raghavgururajan>Now use these commands on libreboot grub command line now. 1) set root='crypto0' <roptat>civodul, so I've copied the overdrive.scm configuration to the overdrive and renamed the hostname to overdrive2 (it's the current hostname), should I run guix system init now? is there anything I should change? <Elon_Satoshi>Why can't I get it to install so that Grub will decrypt the root, though? <raghavgururajan>Because, I think libreboot's grub payload doesn't pass on to grub on the disk. I have told many times that it will. But in my experience, it only finds grub.config, not another grub image. <Elon_Satoshi>Ok after typing "config /gnu/store/*grub.config" the screen clears and the libreboot grub prompt is on the top of the screen again. But that's all that happens <civodul>roptat: are you installing from a USB drive or from the existing openSuSE setup? <raghavgururajan>Try reinstalling guixsd by passing --no-bootloader as argument in guix system init. <roptat>civodul, from an existing openSuse <roptat>do you know how to boot from a usb? <Elon_Satoshi>But I don't want to run "cryptomount -a && search_grub crypto0" everytime I boot. Is there a way to edit libreboot's scripts without taking my computer apart? <roptat>configure.ac:89: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <rekado_>roptat: this is an autoconf macro defined in Guile’s meta/guile.m4. <roptat>rekado_ so that means guile is not correctly installed? <rekado_>you might be missing some development sub-package of Guile. (e.g. guile-dev) <rekado_>or the search path for m4 macros might be wrong <Elon_Satoshi>configfile /gnu/store/*grub.cfg gives "error: filename expected" <civodul>roptat: i've never tried booting from USB on the OverDrive but it might be possible <civodul>anyway, you can take the other route, in which case "guix system init overdrive.scm /" should work <Elon_Satoshi>anyways after I successfully boot into GuixSD with "search_grub crypto0", there's another problem <Elon_Satoshi>While it's booting, it never tries to decrypt the partition <Elon_Satoshi>It says "waiting for partition 'rootfs' to appear" repeatedly <Elon_Satoshi>Did I get the wrong LUKS UUID? The UUID I saw in Libreboot looks very similar to the one in config.scm <civodul>efraim: thanks for the post! should i post it now or do you want me to wait? <roptat>rekado_ you're right, there's a _devel package <Elon_Satoshi>Now that I can successfully decrypt my rootpartition for grub, can someone help me figure out why it won't decrypt for linux-libre? <civodul>Elon_Satoshi: could you post your config.scm file? <roptat>if I understand the manual, I need to use a different computer where guix is already installed to generate the bootstrap binaries for i686-haiku, am I right? <roptat>or can I use haiku to bootstrap haiku? <civodul>hmmmm what are you trying to do roptat? <roptat>haiku is a different operating system, so it's not yet supported by guix <civodul>but honestly, don't hold your breath <civodul>roptat: i don't think glibc was ever ported to Haiku, so... <civodul>Elon_Satoshi: what happens is that upon booting, the initrd looks for a file system with the "rootfs" label and doesn't find it <civodul>could it be that your root file system doesn't have that label? <civodul>Elon_Satoshi: it doesn't necessarily have something to do with encryption ↑ <civodul>roptat: the Haiku booth was actually in front of yours, right? <Elon_Satoshi>civodul: There's another reason why the initrd can't find rootfs: it never asks me to type in the password to decrypt it <roptat>civodul: yes! I know some of the devs, I even have two patches in Haiku :) <Elon_Satoshi>If the ext4 partition wasn't named rootfs due to forgetting to label or a typo, it would ask me for the password to decrypt the LUKS partition, and then fail to find rootfs *bavier real close to finishing the openmpi upgrade <bavier>civodul: btw, do you recall the reason behind adding the openmpi-thread-multiple package? <civodul>bavier: no (was it me?), i'd expect perhaps performance considerations <Elon_Satoshi>civodul: i'll thank you again when i prove that your solutin works <bavier>civodul: sorry, no, it was paul iirc, didn't know if there had been a discussion on guix-patches <bavier>civodul: in any case, openmpi enables thread-multiple support by default, so unless it's disabled in the regular package the two are identical :) <Elon_Satoshi>raghavgururajan: While I'm waiting for guix pull && guix system init /mnt/guix/etc/config.scm /mnt/guix to finish running, is it really possible to change libreboot options using command line tools? <civodul>bavier: then we can just defined "openmpi-thread-multiple" as deprecated <bavier>civodul: ok, I'll send a patch, and maybe others can chime in *civodul pushed the define-syntax-parameter workaround, goes dancing and celebrating ***specing_ is now known as specing