<lfam>Yes, I've read those, although it's good to review them in times of confusion ;) This seems like an unusual case. But I will proceed to lower the caps.
<marusich>Yeah that's kind of an odd name to begin with. My reading of the manual is that "python-pyrfc3339" would be right, but maybe you should get the opinion of someone who has actually packaged something before :)
<fps>scheme is an interesting language. let's say i'd like to use find-packages-by-name to save me (and others) from manually importing the corresponding module
<lfam>I think it's a minor issue. If there are no strong opinions here I will let the patch review process decide.
<fps>i suppose i could extract somehow in what module the package variable is defined
<fps>but then i'd have to modify the scheme program that is the system config itself
<lfam>How does the python-build-process look for things? Let's Encrypt's tests can't find python2-pythondialog (packaged on my end) even though it is a propagated-input. The environment-variables in the failed build tree have python2-pythondialog in the LIBRARY_PATH but not the PYTHON_PATH. Is that correct?
<davexunit>inspect python2-pythondialog's store item to see if it has the right stuff
<davexunit>not being in PYTHON_PATH seems to indicate that the needed directory was missing
<marusich>I put an "add-to-list" expression like the one suggested into my ~/.emacs file, but emacs complains that the variable geiser-guile-load-path is bad: "Symbol's value as variable is void: geiser-guile-load-path"
<marusich>With or without that procedure invocation (before the add-to-list) in my ~/.emacs, Emacs still complains that "Symbol's value as variable is void: geiser-guile-load-path"
<marusich>I'd like to get my guix checkout onto the geiser-guile-load-path.
<lfam>davexunit: I just finished splitting your wip-lets-encrypt "bunch of stuff" commit into one commit per package definition. Still working on the other dependencies and some circular dependencies in zope (?!).
<rekado>catern: yes, you can send requests to a guix-daemon on the network, but you'd need a little bit of socat glue to expose the daemon's socket to the network, and to make the local guix command connect to that socket when trying to talk to the daemon,
<rekado>It's the kind of setup I will be using on our cluster once IT has okayed an rw export of the profile directory.
<efraim>rekado: have you done a full writeup of how it works all put together?
<mark_weaver>if you are avoiding our binary installation method because you don't want to trust our binaries, you should know that even if you compile everything from source in Guix (which takes a long time), you still must start from our "bootstrap binaries".
<mark_weaver>so there's no way to use guix without trusting some of our binaries
<mark_weaver>at least no documented way. in theory, a set of suitable bootstrap binaries could be produced in another way, but it's not trivial and so far no one has done it.
<mark_weaver>but to answer your question, the library that needs updating is libstdc++, and that probably requires updating your gcc as well
<andreoss>why binaries are shipped in source distribution?
<mark_weaver>there's no way to compile anything without starting from somewhere
<mark_weaver>I agree that it would be nice to document a way to cross-compile bootstrap binaries from an arbitrary system, but it hasn't been done yet and there are many more pressing things to do right now.
<mark_weaver>guix is designed to perform builds in a controlled environment unaffected by the particular machine you're on or the host OS. using the host OS libraries and compiler to start would defeat that goal.
<mark_weaver>all builds done in guix are in a container where only components from guix are visible.
<roelj>Why are the package expressions compiled when running "make" on the git repo?
<roelj>And why is it downloading guile versions that are not for my architecture anyway?
<mark_weaver>roelj: good questions. as for the latter question, I'm sure that could be improved, but downloading only the one for your current architecture wouldn't be right in the case of x86_64, because on that architecture you can also run and build i686 binaries, and so you'd need to download i686 as well.
<rekado>roelj: they are compiled for improved performance.
<mark_weaver>and actually, if you have offloading set up with machines of a different architecture, then it is actually possible to build binaries for any architecture that you have a build slave for.
<mark_weaver>but again, that only works if you have the bootstrap binaries available locally.
<mark_weaver>as for why we compile all the package recipes: when you ask to compile a package, it needs to look not only at that package, but also the entire set of packages that would be needed to build that package, all the way back to the bootstrap binaries. that's a fairly large set of packages. having them all compiled probably makes a significant difference.
<mark_weaver>and commands that have to look up packages by name, e.g. "guix package" or "guix build", need to load *all* of the package modules first, which is quite a bit faster if they're compiled.
<roelj>mark_weaver: I see. Thanks for the clarification. In theory, this wouldn't be needed, would it? It's just an optimization for speed, right?
<paroneayea>wingo: wrote a bit too-long of a reply to your latest blogpost ;)
<mark_weaver>roelj: the 'cairo' is defined in the gtk.scm, and no where else. if you want to use it, you must import the (gnu packages gtk) module. importing (gnu packages cairo) won't work, because there is no such module.
<paroneayea>which is unfortunate because I was *really* excited about the guile/guix room
<roelj>mark_weaver: Thanks. I was a bit confused for a moment that it would also drag in the GTK dependencies, but these are just package definitions. It's not like apt or rpm dependencies..
<mark_weaver>right, importing a module just makes available the exported variables from that module. in this case, 'cairo' is a variable exported by the (gnu packages gtk) module. that variable is bound to a package object.
<roelj>When compiling my package definition (guild compile name-of-package.scm), It tells me "no code for module (guix utils)". I believe I'm missing something obvious..
<mark_weaver>roelj: it's missing the guile load paths needed to find (guix utils). normally when adding packages that might be submitted upstream, the right thing is to put the file directly in the git repo, add it to gnu-system.am, and then run 'make'. Otherwise, I would not bother compiling it. having just that one file interpreted will not make much difference.
<rekado>I have never used guild compile for any of my external package definitions.
<roelj>Where should I put the file so that Guix can find it?
<paroneayea>google released its machine learning software as free software under apache v2
<roelj>What's the policy about adding packages to Guix?
<mark_weaver>that method also allows making arbitrary custom modifications to any part of guix, by working in a private branch of git, and easily incorporating upstream work into your private branch.
<roelj>paroneayea: Is TensorFlow really Python-only?
<mark_weaver>roelj: see the "Packaging Guidelines" and "Contributing" sections of the guix manual.
<paroneayea>roelj: it looks like it has a python api but I'm not sure it's the only language possible
<roelj>mark_weaver: Well, I wrote a package definition for a program no one will probably use in the Guix community. It is a GNU package though. Would it be useful to add it to upstream Guix, or should I just leave it at my personal package definitions?
<roelj>Hm, I removed my package from the /gnu/store directory (rm -f) so I could redownload it and view the hash. Now running guix download <package-link> results in "guix download: error: open-file: Nu such file or directory: "<path-inside-store>".
<roelj>I guess I shouldn't have manually messed with the store..
<rekado>"license:" is a prefix to differentiate between variables that are named the same as licenses.
<rekado>e.g. "expat" exists as a package and as a license name.
<rekado>so we usually import licenses with the "license:" prefix.
<wingo>in guile names are resolved in a scope to determine their meaning. we assume that gpl3+ is bound to a license object that is indeed the gplv3+ :) but you'd have to do more analysis to know that for sure. the source of the binding is usually in (guix licenses) where you can see all the licenses
<roelj>much less involved than creating RPMs or DEBs..
<alezost>marusich: re "add-to-list" error: this happens because `geiser-guile-load-path' doesn't exist on emacs start (as geiser is not loaded yet). A usual emacs way is to wrap such settings in `eval-after-load' or `with-eval-after-load'. So it should be: (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/src/guix"))
<marusich>alezost, thank you. That makes sense, and what you suggest seems to have fixed the issue in the way I wanted.
<alezost>actually I don't modify `geiser-guile-load-path'; instead I set my GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables
<fps>roelj: just to chime into the previous discussion about buiding custom packages: most guix tools also have a -L parameter, so if you have in your home ~/guix-custom with custom packages in it you can do e.g. guix package -L ~/guix-custom -A search_term or guix package -L ~/guix-custom -i your-package-name
<fps>if you don't want to commit to setting an environment variable
<roelj>I have a package defined as '(define-module (gnu packages inklingreader) ...)' and a function defined as '(define-public inklingreader (package ..))'. Now when I invoke 'guix package --list-installed | grep inkling' I get: "guix package: warning: failed to load '(gnu inklingreader)': ERROR: no code for module (gnu inklingreader)"
<efraim>not automatic, but I sometimes grab the description from debian
<fps>i guess you could write a little tool that scans existing repos from other distris and offers you to collect tidbits from here and there and then write an initial package file
<fps>a little care should be taken about attribution
<roelj>Maybe it'be cool to have an "easy" way to generate packages (RPMs, DEBs, PKGs) from the Guix builds. Then when people use Guix to build packages for other distros, they can be automatically added to Guix as well.
<mark_weaver>fps: I haven't been following that project very closely (not for lack of interest, just too busy), but I would suggest learning about gnunet, searching guix-devel for past discussions about the gnunet support, and then when you feel ready to contribute, post something to the ML about it.
<fps>mark_weaver: ye.. i have to get my wifi working first, though ;)
<mark_weaver>yes, of course. I wouldn't be happy either without my wifi :)
<efraim>i haven't used gnome in almost 3 years, too much for my laptop :)
<roelj>I'd love to look into getting gnome-shell to work as well. Though I have some way to go to learn Guix.
<davexunit>but it's really interesting to think that GNU could actually realistically provide computers running tons of GNU stuff: the boot firmware, init system, package manager, desktop environment, etc.
<mark_weaver>packaging gnome for guix is quite challenging. not recommended for starting out.
<davexunit>maybe try packaging Cheese. I want it for testing out my webcam :)
<davexunit>I've never been to one of their meetups because I never have time to go to meetups on weeknights, but I'm hoping it will be useful.
<davexunit>I don't know how many people attend on average or anything.
<davexunit>but they meet at MIT so hopefully it will be fun.
<rekado>efraim: re wifi: that's how I do it when I'm not near a cable.
<roelj>I installed Guix from Git sources, and I didn't install any package. Then I ran 'guix install' with the --no-substitutes option. Does that result in Guix building every dependency package from source?
<alezost>fps: I didn't get it, what string do you mean?
<fps>let's say i put together some variables for assembling different parts of the source name. e.g. archive-adress "http://foo/bar, "archive-base-name "foobar", and archive-uri (string-append archive-address archive-basename ".zip)
<fps>and i'd like to refer to them from withing the trivial builder's #:builder argument
<fps>the (inputs ...) field of the package definition is available as %build-inputs
<alezost>fps: yes, you can wrap package definition in a (let ...)
<fps>alezost: that's what i do. hmm, maybe i messed something else up
<fps>oh, i just noted: there's a missed oppportunity of parallelism: you could download a package's source while the required inputs are still downloading
<fps>once the build inputs and the source have been dl'ed the build can start
<roelj>alezost: Thanks for your solution. I had done git pull; make; sudo make install; already and it seems to work as well.
<alezost>roelj: oh, great; I didn't think you use guix from git directly
<alezost>oh, "make install", not directly then :-)
<roelj>alezost: What's the difference between 'guix pull' and 'git pull'. I remember doing 'guix pull' about a year ago when I last touched Guix.
<alezost>"guix pull" downloads the latest guix source, and compiles its guile code, so when you run "guix ..." commands, you use this new code. If you use 'git pull' and make, then you don't need to run "guix pull"