IRC channel logs
2025-02-17.log
back to list of logs
<wakyct>wow Icedove uses a lot of RAM, 1 GB. Am I doing something wrong? <ieure>It's 2025, I wouldn't be surprised to find `ls(1)' needs 1gb of RAM now. <wakyct>if only I could read email with ls <wakyct>this is a fresh email and email account too, just a few messages over imap <ieure>I don't think you're doing anything wrong, I think most software is unbelievably bloated these days. <wakyct>from what I'm reading it typically only uses a few hundred though, this seems odd <ieure>Is the RSS 1gb? Lots of things that don't use actual RAM (like mmap, shared libraries, etc) can appear to increase the memory footprint of a program. <wakyct>I was just looking at task manager in xfce <ieure>wakyct, `ps -up $(pidof icedove)' <wakyct>thanks, yep that corroborates the task manager <wakyct>half of that after restart, I'll keep an eye on it <wakyct>I think I really mis-estimated how big a root partition I needed when I first installed. On a smaller disk (mine is 128, old laptop) what would be a good size for root? <wakyct>I have hardly anything in /home after six months <ieure>wakyct, GC can only delete store items that aren't referenced, you likely need to to `sudo guix system delete-generations 3m', which will prune any generations older than three months, then GC again. Pick whatever time range makes sense to you. <wakyct>thanks, yes I have been pruning but maybe not aggressively enough <wakyct>I also made a 4G swap which maybe was too generous, I have 8 GB of ram <ieure>You need to do the same for your user profile, or `guix home delete-generations' if you use Guix Home. <wakyct>that's probably part of the issue <ieure>Guix definitely needs more space than other distros, 256gb is about the smallest I'd recommend. <wakyct>so nice that reinstalling is less of a pain <wakyct>cool, got down to 65% on root from 90, thanks ieure <wakyct>deleting things on Guix is oddly satisfying <noob-cannot-boot>hi...me again...when i type commands the shell tells me that it can not be found. Look like only guix commands can be carried out... <ieure>noob-cannot-boot, Is your shell sourcing your Guix profile? <noob-cannot-boot>can i loose my profile through "guix gc" or "guix system delete-generations" ? <ieure>noob-cannot-boot, That shouldn't happen, but, without sitting in front of your computer, it's hard to tell what your problem is. <ieure>noob-cannot-boot, What do you get if you `echo $PATH'? There should be multiple entries pointing to your Guix profile. Do those locations exist? <noob-cannot-boot>true....user "/home/support/.guix-home/profile/bin:/home/support/.guix-home/profile/sbin:/run/privileged/bin:/home/support/.config/guix/current/bin:/home/support/.guix-profile/bin:/home/support/.guix-profile/sbin" <noob-cannot-boot>iff the locations exist i can not say as "ls" and all commands except "guix" do not work <ieure>noob-cannot-boot, `guix shell coreutils' should get you a working ls. <ieure>(until you exit that subshell) <ieure>You can also use tab completion in a terminal to see if a path exists, nonexistent paths won't complete. <apteryx>is there any benefit to compiling schemas and icon cache per package? <apteryx>I think these a typically disabled because they do not make sense outside of a profile (and we have hooks for these), right? <apteryx>hm, guix system reconfigure issues a fat WARNING because 'imported module (guix build utils) overrides core binding `delete' <apteryx>we should resolve this annoying problem once for all <noob-cannot-boot>just out of curiousity.... "guix shell coreutils" gave me ls and similar but not "ps" for example. Do i have to specigy something different then coreutils to fer them? <iyzsong>noob-cannot-boot: yes, procps have "ps", as `guix locate ps' reported. <iyzsong>apteryx: per-package caches allow run programs without install/profile, which shepherd services use them. And with program wrappers, it also avoid installing of gtk+ into the profile when you install a gtk+ based program. <apteryx>iyzsong: so should the best practice to let the packages build their iconbsand schemas? I see many packages using substitutes* to disable build targets. <iyzsong>apteryx: icon cache is optional, the build phase usually try to write to the read only hicolor dir, so need to disable them. gsettings schema is mandatory, and is generated in glib-or-gtk-build-system. <ieure>Huh, `guix shell' doesn't update $MANPATH? That's irksome. <podiki>ieure: it is a search path, needs the package i always forget, mandb? dbman? <ieure>podiki, Thanks. That's kind of surprising. <attila_lendvai>is anyone using cerbot successfully with multiple domains and webroots? <attila_lendvai>every time i look into why it doesn't work, it seems to me that the guix certbot service totally misunderstands what --webroot-path and --domain means to certbot. the 'webroot' field shouldn't be on the certbot-configuration, but one level down, on every certificate-configuration <mra>civodul: you may want to have a look at 55231 when you have the chance. i think that your questions have mostly been answered? <civodul>mra: thanks; i just saw lfam’s reply and i think i mostly agree <mra>civodul: yeah, I think that lfam's writeup makes a lot of sense. if we feel that the cost of preventing a hypothetical build farm from accidentally distributing a ZFS+Linux initrd is too great (although, as I mentioned, we could in principle restrict this cost to the construction of initrds by adding a parameter to `derivation`), then I think that the first two v6 patches sent by Maxim are entirely <efraim>hmm, `berg pull comment` is giving me a 429 error on civodul's practice guix repo <csantosb>efraim: remember there is also forgejo-cli <efraim>software heritage also got 429, looks like it might be related to their DOS <apteryx>would someone understand why virt-manager icon shows fine in the GNOME launcher (dash), but not in the app bar at the bottom? <orahcio>apteryx: Maybe the icon-theme, try to change it <apteryx>the thing is the icon shows correctly in the dash, is named correctly in the .desktop <apteryx>but the launched application as shown in the GNOME bottom application dock is the generic blue gear icon <apteryx>maybe because the binary is wrapped and its name is .virt-viewer-real <vhns>Does anyone here running foot also run into the issue of termcap not including it? I currently do the nasty thing of exporting TERM=xterm to workaround it. <iyzsong>vhns: $TERMINFO_DIRS should contain it, but only for users have foot installed. run tmux in it can workaround the issue, since tmux's termcap is in ncurses. <vhns>iyzsong: Yeah, I have foot installed through guix-home but I still run into the issueof TERMINFO_DIRS <vhns>for example, getting "WARNING: terminal is not fully functional" whenever running `guix search xyz <iyzsong>what's the value of $TERMINFO_DIRS, does it contains ~/.guix-home/profile/share/terminfo? <vhns>it's empty, from what I can tell <iyzsong>then does TERMINFO_DIRS in ~/.guix-home/profile/etc/profile ? <vhns>nope, not in there either :p <iyzsong>um, then lookup foot in ~/.guix-home/profile/manifest, does it contains a search-path for TERMINFO_DIRS? <vhns> but I do have it in my (packages) <iyzsong>run `which foot', it seems be elsewhere <vhns>foot is being pulled in as a dep for sway <vhns>but it isn't define explicitly in (packages) <vhns>iyzsong: that did the trick thanks <olndrxyz>Hi, is it possible to prevent Guix from creating the ~/.config/fontconfig/fonts.conf symlink or to define my own fonts.conf file with a Guix home service? <mra>to use guix home to generate a fonts.conf <olndrxyz>mra: yes, something similar but I'd like to define a local fonts.conf file. is there an example for that? <mra>ah, I'm not sure. sorry <freakingpenguin>Hey all, when I shut down my system shepherd starts containerd and virtlogd services. This didn't cause any issues before but lately Shepherd fails to shutdown because it waits for the processes to terminate. Anyone see something like this before? <freakingpenguin>My os is using the containerd/virtlog/libvirt/docker-service-types, but there's no customization with them. <dariqq>trying to configure the shepherd syslog and it feels very verbose to write out out a big if/else construct <simendsjo>freakingpenguin: I'm probably having the same issue. Haven't digged into it yet though. <mirai>sneek, later tell apteryx: Heya, I've got a swtpm package definition sitting here <dariqq>note to self: an error in the shepherd syslog message-destination is not a good idea and may cause boot failures <ieure>I'm doing reviewing Emacs-related patches today, if anyone has a neglected one they'd like eyes on, ping me. <dariqq>simendsjo freakingpenguin: is it the same as #76338? <freakingpenguin>dariqq: Sounds like it, both the services I named don't depend on user-processes. (or rngd-service-type for that matter). <freakingpenguin>Does it make sense for shepherd to respawn services that don't depend on user-processes during shutdown? <dariqq>shepherd just sees that a process quit unexpectedly (via SIGTERM/SIGKILL from user-processes) and restarts it <superkamiguru>Hello all, I was wondering if anyone had an idea of why gnome-disks isn't able to find mkfs.ext4 on a desktop install? I have it installed on my main pc, and I also tested a fresh install on my laptop, and both throw the same error when trying to format a drive as ext4 in gnome disks <podiki>presumably it needs mkfs to be an input and however gnome-disks tries to use have the path patched (e.g. if it tries /usr/bin/mkfs or searches PATH) <ieure>Yeah, that sounds right to me. <superkamiguru>Ah ok. So just a current issue with the package configuration for gnome-disks? <superkamiguru>Just was something that I had used before and was worried I had missed some new configuration I was supposed to be using <podiki>i mean i have mkfs.ext4 in my path (in sbin) but it complained about that too, so it must be trying to open/find it some other way <podiki>the gnome disks thing is mysterious: in a quick look I cannot find any reference in the source to "mkfs" <podiki>it must not call it directly but through something else <superkamiguru>Hmmmm interesting. Yeah I noticed that mkfs.ext4 is in my path as well, so im not quite sure why it can't find it especially if gnome-disks is launched from my shell <podiki>i think somewhere in src/libgdu/gduutils.c <podiki>ah that would make sense, it uses udisks <podiki>(though does check explicitly for vfat and ntfs support in the source) <podiki>yeah in the tests of udisks there is a lot of run_command with mkfs <podiki>and udisks does have a ref to e2fsprogs in guix size <mra>ieure: quite the patch review blitz! <ieure>mra, Emacs stuff is pretty straightforward to review. <mra>still, fewer patches waiting around for review is good work! <mra>phsw: it's been behind for a long time. it's still updating, it's just stuck behind <mra>at least as far as I'm aware. I looked a few days ago and it showed 5th Feb <Guest26>Is there any way to force guix import to output required depedencies? <gabber>Guest26: what are you trying to achieve, in the end? <Guest26>not having to rerun guix shell -f and look at output log to figure out what i am missing when importing package from elpa <dariqq>Guest26: some importers have a --recursive option <Guest26>that does not append use-modules it just figures out which package is missing from guix <Guest26>my annoyance is specifically with figuring out which use-modules to use <ieure>Huuuuuh, I sent an email with patch review this morning, and it opened a new bug? <ieure>How did the second bug get opened? <mra>oh, I also ran into a weird mailing list issue. it seems that the email indices for 55231 have been thrown off? I went to download the mbox file for the patch that Maxim sent a few days ago from issues.guix.gnu.org, and it downloaded a message 6 emails earlier in the chain <rekado>phsw: it does update, though. New emails do show up. They just don't appear in recent. <anticomputer>back on GNU Guix after a 5 year detour through NixOS, glad to be slinging parentheses again <phsw>rekado: oh right, only the panel "recent" does not update