<axd-v>Is there a gui client packaged for qemu? Does the qemu package also come with all of the stuff from kvm to make a vm for debian for example? I've never really used kvm because virtualbox was easily available and was familiar, but I gotta get used to better libre tools now.
<civodul>axd-v: i've never used it but perhaps virt-manager is such a GUI
<pkill9>rekado: what i mean is, how do i put 32 bit inputs and 64 bit inputs in the same profile/evnironment, orin a package definition? something i'm looking at seems to want 32 bit libraries as well as 64 bit libraries
<atw>civodul: that sounds good to me. I've gotten used to the layout of the manual, but initially it was a little confusing. I think the manual could have 3 concerns: GuixSD-only, foreign distro-only, and common concerns
<ng0>civodul: would you happen to know some deeper undocumented guix-specific guile debugging methods? I have to use GUIX_PACKAGE_PATH as a trampoline at the moment, and this one module folder is acting weird, with no weird code in it. used to work even. and (guix discovery) is confused even when the module folder is empty
<roptat>chapter 6 is for guixsd, chapter 2 is for foreign distros. others are common concerns
<lyr3>Even though Ive installed Gentoo sucessfuly I feel like I am installing a distro for the first time with a non-gui installer. GuixSD give me hope that there is trustable distros!
<axd-v>Does anyone use virt-manager? I have installed that and qemu, but still get `QEMU/KVM not connected` when I launch it. `Unable to connect to libvirt qemu:///system \\ Verify that libvirtd daemon is running.`
<axd-v>Well I don't know anything about emulation with qemu/kvm, but due to a lack of options that what I'm trying to learn. It would make sense to me that such things should be taken care with dependancies. I do happen to have `libvirtd` in my path, so I launch it, it just sits quietly at the prompt since it's a daemon I guess, but that has no effect on virm-manager and it still complains with the same error.
<axd-v>roptat: catonano`: thank you for the help, my kernel is recompiling right now heh but in a couple of hours I should have a libvirtd daemon running......... yay. I love the idea of guix, but damn these type of situation are such a meme.. having to wait for a bunch of components to recompile everytime I try to make a tiny change just because the package definition got updated somewhat or something? It's not even a new kernel, same version
<axd-v>and everything. I'm using my own kernel definition so I can see if that's the case or not.
<catonano`>axd-v: using a vanilla kernel would allow you to download a substitute
<axd-v>catonano`: well, I thought that even if you'd built from source (or --fallback) once the package is built once, it won't be rebuilt again.. since it's the same package. Does that not apply to custom package definitions?
<pkill9>yea it does, however if you change anything that affects the output of the package it will rebuild it
<pkill9>axd-v: where/what did you change in your configuration or package definition?
<pkill9>if it was just the system configuration then it should reuse the built kernel
<soundtoxin>any sound experts here? sometimes mpd won't play music for me, it is stuck on paused. I notice if I kill pulseaudio and then try to play it again, it'll work, but then come out of the wrong speakers (internal laptop instead of usb soundcard)
<soundtoxin>playing videos in mpv, I normally get sound out of the right device, but then mpd won't play. after mpd restart pulse, I get an error trying to view pavucontrol
<soundtoxin>if I kill and restart pulseaudio again without using mpd I can see pavucontrol, but then I noticed I don't see my usb soundcard in there
<soundtoxin>I've gotten sound out of my headphones plugged into the usb soundcard, though, in face if I play a video I had open in mpv before messing with all this, it still comes out of my headphones
<axd-v>pkill9: the only thing I really touched was adding a qutebrowser definition after copying it from guix git repo, in order to see how hard it would be to update it to a version that's at least from 2018. However I only got about as far as carbon copying the recipe in there, and then when I later went to system reconfigure, I was obviously met with some error. Then I went to delete anything related to qutebrowser and my config worked for
<axd-v>reconfigure again. As far as I'm aware the qutebrowser recipe didn't really affect the kernel in any way. Second possible thing is that after building my inherited-from-linux-libre custom kernel for the first time, I have ran the `guix pull` command and the libre-linux recipe has slightly changed to more updated libraries or something to that effect, which marked my custom kernel package as needing a rebuild, even though it is the same
<lyr3>I usually kill and restart pulseaudio to fix that
<pkill9>axd-v: as root, run `readlink ~/.config/guix/latest`, then run `find /gnu/store -maxdepth 1 -type d -name '*-guix-?????????'` and replace the symlink in your root's '~/.config/guix/latest' with one of the others
<axd-v>pkill9: interesting, so it's possible to manually use different versions (commits) of guix, in order to build a system that would be updated up to the date of the guix commit? Kind of like having multiple apt/pacman/dnf (repo?) versions each corresponding to a specific date and therefore letting you build a system that would be the latest at a specific point of time in the past?
<pkill9>hopefully it will be implemented in the `guix pull` command at some point, Nix has the ability to roll back the package definitions in it's `nix-channel` command, which is the equivalent of Guix's `guix pull` command
<axd-v>pkill9: very nice, I'm gonna let the kernel finish compiling this time, but this is great to know for the future. Is that in effect making a new "generation"?
<axd-v>pkill9: here is where my lack of understanding comes out. So guix creates system-wide and user-specific generations that act like snapshots of installed packages and configuration at a specific point of time. It is then possible to move between these generations to quickly change what packages are "installed". If I run `guix pull` this pulls in new guix version which has the latest recipe definitions coupled with it, because each
<axd-v>version of guix is also the version of the "package database" you have exposed to you. If it builds successfully then the user's guix_profile pointer for a specific generation that they are running gets updated to point to the new guix version and then it's possible to let the new guix update the already installed packages as per the new recipes? Here is where I don't really understand who is managing the updating of guix itself. Does
<axd-v>the old guix just replace the reference to itself with the new one in the path? I guess that would make sense since each user has their own guix version, but I'm not certain. Tell me if my summary is wrong.
<lyr3>Can I trust GuixSD as daily driver for C and Lisp development?
<bavier`>lyr3: we have some developers making sure guixsd will work for the EOMA68 cards
<davexunit>looks like I'll be able to install guixsd on my novena soon?
<davexunit>might need some sort of tutorial to figure out how to do it right.
<pkill9>axd-v: Preamble: the pointer to guix's package definitions is what gets overwritten (the pointer is in $HOME/.config/guix, called 'latest'), and guix is pretty much hardcoded to look in there for package definitions. The guix-profile is the result of building packages and putting them together into a profile, and guix uses this "package database" in the store path that ~/.config/guix/latest points to to build
<pkill9>the packages (and using substitutes if they're available).
<pkill9>the 'package database'/package definitions aren't the same as the guix-profile
<pkill9>so you have a per-user 'package database' (the recipes to build packages) *and* a per-user guix-profile (a collection of packages that have been built from the recipes, chosen by the user)
<lyr3>NixOS or GuixSD? I know its a delicated question, but I judge that you guys will honest enough
<pkill9>Guix creates a new link to each guix-profile generation, which you can roll back to previous ones, but it doesn't do the same for the package database/package recipes, it just overwrites the pointer/link to the current package database
<ngz>I sometimes encounter the "module not found: PyQt5" when packaging applications, even though python-pyqt is among either inputs or propagated inputs. Any pointer on how to debug the issue?
<thomassgn>I'm preparing to send six patches for haskell, but is best practice one patch per mail to email@example.com? Or should I send one mail with all of them - seeing as they are related package definitions/added variables?
<thomassgn>debbugs is weird. I send a list of patches to the NNN@debbugs address, and I get back acks for creating X new bugs... Shouldn't it just add the patches to the first bug I got and used the NNN@debbugs adress from?
<rekado>thomassgn: no, that’s exactly how it should behave.
<rekado>thomassgn: our recommendation is to send a single cover letter
<civodul>ngz: the ungrafted lilypond has no substitutes either, AFAICS
<rekado>then wait for the confirmation and send the patches to the bug address.
<civodul>ngz: not that it really helps, but it suggests it's not the same bug :-)
<thomassgn>wait. I'm such a clutz. I know exactly why this happened. I had firstname.lastname@example.org as a to in the patches before I used 'git send-email -to NNN@debbugs.gnu.org <list of patches>' that was unnecessary.
<ngz>It is a very frustrating package to build, because it stops for long period of times, probably building documentation, so you cannot even look at some text scrolling in a terminal.
<thomassgn>Should I close the extra bugs it created? (and how would I do that?)
<rekado>my info is a couple of months old already.
<axd-v>I was in here earlier trying to setup QEMU to emulate Debian in GuixSD. So at this point: 1. I've installed the `qemu` and `virt-manager` packages. 2. I've made sure my user is part of `wheel` group. 3. I have added libvirtd to services and can confirm that there is a process named `.libvirtd-real` running. Upon launch virt-manager I still get the message `Unable to connect to libvirt qemu:///system \\n Verify that libvirtd daemon is
<axd-v>running`. Well I feel like the daemon is running, so what now? I'm using the default config for the libvirtd daemon as shown in the manual. Anyone have any ideas?
<vagrantc>axd-v: when i was setting up libvirt, i had to reboot before it allowed me to connect
<vagrantc>axd-v: also, the example in the documentation includes some things not strictly necessary for libvirt
<vagrantc>the tls-port isn't needed, and that suggests to use the "libvirt" group rather than the wheel group
<axd-v>vagrantc: heh, well I was just trying to push and see what comes out so I just literally pasted that in. The unix-sock-group should be "wheel" instead of "libvirt"?
<axd-v>Another question: after a `system reconfigure`, at the very end, guix tells me: `Installing for i386-pc platform.` I'm running x86_64 without a question, 64 bit. Why would it tell me anything about i386?