IRC channel logs
2026-01-22.log
back to list of logs
<FuncProgLinux>Requesting a re-review from the cuirass-bot doesn't trigger the rebuild status <oliverD>I've spent 2 days trying to fix the "you need to log out" error in gnome, i've rolled back repeatedly, deleted gnome's setting (and then restored them) run gc with repair options and nothing seems to work. I got rid of it briefly but after turning off the computer it's back. <oliverD>I keep getting hints to install glibc-locals but when I do that it just breaks things further and prevents me from being able to run any commands from bash because GLIBC is the wrong version. <flurando>hi, I am considerring setting up a home server with raspberry pi or similar products. But I wonder if guix system could seamlessly run on it, for example with raspberry pi 5 and possible vanilla linux kernel. <flurando>Any experience? I would buy a raspberry pi 5 if it is known to work with guix system. <flurando>Though there is indeed a template of raspberry-pi-64 in guix repo, I am not sure for really setting one up. <oliverD>Do I really need to wipe the slate and move everything manually to a new account? <oliverD>I've tried changing my profile updating guix, updating packages and I am still being told to instll libc and run export ... which I have done many times. <oliverD>Sorry about ranting it just been very stressful trying to get back into my computer. <oliverD>(this is not quite as bad as trying to disable Onedrive completely on windows but it's close) <mange>oliverD: Have you looked for any logs that tell you what's going wrong? Either from your Gnome session, or from GDM, or anything? <oliverD>I looked through them but couldn't see anything obviously wrong, I'll look again. <mange>The comment about different glibc versions is a bit suspicious, because Guix should all be built with one glibc. Are you on a foreign distribution? Or are you using old profiles (from before the last glibc upgrade)? <flurando>oliverD: if there is any previous working profile generation of guix, just roll back to that version. <oliverD>I'm using the guix system and this is after running guix pull it suggests that I need to install glibc-locals (now it doesn't ask me to install glibc-locals, i uncomented the varaibles in .profile but it's still not booting) <mange>How old is your profile with Gnome? There used to be a problem with stale caches in /var/lib/gdm which had to be cleared. This is now solved by mounting that directory using tmpfs, but if your system predates that change you might need to clear them out? <flurando>oliverD: roll back to the latest working profile generation first. <oliverD>One of the logs in Xorg.1.log: is systemd-logind: got fd for /dev/input/event6 13:70 fd 33 paused 0 <oliverD>but i have no idea what I'm looking for <oliverD>ive switched back several generating to one i know worked last time and its still white screening. <mange>When you say you installed it two weeks ago, do you mean the whole Guix installation? Or did you "guix pull; sudo guix system reconfigure config.scm" two weeks ago? <RavenJoad>What is the best/easiest way to debug a Guix system test? (One of the gnu/tests/*.scm ones). <oliverD>I put the Guix installation media on a USB 2 and a bit weeks and a bit ago and then flashed it to an old computer that previously had Windows installed (i think the computer is 7+ years old which might explain some of my issues). <mange>Part of the problem with that is that the last Guix release is very old. You can update by running "guix pull; sudo guix system reconfigure /etc/config.scm". This should pull in the fix that I mentioned for Gnome/GDM, which should then work after a reboot. <oliverD>i mean booted into the usb but you get the idea <mange>There's a release team currently working to get a new Guix release out (and hopefully more frequent releases), but that's doesn't help you with what you have, unfortunately. <RavenJoad>oliverD: My old personal laptop, which I still use, is 10 years old now and runs Guix without issue. <mange>Yeah, I run Guix on an eight year old laptop without any issues. If anything, older stuff probably works better because Linux has had longer to get fixes for the hardware. <oliverD>It tells me that imported module overrides core binding delete <oliverD>(it says segfault likely on cpu 2 when i start up is that ok?) <oliverD>Also now I don't get errors when I start Icedove! <mange>"Imported module overrides core binding delete" is fine (I hope - I've been getting that for ages). "Segfault likely", I don't know (it sounds bad, but maybe it's fine?). <mange>oliverD: Should I take your messages to mean you're back into gnome now, too? <oliverD>Yes, also my previous issues with graphics libraries also seem to be fixed <acidbong>moin, guixers. a couple of questions on Guix System config: <acidbong>1. is it possible to set the config as its own package channel? i want both to use some custom packages inside my system and to have them buildable with plain `guix build PACKAGE`, but without splitting the repo <acidbong>2. can a channel be located in `.config/guix`? <flurando>acidbong: 1 yes, actually most personal channels are in this way, but you have to write your config in modular style with define-module stuff; 2 no, that folder is not for user to develop channels in. <flurando>The documentation clearly says you can put anything in your channel, except that packages and services are the most common. <oliverD1>I'm trying to use icecat on guix and when i connect to my outlook account it opens a popup that redirect to a page telling me to enable cookies. how do i make this authentication popup open somewhere else? <oliverD1>I've tried setting my default browser to chromium and frantically copy pasting out the link in the popup (neither works) <thanosapollo>I've switched my server to guix and been playing with git-http-nginx backend, is there a reason guix currently does not specify valid git http actions? I've also opened an issue with some suggestions on how to fix the uri-path bug for "/". <gabber>we have a problem packaging a "version manager" kinda software package. it spits out an ugly traceback (so it doesn't work) unless we add git AND nss-certs as propagated inputs. we patch the packages sources for a full git path but nss certificates seem to still be missing <gabber>do we have to set some env vars within the package for this to work? <gabber>is it problematic that the package to be wrapped is already being wrapped (it is a python executable) <Rutherther>gabber: conceptually definitely not an issue, you just prepend to that wrapper. Moreover I think wrap-program already handles that, but I am not completely sure <gabber>now my only question is: what provides /etc/ssl/certs/ca-certificates.crt ? <gabber>the package `nss-certs` should, but does not and the store output ca-certificate-bundle does not seem to be a package? <Rutherther>gabber: a profile hook does provide that file, out of the nss-certs package <gabber>is it safe to assume people have /etc/ssl/certs/ca-certificates.crt installed? <gabber>on both foreign and Guix Systems? <flurando>gabber: no, there is no /etc/ssl/certs/ca-certificates.crt on guix currently. the only safe option is to use system cert store. <flurando>gabber: So it is safe most of the time to do so, given 99% percent of guix machines have nss-certs installed and relevant one-time service to populate /etc/ssl/certs. <Rutherther>csantosb: yes, he is a committer of all commits. He did the rebase as last person <csantosb>Ok, thanks; I just understood why we Sign Off. <civodul>csantosb: yes, because Andreas rebased it <civodul>ACTION is not convinced by the rebasing strategy for this branch <civodul>ACTION is not convinced there’s a need for next-master in the first place :-) <civodul>something to discuss it post-release! <csantosb>Rutherther: I think I prefer your non fast forward strategy (in case there is some spare time left for more discussions 😉) <Rutherther>csantosb: with the version branches there is no discussion, we pretty much have to do it like this here. Due to the artifacts being built for a commit on the version branch <Rutherther>csantosb: otherwise I personally prefer to 1. rebase the branch, 2. --no-ff to have a merge commit. This keeps the history mostly linear, while including information about merges, having the two different parents so that you can see what commit was the one on master before that <Rutherther>But currently the preferred solution is just rebase and fast forward only <yelninei>no matter what I do, I cant reproduce the bug except when guix-daemon spawns the process. Is guix-daemon doing something weird in how it does that? <Rutherther>yelninei: so without the chroot? Still I think it runs it as a different user, guixbldX when using the privileged daemon. Maybe try running as those users? <civodul>yelninei: hi! which bug are you referring to? <yelninei>and it does not exist unless guix-daemonm spawns the guile <yelninei>(for a simpler package youll also get the warnings when compiling any other guile package, i.e. guile-fibers <ieure>I talk up how good it is to have email, chat, shell, editor, git client etc etc in Emacs, but typing your shell command into the chat is definitely a downside, ha. <gabber>ieure: it happens to the best (: <gabber>as long as you do not tweet your passwords you're ok, IMO <ieure>I deleted my Twitter account years ago. <acidbong>ight, on a serious note: why are package fields, that in Nixpkgs are under PACKAGE.meta, are top-level in Guix packages? is it because Scheme isn't so strong to nest values and access them compared to Nix? <acidbong>(which is homepage, description, license) <gabber>acidbong: my guess is that in Guix packages contain the most minimal necessary fields to distribute software. homepage, description and license are all *essential* fields, so there would be little reason *not to* include them in the one, main entity that is a package in Guix <gabber>but i have absolutely no experience at all with regard to nix, so take this with a pinch of salt <cdegroot>It's probably one of these choices where you can flip a coin and then make a good argument for either outcome. I also think it's completely not important. I mean, I work with both Nix and Guix and never noticed it :) <identity>everything about the package data is meta, apart from the outputs <gabber>all work, some joy, but all in all rather funky <Kabouik>4 or 5 years using Guix as a distro and I still have trouble interpreting the output of package upgrade conflicts: https://0x0.st/PPLn.txt I don't know how to read it because if I do what's recommended at the bottom, it will fail too and show another set of conflicting packages, and this usually is a very long sequence if I try to iterate. <Kabouik>Is there a magical guix command I am missing if there are such conflicts? <identity>Kabouik: are you upgrading the packages one-by-one or all at once? <Kabouik>I was trying them all at once (but tried upgrading those in the conflicts individually too, to no avail). <Kabouik>I tried before and after reconfiguring the system (which worked fine), in case it would have been related to my system packages. <Kabouik>So it seems removing (temporarily) mpv, remmina, vips and flatpak helps going further with a `guix package -u`, but I found no better way to find out than just iteratively going over the package mentioned in the conflict output. <Kabouik>Perhaps these are packages both in my config.scm and in my Guix profile, is that possible? <Kabouik>(I mean is that a possible cause of conflict)? <Rutherther>Conflicts are reported only within the same profile <gabber>Kabouik: i wish i knew of a better way to resolve these <Kabouik>Guix reported that I had two versions of mpv, of flatpak, of remmina (and maybe vips too but I don't remember), but again only after iteratively going over packages names mentioned in the error and retrying the upgrade. Not sure how I got different versions of those concurrently in my profile. <yelninei>Rutherther: But it also happens with "guix authenticate" which runs as root <yelninei>the fun of dealing with mutable global variables <yelninei>on debian hurd-i386 there are the same warnings. At least I am not completely crazy. <yelninei>ACTION wonders how guile-fibers passes all tests on debian <GNUtoo>yelninei: I also got an issue with guile-fibers recently, with GNU Boot, on Guix 1.4.0 <GNUtoo>on one VM (with bordeaux.guix.gnu.org) the build worked fine, but on another one, without bordeaux, the build failed because of guile-fibers. Things now work again without bordeaux, and I didn't investigate more. The problem was a guile-fibers test not passing for some reasons. <GNUtoo>(I didn't find a link and I've no idea how to track the progress) <yelninei>GNUtoo: You might have a different problem unless you are trying to build fibers on hurd. <yelninei>on debian failures due to timeout seem to be non fatal <GNUtoo>With additional search terms I found an IRC log from #bootstrappable that mentions the ada bootstrap, so I'll go ask there. Yesterday I searched the project 2 names verbatim, in quotes, so maybe that why I didn't find it. <efraim>GNUtoo: that's me, I've been moving slowly <efraim>I got distracted, going to start up again real soon <GNUtoo>you're probably aware of neox's previous work that used the Debian packages for ada as a basis to bootstrap ada in Guix? <GNUtoo>btw, thanks a lot for this work, some coreboot drivers are in ada, so we somehow need ada in Guix at some point. <csantosb>Yes, please ! I'm currently using the GNAT-FSF-builds binaries to build Ghdl in Guix Science. Having Ada proper would be great. <yelninei>mrvdb: Are you using an up to date guix? <andreas-e>It works for me, but there are tons of packages. Alternatively, "guix package -A qmk" is useful (it shows just a list of packages instead of all the details). <mrvdb>yelninei: i think so, as in, guix pull this morning <mrvdb>andreas-e: guix package -A qmk shows nothing either <yelninei>mrvdb: What is the output of "guix describe". Does the guix command you use point to ~/.config/guix/current/bin/guix <mrvdb>guix points to /usr/local/bin <andreas-e>Did you do a "guix pull" since you installed Guix? <mrvdb>~/.config/guix/current/bin/guix search qmk works <mrvdb>so, seems something was lingering from an old install and my env is not set up properly, enough to go on and fix, thanks! <yelninei>the allocations libgc makes are more or less the same size. But why is it only in the environment of the guix-daemon that libgc complains. I would expect it to be more random. And why is changing locales affecting it <ieure>yelninei, Guess, setting the locale to something with multibyte encoding means the size of allocations for strings increases 2x or more. <yelninei>ieure: but it does not happen when I run the same thing from bash. And the change is going from LC_CTYPE=C.UTF-8 to LC_ALL=C.UTF-8, so all the ports are already in UTF-8. <yelninei>ACTION tries to build guile agains a libgc with more debuginfo <civodul>acidbong: in Nix, ‘meta’ is separate because it receives special treatment when passed to the ‘derivation’ primitive <vagrantc>hrm. all the guix tests seem to have "test-name: #f" ... which is not particularly easy to distinguish from all the other "test-name: #f" tests ... unless i am reading something wrong <ieure>vagrantc, I recently came to that conclusion as well. <ieure>vagrantc, Yes, I thought it was odd as well. <vagrantc>i swear that used to have meaningful stuff in there <vagrantc>makes it a bit tricky to sort out the ~32 test failures on Debian <vagrantc>also seeing some XFAIL ... that seems new <vagrantc>not sure what XPASS is ... a non-fatal expected to pass but ok if it fails? <vagrantc>extra fun is there are 32 failures ... but only "result: FAIL" on three <vagrantc>ugh. most of the failures are in tests/store.scm, but it provides no debugging output for most of it