<reed_>After I run a guix environment command, how would I say run emacs or vim? <atw>Is that what you were asking? <reed_>atw: That is what I was asking. Thank you! <xelxebar>I'm getting a warning (?) during guix import <xelxebar>trace: lib.zip is deprecated, use lib.zipAttrsWith instead <xelxebar>Should I do something about these as a user? I'm not sure how to get more information on what this means. <xelxebar>Oh. I can't seem to get nix packages to import. The 'guix import nix ...' just ends up crashing with a stack overflow <Apteryx_>xelxebar: are you trying to package nix on guix? <clacke[m]>Apteryx_: They're just trying to install some software that is available in Nix but not yet in Guix. <Apteryx_>OK. I guess it's not free? Otherwise why not package it for Guix. Seems more straightforward to me. <db48x>Apteryx_: the guix import command generates a guix package definition using data from a foreign package system <Apteryx_>I see. I didn't realize we had a nix importer. Neat. <db48x>importers a pretty neat idea all around <bavier1>the nix importer fails ungracefully sometimes if the foreign package's metadata is malformed <xelxebar>Fails ungracefully? As in falls into an infinite recursion and overflows the stack kind of ungraceful? <xelxebar>I feel like I'm doing something wrong. Every nix import I've tried has died like that :'( <bavier1>oh wait, no, I'm thinking of the haskell importer, sorry <bavier1>haven't had a need to try the nix importer <xelxebar>You just inspired me to try the hackage and stackage importers <xelxebar>Dang. They just failed on x.509 certificate errors with the websites... <xelxebar>Do I need to install ca certs or something? <nothingmuch>1. currently it matches distnames in the mapping to the guix namespace, but many dependencies are specified via package name in Perl <nothingmuch>is there a way to make guix import cpan Foo::Bar resolve Foo::Bar according to the index to whateever dist supplies it? <nothingmuch>2. what's the reccomended approach for importing dependency trees? <bavier1>nothingmuch: 2) currently have to manually import each one <xelxebar>Noooo.... I can't even install nss-certs. The substitute is failing to download <bavier1>1) do you have an example of a package where the importer doesn't work as expected? <bavier1>xelxebar: there's always '--fallback' ? <xelxebar>Oh. Right. I should have read the rest of the error message before spamming the chat :P <bavier1>nothingmuch: for 1, I think the importer uses metacpan to resolve which dist a package comes from <nothingmuch>yeah i'm pretty sure it does but the command line doesn't <nothingmuch>(because the importer resolves 1 layer of dependencies) <bavier1>nothingmuch: you mean, 'guix import cpan Foo::Bar' will not look up the dist name? <nothingmuch>for example the Perl package Template is provided by the guix package perl-template-toolkit <nothingmuch>but if you ask for guix import cpan Template or LWP::UserAgent for example, it can't' resolve it <nothingmuch>the CPAN index is a pretty simple data structure, for what it's worth... importing it directly to guix could prove useful for the so called DarkPAN (custom CPAN sites) <bavier1>nothingmuch: haven't heard of DarkPAN <nothingmuch>it's only a 1:1 correspondence by convention, in reality every dist has many packages (= perl level namespace), and a dist gets indexed if the uploader has permissions to those namespaces, overwriting previous dists' claims to those particular packages <nothingmuch>it's just that it's pretty easy to set up a custom CPAN site, as a mirror <nothingmuch>sorry, to distribute "dists" i should say, just so I we don't add a 3rd meaning of "package" <nothingmuch>also I'm not clear, the first "it's" is about CPAN's namespace indexing, the second "it's" refers to what is darkpan <bavier1>nothingmuch: the importer could maybe suggest a dist name if it doesn't match what's on the command line? <nothingmuch>i'm pretty sure that's what the importer does for the dependencies <bavier1>sure, but it might surprise the user <bavier1>e.g. user doesn't know what dist a module is in, asks to import it, and the importer spits out something with a different name; could be surprising <nothingmuch>02packages.details.txt.gz authoritatively maps namespaces to distribution version names in any CPAN mirror <nothingmuch>so IMHO (very humble, since I'm a total n00b to guix) I think that is a more robust way of resolving those lookups <nothingmuch>because it only relies on a CPAN mirror, not metacpan as a service <xelxebar>What am I doing wrong? Why is stackage.org giving me an X.509 verification error when trying to import? <nothingmuch>bavier1: if I were inclined to do recursive reimporting, what's a good practice? I've been cobbling together a custom namespace and adding to GUIX_PACKAGE_PATH, spitting out one package (if not already in guix) per Perl dependency <bavier1>nothingmuch: what do you mean by "reimporting"? <nothingmuch>like, for every package definition guix import cpan spits out, go through all of its dependencies <bavier1>currently it needs to be done manually. we have some ideas in the works to support recursive importing in all the importers. <nothingmuch>those are already in the guix naming format, but definitions for them haven't been printed, mapping those backwards is a bit sketchy (like, i imported something that depends on perl-hash-merge-simple -> Hash::Merge::Simple to reinvoke guix import cpan Hash::merge::Simple) <xelxebar>i.e. build a depenedency dag and install the entire trie <nothingmuch>is there an easy way in guile to enumerate the free variables in an s-exp? <xelxebar>nothingmuch: Have you tried munging aronud on guix/import/cpan.scm? <nothingmuch>i've poked around it, but haven't tried changing anything, i don't quite understand how it works yet <bavier1>nothingmuch: I can't tell you how to spend your hacking time, but looking at the current state of the recursive importers discussion might be more fruitful <nothingmuch>afaict only the cran importer has a --recursive switch, but I'm pretty sure nix and hackage would handle that too, right? <bavier1>yeah, several could handle it no problem <bavier1>it'd just be nice to not recreate the logic in each importer <xelxebar>The nix importer just calls a nix cli tool on the backend. It looks like cpan.scm is directly fetching the json package data from metacpan.org <xelxebar>I *think* that the nix importer automatically handles recursive dependencies because of this. I'm guessing you'd have to recursively call json-fetch on the dependencies in cpan.scm to get what you want... <xelxebar>I don't actually know what I'm talking about here, though. I'm just glancing at cpan.scm and saying what comes to mind <clacke[m]>xelxebar: I got X.509 verification etrors when doing guix import pypi, until I set SSL_CERT_DIR <xelxebar>Now I just need to figure out what to do with the package definition. :P <db48x>xelxebar: stick it in an scm file inside a convenient directory, put suitable define-module at the top, then guix package -L your-directory -i your-package will work ***Guest74 is now known as Dudley
***Dudley is now known as DudleyI
<xelxebar>db48x: Thanks. I'm mucking around with that now. It's sort of a rabbit hole to gather together all the dependencies <DudleyI>I'm planning on install GuixSD on a Dell T3600. Any thoughts? ***nothingm1ch is now known as nothingmuch
<nothingmuch>is it generally reccomended to use guix pull or to stick with the released snapshot? <nothingmuch>bavier1: so looking at the cpan stuff, I think changing guix/scripts/import/cpan.scm to use module->dist instead of cpan->guix-package would make the behaviour more consistent, but potentially break backwards compatibility <nothingmuch>as for dependency management, I think that a sensible solution would be a script that takes package definitions, maps guix packages back to cpan dists, and imports those <nothingmuch>maybe the import command should have --dist or --module, defaulting to --dist for compatibility? <nothingmuch>anyway, i'll try to learn how to evaluate scheme code and enumerate all undefined variables, which should be the missing dependencies, and simply iterating on appending these defintions to a .scm file should be a simple way to do dependencies <xelxebar>nothingmuch: How do you envision the output of some modified importer that resoles recursive deps? <xelxebar>At the moment we 'guix import foo bar' outputs a single (incomplete) package definition template it seems <nothingmuch>xelxebar: it's missing the define-module boilerplate at the moment, I'm not sure what's the best way to deal with that <nothingmuch>but then given a .scm file of previous outputs, you could iterate on import <nothingmuch>import adds a package, and may have undeifned symbols, which can be defined given their name <nothingmuch>iterating on defining those with the same import tool resolves the dependencies <nothingmuch>i'm still new to guix so i don't know about the usability stuff, but on a technical level this seems to me like the simplest way to approach it for the cpan importer based on what i've read/understood <nothingmuch>as orthe define-module stuff, this needs to search for the guix-modules in question and resolve them to where they are defined, in particular the perl stuff is kind of spread out (gnu packages {perl,web,networking,database,...}) <nothingmuch>do all the import commands consistently spew out bare definitions? is there some standard way to make a module out of them? <xelxebar>I haven't thought through it as much as you have, but the core idea of iterating over undefined symbols seems like a good, naive first approach. <xelxebar>nothingmuch: I'm not all that familiar with the import conventions, but as far as I've seen, currently you just get a (package ...) boilerplate for the single requested package. <xelxebar>What you're wanting to do sounds to me more like another guix command built on top of import or something <nothingmuch>well, i want to generate a .scm file with a module for a bunch of packages <rekado>The json importer already produces an actual package object <rekado>the plan is to make all importers produce package objects <rekado>package values can already be converted to package expressions (and, with very little work, a module header) <rekado>nothingmuch: we already have a recursive importer. <rekado>the thing with package objects is that we have to build the objects for dependencies first <rekado>so we fetch the info from upstream, identify the packages that are unavailable and recurse until we hit a package that already exists. <nothingmuch>also the only reference I found for "guix import recursive" is the cran importer <rekado>correct, the cran importer is the only recursive importer at this point <rekado>but it would have to be rewritten anyway\\ <rekado>currently it produces a stream of s-expressions <rekado>that’s not what we want, ultimately <rekado>in the definition of the cran importer <rekado>but it wouldn’t be useful for an importer that produces package objects <xelxebar>Is "package object" here eqivalent to a nix derivation? <rekado>no, it’s a scheme value produced by the (package …) form. <rekado>to print its text representation to the terminal is not really all that important <nothingmuch>rekado: so, if I understand correctly there are plans to refactor the cran recursive import logic into a general purpose thing? and to change the UI? <rekado>commit fb1db385476bc4548d3eadea93b5dd6a346839f2 accidentally already introduced a way to directly build a package from a JSON package definition. <rekado>it would create a package object via the importer and then build the result. <rekado>nothingmuch: “plans” is a bit much. I want to do this at some point, though. <nothingmuch>so, I have a strong Perl background, and I want to use guix to do some devopsy stuff and I suspect I'll have to learn how to do packages as well as services <nothingmuch>good support for Perl will help me with a consulting project, so I have an incentive to get this working <rekado>what is “this” in “get this working”? <nothingmuch>if you provide me with some guidance I'd be happy to help move this along, but be aware I have 0 experience with guix or guile, and though I'm a lambda head, very little of that was in scheme <nothingmuch>being able to handle recursive dependencies for Perl projects <nothingmuch>carton is the de facto standard for vendoring in Perl <rekado>for the time being you could probably just copy the mechanism we use for the cran importer. <nothingmuch>getting a guix env out of a cpanfile.snapshot would be ideal <nothingmuch>ok, i'm going through the HACKING doc at the moment, setting up a local check out of guix and working towards building it <rekado>the single instance importer “description->package” produces two values: the package expression and a list of names. <rekado>“recursive-import” then runs “cran->guix-package” (which calls “description->package”) and receives these two values. <rekado>and then it returns a lazy stream of package expressions (see “stream-unfold”) <brendyn>Can anyone help me write some C++ for a patch. It's pretty simple code but I've never written and C/C++ before so I can't figure it out <rekado>“stream-unfold” has a few components: “map”, “predicate”, “generator”, and “initial state”. <rekado>there you see that it calls “cran->guix-package” again to produce additional values for the stream, when the stream is forced. <rekado>“cran->guix-package” is memoized, so it’s fine to call it more than once for the same inputs. This simplifies the implementation as we don’t need to keep track of packages that we’ve already imported. <nothingmuch>thanks, this is very helpful, I'll give it a shot later today or tomorrow morning <nothingmuch>is there an easy way to use the definitions directly in a file without declaring a module? <rekado>This all is used in (guix scripts import cran), where we force the stream with “stream->list” when recursive imports are requested. <rekado>nothingmuch: I did all of my testing in a REPL. <nothingmuch>hmm... i suppose it'd be wise to learn how to use one <rekado>I use Emacs with Geiser to send expressions from an Emacs buffer to the REPL <nothingmuch>i'm a vim survivor, i turned to emacs, but it's embarassing how much emacs I know <rekado>I recommend scanning the geiser manual and playing with it a little. <rekado>feel free to ask here any time you feel you get stuck <rekado>I know it’s hard to get started with these things. <brendyn>I use spacemacs too. You should install the emacs and emacs-guix. works with spacemacs but the emacs in guix comes with some guix.el <nothingmuch>for now I've been using guix in debian, and still using the debian emacs <nothingmuch>I should also learn how to use emacs on its own though, i'm pretty helpless without spacemacs and evil mode <nothingmuch>i'm missing out on a lot of goodness because of that modal editing brain damage ;-) <cbaines>bayfront currently appears to be broken in some way, and this is meaning that Guix kinda gives up with most operations <cbaines>substitute: guix substitute: error: TLS error in procedure 'handshake': The TLS connection was non-properly terminated. <cbaines>guix package: error: corrupt input while restoring archive from socket <cbaines>just removing bayfront from the substitute urls avoids this error <rekado>cbaines: have you tried using berlin.guixsd.org instead? <rekado>I don’t think bayfront is operational right now. <cbaines>yep, if I don't use substitutes from bayfront then things work <Apteryx_>cbaines: I believe we have a bug for that <cbaines>I'm using it by default though, so I keep having to specifying --substitute-urls <rekado>I’d recommend not to use bayfront by default <Apteryx_>I somehow screwed up when writing about it using "guix substitute" instead of "guix package". If you have a repro available, it might be a nice addition to post it to this bug. <benny>this documentation speaks of setting a root password with "passwd" but that's not available on 0.13 <benny>(when booted from the usb image) <OriansJ>one needs to install shadow to get tools like passwd <OriansJ>but that should be part of the guix image otherwise there is a defect in the 0.13 image definition. <benny>after I did guix package -i shadow I could run passwd, but not before <ryanwatkins>How can one circumvent guix system: error: symlink: Permission denied: "/var/guix/profiles/system-36-link.new"? <ryanwatkins>should I: sudo guix system reconfigure /etc/config.scm? <rekado>ryanwatkins: any modification to the system requires root access. <rekado>ryanwatkins: note that the root user may have a different version of Guix <rekado>ryanwatkins: so you should either run “guix pull” as root, or use “sudo -E guix system reconfigure …”. <civodul>rekado: damn it, that weak hash table thing will never end? ***sonnixin_ is now known as me
***me is now known as Guest50152
<ng0>let's say I have this as an error message: Can't create config directory (/homeless-shelter/.w3m) … how do I deal with it in the guix build env? mkdir-p /homeless-shelter/.w3m before the phase where this is run? <ng0>the question is not how do I deal with it, but how should I deal with it? <ng0>or if I simply continue to skip it as I have done before… it is just the make check in 'doc' of neomutt … choices are w3m, lynx, elinks and w3m is the smallest of them <ng0>imo we only gain a dependency and nothing else. <OriansJ>ng0: it is far easier to gain dependency than it is to reduce them <ng0>I mean, it does nothing to our package, the doc check is unnecessary <ng0>there are some more obvious notices that I will fix upstream <ng0>*obviously more important notes <civodul>ng0: (setenv "HOME" (getcwd)) should do it <civodul>it means the program wants $HOME to be writable <ng0>oh, that's it. okay. I make a note somewhere for myself. Thanks for the explanation <ng0>I've sent an update for neomutt, that's my work for today :) <ng0>I'm getting messages about (charting)… did something change where I have to run a make clean for guix, or can I ignore this? <civodul>most likely you've always had those messages :-) <civodul>i suspect they start with "warning", which means it's not an error ;-) <ng0>but I think I always had those <ruuda>Hi, I am trying the GuixSD qemu image ... what are the login credentials? I cannot seem to find them in the docs <ruuda>Ah never mind, just "root" without password <ruuda>But since I am here anyway, I would like to say that so far I am impressed by the extensive amount of documentation <benny>before I try to troubleshoot further, is it possible to install guixsd on efi or do I need to set up BIOS + grub boot partition <samplet>benny: According to the 0.13.0 release announcement, EFI should work. It looks like the documentation on the website is out-of-date, since it doesn‘t mention it. (On my machine, it is in the “Proceeding with the Installation” section.) <samplet>benny: If you switch to TTY 2 on the installation system, there should be documentation. Hopefully it is up-to-date. <samplet>From the manual: Make sure the ‘grub-configuration’ form refers to the target you <samplet> want to install GRUB on. It should mention ‘grub-bootloader’ if <samplet> you are installing GRUB in the legacy way, or ‘grub-efi-bootloader’ <samplet> for newer UEFI systems. For legacy systems, the ‘target’ field <samplet> names a device, like ‘/dev/sda’; for UEFI systems it names a path <samplet> to a mounted EFI partition, like ‘/boot/efi’, and do make sure the <kristofer>I did a binary installation on a vps earlier today.. now I'm trying to guix system init and I have an error "guix: system: command not found" <kristofer>I ran a guix pull before trying to initialize the system on a seperate disk <kristofer>apparently I need guile-git.. "guix package: error: expat-CVE-2016-0718-fix-regression.patch: patch not found" <ruuda>Hi, I ran `guix pull --fallback` and it went OOM. Now every `guix package` command I run fails with "guix package: error: expat-CVE-2016-0718-fix-regression.patch: patch not found". In particular, `guix package --roll-back` fails. Is there anything I can do to recover? <benny>is there a way find out given the name of an executable to find the package name? <mwette>I ran guix "make check" on my Centos 7 system. It failed 120 of 697 tests. Is that nominal? <emyles`>benny: look in the store for the executable, e.g. for bash: ls /gnu/store/*/bin/bash and the bit between the hash and the version is the package name <benny>oh sorry, emyles`, I meant when I don't have the package installed yet <ng0>well installed doesn't mean installed <ng0>you can have it in the store without being installed in your user profile <samplet>benny: Using “guix package -s NAME” might help. It searches the package definitions, including descriptions and such. <ng0>I guess it would be easy to write something that indexes the files in every build and puts them out to an (online/offline) listing that can be searched and queried, but so far no one has done it (portagefiles.de and the tool to query it is a very simple, not portable solution. At some point I started to port it to Guix, but I stopped at full portage to Guix) <benny>samplet: in this case I got lucky already as I was looking for mkfs.vfat and it was the only result when searching for "mkfs", "vfat" returned the fscksers