IRC channel logs
2023-06-07.log
back to list of logs
<bdju>Why don't I get the confirmation email when I report bugs anymore? Or see my own email with the reported bug? I would think the email wasn't getting through if not for the fact that I can see it from the web UI. <sneek>anemofilia, you have 1 message! <sneek>anemofilia, rekado says: we need more context, but from what I can tell you’re placing your *shepherd service* where a service type value would be needed <anemofilia>Some alsa tools doesn't work anymore in my setup <anemofilia>I have alsa-plugins, alsa-utils and alsa-lib installed <anemofilia>(I actually can't remember exacly when it stoped working too) <HexMachina>Did Guix recently change how commits are signed or authenticated? Running a `guix pull` fort the first time in around 2 months fails for me within git-authenticate.scm calling verify-openpgp-signature with the error "gcypt: Not supported" <HexMachina>I ended up tracking down the error to disallowed signature types caused by my foreign system running under FIPS 140 mode. Doing a temporary `echo 0 > /proc/sys/crypto/fips_enabled` resolves the issue and my `guix pull` works <HexMachina>Which I imagine could occur at various HPC/research institutions <HexMachina>Oh dear, the build daemon also fails within the valid-narinfo? method when trying to download substitutes. My org's rollout of FIPS might prevent me from using Guix :\ <apteryx>HexMachina: could this be resolved by building libgcrypt with FIPS support? <HexMachina>The problem is that it DOES support FIPS. When libgrcypt is loading (on first dlopen I think), it checks the value of `/proc/sys/crypto/fips_enabled`, and if set to 1, a bunch of algorithms are disabled <HexMachina>This indicates that Guix's mechanism of signing/authenticating is relying on old/deprecated possibly insecure algorithms, which FIPS says you can't use <HexMachina>If I `echo 0 > /proc/sys/crypto/fips_enabled` and then restart the guix build daemon, everything works, but this isn't going to fly with my IT department as a long-term solution <HexMachina>Well that's not exactly right. It might be using a newer algorithm that's actually better but hasn't been FIPS-approved yet? I haven't identified with alogirithm is the culprit. FIPS also mandates things like minimum key size <HexMachina>on my system, running with FIPS mode disables the following cipher algorithms: IDEA, CASTS, BLOWFISH, TWOFISH, CAMELLIA128, CAMELLIA192, and CAMELLIA256 - it only allows 3DES, AES, AES192, AES256. For hash algorithms, it disables RIPEMD160, and only allows SHA1, SHA256, SHA384, SHA512, and SHA224 <HexMachina>Not sure if Guix is using one of those disabled algorithms, or if it's a key size issue, or what exactly <HexMachina>It's quite possible Guix is using a newer/better algorithm that hasn't yet been FIPS approved <HexMachina>The algorithms can be seen running `gpg --version` with /proc/sys/crypto/fips_enabled set to 0 and 1, respectively <chomwitt>is there a way to add 'nofail' as a mount option in config.scm ? <chomwitt>but putting it in flags list i get from guix system reconfigure an error of unrecognized option <chomwitt>that makes sense if we accept that flags can include only the symbols mentioned it the doc link i gave <jpoiret>chomwitt: I believe nofail doesn't make sense on guix <chomwitt>jpoiret, if my external ssd is not connected booting stops <jpoiret>the fstab isn't used to determine what to start on boot, the mount? field should be set to #f instead <jpoiret>nofail isn't a possible flag to the mount system call but rather an indication to whatever uses fstab to mount devices on boot to not stop on fail <jpoiret>the (file-systems ...) field of an operating-system populates both an fstab file and shepherd services to mount them on boot, but the latter doesn't use the former <chomwitt>so as an alterantive i use the mount? field and mount whatever i want by a bash script after i login ? <mirai>jpoiret: I don't think so, unless it got changed recently <jpoiret>it's set for things that are needed before the /boot script can execute <jpoiret>git blame tells me it hasn't changed since 2014 <mirai>configuring a nfs volume used to hang the system since it would try to mount it before 'networking was available <jpoiret>guix infers needed-for-boot? for obvious dependencies of the root filesystem <jpoiret>sometimes it can't infer them properly <mirai>perhaps the hang was due to either check? or mount? <jpoiret>yes, mount? adds a service, and if it doesn't have the proper dependencies it might fail <chomwitt>jpoiret, ok . thanks for one more time jpoiret. i will try mount? <jpoiret>chomwitt: i recommend using a guile script instead :) <chomwitt>jpoiret, sure why not. i have started learning guile also <jpoiret>mirai: basically, needed-for-boot? devices are mounted during early userspace, not by shepherd, whereas regular devices are mounted by shepherd. That's the main (and only?) difference <iska>is there a way to export a manifest of a certain profile generation? <efraim>I'm testing buidling fibers 1.3.1 on riscv64 (using package transformations) so I'll let you know how it does <civodul>we should get riscv64 boards in the build farm <davidl_>iska: I think you can try guix package --profile=/var/guix-profiles/per-user/<myuser>/guix-profile-NN-link --export-manifest <civodul>cbaines: you may be interested in the Fibers patch series ↑ <janneke>jpoiret: heads-up, we still seem to have a problem on wip-hurd with libc-for-target and it's something i could not find yet <janneke>when doing an offload build: "./pre-inst-env guix build --system=i586-gnu hello", there is a dependency on glibc-2.35 which does not occur when building natively in a childhurd <janneke>iow, the .drvs for hello differ for offload builds and native builds, on wip-hurd, wrt libc-for-target <civodul>janneke: hey! it sounds unlikely that offloading has an impact on the .drv you end up building, i think <civodul>because the package -> drv step is done client-side <civodul>then guix-daemon receives the .drv and it can choose to offload it, but that's all it can do <cbaines>civodul, we have riscv64 boards in the build farm (although one looks to be offline) <cbaines>so technically it's just one board at the moment <janneke>civodul: yeah, the drvs are different when building from the same wip-hurd branch <janneke>so it seems there's some different between using --system=i586-gnu, and being *on* i586-gnu <cbaines>civodul, as for the fibers patch series, I'm mostly interested in seeing if it builds reliably across various systems <cbaines>previous fibers versions have been very difficult to build on some systems <cbaines>the "good" substitute availability on master looks to be already over though :( <civodul>cbaines: yeah, the fibers test suite takes ages and sometimes seemingly fails to complete <civodul>part of it looks like a benchmark rather than a test suite <civodul>janneke: oh, could be the libc-for-target checks %current-system in the wrong context <civodul>like if you call libc-for-target at the top level, it may get the "wrong" value <civodul>it should only be called from a thunked input field or similar <Guest28>If I run guix pull, how can I check if I upgrade my system that substitutes are already build for the upgrade? I am only aware of guix weather <package> <janneke>(apparently, shared libcrypto.so is silently not being built on the Hurd) <efraim>civodul: with the package transformation it was ~27 minutes including offload time <jpoiret>janneke: you need define/system-dependent wherever you want to use libc-for-target in commencement <janneke>jpoiret: yeah, i think we're doing that now... <janneke>oh wait, there is glibc-utf8-locales-final <efraim>theres a couple of suprise final packages that get automatically generated as dependencies <bjc>what's the right way to add a news entry for ‘guix pull’? <f1refly>I'm not sure if I understand the QT_PLUGIN_PATH correctly. On my system, it is set to '/run/current-system/profile/lib/qt6/plugins'. But, alas, kvantum is using qt5 and it doesn't appear to be happy with the qt6 plugin path. When I start a shell with qtwayland@5 and kvantum, it starts alright. In #57742, it is implied that the plugin path should include both qt5 and qt6, or do I read that wrong? <f1refly>ACTION still has no idea if he is just holding the distro wrong <jpoiret>efraim janneke: wdym by automatically generated? <jpoiret>f1refly: yes, but you probably need to also install qtbase@5 to your profile for the search path to work <efraim>finalize package creates package variants as it needs <f1refly>but I can't install both qtbase@5 and qtbase, right? because there are applications that need @5 and some that need @6 <jpoiret>f1refly: they shouldn't step on each other's toes i think, let me try <jpoiret>why is `guix shell qtbase@5 qtbase@6` downloading qtbase-5:debug <f1refly>I have no idea, but it does that for me as well <janneke>./pre-inst-env guix build -e "(map cadr (@@ (gnu packages commencement) %final-inputs))" <janneke>but it would be more convenient to simply have a whole list of identifiers for those <civodul>and yes, we'll need to remove input labels from commencement.scm <jpoiret>dthompson: it only downloads what should be needed, but as ludo said the grafts prevent this from working properly <jpoiret>basically because the grafting process operates over all of the outputs, ie. there's only one grafting procedure per package, not one per output <jpoiret>haven't looked at the grafting code in a long time <dthompson>I guess I'm not up-to-date. with 'guix environment' it used to just download all outputs. <jpoiret>they both do the same thing internally, only the CLI specifics have changed iiuc. The behavior with grafts has always been there though, so it might be what you've been experiencing <civodul>jpoiret: yes, that's the idea; the grafting code tries to graft just the output you need, but often that's not possible <bjc>is there an easy way to stop a package build after a given phase? i'm trying to verify a ‘substitute*’ rule is applied <jpoiret>bjc: just add a phase that errors out <pkill9_>bjc: i think if you add a phase that just returns #f it will fail <jpoiret>I usually add (oops) in a phase, hoping that oops is unbound :) <bjc>i tried that, but maybe i did it wrong; i'll try again <pkill9_>so something like (add-after 'phase 'new-phase #f), can't remember the exact syntax <bjc>indeed, i forgot to add a name to the new phase. whoops <janneke>ACTION uses something like (lambda _ crash) or barf <janneke>ACTION also sees an opportunity for a feature --stop-after-stage=<sage> <bjc>a flag for ‘guix build’ would be nice <civodul>this could be implemented as a package transformation <civodul>sounds like a good excercise for the reader :-) <bjc>i have suddenly forgotten how to read <distopico>Good day Guixers, I'm new in Guix and I have a question regarding if is possible in Guix define in the configuration a different linux-libre version, I upgrade yesterday and after update from Linux 5 to 6.3 Gnome and 3D with and Nvidia card <distopico>With an Nvidia card with the last upgrade is working unstable and it freeze sometimes <distopico>So, how can I declare in the configuration a different linux-libre version? <janneke>distopico: use something like (kernel linux-libre-6.1), and (use-modules (gnu packages linux)) <distopico>Yeah, it works, there is an issue in kernel 6.3 with my Nvidia 710 card, is work pretty slow, like 6 frames(mostly Wayland), with 6.1 works fine <bumble[m]>hey everyone, guix pull and guix system reconfigure this morning result in this error, without having made any changes to config file used: "service 'term-tty2' provided more than once" <bumble[m]>if anyone would have advice or suggestions I am happy to read those :) <bumble[m]>I tried commenting-out the console-font-service-type definition and the delete call but no change <jpoiret>bumble[m]: there was a change yesterday that each clause will only be used once, hence the (delete agetty-service-type) will only work for tty1. You can pass it multiple times to delete all of them <jpoiret>in the end I'm not sure it was such a good idea <Cairn>Those embedded images defined at the bottom of install.scm... Can those be built from the command line, or do I need to run a guile function directly? <jpoiret>uh, my bad, it's mingetty that you have to delete multiple times <Cairn>Ok, I'm having trouble with the command at "3.10 Building the Installation Image for ARM Boards" <Cairn>guix system: error: while setting up the build environment: :cannot set armhf-linux personality: Invalid argument" <bumble[m]>@jpoiret politely, documentation here only demonstrates a single (delete mingetty-service-type) call so perhaps the example should be updated with multiple delete calls <civodul>jpoiret: re delete only once, i'm not sure it was a good idea either actually <civodul>it was an easy way to tell whether a clause had been used or not, but we could do it differently <bjc>the patch i sent a week or so ago should do the check now, if all you're interested in is whether or not it matched <bjc>i found deleting everything to be irritating, but only deleting one at a time is, too, honestly <ngz>Is there, in a build system, a way to tell the transitive inputs of the package being built (i.e., those bound to stay in the store) from the native one (which could be GC'ed)? I tried `package-transitive-inputs' to no avail. I don't think (guix packages) is accessible from (guix build ...) modules. <sneek>ngz, civodul says: how far are we from merging 'tex-team'? <jpoiret>ngz: there's no correlation between what you're describing, what are you trying to do? <ngz>civodul: AFAIC, "tex-team" can be merged anytime. I'm only working on "tex-team-next" these days. This branch requires at least an additional week of work (and possibly some feedback) depending on if I try to push it to updating to TeX Live 2023 or not. But it's looking good. <patched[m]>How to locate manpages for gcc? guix shell gcc-toolchain -- man gcc says there is no manual entry for gcc... <jpoiret>unfortunately you can't distinguish native inputs from inputs on the build side if you're building natively <jpoiret>patched[m]: in a shell you need to add man-db for the manpage database to be generated for the profile <jpoiret>so `guix shell man-db gcc-toolchain` <ngz>jpoiret: OK. That's what I thought. I'm trying to find a binary among inputs, but assuming I found it, I want it to be always available at run time. <jpoiret>ngz: then you should patch the package's source to refer to it via its full path <jpoiret>then guix will see the reference and keep the input in the closure <ngz>jpoiret: More precisely, I'm creating a symlink from package's bin directory pointing to it. <jpoiret>the symlink should count as a reference for the guix daemon <ngz>Ah. That's good to know. <ngz>jpoiret: So the symlink pretty much guarantees I will not be dangling after a GC. <ngz>(I don't know if I'm dangling myself…) <ngz>It will happen at some point, like the rest of us :) <ngz>jpoiret: Anyway, problem solved! Thanks for confirming it! <bjc>civodul: just catching up on email; sorry about #63921! i assumed order didn't matter, and even wrote my tests to ignore it <bjc>is the issue that the dependency graph is produced before ‘modify-services’ is called? <bjc>or is it that order isn't strictly defined within a service-type? like you can't say that activation services for foo depend on bar already being activated? <mirai>iirc only shepherd services have the notion of conflicting <mirai>the service-type “name” is merely informative <Wurt>Hi, I am a newbie that wants to send multiple patches to guix-patched@gnu.org using Emacs. Is there any specific tutorial for Emacs and Magit? Is there any guide to write the contents of the cover letter? <civodul>bjc: np, i overlooked that too! order matters for some services, like the "boot" service in this case <civodul>mirai: in 0.10, there's no notion of "conflict"; a given name maps to exactly one service (or none) <jpoiret>Wurt: make sure to only send the cover letter first, wait for the debbugs reply and then send the rest to the bug's address <jpoiret>otherwise you'll open one bug per patch <jpoiret>the manual has a secton on it. You should use `git send-email` for this, not send the emails manually <Wurt>Thanks, jpoiret. I read it, but I want to know if there is a specific Emacs package or configuration for this task. Also I wanted to know if there is a redaction style guide. <jpoiret>I only know of one emacs package to send patchsets via mails, but it won't interact well with debbugs, so it's a no-go for guix unfortunately <jpoiret>as for the redaction style, you mean for the cover letter or the commits themselves? <jpoiret>for the cover letter, I don't think there is, just write a clear summary of the patchset and it'll be good :) <f1refly>so, it turns out that my environment was fubar because I mixed up some files with my arch installation by accident, maybe it was all my fault after all <naamon[m]>is internet access required during installation of gnuguix, i686 gnuguix iso? Thank you. <naamon[m]>do you know why gnuguix has chosen not to make an iso available which requires no internet access? <pkill9_>i dont think they actively chose not to, just that nobody bothered to set it up that way, probably because guix is mostly used where there is internet access i would guess <pkill9_>especially as people have different configs to instantiate the system with <naamon[m]>I wanted to know if it was about limited resources? Maby a full system iso adds more work to gnuguix? <apteryx>it'd use a lot of disk space for each image generation, yes <Wurt>Are there two email addresses to send patches? On the documentation links to guix-patches@gnu.org and guix-patches@debbugs.gnu.org, but the later could not be reached. <vagrantc>Wurt: i'd recommend the one that works. :) <Wurt>vagrantc: Ha ha ha. Okey. <Wurt>How much time debbugs take to reply? <jpoiret>if it's your first interaction with the mailing list, it'll have to be manually vetted first <Wurt>jpoiret: Makes sense, I think that I made a mistake sending the cover letter. <elevenkb>Hey y'all's I wanted to roll my own guix build --no-offload in the repl, but I get stuck <jlicht>jpoiret: thanks a bunch for getting proot fixed! <elevenkb>Presently, when I have an offload server (compile (@ (gnu packages irc) irssi)) fails with an error: <elevenkb>In procedure display: Wrong type argument in position 2: #<closed: string 7effad9e43f0 <elevenkb>I'll try disabling my offload servers first to see if that's the issue. <janneke>hmm, so with --system=i586-gnu, gcc-final depends nicely on glibc-2.37, but gcc-toolchain depends on 2.35 <janneke>ACTION has tried using define/system-dependent for gcc-toolchain to no avail <f1refly>disregarding the qt problem for a while - i updated my system and now my system.scm won't build anymore. I tried following the devel documentation for how to set up a greetd-service-type, but it complains that "service 'term-tty2' provided more than once" <f1refly>I deleted login-service-type and mingetty-service-type from %desktop-services <johnabs[m]>Hey guys, I'm trying to rebuild xmonad after an update and the whole thing is wack and my computer is only 20% functional right now. Here's a paste of the error I get when trying to run xmonad --recompile, can some haskell/guix wizard take a look if you don't mind? https://pastebin.mozilla.org/dty7mHQP (Sorry, I'm mostly a Lisp/Julia guy so I'm still learning this stuff 😅) <johnabs[m]> I can also post my config if needed, I only changed 1 line because it's now included in xmonad by default (just removing the import Data.Default line) <ieure>johnabs[m], I'm not a Guix expert (or even regular user), but the error message indicates that the build depends on librt, which either isn't installed, or isn't on LD_LIBRARY_PATH. <ieure>I thiiiiink LD_LIBRARY_PATH is where it'd be looking for it. <ieure>I know it's used by the dynamic linker, but I'm not 100% sure about ld. <jpoiret>johnabs[m]: do you use ghc installed via `guix package`? <johnabs[m]>Okay, I'm looking on guix search, it seems there are two possible options: librttopo or librtprocess, it doesn't seem like it's either of those, or maybe it is? <jpoiret>f1refly: you need 6 (delete mingetty-service-type) because of a change made yesterday <jpoiret>might revert it though, mostly because of this <jpoiret>basically, each clause only applies once but there are multiple mingetty services <johnabs[m]>jpoiret: I have both ghc, and ghc-xmonad-contrib <jpoiret>johnabs[m]: then, can you do `guix package install -e '(list (@ (gnu packages commencement) gcc-final) "static")'`? <jpoiret>we need to add the empty librt.a to gcc-toolchain asap <johnabs[m]>jpoiret: It says "install is an extraneous argument" should I remove it? <jpoiret>ah, `guix package -i -e ...` instead, sorry <johnabs[m]>jpoiret: Ah, okay, new error: (list (: package not found for version (gnu packages commencement) gcc-final) "static") <johnabs[m]>Yup! I pasted this exactly: guix package -i -e '(list (@ (gnu packages commencement) gcc-final) "static")' <jpoiret>johnabs[m]: forget it, it doesn't work as i expected <mirai>sneek, later ask civodul: how does that work? What happens if I add two distinct services (like networkmanager and iwd) that both provide 'networking? <johnabs[m]>jpoiret: Oh, crud, do I need to install the commencement and/or gcc-final packages (assuming I'm reading that symex correctly)? <jpoiret>so, instead, you can do `guix shell -e '(list (@@ (gnu packages commencement) gcc-final) "lib")'`, whic will drop you in a shell with librt available <jpoiret>i was speaking from memory but i did test this one out <jpoiret>ah, that doesn't work either. Let me try to find out what does <johnabs[m]>It created the env, but I'm still getting the same error, and oh okay, you see it too <elevenkb>I managed to resolve my troubles with evaluating a derivation w/o offloading programattically. <jpoiret>johnabs[m]: how about `guix shell -e '(list (@@ (gnu packages commencement) glibc-final) "static")' gcc-toolchain@11 ghc` <ieure>Is there some place which explains a Guix thing I've never understood: why are channels defined per-user, but used by the system configuration? Why isn't there a notion of system channels? <ieure>For example, if I create a channel for personal software, and have (use-modules (personal thing other-thing)) in /etc/config.scm, it only works if the `personal` channel is configured for whatever user runs `guix system reconfigure`. That seems wrong to me. <ieure>It feels very weird to me that the an identical system configuration would work or fail depending on the configuration of the user invoking it. <elevenkb>Nope, just an illusion it seems. I can evaluate packages that are already built, but I can't evaluate new ones. <jpoiret>johnabs[m]: i wouldn't recommend this one, you'd need to keep that librt.so in the same place <jpoiret>whereas here you'll be linking statically against librt.a <jpoiret>librt is now empty since all of the functionality is in libc proper <johnabs[m]>jpoiret: Ah gotcha, I figured, but I thought I could try to help, lol <saravia>hi, how I can change login screen of guix xfce4 version <saravia>^ excuse me, try for hours without achieve it <saravia>(message "five years emacs user hello world") <saravia>mirai: If I want search help for change my login image of guix, how I could do? <saravia>so... the git repository of guix, where is it? <ytc>When I use a standalone window manager like i3 or sway, icons of some applications are missing. But when I use a desktop environment like Xfce or GNOME everything is fine. <ytc>How can I solve this? Why do you think that icons are missing even when essential icon theme packages are installed? Is there anybody with the same issue? <Cairn>ytc: Where are the icons missing? In your application launcher? <ytc>For instance, some of PCmanFM's icons are missing. <ytc>'About' section of GTK applications doesn't show its icon <ytc>like Dino for example <Cairn>Have you configured a GTK theme? <Cairn>Or are you using the qt version? <ytc>I configured it with ~/.config/gtk-3.0/settings.ini and dconf <ytc>I still don't know their difference <ytc>I am not using any qt application currently <Cairn>Oh I guess the default is GTK. Yeah, just make sure you've got a theme specified. <ytc>on X window managers <ytc>gtk theme is properly set, but application icons are missing <ytc>application launchers also show missing icons <ytc>on GDM, an icon is also missing at the top-right corner <jpoiret>cbaines: hey chris, let's say I'd want to merge https://issues.guix.gnu.org/60824, but it has god knows how many dependents. Would you say the preferred procedure would be to create a topical branch for it, and instantly add a request for merge so that it gets in the queue? <jpoiret>how should we handle keeping it up-to-date? merging periodically? <jpoiret>grub seems to be looking for the i386 files for some reason <Cairn>Yeah, I was confused about the i386 mention. What do you mean by my cli? My shell? <jpoiret>no, what's the command you ran (sorry that wasn't really clear) <Cairn>guix system image --system=aarch64-linux --image-type=qcow2 ~/guix/gnu/system/install.scm <Cairn>Freshly cloned git repo at the end there. And like I said, it succeeds with uncompressed-iso9660 <jpoiret>do you explicitely want to use qemu-binfmt, or would you be fine with cross-building <jpoiret>otherwise, can you tell me what `guix build --system=aarch64-linux grub` is? <jpoiret>it should be the same as the grub used in the above <jpoiret>huh, and what does the /lib/grub directory have? aarch64 files? <Cairn>Honestly, I don't mind what I use; this is just a smaller symptom of a larger issue I'm having, but I thought this would more diagnosable. <jpoiret>i meant as a subdirectory of the /gnu/store/...-grub/ <Cairn>My larger issue is trying to get Guix running on VMware Fusion at work, but that's a non-free issue that I assume is better for other channels <Cairn>Oh right, my bad. Was still thinking about what I was typing when I checked <jpoiret>it's possible that grub-mkimage is somehow able to detect it's running on an 86 host somehow <Cairn>It's got an arm64-efi directory. So yeah. <Cairn>grub-mkimage is running on aarch64, albeit in a VM <jpoiret>Cairn: I think I know what's going on <jpoiret>it's a bug on our side, %current-system isn't set correctly while generating the grub config files <Cairn>Have time to commit a fix today? I'd love to try to build this. <elevenkb>Ok my issue from last time is resolved, I had to use guix repl for some reason instead of just geiser. <jpoiret>Cairn: ah no, it's actually different. We hardcode grub to only install for i386 for some reason <jpoiret>probably because everyone uses uboot on aarch64? <Cairn>Should I build for uboot then? <jpoiret>I really don't know how uboot works, but you'll probably have more luck if you want to use aarch64 <jackhill>interesting about grub. I should try it with uboot's EFI environment one of these days. <Cairn>Is this pretty much what I should be doing? Cause I couldn't get this command to succeed either. Trying again though. <Cairn>Can't remember, sorry. Waiting on this build, but I'll see if it works. <jpoiret>in any case, we probably should support using GRUB if it makes sense to use it. I don't know anything about arm boot though <Cairn>Haha, it just says "Failed to install U-Boot" with an incomprehensible backtrace <Cairn>I'll stick with libvirt, since the iso that did succeed already works. <Cairn>I'll just have to ssh into my vm <podiki[m]>what happened with the sbcl riscv64-linux fix? it was committed, reverted, and re-committed? <jpoiret>Cairn: you can have a GUI with libvirt <jpoiret>although i've only ever used raw qemu, but it's possible <Cairn>jpoiret: But every VNC I've tried can't bypass this mac's "retina display" dpi scaling <jpoiret>you don't need VNC, no? Can just emulate a graphical output as a QEMU device and show that <Cairn>It's just a small pile of minor annoyances <jpoiret>oh! then you don't need to specify `--system=` <jpoiret>i thought you were trying to build an aarch64 image on x86 because of that <Cairn>Oh? Does that change anything? <Cairn>I thought I was just being extra cautious, haha <jpoiret>but yeah high dpi and qemu's graphical devices won't mesh well i bet <jpoiret>won't the provided install images cut it? <jpoiret>you can use basically any linux iso to install guix in a vm, by just running the guix install script first, and using that guix to install the system <jpoiret>i don't exactly know what you're trying to achieve there, but i don't know any aarch64 specific stuff, sorry. Someone else might be able to help you <Cairn>I don't think aarch64 is provided <Cairn>You're talking about running a guix system init on a foreign distro? I was thinking about that actually, but I couldn't understand the documentation at a glance <Cairn>It can entirely replace the foreign distro? <jpoiret>you can start an installation iso of any distro, install guix temporarily on the installation medium, and use that to installl the system <jpoiret>i personally installed my current system by running `guix system init` on archlinux :) <jpoiret>which was my daily driver at the time <jpoiret>using an install iso to do it is simpler though, you don't have to worry about installing another distro first but keeping space for guix, then installing guix through that and then deleting the other partition <jpoiret>i'd suggest using something minimal like an arch iso, running the guix-install.sh script on it, guix pull'ing, making sure you're using the latest guix and finally following the system installation guide <Cairn>Oh wow, that's an interesting idea... <Cairn>However, I'm gonna try it tomorrow. Anyway, thanks for the idea! <johnabs[m]>jpoiret: Hey there, I hope I'm not bugging you, but did you happen to find a way to set up that environment with librt per chance? :) <ytc>Could someone please explain what is the purpose of declaring packages in the Home config while it is "guix package"'s job to install packages in the user's profile? <rekado>ytc: I use Guix home to build several profiles: my default profile and a separate one just for Emacs <rekado>since I already use guix home for managing my environment (e.g. services and config files) it makes sense to me to also manage the agents of that environment at the same time, declaratively