IRC channel logs


back to list of logs

<reed_>After I run a guix environment command, how would I say run emacs or vim?
<atw>reed_: if you want to do it as a one-liner, you put -- vim. has an example with python.
<atw>Is that what you were asking?
<reed_>atw: That is what I was asking. Thank you!
<atw>☺ glad to be a help
<xelxebar>I'm getting a warning (?) during guix import
<xelxebar>trace: is deprecated, use lib.zipAttrsWith instead
<xelxebar>Well, a couple "traces" like that
<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_>oh, right, nix is the importer!
<Apteryx_>I see. I didn't realize we had a nix importer. Neat.
<db48x>importers a pretty neat idea all around
<db48x>I wrote one for quicklisp
<Apteryx_>cool! I agree that importers are great.
<xelxebar>They're cool if they work
<xelxebar>The nix importer is brokenz for me :(
<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?
<bavier1>xelxebar: that might help
<nothingmuch>i have some questions about the cpan importer:
<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
<xelxebar>Thanks, bavier1
<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>it'll only work if there's a 1:1 correspondnece
<bavier1>nothingmuch: hmm, ok
<nothingmuch>for example the Perl package Template is provided by the guix package perl-template-toolkit
<nothingmuch>or LWP::* is perl-libwww
<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>to distribute packages inside of an organization
<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>it's a deterministic lookup
<nothingmuch>it could use metacpan to do that
<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
<bavier1>nothingmuch: I see.
<bavier1>good to know
<xelxebar>What am I doing wrong? Why is 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
<nothingmuch>and import those as well
<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
<bavier1>nothingmuch: yeah, not ideal
<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>xelxebar: defing munging?
<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
<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
<clacke[m]>SSL_CERT_FILE was not used
<xelxebar>clacke[m]: Thanks. I just discovered
<nothingmuch>xelxebar: well, that makes two of us =)
<clacke[m]>I set SSL_CERT_FILE, SSL_CERT_DIR
<xelxebar>Yay. It worked
<clacke[m]>... CURL_CA_BUNDLE and GIT_SSL_CAINFO
<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>(for general stability/usability)
<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>and you could make the import tool do it on its own
<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
<xelxebar>guix import --install foo, or some such
<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
<nothingmuch>but i think guix import --module might be that
<rekado>the plan is to make all importers produce package objects
<nothingmuch>rekado: what about recursive dependencies?
<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
<nothingmuch>can you explain?
<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>then we backtrack
<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
<nothingmuch>where can i find the recursive importer logic?
<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.
<nothingmuch>i understood it as a guile expression
<nothingmuch>ah, cool
<rekado>it is an actual value
<xelxebar>Oh, okay.
<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
<nothingmuch>(i use spacemacs... don't laugh ;-)
<rekado>I recommend scanning the geiser manual and playing with it a little.
<nothingmuch>cool, looking into it
<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.
<rekado>good luck!
<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>cool, i'll do that
<brendyn>I mean, install the emacs via guix
<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 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
<rekado>the server is not stable
<Apteryx_>26833 is the bug
<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.
<Apteryx_>28810 might be related as well?
<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>(guix package -i shadow )
<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/"?
<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>Hello Guix!
<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>no, with ERROR
<ng0>one moment
<civodul>oh right
<civodul>it's a warning nonetheless ;-)
<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
<ng0>thanks :)
<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
<samplet> path is actually mounted.
<benny>thanks samplet
<samplet>Sorry for the jumble, everyone.
<kristofer>hello guix! happy saturday
<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?
<ng0>oh, this is interesting work by SuSe I think. If this lands there is no reason for the patch I've sent a while ago.
<pmikkelsen>hey guix, long time no see ;)
<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>at present, no
<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 ( 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