IRC channel logs

<zerwas>I think I messed something up. Doing guix pull results in "guix pull: error: No such file or directory"

<zerwas>ArneBab_: according to the logs you've had this problem, too (in the qemu image). Did you find the reason?

<zerwas>Hm, same for every other command: $ LANG=C guix package -i hello guix package: error: No such file or directory

<Steap_>zerwas: which guix ?

<zerwas>Steap_: 0.5

<Steap_>zerwas: no I mean

<Steap_>$ which guix

<zerwas>that's /usr/local/bin/guix. I used ./configure without any parameters

<Steap_>oh fun, it complains about the subcommand

<zerwas>Sleep_Walker: "yum install guix" on Fedora 20 complained about a missing guile.

<zerwas>Sleep_Walker: after installing guile manually and trying to install guix again, it ends in "Transaction check error: file /usr/share/info/dir from install of guix-0.5-7.1.x86_64 conflicts with file from package info-5.1-4.fc20.x86_64"

<Sleep_Walker>zerwas: right, thanks - there are tiny differences in distributions who this /usr/share/info/dir belongs to

<Sleep_Walker>zerwas: why guile needed to be installed manually?

<mark_weaver>He wrote: <zerwas> Sleep_Walker: "yum install guix" on Fedora 20 complained about a missing guile.

<Sleep_Walker>mark_weaver: I have the history, but I need more exact error message

<ArneBab>zerwas: I did not get it solved, no. I reported it here, though, and it might already be fixed in repository, just not in the release.

<Sleep_Walker>I don't have access to Fedora system to try it on my own

<Sleep_Walker>but it seems I have to prepare one

<mark_weaver>Sleep_Walker: You made a Guix package for Fedora without testing it?

<Sleep_Walker>mark_weaver: yes

<Sleep_Walker>mark_weaver: I made all the packages even without understanding it whole

<Sleep_Walker>mark_weaver: but it is still in my private repository

<mark_weaver>okay

<mark_weaver>well, it sounds like you didn't declare guile as a dependent package, and that /usr/share/info/dir should be removed from the package. I don't know how Fedora normally deals with the dir file.

<Sleep_Walker>there is guile-devel as build time dependency, it seems that result binaries are not linked to guile to autoidentify run time dependency

<Sleep_Walker>and about /usr/share/info/dir - it seems to be issue of Fedora implementation in OBS which is not perfect..

<mark_weaver>guix doesn't use libguile as a library. it runs the guile executable.

<Sleep_Walker>(removing fails the build as it is directory not owned by any package, adding causes issue during installation)

<Sleep_Walker>aha, it's just bytecode

<mark_weaver>what is OBS?

<Sleep_Walker>Open Build Service

<Sleep_Walker>it's something which build openSUSE distribution, but it can build packages for many other distributions as well

<Sleep_Walker>only support is not the best because usualy other distributions use their own build systems and doesn't bother to touch OBS at all :)

<Sleep_Walker>thus there are some slight differences like this causing conflicts on native system

<Sleep_Walker>zerwas: it would help me to see result of `rpm -qf /usr/share/info/dir' from fedora system

<Sleep_Walker>(answer for the question "who owns the directory?")

<mark_weaver>I think it's fairly obvious from what he wrote before that the 'info' package owns /usr/share/info/dir

<mark_weaver>which makes sense anyway.

<Sleep_Walker>hm, probably

<Sleep_Walker>I'll check that from work again

<Sleep_Walker>tuning RPM package for Fedora and openSUSE from Gentoo is not completely sane, mainly before coffee

<mark_weaver>I suspect that the programs that use OBS rarely have texinfo docs :)

<mark_weaver>furthermore, I suspect that in Fedora, when a program installs texinfo docs, some post-install hook is supposed to arrange for the 'dir' file to be updated to point to it.

<mark_weaver>If OBS doesn't have built-in support for that, I'm not sure how it could be done portably across so many distros.

<mark_weaver>also, because of the differences in package names across distros, I wonder how you can declare a dependency on guile-2.0 in such a way that it gets mapped to the appropriate package on each distro.

*mark_weaver --> zzz

<civodul>Hello Guix!

<Sleep_Walker>mark_weaver: each ditribution/version has defined specific RPM macro which allows me to handle distribution/version specific cases separately

<Sleep_Walker>and please do not push me to the position of OBS defender

<Sleep_Walker>I am not, I'm just user

<Sleep_Walker>you can have a look on documentation here http://openbuildservice.org/ (even though it will be terribly outdated and confusing :b )

<civodul>:-)

<civodul>OBS looks rather cool

<Sleep_Walker>I have very mixed feelings about OBS, because my work depends on it

<civodul>oh

<jmd> What does it mean: cycle detected in the references of

<jmd> `/nix/store/191fm840acnpphf1xr175bwkgid4mv7b-package-version-output ?

<sdaasd>civodul: ping

<sdaasd>civodul: I've just read the letter about the binary cache format. Thanks for writing it! It definitely cleared most of the things for me. Still, I don't understand how to sign a binary cache with a private key. What should be used instead of '/path/to/binary-cache' if we map these instructions (https://github.com/NixOS/nix/commit/0fdf4da0e979f992db75cc17376e455ddc5a96d8) to the files created by the "substitute" test in

<sdaasd>'tests/store.scm'?

<civodul>hey sdaasd

<civodul>sdaasd: compared to tests/store.scm, the only difference is that we would add a 'Signature' field in the .narinfo

<civodul>that thing should be a base64 encoded signature

<civodul>the actual format of the signature is not specified

<civodul>in our case, it would be a "canonical sexp" (see pki.scm)

<sdaasd>Wait.

<sdaasd>I understand that the signature should be placed in the .narinfo file. I'm confused by Eelco's instructions which state that I should run 'nix-push' to create a signed binary cache. So, should I specify the directory containing the three files as the argument to '--dest'?

<sdaasd>Or should it be the .narinfo file?

<sdaasd>Or what?

<civodul>forget about nix-push and all that

<sdaasd>So, should I create it manually?

<sdaasd>As explained in the last paragraph?

<civodul>narinfo producers, which include nix-push, Hydra, etc., can provide a 'Signature' field

<civodul>well, for testing purposes, you'll probably create it manually, yes

<civodul>like in tests/store.scm

<sdaasd>Just to clarify, by "it" I meant "the signature."

<sdaasd>Is there a Nix program that can verify that the signature I created is correct?

<civodul>for that we'll use (guix pki)

<civodul>Nix uses OpenSSL, and that's not what we want

<sdaasd>I could start by writing a program that accepts a .narinfo file and returns a signed one? Will it be a good start?

<sdaasd>s/?/./

<civodul>see https://lists.nongnu.org/archive/html/guix-devel/2013-12/msg00135.html

<civodul>hm

*civodul thinks

<civodul>there are mainly two things to do:

<civodul>1. make sure Hydra can use 'guix authenticate' as a drop-in replacement for 'openssl' to create signatures in "our" format

<civodul>2. change substitute-binary.scm to recognize the 'signature' field, and to use 'valid-signature?' on that

<civodul>(2) is where most of the work is

<civodul>for that we need:

<civodul>2.a. a base64 encoder/decoder

<civodul>2.b. the actual support in substitute-binary, with hand-written tests

<civodul>does that make sense?

<sdaasd>Yes, it does. However, I'm a bit puzzled by the differences between Nix and Guix.

<civodul>hm?

<sdaasd>(Let me write it down.)

<sdaasd>I've already asked about 'guix-authenticate', but it won't hurt to do so again. The linked commit says "[...] the base64-encoded signature of the SHA-256 hash of the contents of the NAR info file up to but not including the Signature line." So some program gets an unsigned .narinfo file and produces a signed one. This is clear. Why does 'guix-authenticate' accepts the hash-file and returns an sexp, then? Which file should be passed as

<sdaasd>the hash-file (I forgot again)?

<civodul>'guix authenticate' has the very same command-line interface as 'openssl'

<civodul>not because it's beautiful, but because it has to be compatible with it :-)

<sdaasd>Yes, I remember that.

<civodul>so that the daemon doesn't need to be modified to invoke

<civodul>+it

<civodul>ok

<sdaasd>But what does it expect as the hash-file argument?

<civodul>so basically Hydra produces .narinfo files without 'Signature', passes them to 'openssl' to sign them, and appends the 'Signature' line

<sdaasd>OK.

<civodul>the hash-file argument is a file containing the has

<civodul>+h

<civodul>see openssl(1), or tests/guix-authenticate.sh

<sdaasd>This part is clear: "so basically Hydra produces .narinfo files without 'Signature', passes them to 'openssl' to sign them, and appends the 'Signature' line."

<sdaasd>This is also clear: "The hash-file argument is a file containing the hash."

<civodul>cool :-)

<civodul>what needs clarification now?

*sdaasd is writing

<sdaasd>civodul: What's not clear is how actually Hydra produces the signed .narinfo file. (You mentioned that Hydra currently uses OpenSSL, but may use 'guix authenticate' as well, which is just a wrapper, IIUC.) According to Eelco, the signature should be calculated using the contents of the .narinfo file, not just the file containing the hash (as 'guix-authenticate' does). Did I get it wrong?

<civodul>you'll have to look at the code in Hydra, because i don't know the details

<civodul>but you get the general idea: it produces a narinfo without 'Signature', computes its hash, passes the hash to 'openssl', base64-encodes that, and appends it as the 'Signature' field

<sdaasd>So is this incorrect, "passes them to 'openssl' to sign them, and appends the 'Signature' line"? IIU, OpenSSL can't sign the .narinfo file on its own.

<sdaasd>Ah.

<sdaasd>Now it's clear.

<sdaasd>Whew.

<sdaasd>civodul: Thanks for your patience. I should spend some time digesting the above. Hopefully, I'll be able to start writing code soon.

<civodul>heh, np!

<civodul>i can imagine that getting the big picture is not easy

<civodul>esp. since this is not so well documented ;-)

<jmd>cycle detected in the references of `/nix/store/191fm840acnpphf1xr175bwkgid4mv7b-package-version-output'

<jmd>What does that mean?

<civodul>hey jmd

<civodul>it means that the outputs refer to each other, which they're not allowed to

<civodul>well, cycles are not allowed

<civodul>so you could see if outputs can be arranged differently, or if the cycle can be removed without any loss of functionality

<jmd>Then the cycle involves more than one output. It would be nice if it told me what the other one was!

<civodul>you can "grep -r" in the outputs

<civodul>not so convenient, but hey

<jmd>Unfortunately, I didn't specify -K :(

<civodul>but you probably still have them around

<civodul>in the store

<civodul>they're invalid, but they're still there, normally

<jmd>I'm upto 59% in my /nix dir. I will have to gc soon.

<jmd>What should I be grepping for?

<jmd>Presumably, refering to itself is ok?

<jmd>I think it is lying. I can't find any cyclic references (except) trivial ones.

<civodul>jmd: in output "a", grep -r for the store file name of output "b", etc.

<jmd>That is what I had been trying. didn't find any. I'll try again.

<jmd>It would be really nice if that error message identified the cycle for me!

<civodul>yes it would!

<civodul>:-)

<dafads>civodul: around?

<dafads>civodul: guix authenticate fails for me.

<civodul>tell me

<dafads>ice-9/boot-9.scm:793:17: In procedure call-with-input-file:

<dafads>ice-9/boot-9.scm:793:17: Throw to key `gcry-error' with args `(536871113)'.

<civodul>what does this do: make check TESTS=tests/guix-authenticate.sh

<civodul>likewise, make check TESTS=tests/pk-crypto.scm

<civodul>if any of them fails, please email bug-guix with test-suite.log, the-test.log, and the libgcrypt version

<dafads>Ah, I think I know what's going on.

<dafads>I should reconfigure with a different libgcrypt version.

<dafads>civodul: On a sidenote, what permissions does your '/nix/var/nix/profiles/' have?

<mark_weaver>is there an easy way to duplicate an existing profile to a different directory name, and then make changes to it such that the original profile is not modified?

<civodul>dafads: 755

<mark_weaver>I want to make a new profile that's just a slight variant of my default profile.

<civodul>mark_weaver: no, but i've told myself several times that it'd be useful

<civodul>yeah

<civodul>seems like a common use case

<mark_weaver>civodul: indeed. thanks for the answer anyway :)

<dafads>can't you simply move back and forth using '--roll-back' and similar options?

<mark_weaver>sure, that might be an acceptable hack for now, but I think I can do a bit better.

<dafads>What I'm trying to say is that I don't understand the usecase.

<dafads>IOW, how's that different from the user's perspective?

<civodul>it's less disruptive

<civodul>you can still rely on your default profile while fiddling with a different one

<mark_weaver>I want to run a long-running compile with a different profile (different gcc) without changing the gcc in my default profile.

<mark_weaver>I'm building the free firmware for the FSF-approved USB wireless adapter, which doesn't work with gcc-4.8.2 -- internal copiler error in gcc 4.8.2 while trying to build gcc-4.7.2 :-(

<mark_weaver>actually, something as simple as: "guix package -p foo -i $(guix package -I . | cut -f4)" might work

<mark_weaver>not ideal, but might be good enough for this case.

<mark_weaver>should I pass -p /home/mhw/foo or just -p foo?

<dafads>foo will create a profile in the current directory

<mark_weaver>the manual isn't clear about what the PROFILE argument should be.

<mark_weaver>dafads: thanks

<mark_weaver>civodul: btw, do you have access to the GCC compile farm?

<mark_weaver>I asked for access about a week ago, and got no reply.

<mark_weaver>I need access to an ia64 machine to debug the problem reported by rlb.

<mark_weaver>well, I guess this belongs on #guile

<civodul>mark_weaver: i do

<civodul>yes, i saw that ia64 thing

<civodul>sounds tricky, because it's not even clear that libgc is tested there

<mark_weaver>yeah, that seems like the first thing to check.

<mark_weaver>btw, it seems that this isn't a new problem. poking around packages.debian.org and the qa site, it looks as though guile has never built on ia64.

<mark_weaver>some other platforms are stuck on old versions, like 2.0.5, but there's *no* package for ia64.

<mark_weaver>I notice that we're also broken on x32. the inline asm for math operations in the VM doesn't work there.

<mark_weaver>I need access to more machines.

<mark_weaver>well, I guess I have what I need to set up an x32 environment, but it's a pain.

<mark_weaver>(well, I suppose it would be even better if someone else with access to such machines did the debugging :)

<civodul>yeah

<civodul>x32 is actually "more important" than ia64 IMO

<mark_weaver>agreed

<mark_weaver>I have a pretty good idea how to fix it, but I don't want to blindly commit something without any testing. incidentally, I added more inline asm for multiply and mips/arm since 2.0.9.

<mark_weaver>it made a big difference for multiply, because the portable overflow check for multiply requires a division now.

<mark_weaver>I noticed recently, btw, that gnulib has a module with overflow checks.

<mark_weaver>but it's not as efficient as ours.

<mark_weaver>(intprops)

<mark_weaver>civodul: "guix package -p foo -i $(guix package -I . | cut -f4)" was missing a lot of stuff. I suspect it was missing the propagated inputs. is there a way to get a list of all the /nix/store/* directories that were included in a profile, including the propagated inputs?

<mark_weaver>well, I guess I should just switch back to 4.7.3, and then back to 4.8.2, and then make a link to the old profile with 4.7.3. ugly, but workable.

<civodul>mark_weaver: i noticed the new asm, that's cool!

<civodul>mark_weaver: right, when installing by store file name, you miss important meta-data, such as propagated stuff

<civodul>you can see that from $profile/manifest

<mark_weaver>where is the manifest file?

<mark_weaver>oh, nevermind, got it.

<mark_weaver>thanks!

<civodul>you're welcome :-)

<zerwas>ArneBab: thanks for the feedback

*ggrant thinks he's about ready to start contributing packages again, soon. :^)

IRC channel logs

2014-02-11.log