IRC channel logs
2025-10-14.log
back to list of logs
<scrambler>@FuncProjLinux projectile is key to how i handle navigation <FuncProgLinux>scrambler: I also use projectile, but I'm thinking about moving to project.el <mra>scrambler: I just use project.el. works fine for me <mra>my computer is largely a glorified latex compiler anyway <Kolev>mra: I want a fancy Emacs TeX typewriter. <FuncProgLinux>I give up with sidebars ._. all packages have a "but" in them. <FuncProgLinux>Neotree's nerd-icons detection sucks. Treemacs is way too much. I'd rather un-learn those and use dired instead. <Kolev>DIRED: The first, the last, and the ultimate file manager. <Kolev>I'd like my Sway desktop to automatically mount and open volumes in DIRED. <FuncProgLinux>Kolev: I'll just have to decipher how to make it more evil. So far I only use it to manage my server via SSH <Kolev>Evil? Do you have Evil Mode enabled? :P <FuncProgLinux>Oh and to open projects inside podman containers. I really like TRAMP, specially because on the blue electron editor you need an extension to do that <FuncProgLinux>Kolev: I moved to emacs because vim/neovim was lacking for me :s and I didn't like that the plugins were a language soup. Some vimscript, some python, some typescript... <Kolev>FPL: There's a big vi community using Emacs. "Evil Mode: How I learned to stop worrying and love Emacs." <FuncProgLinux>Kolev: I'm pretty sure there's a video pitch with that same title on youtube <scrambler>@FuncProgLinux if you don't have it already, I think that evil-collection brings evil mode keybindings to many that don'talready have it, and then customize from there using general <FuncProgLinux>scrambler: I do have it :P I had to do some overrides on eat because I had dual-vi mode. The one on bash an the one on the eshell lol <apteryx>did something change with the qemu firmware recently? trying to boot an older vm with virt-manager, it fails with a "unable to find efi firmware" <apteryx>ah, managed to start it with gnome-boxes <apteryx>lol, now ext4 corruption in that debian vm <apteryx>ACTION wanted to check something quickly <adanska>currently working on fixing mutter on gnome-team. needed to update python-dbusmock, which in turn has required tweaking in a few packages. <apteryx>ACTION just discovered a fresh Guix install on Ubuntu using our installer gives the error: guix shell: error: mkdir: Permission denied: "/var/guix/profiles/per-user/user" <apteryx>I'll open an issue when I get a chance <adanska>should I put my PR for the python-dbusmock updates seperate from my mutter fix PR? One depends on the other so I dont think i should, but looking for a second opinion :) <apteryx>adanska: in the same pr will be easier <finthecalculator>hi all, do you know what's the reason for /etc/letsencrypt/{live,archive} to be readable only by root? this prevents services that need to load certificates to run with unprivilieged users. would it imply a security risk to make them readable also by others? <mra>finthecalculator: this folder contains private keys. /etc/letsencrypt/live/<domain>/privkey.pem <mra>if the web server daemon runs as a non-root user (as www, maybe), you could change owndership of the certificates to the web server's user <mra>but you shouldn't make them readable by anyone <finthecalculator>the keys themselves are already readable by anyone as far as i remember. it's just those directories. also I'm not sure if it's better to have (say) an irc bouncer running as root or having those files readable by the world <mra>finthecalculator: i prefer to run things in containers, so running an irc bouncer as root isn't a bit deal, since it's only root in a container <mra>if you aren't using containers, you really probably should not run an irc bouncer as root <mra>every daemon on your web server should run as a user with the minimum permissions that it needs to do its job <elevenkb>Hey there, shepherd has recently been consuming too much of my CPU. Additionally, when I run "sudo herd status" the command hangs. Is there any way to debug this? <finthecalculator>mra: i feel the same, but atm Ican't run soju as unprivileged because it needs access to the certificates. in case no one sees a big risk in making the directories readable by all, in addition to the keys themselves, I'll send a patch to change this. or at least make it configurable in certbot-service-type <ekaitz>flypaper`: it looks good, I need to test it and push it <ekaitz>flypaper`: maybe I'll propose some changes when I do that, but right now it looks good. It's just that I'm busy :) <flypaper`>ekaitz: Thanks! CI seemed to be happy with it. Take your time :) <mra>maybe i should just apply to join the core team so that i can review my own pr :P <mra>work smarter not harder <ekaitz>mra i took a look to it but it goes beyond my knowledge <ekaitz>and you should join the core team <ekaitz>I need to learn the guix internals a little bit better, the nars, the bags and all that <gabber>mra: joining teams is allways a good idea, but reviewing your own PRs not so much <mra>gabber: yeah, not so much a serious proposal <mra>ekaitz: i thought about offering to join the core team, but my knowledge is pretty limited. plus, i've made very few actual contributions to guix <ekaitz>mra: being it a team is not a big deal, you still cannot commit :) <mra>ekaitz: oh, i assumed that all team members had commit access <ekaitz>for commit access we could take a deeper look to your contributions <mra>well, i'll read a bit more about what being a team member entails. <mra>if i do join a team, it would probably be core. seems the most interesting to me <ekaitz>mra: you don't have to do anything, but you'll get emails of very interesting PRs so you might be triggered to review them <elevenkb>mra: I'm a guix user interested in your PR... Could you please link to it? <gabber>mra: imho joining a team is more about will to learn more about a thing than a badge of honor telling others how much you already contributed <apteryx>mra: time to read/review and interest to learn is all that is needed to join a team :-). I think you'd do just great. <mra>ah, this is all very encouraging. thanks! :) <ekaitz>flypaper`: i'm going to remove some (most) of the comments <ekaitz>flypaper`: also I understand you want to stay anonymous but adding some email address to the author is useful <flypaper`>ekaitz: i have an email that maps to for this irc name, should i keep the author the same or also use this nick in the commits? <ekaitz>flypaper`: do whatever you prefer but your git config doesn't have any email, and that's not great if someone finds some issue in your code or anything like that <ekaitz>it's not critical right now, but it could be good <ekaitz>maybe it's just me but I'm hating the web-review workflow actually <flypaper`>ekaitz: yeah, i'm trying to use fj. Simon is has also been vocal about his unhappiness about it on mastadon. <ekaitz>and sooner or later I'll won't use vim either <gabber>ekaitz: going full nano or what? <ekaitz>i plan to write my own editor someday <ekaitz>in order to fight against this feature fomo <ekaitz>i learned a lot about the editor I use, and I use tons of features but I'm not sure if that's actually very good, really <ekaitz>i'm always thinking I'm missing this and that <ekaitz>and I'm always lost in configuration and configuration and blahblahblah <ekaitz>those things don't let us focus on the important things <ekaitz>flypaper`: back to your PR: now phases don't need to return #t <ekaitz>and you have some screwed up indentation, but I'm already fixing that for you, so don't worry <flypaper`>yaks be getting shaved. I have a person i help out with guix stuff, and we always end up wandering into their emacs-config. <flypaper`>ekaitz: ah phases returning #t. I wonder why I even wrote that still, slip of mind? whats the indentation i messed up? then i can see if i can fix my emacs to do the right style in the future <ekaitz>flypaper`: the `add-after`s you added <mra>alright, i sent an email about joining the core team :) <mra>thanks again for the encouragement <mra>ekaitz: the manual says that "Anyone with interest in a teamβs domain and willing to contribute to its work can apply to become a member by contacting current members by email" <mra>so i assumed that an email was the correct way to go about things <ekaitz>in my case I just added myself to the teams file <mra>although I'm sure that a PR also would have been fine lol <ekaitz>civodul will be happy because he sent an email about adding more people to the core team recently <ekaitz>ACTION is happy when civodul is happy <flypaper`>ah, specifically the the indentation of their (lambda argument? Ah, think that was because i always forget that the phase should get a name in `add-*`, but not in replace. Guess i should make it a habit (/ setup my emacs to ) to `indent-region' the package when im done there. <mra>ekaitz: the email from ludo is what made me consider joining! <ekaitz>flypaper`: you also have `guix style` <flypaper`>ekaitz: ah yeah thats true, should use that. <ekaitz>flypaper`: also the dirlocals thingie you emacsers use, that says which things should be considered special and which shouldn't so your indentation works as everybody expects <ekaitz>anyway, merged! congrats to flypaper` ! <ekaitz>is this your first contribution? <mra>flypaper`: congratulations! <mra>my first contribution had to be reverted lol <mra>hopefully yours fares better o7 <ekaitz>almost 12 years ago, I got my first patch merged in KDE and someone told me in IRC: Now you are a KDE developer forever in the history <mra>flypaper`: one must imagine sisyphus happy <ekaitz>every revert is a chance for learning :) <gabber>ekaitz: why don't you give `guix shell emacs emacs-evil -- emacs -nw --eval "(require 'evil)" -f evil-mode` a try? <gabber>it's kinda like your precious vim, just, like... you know <mra>ekaitz: first merged patch is definitely a super cool milestone. contributing to an open source project can seem really daunting <ekaitz>gabber: i know that, but also: no quickfix list, no tabe/find/... i don't use vim only for the keybindings... <ekaitz>gabber: i'm becoming too dependent on it, that's why I don't want to use it :) <ekaitz>emacs would make me have the same issue hahaha <gabber>ekaitz: i don't know what these words mean but i'm sure there's something quite similar in emacs <gabber>well then, off you go writing your own editor (: <ekaitz>exactly what I'm trying to avoid. I'm a simple dude. I want to use tools I can easily contribute to. <ekaitz>mra: that's why we should make it easier for people, not necessarily in the tooling side, but in the people side. I was very lucky to have the small KDE-Telepathy team with me when I started. They helped me a lot. I'll never forget them. <ekaitz>i didn't even know what a Patch was... and all that was before github became famous... they made everything very easy for me <mra>ekaitz: yeah, the social side of things is definitely tricky. guix is nice in that packaging some software that you use is a fairly gentle introduction to the process <mra>i do think that the move to codeberg helps somewhat with this. the pull request workflow seems considerably more beginner-friendly than the patch workflow <mra>ooh, i'd be interested to hear your thoughts on that <ekaitz>the pull request workflow is very hard to understand for people, the problem is that most devs have been forced to use it <mra>this is probably at least in part my bias as someone who started using git in the context of forges <ekaitz>let's put it this way: I know how I should make my tax declaration, but that doesn't mean it's beginner friendly <ekaitz>i teach git in companies, and they don't understand the difference between git and github <ekaitz>and they don't understand what a fork is, or why they need to do it <ekaitz>github has "corrupted" the way we think about git, and I don't think that has been for the good <ekaitz>when I sent my contributions to KDE, I didn't know how to create patches, and they told me how to do it <ekaitz>same with guix. I started to contribute to guix not that long ago. I learned how to send emails (WOW! emails! alien technology) and that was it <ekaitz>guix is way more complex than learning how to send an email <ekaitz>i could even argue that the email workflow was in the easier side of things -> autotools, building thousands of guile files, writing guile, learning what a macro and a gexp are... those are really hard things! <ieure>ekaitz, I think you're glossing over real issues people had with the email patch flow. In particular, sending a patch series was horrible and people regularly had problems with this, which increased the burden of reviewers. <ieure>ekaitz, We got extremely clear feedback from last year's survey that the patch flow was a significant pain point, which is why it changed. <ekaitz>ieure: those are the reasons why I voted for the move to codeberg, but still, I believe sending emails is something one can learn, with not much effort <ekaitz>the issue system was horrible, and not having a clear distinction between patches and bugs was bad <mra>ekaitz: imo, another pain point is that it can be really quite hard to manage large volumes of email, especially for people who are new to an email-based workflow <ekaitz>mra: I have 120 notifications on Codeberg, is that better? <ekaitz>people nowadays is more used to social media, and github-like platforms are just that <ieure>GitHub definitely wants to be that, it's horrible. <mra>ekaitz: i think that it's arguably better? like, if i subscribe to guix-devel, and i'm not familiar with an email-based workflow, it could be pretty annoying to deal with a flood of emails in my inbox <mra>of course you can learn how to deal with this <mra>ieure: yeah, i'm definitely not big on github. i finally moved away from it for good recently <trev>gmane and gnus is more user-friendly way into mailing lists in the modern times, IMO <ekaitz>mra: the slight difference is that my email is mine, and I can download it, filter it, search on it... I'm not tied to whatever the platform gives me <ekaitz>people is not used to that, but that doesn't mean it's harder <ekaitz>still, i don't think people is used to program in guile, but they do <mra>trev: i should really check out gnus. although first and foremost i should probably stop using proton mail. <ekaitz>it's like we are more open to learn the technologies a software project uses, but we are not open to learn their inner workings, their management, their tools... <trev>mra: i don't know if i recommend it for email, but interacting and catching up with mailing lists through gmane is really useful, compared to subscribing and flooding your email if you are like me and don't use notmuch or mu4e <flypaper`>mra: I use gnus, and its a beast. It's complicated, but it can do a lot. It really is the emacs of emacs :P <mra>i'd say that it's a matter of friction, more or less. people are willing to learn, of course, but the amount of "up-front" learning required matters quite a lot <mra>like, most people are only going to be willing to learn so much to submit their first patch <mra>once people are active contributors to the project there's more incentive to learn, but requiring people to learn unfamiliar tools up front is trickier imo <ekaitz>also just to clarify: I'm not regretting the move to codeberg. Our implementation of the email workflow wasn't great and had many issues. <ekaitz>specially for issues, it's way better now imho <mra>i suspect that there is value to some amount of friction in that it filters out junk? like, on github you can literally press a few buttons on their web interface, edit a file, commit it, and make a pr, all on the web interface <identity>let us make contributors jump throught hoops of fire so only the worthy may submit code for review <flypaper`>I thought the documentation on the info pages for the mailing list was really useful when i tried, just the general 'dauntingness' of contributing was more a reason of why i didnt before that. <trev>identity: is installing guix not a good enough hoop of fire? <mra>identity: i'm not trying to suggest anything so extreme as that <ekaitz>identity: i understand your point and agree <ekaitz>i just believe the human part could have compensated the barrier of entry <ekaitz>instead of just using what everybody else does, regardless of if it is better or worse <ekaitz>we could do many other things in a way that is more comfortable for people, but we don't <ekaitz>we chose to put the line right in the contribution process, and that's fine <ekaitz>but there's always going to be some elitism if we don't try to compensate for it with our human side <ekaitz>we chose to use guile, which is not easy to learn for newcomers -> but we could teach them and encourage them <mra>ekaitz: is guile really especially difficult to learn? i'd argue that it's unusually simple for new programmers to pick up <mra>i remember during my bachelor's degree our introductory computer science 101 course was taught in scheme for more or less this reason <ekaitz>mra: I have a friend that is unable to read scheme "because of the parenthesis" <ekaitz>for me, scheme is very easy to read/write, but also is sending emails <gabber>lisps are very hard to write without structural editing / paredit <gabber>i mean: can anybody count how many closing parens are needed anywhere in the code? <ekaitz>mra: look at the answer you got btw <ekaitz>re your proposal to be part of the core team <mra>ekaitz: oh, cheers! thanks! <old>ekaitz: to be fair, it takes some time to get use to parenthesis <ekaitz>but also to get use to {} [] and so on <ekaitz>i'm sure that those who learned scheme first are uncomfortable writing python <flypaper`>gabber: there's this little clip of Sussman teaching SICP where on a blackboard he manually goes to close all the parens of a function he wrote. for every closing paren he says what the function it is that it closes, and then ends with a 'think i got that right'. <old>that's why we have paredit and the like, so we don't count parenthesis like Sussman :p <flypaper`>actually learned python first, but i find lisps easier to program in. <trev>ACTION still indents scheme like C-like langs π <old>I realized the other day that the font color for parenthesis is the same for comments. Which make sens, you learn to filter these together naturally <old>(in my configuration) <ekaitz>i also learned python first and now i'm uncomfortable writing python flypaper` <gabber>flypaper`: from the SICP lectures! i know that. kinda proofs my point, no? <flypaper`>ekaitz: yeah, it just changes how you think. <gabber>old: not sure if i understand. so you don't use rainbow-delimiters-mode? <identity>it was quite some time since i missed a parenthesis in my code, and i do not use paredit/rainbow-delimiters/whatever <old>Parenthesis are colorized with a light-cray, just like comments <old>so my brain can ignore them more easily <mra>i can write lisp just fine without those packages, and i don't use rainbow-delimiters, but paredit is just wonderful <gabber>identity: i more often than not get some errors due to quick commenting out of one but not the other paren <identity>(+ 1 #;(this is a comment, and the whole expression evaluates to 4) 3) <flypaper`>i found #; to been incredibly useful and i really miss it in emacs-lisp because expression-based comments make a lot of sense in a language thats not line-based <identity>before elisp gets #;(datum comments) it should get #| block comments |#β¦ <old>identity: eh I did not knew that. I usually have to paredit-comment-dwim after selection the whole s-expr <old>ehh does not work well with paredit with multi-line s-expr <identity>βscheme-modeβ of gnu emacs is quite bad at #; <identity>i guess elisp has #@N to skip the next N characters, of questionable use outside of the output of the byte compiler <flypaper`>identity: how do you mean quite bad at #; ? in an `emacs -q` a #; does give the entire sexp the comment colors <flypaper`>(though with a half-second delay for finding thec closing bit) <identity>flypaper`: it does that, sure, but some other commands do not treat it correctly <identity>flypaper`: none that i can remember off the top of my head, i generally use datum comments only temporarily <FuncProgLinux>Question. If a package requires a "next" version of another package, is it suitable to be submitted as a merge request, on a single merge request? <vagrantc>FuncProgLinux: not sure i understand the distinction between "merge request" and "single merge request" ... <vagrantc>any chance in general should be submitted as (part of) a merge request ... <FuncProgLinux>vagrantc: Two packages on a single merge request. One commit for the next version and one for the updated package <FuncProgLinux>I'm eager to test the latest mate-panel but it needs libwnck v43.0 or later. We have v40 and it would trigger rebuilds on most desktop environments since it's one of those fundamental libraries <vagrantc>that sounds like a reasonable way forward <vagrantc>e.g. add the next variant in one commit, update the package in another, one merge request for both commits <vagrantc>i think one of the biggest improvements of switching over to codeberg, that i have already almost forgotten about, is submitting multi-commit patch series as merge requests :) <Rutherther>vagrantc: I really don't understand why GNU hasn't updated the debbugs to support in-reply-to for patch series <FuncProgLinux>vagrantc: I like forgejo because while it's familiar is not spamming me with "use our AI, free until it's not!" <FuncProgLinux>Yesterday I got a request to add my channel to the toys project. I liked that forge sourcehut I think <FuncProgLinux>I was able to send my patch via email, no login required. I liked that, felt minimalist lol <elevenkb>Hello there I can't run guix system reconfigure anymore because I get this error: <elevenkb>guix system: error: unrecognized boot parameters at '/var/guix/profiles/system-173-link/parameters' <identity>FuncProgLinux: sr.ht being minimalist and using email as The way to contribute are core parts of the design, Drew DeVault (the founder of sourcehut) is all about them; he is also the guy behind the <https://git-send-email.io/> tutorial <elevenkb>Rutherther: Rutherther: It contains 58 bytes methinks. <Rutherther>ieure: what about cgit? And if you can stand that, what do you cannot stand about sr.ht? <vagrantc>Rutherther: pretty sure it did support in-repy-to ... but sending long patch series was still error-prone, even with tools to help <Rutherther>elevenkb: how do they look? It should be a scheme file with (boot-parameters ... <vagrantc>it's just a larger number of interactions to send multiple mails <vagrantc>ACTION wants to like sr.ht but struggles with it, and has been used to email-oriented workflows for decades <Rutherther>vagrantc: yes, but larger number of interactions is because in-reply-to is not supported. If it was, it would be a simple single git send-email like you can do with the debian instance of debbugs, sr.ht etc. git send-email automatically chains the e-mails with in-reply-to so that they can be grouped <Rutherther>elevenkb: okay, so the most common file corruption where the file doesn't really get saved to the disk <FuncProgLinux>Very post-90's of my part but how do you handle CI/CD on sr.ht? <vagrantc>Rutherther: i definitely got patch series that had the in-reply-to headers set ... but maybe my mail client is doing the right thing and gnu's debbugs ... was not, somehow? <FuncProgLinux>I on my part cannot handle Gitlab, it's way too much information :s <Rutherther>vagrantc: they will still have that set, yes. My point was that you need to send them to a different address, the first one to guix-patches@gnu.org, the second to issue@debbugs.gnu.org, if in-reply-to was supported for grouping emails, you would just send all to guix-patches@gnu.org <elevenkb>Rutherther: Yep system-172 has a valid looking paramters file. Let me see if I can boot into it, brb. <vagrantc>nothing to streamline contributions like ... send an email, wait for it to come back, and then reply with further content to a different address ... <vagrantc>ACTION mostly avoided patch series to avoid that <Rutherther>vagrantc: and since this is already implemented in Debian's debbugs, it seems like only laziness of the administrators of the GNU debbugs instance :( <vagrantc>i wouldn't guess lazy so much as ... so many things to do and overly vested in an old fork, possibly due to decisions made by people long gone <identity>gnu sysadmins still live in the late 90s, with all the things that entails <FuncProgLinux>Rutherther: I see, so I can spin up "runners" like other services as usual <elevenkb>Rutherther: I can't really, switch back to the working one. <elevenkb>I'm using a Lilah's uefi-uki-bootloader, and am not sure how to get it to boot into a previous system. <Rutherther>elevenkb: don't worry about it. Just make the /var/guix/profiles/system a symlink to /var/guix/profiles/system-172-system. Then remove /var/guix/profiles/system-173-system and then reconfigure. It doesn't really matter you're touching current generation's link here, it's not used for booting, just by the guix system command. Unfortunately guix doesn't provide a way to recover from the situation you ended up in, so manual removal of the generation is... <cluelessguixer>It appears as though the only difference between whether or not I can connect to a graphical console through Virtual Manager is whether or not the Guix system has a DE er not. <ieure>Rutherther, Sorry, had a ton of meetings. Sourcehut gripes: wasn't clear that it's for-pay, so I signed up and was surprised I'd have to; you have to log in to each *feature* separately, so when I logged in and went to issues and got another login page, it just seemed broken. No way to delete my account, I had to email Drew and he seemed annoyed that I even wanted to. <ieure>Rutherther, Not sure if any of those things have changed since. Decided it wasn't for me, never used it again. <Rutherther>ieure: yeah, pretty much all of what you mentioned has changed :D <mubarak>I want to install kde plasma with "sddm" as a display manager. I don't want "gdm" to be installed nor any gnome package. So is this config OK? <Rutherther>mubarak: no, because %desktop-services contains gdm service type. You can use modify-services to remove the gdm-service-type out of %desktop-services <identity>(modify-services %desktop-services (delete gdm-service-type)) <FuncProgLinux>mubarak: I use MATE as well but with lightdm, I can send you a paste of the full services config if you need a reference :) <meaty>does anyone here use the-dam.org? what is it like? <meaty>i am wondering how populated it is <tux0r>oh cute, guix AND plan 9 on one machine? i'm sold <mra>the-dam.org looks pretty cute! <gabber>meaty: i was wondering the same. from my impression: if the 5 of us join then it's at least 5 more (: <ieure>FuncProgLinux, There's no security, it includes however much of whatever kind of spam you like. <FuncProgLinux>ieure: I didn't know about that kind of community machines. It does seem interesting though, I came to know of plan9's existence because of Go <ElephantErgo>Hey everyone, I'm having some trouble with guix deploy, and I was wondering if someone could help point me in the right direction? <ElephantErgo>I'm getting an "invalid field specifier" for "%system" in the operating-system field for the machine. I'm not totally sure what's going wrong <ElephantErgo>/home/maddie/Guix/configs/PinebookProInstaller/DesktopLinuxLibre/20251014-0924.scm:88:2: error: my-system: invalid field specifier <ElephantErgo>Or, that should be "%system" rather than "my-system", but same message other than that <Rutherther>ElephantErgo: I think the issue is that you're missing (gnu machine) module import. Not sure why the error message looks like that <gabber>i often get "invalid field specifier" when i mess up my parens (either a missing one or one too many) <ElephantErgo>I think that did it! I was wondering about that, because I was wondering if I was creating the wrong type of "operating-system". I'm rather new to Guile Scheme, though, so I'm not sure if that's how that works or not <ElephantErgo>Now that the use-modules are fixed up, the issues now are more straightforward SSH configuration problems that are totally doable π <Rutherther>ElephantErgo: Yeah, I suppose here the operating-system has been interpreted as a 'constructor' for operating-system record rather than a field. The same name field can be confusing when you then have (operating-system (operating-system ...)), people sometimes omit the second from what I saw <ElephantErgo>So I had another question, and this is in aggressively noob territory... I feel like I don't totally "get" Avahi? I'd love to be able to ssh across LAN using hostnames, so I could do something like "ssh maddie@Desktop.Guix.Maddie" and have that mean something. That's something I can potentially set up, right? Or am I misunderstanding something? <ElephantErgo>I feel like this would be especially nice for repeated use of Guix Deploy π <ieure>ElephantErgo, That's basically what it does, though you'd use the host "desktop.local" to get to a machine with a hostname of "desktop". <ieure>ElephantErgo, But generally, run Avahi on all systems you want to participate in mDNS and it works. Except for when it doesn't. <FuncProgLinux>Sorry to step in but...can that be used to provision substitutes in LAN? :L <ElephantErgo>FuncProgLinux: Oh that's an excellent question, I wanna do that too now! <ieure>FuncProgLinux, Guix natively supports mDNS advertising and discovery of local substitute servers. But you still have to authorize their keys to use the substitutes. <ElephantErgo>Oh cool! So they'll start providing substitutes to each other automatically if they have the authorized keys? <ieure>ElephantErgo, They need to be running guix-publish-service type, but yes. <FuncProgLinux>ieure: Oh, so I have to configure a dedicated server :( I though I could share packages from my desktop to the laptop <ieure>FuncProgLinux, You don't have to configure a dedicated server, not sure where you got that from. <mra>FuncProgLinux: you could, it would just only work when your desktop is on <ieure>FuncProgLinux, You can configure guix-publish-service-type on your laptop and desktop, and have them auth each others' keys, and it should work. <ElephantErgo>Is "guix archive --generate-key" and "guix archive --authorize < key.txt" still the easiest way to trade keys, or is there an easier way between two Guix systems? <ieure>FuncProgLinux, That said, I've never done this myself. Since you have to change your system configuration for each machine anyway, it never seemed super valuable to me. I have a single build/substitute machine. <FuncProgLinux>ieure: Will do! Some testing I do takes ages on the laptop, specially when I have to rebuild an entire desktop :s thank you for the info I now have homework lol <ieure>ElephantErgo, You want to use the public key from the keypair generated when the system installed. <ElephantErgo>Oh huh, I didn't know such a thing existed. Where are those locaed? π€ <ieure>Maybe there's some way to sign archives with a shared key? That'd make this much more useful, since you could have N machines with the same keypair, so not need to auth every single box. <kjartanoli>ElephantErgo: I think on GuixSD the authorization is handled by extending the guix-daemon service. <ieure>ElephantErgo, /etc/guix/signing-key.* <kjartanoli>You can also download the key from the web server provided by guix-publish. <ElephantErgo>kjartanoli: I'll have to take a look at that, because that could definitely make things easier <ElephantErgo>I'd love to go wild on using the combination of automatic substitutes and build offloading. Just leave it to the devices themselves to figure out the easiest way to get the packages they need π <ieure>ElephantErgo, I don't think clients are smart enough to do this actually well. <ieure>ElephantErgo, I have one machine running Cuirass, guix publish, and it's an offload server. Some packages are slower to build remotely due to IO overhead outweighing CPU. Emacs packages are almost always faster to build locally. <ElephantErgo>I see~ That makes a lot of sense. I imagine there could be a bottleneck that would add up with a lot of small packages that try to get knocked out "real quick" over a network <ieure>Going to depend on hardware a bit. Cuirass + publish is great, Cuirass polls your channels and builds whatever things you ask it to, so you have subs when you need them. <ieure>Offload is a bit more of a mixed bag, in my experience. I think it's worth it if you have builds that take a really long time, either due to a slow local machine or a large codebase. <ElephantErgo>Oh, that's *excellent*. I'm totally gonna have to look into Cuirass and Guix Publish π <ieure>Having them all on the same box isn't the best. Offload will wait until the remote machine's load is low, but Cuirass is a spiky, CPU-intensive workload. So sometimes offload just says nope, try later. Which is the same problem you want to solve, really. <ieure>Slow local machines still have to compute the Guix derivation, which is slow even on beefy hardware. And you have to eat that, even if you have substitutes for everything. So I could see offload being useful in that situation. <ElephantErgo>That makes a lot of sense. If I'm doing background builds on the machine, it's alreayd occupied <ElephantErgo>This actually kinda makes me lean towards offloading a bit more on the basis that my primary usecase right now is around builds on underpowered ARM devices π <ElephantErgo>Oh, right, real quick, so with Avahi, did I sorta mess things up by putting dots in my hostname? I have Avahi running on both devices, I tried "Desktop.Guix.Maddie.Local", and I'm not having the name resolve π€ <ieure>ElephantErgo, Yeah, but you really need a high-powered ARM device to offload to. I'm not sure how offload interacts with cross-builds / emulated builds. But building aarch64 under QEmu is dirt slow, even with fairly powerful (Core i7-12700T, 32gb RAM) hardware. <ieure>ElephantErgo, Probably, yes. I don't know what Avahi is going to do with that. <ieure>I'm pretty sure DNS forbids periods in hostnames. <ElephantErgo>Good point on needing a ARM device for offloading. I've been daydreaming about some sort of beefier SBC for this purpose, and I'll have to play with that idea even more π <ieure>ElephantErgo, `guix shell avahi -- avahi-browse -a' will show you all the mDNS stuff happening on your LAN, you can probably figure out what Avahi is advertising your host as that way. <ElephantErgo>Interestingly, I'm not currently getting a peep out of either device, including one that doesn't have any periods in the hostname <ieure>ElephantErgo, What does `sudo herd status avahi-daemon' tell you? <ElephantErgo>Oh you know what? That device isn't actually running Avahi. I forgot to add that to the config for my Pinebook Pro installer π <ElephantErgo>Dang, you are a wealth of knowledge! π Thank you for all the pointers π <Rutherther>Phosphenius: you run the repl by "guix repl", then you ",use (guix gexp)" to get the local file in scope, then what I sent should work. Or are you getting an error? <Rutherther>I don't really know what else than a repl to use <Phosphenius>Rutherther: I guess the output is different on your host? ^^ <Rutherther>I haven't tried it, but I am pretty sure i twill be, yeah. It will be pointing to the original source of the channel for me <ieure>If only it had stack traces. <identity>it has stack traces, but it also loves to reuse stack slots, which turns values in the backtrace into βΉ_βΊs, which makes the backtraces of questionable useβ¦ <gabber>i want to transfer my Guix OS on my pinebook from extrenal SD card (32G) to internal flash (64G). should i just dd the whole device, cross my fingers and hope that works? <cluelessguixer>The mystery why graphical console appears to work on one Guix server, but not the other, remains... Asking AI just sends me around in circles since it refuses to accept that spice appears to be running and configured correctly. <FuncProgLinux>cluelessguixer: AI rarely knows anything about Guix/Scheme :/ <ElephantErgo>gabber: Hey, I'm trying to install Guix on my PBP as well! π <vagrantc>ACTION still has a several years old guix install on microSD for the PBP ... <vagrantc>was the first machine i installed Guix on before Debian <ElephantErgo>gabber: DDing to copy the image from the SD to the EMMC unfortunately won't work. There seems to be something in place that prevents the usable space for the Store from growing if you created the image using "guix image". I'm not totally sure what that was <vagrantc>should try and update it one of these days :) <meaty>i dont have a bouncer, was a verdict ever reached on the-dam.org <Rutherther>ElephantErgo: just to check, you aren't talking about the iso9660 image? <ElephantErgo>gabber: The usable Store space seems to more-or-less idle around where the size of the image is, which is more or less exactly what it needs to be to hold the Store size to support the image's contents <ElephantErgo>Rutherther: I'm not sure, honestly. I have rather limited context besides what I've observed over trying to blindly bang this out over the last weekend <Rutherther>yeah, the partition size is calculated off of the contents that will be put there to prevent 'waste'. You can resize the partition, and the fs on it <ElephantErgo>That was what was kinda weird for me, though. I resized the partition using parted, and it seemed to refuse to let the store size grow <ElephantErgo>...Nope. I didn't realize I had to do that separately π