IRC channel logs
2026-07-09.log
back to list of logs
<ham5urg>when thegraphical installer asked all question and is ready to install I end up in a dead console reading "sheperd: Service user-homes has been started." and the same with guix-ownership and guix-daemon. Beside it is a textual graphical installer, I can not switch the terminal with alt+3 but need ctrl+alt+3 as if it is a X session. Why is it behaving like this? <ham5urg>it's odd, after the installer crashes I switched to a tty and started the installation with guix system init /mnt/etc/config.scm /mnt <jungy_>I was hoping to host a minecraft server with mods on my headless guix instance. Is there somewhere that shows a basic template for your own shepherd service for just starting something and leaving it running? <ham5urg>jungy_, I guess claude.ai will help you a lot to get a first package regarding your problem <noxi>jungy_: the guix cookbook probably has what you're looking for <folaht>dcunit3d, I haven't even created a single package yet :/. <folaht>But I'm going to bed, will ask for help friday. <dcunit3d>it's all good. i had some issues with rust crates the last time i tried as well <dcunit3d>it takes some time. each build system and packaging ecosystem has different design concerns <dcunit3d>i need to learn how to package rust anyways <folaht>For me it's completely unfamiliar territory. I'm already happy when I know how to do 'guix pull && guix package -u', to update my user packages. <folaht>I never packaged something before. <dcunit3d>it seems like you're learning quickly though <folaht>dcunit3d, I've got years of experience of being bad at coding. <noxi>has someone ever tried rootless X on guix? <dcunit3d>i ran sddm, but with the basic .xsession <dcunit3d>does the displaymanager need to run as non-root or to just run x11 as non-root? ... x11 is such a cluster in my head <noxi>i don't think you can run sddm as nonroot <dcunit3d>i wish i did... that's kinda why i like this distro <dcunit3d>are you in the middle of trying to get SDDM to do that? do you already have a system with sddm/x11? <noxi>> are you in the middle of trying to get SDDM to do that? do you already have a system with sddm/x11? <noxi>I'm trying to run with 'DisplayServer=x11-user' <dcunit3d>it was easier to debug with gdm logs. do you know where to look in /var/log? <noxi>/var/log/sddm.log, /var/log/messages sometimes? <dcunit3d>if you can change the sddm config to give you debug output, that's what helped me with gdm <dcunit3d>are there logs here /var/log/Xorg.0.log. i don't think they're super-useful by default <dcunit3d>you may dump sddm.conf and try finding a way to run it through startx or some other way <dcunit3d>i'm not sure how to go about configuring rootless x11 normally <dcunit3d>so noxi does the system have /usr/libexec/Xorg.wrap? <noxi>i didn't find how to use the debug output in sddm but I found some things <dcunit3d>if that's available to sddm when it starts x11, then it needs to be added to `privileged-programs` to mark it as setuid. it needs to be the exact ./sbin/Xorg.wrap that gets run <noxi>I'm not sure Xorg.wrap is on Guix but it's a graphics-card specific fix I believe? <noxi>this that kinda looks like what I'm having, but I used console=tty2 and it did nothing <elevenkb>Guys I tried to defect to NixOS but got too spoilt by Guix's hackability (IMHO). <dcunit3d>does it start to handoff control of the display to x11 (idk how it works precisely) <dcunit3d>elevenkb: i also wandered off for a minute to make lib64 & compatibility stuff simpler... but i don't like the sheer expanse of flakes and how to get nix's dependency injection for flake inputs to work properly confuses me <dcunit3d>like getting the equivalent of overrides/overlays is simpler in guix. larger derivations/profiles are simpler to anticipate & manage. it's somewhat pros/cons of channels <noxi>dcunit3d: I'm not certain, I don't think x even starts <noxi>the seatd->elogind transition has already been painful enough as is <dcunit3d>what window manager were you planning to move to? <dcunit3d>the final build step is always slow. it can require some control over channels & GC, but if the system definition is a minimal PoC, it may help i think, though not the parts involving hardware problems <PotentialUser-22>hey everyone! i just built my first package!...but how do i use it once its installed? its there but i cant use the terminal to run it since it says it doesnt exist. did i miss a step? <czan>PotentialUser-22: Congratulations! It's hard to know exactly how to help without more details. Can you share your package definition, how you installed it, and how you're trying to run it? <PotentialUser-22>czan i installed it using a local scm file with `guix package -f <package.scm>` am i allowed to show the package def if it uses a package from a different channel? its from guix toys. <bdunahu>if it's in the store, you can also do this btw: guix install /gnu/store/abcdef123-my-package-1.0 <bdunahu>I don't really understand the last question, do you mean show with `guix show`? <bdunahu>if it's a package from another channel, you have to add it to your `channels.scm` file and then do a guix pull <bdunahu>it think it just tries to update it because you already installed it with `guix package -f`, what is the current issue? Trying to invoke the binary the package installs results in command not found? <bdunahu>if it installed successfully, then it should be in `$HOME/.guix-profile/bin`, which might not be on your shell's path. You should `source $HOME/.guix-profile/etc/profile` <bdunahu>and maybe add it to your .bashrc or wherever you want to set it <bdunahu>sorry for not understanding the question at first, I see that's the first thing you asked <bdunahu>oh also if you already did that, your binary might say 'not found' (hard to recognize without seeing the exact error) because it was built on a non-guix system and expects to be able to load libraries and other runtime files in directories that don't exist on guix, like `/usr/lib`. Maybe the binary's `rpath` is broken? <PotentialUser-22>bdunahu i just used `source $HOME/.guix-profile/etc/profile. the binary is not in `$HOME/.guix-profile/bin` <bdunahu>okay, if you look in the file in /gnu/store/abcdef-my-package-1.0/bin, is it there? If not the package definition is not installing it <PotentialUser-22>there looks like there isnt a bin directory but a share one. how should i change the package def to install it? <bdunahu>oh if the issue isn't that the binary was installed in `share` for some reason (don't see why that would have happened), then maybe you should check that the package is actually building an executable in the first place <dcunit3d>PotentialUser-22: you may try guix shell -f $pkgscmfile <Guest64>Hi, I'm curious what creates those messages in the Git log like "Merges: guix/guix!9666" <Guest64>Is there some tool that handles it automatically? <dcunit3d>PotentialUser-22: the package spec shows 'install and 'configure were deleted from %standard-phases, so you'll have to inspect the build output in /gnu/store/... one way to do that is with GUIX_ENVIRONMENT in `guix shell` as above <bdunahu>of yeah install being deleted is why the output in /gnu/store is missing your binary. the /share/ directory probably only has the license <dcunit3d>`guix build --keep-failed` helps with figuring out what's going on. <dcunit3d>the guix-daemon limits network traffic, but this would cause the build to fail <dcunit3d>Guest64: there's ./etc/commiter.scm which has some automation. commits usually get a "Change-Id:" and i think other attributes are likely added by forgejo or an issue-tracking system <dcunit3d>that gets set up in the .dir-locals.el for the project <Guest64>dcunit3d: Thanks for the pointers. Yeah, I think that committer.scm actually aims to write the meat of the commit message for you <Guest64>Makes sense that it's an emacs thing :) <futurile>finally have a small bit of breeze through my window, hope it's not as hot today, I can barely think! <dcunit3d>if i'm writing some makefiles for some dotfiles with guix, should i generally try to keep the paths absolute or relative with guix commands? <futurile>if you're working with the files after they've been instantiated into your home dir it won't make any difference because 'guix home' soft links everything right <dcunit3d>i'm mainly trying to set up scripts so that a gc root created by `guix time-machine` doesn't get GC'd <dcunit3d>i'm using the ares repl and i'm trying to run some basic tests with that <dcunit3d>there are lots of path references, but i'm not sure what the conventions are for make <futurile>I thought you could name a profile when you created it, but I can't remember how and guix package isn't showing anything in help. That would be best as you'd know that the profile was then set <futurile>the paths to a specific profile should stay the same, across generations etc <dcunit3d>i found out recently that i can pass --root to time-machine and that creates a GC root, but it's slightly different <futurile>ah OK, it's simple you just name it "guix package --install <whatever> --profile </where/ever/you/want> <dcunit3d>i just don't have enough experience to figure out whether i'm refactoring a lot of files/paths for no reason <futurile>the convention is .guix-extra-profiles/profile-x <futurile>I'm fairly sure that you would create a profile; put packages in it; then use that for guix time-machine (possibly with a channels file); and taht it won't be gc'd <futurile>so I don't think you'd have to do the 'gc root' thing - though have to admit I've never played with that <dcunit3d>i split things across two machines, so i'm trying to get updates in sync. i just set up avahi and that should speed things up, but i need to pin the channels <dcunit3d>i tried using guix copy, but there are quirks since one is arch and the other is nixos. <dcunit3d>the --root option doesn't create generations after running it multiple times. <futurile>wow, ok, heh interesting. If you get it to all to work you should definitely write it up! <noxi>Why has cryfs been removed? <noxi>> [...] and claude authored last month <noxi>yeah in the commit log of cryfs <futurile>brilliant, someone just accused Andreas of "smuggling" llm code in. People are really getting overheated on this topic. <sneek>Welcome back kestrelwx, you have 1 message! <sneek>kestrelwx, podiki says: re: wayland and rust: i would check if wayland is available or not on e.g. i686; if this brings rust to archs it can't work then could make separate package for wayland docs (or wayland with docs) <cdegroot>Am I the only one having trouble with a shortened .bz2 file in the store? /gnu/store/vjc3d916jmnsv16kyv5lh59rk852a0z7-spice-0.16.0.tar.bz2, downloaded it twice, seems to be truncated to 1.7MB. <dcunit3d>were its store items gc'd between downloads? <cdegroot>It's a single file; I deleted it (which does a gc) and retried, same error, so I'm almost suspecting an upstream issue (no disk space issues either) <PotentialUser-22>hey again! i stepped away from my pc last night. but today i read the irc logs and now i think i know how to diagnose my issue. i just need to `replace 'install`...but i dont know what to replace it with. here is the scm file from before:https://paste.debian.net/hidden/f6d6bad1 <ieure>PotentialUser-22, Looks like upstream's build system is heavily oriented around creating distro packages, and it doesn't actually have a from-source install process at all. So you get to create that. <ieure>PotentialUser-22, No. What I mean is that most upstreams have some kind of install-from-source process which you can use in the Guix package build. It seems like this one does not have such a process. But such a process is required to install from source, which is what Guix packages do. So you have to make some version of the thing the upstream lacks. <ieure>PotentialUser-22, This could be in the form of contributing a source install process upstream, then using it in your package. Or it could be an install step in the Guix package build which makes directories and copies files around. <ieure>Whatever the approach, the main point is -- upstream doesn't provide something you need, thus you must. <PotentialUser-22>ieure i understand. looks like ill have to ask the devs how to go about doing this. <ieure>PotentialUser-22, You don't have to. Go look at the shell scripts they have to create distro packages, then do whatever they're doing. But in your package's install step. <spinna>are packages copied by `guix copy` possible to use in some way by the target guix instance? i try guix home and other guix commands but it tries to build them again. both computers have the same channels on the same commits <ieure>rovanion, Guix on a foreign distro? <ieure>Hmm. Error seems to indicate that Guile itself isn't available. What does `which guix' say? <rovanion>/home/rovanion/.config/guix/current/bin/guix <rovanion>Which is a symlink to /gnu/store/387fh9xj7phz3cp86x0zd3fmsggsl8cn-guix-command <ieure>That's a surprising location, I'd expect something uner $HOME/.guix-profile or $HOME/.guix-home. <rovanion>~/.guix-profile/bin/ exists but does not gontain a "guix". <rovanion>Things are going well for me. Rebooted my system, --kexec resulted in a hardlock, and once rebooted my new system has broken DNS :D <ieure>rovanion, The DNS thing is super frustrating, I'm still not 100% sure that's been fixed properly. <jnms>kexec and encryption aren't good friends it seems <rovanion>Ah, because entering that pesky password was just what I wanted to avoid. THank you for the info both of you! <ieure>All my stuff uses encryption and kexec generally works. But on a laptop, it boots up with the backlight completely off for some reason, so you have to type the password in blind. <ieure>rovanion, You still have to enter the password when you use kexec, the new kernel doesn't inherit all the live state of the one it replaces. <ieure>But you enter it into the kernel stuff, which is fast, instead of into Grub, which is very, very, very, very slow. <rovanion>Huh, hopefully I will remember that next time I reboot. <jnms>rovanion: Profiles that will contain a `guix` are `/run/current-system/profile` (managed by `guix system`) and `~/.config/guix/current` (managed by `guix pull`). `~/.guix-profile` is managed by `guix package` (the user package manager) and is empty by default. <kestrelwx>Is this what you got with the crates importer? <folaht>Oh whoops I posted the wrong thread <folaht>kestrelwx, for the earlier thread, it's a no, because it's not available at crates.io as far as I can tell. <kestrelwx>folaht: If you are contributing the package to Guix upstream you would point the importer at `$GUIX_CHECKOUT/gnu/packages/rust-crates.scm`, if this is for your own channel you follow instructions from hako's message and then for the `-i` parameter to the importer you point it at this file in your channel that will contain the crates. <kestrelwx>So replace `gnu/packages/rust-crates.scm` with the path to the crate module of your channel.