<mange>Looks like a "volatile" system is one where a RAM-backed overlayfs is added to the root partition mount, to let you play around without changing the actual image. I'm basing that off the comments in the manual in "(guix) image Reference".
<Kolev>mange, so "volatile" is a normal ISO where your changes aren't saved across boots?
<dthompson>lechner: your diff for the guix on linode cookbook page look good to me. I had to make that same swap-space update.
<dthompson>it's just a bummer that there's seemingly no way to avoid starting with some other OS. I'd really like to be able to generate the initial image on my own computer and start with Guix right away.
<gabber>i think i stumbled over some swap-space operating-system field issue as well - might be worth investigating a bit further (i think it was in the raspberry-pi example)
<civodul>dthompson: where does Linode take its initial image? would the Guix System image need to be in a specific registry?
<efraim>civodul: I've narrowed down the heap OOM to the library-path definition in 'make-dynamic-linker-cache
<civodul>efraim: yes, that’s the thing that loads ELF file one by one in memory
<dthompson>this isn't great but a step in the right direction! 'Kernel panic - not syncing: No working init found'
<dthompson>used to be a panic for not finding the root fs
<dthompson>even closer now... had to change linode config to boot with grub 2.
<dthompson>now it's complaining that /boot/grub/fonts/unicode.pf2 isn't found... indeed it isn't in the image.
<dthompson>the existing guix on linode instructions say to override the installer field of the bootloader to not actually install grub on disk, but I think I need it to get the files that its complaining about.
<podiki>unfortunately qa page not populated since I just merged in master; but was around 95% x86_64, 88% i686, and then next best was maybe aarch or arm at ~50% on bordeaux?
<gabber>how can i satisfy a dependency on libusb-0.1.so.4, libstdc++.so.6, libgcc_s.so.1 or ld-linux-x86-64.so.2? i've tried adding glibc, libusb-compat, gcc, libusb-0.1 to the inputs but that does not satisfy any of them...
<podiki>gabber: satisfy for what? in a package build?
<janneke>Let's finish and release wip[-gash-utils] as mes-0.26 though and see about improvements later?
<janneke>i've got some experiments resurrecting building mes on the hurd and initial modularizing and updating to latest nyacc slated for 0.27 in progress, looking pretty good as well, but for 0.27 too afaic
<podiki>apteryx: hi! any thoughts on when I should merge in mesa-updates? substitute coverage looks good on x86_64 and i686, our other architectures lagging though (next highest was around 55% I forget which since QA page hasn't caught up)
<podiki>some leaf packages will need to be fixed though I tried to get to what I saw
<podiki>I'm aware php fails some tests, I can mention that in an email to guix-devel updating on the branch status
<Andronikos>nckx: You mean with ddrescue not doing it, that it is not the software itself but the hardware. Does that mean the HDD itself or which hardware and what exactly does the kernel do? I always used "dd" and in this case as well. Though I ask just to be sure it is still the best way to do it.
<Andronikos>futurile: Clonezilla was my first thought as well but it is cumbersome booting a whole distribution. Also I needed a clone as a file that is on a physical drive (e.g. backup.img), since I needed some files to copy over to the original HDD. I don't know if Clonezilla can do that. I only used it for mirroring whole drives which worked flawlessly.
<Andronikos>I guess it is not possible to calculate with gzip what the new compressed file size would be? I don't have much storage left and don't know if I have enough free space to store the backup as well as the compressed backup at the same time.
<gabber>Andronikos: i doubt that's a linear calculation... most modern compression algos do kinda smart stuff at times - and depending on the content of your files compressed size can vary much
<vivien>lilyp, apteryx, did you get a notification for #67162–67170?
<vivien>Then I have to reorder the commits to send them, not forget the prefix (PATCH gnome-team), check which revision I have to use, add the gnome-team CC (but magit remembers it so I don’t have to type them), check the issue number, make a cover letter, and send the patches
<ulfvonbelow>trying to update numpy locally and it seems that having both gfortran and the implicit gcc input is causing issues with include files, specifically fenv.h
<ulfvonbelow>the include_next sees the gfortran header, which is an exact copy of the gcc header, which makes it think it's already been included, so it stops. Consequently, the glibc fenv.h never gets included.