<nckx>/sys/firmware/efi exists? Partition table is GPT?
<ulfvonbelow>hmmm, it's not the exact same error message, but one of the more tragic things that can happen is if you boot from the install medium without explicitly specifying EFI boot, in which case the interface to efi variables doesn't appear at all and autodetects will think it doesn't support it
<nckx>Existence of the above /sys directory will indicate as much.
<ulfvonbelow>I had that happen to me before, though the error message was complaining about efi variables being unsupported
<nckx>festerdam: Was this the guided installer or the manual process?
<festerdam>In my config.scm I have (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) ...)). /mnt, /tmp and /mnt/boot/efi are mounted. /sys/firmware/efi does not exist. This was a mix between manual and guided installer. I first generated an initial config with the guided installer, and then changed the kernel and firmware field in the operating-system clause. After that I noticed it trying to
<festerdam>use BIOS/legacy boot instead of efi, which failed on my system (and I would prefer it to use uefi), so I changed the bootloader to grub-efi-bootloader and changed its target list to /boot/efi.
<festerdam>Good night. It-s also quite late here. Will see if the command works.
<ulfvonbelow>if you want to give invoking it manually a shot, you'll want the --no-nvram flag, and optionally the --removable flag too.
<nckx>I'd try using ‘grub-efi-removable-bootloader’ first. If this fails, festerdam can still install it manually, but then it's something we should improve in Guix, rather than helping one person once.
<nckx>festerdam: If your nickname is any indication, it's sunny there too. Good night!
<festerdam>Ok, with the explicit target set it says that EFI variables are not supported on my system and that efibootmgr failed with a no file or directory error
<geri>just the file generation + installing packages is already really powerful imo
<geri>for some reason (local-file "./gui/scripts/launcher") resolves the path properly but (local-file (string-append "./gui/scripts/" "launcher")) treats . as a $PWD in the shell, any idea how to fix this?
<mirai>you'll have to make your docker container listen elsewhere and reverse proxy it with the nginx service from guix
<Guest28>Just to be clear,. The container only listens on 443, though my guix nginx listens on 80
<Guest28>https://paste.debian.net/1285408/ this doesn't work either, if I go to test.pi.lan I get 502 (fastcgi://127.0.0.1:9000) it tries to connect to that address, but I have commented everything from cgit out
<lambdanil>the portals do not work, I have xdg-desktop-portal-gtk installed; the portal shows up in running processes but doesn't work unless I manually invoke $GUIX_PROFILE/libexec/xdg-desktop-portal-gtk -r
<lambdanil>I don't know, I've tried everything I can think of and portals are
<nckx>There's no over-arching ‘machine’ record type to specify (virtual) hardware.
<mirai>If a python package uses urlopen('https://example.com'), do I need to add something to the package definition to account for the SSL certificates? I'm getting: “… The returned text was '<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] …”
<mirai>“guix shell the-package curl nss-certs -- the-program” works but idk if adding curl makes sense since 'the-package' doesn't care about curl
<nutcase[m]>lambdanil: I have `xdg-desktop-portal` and `xdg-desktop-portal-gtk` (and -wlr for wayland) installed. In my login scripts (or to be more precise: in my sway config) I have `dbus-update-activation-environment --all` (after a dbus session daemon was started). 'xdg-desktop-portal` and `xdg-desktop-portal-gtk` are started automatically on login
<bionicbabelfish[>Guest28: $(guix system -L /any/extra/modules vm vm.scm) -m 4G -smp cores=2
<mirai>nckx: could you take a look into updating flac when you get the chance to? being that its one of those ubiquitous but 'team-less' dependencies I'm afraid that it will require the more exotic updating process