***stikonas is now known as stikonas2
***stikonas2 is now known as stikonas
<zacchae[m]>apteryx: I suspect the problem is due to my home env being grossly out of date (still waiting on that qutebrowser patch). <zacchae[m]>Even in my out-of-date system, I think the problem has something to do with my profile and home env not playing nicely, so I tried getting a similar scenario with guix home container to see, but adding python to the home environment specification did not give me access in the container, so I'm not sure how I'd go about reproducing <bjc>EMax`0Mancer[m]: so i got around to installing gnome and gdm, and it looks like its not going to work; /run/current-system/share/xsessions is a symlink *into* the gnome session share <bjc>i had assumed that it would contain symlinks into various packages to collect desktop entries, like other parts of the system do (/run/current-system/share/applications, for example) <bjc>this seems like a bug/oversight to me, since i dunno how it'd be extended for other desktop environments this way ***rekado_ is now known as rekado
<Gooberpatrol66>Anyone know how to use lv2 plugins on guix? The directories listed in $LV2_PATH don't exist. <EMax`0Mancer[m]><bjc> "this seems like a bug/oversight..." <- I can't seem to find any other place where gdm will look. I tried creating a /usr/local/share directory, but that didn't work. <bjc>from what i can see in gnu/services/xorg.scm, it looks as though gdm will also look in your local profile <bjc>so ~/.guix-profile/share/xsessions/whatever.desktop might show up in the picker <bjc>i'm not sure how that works inside gdm -- you may have to enter at least your login before it shows up; i've never used per-user session definitions inside a greeter before <bjc>that said, there should be a way for other desktop environments, installed via guix system, to insert their desktop entries globally. if there isn't i would personally call that a bug, but i may be missing something in how guix is meant to operate. you may do well asking on the mailing list <char[m]>Hello Guix. Any idea why mcron is telling me that next-week is an unbound variable? <char[m]>apteryx: I have #~(job '(next-day) "updatedb") which works, and I have #~(job '(next-week) "...") which does not work <apteryx>hm, it does indeed look like it's missing in (mcron job-specifier) <apteryx>there's next-year, next-month, next-day, next-hour, next-minute and next-second, but no next-week <apteryx>you can probably achive the same using next-day with a range though <char[m]>Is it a guix problem or an mcron problem? <apteryx>the original commit documented next-week but the code never had the matching procedure <char[m]>Well thanks a lot apteryx , I guess I will try to report it to mcron. <apteryx>you can see that with 'git log -G next-week' in mcron's git checkout <char[m]>I guess (next-day (range 1 31 7)) should be equivilent to next-week? <char[m]>I might do it not exacly 52 times per year though. <apteryx>I think you can also use vixie specifications as strings <char[m]>If it is in a file I like vixie, because I can have a guide at the top of the file. If I has to be in a (job ...) which guix mandates, I find the sexp syntax easier. <apteryx>my most complicated spec to date is this: '(next-hour-from (next-day (range 1 31 3)) '(5)) <apteryx>it took me an embarrasing amount of effort ot figure it out <char[m]>Yeah, I saw that in the guix logs, when I was searching for a solution to this. <char[m]>the day range seems to work good for now. Thanks again apteryx <kitty1>user_oreloznog: yo uwu, hows it goin? <kimjetwav>Ooh are we arguing about mcron syntax? Can I get in on that? <kimjetwav>Ahh yeah, the missing week definition. Definitely worked around that myself. <kitty1>:P, I need to mess with guix-hurd someday, as a literal nobody I am curious to see how a guix-hurd logo could look? <user_oreloznog>Kittty1: Cool! I think both of guix and hurd included into one logo. Working on it rigth now... <the_tubular>Anyone know if there's effort about updating podman ? There's a few bad CVE's that 3.4.4 is vulnerable to <the_tubular>There's CVE-2022-1227, CVE-2022-27191 and CVE-2022-27649 that I know of <the_tubular>Biggest one is 1227, could lead to code execution on the host machine <WesterWest[m]>if I mount btrfs subvolumes to their actual path, aka /gnu and /home are subvolumes, do I need to specify them in filesystems? or do they get mounted automatically when I mount /? <jpoiret>WesterWest[m]: iirc you don't need to (and you wouldn't even be able to mount them individually, since the directories are non-empty) <bost>Hi. Is there a way how to force rebuild? I.e. something like `guix build --force --load-path=. openjdk`? <bost>Oh. It looks like by default a package is always (force-)rebuild, except it --keep-failed is used. <jpoiret>by default, if a derivation is already built, it won't be rebuilt <jpoiret>you can use --check to force an independent rebuid ***bjc`` is now known as bjc
<eskin>Hi all, new to guix/guile.. I've tried to install guile libraries "haunt" and "artanis" through guix home, but that doesn't seem to add them to my guile load path <eskin>Does anyone know a way to make it so guile libraries are added to the load path automatically when they're installed that way? <eskin>The binaries are accessible, but if I try to use any of the libraries` modules at the repl it doesnt recognize them <bjc`>eskin: often times when things are meant to go into a shared path, you'll find them underneath your profile/home share path ***bjc` is now known as bjc
<bjc>in this case, artanis stuff can be found in ~/.guix-home/profile/share/guile/site/3.0 <bjc>(as would other libraries installed via guix home) <bjc>if you'd installed it with ‘guix package’ instead, it'd be under ~/.guix-profile (or the path to the profile you installed it under, if you specified that explicitly) <jpoiret>eskin: you need to also have `guile` installed in the profile for the search paths to be considered <jpoiret>think of those like plugins: you need the base software to be installed for the plugins to be picked up <PotentialUser-84>Hi I have something I'm sort of confused about. I'm using TMB which is an R package where you build models using C++ templates. So minimum you need the following packages to make it work "r","r-tmb","gcc-toolchain","make","gfortran-toolchain" <PotentialUser-84>If I put say the r packages in their own manifest and the gcc,make,gfortran packages in their own manifest and call guix shell TMB no longer finds the right glibc version in gfortran <jpoiret>up, that's because of ...... search paths! <jpoiret>oh, wait, are you using gcc or gcc-toolchain in your manifest? <jpoiret>so in `guix shell -m gfortran-manifest.scm` you can use gfortran properly? <PotentialUser-84>Should I expect a difference between loading a package into shell via command line vs. manifest? ***bjc` is now known as bjc
<euandreh>happy to see the highlight changes in "guix search" and similar ui commands :) <milia[m]>So if I understood correctly, to install Guix on an aarm64 machine like RPi4, I have only the options of precompiled binaries or to build it from source? <milia[m]>The available iso images seem to be only for x86_64 and i686 architectures <milia[m]>Is anyone else here runing Guix on RPi, actually ? I'd love to hear some impressions😁 <singpolyma>milia[m]: I think there's no substitutes for arm so it's pretty slow going <jpoiret>PotentialUser-84: well, if you use two separate manifests, yes, there can be differences <milia[m]>singpolyma: Ah ok, sth like Versalpgic's SBC boards? <milia[m]>* Ah ok, sth like Versalogic's SBC boards? <singpolyma>milia[m]: I'm not familiar with those ones, but anyway I gave up in it because of the no substitutes situation. <lamdacore>jpoiret: hi, thanks for helping with lvm on luks setup yesterday. I am however, missing something... grub complains about not finding the specified device <lamdacore>I am unsure if grub shell should also show the logical volumes, but I just see the two physical partitions with ls. <lamdacore>do I need to explicitly include install or include the lvm module in my config? ***bjc` is now known as bjc
<PotentialUser-84>I've also tried a single manifest with all 5 and that also runs into the same problem. Is there somewhere I can read why this might be? <jpoiret>lamdacore: i think we have a bug here <jpoiret>can you try `insmod lvm` and see if the grub rescue shell sees the logical volumes? <lamdacore>jpoiret I tried this already. i just see the vfat partitions and the second "unknown type" <lamdacore>and manually cryptmount the partition - it just asks again for the passphrase which fails, presumably, since it is already decrypted (i get a prompt for this before the guix grub menu) <jpoiret>GRUB doesn't use your default keymap <jpoiret>at least for the prompt at the very beginning iirc <jpoiret>so it's possible you haven't decrypted the volume <lamdacore>am I supposed to get a passphrase prompt before the guix grub? the grub menu should be unencrypted right? <lamdacore>my passphrase should be identical in both qwerty and qwertz <bjc`>the grub menu is stored in the esp, so it's decrypted <bjc`>or, rather, never been encrypted at all <jpoiret>i do have to type my password before seeing the grub menu myself though <SrEstegosaurio[m>lamdacore: Yeah, you usually doesn't encrypt the bootloader. _(I'm not really sure if it's even possible.)_ <jpoiret>you can have all the grub config files encrypted <bjc`>you can, but you have to configure that explicitly <lamdacore>my boot and esp are in a seperate unencrypted fat32 partition <jpoiret>the grub binary itself cannot be encrypted, but can be signed and chainloaded with secureboot ***bjc` is now known as bjc
<lamdacore>i think I see some error flash for a second after I enter the passphrase and it jumps to the grub menu. how can I see find out what I missed? <jpoiret>does your grub menu have a blue background, or the stylish guix logo? <jpoiret>eh, so you did not successfully unlock the drive <lamdacore>thats good. I am leaning towards something related to lvm modules. <SrEstegosaurio[m>jpoiret: Happens to me every time that I want to encrypt my drive, on every distro. Probably a problem with the initramfs. <jpoiret>lamdacore: you run lvm on luks, right? <jpoiret>SrEstegosaurio: no, we're only at the GRUB stage here, the initramfs comes later <SrEstegosaurio[m><jpoiret> "you can have all the grub config..." <- Oh, that's actually cool. I knew that for example you can have your boot partition in a separate USB/SD card. <lamdacore>maybe because I am using not the stable guix iso? I had to pull and install lvm2 on the install media for example <SrEstegosaurio[m><jpoiret> "the grub binary itself cannot be..." <- At some point in time I want to do something like this. <jpoiret>if anything, using latest is better 99% of the time (even 100% :p) <SrEstegosaurio[m>lamdacore: I had troubles with the stable release yesterday so I'm trying the newest one this time. <lamdacore>jpoiret: unfortunately, I am using the nonguix iso for video firmware.. sorry if this is the possible cause <jpoiret>no, this shouldn't be an issue either, it doesn't modify grub iirc <jpoiret>so, after you insmod lvm, you don't see any lvm/something in your drives? <lamdacore>in the grub shell still. I did insmod lvm. and ls again it is the same output <jpoiret>SrEstegosaurio: an install iso containing another channel with proprietary bits. the consensus is that #guix should avoid mentioning or talking about that other channel <lamdacore>jpoiret: no cryptouuid. if I do "cryptmount device_num" it asks me for the passphrase with the cryptuuid in brackets <jpoiret>when i try to cryptomount again my own cryptodisk, it doesn't ask for a password <SrEstegosaurio[m>One question; if I don't need and or want a certain service, may I remove it from the system config file? <jpoiret>did you use PBKDF2 for the key derivation function for your drive? <jpoiret>cryptsetup defaults to Argon2i and friends, which GRUB doesn't support <jpoiret>since it's luks2 you should be able to add a key slot with PBKDF2 and remove the argon2i one without changing anything else <lamdacore>i used defaults. it is an old luks parititons where i have another OS already in another lv already. <SrEstegosaurio[m>I think that my main computur uses a encrypted root partition and I remember the name of aragon2i. It works. <jpoiret>right, and your kernel is on an unencrypted /boot partition <jpoiret>so you only need Linux to be able to decrypt it <SrEstegosaurio[m>SrEstegosaurio[m: I can't give any more details since I'm not at home. But maybe it has no do with the initramfs handling it or something similar. <jpoiret>here GRUB needs to find the kernel, which is in /gnu/store <jpoiret>so my suggestion is (it should be unintrusive for your other OS as well), add a new keyslot with PBKDF2 as the kdf, and remove (or keep it as is if you want) the older one <jpoiret>(ie. don't need to avoid booting on that very luks drive) <lamdacore>I see. let me look into this. Should be simple in that case. <jpoiret>SrEstegosaurio: did it crash without any warnings? <jpoiret>if its the newest installer it should suggest to create a dump <SrEstegosaurio[m>I'm trying to re-run it in order to see if the error was just a random fail or something else. <jpoiret>the dump feature will send the crash dump to a guix server so that we don't need a photo <jpoiret>unless you didn't get past the network screen :p <SrEstegosaurio[m>jpoiret: Oh, that's nice. But I would want to troubleshoot this. If possible. <SrEstegosaurio[m>I mean, the error appears while "installing the base system". (Idk if that's the appropriate term) <jpoiret>there won't be a crash dump there then :( <jpoiret>that only concerns people working on the guix sources <jpoiret>something with "In xxx.scm" with xxx not being ice-9/boot.scm <jpoiret>i'd be interested in the whole thing then if you could take a photo of it <SrEstegosaurio[m>jpoiret: Actually there is something like that, let me take another photo. <jpoiret>what's weird is that it seems to be a bug with `guix system init` <jpoiret>heh, i didn't even notice the scribbles <jpoiret>alright, i think i see where the error is thrown, but ill have to look deeper to see why it appears so <jpoiret>i don't think you'll find much, it's a very internal error <jpoiret>i don't want to discourage you but maybe your time is better spent on something else :p <jpoiret>your photos are already very helpful in tracking down the source of the bug <SrEstegosaurio[m>Okey I understand. The problem is that at first I tried using the "stable" release. It kinda worked untill the GRUB part. So someone recommend me to use the newest one instead but it seams to not be working tho. <calcium>whyn does it fails ? ```guix home: error: build of `/gnu/store/say3bjcw9iijvrfng8zwvlrll7sf7bpx-evinceps-40.2.drv' failed``` <jpoiret>you could isolate that definition in a separate .scm file and return it as the last value, and then `guix build -f thatfile.scm` will give you more info <bjc>is there a reasonable way to get the store path to a non-"out" derivative for use in the system configuration? <bjc>i can extract it using (package-derivation (open-connection) mypackage), and then getting the list of outputs from there <bjc>but it seems not right to use (open-connection) in a config.scm <bjc>i'm having a hum dinger of a time trying to find anything in the programming documentation. the "package" part of the manual has a small fraction of the api defined <jpoiret>bjc: the source is always your best bet, it's pretty readable <bjc>yeah, that's what i've been doing. i guess i should be more direct: am i looking in the wrong place for documentation? <jpoiret>how are you getting the "out" path anyways? it seems like it would need to talk to the store to do that <jpoiret>theoretically you're not but as you've experienced it's pretty under-documented right now <bjc>i *do* have to talk to the store the way that i'm going about it, but it feels weird to me to have a call to (open-connection) or (with-store) in config.scm <bjc>like, i can do things like (file-append pkg "/bin/ls") to fill in the derivation's output path. but that only seems to work for "out", not others <jpoiret>bjc: are you using the result of that file-append in a gexp? <calcium>How can I force guix to rebuild after «guix build -f test.scm» ? <bjc>not explicitly, although i assume it is internally. i'm using it in (extra-special-file "somepath" (file-append pkg "/bin/cmd")) <bjc>i'd hoped (file-append (pkg "src") "/whatever") would work <bjc>rather, (list pkg "src") <calcium>I tried «guix build -f test.scm -S --check -v 10» but it doesn't output as much build process as the first time <calcium>The first time I had message from the build tools, now I only have message from Guix <lamdacore>jpoiret: hi. back again after adding a new keyslot. I think the pbkdf2 option helped. <lamdacore>I can see a crypto0 entry in grub shell. no lvs though still :\ <bjc>calcium: you can 'guix gc' to clean intermediates and rebuild things <bjc>once guix builds something, it assumes it doesn't need to build it again because of its architecture. you shouldn't ever need to force a rebuild <bjc>unless you're actively working on a package at least, and even then i'd think it'd be rare <calcium>bjc: no luck, still no output from the build tools being used behind guix (maybe the first time was a bug that leaked ouput :/, but the leak was useful) <bjc>gc won't always clean up the intermediates, since they may be in use in a profile <bjc>guix build will show everything it's doing. it's normal to run a build and see a bunch of output the first time, then nothing except the results the second time <jpoiret>lamdacore: what about after insmod lvm? <calcium>bjc: Ah, the mistake was that I was still using «guix build -f test.scm -S --check -v 10» instead of simply «guix build -f test.scm» after the garbage collector <lamdacore>need to somehow add insmod lvm to the grub config somehow. but you caught the pbkdf bit. Very nice and thanks! <bjc>the bootloader menu entries will need modification for insmod, i'm pretty sure <bjc>i don't think you can do it in the bootloader configuration either <lamdacore>bjc: So cannot be done somehow in the config.scm you mean? <bjc>right, at least not easily <bjc>it should be easy to add another slot to menu-entry and bootloader-config, though <bjc>hmm.. actually i'm not sure. those things are grub specific <bjc>huh. i'm looking at the source now and it seems that if you have a cryptodevice, luks and luks2 should be insmodded automatically ***bjc is now known as |`
<|`> (let ((devices (map crypto-device->cryptomount store-crypto-devices)) <|`> (modules #~(format port "insmod luks~%insmod luks2~%"))) <|`> (cons modules devices)))) <lamdacore>so I am very unfamilar with grub. (always used syslinux and now systemd-boot or efistub). Should I be modifying /boot/grub/grub.cfg? ***|` is now known as bjc
<bjc>yes, that'll go in /boot/grub/grub.cfg <lamdacore>bjc: yes, I see luks and luks2 in there. I would need lvm in addition. <bjc>you can do the insmod at the toplevel or inside the menuentry <lamdacore>so i have to keep in mind to add this again if I reconfigure the system in the future though <bjc>you'll need to find a way to do this in guix, though, since guix will trash your grub.cfg on every reconfigure <bjc>you could take out the bootloader part of the config.scm <bjc>if there's a bug report for this, maybe +1 it. if there isn't, add one. i'm also going to need the ability to insmod stuff in grub.cfg at some point, so it'd be helpful <lamdacore>not sure if that is wise. would break the links to the /gnu/store kernels <jpoiret>bjc: the issue is that we don't manually insmod lvm <jpoiret>you should definitely open a bug report for it <jpoiret>i definitely know how it could be fixed <jpoiret>for most people it works for them because the /boot/grub is on an lvm drive, so the grub image itself embeds the lvm module automatically <bjc>you are correct about the kernel paths, lamdacore. there may be a way to work around it with include files in grub? <bjc>lvm is in your grub directory, that's not the issue <bjc>it's that grub dynamically loads the modules when it can, for things like commands you type. but for filesystems it doesn't have a way of triggering the dynamic load, so you have to do it by hand <jpoiret>what i mean is that we never insmod lvm, but for other people using lvm, they don't run into this issue because lvm is automatically loaded <jpoiret>it's automatically loaded because grub detects that it needs lvm to even read its own config files, so it's directly embedded in the binary and loaded as soon a grub starts <bjc>oh, you're building grub with it linked in? <jpoiret>Guix is not really responsible for the final grub binary that's installed either in the EFI partition as .efi or embedded in the first sectors of the mbr, it's grub-install that pieces the needed bits together <jpoiret>basically, grub-install takes the standard grub binary and adds a bunch of things to it, like default modules used for accessing /boot/grub and some other things <jpoiret>that's at the root of another problem: GRUB supports luks2 but grub-install doesn't properly detect luks2 devices, so it won't embed the luks2 module if /boot/grub is on a luks2-encrypted drive <bjc>grub-install builds the binary, or grub-mkimage? i've only used the latter to build a custom grub with statically linked modules <jpoiret>grub-install relies on grub-mkimage iirc <bjc>yeah, i've only had to mess with this for building grub images for foreign systems, so anything in grub-install wouldn't work for me <bjc>the bootloader has to use the "grub" package for its paths, right? so theoretically, you could create a new package called "grub", inheriting the old one, then have a build step that does a "grub-mkimage" that includes lvm, and that package would be picked up by the bootloader module? <bjc>obviously the ability to declare extra modules is preferable to that, but in the mean-time, would that work as a hack around the problem? <jpoiret>bjc: rather, you'd have to modify the definition of grub-efi-bootloader to be able to include additional pre-built modules <jpoiret>but tbh, we already have the proper detection of whether we need to insmod luks to get to the store, we can do exactly the same thing for lvm <bjc>the insmod stuff would apply to all the grub bootloaders, not just efi <jpoiret>yeah but currently the bootloaders definitions for grub-efi and grub don't share much code iirc <bjc>i don't know enough about other bootloaders, but would it make more sense in the bootloader-configuration? <bjc>or maybe just a free-text section, so you can literally type it out? <bjc>i'm interested in getting zfs-on-root, which requires 'insmod zfs' in grub. theoretically, i could have that done automatically by detecting the filesystem type the same way luks is done <bjc>i assume there's not going to be much patience for zfs stuff in that level of guix, though, so i'm looking for more flexible solutions that'll let me add it in on my own <Haider>How do you find the path of a binary in scheme? <bjc>binaries don't have paths until you compute their derivations <Haider>ohh, I really should read the manual in depth <bjc>it's ok. it's complicated. i only recently ran through this exercise <bjc>i'm trying to find the mailing list thread that details it so you can read it <bjc>josselin poiret's answer in the thread seems to be the best way <jpoiret>i'm still trying to see if there's a way for file-append to take an output bjc <bjc>i gave up on it a day or so ago. it feels like passing a list to file-append is the right way to do it, though <bjc>might be interesting to try and patch it to accept a list, but i haven't actually looked at its code to see how feasible that is <jpoiret>bjc: could you try (file-append #~#$pkg:lib "/thing")? <bjc>jpoiret: yeah, one sec <bjc>getting "invalid field specifier" <bjc>lamdacore: yeah, that seems like the same issue <bjc>jpoiret: oops, i typoed. lemme try again <bjc>yeah, still getting that issue, whether it be #~(file-append #$pkg:lib "/thing") or (file-append #~#$pkg:lib "/thing") <apteryx>bjc: yeah, there's a bug about file-append for this. You'll have to use plain string-append + plain gexp <jpoiret>#~(file-append ...) doesn't mean much <jpoiret>file-append is something that has to be ungexp'd <apteryx>file-append doesn't work with different outputs <bjc>ungexping the #$pkg:lib seems to just produce the list (pkg "lib") <bjc>with string-append, how would that work? how do i get the "lib" output path for the first argument? <apteryx>bjc: by the way, if you are interested in ZFS, there are patches on the guix-patches tracker sitting for months; perhaps you are the person those patches have been waiting for (to get proper testing/feedback) <bjc>i've seen them, and it looked like they were integrated already <bjc>i had no problem loading the module, anyway, and creating pools/filesystems <bjc>i know there are supposed to be issues with getting the pool imported at the right time for things like home directories to work, but i'm not that far in the process yet <bjc>and anyway, for zfs on root, which is my current target, the filesystems are going to be imported when i need them no matter what <bjc>but that requires being able to put the zfs module path in initrd-modules, and that requires extracting the path to them from the "module" output <bjc>and that's why i'm bugging irc about it ;) <bjc>for the most part, i'd categorize my problems as missing generic functionality, and not zfs-specific. so i hope work here will be more generally useful <bjc>and while it'd be nice to see 1st class upstream support for zfs, i am not expecting it at all <ZhuAisi[m]>Hi, Guixer! Do you think the store dir is equivalent to /usr in FHS distrbutions? <ZhuAisi[m]>My thoughts: There may be some user config if somebody use declarative configuration <bjc>the distinction between /usr and / is arbitrary and dates to a time when disks were very, very small <bjc>i'd argue it hasn't been a relevant distinction for decades, but it's stuck with us due to long-encoded path expectations <jpoiret>the FHS fails to be clear on what /usr is for exactly <bjc>and /gnu/store is an entirely different beast that doesn't map to the unix heirarchy in any meaningful way <ZhuAisi[m]>bjc: The main issue is, I found some software ro mount /usr to sandbox(e.g. flatpak). Some Nix guys patch this behaviour to mount nix store instead. But I don't think store is equivalent to /usr in security aspect <jpoiret>generally, you shouldn't put anything private in the store <bjc>right, that's not a security thing. have you looked inside /usr on a guix system? <bjc>there's nothing in there except bin/env <bjc>so mounting it is pointless, and /run/current-system paths are the closest thing to it <jpoiret>i think what they mean is that bind-mounting /usr inside a container is pretty safe since it doesn't contain eg. system configuration, whereas /gnu/store does <bjc>(and those link to stuff in the store, so that's necessary too) <jpoiret>same for /run/current-system, you have a lot of non-trivial stuff in there <bjc>you're worried about a potential information leak into the container from the store, since the whole store is mounted <ZhuAisi[m]>flatpak-validate-icon requires gdk pixbuf loaders from host systems and mount them into the sandbox <ZhuAisi[m]>I decide to only mount the package closure of gdk-pixbuf and librsvg into the sandbox, because it doesn't need to support format other than jpeg, png, svg <bjc>i don't know of a way to solve this without either: mounting the entire store; or walking the profile/share path and mounting those individually <bjc>as a general architecture, does it make more sense to add support for (pkg "output") to lower-object, or to file-append? <bjc>i'm leaning on file-append, since lower-object seems to want to be a direct translator of thing-that-is-lowerable -> lowered-object <bjc>and since (pkg "output") has the same lowered representation (a derivation), then i don't think it makes sense in lowered-object <bjc>s/lowered-object$/lower-object/ <bjc>what i mean is, since the result of lower-object on (pkg "out") is the same as (pkg "lib"), which is a derivation of pkg, and the derivation is what needs to be queried for the paths based on output, i don't think it makes much sense for lower-object to care about the output <bjc>actually, yeah, i've just talked myself out of putting it there <WesterWest[m]>is there a method to set the initial grub keymap? can I use dvorak for the first drive unlock? (as I understand I just have to unlock it twice sadly) <SrEstegosaurio[m><WesterWest[m]> "is there a method to set the..." <- Yeah, it's possible. <bjc>you can specify the keyboard-layout in the bootloader-config <SrEstegosaurio[m>WesterWest[m]: I'm not sure, I'm still trying to install GUIX. So I don't know anything about GUIX especific stuff. <bjc>(bootloader (bootloader-configuration (keyboard-layout …))) <WesterWest[m]>bjc: that doesnt work for the initial unlock of the device, ie. as I have encrypted root it first ask for a passeird then is grub loaded <WesterWest[m]>* > <@bjc:libera.chat> (bootloader (bootloader-configuration (keyboard-layout …))) <WesterWest[m]>that doesnt work for the initial unlock of the device, ie. as I have encrypted root it first ask for a password then is grub loaded <bjc>your efi/bios is unlocking the drive? is this like a secureboot thing? <WesterWest[m]>i dont think so, i really dobt understand it tbf. I have 2 partitions 1st is mounted on /boot/efi and is fat32 <bjc>the efi partition has to be fat32, and it's loaded directly by your efi. it calls into grub, which is located there <bjc>grub will then load all its things off the efi partition, including its config, and then do whatever the config specifies <WesterWest[m]>but before it opens grub menu it asks me for the password to the second partition (and is qwerty) after that grub menu appears and when I select guix option it asks me for my password again <bjc>i don't know why you'd have to unlock twice during boot, and particularly not with different keymaps. grub should know enough by the time it prompts you to for a password to have your keymap set up <bjc>huh. wild. dunno why it does that. i'm not particularly familiar with luks, though, so maybe that's normal? <WesterWest[m]>it seems that all grub is on /boot/grub which is outside efi <bjc>for guix, either works <bjc>guix configures grub to look for the kernel and initrd in the store, so there isn't anything other than grub necessary in /boot <bjc>but guix does expect /boot/grub/grub.cfg to exist and be your actual grub config <bjc>that path is hard coded <bjc>so if you mount your esp elsewhere, you'll need to bind mount the grub config into the above location or things will break <acrow>I have been using guix-home and I've noticed that if I run, for instance, 'guix package -u flatpak' I get the 'consider setting the necessary environment variable ... GUIX_PROFILE... ' hint. <acrow>I usually love the hints but in this case it offers that I should set GUIX_PROFILE to "$HOME/.guix-profile" but since I am a user of guix-home, GUIX_PROFILE="$HOME/.guix-home/profile". I think this is wrong. Or, maybe, as a home user, I am not expected to run 'guix package -u'? I think the hint might be improved. Hmmmm. <zacchae[m]>acrow: guix package always modifies .guix-profile <zacchae[m]>you will notice that .guix-home/profile shows up before .guix-profile <zacchae[m]>Because guix home will do it right, but if you try and run those sort of commands yourself, you might mess things up. Specifically, running the guix profile command will erase guix-home from your path, which is not what you want <zacchae[m]>On an unrelated note, does anyone self-host an email server on Guix? I want to know if I just need to set up dovecot, or if I need more services (like exim or opensmtp) <singpolyma>zacchae[m]: dovecot isn't a mailserver so you almost certainly need a second thing <bjc>and more on top of that for modern mail. at least a dkim implementation <bjc>not on guix, though, so i can't help you with specifics there <zacchae[m]>Thanks singpolyma, bjc. For now it's just me, so I think something like a maildir setup should be fine if I understand correctly. So what I'm looking for is a MTA then? So exim is the bare minimum? <acrow>zacchae: That makes sense. So. If you are using guix home you need to either ignore the hints or avoid running guix package command, no? Instead depend entirely on home-configuration.scm and then home reconfigure. IIUC. <bjc>personally, i'd recommend postfix over exim, since it's much easier to configure and manage for a self-hosted setup <bjc>postfix+dovecot+opendkim will be what you need for basic reception and delivery, i believe. unfortunately i set my stuff up a long time ago and have been migrating it by way of zfs send/recv, so i have long lost the specifics of everything that's needed <zacchae[m]>acrow: You should ignore that warning I believe, as that is already run if you configure your shell with guix-home. See ~/.profile -> sources /etc/profile -> runs the lines indicated in that warning <Haider>Small question, I am trying to package a package where I had to package it's dependancy also as Guix's version is out-of date, How do I tell the package to use the local .scm packaged version instead of the committed version <zacchae[m]>bjc: I don't see postfix in the guix user manual, so I'll probably stick with exim <bjc>ah, fair enough. i didn't know guix lacked postfix <zacchae[m]>Haider: I believe you can add the directory with your local .scm (see guix -L) and import it normally <zacchae[m]>or just paste your dependency definition to the begining your desired package definition <Haider>Yeah, I tried installing it with -L and the package couldn't find it. Pasting it at the beginning worked though. Thank you! <apteryx>is 'guix shell -m manifest.scm pict' supposed to give me manifest + pict in the same profile? <apteryx>(manifest being a collection of packages captured in a Guix manifest) <jab>Have you guys seen this hacker new article? <jab>Apparently ribbit scheme can be bootstrapped from a POSIX shell. <jab>That's kind of cool. 
