IRC channel logs
2023-04-15.log
back to list of logs
<bjc>got lxd built now. the only issue i have left w/ core-updates is weirdness with the way x keymaps are built <mekeor[m]>hello guix. when i run "xmonad --recompile", i get "Could not find module ‘XMonad’". why is that? <oriansj>mekeor[m]: well if I had to guess there is an unset environmental variable <bjc>oh no. guix build just started pulling down rust crates. this is going to be going for a while… <lfam>Big update just landed on master bjc <lfam>I would give it some time <bjc>this is core updates. lechner has a patch for a bug i wanted to test, but it looks like the turnaround is going to take longer than i expected <lfam>Big update there too. New merge of the master branch into core-updates <lfam>That basically means, rebuild the world from scratch <apteryx>bjc: I'm fixing a few rough things atop core-updates ATM <apteryx>tomorrow morning will probably be a better time to try <apteryx>(e.g. the last 3 evaluations have failed, so no substitutes have been built since the merge yet) <apteryx>ACTION is running 'make as-derivation' to check on things <bjc>the patch is for something deep in the tree. updating it invalidated a ton of substitutes, so i'm just going to have to live with it until its done <bjc>happy i spent the time setting up an offload server the other day <bjc>(which is currently using 350 watts. and it's 27°C outside. i should go to another room) <apteryx>the nss test suite is ridiculously inefficient <apteryx>I've pushed what I hope will fix the core-updates evaluation, but I still wasn't able to test it because of that multi-hour test suite ridiculousness <kitty1>was about to ask a question but I just realized I think I know the answer lmao <lissobone>The instructor was telling me to bomb some middle eastern-style houses, but instead I crashed. <kitty1>Intentionally or accidently crashed? <kitty1>I don't know if I've ever been flying in a dream, but my dreams are very long, in depth, and have story and structure to them often. <kitty1>Also sometimes time travel or loops. Rules to the universe. <lissobone>The speed was too low, and I couldn't gain height. <lissobone>A strange problem has been chasing me (but keeping distance) since I installed Guix. Perhaps it's just bash-related. <lissobone>Certain binaries, for example, the powder toy I compiled a while ago, just don't execute, in spite of the fact that I am the owner and there are execution bits set. Binaries of programs I wrote on my own don't start either, with messages like this: "bash: ./powder: No such file or directory". I should rather recompile them, I think. <bdju>anyone else hit a build failure earlier on python-pytest-trio? <bdju>like many of the build failures I seem to run into, I'm not even sure what this package is or why I have it. probably a dependency for something <jpoiret>florhizome[m]: does it fix a c-u specific breakage? <jpoiret>then it will hopefully be updated on a feature branch rather than c-u! <jpoiret>latest c-u evaluation failed because apparently swig couldn't be built, but it builds fine here (but with a different derivation) <andreas-e>jpoiret: How do you see what caused the cuirass evaluation to fail? <andreas-e>Oh, one just clicks on the red cross to see a log. <jpoiret>yup! i read it locally with a wget cause my firefox can't load that much text <andreas-e>I just built the swig derivation "by hand" on berlin. <andreas-e>The next step, graphviz, triggers the build of nss, which could take a while... <andreas-e>If someone knowledgeable about the berlin build farm is around, I am surprised that there is only one parallel build on powerpc: one of two on guixp9, and none at all on sjd-p9. Has anything been disabled related to them? <andreas-e>I had trouble recompiling core-updates after a "git pull" on berlin, with error messages for compiling non-latin1 texinfo documentation. A fresh "git clone" solved the problem. Just in case someone else experiences the same thing... <jpoiret>damn nss really is way too long to build <irfus>lissobone: you want to look into using the fhs-container option for `guix shell` to run binaries not installed through guix, even if you're compiling them yourself. <jpoiret>oh, so ninja supports setting 1 concurrent job for specific rules <andreas-e>I just downloaded a build log from the Guix Data Service. 79MB! The check phase took 6 hours on the build farm. <andreas-e>I just chose "retry the evaluation" on CI, but, well, it looks like if we are lucky, the result will be there this European evening. <jpoiret>you're telling me it's probably not worth building on my laptop? <andreas-e>Depending on your laptop and how long you want to wait :) Something can still go wrong on the build farm. I stopped my manual build and hope that the CI evaluation will succeed. While it is in progress, there is no red cross. <andreas-e>So the log file is hidden. But the URL can be guessed from other red crosses. <andreas-e>CI is building nss with no parallelism right now. <mfg[m]>what package provides libuuid? i can't find it <andreas-e>So it should take the same time on your laptop, jpoiret. <mfg[m]>is there a particular reason why we don't build mesas amdgpu_dri module? <andreas-e>While waiting, I launched a manual build of rust on berlin. If you need some particular package, I could also try to start the build before going out for the afternoon. <mfg[m]>Hm, we maybe should enable the zink gallium driver in our mesa build <oriansj>mfg[m]: everything in guix is in the shape it is in because that is what the last person who worked on it wanted. <mfg[m]>oriansj: yeah, makes sense. ALso: i think i lied. It seems the amdgpu_dri module doesn't come with mesa as i can't find the corresponding source in mesas git repo. I also don't have that module on my arch linux installation, but there i can start the program without a problem regardless. So i'm trying to find out the differences and test them. <mfg[m]>Tho changing and rebuilding mesa will take to much time iguess :| <mfg[m]>That's why zink may be of interest, to me it seems as if this driver gets used when the wanted target doesn't have a gallium driver but does have a vulkan driver <mfg[m]>but i don't know how these things correlate to each other <jpoiret>sneek, later tell andreas-e: nss built fine, but python-pytest is broken <bjc>i don't know when it happened, but i've started mentally pronouncing “guix” as “geeks” without needing to correct myself <bjc>the first time a software project has made me slightly french <minima>hi, i'm using guix home and exwm as my window manager; when i install a new emacs package, how do i tell emacs that the new package is available without having to restart the whole shebang, i.e. exwm and everything? :) <blendux>minima: how are you installing the emacs package? <irfus>minima: try `M-x guix-emacs-autoload-packages` <minima>blendux: hi, i add the package to my home definition and then reconfigure <irfus>if you're adding it to the home profile, then you might actually have to log off and back in. <minima>irfus: yeah, guix-emacs-autoload-packages doesn't seem to work :( <jpoiret>oh no, mesa depends on python-pytest for which we need an upgrade now <irfus>minima: I have a similar setup as you, and have been meaning to add the profile `guix package` installs into into $path just to avoid restarting exwm each time I try a new emacs package. <minima>irfus: oh cool that we have a similar setup; yeah i'm very happy with it (exwm and guix home) but this issue of having to restart exwm is definitely something where i need to find a solution or workaround <minima>irfus: by the way, when you say restart exwm, you mean basically logging off from x and logging in again, correct? therefore closing all the apps etc... <lissobone>I will look into compiling non-guix-installed binaries this way. <lissobone>I have ran through the entire city and beyond. <jpoiret>minima: this is going to be hard in general <jpoiret>since emacs on guix doesn't just rely on a path but also on a guix-specific .el <apteryx>hm, 'make as-derivation' passes on core-updates, so I wonder why it can't be evaluated by cuirass? <apteryx>jpoiret: could you please brief me about what broke regarding pytest? :-) <jpoiret>well, i'm struggling to understand upstream's explanation <jpoiret>but updating it to 7.3.1 and adding exceptiongroups fixes the problem= <jpoiret>i'm building mesa rn, do you want me to send that patch? <apteryx>ah, I see; 1 failed test: test_raising_repr <jpoiret>(ie. upstream's explanation would work if we had updated python to 3.11 but that's not the case0 <jpoiret>i'm not a fan of hastily updating packages like this though, since we might be missing some removed dependencies or tests that now work but alas <jpoiret>the "new" behavior should only happen on python 3.11, but that's not true for us for some reason <jpoiret>also, the CI evaluation is in progress, andreas restarted it recently <jpoiret>it's currently testing nss of course <irfus>minima: have you tried 'M-x guix ret E`? <jpoiret>I don't think they're going to answer anything other than "update to 7.3" <bjc>weird. i'm getting supposed build failures on my offload server, but the build logs are just a couple lines about updating substitutes from bordeaux and ci <old>python-msal can't build anymore D: <jpoiret>substituting /gnu/store/s84c0p27gf7rb0g4w85cqs150zjxyr7z-rustc-1.54.0-src.tar.xz... oh no <jpoiret>yeah, the CI evaluation is in progress unfortunately <jpoiret>it has to build nss which takes ages <PurpleSym>Was gonna look at Haskell on i686 today, but I don’t have time to build the entire chain up from GHC 7 😕 <jpoiret>maybe we should've recognized that merging staging now was a bad call <jpoiret>at least given the current focus on core-updates <apteryx>is it just python-pytest thus far blocking everything else? <bjc>what was the reason for merging staging when core-updates is seemingly on the near horizon? <jpoiret>merging master back into c-u was the part that took longer than initially planned, hence the delay with CI <bjc>i get merging staging into c-u, i'm wondering why it was merged to master first <apteryx>ACTION pushes pytest 7.3.1 which builds <jpoiret>it keeps it at 7.1.3 but makes it build <jpoiret>that way there's less expected breakage <apteryx>I doubt 7.1 to 7.3 will cause much breakages, unless they deprecated a bunch of stuff <jpoiret>right, but it's better to hedge our bets and keep that question for later <oleander>Hello, what do you think about the asciidoc markup language as a documentation format? Did the Gnu/Guix project ever consider it as a replacement for Texinfo and if not is there a particular reason? I've been considering switching to asciidoc recently for my personal docu because I'm concerned about plaintext readibility. In this regard Texinfo and OrgMode do not stand out. I'm still conflicted on this since I like the "old <oleander>style" format of Texinfo and OrgMode has an huge potential but their syntax is too verbose compared to asciidoc. <apteryx>where was your pytest patch? doesn't seem to be on guix-patches <minima>jpoiret: re emacs path issue with guix home, oh i see; do you see any way to possible mitigate this or any workaround that would save me from having to restart the whole desktop after a guix home reconfigure? <minima>irfus: hm, interesting, i'm trying 'M-x guix RET E' now <minima>irfus: the 'guix-set-emacs-environment' info page sounds pretty menacing lol: "Note that there is no way to restore the original environment (you have to restart Emacs if you wish to do it)" <lissobone>Emacs users be like: what? RESTART?? Nononono! <lissobone>Coming from an Emacs user (writing this from ERC). <jpoiret>i do find it annoying as well that you can't just easily unlead features and reload them at will <jpoiret>it is supposedly supported but almost all packages don't support it <apteryx>we used to be able to just do guix-emacs-autoload-packages <bjc>is there a way to force a single build to offload? it seems like if i ‘guix build rust’ it always tries to build locally <apteryx>we should look into adjusting it so that it can work again with the new per-package elisp subdirectories <apteryx>it should offload by default if you have an offload machine configured <bjc>i would have thought, but it's definitely doing it locally <apteryx>does 'guix offload test' says it's working? <bjc>i can see ‘guix system build config.scm’ runs everything remotely, or even ‘guix build package1 package2 package3’ does, but not ‘guix build package’ <bjc>yeah, it's definitely working <apteryx>I hope the last evaluation completes... anyone knows a way to debug this kind of problem locally? <jpoiret>if so then it's just a matter of `guix pull` IIUC <apteryx>I thought that's what 'make as-derivation' simulates <jpoiret>hmmm right, that seems to be what it does <jpoiret>great news, nss seems to be done building on CI <jpoiret>the evaluation should not be too far off from being done <whereiseveryone>if it wasn't for rubber duckies not sure how i'd be able to code anything <lissobone>whereiseveryone: I am here, hello (answering the question from your nickname). <jpoiret>the log for the new c-u evaluation seems stuck 😞 <bjc>does the rust build chain invoke every rust release from 1.54 to current? <jpoiret>apteryx: by the way, I wanted to update qtbase to 6.5.0 but one of the tests takes 4G to link, which is then promptly killed on my laptop. I don't think disabling parallel building on the whole thing is an option either since it has 4k units <jpoiret>do you know what a good alternative would be? <jpoiret>bjc: each subsequent version uses the previous one <mirai>oleander: asciidoc looks “cool” but there's no formal spec on it <bjc>jpoiret: dang. guess i'm going to be waiting a few hours <jpoiret>I think andreas manually started a build of the rust toolchain on CI at some point <jpoiret>but that may have failed or just vanished <jpoiret>interestingly enough, while building qtbase@6, I haven't yet gone into the rust part <bjc>it'll probably be faster to do it myself. my build machine is fairly powerful, and i only have to worry about the packages i use =) <jpoiret>it's been running for more than one hour now <jpoiret>bjc: oops, looks like we both submitted roughly the same fixes for openldap <mirai>oleander: it might not have the best reputation but XML / docbook is the best fit for things like these <mirai>since you really want to decouple the presentation from the information itself <jpoiret>mirai: you're going to have even more complaints than what we have right now with texinfo though : <bjc>jpoiret: good! i felt a little uneasy about the .so/.la changes <bjc>i figured it was a good time to kick out the crutch, so i deleted it <bjc>when else would it be appropriate if not now? <mirai>jpoiret: indeed, authoring XML isn't exactly the most pleasant thing to do compared to the lightweight markups <mirai>but in terms of expressive power / unambiguity? hard to beat <mirai>the lightweight markups always have some very weird edge cases <mirai>(xml allows you to adorn the text with semantic info which you can use to enrich $Reader$ experience) <mirai>in the same way that epubs do <jpoiret>bjc: it has too many dependents to break some extra stuff at this stage <jpoiret>mirai: ah, but I completely agree with the semantic pov, I was just pointing out that a lot of people might be against it <mirai>texinfo is okay for things like package descriptions and most docstrings imo <mirai>but for the gigantic thing that is guix.texi? (which is nowhere near completion?) <bjc>jpoiret: but surely those dependents weren't building, because openldap's build was broken? i thought working through all these issues before the master merge was the point of the current c-u activity <jpoiret>this is due to the staging -> master -> c-u merge <jpoiret>btw I don't know how useful it is to build everything from your patch or mine if it's going to be invalidated by the other <mirai>jpoiret: perhaps one way to convince the crowd would be to covertly do a (incomplete) demonstration of the Guix manual in docbook that showcases substantially tangible improvements <jpoiret>it would also pull docbook as a guix dependency <jpoiret>ah, but it does already pull it through po4a apparently <bjc>jpoiret: eh, as long as the patches are basically identical, i don't care if i'm wasting effort. my goal is to just get my system to build. after that i can just use the substitutes when they become available <bjc>well, system and home. i suspect my home config is going to take a while <Guest70>how do I install ssh-keygen in guix? <apteryx>jpoiret: I've heard at least one application doesn't work well with qt 6.5 yet (jami), which is one of the main users of Qt 6 :-/ <apteryx>so the CI will be on its way to catchup with substitutes. I wished it had completed overnight though... Apologies for interfering with the CU effort :-/ <apteryx>jpoiret: there's also a new qt 5 version <bjc>i am having a tremendous number of problems with build offloading today, it seems <bjc>when i try and build my system it almost immediately fails with spurious errors, and i can't figure out why. is it possible that the c-u guix and master guix-daemon have issues talking to each other? <bjc>fwiw, i wasn't having issues before i pulled in today's merge of master <jpoiret>apteryx: my updating effort was mostly to reinstate the qssl test <Guest70>Did anyone has nix installed guix? Could you please share your config? <bjc>‘guix system build -k’ seems to have worked around whatever issue i was having, fwiw <spiderbit>I still have the problem with suspending my system, I wonder if there is a way to install pm-utils in guix <spiderbit>According to chatgpt I just need to guix install pm-utils, but that package does not exist :D <bjc>what issue are you having? i'm curious if it's the same one i am <spiderbit>well I think loginctl suspend or echo "mem" >/sys/power/state all means some sort of crash <spiderbit>my workaround is to have a 2nd x running with gnome <bjc>i think there's some device driver state not being handled, possibly due to lack of blobs <bjc>i have better luck suspending when my wayland session isn't running, but it's still not 100%, and i haven't had the time to try and narrow it down further <bjc>what graphics chip are you using? i'm just on intel integrated from an i6-something <spiderbit>but they also said it's probably not the kernel <bjc>are you having the same issue w/ nonguix? <bjc>well, i guess it's not a blob thing, then <spiderbit>I think my amd machine would not boot or if so not enter X at least <bjc>i suspend by writing ‘mem’ to whatever that sys path is, fwiw <spiderbit>I just looked in the mailing list find nothing <bjc>this is supposed to all be handled by the kernel, from what i can tell. there used to be other packages to hande suspension, but they were mothballed when the kernel support improved <bjc>my screens go dark, but my power button light never turns off, and the computer continues to draw ~idle wattage. no solution except a long-press to power-off and then boot again <bjc>when it does work, everything turns off, including the power light, and power usage drops to around 2 watts. tapping the power button brings everything back up again <spiderbit>external dac? fancy keyboards, usb bluetooth <bjc>i do have all those things, except bluetooth <bjc>no, keyboardio model 100 <bjc>yeah, and it has issues with power management already <bjc>i might try and see if that's the issue <bjc>yeah, my usb setup is kind of insane. i have a bunch of kvms and switches to handle all the different computers and virtual machines <spiderbit>no on this pc I use no kvm but yes maybe installing the trackball directly could help or something... but usb can cause problems <bjc>i'd be curious. theoretically usb shouldn't cause these issues, but who knows <bjc>gnome might be going through some extra steps to ensure devices aren't in use before suspend <spiderbit>after crash I did remove all usb and connected another keyboard and with that it also crashed <bjc>can you ssh in from another computer so you don't have to have anything plugged in? <spiderbit>but I doubt it's the problem I just search the log file <bdju>jpoiret: master I think. just the normal thing. <jpoiret>it's just been merged iirc so that might be possible <bjc>i was never able to find logs for it, though there's a kernel flag you can supply that'll tell the kernel to save some variables between boots to help diagnose these issues <bjc>again, thought: i haven't tried it myself <spiderbit>I saw something in the logs but not sure it's helpfull <lfam>ACTION learns about `git clone --filter=blob:none`, which is a space efficient way to clone development repos that will have reliable internet access <lfam>"These clones download all reachable commits and trees while fetching blobs on-demand. These clones are best for developers and build environments that span multiple builds." <lfam>Maybe useful for fetching things in Guix <spiderbit>hmm can it be disabled... would there be uhci driver work or something <spiderbit>or can you force to unload it before going into suspend <bjc>you could blacklist it, but that seems extreme <bjc>i don't think you'll be able to unload it since you probably have devices attached to it <bjc>no, i mean blacklist the driver so the kernel doesn't load it <spiderbit>My trackpad had always worked. But now it still works, with no error message! <bjc>some driver, probably <bjc>ps/2 related, i guess? that wouldn't likely apply here <bjc>how'd you get your error log, btw? dmesg? <spiderbit>hmm the last bug is interesting because from this year <spiderbit>I think the problem might be on the "pci" or "pci-e" bus level <bjc>the usb hangs off the pci-e bus. it's more likely an issue with the usb controller or one of the devices attached to it <spiderbit>I had nothing on it but a different usb keyboard <bjc>do you have any pm stuff enabled in your bios? <bjc>i think i have resume-from-usb on, but i'd have to check <spiderbit>otherwise under nixos it works on the same machine without probs <bjc>the bios plays a large part in orchestrating the suspend/resume, so it might cause problems <bjc>is nix running the same kernel major.minor? <bjc>i've been having this issue since at least 6.1, but i wasn't messing with power management before then, so i can't say how long it's been a problem <spiderbit>I am pretty new in guix so I can't say that too <bjc>well, if nix is on 6.2 and you're not having the issue, but guix+nonguix are with the same kernel, then it's not the kernel, at least not directly <spiderbit>I could go there and look... is there a way to pin down a older kernel version for nonguix that should be doable... but probably I have to compile it then :D <spiderbit> (first (lookup-inferior-packages inferior "linux" "5.4.21")))) <cel7t>Could someone please guide me to the right resource for writing tests? I've recently made a commit to Guix for which I need to write tests, but there's no (easily accessible) documentation for the same <bjc>guix tests are written using srfi-64 <bjc>past that, there's no docs that i know of for guix-specific things <cel7t>I'll just read the code in that case :pain: <spiderbit>probably still older channel on that machine <bjc>that's like a year old, right? <spiderbit>don't know can I see somehow from outside what channel I use in nixos :D <spiderbit>It seems 5.15 is the last 5.x kernel in nongnu <spiderbit>should be new enough for me at least for a test <bjc>Guest70: there's a nix package, but that's all i know <bjc>spiderbit: let me know how that goes. and thank you for digging into this! <Guest70>spiderbit do you by any means, how to this ? <ecbrown>Guest70: guix + nix sounds like a recipe for disaster <zeropoint>does anyone know of a mechanism in guix for automatically rolling back a change if a boot fails? <spiderbit>something like that, but not sure if all this is neccesary <spiderbit>error: selector 'joe' matches no derivations <spiderbit>how do I pin now linux package to a specific version in guix :D <Guest70> (kernel linux-libre-5.15)(operating-system <Guest70> (kernel linux-libre-5.15)(operating-system <Guest70>like that, somehow the chat get mixed <zeropoint>I have a headless server at home which I've installed guix on and can configure via ssh, but I've messed up disk configuration and can't access the server via ssh and had to open up the box to roll back the previous configuration <zeropoint>hoping there's a way to do something like automatic rollback after 10 minutes or something if I don't disable it <spiderbit>ohh I tihnk 5.15 worked without the 106 part <spiderbit>now let's hope it's a supstitute and I don't have to compile it <spiderbit>btw the more comfortable way to suspend is loginctl suspend <andreas-e>jpoiret, apteryx: Thank you for figuring out the python-pytest problem! No regrets for merging staging: We wanted to get rid of both branches, and I still think merging staging first was the more natural thing to do. It was supposed to hold the less disruptive changes. <sneek>Welcome back andreas-e, you have 1 message! <sneek>andreas-e, jpoiret says: nss built fine, but python-pytest is broken <oleander>mirai: they are about to get a spec and there aren't many alternatives. <unmatched-paren>was staging merged today? i thought i saw someone mention that earlier <bdju>what is python-pytest-trio / python-jeepney a dependency of? having trouble skipping the failing build <andreas-e>1.83.1 was apparently introduced in staging/ <andreas-e>bdju: You can run "guix refresh -l python-pytest-trio". <unmatched-paren>getting rid of staging and core-updates definitely seems a worthy goal... <andreas-e>Yes, that is the goal. And move to feature branches where different teams would work on specific goals in their respective realms. <bdju>andreas-e: hm it lists 36 packages and I'm not sure which I have. will have to just wait to upgrade I guess <bdju>I manually checked my manifest for a few and didn't see them <andreas-e>The problem with staging and core-updates is that everybody dumped their unrelated changes there. After a while, nobody knows what is changed and nobody feels responsible. <andreas-e>bdju: On core-updates, I get this: "Building the following 35 packages would ensure 74 dependent packages are rebuilt" <andreas-e>So there are 39 packages between the python-pytest-trio and the ones that are listed. <andreas-e>Probably you installed one of them. I remember them from calibre. Which is rebuilt when you build emacs-calibredb, the first package in the list. <andreas-e>bdju: Do you see problems on master or core-updates? <bjc>oh boy: guix offload: error: corrupt input while restoring '/gnu/store/guix-A1hLYi/lib/ghc-8.4.4/ghc-8.4.4/libHSghc-8.4.4_p.a' from #<input: string 7f832fe14cb0> <old>jpoiret: python-msal can't build from latest guix-pull <old>commit: 7c7853d269fe53271dd35d5bd941d18a2cb55120 <bdju>andreas-e: master, I'm just a regular user trying to update <andreas-e>Potentially the recent staging merge broke the python-pytest-trio package. CI is not yet far enough to have built the package on core-updates, so it may fail there also... <bjc>python-cffi definitely broke <andreas-e>Did you install calibre? In that case, you could try to upgrade with "--do-not-update calibre". Or try to guess which of your packages requires python-jeepney (which itself requires python-pytest-trio to build). <unmatched-paren>bjc: that just looks like a network error (it's pretty misleading :)) <bjc>considering the box is directly attached with an ethernet cable, that's surprising <bjc>i'll try pulling again <spiderbit>Well I think it will compile now firefox... so no test till hours later / tomorow <old>jpoiret: validating 'msal' /gnu/store/7hsnxf4xzryih9h8nh91frhwk7wynhzc-python-msal-1.18.0/lib/python3.9/site-packages <old>...checking requirements: ERROR: msal==1.18.0 ContextualVersionConflict(cryptography 40.0.1 (/gnu/store/5123bahrirj0mxbclmaaq2yvqw0r1l4f-python-cryptography-40.0.1/lib/python3.9/site-packages), Requirement.parse('cryptography<40,>=0.6'), {'msal'}) <old>it works if `guix build --with-latest=python-msal python-msal' so I guess just bumping the version of it should fix the issue <old>oh gosh now I have a build error on rust-1.54 <old>can't update my home <bjc>that built for me earlier today, post master merge <podiki[m]>old: yeah i'm seeing that on a different channel as well hrm