IRC channel logs
2026-05-09.log
back to list of logs
<mwette>I'm now getting this a lot on my 1.5.0 machine I just set up several weeks ago: `guix build: error: renaming failed build tree: Permission denied'. The buidl directories in /tmp are indeed owned by guix-daemon, not me. Also getting, before that: `error (ignored): pivoting failed build tree: No such file or directory' Any ideas? Kinda scary to me. <mwette>^ in response to `guix build -K <anything>' <mwette>ah. journalctl says denied by apparmor <mwette>nevermind : I think this may not be guix related <apteryx>the script guix-install.sh on our site is from the master branch, correct? <apteryx>hm, I forgot, how is the initial root password supposed to be set for a 'guix deploy'ed machine, e.g. to hetzner? <apteryx>uh, password can be set to a sha-512-hashed initial password on a user-account object <csantosb>Hi Guix ! I'm thinking about the cuirass-bot, sometimes it builds thousands of packages for a given pr <csantosb>Say one pushes the pr to master, do these thousands packages need to be build again ? I hope they don't. <identity>i recall some discussion about that previously <identity>maybe look through guix-devel archives/Codeberg issues <Rutherther>csantosb: it's just not working right when it does that. Sometimes it does not have the base built yet and then that happens <csantosb>Intuitively, when I build a new package locally, then I push the change, I don't need a substitute to install it, as it is already present in my store <csantosb>I was hoping that cuirass and the build farm cooperate in a similar way <Rutherther>cuirass and the build farm? wdym by build farm then? <yelninei>Does anyone else think that some dependency trees are completely absurd? Like (transitively) depending on multiple llvm versions or e.g. ruby@2 still having 15k dependant packages when we have 3 newer versions? <yelninei>but because these are so deeply entrenched in the graph it is a lot of work to update that nobody is doing <yelninei>and it is a lot easer to just add a newer version and leave it up to someone else to do the hard work <csantosb>Rutherther: Sometimes it is hard to tell if cuirass and the build farm are the same beast or not <csantosb>yelninei: I agree; and this is why it is so important to pay attention to minimising package's inputs <csantosb>And the reason why some packages are so huge <yelninei>I completely understand the workflow: libxyz is outdated, my new package addition needs a newer libxyz so lets add a new libxyz to avoid rebuilding the world. <yelninei>then more and more things depend on libxyz (or my new package) and as a result it now becomes hard to update both libxyzs and untangle this <csantosb>And then someone else needs to disentangle it <futurile>morning all, hope you're having a nice weekend <yelninei>csantosb: Maybe as a first step it would be good to find out all packages where multiple versions are available (and are not for bootstrapping), force update the default to the latest one everywhere and try to reduce the usage of versioned package symbols where things already spread further. That would be a massive endeavour though <yelninei>especially with many parts of this not being managed by any team (ruby, ffmpeg, ...) <csantosb>I'd say first we need to impose some kind of policy on not doing that anymore, otherwise, this becomes and endless task <yelninei>but how to define "that"? Having e.g. ruby@2 available does not hurt anybody, it still having 15k dependendant packages while not being the default does <futurile>heh heh I'm currently trying to move Ruby upwards to 4 <futurile>there's a lot of out-of-date dependencies, but there are also some libraries that aren't moving, that ecosystem is a lot smaller than previously. So there seem to be some that are going to stay on 3.x compatibility <yelninei>futurile: I got to ruby from trying to find out what still uses openssl-1 <futurile>I'm still working through the various test libs, so haven't looked at what depends on 2.x yet - is there much? <yelninei>qt5 and ut8proc have a note to update "on the next rebuild cycle" that never arrived. ruby-hydra-minimal/pinned is used in tex.scm. There is also ruby-hamster but that is harmless (right now at least) <janneke>yelninei: i booted debian/hurd-amd64 on an x220! <janneke>and it isn't even using latest-greatest (git) of everyting; so i'm puzzled why our hurd doesn't find /dev/wd0 <untrusem>btw janneke from a thread in guix-devel i found that there are llm contributions in hurd <janneke>untrusem: misread that thread must have been <janneke>an LLM has been used to review code and point to possible problematic code fragments <janneke>not that i'm happy with that, but there's been no LLM code, please stop spreading lies! <yelninei>:O , i also have an x220 around that i am not using for anything. <yelninei>debian has lots of patches from git in debian/patches <janneke>yeah, terrible! the debian/patches mechanism is just much too convenient <janneke>yelninei: any specific package you're thinking of? <janneke>i've just locally upgraded rumpkernel to debian/0_20250111-6, which should include debian patches <janneke>however, debian uses: ii librump0 0~20250111-7 <untrusem>janneke: ohh i am glad then, my bad, it was prompted in guix-devel, I should have looked deep before reaching to a conclusion <janneke>just tried to ask on #hurd where the ~7 comes from <janneke>untrusem: np, but a rumour is started all so easily...i've also had to "fight" this on the fediverse <janneke>ACTION is puzzled why so many people would want to put GNU/Hurd down so badly <janneke>yelninei: hmm, hurd/acpi.static is no longer being built ideas? <janneke>we still have: --enable-static-progs=ext2fs,iso9660fs,rumpdisk,pci-arbiter,acpi <janneke>checking acpi/acpi_init.h usability... no <janneke>checking acpi/acpi_init.h presence... no <janneke>yelninei: /me has added acpica to hurd, without any changes or patches or anything...crossing fingers <janneke>the HOST=_LINUX looks indeed terrible <janneke>yelninei: our acpica package, even for linux, does not build any library or install .h files? <yelninei>janneke: debian has a patch to add acgnu.h and acgnuex.h platforms, a patch to add the makefile that builds the shared and static lib + headers <janneke>guess we'll need a libacpi package :) <guest-fnat>Ooops, I was briefly kicked out - I hope nobody got back to me in the meantime? <yelninei>janneke: I geuss we should also fix the ACPI_HOST of the acpica package? <janneke>yelninei: i'm adding `libacpi', that seems to be unrelated to acpica[-tools] <janneke>ACTION has no idea whatsoever if this could help with the 64-bit boot, but it's a difference with debian...so yeah <yelninei>the debian salsa mentions acpica.org in the copyright file, i guess it is some patches ontop of that / the debian fork? <janneke>hmm checking acpi/acpi_init.h usability... no <janneke>however, our acpica package doesn't include any header or library <janneke>ACTION hates this kind of obfuscation, man... <janneke>there's no acpi_init.h in our acpica source package <janneke>tusharhero-xmpp: please stop spreading rumors <tusharhero-xmpp>janneke, I am not spreading rumours. They seem to be linking specific comments. <bjc>‘guix pull’ working on a fresh childhurd feels good <bjc>just need to be able to ‘system reconfigure’ now… <janneke>tusharhero-xmpp: GNU must die, acconding to the interwebs, please dont't help <yelninei>janneke: To add more to the confusion the debian package of acpica is acpica-unix and also has lots of patches to make it work on hurd (and also kfreebsd?) <yelninei>i guess it is only in the debian hurd port repo and not in any "official" repo? <yelninei>i think that is was sam_ was trying to say in #hurd <janneke>tusharhero-xmpp: let's hope so; just saying; please, please, be very careful what you're doing, even if you're "just pointing to" something <janneke>tusharhero-xmpp: you're using ..."seems", and that's a big part of the problem; thanks! <tusharhero-xmpp>janneke, actually I am asking if it is actually true or not because I am not involved with Mach. They have already named it "AI-reviewed" in their list. <janneke>"when did you stop beating your wife?" <janneke>ACTION won't say anithing further on this <graywolf>What package do I need to install info `guix shell -C` to generate terminfo database? <Septimus>Perhaps this is a dumb question, but I am currently running guix pull after over a week without updating, does the most recent commit cover the issues with Copy Fail, or is there more that needs to be done for Guix System users? <untrusem>Septimus: which kernel are you using, The copy fail mitigation was implemented a few days ago and in the meantime, another Linux perk was found and it was fixed some hours ago. So yeah, you should update to the latest commit, but it depends on what kernel are we using. Because guix only have libre kernel. <Septimus>untrusem: as of right now, 6.18.22, just finished pulling the latest commit, about to reconfigure my system. <Septimus>gotcha, thank you for the info; this has been quite the bustling month <csantosb>Just discovered "Referencing Bug Reports" in the doc; unable to figure out how to make it work ??? <ieure>Does Guix have some equivalent to /usr/share/dict/words provided by Debian? Looks like that comes from the wordlist package, my older Debian box built it from http://wordlist.sourceforge.net/ -- I don't see any match for that in the Guix code. <ieure>csantosb, It's an Emacs package, it has its own infodocs, did you read those? <ieure>There are some variables you have to configure so it notices the text referencing the bug, and a URL template to drop a match from that into, to view it. <ieure>Forgejo is slightly worse than GitHub in this regard, both use #nnn to reference both bugs and PRs, but Forgejo uses a different URL for bugs vs. issues. GitHub doesn't (or, well, it didn't; maybe it changed. I quit using it.), so the same works for it. <ieure>You can match on PR #nnn / Bug #nnn, but it's fairly common to just use "#nnn" in both cases. <csantosb>According to `bug-reference-bug-regexp` in .dir-locals.el <ieure>csantosb, I'm confused, bug-reference mode is so you can turn a shorthand like "#1234" into a URL like https://bugs.gnu.org/1234. If you already have that URL, there is nothing for it to do. <ieure>I found the Guix .dir-locals.el, that is an unusual way to use bug-reference-mode. <ieure>csantosb, I see. I also see that's verbatim from the Guix .dir-locals.el. I'm not sure why it wouldn't work. Have you used re-builder before? I would use that to make sure the regexp for the GNU Debbugs URL actually matches the text. <csantosb>ieure: links are obsoleted; I just tried to check it before updating the url to codeberg. <ieure>It looks like Foregejo use the same sequence for issues and PRs, and will redirect to the PR if you load an issue URL with a PR number. <ieure>I love re-builder. I don't need to use it every day, but it's invaluable the times I do. <csantosb>What about guix/guix#xxx for issues ? This is the ref codeberg itself uses. <csantosb>Pr go as guix/guix!xxx instead, by the way <ieure>!nnn is the Gitlab style, I don't know any other forge that uses it. <ieure>I would match on either guix/guix#nnn or #nnn. The guix/guix is implied in the latter case. <ieure>Since this is a dir-local for Guix, the context of "this is the guix/guix repo" is implied. But you wouldn't want an explicit reference not to work. <ieure>I didn't phrase that well, "You'd also want an explicit guix/guix#nnn to work." <csantosb>I'm looking at any pr / issue page at codeberg.org; at the bottom right there is a "Reference" <ieure>Yes, they give an explicit reference, because they don't know the context you'll use it in. If you're looking at Guix source code and see "#1234", that means it's a guix/guix issue, because that's the repo it's used in. <csantosb>(by the way the problem was "\\/\\/" instead of "//\\") <ieure>Escaping in Emacs strings can certainly be unnecessarily difficult. <ieure>tusharhero-xmpp, I'm not sure if that works in a .dir-locals.el file. Those have more restrictive rules for evaluation, to avoid executing untrusted code. <ieure>In the general case, I agree, the `rx' macro is very nice. <tusharhero-xmpp>> tusharhero-xmpp, I'm not sure if that works in a .dir-locals.el file. Those have more restrictive rules for evaluation, to avoid executing untrusted code. <ieure>The user will be pestered any time a previously-approved .dir-locals.el file changes. <ieure>Which will be the case here regardless of rx usage. <csantosb>Here we go: "\\([guix\\/guix]*\\#\\)\\([0-9]+\\)". Beautiful, I know. <csantosb>rx macro would probably make it in .dir-local.el using "eval" <ieure>csantosb, I think it needs to be [guix\\/guix]? (zero or one matches) not [guix\\/guix]* (0 or n matches). Does that match guix/guix/guix/guix/guix/guix#1234 ? <ieure>csantosb, Yes, I just tried. <csantosb>I get "in buffer "electronics.scm" doesn’t conform to the contract specified by its docstring" in any case. Wow. <ieure>csantosb, Yeah, this needs additional tweaking, the charset needs to be a non-matching group instead. `[guix\\/guix]' matches any combination of g-u-i-x-/ letters, ex. it also matches "giux/xuig#1234" <csantosb>"The subexpression 1 should define the region of the bug-reference overlay and cover all other subexpressions up to subexpression 10" <ieure>csantosb, "\\b\\(?:guix/guix\\)?#\\([0-9]+\\)\\b" <ieure>(?: ) is the shy grouping construct, it will match, but not assign a number to a group. <ieure>I think this is still not right, but closer. <ieure>csantosb, You can also build the regexp with rx, then paste its output into the .dir-locals.el. <ieure>Classic "Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems." stuff here, lol. <ieure>Anyhow, going to get breakfast with my wife. Later! <graywolf>tusharhero-xmpp: There is guile-irregex package <csantosb>tusharhero-xmpp, ieure, see #844, using the rx macro <tusharhero-xmpp>I think this is something that would be very handy if it was possible to just use rx directly <csantosb>By the way, no need to call the remote anything in particular (I call it 'codeber'), as claims the footnote in "Referencing Bug Reports" <mitchell>Hello Guix, I am trying to deploy to a system which cannot connect to the internet. Deployment works well but after a while I am accumulating dozens of system generations which I cannot delete because it wants to build stuff and cannot access the internet. What can I do? <mitchell>Is there a method of either manually deleting generations which will allow guix gc to run or to include the things guix system delete-generations needs? <mitchell>oh that did work! what is the difference between that and guix system delete-generations? <untrusem>It is not deleting system generations, I think. It is deleting the profile generations. <untrusem>mitchell: And I think you should send a mail to help-guix mailing list <mitchell>It did delete the system generations though. guix system list-generations shows only one now. <ieure>That shouldn't be possible, `sudo guix system delete-generations' should be the only way a system generation can be deleted. `guix gc -d' only deletes guix generations (what get created when you `guix pull'). <ieure>This is just an ordering issue, I think. If you delete the guix generations before profile generations, the profile deletion may need to download some of the stuff just deleted. <ieure>I always delete system and home generations, then guix generations, then gc. <ieure>Deleting system generations will still sometime download things, though. <mitchell>Well this system has never had generations created by users. It was provisioned offline and only ever guix deployed to. <untrusem>I think deleting things shouldn't download anything, it makes guix a bad candidate for airgapped system <yelninei>deleting system generations needs to rebuild the grub menu <mitchell>guix system delete-generations wants to download things <untrusem>just wishful thinking, i know it is not possible with the architecture guix has <ieure>mitchell, Yes, it can download things like an updated bootloader. <mitchell>well guix gc -d seems to have done the trick. air-gapping is indeed possible <ieure>Yeeessss, but don't confuse "it worked in this instance" for "it will work this way every time." <untrusem>you could do one thing, `guix --archive <drv> > some.nar` and import it on the airgapped system, assuming you can share stuff to it wired <ieure>I believe I read about someone using an airgapped Guix system in a remote area, they had a workflow involving using `guix copy' to put new binaries on a thumb drive and copying them to the destination system. <ieure>Yes, something similar to that. <graywolf>I wonder if you can just somehow "install" the packages necessary for rebuild of the grub many into your operating-system, so that once it deploys, it can rebuild the menu without downloading anything new <mitchell>i'm not sure how to collect those roots ahead of time though <ieure>untrusem, I saw, I'm doing it today. <ieure>graywolf, Any method of getting it into the store should work, but yeah, I'm not sure how to determine it in advance. <meatoid>hi guix, does anyone here use the greetd wlgreet service? I'm trying to get it working in a VM but it just boots into an empty terminal with no prompt <meatoid>i guess that helps for tuigreet, but i'm looking for a way for users to log in via remote desktop and i was thinking wayvnc could be coupled to the compositor running wlgreet somehow <meatoid>is there a better way to achieve this? <meatoid>with wayland i mean, i know there is xvnc <Elwood_Soup>Hello! I'm trying to cross-compile a uboot image for an ARM board on my x86 install (Guix on Debian). I'm running into the following error, which I suspect might just be because I'm not calling the right command for cross-compilation. <Elwood_Soup>objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-2.39.drv-0/build/libc_pic.os' <Elwood_Soup>guix system image --target=aarch64-linux-gnu -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "nanopc-t4-rk3399")' <ieure>Elwood_Soup, The command looks right to me. <Elwood_Soup>This was the related thread I found, which is why I thought there was maybe some way I wasn't properly formatting for cross-compilation. <ieure>Elwood_Soup, The error you're getting means that libc_pic.os is for a different architecture than the expected one, though I don't know which architecture that is or which one is expected. <Elwood_Soup>I'm compiling on x86_64 and targetting the NanoPC T4 which is an ARM64 board <Elwood_Soup>Oh I see, yeah, I'm not sure which direction the mismatch is in <ieure>Elwood_Soup, You might want to open an issue or post on the help-guix mailing list. <yelninei>janneke: Exciting, Does networking work? <janneke>ifconfig: no devices found (or something) <janneke>ACTION hasn't looked into the possible rumpNET curses <janneke>possibly jab has a recipe or otherwise some insights on this <yelninei>not sure what the status was on the dhcp but someone was working on porting dhcpcd <yelninei>in other news I think the Hurd commencement.scm builds on core-packages-team again after the input label removal. This is pre libc update and I expect more issues with that <janneke>right; for now i'm happy with static-networking, that's what i used for the x60 <janneke>oh, nice -- wow that really was a train-wreck... <yelninei>janneke: commencement.scm does some weird things with labels, i.e. %bootstrap-coreutils&co is in the inputs twice once with a bash label and once with coreutils label. At some point the "bash" label gets replaced, but if you do that naively you dont have have coreutils,tar, etc anymore <yelninei>the one benefit of labels was that i.e. to address the kernel headers by a generic label but have different packages provide them on linux/hurd. Without labels finding the headers leaks the current system into the builder by searching for include/linux or include/mach