IRC channel logs


back to list of logs

<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?
*rgc totally newbie
<mark_weaver>rgc: it's best to send patches as "text/plain"
<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.
<mark_weaver>oh well, he already left
<civodul>Hello Guix!
<civodul>hello atheia
<atheia>Good morning
<atheia>Good journey back home?
<civodul>did a little bit of hacking on the train, but i was really too tired
<civodul>and you, recovering from the flu?
<atheia>:-) tell me about it — and I didn't even take part in the hacks
<civodul>heh :-)
<atheia>I'm pretty much there now.
<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>will do later today
<atheia>That's fine no worries
<civodul>good that you're working on improving things
<civodul>dmd needs love :-)
<atheia>Just wanted to let you know I'm open to feedback on the structure.
<atheia>:-) true. And it deserves it…
<civodul>yeah, i like it
<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>There's a reload command?
<civodul>yes :-)
<atheia>I was using the load command.
<civodul>lemme check the name
<atheia>‘load FILE’
<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::).
<atheia>That's the one I was using
<civodul>actually you're right, there's no reload
<civodul>only 'load'
<atheia>loading a file containing existing service definitions (existing #:provides):
<atheia>Loading /home/alex/test.scm.
<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>Right — that would work.
<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
<civodul>so root could connect to that
<atheia>And then simply connecting into it.
<civodul>with Geiser for instance ;-)
<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>Ah, so different approach
<civodul>and that file would be 600 for root
<atheia>Yeah that'd be cool
<atheia>I think we probably want to provide both approaches
<atheia>the 'remove' action, and the unix domain socket :-)
<atheia>(2 different user workflows)
<atheia>I know emacs is the light, but there might be those who want to use dmd without emacs :-)
<civodul>yes, both approaches is best
<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>the REPL can wait a little longer
<civodul>i could look into it sometime
<civodul>i just realized we don't even have a 'TODO' file in there
<civodul>i'll add that to my to-do list :-)
<atheia>:-) sounds fair.
<civodul>Saturday's NixOS talk:
<civodul>atheia: i noticed you use "mu" for email, how do you like it?
<atheia>civodul: I do indeed
<atheia>I find it great
<viric_>ah an indexer.
<civodul>but it's only local storage, right?
<civodul>no IMAP
<viric_>I user mairix since years. Very fast, little storge.
<atheia>It's use is pretty close to dired.
<viric_>also only local.
<atheia>Yeah, I use it with offlineimap
<atheia>Which took a while to get right, but works a charm now
<atheia>viric: mu is an indexer
<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>ok cool.
<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.
<civodul>so you could borrow from them
<civodul>yeah ;-)
<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>(totally joking)
<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>(the 2F will be working on this for a while :)
<mark_weaver>somehow, I had no idea things had progressed so far on that front.
<mark_weaver>(been focused on guile lately)
<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 :)
<davexunit>I really want to see that demo.
<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?
<sriharsha>jmd`, is rlogind running inside the chroot?
<jmd`>sriharsha: I think so
<jmd`>Oh. rlogind. I have no idea.
<sriharsha>or is it called rshd?
<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!