<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
<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?
<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>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.
<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"
<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?
<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.
<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.
<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
<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?
<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?
<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
<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: 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!
<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