IRC channel logs
2025-05-25.log
back to list of logs
<acrow>Maybe someone here has encountered this before while packaging something for guile/guix using hall. paste.debian.net/1376399 <luca>Hi, does anyone know how the XDG_RUNTIME_DIR variable gets set? I've removed elogind from my system services, yet it still got assigned to /run/user/1000 without making that folder <look>luca: on home-xdg-base-directories-service-type, which is an essential service for home-environment <dcunit3d>i just encountered a wierd issue when building nfdump. i used another package (amule) with similar deps as a template, but left an invalid version number (2.3.3) along with amule's base32 hash. <dcunit3d>i changed had changed the package name (of both the definition and the record; from amule -> nfdump). I wrote package outside of my guile modules path. <dcunit3d>it couldn't find the git commit in nfdump, but I think it recognized the base32 has, so it tried to download the archive from a few extra sources (software heritage, etc) <dcunit3d>the guix daemon kept those build runs until they failed (it may have repeated redownloaded or copied the original artifact) <dcunit3d>I fixed the version number, then it started working from the amule source again, until i ran `guix gc` <dcunit3d>idk wierd, but i still have one of the failed build runs <dcunit3d>it was building off of amule 2.3.3, but maybe it was issue with the sqlite database or the deferred guix-daemon builds <Lord_Devi>How do I do something like have config.scm create a custom /etc/sudoers file? I do not see any sudo-service-type to configure, so I think I need to somehow create a custom /etc/sudoers, but can't figure out how from the dox, and LLM's aren't much help either. <Lord_Devi>Oh, found a 'sudoers-file' function for "(operating-system". This is likely what I want.. Still, could not figure out how to just magically write out a custom file to /etc.. <dcunit3d>also, more recent interations of the build may be shimming older build paths (/tmp/guix-build...-2.drv has files that reference /tmp/guix-build-...-0.drv) https://0x0.st/8xcE.txt <dcunit3d>what's happening there, i guess, is that the daemon starts a build container with nothing in /tmp, picks "guix-build-...-0" bc there's nothing there. once finished, the build daemon moves the result out of the container and needs to increment the path in /tmp <meaty>when will codeberg.org/guix/guix.git be available? I'm holding off on updating until it's ready <meaty>blogpost says today but it's not ready yet it seems <ruther>dcunit3d: that is not what is happening. The daemon will create this folder before build and mount it to /tmp/...-0 in the chroot, no matter the number in the /tmp in the _base_ filesystem <meaty>Is the guix/guix repository ready yet? <PotentialUser-71>I'm facing an issue running applications installed previously: /home/user/.guix-profile/bin/polari: symbol lookup error: /gnu/store/7qrirnjxvspls0v98kprpjbpim8rwxgj-gvfs-1.56.1/lib/gvfs/libgvfscommon.so: undefined symbol: g_once_init_enter_pointer <PotentialUser-71>I didn't find any useful information looking for the error or gvfs. As a newcomer I'm stuck. What can I do to resolve the issue? <identity>PotentialUser-71: the polari package may be broken <PotentialUser-71>identity: thanks, but I have this with all applications I installed previously that weren't part of the base system. <identity>PotentialUser-71: you should try upgrading them, then; if the issue persists, try guix gc --verify=contents,repair <ruther>PotentialUser-71: can you try unsetting GIO_EXTRA_MODULES environment variable? <ruther>in the environment you start the app in <ruther>if guix upgrade has any chance of fixing iit, you will at least need to relog afterwards <PotentialUser-71>It starts without images/icons when I run: unset GIO_EXTRA_MODULES; polari <identity>PotentialUser-71: log out and then log back in <ruther>PotentialUser-71: I doubt no icons/images is caused by unsetting GIO_EXTRA_MODULES <ruther>note that this will keep happening as long as you don't upgrade packages at once <ruther>that's just the unfortunate way the gio extra modules env var works. I think it's best to unset it, permanently <ruther>the programs are wrapped with the correct one if they need it <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, old says: if we now have a guile-codeberg interface after importing Guix teams ^^ <luca>what migration? Codeberg time? <ruther>luca: what icon pack have you installed? <luca>possibly none. Can't see anything icon-y related in my config <luca>What icon pack does the gnome service install? <luca>probably adwaita-icon-theme <identity>luca: i think you can set gnome-desktop-configuration's 'utilities' field to '() to not install 'the whole gnome suite', though you probably want just the icon theme <luca>Not adwaita, but hicolor-icon-theme <meaty>if my channel configuration uses %default-channels do I need to double-pull? <identity>meaty: you could just pull once and then copy .git into the other checkout... <identity>do not forget to edit .git/config to point to the right repository though <meaty>nvm, the old repo is down rn so I have to manually specify it anyways <meaty>oh wait, I can't pull... my current system profile is pointed to savannah which is down :( so close yet so far <cbaines>guix-newbie, the migration is happening at the moment, and yeah, I don't think Pull Requests have been enabled yet <PotentialUser-93>is the fish shell for guix home officially supported or not yet ? I try to set it up (foreign distro, Alpine Linux) but I get "3" issues, one is a locale issue, second is GUIX_PROFILE doesnt get defined and third is .config/guix/bin doesnt get added in the path <ruther>PotentialUser-93: GUIX_PROFILE shouldn't realy be set, so it is correct you don't have it set. As for the PATH, so you relogged and didn't get the home profile and guix config profile in it after setting up home-fish-service-type & making it your login shell? <PotentialUser-93>yep, I relogged, guix-home/profile/{bin,sbin} is in the path but not .guix-profile/{bin,sbin} and not .config/guix/bin <ruther>PotentialUser-93: I am afraid that's just how the service is. It doesn't source .guix-profile nor .config/guix etc/profile files like bash_profile does <PotentialUser-93>okay I see, I guess for the path I can handle that, the one remaining then is I get a locale issue with fish that I dont get with bash, guile and perl complains (I will try to reboot but have little hope that will help) <ruther>PotentialUser-93: do not handle 'path', just source the profile etc/profile files to get all the env vars from the profiles (with fenv of course) <ruther>PotentialUser-93: don't forget to set GUIX_PROFILE when sourcing them and unset it when you're done with the sourcing <ardraidi>I'm trying to open a pull request using git push (agit), but I'm getting an error <ardraidi>guix git: error: unknown introductory commit and signer <ardraidi>I tested this yesterday on forgejo in the lab but didn't get this error <ruther>ardraidi: have you also tried using the codeberg url directly? <ruther>ardraidi: although no, scratch that <ruther>ardraidi: the error seems to be coming from pre-push hook <ruther>ardraidi: I think the pre-push hook is not correct for non-maintainers <ruther>ardraidi: so you can just remove it. It is a check to make sure you don't push wrongly authenticated commits to master <ardraidi>Yeah. Took a quick look, but I don't know much about this, so wasn't sure. <ruther>ardraidi: or wherever. But you're not pushing directly to the repository... the pre-push hook just doesn't know that. <hako>that hook checks *.gnu.org <hako>does codeberg.org url work? <ruther>hako: but it doesn't matter what url it will check if you can't be signing commits, that's the case for all non-maintainers <ruther>the hook should just ignore when pushing to `refs/for` <ruther>you didn't need to clone, you can just change the remote <hako>you can directly push to url <ardraidi>ruther: yeah. wanted to test from a clean base. <ardraidi>I think the hooks might need work. I think making git.guix.gnu.org/guix.git work for this is a good idea <ardraidi>TBH, knowing that I can edit the description and other amenities forgejo provides makes life a bit easier. <ardraidi>The pre-push git hook checks for URLs that match '*.gnu.org*', which is why it was being activated and the push was failing, I think. <efraim>hako: the zig update to 0.14.1 broke ncdu@2 <efraim>there's also an update to ncdu if you want to take care of that too <hako>OK, I'll use it to practice AGit-Flow :) <jakef>congrats on the migration, guix! <decfed>Most AppImage will probably depend on some system libraries. So you will face issues. This is different from the AppImage created by guix pack -f appimage which are by design self-contained. However, this will not help if you already have a package definition <decfed>do not already have a package definition <decfed>is Ansel available as Flatpak? That might be a way out for you <nico_>Unfortunately no. There is a Darktable package definition I could adapt. But the application is under heavy and fundamental development, so it might be a challenge to keep up. <look>does anyone know a better way of not having to recompile everything when I switch from a team branch to another, other than having one checkout for each branch? <ruther>look: you don't have to have one checkout per branch, you can use work-trees. Other than that I don't know <hako>worktree? though it's still one "checkout" for each branch <look>oh, thank you both. i didnt know worktrees existed at all, silly me going into every team checkout I had changing remote urls one by one, facepalm moment right here xd <PotentialUser-88>I seem to have an issue with "XDG_RUNTIME_DIR" with guix home, it says the script "on-first-login" wont do anything because its not defined, but it is and when I run the script manually (with the variable defined) it still says its not defined.. <ruther>PotentialUser-88: what has defined the environment variable, and how? How are you checking that it is defined and how are you running the script manually? <PotentialUser-88>I am checking just by using "echo $XDG_RUNTIME_DIR" which show /run/user/1000, and to run it manually I simply give the path to the shell which executes it since it has execute flag <ruther>PotentialUser-88: echo is unsuitable for checking env vars as it will also show shell variables. Use printenv <ruther>Okay. So running ~/.guix-home/on-first-login in that environment will give you and error about XDG_RUNTIME_DIR? <PotentialUser-88>XDG_RUNTIME_DIR variable is set to appropriate value and manually execute the <ruther>please use paste site for logs / code <ruther>Ah, so the error says it doesn't exist, not that it is not set. S <ruther>If you aren't using elogind nor greetd, you will need to take care of that folder and env var yourself <ruther>PotentialUser-88: you can use home-xdg-base-directories-service-type runtime-dir option to set the env var, you still need to create it yourself <PotentialUser-88>the last issue I seem to have (perl stopped yelling after I set my LC_ALL to C.UTF-8) is guile complaining with "guile: warning: failed to install locale", is there a specific variable I am supposed to set or is C.UTF-8 not ok for guile ? (locales with Alpine Linux seems not easy to setup xD) <ruther>PotentialUser-88: yes, set GUIX_LOCPATH to a profile you install locales to <ruther>ie. to ~/.guix-home/profile/lib/locale if you install locales to your home profile <PotentialUser-88>this is my GUIX_LOCPATH: GUIX_LOCPATH=/home/azz/.guix-profile/lib/locale:/home/azz/.guix-home/profile/lib/locale, they both have a 2.39 directory inside <ruther>PotentialUser-88: and what is inside that directory? <ruther>PotentialUser-88: so there is no C.UTF-8? Then that answers why it doesn't work with that locale <ruther>PotentialUser-88: okay, then I have no idea why guile is complaining. (As long as guile is coming from guix that is) <PotentialUser-88>which guile shows that it comes from my guix profile so I would think so <PotentialUser-88>ok interesting, when thats the "first" time the shell start I get the guile warning, when I start a fish inside fish, I dont get the warning <ruther>PotentialUser-88: are you sure you have GUIX_LOCPATH environment variable set in the first one? <ruther>PotentialUser-88: hmm. Not really sure. You can try comparing environments between the two shells, maybe something will stand out <Noisytoot>The README file in the guix repo should be renamed or symlinked to README.org so codeberg renders it as org-mode <cbaines>I'm still pulling from Savannah and I don't know why :/ <civodul>i’ll have to tweak my notification settings on Codeberg because i’m receiving everything <civodul>maybe because i’m in the “owners” team? <hako>Not sure if there's a setting, I'm getting them too after watching the repo. <yelninei>janneke: thanks for the reviews. I rebuild everything after the gcc update and now there is a consistent test failure in gdbm, dont know how this was fine before. There are a lot of fixes for that test case in the git repo already, I am unsure how to proceed <yelninei>nixos added all of the test fix patches, i guess ill do that aswell <scut>I saw a new repo on codeberg, is the migration complete and successful ? :) <scut>ieure: the link does not seem to work on my end unfortunately <ieure>scut, The link to lists.gnu.org? <ieure>Or the link to Codeberg on the post I linked? <scut>Yes, to the mailing list <ieure>Huh, works fine for me. Well, the email is from civodul and the subject is "Codeberg migration complete" <scut>Finally got the mail. Congratulations ! Now, onto my first PR... <ruther>has there been work on QA yet to support PRs btw? <ieure>I'm not sure. Definitely for cuirass, not sure about Qa. <yelninei>hmm, not a huge fan of having to juggle branches around for my pr, i have like 15 patches ontop of core-packages-team most are quick hacks to ignore something for now. But the submitting and updating part was really nice <ieure>yelninei, What kind of branch juggling are you doing? <yelninei>ieure: i have my local core-packages-team branch with some quick hacks and WIP stuff. If I now want to send only the HEAD of my local branch i need to create a new branch with only that one commit to create the pr <ieure>yelninei, Ah, yes, you do have to do that. <cbaines>providing QA is working, it'll continue to process all the guix-patches patches, so there will be no shortage of things there to build and review <ruther>anyone can tell me why it could be that my messages aren't appearing in #75518? It's been three messages so far. I am suspecting some headers aren't treated well by Debbugs? <ieure>ruther, More likely mumi is hosemode somehow. <ruther>ieure: no, it is not about mumi, it is about debbugs <scut>Quick question: ./pre-inst-env guix refresh --list-dependent returns : "Building the following 272 packages would ensure 356 dependent packages are rebuilt" <scut>Do I have to recompile all of them to check my update ? If so, how ? :) <ruther>scut: you usually leave that to QA when it's many packages <scut>Thanks. ` guix build --dependents=1 ` worked fine <ieure>Pretty awesome to apply PR changes with `git merge pr/123'. <ruther>ieure: is that not going to potentially end up with unsigned commits? <ruther>re 75518 issue with no e-mails from me: I just tried plain e-mail just to the issue itself without Ccing others and it went through, so seems it is one/more of the e-mail addresses in To/Cc headers <ruther>ieure: how did you obtain the pr branch in the first place btw? <ieure>ruther, `git config --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"' <ieure>You can check out origin/pr/123, or merge/cherry pick directly from it. <ruther>oh, I didn't know forgejo supports refs/pull <ruther>ieure: I mean it is still "commited by apraga", so it seems to me it's not really because of git merge usage, but not completely sure <ieure>Yeah, that is different than the other PRs I've merged today. <ruther>I thought commiter won't be changed if you do git merge, but seems I was mistaken <ruther>I have to go now, so I can't test it, but I will soon probably. <ieure>Same as applying patches, the author and committer are separate people, <ruther>I was unable to find much information about gpg signing of git merge, the only thing I found was about signing the merge commit itself <ieure>Trying to pull to see if I broke master already. <ruther>or actually you can just use the gnu.org url <ruther>wondering what the policy is on force pushing to master :) <ieure>Guessing only civodul has the power to do that. <ieure>yep ! [remote rejected] master -> master (pre-receive hook declined) <ruther>also wondering how does the mirror bot work after there is a force push <ieure>I was just wondering myself. <ruther>ieure: did you maybe rebase on master in case of one of the prs and not in the other? <ruther>a rebase would definitely make yourself the committer and sign <ieure>ruther, I did for all of them, but I think in the other cases, there were commits to master in between. <ruther>ieure: oh so you mean that in the last case there was nothing done as the base commit was the same? <ruther>yeah, makes sense, then git merge really doesn't sign them <ruther>not sure what the easiest approach is, to make sure everything from the pr gets commited by you <ieure>I have a script I wrote a long time ago, `git rebase-here', it rebases another branch on top of HEAD. Probably something like that. <luca>> error: commit ea779f0b6bf7954327671b98bb93482a28fad668 lacks a signature <luca>ohoh, trying unsigned commits? <ieure>luca, I just emailed guix-devel, civodul has to fix this. <luca>peanuts must be updated :O <SquircleSpace>what's the easiest way to make guix pull temporarily ignore the guix channel? <Hamled>can you specify the previous commit in the channel definition <SquircleSpace>thank you. I'm mid-way through setting up my first real guix install. So, I'm still figuring out how to make things work <Hamled>you'll definitely want to remove that file then, after the current situation gets resolved <SquircleSpace>I'm aware. I'm coming from NixOS so I'm definitely familiar with the implications of pinning the channel to a specific revision <guix-newbie>given today's big event, i'm surprised forgejo and woodpecker are not in guix yet <lilyp>ieure: we got a speedrunner among us <cancername>I pinned to the previous commit for now, 318ad8f <meaty>how can I find the store location of my current system guix? <meaty>the paths listed in "guix locate guix" don't line up with the hash in "guix describe" <meaty>I'm trying to update my userspace repository after guix pulling <meaty>and avoid having to pull the same data twice <Hamled>I think `realpath /run/current-system` should work? <Hamled>Oh, sorry that'd be the current system profile <Hamled>I may still be misunderstanding what you're asking for meaty, but would `ls /gnu/store | grep guix-<short commit hash>/` be the store object you mean? <meaty>doesn't have a .git dir unfortunately... guess the only way to do this is to set my userspace repo as the guix channel <Hamled>I think you're looking for something in /root/.cache/guix/checkouts <Hamled>Oh I guess even that doesn't have the git directory? not sure where the guix program keeps it <Hamled>nm I'm wrong, its probably there, I just don't know what the naming scheme is for the directories in that checkouts path <meaty>Hamled: yeah, i see what you mean. there are .git repos in there <ieure>Ah, thank you to whoever force-pushed my unsigned commit. <ieure>Sorry for wrecking master on the first day. 
