IRC channel logs


back to list of logs

<freakingpenguin>Some services extend a service-type with (const #t) to ensure that particular service is present in the environment. How is that service-type converted into a service of said type?
<freakingpenguin>e.g. cgit-service-type
<jackdk>I really want guix to build everything without substituters, and I seem to be running into . Is there any progress toward a resolution here? Can we fake the system time during the build, or tweak the test suite?
<apteryx>freakingpenguin: I agree it's a bit hurdful
<apteryx>it looks like I have a gvfsd process started as my user (by my session manager?) that has
<apteryx>GIO_EXTRA_MODULES=/gnu/store/qgb5y0f3761f2cb11f48s6fbzg3fkc7i-glib-networking-2.76.1/lib/gio/modules:/gnu/store/ark6dhfyw0w1im0gps37yclizqpz7hxz-glib-2.78.0/lib/gio/modules:/gnu/store/l38xglcs9hxynf33mhn22mnl8rgnnjkz-gvfs-1.50.7/lib/gio/modules:/gnu/store/ark6dhfyw0w1im0gps37yclizqpz7hxz-glib-2.78.0/lib/gio/modules:/gnu/store/c247fm0linxwlx42l8k8wq31dlvd4aqn-dconf-0.40.0/lib/gio/modules in its
<apteryx>that should be enough to get gphoto support, as it's built in gvfs itself
<apteryx>so perhaps libgphoto2 or the gvfsd-gphoto2 daemon that uses it doesn't work as intended
<PuercoPop>how do I try to build my config with a patch applied? Currently my guix home is failing after a pull. It looks to be related with libunibreak, and there is issue open
<PuercoPop>I want to see if the patch fixes my issue.
<apteryx>you build from a guix checkout locally with the patch applied
<apteryx>then you ./pre-inst-env guix home ...
<apteryx>after pluging the camera a new 'gvfs-gphoto-volume-manager' process is launched, as well as gvfs-mtp-volume-manager
<apteryx>so it seems the detection part works and the right components are started
<PuercoPop>apteryx: I have guix cloned locally, but I haven't used it to build anything.
<PuercoPop>So I should apply the patch locally and try running guix home using ./pre-inst-env?
<apteryx>./configure && make -j$(nproc)
<apteryx>then you can ./pre-inst-env something
<shcv>what's the best way to set up an assembler + linker for risc-v? I'd like to try doing some "bare metal" stuff in qemu
<freakingpenguin>shcv: shows a cross compilation toolchain for aarch64 (arm 64), might be similar for risc-v.
<freakingpenguin>Plus some extra stuff to get guix packages available in cross-compiled form visible to the toolchain.
<apteryx>mirai: at least visiting 'gphoto2://[usb:002,021]' in nautilus shows the photo.
<apteryx>the usb address was found with 'gphoto2 --auto-detect'
<apteryx>the question is just why isn't nautilus showing this device to be mounted in its left panel before I do so
<mirai>is this MTP?
<mirai>I know it should be working™ but perhaps it would be faster to simply pull out the SDcard?
<apteryx>it's PTP
<apteryx>I found a way to make it work for now (inputting 'gphoto2://[usb:002,021]' in the nautilus location (URL) bar)
<apteryx>but it'd be delighted to find how to have nautilus list it from the first place so that I could just click on it in its left pane to have it mounted
<apteryx>(as with usb storage devices)
<apteryx>I'd be*
<sneek>wb efraim!!
<adanska>hi guix!
<ngz>I wonder if there's a possible mechanism for committers to augment the build farm temporarily with their personal computer. It might help a bit when core-updates branch is being built.
<futurile>Morning all
<fnat>Weird... I see 'ublock-origin-icecat' is available via 'guix search'. I can also regularly do things like 'guix shell ublock-origin-icecat'. However, if I add it to my home profile (in my 'home-configuration.scm'), I get 'error: ublock-origin-icecat: unbound variable'.
<fnat>Of course I included the necessary import at the beginning.
<fnat>'#:use-module (gnu packages browser-extensions)'
<fnat>Hrm... and also 'error: ublock-origin-chromium: unbound variable' despite including '(gnu build chromium-extension)'.
<fnat>Uneasy feeling that I must be missing something (obvious?).
<ngz>fnat: Maybe add (gnu build icecat-extension) since the error is about `ublock-origin-icecat'?
<pinoaffe>fnat: the variable names are ublock-origin/icecat and ublock-origin/icecat, respectively
<pinoaffe>I found this out by running `guix edit ublock-origin-icecat` and scrolling to the variable definition (the define-public .... line)
<fnat>Ha! Interesting! Let me try that way then.
<pinoaffe>the confusing part is that package names and the public variable names that a package object is bound to need not match
<fnat>pinoaffe ngz: Thank you! It works now. :)
<fnat>True, slightly confusing. I wonder if this should be made more consistent with the other packages.
<jpoiret>fnat: not possible, e.g. when we have different versions of packages they're often named e.g. `guile-next` vs. `guile` and not `guile@specificversion`
<fnat>jpoiret: Hm, not sure I understand. Yeah, I was speculating whether we could have 'ublock-origin-icecat' (or chromium) as opposed to 'ublock-origin/icecat', which would seem to be compatible with what you're saying?
<jpoiret>in this case yes, but it can't really be a policy
<fnat>Ah... I see what you mean, like a general rule.
<fnat>There's something else which is slightly puzzling. 'guix search ublock-origin-icecat' returns 'gnu/packages/browser-extensions.scm' as its location, whereas 'guix search ublock-origin-chromium' returns... 'gnu/build/chromium-extension.scm'. Despite the fact they're both defined in 'browser-extensions.scm'.
<fnat>To be clear, this is not a blocker for me. I was able to install both extensions thanks to the tips above ('/' instead of '-' in the package name). But still slightly surprising.
<Guest82>Hi, I can't boot my Guix system after a recent reconfigure. It asks for my encryption password the first time, and I get past that and to the Grub menu.
<Guest82>However, when selecting a Grub entry, I'm then told: "symbol 'grub_is_shim_lock_enabled' not found".
<Guest82>And sent back to the Grub menu.
<Guest82>Ok, I was able to boot into a live distribution and luksOpen+mount the partition. So the drive should be ok. I'm now going through various forums to see what the solution to this might be.
<Guest82>To start with, I see that /boot/efi is an empty folder. I wonder if I should have something there instead of in /boot/grub/...
<Guest82>I wonder if it might be just a matter of copying /boot/grub/x86_64-efi/grub.efi to /boot/efi/...
<bnes>I have a ci replacement server blocked and when guix system init /mnt/etc/config.scm /mnt it tries to connect to both servers, sometimes downloads but often writes 0% messages.I want to replace the server with a second one. i wrote guix-daemon --build-users-group=guixbuild but nothing happens. how do i make
<bnes>it use only 1 server by default
<bnes>I used https and quotes.and now the first command guix system writes daemon socket connection failed
<apteryx>mirai: my ducktape solution:
<apteryx>would be nice to figure out how to get it registered in nautilus before opening it via its URI in the first place
<apteryx>perhaps I'll open an upstream bug about it; it's probably our fault but hopefully they have the knowledge te help us resolve it.
<Guest82>I see ISO images can be downloaded from Any chance signatures might be available for these images?
<mrvdb>Hi guix. I'm trying to use a later revision of the chirp package, by inheriting from it. Seems to compile/check fine, but the sanity-check phase fails. See: Is this because I used the name "chirp-next"? How to proceed?
<attila_lendvai>Guest3080, do you have a separate /boot partition? if yes, then it must be mounted when reconfiguring. if it wasn't, then maybe the updated files were written to your root partition instead of /boot? or maybe /boot/efi wasn't mounted at reconfigure for some reason?
<attila_lendvai>Guest82, that^ was meant for you
<Guest82>attila_lendvai: Ha! That must be it then. Yes, I have a separate /boot partition.
<Guest82>I'll go and redo the reconfigure in a chroot.
<attila_lendvai>Guest82, if this is the case, then you may try to simply copy the files from /boot/ on your root partition to the actual /boot partition.
<Guest82>attila_lendvai: all of them, recursively?
<Guest82>And I noticed /boot/efi (in the mounted root partition) was empty, files were in /boot/grub - is that expected?
<attila_lendvai>Guest82, i guess all of them, excep that /boot/efi must also be a separate partition, IIRC with fat filesystem. it is read by the bios.
<attila_lendvai>ACTION checks his files
<attila_lendvai>my /boot is on my root partition (full disc encrypted). i have /boot/efi as a separate partition, and only a /boot/grub dir that contains all the grub files.
<attila_lendvai>Guest82, i think first grub is loaded from /boot/efi, then it unlocks my root, then reloads the grub and its config from the unlocked /boot/grub/
<Guest82>Hm... it might be the same here (I'd need to double check as the drive is not mounted now).
<Guest82>Yeah, I also have full disk encryption, I think with the same partitioning / mechanism.
<Guest82>I'd be tempted to think that a reconfigure might be safer and easier?
<attila_lendvai>Guest82, i only have a sinlge /boot/efi/EFI/Guix/grubx64.efi file, i.e. no config. i guess the file contains instructions, or some default config to try to open encrypted partitions...?
<attila_lendvai>Guest82, yeah, just do the reconfigure from a live boot as instructed in the manual.
<attila_lendvai>Guest82, just make sure that you have everything mounted to their right place before you start the reconfigure
<Guest82>Excellent, I'm going to try that. Thanks so much. I'll keep you posted as I go.
<faust45>Hi Guix!
<vagrantc>ACTION waves
<faust45>can I ask here question about nonguix installation process?
<vagrantc>faust45: this is for guix only, nonguix is elsewhere
<faust45>vagrantc: asked at nonguix, but silent
<Guest82>Hm, I'd like to follow this to repair my system.
<Altadil>faust45: nonguix has even less people, so it might take a long time for someone with the solution to read. Don’t despair. :)
<Guest82>However, it recommends to use one of the latest images to create a bootable USB. But I understand these images are not signed?
<Guest82>What are the risks of using 1.4.0 instead?
<vagrantc>Guest82: some of the software in 1.4.0 has unpatched security issues ...
<vagrantc>ACTION tries to remember of the guix-daemon ugly is in there
<Guest82>vagrantc: right, but would that be relevant if I just chroot in my drive's system?
<Guest82>I'm weighing pros and cons of using a more recent - but unsigned - image...
<vagrantc>yeah, it's kind of blind trust vs. blind hope :)
<Guest82>Haha that's a nice way of putting it. Ok, I'm going to create the image from another Guix machine.
<Guest82>My machine no longer boots after a reconfigure (more details mentioned above). I've now booted into it from a Guix live USB and mounted the drive on /mnt, including the boot partition to /mnt/boot/efi.
<Guest82>I noticed that my recent reconfigured created a /boot/efi/EFI/BOOTX64.EFI.
<Guest82>But I can see an older one on /boot/efi/EFI/Guix/grubx64.efi.
<Guest82>The former is actually: /boot/efi/EFI/BOOT/BOOTX64.EFI, sorry.
<Guest82>Should I copy BOOTX64.EFI over to grubx64.efi?
<Guest82>I have a feeling that my machine is able to see the EFI Guix folder but not the BOOT one.
<Guest82>And my BIOS is not very friendly and doesn't allow me to pick whatever EFI file I want.
<simendsjo>How does people handle private ssh and gpg keys with guix home? I was thinking about adding gpg-encrypted versions, but is this a dumb idea?
<Guest82>I re-run the reconfigure from within the chroot. It worked, but again the new EFI file was put in /boot/efi/EFI/BOOT/BOOTX64.EFI instead of in /boot/efi/EFI/Grub/grubx64.efi.
<Guest82>I already use (bootloader grub-efi-removable-bootloader).
<Guest82>No luck, I reconfigured the system from the chroot, I rebooted, but I'm still unable to go past Grub because of the error: symbol "grub_is_shim_lock_enabled" not found.
<Guest82>ACTION scratches their head...
<vagrantc>Guest82: that sounds like the default fallback path for EFI
<vagrantc>Guest82: did you cop ythe config from a live image or something?
<vagrantc>it's basically the path EFI should try if it cannot find the right EFI variables or something
<PotentialUser-64>Hello, i'm trying to build a wayland sway guix and i'm getting the blinking cursor issue as was talked in in september/october 2023.. Anyone could confirm if this bug is not happening anymore in latest release (even the stable one.. i maybe doing something wrong..) (the system is working fine with gnome)
<PotentialUser-64>i'm I at the wrong place to ask for this?
<Guest82>vagrantc: Thanks. Then I was just following a wrong lead. The actual issue I'm having is that I unlock my LUKS once, I get to the Grub menu, select an option from the menu, then get the error re "grub_is_shim_lock_enabled" and get sent back to the menu.
<Guest82>From a moment I thought that could be related to the EFI file being saved in a wrong location, but it was just a bit of a random guess.
<Guest82>I went as far as chrooting into the system with a live distro and launching a reconfigure, but that didn't help.