***cal is now known as Guest70360
<Guest70360>Weird. Guix keeps stalling at "creating manual page database for 32 packages..." <Guest89871>I need some help with installing GUIX if anyone is willing to help me <DoublePlusGood23> /gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8) <reepca-laptop>I'm also having some locale troubles - I set GUIX_LOCPATH as per 2.6.1 of the manual, but still get that warning. I think I read somewhere that it also has to be set for the daemon? Not sure about that. <DoublePlusGood23>Guest89871: oh. You should just post your problem in irc even if nobody directly msgs you. Help google and the lurkers will pick it up. <DoublePlusGood23>I have that set, all glibc-locales, en_US.utf-8 exists, binaries (including bash) are using glbc 2.25 - matching my locales, I'm exporting all the various env vars....not sure what I'm missing <Guest89871>Yeah, it just flashes a black screen then shows me the bios again <Guest89871>I just went into gparted and it shows that the image is on it <DoublePlusGood23>Guest89871: It could be lack of libre drivers, though I'd expect that to at least load the kernel... have you booted a linux-libre system before? <Guest89871>I've only ever used Fedora, Kali, Ubuntu and Arch <DoublePlusGood23>Guest89871: Also, how did you dd the image? like `dd if=guix of=/dev/sdx bs=1M` or `dd if=guix of=/dev/sdx1 bs=1M` <reepca-laptop>DoublePlusGood23: My line in guix-daemon.service is Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale (note lib instead of share) and I now don't get that warning after restarting the daemon, have you tried that? <Guest89871>Just went into the bios again and it's not even showing up <Guest70360>Hey, why do 'w' and 'who' show no info about users? ***Guest70360 is now known as CharlieBrown
<lunacat3>returning to using guix after many months hiatus, and what strikes me most, is how unintuitive it is, and how inaccessable the documentation is. does not bode well for liberating the masses. <lunacat3>not even sure i'm doing things right, even after much time rummaging through various guix --helps. guix refresh, is that the right thing to do to refresh the list of available packages? it's doing something weird n slow. <lunacat3>nope. docs suggest not. "the primary audience of guix refresh is developers". <reepca-laptop>CharlieBrown: "all files" here meaning "all files in the store"? <CharlieBrown>reepca-laptop: No. I mean, I just gave someone an account on my computer, and when they logged in, they could explore my home directory in the file manager. <lunacat3>tbh, i havnt checked that on multi-user systems <reepca-laptop>On Lubuntu at least (so I'd assume for the other *buntus) a user I just created using "adduser" was able to access my home directory. <lunacat3>ACTION doing guix package -i mplayer --fallback, hoping that sorts things so he stops seeing message about failed whatevers from likely net issues ~ just scrolled outta sight <brendyn>CharlieBrown: Sounds like a serious issue. <brendyn>Many programs run as separate users to achieve a degree of security, this ruins part of that it seems <lunacat3>so anyways, it can be sorted so it's not so. so is it just a matter of directory ownership? <lunacat3>n ... like CharlieBrown says... whys it not like that by default, across users' homes. <CharlieBrown>I don't want to remember to do that when I deploy my config elsewhere. <lunacat3>it does rather seem like a smarter default. <reepca-laptop>I don't see a way to specify that in the "user accounts" section of the manual <reepca-laptop>if you wanted to immediately fix it you'd actually also have to do chmod a-x /home/myuser, just a-r wouldn't be enough <brendyn>Oh crap, now I can't read my own dome directory <brendyn>reepca-laptop: a-x removes permissions for everyone <reepca-laptop>Huh. I think I misunderstood something about how chmod works... I thought it would just clear a single bit. <brendyn>CHMOD(1): the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). <brendyn>Sounds like that would cause problems with group permissions? <brendyn>Like, I'm in a fuse group, maybe it would prevent me from mounting fuse drives? <brendyn>We're all fools I guess, we'll see what damage we cause to our machines in time! ***cal is now known as Guest78739
***Guest78739 is now known as CharlieBrown
<reepca-laptop>I think bind, currently installing with fallback and I'll check once it's done. I wonder if there are better ways to check that. ***Lijero_ is now known as Lijero
<Lijero>reepca-laptop: Thanks! I figured it'd be in bind, but it didn't make sense to download all of bind for just the utils. Today I learned that I can do just the utils! <reepca-laptop>Actually if "guix size bind:utils" and "guix size bind:out" is any indicator, bind:utils is actually a superset of bind:out, strangely enough. <reepca-laptop>How can I make emacs aware of the guile documentation from guix? <marusich>Do you mean, Guile's Reference manual (in Texinfo format)? <marusich>If so, you probably need to ensure that ~/.guix-profile/share/info is on the INFOPATH. <marusich>OK, you probably will need to have something like this in your .bashrc file or equivalent: <marusich>export INFOPATH="$HOME/.guix-profile/share/info${INFOPATH:+:}$INFOPATH" <marusich>That will ensure that the texinfo-format manuals in $HOME/.guix-profile/share/info - which is where Guix puts them - are readable using the info reader and also via emacs. <marusich>Note that you'll need to source the .bashrc file, or just log out and log back in, or just reboot, before applications like emacs will see the new value for the environment variable. <marusich>Probably not, since unless you've updated the environment variable to include the new directory ($HOME/.guix-profile/share/info), emacs still won't find the docs. <marusich>You could start it e.g. like this: env INFOPATH="$HOME/.guix-profile/share/info${INFOPATH:+:}$INFOPATH" emacs <marusich>that would work. But ultimately you probably want to know whether or not it works when you boot your computer up the next time, and the only way to really know the answer to that is to try. <marusich>though, for something like this (just changing enviornment variables exported by your .bashrc), logging out and logging in is sufficient. <reepca-laptop>Noob question - is it possible to log out and in without losing all my open programs and their states? <marusich>If you just want to do it for this one session, I suggest you just execute the "export" command in a shell (e.g., gnome-terminal, whatever), and then launch emacs from there <marusich>That will let emacs find the docs. But you won't really know if it'll work next time you log in until you try. <reepca-laptop>M-x shell and then from there launch another emacs. Since on launching the shell .bashrc is sourced, the variable is set for it. <reepca-laptop>but now I've got 4 emacsen open for various reasons and I think I'll just coagulate them into one... back in a smidge <brendyn>Gyah. Is it possible to make an offline install image where all the dependencies needed are already on the image? I've been running and rerunning this guix system init for 100 hours or so now but there are always network problems with hydra <marusich>reepca-laptop, can you do me a favor? Can you tell me if there is a line with INFOPATH in it in the $HOME/.guix-profile/etc/profile file? <marusich>The Guix manual recommends sourcing this when running on a foreign distro ((guix) Binary Installation), but I wonder if it would solve your issue. ***andreh1 is now known as andreh
<marusich>On GuixSD, the INFOPATH is set in /etc/profile. <reepca-laptop>I've been using emacs for about 2 years now and only just now realized that elisp symbols are case-sensitive when trying to find the value of Info-directory-list :| <reepca-laptop>How can I get the guix manual accessible from top-level info directory? The manual doesn't mention that, just how to get put the pages in the right place. <marusich>reepca-laptop, I think that if you have manuals on your INFOPATH, you will see them in the "top-level info directory", won't you? <reepca-laptop>According to C-h f "info" "The top-level Info directory is made by combining all the files named ‘dir’ in all the directories in that path." where "that path" is Info-directory-list. /usr/local/share/info/dir doesn't contain guix, and I'm not sure how to make it contain it. <reepca-laptop>(/usr/local/share/info/ does contain guix.info.gz and guix.info-1 through 3.gz) <Apteryx>reepca-laptop: This is happening on a foreign distro? <Apteryx>And did you try setting the INFOPATH to something reasonable? <reepca-laptop>I've set INFOPATH to show the guix info pages in ~/.guix-profile/share/info/ and the ones in /usr/local/share/info/ are available without being specified in INFOPATH both in the standalone info reader and in emacs. "info guix" from command-line works, but just "info" doesn't include it in the top-level directory, nor does "M-x info" in emacs. <Apteryx>I think you need a dir file in the Guix info folder, which can be generated using the 'install-info' command. <Apteryx>I'm not sure why such file wouldn't be shipped with Guix though! It might be a bug. <reepca-laptop>I think I see what's happened. Usually guix is installed for the user, which isn't my case - I only have it installed for root. So /root/.guix-profile/share/info/ contains the guix info files (and a correct dir file), but /home/reepca/.guix-profile/share/info/ does not. I installed the documentation into /usr/local/share/info/ as per the instructions in the manual in 2.1.6 when I did the binary install. However the dir file was not <reepca-laptop>updated in that process. The documentation in 2.1.6 should be updated to also run install-info for each of the files being installed. <reepca-laptop>Anyway, regenerated dir for /usr/local/share/info/ and now it's showing up properly in the top directory <marusich>reepca-laptop, by the way, the reason INFOPATH was not exported by ~/.guix-profile/etc/profile was because you did not have texinfo installed in your profile. <catonano>paroneayea: has squee a tarrball anywhere ? <marusich>If you had installed texinfo into your profile, then (assuming you had followed the advice given in (guix) Binary Installation to source $GUIX_PROFILE/etc/profile) I believe the INFOPATH would have been set up automatically (when you logged in) <marusich>reepca-laptop, interesting. Perhaps you could prepare a patch and submit it to guix-devel@ for review? <marusich>I'm sure everyone would appreciate the contribution to improve our docs. <reepca-laptop>Would it be fair to assume that if info is installed, then so is install-info? <marusich>reepca-laptop, for what it's worth, I followed the manual's instructions, and I do actually see guix in the top level directory when looking at it via "set -u INFOPATH info" <marusich>sorry, meant to say "env -u INFOPATH info" <marusich>It also shows up in emacs when I run "env -u INFOPATH emacs" <reepca-laptop>do you have guix installed for the user that's running those commands (that is, it's in their profile)? <reepca-laptop>er wait, probably irrelevant since you're unsetting INFOPATH <marusich>Just to be certain, i'll try removing it and trying again <marusich>on my machine, /usr/local/share/info/ contains guix.info-1.gz etc. (it's a symlink), and it also contains dir (another symlink, pointing to /var/guix/profiles/per-user/root/guix-profile/share/info/dir) <marusich>Could the presence of that dir symlink be the reason why the contents of /usr/local/share/info/ was included, including the guix manual, in the top level directory listing? <marusich>Even when I removed guix from the profile, I still see the guix manual in emacs and info (when running 'env -u INFOPATH info' or 'env -u INFOPATH emacs') <marusich>But, as you mentioned, the presence of guix in my profile shouldn't make a difference since I'm unsetting INFOPATH. <reepca-laptop>When ln makes a link, if there's already a file with the same name, does it overwrite it or fail? <rekado>‘ln -sf’ will overwrite the link if it exists. Otherwise it will fail. <reepca-laptop>That would explain it then, dir already existed in /usr/local/share/info/ on my system, so I didn't get the guix version. <marusich>Interesting. Does that mean we should still update the manual to recommend a different method of installing the info files into /usr/local/share/info? <marusich>In case someone else has a system where dir already exists? <reepca-laptop>I suppose so. The idea is to make the documentation available, like the guix command, for anyone on the system regardless of whether they have it in their profile, right? So I think it would make the most sense to combine the guix info files with whatever is already in dir using info-install. <catonano>ok, I have packaged both guile-squee and guile-miniadapton. Now, I can start my exploration for a new version of my nodejs data harvesting thingie <marusich>reepca-laptop, that sounds reasonable to me. Would you like to submit a patch? <reepca-laptop>I guess I'll have to figure out the process of that sooner or later, may as well be a small thing. Sure. <marusich>The manual has a pretty good description of how to submit a patch. It'll be a good reference <apteryx[m]>reepca-laptop: instead of trying to combine the dir files, it's probably best to document how to run the install-info command in our manual, or simpler, do not advise copying/linking the info manuals to /usr/local/share/info and instead advise to add their Guix root profile share/info (/var/guix/per-user/root/profile/share/info or something like that) <apteryx[m]>But for the latest to be global, INFOPATH would need to be set in /etc/profile <reepca-laptop>apteryx[m]: So we should advise to include the root info directory in INFOPATH for any users that want access to it? <rekado>catonano: do you get any error messages? How do you run it? <slyfox>looks like --keep-going does not work for 'guix build' <slyfox>tried 'guix build $(a long list) --keep-going' and it failed on 'vim-full'. if i remove 'vim-full' from the long list build continues <slyfox>or is the option also positional? should i specify it before package list? <catonano>rekado: no, i don't get any error message <catonano>rekado: I run it the same way I was running it when it worked <catonano>I have the postgresql service conugured in my config.scm <catonano>I will send my confiig.scm on the help mailing list <rekado>catonano: are there any messages in /var/log/messages ? <catonano>rekado: yes: FATAL: database files are incompatible with server <catonano>DETAIL: The data directory was initialized by PostgreSQL version 9.5, which is not compatible with this version 9.6.2. <rekado>I remember from my experience using postgres some years back that upgrades are a bit hairy. <rekado>e.g. you need the old version to upgrade to the newer version, or something <catonano>rekado: as far as I understand there's a dump format that is version agnostic <catonano>prrobably you are assumed to regularly store a dump <catonano>in this case it's not a problem because I had only one record in my db <htgoebel>I have some package containing a shell-script which is calling gpg. <htgoebel>I'm just wondering how to handle this case. <htgoebel>Or should I hard-code the paths to the executable into the shell-script?? <sneek>htgoebel, you have 1 message. <sneek>htgoebel, snape says: Thanks for the references. I already sent emails about it to the list (#26588). If you think it's not correct, please answer them. <wingo>i think guix pull doesn't need --fallback, right? it just updates the available package set. i think it will fetch the compiled package set from hydra if one exists but if not, it is automatically --fallback for that one job. <reepca-laptop>Also I'm wondering why guix pull is trying to download xz-5.2.2 <brendyn>guix pull built some stuff for me too once. not sure why that happents <reepca-laptop>seems to be proceeding just fine after manually installing xz with --fallback <rekado>htgoebel: I would embed the path to gpg. I find propagated inputs icky. <rekado>htgoebel: this als depends on how important gpg is to the tool. If it is optional and a rare use-case one could leave it off and ask users to install gpg separately. <reepca-laptop>So I'm installing emacs and noticing that there are a *lot* of duplicated inputs, just with different hashes. Why is that? <wingo>reepca-laptop: probably grafts <reepca-laptop>I'll add that to my list of things to read about when I wake up <rekado>FYI: Today I’ll push some of the Java patches that Roel reviewed. <efraim>guix-package.sh still fails on aarch64 <htgoebel>rekado: For me it's more the question about: Should the user be allowed to use a different version of gnupg. <rekado>htgoebel: depends on what the program does <rekado>htgoebel: I would assume that people would like to use their own installation of gnupg <rekado>in that case I’d expect that gpg would be looked up in the PATH and thus would use whatever I have installed <rekado>if gpg is used more like a library, though, then it makes more sense to add a stable reference to the store item. <davidl>I very frequently have problems downloading packages when I run guix system reconfigure, and it suggests using fallback. It says the reason is possibly network - related but I don't think so because it happens all the time. <rekado>davidl: it takes more than one machine to network <rekado>davidl: hydra often has problems serving all users <rekado>so it may indeed be a network problem, but on the end of the server, not on your end. <davidl>rekado: ok. I looped over the system reconfigure command all night without success. <davidl>now Im building icedove and probably the linux kernel and more from source. <davidl>if I get better uplink some day I can help with some hosting. <rekado>davidl: are you using an i686 system? <rekado>davidl: the kernel packages have been upgraded just a few commits ago <rekado>davidl: so it’s possible that hydra hasn’t yet built the latest versions <rekado>on i686 hydra seems to be lagging a bit; I haven’t been able to fetch a new icecat package in a while. <wingo>a sort of "state of the union" mail regarding guix infra would be nice <rekado>wingo: unfortunately, there are still problems with the hardware we got (random shutdowns). We will receive some replacement CPUs for the server soon. :-/ <wingo>brendyn: like what servers are out there, what their utilization is, what the bottlenecks are, what the average lag is, and a status on the various freedom aspects of our hardware <wingo>rekado: hoo, that is a bummer <wingo>i don't like the metaphor so much but this is definitely "pets, not cattle" ;-) <wingo>brendyn: also, what people can do to make things better -- is it a question of money or logistics or hackpower or what <brendyn>wingo: Yesterday I suggested making a ROADMAP <brendyn>I wonder if it is reasonable to have a repo with one great big .org file where such things could be constructed, and a road-map gennerated from it? <rekado>brendyn: I think it would be better to use the bug tracker for this <rekado>we’re already doing this to some extent <wingo>hard to say. a good first step would be to simply write down a road-map that is valid at one point in time and blog it <wingo>then it can decay with time, no problem, and if we want to update it we can do that too <rekado>(and debbugs allows us to view the bug list as an org file) <brendyn>I'm not really capable of that since I only understand packaging, not Guix it's self <wingo>rekado: how does that work? :) <wingo>rekado: what else are you not telling us about? :) <brendyn>civodul Already made a out of date ROADMAP, it's around about time to update it. <wingo>brendyn: i am sure patches would be very welcome :) definitely valuable work there. <civodul>plus, when i made it it was up-to-date :-) <wingo>civodul: your fault checking it into git instead of blogging it, then ;-) <brendyn>civodul: This time make a futuristic one that talks about Guix 2.0 and 3.0 <wingo>it can install a 3d-printing package and print whatever you want, reproducibly <wingo>sudo guix print3 sandwich-maker --fallback <brendyn>wingo: I work on packaging for Guix every day, but I seem to be cursed with choosing troublesome software. The Calibre developer apparently doesn't care diddly-squat for package managers, telling everyone to use the official binary <brendyn>I've literally discovered the existence of 2 or 3 licenses I've never heard of before by searching through the souce code. Nearly 15 documented in the license field so far. <civodul>once i'm president, --fallback won't be anymore! <brendyn>Can we make on offline installer for 0.13? <brendyn>rekado: Let you install one of the example desktop configs without the internet <rekado>haven’t seen roelj here for a while, but anyway: let everyone know that roelj is a hero for reviewing more and more of my ugly java patches! <rekado>brendyn: so it would come with a pre-filled store that only has to be copied over? <brendyn>Maybe It could just be available as a torrent instead of using gnu servers <sneek>I last saw roelj on May 02 at 12:41 pm UTC, saying: uh-oh. <brendyn> Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its own source and binary releases. <brendyn>desktop-file-utils should be native-input or input/ <paroneayea>catern: no squee tarball, but maybe there should be? <efraim>I don't understand #:build #f in clisp <catonano>brendyn: lots of sotwares are hard to package ! <catonano>paroneayea: I made a package recipe but a solution for the link to the C library is necessary <brendyn>catonano: Packaging is also backwards; you have to unpackage all the stuff upstream has bundled with their software <paroneayea>catonano: yeah, gotta do that... I've done it before... <efraim>Compiling clisp on aarch64 fails with a 'cc' call, which doesn't panic it on x86_64 <rekado>It seems that cuirass just stops doing anything when a build fails. Is this normal? <rekado>I know that the GSoC proposal involved making cuirass more robust <rekado>but how does bayfront handle this? <efraim>On a related note, I tried blind-updating Hydra but the build failure didn't change and I didn't investigate <civodul>rekado: good question, i submitted a patch in Cuirass to use keep-going and so on <civodul>maybe we should update our Cuirass snapshot <civodul>yeah our Cuirass snapshot is one commit too old <rekado>ah, good to know. I’ll update our package then. <brendyn>Where should mathjax go? A new gnu/packages/javascript.scm ? <civodul>oh it also needs an upgrade to Guile 2.2 <efraim>I don't know what it means, but Qt-5.9 is supposed to be LTS <catonano>brendyn: hasn't mathjax an awul lot of nodejs dependencies ? <brendyn>Seems to just require xorg-mkfontdir and fontconfig <efraim>Sneek later tell janneke mes failed on aarch64 like this: bash: out/i686-unknown-linux-gnu-mes: cannot execute binary file: Exec format error <efraim>Sneek later tell janneke *** [module/module.make:14: module/mes/read-0-32.mo] Error 126 <efraim>I should try to write a systemd unit file for curiass, then I wouldn't have to always keep on top of my machine to make sure its building something <efraim>I'll put it on the to-do list with writing a rebootstrap-hello.scm file to create bootstrap binaries and use those to build back to 'hello' as a way to test core-updates and bootstrapping <brendyn>Add a service that measures your cpu temp, and when it goes down, restart curiass <efraim>I'd have to break out my conky scripts to remember where that information is <Apteryx>reepca-laptop: re INFOPATH, I would think that would be a better approach (to set INFOPATH to the root profile's share/info when using Guix on foreign distros -- that way we don't have to tell them to mess with install-info to regenerate the 'dir' file, and if they want it to be system wide they can always export INFOPATH in /etc/profile). <rekado>who would like to try to write a lightdm service before the next release? <bavier>rekado: I like the idea, but I don't know if I'll have the time <davidl>my qemu 2.8 build fails by not passing a post-something test. Im running with -K flag now though. Should I report failing builds somewhere? <davidl>efraim, mine said qemu 2.8 in the output just 20 min ago. <rekado>davidl: are you using the latest version of Guix? (e.g. with ‘guix pull’) <civodul>ACTION .oO why do we have to rebuild texlive today? <castilma>hey guys, the doc says on guix pull : "the command downloads the latest guix source code and package descriptions, and deploys it". so is it more like $ apt-get update && apt-get upgrade ? is there a way to just $ apt-get update? i.e. to only update package descriptions? <davexunit>it doesn't update any of your other software <castilma>the I understood 'deploy' wrong. and why does it download the newest guix source code? <davexunit>castilma: because 'guix pull' compiles a new guix from source <davexunit>so it uses source rather than a pre-built binary <castilma>so, it does upgrade one package;guix. what's the rationale for directly upgrading? <rekado>civodul: new sub-command ‘guix why texlive’? <davexunit>castilma: if you don't upgrade you won't be able to install new things. <civodul>i thought about doing that in 'guix graph' <rekado>ACTION works on some forgotten patches in guix-patches <castilma>davexunit: that sounds strange to me: you have to upgrade the package manager to a newer version to be able to install newer versions of other packages. afaik 'normal' package manager don't work like that. the package lists are always in the same format, and you can still use a version of your package manager that is several years old, right? I mean, the only reason why that would be necessary, is if the package-description-format chang <b11111000000>i'm sorry if it discussed already, but I can't find details about how to setup X11/xorg.conf.d configs? <davexunit>castilma: in guix, packages aren't distinct from any other part of guix. <davexunit>they are Scheme code like the rest of it. guix comes with all of its packages. <b11111000000>^^^ question related to GuixSD: I need to create a package, that put all stuff to ~/.guix-profile/etc or somewhere? Or I need to simply create /etc/X11/xorg.conf.d ? <rekado>castilma: packages in Guix are Scheme values. Together they form a graph data structure. When you install a package you translate part of that graph into binary artifacts. <rekado>b11111000000: to change the xorg configuration you should change it in the operating-system definition <rekado>b11111000000: e.g. in /etc/config.scm <b11111000000>rekado: but complex configs of specific Input and Video devices? <rekado>b11111000000: the manual has some information about this. Search for ‘xorg-configuration-file’. <b11111000000>rekado: I read info already, but can't figure out how to config it <rekado>b11111000000: it allows you to add text snippets to the configuration. I use it to add support for a track-ball. <rekado>b11111000000: just a moment, I’ll share my configuration with you <rekado>b11111000000: it’s a bit long — don’t worry! <rekado>at the top you see ‘marble-mouse-settings’ <rekado>I’m reading the regular xorg configuration snippet from a file. <rekado>then later with my modification of ‘slim-service-type’ I’m adding it as extra config <rekado>(together with an evdev snippet to allow me to use dvorak for the SLIM display manager login screen) <castilma>I would expect, that updating the package list (=scheme values), you wouldn't need to update the program that reads those newer values. I thought, that the packages list is just a lot of scheme code, that is interpreted when I run e.g. guix package -u foobar; it searches in this huge scheme file for the foobar function/value and applys it. but now I get the feeling, that the scheme code /package list ist compiled and included in the gui <rekado>b11111000000: you’re welcome. If you have any questions about this just ask! <rekado>castilma: there is no package list. There are only live package objects. <haz1>Hi, is there a command to get the list of packages that provides a file? Something similar to "yum provides" <rekado>castilma: the package manager does not interpret a list of packages; the available packages together with the facilities of Guix form a Scheme library. <rekado>haz1: unfortunately there is not. <rekado>haz1: this would require users to query a remote server such as the build farm <rekado>haz1: the build farm software currently does not provide this feature <rekado>haz1: if you have a reasonably large store it’s sometimes enough to just search in it, e.g. with ‘find /gnu/store -name foo’. Sometimes the thing you want is already there, but just not in your profile. <haz1>redako: well, ironically I am looking for the package that install find! <rekado>haz1: find is part of the findutils package <civodul>the activity on guix-patches is impressive <castilma>rekado: the penny didn't drop, yet. but I think it's on the edge of the table. thanks for that. another thing. I'm currently installing guixsd in qemu. I'm running guix pull and it is slow af. is that normal? <haz1>redako: right now, I execute "yum provides '*/foo.h'" which returns a list of package names. And then hopefully the names of packages on guix are similar <civodul>rekado: actually the big texlive tarball bundles lots of things under libs/ <davidl>rekado: I tried running guix pull but ran into errors again. Im not doing a full reinstall and didn't run guix pull and am now resorting to guix init --fallback.