IRC channel logs
2025-08-12.log
back to list of logs
<eikcaz>I think I have some corrupt store items. I see there is a .drv that is empty for one which is crashing things. Is there an easy way to remove store items by path? <eikcaz>Back. Tried 'herd stop file-system-/gnu/store' to delete the offending store item. This, maybe unsurprisingly, had quite a few dependent services... Do not reccomend. <efraim>... approaching 43 hours on gcc-final on powerpc-linux <eikcaz>I tried guix gc'ing and re-reconfguring, but booting still fails with &missing-service-error: user-homes. Since it's so early in boot, I only have an image of the error here: https://zacchae.us/boot-err.jpg <efraim>there's also sudo guix gc --verify=repair,contents to try to fix/rebuild the empty derivations <eikcaz>hmm. should I guix system delete-generation the broken system generation first? <eikcaz>Oh hey, it's definitely printing about corrupted or missing paths! <efraim>eikcaz: do you have any custom services? it looks like something depends on user-homes but it isn't pulled in by any of your other services? <eikcaz>efraim: all the services are simple/off-the-shelf. I modified gdm-service-type and elogind-service-type in %desktop-services to disable auto-suspend and handle-power-key as 'suspend (respectively). Overall, I would consider my setup quite minimalist <efraim>so then I hope its just the corrupted store items <eikcaz>Yeah, I'm pretty sure all my issues can be traced to electrical problems on my device (now fixed). I'm a little skeptical that --verify=repair,contents could really tell if an archive is valid in all cases, but it seems to be doing something, so fingers crossed. <eikcaz>ah. Reading the docs on --verify. I'm understanding more, and becoming more optimistic :) <Rutherther>eikcaz: deleting paths in the store can never help in such situations, as you would also have to update the database, otherwise guix is still going to be confused. But at that point you just use guix gc -D to do it for you <eikcaz>Thank you #guix. My machine lives :) <identity>i notice that the default .bashrc creates some aliases, like ll="ls -l", but it also sources /etc/bashrc.d/aliases.sh which seemingly does the same thing? <Rutherther>Default bashrc... Meaning the default in guix-home? <Rutherther>Guix home is also for other distros, so yeah, there can be something doubled because of that. Like sourcing /etc/bashrc even though bash on Guix System will do that automatically, or this <simendsjo>Digged into why a lot of sites was rendered using awfully pixelated fonts. They prioritized Helvetica highest, and I had font-adobe75dpi and font-adobe100dpi installed which included (amongst others) this font. Uninstalled those packages, and now all sites renders properly! Fontconfig is not deterministic, so it only happened on one system. Should have debugged this january when I set it up :) <efraim>I might need more dev boards, I'm stuck waiting on aarch64 and riscv64 builds :/ <ekaitz>efraim: too late, we had some money for more and it has never been reclaimed <efraim>My visionfive2 is sometimes more performant than my Hifive Unmatched, I bet it would be even faster with emmc, and it can be powered using my PoE splitter <efraim>mine only has 8GB, but I added like 12gb of swap <csantosb>This remembers me a 4th gen rpi at home ... need to do something about <efraim>mine is fairly simple; I flashed ubuntu on it, sudo apt install guix, and then did the dance to add it as an offload target <identity>both of my workstations, one laptop and one tower, have only 4GiB of RAM each… <efraim>I aimed for overkill and my desktop has 24 threads and 64gb of ram <csantosb>Do we have Guix system images for rpi somewhere ? <csantosb>Or a more or less documented workflow somewhere ? <efraim>looks like the image generation stuff is back to only generating ext4 filesystems :( <csantosb>This might be enough for a rpi ssd; I'm mostly concerned about booting <efraim>oh, sorry, I got distracted and forgot <efraim>I think we have something, since we have rpi bootloader stuff in guix, but I'm not sure how it works <ennoausberlin>csantosb: RPI 4 is a target in Guix already, but you will miss some drivers. <ennoausberlin>I know at least one working rpi 4 config, but there are non free drivers included, so I will not promote it here <csantosb>So people boot something else, then install guix ontop ? <user>Suppose i want to run a SearXNG instance on my guix system. As SearXNG is not packaged, would i have to go the packaing route? Sorry if this question is stupid but i am a little confused about how services work in guix system. The manual indeed looks as if it has all the answers but i just get lost in it <identity>user: yes, but you could use ‘oci-container-service-type’ instead <user>Oh this is interesting, thank you! <efraim>I have nss on nss-update failing to build for i686 <ekaitz>what kind of error is 'Error: could not load cache'? in a cmake? <ekaitz>i have an old package that just exploded with that <ekaitz>oh and it replaces the configure step with something else <ekaitz>oh great the cmake build system internals have been changed and now it runs cmake also in the build step <ekaitz>why do we break things like this? :( <ekaitz>oh in this case is the qt-build-system that now uses cmake <csantosb>Sometimes I think that complicating things is the shortest path to keep your job <efraim>we need to do something about the dependency tree for mesa. on riscv64 I need to build gcc-13, gcc-14, llvm-13, llvm-18 and llvm-for-mesa <andreas-e>efraim: Excellent analysis of the nss problem on i686! I did not know this, so learnt something new. When looking at the builder script on x86_64, it indeed contains "(unless #t ((substitute...". And on i686, this is "(unless #f ...". <efraim>one of these days I'm going to have to figure out how to find the builder script <andreas-e>And on the master branch, all this has disappeared. I am not sure whether this is actually related to if vs. when/unless, but rather to the different place where the (un-)gexping is placed. <andreas-e>The script is easy to find: "guix build ... --derivations". <andreas-e>You open the result in vim, and then /builder . <andreas-e>So I think it can be repaired, but would be super ugly... <andreas-e> (string-append "SOURCE_DIR=" (getcwd) "/nss\n"))))) <andreas-e>This handles the case in 64 bit and copies the "faulty" code in the form of "(unless #t ..." into the derivation. <andreas-e>The else path can now be anything to repair the 32 bit case. <andreas-e>It does not work, precisely because the level of gexping/ungexping is not the same. <efraim>the last commit adds nss-uri and also switches out the if's. I guess we could just revert it or drop it. or half of it <andreas-e>efraim: I have a solution that does not change the derivation on x86_64. But is is quite ugly... <efraim>yeah, wrapping the whole thing, and there are a couple of them <efraim>almost 16000 packages just on x86_64 <efraim>yeah, now would be the best time <andreas-e>We could either just repair the thing (even with rebase -i the commit itself) or let the next branch go to the front again. <andreas-e>I think repairing and rebasing would be good. This branch has been around for quite some time. <andreas-e>efraim: Message sent. Could you quickly give me your opinion? I am torn between applying the patch; it is ugly, but relatively clear, and I have added a lot of comments. Still there is a risk we will forget modifying things at the next update. So I am also okay with just dropping one level of parentheses and starting from scratch. <andreas-e>In any case, I would like to act now and not way potentially hours or a day for a reaction by the team. <andreas-e>In any case, I would like to act now and not way potentially hours or a day for a reaction by the team. <andreas-e>In any case, I would like to act now and not way potentially hours or a day for a reaction by the team. <andreas-e>Hm, in any case we need to wait for a branch evaluation, so the build farm will be idle for a few hours. I think I am in favour of (mostly) reverting the last commit, efraim, as you suggested. <efraim>You might want to fix the indentation of the lines and bring up the trailing closing parenthesis, but the derivations are unchanged on x86_64/aarch64/riscv64 <andreas-e>I kept the indentation so that the workaround can be dropped by simply deleting a few lines. <efraim>I'd either apply that patch or switch it back to the if's <andreas-e>Okay, I am reverting. The when/unless in the builder script are ugly; ungexp-slicing the full form is a feature, not a bug :) <andreas-e>I have force-pushed without testing whether nss actually builds anywhere... Here we have nothing to lose, and triggering the data service is the important thing to do. <podiki>package that includes a python script should have python as a regular input right? <podiki>as in the script is only runtime, not during build time, so it shouldn't capture native-input python <podiki>never realized lensfun (camera lens distortion database) has a script to grab newer data, as they don't frequently update the program itself <podiki>and turns out it didn't work on guix without some fiddling of the python part (needed python input to install module and to fix not making an egg) <podiki>long story short, got newer lens info in user directory, works with darktable so don't have 2 year old lensfun database anymore <podiki>hmm...though i guess a user may not realize the script is python and so won't work without python in the profile (env)...probably should wrap <luca>in terms of reproducability and dev and all that stuff, is it preferable for a project to have a package definiton only im guix.git, both guix.git and their own project (next to source), or just the source? <identity>luca: fine to keep both, you could even inherit from the guix.git package definition to avoid duplication for ‘description’ and similar fields; the approach of having both seems to be more common (mind the small sample size) 