IRC channel logs
2025-10-29.log
back to list of logs
<ekaitz>csantosb: what's going on with our business? is it stuck? <lfam>Is lists.gnu.org not loading in a web browser for anyone else? <ieure>bowdrill, Yes, Savannah is awful, the repo has moved to Codeberg. <bowdrill>ieure: ok, the reference still mentiond the Savannah URL in section 22.1. Would it be helpful if I updated the URL in my first patch? <ieure>bowdrill, Genuinely have no idea what anything you just said means. What reference? Section 22.1 of what? What patch? Why would a patch change where you pull from anyway? <ElephantErgo>Hey everyone, I'll probably have more room to experiment once I'm back home in front of my Guix machine, but I've had a question rattling around in my head for the last couple of days that I wanted to float real quick <sneek>Welcome back ElephantErgo, you have 1 message! <sneek>ElephantErgo, gabber says: it worked just fine (resize the partition, then the fs) <ElephantErgo>So for the system image for the Pinebook Pro, it has a field that specifies the use of a system specific u-boot bootloader, but it points to a non-existent target. I notice that there isn't a separate partition for u-boot when I flash the image to an SD card. Where does the bootloader actually go when I run "guix system image pbp.scm"? <ElephantErgo>I'm wondering this towards writing a config file where I can run "guix system reconfigure" to install an updated OS profile, and having a cooperating bootloader. If it helps, I have TOW-Boot installed on the PBP's SPI chip, but I don't want to get too lost in the weeds of that hardware in particular if it isn't necessary <bdju>I still have that Sway freezing issue from a few months ago. Is there nothing I can do besides reboot? I can pkill -9 sway over ssh but then I can't start it again successfully from the TTY. Have the usual BUG... line in dmesg. https://0x0.st/K_bx.txt <bdju>Have been told it's not a Sway issue nor mpv issue, might be Intel iGPU driver issue, might be bad RAM. Why do I have to reboot, though? Is there nothing I can do/restart without rebooting to get the same effect? <ity>Where can I learn Emacs well? <futurile>zlqrvx: I think what you have is fine, or shorten it to cstanb's suggestion. There's no rule about how long your sentence should be. What matters is whether lilyp thinks it's sufficient since they are a committer <futurile>zlqrvx: so as them to review it again, and/or ask them for guidance on what they consider to be correct - given that they are looking after those files <futurile>zlqrvx: in general people don't explain their changes much in Guix. The "format" in the manual is about "what" changed and people tend to be (overly) picky about it - the normal bikeshedding of developers. In terms of "why" I personally do more than most, I do what cstantosb suggests, I put it as the second sentence of the commit. <futurile>zlqrvx: and if some reviewer doesn't like it, I remove it - because life is too short to be arguing over the formatting of stuff <futurile>zlqrvx: which is also why I put full stops at the end of bullets, and two spaces at the start of sentences, even though these are entirely made up styles that only Guix people use <futurile>zlqrvx: put your last sentence on a new line 3 <futurile>zlqrvx: lilyp will probably make you remove it, they prefer terse commits (I think), but it's not a _rule_ it's just taste <zlqrvx>futurile: as in right below `[arguments]: Add #:include`? <futurile>zlqrvx: no - so 1st line "gnu:xxxxx" all correct; then a line break (line 2); then your "why" sentence; then your whole detailed -> https://bpa.st/GSMA <futurile>zlqrvx: really the rules in the manual are all about the format of the first sentence, and then the format of the *gnu/packages/emacs-xyz line - and how to specify whether you're changing an argument or whatever <futurile>zlqrvx: and all the rules are basically there so that someone can easily grep the log <futurile>they're the rules of the project so I follow them; but I'm not on the pedentry side and think they're over-compilicated and a bit useless since all the info is in git log anyway <zlqrvx>futurile: ok that makes more sense now. Thanks for your help! <trev>does anyone have a clue why the workaround is needed here? it's the only way i can get certain flatpak apps to launch from gnome launcher: https://termbin.com/t1t6 <nmeum>easy to reproduce bug (segfault of nvi) with, imho, an obvious fix which can also be easily tested <futurile>nmeum: it looks like Z572 committed the original PR that Janneke did, I would ask them - you can request they review <futurile>nmeum: did Debian drop nvi from their installation image then? you reference its unmaintained <futurile>nmeum: if nobody looks at it I can add it to the 1.5.0 release board <nmeum>thanks for the feedback I requested a review from Z572. would be cool to add it to the 1.5.0 release board as nvi doesn't work on the framebuffer console in the installation media without this <nmeum>debian did not drop nvi but other distros (e.g. alpine) have dropped it. debian also has a gigantic patchset for it, not sure if we should backport their entire patchset or not <futurile>Interesting q, in general we don't have the resources to maintain big patch sets to upstreams (in my opinion), but we also tend to be quite conservative. <futurile>nmeum: you could probably make a suggestion on the PR for an alternative to use instead of nvi if you think there's a good option <futurile>now would be the time for us to make such a change to the installation <nmeum>I am not sure though if there is any well-maintained minimal vi package though, at least I am not aware of one. but I will think about it <futurile>ack ack - probably why nobody has tried to change it <ngz>emacs-use-package is deprecated (development now happens from within Emacs). How should we go about removing it? This is, AFAIU, not a use case for define-deprecated-package. <jlicht>ngz: don't they still make use-package releases separate from emacs releases? <neox>Hi there, I encounter crashes with Gnome Wayland on nouveau (Kepler) since mesa merge. It seems that gnome-shell segfaults on libgallium. I saw there is a bugfix targeting Kepler in mesa 25.2.5, so I'm wondering how I could test it? <Rutherther>neox: I mean that's quite hard. The most proper way would be to update the package properly, but that is quite a big rebuild. Another is using grafts, but at that point if you will be getting crashes it could also be due to some ABI incompatibility. Easiest is to do both of these is in a guix checkout locally and then pull from it <neox>I was afraid of that answer. <neox>Ok, it seems indeed the way to go <Rutherther>the first question is if mesa will build with just version change or if there will be more necessary, like bumping dependencies. For that you can just try "guix build mesa --with-version=mesa=25.2.5" (I am running it now) to check if something else will be necessary <neox>Thanks, I'll run it too now <neox>(I hope there is no dependency bump as it is advertized as a bugfix release) <Rutherther>yeah, it's good it's a bugfix release, because at that point you should even be fine with the graft <neox>Btw, I have few knowledge on that grafting system, is it automated or should I do something to trigger it? <trev>anyone notice ,build and other guix commands not showing up in `guix repl' anymore? <trev>hmm.. i could've sworn it worked without that <trev>ok that indeed works, thanks kestrelwx <kestrelwx>Could you try on an earlier commit? I haven't tried the REPL yet. <trev>i was recently on an earlier commit and did a pull then noticed it happening. Don't take my word for it, maybe I always imported (guix) <neox>Rutherther, it built perfectly <Rutherther>neox: I am not sure what you mean by that. grafting is not automated, the package that has a graft links to its graft, that's how grafts work, guix then sees what the graft is and uses that instead of the original package. You still need to link the original package to the graft yourself, mesa in this case <neox>Ah ok, I really don't understand how it works so I might need help x) <neox>So now, I'm using my local checkout and I'll update mesa version in the right scm file under gnu/packages right? <Rutherther>neox: the simplest you can do is copy the full mesa package definition right below it, name the symbol something like "mesa/fixed" and then in the original mesa package add field "(replacement mesa/fixed)" <neox>Rutherther, is there a reason not to use inherit there? <neox>should I also change the name to mesa/fixed or leave mesa? <Rutherther>you cannot change the name, grafts rely on the package's path being the same length <Rutherther>even changes in version always have to keep the length, ie if there was 25.2.10, you would have to use something like 25.2.x <neox>Ok I added my commit on top of current master. I'm going to pull from local repo <padtole>Hi, I am running out of heap space on i686 building guix-packages-base.drv . is this a common issue? the system has 3GB of ram and a huge swapfile, but it won't finish a guix pull <padtole>I'm still on the install cd, i've actually been trying to install guix for about a month, but i keep trying new things and learning they're not ready yet :) <jab>padtole: in my opinion guix is a little bit of a rich man's operating system. It works best on 4+ GB of ram and good internet speed. It IS super awesome! but other distributions (debian for instance) install packages MUCH faster. <kestrelwx>I've used Guix on a 4GB laptop for quite a bit. <jab>I actually uninstalled guix from my purism phone. Debian seemed to work 10x faster at installing packages than guix. Maybe guix will one day get a "prescheme". and that'll make it better. <padtole>jab: this is something i am thoroughly learning. i'm thinking small systems must mostly be cross targets. <kestrelwx>Yeah, I never had this issue, but this is x86_64. <jab>I actually am having trouble running # guix pull <jab>but it seems to be internet related. <jab> savannah seems to be really slow at the moment. <jab>I mean REALLY slow. I left "#guix pull" running yesterday. It got 80% done apparently, and then it didn't complete. <padtole>well i can finish the clone, this is indeed very slow but eventually finishes. the old savannah git repo is impossible, but the newer repos work. indexing is also slower every day as the repository grows. but the crashes happen in the package building <padtole>i'm curious if the git implementation is scheme-only, i'm continually impressed by so much functionality inside guile <padtole>i noticed each user and repo path makes a different .cache/guix/checkouts subdir so it's helpful to unify them when limited by time and resources using symlinks and/or git commands <jab>maybe I don't have nss-certs installed or something. <jab>Rutherther: thank. Trying that now. <jab>anybody have an idea how large guix.git is? 1GB ? 10GB ? <Rutherther>and the amount you download is closer to something like 400 MB <padtole>what i am doing now is putting my .cache/guix/checkouts folder on reusable media so i don't have to keep pulling <jab>I guess codeberg's rate limits their git download bandwidth, which makes sense with all the AI bots crawling the internet. <kestrelwx>Oh, I keep forgetting about the redirect failing. <Rutherther>exacly, as the page says you configure your channels in ~/.config/guix/channels.scm or /etc/guix/channels.scm for system-wide location <padtole>am i likely to be the only i686 user? if guix pull is not working on i686? <ngz>jlicht: no, upstream is archived. Development happens in Emacs only. So we’re providing an outdated release. <Rutherther>padtole: I doubt you would be the only, but it's right there aren't many. So it's possible something gets broken. What's the error? <jab>padtole: I bet you OpenBSD would work well on that device. They pride themselves on supporting really old hardware (and modern stuff too). <padtole>Rutherther: right now guix 156d81666 (recent master) fails to guix pull down to v1.4.0+154701.013cc1952a8 compiling base packages <padtole>Rutherther: errors include "GC Warning: Failed to expand heap by 8192 KiB" "GC Warning: Out of Memory! Heap size: 2608 MiB. Returning NULL!" "allocating JIT code buffer failed: Cannot allocate memory" <padtole>Rutherther: when i see those trailing up the screen i generally have maybe 5GiB of swap free and maybe 200MiB of RAM <Rutherther>on i686 I think apps can allocate only 4 GB at most due to the 32bit architecture, so I don't think it matters how much swap you have free. If a specific process needs more than 4 GB swap won't save you <padtole>that's my intuition too but the heap size is > 2^^31, so i was thinking maybe pinned memory or a kernel quirk, my disk is like 100KiB/s when thrashing for a long time <padtole>but yeah maybe i need to find a revision that works and bisect, maybe make a custom guix that has fewer modules to compile 0_0 <padtole>jab: i thought guix would make it nice and clear with multiple avenues to reproduce and examine bits of a system when bugs get confusing, but it does seem to really assume a powerful host system to kind of bootstrap that <pomel0>i tried guix on i686 once, but the lack of binary substitutes made it unviable for me <Rutherther>you shouldn't need to bootstrap when using substitutes, really, guix cannot be used very well on hosts that aren't as powerful, it's better to either substitute everything or to deploy <padtole>sorry by bootstrap i meant deploy i686 systems from x86_64 ones, not the guix bootstrap packages, wrong term <chipb>Rutherther: a healthy chunk of usermode process address space is still reserved for the kernel, so the limit is less still. either 2GiB or 3GiB depending on how the kernel configuration set the split. <Rutherther>chipb: Oh I didn't even mean to be specific on what part in the application space is occupied by the kernel or libraries etc. <padtole>it sounds like maybe i need more free ram for guile's heap and maybe things can succeed <padtole>hrm i actually have 2GiB total ram, this is likely not within any normal recommended specifications <chipb>the physical ram isn’t strictly the constraint if you’re willing to eat the cost of thrashing. <padtole>yeah it's discouraging it crashed when i have swap <padtole>but you mean that on a 32-bit system, even if you have 1GB of ram and 1TB of swap, mallocs will succeed only up to 2.8G or so? <chipb>a heap size of 2608 MiB *is* awfully close to the default 3GiB kernel split. the rest is probably accounted for in mmap()ed files and stack. <chipb>mallocs will succeed up to ~3GiB. <chipb>minus the other mapped pages. <andreas-e>padtole: 2GB of RAM should be enough. I am using Guix on a virtual machine with 2GB; indeed 1GB was not enough. And this is on x86_64; in 32 bit memory usage can only be a bit lower. <dariqq>padtole: You can build the guix pull files for i686 from x86_64 (with guix pull -p /tmp/somewhere -s i686-linux) which has a higher success rate. Also you can try disabling the guile jit which caused some miscompilations for me (see #74381) <andreas-e>At the same time, this is a headless machine; so maybe your user system and X11 and so on eat too much of the main memory? <padtole>andreas-e: i'm not using X11 but i am still on the install cd so this reduces the available ram. the problem could be with the address space on 32 bit as chipb mentioned, on x86_64 you can address more memory at once. it sounds like disabling the jit would be a good thing for me to try! <chipb>not being able to malloc() is *address* space exhaustion, not physical memory exhaustion. <andreas-e>I am confused; normally one installs, then boots into the new system, then does a "guix pull"? Why do you "guix pull" from the install medium? <padtole>oh the install was taking hours and hours so i started using the system before it was done; some packages i want are in future revisions. i'm moving more toward what you say now though <padtole>i guix pull'd master to use new packages, then i thought i'd install from that after the system crashed the next attempt, but packages were missing, so i downgraded, and then ran into the ram issue <jab>oh, guix should run on fedora, but fedora started using SELinux...is it possible to use Fedora Linux with SELinux enable & run guix ? Is anybody doing this ? <dariqq>padtole: if all things fail you can also compile and use guix from a checkout which is not as ram intensive as guix pull <padtole>thank you. i've now visited your linked issue and i see it documents my exact issue. thank you again. <neox>Rutherther, I just rebooted after reconfigure but it seems I still have libgallium-25.2.3 installed. Perhaps I have something else to configure in order to use mesa/fixed? <futurile>jab: there's a policy in the etc/guix-daemon.cil.in that you might be able to use <padtole>dariqq: another idea i had was running an x86_64 qemu guix somehow for issues like this, but ideally there'd be some way for the underlying data to be chunked <Rutherther>and when you reconfigured, did you see grafting lines with mesa? <Rutherther>anyone knows if it's possible to tell if a field of a guix record is thunked? <neox>ACTION is trying again without using inherit, to be sure <pomel0>I installed guix yesterday on my laptop, and I'm having trouble modifying kernel parameters in grub through config.scm. What I have doubts about is is it necessary to create a menu entry if I want to change kernel parameters or can I do so just from bootloader-configuration? <Rutherther>kestrelwx: no, guix's thunk fields have exactly one argument <Rutherther>also I would rather _know_ it's thunked field rather than guess by the number of arguments etc. <pomel0>specifically, I want to add nvme_core.default_ps_max_latency_us=0, so inside menu-entry I should have (linux-arguments '("nvme_core.default_ps_max_latency_us=0")) am I right? <Rutherther>pomel0: for modifying the arguments there is the kernel-arguments field in operating-system and yes that would be the value to set it to in case you want that argument <pomel0>ok that seems to have done it, thanks a lot <pomel0>i have to read up on the documentation i think <neox>Rutherther: indeed inherit made things not work, I just got a message about fingerprint not matching lol <neox>(I forgot to update that) <pomel0>is it normal that guix pull takes unbelievably long to receive objects the first time you run it? <ieure>pomel0, From an install of the 1.4.0 release? <ieure>Rutherther, I agree, horrible, lol <Phosphenius>Hey, I have a question regarding conflicting packages. I’m packaging an application as `app-bin` as I can only build the package from a binary tarball and not from source. <Phosphenius>Later I want to replace that package with just `app`, optionally there could also be a `app-native` which uses a different build mechanism. <Phosphenius>So I want all these variants, but they should conflict with each other. <Phosphenius>Can the `(replacement …)` be used for that? It seems to be tied into "grafts". <Rutherther>kestrelwx: no, it's just the name, I didn't use it afterall. the field-obj is obtained through accessor. I passed through the name, because it became apparent the procedure is going to match too much and I already got issues because of that, but afterall I solved them at different level <pomel0>ieure: ended up changing the channel to codeberg.org and the speed was much better <pomel0>however I need to find the channel introduction for authentification <jab>hello guix, I am running guix system. Can I get some help in how to make a /etc/channels.scm file such that "guix pull" pulls from codeburg? I don't want to have to keep typing in git pull --url=https://codeberg.org/guix/guix.git <ieure>jab, If you've pulled from Codeberg, the defaults should have been updated. If you're still pulling from Savannah, you have some configuration explicitly saying to do so. <andreas-e>jab: It is recommended to pull from git.guix.gnu.org - its DNS entry points to one of our machines, which redirects to Codeberg. <andreas-e>Is this not set up automatically? I do not think I have configured it anywhere. <Rutherther>it is, but jab is trying to prevent that one fetch & auth of the whole repo they will need to make when they switch from codeberg.org/guix/guix.git to git.savannah.gnu.org/guix.git <jab>I am not running guix system I am running guix on debian. <Rutherther>the default url has nothing to do with guix system <cluelessguixer>Are deprecation warnings when doing guix pull expected? Maybe a temporary thing? <ieure>Some stuff needs to get updated. <padtole>what are the cool, guixy ways people are doing common things like irc, email, guix issues, codeberg access, etc from the command line terminal? <sham1>Do you accept "emacs" as an answer <padtole>i suppose that's acceptable. gotta learn my chords <ekaitz>padtole: if you like other answers you can also do neomutt, weechat, vim...? <ieure>Emacs is great for IRC, fine for email, awful for web stuff. EWW used to be pretty useful for stuff like reference documentation, but a bunch of that is behind Anubis or other LLM scraper mitigation tools, which require JavaScript, which EWW doesn't support. <padtole>thanks. looks like issues are debbugs which has an interface in emacs and guile <ieure>padtole, Issues have moved to Codeberg. <ieure>padtole, There are still issues in Debbugs, but since the cutover, most are in Codeberg. <sham1>IIRC there was an Emacs interface for Forgejo repos <csantosb>In cli, we also have forgejo-cli in the repos <cluelessguixer>A lengthy system reconfigure later and holy moly I see the (oci defined) docker containers running! <slipening>Hey, there. I just moved over from NixOS to Guix a month ago, and I'm still having trouble setting-up pipewire. I'm wondering if anyone using Guix SD actually has a working pipewire setup that's as simple as adding the home service to your config, or if always requires messing with Pulse and Alsa. I've compared my own setup to David Wilson's setup <slipening>and the setup on RDE, and still haven't been able to get pipewire going. Any direction/insight would be greatly appreciated. <Rutherther>using pipewire home service doesn't mean 'not messing with pulse or alsa'. On the contrary, that service adds a config so that apps do not start pulseaudio server automatically. <Rutherther>and yes, pipewire started working for me after I added that service <slipening>Thanks, that's good to know. I really wasn't sure if it could be that simple. What DE or WM are you using? <sham1>Whenever I've added pipewire to my Guix Home setup, it has always just worked <slipening>K, I might try getting off of Gnome, then. That's probably complicating things. I used to use tiling WMs. <Rutherther>and you've checked the shepherd service has started and is not throwing errors? <Rutherther>(or rather all related services, it's not just one) <loquatdev>How would I go about appending text to /etc/hosts? I know about hosts-service-type, but I have a hosts file in text that I would like to append to /etc/hosts. I feel like there's a smart way to do it since I see `(extend append)` in hosts-service-type, but I'm not an expert on services. <loquatdev>Specifically, I'm trying to add one of the StevenBlack `hosts` files. <snamellit>loquatdev: I think that can be finagle to your use-case? <loquatdev>It could work, and I'm sure it would be a better solution in the future since it would allow using scheme to filter and modify the resulting objects, but it does feel a little excessive since all hosts-service-type does is re-serialize them into /etc/hosts. Would it be possible to replace the hosts-service-type with a custom service that just <Rutherther>loquatdev: sure you can just remove it out of essential-services of your operating-system and make your own service that extends ets-service-type with "hosts" file <Rutherther>loquatdev: see modify-services. But note that you cannot use any services that would extend hosts-service-type. I think that concerns only block-facebook-hosts-service-type, though <sham1>I feel that one could always just parse the extra hosts-file and then extend the service that way <sham1>It would compose better, even if the concern is that it's just roundtripping the data via scheme <cluelessguixer>What would be the equivalent of putting "--cap-add=CAP_PERFMON" to the docker command in the oci-container-configuration block? <sham1>(extra-arguments '("--cap-add=CAP_PERFMON")) <sham1>I.e. there is no thing there for setting capabilities <sham1>There probably should be, but yeah <cluelessguixer>sham1: I presume that'll work, thanks. Just gotta figure out how to configure Frigate properly now... <Guest8>Hello, sorry if this is the wrong place to ask but does anybody have any experience using the guix install script on immutable Fedora distros such as Fedora Silverblue? I'm sure I can manually jank things around a bit to get guix up and running, but using the official installer seems like a better idea if possible. The main problem is that the root <Guest8>directory of the system is not writable, so "/gnu" can't be created by the script. <Guest8>I just learned about guix a week ago and have been obsessing over trying it out 