IRC channel logs

<sriharsha>what does '`' do when placed before parentheses?

<Steap>sriharsha: most importantly, how do you DuckDuckGo "`", "," or "@" ? :p

<sriharsha>I searched for guile tick instead and found this: https://www.google.com/search?q=guile+tick&client=iceweasel-a&rls=org.mozilla:en-US:unofficial&channel=fflb&source=lnms&tbm=isch&sa=X&ei=dMrfUqHmEo2O7QaRvYGgBw&ved=0CAkQ_AUoAQ&biw=959&bih=1034

<sriharsha>those days of gaming...

<civodul>Hello Guix!

<mark_weaver>sriharsha: '`' is quasiquote. it's a lisp/scheme templating mechanism. it's like "'" (normal quote), except that selected parts can be _unquoted_ using comma ','. After the comma comes an expression that is evaluated. For example (let ((foo 42)) `(this is a test of ,(+ foo 1))) => (this is a test of 42)

<mark_weaver>hi civodul!

<mark_weaver>sriharsha: there's also ',@' (unquote-splicing), which expects an expression that evaluates to a list. the list is _spliced_ into the surrounding list.

<sriharsha>mark_weaver, thanks

<mark_weaver>oh, that lattern 42 should have been 43, obviously :)

<mark_weaver>s/lattern/latter/

<sriharsha>:)

*civodul just offloaded a build from his laptop to hydra.gnu.org :-)

<mark_weaver>civodul: when the offloads are done, does the actual build machine attach a signature that can be preserved, such that an end user can trust the build machine without necessarily trusting hydra?

<mark_weaver>The reason I ask is because it would be good to limit the amount of damage a compromised hydra can do.

<mark_weaver>for example, suppose that all modern intel machines are compromised by design, but loongson machines aren't. (not saying this is necessary true, it's just a hypothetical).

<mark_weaver>it would be good if loongson users can trust the loongson build machine without trusting any intel machines.

<mark_weaver>(this is generally good security practice, to minimize the number of machines that can compromise any given signature)

<civodul>mark_weaver: not at this point

<civodul>well, in the typical setup, hydra.gnu.org would offload to other machines

<civodul>and that means hydra.gnu.org trusts these machines

<civodul>so it imports their build results in its store

<civodul>ideally we would keep track of where it comes from

<civodul>but yeah, i understand your concern

<mark_weaver>well, ideally, the signature would be made on the build machine, and propagated to the end user.

<mark_weaver>so that's end-to-end security, rather than merely security along each individual link. the links being buildmachine->hydra and hydra->user.

<mark_weaver>end-to-end security means that I only need to trust the build machine. link security means that I have to trust both hydra and the build machine.

<mark_weaver>I've said all this before, but it was on IRC and probably went down the memory hole. sorry, I should have put it in an email.

<civodul>no no, i do remember discussing it

<civodul>but i'm working incrementally ;-)

<civodul>the problem is that there's currently no place where i could store a list of signatures like this

<mark_weaver>fair enough. thanks for working on it! sorry I haven't been able to help more with guix lately.

<civodul>i agree it would be best to do it the way you suggest though

<civodul>in the meantime, get your loongson ready ;-)

<mark_weaver>heh :)

<mark_weaver>yeah, I think the Loongson 3A may become a build machine.

<sriharsha>mark_weaver, thanks for the commit log hint. Should I send an another patch containing the suggested commit log message?

<mark_weaver>yes, please!

<mark_weaver>thanks!

<mark_weaver>ditto for the sqlite upgrade (I just sent another email about that one)

<mark_weaver>civodul: what's involved in getting the machine ready, btw?

<sriharsha>yes, I just saw that

<mark_weaver>I've forgotten now what's the recommended way of working around the /dev/shm problem on debian machines. (really, we should make the daemon handle it gracefully)

<civodul>mark_weaver: it should have an ssh account for hydra, that will allow it to run "guix archive --import/export/missing" and "guix build" there

<civodul>and its acl should include hydra's public key

<mark_weaver>okay, that's easy.

<mark_weaver>civodul: will it run 'guix pull' ?

<mark_weaver>what mechanism do you envision for making sure the build machines are kept up-to-date?

<mark_weaver>or maybe it doesn't matter, because you build derivations that are sent over the wire?

<civodul>mark_weaver: they don't have to be up-to-date

<civodul>the derivations are sent

<civodul>and then built

<mark_weaver>okay

<mark_weaver>the hardest part here is that I now feel an awesome responsibility to make sure this machine hasn't been compromised.

<civodul>really just taking advantage of Nix's design here

<civodul>ah, well

<civodul>don't feel too much pressure either ;-)

<mark_weaver>I should probably do some kind of fresh install here. I've been running iceweasel on this machine.

<mark_weaver>I have enormously more confidence in the 2F machines, but alas they are quite slow.

<mark_weaver>civodul: oh, one complication with the 3A: its CPUs are hot-swapped automatically, based on load (or something), so even though there are 4 cores, (current-processor-count) often reports less.

<mark_weaver>well, I guess I can just pass --cores=4 to guix-daemon, which is what I've been doing.

<mark_weaver>This /dev/shm thing is a pain.

<mark_weaver>we should really come up with a better solution.

<civodul>mark_weaver: yes, --cores=4 should make it work, somehow

<sriharsha>looking from the code at nix/libstore/build.cc (http://pastebin.com/PnQbN67H) it looks like a new tmpfs is mounted on /dev/shm. It this still problematic?

<mark_weaver>well, that doesn't work is /dev/shm is a symlink, as it is on Debian systems.

<mark_weaver>s/work is/work if/

<sriharsha>but build.cc seems to mount /dev first in the chroot

<sriharsha>and then tests id /dev/shm exits and then mounts tmps on it

<sriharsha>The only failure I see here is that /dev/shm may already exist as a symlink and that should result in the tmpfs mount to fail

<sriharsha>at which point, an exception should be raised.

<sriharsha>Or, am I reading it wrong?

<mark_weaver>I think what actually happens is that the 'mount' call succeeds, but it's not accessible, or something.

<mark_weaver>experiment, however, is clear: there is no exception, and yet anything that needs /dev/shm fails to work.

<mark_weaver>I guess the 'mount' command checks to make sure the mount point is valid, but I guess the syscall doesn't.

<sriharsha>yes, I too observe the same

<sriharsha>mark_weaver, I am suspecting pathExists()

<mark_weaver>civodul: FYI, "make check" fails in core-updates for me. "guix package: error: package `binutils-2.24' lacks output `lib'

<sriharsha>it has an lstat()

<sriharsha>let me do a quick test

<mark_weaver>sriharsha: I wouldn't spend too much time on that though, because really /dev should be synthesized from scratch instead of being borrowed from the host system.

<jmd>I'm packaging gnuplot. It has its own funny licence. How do we specify that?

<mark_weaver>jmd: I'm not sure gnuplot is even free software.

<mark_weaver>despite the name, it has nothing to do with gnu

<jmd>Yes. it does. It is part of theGnu system.

<mark_weaver>its faq says: "Gnuplot is freeware in the sense that you don’t have to pay for it. However it is not freeware in the sense that you would be allowed to distribute a modified version of your gnuplot freely."

<jmd>It does allow modified distributions. It just says that they must be distributed as patches.

<jmd>Lots of GNU software has dependencies on it and has don years.

<mark_weaver>well, okay, I haven't looked closely.

<mark_weaver>but FYI, it's not part of the GNU project, and never has been.

<mark_weaver>I only say this because I assumed it was a GNU project for a long time.

<jmd>Yes. I know that, but it is nevertheless part of the GNU System. Like flex it is not a GNU Project, but it is part of the GNU System.

<jmd>Anyway, how do we deal with unusual licences?

<mark_weaver>I forgot, sorry.

<sriharsha>jmd, something like (license? "weird license" "URL" "comment")

<sriharsha>s/license?/license

<sriharsha>mark_weaver, pathExists() is working as intended..

<jmd>sriharsha: That causes guile parse error

<mark_weaver>license is not exported from licenses.scm

<mark_weaver>I guess (fsf-free "URL")

<mark_weaver>but that's only appropriate if you know that the FSF considers it free. I've asked RMS if it's a free license.

<mark_weaver>(I suspect it is)

<mark_weaver>(but it's not in <http://www.gnu.org/licenses/license-list.html>)

<jmd>I'm sure it's been discussed in the past.

<jmd>And like I say, it will have huge repercussions if its declared non-free.

<sriharsha>jmd, did you try with 'license?'

<mark_weaver>sriharsha: license? is a predicate, so not appropriate. 'license' is not exported from the licenses module, so it wouldn't work.

<sriharsha>ok

<sriharsha>how do these predicates work? I understand it is some kind of a test, but where is the test defined?

<mark_weaver>it's defined as part of the record type definition in licenses.scm.

<mark_weaver>'define-record-type' is a macro that expands into a bunch of definitions.

<sriharsha>hmm, but what does it check there?

<mark_weaver>predicates are just normal procedures. we usually call them predicates if they return a boolean.

<sriharsha>ok.. I was expecting it to compare a given license name to the different licenses declared in the same file

<sriharsha>does it do it implicitly?

<mark_weaver>sriharsha: records are defined in terms of a lower-level concept in Guile called structures. structures have vtables that define their layout. in this case, 'license?' is defined roughly as (define (license? obj) (and (struct? obj) (eq? (struct-vtable obj) <license>)))

<mark_weaver>so first it checks that it's a structure, and then it extracts the vtable from that structure and makes sure it is <license>, which is the vtable for that record type.

<mark_weaver>that's all it does. it doesn't look at the license name or consult any list.

<mark_weaver>but these are low-level details that you should not depend on. they might change in a future version of guile. just explaining for educational purposes :)

<mark_weaver>from a high-level perspective, (license? <obj>) simply tells you whether <obj> is the result of a call to (license ...)

<sriharsha>ok, thanks! so, this is kind of type checking then?

<mark_weaver>exactly

<sriharsha>:)

<sriharsha>thanks

<mark_weaver>sorry, I guess I could have said less :)

<sriharsha>no, you explanation was succinct and had the required in-depth details I like to know.

<mark_weaver>okay :)

<jmd>Is there a way to install a package in an alternate profile directory?

<sriharsha>How can I force rebuild an already built derivation?

<mark_weaver>jmd: yes. guix package --help | grep PROFILE

<jmd>--no-substitutes

<mark_weaver>sriharsha: out of curiosity, why do you want to?

<mark_weaver>is it really exactly the same?

<sriharsha>I hacked on the build.cc code and want to rebuild with the hacked chroot setup

<mark_weaver>sriharsha: you have to delete it from the store, using "guix gc --delete /nix/store/..."

<sriharsha>ok

<mark_weaver>note that it won't let you delete it if it's installed in any profiles (even old ones, so you might have to delete your old profiles), or if any other builds contain references to it.

<mark_weaver>do _not_ delete it manually.

<davexunit>I think I made that mistake once.

<davexunit>had to hack the sqlite db to fix.

<sriharsha>I too did that manually not too long before; I had my fair share there :)

<mark_weaver>I also did it once, and I just blew away everything and bootstrapped from scratch. I had no patience to venture into the sqlite db :)

<mark_weaver>if other things depend on it, as a trick you can make some trivial change to the build recipe.

<civodul>mark_weaver: thanks for the report, a bug indeed

<jmd>Some packages try to install things in the directories of other packages. How can we deal with that?

<civodul>by telling'em not to!

<civodul>:-)

<civodul>often, they have --xxxdir configure flags to specify what we want

<civodul>in that case, it's a matter of adding #:configure-flags

<civodul>otherwise, you can always patch the thing as needed

<jmd>Your first reaction was the same as mine - send the heavies around to their home!

<Sleep_Walker>do I understand the error correctly, that it attempts to download file from internet and fails? --> http://sprunge.us/Gjgj

<Sleep_Walker>(attempt to create guix RPM package)

<mark_weaver>civodul: what report are you talking about?

*mark_weaver doesn't recall filing any bug reports lately :)

<civodul>mark_weaver: the test failure on core-updates :-)

<mark_weaver>oh, right :)

<civodul>Sleep_Walker: yes, you guessed right :-)

<civodul>Sleep_Walker: since Guix starts building "from scratch", it needs a pre-built binary of Guile to begin with

<civodul>see http://www.gnu.org/software/guix/manual/guix.html#Bootstrapping for background

<Sleep_Walker>civodul: can't be used guile from the system?

<civodul>no

<civodul>for many reasons

<civodul>but basically the idea is to maximize build reproducibility

<civodul>and the cost for this is to control what's used when building something

<civodul>s/cost/approach/ :-)

<mark_weaver>Sleep_Walker: is the RPM build done in an environment where networking is disabled? do you think that might be the cause for the failed download?

<Sleep_Walker>mark_weaver: yes, that is the case

<mark_weaver>Sleep_Walker: okay, I guess you'll have to bundle the downloaded guile binary with the RPM source, somehow.

<Sleep_Walker>I can pre-download the file and make it available during build

<Sleep_Walker>but I'm afraid that I'm not able to patch this language

<mark_weaver>unfortunately there's one for each platform.

<Sleep_Walker>I can download them all and simply make them available

<mark_weaver>you don't have to patch anything. just put the file where it belongs: guix/gnu/packages/bootstrap/*/guile-2.0.9.tar.xz

<civodul>exactly

<civodul>that's how Guix is packaged in Guix

<mark_weaver>there's one for each supported platform. currently we support i686, x86_64, and mips64el.

<Sleep_Walker>good :)

<Sleep_Walker>interesting that i686 was chosen on x86_64 platform...