IRC channel logs
2025-12-29.log
back to list of logs
<ieure>fmarl, guix-devel mailing list. <getstate>I'm struggling to start KDE (wayland) from GDM for some reason. It just crashes back to the login tty. <jact>Hi, I'm trying to create a Guix package for BaseX, a Java program, and am running into an issue with one of its Maven plugins that currently doesn have a Guix package. I tried to exclude it from the pom.xml using the :#exclude keyword, but it still complains that the input is not found. pastebin: https://pastebin.com/kyPCSh4Y <jact>the Maven extension in question is wagon-ssh-external. <ieure>jact, Remove the plugin from the pom.xml with a patch, snippet, or build phase. That plugin is used for copying release artifacts around, it's not something needed in this context. <jact>OK, thank you! I will give that a try. <getstate>When I try to start guix with KDE on wayland (added the plasma-desktop-service-type, from GDM), I get a crash and `run/user/1000/doc permission denied` <ieure>getstate, Hmm, I set up Plasma on a machine earlier today and had no issues logging in. Where are you seeing that message? <ieure>getstate, These are the permissions of that for me, FWIW: dr-x------ 2 ieure users 0 Dec 31 1969 /run/user/1000/doc/ <getstate>I get r-x------ as well, I'm actually unsure why it just crashes GDM, but that's all the logs gave me <ieure>Can you log into any other DE? <getstate>i3/hyprland works, just KDE on both xorg/wayland (xorg loads in, then freezes the whole computer) <jact>Getting another maven-related error. Trying to compile javacc-maven-plugin with guix. I am able to compile javacc itself, but not able to use it in a maven project. Even if provided as an input, it gives `no-such-input' with args `("net.java.dev.javacc" "javacc")' when trying to build the plugin. I suspect this is because javacc is compiled with ant, not maven, in the guix package. <apteryx>ACTION wonder what the purpose of commit 9a75c8ac135854f3380352b9dd3e653e6ff14614 is <sysbl1nk>I'm trying emacs IRC, never been in one of this rooms <efraim>apteryx: looks like that patch would benefit from a comment in the header. I'm guessing it's from upstream <apteryx>so I'd suggest either doing so, or dropping it, as there's little point diverging from upstream for cosmetics. <apteryx>yep, that's what upstream still uses, and no PR suggesting to rename that to LUANTI_GAME_PATH, yet <apteryx>so it may support that in the future instead of these old path variables. <efraim>that reminds me that I should see about writing a patch for dillo to use XDG directories <efraim>probably best to open an issue and tag lilyp and see why she added it and if it can be dropped <test202020>i trying install guix by manual on official website <identity>is it the latest manual or the one that is 50 (exaggerating) years old? <identity>because we have both up and default to the 50 years old one. <identity>stable is ancient, switch to the development one or read it locally (after you install, i guess?) <test202020>that for verify iso image by 15145 savannah user <identity>test202020: you can use either and then upgrade to latest <identity>1.4.0 has some bear traps set up, mind you. you will have to pull from codeberg manually the first time <test202020>because i am not found where i can download image without proxy <mannifred>Without systemd idk it all feels more buggy on guix <sneek>mannifred, you have 1 message! <sneek>mannifred, ieure says: I can't reproduce your KDE problem, windows move around just fine when I drag them by the titlebars. <identity>then it should do that without having to specify <mannifred>It seems like everything nowadays has to be systems centric <mannifred>When you try to run without systemd you will get problems <identity>people love when you can actually do stuff without closing your eyes and pointing somewhere and seeing if that works. that is what systemd gives them, basically <identity>it is also the most common init system, by a large margin <identity>if you do not count macos, but who counts that? <mannifred>identity few months back void Linux and alpine was still working nowadays they work but really rubbish <identity>maybe they should get a better init system :3 <identity>not necessarily, but something that is better than a bunch of shell scripts and duct tape <identity>systemd also provides much more than just PID 1 <mannifred>Well on guix I had some problems too similar to the problems on void <mannifred>Like not seeing my console output till I do type in my name and password and then spam enter key to make system react <identity>that seems like a hardware/firmware/whatever problem and not an init system problem <mannifred>How could it be one if it is on alpine void and guix? <identity>i mean, there are more differences between alpine/void/guix and nixos than just that <identity>yeah, apart from all the other differences <mannifred>So maybe no systemd has problem with Displayport <mannifred>Nah I don't have a logical explanation for this behavior <identity>maybe nixos is the only one of the four that properly configures DisplayPort on startup? <mannifred>Systemd starts a system service to fix the black screen and on no systemd the system does not react to keyboard input <mannifred>Identity well the older version of no systemd os still work <identity>smells like a kernel/drivers problem to me <mannifred>Like what if systemd code is inside the kernel <identity>this begins to sound like a conspiracy theory. Linux is not dependent on any init system <mannifred>Identity it would explain certain behaviors but I'm not a developer can't say much <identity>it would explain certain behaviours if it was true. if. <mannifred>Identity which Linuks distro would you take if you had to use systems <mannifred>Identity I just seen on nixos there was bugs in cosmic and on arch the bugs was patched out already <test202020>if now i choose one full disk for home and system how to difficult change that late? <identity>test202020: i would guess you would need to either wipe the disk or do some extremely dangerous live-patching <test202020>and why installer write to config services that i bot selected <identity>test202020: from what i know, Guix does not use LVM during the installation (you could do that manually, i guess?) <test202020>guix have mechanism for not break system while memory is small? <identity>test202020: what do you mean by that, exactly? <identity>this is probably a file system problem more than a Guix problem, as long as you run ‹guix gc› once in a while <mannifred>And then on a nixos which is an os with a rat as owner <test202020>exist way to change substitutes within running install? <identity>test202020: the installer should have prompted you for that, see (info "(guix) Invoking guix publish") <mannifred>Identity why does no systemd feel like less screen tearing ? <test202020>install try to connect ci guix but that blocked by hosting provider for my country and that make installing very slow <test202020>write_wait_fd unimplemented error broken install <mannifred>Identity which distro based on nixos would you take ? <test202020>where i can change defualt subtitude in installer? <test202020>installee not contain config.scm in source form? <csantosb>Godd morning Guix ! TIL about the black magic in `texlive-local-tree`, after one full day of failures to build a package <test202020>how i can change substitudes-urls for installer in live usb? <viaken>test202020: Re: Changing disk layout after install: No need to wipe the disk or live-patch. You can boot on a LiveUSB and move things around. <viaken>Speaking from exprience, the small disk risks are mimimal. Upgrades just fail when you run out, but they're atomic, so you're safer than most other distros that could be left in a broken state. <test202020>Now i not have problem with disk because i cannot install system <viaken>I'm still catching up on scrollback <test202020>mirrors choosing is slowly and i cannot change substitudes <viaken>I don't know anything about the mirror/substitute situation. <apteryx>test202020: what do you mean by you cannot change substitute? <apteryx>you have to ensure the daemon runs with --substitute-urls='your-url1 your-url2' <apteryx>can probably kill and restart it with the right arguments <apteryx>there's also GUIX_BUILD_OPTIONS you could set to '--substitute-urls=...', this may be enough <apteryx>make sure you export it before running your guix system init/reconfigure <apteryx>but yeah, from the graphical installer, not sure if you can get it picked up, as the installer process is already running so you can't change its environment; the guix-daemon restarting may be a better idea if you want to change substitute servers for the graphical installer <Rutherther>you need to stop it with "herd stop guix-daemon" <apteryx>you can hop to another pseudo-terminal with Alt-F3 or such <test202020>okey, process stopped but that anyware using default substitudes <apteryx>is sharing the user namespace the only way to ensure permissions for a writable directory are OK in a containerized process (using least-authority-wrapper ?) <apteryx>the problem I get if I don't is that it fails to create a directory in a place that should be writable for that user, because the user ID is not the same in the container I guess <test202020>pgrep -a guix-daemon showing my process with substitue mirror as argument, bht that not work <Rutherther>apteryx: I don't know much about that, but I thought there is a way to map users in a custom user namespace, so there would be no need to share the user namespace. Although maybe least authority wrapper does not have this implemented <apteryx>what happens ? Fetching from the usual places? <apteryx>Rutherther: yeah seem to remember that too; ah, there's guest-uid and guest-gid <apteryx>test202020: weird, are you sure there's no other daemon? Otherwise perhaps your urls are wrong or not authorized, in which case I guess it may fallback to its known-good servers <apteryx>Rutherther: looks like a way may be to specify #:user and #:group for least-authority-wrapper <apteryx>and leave these out of the encapsulating make-forkexec-constructor <Rutherther>test202020: what iso did you download? guix weather on 1.4.0 will always use the default substitute urls, no matter what the daemon has. <test202020>while i provide argument to guix weather that working, but not for daemon <apteryx>Rutherther: nevermind that's already what I was doing :-) <test202020>Rutherther: you mean try to run install with my deamon run with urls? <Rutherther>test202020: No. I mean that guix weather is not a good test on 1.4.0. Test with guix build. Or use new iso <apteryx>I guess I'll try specifying #:guest-uid and #:guest-gid as well... but that seems clunky <test202020>i waste more time to try install guix and i think no time for that for current <Rutherther>anyway I am not sure passing --substitute-urls will work, because the installer restarts the guix-daemon shepherd service before performing the installation. So that might do something wrong with your setup. Probably better to install manually, until support for changing substitute urls is added to the installer <Rutherther>but as long as at least one of the substitutes is working for you I don't understand why you would face any issues <test202020>in manual installation have way to change substitue? <Rutherther>test202020: all guix commands provide a way to supply substitutes, or you can change the substitutes of the guix-daemon if you didn't want to specify them on the cli over and over again. <test202020>sadly that guix not provide mirrors in installer depended on nefwork <ximon>I tried void totally ripped distro <Nimous>Hi. I have some questions about design decisions of Guix but I can't find answeres in the documentation. Why does guix pull an entire git repository and compile it into its own binary as package database? that is very inefficient if you ask me. Other package managers just use files as their database. Is there a plan to change the design and make the process of upgrading less cumbersome? <Rutherther>">why does it pull entire git repository" For authentication of the commits, to verify they are authentic. It is verified based on an introductory commit that is somewhere in the history <Rutherther>">why does it compile it into its own binary" there is no single binary. Rather, it compiles the individual scm files into invididual go files. Guix is source based. If you used the source itself, it would be very slow, so that's why it's compiled <Rutherther>As for why it's source based, that's some core values of Guix, that is how it can be functional, unlike other package managers that just have databases of packages and download the results <nimous>A database file can also be signed. Other package managers sign their repositories too <Rutherther>as said, Guix is source based, so you do have to sign the sources <gabber>nimous: yes, but do you know how the results come to be? <Rutherther>that is what the users interact with, the sources <gabber>signing something simply shifts trust to the one who signes, which is usually someone you don't know <nimous>if it is absolutely necessary to have the database compiled into guix binary, wouldn't it be more efficient to build the guix binary itself on the build farm and just download and replace the newer binary which has the newer database baked in? <nimous>this way the users don't need to pull the repo upon each update <Rutherther>1. there is no database, 2. that is exactly what happens, the build server does build it and most of it gets substituted, unless you pull too early after a commit has arrived <gabber>WDYM with "binary"? guix is written in Guile Scheme, and it comes in the form of scheme script (text) files <nimous>Rutherther: I installed Guix distro in a VM now and the info manual directed me to do a guix pull, which pulled the entire package definition repo. I am not talking about pulling the source of packages. I know there is substitutes for them. But "guix pull" clones the guix package repo. <nimous>gabber: Doesn't Guile support compilation? <Rutherther>right, that is for the authentication of the commits as I said earlier <Rutherther>Guile does support compilation for individual modules. The individual modules are compiled to go files. There is no *single* binary <gabber>nimous: yes, Guile is compiled(?)/transpiled(?)/converted to bytecode, but that happens when you use a scheme file for the first time, not for you on a foreign machine <Rutherther>gabber: during guix pull all the modules in all channels are compiled to .go objects beforehand. The compilation happens during that build, not when users first use them <nimous>rutherther: Yes I know. The manual mentions that guix checks for commits. But I think this process should happen on a server somewhere. This way you can just type "guix update/upgrade" and guix would just download a new version of itself and then update the installed packages accordingly. <identity>‹transpile› is the word you use instead of ‹compile› when you have no idea what you are talking about <Rutherther>nimous: wdym happen on a server? I don't understand. The process is to authenticate all the commits to check for authenticity. If you make a server that tells you yes it's authenticated, what's the point of the authentication at all? <identity>nimous: so somebody else should check that the signatures are correct? and then, what, sign the signature check? <identity>i think you mean «i did not mean to imply that» <identity>the point is, Guix already *does* the things you want it to do, Guile is just excruciatingly slow sometimes <identity>and your internet, too, i guess. and your hard drive. <nimous>Rutherther: I think the process makes sense for source based package management (I guess?) but I'm not doing the source based thing here. I am installing my programs as prebuilt binaries here. So why does Guix checks for source authenticity here? Guix is a hybrid package manager with binary based and source based installations, but it behaves as source based even when you're doing a binary transaction. <Rutherther>Everyone using Guix is doing that thing, it's one of the core features of Guix that it's source based <Franciman>radhitya: yo do you have a public guix config? <Rutherther>nimous: the way Guix gives you substitutes is that it reads the source and comes up with a unique path under /gnu/store that you can use the substitute servers to download. Without the source, you have no idea what to downlad <nimous>identity: Funny thing is the Guile operations are faster than the git pull. I guess git pull is single threaded because only one of my CPU cores hit 100% usage while doing the pull. <identity>nimous: you can not just get your package database out of thin air, verified for authenticity and all; you have to fetch it and check it for yourself, or rather make guix authenticate do the thing <Rutherther>nimous: the channel is cached, so it's only the first pull that takes such a huge amount of time. Guix repo is huge. While there are definitely possibilities for optimization when cloning the repository, still it would be slow the first time <loopified>Hey! Renewing my interest in Guix after a long time busy with other stuff. I'm really excited to learn about proximity of the upcoming release! Congratulations to everyone involved and THANK YOU! Fingers crossed for it to be a smooth one. :3 <elevenkb>How do you run emacs from a guix home container <Rutherther>elevenkb: you need to set DISPLAY or WAYLAND_DISPLAY env vars to the values in your own environment. On top of that on X you might need to also share XAUTHORITY. Then you need to --share the directories with the sockets, either /tmp/.X11-unix or XDG_RUNTIME_DIR (usually /run/user/$USER) for Wayland. Then you should be able to run GUI programs <Rutherther>...or you can just run it from the terminal, then no special setup is needed <FuncProgLinux>Rutherther: are package additions still accepted in Desktop environments? <FuncProgLinux>I think MATE is missing the xdg desktop portals, usually it relies on the GNOME one, but there's a cross-desktop one made with libxapp but I haven't packaged it correctly <Rutherther>FuncProgLinux: package additions by themselves are definitely fine, not sure what you mean by additions in DEs though <FuncProgLinux>Rutherther: Appending a dependency to mate-desktop-service-type. The desktop itself is like 98% complete by now in Guix <FuncProgLinux>I think only 1 package and the screensaver is missing for it to be as complete as XFCE/LXQT <Rutherther>are there any additions throughout last few days? <FuncProgLinux>Ah, and the Wallpaper thing. But it seems thunderbird doesn't save the DM's :( <FuncProgLinux>Rutherther: Package additions in mate.scm? No. There have been upstream point releases but the dependencies themselves are not in Guix yet as they need a newer libwnck and glib. <Rutherther>because there are so many various commits on master, I probably would not go for risking updating to master after the RC1, but just cherry pick a few fix commits. So addition to mate desktop service does not matter so much <FuncProgLinux>I see. Then I think I can package xdg-desktop-portal-xapp since that opens up desktop portals for MATE/XFCE and Cinnamon without relying on the GNOME ones. <identity>probably that they are the GNOME ones instead of their own <identity>and i think the file picker GNOME uses is going to depend directly on Nautilus, aka GNOME files, in a future version <FuncProgLinux>Rutherther: It doesn't integrate well with other GTK desktops. And relies on GNOME-only APIs <FuncProgLinux>All of the "xapp" things are to maintain compatibility/design consistency across GTK3 desktops outside GNOME. <FuncProgLinux>Just remembered that #3023 is still W.I.P but it includes libadapta which might be useful for those GTK4+Libadwaita apps for non-gnome desktops <FuncProgLinux>Nothing against libadwaita or GNOME btw. I just think it would be nice to leave the lesser-known desktops in a nice shape IMHO <basicnpc>I'm on guix (bleeding) master and some substitutes are not ready yet. Staying in a too-old guix would have the same issue. For Master-Minus-N-Days to be the sweet spot, what is N? <FuncProgLinux>I usually update on fridays unless a CVE warning pops up in the Guix blog RSS. <basicnpc>Also, when guix is building, my terminal isn't printing at all (besides the initial building /gnu/store/vmqma...). Can I make it not hide the output? <Rutherther>basicnpc: for x86_64 I would expect substitutes in a matter of a few days <Rutherther>basicnpc: are you applying -v1 flag or something like that? <basicnpc>So.. is N=7 good enough? Any way I can do that without manually looking up for a specific hash every time? <Rutherther>You always need to look for a specific hash, the build farms do not build for every commit, they build only for commits that were HEAD of master at one point. <basicnpc>Rutherther `guix shell nyxt -- nyxt`. It's now 'stuck' at building sbcl-cl-webkit. htop shows it's taking 101% CPU for a while. <basicnpc>Rutherther: All past HEADs of master got built completely? <PotentialUser-29>hey guys im having some trouble with guix, is this the right place to ask for help? <ekaitz>PotentialUser-29: this is *the* place for that <ekaitz>you can also use the help-guix@gnu.org email address for it <gabber>PotentialUser-29: go ahead and ask (: <PotentialUser-29>ok so im running void linux and i installed guix via the script, but for some reason once i do, my wayland compositor (niri) errors with something like `cannot load xcursor theme`. i uninstalled guix and everything is back to normal. then i reinstalled and my cursor is wrong again. i wouldnt really be a big problem if the niri fallback cursor wasnt <PotentialUser-29>i dont believe the guix installer touches `/usr/share/icons` so im really confused about this <Rutherther>interesting. Did you relog after installing guix to observe this behavior, or was it even before relog? <PotentialUser-29>i did relog, tried restarting even, no difference. i think the cursor changed before relog but i dont remember, let me try again <identity>i experience the same problem (or i *think* it is the same problem) on Guix System, for the record <Rutherther>PotentialUser-29: can you try to comment out line with "export XCURSOR_PATH="${XCURSOR_PATH:-/usr/local/share/icons:/usr/share/icons}"" in /etc/profile.d/zzz-guix.sh and relog? <PotentialUser-29>i just installed, yeah id need to relog for the problem to appear, ill try Rutherther suggestion and report back in a sec <Rutherther>in case it helps, try adding "$HOME/.local/share/icons:$HOME/.icons:" before "/usr/local/share/icons" after uncommenting the line we talked about <basicnpc>nyxt ApplImage and Flatpak versions seem to work. But those are unacceptable to the guix channel, right? <identity>basicnpc: right, those are build artefacts <identity>bundled dependencies are allowed, you just have to build the whole thing from source <identity>and, generally, unbundle dependencies where possible <Rutherther>PotentialUser-29: after relogging, right? Okay. Still, I am pretty sure it has to be one of the environment variables in zzz-guix.sh, since it happens only after relogging. Can you try commenting out also the rest of the exports around the XCURSOR_PATH? The xdg data home, xdg config home and so on <FuncProgLinux>I remember I had the same dilema with some indicator libraries <FuncProgLinux>The package failed to build without "static libs" enabled in the compile flags <PotentialUser-29>it seems you were correct, after commenting out all the xdg stuff and relogging my cursor is back to normal :D <FuncProgLinux>Oh, it wasn't indicators. It was caja-actions. It required "--disable-static" to build correctly in guix <Rutherther>PotentialUser-29: would you help debugging this - checking what environment variable set does this? My first guess would be the XDG_DATA_DIRS <PotentialUser-29>okay so it seems to be caused by a combination of XCURSOR_PATH and XDG_DATA_HOME <Rutherther>interesting, where do you keep your cursors? did you install them system wide? <Rutherther>can you also try adding those "$HOME/.icons:$HOME/.local/share/icons:" to the XCURSOR_PATH, prior to /usr/local/share/icons? <PotentialUser-29>honestly idk how cursor icons work, but i believe mine are at /usr/share/icons <PotentialUser-29>ill try adding .local/share/icons, since ~/.icons doesnt exist on my system <Rutherther>okay. Yeah, I think we ought to add that, along with ~/.icons. It shouldn't matter it does not exist for some <PotentialUser-29>yeah its completely fixed, i uncommented the XDG_DATA_HOME and still everything works <Rutherther>it will be in Guix in a week or so if no one has any objections to it, I will push it <Rutherther>sneek: later tell identity: if you're encuntering this (larger cursor) on Guix System, it might be the same thing, ~/.local/share/icons is not added. Only ~/.icons is from user's home in /etc/profile <Rutherther>FuncProgLinux: I think so? Why wouldn't it be? 🤔 <FuncProgLinux>Rutherther: Idk, some PR's have that label lol. Also, most gtk desktops do search on those paths. <Rutherther>PRs typically get that label after someone reviews them, to show PRs that are already reviewed by someone in an easier way