<rekado_>I'd like to but I can only use one hand right now... :)
<c0c0>I'm booting the Guix installation image in a VM as described in "Installing Guix in a Virtual Machine" in the Guix manual. It seems to get stuck (no visible progress) at "ssh-keygen: generating new host keys". Is that supposed to take really long, or is something going wrong?
<rekado_>when it gets stuck it can be due to a lack of entropy
<nixo_>In the following days, I'm going to push the first batch of julia packages (hundreds of them .-.). Before pushing, I've got a question
<nixo_>julia wants to precopile things, so a writable folder is required (usually ~/.julia/compiled/v$VERSION). This works fine, but when instantiating different guix environments the content of this folder contains artifact from the other environment.
<nixo_>The question is: is there something like a UUID in the GUIX profile that I can use as compiled folder path? like ~/.julia/compiled/$GUIX_PROFILE/
<kaun_>While I ponder my hardware fate, has anybody tried to have partitions on the free space in the installation media?
<nckx>kaun_: I don't blame you. AFAICT AMD has been waging a very successful disinf^Wprop^Wpromo campaign to paint their proprietary drivers as ‘open’. It's become a meme: AMD works with free drivers (nope).
<kaun_>I have 6+GB of free space, and it would be nice to use it to keep my Gentoo /home.
***benny_ is now known as benny
<kaun_>ISO image resizing, or can something be done to the installation drive itself?
<kaun_>nckx: Yeah, it is terrible that even GPU initialization and 2D needs a firmware blob.
<nckx>kaun_: You can't resize an ISO, but the installer uses a well-known hack to provide both an ISO file system and a GPT partition table. You should be able to edit the GPT table without breaking things, but I can't speak from experience.
<kaun_>leoprikler: Ha ha! I only want to keep part of it handy.
<nckx>kaun_: Dunno your Guix-fu, but VT switching with C-M-Fx will probably still work & you can then install Guix manual-ly. If that's your thing.
***benny is now known as Guest81021
***Guest81021 is now known as benny
<kaun_>nckx: I can muck around like that (that's how I realized I can't do an mkfs on the free space and copy the old /home in the installer session). It is concerning that that installer didn't even become visible.
<nckx>truby: I was out for a sec, but yeah, it's basically that for some chips at least these ‘optional’ features start at… modesetting 😛 And people don't realise this because vanilla Linux (now *that's* a fetish I'll never get) ships blobs by default.
<truby>does modesetting require binary blobs necessarily? or just for AMD cards
<leoprikler>I have an AMD card, that somehow worked without blob, but very badly
<leoprikler>and GDM failed to load appropriate drivers while slim worked
<nckx>truby: The 2 should not be related. It's a choice. (Sure, maybe forced by ‘third-party “IP”’ licencing, but still a choice.)
<nckx>I'm preaching to the choir here, but… computing going where it's going, that is a very bad thing.
<truby>I keep getting this issue: `error: failed to run download program '/home/truby/src/guix/scripts/guix': Permission denied` when trying to run a source checkout :-(. But I can run that script with ./pre-inst-env fine, so it's definitely there and executable
<truby>(I just followed the instructions in the manual)
<kaun_>The situation apparently is not so bad on ARM, because the NEON instructions make software drivers faster so you don't miss the hardware acceleration much.
<kaun_>Of course, the ARM booting situation is apparently bad, no standardization full-on balkanization.
<truby>hmm why would NEON make things faster when SSE wouldn't?
<truby>AArch64 actually specifies that you should be using UEFI.. it's just nobody listens :-(
<ixtlan>Hello all. I'm trying to install the full guix system on a pc but there's a problem.. somehow. Specifically, when "populating '/mnt'", it bails with an error and claims 'You have a memory leak (not released memory pool)'.
<nckx>truby: It's quite simple: just send an e-mail (with as much info as is reasonable; hopefully slightly more than ‘Permission denied’) to bug-guix at gnu.org.
<truby>well... I've changed nothing and now it works. Despite not working the many times I tried yesterday and so far today. Spooky :-)
<ixtlan>nckx: It is. First time around I did it twice, then went travelling, had media issues at first but then ended up with the same error as before. I tried downloading again from the site just in case, but it appears to be the same image as before.
<nckx>truby: The downloader will fail to run if your daemon is running everything as root (so without --build-users-group=) but a) it's unlikely you're doing that and b) I think it gives a better error message in that case.
<nckx>truby: Other, slightly better, random idea: are you running this on a ‘foreign’ distribution that has some kind of advanced access control like SELinux?
<truby>nckx: I'm on a foreign distro, I haven't turned on SELinux and I doubt Arch turns it on by default but I can check
<nckx>ixtlan: Huh. Interesting (which is not what you want to hear as a user, sorry 😛).
<nckx>truby: Does this happen with something trivial like ‘sleep 1h’ in an environment shell? Because I can't reproduce it.
<truby>nckx: I worked it out :-) my home directory was not world readable
<truby>so the guixbuild users couldn't get to that file
<nckx>truby: Ooh, you're running your daemon from /home? Of course.
<nckx>I run Guix from ~/guix all the time (drwx------ /home/nckx), but not the daemon.
<bdju>I think GPUs are just very specialized CPUs, but I am not confident in this thought. I would say amd and nvidia offerings are probably using something not that different for their stuff
<truby>yeah, that's where I did my source checkout. Might be worth adding in the guide that the source checkout needs to be somewhere that the guixbuild users can get to? It seems obvious to me now that I think about it
<truby>bdju: the architectures are quite different, Intel tried to make an x86 GPU and it failed horribly :-). But, RISC-V might be more flexible enough than x86 that it could work
<bdju>well, I wouldn't expect x86 bits, maybe arm or mips or something. the sort of stuff you see in embedded devices like routers and TVs
<truby>I suspect that my other bug (the one where ctrl-c kills everything) is probably related to the fact that I'm using fish
<kmicu>(I cannot help too cuz I have no idea what to really recommend.)
<leoprikler>ixtlan: depends on the kind of bug you're reporting
<nckx>leoprikler: Yes, I know. But I read & answered the question ‘is it quiet?’, not ‘is it booted with the “quiet” command-line parameter?’. The latter is true.
<leoprikler>nckx: well, fair enough, my wording was somewhat ambiguous :)
<c0c0>probably more of a qemu question than a guix question, but let me ask it anyway. when i try to install guix in a qemu vm, i create an image with "qemu-img create -f qcow2 guixsd.img 50G" as described in the guide. but then the graphical installer doesn't see a disk. when i go for the manual install and run lsblk, i see this: https://paste.debian.net/1106392/ sda is the installation medium, and the
<c0c0>rest doesn't look like something were i can install the guix system. any hints on what i'm doing wrong?
<ixtlan>leoprikler, it's something that happens during install. I think screen output would be helpful, but I see no log similar to screen output.
<leoprikler>ixtlan: Where exactly during install? In the final stage when building everything?
<ixtlan>It is after building and applying grafts, during 'Populating /opt':
<ixtlan>When "populating '/mnt'", it bails with an error and claims 'You have a memory leak (not released memory pool)'.
<ixtlan>Eh. Not /opt, /mnt. Good that copy-paste's memory works.
***wingo_ is now known as wingo
<leoprikler>ixtlan: I'm not sure where this message would end up in
<leoprikler>do you get a message afterwards saying "derivation bla failed, check X log"?
<ixtlan>"Guix system error: Failed to install bootloader."
<leoprikler>I too have more luck with manual than graphical, but there's two reasons for that
<ixtlan>The resulting system does seem to work though. It complains over sector size and other things, and passphrase for the encrypted harddisk is asked twice for some reason, and the system is -very- bare-bones since i3 complains it can't find a terminal to use, but.. it seems to work. Just needs some filling in.
<leoprikler>1: I inevitably f up in the middle and the graphical system is not nice when restarting
<ixtlan>But also I'd just bought these wifi dongles and didn't want to spend more money and time before getting the system working.
<leoprikler>It's bad enough, that I have to run my local Guix, because Seahorse broke
<ixtlan>I might have to get something more compatible this time around though.. I guess guix is not all that proprietary-friendly. Which I do kind of like. As long as I have my current system already running. Mostly I like guix for providing transparency and repeatability.