IRC channel logs


back to list of logs

<davexunit>hey #guix
<davexunit>could anyone remind of when the appropriate time to propagate inputs is?
<davexunit>I remember checking the library's pkgconfig .pc file
<davexunit>but I don't remember what I learned from that
<davexunit>giving up for the night.
*davexunit zzz
<civodul>Hello Guix!
<d232323>civodul: Weinholt uses SRFI-78 to test the base64 module. Should we bundle SRFI-78 with Guix, or should I rewrite the tests using SRFI-64?
<civodul>d232323: if converting is fine with you, then let's do it
<civodul>i.e., if that's not too much work
<d232323>IIRC, the tests are trivial.
<d232323>So, yeah, I'll rewrite.
<civodul>cool, thank you!
<d232323>civodul: Why do I need to attach 'tests/store.log'? I thought that 'test-suite.log' includes everything, no?
<civodul>actually tests/stores.log and test-suite.log are from Automake
<civodul>and then stores.log is from SRFI-64
<civodul>so we need stores.log and test-suite.log
<d232323>Okay, I'll attach 'store.log', then.
<phant0mas>civodul: can I put some extra flag for a specific target in cross-gcc?
<civodul>phant0mas: a little, see gcc-configure-flags-for-triplet in gcc.scm
<civodul>which flags do you have in mind?
<phant0mas>I am need "--enable-build-with-cxx" and --disable-nls
<phant0mas>I may*
<phant0mas>btw what the difference between @(if libc and (if libc
<phant0mas>what is the extra @
<civodul>,@ is unquote-splicing in Scheme
<civodul>and , is unquote
<phant0mas>one last thing, the hurd glibc will be a different package from the existing glibc in base.scm ,right?
<phant0mas>a different recipe in base.scm
<civodul>ideally, the only differences would be the 'source' and 'inputs' fields
<civodul>so you would do (define glibc/hurd (package (inherit glibc) (source ...) (inputs ...)))
<civodul>tschwinge: do you think you could upload, say, glibc-hurd-2.19.tar.xz on
<d232323>civodul: Should 'guix/scripts/susbtitute-binary.scm' export anything except 'guix-substitute-binary'? In the diff, I do it for the tests. But I also could use @@, should I?
<civodul>the exports you did were fine, IIRC
<civodul>we also need black-box tests in tests/store.scm though
<civodul>i'm not sure if there were some in the last iteration
<d232323>There definitely were some. In particular, 'parse-signature', 'verify-signature', 'read-narinfo', and 'write-narinfo'.
<civodul>that's in tests/substitute-binary.scm right?
<civodul>that's more "white-box"
<d232323>Nope, I'm still talking about 'guix/scripts/substitute-binary.scm'.
<civodul>ah, sorry
<civodul>well yes, sounds fine :-)
<civodul>i'll be afk for a while
<S2342>civodul: here?
<S2342>civodul: nevermind
<phant0mas>unless we get a tarball for glibc/hurd I have to use git fetch
<phant0mas>how can I tell git fetch to download a specific branch?
<mark_weaver>it couldn't be a branch anyway, it would have to be a tag or commit hash.
<mark_weaver>it has to be deterministic
<civodul>phant0mas: you could use
<civodul>hello mark_weaver :-)
<mark_weaver>hi civodul! how do you find out the correct sha256 hash, btw?
<mark_weaver>is guix download or guix hash usable for git fetches?
<phant0mas>in the example it's using a tag
<phant0mas>what if I want to use a commit hash?
<mark_weaver>I suspect you can just use a commit hash instead of the hash.
<mark_weaver>*instead of the tag.
<phant0mas>(commit (string-append "v" version
<phant0mas>like that?
<mark_weaver>no, just (commit "bdb7a18d78b04ac3ef7a2d905485500f13bb69fb")
<mark_weaver>the string-append thing was to construct the tag name.
<phant0mas>and how do I get the correct sha256 hash for it now?
<mark_weaver>well, pending a better response from civodul: try and and get the real hash from the error message :)
<mark_weaver>try it with a made-up hash, that is.
<mark_weaver>the error message will say what the true hash was.
<mark_weaver>(when you try to build it)
<civodul>mark_weaver: yes, "guix hash -r" on the checkout without .git
<civodul>or from the error message, indeed :-)
<phant0mas>civodul : before you told me the name of the recipe should be define glibc/hurd
<phant0mas>why shouldn't I use define-public?
<davexunit>I don't like define-public. makes it hard to see at a glance what a module's public API is.
<davexunit>I like to put the public variables in the #:export list in the define-module form.
<phant0mas>while the scm file compiles succesfully with my changes, when I try to build the recipe I get the error unkown package
<phant0mas>guile -c says everythin is fine
<davexunit>phant0mas: could you share the file?
<davexunit>perhaps I can spot the issue
<rigelk>hi there :) what is phant0mas trying to do ?
<mark_weaver>he's working on porting guix to the hurd.
<mark_weaver>phant0mas: more information please.
<phant0mas>sorry for the delay ,phone call
<phant0mas>it is just the start of the recipe
<phant0mas>in base.scm
<mark_weaver>you have to give the package a distinct name.
<mark_weaver>(if you want to build it with "guix build" or "guix package")
<mark_weaver>(without the -e option)
<mark_weaver>the name passed to "guix build" or "guix package" looks up the (name "blah") field of the package, not the variable name.
<phant0mas>I got it
<phant0mas>How can I build it with the use of build -e?
<sriharsha>phant0mas, you have to use the -e option like this -e '(@ (gnu packages <filename without .scm>) <package>))'
<phant0mas>thank you
<phant0mas>I should really learn scheme better
<rigelk>what is the purpose of `make sync-synoses` ?
<mark_weaver>well, for GNU packages there's a central place where the synopses are kept, so maintainers can update them in one place instead of having to notify GNU Guix, GNU GSRC, etc.
<mark_weaver>(I don't know the full list of places that currently make use of this central store of GNU package synopses, but it's more than just Guix anyway).
<rigelk>i see. following the following slides ( ), i try to make guix know the package which i've added the definition. but i have the following error(s) : am i missing something ?
<mark_weaver>rigelk: a couple of comments: (1) you shouldn't build things as root, just the guix-daemon and "make install"
<mark_weaver>(2) that paste cannot be a true paste, because you mispelled "sync-synopses"
<mark_weaver>(and I misspelled "misspelled" :)
<mark_weaver>(3) if you want to do development on guix like adding packages, then you should be working from a git checkout.
<mark_weaver>I guess that you modified, which triggered a re-run of automake, and then it doesn't like that your automake is different than the one that was used to create the tarball.
<mark_weaver>in git, it's been renamed to "sync-descriptions", btw.
<mark_weaver>to clarify (1), you should build things as a normal user, and only use root to run guix-daemon and to run "make install".
<rigelk>thanks a lot for the info mark_weaver :) i think i'm gonna make a clean git install from now on. enough playing around.
<mark_weaver>so I recommend doing "git clone git://" and then in the guix directory: ./bootstrap && ./configure ... && make
<mark_weaver>you're welcome! let us know how it goes :)
<rigelk>however, as crazy as it seems, `make sync-synoses` works as `make sync-synopses`. Btw, the former is written in the slides :/
<mark_weaver>oh, interesting :)
<mark_weaver>the string "sync-synoses" does not occur anywhere in the 0.5 tarball.
<mark_weaver>is "make" doing some kind of auto spelling correction?!?
*mark_weaver doesn't understand
<rigelk>mark_weaver: is a `dot` command needed to `make` guix ?
<mark_weaver>it's from graphviz
<mark_weaver>for now, you can just touch the file it's trying to make, or copy it from the tarball.
<mark_weaver>it's just an image of a dependency graph, for the manual.
<mark_weaver>rigelk: ^^
<mark_weaver>(the tarball comes with it pre-built)
<rigelk>mark_weaver: thanks for the tip ; i `touch`ed the file and compiled successfully.