IRC channel logs


back to list of logs

<dcunit3d>when i'm running `guix pull` i can't seem to up the commit or url for the 'guix channel
<dcunit3d>it just pulls from the same `6f75565` commit everytime which is preventing other channels from updating. i
<dcunit3d>i've tried changing the commit hash to something more recent and the url to a local copy of the savannah repo with file:///
<dcunit3d>for other channels, i can specify these things fine.
<necrophcodr[m]>dcunit3d: are you specifying those in ~/.config/guix/channels.scm?
<dcunit3d>yeh, well that or ~/.config/guix/base-channels.scm and `guix pull --channels`
<necrophcodr[m]>do you want the most recent or just a more recent commit?
<necrophcodr[m]>because you could also just try removing the commit specified in your channel configuration for the guix channel and see if that does it
<necrophcodr[m]>then add it back in afterwards with the commit guix shows with `guix describe` iirc
<dcunit3d>either way, it only pulls the 6f75565 config
<dcunit3d>if i change any of the other channels, those updates are shown when i run `guix pull`, but when i change the guix channel definition, it doesn't show
<dcunit3d>like it's cached somewhere or something
<dcunit3d>i think it might be that another channel is pinning the commit. i just removed the guix-past and gn-bioinformatics channels and it's updating correctly
<necrophcodr[m]>i think your mind is in the right place. it probably is specified somewhere somehow. i don't know enough about the internals to know where it could look though.
<necrophcodr[m]>dcunit3d: ah, i was not even aware that was possible, but that's a VERY good point
<necrophcodr[m]>dcunit3d: i think you're right:
<necrophcodr[m]>In their README it states:
<necrophcodr[m]>> In order to maintain stability, the guix-bioinformatics channel depends on a specific commit of upstream Guix. So, it is recommended to isolate use of the guix-bioinformatics channel in a separate guix pull profile.
<dcunit3d>ah thanks i didn't see that
<necrophcodr[m]>Yeah I wasn't even aware those things were possible haha, but it's definitely good to know!
<dcunit3d>well it seems to be working now. it's been like this for about 2 weeks, so i was worried something was corrupted
<dcunit3d>thanks. i gtg. i'll be back on later though
<gabber>may i ask for feedback on ? i've submitted the last patches about a year ago and i'd love to see ack in guix :)
<ulfvonbelow>anyone know how to make a container where the loopback interface isn't accessible but other network interfaces are?
<jorge[m]><jorge[m]> "this is happening in the..." <- Please help me I couldn't solve this
<rekado_>gabber: the patch looks good to me. I can apply it later and fix a few problems before pushing it.
<rekado_>there are a few problems with formatting and style, but I don’t think we need to delay this by asking you to send a revised version.
<PotentialUser-84>Hello. I am interested to replace my doom-emacs setup (although it works fine) with emacs packages managed by guix. Basic functionality I want to keep is which-key, evil-everywhere, magit, projectile or equivalent and a basic  python setup (at my workplace). Are there any pointers or does someone already reaches a similiar setup?
<jpoiret>PotentialUser-84: i think that while you'll have the packages installed by doom, you'll be missing all the doom glue
<civodul>Hello Guix!
<Not_Leader>wait a second does using irc make me an adult?
<koorosh>hi I'm new to guix and I'm trying to install a guile module that I wrote my guix.scm file looks like this
<koorosh>when I run guix package -f guix.scm there is no error but it never terminates and starts using a lot of ram
<rekado_>koorosh: what is your intention with that native-inputs field?
<rekado_>why should this package be an input to itself?
<rekado_>and why should a string be an input?
<rekado_>if it’s supposed to be a label (note: we don’t use those any more) then you need to use an alist
<koorosh>to be honest I don't know how my native-inputs should look like the guix manual says that packages build with guile-build-system should provide a guile package in their native inputs
<unmatched-paren>how do i register an extension directory in a channel?
<unmatched-paren>I have the command working when i use pre-inst-env
<unmatched-paren>but it doesn't work under pull
<unmatched-paren>(the extension is under guix/extensions)
<rekado_>koorosh: this means the “guile” package, not just any package using guile :)
<rekado_>use (native-inputs (list guile-3.0))
<jpoiret>unmatched-paren: wdym by extension?
<rekado_>what you have right now is a cycle
<jpoiret>a Guile c extension?
<rekado_>a Guix extension
<rekado_>you need to set GUIX_EXTENSIONS_PATH
<unmatched-paren>rekado_: My pre-inst-env does that, but I thought guix pull would set that itself?
<rekado_>…to the guix/extensions directory
<rekado_>sadly the variable is not set automatically
<jpoiret>is there any doc on the subject?
<unmatched-paren>jpoiret: GWL is a guix extension, for example
<unmatched-paren>I'm adding a small commmand to guixrus ;)
<unmatched-paren>rekado_: How would I make guix set it?
<rekado_>jpoiret: looks like it’s not actually documented
<koorosh>ty :)
<jpoiret>oh, it's just to add scripts?
<rekado_>unmatched-paren: the search path mechanism fails us here
<unmatched-paren>I see gwl sets it manually
<rekado_>unmatched-paren: the “guix” package has a native search path for that variable, but you won’t ever install that package
<jpoiret>gwl is a package it seems
<unmatched-paren>but how does it do that if the extension can't be loaded?
<rekado_>jpoiret: it’s a package that provides a Guix extension
<unmatched-paren>it sets the extension path inside the extension
<rekado_>unmatched-paren: gwl doesn’t set the variable
<jpoiret>right right, I was comparing that with a guix channel that's pulled
<jpoiret>one more reason to weigh in at :)
<unmatched-paren>Oh, yes. I see, it sets the LOAD_PATHs, but not GUIX_EXTENSION_PATH
<unmatched-paren>Would a patch to automatically set GUIX_EXTENSIONS_PATH be accepted or is there some reason not to?
<jpoiret>i think we'd need to add a field to the .guix-channel file
<jpoiret>but with that added it shouldn't be too hard imo
<rekado_>unmatched-paren: it was always my intention to have it set automatically
<rekado_>would be nice to have a mechanism that works both for channels and for packages.
<jpoiret>is debbugs down?
<rekado_>not for me
<jpoiret>i didn't get an ack for my teams patch
<oriansj>Not_Leader: no more than paying taxes makes one an adult
<unmatched-paren>hmm, why is `./pre-inst-env guix pull --url=file://(pwd) --profile=/tmp/guix` taking so long?
<jpoiret>it's got to update its local checkout of that url, which will be a different cache than the usual guix one
<jpoiret>you're basically fetching the whole guix repo again
<unmatched-paren>Ah, so it's just rebuilding the repo from scratch.
<jpoiret>did you disable authentication also? :)
<unmatched-paren>was i supposed to?
<jpoiret>well, you've got local commits that aren't signed, right?
<unmatched-paren>i guess so, yeah.
<jpoiret>it'll just error out later, no worries
<unmatched-paren>I've added an extension-paths field to <channel-metadata>; I guess I should add a test for it in tests/channels.scm? If so, what exactly should I test?
<efraim>does setting '#:parallel-build? #f' change the derivation?
<unmatched-paren>I guess I should test deserialization of the field from channels.scm
<unmatched-paren>rekado_: Seems like guix extensions are managed as services, is this correct?
<unmatched-paren>Or, rather, by the guix service.
<unmatched-paren>aha, looks like i need to modify guix/ui.scm (extension-directories)
<unmatched-paren>I'm not sure how I'd get the extension directory from the <channel-metadata> to (extension-directories) though.
<unmatched-paren>Ah, I think i'd modify guix/self.scm.
<Not_Leader>is guix home recommended for user–level package management?
<unmatched-paren>Not_Leader: yes
<PotentialUser-84>jpoiret: Thank you. I will keep doom for now until I am more familiar with the needed packages
<jpoiret>unmatched-paren: rather, i'd suggest modifying guix/channels.scm
<jpoiret>that's how the guix pull profile is constructed
<jpoiret>guix/self.scm is for guix's own build process when being guix pull'd
<Kabouik>Hey there, has anyone heard about any success running appimages on Guix system? I know it's like the opposite of the philosophy of Guix, but I depend on one appimage and yet I'd like to get as close to the Guix philosophy as I can. Last time I checked was around Xmas and pkill9 had some kind of proof of concept but I failed to use it for my appimages (, and there is also
<Kabouik> but I am not sure it's working yet, and it's NixOS
<Kabouik>Right now my Guix machine is a bit dormant but my ultimate goal is still to use Guix on my main computers
<drakonis>Kabouik: some experimentation required
<Kabouik>The appimage I need is rather complex too: it depends on the GPU or iGPU, streams video (cloud computing), conveys mouse/keyboard inputs, and grabs the mouse within window borders; I suppose all this are even more reasons it'd fail
<civodul>Kabouik: i suspect it's the same problem as with other ELF binaries: they probably need to be patched to refer to the "right", no?
<Kabouik>Anyone made appimages work with this? That's interesting, would be cool if a simple path patch would fix it all
<NinjaTrappeur>Kabouik: if you're up to get your hands dirty, you could mimick what's done in NixOS on Guix. The overall idea is to unsquashfs the appimage before linking some libraries to the entry point (AppRun).
<NinjaTrappeur>The NixOS appimage tool generates a chrooted FHS with the usual suspects in terms of libraries. It's a solution that'll work 90% of the time.
<NinjaTrappeur>list of the libraries in the chroot:
***wielaard is now known as mjw
<NinjaTrappeur>Script in charge of unpacking the appimage:
<NinjaTrappeur>(good luck!)
<Kabouik>I would be happy to do that but I think luck is not the only thing I'd need, I'm not sure I'm skilled enough for the task :<
<Kabouik>I know bash (kindof) but not guile, and am not familiar yet with where libraries are organized in the Guix filesystem
<Kabouik>That's the script I linked above I think, so I starred it already and hopefully will give it a go at some point, but I am not sure I can translate it into Guix
<Kabouik>At least there's real hope now!
<NinjaTrappeur>This script is meant to be used as an entry point. You won't necessarily have to translate it to guile to start working on that.
<NinjaTrappeur>I think the first step would be to create something analogous to the NixOS fhs chroot. Either by creating a FHS chroot yourself, either by patching the appimage entry point and injecting the right libraries.
<NinjaTrappeur>(I'm not skilled enough with Guix either to provide further help ><)
<ric342[m]>I'm curious, has anyone created an example scheme file that can build (and maybe also configure) an OS other than guix from guix? Such as a debian vm?
<jpoiret>ric342[m]: i'd say it'd be way too out of scope
<ric342[m]>I think gnutoo made one for arch though, not sure if he got it to fully work or not though
<ric342[m]>Well, without the configuration part, which definitely sounds hard
<jpoiret>hmmmm, right, but then you're not really using guix system then
<jpoiret>i don't think it'd be too hard to package the arch install scripts for example :)
<ric342[m]>Yeah upon a closer look it looks like this is kind of installing it onto the system
<jpoiret>the example you gave doesn't let Guix build the OS, it just provides the installer programs
<jpoiret>to let Guix build the OS would be too hard, we'd need bindings to the target package manager
<jpoiret>(at the very least)
<ric342[m]>I'm thinking as in like, bootstrapping an OS, and maybe from there finishing it in a vm
<ric342[m]>As I seen GUIX talking about that on the blog, although maybe I'm misunderstanding
<podiki[m]>on the FHS chroot front, I have a modified fhs-container (from that other channel) that I've just been using to try out some development stuff
<podiki[m]>eg. rustup, poetry, npm, stuff that likes to downloads binaries sometimes; think I got a lot of it working, all in an isolated container
<jpoiret>podiki[m]: 🥳
<podiki[m]>although obviously it helps run binaries, would a guix shell command to provide an fhs environment have its place in guix? i feel like it would, useful development tool
<podiki[m]>esp for ecosystems like js that we don't have much in guix (node will download binaries)
<drakonis>podiki[m]: :toot:
<ric342[m]>I tried out the onion substitutes section from the cookbook, however, when I do a guix install it just hangs or fails the tls
<ric342[m]>Connecting to the onion site in firefox works, so I think the tor daemon is working
<ric342[m]>I also tried replacing localhost with but it also did not work
<zimoun>from REPL, how ,use is from (use-modules) ?
<ric342[m]>I didn't put anything different into (use-modules)
<ric342[m]>Is there something I am suppose to add to that?
<zimoun>ric342[m], no no. I do not know. It is my question because I am blocked. Not an attempt to answer you. Sorry. :-)
<ric342[m]>Oh sorry I misunderstood
<apteryx>podiki[m]: it would; --fhs has been on my TODO list for a long time
<apteryx>it'd need to implicitly pull --container
<unmatched-paren>jpoiret: thanks!
<podiki[m]>apteryx: great, I'll take a look at how to extend container maybe; the hard work was already done by others for a non-free package
<podiki[m]>apteryx: but just using that wrapper for something like bash gets you most of the way, needed some env variables and it is mostly there
<unmatched-paren>jpoiret: Seems like I need to make a %extension-path variable. Should I add this in gnu/packages?
<podiki[m]>apteryx: any discussions on guix-devel about design decisions before? or maybe I'll start a thread, see what would be useful baseline
<jgibbons[m]>Hi guix! I have 19 chapters planned for my book, including a chapter each on package definitions, using a development cycle with guix, build systems, the test suite, scripts, contributing upstream, guix home, virtual machines, services, deploying, building an offload server, channels, and time-machine. I'm also considering writing about configuring a secure system. Are there any other topics I should add to the outline?
<unmatched-paren>jgibbons[m]: Explanation of guix internals, perhaps?
<unmatched-paren>like derivations, the daemon, etc.
<unmatched-paren>And maybe a chapter about the API it provides for extensions and scripts.
<unmatched-paren>with information like how to manipulate the store, how to build a derivation, et cetera, things that might be useful when writing an extension or script
<vagrantc>jgibbons[m]: not sure how you wrote it, but there has been discussion about making changes to the development cycle process for staging and core-updates ... not sure if it will go anywhere, but might be good to not hard-code too much in a "book"
<vagrantc>jgibbons[m]: foreign distro installations vs. Guix System ?
<vagrantc>jgibbons[m]: curious what the target will be, as a lot of that is covered in the manual
<jgibbons[m]>vagrantc: I already have a chapter mostly complete on installation.
<jgibbons[m]>I haven't written any of the chapters I said I have planned.
<jgibbons[m]>I want to provide a more in-depth look at all those topics. For example, I'm going to include a Dockerfile to build and install guix from source on a Debian system without relying on guix bootstrap packages.
<jgibbons[m]>I already have working instructions on running guix in docker.
<jgibbons[m]>I'm also going to try to provide a guix-built guix Debian package.
<apteryx>fwi, I've open an issue with repology at because it seems they aren't able to fetch our packages.json file.
<apteryx>s/fwi/for your information/
<jgibbons[m]>vagrantc I'll walk through the baby steps for defining packages and constructing services. There are a lot of services I suspect guix users might want like minetest, infinoted, and drawpile. Not to mention the many other networked games and utilities already available without matching services.
<jgibbons[m]>Does the manual include a section on how to define a build system? Last I checked it only lists what's available. Same with scripts.
<ric342[m]>not sure if in a usable enough state but, jgibbons what about reduced binary seed bootstrapping?
<jgibbons[m]>I want to make 100 printed copies and donate them to public libraries across USA. I guess my audience is beginners to intermediate users.
<unmatched-paren>jgibbons[m]: it should be fairly straightforward to figure out build systems from the source code
<unmatched-paren>but yeah, that should be documented
<unmatched-paren>everything should be documented
<jgibbons[m]>ric342: I'll include a chapter on the reduced binary seed bootstrapping if I can.
<ric342[m]>Will you also be posting it online? Maybe I will read it, sounds cool
<jgibbons[m]>unmatched-paren: my book will be an alternative to using the source.
<jgibbons[m]>ric342: I would like to get some money from my book because a lot of time is going into my research. I've considered crowdfunding prior to release. I've also considered releasing it under GNU FDL and including a plea for crypto donations in an invariant section.
<unmatched-paren>jgibbons[m]: be aware that some (many?) consider invariant sections to be non-free
<jgibbons[m]>Some who have shown interest have said they prefer digital
<unmatched-paren>e.g. Debian
<unmatched-paren>I'm not sure about Guix's stance on the issue
<ric342[m]>Personally I usually read digital before deciding to get a paper copy
<unmatched-paren>ric342[m]: me too
<unmatched-paren>I would personally use CC-BY-SA-4.0 instead of FDL
<ric342[m]>But if it's something that has a new revision every few years I probably wouldn't get paper
<unmatched-paren>we do include the emacs info pages
<unmatched-paren>But not the glibc info pages, it seems... Strange.
<jgibbons[m]>If it's CC-BY-SA I will want to crowdfund.
<ric342[m]>The donation model seems nice, but it's up to you if you think it will adequately reward you, but in combination with a crowdfund may be workable
<ric342[m]>Especially for future revisions
<unmatched-paren>jgibbons[m]: Hmm, I guess you'd have a website with an introduction to the book that isn't actually part of the book, right?
<unmatched-paren>Oh, wait. Bad idea, never mind.
<unmatched-paren>Crowdfunding sounds like a good idea :) A chapter for each milestone, maybe?
<jgibbons[m]>Some of the planned chapters were requested on this IRC.
<apteryx>podiki[m]: I was thinking about 'guix shell --fhs'
***Dynom_ is now known as Guest9321
<ric342[m]>btw does anyone know about using the onion substitute server?
<jgibbons[m]>ric342: I suppose you'd need to configure guix to use the onion daemon as a proxy. Have you tried that?
<jgibbons[m]>I don't know how to do it, could be documented in manual?
<jgibbons[m]>On the road, can't check.
***mark_ is now known as mjw
<ric342[m]>jgibbons: I tried following the example in the cookbook
<ric342[m]>Heres what I put
<ric342[m]>hen I do a guix install it just hangs or fails the tls
<ric342[m]>My config:
<ric342[m]>Connecting to the onion site in firefox works, so I think the tor daemon is working
<ric342[m]>I also tried replacing localhost with but it also did not work
<jgibbons[m]>Oh, I could try planning a chapter on building a system for arm SBCs. There is something forked from uboot that lets distros design with a UEFI bootloader. Mobian is encouraging its use with pinephone. I can work out how to make a generic guix arm efi image and describe how that works.
<ric342[m]>Yup definitely, gnutoo has some examples for that on his gitlab jgibbons
<ric342[m]>(not EFI though I think, just regular u boot)
<podiki[m]>apteryx: meaning with this option the shell spawns in a container with an FHS setup for given inputs? I think it might be helpful to have some default package lists, since it can be a lot for an isolated container to get anything to work
<jgibbons[m]>ric342: looks like I'm thinking of tow-boot.
<jgibbons[m]>I don't know how blobby it is so I won't discuss it further here.
<jgibbons[m]>I've never been able to get u-boot to build with guix no matter what architecture I'm using.
<apteryx>podiki[m]: yes, guix shell spawned in a container with the given inputs. Why would it need a default packages list? I'd prefer users with large environments to manage to use a manifest.scm file.
<apteryx>so they could 'guix shell --fhs --manifest=manifest.scm'
<podiki[m]>yeah sure, maybe a cookbook or other entry for useful starting manifests
<podiki[m]>e.g. doing web/js development, or some language; though might need to set some env variables as well, right now doing that manually as not sure how search-paths interact here
<podiki[m]>(wasn't there some discussion here the other day about guix shell and setting env variables?)
<jgibbons[m]>I think there's a --preserve option...
<podiki[m]>yes, but lsome will need to be different in the fhs container; some you'll want to preserve though
<jgibbons[m]>G2g. I'll come back at a different time to report my book's progress.
<johnjaye>guix is guile 3.0 right
<unmatched-paren>johnjaye: I think it runs with both 2 and 3
<johnjaye>ok. is it like a python2/3 situation where the new version totally ruins existing code?
<johnjaye> honestly if they left the print instead of print() syntax in i think it would have gone more smoothly
<unmatched-paren>> It seems that developers have become wary of 2-to-3 transitions for programming languages. Fear not! Switching from Guile 2 to Guile 3 turned out to be an easy task. In fact, very little changed in the language itself; what did change—e.g., semantics on fine points of the module system, support for structured exceptions—is either optional or backwards-compatible.
<johnjaye>by the way did anybody know the error I got when trying to install earlier?
<johnjaye>i'm stuck in virtualbox until i can get this resolved
<unmatched-paren>that's pretty bizarre. it's not normal to have that many issues with installation
<unmatched-paren>(you'd hope so, wouldn't you :P)
<vagrantc>jgibbons[m]: regarding EFI, u-boot can also do that, that's where tow-boot got it's EFI from. The main differences as i understand it is that tow-boot is usually installed to something other than the boot media (e.g. flash on spi or the special emmc partitions used for exactly this purpose)
<vagrantc>jgibbons[m]: it also apparently has enabled and/or added functionlity to interact with it from a menu on the screen
<vagrantc>really surprised you can't build u-boot ...
***aeka` is now known as aeka
<stikonas>vagrantc: provided that keyboard and screen works in u-boot... Which I was not able to get working
<vagrantc>admittedly i've mostly used u-boot with serial consoles ... but definitely a few notable exceptions (the computer i'm using now)
<stikonas>yes, I had more luck with serial consoles but I wasn't able to get keyboard/screen to work on rockpro64...
<stikonas>possibly it's hardware dependend...
<rekado_>keyboard and screen works for me on the rockpro64
<ric342[m]>Are there any substantial hurdles to running a guix system with musl instead of glibc?
<vagrantc>ric342[m]: i suspect this is one of those "theoretically no, practically speaking lots" sort of issues
<ric342[m]>I wonder if you can look at a os that uses musl and convert the packages over?
<ric342[m]>It might be nice for a device with low resources, even if it has very few packages available
<ric342[m]>this kind of flexibility might be an advantage the guix way of doing things could offer
<vagrantc>ric342[m]: it would pretty much be a completely different system
<ric342[m]>why? to me if it's using the guix specific utilities and managed through scheme it is just extra modules
<ric342[m]>guix even supports an entirely different kernel
<vagrantc>because all the existing packages indirectly depend on glibc, rebuilding anything that low on the chain will result in an entirely different system ... possibly using similar methods
<ric342[m]>that's true, but couldn't the guix package manager be utilized to resolve the different c libs as like a different dependency option for the packages?
<vagrantc>as i said, theoretically it should work, practically sounds like a project surely full of surprises :)
<ric342[m]>i e both package definitions exist in the channel or have variable for it effected by which clib is chosen in the main system config.scm?
<vagrantc>you'd need to rebuild the bootstrap chain ... unless you used glibc to bootstrap your musl
<ric342[m]>maybe so, but maybe guix can be a very universal base so different distros can base on it and re-do the same things less
<vagrantc>sure, in the sense that guix is "just" a software building tool
<ric342[m]>sounds easier for collaboration between different groups too
<ric342[m]>i suppose using glibc to bootstrap it is okay
<ric342[m]>whatever makes the most sense as a bootstrap with the most support
<unmatched-paren>surely rebuilding the bootstrap chain isn't hard
<unmatched-paren>because musl is already part of the chain
<unmatched-paren>in fact, it's rebuilt multiple times :)
<ric342[m]>im still new to guix but I'm hoping as a base it can become very widespread like how debian is
<unmatched-paren>"TeH pArEnS" might be an issue there :)
<ric342[m]>it seems pretty challenging right now but there's a lot of things that can be built on it to make it feel like a more user friendly os
<unmatched-paren>but with nix "TeH sYnTaX" is even worse, so maybe guix has a better chance than it
<ric342[m]>the average user doesn't necessarily need to see that at all
<ric342[m]>the role of a distro maintainer can be to write those for them as well as tools that can make basic adjustments to it
<gnucode>is there an easy way to apply a patch from debbugs-gnu to my local guix repository?
<unmatched-paren>gnucode: download the mbox and `git am` away :)
<gnucode>unmatched-paren that seems very tedious...
<unmatched-paren>curl might be able to make it easier
<gnucode>It would be nice if I could apply the patch from emacs and debbugs...just my 2 cents.
<morganw>I think there is an Emacs package which can apply git patches that are in a mail message.
<unmatched-paren>I use aerc which allows me to download and apply the mbox automatically, not sure whether $EMACS_MAIL_CLIENT can do that
<unmatched-paren>aerc command is :pipe -mb git am -3<Enter>
<unmatched-paren>"pipe the mbox into git am three-way"
<gnucode>unmatched-paren are you using mbox to read the guix email achives?
<unmatched-paren>gnucode: what do you mean?
<unmatched-paren>i think aerc uses maildir by default
<gnucode>ok. Maybe I should give aerc a try. I keep wanting to use emacs for most of my email and everything needs. But I have a really hard time figuring out how to use it.
<morganw>gnucode: I think this is one some people use:
<gnucode>I used to be able to send email via I can't.
<unmatched-paren>aerc uses vi commands, fyi
<gnucode>I am using evil-mode
<unmatched-paren>gnucode: I'm afraid my patch adding aerc hasn't been merged yet though
<unmatched-paren>because of the general lack of vi users around here :)
<morganw>It believe that if you use Gnus there is also a built in command to send the message buffer to a pipe and so something with it.
<morganw>*do something
<morganw>Or possibly it was built into message mode, I think I tried it once but I don't remember the exact process.
<unmatched-paren>maybe there's a way to pipe the mbox too
<gnucode>I just found this:
<gnucode>seems promising
<ulfvonbelow>M-> C-<space> M-< M-| <your command here>
<ulfvonbelow>that works with any buffer btw
<rekado_>gnucode: I use mu4e (which uses gnus message mode to display emails) and wired up the mu4e-action-git-apply-mbox action.
<gnucode>rekado_: do you ever use debbugs?
<rekado_>I dog-food mumi /
<gnucode>rekado_: hahah.
<ric342[m]>I'm new to emacs and so far I'm liking doom emacs for org mode editing some scheme code, it's been easy enough to get started since I'm used to vi bindings
<ric342[m]>But about the meme of emacs being an operating system, I wonder is it really a good idea to view email, rss, matrix etc and more within emacs from a security perspective?
<ric342[m]>I feel like going beyond general text editing, or at the most beyond offline only uses, it sounds like it would be hard to maintain security.
<gnucode>ric342[m]: use it for what makes sense to you. I have given up on using emacs as a web browser. It is not a very good web browser in my opinion.
<gnucode>Org-mode rocks!
<ric342[m]>Also maybe guix can be leveraged to improve the security model of emacs?
<gnucode>by the way, it seems like I was able to apply patches. Which is kind of cool.
<ric342[m]>(note I dont know hardly anything about the security model of emacs, I'm just wondering things)
<apteryx>rekado_: hi! any news about accessing iDRAC via node 129?
<rekado_>apteryx: oh, that… You needed a free IP on the management network, right?
<apteryx>I'm kind of clueless as to *what* I need, but I suppose yes. I had tried to set up an IP next to the one Berlin is using that seems to be used to route to iDRAC, but in vain
<rekado_>that management network is pretty full
<rekado_>I’ll have to check out docs to see if there’s an unused IP we could assign
<apteryx>OK! I think I had sent some nmap scan result or partial result to guix-sysadmins, not sure if that's useful.
<rekado_>looking at your email I think you got the netmask wrong
<rekado_>should be 26
<rekado_>you used 24
<rekado_>the 252 IP should be free
<rekado_>eno3 is also correct
<rekado_>maybe try again with /26?
<fnstudio>hi :) is it possible to run shepherd/herd on a foreign distro? e.g. in order to run services such as cups from guix as a non-root user?
<apteryx>rekado_: thanks, will do
<apteryx>I've tried with /26 but I still get channel 3: open failed: connect failed: No route to host\nchannel 4: open failed: connect failed: No route to host upon attempting to access iDRAC via node 129