<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>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>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"?
<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
<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)
<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?
<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.
<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?