IRC channel logs
2025-10-28.log
back to list of logs
<apteryx>old: the reason I started wanting to use munmap myself in some parts of the libraries, is because it was breaking some tests in tests/gremlin.scm, where an ELF file was mmaped MAP_SHARED, modified in place, then running (gc) was not enough to clear it, and testing that the ELF could still exec failed with a busy error because of the still active mmap <apteryx>so I took the precaution that everytime mmap was used with MAP_SHARED, I'd ensure the scope where it's used is finished (in a let for example), then call munmap to drop the map. <apteryx>that fixed that particular issue, but introduces double frees in the guardian pump <apteryx>maybe I can try adjusting the test instead of messing around with munmap <apteryx>but I'm a bit weary this could byte us in an actual situation (MAP_SHARED lock kept active in places it could be a problem, such as trying to write to the file via other ways after a RUNPATH was adjusted or similar) <rgarcia>can I search guix packages by file? say: what package contains png.h? <vhns>Does anyone have any guidance on getting elogind to work on a headless server? As of now it keeps on restarting, dies, and in turn breaks logging in. <jab>heyo, what are ya'lls favorite guix packaged games? <jab>also is there an easy way to disable guix computers from going to sleep? <jab>I'm noticing that I can't ssh into my desktop when it falls asleep/hibernates. <jab>looks like I can disable sleeping inside KDE <futurile>jab: you know about the games channel, it's separate from guix <jab>I actually forgot about that. I'll google it. <jab>to be clear I am looking for free software games. :) <sham1>Xonotic is free software. Quite fun if you like FPSes <jab>yeah, I've heard that one's popular...probably minetest too. <jab>or whatever the open source minecraft game is called. <apteryx>ACTION pulls its head out of the rabbit hole to take a breathe of fresh air <jab>hey #guix, I want to get my friend's talos II (power 9) machine set up so that guix can start using it as a build farm within a week! As far as I know, guix system does not run on power9, but guix does. <jab>Does guix any any current power9 build machines running on real hard ware? Are they using debian + guix ? <apteryx>jab: hello! Guix has access to some powerpc64el VM for building packages <apteryx>there's no installer built for powerpc64el, though you could bootstrap installing Guix on top of a foreign distro and build the image there. <jonsger>although if I look at the metrics of our CI https://ci.guix.gnu.org/metrics Ii don't think raw build power of those Power9 machines is the bottle neck. They seems to look pretty idling. I guess this is a problem of scheduling (Cuirass) as well as failing dependencies on powerpc64le, which lead to many packages which can't get build... <jlicht>apteryx: did you remove a comment on the unshare issue? I'm being gaslit by codeberg notifications :D <jab>apteryx: yeah, I really want to use guix system on power 9. Or OpenBSD. <apteryx>jlicht: haha, sorry it was meant for the associated PR, not the issue. <jlicht>which PR would that be? I'm not subscribed to it, I think <vhns>Guix System running on a Talos would be pretty cool <apteryx>I think some people are or were doing it <ieure>Yes, I believe there are a few people with that setup. <apteryx>it's very cool that the board is custom made by one looks like a one or at most a few persons company? That's nuts. <vhns>I think the coolest things is it being a different architecture and fully libre, iirc <apteryx>yes. Though different architecture can also mean fixing packaging bugs that nobody else sees, if it's not popular enough. <jab>apteryx: who is doing it? <jab>I thought guix system wouldn't run on power9 <apteryx>I haven't tried, but assuming it can boot with grub-pc or grub-efi I don't see why it wouldn't work. <apteryx>There's already a binary Guix installer for it. Perhaps GNOME wouldn't build if there's some breakage in the graph, but something small to get started should, I'd expect? To be verified of course :-). <apteryx>Could be bootstrapped from a running Debian or other foreign distro, using 'guix system init your-config.scm'. <apteryx>Or you could produce a system installation image from that system too and try booting from it. <jab>I'll try generating a bootable installation image for power9. See what happens. <cbaines>I've got a Talos II connected to the bordeaux build farm (polaris), but it's rarely on at the moment <cbaines>It's also running Debian rather than Guix System, the main problem being building grub <jab>cbaines: would you recommend running Debian + guix then ? <jab>I'm going to say yes...otherwise you would use guix system. <cbaines>It works for me, although I'd like to get Guix System working at some point <jab>cbaines: can you send me your server config.scm ? <cbaines>Now we're on Codeberg, we should have labels for architectures <cbaines>jab, I don't have a system config for the Talos II system, since I'm running Debian <jab>this is sooo trippy installing debian on the Talos via the com port. <jab>It's soo cool seeing a com port output graphics! <ekaitz>jab: are you the person who sent an email to the companies listed in "commercial support"? <jab>my friend and I also want to potentially hire ya'll to get guix system working on power9. :) <ekaitz>jab: i have to answer that mail, but I might be delayed <jab>whenever you get a chance. :) <yelninei>I currently have an uncommitted change in CODEOWNERS, is this expected? <ieure>yelninei, Depends on what you were doing, I guess? <yelninei>ieure: Ran make after rebasing my branch and the order of packages/oneapi.scm is different in the newly build codeowners <ieure>yelninei, I don't understand what you're saying at all. Did your rebase stop because of a conflict with upstream? <yelninei>then I wanted to switch branches but git complained because of the uncommited changes <yelninei>for me the file is added in alphabetical order for the hpc team and not at the end <ieure>yelninei, I'm not sure. I'd just discard the changes and switch. <yelninei>yeah, but the nondetermism is probably not great <futurile>yelninei: what is the change in codeowners? <futurile>yelninei: I've just got something similar, rebuilding guix and for some reason gnu/packages/oneapi\.scm shows as having been moved <yelninei>futurile: Order of files for the hpc team , for me oneapi.scm is the second file and not last. Position 2 matches the position in the team scope <yelninei>could it be a locale thing or maybe just a mistake? <cluelessguixer>Is oci-service-type an alternative to using docker/podman or just a Guix way to use them? <futurile>I can see `make` doing: ./etc/teams.scm codeowners > "CODEOWNERS.tmp" and then that file is moving oneapi.scm around <futurile>cluelessguixer: a way to use docker/podman as a Guix service, so you configure stuff through Guix AFAIK <ieure>cluelessguixer, Guix supports directly managing containers with oci-service-type, as well as managing Docker and/or Podman daemons and letting you manage things with those. <cluelessguixer>Neat. I'll see if I can't get frigate up and running through that service after dinner. <yelninei>is there a way i can get how long a (offloaded) build has been running? <Guest92> hi, i'm interested in the distro, but between non-updated packages and the fundraising campaign, i'm wondering how healthy the project is <Guest92>i'm not an user, but how would the people here judge the current health of Guix? <ieure>Guest92, Packages are updated every single day. <Guest92>i've seen some packages that are behind compared to other distros, that's what i mean <ieure>Every distro has packages behind vs. other distros, Guix is not unique here. <futurile>Guest92: it will partly depend on your expectations, Guix is done by a much smaller team than something like Fedora or Nix. It's also easier to get involved so package your own things, or get involved improving Guix <Guest92>i def wouldn't mind getting involved <ieure>I'm a committer, I think the health is find and improving vs. where it was 1-2 years ago. We're working on a release, moved to Codeberg, have the consensus document system. <Guest92>i had heard about codeberg. nice to hear things are moving <futurile>Guest92: you can also fall back to stuff like Flatpak (or even Nix) if there are things Guix doesn't have <sham1>Nix actually works wonders in Guix, because of course that ecosystem has a lot more stuff on it, which you can of course use, but then you also get all the Guix stuff which is usually better documented and such. Good things on both sides <ieure>Hmmm, is there anything to clean up /var/cache/guix periodically? Was looking at my cuirass/offload/publish box and noticed it was really low on disk, even after GC'ing. Turns out there's 290gb of stuff in /var/cache/guix/publish/ <ieure>Manually did this with `find /var/cache/guix/publish -type f -atime +90 -print0 | xargs -0 rm', but would love something automated for this, so I don't have to keep doing it by hand. <FuncProgLinux>sham1: I haven't used nix a lot in guix, I thing nix-lang is... a little tiny bit ugly but the flakes thing has helped me to deliver newer perl scripts at work :) <lee-thomp>What's the modern convention for `#:install-plan'? I can understand a quoted list of lists, but I'm also seeing gexp quasiquoted lists or doubly quoted lists, what's up with this? e.g. compare `book-sicp' `book-faif' and `bash-unit' <FuncProgLinux>The --emulate-fhs shell opt has been a lifesaver with appimages. <FuncProgLinux>lee-thomp: Some packages use the "old" style but that's not necessarily bad. I would recommend you to go with the new gexp style :) <FuncProgLinux>I use that for some icon themes: #~'(("usr/share/icons" "share/icons")). While I don't really get the logic behind the #~' (was it a quote equiv?) it does make builds look more consistent. And in some cases gexps reduce the amount of code you need to produce a package definition <vhns>I think I'll just reinstall this box <ieure>vhns, FYI, I filed that issue and it hasn't been happening to me for months. <jab>well guix is taking a long time to root@debian:# guix pull <FuncProgLinux>I tried running (setenv) inside the manifest.scm file but guix refuses to acknowledge the order <crazazy>heyo, strange question, but are there versions of guix with less git history? `guix pull` is taking very long <ieure>crazazy, No. I believe there's been some work on using shallow clones, but if you're pulling, you have to fetch all the commits from your current HEAD to the new one. No way around that. <crazazy>the long part is the indexing part it seems <ieure>crazazy, libgit2 has some pretty horrendous performance issues, it's likely that. <csantosb>Hum. I installed Guix on top of Alma a couple of days ago, `guix pull` took something like a few minutes, no more <crazazy>might be my puter, its a thinkpad s540 from like 2014 <csantosb>Or bandwidth from Codeberg side, it oscillates quite a few <ieure>Isn't indexing a local operation, CPU-bound? <cluelessguixer>Am I on the right track with this OCI config snippet? https://bpa.st/NVCQ For Jellyfin I also need something like "- type: bind" under volumes with source, target, and read only options. Should I have this simple-service in home or system config file? I'll have to set up Podman too I guess. Excuse the weird formatting btw, not sure what happened... <alanz>I am using the new rust workflow to import a project. One of the Cargo.toml entries is `paths = { git = "https://github.com/rust-lang/rust-analyzer", rev = "2025-03-04" }`, and it generates `(define rust-paths-0.0.0.02862f5 ..` in the file. But the actual build process does not find it. And it generates a TODO comment in the generated guile. Is there some way to use a subcrate like that, given I can't change the upstream? <ieure>cluelessguixer, Seems more or less right. Far as I know, OCI containers are system services only, not home services. Why do you think you need podman? <cluelessguixer>ieure: Well, if I don't need Podman then all the better I guess. <Rutherther>you need either podman or docker, docker being the default chosen as runtime <yvesbode>Hello everyone, hope you are having a great day. I'm trying to understand the `~/.guix-profile/share/icons` directory here, specifically to install a cursor theme I've downloaded from the internet. So conventional Linux wisdom tells you that a cursor theme can be installed on the `~/.local/share/icons` directory and enabled via `~/.Xresources` or <yvesbode>the GTK3 configuration located in `~/.config/gtk-3.0/settings.ini`. I have noticed Guix ships a package called `xcursor-themes` containing three themes (redglass, whiteglass and handhelds). These themes endup on the `~/.guix-profile/share/icons` directory as symlinks to the GNU store and I can enable them just fine using the usual configuration <yvesbode>files and procedures. However, if I copy those same theme files into `~/.local/share/icons` and remove the `xcursor-themes` package I can't seem to be able to enable them anymore. Similarly, I can't enable cursor themes downloaded from the internet and placed into that same directory. I tried placing my downloaded themes into the Guix Profile <yvesbode>directory however that is read-only of course. Am I correct in assuming that Guix overrides the `~/.local/share/icons` convention and if so, would I have to package my downloaded themes as Guix packages so they end up on the profile directory? Sorry for the long message, any help appreciated :) <Rutherther>themes can be installed in any of the directories that are in any of the directories in XDG_DATA_DIRS <Rutherther>yes, that directory is read only and the way you write to it is by adding a package to your profile that provides the files you want, if you have a specific files you can use a package with copy-build-system to just copy them and install that package <yvesbode>I see, thank you! Maybe the themes I'm downloading from the internet are bad, I'll try to look into it. <Rutherther>it might be a ton of issues, really, themes aren't so easy. You also should take into account for example that they can sometimes apply properly only when you restart applications or even relog. Also not all apps are gtk3 apps, ie. gtk4 will use configuration from dconf, so what you put to ~/.config/gtk-3.0/settings.ini has no effect for them <Rutherther>cursors are the worst I would say. For those I usually resort to setting XCURSOR_THEME env var even though I don't prefer using GTK_THEME for regular themes <Rutherther>also I realized I made a mistake in my earlier message, for cursor themes it's XCURSOR_PATH, not XDG_DATA_DIRS <yvesbode>Interesting!! I think this might just be it. My XCURSOR_PATH has: /run/current-system/profile/share/icons:/home/bode/.icons:/home/bode/.guix-profile/share/icons:/run/current-system/profile/share/icons <yvesbode>only the "legacy" .icons directory is included <yvesbode>and the guix-profile that was working with the themes from the package I installed <yvesbode>how do you configure your XCURSOR_THEME env var? <yvesbode>interesting, I'll check that out sometime in the future as learning about and configuring guix home is earmarked as the next thing I'd like to do on guix <yvesbode>Rutherther managed to make it work now, by placing it into ~/.icons. Thank you for the info!