<rgc>question: I'm about to send the recipe as an attachment and gnus asks me the type of attachment (defaulting to application/octet-stream). is it ok to send it like this? <mark_weaver>butif you already sent it as application/octet-stream, no worries. <rgc>oks. I already sent it, but good to know. thanks for the info. <mark_weaver>actually, I guess "text/x-patch" is really the most proper. <civodul>did a little bit of hacking on the train, but i was really too tired <atheia>:-) tell me about it — and I didn't even take part in the hacks <atheia>Nice to be able to pick up all my projects again. <atheia>So I sent 2 patches working on the 'normal user' experience of dmd, <civodul>yeah i noticed, just didn't take the time to look into them yet <atheia>I think the functionality is there, but I'm not sure about the implementation <civodul>good that you're working on improving things <atheia>Just wanted to let you know I'm open to feedback on the structure. <atheia>One thing that strikes me: currently, I think, you can load additional service definitions as dmd is already running, <atheia>But adding a service that is already defined causes an error (presumably because the service already exists. <atheia>It would be quite nice I think to just be able to 'override' the old definition <civodul>when you do "deco reload something"? <atheia> Evaluate the Scheme code in FILE in a fresh module that uses the <atheia> ‘(oop goops)’ and ‘(dmd services)’ modules—as with the ‘--config’ <atheia> option of ‘dmd’ (*note Invoking dmd::). <civodul>actually you're right, there's no reload <atheia>loading a file containing existing service definitions (existing #:provides): <atheia>Assertion (null? (lookup-services (canonical-name new))) failed. <atheia>Simply renaming provides to something new then works <civodul>then maybe dmd should have a "remove" action to remove a service <atheia>So I think it may have to do with the requirements for #:provides to be unique (which makes sense), and by not having a mechanism for 'redefining' or 'overriding' the pervious definition of the service identified by #:provides. <atheia>So you have your init.scm, you start dmd, then notice you want to change some of the definitions in yourinit.scm <atheia>You make the changes to init.scm, run a generaly unload procedure to unload all service definitions and reload the file? <civodul>or i would do "deco remove dmd foo && deco load dmd file-that-defines-foo.scm" <civodul>even better would be to have dmd start a REPL server on a Unix-domain socket <atheia>And then simply connecting into it. <atheia>I think Andy at some point mentioned there might be issues around the safety of the --listen flag for Guile on multi-user systems <atheia>(I think it was in the context of tekuti, his blog, but that may be outdated) <civodul>yes, because --listen opens a TCP socket <civodul>so we'd instead open a Unix-domain socket <atheia>I think we probably want to provide both approaches <atheia>the 'remove' action, and the unix domain socket :-) <atheia>I know emacs is the light, but there might be those who want to use dmd without emacs :-) <atheia>Cool, I'd be pretty interested in adding the 'remove' action approach to my to do list for the short-term-ish. The unix-domain socket thing sounds a little more involved (might take a little longer from my side). <civodul>atheia: great if you can do the 'remove' thing <civodul>i just realized we don't even have a 'TODO' file in there <civodul>atheia: i noticed you use "mu" for email, how do you like it? <viric_>I user mairix since years. Very fast, little storge. <atheia>It's use is pretty close to dired. <atheia>Which took a while to get right, but works a charm now <viric_>offlineimap worked very bad for me. mbsyc is a huge win! :) <atheia>mu4e is a client for emacs that uses the indexer <atheia>mbsync… interesting. Should offlineimap ever give me problems again then that might come in useful :-) <viric_>offlineimap took a huge cpu usage for me <viric_>so mbsync worked many times faster with barely any cpu use <atheia>I see. Maybe it's optimised: it's working fine for me now, and generally only needs a few sec to resync my emails. <zacts>civodul: has any progress been made with an alternate kernel? HURD? <zacts>I would actually eventually be interested in a gnu/kfreebsd guix <zacts>we almost have the deblob script working, and we are going to borrow previous work from debian <civodul>zacts: no progress at all as it's not high-priority currently <civodul>but as said on #guile, i'm happy if someone else works on it <zacts>first we'll fully deblob the FreeBSD kernel. the projects can share work. then we'll see about a basic gnu userland with guix, borrowing from debian's work and the libc patches. <zacts>the goal of the other project is to have a bsd userland and bsd kernel. while the guix would be a gnu/kfreebsd. <zacts>although, we may use a newer gcc in place of llvm/clang <civodul>well i'm not interested in the BSD userland for Guix <civodul>as for kernel deblobing, i think that's something the Debian folks are already doing <zacts>civodul: I know, gnu userland for guix. <zacts>we are, I've been chatting with them. ***Steap___ is now known as Steap
<zacts>oh, btw civodul I've ported candy crush to guix. <zacts>just to see if you guys are awake <zacts>but, seriously when I have patches I'll let you know. bbl. <mark_weaver>civodul: btw, I read the slides of your recent presentation, and the stuff near the end about system configuration is very exciting! it inspired me to update guix on all my machines, including my 2F. <mark_weaver>somehow, I had no idea things had progressed so far on that front. <davexunit>I read the slides as well. they were very interesting. can't wait to watch the full presentation. <civodul>mark_weaver: just noticed your comment about the talk <civodul>the last demo was pretty fun for me :-) <civodul>maybe more fun for me than for people in the audience ;-) *mark_weaver looks forward to seeing the video :) <jmd>Some upstream sources publish thier sha256 <jmd>However not in base32 <jmd>Can we have have the sha256 in base 16? <civodul>jmd: yes, with (base16-string->bytevector "...") <civodul>but i'd rather keep them base32 in files, so it's more compact <jmd>In the chroot jail, it seems that rsh localhost is not possible. <jmd>I thought that localhost was still supposed to be accessible? <jmd`>Oh. rlogind. I have no idea. <jmd`>I'll check, thanks for the tip <jmd`>Should /etc/passwd be available in chroot ? <jmd>There is a "nobody" in /etc/passwd but there isn't a "nogroup" in /etc/group <jmd>I have a test which needs one. Can we add it? *civodul tries out Inkscape, woot!