IRC channel logs

<mark_weaver>but there are some issues. one is where it should live. right now, I carry it with me everywhere, which is the only way I have of ensuring its physical security.

<mark_weaver>I guess we should find a place for it to be permanently hosted.

<mark_weaver>but I don't really trust the physical security of the home where I often reside.

<mark_weaver>not that it's any worse than the average home in that regard; but anyone who can pick some locks could get to it.

<civodul>heh, right

<civodul>do you think the FSF/MIT could host it?

<mark_weaver>no doubt, they could.

<civodul>ok

<mark_weaver>it's all doable; I just need time to find the right people to talk to and get it done.

<civodul>yeah, sure

<mark_weaver>right now I'm trying to focus on getting a couple of things into 2.0.10 before its release. (SRFI-43, SRFI-64, MVars, and the coop-repl-server)

<civodul>no rush

<civodul>surely *this* is more important than setting up the build slave ;-)

<civodul>thanks for your energy on this

<mark_weaver>heh

<mark_weaver>no problem, glad to help! likewise :)

<mark_weaver>btw, what's the recommended strategy for cleaning out /nix/store on the build machines?

<mark_weaver>I don't like the idea of simply running "guix gc" and then downloading the binaries from hydra again.

<mark_weaver>that again means that hydra would be capable of compromising the build boxes.

<civodul>well the basic strategy would be to run "guix gc" periodically

<civodul>but then indeed any missing pieces would be provided by hydra

<mark_weaver>well, "guix gc" removes too much for a box where --no-substitutes is used.

<civodul>technically it wouldn't be using substitutes here

<civodul>it's just the offload hook that would send any missing prerequisites

<civodul>over SSH

<civodul>but the end result is the same, yes

<mark_weaver>oh

<mark_weaver>I think we need to take security more seriously in our design of the build farm.

<mark_weaver>I really do feel an awesome responsibility, when providing prebuilt binaries to potentially large numbers of people.

<mark_weaver>and I think that's appropriate.

<civodul>yes, sure

<civodul>think about the responsibility of a DD ;-)

<mark_weaver>indeed!

<civodul>i think the offload could actually keep signatures around

<civodul>and so it could reuse them when re-exporting something

<mark_weaver>that would be good.

<civodul>so that's an idea to pursue

<civodul>that said, the basic master/slave model is that the slave has to trust the master

<mark_weaver>well, I don't think that's the right model :)

<civodul>hmm, it's the master telling the other machines what to build, right?

<civodul>so...

<mark_weaver>I'm sorry I haven't had more time to spend on this stuff. I suppose it's an area of expertise for me. I'm just overloaded.

<jmd>pwd

<zerwas>/home/jmd

<viric>cat /etc/shadow

<civodul>viric: + sudo

<civodul>viric: you're not going to Brussels, are you?

<viric>:)

<viric>no, I don't plan to

<viric>last year I didn't plan either, but my office decided to send me to paris the next monday of fosdem

<viric>so I finally came

<civodul>oh, ok

<viric>I don't think there is much interesting in fosdem, other than meeting some specific people ;)

<civodul>heh :-)

<civodul>it's like some sort of a pilgrimage too ;-)

<jmd>I tend to agree. It used to be much better.

<jmd>downloading the source of apr fails.

<jmd>404

<viric>mh a too expensive pilgrimage

<viric>:)

<viric>and I won't "petveturi" to it :) I don't have enough time

<zerwas>yeah that's the main reason for me too. Too expensive to get there

<zerwas>Thankfully videos of the talks will be available

<viric>the talks are the worst of fosdem ;)

IRC channel logs

2014-01-27.log