IRC channel logs
2023-08-07.log
back to list of logs
<jackhill>Hey, looks liek the cert for issues.guix.gnu.org expired <jackhill>not sure who's responsible for that. nckx ? <graywolf>Did the cert of issues.guix.gnu.org expire? <vagrantc>you can get the classic debbugs interface at debbugs.gnu.org <graywolf>Thanks for the sanity check. Yeah, will do that. <vagrantc>but yeah, issues.guix.gnu.org has some nice integrations with qa ... and just a little gentler on the eyes :) <vagrantc>which reminded me to check for unapplied patches ... :) <graywolf>I am waiting for reviews and merges it you are bored :D <vagrantc>my skills at reviewing can be disappointing ... but i can try :) <graywolf>I am looking forward to be able to enter luks password just once per boot :) <vagrantc>ok 65002 sounds like a very nice feature, but a little above my head weather the patches need any improvements :) <vagrantc>but if i understand correctly ... you manually create an extra cpio archive and append it to the initrd that is used for boot? <graywolf>Yeah, did not figure out any other way since it cannot be stored in the store <graywolf>Seems to work and should not impact people not using it in any way <vagrantc>and the combined initrd is only accessible by root? <graywolf>There is no combined initrd, that is the point. The /key.cpio is chmod 0000 and contains just the key. grub then just loads both, so <ulfvonbelow>there is no "combined initrd" as a single sequence of bytes on disk ever; grub appends them in memory before passing them to the kernel <vagrantc>ok, so you pass two initrd to grub ... and the one is very restricted <vagrantc>ok, that's about it for my high-level review :) <ulfvonbelow>what would be even better would be if grub supported some sort of tmpfs; then in the embedded cfg file you could create an in-memory cpio archive containing the password and pass it without it ever touching the disk at all <ulfvonbelow>also, when generating a cpio archive, make sure to include the parent directories separately, and before the archive itself if it exists <ulfvonbelow>e.g. I have my key file appear in /etc/secrets/luks-key, so I had to tell cpio to include /etc, /etc/secrets, and then /etc/secrets/luks-key <ulfvonbelow>re: 65002, I'd maybe change it from extra-initrd to extra-initrds. <ulfvonbelow>I can't think of a need for two or more extra initrds off the top of my head, but at least that way the full functionality is exposed <ulfvonbelow>as many as can fit within whatever command length limit there is, I believe <vagrantc>actually appending an initrd would be more generalizable to other boot methods, fwiw ... though still has tricky security properties with key material <vagrantc>at which point ... not sure why it could not just be included in the regular initrd <vagrantc>... hard to imagine other uses ... but maybe i lack imagination. :) <vagrantc>graywolf: regarding the kernel update ... nothing obviously borked there :) <ulfvonbelow>my understanding is that the ability to boot multiple concatenated initrds is already grub-specific <ulfvonbelow>I don't see why that would be the case, since the concatenation is done before it reaches the kernel <vagrantc>if you pass an already concatenated initrd, the bootloader does not need to do anything to mangle it <ulfvonbelow>also I should reword: the ability to concatenate multiple boot initrds and then boot the concatenated initrd is grub-specific <vagrantc>linux will happily accept any number of concatenated cpio archives <ulfvonbelow>aye, but when should it be concatenated? Not at os-eval-time (lest 'guix system init' or 'guix system build' create it on the wrong system), not at boot time, and not at reconfigure-time, since those happen too late. <vagrantc>so i guess i was proposing to actually generate a private, concatenated initrd ... but i cannot think of any use-case that would actually benefit from that <thanosapollo>anyone else has issues with using guix command in eshell? Whenever I just type `guix` it starts a repl <thanosapollo>Using Debian, emacs installed with emacs-next guix package <samplet>Have you read that? I’ve never used it myself, but that’s what I would try. <samplet>thanosapollon: Does it make a difference if you give it a complete command, like ‘guix describe’? <samplet>I tried ‘guix’ in eshell, and got the same result as I do in Bash, FWIW. <lh>> Hey, looks liek the cert for issues.guix.gnu.org expired <lh>ci.guix.gnu.org as well <lh>that’s really weird, chromium connects fine to the http version 😨 <mirai>expired cert for issues.guix <UnderSampled>Hello. How do I move /gnu/store to /home/user/gnu/store? <iyzsong>UnderSampled: i think you can move it there and then bind mount it back to /gnu/store. <iyzsong>yes, that can be changed when compile guix via '--with-store-dir=PATH', but then you won't able to use substitutes, have to build all things from sources.. <iyzsong>or use a fs wrapper like proot to fake it to /gnu/store, which slows things a bit. <iyzsong>build results are path dependents, eg: hello linked glibc to /gnu/store/....-glibc/lib/libc.so.6 <iyzsong>so when you changed the store dir, what you get from the ci won't run <UnderSampled>Now, how can I download substitutes faster than 24KiB/s? <UnderSampled>Reproducible builds and all, seems like a consensus network should be able to build and distribute all the things! <iyzsong>there are some mirrors for both ci and bordeaux, and some works (ERIS, etc.) for distrubuted substitutes <iyzsong>we have 2 CI farms, one is at berlin (ci.guix.gnu.org) and another at bordeaux <piptown>Hey I've just install guix 1.4.0 and I install bspwm no problem. How do I get guix to make that my default wm or select it for use? <iyzsong>UnderSampled: add via '--substitute-urls "AAA BBB"' to 'guix-daemon' or 'guix' (for oneshot usage) <iyzsong>under debian i think it can be done with 'systemctl edit guix-daemon' <iyzsong>piptown: which login manager (gdm, lightdm) you use? if bspwm doesn't show in the login manager (due to not have a desktop file), you can write a ~/.xsession script file (for the login user, and make sure it's an executable) to run it <UnderSampled> --build-users-group=_guixbuild --discover=no --substitute-urls "bordeaux.guix.gnu.org" <hako>Need to include ci.guix.gnu.org as well <hako>I think https:// is also needed. <iyzsong>yes, should be --substitute-urls="https://..." and the default one does include ci and bordeaux alreally <iyzsong>so you want to try the US/Singapore one if ci and bordeaux is slow <piptown>iyzsong: I guess it's gdm whatever the default is when completing the installation. <iyzsong>UnderSampled: that's fine, but you'd probally want to remove slow ones from the list <hako>It's a mirror for bordeaux, not ci <iyzsong>yes, those have the same, both are mirror to bordeaux <iyzsong>piptown: okay, if bspwm doesn't show up, you can write a custom ~/.xsession script file for it.. <UnderSampled>I meant does bordeaux have different ones compared to ci <hako>And you need to put the mirrors first, since the order in --substitute-urls is also the fallback order. <iyzsong>well, it may or may not miss substitutes depends upon the "weather" on CI, better have both ci and bordeaux, but yes you should put fast ones first in the list <UnderSampled>guix install: error: reading file `/gnu/store/mh01bp841xvcvv8mv6car7l92h6h19rk-curl-7.84.0.drv': No such file or directory <UnderSampled>I deleted /gnu/store when making the bind-mount, figuring it would be okay since I didn't have anything installed yet <podiki>issues frontend has an expired certificate <Kabouik_>I'm really confused with the combination of btrfs + Guix. `btrfs fi usage /` says I have 53GB free (and 38GB unallocated), yet guix system reconfigure fails due to no space left on device. <graywolf>On what device? Could it be /tmp too small to build stuff? <Kabouik_>I only have a single partition though, /tmp should have 53GB available too <graywolf>Can you post output of df as well please? <graywolf>The df is weird. Should /dev at least be there as well? <Kabouik_>Not sure how this works, maybe cryptroot is adding one layer of complexity too? Anyway, thanks graywolf. <Kabouik_>Just in case, here is where my guix system reconfigure fails: https://0x0.st/H_TZ.txt At this point with a broken reconfigure, I'm not sure it's safe if my computer reboots or runs out of battery. <Kabouik_>Maybe the space is missing on /boot only? <jpoiret>Kabouik_: you're missing space on the efivars <graywolf>You might try the removable efi grub, that should not touch efivars at all I assume <jpoiret>also it should be safe to reboot because system upgrade is atomic <jpoiret>(well, maybe not the bootloader installation0 <Kabouik_>So, just `rm /sys/firmware/efi/efivars/dump-*`? <rekado>ACTION restarted nginx on ci.guix.gnu.org to refresh them certs <sneek>Welcome back rekado, you have 1 message! <Kabouik_>I just need to make sure it'll reboot fine despite the removal and the aborted reconfigure, since I'm currently at work (I could more easily take the risk to spend some time on fixing it if I was home). If it's safe, then I'll do it now because I need this reconfigure. <Kabouik_>So this is my concern after jpoiret mentioned "(well, maybe not the bootloader installation)" <jpoiret>nah, this is fine, grub gracefully exits <jpoiret>i was just wondering whether a power-off during bootloader installation would be catastrophic <Kabouik_>Alright, let's remove the dumps and try then. Not particulary used to removing * in a /sys subfolder. :eyes: <jpoiret>but still you might want to try to reconfigure right ow <Kabouik_>Yeah, trying before reboot first. Thanks. <Kabouik_>Worked immediately (I guess this was the last step of my interrupted reconfigure). <sevan>civodul: you're looking for someone with a phd to fight with autotools & other build infra? <minima>hi, yesterday i mentioned some issues with `home-unclutter-service-type', i.e. the fact that unclutter doesn't unclutter :) and the mouse pointer doesn't get hidden; the logs say something something could not access display <minima>unclutter works well if i start it from a terminal <minima>i tried restarting the service with `herd restart unclutter' but that doesn't help - it only adds a new error report to the log file <minima>possibly worth to mention that this is a guix and guix home installation on top of a foreign distro <minima>i guess this may have something to do with my x server not accepting requests coming from the shepherd user? <bjc>are you starting shepherd after you start your x session? <civodul>sevan: heh :-) not necessarily with a PhD, and there'll certainly be things much more fun than fighting with build systems! <bjc>otherwise it won't have the right environment variables set <bjc>a nice feature for us home shepherd users would be the ability to set environment variables after the shepherd has been started <civodul>bjc: yeah we need a way to handle X11 in user Shepherd and to pass $DISPLAY to the relevant services <minima>bjc: i do start shepherd before x, but last time i "home-reconfigured" the x server had already been started, maybe something wasn't picked up at the right time? <minima>no, that's exactly what you were saying <minima>oh ok, that explains the issue then <bjc>civodul: arbitrary environment variables should cover basically every case. something like "herd root setenv DISPLAY=:0". do you see a reason to have it more special-cased than that? <civodul>bjc: if we could express precisely what a service depends on (like "running X server"), then we'd also make sure those services are only started when their requirements are satisfied <civodul>in the meantime, one can do: herd eval root '(setenv "DISPLAY" ":0")' <bjc>i have custom services like that already (‘sway-tasks’ in my case, since i use sway). as part of sway's startup, it runs ‘herd start sway-tasks’. but i need to start it after sway starts just to get the environment variables in it <bjc>i hadn't thought of just using ‘eval’, maybe i'll do that. but it'd be nice to have a more blessed method <bjc>the systemd folks have ‘graphical.session’ or something like that, as an abstract hook. i'm not sure how that would translate to the shepherd, though <civodul>we could have an x11-session service that gets started once someone is listening on port 6000 (and similarly for Sway) <bjc>start it via a file-watcher/inotify thing? does shepherd do that? <bjc>oh, i think i see. no shepherd smarts needed, just have a service that watches the appropriate thing and starts services on your behalf <civodul>actually these days it's "/tmp/.X11-unix/X1" <civodul>hmm qa.guix says "Yet to process revision" even for patches dating back to June <civodul>cbaines: hello! are you aware of an issue on the qa.guix interface that would lead to incorrect statuses? <dthompson>going to try jack + ardour on guix real soon and I couldn't have asked for a better blog post to read as prep. <minima>hm, i tried `herd eval root '(setenv "DISPLAY" ":0")'' but that didn't seem to fix my unclutter home service issue `could not open display' <cbaines>civodul, QA has been effectively rebasing all/most patches recently, I think due to branch merges (like tex-team-next) and the %final-inputs bug (which has a workaround now) <civodul>cbaines: oh, i didn't know it would rebase and reprocess branches <cbaines>so far I've just worked around this in the data service by making the order in which derivations are computed deterministic <cbaines>that at least means that there aren't wierd comparisons showing up in QA where lots of packages appear or disappear <apteryx>cbaines: hi! Suppose I propose to merge the elogind-updates branch by sending a merge commit, will it get built although it'd cause 3k rebuilds per architecture? <apteryx>I guess my question is: "is there a limit to the number of rebuilds caused by a merge request to build the branch with QA" ? <cbaines>apteryx, nope, there's no limit to the number of changes for a branch <cbaines>however QA will currently build the first two branches in the queue, but it looks like there's space currently since there's only rust-team currently waiting <efraim>I hope i686-linux catches up on qa.guix, rust-team hopefully shouldn't cause breakages <efraim>and I just finished packaging maturin for more python packaging <cbaines>efraim, now that milano-guix-1 is back, I'm hoping it'll catch up soon <apteryx>dgr: apply them locally, build the tree, then run something like './pre-inst-env guix build $package-name' <apteryx>then you can run it from the store or via './pre-inst-env guix shell $package-name -- $package-command' or similar <apteryx>since the linked series is to be used on a operating system definition, ideally it'd be tested by a system test, then you'd run 'make check-system TESTS=$test-name' <apteryx>to test it manually, you could reconfigure your system with it and test it, though beware in case of bugs, it could break your system and force you to reboot in an older generation <apteryx>maybe it has to do with the client cert I have configured for admin access? "The SSL certificate error" <dgr>apteryx: fist step "apply them locally" is done but "build the tree" isn't clear to me. <apteryx>see "info '(guix) Building from Git'" <minima>hi, i keep some log files at the user level, e.g. in `~/.local/var/log/'; is there any way to tell guix home to use that path, while hardcoding as little as possible of it? any standard way to "expand" XDG variables? <hako>There's a %user-log-dir variable from (shepherd support). <hako>You can find its use, for example, in gnu/home/services/ssh.scm. <teku>Hi all, i am trying to figure how to configure a swap space (not sure if file or partition isbest / required) for hibernation on a encrypted device. Anyone have a working config? Thanks <nckx>teku: I suspect jackhill does <nckx>As for file vs. partition, file adds some complexity (fragility) that I would personally avoid if all else is equal. <apteryx>I've tested the latest elogind on a x200; works fine <apteryx>cbaines: is the naming convention for merging branches documented? <apteryx>I don't see what it should be named from reading "info '(guix) Managing Patches and Branches'" <apteryx>maybe just the merge commit to master sent with 'git send-email' ? <apteryx>ah, format-patch can't output patches of merge commits, hm <jackhill>PotentialUser-60: I think `guix pull` will get you a new guix command paired with new package definitions, then a `guix package -u` and `guix system reconfigure …` will give you an updated profile and system. <Altadil>it has basic commands, including for updates <layer8-problem>Hello, i have problem running the command `guix home container home-configuration.scm`, this is in a git-repo. It complains about not finding the file or directory, although it does exist in the current directory. If I run `guix home import .` and then use the new file - it works. If i git restore the previous version, it fails again. What am i <RavenJoad>If I use the certbot-service-type, do I need to manually generate the certificates the first time? Do I need to manually add a job to periodically refresh the certs later too? <viaken>Is it possible to write directly to /proc/(pid)/environ? <viaken>Oh shoot. I was stuck in scrollback. <pinoaffe>RavenJoad: you don't need to manually generate the certificates the first time (though you can, to speed things up), and such a job is added automatically <pinoaffe>I've had quite some issues with certbot-service-type though, so it's a good idea to keep an eye on it for at least one refresh cycle, and to familiarize yourself with it <pinoaffe>oh and you shouldn't add several instances of certbot-service-type to a single system, I found out the hard way that that doesn't work <crzjp>hey folks, what's the status for emacs 29.1? <RavenJoad>pinoaffe: Ok, thanks. The VM I am testing with right now did not have the certbot certs generated yet (/etc/letsencrypt/live is empty), so I wanted to double-check, since I could see this being a non-automate-able step. <RavenJoad>I was not planning on adding several instances, but thanks for the heads up! <RavenJoad>The problem with certs not being there seems to be due to my misconfiguration somewhere. <graywolf>Anyone knows how far away we are from emacs 29 in guix? <nckx>emacs-next is the emacs of the future, today. Just not .1. <nckx>My above link (not my message) is as firm a roadmap as you'll get. <apteryx>looks like the [m] users are on a forced vacation <cbaines>apteryx, the naming convention for issues for merging branches isn't documented yet, but it seems like people are happy with the current convention, so maybe we should document it now <apteryx>just to be sure, *what* is the current convention used? <apteryx>ACTION tries to package yubikey-manager-qt