IRC channel logs
2023-07-09.log
back to list of logs
<vagrantc>well, the kernel may not have support to reveal the information or may not have configurations enabled to allow that cpu to display such information <vagrantc>or less likely, the hardware doesn't support it ... <festerdam>Hi, all. I-m trying to install grub/efi, but the installation fails with /some/path/modinfo.sh doesn-t exist please specify //target or //directory <festerdam>Correction follows. I'm, grub-efi, doesn't, --target, --directory <festerdam>For some reason the keyboard layout chosen has no effect on the tty of the install medium <festerdam>grub-install --boot-directory /mnt/boot --bootloader-id=Guix -efi-directory /mnt/boot/efi <ulfvonbelow>might have to elaborate a bit on that /some/path part <festerdam>ulfvonbelow: /gnu/store/hash-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh <ulfvonbelow>and what does 'ls /gnu/store/hash-grub-efi-2.06/lib/grub' tell you? <nckx>grub-efi wil contain x86_64-efi. <nckx>So GRUB thinks it's being called to install in non-EFI mode. <nckx>Is everything mounted correctly? <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? <nckx>What does your bootloader field look like? <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. <nckx>You need to boot in UEFI mode to install GRUB that way. <ulfvonbelow>if you need to boot in UEFI mode in order to install a UEFI bootloader, how did the first UEFI bootloader ever get installed? <nckx>I wonder if the ‘grub-efi-removable-bootloader’ would work, since it doesn't try to set a boot variable. Probably untested and unlikely, though. <festerdam>Could I try to guix install the missing software on the installation medium or would it still fail/wouldn-t work? <nckx>festerdam: What happens if you invoke the above grub-install command with an explicit ‘--target=x86_64-efi’ argument added? <festerdam>I-m assuming some software is needed to be able to install an efi bootloader. <nckx>This is not due to missing software, no. <nckx>We're invoking GRUB in a manner that makes it ‘auto-detect’ the desired mode, badly, and it detects i386 (‘not UEFI’). Since this is an EFI-only GRUB package, that doesn't end well. <nckx>The only reason GRUB would ‘require’ to be booted in EFI mode would be to set a boot variable, but writing everything to disc wouldn't require that. <nckx>ACTION has to go to bed, it's light out. <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 <jpoiret>sneek, later tell civodul: Reviewing the patchset, there's one thing I'm not too happy with: janneke added a glibc-locales for 2.37, which is also called glibc-locales. <jpoiret>sneek, later tell civodul: Problem is, then for all other systems as well the glibc-locales 2.35 is being shadowed by this one, even though it's not a supported system! <jpoiret>sneek, later tell civodul: We could rename it to glibc-locales-hurd but personally I'd rather have specification->package select a package that's supported by the system if possible. <janneke>jpoiret: yeah, i "played" with libc-locales-for-target, but didn't succeed in actually using it <jpoiret>the code itself is okay, it's the way we handle package specification that is a bit stinky <jpoiret>I wonder how it works for eg librsvg on aarch systems <janneke>no, libc-locales-for-target is not used, we should probably skip/postpone that patch <jpoiret>that's good then, lets us postpone the solution to it as well :) <jpoiret>since i know some people use the locales on the command line <janneke>you've seen youpi's answer i got for for netdde.static right, that would be needed for booting from NFS? <janneke>so we may want to keep it possibly add a comment? <jpoiret>ah, librsvg-2.40 is hidden, but then why doesn't `guix build -n --system=aarch64-linux librsvg` give me at least a warning saying that this isn't supported? <jpoiret>janneke: is the = in `(noisy-setenv "BSDOBJDIR=" (string-append (getcwd) "/obj"))` expected? <janneke>jpoiret: oops, no that's a typo (copy-o?) <janneke>and that most probably means we can do without it entirely! <janneke>i've copied and adapted this from debian/rules, of course <janneke>ACTION appreciates jpoiret's sharp eye ;) <jpoiret>it's very impressive that we can manage to mostly build debian's packages without too much work :) <janneke>ACTION read that a bit like: let's give up and switch to debian ;) <jpoiret>aha no, rather we can just leech off someone else's battle with autotools <geri>is there a simpler way to "install" a script with guix home than creating a package definition? <janneke>right, i'd like to see it as a cooperation, in some way <janneke>actually, i've created patches to their build system non non-multiarch toolchain, and helped to greatly reduce the git archive, so yeah :) <jpoiret>geri: you should be able to use just a (local-file ...) or (mixed-text-file ...) instead of a whole package definition I think <jpoiret>ah, but not if you want it in eg. bin/ <geri>i just want it to be in PATH <geri>rn i got a "little" wrapper to quickly define a package but that feels overkill <janneke>ACTION thinks ~/bin should be possible? <jpoiret>geri: well, my other thought was using directory-union with some local-file <jpoiret>if you want it to be in PATH automatically i'd recommend making it end up in the GUIX_PROFILE/bin, not in ~/bin <jpoiret>but again I don't use guix home so I can't really test it out either <geri>jpoiret: i feel that, i had 12 files/directories in my home directory before recently :D <geri>jpoiret: do you manage your dotfiles with symlinks/git/whatever to be more portable? <jpoiret>I use one org-mode file to tangle all my dotfiles <geri>i basically stopped using org because its soooooo slow to load <geri>it literally makes startup time like 5 times what it is now <jpoiret>but yeah i just have my emacs open and never close it really <jpoiret>i do plan to switch to guix home at some point but ... i'm not 100% satisfied with where it is right now but haven't tried improving it either <geri>yeah, problem is if my emacs config is in org mode it takes at least 6 seconds to start fixing things, which is a pain because i tend to restart emacs to ensure clean state <geri>i'm still experimenting with guix home cause i want at least my shell and emacs configs to work on non-linux systems <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? <janneke>ACTION grumpily works around that by inserting (current-source-directory) <geri>gives me an unbound symbol error, is it in some particuar module? <geri>current-source-location seems to be it <geri>nvm, it doesn't work with modules <geri>or i shouldn't use modules instead <geri>janneke: found it in (guix utils) <jpoiret>janneke: am i right thinking that the gnumach noide patch could be applied to gnumach only, not gnumach-headers? <jpoiret>otherwise I think i'm mostly through the review <jpoiret>couple of changes but nothing drastic <jpoiret>i'm just taking this opportunity to sort out where each patch should go <janneke>jpoiret: yes, that's probably better <janneke>also, gnumach-add-missing-const_mach_port_name_array_t-type.patch is unused and can be removed <Guest28>Shouldn't web services like cgit detect that port 80 is already in use and therefore not even allow to reconfigure the system? <mirai>Guest28: cgit service isn't your typical daemon <mirai>behind the scenes it generates a nginx config snippet <mirai>and I don't think its feasible to make services aware of each others port (unless they're all plumbed through something like inetd) <Guest28>Ah okay, well I thought maybe it was some edge case that could be easily checked and wanted it to mention <nckx>What's already using port 80? <Guest28>Just a docker container. I wondered if I get some fancy error message. Turns out it just starts nginx and nginx will fail. <mirai>Guest28: did you run guix pull recently? <Guest28>mirai: No, state is from 22 dec, 2022 <mirai>The nginx service from guix probably launches faster than your docker container <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 <jpoiret>lambdanil: do you have XDG_CURRENT_DESKTOP properly set? what's your WM? <jpoiret>do you do `dbus-update-activation-environment XDG_CURRENT_DESKTOP WAYLAND_DISLAY`? <lambdanil>in XFCE, using the xfce-desktop-service-type service <jpoiret>xfce itself should take care of this <lambdanil>Flatpak starts the portal but somehow it fails to connect the backend it looks like <lambdanil>fixed by adding "$HOME/.guix-profile/libexec/xdg-desktop-portal -r &" into my login commands, not a proper solution but it works <jpoiret>i'm guessing dbus is not starting the program with the right environment variables <jpoiret>what if you do `dbus-update-activation-environment XDG_CURRENT_DESKTOP WAYLAND_DISPLAY` very early? <lambdanil>is WAYLAND_DISPLAY necessary with xorg? Anyway I'll look into it some more later, for now I have a workaround that gets the job done, thanks for the help <Guest28>Is it possible to tell guix system image vm to producde something with more than 512mb ram? <singpolyma>nckx: guix system vm can produce a script to auto run the image with qemu IIRC <nckx>Then pass -m 2G to that script. <nckx>singpolyma: That's without ‘image’. <Guest28>yea, i need to modify the script all the time <nckx>No, it accepts arguments. <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 <nckx>curl has these set, so adding curl as a ‘consumer’ to the shell is what sets them for you package, as something of a side effect. <Guest28>bionicbabelfish[ thanks, that is what i needed <e5df784>Im trying to install guix on arm board orange pi 4. guix can not install u-boot bootloader <e5df784>I run `sudo guix system init system.scm /mnt` get "Failed to install U-Boot" after coping files <mirai>nckx: :)) I think I authored this bit <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 <mirai>grafts or ???-whatever its called <nckx>mirai: Which CVEs did you have in mind? <mirai>uuh, I'm not exactly recalling which ones in particular <mirai>let me see if I have some note in my org files <nckx>They don't appear to be mentioned in the release notes. <mirai>huh, got nothing on my notes <mirai>and searching for flac CVEs only gives me pre-1.3.4 ones <mirai>wonder where I read about it <mirai>the last flac release notes do talk about “fixing a lot of bugs” though <nckx>Sure, but then we don't need a graft. <nckx>I'll just update it on core-updates and it will trickle up to master eventually. <nckx>Since it's just a straightforward update now. <mirai>there's no core-updates though :) <mirai>… unless something changed? afaik c-u is gone <nckx>And if flac is ‘team-less’, what's the idea? <nckx>mirai: It's possible I (re-)created it when pushing. <mirai>😂 I too wonder about its answer <mirai>I've got a few patches that are c-u grade material <mirai>short of starting something silly like “mirai's patch orphanage” or “no-team” <mirai>best if you can read it with NNTP or something that can show threaded answers <nckx>Indeed, that should be used with import-modules. <nckx>Stupid thinko, but thanks for the thread! <nckx>It's a bit creepy how much Guixmuscle-memory got lost over a mere few months. <nckx>I'll fix it with some other commits. <mirai>it's not the only package that over-imports so you wouldn't be the first one <mirai>but perhaps you might want to grep and fix the other ones as well? I believe they're not too many <cbaines>we even have a "core" team, so I think this fits within the proposals team related branches too <nckx>Let's call it core-updates. <mirai>so s/core-updates/core-team/ ? :) <nckx>I didn't think it included left-overs. <jpoiret>core changes should really be core changes though <GNUtoo>hi, is it possible to build a package from a script with "#!/usr/bin/env -S guix repl --" ? <jpoiret>`#!/usr/bin/env -S guix build -f` seems more appropriate <GNUtoo>It's for building packages that I then reuse to run commands or produce configuration that is then modified <GNUtoo>But if I do (build-package hello), hello is not built <GNUtoo>So if I want to then call hello with (with-store store (system* (derivation->output-path (package-derivation store hello)))) the binary is not there <GNUtoo>ACTION wanted to experiment with that for automatic tests, reusing some packaged configuration inside a host distribution, etc