IRC channel logs

<char>Hi, so Im trying guix home. I have the home-niri-service-type in there, but now niri doesnt show as an option in gdm even tho it did when I have the niri configuration in my operating-system guix config.

<pomel0>lol I just did the same

<pomel0>note to self don't enable home-niri-service-type if you have gnome in your config.scm file

<char>oh? I dont have gnome, but I have lxqt. does that somehow disable niri?

<pomel0>no I don't think so. In my case it broke everything lol, I tried login in gdm and it just looped back to gdm

<identity>char: the home service is supposed to start niri when you log in from a tty, not make you able to log in at the gdm (how would it do that, anyway?)

<pomel0>identity: oh that makes sense! because when I say gdm was broken I logged in another tty and inmediately it opened niri. I understand that now

<pomel0>unrelated, but anyone knows the introduction for the codeberg guix git repository? to add to my channels

<pomel0>I can't find it anywhere

<pomel0>the manual says that for the main channel, I get that information automatically from my Guix installation. But I changed the guix channel from savannah to codeberg, so I don't have that information anymore

<pomel0>unless it's in %default-channels? in which case idk how to print what %default-channels has

<kjartanoli>pomel0: It should be the same introduction. The only thing that changes is the repository url.

<pomel0>how do I check the %default-channels 'guix introduction

<kjartanoli>You can also always `guix describe --format=channels`

<pomel0>...or is there a better way to change the url in %default-channels to codeberg?

<pomel0>kjartanoli: doing that command doesn't give me the introduction, just what I already typed into ~/.config/guix/channels.scm

<kjartanoli>It prints them for me, but then that probably means that my channels.scm has them.

<kjartanoli>I thought running `guix pull` after the switch to Codeberg should have updated %default-channels automatically.

<kjartanoli>This is what I have for the guix channel: https://paste.debian.net/1403719/

<pomel0>probably my fault since I changed the channel before I did the first `guix pull`

<pomel0>it's just that savannah was so slow for me it'd have taken me hours, so I changed to codeberg manually

<kjartanoli>That would explain it.

<pomel0>using the introduction in yor channels.scm worked, thanks

<kjartanoli>Glad I could help.

<char>identity: that does makse sense. what am I missing without having gdm then?

<char>identity: I think if niri makes a .desktop file gdm should pick it up.

<identity>char: i doubt you are missing much without gdm (apart from mutter in your system profile, ha), gdm would not pick up a .desktop file from your home configuration because it only looks for the system-wide .desktop files

<char>okay. also how can I get rid of gdm? I dont see it in my services. It must be in %desktop-services.

<identity>do the GNOME people have any plans on making GDM not fail spectacularly without a desktop file? like, an error message at least, come on

<identity>char: right, you need to use ‘modify-services’ for that

<flurando>I don't understand, you want to use GDM without an available .desktop file to introduce any desktop environment

<meaty>niri has a .desktop file though?

<meaty>the issue is that home-niri-service borks GDM launching the session

<identity>flurando: imagine if it said «there is no .desktop file» instead of showing you a grey screen for a moment and then showing back up for non-obvious reasons

<meaty>you have to log in from a vt

<meaty>I'm working on a patch to make the service useful

<flurando>sounds like a problem of home-niri-service

<meaty>note that the service also makes logging in to a bare terminal difficult

<meaty>because niri starts with the home shepherd and you get logged out when you kill it

<identity>flurando: grey-screen-and-back-to-gdm is just gdm, though

<char>why not have have a nonhome niri service? would it break screensharing?

<meaty>what should have been done is have it just write a config and leave session management to the session manager, like the sway service does

<identity>meaty: what do you mean «you get logged out when you kill it»? you can just herd disable niri and exit as normal?

<meaty>identity: oh, I hadn't considered that :p

<flurando>Actually only default Gnome works to an acceptable here in Guix. Other stuffs are hard to get working even on debian.

<meaty>one day I will finish my pcsx2 patch... one day

<flurando>char: By "screen sharing", I don't even know screen sharing / screen recording works on Wayland, or do they?

<meaty>flurando: you mean in general? it's implemented

<flurando>meaty: Nice to here that. I used to think that is impossible on Wayland, except some api for "gnome-screenshot" to take a picture :)

<char>I got rid of gdm and was thus greeted with the terminal. I login, but no niri. what did I do wrong? Its in my guix home.

<meaty>char: is the home-niri-service still there and working? check with `herd status niri`

<char>meaty: its not there :0

<meaty>char: :0

<char>guix home reconfigure ... works, and I can see the home generations there.

<flurando>char: I suggest you to pick up some equivalence to gdm, mannually "startx" is pointless for personal laptops by hand.

<char>flurando: I am understanding that if I log into the terminal, then guix home will kick in and start niri (or whatever else). Right now, Im at the manually typeing the command step (and I dont like it)

<char>flurando: I also understand that nothing configured with guix home would be able to be picked up by gdm or any other display manager.

<identity>flurando: for the record, you do need startx or any of that stuff because your wayland compositor is also your display server, and if not it should figure that out by itself. just doing «exec sway» or such is enough

<flurando>char: is it possible to turn niri-service-type to the system profile? I guess you won't mind any random user on your guix system could use niri. Or at least extend the etc-service-type to include a systemwide niri confuguration (the .desktop file).

<identity>what would be the point?

<char>identity: to make it work. its not working right now at all.

<identity>char: your home profile needs reconfiguring, it seems

<char>well it does work if I type "niri" (I dont want to do that), but the home-niri-service isnt working.

<flurando>identity: In my view, if you are going to use Gui environment, of course its better to launch into it automatically, instead of typing "exec sway" or "startx" mannually after login.

<char>identity: I have configured it plenty. its only niri, dbus, pipewire, and base-services.

<identity>flurando: yes, but the home service does that without the need to mess with the system configuration

<flurando>char: Maybe niri-service-type has some dependency? Like some other service must be started before it?

<identity>char: so does niri not show up in «herd status»?

<identity>flurando: i highly doubt that

<char>identity: it doesn not.

<char>it does not

<identity>char: weird

<char>its only this: https://paste.debian.net/1403724/

<flurando>when you reconfigure home, guix should print out the log of respawned services, if niri does not even show up then, someone has to check niri-service-type source code.

<char>I left the imports out of the paste

<identity>there is no problem with the source code because i am currently typing this from my emacs running in niri using niri-service-type

<char>flurando: It doesnt talk about services. it only talks about symlinks and gexps

<char>identity: thats home-niri-service-type right :)

<identity>char: could you try just (home-environment (services (cons (service home-niri-service-type) %base-home-services))) and make sure that neither dbus nor pipewire show up in herd status?

<identity>yes, home-niri-service-type

<flurando>char: sorry, I checked, you are right, only shepherd service is mentioned...

<identity>and that pipewire and dbus show up in herd status if you leave them in, obviously

<char>do I need to reboot or logout for any of this?

<flurando>Maybe the problem is that you does not have any login manager

<identity>char: you should be unceremoneously thrusted into niri, though i guess trying that would not hurt

<identity>flurando: no, it really is not the problem here, the user shepherd is acting up

<char>"unceremoneously thrusted into niri" that did not happen, and there is no niri in the herd either

<identity>char: and pipewire?

<char>I commented out the pipewire and dbus, so those are no in there either

<identity>i guess the correct form here would be «thrust»

<identity>char: try logging out and back in, maybe this is happening because this is your first time using user shepherd services and some variables were not set or whatever

<flurando>I have an idea. You can copy and modify the source code of gnu/home/niri.scm and mannually add debug script inside ~(list #$(file-append bash "/bin/bash") "-l" "-c" "exec dbus-run-session niri --session")~

<char>identity: still nothing after logining in again

<flurando>I guess since you don't have a login manager, you failed to use "dbus-run-session" when shepherd in homeland tried? Anyway, add some output to file to see whether this shepherd extensionis executed or not.

<identity>char: i have no idea why this is happening, usually shepherd just works out of the box, i assume this somehow relates to your current configuration

<char>as in something in my operating-system?

<identity>flurando: if the service had failed to run, shepherd would say so, this is not it

<identity>char: perhaps, or something in your $HOME, like .bashrc and such

<flurando>identity: I am not so sure, this is shepherd, might include some unknown error. for example, change the command to "touch /tmp/niri-shepherd-called && exec dbus-run-session niri --session", then use the modified niri service in home config, reconfigure then herd status niri or a relogin.

<flurando>or just try to change the command to "niri", if as char says, directly run niri works.

<identity>if the service would fail to start if would show up in the service list, marked as «disabled», and it does not show up at all

<flurando>I just wonder it is not added to shepherd at all or it was ran but somehow erased from the list

<identity>why would it be erased from the list??

<flurando>I don't know, but there is not really much else to try.

<char>I got rid of my .bashrc, but it didnt help. I also dont see how anything in bashrc would stop guix home from registering services.

<flurando>Please try modify niri service as I said, I am so curious why this bug occurs and would definitely try myself if I am not using gdm and Gnome, which makes me trying your config hard.

<identity>the service is not on the list because it does not *get* on the list, not because dbus-run-session is missing (it is not missing) or because it gets automagically removed from the service list (it does not get automagically removed from the service list)

<char>identity: how can I check that the dbus-run-session is not missing?

<flurando>identity: then why it does not "get" onto the list? I don't see any error in home-niri-service-type definition.

<char>flurando: I dont even know how to modify the niri service in the way that you say.

<identity>char: dbus-run-session --version

<identity>flurando: why would it make trying the configuration hard? just log out from GNOME, log in on tty1 and reconfigure with the niri service

<identity>not sure you even need to log out from GNOME

<flurando>char: do you know how to import modules in guile? If you do, you just need to copy the gnu/home/niri.scm, then edit on an pasted file. Later import your edited module and use your home-niri-service-type instead of the official one. (you can use :prefix custom- when importing so that you just use custom-home-niri-srvice-type)

<char>does home use the same shepherd as nonhome guix?

<flurando>same binary by default, but not run as the same user

<flurando>I guessed...

<char>flurando: cool. I may try it. oh, so should I not be running sudo herd status niri?

<identity>they are not the same binary, for now

<char>we are getting somewhere now. I see the services.

<identity>they also run in separato processes

<char>(failed tho)

<identity>s/separato/separate/

<identity>(for now)

<flurando>identity: Well, I also have to make a custom system profile and create a new user in it. Mine has a lot env modified.

<identity>flurando: why would you need a custom system profile?

<flurando>identity: I use gdm, bro. char does not, this is different.

<identity>do not fucking ‹bro› me

<identity>this is also does not make the situation different

<flurando>identity: sorry, I didn't know that is rude

<char>flurando: with gdm, you can still log into terminal with control+alt+f3

<identity>flurando: 1. do not be overly friendly with people online; 2. do not assume all people online are men; 3. do not call women ‹bro›

<flurando>char: The main point here is I think the problem is you do not have anything like gdm, which I think is important for automated launch of desktop environment (as the only tested on Guix is Gnome...)

<flurando>identity: Thanks for noting, I have taken your words down. Sorry :(

<flurando>identity: wasn't meaning to regard everyone as man, just using the word as something like "yo" or "hey".

<identity>bro(ther) is obviously gendered, so try to use a word that is not next time unless you know the other gender of the person you are talking to

<identity>anyways, i do not have gdm, or any other display manager for that matter, and the home-niri-service works like a swiss clock. the only thing it does is set some environment variables and exec niri (via dbus-run-session), you do not need gdm for that

<flurando>char: I only have time to try the method 9 hours later, if then your niri still fail to run or just running under root user even when you only defined it in home!

<flurando>identity: Good to know that, I would try what I say later, if char is still bothered by the issure then. However, I wonder what would help if just using (service home-niri-service-type) also runs well on my device, so maybe a better way is to let char somehow examine the failure log of niri-service (as he said earlier, saw the service with a failed-to-run status)

<flurando>The bad news is, I myself don't know how to check shepherd log about failed service... So not much to help.

<identity>oh, i missed that the services showed up as failed. the issue should be easier to debug now

<flurando>how, curious about how to check shepherd service log on Guix

<identity>herd status niri should show the logs for the niri service

<flurando>well, I know this, but herd status does not print the full log, and only several lines at most when shepherd thinks the message is important.

<identity>«herd status niri -n 50» prints the last 50 messages, -n 100 prints the last 100, etc.

<flurando>True, I have never got to know this!

<flurando>char: check identity 's words. I am logging out.

<char>identity: The only message is "Process exited with code 101." which I think means a rust panic. I dont know if rust panics are mean to have more knowledge with them or not.

<char>dbus and pipewire seems to be running without any hitches

<meaty>char: Do you have another niri process already running?

<char>yes ... I can try without it.

<meaty>that'll do it I'm pretty sure, sessions try to be exclusive

<char>meaty: That did it! Thanks everyone for the help.

<flurando>meaty mvp :)

<meaty>I try :)

<meaty>in other niri service news I am making good progress on my scheme->kdl library so the service can do something more helpful than make confusing situations

<char>I saw someone was already configuring niri fully with scheme.

<meaty>char: yes, SSS. they beat me to the punch, but this is a generic library so we can configure other kdl stuff too (at least, that is my pitch)

<char>that sounds better to me.

<char>I will likely keep using the KDL tho.

<pomel0>does anyone here use dwl-guile btw? I want to try that out

<meaty>pomel0: wow, that's cool

<meaty>not even packaged yet

<meaty>oh wait :p there's a service

<pomel0>yeah but seems like the project is not active anymore :/

<apteryx>ieure: hello! I was trying to strace icecat to see which library it can't access for facebook videos missing audio, and I don't see something standing out so far; would you have ideas? I suspect the patch in librewolf giving it access to the whole of /gnu must be the reason it works there, but I'd like to find a more precise solution, if possible.

<trev>sigh...i think i asked this before: i have a custom emacs package and i want to install the doc output with it, but using (specification->package+output "emacs-next-next-pgtk:doc") doesn't work. Using `guix shell emacs-next-next-pgtk:doc` works for some reason. What am I missing here?

<flurando>trev: you called the procedure in a wrong way. check this: (specification->package+output spec #:optional (output "out"))

<flurando>so you should use (specification->package+output "emacs-next-next-pgtk" "doc") instead of trying to refer to a package called "emacs-next-next-pgtk:doc"

<trev>flurando: thanks. why does `(specification->package+output "git:send-email")` seem to work then?

<trev>(specification->package+output "emacs-next-next-pgtk") crashes the REPL for me :D

<trev>ah nevermind

<trev>the repl is being really naughty

<flurando>trev: here, "git:send-email" and "git" "send-email" has same effect. So it is not the problem and specification->package+output actually allows using : inside spec! However I don't even have emacs-next-next-pgtk, so could not debug with you

<trev>it's just an inherited emacs-next-pgtk

<flurando>trev: https://paste.debian.net/1403757 I tried in guix repl, it worked...

<trev>flurando: yes, emacs-next-pgtk works, but my locally defined package does not (in my personal guix config)

<trev>of course load-path is set correctly to include these configs, so I can actually see the package itself

<flurando>strange, if your guix shell can find the correct one, why couldn't specification->package+output ? I wonder if specification->package+output could find "emacs-next-next-pgtk" at all? Maybe you can just let it pick the default output and see what happens.

<trev>no, specification->package+output crashes when I call it with emacs-next-next-pgtk!

<trev>most likely cause the package cannot be found using `find-packages-by-name'

<flurando>THat is exactly the case when I customize packages! By default (gnu packages) won't check your defined load-path at all

<trev>makes me cry

<trev>guess i need to move everything to a channel

<flurando>no, you don't need to, just import and use the package in manifest

<clone>Hi, is there a way to use a gnome from an inferior in a system configuration? (I want to avoid ever having my extensions break unexpectedly). I tried this obvious seeming way but I got the described error: https://paste.debian.net/1403760/. Thanks

<flurando>there is but very hard and complex

<flurando>because gnome desktop service is now composed of 4 core services listing out a bunch of dependencied

<flurando>they are core services, extra packages, shell and utilities, and you would have to change the stuff there

<flurando>I customized some apps comes with gnome, but personally I have not tried to pin the gnome desktop version because I once met the same error as yours.

<clone>I see

<trev>flurando: but i want to install the package in my guix home :\

<trev>it works without specification->package+output, but i want to install the "doc" output as well

<clone>could you just put emacs-next-next-pgtk (list emacs-next-next-pgtk "doc")? even if it's a bit more ugly

<trev>clone: yes, i actually just figured that out before you wrote it!! thank you!

<trev>no clue why that works though

<clone>the (list package-variable "output-name") is how you get outputs from package variables in most cases as far as i can tell

<trev>yeah i guess it accepts many types of items and that's just one of them

<futurile>Morning all - happy Friday!

<Rutherther>morning

<trev>happy friYAY

<user_oreloznog>Morning guix!

<efraim>o/

<kestrelwx>Hi!

<ekaitz>efraim: Hi!

<efraim>at the reproducible-builds summit, lots of fun stuff. on to the hacking days

<efraim>I'm flexing my python, getting reprotest up to date. it builds packages multiple times with varying some environment variables to see how reproducible packages are

<efraim>it hasn't seen real love in several years

<futurile>nice!

<anemofilia>Is there any good reason to have the ~/.guix-home symlink when the exact same information can be found under /var/guix/profiles/per-user/USER/guix-home?

<ekaitz>efraim: did you talk with jab about power?

<ekaitz>ACTION clarifies: power ISA

<futurile>anemofilia: sorry, you asked this a while - are you familiar with how .guix-profile works with generations?

<anemofilia>Yes, I am

<futurile>anemofilia: same idea AFAIK, it's linking to the 'per generation'

<anemofilia>futurile: Sure, but the same holds for their correspondents under /var/guix-profiles/per-user/USER

<anemofilia>As I don't manage any packages with guix install I can't point right now which one is the correspondent to ~USER/.guix-profile, but IIRC there is one

<anemofilia>Should be easy to verify too

<futurile>Guess I don't understand what the question is :-)

<anemofilia>I mean, if we could simply refer to /var/guix/profiles/per-user/USER/something everytime we need to access it, why poluting the user directory with dotfiles?

<anemofilia>If I remember correctly, a couple years ago when people were discussing about having multiple home profiles, instead of a single home profile, they also discussed the possibility of choosing where this profile would be placed. Which seems very reasonable to me, even with a single home profile

<anemofilia>If it were to be placed into some place inside $HOME, I would rather place it under $XDG_STATE_HOME

<futurile>I think "polluting" is probably a bit of a new idea that people have these days, having a start-up file that's called ~./guix-profile used to be pretty common practise

<futurile>yeah - exactly you just wrote the thing about XDG_STATE_HOME - that's 'new' as-in it's from xdg which outside of Linux is less a thing

<futurile>I personally don't use profiles a lot - but yeah, the manual talks about using them a bit - I use guix shell

<futurile>I guess you could put aliases into your .bashrc (or whatever) so that all your guix commands did `guix --profile=$XDG_STATE_HOME/.guix-profile` or something - if it's annoying for you

<anemofilia>I do know it's a very minor "problem", I just wanted to know if there's some particular reason for the choice

<anemofilia>futurile: I don't use guix install, so I don't even have a $HOME/.guix-profile. Your suggestion doesn't work with guix-home though

<futurile>yeah, it's an interesting question - I don't know - I guess you could try search guix-devel

<futurile>it's probably one of those things that you would use XDG_HOME/blah these days

<anemofilia>futurile: I looked for it on guix devel, but couldn't find anything very elucidating

<yelninei>Hi janneke, I added the update to 20251029 to my wip pr, still trying to figure out the sigfpe issue

<janneke>yelninei: very nice

<yelninei>also I am still a bit confused with the shell replacement issue when the execve fails but maybe we can ignore it for now and prioritize the update (assuming no other regressions)

<jlicht>it seems the ip_tables kernel module is nowhere to be found in our linux-libre@6.17 package. Is $TODAY the day I have to learn how kernel configuration works ;)?

<trev>jlicht: seriously easier than learning guix configuration

<pomel0>hi everyone

<kestrelwx>Hello!

<pomel0>how's it going :]

<pomel0>i'm on to the next step of my guix journey, changing gnome for a wm

<ekaitz>pomel0: i did that some time ago, which wm?

<pomel0>trying to get sway to work

<pomel0>idk why it isn't listed in gdm

<ekaitz>pomel0: https://git.elenq.tech/guix-configuration/tree/desktop.scm here you have the evolution of my desktop, i moved from gnome to i3 a while ago so you probably can see what I changed there

<Rutherther>pomel0: how did you install sway?

<janneke>yelninei: hehe :)

<pomel0>Rutherther: trying out the home service

<characteristic>pomel0: if sway is not in your system profile, GDM will be unable to see the .desktop file

<Rutherther>pomel0: gdm is not capable of seeing your home, it uses the system profile, the system packages to get the desktop files for sessions

<Rutherther>if you wanted it to see sway directly, you would have to install sway by putting it to packages in your operating-system

<characteristic>you can just login from a tty and start sway normally if you would prefer not to put sway in your system profile, with some hiccups (not sure if sway deals with dbus and environment variables by itself or not)

<pomel0>characteristic: yeah the problem with that is idk how to disable gdm, I'm guessing I need to modify %desktop-services?

<characteristic>pomel0: yes, with ‘modify-services’. you do not have to disable gdm to log in from a tty, for the record

<cdegroot>jlicht: switch to nftables. There's Guix support for that.

<jlicht>cdegroot: that's what I'm currently looking into, but thanks for the pointer. It actually looks sane so far :-)

<cdegroot>Yeah, it's much nicer than iptables. Although I'm itching to write a Guile wrapper around that curly brace stuff :-)

<cdegroot>(One thing I like about Nix is that most services have a config item that says "open the firewall for me" and then that all gets merged into one generated nftables config. I'm bogged down with other work but it's very high on my list to figure out how Guix can do the same)

<yelninei>ACTION found the patch that fixes the problem

<pomel0>ah! I have sway-bar now!

<pomel0>I wonder why the default sway home service configuration doesn't add a bar

<characteristic>pomel0: but do you *need* a bar?

<pomel0>I like looking at the hour I think

<pomel0>hmmm, what do I need to do exactly to not have gdm enabled?

<ieure>pomel0, (modify-services %desktop-services (delete gdm-service-type))

<pomel0>I did that

<pomel0>still shows up gdm when I boot up :/

<ieure>And `sudo guix system reconfigure', and reboot.

<Rutherther>pomel0: are you using set-xorg-configuration then?

<pomel0>ahh I am

<pomel0>well I guess since I'm using sway I can just delete that

<ieure>Yeah.

<g_bor>Hello

<g_bor>sneek: botsnack!

<sneek>:)

<pomel0>oh I had this question the first moment I started using guix. is there an option in the guix command to remove obsolete dependencies?

<pomel0>or does it do that automatically after `guix remove package`

<kjartanoli>Remove them from your hard drive or remove them from your profile?

<pomel0>from my hard drive

<kjartanoli>guix gc

<pomel0>thanks!

<g_bor>I am trying to reach out to Timothy Sample

<g_bor>Any chance they show up here?

<kjartanoli>One thing to note is that guix gc will only delete things that are not referenced by any profile. So you may need to delete the older generations of your profile first.

<pomel0>oh I see

<pomel0>I'll look in the manual how to do that

<kjartanoli>I am looking at the manual now. `guix gc --delete-generations=1w` will delete all generations older than a week and then collect garbage. guix home, guix system, and guix package also have the --delete-generations flag.

<ieure>kjartanoli, home and system use delete-generations N, pull uses --delete-generations=N.

<ieure>The various Guix CLI tools are very inconsistent, even internally.

<kjartanoli>Right, thanks for the correction. It's been a while since I had to run any of them.

<Rutherther>I am reasonably confident all the cli tools support removing older than a specified duration, so --delete-generations=1w will work with all gc, pull, home, system & package

<kjartanoli>At least according to --help ieure is right that home and system have it as a command not a flag, i.e. its delete-generations without the --.

<Rutherther>yes, it's a subcommand for them, what I meant is the values it accepts. It does accept 1w etc.

<ieure>Yes, the values it accepts are the same whether it's an option or argument. Should see if I can hack up support for "-2" type expressions (keep the last two generations, delete the rest). That's generally what I do, keep 1-2 known good working generations and delete the rest.

<Rutherther>I think that should be possible to do, yeah. Also would appreciate that instead of the duration that is just approximately doing that for me, but I still use it out of convenience

<ieure>Yeah, I usually list generations and delete 1..(current minus two). But shouldn't be too bad to add explicit support.

<pomel0>changing sway-menu for wofi, as it recognizes my flatpak directory

<pomel0>oh

<pomel0>`guix home reconfigure src/guix-config/home-configuration.scm` is giving me an error building sway-config :/

<pomel0>oh weird, it is actually failing because of my config

<pomel0>I'm trying to change the menu from sway-menu to wofi doing `(variables (append '((menu . ,(file-append wofi "/bin/wofi"))) %sway-default-variables))`

<pomel0>but doing that guix home reconfigure fails

<characteristic>pomel0: you need to replace the menu, not add a new one

<characteristic>otherwise you end up with two names

<pomel0>ohhhhhhh

<characteristic>two menus, i mean

<pomel0>so I should modify %sway-default-variables

<pomel0>well I couldn't figure out how to edit %sway-default-variables so I just added the variables it sets (there aren't that many) to my guix home config

<acrow`>ACTION waves at vagrant

<vagrantc>ACTION waves in kind

<mubarak>Hi o/

<mubarak>A week ago I installed guix latest with kde plasma. I noticed that guix in the three steps(guix system init /mnt/config.scm, guix pull, and guix reconfigure) download the same packages for the hole system again and again. These packages are first installed when installed the system. And when updating the system by running guix pull, it should only

<mubarak>update new packages if its available.

<mubarak>in my country the internet is expensive, I purchased 10G and consumed by installing only the system and updating it.

<ieure>mubarak, It doesn't redownload the same things, the local store is always used if the package is there.

<ieure>mubarak, Guix (and Nix, which it's based on) rebuild packages any time its inputs (roughly: dependencies) change. So packages rebuild more frequently than on other distributions, and that's what you're seeing -- downloading new builds of the same upstream version.

<mubarak>ieure, I noticed curl package and many packages gets downloaded 2 or 3 times with the same version number

<Rutherther>that the version number is the same doesn't matter, what matters is that the hash isn't the same - they are different packages

<Rutherther>yes, guix is storage expensive, because of its functional nature. So if your download traffic is limited you might want to use something else than guix

<mubarak>Rutherther, What I meant is guix should check exsiting packages first before re-downloading it again.

<ieure>mubarak, Again, it is not redownloading anything.

<Rutherther>it does and it did. It found out you don't have them

<luca>Hi, could someone take a look at my PR? https://codeberg.org/guix/guix/pulls/3331

<mubarak>The last time I did the 10G that I purchased ended before I install icecat, gcc and some packages

<ieure>mubarak, As Rutherer mentioned, Guix needs more storage (hence, more bandwidth) than other distros. If you have limited bandwidth, something like Debian may be a better fit for you. You can also run Guix on top of other Linux distros if you want some of the experience.

<trev>mubarak: if your adamant about guix, you could make a more minimal system config (don't use gnome or a DE)

<trev>s/your/you're

<vagrantc>guix is very disk (and bandwidth) intensive

<ieure>I believe I've also heard of people running Guix completely offline and updating via sneakernet -- using `guix archive' to copy store items from a networked machine to a USB disk, then physically moving that to the offline machine, importing, and updating.

<mubarak>trev I could use a window enviroment. I was hoping it will change it the future

<ieure>mubarak, You're hoping the bandwidth-intensive nature of Guix will change in the future?

<mubarak>:) Yes. I hope so

<kestrelwx>If you were on a really beefy machine and were limited by bandwidth, you could build from source without substitutes, probably.

<luca>Honestly downloading source code for all dependencies is probably more intensive

<ieure>kestrelwx, Depends a lot on the package. The NAR for the Firefoxen web browsers is <100mb, but the source tarball is >500mb.

<ieure>mubarak, I think it's probably not very likely. The only real leverage for doing that is optimizing bytes over the wire by binary diffing what you have vs. what the substitute servers have. Accomplishing that would be a very substantial effort.

<ieure>I'm not sure how practical it actually is.

<kestrelwx>But would source derivations change as much?

<Rutherther>also you will need more packages, to be able to build the packages in the first place. With substitutes you get only the dependencies actually needed for runtime

<kestrelwx>I guess it really isn't guaranteed source would be less, yeah.

<rly>kestrelwx: even if the source derivations change less often, every time they do change it's a full redownload instead of an incremental git pull so it would probably still be infeasible

<vagrantc>or if guix gets together a team of folks to maintain a stable branch with fewer updates ... but that would require a team of people on a project already lacking that sort of people energy

<luca>tbh if you are network constrained alpine may be a good choice. They split their packages to be really minimal

<vagrantc>i have often wondered if a git cache wouldn't really serve guix well... so that all those git clone/fetch/etc. operations from guix-daemon would only have to pull any given update once across the network

<vagrantc>at the expense of more space storage, perhaps ...

<luca>git cache for guix.git or cache for sources of packages that guix needs to build?

<vagrantc>but the git clone -> toss out history -> source checkout in /gnu/store

<ieure>vagrantc, Yeah, a stable branch would help this a lot, assuming we have enough people to manage it. Running Guix feels a lot like running Debian sid.

<vagrantc>seems kind of sloppy

<ieure>Only affects builds though, right? Not downloading substitutes.

<Rutherther>vagrantc: we already do have a git cache, so it would just be a matter of using it for the git-fetch

<vagrantc>Rutherther: how's that?

<Rutherther>see the cache in ~/.cache/guix/checkouts that's used for transformations and for channel checkouts

<vagrantc>i mean, i always "git pull --url=/home/vagrant/src/guix" and manually update my local checkout, so i don't have to download things multiple times

<vagrantc>Rutherther: ah, true!

<vagrantc>but ... i think that is only client-side ... extending that to work and interoperate from guix-daemon seems like something else

<Rutherther>why would you want to make it interoperate from guix-daemon? That seems unnecessarily complicated to me, you can just do it before you hand it off to the daemo

<mubarak>luca, alpine looks good. I can't say I have a powerfull laptop, but it's good HP with core i3, 4G RAM, 500GB HDD.

<vagrantc>Rutherther: perhaps just a lack opf understanding how all the parts fit together

<mubarak>luca, you've heard of Sudan? we are at war for 3 years, and it still going.

<luca>Yeah. It's really sad

<mubarak>in the past I was connected to the internet 24/7. Now I can bearly connect to the internet for day or two in the mounth

<luca>Right now Tanzania has also lost internet right after their election https://mastodon.social/@netblocks/115469839118951826

<Rutherther>the daemon doesn't even understand git, it just does the instructions from git-fetch, making the daemon cache would mean making new operations for fetching through git etc. so that the daemon knows how to use git. But at that point, how would the daemon even know what git version to use for example

<Rutherther>and currently it tries to fetch only the one given commit, so I am unsure how much caching would help. At least assuming that most services allow you to shallow fetch a given commit

<vagrantc>i suspect there are a fair number of services that do not work with shallow fetching, and i suspect caching locally would still even help with a shallow fetch

<char>hello. Im back with more guix home troubles. when I log into a freshly booted computer, the home shepherd isnt running. If I run a home reconfigure, everything work until the next reboot.

<ieure>char, You likely removed one of the services which pulled in home-shepherd-service-type. Try adding that to your service list.

<Rutherther>char: how are you managing your login shell profile file? what are you using to log in?

<char>ieure: I already have the home-shepherd-service-type (no configurations).

<char>Rutherther: Im logging into the terminal.

<Rutherther>then "login" I suppose and that one should run your shell as a login shell, so the profile file should be executed. So that's good

<pomel0>hi, back from trying out the sway home services

<pomel0>I managed to get everything working the way I want it, but I'm having a weird problem with swaylock, where I can't unlock it even if I type my password right

<pomel0>really I have no idea what to do here other than disable swaylock, because it's not like there is a config for swaylock, I don't think

<pomel0>and even then, what should I config to make my password work with swaylock? (which is the defaul behaviour anyways and is just not working for some reason)

<luca>Did you use screen-locker-service-type? https://guix.gnu.org/manual/devel/en/html_node/X-Window.html#index-screen_002dlocker_002dservice_002dtype

<Deltafire>anyone know the eta of python-branch merge?

<pomel0>luca: No I didn't, I'm trying out what the manual says there now

<pomel0>just weird looking in the X Window entry for something made for wayland

<pomel0>well that seems to be configuring itself rn, I'll have to test later if it works ok

<pomel0>right now I have another question

IRC channel logs

2025-10-31.log