IRC channel logs
2024-10-20.log
back to list of logs
<podiki>oh neat, when did new guix website go live? <civodul>podiki: last month or so (thanks to Luis Felipe again!) <civodul>fnat: looks like shepherd didn’t get started for some reason <podiki>civodul: I remember the proposal, and always love Luis's work, great to see more of it live! <RavenJoad>I am debugging a problem where LaTeX fonts are rasterized/bitmap when I am inside a direnv-loaded guix-built shell. When I use my globally-installed texlive installation (texlive-scheme-full), I get vector fonts. <RavenJoad>Does anyone have an idea of where to _start_ figuring this out? <GNUtoo>yes, there is something in the manual about issues like that but they are mostly for the split latex installations <GNUtoo>It's in the "18 Using TeX and LaTeX" chapter <GNUtoo>But it assume that the LaTex output some warning/errors <GNUtoo>It shows that example to search in which page could a specific font be to fix the issue described <RavenJoad>I am just using the standard computer modern font. I have not loaded any packages to change the font for this document. I guess I need the <GNUtoo>Another option is to install the big metapackages for LaTex stuff and step by step remove what's not needed <GNUtoo>It also assumes that you can make it work somehow with these big metapackages <RavenJoad>The metapackages are fine. I am not using many packages outside of texlive-scheme-medium probably. But now I have a fun different issue. <RavenJoad>A Guix package I defined to build a PDF is failing to execute make. The package uses gnu-build-system, whose build phase does the standard "make", and that make calls latexmk. But I get "In execvp of make: Argument list too long". <GNUtoo>If you build the pdf within packages, the syntax to import tex stuff in inputs is probably different <GNUtoo>I used it in the simtrace package if I recall well, it's probably somewhere on issues.guix.gnu.org <RavenJoad>So I figured out the argument list thing. It appears to happen when I use texlive-scheme-full as a native-input. <RavenJoad>GNUtoo: It looks like I was missing texlive-updmap.cfg function. I added that and now I only have one Type 3 bitmap font left to find and fix. <RavenJoad>Reading the comment in tex.scm, it makes sense why I would get vector fonts on my personal interactive shell, but not in the build environment (profile hooking). Perhaps the LaTeX section should be updated to note this? <apteryx>does guix system always default to 10 guixbuilder users? <sneek>apteryx, you have 1 message! <sneek>apteryx, podiki says: re: branches, I think yes waiting on fonts-split-outputs. mesa-updates (just updated and rebased) should be good to go, just been waiting for non-x86 builds for weeks <apteryx>podiki: is it clear why fonts-split-outputs is being held up (instead of merged)? <podiki>it was just merged earlier today/yesterday <podiki>i rebased mesa-updates after, though that didn't introduce builds from what i can see <podiki>hopefully that means non-x86 will get building sooner, but i know efraim had built mesa locally on aarch64 and powerpc64le some time ago <podiki>x86_64 and i686 coverage should recover very quickly to at least what was on master before. so should just be waiting for other builds now <vhns>is there any smart way to include the system configuration in /etc? <vhns>say, using the etc-service-type to include the file which you're running `guix system reconfigure config.scm´ in there <__cornflake__>I'm not sure, but that's a good question, I just don't know, I'm not really a guix expert but there are a lot of people on here who can probably answer that for you! <apteryx>vhns: sure; use the special-extra-file service <apteryx>untested, but should give you the idea: (services ... (extra-special-file "/etc/config.scm" (local-file "./your-config.scm))) <__cornflake__>also, I'm not trying to be rude by overriding your question, but I'm back with my home shepherd issue, here's what I'm doing for the service definition: https://paste.debian.net/1332803 and here's the error: https://paste.debian.net/1332804/ I'm trying to start the emacs daemon using shepherd from inside my guix home config file. I've been trying to figure out what I'm doing by reading docs and whatever else I could find, but it hasn't <apteryx>weird that there isn't an home-emacs-service-type or something yet <__cornflake__>yeah since so many people are probably trying to start the emacs daemon with shepherd <__cornflake__>it would be cool if there was a home-command-service-type where you could just give it a command and it would run it <__cornflake__>that would replace the various "exec XYZ" lines of code in most wm's <apteryx>here though the destructor is special <apteryx>I remember struggling a bit with that years ago ;-) <__cornflake__>I think what's making this hard for me is that I can't find an example of home shepherd stuff <__cornflake__>I read the blog post about user shepherd using shepherd's config file, but I can't seem to find anything using this home-shepherd-service-type <apteryx>I think one of the original guix home author probably makes heavy use of it in their guix-rde project, perhaps that could be used as a source of inspiration <apteryx>uh. maybe after you've tested it you could submit it for proper inclusion in guix, by emailing guix-patches <__cornflake__>he actually has that repo set up as a channel, so I think you could use all his home services by adding that as a channel <__cornflake__>also idk if this is the proper place to talk about this, but it puzzles me why shepherd isn't written in C. It needs to have high performance and isn't one of the main selling points of guile that it is great for extending C programs? <__cornflake__>and every other init system is written in C or some other systems programming language <apteryx>it doesn't need to have high performance. most of the time it doesn't do much at all <apteryx>guile does have a larger memory footprint though, due to being managed (running on a vm); my PID 1 currently uses 146 MiB of resident memory, which seems higher than what I recall (Guile applications typically require about 30 MiB, similar to Python) <apteryx>on a more minimal machine it's using 51 MiB <apteryx>systemd would use something like 3 MiB IIRC <__cornflake__>I don't have any issues with shepherd it just seems like using an interpreted language for such a critical task as the init system is strange to me <__cornflake__>it would be like using python or javascript as your init system <__cornflake__>maybe I'll try rewriting it in C and see if I could do it lol <kaij>I have a bunch of one-shot services that I want to run one after the other on boot. For some reason herd is refusing to actually wait for them to complete. is there something I have to do when using fork+exec-command so herd waits for it to complete? <apteryx>lilyp: what does "GI tests require installed libraries" mean in the new 'glib'? <apteryx>oh I see; the check phase is simply moved past the install one. <dariqq>inspired by the discussion here i tried to make an emacs-daemon home-service and It seems to disable the graphical part in the gnome-wayland session because XAUTHORITY does not exist yet <dariqq>using emacs-pgtk as the server works without issue. That seems to not require Xwayland <Rutherther>dariqq: I think the only thing required for the pgtk should be dbus connection. Additionally if you have some stuff that depends on the display, like opening links, you might also need to ensure WAYLAND_DISPLAY and/or DISPLAY variables are passed to it <fnat>civodul: Hm I see, thanks (re herd not working in my Guix Home and the '/run/user/1000/...' file not existing). <Rutherther>what's proper way to respond to e-mails from the mailing list? I am subscribed but only for daily digest, so I don't get the stuff as raw e-mails. Can I somehow download the original e-mails from the list? or should I copy the email from the digest and try to convince MUA it's a received e-mail that I can reply to so that it provides correct headers for reply? <fnat>I'll try a reboot, unless anyone has any idea on what service to restart to bring a Guix Home shepherd back to life? <fnat>I should have mentioned that my Guix Home (with the '/run/user/1000/...' error) is activated via 'guix-home-service-type'. This service might be the culprit? <dariqq>Rutherther: Problem is that when shepherd starts emacs upon login links like XAUTHORITY/DISPLAY/WAYLAND_DISPLAY dont exist yet. The default emacs.service systemd unit also has the same problem (under wayland) <fnat>Oh well... I see mention of a 'GUIX_SYSTEM_IS_RUNNING_HOME_ACTIVATE' env variable... which might be what I need. Investigating further... <fnat>dariqq: Ha, lovely, thanks! <fnat>So it seems I need elogind or similar to create the XDG runtime directory, etc. <fnat>Is there any more lightweight alternative to elogind? <aldum>Chimera has something for this <dariqq>maybe seatd? Never used it though <fnat>Thanks, I'll have a look. <aldum>sorry, I was thinking of turnstile <Rutherther>sneek: later tell dariqq, yes, that is why you need to make it require other services like x11-display, and for wayland display you have to make your own service as guix channel doesn't support setting that environment variable. Additionally you then need to override the #:environment of fork+exec-command. <fnat>luca: Thanks! Manually creating the folder makes sense to me, thanks, I'll try that then, without elogind. <luca>Oh also be aware that some software expects the folder to always be `/run/user/$(id -u)`. I can't say I've had any issues personally though <efraim>podiki: I'm having some trouble attempting the rebuild of mesa on powerpc64le (but it's entirely my fault). I'm rebuilding mesa now on aarch64/riscv64 (and armhf after) <Rutherther>luca: when using gexps inside of arguments list, do not quote the list, use (list instead so it is unquoted. The way you have it now will pass gexps to the build daemon, and that is not allowed. gexps have to be evaluated prior to that <Rutherther>luca: also that add-before is quite strange, where do you want to put it? it should be "(add-before 'what-phase-to-put-it-before 'name-of-your-new-one (lambda))", I don't understand why you have that many arguments there <luca>The idea was to chdir for every stage, so I thought the syntax was "(add-before 'stage-1 'stage-2 'stage3 (lambda))", but it appears I was mistaken. Thanks! <Rutherther>luca: you don't need to do that, just chdir before the first one where it's needed. The phases do not do chdir normally <Rutherther>because you put it to (), don't do that, just "(list #:phases ...)" <Rutherther>() means to apply(execute) something, so right now you are trying to execute #:phases <Rutherther>luca: you will also have to quote the #f I think, something like '#f, but it might not be required. <luca>It doesn't error out yet, but I'll keep it in mind! <luca>Now `(chdir (string-append "runit-" version "/src"))` fails with "In procedure string-append: Wrong type (expecting string): #<procedure version ()>". Aren't those all strings? <Rutherther>luca: no, version is a symbol, you need to pass it from the outer context - ungexp it <Rutherther>luca: what is inside of gexp is executed in the daemon, so "version" symbol doesn't exist there. Gexps can capture the environment, that is why they are useful, and to do that, you use ungexping. It's like quasiquote and unquote, but more robust <luca>All right, adding #$ before (string-append) and it helped! Thanks <Rutherther>luca: that makes the whole string-append run before build, and the whole thing is just a string, you could also add #$ only before version and then string-append would be ran in the daemon, but only with three strings as arguments. Not that one would be somehow better/worse, just saying so it's clear <dariqq>there is a x11-shepherd-service that does exactly what I want. (At least for DISPLAY and not XAUTHORITY). Maybe that will be enough <sneek>Welcome back dariqq, you have 1 message! <sneek>dariqq, Rutherther says: yes, that is why you need to make it require other services like x11-display, and for wayland display you have to make your own service as guix channel doesn't support setting that environment variable. Additionally you then need to override the #:environment of fork+exec-command. <dariqq>Rutherther: Yes found that myself eventually. Do you know why this seems to require fork+exec-command instead of make-forkexec-constructor? <Rutherther>dariqq: I am not completely sure. I suspect is has to do with where the code is actually executed. Possibly one time in the builder itself, and one time in shepherd. <fnat>Adding 'elogind-service-type' to a minimal installation and reconfiguring fails and leaves the system in a very bad state. E.g.: https://dpaste.org/dxA4d <fnat>I'm forced to reboot the machine. <fnat>Perhaps there's some other service that I should make sure I use together with elogind? <fnat>In case it may be relevant, I launch the reconfigure via 'guix deploy'. <fnat>Open SSH sessions are not terminated - but they become useless. New SSH sessions are not accepted. <fnat>Not a big deal, the machine is physically accessible. <fnat>Local logins also are not possible, after typing username and password, I'm redirected to the login prompt again. <fnat>Luckily a reboot fixes things (as opposed to having to boot from the installation USB). <fnat>It's definitely elogind as that's the only change. <lilyp>sneek later tell apteryx I need to hold off the glib change, because python-pygobject and gjs break – updating pygobject is no biggie, but gjs requires a newer mozjs (128 as of the latest version) <lilyp>On that note, is someone from the gnuzilla team here? <fnat>I threw in a bunch of other services (part of the "dbus clique", i.e. avahi, polkit, dbus) in addition to elogind, but a guix deploy still results in a broken system (broken as in it seems to require reboot). <fnat>I'm not sure if it's to do with elogind in itself or the fact that I'm reconfiguring via guix deploy instead of locally (just wild guessing here). <dariqq>Rutherther: I think I see the issue now. When fork+exec is used everything is inside an outer lambda and evaluated upon starting the service. make-forkexec-constructor creates such a procedure and passes the environement variables and thus these are evaluated upon loading the config <graywolf>Hi, quick question, if I report a bug and later realize I know how to fix it, what should I do? Close the bug and send the patch? Send the patch to the bug adress? Something else? <Rutherther>graywolf: you can send the patch to the bug itself, it makes it clearer to follow <graywolf>Rutherther: Ah, will do. Thanks :) I wasn't sure if issues.guix.gnu.org would correctly handle that. <dariqq>this is trickier than it seems. The x11-display service just finds the display by looking in /tmp/x11-unix/. Might be possible to hack something together by looking in XDG_RUNTIME_DIR . But might get really ugly <Rutherther>dariqq: what do you mean? there will be socket in that folder as long as xwayland is started <dariqq>Rutherther: yes. But in mutter XAUTHORITY is something like /run/user/1000/.mutter-Xwaylandauth.7AT4V2 and not $HOME/.Xauthority . I get a window with emacs-gptk because the default wayland-0 matches WAYLAND_DISPLAY. Currently trying to see if I can adapt the x11-display code for wayland-display and hopefully something similar for XAUTHORITY <Rutherther>dariqq: are you using like ssh x forwarding or something like that you need xauthority? <dariqq>Rutherther: I just want the emacs-daemon to create a window. It checks that at launch where XAUTH is not instantiated and mutter using a nondefault XAUTHORITY <noe>Is there a cuirass-web instance for bordeaux.guix.gnu.org ? <nckhexen>The README says ‘TODO Continue working on web interfaces’ but I don't think one exists. <efraim>ugh, had a power outage in the middle of a git commit and now my tree is corrupted. I'm now looking at how to prune empty items :/ <janneke>istm that our 32bit x86 kernel does not boot, getting a kernel panic <efraim>I haven't come across that myself <janneke>i'm building installer images and the 32bit version does not boot on any of my machines (32 or 64 bit) <dariqq>I am giving up on this, emacs server and wayland dont go well together <dariqq>Ok there is a patch from opensuse wich (finally) works. That is way simpler than what i was trying to do <fnat>Interesting, I've managed to reproduce my issue where things go pear-shaped after a reconfigure. <fnat>More precise context: update from a minimal headless install to a system with elogind. The update takes place via guix deploy. <fnat>The deploy stops with error 'guix deploy: error: failed to deploy host: remote command '/run/setuid-programs/sudo ... remote-exp.scm ...'. <Rutherther>fnat: does the problem not occur when you use guix system reconfigure from minimal headless to elogind? <fnat>After that I can no longer login to the machine, neither via SSH nor from a TTY. <fnat>I've managed to reproduce this in a VM, which is good I think. <fnat>Rutherther: Right! Thanks, that's my next step. I'll update you in a min. <fnat>I had to fight with a locked/corrupted QEMU image (because of the forced shutdown) and now doing a guix pull, but getting there. <marmalade>Hey there, I'm trying to install chezmoi using guix installed on a foreign distro but it fails, and I'm not sure how that's possible? <marmalade>Or what to do about it - I checked the build log and it just looks like charmbracelet/glamour's build tests are failing? <Rutherther>marmalade: what guix revision are you on? on latest it seems to be available from substitutes at least on x86_64. So try updating - or are you on another architecture? <marmalade>Rutherther: should be latest? not sure, i just did the normal shell script install and selected all the defaults - i'm also on x86_64 <janneke>efraim: fwiw, using linux-libre-5.15 works fine for me, 6.10.13 panics <Franciman>i'm really out of ideas, i can't find a way to fix telegram-desktop <Rutherther>marmalade: what installer? check with guix describe which revision you are on <Rutherther>marmalade: that is 1.4.0, do guix pull to get to latest version (keep in mind you will have to source ~/.config/guix/etc/profile in your shell, and should have that somewhere in bash profile or something like that so it's persistent <Rutherther>marmalade: also I forgot to mention, when sourcing the ~/.config/guix/current/etc/profile, set GUIX_PROFILE=$HOME/.config/guix/current environment variable (just for the script, not in future for your shell) <marmalade>Rutherther: hrmm no such file or directory re ~/.config/guix/etc/profile. I already did guix pull as well, but I did it again and it confirmed that nothing needed to be done. That said, it *is* complaining the following: <marmalade>hint: After setting `PATH', run `hash guix' to make sure your shell refers to`/home/marmalade/.config/guix/current/bin/guix'. <marmalade>is the installer script old or something maybe? <Rutherther>marmalade: the install scripts are made to give you the latest release version, because that one is guaranteed to work. But you should not use it for more than installation of newer guix. So yeah, it's old, but it's intentional. <elb>Is there a good way to turn a `guix shell -m manifest.scm -C --tons-of-other-stuff` invocation into a single .scm file, like a guix container operating-system but to be created anew on each invocation? <Rutherther>elb: you can put shebang on top of the manifest.scm file that will do that invocation and use the file as manifest. But tbh I forgot how exactly to do that, so I can jut tell you it's possible. <Rutherther>marmalade: so did you source the profile or not? - do you have ~/.config/guix/current/bin in PATH? <elb>oh ... that's kind of clever, actually <elb>I know how to do that <elb>ahh crap but some of those values are computed by the shell, so I don't know how to do that in this particular case <marmalade>wait i'm supposed to do all these steps post install script? <Rutherther>marmalade: unless you restart your session, you need to do it manually. The script makes sure to make it persistent, but it can't affect your current environment due to how environment works on linux <Rutherther>marmalade: what do you mean etc/profile does't exist? does the path ~/.config/guix/current exist? if so, send "tree" of it <marmalade>I mean, I am on debian, should I have just apt installed it? <Rutherther>marmalade: so etc/profile it is there, so what's the problem? <Rutherther>either restart your session or source it yourself, there is no other way <marmalade>Rutherther: I restarted after installing guix I'm pretty sure, but when I try to do `source ~/.config/guix/etc/profile` I get back `source: no such file or directory: /home/marmalade/.config/guix/etc/profile` <Franciman>because of the segfaults i've been telling here for the last 2 months <Franciman>then, i give up and want to get back to an older guix version <Franciman>does guix time machine allow to buix an older system? <Franciman>seems like glibc, surely at this point in time: ecdcc19200a6c3510b100a852147c7557d1f277f everything worked <marmalade>Rutherther: tyty looks like it's all working now <fnat>The "minimal-to-elogind" reconfigure went well when run locally as opposed to using guix deploy. <fnat>Perhaps this is kind of expected for the way this (significant?) update changes things? <fnat>OTOH, maybe it's something I should report via guix-bugs? <Rutherther>Franciman: yes, the time machine is made to be able to go to past and future, so you can of course go back 2 months and build even older system if you want. <marmalade>Is installing GUI programs supported with Guix on a foreign distro? <marmalade>Sorry, I'm just trying to get my baseline for this install setup, which means Emacs, but I'd prefer ver 29 which Guix has over v28 which Debian has. <Franciman>Rutherther: can i do that while installing newer packages from later revisions? <lfam>marmalade: It's intended, and many of us do it. There could be some annoyances that would not be present on Guix System <stochastic>How could I modify a service to give it an arbitrary environment variable?