<dissent> is there any documentation on how to use emacs packages downloaded with guix? <apteryx>florhizome[m]: on core-updates in general we are free to update core stuff to newer versions; so for example meson which has many dependents can be bumped to a recent version <apteryx>on master things get more complicated over time because some packages need new releases, but we can't simply bump the default meson package because it'll rebuild too many <florhizome[m]>I would argue the default can stay as is but the question is can we have newer "next ones" and does that need a patch :) <dragestil>Does anyone know how I can use xref on .scm package definition files? a simple example would be to find definition of search-patches. it does not work ootb <mekeor[m]>i usually ripgrep for "(define-public search-patches" or so <dragestil>search-patches is not a package though, more like a function <dragestil>not familiar with guile, are functions defined with define-public? <slyfox>define-public is a macro: guix/packages.scm:(define-syntax define-public* *mekeor[m] shrugs and smiles <nckx>florhizome[m]: Yes, you can add as many newer versions to master as needed. You can add this patched Meson, the very same one that's on c-u-f-b-c right now, to master, if needed. You can use this new Meson in other new or existing packages on master. The key is only that you don't touch the default version that the thousands of other Meson users use. I'm assuming you need a newer Meson here but the addr2line error is completely unrelated to Meson. <nckx>I might try your paste tomorrow. <apteryx>nckx: my ssh issue is resolved by the way (was that second autossh on the same monitor port...) good night! <jgart>dissent, you can just start installing emacs lisp packages and emacs will automagically find them <jgart>that's if you install a guix installed emacs <jgart>emacs is patched in guix to set up the environment variables and paths needed to find the elisp packages <jgart>you'll have to configure the packages once they are installed if you want them to be loaded at startup, etc... <kozo[m]>and what a joy it is when programming in common lisp when a sbcl-* package is installed in guix <jgart>kozo[m], are you using guix on a foreign distro? <jgart>I'm curious if the common lisp libraries are supposed to be sourced in a repl like the python libraries are <jgart>last time I tried on a foreign distro I had a difficult time <jgart>but I think it might of worked smoothly on Guix System <Jeremy[m]>it seems like all the desktop environments have some problems <Jeremy[m]>GNOME is slow and choppy, KDE lacks design and has too many options, MATE and XFCE are borderline unmaintained <apteryx>I don't think GNOME is slow and choppy? <apteryx>but then I use ratpoison, which holds in 5 MiB of memory. <Jeremy[m]>M6piz7wk[m]: I remember it like this, scheme is the little baby elephant, CL is the big beefy elephant <jgart>Jeremy[m], bspwm is the best desktop ;) <jgart>It'd be cool to package the whole pantheon suite from elementaryOS <Jeremy[m]>jgart: I definitely enjoy bspwm but I don't think my grandma would understand it 😄 <jgart>I'd like to package pantheon and help maintain it. I'll probably won't end up using it, though... <jgart>Jeremy[m], pantheon suite would be great for a grandma as well as a seasoned dev <M6piz7wk[m]>Do people really pay more for functional languages then for python and rustlang <Jeremy[m]>jgart: I've actually contributed a bit to Pantheon <jgart>would you like to work on packaging it? <jgart>maybe we can divide and conquer it <Jeremy[m]>* all the issues/PRs/etc. are on Github, a nonfree platform <Jeremy[m]>* developers don't seem to care much about free software (?) <Jeremy[m]>* basically piggybacks on GNOME for all the backend stuff, leading to "downstream syndrome" of tiny bugs and papercuts <Jeremy[m]>* performance is on par with GNOME, nowhere near XFCE/MATE/i3 levels <M6piz7wk[m]>Can anyone recommend me a free video course for guile? i am watching the scheme one by Dr. Andy Wicks that summarized materials by Prof. Marc Cavazza atm.. <jgart>I just got fuzzy finding windows set up with rofi and bspwm and I'm really liking it. <jgart>M6piz7wk[m], can you share that vid? <jgart>I don't think there is any free video courses specifically for guile <jgart>It'd be cool if they existed <M6piz7wk[m]>how else are people who hate reading like me supposed to learn it then~ <Jeremy[m]>I've thought about making a new desktop environment <Jeremy[m]>But idk if anyone else would want to contribute 😅 <jgart>how is it different from the others? <roptat>jgart, would you like to create a monthly guix documentation meeting in addition to the packaging meetings? :) <M6piz7wk[m]>hmm that video is apparently made by a person who is 97 yo <jgart>we could meet once for packaging/upgrading software and once for docs <jgart>or just once a month and decide to make it a docs meet <jgart>It depends what people are up for <jgart>Or, if someone wants to host the docs meetup I'm down to attend, of course <jgart>but I don't mind organizing it also <Jeremy[m]>jgart: idk, it would probably have a highly opinionated HIG/design system and a lightweight compositor (wlroots?) <roptat>I'm thinking doc might be easier to work on together <Jeremy[m]>and be a GNU project hosted on Savannah, etc. <jgart>It would be great to work on guile docs too <jgart>but maybe that would be part of the guix docs meet also on certain occasions? <jgart>I think helping guile also helps guix <jackhill>I'm very much interested in recipe writing for the cookbook! <jgart>but we only have so much time in a session <jgart>jackhill, are you still interested in working on the janet-build-system? <jackhill>cookbook seems to be the type of thing that could really benefit from group brainstorming <jgart>since jpm is no longer part of janet <jackhill>jgart: yes, I saw that! I meant to write to you, but time got away from me. <jgart>I spent last guix meetup just working on the cookbook with a new contributor <jgart>If y'all are down I can focus the next one on docs also <jackhill>with janet, I got to the point of the build system, where I got out of my depth, and needed to go learn more and haven't come back to it yet. <jgart>And then we can decide how we want to split those meets between docs and packaging <jackhill>I'm happy to have you work on it, or we could do it together <M6piz7wk[m]>> and when i press enter we get a list within a list that has a tree of directories <jgart>I'd prefer to do it together if you'd like at some point <jgart>I've been busy with work but I think I can sneek in some time for janet-build-system <jgart>Yup, I had read through those patches <jgart>jackhill, do you think next step is packaging jpm? <jgart>should jpm be bundled again with janet? <jgart>or we can keep them separate <jgart>since upstream keeps them separate <jackhill>jgart: I think it would be find to have them separate. <M6piz7wk[m]>... so i can just define a list and expand it in my (operating-system) instead ofbeing stupid <jgart>An operating-system is a scheme record <jgart>they are a big part of scheme data structures <jgart>haunt the ssg also uses records to model a page/blog <jgart>might want to see that code to for ideas <jgart>that is, a scheme record is usually implemented as a macro <jgart>it generates functions when you instantiate a record <roptat>M6piz7wk[m], append concatenates lists (append '(1 2) '(3 4)) -> '(1 2 3 4) <M6piz7wk[m]>why is cons not called prepend.. it seems like it would be much easier to remember <jgart>for example a guix package is a scheme record <jgart>and when you instantiate a guix package you get a package? procedure <jgart>and you'll see that that returns a boolean true <jgart>but bspwm is also an instance of a record <M6piz7wk[m]>> we have a two functions `car` and `cdr` what they stand for? nothing relevant <jgart>jackhill, I had read through those also :) <jgart>I'll give it another read, though <jgart>I'm still trying to understand jpm <jgart>and how it does what it does <jgart>car takes the head of a list <jgart>and cdr takes the rest of a list except for the head <jackhill>Jeremy[m]: cool! I think what I want is a project, or maybe just documentation, for using all of GNOME's behind the scenes plumbing and lets the user bring their own compositor/shell <M6piz7wk[m]>why not call it `head` and `tail` like a sane person then *M6piz7wk[m] should make a guile dialect <jgart>they have some historical reason for why they are called that way that I think references register machines or something <jgart>M6piz7wk[m], first from srfi-1 is probably nicer to use than car <jgart>guile should just have a rest procedure instead of cdr *M6piz7wk[m] goes to make standard and ban the usage of car and cdr in his code <jgart>M6piz7wk[m], learning the difference between lists and vectors in scheme will be a good way to spend your time also <jgart>and what they are optimized for <Noisytoot>M6piz7wk[m], (define head car) (define tail cdr) <apteryx>it feels nice to do without labels or core-updates <M6piz7wk[m]>jgart: wait there are different usages for first and car? <jgart>I forgot if srfi-1 provides rest/tail <jgart>if you look up the implementation of first in srfi-1 you'll see that it is just an alias <jgart>similar to how Noisytoot showed above <jgart>M6piz7wk[m], guile has a pattern matching module also <jgart>it's used in other implementations as well <jgart>I think they just vendored the code in mostly <jgart>would be cool to create a distribution of Guix System in the future based off of a dialect that runs on the guile runtime :) <jgart>it would be possible to implement something like janet for example, in guile <jgart>there's already a clojure implementation in guile called lokke iirc <M6piz7wk[m]>can't we just make guile to define those two to make the language easier for everyone instead of remembering random identifiers that mean nothing <Noisytoot>M6piz7wk[m], the names 'car' and 'cdr' compose well (cadr, caddr, cadddr, cdar, cdaar, cddar, …) *M6piz7wk[m] undoes his standard *M6piz7wk[m] also doesn't know what cadr, caddr, etc.. is <jgart>there's also second, third, fourth etc... in srfi-1 <Noisytoot>CAR = Contents of the Address Register. CDR = Contents of the Decrement Register. <Noisytoot>CAR = Contents of the Address part of the Register <Jeremy[m]><jackhill> "Jeremy: cool! I think what I..." <- Yes, this seems like a great idea. <M6piz7wk[m]>damned 97 yo professor treating me like a child that can't handle the truth <jgart>The only thing I've used from gnome for any stretch of time was tilix terminal <jgart>but now I'm back to hopping between alacritty and st mostly <jgart>M6piz7wk[m], there's also a vector-ref *M6piz7wk[m] is considering writting a rustlang thing that compiles into guile <M6piz7wk[m]>... which would be a terrible thing bcs declaretive vs imperative <jgart>How about a guile thing that compiles to nix? <M6piz7wk[m]>... unless i write the whole rustlang in macros and stuff <M6piz7wk[m]>jgart: bcs nixlang is designed to give you anxiety and ptsd from looking at JSON <jgart>so maybe you can just write guile instead <jgart>and have it compile to nix :) <M6piz7wk[m]>tbh just on theory i like guile more then any other lisp i know so far <dragestil>how do i start a service from a package installed by guix on a foreign distro? <dragestil>i just guix installed docker, but not sure how to start the daemon <jgart>you'd have to have a working shepherd I'd imagine <jgart>Guix services are Guix System services <M6piz7wk[m]>From what i learned about docker in the previous days i assume you need a docker-service-type that is made for that deployment <jgart>I don't think there is a way to run them on a foreign distro unless you have GNU shepherd replacing the foreign distro's init system <dragestil>i'll just uninstall docker from guix and install it on the foreign distro <jgart>you might be better of just using your distro's packaged docker service *M6piz7wk[m] would just define a service file for it <dragestil>M6piz7wk[m]: but you'll also have to install shepherd, no? <jgart>If your distro comes with a docker service why define one yourself instead of just using the service that's packaged? <M6piz7wk[m]>nah? just define what your init is supposed to do when you ask it to start and stop <jgart>for example I just use the docker runit service made available by void linux <dragestil>jgart: oh i'm trying to use guix as much as possible <M6piz7wk[m]>wait if it's guix in a docker providing a guix service then just install shepherd in docker and do `herd service start` ? <jgart>might be going down a rabbit hole <jgart>but might be fun to hack on gentoo <M6piz7wk[m]>check the service file for what it does for `start` and put that in your init then <dragestil>jgart: so you've been able to install all packages with services with void linux pkg manager <dragestil>without any conflicts with your guix installed stuff? <jgart>systemd is pretty baked into debian unless you do some serious forking like devuan did <jgart>I use guix mostly for development on void linux <jgart>For example, if I'm hacking on a python project then I might have a manifest with all the python libraries I'm using <jgart>Then, I'll use guix instead of pip, for example <M6piz7wk[m]>or bedrock linux.. afaik it has handling for various inits <jgart>I use doas on void instead of sudo <M6piz7wk[m]>so if you do `herd service start` in a stratum it should translate in it starting a service <jgart>I have a quasi bedrock setup on void <jgart>that's my bedrock arsenal of tools :) <jgart>they each have their pros/cons *M6piz7wk[m] doesn't know what xbps is <jgart>that's void's package manager <dragestil>any pkg manager is faster compared to guix... <jgart>but it doesn't do what guix does <jgart>so, I use one or the other depending on what I neede <M6piz7wk[m]>e.g. the argument that portage is better bcs it's faster then paludis <jgart>xbps is also simpler than portage <M6piz7wk[m]>only for portage to fail resolving dependencies without conflicts :p <jgart>and has a cleaner/better design than pacman <M6piz7wk[m]>is there even a package manager that doesn't have cleaner/better design than pacman <jgart>I like gentoo but I feel there is a lot of arbitrary/idiosyncratic stuff to learn with portage. Atleast with guix you're learning scheme. I could say the same for nix. <jgart>Let's just spend our time learning a great language like scheme. Life's too short. ***yang is now known as Guest6805
<jgart>scheme, ocaml, idris2, purescript <jgart>btw, let's package idris2. It compiles from chez scheme now instead of haskell <jgart>The implementation of what I want for pipg might be more complicated. It might need some string metric for doing the "right thing" <jgart>Noisytoot, yup, it has tables, structs, arrays, etc.. <jgart>janet doesn't have lists either :) <jgart>it has an interesting object system also modeled after Prototypal inheritance like javascript <jgart>I think it is definitely a lisp <jgart>It has macros, homoiconicity, it's parens-based...if that's a term like plant-based is... <jgart>Maybe the same can be said about other languages. <Noisytoot>it also uses # instead of ; for comments (although that does not make it not a lisp, just different from other lisps, probably without a good reason) <Noisytoot>Is there something like sly/slime/geiser for janet? <jgart>there's some sort of comint integration package for emacs <jgart>I just load my file in the repl <jgart>haven't been doing the sending expressions over thing <jgart>I think there's a vim package that's able to send over expressions from any arbitrary language with a repl <jgart>that can probably be used with janet <jgart>but emacs has janet support for sure for the usual things <jgart>maybe not as fancy as geiser but whatever <apteryx>that sounds an even worst idea than vim in emacs ;-) <nckx>(Actual, for once) morning, Guix. <jackhill>hmmm, ELisp isn't listed in the clients of tomorrow sections. Clearly that needs to be fixed :) <jackhill>(well, I guess it does have that with Guile's ELisp language) <nckx>apteryx: Ah, thanks for the closure :) I was wondering. <apteryx>is there a way to define a gexp such that if it produces no output, it doesn't error? <bdju>jgart: conjure looks cool, but it seems to require neovim 0.5 or newer, and the guix neovim package is too old <jgart>it has a ton of tree-sitter deps and we'd have to update all of our lsp servers for it to be viable <jgart>and rust is too old currently to build it <jgart>the rust packaged in guix, that is <jgart>It's packaged in parabola though... <jgart>bdju, what packages are you interested in working on? <bdju>jgart: I've added a lot of stuff to the guix wishlist. I'm not sure which ones I'm most interested in <bdju>my ThinkPad seems to thermal throttle a bit, so maybe the undervolt package would be pretty high priority <bdju>I ran NixOS on the same machine a year or two ago and a bit of an undervolt kept temps down pretty significantly, but I wasn't able to do the same on Guix System <bdju>oh, and aerc (the mail client) would be nice <bdju>I've been using it over ssh on a server running another distro in the meantime <jgart>tests are passing but of course double check and test <jgart>bdju, if you like aerc you might like bower <jgart>I need to finish it up but it's currently available from GuixRUs channel <jgart>A new version will be available very soon <jgart>I've used aerc and I prefer bower to aerc <jgart>bower is just a notmuch client. It uses your $EDITOR to compose and msmtp or similar to send <jgart>I use offlineimap to get emails <bdju>aerc has a few horrible bugs but I tend to like it when it's working. it logs out a gmail account I use constantly, crashes when pasting in text to the compose window pretty often, and sometimes changing which account I'm looking at crashes it. I just run it in a while loop now expecting a crash. <bdju>I have been meaning to use offlineimap or something like it. haven't gotten around to setting it up so it works with aerc. I've used it for manual mail backups but then aerc also separately fetches stuff <Jeremy[m]>Shouldn't gnome-online-accounts be patched to avoid recommending proprietary services (Facebook, Google, etc)? <jgart>Jeremy[m], luakit also needs to be patched to not have google as it's default search engine <jgart>I think even nixpkgs has it patched <bdju>seems like there's less of a UI compared to aerc. looks a bit messier to me <jgart>oh never mind I'm wrong on that I think <jackhill>Jeremy[m]: my understanding is that is doesn't need to be patched (g-o-a is also not the only package we have that talks to some remote service). The thinking is that services aren't really free or non-free. Naturally, I think it is prudent to not use those services for many reasons, but as long as it doensn't talk to the services unless the operator instructs it to do so, I think it's okay. It could even <jackhill>yeah, default search is an example where someone could accidentily use it <Jeremy[m]>jackhill: IMO using proprietary services has a lot of other issues, like privacy and security <Jeremy[m]>it is worthwhile to note that Google donates to both GNOME and KDE, and they happen to be the two desktops that offer integration with Google services! <Jeremy[m]>(sometimes even better integration than with free alternatives -- e.g. GNOME made a whole app to sync Google Docs) <jackhill>Jeremy[m]: I don't disagree (there are more bad things too) <jackhill>hmmm, I'm tempted to say the default should be noop. Some choices are better than others, but I don't know that we would be able to pick the right one for everybody <jgart>jackhill, noop for default search engine? <jackhill>jgart: that's what I was thinking. I use ddg (for example), but there's still just some 3rd pary company. But please discuss it with some folks who have given it more thought first :) <jgart>I agree. I'm skeptical of ddg also. I'd trust my own self-hosted searx instance to ddg but maybe it's the defacto if not google... <jackhill>I don't know how hard luakit makes it for users to override the default. A clever thing would be to be a static page explaining the problem and how to set the default, but each application that uses luakit would probably have a different way of doing it. <jgart>it's very easy to reconfigure it <jgart>but you have to create a config file or know the command from the mode line to run to set it <jgart>luakit has a command mode like vim <jgart>but then that might not persist <jgart>so config I think is the way to go <jackhill>Anyway, like I said, I'm just brainstorming on IRC, please seek real advice :) <jgart>adding the "(assoc-ref %outputs "out")"? <jgart>I think that's the diff with what's in master currently... <jackhill>yes, don't set DESTDIR at all and instead set PREFIX= to out <apteryx>nckx: challenge for you in the morning's freshness: define a manifest with icecat, which depends on gtk, which propagates gdk-pixbuf; now run (map manifest-entry-item (manifest-transitive-entries manifest)) -> gdk-pixbuf is nowhere to be found? <jackhill>The reason I did that was so that janet's interal paths pointed to the right place. I'd have to check again with the updated janet to see if that's still needed, but PREFIX seems like the right knob anyway <jackhill>ah, yes, the pkg-config file is wrong when using DESTDIR instead of PREFIX <jackhill>I think. Let me check again tomorrow. It's getty late here, and I'll probably think better then <apteryx>but I can't find how to get ahold of 'em, at least at 2 AM. <jgart>Would Luke Smith's st fork be appropriate for upstream guix? <jgart>I will say that his st fork is way nicer than the vanilla st that is in master <jpoiret>my 2 cents: Luke Smith, from what I've read, is a white supremacist, so linking to his home page (containing his podcasts for example) doesn't seem like a good idea <jpoiret>I'm not exactly sure what Guix's policy is on this (how is package inclusion decided, apart from license issues) <vivien>My turn for 2 cents: the personality of the guy is less of a problem than the fact that his fork has his own name, so that may appear as an endorsement from guix (and, it’s grossly megalomaniac) <jpoiret>but yes, i don't think guix should endorse such a package (mostly because it `HAS` to reference this person in some way to be packaged) <florhizome[m]><Jeremy[m]> "so, what desktop environment..." <- I can paste what i have on gala. would be key for pantheon. you can also find ppl using it as WM for xfce which i wanted to try out. so far plank does work halfway (no taskbar (some problem with bamf) and i get a strange transparent line in the lower half of the window). but for building gala we just need plank as input/lib i think. gala right now doesn't build bc it needs a newer mutter, <florhizome[m]>which needs a newer glib and for glib the meson problem kicks in. if you're on c-u-f-b-c maybe you will havemore luck. for wms: there is a wayland version of stump in work (mahogany) but progress seems slow. I think I saw someone working on guile bindings to dwl on github (guile-dwl). the reason i am building (and using on other ditros) wayfire is that it is modular (designed in the vein of compiz). so smaller des can pick it up, and ppl can <florhizome[m]>write their own plugins. right now interesting progress is made with "swayfire" which is a plugin for swaylike tiling for wayfire, and wf-lua, which is an IPC in lua for it. there is a lisp called fennel which can be used for lua, maybe that would workout... on the other hand maybe someone can write guile bindings somewhen. they also did work to introduce a workspace-protocol to wlr, which hasn't been picked up unfortunately but would be <florhizome[m]>very important for DEs and devs to be able to choose between wayland WMs. so overall a nice project. <minikN>Hello. Could someone show me a pkg definition using the cargo build system where a dependency (in Cargo.toml) is a git repo? I'm having trouble building a package because cargo can't fetch the dependency from git <singpolyma>minikN: probably need to substitute* for it to not need git <minikN>I see. Do you happen to know a pkg where I can take a look? <singpolyma>No, sorry, someone else may. It should just be a matter of writing a regex if that's what's needed <nckx>jgart, jpoiret, vivien: Hmmmmm. <nckx>We're not hard-bound to linking to what upstream says is their home page. <nckx>We could call it e.g. ‘st-ls’ or simply ‘st-fork’ if the name is really a problem. <nckx>I don't agree that the name is megalomaniac but if said name is so tainted, we can drop it. <nckx>apteryx: I'll take a look after clearing my head in the garden :) The rain is briefly distracted and I must seize my chance. <apteryx>in the meantime i'll rebuild mrustc on the last commit, supposed to fix i686 <minikN>Trying to write a pkg definition with the cargo-build-system, what should I do if a dependency is not available in guix or has the wrong version? <jpoiret>minikN: I'd say use the newer version, and update the guix version if it's older, but I don't know if cargo-build-system bypasses any version checking. I know with go-build-system you can just another version of a dep than the one in go.mod <minikN>jpoiret the version required by cargo is newer than the one in guix. <roptat>update the one in guix, and check dependants <roptat>(you can get the list of dependents with ./pre-inst-env guix refresh -l rust-foo, where rust-foo is the package you are updating) <minikN>I also don't have pre-inst-env available, I simply have a scm file with my definitions and feed it to guix build. <roptat>you could also create a new package for the newer version <roptat>but it will be more difficult to create a patch later <abrenon>if this "new package" is simply created out of the existing one, porting back the fix to the original package definition to create the update patch wouldn't be so hard maybe ? <roptat>yeah, maybe it's just me, but I find it hard to take the time to clean things up and include patches in the repo once it works locally :p <roptat>it's just more work than doing it in a local checkout I think <apteryx>is it me or is 'guix shell' slower to re-enter a previously cached environnment? <roptat>is it? it feels super fast to me <apteryx>ah nevermind, I'm using it from my in-flux tree, perhaps I had touched something <florhizome[m]>well it starts and runs, more will be needed to be investigated <singpolyma>ajarara: do you have pre-inst-env working and all that? <singpolyma>ajarara: then yeah, just normal git send-email, just being aware that if it's multiple commits you need to send an email first to get a bug number and then send all patches to that <nckx>ajarara: If that section is incomplete, it's a bug. <ajarara>the changelog man pages? Or the pre-inst-env step? <nckx>Specifically that section, I mean. <nckx>If there were some random second document you also had to read in order to actually contribute, it would belong in the manual too :) <ajarara>probably how to send patches without having to configure smtp (using fastmail's web UI in my case). I see they're represented differently on the issue tracker (I attached them on my first attempt). But that's probably a link to how git send-email formats the body. <ajarara>I'm thinking it's as simple as pasting the patch text in the body. <nckx>Ah, provider-specific set-up didn't occur to me. <nckx>IIUUC you can simply use git format-patch here. <nckx>git send-email is really for sending e-mail from git. <ajarara>right, I get a file in the worktree. I just attached it, but this go around I'll inline it in the body of each patch in the set instead. <ajarara>once I have the full thing in an hour I'll close this issue. <nckx>If by in-line you mean directly in the message text: prefer attachments. <nckx>Mangled bodies make committers sad. <ajarara>Okay, great. So I'll keep on doing that then. <ajarara>singpolyma: I'm a little hesitant to stash smtp creds anywhere. I guess I can come up with an email address that I use solely for sending patches, instead of using my 'everything' email. But I'm totally cool with creating patches and attaching them through a UI for now. <singpolyma>You'd only be "stashing" them on your own computer <nckx>Git also supports a sendemail.helper directive that might work for you. <singpolyma>I guess that depends on your provider and what you want to get out of your 2fa. I send email exclusively over ssh and don't actually use SMTP auth, myself :) *nckx just types their password every time. <singpolyma>If you use a sourcehut instance to send they use their own SMTP server of course *ajarara can't wait for (any) adoption of webauthn <nckx>How does that apply to e-mail? <nckx>Specifically, how would I one support for that to their SMTP server? <ajarara>it would avoid it entirely, relying on the authenticator for identity. Everytime you send an email you're prompted for proof of one. <ajarara>when I think about using sourcehut to send patchsets I register an smtp token that says 'you may send email on my behalf', and I authenticate to sourcehut when I log in <ajarara>that second part is (authenticating to sourcehut) is feasibly replaceable today, but I don't see why the layer underneath, smtp or MX could also rely on webauthn <nckx>So git send-email prompts for your sr.ht password or token? <ajarara>git send-email prompts for an authenticator, like a fingerprint scanner on device or a security key <nckx>So the ‘Web’ word here is pure marketing, right? <singpolyma>nckx: that's true of most "web" things. Like websockets, also not web related. WebRTC, not web related *nckx currently uses oathtool to work around things that require 2FA, presumes the same is possible here, and it sounds like a better standard. *nckx shrugs too, shrugging's cool. <nckx>I don't understand why you'd use a word with negative connotations to market your stuff, but all the better then. <singpolyma>nckx: only negative with our types. For the majority dev, web means "easy" or "like other stuff you know". Of course I think it's meant to convey "implemented by chrome" <nckx>‘Our types’ is prolly a good point. <nckx>(And es aren't allowed, so closer it won't.) <nckx>anjan: You know, I've become convinced that Guix's linux-libre kernel is utterly missing Coreboot framebuffer support. https://paste.debian.net/plainh/6f8a0d5c In normal cases this doesn't matter — the ‘real’ full featured graphics driver takes over almost immediately to display the boot console, initramfs output & your desktop. But if something goes wrong during early boot the system will appear to freeze because the kernel can't modify the pixels. <nckx>There's no way around that. <vagrantc>is that a feature specific to linux-libre? <vagrantc>is there a compelling reason not to enable it, if it's just kernel configuration options ? <nckx>vagrantc: We'd be losing whatever (if any) functionality CONFIG_DRM_SIMPLEDRM provides; this is a new option with which I'm not yet familiar so I can't say. There is also a theoretical chance of regressions on non-CB/LB systems in enabling CONFIG_X86_SYSFB as it changes how the kernel assigns/prioritises FB drivers. <nckx>I don't think it will break but I can't guarantee it… <nckx>I only started looking into this today after lfam brought it up; I run my own kernel (which does have these options set BTW). <nckx>The two points above are the *only* reasons I hesitate to make these changes on master. They seem like the right thing otherwise. <nckx>I'm talking to myself as much as to you, trying to find a third option :) <nckx>Nothing better than talking at length in public & ending with ‘oh, no, wait, X, never mind’ afterwards to get the creative juices flowing. <GNUHacker>mi Tor instance dont work in Guix system, when I run say: [warn] Received a bad CERTS cell: At least one certificate expired. <nckx>Does it work on a different distribution on the same machine/network? <nckx>And how does it ‘not work’ on Guix System? <nckx>Do you have /run/current-system/profile/etc/ssl/certs/Starfield_Class_2_CA:2.1.0.pem ? <nckx>(This is a random test, not a particularly relevant cert.) <nckx>Here's what I did to successfully run ‘torify curl ip.tobias.gr’: Add tor-service-type to my list of system services, make sure tor is running with ‘sudo herd status tor’, make sure I have the tor-client & torsocks packages installed. <nckx>If you are missing the above ssl/certs file you also need to add nss-certs to your system package list. <GNUHacker>sudo herd status tor say: Stopped [...] [warn] Received a bad CERTS cell: At least one certificate expired. <nckx>That doesn't make sense. Are you sure that warning is relevant? Why? (Do you have nss-certs?) <nckx>Does ‘sudo herd restart tor’ (possibly after a ‘sudo herd enable tor’) consistently fail? <GNUHacker>on restart tor: 24 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN <nckx>Can you share the full log? <roptat>GNUHacker, is your clock at the right time? <roptat>then that might be it, if you fix your clock, certificates should no longer be expired <apteryx>haha! I was able to use geckodriver from icecat 91 with selenium <nckx>GNUHacker: That will set your system time, which is a counter in RAM. It will not survive a reboot. For that, run hwclock --systohc afterwards. <apteryx>there was some KEY = "moz:firefoxOptions" string (FirefoxOptions.KEY) to monkey patch into moz:icecatOptions for it to work <nckx>If you don't have a hardware clock (some cheap systems like ARM don't ship one for bizarre reasons) you'll need NTP. <nckx>Out of curiosity, how can you have a wrong clock & not notice/tell us? <nckx>I'm building an image with those options set and will test it on my X230T. <anjan>nckx: ok, please let me know how that goes <anjan>nckx: btw, the problem only appears after you install and try to boot into your new system <nckx>I don't think it's quite that. <nckx>If it is what I think it is, it's that the kernel has no way to report early-boot errors, and the ISO doesn't throw one whilst your installed system does. <anjan>nckx: btw, I had a similar issue installing to my desktop that runs proprietary amd/gigabyte bios <anjan>so Im not sure what it is.... <anjan>I just wanna install guix once man ;_; ***Guest6805 is now known as yang
<ajarara>why isn't openssh-sans-x just another output of the ssh derivation? predates the idea of multiple outputs? <lilyp>what does the sans-x change here? if it changes inputs, then that's why :P <ajarara>yeah, it drops xauth. but the manual says it supports that use (different dependency footprints) <nckx>‘SSH without X’ is a different way to build SSH. It's not one part of what you get when you build SSH normally, which is how ‘outputs’ are used in Guix. <nckx>‘Build foo, install it to :out, then make clear, and rebuild it again with different options to install to :bar’ is not how they are used. <ajarara>oh.. more like 'given this build, get me the {docs/binary}, and not the other' <nckx>And even then, as you probably noticed, convention is to use them only when the probably space savings are significant. <jgart>nckx, vivien, jpoiret, I'm fine with renaming luke's fork if that makes everyone happier. I think it would be a shame to not make this free software available to the guix community. <jonsger>what do people think about using zstd instead of gzip as default for logrotating in Guix? <nckx>gz is not the local best at anything, AFAIK. Except, dubiously, compatibility with ancient systems. <nckx>jgart: I think that's the way to go then. <nckx>We can look for a more suitable ‘home page’ together if you can't find one. <jonsger>nckx: was the thumb up to zstd or lukes fork? <nckx>Normally we'd link to a third-party-hosted man page or something but this is sucksoftware, so it doesn't even have documentation. <ajarara>I think I've been confused for someone else: I haven't had this issue. <nckx>If you could all choose differently-coloured nicks so's not to confuse my synesthesia that would be great. <nckx>Which term even is that? <nckx>(My brain has ‘colours’ that don't actually exist, complicating matters.) <vagrantc>everyone appears to be using the same nick color to me :) <nckx>Okido ya yellowish weirdo. <vagrantc>oh wait, my own is apparently "white" and everyone else is "grey". <nckx>Well, that's up to your client, and possible. <the_tubular>True, as I said, the other day, still looking for a good XMPP server / client ***nf__ is now known as nf
***roptat is now known as Guest3449
***dongcarl3 is now known as dongcarl
<apteryx>nckx: my terminal color theme I should have said; I use xterm <singpolyma>the_tubular: if you're on XMPP you don't need the client to support IRC. Biboumi is great and acts as a bouncer for you <singpolyma>the_tubular: for example I am joined here via xmpp:#guix%irc.libera.chat@irc.cheogram.com <nckx>apteryx: Interesting choice. Specific reason? I've heard some cite speed but I cannot replicate that. Some also cite vague ‘correctness’ (in what, I do not know) but its code sure doesn't hint at that… <nckx>Or maybe you just like the simple thing that starts with x and comes with X, which is, of course, fine. <pinoaffe>hi guix! can anyone tell me how the value for the emacs "load-path" variable is determined in guix? <pinoaffe>I was expecting it to simply be the $EMACSLOADPATH env-var, but guix package --search-paths did not return anything useful <nckx>pinoaffe: It should list EMACSLOADPATH, which is very much the source (look inside). <pinoaffe>nckx: aah okay, so it's not a one-to-one translation of EMACSLOADPATH, but it is based on the envvar, that makes sense I guess <nckx>According to my own limited understanding of emacs, anyway. ☺ <pinoaffe>nckx: do you know of a way to make emacs "repopulate" load-path? <pinoaffe>I tried running (package-initialize) again, but that did not do the trick <pinoaffe>I'll keep on digging, then, cuz I find it quite annoying that I can't just "require" a package in my running emacs after installing it <nckx>pinoaffe: Try (load "subdirs"), then require it. <raghavgururajan>the_tubular: Currently, Gajim (GTK) and Psi+ (Qt) are the full-featured XMPP clients. Both are available in Guix. Let me know if you have any troubles with them. :) <pinoaffe>lilyp: nckx : thanks!!! I guess I'll use part of normal-top-level *nckx hadn't seen lilyp's answer but yw. <ngz>Hello folks. I noticed that go importer chokes on projects that are sub-directories of a repository, e.g., "github.com/Azure/go-autorest/autorest/adal". Is it a known issue (I couldn't find anything on the ML) or an expected shortcoming? Or is it worth a bug report? ***jetomit_ is now known as jetomit