IRC channel logs

<vmlinuz88>paroneayea davexunit: Is there perhaps a more stable (less unstable) version of Guix than what is available in its git repo?

<davexunit>vmlinuz88: no, this is alpha software.

<vmlinuz88>davexunit Thank you; I figured as much. Also, I'm running guix as a standalone on Fedora 21; I attempted to install a package (dfc) and received the following error: Failing tests: 17: test_option_b (2 failures).

<davexunit>vmlinuz88: this failure was when compiling dfc?

<vmlinuz88>I also looked at the log for test_option_b, and it said "File archive1.tar has size 3072, expected 2048" and "bsdtar does not pad archives written directly to regular files"

<vmlinuz88>davexunit Yes

<davexunit>vmlinuz88: could you file a bug at bug-guix@gnu.org

<davexunit>with the relevant details

<vmlinuz88>davexunit Sure thing

<davexunit>reproducibility bug

<jdahm>basic question: I'm trying to install guix from the latest .xz image directly to a virtual machine using gnome-boxes, but that only allows using .iso and devices. I've tried mounting with mount -o loop gsd.... but mount can't determine the fs type that way. I've also tried renaming it to .iso but that leads to a corruption error. Is there an easy way to do this without a thumb drive handy?

<vmlinuz88>davexunit Also, I thought guix retrieves binary packages from hydra by default, but it appears that it is trying to build the dfc package. Is there something I need to do specifically to get binaries?

<davexunit>jdahm: it's a raw disk image, yeah.

<davexunit>we don't yet provide ISOs because no one has done the work to generate one

<davexunit>vmlinuz88: you have to authorize hydra.gnu.org

<vmlinuz88>davexunit Ah, okay thank you.

<davexunit>it only downloads binaries by default in the installation image

<jdahm>davexunit: yep, I got that. Is there a way to mount that in linux so that it thinks that's a device?

<davexunit>jdahm: not sure, I've never tried that.

<jdahm>davexunit: got it! used some trickery

<paroneayea>so, interesting idea I was discussing with a friend: using Guix + Hydra as a continuous integration / pipeline system for a blender free culture film

<paroneayea>why not?

<paroneayea>typically there's a complex depgraph that's more or less handled manually:

<jdahm>davexunit: basically I had to specify an offset following the response by @baumgart here: http://superuser.com/questions/117136/how-can-i-mount-a-partition-from-dd-created-image-of-a-block-device-e-g-hdd-u

<paroneayea>xcf files which render to png files which are used in .blend files that render to a lot of .png files that are brought into ffmpeg into a movie

<kete>you should blog that, jdahm

<jdahm>kete: yeah I've been meaning to begin a blog for this sort of thing... will get around to it soon. Adding it to my queue of posts now

<jdahm>kete: I am very interested to play around with guix, especially once it hits 1.0

<kete>yeah, me too, or .9 even. I couldn't get .8.1 installed on bare metal. A microblog mention would be fine, too. might help someone

<kete>been busy with school

<cmhobbs>is there an off chance that clojure is in guix yet?

<davexunit>cmhobbs: not yet.

<davexunit>paroneayea: that's a good idea!

<davexunit>jdahm: thanks for the link!

<davexunit>we should mention this technique somewhere

<davexunit>until we can provide ISOs

<cmhobbs>davexunit, thanks

<cmhobbs>wishful thinking :D

<davexunit>cmhobbs: someone has been working on openjdk

<davexunit>so maybe we'll see it someday

<davexunit>I imagine we're quite a few dependencies away.

<cmhobbs>i'm hoping guix hits stable before jessie replaces wheezy. my current development projects require guile, ruby, and clojure

<cmhobbs>i can get by without other packages i use

<cmhobbs>well, and emacs

<cmhobbs>yeah, we're probably a long way away

<paroneayea>cmhobbs: before jessie replaces wheezy?

<paroneayea>jessie was released!

*cmhobbs falls over

<cmhobbs>i need to come out of my cave more often

<paroneayea>just last week! :)

<cmhobbs>well, i have to update this box at some point

*cmhobbs dreads that

<cmhobbs>i fear change

<paroneayea>I think it would be great to have a guix package for debian

*paroneayea says, for the 1 millionth time ;)

<cmhobbs>i'm using guix on wheezy

<cmhobbs>not as a debian package though

<davexunit>the .deb would have to be unofficial

<davexunit>since we wouldn't meet the official debian criteria

<paroneayea>right because of the FHS

<paroneayea>davexunit: new debian leader wants to support PPAs anyway :)

<davexunit>yay

<davexunit>zzz

<davexunit>later all

<vmlinuz88>is there a way to update or refresh the package derivations in the /gnu/store directory?

<vmlinuz88>I accidentally removed one

<rekado->re clojure: we have the JDK7, but we do not have any of the common Java build tools with the exception of ant.

<rekado->ardour fails with validate-runpaths. I'll fix it tonight.

<rekado->gcj failed in validate-runpath. I thought all gccs had their rpaths fixed.

<rekado->elogind built.

<civodul>Hello Guix!

<vmlinuz88>Hello civodul

<effa>Hi civodul

<effa>thanks for the feedback on hackage importer!

<effa>unfortunately right now I do not have time to work on it.

<effa>But, will come back to it, hopefully in 1--2 weeks.

<effa>I have a question/suggestion:

<effa>In Haskell you can sequence functions in a Monad with

<effa>m >>= f1 >>= f2 ...

<effa>As far as I understand in your guix module

<effa>(>>= m f1 f2 ...)

<effa>is not supported.

<effa>If this is correct, don't you think that it would be helpfull?

<civodul>hi, effa!

<civodul>oh, right

<civodul>it would probably be helpful indeed

<civodul>maybe not too difficult either

<civodul>(actually i mostly use mlet to hide the binds)

<rekado_>I thought it was supported already? I have my own little guile-monad module and I can sequence monadic functions: http://git.elephly.net/?p=software/guile-monad.git;a=blob;f=test.scm;h=02f5f0a350a99470f38d74d42a5b39276078b71b;hb=HEAD

<rekado_>isn't everything sequenced in monads? Or do you mean this particular syntax for >>=?

<civodul>oh, another monad implementation :-)

<civodul>the problem is with this particular syntax

<rekado_>I see.

<civodul>but otherwise yes, we can sequence calls with mlet, mbegin, or nested binds

<effa>yes, the question is >>= specific

<phant0mas>hey civodul did you see the updated patch? http://lists.gnu.org/archive/html/guix-devel/2015-05/msg00020.html

<civodul>phant0mas: not yet i guess, but i'll get there! :-)

<phant0mas>ok

<civodul>i process messages mostly in FIFO order, sorry for the delay

<phant0mas>no worries, I am working on tar now, waiting for a rebuild to finish :P

<civodul>heh

<civodul>maybe you could have cheated by applying the patch conditionally

<civodul>depends on what it looks like

<rekado_>flexbar-2.5 fails with linker errors (cannot find tbb symbols), but only mipsel. I don't know how to fix this.

<civodul>uh

<civodul>no idea

<civodul>i think we should focus on fixing the x86 issues first

<civodul>texlive upgraded once again, yay!

<civodul>one has to be patient, but it eventually succeeds :-)

<rekado_>hmm, I can't seem to fix gcj. When I pass LDFLAGS=-Wl,-rpath=$out/lib as #:make-flags the LDFLAGS aren't actually set.

<rekado_>Is this something to do with the multiple phases of gcc building?

<paroneayea>hey civodul, I'm confused by https://www.gnu.org/software/guix/manual/html_node/The-Store-Monad.html#The-Store-Monad

<paroneayea>"There are two things to note in the second version: the store parameter is now implicit, and the monadic value returned by package-file—a wrapper around package-derivation and derivation->output-path—is bound using mlet instead of plain let."

<paroneayea>I see no package-file...

<rekado_>paroneayea: there's a package-file in ./guix/packages.scm

<paroneayea>rekadoah

<paroneayea>rekado: ah

<mthl>Hello Guix!

<paroneayea>hello mthl !

<mthl>not really interesting, but there is a show that has cited GNU dmd (actually made fun of it)

<mthl> http://bitlove.org/jupiterbroadcasting/laswebm/linuxactionshowep363-432p.webm.torrent

<mthl>~22min

<paroneayea>oh well, I doubt many understand why dmd is interesting, there's not enough "public" use case yet

<paroneayea>guixsd raising in prominence should help

<mthl>understanding is out of bounds for this kind of show, the view is "Why the hell can't they just accept systemd"

<mthl>without acknowledging the fact that systemd support only linux

<civodul>heh

<civodul>at least they heard of dmd ;-)

<civodul>rekado_: LDFLAGS handling in GCC is very tricky

<civodul>see the gcc-libvtv-runpath.patch that i ended up with

<civodul>paroneayea: you found another issue/anachronism, i'll take care of it

<paroneayea>civodul: thanks :)

*davexunit watches the linux action show thing

*davexunit can't resist morning rage...

<davexunit>lol it was really a non-story

<davexunit>I don't know why they even brought it up without mentioning guix

<davexunit>"I read the home page summary, so now I'm going to assume that they hate systemd and laugh at it."

<rekado_>at what point did people agree on systemd as the only thing you should ever need? I remember that it was not like that when pulseaudio appeared. I wonder if there's a lesson to be learned.

<paroneayea>davexunit: which is why dmd came after systemd amirite??? ;)

<davexunit>civodul traveled back to 2003 to create dmd under a psuedonym, he then left the project dormant so that he could pick it back up in 2013 to make it seem like he wasn't just another systemd hater.

<paroneayea>:)

<mthl>:)

<civodul>dmd is really old

<civodul>it was very innovating back then, when you think about it

<civodul>which reminds me i never got an okay from rms to rename it to sherpherd, *sigh*

<civodul>*shepherd

<davexunit>what was deco going to be renamed to? 'herd'?

<civodul>yes, that was the idea :-)

<civodul>rms proposed "pandemonium", which sounded quite negative to me

<davexunit>yeah

<davexunit>not a good name

<davexunit>too many syllables, too.

<civodul>rekado_: re http://hydra.gnu.org/build/411869/nixlog/1/tail-reload, you'll probably have to take the same route as either 21e583de or the libvtv patch

<rekado_>civodul: I'm recompiling with a similar tweak right now.

<civodul>great, thanks

<paroneayea>oh no, herd?

<paroneayea>that's going to be..

<paroneayea>ambigous when spoken right?

<davexunit>whell the project would be 'shepherd'

<davexunit>'herd' is just the client

<rekado_>is the name still in the race or does "never got an okay from rms" mean that it's out already?

<paroneayea>davexunit: how about "sheep" ;)

<paroneayea>I think that herd and hurd is confusing though.

<civodul>rekado_: i think it's still in the race, rms was not opposing it

<civodul>paroneayea: the rationale was that herding is what a shepherd does :-)

<civodul>the the connection with the Hurd is fun i think

<civodul>s/the/and/

<phant0mas>civodul: one note before I leave for class, the problem I have with tar seem to be solved in commit e9ddc08da0982f36581ae5a8c7763453ff41cfe8 in their repo

<civodul>ah, that's good

<civodul>i don't see any commit in release_1_28..HEAD relating to PATH_MAX tho

<civodul>re dmd, i just found that: http://forum.dlang.org/thread/rowdinidkdmmijwftsdh@forum.dlang.org

<civodul>"daemon hurder", same line of thought ;-)

<rekado_>I *almost* fixed gcj.

<rekado_>oddly, lib/libgcj_bc.so is still broken while lib/libgcj_bc.so.1 is fine.

<civodul>maybe you picked the wrong makefile variable to add LDFLAGS?

<civodul>i sympathize with you anyway, i know how it feels to try a one-liner just to get a failure 2.5 hours later :-)

<rekado_>it works for the other libraries, but not for the libgcj_bc.so dummy library. Will investigate more tomorrow. Annoying.

<civodul>ok

<sirgazil>civodul: the website is in the repo now.

<civodul>oh great, thanks sirgazil!

<civodul>you've been fast

<davexunit>ooooohhhh

<davexunit>sirgazil: teespring says that I should get my GuixSD shirt by May 15th.

<sirgazil>ten more days? I wish shipping was faster...

*civodul missed the deadline :-/

<sirgazil>Maybe for the next-next release we can sell the shirt again and collect some money for hardware?

<sirgazil>Maybe using GNU shop.

<paroneayea>sirgazil: ooh what's this about the site?

<sirgazil>paroneayea: just a provisional HTML site built with python for the 0.8.2 release. I need more time to be able to do it with SXML.

<paroneayea>sirgazil: cool

<paroneayea>SXML, will that version use davexunit's Haunt? ;)

<davexunit> https://gitorious.org/haunt/haunt

<davexunit>if anyone here is interested in building static sites with Guile, take a look. :)

<paroneayea>sirgazil: can't speak really for the FSF but it might be worth talking to them about it. I did talk to John recently about the possibility of Guile doing some fundraiser stuff and using the FSF's infrastructure and I know he was interested in talking about htat

<paroneayea>so anyway, I think the possibility of talking about it is open :)

<sirgazil>Right.

*sirgazil goes check Haunt.

<civodul>sirgazil: Python, really? :-)

<davexunit>he might need some help to get everything fully guile-ified :)

<civodul>yeah, Haunt looks cool!

<civodul>i was telling sirgazil that we could start with just a raw HTML->SXML conversion

<civodul>and then start from there

<davexunit>cool

<civodul>but maybe we should keep the HTML and throw Haunt in?

<civodul>what are your thoughts?

<davexunit>sxml would still be good

<davexunit>most likely

<civodul>SXML becomes interesting (compared to HTML) if we actually factorize things

<davexunit>yes, agreed.

<davexunit>more power there.

<davexunit>I think either way, moving to sxml is a good idea.

<davexunit>haunt might be too much dog fooding

<paroneayea>:)

<davexunit>but it would certainly help haunt cover "real world" use cases.

<paroneayea>iterative dogfooding?

<paroneayea>tail recursive dogfooding?

<davexunit>I'm still lacking a markdown parser so that I can convert my own blog.

<paroneayea>davexunit: I still wonder if shelling out to markdown parser might be a good quick-bootstrapping route

<davexunit>paroneayea: yeah, it would work.

<civodul>davexunit: so should we start by converting to sxml, and start using Haunt whenever you think it's appropriate?

<davexunit>civodul: that sounds like a good approach

<paroneayea>\\o/

*paroneayea cheerleads in the background

<sirgazil>I also want to learn doing it with SXML. But a static site builder that lets people write in their prefered format is still useful.

<davexunit>sirgazil: it's good for writing prose, yeah.

<davexunit>but for building themes and such, SXML all the way.

<davexunit>just for reference, here's what a SXML post looks like in haunt: https://gitorious.org/haunt/haunt/source/example/posts/foo.sxml

<davexunit>and raw html https://gitorious.org/haunt/haunt/source/example/posts/bar.html

<davexunit>the metadata goes before the "---"

<paroneayea>some day guile-emacs will be at the next stage, then maybe orgmode's parser can be refactored into a way that haunt can call out to it ;)

<davexunit>some day...

<paroneayea>then I can run my blog in orgmode + haunt! ;)

<davexunit>batch mode emacs would suffice until then

<davexunit>my problem with that was org-mode insisting on generating a complete html document, when I only want the body stuff.

<davexunit>someone told me a way around that, though... maybe. can't remember.

<paroneayea>I told you a way around it :)

<paroneayea>but maybe I should prototype it.

<davexunit>:)

<sirgazil>davexunit: I get a syntax error when running haunt's ./configure: http://www.pasteall.org/58225/text

<davexunit>sirgazil: you're missing guile's M4 macros

<sirgazil>Ah, ok.

<davexunit>test for /usr/share/aclocal/guile.m4

<davexunit>or wherever you installed guile

<davexunit>sirgazil: thanks for checking out haunt :)

<davexunit> http://www.wired.com/2015/05/google-backs-alternative-docker-cloud-computing-s-next-big-idea/

<davexunit>ugh.

<zacts>docker sucks really bad

<zacts>I'm sorry man, I had to work with it for a while

<zacts>and man it had some really really braindead bugs

<zacts>especially in regards to mounting subvolumes

<zacts>it would do strange random things

<davexunit>it's "the hottest thing" right now, though!

<zacts>and I narrowed the bug down to a specific thing on github

<zacts>yeah, all of the corporate hype

<zacts>it wasted about three days at least of my time

<davexunit>I saw a slideshow that deconstructed what "containers" really are, there needs to be more material like that.

<zacts>also, the docker build envs can build differently depending on what the host env is like

<davexunit>docker is a crappy high-level layer over namespaces, cgroups, and chroots.

<davexunit>zacts: reproducibility not as high on the priority list as that sweet sweet VC money.

<zacts>yeah

<davexunit>and don't get me started about CoreOS...

<davexunit>so misguided.

<davexunit>why do you want to run an OS that is *completely* different from the OS you are deploying on it?

<davexunit>we could just as well make a small Guix image with just enough stuff to be a remote container host.

<zacts>davexunit: I saw this really great article on hackernews about guix build envs

<zacts>I can't remember the link off-hand

<davexunit>guix? really.

<davexunit>?*

<zacts>davexunit: yeah, let me search for it

<zacts>like reproducible package builds

<davexunit>what is it the "Guix in an HPC environment" article?

<zacts>ah yeah, that was it

<davexunit>rekado_ wrote that. :)

<zacts>oh cool

<davexunit>there's also my older post about 'guix environment' http://dthompson.us/reproducible-development-environments-with-gnu-guix.html

<paroneayea>oh hey

<paroneayea>relevant!

<paroneayea> https://github.com/getpelican/pelican-plugins/tree/master/org_reader

<davexunit>paroneayea: yessssssss

<davexunit>I can work with this!

<paroneayea>just in time from jim campbell on pump :)

<davexunit>awesome

<paroneayea>davexunit: you might want to provide the option to do -q

<paroneayea>since otheriwse it will open a person's *whole* .emacs for each file

<paroneayea>emacs opens fast, faster than python, for "emacs -nw -q", but not when you're opening my whole config ;)

<paroneayea>oh nm!

<paroneayea>it uses --batch.

<paroneayea>fast!

<davexunit>nice

<davexunit>the one thing I see that I want to change so far is the metadata gathering

<davexunit>it's hardcoded

<davexunit>should be avoidable

<davexunit>depending on the date parsing thing

<davexunit>here's CoreOS' container specification stuff: https://github.com/appc/spec/blob/master/SPEC.md#image-archives

<davexunit>just like docker, it's a "shove a copy of the whole distro in an image" thing

<davexunit>instead of the nix/guix route of "deduplicate everything via the store, just mount the system closure"

<sirgazil>davexunit: with haunt, where would one define custom templates and put static assets?

<davexunit>sirgazil: theming is pretty much up to you. I wrote a 'blog' procedure that generates a blog, and for that I defined a <theme> data type that could be used. needs documentation!

<davexunit>as for static assets... let me see if I committed the relevant code!

*davexunit tries to eat some of the dog food out of sirgazil's dish

<davexunit>sirgazil: https://gitorious.org/haunt/haunt/source/haunt/asset.scm#L53

<davexunit>I wrote an <asset> type

<davexunit>and perhaps more importantly, a procedure called 'directory-assets' that will read all of the files in a directory as assets.

<davexunit>we should take this to #guile, though.

<davexunit>well, I guess this is about the future of the guix website

<davexunit>so it's relevant

<sirgazil>OK

<sirgazil>And yes, it's for the website :)

<davexunit>(directory-assets "css" "css") would copy everything in the "css" directory of your project to a "css" directory within the output directory, recursively.

<bavier>guix should have colorized terminal output ;)

<davexunit>bavier: first it's colored text, then it's emoji!

<davexunit>give 'em an inch...

<bavier>davexunit: :P

<civodul>:-)

<civodul>bavier: what makes you say so?

<bavier>civodul: I was playing with Spack, and the colors make it quite a bit easier to find messages that are comming from the builder vs the build output

<civodul>ooh

<civodul>hmm

<civodul>'guix build' essentially writes nothing but the build log

<civodul>but maybe for 'guix package' the messages can be confusing?

<bavier>possibly

<bavier>I've not taken inventory of our different messages, so I have no concrete proposal

<bavier>but yeah, I'm not sure that we'd want the build daemon to generate terminal colors

<civodul>certainly not the daemon, indeed

<civodul>actually, i don't really like the idea of generating colors :-)

<civodul>but maybe there's something we could do in the clients

<bavier>civodul: :)

<civodul>or maybe make colors optional

<civodul>so, you're sold to Spack? :-)

<bavier>like gcc's optional colors

<civodul>right

<bavier>civodul: not yet ;)

<civodul>heheh

<bavier>I like some of their developer tools

<bavier>e.g. `spack edit`, and `spack graph`

*civodul looks

<bavier>and their version searching is interesting

<civodul>found it: http://scalability-llnl.github.io/spack/command_index.html

<civodul>version searching?

<bavier> http://scalability-llnl.github.io/spack/packaging_guide.html#finding-new-versions

<bavier>I know we could do something similar

<civodul>ah yes, i had noted it in my todo :-)

<civodul>yes, it's interesting

*civodul is a bit jealous

<bavier>heh

<davexunit>we could totally have that

<bavier>the code is simple enough to read too, wouldn't be difficult to borrow some implementation ideas

<civodul>yeah it seems to be nicely written and designed

<bavier>the difference for us it that we're (usually) interested in the latest package versions, whereas Spack likes to provide access to *all* versions available

<bavier>my todo list for Guix is getting too big ;)

<phant0mas>I think I screwd something up :(

<phant0mas>suddenly lzip fails ./testsuite/check.sh: line 120: cmp: command not found

<phant0mas>thank god there is git :P

<davexunit>bavier: I think all of our todo lists for guix are actually infinite series

<davexunit>which conveniently enough we can represent with some Scheme code...

<bavier>davexunit: haha

<davexunit>paroneayea: reading the newish comments here: https://identi.ca/cwebber/note/9Z4W2XIdSHqyllvFd-qvPw

<davexunit>I'm pretty sure the "nightmare" scenario is possible with guix.

<civodul>nightmare with Guix?

<davexunit>it might a be a pain to implement, but for C applications, it's already possible to mix libraries/applications that depend on the different versions of the same library.

<civodul>but we could statically check some things

<davexunit>civodul: https://microca.st/clacke/comment/cobxTlaVQ_CNDwyBXR0o_Q

<davexunit>we can totally handle the scenario outlined there.

<davexunit>it's just a matter of writing the implementation, but if npm can do it, it's possible and we can do it, too.

<civodul>"It's a difficult problem and at least npm has a way to not solve it and still get your stuff." :-)

<davexunit>A depends on B, and both A and B depend on different versions of C.

<davexunit>well, maybe this wouldn't work so easily.

<civodul>davexunit: that's a language feature

<davexunit>I could see that being an issue in C.

<davexunit>yeah

<civodul>npm has to handle this because JS supports it

<civodul>(which is "nice")

<davexunit>haha

<civodul>but anyway, we can definitely build a DAG with different versions/variants of the same package

<civodul>it's just that usually, things will just crash

<davexunit>but if they don't in JS, then we can accomodate it.

<civodul>except for JS, that i

<civodul>+s

<civodul>yes

<civodul>that means 'guix import npm' must pay attention to the versions of dependencies :-)

<davexunit>;)

<davexunit>it's not really great to be using different versions of the same library, though. yuck.

<civodul>yeah, that's terrible

<civodul>i wonder how it works at all

<davexunit>it's a free for all.

<davexunit>but yeah, the packages are namespaced somehow, and you import the library in a special way in your JS code.

<civodul>i mean object slots are referred to by name, so at least that is not sensitive to object layout

<civodul>(unlike guile structs, for instance)

<davexunit>if we start including node packages in our distro, we would of course strive to minimize the number of versions we must keep around for the same library.

<davexunit>yay more extra work

<davexunit>this is what happens when packaging is a free for all, and no one's doing the curation.

<civodul>heh

<cehteh> https://news.ycombinator.com/item?id=9484757

<cehteh>thats why we all love PHP :D

<civodul>woow, lots of fun on the web ;-)

<cehteh>no matter how good and experienced a programmer is, PHP makes it impossible to write safe and reliable programs

<cehteh>rasmus should apply it to the underhanded C coding contest

<phant0mas>civodul: a question, gnu-build-system uses %final-inputs to build any package, right?

<civodul>phant0mas: right, unless #:implicit-inputs? #f

<phant0mas>so if I want to patch tar, I need to have patch-final and included it in %boot6-inputs.

<phant0mas>Is my line of thought right?

*civodul looks

<civodul>phant0mas: you shouldn't need to do anything special

<civodul>see findutils for instance

<civodul>it has a 'patches' field, but things just work

<civodul>oooh wait

<phant0mas>when findutils builds, patch already exists

<civodul>phant0mas: could you post the patch and backtrace?

<phant0mas>I will wait for this build to finish and I will

<civodul>maybe you need to have patch-final in %boot6-inputs, as you note

<civodul>indeed

IRC channel logs

2015-05-04.log