IRC channel logs


back to list of logs

<zacts>yes, I do
<zacts>I just have many more blank dvd's than I do usbs, but it's ok for now
<rekado>I'm packaging lash 0.6.0~rc2 and the tilde is a bit of a problem.
<rekado>Normally, I should be able to escape it with another tilde: "0.6.0~~rc2", but Guix doesn't like that:
<rekado>guix build: error: build failed: invalid character `~' in name `lash-0.6.0~~rc2.tar.bz2-builder'
<rekado>any ideas how to get around this?
<rekado>even if the tilde is just part of the uri string (and not the version field) it fails.
<rekado>actually, it's only a problem in format strings, isn't it? So it shouldn't need to be escaped at all, or am I mistaken?
<mark_weaver>hmm, that's surprising.
*mark_weaver looks at the download code
<mark_weaver>okay, it has nothing to do with format. it's a deliberate limitation in the set of characters allowed in store names, inherited from nix.
<mark_weaver>see 'checkStoreName' in nix/libstore/
<mark_weaver>rekado: you could include a 'file-name' field in the 'origin' to change the filename in the store.
<mark_weaver>and also keep it out of the version
<mark_weaver>see 'libuninameslist' in gnu/packages/fontutils.scm for an example of the use of 'file-name'.
<mark_weaver>you could use a different character and then use 'string-map' to map it to tilde in the uri field. see icu4c for an example use of 'string-map'.
<mark_weaver>the set of allowed characters in store names is apparently ASCII alphanums plus "+-._?="
<mark_weaver>rekado: ^^
<mark_weaver>I would probably use '-' in place of the '~' in version, but I'll leave it to your best judgment :)
<mark_weaver>oh, there's another issue.
<mark_weaver>'version-compare' should ideally do the right thing here.
<mark_weaver>i.e. it should consider 0.6.0~rc2 to be older than 0.6.0
<mark_weaver>I'm not sure we can achieve that with our current 'version-compare', which just wraps strverscmp
<mark_weaver>(from libc)
<rekado>on the bright side: there hasn't been any other release since about 7 years.
<mark_weaver>well, don't let this block you. maybe we can improve it later.
<mark_weaver>heh :)
<mark_weaver>anyway, I must sleep. happy hacking!
*mark_weaver --> zzz
<civodul>Hello Guix!
*civodul has just booted into a system with the brand new splash screens
<rekado_>ouch! Just realized that my package for jack doesn't include the alsa backend module... Will fix this after testing some more.
<civodul>does it have PA?
<rekado_>the problem is that I forgot to add alsa-lib to the inputs and pkg-config to the native-inputs.
<rekado_>also, I'd like to rename the package name of the "jack-2" variable to "jack2", so that it's easier to install either JACK1 (just "jack") or JACK2 ("jack2")
<rekado_>JACK2 isn't supposed to obsolete JACK1, so it's probably wrong to have both packages use the name "jack".
<ewemoa>PA == pulse audio?
<civodul>yes, PulseAudio
<civodul>i thought an audio geek would know that ;-)
<civodul>rekado_: regarding the package name, it's fine to call them "jack1" and "jack2" if that reflects upstream's view
<rekado_>Oh, I tried hard to forget about pulseaudio. PA means "Public Address" to me ;)
<rekado_>JACK1 does not have a pulseaudio backend.
<civodul>oh really?
<rekado_>the recommended way to use JACK on a pulseaudio system is to temporarily suspend pulseaudio.
<civodul>i quite like PulseAudio
<civodul>heh, ok
<rekado_>JACK is very simple. It's little more than a shared buffer for audio clients.
<rekado_>This allows it to be fast.
<rekado_>Pulseaudio has different goals and they are incompatible with what JACK achieves.
<rekado_>it's possible to route JACK through PulseAudio but that's rather silly as you lose the guarantees of JACK.
<rekado_>here's some more info about this:
<rigelk>civodul, what web server the G(SD) web site runs/should run on ? (i’m wondering if a guile web server handles it by now)
<rekado_>hmm, the test suite for R fails probably because of locale-related issues. Works fine in guix environment --pure.
<rekado_>adding an 'install-locales phase where en_US.UTF-8 is installed and set using setenv LANG doesn't seem to help.
<phant0mas>I am trying to remove a member of a list after first finding it with (cut (string match...)) but I get unquote: expression not valid outside of quasiquote in form (unquote cf)
<phant0mas>any ideas on what am I doing wrong?
<civodul>rigelk: uses Apache httpd i think
<civodul>it'd be nice to use a Guile web server though
<civodul>phant0mas: change ",cf" to "cf"
<civodul>comma is equivalent to "unquote"
<civodul>and unquote can only appear within a "quasiquote" (backtick)
<effa`>rekado_: could this have to do with time zone? See
<phant0mas>civodul: isn't string-match defined in ice-9 match? Because I am getting Unbound variable: string-match
<civodul>string-match is from (ice-9 regex)
<civodul>read the fine manual ;-)
<rekado_>effa`: good idea. I'll try to patch in the setting of TZ.
<rigelk>civodul, is there a way to submit an update to the Guix web page (hosted on
<nebbia>hi everyone, i have a question, if my installation of linux doesn't support a certain hardware is there the possibility to install drivers ? i mean how do you proceed when installing drivers for unknown hardware ? do you search for the module ?
<nebbia><nebbia> are there sites for hardware ? or what
<rekado_>nebbia: do you have particular hardware in mind?
<rekado_>nebbia: also, what do you mean by "installation of linux"? Are you using the Guix system distribution? Or some other GNU/Linux distribution?
<rigelk>nebbia, a lspci -k on a working linux distro should help to find the module, as mark already told me
<rekado_>effa`: (setenv "TZ" "UTC") really does fix the tests. Yay! Thanks again for the hint!
<nebbia>but lspci -k tells me the actual driver in use not the required module, how do i know the specific module for a certain hardware?
<jxself>You don't see it also saying: "Kernel modules" right below where it says "Kernel driver in use"?
<nebbia>jxself no there isnt'
<jxself>You asked in a few different channels so I'm not clear if you actually use Guix or not.
<nebbia>sorry not...
<nebbia>i'm using debian
<jxself>OK. See my comment in #gnu then about trying a newer kernel.
<nebbia>thank you
<civodul>rigelk: sure, do a CVS checkout of the web pages (!) and send a patch to the list
<nebbia>which are cool things about guix ? i've heard that it doesn't follow fhs is it true '
<civodul>jxself: BTW, what would it take to have framebuffer + Freedo on boot?
<civodul>jxself: is that possible in a generic fashion, i.e., without explicitly loading i915 or some other hardware-specific module?
<effa``>rekado_: glad it helped :-)
<jxself>Ah, it'd be nice to see Freedo on boot huh?
<jxself>That should be doable. I shall look into it but not now - I gotta get ready to leave.
<bavier`>semi-serious roadblock in the hydra packaging: one of the dependent modules is nonfree
<mark_weaver>bavier`: which one?
<bavier`>it's vaguely under the Artistic 1.0 license
<mark_weaver>jxself, civodul: lxo distributes a ready-made freedo patch, but it's not included in the main tarballs by default.
<bavier`>I did send an email to the maintainer asking if they'd consider re-licensing
<mark_weaver>bavier`: thank you
<bavier`>mark_weaver: np; now just to wait for a reply ;)
<mark_weaver>jxself, civodul: here's a copy of the patch in the linux-libre SVN repo, but I'm having trouble finding a more canonical for it:
<mark_weaver>it's in the freed-ora subdirectory. there's another copy in the lemote directory too as I recall.
<mark_weaver>but it's generic AFAICT
<mark_weaver>here's the actual SVG:
<mark_weaver>if you search for "freedo.patch" on the main linux-libre site <> it links to the lemote directory of the SVN repo, so maybe there really is no better location :-(
<mark_weaver>and that would be:
<mark_weaver>on the plus side, the patch is trivial except for the embedded image, which we could generate ourselves, so maybe we should just take it internal.
<civodul>mark_weaver: we do have the patch already, just no framebuffer support on boot
<mark_weaver>oh, okay
<civodul>bavier`: ouch, good catch
<civodul>it definitely went unnoticed
<taylanub>mark_weaver: by the way, my moreutils patch is still lingering
<mark_weaver>taylanub: oh, thanks for the ping
<mark_weaver>oh, right. I was hoping someone could chime in with a better solution to the docbook-xsl thing, but I guess not
<nully>i usually use privoxy as a lazy socks proxy
<nully>back scroll :) responding to old messages
<bavier`>hello ben____
<davexunit>ben of many underscores
<ben____>hi, my (very beginner) question: is it possible to install non-free software (corporate code) with guix?
<grantixx>Well yeah, there's no DRM or anything in-place though ... obviously it's not reccomended.
*grantixx just noticed the Logo-update on SLIM in the gitlog. :^)
<bavier`>ben____: guix and the guix system distribution are committed to only including free software, but as grantixx notes, there's no restrictions in place, so for personally use you can do what you want.
<phant0mas>I have a question, if string match compares a regexp with a string, how can we find a string from a list?
<phant0mas>Because when I use (remove (cut string-match "--with-headers.*" <>) cf) where cf is a list
<phant0mas>I get that "in procedure regexp-exec: Wrong type argument in position 2 (expecting string): list"
<phant0mas>I have found uses of the above code in other recipes and according to the guile manual I think I am doing it right
<phant0mas>so what am I doing wrong?
<ben____>bavier: I'm looking for a way to make my own deployments saner and I think guix could be helpful.
*grantixx wishes he didn't have a real busy weekend, or he would start working towards Stumpwm. taylanub work has saved a lot of effort in route to that. :^)
<davexunit>ben____: it certainly can help make deployments saner
<grantixx>davexunit: Publish or whatever it was called, that you were/are working on is great for local deplowment too.
<davexunit>also a good first step towards peer-to-peer distribution
<ben____>davexunit: thanks, the only thing is unclear to me. If I use guix to deploy my own shitty java webtools how can use guix and not violate any policies.
<grantixx>Violate policies on which end, Guix's or the webtools?
<grantixx>Which policies are you worrying about breaking?
<davexunit>ben____: well, we would not accept contributions of proprietary packages upstream.
<ben____>using closed software withing GPL licensed software
<grantixx>If you package non-free software, it just won't make it upstream. It'd be seperate from Guix in the sense that it would nod have a chance to be merged ever.
<davexunit>ben____: the GPL applies to those you distribute guix to.
<grantixx>ben____: Ah, you mean policies in the sense of legality?
<grantixx>ben____: How is this different than writing non-free Linux modules?
<grantixx>I'm pretty sure it's legal, but I'm not a lawyer nor expert by any stretch in this field.
<davexunit>ben____: I feel like I need a little more information to understand your situation. for us, the bottom line is that we're committed to providing a fully free distro.
<grantixx>ben____: I think they are worried about if it is legal to write Guix packages (Gpl software, which if it's not upstreak it doesn't need to be GPL... right?) for non-free software.
<grantixx>I could be way off though, just woke up and still partially out of it.
<davexunit>well, whether or not the software packaged is non-free isn't particularly important in this case.
<davexunit>a guix package is a derivative work of guix, and thus subject to the terms of the GPLv3.
<davexunit>if/when distributed.
<ben____>davexunit: I have a scenario in mind, but maybe I'm completely wrong with this. I'd like to package my coding sitting in private repository so that I can installing on production machines.
<grantixx>davexunit: In any case, you can write GPLv3 software that interacts with non-free software if you don't distribute it right?
<ben____>davexunit: this is boring corporate stuff, this private code doesn't even have a license :-)
<davexunit>grantixx: your own undistributed code is free in the trivial sense.
<grantixx>ben____: What happens if your companies code gets "leaked", legally?
<davexunit>grantixx: I think that is just confusing the situation.
<davexunit>with no license, that code is "all rights reserved"
<davexunit>and the company has the copyright.
<davexunit>let's not worry about that.
<grantixx>davexunit: Yeah, sorry I was just generally curious.
<davexunit>ben____: okay, so to be clear: writing a guix package does not impose any sort of licensing restriction on the packaged software.
<grantixx>Ah, thinking back that makes sense. Explains the issue with Github a few years back.
<ben____>davexunit: thanks, and do you know where this is (technically) described in the manual?
<davexunit>we, the upstream developers, will only accept packages into the official repository that are freely licensed.
<davexunit>ben____: it's not, afaik. this is just some basic copyright talk.
<grantixx>A small blurb might be useful, maybe? :^P
<davexunit>I don't think so.
<ben____>davexunit: sorry, I meant, is there some description on how to setup a private repository (if that's even necessary)
<nee>davexunit: if you write a guix package, only the package.scm derivates guix. The software that the package builds should not be affected by the GPL?
<bavier`>ben____: clone the git repo.
<davexunit>nee: yes. if you look at our packages, we package software that is BSD3 licensed, or Apache 2.0 licensed, etc.
<davexunit>that software is not suddenly a derived work of guix because we packaged it. that's backwards.
<ben____>I was looking for something like /etc/apt/sources.list :-)
<rigelk>ben____, you want to setup an hydra clone. hydra builds the packages definition and makes them available as substitutes
<davexunit>ben____: you can fork the guix repo and keep your custom patches in a separate branch, some of us do that already for our personal patches.
<davexunit>ben____: OR
<davexunit>you can manipulate GUIX_PACKAGE_PATH
<grantixx>Is it worth donating a machine and bandwidth to Hydra?
<davexunit>and point it at a directory that contains package definitions. that *is* documented in the manual, if you want to read more.
<grantixx>I have a okay-tier box I could donate to x64 build.
<davexunit>I do this for a couple of custom packages I wrote for unreleased software that aren't suitable for upstream yet.
<rigelk>grantixx, please submit your hydra hardware donation to guix-sysadmin mailing list
<davexunit>ben____: we don't have anything like /etc/apt/sources.list, because our packages aren't just files sitting on a remote server somewhere, they are full Scheme objects defined in the source code of Guix.
<grantixx>rigelk: Would it need to be a dedicated box?
<ben____>thanks alot for this information. I'll go back to the manual.
<grantixx>Like fully*
<grantixx>Solomly it's used as a HTPC, but most of the time it's just sitting there.
<rigelk>grantixx, no. it needs a ssh access with root rights called hydra, and a guix dæmon running. Up to you to allocate the ressources you wish to give it :)
<grantixx>rigelk: Ah, okay. Will add to my todo-list then. :^)
<rigelk>remember to configure your NAT settings grantixx, so that your HTPC remains accessible from us.
<benjb>I've another question regarding installation of guix.
<benjb>I'm not so comfortable with installing guix on my running ubuntu. Do you have any experience with qemu or virtualbox?
<grantixx>rigelk: Also noted, thanks. It'll probably be closer to the end of the month of begining of next before I take more tangibale action in route to this though fyi.
<grantixx>benjb: Guix's "system vm" module exports to qemu. :^P
<grantixx>It should be trivial to install to a Qemu image from the usb-install image though.
<civodul>benjb: the package manager itself is non-intrusive: everything it installs is in /gnu
<civodul>so there's not much to be afraid of when using it on another system
<civodul>at worse you could always rm -rf /gnu and be done with it
<benjb>civodul: are the many environment variables that are changed by guix ( like PATH, ..)?
<benjb>I'm asking this because with 'brew' (macosx) there was confusing situations with gcc and libraries.
<davexunit>benjb: we have an automated way of configuring the proper environment variables for the packages you've installed
<benjb>and this is a one time operation, or per user session ?
<davexunit>you would call the relevant guix command in your bash_profile or bashrc as needed
<davexunit>'guix package --search-paths' will print out the env vars
<davexunit>then you can source them
<benjb>I'm reading about 'guix system vm'. Fascinating stuff. Does that mean I can build and deploy an app and the underlying os from scratch?
<davexunit>benjb: yup.
<effa```>I find that icecat doesn't use PulseAudio and can't find a way to specify to use it. Any suggestion?
<davexunit>effa```: I also ran into that problem, also no WebGL. haven't figured it out yet.
<effa```>OK. thanks.
<davexunit>sorry I don't have good news
<paroneayea>oh yeah, and since I left #guix hanging
<paroneayea>I've got guilemacs running :)
<paroneayea>so I can probably do a guix package
<paroneayea> wooo
<benjb>is the notion of a 'registry' with base images also something that could make sense for guix? (comming from docker:
<davexunit>benjb: I don't see much value in it, but maybe.
<davexunit>the thing is, docker requires images in order to work, afaict.
<davexunit>guix does not.
<davexunit>with docker, you'd start with a debian image or something, and then go through some "generations" of adding packages and setting things up.
<davexunit>and I think, but am not sure, that each step along the way is cached.
<davexunit>correct me if I'm wrong, please. :)
<rigelk>correct, unless given --no-cache option
<davexunit>that process of incremental caching is much different than the way guix/nix work.
<davexunit>we use a declarative configuration file and say "configure the system to be like this"
<davexunit>rather than "start with a debian image, apt-get install mysql, apt-get install apache2, etc."
<rigelk>benjb, is "repository" a notion that lacks meaning for what you plan to do ?
<benjb>IWhat I would like to do is to package my app with an os.
<davexunit>benjb: how so? what kind of an application is this?
<benjb>And then be able to install this package with as little effort as possible ( not using virt. images) bit have the application and its setup installed with 100% accuracy.
<benjb>Right now I'm looking for a solution for a simple Perl web app.
<davexunit>okay, so you don't want to distribute a VM image or something, makes sense.
<benjb>yes, yes correct.
<davexunit>so, the first step would be to write package recipes for the components of your application.
<davexunit>once the packages build and work properly, you can work on writing an OS configuration that includes those packages, and all the system services necessary to run it: database server, web server, etc.
<benjb>That would mean receipies for : 1. Perl, 2. JSON::XS module, 3. the 'uwsgi' server with the specific 'psgi' configuration, ...
<benjb>and then writing configuration (with shell command?) on how to stitch the setup together?
<benjb>how do you do the finer stuff, configuration files, permissions, etc.
<davexunit>benjb: well, we have perl covered at the very least.
<benjb>or is this not the target for guix?
<davexunit>you can do configuration files for sure
<davexunit>this is an area I haven't explored fully yet, I'm also working on automating web application deployment.
<davexunit>but you'd be almost all the way there if you had the necessary software packaged and the necessary system services defined.
<benjb>davexunit: are you a guix develeoper, or a user like me?
<davexunit>benjb: developer, but I'm not the maintainer, and I don't know how everything works. :)
<benjb>scary :-)
<davexunit>I just haven't explored everything there is. :)
<davexunit>like defining new system services, I haven't had to do that yet.
<benjb>is the nixos manual something that can be helpful, or is guix too different?
<davexunit>it wouldn't be particularly practical
<davexunit>it might be helpful to learn more about the concepts that nix and guix share, but that would be it.
<davexunit>our CLI is different, our implementation language is different, etc.
<Gabou>I've sent an email to guix-devel mail list but it looks like it hasn't been received, any idea?
<Gabou>Is there any pending system where my mail nees to be approved or something?
<davexunit>Gabou: how long ago?
<davexunit>did you subscribe to the list?
<Gabou>like 20 minutes ago?
<grantixx>Test fails for building Clisp on my end.
<davexunit>Gabou: the gnu mail server gets a lot of traffic, wait a bit.
<grantixx>Pulled from the latest, tried to update my config file and reconfigure.
<grantixx>taylanub: ^
<davexunit>how are you checking that it has been received? the archive?
<davexunit>the archive isn't updated in real time.
<Gabou>davexunit: oh sorry I will wait then...
<Gabou>Well, I've checked in the archive but it says refreshed every 30 minutes so.. yes maybe I should wait more
<davexunit>Gabou: sometimes mail goes through quickly, sometimes it gets queued up for awhile.
<davexunit>Gabou: what's your email address? I will check if I've received it
<Gabou>gnu mail list server is really huge, lot of lists in here
<benjb>where is the best source to learn about guix concepts?
<Gabou>It's about torrents and gsd
<davexunit>benjb: the guix manual.
<benjb>yes I've red it but still guix feels very blackboxish to me
<benjb>there is the package manager, the operating system, the public repository, hydra, etc.
<benjb>I would like to read more about the components.
<benjb>... and how they play together
<davexunit>Hydra is from the Nix project, so you could find their docs about that one.
<davexunit>it's a continuous integration system
<davexunit>sort of like Jenkins or Travis-CI if you're familiar
<rigelk>hydra handles the public repository as well
<davexunit>our instance of hydra does, yes.
<davexunit>it builds the packages for us.
<benjb>another problem: can't untar the usb image gsd-usb-install-0.8.1.x86_64-linux.xz
<benjb>nevermind (unxz)
<rigelk>yup. xz -d works as well
<grantixx>paroneayea: Oh, very neat! I would love a Guilemacs package floating around somewhere. :^)
<grantixx>Are there any benifits to *.iso that I should be aware of? People keep brining it up to me as a desired method to play with Guix(SD).
<bavier`>grantixx: I've noticed a lot of requests for iso's as well
<grantixx>Well, it was the 3rd person to do-so. Not suer if that's can count as "keep bringing it up".
<bavier`>I think it's a familiar method for many people
<rigelk>grantixx, GSD is bundled as a hard drive image, which seems to make a difference compared to legacy .iso
<bavier`>and there are many tools out there to work with live cd's
<grantixx>bavier`: Yeah, was about to mention this. It's probably an expectation to many coming from "Linux Distro" culture.
<bavier`>grantixx: yup
<bavier`>I'm sure we could create one...
<grantixx>rigelk: I mean, unless your bios don't support usb images ... it shouldn't be an issue right? The usb-image install.
<grantixx>bavier`: ZDavis was working on it for awhile, don't know if he hit a road bump or life just got busy though.
<bavier`>grantixx: ah, ok
<grantixx>taylanub: Writing log to file, error again after another run through on x86.
<rigelk>grantixx, i’m having such bios errors :)
<grantixx>rigelk: Did you make a bootstrap partition on the actual drive?
<grantixx>Not pretty, but works.
<grantixx>I have the same issue on one of my test Laptops.
<rigelk>no. ’mind explaining ? it sounds interesting
<grantixx>rigelk: Okay; I alloted 10gb or-so to a partition on sda1 for Parabola GNU+Linux-Libre which I installed from a *.iso on a physical disc (cd) to the physical disk (the harddrive). Then from that install, I built Guix on the host distro (Parabola). Once that built I allocated the remainder of the drive to an empty ext4 partition, mounted that partition, then "guix system init /etc/config.scm /mnt" and let it work it's magic.
<grantixx>Of course, make sure the disk-label section is pointing to that portion of the drive so GSD's install will overwrite the current Grub config.
<benjb>hi I try to install the usb-image on qemu, can I boot directly from that image?
<grantixx>Yes? You mean you want to boot qemu from the usb-image to install to a qemu image?
<benjb>a qemu 'disk' you mean?
<grantixx>A virtual disk, yes.
<benjb>I was a bit confused about the whole "usb" part
<grantixx>benjb: The install medium for Guix is called a "usb-install" image.
<grantixx>GuixSD rather.
<benjb>"usb-install" is this a term?
<benjb>and another question
<taylanub>grantixx: you're on 32b?
<grantixx>Should "guix system reconfigure /etc/os-config.scm >> fail.txt" work to genrate a log file or am I way off?
<grantixx>taylanub: Yeah.
<grantixx>i686 on this box, my main box is x64.
<grantixx>I might switch back over to GSD on my mainbox now that Clisp is packaged though.
<taylanub>x64 means x86_64 AKA amd64 thus 64b, right? do you have guix on it? can you test CLISP from Guix on it?
<grantixx>taylanub: Yeah, I'll go down to my main box and pull down the latest now and get back to you. Give me a few.
<grantix>Okay pulling latest now.
<grantix>taylanub: Yeah, worked for x64. But it also didn't try to build the package from source. Maybe there isn't an i686 subsititue on Hydra yet?
<grantix>Don't know why the build would fail on my end on that machine though.
<grantixx> Okay, going afk a bit. Will look into it more tonight or tomorrow likely. o/
<benjb>nixos and xen. interesting read:
<benjb>could this also be done for guix?
<davexunit>benjb: guix can create KVM machines
<davexunit>rather than Xen
<zacts>hum.. I'm trying to learn a good way to encrypt email
<a_e>mutt and gnupg
<zacts>let me show you what I mean
<zacts>I also found this
<zacts>oh and..
<zacts>STEED is a new idea for an email standard, apparently
<davexunit>zacts: if you use emacs, notmuch does well with gnupg
<zacts>I'm using emacs yes
<zacts>oh cool notmuch is similar to sup
<zacts>I've wanted to try sup, but I couldn't get it to build last time I tried
<a_e>Some interesting points. Especially number 11.
<a_e>Some moot ones. Like 8: If I just want to encrypt, I do not need to sign.
<zacts>davexunit: how does notmuch integrate, or make gnupg more powerful?
<a_e>The metadata problem also is bad.
<zacts>although, apparently gnunet could circumvent many of these issues
<zacts>a_e: ^
<davexunit>zacts: well, if encrypted mail uses the proper mime types, I can simply press $ to decrypt it
<davexunit>so that's convenient
<zacts>I'm thinking a gnunet based email system would be cool
<zacts>oh cool
<davexunit>in cases where the encryption is the old inline style, I highlight the region and run M-x epa-decrypt-region
<davexunit>that's not a notmuch feature, though.
<davexunit>just a handy emacs thing.
<zacts>I'm actually using emacs bindings now, and I don't mind because org-mode is so cool
<zacts>org-mode was the killer feature that switched me over completely to emacs from vim
<zacts>hum.. also I didn't realize that gnupg was so severely underfunded
<zacts>but they've made a lot of progress with that apparently
<rekado>I'm using mu4e which is very much like notmuch but integrates better into Emacs, in my opinion. I used notmuch for a few months before switching to mu4e.
*paroneayea using mu4e also
<benjb>hi, sorry to interupt, I'm still reading documentation on guix and nix*. Currently on nixops, which seems very useful. What do you think it?
<davexunit>it's good and we need something like it
<benjb>this paper is also interesting (on "charon" former name of nixops)
<davexunit>yeah, I read that a week or so ago.
<davexunit>interesting stuff.
<Gabou>davexunit: I saw my mail on the mail list so I guess it's okay
<Gabou>hope I'm helping with what I can provide
<paroneayea>I'd love to have something like nixops for guix
<davexunit>in due time, it will happen