<plattfot>When I created the patch it worked fine on my machine (still does). But as the bug report shows some users are having issues with it not finding some of the code. And I can reproduce the issue on my laptop.
<zceejkr>Hello, I just installed GNU Guix with the graphical installer on my laptop. The partition table was a GRUB partition and a system partition. But now when I try to boot, I get told that no bootable device is found. I tried both Legacy and UEFI boot modes. Any ideas what to do?
<atkka>zceejkr: if the installer finished successfully, reboot into your system's bios/uefi and point to your bootloader manually
<stikonas[m]>I would first boot livecd and check situation with e.g. fdisk
<zceejkr>atkka so I found a menu that allows me to enter costum boot path. Is it something like /dev/sda?
<zceejkr>What I mean to ask is, what do boot paths look like
<atkka>it will depend on the uefi/bios probably, on mine it says something like hd(0) gpt ... and some other stuff, I can select that then /boot/efi and grub64.efi or something along those lines
<atkka>but I have to do that fairly often as lots of distors don't seem to populate my boot list automatically
***apteryx is now known as Guest91811
***apteryx_ is now known as apteryx
<PotentialUser-32>I am trying to load the v4l2loopback kernel module. I have installed the eponymous package but are struggling to get the module loaded. I tried adding (service kernel-module-loader-service-type '("v4l2loopback")) to my operating system service declaration but see no effect. I am on Guix SD (inside a qemu VM). Anybody can help me please?
<mroh>PotentialUser-32: you could try `(kernel-loadable-modules (list v4l2loopback-linux-module))` instead of the service, but I guess qemu could complicate things, idk.
<Zaladane>I'm looking over the manual and I can't find a section that outlines this bit, but is it possible during the graphical installation process to select no desktop environment/tiling window manager and have Guix just do something like a base install --- like you would if installing without selecting one of the available DE/TWM during an installation
<mhj[m]>Heyo, just a quick question. On the site https://hpc.guix.info/ , there used to be a way to search for packages instead of browsing through them. Now whenever I go to the 'browse' link on the site I posted, you can only browse. Is hpc.guix.info part of the official guix site or is it run independently? Just wondering, because searching for packages is so much easier than browsing through them haha
<marusich>dftxbs3e, I see that when using the powerpc64le-linux bootstrap binaries, glibc-final-with-bootstrap-bash (that is the variable name; it refers to a package with name "glibc-intermediate") fails to build because there is an "undefined reference to `__mulkf3'". Since this sounds related to https://gcc.gnu.org/wiki/Ieee128PowerPC I thought you might already know what to do to fix it?
<apteryx>hello! Are these errors during offloading caused by network glitches? "Throw to key `guile-ssh-error' with args `("read_from_channel_port" "Error reading from the channel" #<unknown channel (freed) 7fdc35649560> #f)'."
<marusich>I think the error occurs because the glibc source code, which is for the fairly recent version 2.31, refers to these new symbols which are missing in the relatively old bootstrap gcc, which is version 5.5.0.
<lfam>Is anyone using a package that depends on ffmpeg on aarch64? I see that berlin fails to build a transitive dependency (libnotify) on aarch64
<lfam>I wonder if this can be reproduced on bare metal
<raghavgururajan>Applies on top of commit 041a9466ea23d6ae811491bcf529bf9487317b48 in master.
<jonsger>got them with wget --content-disposition out of mumi :)
<jonsger>never saw that (source (string-append (getenv "TEMP") "/source")) before, but if it works
<raghavgururajan>efraim: I just realized that we have been using 'pre-releases' and not 'stable-releases' for liferea. The current pre-release is 1.13.5, whereas, current stable-release is 1.12.9. Should I downgrade from 1.13.4 to 1.12.9?
<efraim>i'll see if I can whip up something that should work
<kozo[m]>I want to run wg-quick on a conf file from mullvad vpn
<jmarsden>I am seeing an error building /gnu/store/*-disk-image.drv (on arm-aarch64). Is this a bug in my OS definition scm file, or something amiss with U-Boot? How could I troubleshoot this further? /gnu/store/8xvmri7z0prsz61cg4v22nmkaddid6bk-genimage.cfg:14: no sub-section title/index for 'config'
<cbaines>on the subject of arm, I've been getting arm builds (armhf-linux and aarch64-linux) going again on guix.cbaines.net
<cbaines>once that is up and running, I can hopefully get arm stuff going properly on the guix-patches Guix Build Coordinator instance :)
<lfam>That would be really helpful. People said the lack of substitutes (at least for armhf) were a hindrance to their usage of Guix
<lfam>raghavgururajan: I'm going to push the first three commits to core-updates. After that, the old commits don't apply to core-updates, and it's not trivial to work around. Can you send updated patches for those?
<lfam>Specifically, I'm going to push what was 49d38b9a44d1045133e993f372394f9d3c626a72^..f6a00057f51e43bb136f326edf670a08d125919d
<lfam>If you pass that "refspec" to `git log`, you can see which they are
<lfam>And you can do `git checkout core-updates && git cherry-pick $commit` to see what I mean about them not applying
<raghavgururajan>lfam: Sure, let me know which commits doesn't apply. I'll send you updated ones.
<lfam>I'm not sure if anyone has a schedule in mind for core-updates yet
<lfam>I would suggest we wait at least a month to begin. The build farm is improving rapidly, and it would save more time to wait and take advantage of more improvements
<cbaines>more importantly, core-updates is pretty broken at the moment, neither Cuirass nor the Guix Data Service can process it successfully
<cbaines>it would be useful to fix that, before adding any other changes
<lfam>I don't know if it's "supposed" to be working right now. Traditionally it just collects random patches for a while, and then later on we fix it
<lfam>It might be nice to change that workflow! But it's also nice to take contributions when they are available, and since upstreams don't really coordinate (even within GNU), one major update can break the branch for months while other upstreams adjust
<cbaines>indeed, I'm still hopeful for lots of workflow improvements