<sneek>maximed, iskarian says: The implementation goes over my head, but the overall approach seems sound. I still think the (let (...) (package ...) idiom feels clunky and should be replaced with something else, though. Also, I think https://issues.guix.gnu.org/50274 might have the git-fetch updater effort in mind? :)
<maximed>If device=laptop here: my laptop updates to newer kernels without trouble
<maximed>and updating a kernel (typically?) doesn't require updating the firmware as well
<Noclip[m]>maximed: The article seems to mainly referr to arm boards like the raspberry pi.
<Noclip[m]>"and updating a kernel (typically?) doesn't require updating the firmware as well"
<Noclip[m]>-> I thought that too and that is why the article confused me a bit. I'm now trying to bring light in the dark and understand things better.
<maximed>I don't know much about the raspberry pi, Noclip
<Noclip[m]>maximed: It's a similar situation as with most other arm computers including smartphones.
<laanwj>*generally* kernel builds do not need any proprietary firmware as it is loaded from /lib/firmware when required, not embedded in the kernel, it is forbidden to do so for upstream kernels, some vendor-specific kernels (for boards that aren't supported by upstream) deviate from this
<Noclip[m]>laanwj: In the article it sounds as if only the raspberry pi foundation could port new kernel versions over to the raspberry pi because only they have access to the source code of the binary blob. Does this make sense?
<laanwj>Noclip[m]: yes-for how some vendor-specific (like in this case, rpi-specific) kernels are structured this makes sense, they contain board-specific drivers (sometimes even -ew- binary .o files directly linked in) that would never be accepted in Linus' kernel due to this, and work to support such boards in upstream will have to avoid binary blobs completely by clean-room reverse engineering, or if that
<laanwj>is not possible, use the kernel firmware loading mechanism
<laanwj>in any case this can be really annoying, often vendors don't upgrade their kernels anymore after a year or so, i personally tend to only use embedded boards that have upstream support like i.MX series
<Noclip[m]>laanwj: Ah thanks. As far as I know pine64 takes foss fairly serious.
<Noclip[m]>laanwj: Looks like I found the answer: "Currently the majority of Linux distributions for the PINE A64-LTS are using mainline Linux"
<bsturmfels>I'm making progress on my `guix deploy` setup! I'm a bit unclear about how the certbot service works. I've deployed a config with a (service certbot-service-type ...), but don't see a certbot service in `herd status`.
<mothacehe>bsturmfels: hey! certbot is triggered by mcron, you can run "herd schedule mcron" as root to find it.
<bsturmfels>mothacehe: thanks! yes, support got back to me with a solution. Turns out if you choose an image type other than "BYO ISO" when provisioning, it uses a more automatic resizing method which seems to choke on the multi-partition Guix image.
<bsturmfels>mothacehe: their resizing is actually pretty advanced compared to anything else I've seen eg. AWS/Linode. On say a Debian image, you can increase *or decrease* storage with a single button in the control panel, fully automated.
<bsturmfels>as in, it increases the storage quota, resizes the partition and the filesystem either up or down accordingly
<mothacehe>oh i see, we would need to work on providing bootable images with a single partition then.
<bsturmfels>for this special case it would help, but probably not a high priority for others
<mothacehe>yup, i'll keep that in mind. We could even file a bug report about it.
<bsturmfels>I did also discover that if I `guix deploy` with the root filesystem device still set as /dev/vda1 as in the base image config, it won't reboot, since the EFI partition is actually /dev/vda1 and root is really /dev/vda2
<mothacehe>yeah, made that mistake while trying to test a few resizing commands on my own blog yesterday
<bsturmfels>that might be the biggest win for a single partition - just easier to figure out
<bsturmfels>they also confirmed they don't support QCOW2, but I can live with that now I know how to resize
<bsturmfels>yay, your single partition base image boots fine, and resizes no problem on the non-automated "BYO ISO" operating system choice. On the "Debian" os choice the auto-resize increases the storage allocation and resizes the partition, but shows an error on the dashboard but all I have to do is "resize2fs /dev/vda1" and it's sorted
<bsturmfels>mothacehe: my resizing issues may have been lesser than I realised all along - I had assumed that the failed booting after `guix deploy` was related, but now know that it wasn't. Two small solveable issues, rather than one big problem. (thanks to your help) :)
<bsturmfels>mothacehe: actually, just double-checked the the previous multi-partition image on their auto-resizing "Debian" os config and it's properly broken and can't be worked around manually (without re-provisioning as BYO ISO). Your single partition image is a significant improvement in that respect.
<sneek>efraim, iskarian says: so what's your solution to building all source packages? I believe avoiding that that was part of the reason for putting inputs in cargo-inputs in the first place
<mothacehe>bsturmfels: ok, we slowly progress :) If you can find the sources of their resizing tool we can maybe understand why it doesn't work on our image.
<efraim>sneek: later tell iskarian building and testing them is good to make sure everything works. If it does turn out to be too much we could keep using #:skip-build? #t and it should still copy the sources into the output for the next package build and we keep our nice dependency chain
<zimoun>“guix environment –ad-hoc texlive-tiny texlive-beamer – pdflatex talk.tex” tells me than beamer.cls is not found. What do I miss?
<zimoun>civodul: about python2-, I think the plan is: keep them while it works. :-) Morever, python2-markdown is removed by the patch but “guix refresh -l python2-markdown” returns python2-cheetah which is not removed. Therefore, the patch will breaks unrelated packages
<bsturmfels>zimoun, civodul: would you suggest I close that bug and reopen with just the *actual* leaf packages, or forget it all and stick with "keep it while it works"?
<cage>Hi! This time i have no questions or problems to submit, instead i would just say thanks to all the channel for all the support the person here gave me in this last months each time i needed some help! :)
<bsturmfels>zimoun: is there any way to mark packages as pending removal? so that they show a warning when you install them?
<zimoun>bsturmfels: Nothing I am aware. Maybe deprecated-package could used. I do not know.
<civodul>zimoun, bsturmfels: oh i see; maybe bsturmfels can send a v2 that only removes the subset of these packages that are leaves?
<zacchae[m]>I tried building linux-libre for aarch64, and it crashed saying I ran out of disk space. I checked after and both my host machine and the drive I am trying to install to have > 15G of free space. Am I really running out of space (and the used space is just clearing after crashing) or should I make a bug report?
<nckx>My tmpfs is 15G and I've never had a build failure due to that, but maybe things are different there. Is anything building in parallel? Have you tried keeping an eye on ‘watch df -h’ during the build?
<zacchae[m]>IIRC, I had this problem trying to cross-compile this from an x86 computer (for aarch64), and I came across a similar error, but I assumed it had something to do with guix system image not estimating image size correctly, so I switched to what I'm doing now because it seemed more robust: guix system init from guix running on foreign distro running aarch64 linux kernel (archlinuxarm)
<nckx>That code could easily print *which* (/gnu or /tmp) is low on space but doesn't :-/
<nckx>Yeah, that's a totally different guessing mechanism. ☺
<nckx>No problem, but 4G being little is at least plausible.
*nckx happens to be building Linux too; will keep an eye on /tmp; now -> ☕
<nckx>It finished, and /tmp usage spiked to 1.5G for the last few seconds. But this is not the default Guix kernel configuration; it's not implausible that a distro kernel that includes modules for every thrift-shop MIDI keyboard ever made might push 4G.
<sneek>iskarian, efraim says: building and testing them is good to make sure everything works. If it does turn out to be too much we could keep using #:skip-build? #t and it should still copy the sources into the output for the next package build and we keep our nice dependency chain
<civodul>i'm glad these things don't take much time to build
<civodul>roptat: isDirectory behaves correctly with the patch above
<zacchae[m]>Is it normal for one guix system init run to build multiple linux-libre versions? (all have linux-libre-5.10.61-guix, but they have different hashes in front)
***LispyLights is now known as Aurora_v_kosmose
<civodul>zacchae[m]: that looks fishy; maybe it can happen when building something like zfs-on-linux though
<zacchae[m]>civodul: I'm using a pretty minimal system config on an ext4 filesystem. My understanding is that for a given architecture and code version, the hash should be uniquely determined, no? Here is what I'm seeing: