IRC channel logs
2025-03-21.log
back to list of logs
<jA_cOp>Is there a way to prevent one-shot shepherd services from starting every time the system or home configuration is applied? <jA_cOp>lechner: did debbugs end up posting two messages for one "event" just there? w.r.t. patch 73654 above. From the web interface it looks like there was just one email <lechner>jA_cOp / it was probably a 'touch' or a 'chown' by Debbugs. Debbugs also modifies the first two lines of the mbox file, making it non-standard. i think the rsync happened between two associated file operations <marmarismarmar>desktop icons on plasma doesn't work (or update I guess?) after an update. Fortunately, I can open the applications by using krunner and use the command line option for now <apteryx>the date is wrong on berlin: 04:16:33 AM <apteryx>I guess it is running with the bug where ntpd was crashing <amano>Is guix a substitute for docker? <weary-traveler>amano: docker is build-once, whereas guix is build-reproducibly. one can use guix to build, among other things, a docker image. a guix manifest in that sense could be considered an improvement on a dockerfile <dcunit3d>amano, weary-traveler: yes, but there are many lower-level details. if a /gnu/store on a docker container is too large or uses too much linking, this would increase boot time for /some/ containers (like for serverless). it's unlikely there would be much hardlinking on a dockerfile produced via guix (such container images are unlikely to have many image layers on top of guix). guix is a better way to specify dependencies and you can <dcunit3d>validate the hashes used in a docker image (before or after they are included). <dcunit3d>"guix speaks docker images" sums up the capabilities. if people are using Nix for container images, then maybe. <dcunit3d>specifying container (as docker images) where the image entry point manage multiple processes is likely easier from Guix ... if you're well-versed with Scheme <dcunit3d>troubleshooting that on the docker side is probably rough. <dcunit3d>comparing the two, esp if integrating one into the other, is a deep topic <dcunit3d>it would be interesting to determine whether you could "un-store" a docker image or container. like flatten a package/image/system so that it can have only the FHS it needs. <dcunit3d>that would be likely a bad idea to attempt (not enough value, difficult to support/maintain) <jA_cOp>lechner: so, if I understand it right, both updates were spurned by rsync detecting changes to spool/db-h/54/73654.log? I'm just curious but, that's not an mbox file, right? <jA_cOp>it sounds like a hard problem to solve, but it's a neat setup you have there, parsing rsync -i and using ii <jA_cOp>dcunit3d: at a previous job we would use Nix to provide the dev environment for an application, then build a container image with Nix to deploy it on a Kubernetes cluster. So, I guess it's a "nice to have" capability if your deployment target only speaks containers <adanska>is there a way to modify the phases of an inherited package? like say im inheriting from a package with modified phases, would it be possible in the inheriting package definition to further modify those phases, such as removing a phase that existed in the inherited-from package? <untrusem>I didn't built it but downladed tar that provides binary, cause I don't have 300mb to spare to clang <untrusem>`exec: Failed to execute process './uxnemu': The file exists and is executable. Check the interpreter or linker? <jA_cOp>pre-built binaries from other distros will usually not work on Guix as-is, as they expect libraries to be located in FHS locations, while Guix puts them in the store. One way to run them is to use guix shell with the --fhs option <untrusem>what should I set as xdg-runtime-dir in fhs shell? <vhns>is `rustfmt` not available in guix? `guix search rustfmt` yielded nothing. <jA_cOp>I'm assuming that the program you're trying to run actually uses XDG_RUNTIME_DIR, otherwise you can of course just leave it out <jA_cOp>vhns: it's provided by rust:tools (i.e. the "tools" output of the "rust" package) <adanska>mange: thank you, I was able to get this to work :) <untrusem> so take this build.sh file of uxn for expample <Kabouik>Thanks civodul for the precision. Yup, I know it's acommunity project (and that you emphasize on it says a lot about the whole idea by the way, thanks for that), but I assumed that founders were there from the very beginning when it was much smaller. <PotentialUser-39>Hello Guix. What file system are you using on the servers? For now I stick to ext4 for a long time but never benchmarked it. I wonder what ZFS, XFS or btrfs can improve on my 1 TB root server <futurile>You know I really wonder if "Distributions" can survive the rise of languages like Rust and Golang. I'm 200 crates in now, going around in circles adding <crate-blah>-0.23 ...[50 crates] ... <crate-blah-0.24 ... [25 crates] ... <crate-blah>-.20 - it's f'ing ridiculous <futurile>so far I've spent 7 days trying to review "1 issue" - and literally trying to update from 0.xx of this cli tool to 0.xy introduces so many additions <futurile><back to work - less moaning more building!> <mange>futurile: Yeah, I think it's going to need a different approach. It's not sustainable to have these huge swaths of packages. I know there's been some back-and-forth on the mailing lists about it, but nothing I've seen feels particularly satisfying. <Kabouik>Oh damn, civodul, I took me time to read your nick backwards and connect it to the person. :facepalm: <Rutherther>untrusem: there isn't 'cc' symlink in guix unless you emulate fhs in a container. Since it's usually just a symlink to gcc anyway on other distros it shouldn't be necessary <untrusem>still if I try to build some program, it says cc not found <Rutherther>most programs should have a way to specify the c compiler... <identity`>you should pass CC=#$(cc-for-target) to make or something like that <identity`>doesn't the uxn package from the official channel have that in the definition? <Rutherther>if you just updated the package to newer commit you can still keep the build phase it has that sets it already <untrusem>exec: Failed to execute process '/home/untrusem/.local/share/../bin/uxnemu': The file exists and is executable. Check the interpreter or linker? <lechner>jA_cOp / you are right, and *.log files are slightly modified mbox files. <lechner>not sure i'd call it a neat setup, but it's all i could do while begging FSF to let me modernize debbugs.g.o, which I have done for years <civodul>AFAIK bugs.gnu.org is run by volunteer(s), not by FSF employees <lechner>civodul / Surely, you know better than I. My main obstacle was that the FSF sysops (who I'm not sure are volunteers) did not allow me to deploy GNU Guix on the VPS they gave me. They insisted on Trisquel, which they configure via Ansible <civodul>lechner: oh i see, i didn’t know about this plan <civodul>you’re right, the FSF sysadmins are employees <chaseg>hi, does anyone have hints for me about why my shepherd service that depends on networking is starting before static networking is actually up? <chaseg>i tried making the service manually check /sys/class/net/*/operstate but then it just hangs the entire boot. I don't know why i define (requirement '(networking)) and shepherd is starting it before the network is actually up, even though other services like ssh start in correct order <lechner>civodul / i know you are committed to Codeberg (and none of my efforts are intended to interfere) but I'm thinking of Emacs too. any strings you can pull with GNU would be much appreciated <lechner>also, i really want to score the first GNU Guix deployment at FSF <lechner>civodul / while I have your attention, the long-term plan for Debbugs is to offer diff'ing of S-expressions rather than lines of text, which I'm not sure Codeberg will then be able to accomodate <lechner>chaseg / this is a well-known problem that was supposed to be fixed. i'll post later but have to drive someone to school right now <civodul>lechner: a Git plugin for local diffs would work with any tool i guess <civodul>Arun worked on such a tool and presented it 2–3 years ago at FOSDEM <civodul>and i think i’ve seen other attempts recently <chaseg>lechner thanks, maybe I could help fix it with more info. I couldn't find any indication about it with a google search. <yelninei>3/4 of my failing gnulib tests pass in the boot0 variant but not with the -final or the normal package. The last one is skipped. This confuses me even more than before <lechner>civodul / talked to arun about it but he called it a difficult problem and referred me to another tool, perhaps called ydiff <lechner>futurile / will distributions, or perhaps just package managers, be able to provide a more attractive alternative to language-specific package managers? why not? <civodul>futurile: i wonder too! but i think there’s a lot of room for improvement on our side when it comes to Rust; we can take inspiration from Nixpkgs, as has been suggested on Mastodon <lechner>chaseg / the first issue is that shepherd requirements do not wait for a prerequisite to be done configuring. i'm not sure how that would even work unless the prerequisite reports back an intermediate state of "configured," i think that behavior goes back to systemd and even sysv init scripts. in the interested of short boot times, services are started aggressively. each should be able to deal with short-term problems while runnning <lechner>and therefore recover when a prerequisite starts late. in your case, the consuming service either needs to wait to reconnect <futurile>lechner: for average development projects I don't think distro package managers can provide a more attractive experience - the fact is that distro's have become pretty 'invisible' to the average developer these days - most of the people I've worked with these days consider the distro part an obvious foundation - their mental model starts with their language. I'm not saying that's true, I'm just <futurile>saying their world-view is language centric. <futurile>civodul: yeah, I actually think our tools are pretty good compared to many distros - and the recent thread (which I understand poorly) about improving Cargo/Rust is all good stuff - how many of the others cope is beyond me - it's extremely boring packaging package after package after package - I'm probably 3 solid days from finally getting an actual end-user tool to work! <futurile>civodul: "many of the others" meaning "other distributions ..." <lechner>futurile / would it help if guix were to subsume and absorb the functionality of language-specific package managers in a generalized fashion? are we leaving an opportunity behind to make the world a better place? <futurile>lechner: I think we already try and bite off more than we can chew - it's a small team using an unusual set of concepts and languages - trying to do a "multi-language" package manager; a linux distro; write our own tooling ... it already feels like we have too many sharp edges. In reality if you write Python for a living, you'll use whatever tool your peers use - so no I wouldn't focus on that <futurile>personally - but it's a volunteer project so people can do what they wish :-)) <lechner>futurile / how about about we encapsulate their package manager like we do for services today? <ieure>Will also mention that, overwhelmingly, commercial software development happens on Windows and macOS machines. Not sure how Guix runs on Windows (I suspect it works under WSL2), but it doesn't run on macOS at all due to bootstrapping issues. <futurile>lechner: the speed of guix (evaluation/guix pull), error messages and stuff the survey showed seems like areas of maximum return for the effort - according tot he survey <ieure>So practically speaking, Guix can't even get a foot in the door for this kind of work. <futurile>yeah, not working on Mac is a much bigger problem than it was 20 years ago - it's practically defacto in a commercial setting now <ieure>Literally every job I've had for the last 20 years has used a Mac. <futurile>lechner: yeah, maybe that's promising - in general it would be better "as a small project" to benefit from others work - the importers are a great example of that - perhaps this would be too <ieure>I've had two where I was able to talk them into letting me use Linux, one of those was because I was friends with the CISO and he gave me a one-off exception. <lechner>ieure / winblows and whopple probably don't ignore people's bugs. they suck up all the data from your keyboard and hard drive they can <ieure>lechner, I don't run Windows at all, but the modern Mac experience is unbelievably buggy. Extremely basic stuff like "unplug from monitor, then plug back in" causes showstopper issues you have to reboot to resolve. That bug has been around for over a yearh. <ieure>lechner, Guix on a $180 used ThinkPad is, not exaggerating, a more stable and less buggy experience than a branch new $3200 MacBook Pro. <ieure>But I have Apple Intelligence! As they keep telling me, as they reenable it, forcing me to go disable it for the Nth time. <ieure>It is *dire* on commercial platforms. <podiki>there is a project to use guix on macos via vm <podiki>not ideal but i've been meaning to try it <ieure>Yeah, I set up Guix in a VM, but the VM software (UTM, it's a GUI wrapper for QEmu) is inadequate. <lechner>let's blow all those folks out of the water. i have n ever seen a friendlier and more capable group of open-source developers. guix can do it <podiki>the issue, if i remember, is no glibc ported to current mac (with free tools/compiler) <ieure>Guess my point here is that if we want Guix to win over language-specific package managers, inability to run on one of the most widely-deployed platforms for programming is a major issue. <ieure>Yes, they do it by not bootstrapping from source. <podiki>yeah it is a free software issue <podiki>no glibc on mac with a free compiler, if i recall <ieure>I think they're separate issues, one being no glibc port to Darwin, the other being no Free compiler you can bootstrap with. <ieure>Because the official toolchain requires clickwrap EULA to run. <lechner>podiki / thanks! i'm not sure that's a problem. people just can't have both--i.e. snapple and free software but we should still give them guix <podiki>i'm not sure what you mean, as in guix but built from the macos tooling (nonfree)? <lechner>life is a compromise. intel management engine may still run on my equipment even though i employed all my skills short of a soldering iron <podiki>i'm not sure what is possible or not, i just remember looking at this same question <lechner>didn't someone just mention nix can do it? <podiki>i agree that would be a positive step, though would have to happen separately from upstream guix right? <ieure>podiki, I'd think so -- also would be verboten to mention here, which seems like a problem. <ieure>I think the real risk here is getting a bunch of bug reports if stuff breaks in that setup, which Guix won't be able to do anything about <podiki>i think there would people who would like such a project, now who has the skills to do it :) <lechner>it's prohibited to talk here about running on proprietary equipment? <lechner>or it's prohibited to promote such a solution as superior to an open one? <lechner>where is that statement from FSF about running Emacs on Winducks? <futurile>yeah, a quick scan of the Nix project doesn't shed any light on how they bootstrap - I really should spend some time getting to know it <podiki>just that you can't promote non-free stuff, roughly. it is not such a clear line sometimes <lechner>or is all this illegal under DCMA now? <podiki>so if we wanted to dig into how to use non-free tooling to build guix, we'd want to discuss elsewhere, if it was at length <podiki>I just pushed vulkan and mesa updates to mesa-updates branch to build; will send patches/request to merge later today <podiki>ieure: right, thanks, that is the more exhaustive message in that thread <podiki>the project i linked above seems like the best we can do without major efforts in libc <futurile>ieure: yeah agreed, I wondered if anything changed since 2017 - not curiousity to _really_ dig into it now though :-) <futurile>lechner: podiki is just referring to the fact that as a GNU project we don't "promote" non-free software - assuming that a Mac version was using a non-free software chain - it couldn't go into Guix - so it would have to be worked on in some other part of our community - an example being nonguix - since no-one has time to work on it, I don't think we have to worry too much about it heh <podiki>though that is a good point, maybe we don't have it anywhere explicitly for what being a gnu fsdg project means in terms of official communication channel topics? <futurile>lechner: we've generally taken a relaxed reading of what "promoting" means, but as you know there are always a variety of views in free software on specific meanings <podiki>last point before i go for now, that thread earlier someone was trying to have guix system docker images, which we do have now, wonder how that works on mac? <df>not sure whether the inability to find binaries and cwd apparently being wrong are separate problems <df>I guess maybe it's trying to write to . because mktemp failed? <ieure>df, Probably missing inputs to the package for mkstemp and id commands. Maybe TLP was updated and needs those, but they got missed in the upgrade? <df>missed how? or, more helpful question, what would the solution be? <df>they're both part of coreutils so I would have thought they'd be available <df>but I think I probably still don't understand inputs vs dependencies <futurile>df: I guess you're using it via the service. Try installing it as a package and using it, see if it works. That will then at least tell you if it's specific to the service <df>I had a quick look at nicolas' patch and I doubt it would break it in this way <futurile>I'd guess the package doesn't require 'coreuntils' to build, but maybe the 'service' should have it or as it's required to run - as the service doesn't start with a shell - or something odd like that <futurile>df: agreed that Nicolas' patch doesn't look like it would break it, maybe a search of issues.guix.gnu.org will find something <df>futurile: just doing a reconfigure, but come to think of it, running it from a shell seems bound to work because coreutils will be in $PATH, right? <ieure>df, Missed like, the package was updated from some older version to 1.8.0, and 1.8.0 added calls to mkstemp, and the patch to update didn't put coreutils into the package inputs. <df>gonna have a look at the TLP git history <df>futurile: any idea how I would test it manually? <df>I ran sudo tlp start, and it appeared to work <df>but there isn't a tlp process running <df>ieure: yeah it definitely looks like an invocation to mktemp was added between 1.5.0 and 1.8.0 <lechner>Rutherther / your updates to #77086 are entirely appropriate and probably necessary to solve it <df>oh... but that is only called from unit tests :( <Rutherther>I would like to point out that I think this: https://issues.guix.gnu.org/77086 is a very serious bug that has already caused multiple users to get corrupted (empty) derivation files. Multiple users in the last month have encountered corrupted files. Some reported it to https://issues.guix.gnu.org/76959, some were just here without reporting it. I know of at least 5 users that encountered corruptions and would think this is the most likely cause. If... <Rutherther>... someone is more knowledgeable about shepherd and services upgrade, please take a look. I will try it myself, but I might be unsuccessful as I don't understand well shepherd stopping mechanism nor the service upgrade procecure. <df>hmm, yeah, the call to mktemp in tlp-func-base was already there in 1.5.0 <lechner>Rutherther / are you sure Shepherd is at fault? What can it do when the filesystem is busy? I believe the culprit is potentially elsewhere---unless it's related to Shepherd not shutting down a service because it does not explicitly depend on user-processes (and that's part of Guix, not the Shepherd). there was a commit about it in the past three weeks <Rutherther>lechner: I am not completely sure about it, but if you take a look at the log I attached you can see that chronologicaly 1. root-file-system stop fails on busy /run/user, 2. user-file-systems are unmounted (/run/user/0 and only then /run/user can be unmounted). The order definitely has to be reversed <df>maybe it is something to do with that perl script change... <df>well I guess I can just try reverting it... <Rutherther>lechner: re 'what can it do when the filesystem is busy' - the filesystem is busy because what is on it hasn't been unmounted, linux won't let you unmount root if you leave something mounted under root <lechner>Rutherther / yeah, i got what you are saying. looks like an issue of service ordering. what if the recent commit adding 'user-processes' as a service requirement in a bunch of places also, inadvertently, affected user-file-systems? <lechner>Rutherther / also thanks for staying on top of this very grave issue. i might consider an advisory not to pull atm <podiki>i can't say i've hit it personally, maybe it is for certain filesystems/configuration combinations? <Rutherther>lechner: on top of that I can tell you that without reconfigure, user-file-systems stops before root-file-system from the log <lechner>i would send an email to -devel unless the issue appeared there already <Rutherther>lechner: on top of that I can tell you that without reconfigure, user-file-systems stops before root-file-system from the log <Rutherther>lechner: I am not sure if an advisory not to pull makes sense currently, because most people keeping up with latest guix are already going to be affected already. I think that what can work for affected people is to, before rebooting or halting, quitting most programs, and executing "sync" that I think should commit everything to the disk. Only then to halt <Rutherther>podiki: it is very well possible. My guess is that it will affect only people using elogind and there might be more conditions I am missing <podiki>i agree with a message to -devel for visibility if it wasn't already <janneke>i hoped the race fixed in shemperd-1.0.3 would fix this problem too, but it doesn't seem to <podiki>i do specify elogind-service-type, though just to disable power key (cats love the tower) <Rutherther>lechner: btw if I don't do full reconfigure, but only run the upgrade-shepherd-services scm file, I also get the error <fnat>I've got this 8GB '...texlivetexmf-20240312' folder in the store already and I'd like to launch a Guix Shell environment out of it. Is there's an easy way to get the Guix checkout that particular TeXLive version corresponds to, so that I can use it with time-machine? <fnat>Without time-machine I'd end up redownloading the whole 4GB TeXLive package. <fnat>*out of it = based on that version that's in the store <Rutherther>fnat: you can definitely use it with time machine if you know the commit. Also if you just pulled in the mean time it will be easier to look through the /var/guix/profiles/per-user/$USER/... current guix generations and execute the guix executable in one of them to get the texlive packages <Rutherther>it's not really possible to link store items to guix version unless provenance is used (which is used only for system, home, user profiles) so you probably won't be able to get that information here for those paths <fnat>Rutherther: Thanks. Hm, no, I haven't just pulled, that TeXLive must date back to a few weeks ago. I guess I should have used a profile or something to that effect. Ty! <Rutherther>fnat: sorry, by just pulled I imagined something like: Used one of the previous guix profile versions that you since then updated with guix pull, as contrast to using guix time machine where you possibly forgot at which commit that was. Though I see why it doesn't sound like that <df>is it ok to build guix with make -j N? or does it not make a difference, it looks like it might be using multiple cores anyway <Rutherther>(also this is assuming that you haven't deleted the previous generations) <Rutherther>df: guix package itself? It is not okay, it was removed few months ago, because it seems that guile build system is incapable of producing reproducible packages when more cores are used <Rutherther>(of course if you're just doing something locally and don't currently care about 100% reproducibility, it is fine) <podiki>df: if you mean in a guix git checkout make -jN is fine locally yes (and much faster) <df>yeah I mean in a checkout, cheers <fnat>Rutherther: I'm sure I still have the relevant generation, I'll try and launch a guix shell with various commits until I find one where TeXLive doesn't get re-downloaded. This is what I did in the past, I was hoping there could be some more clever way. <fnat>(I mean, taking the commits from list-generations.) <Rutherther>fnat: I am afraid not really another way for regular packages / profiles from shells. It's probably easiest to either guix shell -r to gc root it somewhere and use it later or guix package with -p to make a package profile out of it that you can use later <fnat>Excellent, thanks Rutherther! <Rutherther>janneke: I am updating to make sure it wasn't just because I was on older commit. I wanted to test on the same commit as ieure reported the issue first. It was before update to shepherd 1.0.3 <Rutherther>but I am not really sure if this can just be a race condition, doesn't shepherd stop the services consequently? <Rutherther>the shutdown-services procedure used for this has a for-each with (service-list). I thought that is executed one by one, always waiting for the (stop-service) to finish <df>hmm, never actually tried this before, should this work? <df>sudo ./pre-inst-env guix system reconfigure config.scm <df>guix: system: command not found <df>hint: Did you mean `system'? <Rutherther>df: unfortunately it doesn't really work with sudo, easier to run as root directly <df>same error (after using sudo su) <df>or just plain su with password <Rutherther>are you in a pure shell? sometimes that is also the culprit, the configure and make should be ran in pure shell / container (but for reconfigure you won't be able to use container). Otherwise something can go wrong <Rutherther>df: if using su itself, don't forget to add "-" flag to make it start a login shell. Otherwise your environment is inherited which is not good <df>yeah, I tried with and without, without I got a permissions error <lechner>podiki / Rutherther / maybe also include the link to the Magic SysRq thingy? As an early Shepherd adopter, I use it all the time now. <Rutherther>lechner: could you point out what you mean? I am not that proficient with shepherd so I don't know about its magic sysrq thingy <lechner>Rutherther / janneke / the Shepherd release didn't matter b/c the issue is in Guix services <Rutherther>lechner: oh you meant the linux kernel thing, okay <podiki>df: as Rutherther said, you should be able to run sudo pre-inst-env from a regular shell (not guix shell or container) and i would advice that always over su/becoming root <podiki>(easy to get root owning stuff it shouldn't for a user) <df>seem to be getting that error whatever I try <df>although, does 'regular shell' exclude eg a screen session? <Rutherther>lechner: it seems to me that the issue is how shepherd loads the upgraded services (upgrade-shepherd-services.scm) where the requirement of the service is lost. But I am not completely sure. I don't think the issue can be in guix services themselves because the issue happens only when this upgrade script is ran, not generally <df>oh wait, you said I should run configure and make in a pure shell? <lechner>okay, i'm not going to argue with you. maybe take it up with lfam, who is not here right now <df>nah wait, actually, I already did it in a container <lechner>Rutherther / podiki / re email, the weekend is coming up. a lot of hobbyists will update tonight and tomorrow <Rutherther>lechner: I think I will be able to say in like half an hour (the vm pull / reconfigure is taking some time) if the issue is still happening after shepherd 1.0.3 for sure. Not sure if there is anything else I can do in regards to the email <dariqq>if i am reading things correctly the /run/user mountpoint from logind might get unmounted too early after a reconfigure? <lechner>Rutherther / i can't send it. lfam who has seen the issue would be a good candidate, or podiki who writes well. or you. i'd keep it succinct with references to the relevant bugs, with a request to report symptoms and a quick reference to B-U-S-I-E-R backwards <lechner>i'm seeing a good friend in fifteen minutes and will be out for the rest of the day, perhaps with small interruptions. <lechner>also not sure about that. podiki will know <podiki>yeah i think devel as a current bug/heads up <podiki>i'm actually in the middle of reconfiguring today, guess i'll find out later if i'm still unaffected <podiki>it is the commands to recover and reboot, with magic sysreq key, as long as the kernel is still able to respond even if system is borked <podiki>ACTION has to run for now though! check in later <lechner>Rutherther / please read the link i posted earlier <lechner>i also have to go. no one has to send anything, but it would be a nice courtesy. i haven't updated since i saw lfam and someone else in despair <lechner>it's the key sequence, in reverse, that you type with Magic SysRq to have the best chance at an intact filesystem <lechner>check out the key bindings---in reverse <Rutherther>but the thing is the system does not get stuck here at all, so I don't think this communication with kernel is necessary here <df>if (extension-directories) returns an empty list here, is that bad? <df>it's weird, because other stuff (like --help) finds the list of commands just fine <df>in fact command-hint appears to, and that's using the same list, wtf <df>oh wait maybe I've got the wrong end of the stick and extension-directories isn't what I'm interested in for a core command... <Rutherther>janneke lechner podiki : the issue is gone on newest guix with shepherd 1.0.3. I was testing on older one to make sure I have the issue reproduced. The same config, but newest guix doesn't cause the issue anymore <Rutherther>janneke lechner podiki : the issue is gone on newest guix with shepherd 1.0.3. I was testing on older one to make sure I have the issue reproduced. The same config, but newest guix doesn't cause the issue anymore <Rutherther>so actually pulling should be a good way to get out of the issue if one is already affected <Rutherther>potatoespotatoes: I am not sure how to do that specifically. But there are at least two possible other ways to achieve the goal: 1. prepend the path to GUILE_LOAD_PATH env var, that is done with simple export in direnv file, 2. make a wrapper script called guix that you add to PATH via direnv and pass the flags you need <df>so I think I've narrowed down my (current) problem to this: <df>(misc-error #f no code for module ~S ((gcrypt hash)) #f) <df>while trying to load (guix scripts system) <df>it looks like guile-gcrypt is a separate package? <df>should I have had it installed while building? <df>huh, well installing the package in my user profile and then using sudo -E seems to have worked <df>judging from what other people on the channel said that shouldn't be necessary though <df>I guess it must be installed somewhere on the system for guix to work at all <Rutherther>no, it has to be in the environment that runs the script. If you use sudo, the environment is not passed through <df>plus there was no error when building, just when I came to run it, presumably it's included in -D guix <df>hmm, well I tried su as well, but I didn't have the package in my profile then <df>... and tlp fails with the same error, so I can probably rule out that patch causing the problem <df>now I can easily experiment with changes to guix, I suppose I might as well try downgrading it <potatoespotatoes>Thank you Rutherther -- I opened up an issue on direnv and I'll take a look at changing the load path later! <df>though I couldn't see any code changes outside unit tests that I'd expect to cause this problem <df>since it was trying to create temporary files in the process of reading config <df>although tbh maybe I should just jump straight to adding coreutils-minimal as an input <lilyp>do we have a typescript compiler in guix? <Rutherther>lilyp: the only ones I know about are in rde and guix-science channel. I don't think there is one in guix channel <Rutherther>I have already encountered node packages that wanted typescript and I have no idea how to package them <PotentialUser-64>Hi #guix! Why does `guix system --delete-generations 1m` download things? <Rutherther>PotentialUser-64: no, it needs to change the bootloader config file so that it doesn't include that generation anymore <PotentialUser-64>en me on the difference between `guix pull` and `sudo su; guix pull`. If I want to minimize the disk space used by guix, should I run both so that only one version of guix is stored in the guix store ? <podiki>i wouldn't use su and guix pull, there's no need <podiki>you only need sudo for system reconfigure <podiki>(big point about guix: no root needed for package management) <Rutherther>PotentialUser-64: guix pull pulls to user profile ~/.config/guix/current for the user logged in. So one will end up in root's home and one in user's home. You don't typically use root's guix unless on a foreign distro <PotentialUser-64>thank you! Somehow I was under the impression that, since we use `sudo` for `guix system reconfigure`, the root version of `guix` was being used. What I am saying is wrong, then? <Rutherther>yes. sudo uses PATH from the previous environment. So your user's guix is used <Rutherther>PotentialUser-64: I can't tell you why is something being downloaded if I don't know what it is. But as a general answer there will be a build dependency used that probably got removed when you ran garbage collection so it's downloaded for the bootloader config build <PotentialUser-64>Good to know, makes sense. So just to make sure that I understand correctly, suppose that I have a file config.scm and two users on the machine, each with a different version of guix. Given what you said, the state of the machine will depend on who runs `sudo guix system reconfigure`? <Rutherther>yes if you don't make sure they use the same guix, the result might be different <PotentialUser-64>Rutherther: That's probably it! I use `guix gc` a lot because I'm always out of disk space <llano>Hi folks: anyone using guix pack to pack a docker image? I must be missing something obvious with the entry point. I cannot execute anything from the image; some sort of path issue <llano>Per usual, the issue is between the chair and the keyboard. Its 'docker load < /gnu/store/the-image.tar.gz' not 'docker import /gnu/store/...' <ieure>llano, I also ran into this, docs could definitely be more clear. <llano>ieure, have any tips, tricks, or gotchas for packing docker images? <vagrantc>where is platform-linux-architecture defined in guix? or is it from guile or something? <Rutherther>vagrantc: no, it's a record getter. platform is the record, linux-architecture is the field. So it's defined with the record in guix/platform.scm <ronqui>i'm on my guix machine right now, and i'm curious how i'd set up something that lets me open this graphical session up on another computer <ronqui>I thought that vnc makes a new lil session <ronqui>What I wanted instead is to see the current screen(s) I've got up on another machine <Rutherther>ronqui: what it does depends on the server that's running on that computer. There are implementations that hook up to the running session <ronqui>Maybe it's because I made (display-number) 3 in my config <graywolf>Hello Guix! How should I go about getting some statistics (or at least flow of events) from shepherd? I am interested in data like "X failed and was restarted", "timer Y was executed", "Z service was registered", "し service was removed", ... <sneek>graywolf, you have 2 messages! <sneek>graywolf, lechner says: / i think Cournoyer is apteryx here <civodul>graywolf: you can get some of that with ‘herd log’ <civodul>but if you want more details, you probably need to use the Scheme interface directly (client-side or server-side) <civodul>you can check how ‘herd.scm’ does it (for instance to retrieve info about timers) <graywolf>Oh I did not know about herd log, looks interesting. Does not seem to have -f, so I will need to poll :/ Will look into the herd.scm, thanks :) <graywolf>(Maybe, to prevent XY-problem, any chance there is Shepherd integration for prometheus metrics already?)