<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
<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>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.
<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>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>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>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.
<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