IRC channel logs
2023-04-29.log
back to list of logs
<mirai>apteryx: I've done reviewing the series, some comments: hold 1/17 for now <mirai>did the series pass make check-system TESTS="mpd mympd" ? <bjc>can we just remove the .hwl files packaged with python after the test, but before install? might give a nice way of unbundling setuptools <vagrantc>anyone able to guix pull successfully on aarch64? <vagrantc>last success i had on this machine was early november with 733fba28dfabfb34bd205d7386e4c053627e6428 <sime>hi, can anyone imagine why gst-libav is not an input of epiphany? no youtube video can be seen without it. it seems like that bothered no one before <vagrantc>sime: if you install it, does it work then? <bjc>a lot of distros give you choice in what codecs and implementations of them you want to install <vagrantc>in general, optional plugins are installed at the user's discretion <bjc>the problem being it can be hard to figure out which ones you want <bjc>guix does have a how-to guide, at least <podiki[m]>trying to update godot and doing some unbundling...I include our eudev but from a file there doens't find "macro.h"... <sime>can you link the guide please? <bjc>i don't know if it has what you want, but patches are very welcome if you can dedicate that time <sime>i would consider codecs for youtube to be so essential (at least for (non-technical) gnome-web users) that they should be installed by default <bjc>by “optional”, i think the strictest sense is met: the code itself doesn't require them to function <bjc>we could have a ‘recommended-codecs’ package or something <sime>still, the first impression when using gnome-web for me was "oh that looks broken, better stick to firefox/icecat" <vagrantc>oh, my guix pull issue seems to have eventually resolved itself ... it was stalled out for $forever <bjc>is this as epiphany-specific thing? when i watch video i do it flatpak-firefox, so i have no idea how other things work <sime>icecat plays videos out-of-the-box, so yes, epiphany-specific <vagrantc>only video browsing i used on guix was maybe icecat to watch some talks ... maybe even hopped on big blue button for videoconferencing once ... but haven't done much of that lately <bjc>sime: you can always submit a bug report with the name of the codecs you think are a neccessary <apteryx>mirai: oh, I should try check-system mympd, I had forgotten about that <apteryx>mirai: hm, mympd defaults to port 80 <apteryx>mirai: a systemd style socket-activated service could run on low ports I guess? <apteryx>perhaps that's the future direction for mpd/mympd, to allow running on low ports while offering the most control on the user/group used <apteryx>and so far I can have mympd on 8080 for http and 443 for https <mirai>I'd look into using posix capabilities? <mirai>apteryx: btw, empty-serializer also works as a literal <mirai>so something like (... empty-serializer (sanitizer …) ) works <mirai>it's not deprecated otherwise you'd get a message <spiderbit>hash tables are meant to torture people right? <spiderbit>they pretent to have no order but loop creates a order <apteryx>mirai: I see this now. So there's two forms accepted. Using parens everywhere feels a bit more consistent, perhaps? <ChocolettePalett>Is it possible to somehow remove "ci" substitute server from default substitute server list and instead only use "bordeaux" substitute server? <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. <jackhill>if it's rejecting the bordeaux substiitutes, then that's a different story and we'll there will be more debugging <jackhill>ChocolettePalett: ah, that's good. Definitely hope it helps <mirai>apteryx: I understand it but it's not exactly the same thing <mirai>technically when you do (serializer empty-serializer) you're passing a procedure <mirai>which is something like (const "") <mirai>it doesn't look like it makes a difference now but it will if serialize-configuration accepts things like transducers (once I figure out why my gexps are failing here) <apteryx>actually we have a test for that scenario: config-with-proc <apteryx>I think it works because empty-serializer is a defined as a proc <apteryx>but the literal would be more efficient :-) <jackhill>cool, I just closed an issue I opened two years ago! It had been fixed for a while thanks to a new upstream version, but our issue had been left behind. <podiki[m]>will need improvements to unbundling and seems it wants to dlopen everything so i just ld_library_path wrapped :( <podiki[m]>(or will have to, just did it when running for now to see if it works) <apoorv569[m]>The python binary in Guix is called python3.. Is there a way to symlink it to just python? <apoorv569[m]>I'm using poetry to manage my python project and it looks for a binary named python. <podiki[m]>python-wrapper is the package you want instead <apoorv569[m]>Ah! so only need python-wrapper or both python and python-wrapper? <podiki[m]>(you can check with "guix show python-wrapper" and the description provides more details on this) <podiki[m]>welcome (i only learned about it much later too) <podiki[m]>ah, maybe godot's dlopens aren't so bad, they have some wrappers and that might be the main place to patch the dlopen call...tomorrow <apoorv569[m]>Description only mention to not install python alongside.. <podiki[m]>tree -aC $(guix build python-wrapper) is the quick way i check <apoorv569[m]>Actually the command pip is available right with the python package <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. <rekado>the default value is %base-firmware <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. <lilyp>Why would you upload an audio file into a text chat? <lilyp>probably maybe, but these things can be checked at use time <mirai>sure, but wouldn't it be cleaner to do so at configure time? <ofeeg>Is that audio file just a voice message? Is it a meme or something lol? <lilyp>mirai: possibly, but that would hurt the composability of transformers <lilyp>i.e. ((compose b a) mpd-service) != ((compose a b) mpd-service) <mirai>is it because b∘a might yield a valid configuration even though either b or a alone might not? <mirai>or their commutation would be incompatible as well? <lilyp>suppose b makes the user part of the audio group and a adds a plugin that requires that to work <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? <bjc>i think you can provide it a symbol <mirai>it does work if I use (start 'my-action) <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 <mirai>one-shot immediately ignores everything <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 <mirai>it's going to come in handy for things like btrfs/zfs scrub <bjc>that should be done in mcron, i think <bjc>why? it's how i've always done it <bjc>you mean like if it's still running? or a resilver is in progress? <mirai>an interrupted run for example <bjc>zfs is smart enough to deal with that. not sure about btrfs <bjc>but you can always encode that is a script rather than call scrub directly <mirai>if you naively schedule btrfs scrub start and you get a poweroff or something that makes the test interrupt <mirai>subsequent scrub starts won't do anything <mirai>my goal is to have it handled intelligently within a herd service <bjc>you still have to kick it off periodically, right? so you'd have mcron do a ‘herd start btrfs-scrub’? <mirai>so even system shutdowns will cleanly call btrfs-scrub stop <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 <mirai>is it actually being ignored by shepherd? <bjc>one shots are tracked differently. you should be able to run them over and over again without issue <bjc>i dunno what happens if you start two at the same time, or one while a previous one hasn't finished, though <lilyp>mirai: if it's already started, nothing should happen <lilyp>same if it's starting unless you find a race somewhere <mirai>regarding the shepherd hang on the same socket thing, I'll send a report to bug-guix in a bit, can you PM me your mail addr so I can CC you to it <bjc>so i just ran some tests: the shepherd hangs until the ‘start’ procedure finishes, so you can't run two one-shots at the same time <bjc>so you shouldn't have to worry about that, at least <bjc>since there's a listen queue on the socket, the second request just waits until the first is done, as long as you don't have some exogenous time-out <mirai>apteryx: do you have an easily accessible checkout with the mpd changes? <graywolf>Hello guix :) Where should one report typos in the official blog? I looked around but did not see any link/contact specific to that. <sneek>graywolf, you have 1 message! <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? <graywolf>jgart[m]: Hm, I would have assume there would be a address per repository, but will send it there <jgart[m]>some sourcehut projects do a similar thing where you have one mailing list for multiple projects <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 guix-patches@gnu.org 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 may go reread that now myself. Has some good points <jgart[m]>> First, immediately state your question in detail. Do not say, "hi, is there anyone around?" or "can anyone help me with a JavaScript problem?" ... etc <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. <bjc>PotentialUser-90: yeah, they all use cgroups internally <bjc>guix does have a vm option, if that's something you're interested in, but it's a lot more heavyweight, obviously <graywolf>Typical thing that is said in these situations is: `containers are not a security tool'; If you aim for security isolation, VMs are better (and yes, much more heavy). <mfg[m]>this may have something to do with g-exps (which i don't know much about) as they seem to have been introduced in cross-base.scm now (unless i just didn't notice them before) <civodul>mirai: i don't understand the code, but my guess is that you need to clarify what code goes in which stage <bjc>graywolf: i understand the advice, but i think it's too draconian. containers can be an element in your security. as always, it depends on your threat model <bjc>sticking discord in a container so it doesn't spy on you, but gives you convenient access to it, integrated into your desktop, makes sense to me <mirai>civodul: the naive code I wrote (that doesn't work) yields: In procedure string-append: Wrong type (expecting string): #<gexp (format #f "~a ~s~%" #<gexp-input "user":out> #<gexp-input "mpd":out>) gnu/services/audio.scm:163:4 7f686e3f01e0> <mirai>because the reducer is seeing gexps <mirai>essentially yes, the gexp-ungexp boundary <bjc>PotentialUser-90: i'm not sure, honestly. i think they relate in some way, but i've never used the images facility <PotentialUser-90>graywolf I agree with that. At the very least they do not share the kernel. Furthermore, there is no direct hardware access, I believe. <graywolf>PotentialUser-90: In general I would say you get as much security from --container as from for example podman. If that is enough for your use case is something you need to figure out :) <bjc>i'd agree with that assessment <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? <the_tubular>graywolf only bad part is that auto-updates aren't working without systemd. <bjc>how'd you deal with cgroups? custom kernel args? <graywolf>bjc: `elogind.legacy_elogind_cgroup_controller=1' <bjc>that's on the kernel command line? <bjc>ok. i'd heard about that already (maybe from you, even) <bjc>i switched to seatd/greetd to get it working <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 <bjc>elogind *was* part of systemd. it was surgically extracted for non-systemd systems <graywolf>bjc: The "discord in the container" you mentioned, is that with wayland or x11? <bjc>i do it with x11, since i started that practice when i was on x11 <bjc>you should be able to do it with wayland, too, but i've never done it <graywolf>Do you sandbox the x11 somehow or keylogging is acceptable risk? This is the one part I never properly figured out under x11. <bjc>the hardest part is pulseaudio (of course), but you can share that socket and cookie, too <bjc>i accept keylogging is possible <bjc>i should move everything to wayland, but i don't think discord is that level of malicious. might be, though! capitalism loves spyware <graywolf>Yeah, I just like.. don't like wayland. I think the design is... bad. <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. <bjc>--keep-going should be safe <mirai>graywolf: I read that more as an argument for profile levels in wayland <mirai>kinda like what you have for codecs <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 <bjc>(not that it should) <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 <unmatched-paren>that said, i have only used gnome and sway with wayland; i believe you when you say it's a car crash on KDE... there must be quite a lot of code to port in there <graywolf>I'm pretty sure nvidia is to blame to some degree as well; but it worked with x11, so ¯\_(ツ)_/¯ <unmatched-paren>i think one argument for wayland's cleanliness is that it uses built-in kernel graphics drivers <unmatched-paren>rather than the xfree-whatevertheywerecalled packages... so i suppose the kernel drivers might have a few problems here and there :) <PotentialUser-90>minima Looks like 2.0.1 was released recently. Is pandas and other Python packages usually behind version-wise on Guix? <Guest19>I always wondered why KDE is not a DE option. I don't use it anyways but what exactly is the reason it is not currently supported? <minima>PotentialUser-90: hey, thanks for checking; well, yes, i think there's some natural delay between upstream and the distro package, as it's usually the case <minima>i see that 1.4.4 (current guix version) was released in 2022/08 <graywolf>Guest19: afaik it is in the "no one did the work required" category <jgart[m]>I had ChatGPT write a Guix package for me last night. I have to say that I was very impressed. <bjc>Guest19: i think it is an option now? but yah, it's a lot of work to port kde <unmatched-paren>but semi-recently someone did all the work to add all the kde packages <jgart[m]>I do think that ChatGPT is confused about bags also though... <bjc>guix has plasma-5.25.5 packaged <minima>i'm in the middle of a "guix refresh --recursive python-pandas" - i've started laughing convulsively already <jgart[m]>or doesn't have a deep understanding of them <Guest19>Ah okay I understand. That means there is no difficulty in it as of complexity but it is just tons of packages and therefore a lot of work to get it to work on Guix? <lilyp>minima: guix refresh --recursive sadly recurses in the wrong direction <Guest19>me neither but maybe someone wants to use it. <lilyp>it goes up the tree until stage0 rather than down towads the leaves <minima>other than that - i've the feeling that updating pandas might be a rather laborious task <lilyp>depending on your language --help would have been useful <PotentialUser-90>Building new packages by just updating the references to the source... is that likely to fail most of the time (say... for a minor revision)? <lilyp>it may be, but it also might not <bjc>most of the time a patch level update is just bumping the version and changing the hash ime <lilyp>if the devs are reasonable, you don't need --recursive and can do things locally <minima>ok, worth an attempt then, let me try (very skeptical i'll be able to do it, but let's see) <porcupirate>Hey guix, I'm trying to configure a printer on a guix system. Both the cups web interface and lpadmin fail when I give correct credentials. Is there anything I need to do to make it work? <porcupirate>When I try to print something, this is added to the cups error log file. pam_authenticate() returned 7 (Authentication failure) <lilyp>being member of the lp/lpadmin groups helps <Mari[m]>guix system: error: service 'guix-daemon' provided more than once <lilyp>what does your config.scm look like? <lilyp>well, if it doesn't even have one, there's no way it could have more than one <bjc>doesn't %base-services include it? <lilyp>you can define it iteratively through guix package transactions <lilyp>yep, but any profile works for that really <lilyp>though note that non-default profiles do include some clutter <PotentialUser-90>Do you mean that I can interactively define any profile? But in that case, how would I change between them, if I cannot reference the fine that holds its definition? <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++. <porcupirate>Modify the package in question to use a specific version of c++. I think it should be a compiler option. <panosalevro>hmm.. i think i get the error with more than one package though. <lilyp>it's probably headers leaking <bjc>i think i saw something in the c++14 spec that said a bunch of those types got moved. you may just be able to add a header file to get them back <bjc>alternately, you can probably just tell the compiler to use an older standard <lilyp>that won't help, the standard never intended for those leaks so it's a-okay <lilyp>source: am currently fixing ppsspp, which used c++11 <lilyp>the best fix is upgrading them <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 <lilyp>doesn't really matter; guix itself uses gcc 11 everywhere regardless of the gcc you use <lilyp>if you mean rolling back gcc as a distro, that'd be a world rebuild <lilyp>i do wonder why we picked 11 instead of 12 or 13 tho <spiderbit>So I wonder why I have so much issues outside of gnome, 1. suspend works only in gnome and 2. nautilus in gnome shows me my nextcloud account to mount, but not nautilus outside of gnome. <bjc>i really need to figure out thet suspend weirdness. it drives me crazy <panosalevro>lilyp: can i upgrade guix whilst ignoring some packages? so that the rest of the system can upgrade <lilyp>spiderbit: the nextcloud stuff might be tied to gnome-online-accounts in which case good luck trying to get those outside of gnome <lilyp>for user packages there's --do-not-upgrade=regexp <civodul>mirai: it may be a case when you need to stage string-append as well; as in #~(string-append #$a #$b), where a and b are both "string-valued" gexps or lowerable objects <jpoiret>lilyp: iirc the change to gcc 11 as default toolchain was made quite some time ago on c-u <spiderbit>well it's about xserver so I don't see how that could help with their of this problems <lilyp>ahh, we did freeze it some time ago, didn't we? <spiderbit>the problem seems a bit that there is no gnome-settings-daemon or no executable for it <jpoiret>there wasn't any official freeze, but I guess no one bothered to switch gcc or glibc again on the branch <spiderbit>I mean there are other ways to get access to nextcloud... even then I can't use the remote nextcloud in emacs which would be anoying, but I wonder if it's connected to my suspend-issue. <spiderbit>ohh I think I stumbled on a mentioning of my suspend bug: <mirai>civodul: hmm... I wonder if it would be still accurate to call this a "transducer" if I do #~(reducer #$(list-transduce … rcons)) instead <bjc>spiderbit: i thought your issue was that the system wouldn't go to sleep in the first place? like your displays would turn off, but the power light would remain on on the chassis <spiderbit>well if you read the text there it sounds like it <bjc>oh, i should keep reading =) <mirai>technically it would be a procedure that accepts a “combining” procedure and SRFI-171 compositions <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. <spiderbit>like suspend not always crashes more so 50% or so <bjc>what's the gpp device? <bjc>you can use lspci to look at that node <spiderbit>00:01.7 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] <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. <bjc>no idea, and ddg is no help <spiderbit>I can try to echo it and see if my system crashes :D <spiderbit>but there are other gp active in this example <spiderbit>well did a normal suspend it worked but gpp0 is still disabled <bjc>that page says you should write that value if gpp0 is already enabled, so i'd assume it disables it <bjc>ah, writing toggles it, so indeed, it'll disable it if its already enabled <bjc>i only have xhc set to “enabled” <spiderbit>ok first crash but I did not change anything with the wakeup thing <tremon>hi all, how do I get git from guix to support https certificates? so far every git clone ends in "server certificate verification failed. CAfile: none CRLfile: none" <tremon>repeating the same git clone command from the host OS (debian) works fine <spiderbit>00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 1 <spiderbit>00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 2 <spiderbit>hmm that echo GPP6 didn't crash my system at least <spiderbit>now the system never started blinking... but it woke up anyway <bjc`>well, disabling XHC didn't work for me, but i did notice that my usb dac sent a fraction of a second of audio twice, so maybe it's been the problem <jpoiret>zamfofex: whenever you update glibc you have to rebuild gcc iirc <jpoiret>no but i mean i don't think it's something we can avoid <zamfofex>I mean, if GCC has to be rebuilt for the sake of other packages, that’s fine, but I remember it having to be rebuilt when running ‘guix build glibc’ itself too. <zamfofex>Like, there were a few handful packages that had to be rebuilt with each small change, but they were foundational packages that took several hours to rebuild. <spiderbit>well tried to enable all other GPP things and even enable the one they suggest to disable <jpoiret>zamfofex: a full gcc depends on glibc <bjc>spiderbit: i'm using the libre kernel, so no firmware here <jpoiret>though, when you do `guix build glibc`, you're building the commencement glibc as well as the "full" one <jpoiret>spiderbit: please do not link to nonfree software in this channel <bjc>spiderbit: i've only ever run guix on this machine <jpoiret>zamfofex: you should instead do `guix build -e '(@ (gnu packages commencement) glibc-final)` <spiderbit>I would kept it non-guix but they think it's probably upstream and jpoiret uses linux-libre with the same problem but sure I don't have to link to stuff <spiderbit>the funny think is that gnome suspends repeatable without problems... therefor it does'nt really sound like a kernel issue <jpoiret>yewscion: Sorry I haven't got back to you on the agda update. Just got back to working on it, and I think I have a working agda-build-system that is pretty generic <jpoiret>ie. package definitions for agda-stdlib and agda-cubical are very straightforward, and I added a search-path to agda to handle library dependencies via a patch <panosalevro>if i change my username in the (user-account) field, will i break my system after a system reconfigure? or will it just rename my user? <Guest19>it doesnt delete home dirs (if it actually renames it, I dont know) <Guest19>oh yea sure, was just a quick dirty answer since I doubt you get an actual answer. <Guest19>do you use gnome or which one do you use? I could try in a vm and see if it breaks but would take a while <panosalevro>Guest19: no please don't waste your time, ill try it out eventually <lilyp>you wouldn't break your system, but you might break things for the user that existed previously :) <Guest19>panosalevro well I wouldn't call it wasted time since I think it is actually interesting if it handles that edge case. Though I appreciate it. <lilyp>also, you probably won't get the same uid for the new user