IRC channel logs
2025-01-23.log
back to list of logs
<ieure>TheWalkingDad, Thanks, same here. <eikcaz>I wrote some simple guile code that makes HTTPS API calls to automatically update DNS records. It's super helpful for maintaining a domain on a dynamic IP. Is that the sort of thing to try and merge into Guix, or should I go through the hassle of packaging that one file seperately as a guile module and call it from a gexp? <the_tubular> I can't answer, eikcaz, but I'd be interrested of taking a look! <eikcaz>The code is DNS-provider-API specific, so it seems a bit weird to bake that into Guix <the_tubular>Maybe, there is stuff like awscli packaged in guix too <eikcaz>part of me feels like mechanics dealing with a closed/centralized API shouldn't be baked into Guix itself, but that a package would be fine. The other part of me feels like it's too damn simple to worry about that kind of thing, and DNS was always inherently centralized yet we use it anyway (until GNS can save us) <lockbox____>Looks like you should make that a guile library you can import, then add that as a service <vhns>Hi. From what I can gather reading the documentation, certbot-service-type should automagically extend the nginx service to do proper redirection of .well-known/acme-challenge for the domains listed in it and in my nginx configuration, right? I ask because I currently have a relatively simple configuration yet LetsEncrypt keeps on telling me it got 404s for the challenge. <vhns>In certbot's logs I can see that it does create the needed directories under /var/www, it's just that the redirect isn't being done properly <mange>Hmm. I would have expected that to work. Have you restarted the nginx service after adding the certbot one? <mange>Like, if you had the nginx service running, then reconfigured the system to include certbot, then you need to restart nginx to pick up the config that certbot added. <vhns>mange: there are a couple of bugs I have gathered so far: NGINX's "listen ssl" directive *requires* a domain name. It seems, at least if you have more than one domain (example.org & www.example.org), that it does not add any domain name to that directive. The second is that NGINX *requires* a ssl-certificate and ssl-certificate-key directive which certbot-service-type does not add/extend to the service either. <mange>My understanding is that the certbot service adds a HTTP (no S) server block for each of the domains you ask certbot to manage to handle /.well-known, and it expects you to define the HTTPS blocks for yourself. <vhns>from what I understood, reading the docs, those were also expected to added by the extension <vhns>I'll give it another whirl before posting more in here <vhns>if I get a working config I'll post it, too <mange>So, in your case I would actually expect the nginx-server-configuration to contain a (ssl-certificate "/etc/certs/ratnet.servers.vhns.com.br/fullchain.pem") and a (ssl-certificate-key "/etc/certs/ratnet.servers.vhns.com.br/privkey.pem") <vhns>turned out the issue was indeed between the keyboard and chair <mange>You say that, but the fact that there's no example like that in the documentation is clearly a flaw. If you've got time to add it and send a patch I'm sure it would be appreciated. <vhns>I'll give it a go tomorrow, very late night 4 me <vhns>has anyone been getting sudo to segfault? on commit 4241a5a4688e8a118b2f66423abd3ef8baae98fc <vhns>I know that video over text and incomplete info are very much frowned upon here, but I'll just be posting this before heading to bed in case it might interest anyone: https://i.nuuls.com/fUHJT.mp4 sudo segfault and relevant system configuration: https://paste.debian.net/1346406/ all on commit 4241a5a4688e8a118b2f66423abd3ef8baae98fc <allana>Hi, anyone else facing this issue, and has anyone found a solution other than what is suggested? "Emacs fails to start with "List contains a loop" error" (https://issues.guix.gnu.org/75709). I recently ran a guix pull and reconfigured my pretty minimal guix home. <jaft_r>ArneBab: did you have any further luck other than your ~EMACSNATIVELOADPATH="" emacs~ workaround for the "List contains a loop" error you ran into? allana has stumbled into the same issue, unfortunately. <allana>I actually didn't quite understand the suggested fix in the mumi either, which was "try replacing nconc with append" <jaft_r>allana: honestly, I'd assumed that recommendation had been specific to Thiago as someone else mentions, "You quite likely have redundant code in your shell init scripts," but I can't find any attachments or repo. references so I guess not. <daviwil>Anyone else getting 502 errors when running `guix pull` right now? <allana>jaft_r: thanks. I am guessing other guix home users might run into the same problem. I'm fine using an older generation for now but I think there is a problem and I don't know where to start looking to fix the issue at present. <daviwil>Strangely the channel URL can be accessed directly in a browser with no trouble, so I'm not sure what exactly `guix pull` is tripping on <jaft_r>allana: yeah; that's definitely fair. So I think it's in the source code, itself. I notice the function ~emacs-subdirs~ has ~nconc~ in it. Unfortunately, not sure what it means; are you running on a foreign distro? <daviwil>Seems that Guix channel is working again <hapst3r>after running `guix pull` and updating my packages, when running `emacs` from the command line I am prompted with "List contains a loop" with a long list of packages 'native-site-lisp' mentions (https://paste.debian.net/1346423/). I am using aot native compilation. Any idea how this is caused and what I can do to sort it out? <dariqq>tried to update a python package and it now depends on rust. Why does cargo have to be so annoying and special with the rust dependencies which makes things almost impossible to package when the buld system is not cargo (but meson or python) <sneek>Welcome back dariqq, you have 1 message! <sneek>dariqq, lfam says: Any ideas why I'd be unable to configure CONFIG_OF off? No matter what I do, it always turns on, and I don't even get asked about when doing `make oldconfig`. It's just automatically set to Y <allana>hapst3r: I am facing the same issue, and asked a similar question a little while earlier. I expect there will be more of us today <jaft_r>daviwil: I'm no longer getting a 502 error but trying to do a pull causes a "the index is locked; this might be due to a concurrent or crashed process" error message; d'you see anything like that? <daviwil>Not sure about that, it seems to be working fine for me now <dcunit3d>is there source for the Guix Refcard? i looked in the guix/guix-artwork repo <futurile>you know it's going to be a tough day when you're on the third cup of coffee and your brain _still_ feels like a piece of damp string <efraim>I drink my coffee out of a half liter beer mug <jjba23>hi all, i have a weird bug in one of my computers, which <jjba23> does not happen in the other one. i have cleaned the <jjba23> store (guix gc) in several ways and several times, and <jjba23> it's keeps happening. I get a "error parsing derivation <jjba23> `/gnu/store/......-asoundrc.drv' expected string <jjba23>trying to delete this from the store with guix store gc --delete does not work since it says it still is alive <Rutherther>Yes, you need to also delete what holds it there - use gc with --referrers argument <Rutherther>If full gc doesnt clean it, it means a gc root points to it, ie. a profile <jjba23>so when looking at referrers it goes from audiorc -> files -> home <jjba23>and yeah a couple of full gcs didnt help <jjba23>can i just do guix gc --delete ...home <Rutherther>No you cannot do that, you need to remove the gc root. So use guix home delete generations <Rutherther>If you dont need any older home gen, just do a full one, otherwise specify which you can delete. Those should of course include this store path <jjba23>also not working.. but thanks for the tips <jjba23>and when running guix home i get a warning, could not determine origin of current system <jjba23>ha wait found the problem , if i comment out the pipewire service for my user it works <jjba23>so without pipewire, my guix home reconfigure works, but with it, as of latest commit in guix, it wont succeed and gives me that derive thing <Rutherther>And its only for that one because that one hits this corrupt derivation <Rutherther>Have you first tried to repair it through gc? That is always the first step, before trying to delete it <jjba23>yes i did, and it fails to repair <Rutherther>If it doesnt work, you delete it, as I was saying g - first the gc roots for the profile and then gc for the store files <jjba23>could you tell me what those commands would be ? <Rutherther>First guix home delete generations, then guix gc. That is if you are fine with removing all generations and all store files not gc rooted. If not you will need to use arguments to specify the generations <jjba23>thanks a bunch Rutherther that solved the issue and now it all works and builds properly. i will try to clean generations more often and doing gc. is there something i can watch more careful to avoid corruption? i have stable(ish) network, and SSDs <Rutherther>No, there is nothing you can do. Disk corrupt ion is not caused by user usage (except if you were to kill -9 guix daemon, disconnected disk during usage or forcefuly shut whole computer down) <hapst3r>dariqq: when I try to open the issue, I run into a gateway timeout. <efraim>does anyone have the bug number for the aarch64 svg issue? <apteryx>is this really the right email for Guix translation issues? Signalez toute erreur de traduction à : traduc@traduc.org. <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, ArneBab says: did you see the request by lloda for a test for https://bugs.gnu.org/67255 ? The code looks good to me, too, so with a test added (and if all tests still pass) I think it’s good to go. <apteryx>I might consider adding a test for it, but I note there currently isn't any test for define-library <apteryx>is it possible to match on the whole path with 'guix locate' ? <apteryx>I tried the glob option, but it seems to still match only if the file base name contains the pattern <dariqq>anyone knowledgable of python packaging around? I am trying to inehrit from a package using pyproject-build-system howver it seems to use pyrthon-build-system instead (unless I specifically also set that) <Rutherther>dariqq: inherit is much more simple, it just gets all the attributes and copies them, it doesn't have special behavior for specific structs or specific values of fields. So what you're saying it by itself changing from pyproject-build-system to python-build-system is impossible <dariqq>Rutherther: try guix build -f this : https://paste.debian.net/1346449/ , i get an error that #:test-flags is not a valid keyword for python-build (which is correct but it should be using pyproject-build) <dariqq>hmm it works as expected on another machine <Rutherther>this package has been changed to pyproject build system 3 days ago <dariqq>Rutherther: omg thanks. It seems I still had the old one. But when I evald the code in the repl i was using my up to date checkout. I thought i was losing my sanity <dariqq>ACTION updates their system and tries again <dariqq>heh that fixed everything :) thanks <graywolf>Hello Guix :) I am looking into replacing mcron with shepherd timers (seems to be the new hot thing), but the document seems to not mention how to hook it into an email. <sneek>graywolf, you have 2 messages! <graywolf>How do I do the typical "if non-empty output, send via email" the crons usually do? <gabber>i try to procedurally generate shepherd actions, but https://termbin.com/z47t results in "Unbound variable: args" when invoking `herd FOO-ACTION foobar-service' <Rutherther>gabber: you need to ungexp the "args". Otherwise args will just end up in the target shepherd service scm file <gabber>ahhhh, so `#$args' inside the `#~(lambda ...)' <graywolf>Same thing you have for #$(django-deployment-configuration-deployable config) <Rutherther>but if you were to put in static arguments it wouldn't <trev>hi guixers. I noticed that the guile package doesn't have guile-gnutls in its dependency list, but if you use the build in web client it seems to require it. I am on a foreign distro so this might not be noticeable on guix system. Is this normal? <gabber>Rutherther: i didn't choose cons by accident ;) <Rutherther>other than that you might have to quote the ungexped args <graywolf>trev: I assume so in order to keep the bootstrap dependencies low. I encountered same issue on macos. <graywolf>Rutherther: oh yeah that is a good point, I always keep forgeting about that. Since things like '"foo" and '42 works fine, I guess I could just defensively always quote? <trev>graywolf: i see. good to know <gabber>is about 2 levels of quoting and ungexping above my current state of mind (: <graywolf>gabber: The #$args just puts the args in there as they are. So if args are (42 43), (display #$args) turns into (display (42 43)) which tries to apply 42 to 43 (obviously does not work). (display '#$args) turns into (display '(42 43)), which is likely what you want. <graywolf>In general if the un-gexped variable is a list, you often want to quote it, otherwise it gets evaled, which often is *not* what you want here. <graywolf>For numbers and strings it does not matter, since "foo" and '"foo" both are just "foo", so in that case it works fine. <rhuijzer>Hi. My guix system is broken. Every guix command results in /gnu/store/xxx-guile-wrapper/bin/guile: symbol lookup error: /gnu/store/xxx-libgcrypt-1.11.0/lib/libgcrypt.so: undefined symbol: gpgrt_add_post_log_func, version GPG_ERROR_1.0 <rhuijzer>rollback is also broken and booting an older version from gnu grub gives the same result. Does anybody have a clue? <gabber>rhuijzer: the system boots, though" <gabber>Rutherther, graywolf: thanks, again! <Rutherther>rhuijzer: this usually means wrong library is being used instead of the one for the program. There can be multiple possibilities that cause this. First to check is, do you have LD_LIBRARY_PATH or LD_PRELOAD set? <gabber>so the system boots into the current generation, but all `guix` commands fail? <rhuijzer>RutRutherther: will check gabber: correct. the previous generations produce the same result <Rutherther>rhuijzer: unset it and try again. Generally, you shouldn't set it <rhuijzer>rutherther: Seems to fix the problem, thanks! Its for the dynamic linker, right? Wonder where it came from <gabber>rhuijzer: sooo vscodium set the variable for you and borked your system? or did you do that all by yourself? <gabber>(this might hint towards a bug in the vscodium package) <rhuijzer>gabber: might be vscodium yes, that's the only gui program that i've got open right now <rhuijzer>I will test further and create a bug report if reproducable <Rutherther>rhuijzer: definitely not something from guix channel itself. So either other channel or you must've set it somewhere <Rutherther>and yes, its' for the dynamic linker. The libraries coming from ld lib path will be preferred to the ones the executables were compiled against <rhuijzer>rutherther: it's not in my dotfiles or guix declarations. very odd. <gabber>rhuijzer: that's what your pastebin (i.e. what the LD_ path was set to) hints towards <Rutherther>yeah, vscodium is wrapped with ld lib path, unfortunately. So when using it you need to somehow unset it in the terminal / in codium the packages <gabber>can i set env-vars in (invoke ..) calls? or do i have to relay through a shell call? <rhuijzer>A bit stupid of me to not try running commands in a different terminal emulator besides vscodium, but it used to work fine. <gabber>rhuijzer: it happens to the best (: <gabber>also, you could've tried logging in/running with another user (e.g. root) <Rutherther>rhuijzer: it will usually work fine. Probably you updated to newer guix which uses new gcrypt lib, but haven't updated vscodium itself <rhuijzer>gabber: yeah I shoud've. But I was recovering from another related problem (disk completely full during guix pull) so I thought these where related and didn't test well enough <Rutherther>honestly it's really unfortunate vscodium is wrapped with ld lib path. But I suppose it was too much work to get it working otherwise <rhuijzer>It's a non guix package, so not in guix, but probaby a well used one <ekaitz>we don't have a large spanish community here do we? <ekaitz>if any spaniard wants to say hi... please feel free to. I just packaged the libraries for DNIe in my own channel... I may try to convince the police to make it free software <ekaitz>(DNIe is the spanish ID card, that is also a smartcard) <ekaitz>now, anyone has experience trying that kind of thing? fighting against the national police or government to produce free software? <ekaitz>what they have is almost compatible with opensc <futurile>Anyone willing to push a blog post for me? <janneke>sneek: later tell jespada: could you please consider changing your quit message into something that doesn't trivialize the importance of user freedom and doesn't normalize or encourage the use of freedom denying systems? <luca>Great blog post! Love the shoutout to void linux (feel represented ;)). Also love to see a lot of comments with which I both agree and disagree. Feels like guix is quite diverse in it's user base <luca>oh the patch above is the second part, that I didn't read yet, only the first part <luca>actually it's written in lisp I have no idea how to read this <futurile>luca: yeah, second one is ready to go - it covers how users use guix - whether they use nonguix and overall satisfaction - the comments are linked which are worth reading (if you have the energy) <futurile>luca: I agree with you - "guix is quite diverse in it's user base" - having read every single comment and put them into themes - it's a really diverse community of users and contributors <ieure>The one uniting factor of Guix users: We're all Sickos. <luca>futurile: Thanks for setting up the survey btw, and making the blog post! I think it ended up great. (though I won't read the individual answers. But thank you for doing so :D) <jlicht>(so there will be substitutes for some of the bigger leaf packages) <futurile>jlicht: who has permission/ability to add a branch to CI? <jlicht>hopefully, someone who lurks here :). I actually am a bit out of the loop wrt the nitty gritty infrastructure stuff, as well as the new merge trains <gabber>is it feasible/simple/doable to set environment variables within shepherd services? or how do we do stuff like that in Guix? <Rutherther>gabber: sure, make-forkexec-constructor even takes #:environment-variables argument <mirai>gabber: IIRC mpd-service-type can do this <gabber>does that also work in shepherd actions? <Rutherther>gabber: well you don't typically fork in action, so no, this doesn't work. You can of course just use setenv, but beware, it will set environment inside of shepherd itself as far as I know, so it's probably better to set it to previous value before the action exits. <gabber>context is a python script (Django's manage.py) that uses (or can use) an env-var to choose a settings module <graywolf>You will need to invoke the python script somehow, to just pass the environment when invoking it. Probably better then setenv tbh. <gabber>Rutherther: huh. this could be an option! but invoke is just a syscall without a shell, right? <graywolf>(invoke) from (guix build utils) is wrapper around `spawn' (or `system*'?). There is a syscall underhood ofc, but also a guile code around it. <gabber>graywolf: invoking the script is no issue - setting the env var is. <gabber>if there is no shell involved (but only a exec* call) there's no shell in which an env var can be set <graywolf>No, my point is you can use (spawn) which has #:environment argument. <graywolf>You do not need shell to set an environment variable, that is not how unix works <Rutherther>gabber: I don't know why it's important that it is 'without a shell'. To set env vars just inside of a subprocess, you can fork to a subprocess, set the env vars there, and then invoke what you actually want. You don't need a shell, it can be, ie. guile script <gabber>sorry, i think i got a little confused by fiddling with code for quite some time without success <graywolf>So, uh, I know I am probably annoying at this point, but while fork -> set env -> exec does work, if the goal is "run python script with environment varible", I fail to see while not just use `spawn'... <gabber>graywolf: you're not annoying, you're actually helping (: <Rutherther>if the environment variable is PYTHONPATH, I would suggest to wrap the script first, so that it's more 'guix friendly'. Invoking that then basically means to fork -> setenv -> invoke script <gabber>Rutherther: nope, it's DJANGO_SETTINGS_MODULE <gabber>the program is packaged and as guix friendly as it is <gabber>further context: i am packaging a Django application and creating a Shepherd process to manage it <gabber>while the env vars are set in the gunicorn process running the django app (towards the web proxy) the manage.py script uses a default value for the settings module - which of course can not be set at package build time <luca>does guix have a fediverse/mastodon account I could follow? <janneke>luca: nope, but search for #guix and you'll find some of us <ieure>luca, @civodul@toot.aquilenet.fr ;) <luca>I'm on a single user instance so following accounts is more effective than following tags (though I know this is a skill issue on my part :P) <chillininva>I reconfigured my system, and now xfce asks for authentication for the power manager whenever I try to adjust the screen brightness. Is there a way that I can circumvent this? 