IRC channel logs
2025-04-05.log
back to list of logs
<podiki>Normally I'm around now yes, just not this time until later this evening. Looks like it got handled! <jA_cOp_>For a package definition, is there a nice way to apply a patch inside a phase, so I can do it in between certain phases? Currently using gnu-build-system for the package <Bok>hello, I have been considering switching from nix to guix but doing some research first. <Bok>It looks like that the latest neovim version supported by guix is 0.9.5, which came out in Dec 2023 <Bok>If I wanted to install a more recent version like 0.10.4, how would I do that using guix? <jA_cOp_>of course, if the reason neovim is outdated is because the newer version brings some packaging challenge, then it's not gonna work <Bok>thank you for the link, I'll read more about it. yeah, I'm not certain why guix has such an old neovim package but maybe that is why? <jA_cOp_>if there's some packaging challenge, you might find a reference to it by searching the mailing lists or the public IRC log <Bok>that's good advice, I'll see what I can find <jA_cOp_>also, if you were thinking of switching to Guix system, maybe try out Guix on your existing distro and get neovim working there before making the plunge on a full system install :) <Bok>lol I was thinking the same thing. I just tried to install guix on nixOS and it had an error which I found awfully suspicious XD <hiecaq>Hi guix, is there a way to integrate services with guix-shell -C? For example, I want to use some packages with some service-managed configs, but isolated in the container. I guess --profile would probably work if I just manually create a profile beforehand, but I hope there are some better ways <apoorv569>Is there a build system for packaging gradle/kotlin stuff? <meaty>what should I enter as the "version" in 'git-version' for a package that has no version tags at all? the date as year.mo.dy ? maybe 0.0.0? <meaty>a grep shows the latter is more common but moth are present <meaty>also, is it better to use " characters in descriptions and synopses or `` and '' <apteryx>does elogind provides a org.freedesktop.systemd1 dbus service? <apteryx>hm, no, it seems it only provides org.freedesktop.login1.service <adanska>hi Guix, im experiencing a build faliure with `go`. building from source (ie `guix build guix build --no-substitutes --no-grafts --check go`) fails with a read only filesystem error: (https://paste.debian.net/1367589/) the package is go-1.4-bootstrap. I think theres some other packages that fail with similar tests, although they escape me right now... <apteryx>anyone knows what localed does? am I supposed to select multiple languages on the login screen or something? <apteryx>does 'localectl set-keymap dvorak' work for you? on my Guix System it prints: Failed to set keymap: Failed to set virtual console keymap: Function not implemented <apteryx>hm, nope. it doesn't print any error but 'systemctl status' shows the keyboard layout is unchanged. <keinflue>adanska: I also noticed the same. I think commit 40f69b586a440d0397fa3dfe03b95a0f44e4d242 made the root file system in the build container read-only. Several packages including shephed, go, scons and ruby fail their tests with that because they try to remove non-existent files under /, assuming to get back ENOENT from the unlink(at) syscall, but <keinflue>under Linux (currently) EROFS is returned instead if the file system is read-only, even if the file doesn't exist. <divya>Great, now even ghc-9.4.4 is not working. <apteryx>how do I configure my keyboard via operating-system for Wayland? <apteryx>I'm using GNOME, which now defaults on Wayland, and of course the documented xorg-configuration means does nothing. <adanska>keinflue: glad to see that it isnt just me. has an issue been opened? <divya>apteryx: What exactly are you configuring? <divya>apteryx: I have this in operating-system: <divya>(keyboard-layout (keyboard-layout "us")) <apteryx>I bet that's the default, so if it doesn't work you wouldn't know, right? :-) <divya>The manual says you can use setxkbmap for dvorak as well <apteryx>I have (keyboard-layout (keyboard-layout "dvorak")) <apteryx>even with the above my Linux virtual terminals are using 'us' (querty), not dvorak. Same for GDM <keinflue>adanska: I have not seen an issue and I have never reported one, not sure what the procedure is. <divya>apteryx: I've heard Wayland previously has had keyboard layout issues <adanska>keinflue: yeah! that would be great. cc ludo in since it was thier commit that caused the breakage, im sure he would be interested in this. <apteryx>hako: I see; that's not entirely satisfying for the general case where the keyboard at the graphic login screen would be correct too. It seems the localed stuff has a config file to set these; perhaps we aren't using that, or perhaps it doesn't currently work correctly. <apteryx>I guess on other systemd systems it's handled by localed, which is provided by it (and for which we have a service, especially for GDM to behave better) <apteryx>I've been tinkering with 'localectl', and it doesn't appear to work (the current keyboard isn't changed even when the command appears to succeed). <aemogie>hi all! is there a way to write a service that optionally extends another service without attempting to instantiate it? <aemogie>something that gives behaviour similar to nixos's `config.otherModule.someConfig = lib.mkIf config.otherModule.enabled {...}` or if not what would be the guix way to go about handling this use case? <aemogie>for example a gpg service where if git is enabled, automatically sets up commit signing, or a theming service where it attempts to configure any enabled services, or a waybar services that autolaunches waybar on all currently installed window managers, etc. <lilyp>aemogie you can do this, but it's not customary <lilyp>basically, you'd end up writing a procedure to generate the service type <aemogie>would that be something like, the user of the service would explicitly ask for the specific extensions the service should have, as opposed to the service implicitly looking at the current service list and determining what it should and shouldn't extend? <aemogie>would something like (make-theming-service-type #:swayfx #t #:emacs #t #:foot-terminal #t) be what you mean <lilyp>nah, you can code up some automagic to guess those service types, but you would have to make that dependent on the arguments the user provides <lilyp>note that stuff like that isn't typically necessary, because you can define your own service types on the user side <aemogie>im not sure i get what you mean, what would be the more traditional/guix-y approach for this? <lilyp>just write a service type that extends the stuff you need at point :) <aemogie>so, the `my-gnupg-service-type` would only configure the required things, and the optional ones i write extra service for? but then the issue is i lose information, no? the gpg service type has the configuration value for the signing key, whereas a `my-gnpug-git-commit-signing-service-type` wouldnt, right? <lilyp>you can share configuration variables between them, I don't see why that'd be an issue <aemogie>it's more that i dont like explicit/external wiring by api callers as it feels fragile, even if i am the caller of my own api. but i suppose that is a personal stylistic preference than any functional one :) <gabber>what's a (relatively) simple package with multiple outputs? <gabber>or: how can i build a package with multiple outputs? i would like to extend terminal pacakges with a terminfo-only output <janneke>gabber: try git grep '(outputs' -- gnu/packages and select one you like <mirai_>apteryx: does (keyboard-layout (keyboard-layout "…")) not do it for you? <mirai_>you might need to "gsettings set org.gnome.desktop.input-sources show-all-sources true" <apteryx>mirai_: yeah, it doesn't work for me (I'm stuck with us english keyboard layout in GDM although I've specified keyboard-layout to dvorae) <apteryx>lilyp: I've fixed (skipped) test failures and bumped a few gnome packages on the elogind-updates branch; scheduled for a merge soon. you may want to take a peek <lilyp>we need a larger glib/gtk bump if we want to do gnome 48, sadly <apteryx>I tried gtk 4.18 but hit some other dependencies requirement, so punted for now <lilyp>last time i tried, I hit a cycle <lilyp>(particularly, a cycle within the glib package) <identity>apteryx: i think you need to set it in xorg-configuration in the system config for gdm to pick it up <apteryx>identity: I use wayland, so that does nothing, IIUC <identity>apteryx: i do too, but it works that way for me <identity>(services (append (list (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout)))) %desktop-services)) <nigko>ACTION is seeing a series of 'Clearing orphaned inodes' messages during the boot after reconfigure. <nckx>Did somebody manually restart goggles-bot? <nckx>‘It is running since 05:38:07 PM (38 seconds ago).’ <ieure>Welp, the not unmounting fs bug has claimed my main Guix devel laptop's root FS :( <ieure>> du: cannot access ''$'\033''[01;34m/gnu/store/wk6nvy8yqx8wbs25byi1rcnqqwb8kxwl-postgresql-14.13'$'\033''[0m/': No such file or directory <ieure>Okay no, that's just ls color codes in the output, ugh. <nigko>nckx: Indeed, I have "Ignoring error while stopping file-system-/gnu/store: (system-error "umount" "~S: ~A" ("/gnu/store" "Device or resource busy") (16))" line in the logs just before reboot. <nigko>Rutherther: I have this line in logs even after reboot without reconfigure. But 'Clearing orphaned inodes' messages appear only after reconfigure. <Rutherther>the thing is that the root file system unmount does a recursive unmount <Rutherther>so the error you sent is probably unrelated to the actual issue <nckx>ieure: Cursed e2fsck patch that renames corrupted files to blink ANSI red. <Crawf>Is guix.gnu.org down for anyone else, or is it just me? <lfam>I suppose it's been mentioned that guix.gnu.org is offline <nckx>A comedic 25 seconds before you joined. <nckx>ACTION tries the advanced debugging technique of herd restart nginx… <nigko>Rutherther: According to my logs the error appears only after reconfigure to 9866d32e173050ba99dc520b0a4d5aacb85e3fa0. So, the timings is in favor of the same issue. <Rutherther>nigko: oh, so your previous information about it being printed every time is not correct then? <nckx>ACTION tries the advanceder debugging technique called pkill -9… <nckx>My brain is unable to think of a problem that would match me being able to ssh into the server, curl localhost:443, but get a ’connection refused’ in Firefox on the same machine. <nckx>lfam, Crawf: Is it still down for you? Can you ping/mtr it if so? <nigko>Rutherther: It wasn't precise. My extra investigation reveals this additional info. <nckx>(I don't need the output, I don't think I can do anything with it, just curious if it's a routing issue.) <lfam>nckx: It replies to `ping guix.gnu.org` from "elidee.aquilenet.fr (2a0c:e300::58)" <Crawf>Ping works, but that was true before. Curl fails <lfam>Seems to be okay with `mtr` too, although I'm not so familiar with mtr <nckx>I think it also uses ICMP so if it worked before I guess it's not relevant. <Rutherther>nigko: can you send the whole log you've got after issuing reboot command? <Rutherther>nigko: although wait... that commit you sent, it's from a month ago <nckx>I'm hesitant to blame it on the MDC firewall because it feels like a cop-out, but if I can curl localhost and there's no proxy between nginx and port 443, I can't think of an obvious alternative. <Rutherther>(just ignore my last message, I haven't realized you sait it's where it started) <Rutherther>nigko: can you send the whole log you've got after issuing reboot command? <Rutherther>nigko: although wait... that commit you sent, it's from a month ago <nckx>It's a ’smart’ firewall so it's probably pretty stupid. <Rutherther>nigko: hmm I see Service tlp might have failed to stop. in your log. If tlp really hasn't stopped, it could explain why store is in use <nckx>Wait a sec. This is embarrasing. berlin happily serves guix.gnu.org but that's not where the DNS points to 🤦 <nckx>Restarted nginx on bayfront, oh look, is work. <nigko>Rutherther: I have disabled tlp service, rebooted, rebooted again. The error is still there. <Kimapr>I'm messing with AT-SPI and have noticed that none of GIMP, HexChat, Icedove are accessible through the accesibility bus. All other apps work, even Telegram in Flatpak (which is surprising). <Kimapr>I don't know what the deal with Icedove is because Icecat does work and it's almost the same thing but the common thing between GIMP and HexChat is that they're GTK2 <Kimapr>GTK2 *should* work, but seems it doesn't on guix <Rutherther>nigko: the only other thing I can think of to look at, is to see all your services from herd status, and check if there is one that hasn't been stopped in the reboot log, <cow_2001>You know what I hate? guix style deleting my #;ed up exploratory bits of code. <nigko>Rutherther: Well, I still see 'Service urandom-seed might have failed to stop'. This one seems to be in %base-services. <Rutherther>nigko: yes, but that one isn't actually a service that would have a process running <cow_2001>you are at the exploratory stages of a bit of coding, you write one or two extra version of the same functionality, so you comment them out with #;, right? then just so that things look nicer you guix style... and then your code is GONE! <lfam>So does `guix style` just delete all comments? <Rutherther>nigko: I wouldn't really say it's 'okay', but it shouldn't really be cause of this issue as it's not using anything from the store <Rutherther>nigko: it's just a simple script that sets up /dev/urandom at start and cleans it upon stop. It isn't doing anything 'in between' <Rutherther>nigko: I am getting the same thing about urandom-seed in log for a VM, although I am not experiencing unmount issues there <lfam>nigko: Is that service failing to stop in a VM or on "bare metal"? <nomike>In "22.10 Submitting Packages", it is mentioned in step 5 to test whether the package builds correctly. Which it did. In step 10. I should test whether the package build is deterministic using `guix build --rounds=2 my-package` The provlem is, that it doesn't build it again, as it is already built. It used says `/gnu/store/7mm4l8nb7z1k80v06prvf7ynkmkn67yv-jupp-3.1jupp41` at that step. What am I missing here? <lfam>nomike: Add the option '--no-grafts' <nigko>Rutherther: There are no other 'failed to stop' services except 'Service file-system-/gnu/store', which triggers the 'Ignoring error ...' line. <lfam>nomike: We use a feature called grafts to cheaply apply security updates to packages that would otherwise cause most of the distro to be rebuilt. This action is a "build" that happens on top of the actual package build. So what's happening is that only the grafting build is repeated, not the compilation <nomike>I'm trying `./pre-inst-env guix build --no-grafts --no-substitutes --rounds=2 jupp` but it still doesn't rebuild the package. <Rutherther>nigko: I know, that's why I suggested looking at the list of services that are normally running, because it could happen the service is not stopped at all, or that shepherd tries to stop it only after too late (which we might not see from the log as it's so close to shutdown part of it gets lost) <Rutherther>... or not really lost it's just that the log service stops, so afterwards we don't get logs <lfam>nomike: Please share your package definition and I'll try it here <lfam>nigko: Is the urandom-seed-service failing to stop on a computer, or just on a VM? <lfam>nomike: Oh, you also should add the '--check' option <lfam>Guix doesn't build things that are already built unless you use --check <lfam>That service is my baby, I suppose <lfam>Do you see any errors about the service during boot? <Rutherther>nomike: I think rounds works only when it's not been built yet, I can build a package like that two times after gc'ing it from the store. When it's already built, --check has to be used as was mentioned <nomike>./pre-inst-env guix build --no-grafts --check --rounds=2 jupp` did the trick. <nigko>lfam: No, I don't see. urandom-seed is starting normally. <lfam>Thanks nigko. Same here, and I also see the warning about stopping. Stopping is not super important but it does increase the security margin to some superstitious degree, because we refresh the seed after boot as well <lfam>nomike: It's not really wrong, but it maybe assumes some knowledge that a reader of this chapter wouldn't be expected to have. The thing about grafts is conditional on grafts existing in the codebase, which is common but not a given. I think that '--check' could be suggested, although if the package hasn't been built yet, then that option will cause an error, because there would be nothing to check <lfam>This step is really a "nice to have" more than a strict requirement <lfam>It's kind of a situation where there is no command that would work in every circumstance <nomike>Maybe some advice should be added, that if `guix build --rouns=2` completes very fast and doesn't re-compile the application the options `--check` and `--no-grafts` should be tried. Or something. I know now, but it was quite confusing at first. <nomike>And it isn't obvious from how the documentation is written, that it's a `nice to have` rather than a requirement. <lfam>Hm, that's my opinion :) To be honest, I never check the reproducibility if I am reviewing somebody's contribution of a package <lfam>Like, the requirement is to communicate your code or idea to someone in the project. The rest is ultimately "nice to have" :) <lfam>A patch to improve the manual is very welcome <lfam>Thanks for bringing this up! <lfam>nigko: I'm trying to debug this now. First step... build a VM image, which takes a little while <nomike>I will try to do this. I can only offer German and English though. But I'm sure there are others who can take over for the other languages. <nckx>cow_2001: I'd say that's an obvious unintentional (almost certainly untested) bug. <nckx>I've been trained to avoid #; comments because emacs-paredit absolutely murders them if you're not careful. Unfortunate. <nigko>lfam: I see. Good luck! I have to go. <lfam>nomike: Only English is necessary <cow_2001>nckx: i am going to send a bug report, right? <nckx>In general, ‘guix style’ makes some wrong choices IMO. Don't take its output as finished gospel of the project coding style. <cow_2001>nckx: what do you call #; comments anyway, other than just saying "#; comments"? <nckx>ACTION calls them #; comments 😛 <nckx>I guess I'd call them ‘Guile sexp comments’ in IRL conversation. It's not like it's ever come up. <lfam>dariqq: Thanks for digging that up. We can wait for it to get fixed upstream. <Kabouik>Is there any reason why a guix system reconfigure would hang on "guix system: bootloader successfully installed on '(/boot/efi)'"? It did that, then nothing happens and I can hear the fan speed going down as if guix system was not using much CPU anymore. <nckx>Sounds like the point at which it tries to talk to the running Shepherd to restart services? <jA_cOp_>was the system time set as part of the reconfigure, like with ntpd? I know there's a bug in Shepherd when the system time is changed <Kabouik>Well, sudo herd status sshd hangs as well <Kabouik>How would I know that jA_cOp_? At least there is nothing specific to that in my config.scm, nor is there even ntpd as a package in there. <jA_cOp_>Then I would guess not, unless it's part of %desktop-services. I don't think it's part of %base-services? <Kabouik>But it seems shepherd might have crashed if herd doesn't work either? <Kabouik>Would it be safe for me to reboot at this point? <nckx>No less safe than later. If the Shepherd's really hanging, I don't know how to wake it, and it's not like you can kill & restart it :) <nckx>Make sure to close everything & sync. <nckx>Basically, your Shepherd got envious of those fancy new versions with bug #77086, and decided to make you emulate it by hand. Maybe. <nckx>(If you have to hard-reset to complete the reboot.) <Kabouik>The reboot went fine nckx and shepherd is running again. Trying to finish the guix system reconfigure now. <nckx>Huh. Weird that a hanging Shepherd rebooted, but ultimately good news. <nckx>The previous reconfiguration is finished and you've booted into it, restarting services was the last step & it doesn't modify anything persistent, but it's a good test to see if Shepherd's now responsive. <nomike>lfam, regarding that documentation. In step 5. you are instructed to verify that the package builds successfully. You mentioned that adding `--check` in step 10. will fail if the package hasn't been built before, but due to Step 5. IMHO it's safe to assume that it always has (unless you are experienced already and didn't fallow the manual in order. but then you don´t need the manual anyhow, do you?). <Kabouik>Funnily, I installed Guix just recently on this machine (a funny one: https://0x0.st/8_PI.webp) and kept a Windows partition on it in case I'd need to upgrade the BIOS. I think this system reconfigure installed the bootloader on /boot/efi, and now at reboot, the Windows bootloader went all dramatic, stating that it was restoring stuff, rescuing, yadi yada. Until it let me to a semi-GUI (definitely not text only) where I could select Guix, but that was <Kabouik>Hanging shepherd did not reboot, I did it manually (with a hard-reboot since `sudo reboot` would need Shepherd I guess). <Kabouik>I can confirm that reconfiguring again worked nckx, no shepherd crash this time. <nomike>lfam, does that also mean. that you have to use `--no-grafts` as well? Because than I could just adapt the sample code and there is no need to further complicate things with a "Note: In case of blah you need to add `--no-grafts`.". <lfam>nomike: The grafting thing is a separate concern. If the package you are trying to build is subject to grafts (most are, most of the time) then you'd want to add --no-grafts when checking if a compilation is reproducible <nomike>But id the package has no grafts and I still add the `--no-grafts` option, would that be an issue? <nckx>Kabouik: Most UEFI machines implement their own ‘OS chooser menu’ or ‘boot loader’ or whatever you want to call it in firmware, and in a perfect world you'd not need GRUB or any other third-party ‘boot loader’ like rEFInd, but in practice the firmware is so buggy and differs so wildly between machines that it's seldom used as intended. <nckx>It often immediately breaks when confronted with anything other than the single Windows installation it was shipped & tested with. <nckx>(Not yours, apparently, just saying.) <Kabouik>I'm used to at least having a keybind to pull the BIOS boot entry menu at boot, typically F7, but this machine doesn't have any. In my other Guix machine, I could therefore set Guix as my primary boot, and if I seldom need something else, I would use that F7 menu. Here, the issue is Guix is not even listed in the BIOS, so I cannot set it as primary, and have to go into Windows recovery mode to finally see a Guix entry somewhere. Though maybe guix <Kabouik>system reconfigure doing something with /boot/efi has helped on that front, I should check. <lfam>nomike: I don't remember how it behaves in that case <nomike>Hmmm...if I would know a package which doesn't have any grafts, I could easily tell. <nckx>Kabouik: Wait, no way to interrupt boot at all? Let's remove the boot menu and require the user to request a reboot into ‘firmware set-up mode’ from… a working OS. What could go wrong. <nckx>(You can request this from Linux using some command I forgot, you don't need to keep Windows, but still…) <nckx>Our GRUB also provides a menu entry but pray you don't break GRUB. <lfam>nomike: I'll see if I can find one <lfam>Needs to be something that doesn't depend on glibc <lfam>Since glibc is currently subject to grafting <Kabouik>nckx: I can interrupt boot by going into the BIOS (which is firmware set-up mode, right?). That's all. Maybe I missed a key but I think I tried them all. And anyway, if Guix partition is not visible to the BIOS boot order submenu, I don't think it would be from a F7-like boot entry selection. On my other machines, I can see the Guix GRUB menu, but it's typically showing after I typed my passphrase once. <lfam>ACTION looks to Rust, where none of the normal Guix rules hold <Kabouik>I'm keeping Windows not to reboot into BIOS but because the BIOS upgrade utility the manufacturer has is Windows-based, and being a niche device with a small number of units, I expect bugs that may eventually be fixed with BIOS upgrades. <lfam>nomike: I tested it with a Rust package, since Rust in Guix is "different", to use that word like the kids do <lfam>Using --no-grafts with a package that is not subject to grafting does not cause any errors or warnings, so I guess it's safe to put it in the instructions <[>What's different about Rust in Guix? <lfam>[: Because the Rust software ecosystem is utterly rife with dependency cycles, the normal Guix approach of modeling dependencies as an acyclic graph is not used <lfam>It's basically a totally different thing from the rest of Guix packages <nckx>Kabouik: Yeah, people still colloquially call the UEFI firmware the ‘BIOS’. It's not, and it can either be pedantry to point this out, or it can be a vital distinction, depending on the context. :)+ <nckx>Kabouik: I see. All fine reasons <Kabouik>I actually thought I should call it UEFI something but was not sure I got things right so I preferred using BIOS to be sure I wouldn't make a worse mistake. :< <lfam>[: It's a bit annoying but it's a worthy trade-off to get this software into the distro <[>How does Guix even handle dependency cycles? <nckx>It becomes confusing when CSM enters the chat, which is UEFI's ‘BIOS emulation’, and then you have people saying stuff like ‘I entered the BIOS to toggle BIOS to boot the ISO’ or stuff like that. And in your case, I wasn't sure which one you meant at first. All good. <lfam>[: Usually, we make a chain of "bootstrap" packages to work around them. Like, we start with old versions of the cyclic packages from before they depended on each other, using them in turn to build the later versions until we get to something current. But with Rust, it's just a spiderweb <nckx>Guix doesn't handle them as much as it forces you to untangle them by hand *before* modelling them as packages which must form a pretty DAG. <meaty>do the upstream rust people see this as an issue? <lfam>sneek: later tell nigko: I created a Guix VM image based on the bare-bones template, but I added some "printf-style" tracing to the urandom-seed-service. When halting and rebooting this VM, I see that my final tracing message is printed to /var/log/messages, and that is printed after the seed is refreshed before the system is stopped. But I still see the warning that the service might have failed to stop. So I think the warning is misleading, but someone should see <lfam>about figuring why it is printed and fix that <lfam>And that's fine, I guess. It's our problem that we want packages to form a DAG <zilti>okay, I'm gonna stop using XFS. What amateurs made this crap? Second time this week that that FS decided to spontaneously self-destruct. <lfam>zilti: I'm curious what kernel version you are using. I would have thought that XFS was robust at this point <nckx>lfam: Not trying to provoke, but how is it fine? I.e., do they have their own algorithm to actually build everything from source… somehow? <zilti>lfam: well, whatever the most recent one in Guix is. I don't really check. <lfam>nckx: Well, when I say "I guess", I'm trying to hint that I accept it but I don't like it. They have their own goals and we have ours, and I don't think our respective projects are going to convince each other to change something here <zilti>identity: I cannot do that anymore. Grub cannot boot the system anymore. <lfam>That's going to be the 6.13 kernel series <zilti>Guess I'll give btrfs another try... That one makes a stable impression, even though a few years ago it also badly failed me more than once <lfam>nckx: I doubt the leadership of the Rust project thinks that they are unable to build from source in a way that matters to them. Of course we have a different opinion about it <lfam>And I do find the situation really frustrating for Guix, and I'm worried about how we will make it work for our kernel packages <nckx>lfam: I didn't mean to debate whether it's ‘good’ or ‘bad’. Just surprised that they'd tolerate needing pre-built packages to build stuff. Seems… contradictory of my distant view of Rust as caring about security. That's all. <nckx>I totally get that they might not agree with our restrictions but assumed they had a way of building $huge_project from source using their own dependency model. Anyway, I'm meandering, never mind. <lfam>In my time following discussion about security, I found that people have different ideas about the kind of security that matters. They care about code executing properly, we care about provenance <lfam>They kinda failed to build their technology to address the subject holistically <nckx>The obvious response is ‘which code do you think you're executing securely’ but I'll drop the subject since I'm not debating you. <lfam>Yeah, I think we having slightly different conversations. Moving on :) <nckx>Didn't help that I used ‘you’ to refer to Rust and not, uh, you. 