IRC channel logs
2025-01-12.log
back to list of logs
<Kreijstal>I mean I kinda need this because I am a newb who doesn't know what I'm doing <freakingpenguin>I see some interesting behavior (that's probably my fault). After reconfiguring $ herd status foo-timer showed a schedule as expected, but when I rebooted the service was started on boot and boot deadlocks. <wakyct>I'm kind of stumped here, even though I've deleted a phase with (modify-phases %standard-phases (delete 'configure)) I still see "starting phase `configure'" in the build? <wakyct>anyone know why that might happen? <old>when I build a package with the `--target' option, no tests are being ran <old>I only get a message from guix: test suite not run <wakyct>nm, it happens because I can't read... <Guest1>Is there any way to make a service depend on another service that isn't a shepherd service? Shepherd had provision and requirements but I don't see anything similar for the service-type <freakingpenguin>Ah, my problem was because I didn't wrap the timer ACTION in a thunk. <wakyct>does anyone know typical causes of void-variable error when building emacs packages? It's not obvious to me from the elisp in the package itself though I do see some mentions of it in the wild so it seems like a somewhat common issue? <wakyct>I've tried building with a full emacs but got the same error <freakingpenguin>Has anyone added timer-trigger-action with shepherd timer services in Guix? I get "error: timer-trigger-action: unbound variable" even with #:use-module (shepherd service timer). <freakingpenguin>Curiously $ guix repl and ,use (shepherd service timer) complains about the fibers module not existing. <rekado>Deltafire: I don't just want the few volunteers in python-team to take notice, but people who might have an interest in the affected packages. <sleep_walker>I found my answer - I can install `guix package -i /gnu/store/path-to-my-package`, thanks. I had no idea it works this way too... <janneke>rekado: i have a few python package updates on core-packages-team, because they didn't build with gcc-14 <janneke>i also "stole" some package updates from the python-team branch to get things to build on core-packages-team <janneke>there's a tiny chance you can steal some python updates back but i figure you're looking for structural (django, ...) help <ferocious_iguana>The reason I could not boot Guix installer on my computers is because I had secure boot enabled (both Fedora and OpenSUSE Tumbleweed installations). <divya>ferocious_iguana: Indeed, it won't boot otherwise on UEFI systems <nmeum>what does the 'user-processes service requirement do? which services should make use of it? its not documented in the manual, or I am unable to find it at least. <Prock>Been a ages since I used Irc <Prock>I need help, I think its an amdgpu issue? <Prock>If I Ventoy boot the latest version , it locks up very early in the iso's boot process <Prock>If I use the iso that doesn't have a version to it, just latest, I can install and login but a few seconds later it locks up <Prock>I came from Gentoo and have tinkered with nixos, if knowing that helps, I'm diving in head first learning as I go <Prock>I think I need to ask a question about what is said to be off topic in the title. Or could it be that I need to disable one graphics card in a certain way, and use the open source variant of nvidia? <Prock>How often are the iso's for the download/latest put out <ferocious_iguana>So I obtained the latest ISO and built from it this morning, but I built it myself from Guix installed in QEMU on my main distro <cassio>I want to change my screen locker to swaylock. Is it enough to declare it within the `screen-locker-service-type` configuration, or I also need to declare it as a `privileged-program`? I'm confused because in the Reference Manual it says that the configuration of swaylock requires these two flags: `(using-pam? #t) (using-setuid #f)`... <Rutherther>cassio: swaylock doesn't need to be a privileged program. It needs only pam rule <ekaitz>efraim: what's our position on having multiple package versions? i just fixed sioyek adding an older mupdf and now i'm not sure if I did right <graywolf>Welp, you can "uninstall" guix by running guix gc after guix deploy fails to switch generations. <graywolf>And after reboot, the only generation is the one that failed to be switched into, so the system refuses to boot. Nice. <graywolf>Yeah, I tried, the problems seems to be that interaction between failed generation switch, guix system delete-generations and guix gc is not fully thought out <Rutherther>graywolf: that's not right. You must've somehow manually removed the gc roots for your profiles then, or had a disk corruption that removed them. Normally gc won't collect your installed profiles <graywolf>The problem is that guix deployed failed to switch the generation (due to file corruption in one of the .scm files), but I guess the root was already gone <graywolf>It is bit hard to reproduce (due to file corruption seemingly being the condition) <janneke>graywolf: iow, it should be impossible (without disk corruption) to break guix. in the extremeley unlikely case that you can, and have a (reproducible) recipe for it, that would be a most serious bug that needs to be reported <janneke>s/needs/would be amazing if you.. it/ <Rutherther>janneke: it is possible to guix gc the guix version your are using if you remove its gc root under /var/guix/gcroots <graywolf>I definitely did not manually remove anything. The sequence was guix deploy (failed) -> reboot into previous generation -> guix deploy (failed to switch) -> guix system delete-generations -> guix gc | at this point `guix' binary is gone <janneke>Rutherther: sure, but that would be a WONTFIX rather than a critical bug <graywolf>(There might be something wrong with guix deploy btw, this is second time in past 3 weeks I had corrupted item in the store after guix deploy. On two separate machines, so HW issue is unlikely.) <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, janneke says: reconfiguring the system fixed offloading <janneke>i was hoping the build farm would seffer the world rebuild for me this time, but i started a local build again and got until hello and libstdc++, so things seem to be fine... <civodul>janneke: it might be that evaluation was ongoing when i reconfigured/restarted Cuirass yesterday <janneke>maybe "too much" gets to be rebuilt, queue too large or something? <janneke>civodul: also, i'm wondering what the best way forward would be. <civodul>to move forward, there should be a “request for merging” on file <civodul>otherwise other branches will keep getting merged before this one :-) <janneke>right, do you think "we"'re already there? <janneke>cuirass says 81% success rate (whatever that may mean) for x86_64 and i686-linux, i was in the process of wondering what failing builds/targets to pick next <janneke>until now it seemed pretty obvious which packages needed to be fixed <civodul>i think the suggestion is to file the request early on anyway, because there’s going to be some time before it’s our turn <civodul>BTW, are “we” done in terms of package updates? are we in the fix-broken-builds phase, so to speak? <civodul>ACTION clicks “Retry the evaluation” <janneke>civodul: eh, i don't quite get your question. the only packages i wanted updated was gcc, to 14.2.0 -- all other updates were either by explicit request (cmake build system, gexp-fixes) or because the update happened to fix its build wmith gcc 14 <janneke>iow, i tried to keep the package updates to a minimum to avoid an "update storm" <civodul>i thought we’d at least upgrade glibc <civodul>because it’s on a 6-month schedule roughly and that should help x86_64-gnu too <civodul>that said, i really failed to catch up on this! <civodul>but that’s fine, we can have a separate entry <janneke>#74676 was meant as a: "please help with the gcc-14 transition" <civodul>janneke: maybe you should rebase the branch to trigger a new evaluation and all <janneke>great, i'll open a request for merge bug <graywolf>civodul: The "gexp-fixes" part probably refers to my patch #73660. Yours LGTM would be much appreciated. <graywolf>I recommend viewing the patch on debbugs.org instead of issues.guix; issues.guix is not... great with non-ascii :) <civodul>graywolf: just replied, re gexp/locales/encoding :-) <janneke>ACTION pushes rebased core-packages-team and files rfm #75517 <graywolf>Thanks for review, will take a look later (probably tomorrow) <civodul>janneke: looking at the manual, i think there should be double quotes around the branch name <civodul>(i was bitten by something along these lines a while back) <janneke>i took the double quotes as a mistaken <branch-name> <janneke>the manual should read: "<branch-name>"? <janneke>hmm it says "NAME", i guess i was wrong <janneke>also, "core-packages-team" can be rebased and pushed, there's no need for "merge"ing <janneke>i wonder if that could be/needs to be changed (as an old-timer, i don't believe in merging) <podiki>janneke: i think all branches now work on rebasing, so the "merge" indeed isn't a "merge" commit <podiki>but i guess in the non-git usage of the word it works :) <simendsjo>civodul: hi, yes, I'm here :) I send an update for the hanging guix-home shepherd. Several services causes the hangs, all mine. So I must be doing something odd although I cannot see what... <podiki>yeah i much prefer it, cleaner history on the main branch <janneke>yes, and you can bisect if there's a problem <janneke>ACTION alsosometimes uses "merge" when they secretly mean "rebase" not to upset the new kids <graywolf>New kids all squash merge and I hate it. My artisanal commit messages get turned into this horrible blob of markdown and checkboxes. <old>I'm re-asking my question this morning <old>when I build a package with e.g., `--target=powerpc-linux-gnu', tests are not executed <old>I only get a message from guix saying that the test suite was not ran <old>at this point I have no idea why <graywolf>old: Seems to make sense. With --target you are cross-compiling, so the tests not running seems to make sense? <old>I have qemu with binfmt for that <old>There should be an option for forcing tests tho <graywolf>You can run with --system=... instead of --target to use ghe qemu-binfmt <old>right. --system seems to work for aarch64, but i got little problem with powerpc and armhf <old>compare to just cross-compile <civodul>simendsjo: thanks! and is it hanging again? <civodul>the shepherd.log you sent is from just an hour ago, long after your initial report <janneke>old: also qemu binfmt only works when cross-compiling between identical operating systems/kernels <wakyct>hi Guix, for language support in Emacs for a new project I might be looking at setting up a lsp server with lots npm dependencies. Am I in for a world of hurt? Should I figure out something else for editor completion, etc.? Or should it be relatively straightforward to set up <wakyct>the lsp server (typescript) is being ported from a vscode plugin if that's any indication <janneke>wakyct: isn't there a sensible treesitter based implementation? <wakyct>I would like to give that a go at some point but I was looking at it the other night and it's too much for me to take on right now <wakyct>I wouldn't mind just using a binary for the server really, I just haven't had to install node thankfully and I don't know how bad that is <graywolf>lol it took me many months and many giving ups before I realized (just now) that --method=store should be passed to guix locate -u, not to the guix locate FILE. <graywolf>32678 vs 509 packages, hopefully it will start actually finding things... <podiki>oh did not even know about that guix locate option, nice <civodul>graywolf: though you probably don’t have the 32K packages in store… <jlicht>wakyct: there's an npm-binary importer that may help you package an initial, non bootstrapped version of your lsp. it most likely won't be eligible for inclusion in guix proper without more work though <jlicht>I use it for a shoddy guix package for the typescript LSP <graywolf>1. How much disk space do currently substitutes for x86_64 take? Do we know? 2. How can I download them all (to some directory)? Is that possible? <Prock>Did anyone ever get to my question from hours ago? <Prock>Install Error, The dump was uploaded as installer-dump-8e7c4f17 <wakyct>I don't think so Prock, you can always check the archive too <Prock>Like a chat archive? I'm not sure how to do that. <wakyct>but searching my log here I don't see an answer at least with your nick in it <wakyct>if you need proprietary drivers you won't be able to install, but usually it tells you in the install process <wakyct>I guess I should say 'you won't be able to get it work properly' <Prock>I have two graphics cards, an Nvidia and a Radeon. <wakyct>usually it tells you in the install you have nonfree hardware <Prock>It mentions a radion won't work, but couldn't I just use it in video full time? <Prock>How would I go about being able to use non-free drivers? <wakyct>I don't think that's on-topic here sorry, but you can easily find this info searching <wakyct>the Guix subreddit might be a better place if you want to ask users <x8dcc>Hello, when declaring a package, how do I specify the version of one of the inputs? <graywolf>Is it permissible in package to refer to GNU Guix as GNU/Guix? I am scared of the space in the official name... I can always just leave the "unknown" <Rutherther>x8dcc: you don't specify versions. You refer to guile symbols. So refer to a symbol that has that version <x8dcc>And what's the naming convention for packages with multiple versions? 'package-1.2.3'? <Rutherther>x8dcc: it depends. Sometimes just -x, sometimes -x.y <x8dcc>Okay, but not 'package-v1.2.3', for example <x8dcc>Okay, thank you. I will try to get this working <mightysands>So I was just thinking... usually, when someone breaks into a Linux machine, gaining root is essentially the worst outcome and an attacker will always try to escalate privileges. Would I be right in assuming that guix would technically make it a lot easier for an attacker to gain root on a machine, given its ability to use guix shells and also the fact it allows users to install packages without root ? <Rutherther>mightysands: no, you cannot get root with shells nor installing packages <mightysands>(some people say it is, some say it isn't. I'm just trying to look at guix from an amateur security angle) <ebrasca>Hi, how to define a service to autostart an app? <graywolf>mightysands: You cannot install suid packages using guix shell. So there should be no additional risks compared to downloading the source and compiling the code as an regular user. <Rutherther>mightysands: profiles are just paths in the store, when you enter a shell you just put store path in some env vars, same goes for installing. Store cannot contain any privileged programs - no setuid, setgid flags, no capabilities <graywolf>(Well, you "install" the package, but without the suid bit) <Rutherther>ebrasca: what do you mean by an app here? are you talking about a gui app or do you mean like a service? <Rutherther>ebrasca: that's complicated. For firefox, it is started inside a compositor environmnent. For sway, it is started as a user and you typically want it on a specific tty. I would not recommend a service for either of those, and rather use .profile for sway and sway's auto startup for firefox <ebrasca>will that start sway all the time I start a terminal? <graywolf>.profile is used for login shells, terminals (usually) do not run those. <Rutherther>ebrasca: no, .profile is executed only when you open a login shell. When you open terminal in gui session, it doesn't start a login shell. Moreover you of course can add a condition for a specific tty only or only one session, etc., it's completely up to you how you handle it <graywolf>I assume there is some command to replace that for wayland <ebrasca>graywolf: I can't tech my mother to run sway on the terminal to start sway <graywolf>I think that is the common way how to auto launch WM <ebrasca>Adding to the .zprofile worked fine. <wakyct>when I install a new Emacs package, how should I load it into the running Emacs? I tried (load "subdirs") which I saw suggested elsewhere, but only logging out seems to update things (based on executing profile I guess) <graywolf>wakyct: When you figure out, let me know :) I always restart. :/ <wakyct>haha, yeah, it seems like there should be a better way... <wakyct>I guess it might be possible to manually fix up the Emacs load path? <lilyp>Loading subdirs *should* work, but it will only matter for stuff that hasn't been loaded yet <lilyp>of course, you can always reload libraries <dariqq>yay, the 'GC Warning: Failed to expand heap by 8192 KiB' error during guix pull on i686 is back and this time it just causes guix pull to hang indefinitly <dariqq>running from an x86_64 machine with -s i686-linux the guile process peaked at 3.5GB memory + another 500MB for guix itself (but at least it succeeded there) <wakyct>lilyp I'll give it another try later...when I tried originally it didn't load the new package, though it was in site-lisp <wakyct>it also seemed like old packages (like if I'm package installing and removing the same package) remained in load-path so I'm not sure if Emacs would know what package to load <wakyct>but that was just looking at load-path var so I'm not sure if that's right <wakyct>this is all managing things with Guix...maybe I should give in and use Emacs to manage its pkgs but I'd rather not <lilyp>to be fair, it is hacky and reloading emacs is the "cleaner" solution <lilyp>that said, I just confirmed with two pure environments, that loading subdirs works as intended <lilyp>hmm, looking at the load path you are right, though, that the newer stuff is put later <lilyp>so if you actually want to reload stuff, you'd first have to drop everything that ends with "site-lisp" from the load path and then load the new one <lilyp>I think this has to do with how `normal-top-level-add-subdirs-to-load-path` works <lilyp>Ahh, first have to add push directory in which subdirs.el resides for it to make sense <lilyp>so for your regular guix config, this should not make a difference <dariqq>huh, now guix is claiming that rust-criterion-0.5 is unbound, something really weird is going on <dariqq>ACTION gcs the generation and tries again <dariqq>redoing the 'guix pull' and now everything is fine again, weird <dariqq>(i did disable guile jit though this time) <dhoffman>what packages should I install in my `guix shell` to build the wip-riscv-bootstrap branch? looking through the output of `./configure --host=riscv64-linux` it does a search for the cross-compiler but fails and falls back to gcc/g++ (the fact it doesn't outright fail at this point is concerning) <dhoffman>might take a stab at a clang-built setup but at this point i want to reproduce whatever ekaitz / efraim are working on <ekaitz>dhoffman: wip-riscv-bootstrap is not easy to shell in <ekaitz>the goal of the branch is to make the boostrap of guix <ekaitz>try to `guix build` the packages from the branch, and you'll see <ekaitz>more specifically the commencement.scm module <ekaitz>those are the packages that bootstrap the whole software distribution <ekaitz>the problem is that we didn't connect those to the rest of the packages yet <ekaitz>efraim is working on that and it's not an easy task <dhoffman>yea i'm aware. i'm trying to help knock out some problems along the way <dhoffman>unless everything lives in his mind and it would be burdensome to formalize what needs to happen/coordinate on it <ekaitz>in that case focus on building the gcc's on the commencement file <ekaitz>you will be able to build at least the 4.7 but you should get stuck no very far away from that <ekaitz>that will give you context on how does the bootstrap system work <Kolev>How to check U.S. weather with Emacs on Guix System? <PotentialUser-62>Hello. I am having a problem installing onionshare. Is it just me? If not, does this kind of things happen with some regularity (build failure)? 