IRC channel logs


back to list of 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>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 (even though it will be terribly outdated and confusing :b )
<civodul>OBS looks rather cool
<Sleep_Walker>I have very mixed feelings about OBS, because my work depends on it
<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 ( to the files created by the "substitute" test in
<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>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?
*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.
<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
<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
<civodul>the hash-file argument is a file containing the has
<civodul>see openssl(1), or tests/
<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>Now it's clear.
<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!
<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/
<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>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 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>x32 is actually "more important" than ia64 IMO
<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>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.
<civodul>you're welcome :-)
<zerwas>ArneBab: thanks for the feedback
*ggrant thinks he's about ready to start contributing packages again, soon. :^)