IRC channel logs
2026-04-29.log
back to list of logs
<ieure>noxi, You can include newlines in the replacement, but I'm not sure if you can match on newlines. <ieure>A patch or a snippet might be a better tool if you need that. <noxi>How do you make a snippet that matches on many lines? <ieure>Mm, maybe a snippet is not a good approach. <ieure>What are you replacing / replacing it with? <noxi>I'm trying to unvendor a dependency from a project, so I'm replacing a list of dependencies with a single one <gabber`>noxi: if it makes the software better, maybe upstream is interested in incorporating that change <gabber`>could be worth suggesting a PR or something <noxi>No, I think I understand why they vendored it in the first place, but it's a reason that's not relevant for Guix specifically <gabber`>dang. git.sr.ht is down and my personal channel is hosted there. has anyone ever though of adding multiple remotes to channels? <noxi>> dang. git.sr.ht is down and my personal channel is hosted there. has anyone ever though of adding multiple remotes to channels? <noxi>yeah, it's pretty easy with magit <gabber`>i mean in guix channels as in a channnels.scm file <noxi>how is one supposed to provide the correct path for a patch in a recipe that isn't in the main guix? <noxi>it seems search-patches is really only tuned for guix <ieure>noxi, You're correct that it doesn't work the same in the guix repo as outside it, I don't really understand why that is, it's tremendously frustrating. <ieure>It does work, just not the same. <ieure>noxi, The patches field of the origin record of the package which that one inherits from. <ieure>noxi, That's a package variant, it takes an xorg-server package and adds a patch to it. <noxi>i thought it was something special <ieure>No, it's the accessor for the record field. <noxi>It is tremendously frustrating <noxi>I'm trying to use Guix as a dev shell with guix.scm and a .guix <dckc>guix wants to rebuild emacs. ouch. <ieure>dckc, Yeah, just noticed a bunch of that stuff rebuilding. <dckc>any idea what triggered it? i.e. which dependency changed recently? <ieure>Nope, I looked at the log but didn't see anything obvious. <dckc>I'm still struggling to figure out norms for keeping up to date. today I got "warning: Your Guix installation is 143 days old." <ieure>dckc, I believe that warning is specifically for guix, the binary, the thing you update with `guix pull'. <dckc>I use guix on top of debian. what's the norm for not getting 143 days out of date? just manually `guix pull`? or is there some analog of unattended-upgrades? <ieure>dckc, Guix services don't work on foreign distros. The norm is to periodically run `guix pull'. <ieure>You can put that in a weekly cron job or something. I wouldn't want to run it daily. <ieure>Cron job for your user, not root. <dckc>and every once in a while, it's going to rebuild emacs; that's state-of-the-art, right? I'm not missing something? <ieure>dckc, `guix pull' will not rebuild Emacs. `guix pull' updates Guix itself, not the packages which Guix has installed. <dckc>guix install: warning: Your Guix installation is 143 days old. <dckc>guix install: warning: Consider running 'guix pull' followed by <dckc>'guix package -u' to get up-to-date packages and security updates. <dckc>the `guix package -u` part was what started building emacs <dckc>do folks run `guix package -u` periodically? <ieure>dckc, There are multiple ways to manage packages in Guix, of which the imperative style you're using is one. I don't use that, but I'd assume that those who do periodically run `guix package -u' to upgrade things. <ieure>dckc, Note that the "upgrade" actually creates a new per-user profile generation, and you can revert back to the previous one if the new one breaks in some way. <ieure>`guix package --list-generations' will show your per-user profile generations. <dckc>20hrs ago Ricardo Wurmus made a whole slew of commits <ieure>dckc, If you haven't updated in 143 days, I don't think it matters much what anyone did 20hrs ago. <dckc>I'm just scrolling thru recent commits to get a sense <ieure>There will have been thousands of commits in that timeframe. <dckc>I just looked thru a week or so <noxi>dckc: guix pull is apt update, guix package -u is apt upgrade <vagrantc>well ... not really, because "guix package -u" (a.k.a. "guix upgrade") only updates the user's packages, not the system installed packages ... <vagrantc>"guix system reconfigure" and "guix upgrade" is kind of sort of like apt upgrade, although there is no real correlary to user-installed packages in debian <dckc>ok... so I found a combination of packages I like for .py dev. I suppose I can make a manifest. then I should restart emacs in an env built from that manifest? <dckc>restarting emacs is something I'm used to doing more like... monthly when I need to reboot the machine or something. hm. <identity>dckc: you could use direnv, or you could use guix.el <identity>(info "(emacs-guix) Profile Commands") is relevant <GalaxyNova>ah Rutherther I was being stupid yesterday and I forgot to commit my .guix-channel <GalaxyNova>(it was using the version from the commit which was obviously bad syntax before I read the docs) <noxi>I don't know how guix.el is fitted for this, but I know direnv is perfect for the job dckc <noxi>Using direnv, you can put a .envrc file at the root of a project and use `use guix` at the top <noxi>this will make direnv load the guix manifest you may have in your project <noxi>Is there a way to convince guix shell to let go of a shell and rebuild it? <nckx>sneek: later tell yelninei (help2man) I didn't see your reply in time but it was certainly something like that. Eventually got a spew of ‘invalid bytecode version’s that wouldn't stop despite remaking. A deep clean & rebuild seemed to work, at the expense of yet another hour of space heating. <nckx>sneek: botsnack to ease your pain. <mwette>On a foreign distro, how should guix-daemon be updated? <iyzsong>mwette: run 'guix pull' as root, then restart the 'guix-daemon' service. most likely it's a systemd service, see Exec in its service file to confirm the daemon executable path. <mwette>iyzsong: ty. That is what I was doing, and the path is /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon which seems right to me <theesm>hi guix o/ noticed that mail.scm doesn't seem to be covered by any team, seems like something sysadmin could probably adopt <yelninei>janneke: I think i figured out how mesa works in debian. They use an ancient version <sneek>Welcome back yelninei, you have 1 message! <sneek>yelninei, nckx says: (help2man) I didn't see your reply in time but it was certainly something like that. Eventually got a spew of ‘invalid bytecode version’s that wouldn't stop despite remaking. A deep clean & rebuild seemed to work, at the expense of yet another hour of space heating. <janneke>yelninei: yuck, but good you found out <yelninei>janneke: the good news is that the next mesa release has lots of hurd fixes and should make things a lto easier <dckc>direnv ... yes; that sounds good. I use it for lots of other stuff <csantosb>Hi ! Am I the only one experiencing issues when guix pulling from codeberg ? <ieure>csantosb, What kind of issues? <ieure>I just kicked off a pull, it seems to be working. <ieure>It was able to fetch the commits, which I assume is where you were having problems. <csantosb>"guix pull: erreur : Erreur Git : failed to connect to codeberg.org: Operation timed out" <ieure>csantosb, I can't reproduce. <ieure>csantosb, Yes, the error is saying Git can't establish a TCP connection. What does `guix shell netcat -- nc -vzw1 codeberg.org 22' report? <ieure>You want something like: "codeberg.org [217.197.84.140] 22 (ssh) open" <ieure>I have what looks like good connectivity on IPv4 and IPv6. <ieure>csantosb, The netcat command specifies a timeout of one second, if it took 10s, it was somewhere other than establishing the connection. <vagrantc>i always pull from a local checkout, as well... since i am always fiddling with the local checkout anyways ... no sense downloading it twice <vagrantc>also works better when network (on either end) is flaky ... <vagrantc>*seems* slow at times, oddly enough ... e.g. pulling from a local copy where you have all the data sometimes takes longer than pulling all that data over the network <csantosb>Runs smoothly after a reboot. Sometimes an electronics background helps in life. <csantosb>vagrantc: I guess pulling from the local copy is the way to go, given that it sits already there anyway <mightysands>Okay, so trying to use the default iso image for guix system 1.5 on Thinkpads R400 and T60 doesn't work, leading to a kernel panic on the former, and not even getting as far after the grub menu ( it just hangs ) on the T60. I've verified the checksum of the iso against the contents of the install usb and it's a match. Trying out an OpenBSD liveusb worked, and I think reveals that the problem isn't with my laptops, but rather either <mightysands>The question is ( I think ); is this an issue with the Linux-libre kernel ? Or specifically the way it was compiled in the default iso image for guix 1.5 which is causing these issues ? <mightysands>Are there instructions for generating my own iso image with a custom compiled Linux-libre kernel for guix which I could follow, and see if that helps ? <ieure>mightysands, There are not instructions for that, specifically, but there are instructions for each individually. <mightysands>ieure: Compiling the kernel I could do, but would you know where I could find info on how to organise my own guix image ? That'd be the part which is most obscure for me <ieure>mightysands, The install image is in (gnu system install), you can inherit and replace the kernel field with your kernel. Or copy/paste. <ieure>mightysands, The `guix system image' invocation to create an ISO image from the Scheme declaration of what the image should be is in the Guix manual. <ieure>I have some hardware of that vintage I could dust off to see if I can reproduce the issue. Not sure I have a T60, and definitely don't have an R400, but have X200/X201, T61p, and I think X60/X61 kicking around in storage. <vagrantc>csantosb: the only minor surprise is keeping your local copy of the keyring branch up-to-date ... it does not change often, but when it does, it <mightysands>theesm: Thanks. I was thinking about posting an issue on the tracker. Only snag is I wouldn't be sure how to copy paste the error message output from the R400 to my other functioning computer to post it as part of the issue <ieure>mightysands, Yeah, that is irksome. Photo of the screen is probably sufficient. <ieure>Looks like Linux 7.0 is the version that finally makes this Snapdragon ThinkPad work. Current Ubuntu is running on it better than it has since I got it, audio and sleep are working. So I think after Guix gets 7.0, it should be doable within my free time constraints. <vagrantc>ieure: literally building 7.0.2 right now ... <vagrantc>the boot logo patch no longer applies, and i haven't finished building just yet... <yelninei>wasnt there something about making it easier to customize the boot logo? <vagrantc>obviously something changed ... this patch has been unchanged since 3.16 up through 6.19 ... 7.0.x is the first time it seems to need to be updated <theesm>vagrantc: is the patch already fixed upstream for 7.x? read that it's broken in the linux-libre irc some time ago <vagrantc>theesm: nope, i just disabled the patch for now <vagrantc>last "published" version of the patch were were using was for 5.5 (but it in fact is identical to the version in 3.16) <vagrantc>if there is a more recent updated patch, ... please comment on the pull request :) <mwette>After installing a new router recently I ran into issues w/ guix, ssh, web browsers etc. on multiple computers. I discovered if I limit the bandwidth from/to my NAS everything cleared up.