IRC channel logs
2026-03-24.log
back to list of logs
<bjc>well hot dog, i finally got a pull to work on hurd <bjc>well, subsequent pull is now sigilling again <bjc>and gdb is having a conniption trying to load the core file <kratacoa>Rutherther: managed to solve my issue thanks to your advice. The Guile failure was a hardware failure, I assume the initial `guix pull` was as well <bdunahu>Is there a way to make `guix build --rounds=k` actually force a rebuild? It seems to use cached results and finish in seconds, which seems to defeat the purpose. <bdunahu>Thanks, that's what I was looking for! I wonder if `--rounds` should imply `--check`, unless there's a reason to use one without the other? <PotentialUser-8>I'm having trouble with upgrading my Emacs packages. I use emacs-next-pgtk, and all my Emacs packages (managed via Guix) are native compiled. In newer commits of Emacs, tests of emacs-dash fail. Since dash.el is quite a popular library, that means many of my packages depend on it and thus, attempting to upgrade also fails. <czan>I just ran "guix build emacs-dash" and it happily gave me a store path, so I assume you're talking about building it some other way? <PotentialUser-8>czan: It fails when natively compiled against `emacs-next-pgtk`, i.e. "guix build emacs-dash --with-input=emacs-minimal=emacs-next-pgtk" <identity>PotentialUser-8: maybe that means you should pester the developers to switch from dash.el to the built-in cl-lib/seq/map&c. <czan>Right, that makes sense. Given you're using transformations anyway, can you use --without-tests=emacs-dash? Or are the test failures legitimately showing that the package is broken? <PotentialUser-8>identity: Unfortunately, quite a lot of the packages I use depend on dash.el :') <identity>PotentialUser-8: that means you have a lot of work to do <PotentialUser-8>Huh, Kiwi IRC replaced my text emoji with a completely incorrect Unicode emote, weird... <PotentialUser-8>czan: Building with that flag works, but I don't know how to translate it to package upgrades. <PotentialUser-8>I tried "guix package --without-tests=emacs-dash -u" but it didn't work; still failed with the error on `check` phase <PotentialUser-8>I presume that's because emacs-dash is not "directly" in my profile (i.e. via my specification), but rather a dependency. <czan>How are you doing the transformation to change which Emacs version is used to compile? <PotentialUser-8>czan: I've simply been using "guix package -i emacs-foo --with-input=emacs-minimal=emacs-next-pgtk" to install my Emacs packages <czan>Right, so then I think the transformations get saved into $profile/manifest. I worry that you might need to do "guix package -i" for each package that needs the emacs-dash transformation. Have you considered using a manifest.scm instead? It's a bit more straightforward to apply the transformation to lots of packages in a manifest. <PotentialUser-8>czan: I haven't used a manifest yet because there are a couple things I have to do in my dotfiles *before* switching to manifests, but a switch should be effortless enough after that. <czan>Oh? A manifest doesn't do anything other than just declaring the sorts of things that you can do with "guix package {-i,-u,-r}" (unlike "guix home", which can do a lot more). What do you need to do with your dotfiles before you can use a manifest? <PotentialUser-8>czan: Well, I don't *have* to do these things, I'd just *like* to do them. My dotfiles are a mess and were pending a refactor; I kinda started one and never got around to finishing it, and if I start managing a manifest I'd spread my attention even further and make it more likely to have everything unfinished. <czan>Sure. :) I guess the thing is that you're currently just hiding the state from yourself (because Guix hides it away behind the imperative "guix package" actions). A manifest would just make it slightly more explicit, and give you the power to do the transformations you want in a more robust way. <czan>But I totally understand the desire to not add more "junk". I've taken the "big ball of mud" approach to my config, so it doesn't stress me out to add a bit more mud to the ball. :) <apteryx>would someone know why adding #:disallowed-references (list gtk gtk+ qtbase-5 qtbase) to ffmpeg causes a top level module circular dependency? <apteryx>it appears to be caused by just 'gtk' on my branch <czan>I don't know, but could it be because gtk depends on ffmpeg, and arguments isn't thunked? <czan>Nope, arguments is thunked. <identity>i get «GC Warning: Repeated allocation of very large block (appr. size 468 KiB)» during reconfigure after pulling, though it seems to proceed normally so far. i presume it is safe to ignore? <apteryx>we have some code that uses large amount of memory, like the phases validating the runpaths, so that's expected for now <apteryx>czan: yeah, I would have thought thunkness would have prevented this from happening <csantosb>For reasons unknown, this comes to my mind more and more frequently, suckless.org/philosophy <cbaines>hopefully it won't be down for longer than a couple of hours <civodul>cbaines: thanks for taking care of it! <csantosb>civodul: Out of curiosity, I'm able to restart only some builds,pulls.ci.guix.gnu.org/build/1481504/details, is this expected ? <civodul>csantosb: yes! you can restart builds that (1) are in “failed” state, and (2) took less than an hour to build <civodul>tradeoff between convenience and resource usage <civodul>uh, /gnu/store/y38hhc68fiwhkmyg20bvsjqy1w0vdnww-gcc-mesboot-4.9.4.drv takes more than 6h to build (so it usually times out) <gabber>is there a correct or best way where to add a symlink for a GC root under /var/guix/gcroots? is /var/guix/gcroots/profiles/per-user/${USER} the right path or is that managed by guix home or something? <gabber>and is it even possible to add a channels.scm+manifest.scm profile like this? <czan>If you use "guix package --profile=..." it should get added to /var/guix/gcroots/auto, and hang around for as long as the referenced profile directory does (which requires the Guix daemon to be able to see the provided directory). <gabber>czan: which i guess it does since i still run guix-daemon as root? <czan>Yeah, should be fine, then. <civodul>cbaines: no, i’m totally clueless :-) i just wanted to express support <postroutine>Hello. I was reading the manual about how to write my own service type and it suggest to use the macro `define-configuration` to define the service configuration scheme record. But while reading the `mumble-server` service type code, I see that it directly use `define-record-type` instead of `define-configuration`. Is there different ways ? <postroutine>And if I understand correctly, `define-configuration` will manage the generation of the service config file content. So, how is it possible to do it while using `define-record-type` instead ? <csantosb>Substitutes are particularly slow, or this comes from my side ? <civodul>now, ci.guix is overloaded today, i don’t understand why <bjc>none of the existing modules seem to apply <bjc>related: there are associated udev rules for it. i assume that belongs as a system service, but again, i'm not sure where <efraim>civodul: looking at top it looks like there are several copies of the daemon running <bjc>it does a lot more than flash <bjc>but yeah, that's not inappropriate <bjc>it's also specific to this piece of hardware, as opposed to like openocd <gabber>bjc: i'd prefer flashing-tools towards creating its own module <bjc>close enough for me, then <bjc>any idea where to put the udev stuff? <gabber>shouldn't this go together with the package and be an input to it? similar to android-udev-rules? <bjc>i was hoping to have something to instantiate directly, rather than just leaving a comment <bjc>if the convention is to put it in the same module as the package, i can do that <bjc>the android-udev-rules are a package, though. does that make sense? <bjc>i wanted a service, for use with ‘udev-rules-service’ <gabber>bjc: the udev-rules are only so your machine can "talk" to the device. how you use that connection is up to you <bjc>i know, i wanted to give you something to set it up easily that takes any guix-specific changes into account <civodul>oooh, i think i know why ci.guix is slow: i started ‘guix deploy berlin-nodes.scm’, and that builds a bunch of QEMU images, which is i/o-intensive… <civodul>looking into redeploying those childhurds <bjc>i suppose i could just make a qflipper-service-type that extends udev <yelninei>civodul: \o/, thanks, the build for guile-bootstrap etc would also need to be restarted afterwards as they already failed <yelninei>ACTION is still still struggling with hard to isolate druntime segfaults <yelninei>well copy pasting the complete unittest in a new project it is fine. Running it in the upstream test framework it crashes <redacted>> - [ ] Closure size given by `guix size`. <redacted>It's not clear what this checkbox implies I should be doing. <chris0ax>#hi, has anyone ever tried to update guix similar to a guix pull in an offline manner? like i load what i need in an usb, connect and mount that, and import into the target machines guix store the updated guix <ieure>chris0ax, I have heard of people doing this, but I don't know the exact mechanism they used. <ieure>chris0ax, I think you'd probably want to clone the repo onto your external storage, then use a channel configuration that pulls from wherever that gets mounted. You'd also probably want substitutes and some way to get them, I believe `guix copy' can transfer a store item closure around. <identity>chris0ax: guix pull --url=/media/usb_stick/src/guix/ <identity>this gets you through the offline guix pull part, at least <identity>that works only with the Guix channel, though, you need something different for other channels <chris0ax>from what i read, guix pull supports file:// urls, so for multiple channels i guess i'd have to specify that in a custom channels.scm <chris0ax>ieure: does `guix copy' work locally? i assumed id need `guix archive --import' since the docs talks about it with SSH in particular in mind <chris0ax>ill probably do a write up on this, feels like a cool experiment <yelninei>it seems it is not the test that is crashing but the debug version of the runtime library somewhere and as all that happens before main it is hard to find out where exactly <gabber>how can i test a substitute* regex without actually substituting stuff in files? <gabber>i get a decoding-error "peek-char" "input decoding error" <bjc>i copy the line i want to test against into a guile repl and string-match it until it does what i want <ieure>gabber, The procedure modifies files in-place, I don't think there's a way to make it not do that. You can use in the REPL, possibly wrapped up in a `begin' which resets the contents of the file it operates on (ex. by copying from a known-good original to a working copy for substitute*). <bjc>since the substitution typically happens early, i also (invoke "false") at the end of the lambda so i can quickly check that it worked without doing the whole build <ieure>bjc, Depends what you're building, for some packages, even unpacking the source can be slow. <bjc>yeah, it won't work great for gcc <bjc>it's still the earliest you can stop it to see if the rules worked, though <gabber>hrmpf. there are python2 style `print "foo bar"' statements in `if debug:' clauses in a package that i'd like to prevent from breaking our 'compile-bytecode phase <gabber>but i fail to do so adequately with substitute* <bjc>does python3 require parens now? <ieure>bjc, Since the very beginning. <ieure>print is a function in Python 3, not a statement as in Python 2.x. <bjc>i guess “now” implies a recency i didn't mean to =) <gabber>hrmpf. it works in the repl with the downloaded source file but not in the build phase :( <ieure>gabber, Hate that. I sometimes stick a divide by zero in a build phase when I want to examine things in the middle of a build, `guix build -K ...' and go poke around the working tree. <gabber>ieure: does (exit -1) not do the trick for you? ;) <yelninei>gabber maybe an issue with the file encoding? You could wrapping with (with-fluids ((%default-port-encoding some-other-encoding)) (substitute* ....) <gabber>huh! it is encoded as ISO-8759-1 <gabber>does our builder stumble over that?? <ieure>gabber, I'm not sure how character encoding works in Guile. I don't think that's a builder/build daemon issue. <gabber>(how) can i change the encoding of said file? <ieure>gabber, Are you sure that's the encoding? Do you mean ISO-8859-1? <ieure>Does it actually have any non-ASCII characters in it? <gabber>there's an é on the second author line <gabber>but the build process failing to substitute* on this file seems like a bug, no? <ieure>I'm not sure. It seems very unlikely that this is the first package to need to modify a non-UTF-8 source file. <gabber>are non-unicode text files still that common? <ieure>Much of the most important systems in the world run on ancient EBCDIC flat file COBOL pigshit. <gabber>i meant common in Guix packages (that need substitute*-ing) <gabber>i work with win-1252 encoded files during daytime <ekaitz>you could do something similar in the guix foundation <ieure>kestrelwx, No. The home team is responsible for the `guix home' command and infrastructure, not every possible home service. <ieure>kestrelwx, The definitions of which teams own what files is in etc/teams.scm. <gabber>can i roll-back a user home profile while not logged in as that user? <kestrelwx>ieure: Oh, I thought the entry in CODEOWNERS would match anything under `gnu/home/`. <ieure>gabber, Yes, replace the $HOME/.guix-home symlink with one to a previous generation. All known generations are in /var/guix/profiles/per-user/$USER. <gabber>my shepherd (root) hangs after logging in for some reason <ieure>gabber, This doesn't do *everything*, if the generation uses the file-service-types to drop config in places, that won't happen unless you activate the generation. I'm not sure how to do that. Maybe this is enough to get you logged in. <ieure>gabber, Other option is to rename .guix-home, log in, rename it back, roll-back / fix / etc. <gabber>huh, it seems to hang even without logging in? <gabber>i booted with a previous generation, same effect <gabber>what hardware issue could cause such a weird thing? faulty (second) RAM stick? <ieure>gabber, If your problem is with the home generation, rebooting to pick a different system generation isn't going to fix anything. <gabber>well, i'm not sure what causes the problem <ieure>Question, what are X11 folks doing about screen tearing? <gabber>ieure: switching to wayland, i presume <ieure>Anyone switching to wayland is no longer "X11 folk" <ieure>I am not switching to Wayland. <ieure>Context is, I have hardware which isn't supported (or, not supported *well*) by the intel Xorg driver. The tearfree option works, but other stuff is hilariously broken. Like certain programs simply don't update their display unless I resize their windows. Others work fine. It's weird. <ieure>So I switched back to the modeset Xorg driver, now stuff works, but with awful tearing. <ieure>Rutherther, Yes, they're all horrible. <ieure>kestrelwx, Yes, very typical for Intel video. <Rutherther>ieure: as in, they didn't help with the tearing? <ieure>Rutherther, There are three options, all horrendously buggy and in various states of unmaintained. <ieure>Rutherther, "horrendously buggy" like: stops working and requires restart. Doesn't know about XrandR at all, and if I plug a monitor or change rotation, video is unusably corrupt until I restart. Just awful. <ieure>I have no idea what changed to require a compositor to get basic, functioning video in Linux, but it wasn't like that back in the day and I really dislike it. <ieure>Hmmm, modesetting might have a tearfree option now. <Rutherther>ieure: interesting, in my experience I could almost never get along without a compositor, always had screen tearing without it. Well by always I mean last 10 years since I did not use Linux before <ieure>Rutherther, I used Linux exclusively from around 1995 to 2005, used Macs for a while when they were decent *nix boxes where the WiFi worked, switched back in ~2015. Lot of stuff changed in that era. <gabber>i think my ~/.guix-home is now gone <gabber>the machine hangs as soon as `herd status` is invoked when i'm logged in via tty as root <ieure>gabber, Interesting, does root even have a user Shepherd? <gabber>ah no, the machine is still ok, but the command hangs <gabber>i'd guess the invokation as root was the same as `sudo herd` <ieure>`herd' as root typically interacts with the system Shepherd. <ieure>Yeah... so something is horked with the system. <gabber>so it's not the user shepherd that is the problem, but rather system shepherd <Rutherther>gabber: is it possible there was a date change? ie. no RTC and NTP? <ieure>gabber, Alright. I have just seen a good amount of these mystery hangs related to bad networking. <gabber>yes, i think the onboard battery is borked (date is reset on reboot), but my computer parts guy assured me this laptop (2014 MBP) has no onboard battery <gabber>so i replaced the main battery but this doesn't do the trick <Rutherther>gabber: then that could be the issue. Shepherd will hang on date changes, more than a ~1 day <gabber>`hwclock` and `date` return the same <gabber>`herd disable ntp` hangs as well <Rutherther>that would not help when the system is already in this state <Rutherther>I meant to not start the service at all on boot, ie. remove it. Or you can just disconnect it from the internet so that it cannot update the time and check then <gabber>the machine automatically connects to my wifi .... <gabber>should i just wrap it in aluminum foil? <gabber>reconfiguring the system currently is difficult; and hindering it to start without `herd disable`ing it similarly <gabber>Rutherther: but what's the path forward, then? how can i fix the system? <gabber>i don't think i could live without ntp <ieure>aaaayyyyy, modeset tearfree enabled works a treat. <Rutherther>gabber: why dont you disable it through nmcli oř whatever mechanism you are using to configure it? <ieure>Shout out to "vsync tearing test" on YouTube, the only actual good vsync test video. <Rutherther>gabber: I do not know. If the issue is the date change, I don't know a fix. If it isn't, then there might be somethjg <ieure>gabber, Maybe you can use GRUB to edit the kernel CLI arguments, to blacklist your WiFi driver. <ieure>gabber, That would boot you up without networking, so ntp wouldn't be able to advance the clock, and hang shepherd. <ieure>Or you could take the laptop to a park and boot it there. <gabber>that could work (i think the aluminum foil hack would be much easier, though) <gabber>do i need to fix my hardware clock? <ieure>And if you can't do that, disable the NTP service. <Rutherther>gabber: That will likely be the easiest fix, yes <Rutherther>gabber: unless you decide to take care of fixing fibers <ieure>Gotta be able to log in to do that, I think. <gabber>turns out i can log in as root and do `su - gabriel` <gabber>but trying to deactivate the wifi hits the shepherd bug <ieure>gabber, `sudo rfkill block wlan' <gabber>i think i'm good (: the system fixed itself(?) apparently before i could `hwclock -w` with the laste reboot? <ieure>Spoke too soon... modeset still tears :( <ieure>"[ 24.086] (WW) modeset(0): Option "TearFree" is not used" <ieure>Maybe there just hasn't been an Xorg release since the patch landed. <ieure>Maybe I'll see about including the patch in Guix. <ieure>It would save me a lot of hassle. <ieure>untrusem, 149.0 is here, do you want to take that? <gabber>wow, the "Channel changes compared to the previous (successful) build" in (new?) cuirass is amazing! <redacted>guix deploy is giving me "message authentication code incorrect" errors server side. Is there a way to get more verbose logs from the SSH connection?