IRC channel logs
2026-11-05.log
back to list of logs
<citadel>I'm running into an issue where my terminal (foot) outputs "WARNING: terminal is not fully functional" when I try to run a command that uses a pager, for example git log. How should I go about fixing this? <ieure>Use a fully-functional terminal. <citadel>:( but foot seems to work fine on my other machines nut running guix <ieure>I don't know anything about foot, the message usually gets printed when TERM=dumb or TERM=emacs, it means that the terminal is line-oriented and the cursor can't be moved around. <sham1>You need to include your terminfo to the profile you're running in, e.g. guix shell or similar <sham1>Or yeah, something like TERM=xterm also works <citadel>sham1: Could you explain how I could do that? I've been toying around with Guix Home these days so I have a somewhat functional home.scm file at the moment. I'd prefer to go with the first option of including terminfo in my profile. <sham1>Well you need to include `foot` into your (packages ...) field in your home-environment <sham1>Can you use a pastebin to show your home-environment <sham1>What is your TERM environment variable. Is it just "foot"? <citadel>One potentially weird thing I have done was set my user's shell to fish in the system scm file, and added ~/.guix-home/profile/bin to PATH in my fish config. <citadel>but... I'm not really sure if that would cause issues with foot? <sham1>Oh yeah, you need all of the environment variables from ~/.guix-home/profile/etc/profile <sham1>Because that's for example how the terminfo database gets located <citadel>Ahhhh I see. I think I better read up more on shells in the manual. Thanks <citadel>Neat. Even though documentation doesn't exist yet for (home-fish-service-type) I was able to pretty easily check the source code and get it to work. Now my foot terminal doesn't complain everytime I run a pager command :D <Guest26>i have a manifest defined in a guix channel and now want cuirass to build a docker image from that manifest. `guix pack -m` expects a path to a manifest file. `guix pack -e` expects an expression that evaluates to a single package. is there a way to yield the path of a channel checkout (which i could extend by the path of the manifest)? or <Guest26>is there a way to make `guix pack -e` evaluate to a manifest and use that? <illybytes>so im progressing well witb my packagine of the gnome extension tophat <illybytes>only issue is, im trying to compile translations <illybytes>present charset "utf8" is not a portable encoding name <rrobin>did something change when using newer versions of rust and rust-analyzer? It looks like rust-analyzer is not working properly here, it fails to resolve symbols from std lib. It has been a while since i have used it, but I see there was some fiddling with RUST_SRC_PATH in my settings. Still trying to dig up the issue, I just see failed calls to cargo metadata in the logs <efraim>I built rust-1.91 using clang-runtime-21 for the compiler-builtins and dropped the time for 'build from 687 to 678 seconds ... <efraim>rrobin: I didn't have a way to test rust-analyzer with rust-1.98 vs rust-1.93 so it's possible it's not correct <efraim>oh, then I assume it's supposed to work and have no useful suggestions :( <rrobin>just wondering - it has been several months since I touched rust-analyzer <rrobin>something probably changed - the metadata errors were my cargo settings, but the absence of std symbols is probably something else, oh well <efraim>building rust-1.92 with both rust-1.91 options, without clang-runtime 652 seconds, with is 676 <Icy-Thought>here is a question, is there a way to have all manifests (scattered around various places) auto use the latest version of x (example gcc) package? Or should one just resolve to installing it system-wide? <Icy-Thought>I guess guix gc would take care of updating it but yeah <bjc>all your manifests should be using whatever is in the current user's guix profile unless you take steps to do otherwise <ArneBab>lilyp: thank you for merging the wisp update! <Heterochromium>Will there be problems if I have NetworkManager and `static-networking-service-type` enabled simultaneously? <bjc>i thought they'd conflict <rrobin>for some service you can override with shepherd-provides, but i don't remember if the network-manager service supports it <rrobin>but i think static-networking-service-type has the equivalent option so they don't conflict <rrobin>yeah that is it, network manager service does not have an option, but static-networking-service-type has (provision '(internal-networking)) <rrobin>now if you configure the two service to manage the same interfaces bad things will happen for sure. see the nm config option unmanaged-devices=except:interface-name:enp1s0* <bjc>by default, though, they conflict, right? <bjc>like, they all provision 'networking <vagrantc>is there a way for a git-fetch origin to do a shallow checkout that has still has history between a specific tag and everything up to a specific branch? i need to basically call git-format patch to generate a patchset, that can then later be applied in another package ... <ieure>vagrantc, Don't git-fetch clones remove the .git directory? <vagrantc>ieure: right, would also need to stop it from doing that too <vagrantc>alternately, i could just do it all manually and publish a branch with the patches ... but wondering if there is a "cleaner" way to do it <ieure>vagrantc, I'm not sure you can reasonably do this in a Guix build. Maybe you could abuse computed-origin? <ieure>Preserving .git seems like a big ask, it's removed to ensure reproducability. <vagrantc>guess i could also publish a tarball of the patches ... hrm. <vagrantc>ACTION plays the git fetch && git rebase && git pull && git push || someone else pushed already try again game <vagrantc>my guess is most folks skip the git pull step <ieure>Depends on the thing getting pushed? If it's just a package update or something, I don't think there's much value. <vagrantc>i've been surprised how many "trivial updates" have ended up breaking guix pull over the years <vagrantc>i usually wait till most of europe has called it a night ... probbably should just wait a few more hours before bothering <vagrantc>only ... 5 rebase attempts this time ... and thus the last update for linux-libre 7.2.x concludes. <csantosb>I just noticed that `./pre-inst-env guix refresh --list-dependent eigen` is different to `guix refresh --list-dependent eigen`, feature or bug ? <lechner>I thought the discussion bemoaned the state of master, but I was probably wrong <dlowe>hm. herd status is hanging on me <dlowe>also I can't connect via ssh <GalaxyNova>why does git-fetch call git directly instead of libgit2 through guile-git? <bjc>libgit2+scheme is much easier to bring up than git <dthompson>libgit2 also does not support certain git features <bjc>yeah, it's annoying and very slow to boot <bjc>but bootstrapping is a very important part of guix, so sacrifices are made in its support <bjc>“to boot” is an idiom meaning “as well”. sorry, that might be confusing in this context =) <GalaxyNova>I was looking into the new sha256 support for origins and the current implementation is unfortunate, because it requires an extra network round trip <GalaxyNova>perhaps if it uses libgit2 instead there would be a way to detect the object format during the git protocol handshake itself <bjc>an extra network trip is the least of its problems <bjc>it does use libgit2, doesn't it? <bjc>i'm not on my guix system and can't check <yelninei>sah256 support in libgit2 is still experimental <bjc>really? i don't remember seeing that <bjc>i don't know the libgit2 internals, but on the scheme end it's just an ffi into it <GalaxyNova>one defined in git-download.scm, the other in build/git.scm <GalaxyNova>the former is used for guix pull the other is for builds <bjc>i'm not familiar enough with those bits to say, but it strikes me as very odd <bjc>i do know that one git fetch of the complete repo is very slow all by itself <GalaxyNova>yeah there is (was?) some work to make it faster <GalaxyNova>but it is imo unfortunate there is an extra 1-2 second overhead now to every git-fetch operation in builds <lechner>dlowe: You may have an error in your self-defined Shepherd services. I was a beta tester and saw that often. <dlowe>no, I think this may be an error with shepherd running sshd in inetd mode <dlowe>I restarted ssh-daemon and its child nodes started being numbered at 1 again. <dlowe>and eventually it hit an existing live connection name <GalaxyNova>bjc: also at least in origins with git-fetch there is rarely a clone of the whole repo <marty>i have mullvad vpn and am looking to get it working on my guix laptop. does anyone know if i start by installing 'wireguard-tools' ? <ieure>marty, Depends on your setup. Network Manager has native support for WireGuard, and doesn't need that package installed. You can configure it with ex. the GNOME networking stuff. <marty>ok, i have the Gnome stuff for now <ieure>Should just be a matter of going into the settings and configuring, then. <ieure>Has been a while since I've done that, though, so I don't have much guidance beyond "it worked the last time I needed." <marty>now i have mullvad vpn on my guix... no debian repo or systemd needed <marty>then i followed these directions to use nmcli to add the vpn connection with the file <ieure>marty, Excellent! Might be worth writing up and contributing to the Guix Cookbook? <marty>i'm on codeberg already. is it on there? <ieure>marty, Yes, in the guix/guix repo, `doc/guix-cookbook.texi'. <marty>also, i believe the nmcli is separate from Gnome... so it would work on other desktops and cli installs too. i believe... i could test. <ieure>Correct. Network Manager is DE-agnostic, nmcli talks to NM directly. As do GNOME/KDE and likely other DEs.