IRC channel logs
2025-10-24.log
back to list of logs
<tomenzgg>Does Guix keep track of all created profiles (beyond the default one, System, and Home) or are additional profiles just managed manually by the user? If the former, is there a command to list all profiles? <ArneBab>Is there a guix repository that only gets updated when the builds for packages work? <ArneBab>tomenzgg: I think it’s guix gc --list-roots <Deltafire>as with other "rolling release" distros, there's always a chance of something breaking when you update <Deltafire>luckily it's really easy to roll-back with guix :) <futurile>civodul: is there a way to break into a marionette test to do things manually on the test system? e.g. testing debian-install <_d^b_>Is it possible to run Guix System on an RPi 5? <futurile>_d^b_: I would ask on guix-help to see what people are doing <futurile>damm, I need to find a way to post process an image that I'm downloading for a system test, it's too small! <cbaines>what was that distro based on Guix? I've forgotten the name. <orahcio>Hi Rutherther, thanks for the answer on that issue #3790, the problem is my disk, right? I can not reconfigure my system anymore, the output of `guix system reconfigure ...` https://www.paste.org/129535 <Rutherther>orahcio: Hi. Not necessarily, but it's one possibility, yes. You can try using software to test your disk thoroughly to see if it fails. Filesystem corruptions can also happen in case the filesystem doesn't get unmounted cleanly. That can happen ie. on power cuts or on in case there is a software bug <orahcio>Rutherther: Thanks again, I will test my disk and close that issue <Rutherther>as for mitigating your issue with reconfigure, you can try reconfiguring with --no-grafts, if that succeeds, then remove all previous generations (or only the ones pointing to that broken version of pulseaudio) and reconfigure again, without that flag. <orahcio>Rutherther: ok, I will try --no-grafts <Rutherther>sorry, I forgot to say to run "guix gc" after you remove the generations, before reconfiguring again <orahcio>Rutherther: yes, I like to remove alway 1w old generations <Rutherther>that's likely not enough, you need to remove the generation you are currently on and possibly more <orahcio>but it is possible to remove the current generation? <Rutherther>no, that is why I told you to first reconfigure with --no-grafts <orahcio>ok, I will try --no-grafts first, and test my disk only after this <futurile>hah hah hah found it, apparmor is preventing the system tests working on ubuntu lts <futurile>ironically I'm tryiing to build a new test to check if apparmor and the unprivilged daemon work together <futurile>before you do the thing, do this other thng, to build a thing that lets you do the thing heh <ieure>futurile, Oh yeah, a proper yak shave. <ieure>futurile, I work with vintage electronics, there's a good amount of buy a thing to make a thing to fix a thing to fix another thing to fix the actual think you want. <acrow>futurile: just curious -- how did you edit that image ? <sneek>acrow, Rutherther says: I am not sure if someone properly addressed your problem. The /run/user/$USER is created by the pam rule, so no, you cannot install elogind as package and get that folder. But you dont need elogind in the first place. You can just set XDG_RUNTIME_DIR to a directory you prefer. People commonly use a directory under /tmp if they dont have logind. If shepherd is started with this env var, it will put its socket there. <acrow>Rutherther: thank you. Eventually I just bit the bullet and reconfigured with the elogind service and guix took care of the rest. I was worried about nothing -- but I did plumb interesting depths of linux, XDG, pam, and, of course elogind. From my new perspective I don't know why that isn't just the default because pam otherwise makes session management challenging to implement. <futurile>acrow: the image to use is defined in gnu/test/foreign.scm, I'm creating a new test and the image to use is defined in ubuntu-lts-qcow2, turns out you can just provide the URL as something like "uri ("/tmp/futurile-test.img"" - so you can start the image up, fiddle with it and then run the system testt again <acrow>futurile: so you were able to simply modify the image inside guile? <acrow>I don't know what the goto image manipulation library for guile is. Consequently I end up jumping into some other cli package tool. <futurile>acrow: no, I'm just using changing it on the cli, and then booting it in guile/system-tests - yeah me either - I literally started playing with the system test stuff today so I'm probably doing it all wrong :-) <acrow>Well, if it works, it's the right way to do it. <acrow>ACTION I see vagrantc over there with the coffee <vagrantc>ACTION is not (much of) a coffee drinker, acrow must have seen some other vagrant <vagrantc>anyone know if it is possible to subscribe to a codeberg label without being part of the relevent team? <m4xxed>is it possible to ssh into a fresh guix system machine without 'further setup'? I ask since I get connection timeout and the ssh-daemon is running on the new systems system shepherd <m4xxed>would make setting up a new system much easier as I can then also copy over dotfiles etc.... <ieure>m4xxed, Never had an issue with this as long as I enable the SSH server during install and create a user account. <ieure>m4xxed, You can deploy a Guix Home configuration from your operating-system definition. But I'm not sure how to manage Home configs that are in a private Git repo, which I expect most are (mine definitely is). <m4xxed>ieure I have a user account... but I might have forgotten to enable the ssh server during install. Any hints as to where I would do that? <m4xxed>ieure because I have the `(service openssh-service-type)` in my system services... I just did not pass a configuration into this service. Would that be required to enable the service? <ieure>m4xxed, I don't think so, it should be running. <ieure>m4xxed, Maybe you gave ssh the wrong hostname or IP when you tried? <ieure>Or have some packet filtering happening, <ieure>m4xxed, Not sure if the installer adds avahi-service-type, but that definitely helps fine your new machine. <m4xxed>ieure I did not use the hostname, just user@ip-adress so I will look into that <m4xxed>ieure avahi-daemon seems to come by default :) <ieure>m4xxed, Probably true if you use %desktop-services, maybe not for a headless install. <test2020>hello, somebody trying to bootstrap gradle? <orahcio>Thanks Rutherther, reconfigure with --no-grafts works <bowdrill>First guess: find the derivation of incus, then find the output that produces incusd. Somehow get a "lowerable object" out of that <Rutherther>specifically you need something that has a gexp compiler implemented. For example, and the most straightforward, a package. So just "incus", from (gnu packages virtualization) <bowdrill>It's possible I'm misinterpreting. I ran `guix repl`, then evaluated `(use-modules (gnu packages virtualization))`, expecting to find an `incus` binding, but I didn't. I still verified that `guix package -I incus` shows incus is installed. <bowdrill>Let me see if I get an unbound error after `guix system reconfigure`... <Rutherther>I get incus binding. Are you sure you're on recent guix? What does "guix describe" tell you? <bowdrill>It's the repository you expect, commit 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714. Running pull now jic <Rutherther>that's commit from 2022, it's the v1.4.0 version <bowdrill>I've had the experience of running pull several times without new commits seeming to stick. Is this because I'm not using the right profile? <Rutherther>probably, did you relog or source the profile (~/.config/guix/current/etc/profile file) after you pulled? <bowdrill>I added the profile envvars to .bashrc and run `hash guix` as suggested. <bowdrill>guix pull says its building from 2cd14fc now. I'm going to verify if I somehow end up on the 8e2f... commit again after sourcing the profile. <Rutherther>you shouldn't modify env vars in .bashrc, env vars should be modified only in profile files <mhcat>I have a lot of deprecation warnings when I run guix pull - what should I do with these? <mhcat>none of them refer to packages I've installed explicitly (I'm not running guix system, but as userspace pkg manager <identity>mhcat: it means there is an issue in one of the channels you are using, the developers are likely aware <mhcat>identity: thanks - good to know <identity>mhcat: by the way, the word for «running on a foreign distro» is just that, ‹foreign› <bowdrill>Okay, so I was using the wrong profile (/run/current-system/profile/bin/guix). After reverting my .bashrc to the original (my change was setting and using $GUIX_PROFILE), I used the correct value of path to source the new profile. `guix describe` now points to 2cd14fc. <bowdrill>However, `guix repl` now breaks with: /gnu/store/ccxagad0fnzyh0z5xflh3wjlxn4la79n-guile-wrapper/bin/guile: symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <bowdrill>Trying `guix package -u` to see if that's enough. <andreas-e>mhcat: The warnings come from the Guix main channel and are hopefully harmless. We need to go through the warnings to fix them. <bowdrill>Rutherther: No. If I understand you, then I need to set it in "$GUIX_PROFILE/etc/profile". Is there a command that computes the correct value? <Rutherther>The correct value is that it is not set. No, you do not modify etc/profile in any of the profiles guix manages. They are immutable <kavring>omg such techs is there a #guix-noobs channel? <Rutherther>what you're seeing is mismatch between glibc of your system and your user, it should go away after you reconfigure <bowdrill>Okay, so run `guix system reconfigure` now? <ieure>kavring, This is basically that channel. :) <mhcat>identity: I dislike the term "foreign" in that context <AidenIsik>Does anyone happen to know the last commit where KDE Plasma successfully built? <AidenIsik>I've not updated in a bit and it's currently broken <AidenIsik>Yeah issue for it showed up in the issue tracker about 3 hours ago <bowdrill>Okay, so reconfigure fails because I'm back at the 2022 commit (I needed to login again). I updated the PATH as suggested by `guix package`, sourced ~/.guix-profile/etc/profile, and ran `hash guix` again. Still stuck on 8e2f32c. <bowdrill>Is it possible that the profile in my home directory was not actually updated after a pull? <bowdrill>Okay, I instead sourced ~/.config/guix/current/etc/profile instead of ~/.guix-profile/etc/profile. That fixed the commit at least. <bowdrill>I got confused because `guix pull` and `guix package --search-paths` mention `~/.guix-profile`. <Rutherther>~/.config/guix/current is where guix is located. ~/.guix-profile is where you install other packages <Rutherther>I would be very surprised if guix pull mentioned ~/.guix-profile <andreas-e>bowdrill: I noticed a similar problem to yours when I somehow (do not ask me why) ended up with guix installed into my profile; I hope you did not do a "guix install guix" or similar. <andreas-e>AidenIsik: You could try commit c955797f0b18571f3e0b44f4f4849367d50a1df8 or before; KDE was changed right after that. <bowdrill>andreas-e: Nope. My mistakes so far come from being confused about profiles. <Rutherther>bowdrill: okay, that is a bug then and I believe that bug has been fixed already since v1.4.0 <ieure>It's been 2.5 years or so since the release <Rutherther>bowdrill: That is difficult to answer, it should be once per year since the following year. But we will see how it goes <bowdrill>If I get good enough to volunteer, maybe I can help there. <AidenIsik>Are there any plans for a stable branch? Or too much maintenance burden? <andreas-e>No plans right now, indeed we think it is too much maintenance burden. <AidenIsik>I would be happy to help with such a thing if you decide to do it in the future, but right now my knowledge of Guile/Guix isn't sufficient <FuncProgLinux>Do you recommend to "make clean" after pulling the guix checkout? :s I'm having a build that segfaults and/or intltool dies with a TypeError. It was building fine on monday :( <ieure>FuncProgLinux, I never `make clean', makes the compile take forever. <FuncProgLinux>It's part of the MATE refresh thingy I'm doing. A missing caja component to be specific. <andreas-e>QA has gone down a bit since the move to Codeberg, because the infrastructure that did continuous integration on pull requests was taylored to debbugs. So I think we tend to push more commits that break things... But there is some work done to improve QA again. <FuncProgLinux>ieure: I had to do that when uploading the pluma fixes. It does take forever on the texi manuals stage <andreas-e>FuncProgLinux: "make clean-go" can be useful (and enough) when the ABI of some Guix modules changed. <andreas-e>But as ieure said, it depends on the power of your machine; for me it takes about half an hour, so I only do it if I see no other solution. <bowdrill>`WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'' <bowdrill>Printed near the end of `guix system reconfigure /etc/config.scm` <bowdrill>Rutherther: Finally, I see that incus binding. lol <FuncProgLinux>time to --rounds=10 to either confirm or disprove my suspicions lol <bowdrill>What is the preferred way to update /etc/config.scm when tracking it in version control? ln -rs /path/to/tracked/config.scm /etc/config.scm? <ieure>bowdrill, Delete /etc/config.scm and `sudo guix system reconfigure /path/to/repo/config.scm' <ieure>There is absolutely nothing special about the config being in /etc/config.scm, it can be anywhere. <bowdrill>Okay, then I'll take to heart that I really don't need to touch anything in /etc. Thanks! <NotTerry>Anyone else getting error from guix pull that it can't connect to git repo neither savannah nor codeberg? (While I can clone the same and other repos just fine with the git in my profile.) <gabber`>doesn't the 'patch-shebangs patch for example python scripts with a `#!/usr/bin/env python3' shebang line? <FuncProgLinux>NotTerry: I can access just fine but if you want to reduce network errors you can fork and use a local checkout as the main guix channel <FuncProgLinux>I had to delete the openpgp-fingerprint section though because the reconfigure takes ages when guix pull-ing and it errored out due to "wrong keys" <NotTerry>FuncProgLinux: I am more trying to find out why it happens. It clearly isn't a network error in the machine as a whole. Just in the environment that does the guix pull operations. But I am still too new to Guix to understand whats going on under the hood or even debug it. <ieure>NotTerry, Want to put the error you're getting into a pastebin? <NotTerry>ieure: It is a oneliner that says that it can't connect to the repo via https. No other more specific words. <FuncProgLinux>NotTerry: I'm also not a guix guru, but codeberg does suffer more outages than bigger git forges. And Savannah...well ._. it does die pretty often. <NotTerry>ieure: Umm that of course one more thing. Its a timeout. <NotTerry>But not clear if it is a timeout in the network sense or a timeout in the glue logic around the network call sense. <FuncProgLinux>NotTerry: Do you have a Codeberg account? can you "git clone" via SSH just fine? <Deltafire>you could fire up ethereal.. wireshark to be sure <ieure>Deltafire, Not terribly useful since everything is HTTPS now, would have to stand up mitmproxy to get anything useful. <Deltafire>just done a guix pull here, seemed pretty speedy <NotTerry>FuncProgLinux: It is just guix pull that does not work. Doing https clones from the same shell, from the same repo just in the guix pull wrapper just works. <NotTerry>no it does not, it actually went through after minutes <NotTerry>Maybe its the same thing for the guix pull but the timeout is shorter.