*paroneayea eyebrow moves up <davexunit>paroneayea: yes! guix can make vms so why the hell not? <tadni>davexunit: Vms in what regard? Of GNU distro, or self contained? *tadni is a bit disappoined the installer image and assumingly the vm to, you can't seem to specify to use the latest guix pull. <tadni>The GNU Distro usb image I generated the other day, had 0.7 and installed 0.6, like the regular Alpha installer. <jxself>Yes. I understand that's the norm. <jxself>The idea is what, once you install it, you're supposed to go and immediately update it. <tadni>Well, it's supposed to install 0.7 -- 0.6 in the Alpha was a release error. <jxself>My understanding is that there's some nontrivial issues. <tadni>The problem is, that GNU Distro Alpha is borked right now unless you use and install the latest git checkout. <jxself>That might be the best thing to do then. <tadni>Well, assuming you want a graphical session and the latest repos. <davexunit>the problem is that it isn't easy to know the hash of the current version of guix *and* have that hash be shipped with that version of guix <tadni>davexunit: Then have the installer use the latest guix and use the latest snapshot for the distro? :^P <davexunit>tadni: cool screenshot in the lisp general, btw. <isd>Hey all -- I'm trying to fiddle with the pypi importer, and when I run `guix import pypi ...', I get a stack trace which ultimately seems to complaining about a missing module "json," which is imported from pypi.scm but not available <isd>I'm not really sure how to go about troubleshooting this; don't know much about guile's module system yet. Thoughts? <mark_weaver>isd: to use the pypi importer, you need to guile-json. it's mentioned in the "requirements" section of the manual. <isd>mark_weaver: thanks. ***tschwing_ is now known as tschwinge
<jmd>civodul: I encountered another source which only offers https downloads. <civodul>jmd: https i OK, there are many of them in source URLs <civodul>however, we found a couple of servers that require the client to implement a TLS extension <civodul>and that TLS extension is unavailable to us, unless GnuTLS master is used *davexunit was fumbling around with the store monad this morning <civodul>davexunit: so how do you like the monad thing? <davexunit>I understand the basic idea behind lifting and such. <davexunit>and now I'm trying to use the store monad to clean up 'guix environment' <davexunit>I got confused trying to map over a list of packages using package->derivation <civodul>oh that returns a derivation as a monadic value <davexunit>I ended up needing to do something like this: (sequence (mapm %store-monad package->derivation packages)) <davexunit>(mlet %store-monad ((drvs (sequence ...))) ...) <davexunit>not sure if there's a more concise way to do that <civodul>turning lists of monadic values into monadic lists of values is like this <jmd>how did you get it to work_ <jmd>;;; Failed to autoload make-session in (gnutls): <jmd>;;; ERROR: missing interface for module (gnutls) <jmd>ERROR: In procedure module-lookup: Unbound variable: make-session <jmd>(yes, I do have (modules '((gnu packages gnutls))) ) <civodul>jmd: right, in the 'origin' form, make sure to specify the https URL, not the http one <civodul>and no, you don't need (modules ...) <jmd>Ths url merely says: This is a free software license, and compatible with the GPL. <jmd>So why is it an invalid input?? <civodul>jmd: you wrote ("zlib" ,zlib), but the 'zlib' variable here refers to the one from (guix licenses), which is a <license> object <civodul>instead, it should be referring to 'zlib' as exported by (gnu packages compression) <civodul>to achieve that, you can use #:prefix when importing (guix licenses), for instance <jmd>I thought it was telling me there was a license conflict. <jmd>Is it possible to say that a package requires more than one source tarball? <civodul>the extra sources need to be added as inputs <jmd>civodul: Then I need a kindof "dummy" package whose output is the same as the input ? <civodul>no, you can put an 'origin' in the 'inputs' field <civodul>see what texlive.scm does with texlive-texmf-src <bavier>does anyone here have a need for an imake package? <mark_weaver>civodul: maybe we should apply the TLS extension thing to our GnuTLS in the meantime? <civodul>mark_weaver: if it's really blocking, but otherwise we can wait for the next release (it's frequent enough, usually) <civodul>for SANE i found an alternate URL, so that's not really a problem <civodul>the other case was Magit, perhaps that one is problematic <mark_weaver>FYI, magit-1.2.0 doesn't work with the emacs pretest. there's supposedly a 1.2.1 release, but the provided download link doesn't work. in the meantime, I've applied an upstream-provided patch to fix it. *civodul needs to try the Emacs pretest <civodul>i tried a previous one, but many things broke with my setup <civodul>yeah, i just need to adjust some of my .emacs <mark_weaver>but I probably don't use as many packages as you do. <jmd>texlive seems to have a dummy package for texilive-texmf-src which it declares as an input for texlive <civodul>it actually seems more difficult for me to upgrade Emacs than to switch to the standalone Guix :-) <civodul>jmd: exactly, that's what you could do <jmd>Is there any way I can change the directory in the store where a package gets put? <mark_weaver>well, you mustn't be able to override the hash in there. the rest could perhaps be specified in theory, but I wonder: why do you care? <jmd>mark_weaver: Because the dependent package makes some assumptions. <jmd>It insists that the tarball is called "1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz" <mark_weaver>well, you could arrange to put it in /gnu/store/XXXXX/1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz where the XXXXX is chosen by Guix. would that be sufficient? <mark_weaver>or better yet, you could just use 'substitute' to change it in the code that makes that assumption. <jmd>But guix doesn't do that. It puts it in <jmd>/gnu/store/XXXXX-1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz <mark_weaver>Is it a build system of some package you want to add that assumes this? <mark_weaver>I have two suggestions: (1) use 'substitute' to patch the build system to look for it in the right place, or (2) add a phase that copies /gnu/store/XXXXX-1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz to the file name you want somewhere in the build directory. <mark_weaver>if you really need it, you could make a new package that just copies /gnu/store/XXXXX-1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz to /gnu/store/XXXXX/1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz <jmd>I might have to do 2. <jmd>I't opens up a real can of worms. <jmd>I'd hoped I could use trivial-build-system or something just to copy it to the output <mark_weaver>jmd: The 'paredit' package in gnu/packages/emacs.scm is an example of a trivial-build-system package that does something similar. just remove the (guix build emacs-utils) module imports, change the destination of the copy, and remove the byte-compile-file thing at the end. <jmd>Yep. I'm looking at that now. <mark_weaver>btw, keep in mind that you'll still have to keep the 'mkdir-p', even if it's just %output (which is "/gnu/store/XXXX"). though in that case you could use 'mkdir' instead of 'mkdir-p'. <jmd>and copy-file will no longer be appropriate. <mark_weaver>I suppose you could make a link instead, though I'd like to hear from civodul about that. <jmd>Well copy-file will be ok. But the dest will be different <jmd>The link is an interesting idea. <mark_weaver>I guess a link would be fine. we do that for profiles, after all. <jmd>Should it be a soft or hard link? <davexunit>I feel bad about how many people have experienced a broken 'guix pull' because of the guile-json thing. :( <bavier>davexunit: makes me think about the time I broke half the hydra builds when I added the openmpi package. <jmd>fefe````: Imake has been unmaintained for several years now. <jmd>There seems to be an issue with icu4c <jmd> ldd $(./pre-inst-env guix build icu4c)/bin/genbrk <jmd>shows missing libraries <jmd>I wonder if anyone has a script to find the minimum set of inputs for a package? <civodul>i usually start from the empty list and add inputs until the thing is satisfied <civodul>when would you need to compute the minimum set of inputs? <jmd>Well I do too. But for complicated cases I often end up with inputs which I later realise were not required. <civodul>i tend to check at the end what "guix gc --references" report <civodul>and if some libraries that i added as inputs are missing there, then they can usually be removed