<ChocolettePalett>I also tried modifying services according to the documentation, but failed, as well as when trying to redefine %variable-responsible-for-substitute-urls
<jackhill>yeah, usually I just add my own to the default list in there, but it's easy enought to just leave out the default.
<jackhill>redefining the variable won't work in scheme (it might in elisp) because of scheme's lexical scoping.
<ChocolettePalett>Ah, it seems that I forgot about the keys... Why is it necessary to add the authorized-keys'' if(inherit config)'' is used?
<ChocolettePalett>* Ah, it seems that I forgot about the keys... Why is it necessary to add the authorized-keys if (inherit config) is used?
<jackhill>ChocolettePalett: I don't think it should be, bordeaux should be in the default list. I left that in my example, because I also have a local substitute server, and I thought it could be infromative.
<cbaines>podiki[m], qa.guix.gnu.org isn't building patches currently
<cbaines>bordeaux.guix.gnu.org needs to catch up building things so that there's a basis for the comparisons
<jpoiret>cbaines: does qa use the "patch" tag to identify issues with patches?
<jpoiret>ie can i add the patch tag to a bug to make qa pick my patchset up?
<lilyp>i think it reads stuff from guix-patches so you'd have to send a reassign message to debbugs
<cbaines>jpoiret, as lilyp says, it's just looking at guix-patches. Also, because it uses Patchwork, it is reading from the guix-patches mailing list, so I'm not sure reassigning bugs to guix-patches will work.
<ofeeg>Anyone know if I need to write a new scheme file to install new firmware on guix? I know on debian I could just cp firmware to a specific directory but I don't know if I can do that solution on Guix. It might be in the documentation but looking through said documentation I haven't found a solution.
<rekado>ofeeg: to change what firmware gets installed you have to override the value for the “firmware” field in your operating system configuration.
<ofeeg>rekado: What is the appropriate way to do that? I have display'd the %base-firmware variable and it seems to be a list of packages, but when I look at how to create a package I feel like I'm not looking at the right thing, if that makes sense.
<ChocolettePalett>But I haven't even managed to install Guix yet, so my assumption might not be very correct
<jpoiret>ofeeg: well, if the firmware is not packaged in guix, you'd need to package it first
<jpoiret>and then use that package in the firmware field
<rekado>ofeeg: these are in fact packages that install files to their output prefix under /lib/firmware
<rekado>so you’d need a package that installs its files to $out/lib/firmware
<rekado>then add it to the list of packages in %base-firmware (or replace it entirely)
<rekado>so the field in your operating-system record would look like (firmware (list my-firmware-package)) or (firmware (cons my-firmware-package %base-firmware))
<ofeeg>Ahh, that explains why all the /lib/firmware directories were only found in /gnu/store paths.
<ofeeg>I got very confused when I couldn't just cp my files to those directories but then I learned a bit about what gnu store actually was. Thank you all for your guidance.
<jpoiret>ofeeg: i suggest learning a bit more how guix system works itself, it is very different from how usual distributions manage their system
<jpoiret>in general, you don't copy or modify files but just modify your system configuration
<ofeeg>Yeah, I am starting to learn a bit more about that now. I do have familiarity with guile from deciding to make a netcat replica in guile at one point. It was a fun toy to play aaround with for a while, so at least the rest I'd have to do is go through a bunch of references in the doc.
<Michal_Atlas[m]>Hello, does anybody else use mcron on a laptop? The manual states that jobs should run after wakeup if the machine is suspended, however I use '(next-hour '(6)) and it only seems to run if the system is awake at that time.
<apteryx>Michal_Atlas[m]: Perhaps a bug? The source is small, you could try to review if there's logic there for it to happen.
<Michal_Atlas[m]>That's a good idea, I might look through it, and perhaps update the Guix manual afterwards since this seems like something many people would be using on GuixSD. But it would be strange for the manual and implementation to differ so much.
<apteryx>oh, is it mentioned in the Guix manual or the mcron one?
<mirai>when exactly do I need to use with-imported-modules
<Michal_Atlas[m]>The mcron one has about 5 lines describing that it's not really made for laptops but it should work nonetheless. And the Guix one has a nice tutorial on mcron but omits info about this entirely.
<Grimpper>Good evening. Anyone using `xfce4-weather-plugin` is able to set it up? I'm not able to configure the location
<mirai>if I use the my-custom action, shepherd completely hangs
<bjc>i have some questions about why you're organizing the service this way, but outside of that, i think the problem is that from within a shepherd call, you're trying to make another shepherd call across the socket
<bjc>the daemon only handles one call at a time from the socket, from what i can tell. so the code in ‘my-action’ will hang when it tries to send a message through it (which is what ‘start-service’ does internally)
<bjc>you don't need to do that. since ‘my-action’ is run inside shepherd itself, you can just use the stuff in the (shepherd service) module to do what you want. namely ‘(@ (shepherd service) start)’
<mirai>bjc: what kind of argument is 'start' expecting?
<mirai>though I just found out that (respawn? #f) disables the service
<bjc>that said, i'd consider shepherd hanging in this way a bug. ideally there shouldn't be much of a practical limit on how many clients it can serve at the same time, so a bug report is probably in order
<bjc>that's a weird name for ‘disable’, but i guess i understand how it came to be. i think you want ‘one-shot?’, though
<mirai>I wonder if there's a way for a herd service to exit gracefully without it being considered a service failure
<mirai>no, I'd like for start and stop to keep working
<bjc>honestly, the shepherd should *never* hang. any time it does is a bug, no matter the circumstances
<bjc>you can still use ‘start’ with one-shot. although stop would be a problem
<mirai>well, I can workaround this by performing enable on the my-action beforehand
<bjc>now that i have most of my core-updates problems fixed or with a patch pending, maybe i should get back to looking at shepherd. splitting out ‘disabled?’ from ‘restart?’ should be easy enough and useful
<bjc>you can't count on a shutdown, though, right? sometimes the power just dies
<mirai>indeed, and for those cases the scrub should resume as soon the system powers up
<bjc>so it's only a problem with a clean shutdown?
<mirai>so in effect the 'start' slot of this service would actually mean 'resume'
<mirai>the 'stop' is btrfs scrub stop (which means interrupt)
<mirai>and you'd schedule new scrubs with (herd new-scrub …)
<mirai>if I simply put scrub start on the 'start' slot, then not only it doesn't automatically resume an interrupted run but you'd schedule a new scrub after system bootup if the last run was successfully finished
<bjc>this seems over-wrought to me, but i'm not particularly fluent in brtfs, either. i do know that i don't really trust the current (pre-0.10) shepherd to keep track of processes that well, though
<bjc>i dunno if it's better in 0.10 either, but i am sure shepherd loses track of things in its current distributed form
<bjc>were it me, knowing almost nothing: the only thing i'd do in shepherd would be kick off a scrub on boot if i could detect a scrub was interrupted. otherwise everything else would be in a script run by mcron
<bjc>although, i guess mcron has its own issues with running tasks that were scheduled when the power was off. or at least there have been a couple people here recently saying that
<mirai>what happens for a non one-shot? service if I issue start on it and it's already started
<sneek>graywolf, efraim says: For your 'modprobe -r mt7921e' on shutdown I suppose you could have a service which depends on networking with something like #~(lambda #t) for the start script and your shell script (with a small sleep) for the stop script
<mirai>also, check for 'syslog (as a symbol) yields easier comparisons I think
<mirai>if you get a string instead, then it's obvious that it's a path
<mirai>in theory, we could perhaps unify the “logging arguments” of almost any service into a <log-configuration> record-type, which is perhaps a better interface but we can leave that for another time
<jgart[m]>and hope that someone reviews it quickly if they find the time
<graywolf>jgart[m]: Thanks for the tip, will try. The post is from January 4th, so the "quickly" part is probably not necessary :)
<jgart[m]>graywolf: Do you know the email to send the patch to for that?
<PotentialUser-90>I was wondering if some kind soul would clarify a thing or two about Guix.
<jgart[m]>I don't think we have a formal process like that for guix related projects that are not guix that go to email@example.com but I may be wrong.
<jgart[m]>PotentialUser-90: Rule #1 for irc: Just ask the question Rule #2 Use an irc bouncer to see if some one later responded to your question
<jgart[m]>If Rule #2 fails then repeat from Rule #1
<jgart[m]>You can also try asking questions on the mailing lists. guix-devel or help-guix are two good places depending on what you're asking
<PotentialUser-90>I was kind of trying to be polite, but I understand about the noise. I do not know abut the IRC bouncer, but I could not find it in the IRC logs.
<jgart[m]>The etiquette for irc is to just ask. It's an official etiquette somehwere in some old handbook by raymond something something forgot their last name (might have messed up their fist name also). Some hacker
<PotentialUser-90>The question is more of a detail, and is as follows: I was reading about the "guix shell --container" functionality, and I wanted to compare its ability to create an isolated environment with other tools, like Firejail, Docker, or Virtual Machines.
<PotentialUser-90>My first question would be something like: was the --container option built for security or for convenience, in your opinion?
<jgart[m]>I'm still learning the points in that etiquette guide myself also
<jgart[m]>i forget to apply them from time to time
<bjc>PotentialUser-90: i assume it was built for testing in isolation, but i wouldn't know for sure. i'm curious why it matters, though? you can use it for whatever purpose that suits you
<bjc>it's similar to firejail and docker, since they all use the same underlying linux kernel facilities, and a bit of a hybrid, since it's more ad-hoc than docker, but lacks the configurability that makes firejail popular
<mfg[m]>I'm getting the following cryptic error: ice-9/read.scm:126:4: In procedure read-expr*:/gnu/store/hk7xl3d7nszqa854p70bwz2833aajpy1-gcc-cross-sans-libc-arm-zephyr-eabi-12.2.0-builder:1:3339: Unknown # object: "#<". Has someone seen this before? This didn't happen before the core=updates merge.
<graywolf>Podman is nice, especially the "no daemon required" and "no root required" parts. And it's pretty much drop-in replacement for docker (at least for my needs), I don't have actual docker installed for many years now.
<graywolf>Aaand it does not mangle your ip tables ^_^
<bjc>same. i really like being able to run containers sans root
<graywolf>That reminds me, I wanted to write a guide how to get it working under guix
<jgart[m]>When will someone implement the Podman equivalent for the Nix daemon?
<bjc>a lot of what i used to use containers for i do with plain old guix now, though. it was one of the major draws of guix for me
<graywolf>ACTION adds yet another entry into the todo list
<bjc>graywolf: do you have rootless working? with elogind?
<graywolf>Arguably I believe it should be default, since v2 is not really useable under guix (yet?); Also trying to get v2 working with guix is on my list as well, last time I asked around here I did not hear any actual technical blockers on that front
<bjc>since podman can run rootless, is there any technical reason guix-daemon can't do the same thing?
<PotentialUser-90>So elogind would be running in the container, right? Running GUI tools inside containers is possible or easy?
<bjc>i think you'd still need the daemon to sequence the store across multiple commands, and provide isolation so you don't accidentally bork your whole system. but i don't think you'd need root to get that environment, and since the store only uses one user you don't even need sub[ug]id files
<graywolf>Nah, elogind is running on the system. Problem is that is tries to use cgroup v2, but some cgroups are already created by guix. And podman cannot handle "hybrid" setup (some controllers v1, some v2)
<jgart[m]>bjc: someone actually implemented a daemon-less nix like POC in janet already
<jgart[m]>but it is abandoned now as they got bored and are now working on something else probably
<bjc>PotentialUser-90: you don't need elogind in the container, or much of anything else, really. if you want to run gui apps you need to share your .x11-socket or the wayland one, along with the right environment variables. there's stuff for that either in the cookbook or regularmanual
<graywolf>But I guess I will have to move over one of these days :/
<bjc>everything option is bad, but at least it's not windows?
<PotentialUser-90>pulseaudio is typically uncooperative, in my experience, so I do not feel surprised.
<unmatched-paren>graywolf, bjc: huh, although i've never seriously used libx11 or libwayland, i've always had the impression wayland is cleaner
<bjc>i made pulseaudio work for firefox in a container, but it's a lot of hassle, so i don't bother with others
<graywolf>Yeah, I *still* did not figure out how to convince windows to stop restarting for updates. I hate it so much. Luckilly it's basically just a gaming console for me these days.
<bjc>unmatched-paren: wayland certainly claims to be cleaner. the reports from actual devs seem to be that it's a mess and not really a real improvement over x in most ways
<graywolf>unmatched-paren: My problem with wayland is that every single compositor (is that the correct word?) has to implement everything.
<graywolf>Sure, there is wl-roots, but for example gnome does not use it. So if you need feature X, let's hope your compositor supports it, otherwise you are fucked.
<mirai>graywolf: you can piggyback on libweston or $somelib
<bjc>yeah, the wayland protocols stuff just seems awful
<jgart[m]>I'll just use sway as an end-user and let them deal with the little clean monsters they've created...
<bjc>i use sway and mostly don't care. but i'll note that almost everything i use is actually running in Xwayland
<futurile>Q: is using the `guix upgrade --keep-going` safe, will it figure out to only upgrade packages that don't break the dependency tree? In my case I'm 'upgrading' a manifest and it keeps failing because some of the packages won't build - but not upgrading anything is sort of annoying.
<minima>hi, pandas seems to be at version 1.4.4 in guix but i understand upstream is 2; i imagine that updating pandas takes some serious effort, anyone knows if there's been any work in that sense already?
<bjc>futurile: remember that you can always roll-back if things go horribly awry
<PotentialUser-90>I never tried wayland. I was thinking of giving it a few years to mature, and try it when it becomes a drop-in replacement for xorg. I would never know if some behavior is a bug, a feature, or "I'm holding it wrong".
<bjc>my experience with wayland is that it depends a lot on your compositor. with sway and gnome it seems to work pretty well. with kde it's a disaster
<bjc>not that i've used plasma in a year, but *every* upgrade for years was "wayland works great now!" and it was always awful
<rekado>ACTION noticed that commit hash abbreviations are pretty long now
<jgart[m]>Do you know when you're holding an apple the wrong way? Just go with that instinct regarding sway and read the favored manual
<graywolf>Also it's fun with nvidia GPUs, but wife had a lot of fun trying to set DPI on the built-in laptop monitor
<porcupirate>panosalevro: "../source/src/vector/vrle.cpp:129:32: error: ‘numeric_limits’ is not a member of ‘std’" - the last time I saw something like this, the compiler was using the wrong version of c++.
<minima>hm i entered a guix environment "guix shell --pure -D guix help2man git strace"; run "make clean && make" within my guix checkout, then finally "./pre-inst-env guix search hello" - i get this error: "guile: symbol lookup error: ...-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE"
<lilyp>newer versions tend to be written for newer compilers
<panosalevro>lilyp: maybe i should just wait a couple of days then :)
<panosalevro>(is guix ever going to be "bleeding-edge like arch?)
<lilyp>you might be waiting for more than a couple days, though
<lilyp>telegram is notoriously difficult to upgrade
<zamfofex>lilyp: Turns out it takes nearly forever to wait for things to build and be verified when you update either GCC or glibc, and when it fails you have to wait all that time again before you can know if your changes fixed anything, so people are generally a bit frightened to work on them or updating them.
<zamfofex>lilyp: I wish that could be rectified somehow, though I don’t exactly know how. Things seem to be fairly intertwined on the bootstrap level, so you can’t update glibc without waiting for part of the bootstrap process to happen again, for example. I wish it were more streamlined, so you could update the glibc and rebuild *only* the glibc package.