IRC channel logs
2023-03-27.log
back to list of logs
<rekado>efraim: I’ve had no success with rust 1.54 on aarch64. The builds keep getting killed at various points. <efraim>rekado: I wonder if it'd be best to revert b178ca6676cd733c53dc64b2dfeffdb8e168ec3a removing more stuff from the rust-1.54 sources so that we can reuse 1.54 from master <efraim>aarch64 rust bootstrap is what's holding up the branch at this point <where-are-my-par>I'm trying to reconfigure my system but guix substitute signals an error <where-are-my-par>try to 'sudo guix system --fallback reconfigure path-to-cfg' but it keeps failing. The hypothesis in some bug reports is that substitute server is failing, so the client signals an error. I think that when using --fallback, it should simple build the package instead. <civodul>i wonder why goggles-bot gets disconnected eventually <civodul>jpoiret: hi! a Hurd update: all is fine, except EOPNOTSUPP in set-translator (hurd-boot.scm) when booting <jpoiret>civodul: if by ring a bell you mean that's exactly what I was stuck on, then yes :) <civodul>i checked the partition on Linux and it does support xattrs <civodul>so something's wrong on the Hurd side of things <jpoiret>i was worried it might just be an unlucky combination of mach+hurd versions <civodul>Mach doesn't know what a file system is :-) <jpoiret>although set-translator is a direct syscall? <civodul>well, "sys" call: it does a file_set_translator PRC <jpoiret>the thing is, it only happens for /servers/socket/1 <civodul>libc implements setxattr in terms of Hurd RPCs <civodul>what d'you mean "not the other translators"? <jpoiret>I think we set up quite a lot of translators in hurd boot <civodul>for me it stops here because Guile can't run without pflocal <civodul>so! commented out /servers/socket/1 from hurd-boot.scm (because in fact it's set up earlier), which leads me to the next problem <civodul>ooh, mach-defpager doesn't appear in "show all tasks" <civodul>most likely we're just unable to spawn stuff <jpoiret>basically the conclusion I came to was that spawn uses sockets, but /servers/socket/1 isn't up so we can't use them <jpoiret>oh, sorry didn't see the issue above, maybe it's worse than this >p <jpoiret>it might also be a problem with ext2fs blocking <attila_lendvai>is there a simple way in guile to append one more positional argument to an args list when keyword args are also present? <attila_lendvai>...or maybe i should just add it as a keyword arg with an assert, even though it's mandatory. <minima>hiya, i'm configuring lightdm on a debian - which i have as a thin-layer, on top of which most things are handled at a user-level with guix and guix home <minima>i ask lightdm to start my window manager (exwm) with a script <minima>the script launches xss-lock and then emacs <minima>apparently, looking at the logs, the script gets executed, but it fails as it doesn't find emacs in path (lightdm is installed at the system level and emacs is installed via guix home) <minima>i assume that, at some point in the start-up script, i need to parse my bash scripts or otherwise make the script aware of the guix profile paths <minima>am i on the right track, is there a canonical way of doing this? <minima>well it doesn't have to be ubuntu related... ok, sorry, bad joke <bjc>window managers/wayland compositors which are started by the greeter need to be installed at the system level, just like the greeter, for them to be found <_graywolf>Hi :) I've installed Guix on a foreign distro, and it seems to work however I get a hint "hint: Consider installing the `glibc-locales'" and I'm not sure how to get rid of it. The package is installed and environment set: https://paste.vpsfree.cz/9FJw36hR/raw/ . Any ideas? <minima>hm oh, that'd be a no-go then, as i'd have a preference for installing emacs via guix... hm <bjc>there's no connection between system-level configuration and stuff installed at the user level (either via guix home or guix package) <minima>bjc: thanks; i thought it was just a matter of exporting my user paths in the script so that (guix's) emacs gets found... but i then understand i was wrong <bjc>you could do it old school and log in via the terminal and startx your way to success. since you'd be doing it after log in, it can use whatever you've installed <minima>bjc: yeah, that'd be my preferred method, indeed, with the additional plus of having fewer moving parts and dependencies - however, i'm also having problems with the startx approach, which is why i was giving lightdm a chance <minima>i've been posting something about startx on #emacs <Lumine>minima: as a lurker in #emacs, I noticed you have dbus-launch in your xinitrc, it's not needed if you're on Guix to launch exwm <minima>Lumine: oh, super, i'll try again without that then! which i did already, but let me try again, thanks!! <minima>what would you advise, a simple 'exec emacs'? do you think i need to specify my init.el path? i'd suppose so... <Lumine>I only have `exec emacs` but I also have a bunch of other things which I'm not entirely sure which affect the actual launch <Lumine>Since I'm running guix and exwm without a debian overlay <minima>humble piece of advice: do not touch that "bunch of other things", as apparently is what keeps that together, ahah, no it doesn't work for me with the sole .xinitrc... <Lumine>But I also am running it with GDM, so it's not just startx with me... <jpoiret>minima: some DMs/login managers do first run your shell login scripts first <minima>ah i see, yeah, i've a guix image already that boots into exwm and works like a charm in a VM, i'm looking fwd to switching to a pure guix system but i need to figure out a couple of things re the kernel first <jpoiret>i really recommend using more minimal DMs as they're more understandable and don't magically do stuff behind your back <jpoiret>i got gradually sick of GDM just starting a bunch of stuff by itself <minima>jpoiret: hey, thanks, well i've been trying with a barebone startx as well as with lightdm <Lumine>As a side note, I afree with jpoiret, I'm planning on ditching GDM <minima>but both approaches fail, for different reasons <jpoiret>I've also moved to wayland a long time ago so 🙃 <minima>i was discussing the possibility of using a login manager installed at the system level (debian :( ) and then the WM (EXWM) at guix-home level <minima>is that a setup that you think could work? <_graywolf>I just don't use DM at all, works fine (albeit required some tweaking) <jpoiret>if the login manager does run things through your login shell, then yes <minima>jpoiret: i mean that exwm boots into a blank screen, the process starts but nothing is displayed and i need to kill x <jpoiret>on guix we often cheat and modify the DMs to run the commands through login shells so that everything is setup properly <minima>i'd prefer a startx-only approach, but i must be missing some key elements for exwm to become alive <the_tubular>Wasn't there a talk on emacs conf about it no so long ago ? <_graywolf>I see that guix has some guix specific env variables (GUIX_LOCPATH, ...). Is there something like GUIX_LANG? <_graywolf>I need to have different LANG for Guix and for the native programs of the foreign distro :/ <User-48>I'm having a problem with nm-connection-editor. When I try editing a wifi connection it says "GLib-GIO-ERROR **: Settings schema 'org.gnome.nm-applet.eap' is not installed". It was working last week before I updated, but suddenly stopped working now. So I'm not sure if it's a missing package or not. <_graywolf>Ooooh on foreign distro /gnu/store is *not* RO. That makes things simplier. <rekado>_graywolf: it should still be RO. We provide a mount service to make it so. <rekado>_graywolf: you should never modify /gnu/store. <_graywolf>rekado: Sadly I did not really find another way how to make guix work with my LANG setting except by modifying the store directly :/ <_graywolf>I probably could compile my own locales package, but since this is just a temporary measure until I move to GuixSD, ... <_graywolf>Also, it's definitely RW, should I bug report it? <minima>jpoiret: going back to what you were saying re greetd, i suppose i'd need to have it installed at the underlying OS level (as opposed to via guix-home), as it needs to run setuid or as root or something, isn't it? <minima>oh wait... that's a wayland login manager... <jpoiret>I use agreety, which doesn't use X nor wayland, just runs in a tty <drakonis>the majority of them are like the upstream distro but with less packages <civodul>soundmodel: also, that web page is actually maintained by the FSF, so i'd suggest talking to them <soundmodel>I thought I liked Parabola the best, but then I thought that Guix seems like a reference standard <soundmodel>so then I thought why bother with the other ones <drakonis>a stripped down version of the original thing <soundmodel>I haven't used Guix yet, but what the description sounded like, then even Arch Linux seems pointless <drakonis>guix on the other hand isnt nix sans nonfree packages <soundmodel>I think that list might not be very representative <soundmodel>probably they just put whoever wanted to be there <singpolyma>It's probably exhaustive in terms of why meets criteria <soundmodel>PureOS is a bit odd, because I read that the company does sell all sorts of things around the OS <singpolyma>msavoritias: you mean because no effort is made to see those things get done? <soundmodel>trisequel I don't understand how it can fulfill the criteria <msavoritias>No, because some of the projects are either compani driven or shouldnt even be there <singpolyma>soundmodel: because they remove all packages that are problematic <soundmodel>well not necessarily, because I'm asking why should I concern with something else than Guix for "FSF Linux" <singpolyma>They are all based on something that does not fulfill, except for guix which is based in nothing and is only itself <singpolyma>soundmodel: I would say don't concern yourself with FSF generally. Make up your own kind what is good based on your own powers of reason :) <civodul>apteryx: hi! journald is part of "core" systemd <apteryx>I just read 'man 3 sd_journald', and elogind appears to stub these <apteryx>it offers systemd-compatible headers (which includes journald.h) <apteryx>man $(guix build elogind)/share/man/man3/sd_journal.3.gz <soundmodel>@singpolyma well my issue was to find a distro that's most public domain <soundmodel>because I'm tired of the issues of vendor lock-in <apteryx>soundmodel: depends what you want to free yourself from, but any FSDG-endorsed distribution goes a long way in protecting your software freedoms <apteryx>Guix may also be more hackable, after you've spent some time learning Guile <soundmodel>I also liked that Guix seemed to answer my question about "app dev language of Linux" <soundmodel>because no other distro seems to make a conscious choice about good app languages <soundmodel>even though I've seen some individual projects switch away from Guile <soundmodel>IIRC Zrythm is trying to remove Guile in favor of Python <apteryx>interesting... sad to see the divestment of Zrythm from Guix/Guile. I wonder what went wrong for them. <soundmodel>but it's evident that Python is not an app language <soundmodel>so it's nice that Guix seemed to enforce some idea about userland languages <drakonis>it looks like they're going the other way? <soundmodel>I think the issue was also that CPython might be faster <drakonis>the changelogs for zrythm dont seem to point towards anything <apteryx>if I recall benchmarks correctly, Python is often 30x slower than C, while Schemes were typically 3-10x slower than C <soundmodel>the discussion revolved around the idea that if one wanted to write a DAW in C <soundmodel>and every other app is also going around the lua, python decision tree <soundmodel>the point was that I've thought that the OS vendor should dictate the userland more <soundmodel>but this issue has been discussed earlier w.r.t. GNOME <soundmodel>I just personally thought that what Apple and Microsoft did with Objective-C and C# is useful <soundmodel>but as it says on Wikipedia: "The core idea of Guile Scheme is that "the developer implements critical algorithms and data structures in C or C++ and exports the functions and types for use by interpreted code.", so it's like Java, but without the dumb parts <civodul>soundmodel: that *was* the core idea of Guile, before 2.0 <soundmodel>because it's not in popular game engines or something <janneke>"if something has existed for a very long time, and is not popular, it must be good" <soundmodel>a lot of people just seem to look at what's offered <soundmodel>which is again an argument in favor of the os vendor enforcing good practices <soundmodel>instead of letting people try if Mono is good for Linux <TristanCottam[m]>Hi everyone! I'm trying to set up certbot on Guix System. I'm unable to successfully obtain an SSL certificate, but I'm unsure how to troubleshoot. <mirai>TristanCottam[m]: did you manually run the renew certificates script <TristanCottam[m]>No, what I read from gnu/services/certbot made it look like it happened automatically twice a day randomly during the 1st and 13th hours <mirai>you need to run it once manually I think <TristanCottam[m]> * No, what I read from gnu/services/certbot made it look like it happened automatically twice a day at a random minute in the 1st and 13th hours <mirai> /var/lib/certbot/renew-certificates <mirai>in part, a problem that I understand as "chicken and the egg problem" <mirai>the certbot in guix is coupled with nginx <mirai>so you can see where the problem starts when you need the certificates for nginx to start <civodul>mirai: "time-of-check-to-time-of-use" race: between the verify-not-symbolic and mkdir-p calls, or between mkdir-p and chown, an attacker might be able to change things and invalidate the conclusion that was drawn <mirai>and certbot needs nginx to request a cert <civodul>with the *at family of function, you can make sure you operate on the same file that you checked <mirai>civodul: but why the symlink restriction? <civodul>mirai: OWNER is not necessarily root, and OWNER could install a symlink pointing to a root-owned file <mirai>civodul: oh, I have the mkdir-p and chown pattern there, but is it a problem if these are performed within a service constructor? It's running as root (or the shepherd owner) I think <mirai>right, that would be bad indeed <mirai>TristanCottam[m]: either you have to configure nginx to hold off using a TLS cert it doesn't have yet, or its firewall issues <TristanCottam[m]>I managed getting SSL certificates through a Docker container, so the firewall seems to be good. How can I configure NGINX appropriately? <mirai>is it already configured to use SSL certificates? <civodul>rekado: hi! could SELinux prevent guix-daemon from remounting /gnu/store read-write? (it gets EACCES in its MS_REMOUNT|MS_BIND call) <civodul>that makes gnu-store.mount unusable AFAICS <mirai>so it turns out nginx service hardcodes info error log <mirai>must be fantastic for flash endurance <pharcosyle>hey folks, I'm trying to update Guix core packages and GCC (to 12), anyone know anything about that? <pharcosyle>atm I'm having an issue with sed-mesboot and a couple of other bits <apteryx>mirai: oh, is this why the berlin nginx logs grow into multi-TiB over a couple months? <uniavix>When I do guix system reconfigure /etc/config.scm I get an error message saying to herd restart the service and herd status shows that term-console is stopped but I'm unable to start it... <mirai>I don't know if it makes sense to mark severity as high <mirai>(whats the criteria for severity levels anyways) <mirai>but I'd consider it one since: 1. clowns could just dos it with garbage requests <mirai>2. it's grinding my flash drives down <mirai>uniavix: normal, term console is only relevant if you configured a kernel console=… parameter <mirai>🤦 I forgot to mention that the nginx change is testable with check-system TESTS=nginx <podiki[m]>hrm or does imagemagick need to be patched, e.g. including libwebp in the profile/shell doesn't help, but it should delegate to the libwebp utilities <rekado>civodul: it’s possible. Someone with an SELinux system could tell us what permission needs to be declared, then we could update the policy. <civodul>for 1.4.0, it looks like we might need to just disable gnu-store.mount <mirai>under what cases are the severity tags appropriate to be set? <lilyp>when you find an acropalypse, you can set a higher severity :) <mirai>I didn't find anything with that kind of fame, but I found a SSD cruncher and/or “fill your disks by logging garbage” with #62490 <mirai>my 28d almost LAN traffic only nginx instance generated: 11G+ error log, ~700M in regular logs <mirai>can't imagine what it must be for popular instances <lfam>Good reason to use a compressed filesystem <mirai>I didn't tag the issue above but disk crunching doesn't sound too good <mirai>though it's not “heartbleed” kinds of severe <practical-friend>Exception: #<&compound-exception components: (#<&error> #<&origin origin: invalid-certificate> #<&message message: #<x509-certificate 7f7d98cb5d20>> #<&irritants irritants: "disarchive.guix.gnu.org"> #<&exception-with-kind-and-args kind: tls-certificate-error args: (invalid-certificate #<x509-certificate 7f7d98cb5d20> "disarchive.guix.gnu.org" (#<gnutls-certificate-status-enum expired> #<gnutls-certificate-status-enum invalid>))>)> https: <civodul>yes, i don't know why the "certbot renew" mcron job didn't run <minima>oh i thought it was just me :) the number of times i need to reload nginx manually! <civodul>we're a whole bunch of people ending up manually restarting nginx! <civodul>a colleague of mine would email me every 4 (or 6?) months to tell me my cert has expired <civodul>every time i think i've fixed it for good <podiki[m]>was just about to ask about tex packages when I remembered the new manual section added (last year? recent)....yay <lfam>So, what fails is the hook that reloads nginx? <podiki[m]>ACTION goes off to build a list of what's needed for a fancy cv <apteryx>civodul: 2023-03-24 00:33:54 127768 /gnu/store/jnp0166xw62dafd2zgxdmvjb6yq8ak32-certbot-1.28.0/bin/certbot renew --webroot --webroot-path /var/www: failed after 234.635s with: (misc-error #f unclean exit status ~S (1) #f) <apteryx>c.f. /var/log/mcron.log (which seems to be getting rather large) <apteryx>seems it got some 404 (unauthorized) from Domain: www.guix.info <civodul>maybe it's those --webroot* options that are no longer valid in our setup <apteryx>I'll add an item to bug-guix with [berlin] in it to keep it tracked <euandreh>podiki[m]: that error looks like you haven't installed svn <euandreh>I've used the texlive importer some time ago, and it indeed used svn to download some tex code <podiki[m]>that is surprising to me, would expect an importer to work without adding dependencies <podiki[m]>thanks that works; importer does "public-domain" for license and a (version #f), but after fixing that package works (to build at least) <civodul>ACTION fell deep into the posix_spawn quagmire