IRC channel logs
2026-07-24.log
back to list of logs
<vagrantc>just some rough transitions here lately... *sigh* <ieure>vagrantc, That's on the go-team branch, not master. The Guix package for containerd-cgroups is four years and two major versions out of date. Looks like github.com/opencontainers/runtime-spec/specs-go was updated to a newer version, but containerd-cgroups was not, which is the source of the breakage. <vagrantc>ieure: it was merged to master and fails there too! <ieure>vagrantc, Ah, well. Version bump should fix it. Though it will mean two major versions, which likely break other stuff that needs it, so... <vagrantc>go-github-com-containerd-cgroups 1.1.0 out gnu/packages/golang-xyz.scm:6886:2 <vagrantc>go-github-com-containerd-cgroups-v3 3.1.3 out gnu/packages/golang-xyz.scm:6957:2 <vagrantc>guess i could try to find the chain of deps and bump them individually <vagrantc>hrm. cannot even figure out what is pulling it in... <vagrantc>go-gvisor-dev-gvisor seems to build fine with go-github-com-containerd-cgroups-v3 <vagrantc>this yak looks to have a shorter coat, at least, if not done <vagrantc>at least go stuff seems to generally build pretty fast... <vagrantc>hrm. i submitted a pull request to fix go-gvisor-dev-gvisor ... but maybe i should just push it, since it fails to build entirely and blocks other packages? <vagrantc>hopefully the go team will respond swiftly to the PR and it will be a non-issue tomorrow :) <vagrantc>at least i know a local workaround for now... <cnx>i think bordeaux is down for maintenance, hence topic branches rely on ci for evaluation (which indeed means the lack of substitute on non-amd64 archs) <trev>There are no days when you're forever online like me 🥹 <qzdl>been wondering about the iso / tarball install path following substitute CVE; combined with rootless daemon unable to build some packages like coreutils from source, some are likely stranded <qzdl>probably worth a minor version release (1.5.1 @ >=897832f374dcdc9eeaf19d01e70b9a92fccfc68c) right? <Rutherther>unfortunately I am afraid you cannot really do a 'minor' version release. Also, the release numbering doesn't really follow any standards <qzdl>fair enough, but surely we can just cut a new tarball for guix-binary-X.Y whenever? or is there some provenance requirement <Rutherther>due to how guix pull works you cannot just put one commit on top of the currently released version, you can only bump to latest <Rutherther>I am not really sure why it lists only x86_64 on the guix.gnu.org page though <Rutherther>yeah, I mean this is quite recent compared to when Binary installation has been written <Rutherther>and it's a question if you even want to point people to this page, since these are completely untested <qzdl>Rutherther: well, thanks for the info! <gabber>on a machine with nproc returning 24 `guix repl` (parallel-job-count) returns 1. am i doing it wrong? <gabber>this is executed in a Guile script that loads (guix build utils), not a package/gexp environment <abbe>Is there a guix service that would create files in /etc, instead of symlinks ? <abbe>context: i want to create /etc/ssh/ssh_config but /etc/ssh already exists and therefore can't be symlinked to nix store <abbe>if I use etc-service-type <identity>first of all, it is just ‹the store›, but also definitely not the «nix» store, this is Guix <identity>second, how are trying to create /etc/ssh/ssh_config? <abbe>it's a plain-file object <identity>i need more information than that. the configuration file, ideally <abbe>yes, it' configuration file <abbe>I am programmatically generating its contents <identity>please, show me how you are trying to create /etc/ssh/ssh_config <abbe>(simple-service 'etc-ssh-config etc-service-type `(("ssh/ssh_config" ,(plain-file "ssh_config" (ssh-configuration-function))))) <abbe>this is my current service instance which failed to work because /etc/ssh already exists as a directory, and therefore can't be symlinked by etc-service's activation script <abbe>#<&compound-exception components: (#<&external-error> #<&origin origin: "symlink"> #<&message message: "~A: ~S"> #<&irritants irritants: ("File exists" "/etc/ssh")> #<&exception-with-kind-and-args kind: system-error args: ("symlink" "~A: ~S" ("File exists" "/etc/ssh") (17))>)> <dthompson>I'm getting a flood of "incompatible bytecode version" warnings in my guix dev env and I just don't understand why. I've done plenty of guile development to know the usual suspects but it's something different. <dthompson>'./pre-inst-env guix' is somehow causing guix to look at .go files in /run/current-system which is baffling to me <dthompson>it shouldn't be looking there! my working directory is on the front of the load path and the bytecode files are in there! <nick68> Hello guys, i have a question, i can send normally here? <identity>yes, this is a channel for (among other things) asking questions about Guix <yelninei>dthompson: agianst which guile is the guile binary in the guix sourcedir linked? Try rebuilding that <dthompson>yelninei: wow I did not know that there was a copy of the guile binary in here... <yelninei>gabber: you probably want '(current-processor-count)', (parallel-job-count) uses NIX_BUILD_CORES environment variable that gets set by the daemon <yelninei>dthompson: It is a just a small wrapepr around scm_shell (see guile-launcher.c) and sets up utf-8 locale and some things with load paths <dthompson>yelninei: yeah I just did a blame on Makefile.am and see that this was added in 2020. totally missed that! <nick68>I use QEMU for virtualization, but I've run into a couple of limitations. For instance, I cannot use -audiodev pipewire, and Venus doesn't work because virgl lacks the required feature flags. Would it be better to submit a pull request upstream to add them, or is it better to create a package that extends it, or add a modified version to a personal <irc_mirror_zulip>@**Sergio Pastor Pérez**: Oh, right, well, when we made this thread we where not thinking of having multiple channels so we just named IRC. But Since it's mirroring '#guix' we should probably just name it that. <irc_mirror_zulip>@**Sergio Pastor Pérez**: So, I will shut this down for now to not bother. <irc_mirror_zulip>At some point we will instantiate a service in the infrastructure so the but runs continuously. <mochie>curious where that bridge was from <jlicht>fwiw, and probably sounding a lot more cranky than I actually am, I do not like these kinds of bots/bridges as they usually make the IRC experience quite shoddy <mochie>is this a very recent thing or? i didn't find anything about zulip on the contact page <pastor>Well, I don't think it was so bad, no? The name may be a bit long but it will make for a more inclussive community <cnx>i don't think everything must be bridged together <jlicht>but that it's possible with (only FOSS?) tooling is still quite cool :-)! <pastor>mochie: It's not official, we are just testing the software. We plan to make a demo so people can try how the experience is and whether they like it. <sham1>IMO as long as it's easy enough to get to the other comms channel if needed, it's probably not necessary to have bridges everywhere <cnx>different protocols/platforms may exist independently, and accepting their differences is another kind of inclusivity <pastor>Yes, all FOSS, we are finishing the PR in upstream Guix <sham1>Although something like XMPP or Matrix does make bridging a lot nicer than IRC fwiw <jlicht>thanks for working on this pastor, sorry to seem such a grump o7 <Guest28>nick68: those sound like useful things to have in the main qemu package <pastor>It's fine, I didn't make this for myself, its really for easing onboarding newcomers <mochie>i do generally prefer something other than irc for communities so chat history is easier to deal with and stuff like markdown is more of an expectation to be supported. also talking on my phone sometimes <nick68>Guest28 i try open a pull requets, tks! <mochie>i guess a downside is emacs support is a bit worse with the other platforms? the matrix client lacked a few features last i checked, but i haven't research zulip <pastor>I don't have a bouncer and I have to go now, so I won't be able to read any questions you may have. You can contact me through mail if you need, in anycase, things will be announced through the mailing list. Bye! <mochie>i haven't gotten into emacs myself yet because the font rendering with fractional scaling on pgtk isn't perfect <mochie>trev: what would the alternative be for someone on hyprland? xwayland has some jank with the clipboard in most applications, and i quite frequently copy and paste code snippets <jlicht>I use pgtk; what should I do to never unsee what's wrong with it? <trev>mochie: just xwayland and the regular emacs-next <mochie>jlicht: my issue only shows up when using wayland fractional scaling. i found out by feeling like something looked off, and then comparing the font rendering with firefox <trev>jlicht: never get a 4k monitor and/or use fractional scaling <identity>yeah nah last time i used Emacs under XWayland it was trash <trev>The issues may not occur on gnome. I haven't checked in a long time <mochie>i do also have a 4k monitor too now.. i heard bad things about latency from cpu rendering <jlicht>traded in my (broken) 4k for a 5kx1440, so crisis averted I guess :-) <trev>identity: probably your x settings or fontconfig <identity>trev: oh, i was certainly longing for touching xorg.conf again! <mochie>i didn't even know xwayland was affected by those types of files <mochie>identity: oh hey i haven't seen that one before <sham1>Well xwayland is still an X server <mochie>i'm not very knowledgeable on xorg/x11 stuff as my first proper experiences with linux were hyprland and plasma 6 <abbe>repeat of my previous message: Is there a guix service that would create files in /etc, instead of symlinks ? <ieure>abbe, Symlinking stuff from the store is the normal way to do this, what about that doesn't work for your usecase? <gabber>huh, did not expect to get mentioned there by name <trev>you're a big deal around here! <abbe>ieure: i was doing this: (simple-service 'etc-ssh-config etc-service-type `(("ssh/ssh_config" ,(plain-file "ssh_config" (ssh-configuration-function))))) <abbe>ieure: and i get: #<&compound-exception components: (#<&external-error> #<&origin origin: "symlink"> #<&message message: "~A: ~S"> #<&irritants irritants: ("File exists" "/etc/ssh")> #<&exception-with-kind-and-args kind: system-error args: ("symlink" "~A: ~S" ("File exists" "/etc/ssh") (17))>)> <mochie>trev: i hope there have been made puns with "twig" at some point on or about the blog <trev>mochie: heh...some people have joked about it already <ieure>abbe, Your problem isn't that you're using a symlink, it's that you're interfering with openssh-service-type. <ieure>abbe, I don't see any facility for configuring global SSH client behavior in openssh-configuration, your best option is to send a patch adding that. <yelninei>ssh X11 forwarding now finally works for a childhurd (after a bit of setup for sshd). If someone has a hint why xterm fails with ENOTTY let me know <yelninei>i think I found the xterm issue. Yet another glibc patch to disable some ioctls that dont work <abbe>ieure: the directory /etc/ssh only has regular files (host keys) created by sshd service. <abbe>and guix wants to create <system-store>/etc/ssh as a symlink, instead of recursively symlinking the files <abbe>sorry */etc/ssh as a symlink to <system-store>/etc/ssh <ieure>abbe, Yes, this is a more detailed way of saying what I already did, which is that your two services are interfering with each other. <abbe>i'll try to fix this by implementing a separate service, e.g. my-etc-service which will recurse for symlinking, instead of symlinking directories, so resultant symlink farm can be merged into what's in the /etc filesystem <abbe>and if that works, then i'll apply it to etc-service's activation function and submit a patch to guix <abbe>thanks for the response, ieure <vagrantc>ok, day 2 of compiling rust on aarch64-linux ... this is not some tiny dev board, it's got 32GB of ram and 8 cores (4 of which are moderately fast) ... can build a linux-libre kernel in 20-45 minutes <gabber>yelninei: thanks! that's probably it! <Rutherther>vagrantc: but I expect it's progressing over the bootstrap versions? Or are you building one version for two days? <vagrantc>Rutherther: yeah, all the bootstrap versions <vagrantc>for the release, aarch64-linux was considered a tier1 architecture or whatever ... but it sure doesn't feel like it after the release :) <gabber>lol. guess i missed the point here. cool you can compile linux in half an hour. that's a rather fast board right there <vagrantc>when a world rebuild can be merged without any substitutes... <vagrantc>anyone know how to unmark a pull request as manually merged" <vagrantc>for some reason the kernel updates are triggering a rebuild of librewolf (currently builds on master) and codex (does not build on master, so *shrug*) ... i presume because i finally remembered to update the default kernel version from 7.0 to 7.1? <vagrantc>ieure: any chance you could try building librewolf against the kernel-updates branch? i am lacking a bit on resources at the moment... <vagrantc>i've been trying to push this for days, but then the world rebuild happened <ieure>vagrantc, Sigh, just wasted like 20m compiling the wrong branch. <gabber>guix shell inetutils --pure -- ping codeberg.org <gabber>Throws: "ping: Lacking privilege for icmp socket." <gabber>but `ping codeberg.org` of course works fine in my home profile <Rutherther>it doesn't, it uses the ping with privileges from /run/privileged/bin, it's not from your home profile <gabber>any idea how i can test whether i can reach codeberg.org from a Guile script? <vagrantc>ieure: huh. yeah, i see substitutes for x86_64-linux librewolf now ... aarch64-linux, of course ... still buuilding rust locally <vagrantc>ieure: it came up as a build failure on the ci bot in one of the tests ... but ... seems fine (which I suspected all along, but who knows) <ieure>vagrantc, Alright, happy to help if you need other stuff from me. <jresich>does anyone have a working non-GDM greeter configuration for a niri (or other wayland) setup <jresich>I have tried sddm (only works with X11) and greetd (niri cannot boot from the tty it gives and the wlgreet config from the manual crashes) <jresich>also, GDM hasn't been working recently either, it fails with "authentication error" and then the password box breaks <jresich>*also the x11 sddm session can't seem to locate niri's session .desktop file, won't let me log in <ieure>jresich, I've run into that as well, it seems to happen when my home and system generations are out of sync. <ieure>I think it happens in other situations also. <jresich>ieure my home configuration is deployed using the system home service <ieure>jresich, :/ Did you reboot after? I have also encountered it after reconfigure, if I don't reboot. <ieure>(Not excusing any of this, it should not break like that, ever.) <jresich>i do have one very old 'guix home' generation from 2024 that i don't know how to delete <jresich>ieure i reboot after every reconfigure