<djeis>Does anyone have good strategies for debugging why shepherd isn't behaving like I expect? <djeis>(For reference, I'm trying to define a one-shot service and it's failing to start it) ***rekado_ is now known as rekado
<jab>djeis: That might get easier to figure out in a month or two...See ludo's recent guix devel message: <lfam>"This slows down startup, <lfam>prevents things like running two clients at the same time, or serving a <lfam>client while waiting for a PID file. In other words, it sucks." 😂 <lfam>That's very promising work! <AwesomeAdam54321>Services should run in the foreground so that the shepherd can manage them properly <the_tubular>Something weird just happened with nscd and/or shepherd ... <AwesomeAdam54321>the_tubular: If you're running it as a user shepherd, the log file is at $XDG_CONFIG_HOME/shepherd/shepherd.log <lfam>Or else, check /var/log/messages <lfam>Just in case you didn't know, the nscd service has a couple helpful actions that are not so discoverable from the command-line <lfam>`herd statistics nscd` and `herd invalidate nscd` <lfam>They are documented in the manual, of course <lfam>They are documented in Base Services section of the manual <lfam>Oh, right: `herd doc nscd list-actions` <lfam>That's how you find it from the command line <lfam>herd doc nscd action invalidate <the_tubular>I want to create something like %default-config and have it set like my locale and timezone, so I don't have to set it in every config.scm file <lfam>I guess you can just (define-public %default-config) in the_tubular.scm and import it in config.scm <lfam>Or define %default-timezone and etc <lfam>Maybe people can share their solutions <lfam>Yeah, one season per year ;) <lfam>It's fun to read News for channel 'guix' <the_tubular>But yeah, I like it, often new switches are added that I've never think of and they are pretty cool <lfam>What about announcement of big upgrades? <lfam>Like, "Added new kernel series" or "Default kernel series upgraded" *the_tubular fears april's fools <lfam>But really, is a new kernel version news you can use? <vagrantc>seems a little redundant ... i mean, guix notices when you get a new version of a package <vagrantc>though, i guess in some ways the kernel is potentially a bit more disruptive <lfam>That's my intuition, but then I haven't noticed many complaints when the major version is updated <vagrantc>sometimes people are eagrely awaiting a new kernel version :) <lfam>5.17 is cooling on the patch tracker <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." <jgart[m]>How can I load a profile in emacs without restarting emacs? <jgart[m]>I created a new default profile in a separate terminal. <jgart[m]>But have a running emacs instance that is not using the latest profile ***sneek_ is now known as sneek
<the_tubular>I mean, apart from /gnu/store, is it use for something else ? <lfam>But, it does give us the option later to easily add something there <lfam>My guess is, it is the same length as /nix/store, and was thus the easiest thing to make <the_tubular>Sorry, it's late. And I'm just browsing docs. and I get weird questions :P <AwesomeAdam54321>lfam: Why does the guix installation script check if /gnu exists, rather than /gnu/store? <tschilptschilp23>jgart: if still of interest -- if you mean your ~.emacs~, you can do ~M-x load-file RET~ with the buffer in focus ***alMalsamo is now known as lumberjack123
***iyzsong-www is now known as iyzsong-w
***toulene3 is now known as toulene
<bhoefling>Is a relocated store generally "supported" by Guix? I.e. due to company restrictions, I'm in $HOME/g/s instead of /gnu/store. Is this now my fault, or should this work? <AwesomeAdam54321>bhoefling: Yes, if you're building Guix from source. You can set it to use a different store location by giving the --with-store-dir= option to ./configure <bhoefling>AwesomeAdam54321: Yes. But in practice, I get some problems. Lately more. <bhoefling>My concrete problem: Some packages get extra characters added, like in g/s/f0d53nam13a4vvj849xv6db477hnp4xw-zc4n76s2x0jgsf9v3-rust-packed-simd-2-0.3.6.tar.xz <bhoefling>And this is nowadays a dependency of nearly everything :-( <bhoefling>Any idea how this extra string comes in, and why not on a "normal" /gnu/store? <wehlutyk[m]>I'm trying to build a raw image for a rock64 board, from my x86_64 laptop <wehlutyk[m]>everything works well with the `gnu/system/images/rock64.scm` example configuration <wehlutyk[m]>but once I start modifying things and some builds need to happen on my machine, it runs into errors <wehlutyk[m]>fish seems to be built properly on aarch64 on cuirass... <wehlutyk[m]>is there something I'm missing, like a cross-build configuration I haven't set up? <wehlutyk[m]>(my build command is `guix system image config.scm`, where config.scm is the first pasted file from above) <civodul>wehlutyk[m]: looks like the fish package isn't prepared for cross-compilation <civodul>may be fixed by adding coreutils and bash to 'inputs' <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) <civodul>it's not maintained by the project though ***m5zs7k_ is now known as m5zs7k
<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?: <tooblu>guix install: warning: Consider running 'guix pull' followed by <tooblu>'guix package -u' to get up-to-date packages and security updates. <tooblu>The following package will be installed: <tooblu>guix install: error: profile contains conflicting entries for emacs-dash <tooblu>guix install: error: first entry: emacs-dash@2.18.1 /gnu/store/yv1347xsnmpb4y67bm57wivcxvd1q1z3-emacs-dash-2.18.1 <tooblu>guix install: error: ... propagated from emacs-lsp-mode@7.0.1 <tooblu>guix install: error: second entry: emacs-dash@2.19.1 /gnu/store/vjmddpdg51q2v2881b5fshi69mp5j3xm-emacs-dash-2.19.1 <tooblu>guix install: error: ... propagated from emacs-transient@0.3.7 <tooblu>guix install: error: ... propagated from emacs-magit@3.3.0 <tooblu>hint: Try upgrading both `emacs-lsp-mode' and `emacs-magit', or remove one of them from the profile. <anadon>@tooblu: You still need to run `guix pull`. <tooblu>I did a pull and full upgrade. It didn <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. <anadon>Guix doesn't isolate packages from transient dependencies. I wish it did, but that has some other consequences. <vagrantc>packages with propagated inputs can be a bit tricky to have co-installed sometimes <tooblu>I did git pull and git upgrade. I just did another git pull, and then a git upgrade emacs-magit (didn't do anything), and then git install emacs-lsp-mode, which failed as above. <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 <tooblu>$ guix shell emacs-lsp-mode emacs-magit <tooblu>Try `guix --help' for more information. ***the-porcupirate is now known as porcupirate
<vagrantc>you seem to be running a very old version of guix <vagrantc>you're not running the version you've pulled <atka>fresh install? forgot hash guix perhaps? <tooblu>do I need to do a guix pull as root to get the latest guix? <tooblu>  commit: a0178d34f582b50e9bdbb0403943129ae5b560ff <vagrantc>you should never really need to run 'guix pull' as root <vagrantc>there are some exceptions, but in general... <vagrantc>a0178d34f582b50e9bdbb0403943129ae5b560ff is from May 2021 ... <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>tooblu: .config/guix/current is what "guix pull" updates. "guix install" (and upgrade, etc.) manage what packages are installed in your profile other than guix itself. <vagrantc>tooblu: and your profile is .guix-profile/bin/ ... which you shouldn't have to manually manage at all. <tooblu>so, in my .{bash,zsh}rc file, I should have: <tooblu>GUIX_PROFILE="$HOME/.config/guix/current" <tooblu>GUIX_PROFILE="$HOME/.guix-profile" <vagrantc>the variables should get set up properly out of the box, but in initial installations, sometimes you may need to log out and log back in again to get them to properly get noticed <vagrantc>i haven't had to manually tweak those in years; it should work out of the box. <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. <vagrantc>it used to instal something into /etc/profile.d if i remember correctly... <tooblu>I don't see anything obvious in /etc/profile.d <vagrantc>that should ... do the right thing, as long as you don't re-do what it did in your own ~/.*shrc <vagrantc>once you've run "guix pull" and installed something, and then log out and back in again <tooblu>ok, so remove anything guix related out of my ~/.*shrc? <vagrantc>i *think* so ... but it wouldn't hurt for someone more savvy to speak up at the moment :) <vagrantc>also, i've never really used zsh, certainly not in the context of guix, so ... maybe there's some gotcha there. <tooblu>I'll try it ... see what happens. Thanks a ton for your help! <vagrantc>hope it works for you ... you do have both .config/guix/current and .guix-profile now ... so ... it *should* work <vagrantc>i think when i first started using guix, you had to manually add all that stuff manually, so there might still be some documentation out there about adding it <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) <jts>Minigalaxy is on Flathub* I should say <anadon>Someone want to explain _this_ error to me? <anadon>configure: checking for guile 3.0 <anadon>configure: error: guile required but not found <anadon>$: guix environment guix --pure --ad-hoc help2man git strace bash lesspipe less guile <anadon>$: ./configure --localstatedir=/gnu/store <vagrantc>anadon: unrelated ... let me introduce you to https://paste.debian.net ... generally if you're pasting more than three lines you should use that and paste the link <vagrantc>anadon: do you mean the version-1.4.0 branch of guix? that branch is not currently developed, if i recall correctly <civodul>anadon: hi! could you check what "type -P guile" returns in that shell? and what does config.log say? <civodul>jts: hi! if its sole purpose is to get non-free software, then no, it cannot be in Guix proper <civodul>but if it has other purposes, it could be in <anadon>Sorry, I've been out of the swing of things for like 2 years. I've gotten rather rusty. <anadon>civodul: no output, return status of 1. <anadon>If 1.4 is no longer developed or maintained and was never released, should it be deleted? <civodul>the branch will probably be rebased soonish <anadon>Me walking in after a bit, I thought that was the branch I should work off of. <civodul>well, master is where the focus is right now, but hopefully we'll revive version-1.4.0 real soon now <anadon>I started my packages in their own file anyways, so it is trivial for me to hop bases. <civodul>so, i don't get why "guix environment guix" wouldn't give you guile <civodul>BTW, you might want to try 'guix shell' too <anadon>slash "They're the same picture" <jts>one is the development eg master branch of the docs <jts>civodul: what would be the significance of a release at this point given that Guix is functionally a rolling release atm? <jonsger>PR in public relations not in pull request :P <vagrantc>is there any way to get a list of new/upgraded packages from guix pull now? <anadon>Updating guix isn't getting the new commands like `shell`. Do I need to nuke and pave? <kitty1>its kinda sad how overly verbose the news is now, I really really really liked when it was just automatic, made it feel like guix was made for humans. <kitty1>I mean, I could obviously just set up some command to do that myself but still kinda sad without it new users might miss thats even a real feature <kitty1>and makes keeping track of updates for new people require more mental energy and thus less accessible <kitty1>I mean like, overly verbose the command to do it is <kitty1>instead of guix pull or guix pull news like before automatically doing it. <kitty1>Imo it should be the other way around <kitty1>guix pull --minimal or guix pull news -M or something for the simplified view. <kitty1>with the detailed view being the default. <kitty1>Would be much more accessible for new people imo <acrow>anadon: No I wouldn't 'nuke and pave'! Maybe just try hash guix and/or source ${GUIX_PROFILE}/etc/profile <acrow>anadon, did you do a 'guix pull' beforehand? <acrow>anadon: As yourself, not root. <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 <jts>anadon: when you run guix package --export-channels what branch is listed for the guix channel? <kitty1>but I really think just guix pull should do that at the end by default, with some form of guix pull -M (minimal) giving it the current behaviour <anadon>The time cost of fixing has now exceeded that of starting from scratch, and so I'm reinstalling. <anadon>Why is `/gnu` stuck as RO that I can't delete? <civodul>now i hear what you say, and it seems to me different people have different needs <vagrantc>what i never heard from anadon was weather they logged out and back in again ... <civodul>some were just as vocal saying that it was all too verbose before <kitty1>civodul: I'm aware; and I def do see the use of having that as an option but I do disagree with that being the default tbh <kitty1>but maybe I'm wrong, I am just a sample size of one and thats not something that would be hard for me to set differently for myself personally lmao <civodul>yeah, the question of what a good default is is tough <civodul>i was personally fine with the previous defaults, but i've seen people who are "less into Guix" not pay attention to any of those lines <civodul>i think by keeping only news headlines by default, people may be more likely to read them <kitty1>huh, thats strange, I'm not very deep into things (although use it as a daily driver) and I pretty obsessively look at every new package and package update that comes through lmao <civodul>but again, we'd need a user study with a large sample <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?