IRC channel logs
2026-04-04.log
back to list of logs
<dan>Added the authentication keys and now my guix pull completed successfully! When I try to deploy, I see the same error about the source guix channel not being an descendant. <dan>I got this to work after pulling on the source machine as well (duh). Still getting used to everything. Trying to run the tests, running into an issue where I am hanging on the container test. Anyone seen this before? Working on the --exclude incantation, but no luck. <YAR_Oracool>How do I throw partition label as source in mapped devices? <YAR_Oracool>I just want to use a reusable system instead of UUID <dan>set up guix on a linode a few weeks ago, sounds like you might be doing something similar. <dan> ;; we configure our bootable guix system to be on device "/dev/sda" <dan> ;; if you want to use a different device, change it here <dan> (file-systems (cons (file-system <dan> (device "/dev/sda") <dan> (type "ext4")) %base-file-systems)) <dan> ;; our swap is assumed to be /dev/sdb. <dan> ;; if your vm will have a different swap device, change it here <dan> (swap-devices (list (swap-space <dan> (target "/dev/sdb")))) <ieure>dan, Use a pastebin, do not paste in the channel. <dan> (initrd-modules (cons "virtio_scsi" ;Needed to find the disk <dan> %base-initrd-modules)) <YAR_Oracool>if I give dev address, grub justsays: adresss? nah! get the hell ouuta here with that <YAR_Oracool>I did the normal adress like the guide. guix says grub might ignore addresss and ye.. .it did. my vm broke <dan>yeah sounds like you're pretty far ahead of me here. good luck <YAR_Oracool>I need that or a way to tell the system to inheret it from the previous config, or, set it up to throw the result of a command line that results in the uuid in there. <dan>maybe if it's possible to do after the main device setup, you could put your device mapping logic in a gexp to be run at system activation? that gexp may know the right uuid and be able to run the right command <YAR_Oracool>SInce I can't make partioins from configs. I'll have to bridge the gap <ieure>YAR_Oracool, Did using a disklabel not work out? <YAR_Oracool>ieure: Cryptlabel is assigend in device map. I can't assig it the label it makes <YAR_Oracool>And in mappeddevices dcs,there is no refrence to sourcing a volum label <YAR_Oracool>I can not any info on being able to say (source (label "xyz")) <dan>maybe time to read the source? <YAR_Oracool>dan: I can code my own C++ programs but reading an OS source code is beyond me <YAR_Oracool>huh.. .guess third times the charm and drive adress just worked... <mra>hey! so, i was having problems with guix on nixos. i decided to clone the guix repo, build guix using dependencies from nixpkgs, and then run ./pre-inst-env guix pull --no-substitutes to bootstrap guix so that i could have a setup which is independent of nixpkgs <mra>and i seem to be having the same issue with my bootstrapped guix <mra>within /gnu/store, i have an executable called <HASH>-guix-command, so i tried running /gnu/store/<HASH>-guix-command pull to complete pulling guix but now using substitutes <mra>but doing so seems to yield the same output and error as when i use the guix from nixpkgs. give me a second to send the error... <mra>this is the error that i'm getting <mra>it's confusing because it seems to still be failing on some nixpkg implementation of guix, even though i thought i bootstrapped an independent one! <dan>getting a "suspicious site is blocked" <YAR_Oracool>sounds russian so I can see amaerical places blocking it <mra>dan: shouldn't be an issue? paste.rs is a fairly common pastebin <mra>YAR_Oracool: .rs is serbian, not russian. russian is .ru iirc <test202020>hello. exist way to use in manifest custom unpulled chanbel? <Rutherther>test202020: Sure just put it to load path from a folder on your filesystem with -L <test202020>Rutherther: i mean to provide manifest for guix shell <test202020>Rutherther: how i can get sguix shell with my prefill packages? <test202020>Rutherther: i need to get container shell with packages for development environment and with my custom packages not pulled to home profile <Rutherther>Just put them to load path. Or use time machine that will do it for you <nckx>So are package variables in gnu/packages/rust-crates.scm also garbage-collected at some point? <Rutherther>nckx: I think not yet. But they definitely should be <kestrelwx>How would I get the PGP key needed to update nyacc? I get failure to fetch it. <nckx>Hunch confirmed, thanks! <nckx>Never mind, I had their key in my 'ring and pasted the wrong address to check. <kestrelwx>Oh, maybe the servers were down when I was trying. <postroutine>Hi. To come back about what I have talked about yesterday: Installing Guix System on a PC Engines APU2 computer. (A computer with no screen output, only UART) <postroutine>I have chosen to create an bootable image with `guix system image`, instead of modifying the Guix System installer disc to add it UART support. <postroutine>My bootable image is built from an `operating-system` definition, with Grub and the Kernel configured to use the UART 0 as an interface. And I activate the agetty service, also configured to use UART 0. <postroutine>For now, I only tested it in a VM. Using the commande `guix system vm` and by adding an UART to the QEMU system. <postroutine>Creating a bootable image instead of using the installer disc is verry nice. <postroutine>But to one exception: It will not set the users password. That mean, on first boot, I can login as root with no password. <postroutine>To be remembered, when creating system image to populate VM. Especially when we start the openssh service. <postroutine>I don't remember reading something about it in the manual. <postroutine>By chance, the setting `permit-root-login` of the `openssh-configuration` is set as `#f` by default. <postroutine>And `allow-empty-passwords?` is also set as `#f` by default. <postroutine>This is strange, why the setting `permit-root-login` don't end by a "?" while `allow-empty-passwords?` does ? <Rutherther>postroutine: so what's the issue? I don't get it <ieure>postroutine, Are you including password hashes in the operating-system configuration you're using for the image? If you don't include them, the users will have no password. <ieure>Potential-User, permit-root-login isn't a predicate; its value is a symbol. So no ? at the end. <ieure>nckx, I do not believe stuff in rust-crates.scm is GC'd. <postroutine>When the `guix system vm` and `guix system image` are used, the resulting system need to set manually the root password. To the contrary, the installer disk ask the root password to set. So, in the case of image and vm command, it could be forgotten. A small note in the manual, to remind it, could be nice. <Rutherther>postroutine: so are you saying you included the passwords in the operating system definition and they did not get set? <nckx>Then I guess my question becomes: should I feel obligated to check for unused packages when modifying it? Does anyone? <postroutine>Rutherther, no. I did not set them in the operating system definition. <Rutherther>postroutine: so I don't see any issues then. What is guix system image supposed to do when you didn't tell it to set any passwords? <Rutherther>nckx: I would say not at all. It doesn't make sense to me to do it at that time. Rather, it should be purged from time to time, I would say. That way it's going to be easier rather than 5 contributors trying to remove the same crates, repeating the same work and causing conflicts <postroutine>Rutherther, I think `guix system image` have nothing to do. It just say that it would be nice if the manual remind that, when creating an image or a vm, root password need to be set manually. To the contrary of the disc installation who, interactively, ask for root password. <Rutherther>postroutine: but it doesn't need to be set manually <Rutherther>you can just include the password in the operating system declaration and it will be set <Rutherther>nckx: it should be fairly simple to make a script to check for unused packages there <dariqq>there is the etc/teams/rust/cleanup-crates.sh script <postroutine>Rutherther, for root ? But, if I set the password in the operating system declaration, it would be stored in the Guix store. I don't think it's a good idea. <Rutherther>postroutine: you set it as a hash, not as plaintext <dariqq>i use that all the time for my custom channel, i guess the rust team does that on the guix crates regularly <Rutherther>nckx: dariqq I would say that rust-team should be taking care of this when doing rust-team branch rather than the contributors who add/update packages <RavenJoad>How can I get the doc output for all of the texlive packages when I install texlive-scheme-full into my home profile? <dan>q: why would "guix remove [package]" trigger downloads? <Rutherther>dan: guix operations are atomic, guix needs to build the profile again, it doesn't reuse the current profile. First of all, the tools for building the profile itself need to be fetched if they were gc'd. But also when there are grafts, the ungrafted package variants aren't gc rooted so on gc they're removed and they need to be fetched again for profile build. <nckx>kestrelwx: I really can't reproduce this, but it might be due our different GPG configurations. I'm far from an expert on how much of the user's configuration Guix uses, and what it overrides. https://paste.debian.net/hidden/3ed3f55f <dan>Rutherther: huh- thanks. good to know. it did come up right after running "guix gc". <nckx>It may download things even without a GC if you, say, pulled in the interim. Updated tools to build your profile etc. <nckx>OK, if I remove my ~/.gnupg I get ‘gpg: keyserver receive failed: General error’. Which is *still* wonderfully different from your ‘No data’ because computers are great and not at all evil. <dan>nckx/Rutherther: what guarantees this atomicity with remove? I can see how maybe with installs, a gexp or derivation would build a tree of dependencies before evaluating... but I can't see where a derivation is invoked in a removal? reading through the guix remove script now... <Rutherther>remove just means to build a profile with all previous packages except the one you want to remove, there is no actual remove involved in any way <nckx>Eh, what the hell, now I restored my ~/.gnupg (the previously working set-up) and get… ‘No data’ 😒 <dan>Rutherfer: ah! interesting <nckx>Either I'm being rate-limited $omewhere or I'm merely reminded why I never voluntarily deal with GPG. <dan>*Rutherther: (th not f, sry) <Rutherther>dan: if you want to actually remove the package from your store, you will need to remove the previous generations that contained it (ie guix package --delete-generations) and then run guix gc <dan>Rutherther: ty- trying that now <Rutherther>you can also use delete genrations on guix gc, but it will also remove ~/.config/guix/current generations <dan>Rutherther: yup still getting used to generations- tyty <nckx>It seems that having ‘keyserver hkps://keys.openpgp.org’ in my dirmngr.conf is what makes this work. <nckx>(You need to kill/restart dirmngr each time you edit it.) <nckx>And maybe ‘hkp-cacert ~/.gnupg/pems.nckx/le-concatenated.pem’ which I apparently created in 2019. No memory of that. <nckx>It's apparently ISRG Root X1. <RavenJoad>I get this error when I build a VM of my laptop. "guix system: error: EFI bootloader required with GPT partitioning". I just reconfigured my laptop with this config last night. <RavenJoad>Rutherther: Yes. I tried --full-boot already and that didn't address it. <RavenJoad>According to guix system list-generations, I have bootloader: grub-efi <Rutherther>right, the error is misleading, what it's trying to tell you is that the partitioning is not efi <Rutherther>as a workaround you will probably still have to switch the bootloader for the vm to be non-EFI one <Rutherther>as a long term solution the image generation for guix system vm should be remade so that it properly chooses efi partitioning when the system uses efi bootloader <RavenJoad>According to fdisk: Disklabel type: gpt, and /dev/nvme0n1p1 EFI System. <RavenJoad>Oh! The virtual disk doesn't have efi. Got it. <Rutherther>RavenJoad: wdym? disklabel of what? the image did not even build since it errored, how would you know its type... <Rutherther>I am looking in the code and it will use raw-with-offset-disk-image, meaning non-EFI one. <RavenJoad>Sorry, that was the output of my physical disk. I was attempting to answer that my partitioning /is/ efi. I didn't realize you meant the virtual disk. <Rutherther>guix system vm does not depend on your partitioning at all. It doesn't even depend on you running Guix System. Any guix installation should be fine <RavenJoad>Right. I was just confused. I'm surprised virtualized-operating-system doesn't set the bootloader field to something that guix system vm can use. <Rutherther>it did... until 0689ad6dd09ca212f5b62efcbe6ac2921cf2b03a <RavenJoad>I very rarely use guix system vm on my real configs. This is the first time doing it recently. I have some toy operating-system configs that I use for testing services, which always work. <RavenJoad>I just wanted to mess around with the wireguard services while I am busy compiling clang. <RavenJoad>I didn't realize it was an actual bug. I'll attach my system config, the command I used, my generations, etc. on that issue report. <Rutherther>I mean you can, but I don't think it's necesary. Simplest reproducer is "guix system vm gnu/system/examples/vm-image-efi.tmpl" in the Guix repo <RavenJoad>Fair enough. I included my details, just as another data point. <RavenJoad>While I have you Rutherther, would you happen to know how to get the doc outputs of the texlive-* packages when using a scheme, like texlive-scheme-full? <RavenJoad>Ok. Perhaps this is something I open an issue for or put on a mailing list then.