<vagrantc>does guix pull still report new and upgraded packages?
<lfam>Let me check `guix pull --news` for more details about the news feature
<lfam>"The output of `guix pull --news' has been shortened to display only fresh news items such as this one. It no longer includes the partial selection of new and updated packages, which was often long enough to be distracting whilst being too short to be useful."
<civodul>the fiberized shepherd is a fun thing to hack on
***lukedashjr is now known as luke-jr
<gnucode>civodul: may I ask how where you get the courage to dare to hack crazy things? It seems like you are one of the better people who are willing to try to hack together new and exciting guix related things.
<civodul>gnucode: there's a number of people who hack crazy things here, sometimes much crazier than this :-)
<civodul>for me it's entertaining, kinda like a reward after less fun patch-review work or $DAYJOB work
<MysteriousSilver>hi! is there any official mirrors for substitute servers? (incase the european servers become inaccessible)
<htsr[m]>Hi Guix! I'm trying to import some go modules with `guix import go` but some of them are in sub-directories of the git repository so the import fail. Should I write the package definition myself? How should I handle this sub-directory thing? I can't find an existing go package in guix to take as an example.
<htsr[m]>Nervermind, I've found one! It's `go-github-com-muesli-reflow-wordwrap` and it's pretty simple
<civodul>htsr[m]: ah, great that it works for you :-)
***dongcarl1 is now known as dongcarl
<attila_lendvai>htsr[m], i have some pending patches to the go importer that can deal with such modules. which reminds me that i should wrap them up and send them upstream...
<htsr[m]>attila_lendvai: Awesome! I'll wait until "it's ready®". Do you need help to test the patches?
<attila_lendvai>htsr[m], i'll take a look at them, rebase them to master, and push them somewhere in the next hour or so
<ekaitz>hi guix here can i install gnu/stubs-32.h?
<ekaitz>in other distros that's at glibc-devel.i386
<attila_lendvai>htsr[m], it compiles and seems to run fine with a cursory testing, but do note that there were some non-trivial merge conflicts, so it may be borked due to them
<attila_lendvai>htsr[m], the branch also contains a WIP commit that enables info level logging. you may want to turn that off, or drop that commit
***robin_ is now known as robin
<anadon>Hello all, I'm trying to add 2 packages for shared libraries and headers/static libraries required for Antlr4 development in C++. I need to modify the cmake build step to remove files not relevant to each particular package and to set some environmental variables. Can someone either point me towards the specific documentation I'm missing ot
<anadon>suggest how I might accomplish these tasks?
<anadon>I think I just need to modify the build steps.
<tooblu>getting conflicts with emacs package. Is there a way to resolve this other than removing one of the conflicting packages?:
<anadon>If that doesn't do it, you'll need to figure out a timestamp range and run your profiles out of guix from that timestamp, or update emacs-lsp-mode (and everything else for that metter) to use the new version of emacs-dash.
<tooblu>For emacs packages, is it better to just use normal package sources, or should I keep working to make the guix emacs packages work?
<vagrantc>tooblu: do you have other channels configured? there appears to be only one version of emacs-dash defined in guix master, so i don't see how there would be a conflict if you are usign the same version of guix to install them
<vagrantc>tooblu: try this ... guix shell emacs-lsp-mode emacs-magic
<vagrantc>if it is in path, "hash guix" as atka mentioned
<vagrantc>also ... command -v guix ... will show you the path to the guix you're using
<vagrantc>if it's in /usr/bin or /usr/local/bin or something, it's likely an old installation (e.g. from package or from the guix binary tarball)
<vagrantc>(presuming you're using "bash" as your shell ... not sure about other shells too much)
<tooblu>It wasn't. I had /home/jra/.guix-profile/bin which looked like it was linked to the same place. I just did a GUIX_PROFILE="/home/jra/.config/guix/current" and . "$GUIX_PROFILE/etc/profile", and then guix pull, guix upgrade emacs-magit, guix upgrade emacs-counsel, and guix upgrade emacs-lsp-mode... which worked!
<vagrantc>no need to upgrade individual packages "guix upgrade" should upgrade them all
<vagrantc>as, that would cause you to get an earlier version of guix each time you "guix pull && guix upgrade"
<vagrantc>well, guix pull wouldn't enter into it, i guess ... if you're using the guix installed via "guix install guix" each time your run "guix upgrade" you'll effectively downgrade all the packages guix is aware of ...
<vagrantc>in other words, don't install guix into your profile :)
<vagrantc>you want to make sure to use the guix provided by "guix pull"
<tooblu>I really don't get the whole $HOME/.guix-profile/bin and $HOME/.config/guix/current thing. I feel like sometimes I'm supposed to use one, maybe just on install?, sometimes I'm supposed to use the other??? Sometimes I'm supposed to put one in my account dot files, sometimes the other. Is there a good explanation of this?
<vagrantc>.config/guix/current should be first in your PATH, then it shouldn't matter if you install guix in your profile (though at best, it will cause you problems, so ... don't)
<vagrantc>e.g. before you have installed your first package, there won't be a .guix-profile, before you run "guix pull", there won't be a .config/guix/current ... so after you've done those things for the first time, i would recommend logging out and logging back in again
<vagrantc>but if you've manually tweaked your .bashrc/.zshrc ... you might need to undo those for it to work properly
<tooblu>I think, maybe, the install puts the second on in, but then after a guix pull it tells you to use the other one. I don't really know. I'll go with the first one and see if that helps, generally.
<simendsjo>Awful hack in my .sblrc, and it works... `(ql:quickload :cffi) (pushnew "~/.guix-profile/lib/" cffi::*foreign-library-directories* :test 'equal)`
<jts>Hello everyone. If I managed to package Minigalaxy, a Gtk Linux client for https://gog.com , for Guix, would it be possible to get it into Guix proper or would I need to keep it elsewhere? I know it allows users to install nonfree software, but my reasoning is that Flatpak does as well and is still in Guix (in fact, Minigalaxy is in Flatpak, I'd just prefer a native package)
<cwebber>"should we really be using guix shell if it's not in the stable release" <- a thing said at work ttoday
<acrow>anadon: Hmmm... that seems like a problem -- maybe try logging out and then back in to get a fresh shell/session, no?
<civodul>kitty1: "guix pull" is less verbose now, not more
<cwebber>so yeah even if guix is rolling release, it does make a difference in perception... and each release is a heartbeat
<anadon>acrow: source and new shells don't change behavior.
<anadon>cwebber: Actually, that may be it. I may just be on `stable`, whatever that end up meaning.
<anadon>Which suggests that the original build guix doc I was on is correct, which makes the errors I was seeing even more bizarre.
<acrow>anadon: unless they are in differing environments.
<anadon>Your unintended implication is that `--pure` doesn't work, which is probably wrong and much scarier.
<acrow>anadon: I guess I don't understand your situation.
<anadon>It is software. No one understands anyone's situation really.
<kitty1>civodul: verbose as in having to write things down in a more verbose manner ; the information of guix pull --news --details is extremely extremely important for new users to be exposed to without having to make their own commands or modify guix in some way. At the very least guix pull -N should do the job of guix pull -N --details, and some form of guix pull -NM (news minimal) should do the job of
<kitty1>I'm someone who is very curious about that type of thing, who guix pulls maybe even too frequently, and is on a decent monitor so I'm going to be very bias towards that compared to someone who guix pulls infrequently, and doesn't care as much lmao
<civodul>maybe at some point we'll need a config file to tweak these things
<kitty1>ah yeah, that would be quite cool if done well
<acrow>kitty1: for the time being could you just create a 'guix-pull' script?
<acrow>guix pull && guix pull -N --details <-- for instance
<acrow>I suppose there is a guixier way to do it though.
<kitty1>acrow: yeah, thats what im probably going to so; on a personal level this isn't much of a problem as I already know of it and some time will bother doing something like that, just kinda worried if new people to guix will even be exposed to that functionality
<Ox151>hello, I have a fresh GuixSD install and I am trying to use gpg but iam not being prompted by pinentry at all. I have set a gpg-agent.conf with the line "pinentry-program /home/<user>/.guix-profile/bin/pinentry-gnome3" but I still get not password prompt. Has anyone been able to sucessfully use pinetry with gpg easily? or am i missing something?