IRC channel logs


back to list of logs

<jackhill>Hey, looks liek the cert for expired
<jackhill>not sure who's responsible for that. nckx ?
<graywolf>Did the cert of expire?
<vagrantc>graywolf: looks like it to me
<vagrantc>you can get the classic debbugs interface at
<graywolf>Thanks for the sanity check. Yeah, will do that.
<vagrantc>but yeah, 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>65002 and 65061
<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?
<vagrantc>otherwise it could leak the keyfile...
<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
<graywolf>yeah that is better way to put it :)
<ulfvonbelow>(I did a similar modification locally)
<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>it's painfully close to being doable
<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
<vagrantc>how many initrds can grub handle?
<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
<vagrantc>works fine with u-boot
<vagrantc>i think it might be linux-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
<vagrantc>reconfigure seems plausible ...
<thanosapollo>gnu-morning #guix
<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
<stevenroose>How do I enable the sdhci kernel module in Guix?
<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.
<samplet>(I’m not on Debian.)
<stevenroose>samplet: thanks, will try that
<lh>> Hey, looks liek the cert for expired
<lh> as well
<lh>hsts 😔
<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?
<UnderSampled>(I'm running in debian, not guix-sd
<iyzsong>UnderSampled: i think you can move it there and then bind mount it back to /gnu/store.
<UnderSampled>I know I can mount something
<UnderSampled>but, the documentation ( says "by default"
<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.
<UnderSampled>Why does setting the store dir disable substitutes?
<iyzsong>build results are path dependents, eg: hello linked glibc to /gnu/store/....-glibc/lib/
<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>And why isn't it a distributed thing :D
<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>UnderSampled: US and Singapore bordeaux mirrors url can be found here:
<UnderSampled>what does Bordeaux mean in this context?
<iyzsong>we have 2 CI farms, one is at berlin ( 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?
<UnderSampled>How do I use the mirror?
<iyzsong>UnderSampled: add via '--substitute-urls "AAA BBB"' to 'guix-daemon' or 'guix' (for oneshot usage)
<UnderSampled>no config file?
<iyzsong>under debian i think it can be done with 'systemctl edit guix-daemon'
<UnderSampled>never done that before
<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>ExecStart=/usr/bin/guix-daemon \
<UnderSampled>    --build-users-group=_guixbuild --discover=no --substitute-urls ""
<UnderSampled>does that look right?
<hako>Need to include 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
<UnderSampled>so, then I don't gain anything by doing this?
<iyzsong>so you want to try the US/Singapore one if ci and bordeaux is slow
<UnderSampled>US sounds good
<UnderSampled> ?
<UnderSampled>that one?
<UnderSampled>okay, so the full list should be "" ?
<piptown>iyzsong: I guess it's gdm whatever the default is when completing the installation.
<UnderSampled>Trailing slash good?
<iyzsong>UnderSampled: that's fine, but you'd probally want to remove slow ones from the list
<UnderSampled>so just the mirrors?
<hako>It's a mirror for bordeaux, not ci
<UnderSampled> ""
<UnderSampled>do they have different substitutes?
<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
<UnderSampled>am I missing something by removing 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
<UnderSampled>(this error was from trying to install `kicad`
<UnderSampled>ah, running `guix gc --verify` fixed it
<UnderSampled>also, the mirror is much faster!
<UnderSampled>Thank you!
<iyzsong>cool, that's glad to hear!
<podiki>issues frontend has an expired certificate
<podiki>ditto for
<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>Isn't /tmp tmpfs or something?
<Kabouik_>That's what I get with fdisk:
<Kabouik_>sda1 is just a SD card
<graywolf>Can you post output of df as well please?
<Kabouik_>df (but likely not reliable due to btrfs):; and btrfs fi usage /:
<graywolf>The df is weird. Should /dev at least be there as well?
<graywolf>But at this point no idea, sorry
<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: 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?
<graywolf>I did not see EFI partition in df...
<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>you should clean it up following eg.
<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-*`?
<Kabouik_>And then reboot?
<jpoiret>check that they are there though
<Kabouik_>They are
<rekado>ACTION restarted nginx on to refresh them certs
<rekado>(a couple of hours ago)
<sneek>Welcome back rekado, you have 1 message!
<sneek>rekado, daviid says: => 504 Gateway Time-out
<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).
<civodul>hey there!
<civodul>there are 3 open engineer positions for packaging/CI in HPC here, including Guix:
<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
<dgr>how to test ? I got a clone of guix and applied the patches but how do I acivate the code? I tried `guix pull -L path/to/git/guix` but it takes forever...
<sevan>civodul: ack :)
<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")'
<civodul>but that's more of a hack
<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?
<civodul>it could
<civodul>or it could poll :-)
<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
<apteryx>civodul: hi! welcome back :-)
<civodul>hey apteryx! tx :-)
<civodul>for instance, has substitutes available at bordeaux.guix, so it's definitely been built
<civodul>but says "Yet to process"
<civodul>cbaines: hello! are you aware of an issue on the qa.guix interface that would lead to incorrect statuses?
<dthompson>I re-read recently and heck rekado is just on another level on this one.
<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
<civodul>that explains it
<civodul>(what's the %final-inputs bug?)
<cbaines>civodul, it's a bit crude but currently it'll remove (and then recreate) patch branches when there are 10,000+ changes for i686-linux between the base revision for the patch and the latest processed master branch revision
<cbaines>civodul, as for the %final-inputs bug, that's described here
<cbaines>there's a patch here but I think it needs to set the port filename, and I also still don't really understand where exactly things are going wrong
<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
<civodul>ACTION looks
<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
<apteryx>sounds good
<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
<dgr>What is the workflow to test patches? I what to try out and verify
<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>hm, is returning a 400 for someone else?
<rekado>apteryx: works for me
<apteryx>maybe it has to do with the client cert I have configured for admin access? "The SSL certificate error"
<apteryx>was working fine until recently
<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
<minima>hako: oh lovely, 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
<PotentialUser-60>How to update guix in virtual Box?
<pinoaffe>hi guix! could someone take a look at , , and (a total of 4 new emacs-xyz packages)
<PotentialUser-60>Can anyone please tell me how to upgrade guix please.
<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>PotentialUser-60: take a look at
<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
<layer8-problem>doing wrong? Any suggestions?
<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?
<nckx>Better link:
<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.
<graywolf>Thanks :)
<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