<podiki[m]>how come I can never remember how to mix old style inputs for a specific package output with the new label-less style... <podiki[m]>so I can hopefully remember, it is `(,package "output") ***jonsger1 is now known as jonsger
<nckx>podiki[m]: That's new, not old, style. <nckx>Although I… kind of get what you mean on second glance. <podiki[m]>...it reminds me enough of the old style I can never remember it <podiki[m]>but yes, also different enough neither one works in the wrong context, of course <nckx>Why we keep using '? Who knows. Nostalgia? <nckx>AwesomeAdam54321: That's… 2 awesome 4 me. <nckx>(In reference to your ,(inputs "package" package) which I don't get.) <podiki[m]>nckx: yes, that makes more sense. but again, will I remember it when I next need it however long until the next time <podiki[m]>what I'll do, as usual, is cheat by going back to this package definition I wrote; that I can remember <nckx>We can both agree to pretend you will. <AwesomeAdam54321>nckx: I don't remember it, but the old style repeated the package name twice <podiki[m]>should keep a steady diet of packaging to keep the skills sharp <oriansj>podiki[m]: or perhaps a better is make packaging so simple and hard to get wrong that the default result would be package works <apteryx>can someone else check the size of our current 'glibc-locales' package? <podiki[m]>oriansj: I've often been nicely surprised by guix import, requiring just some stylistic changes <podiki[m]>apteryx: I see the same, 928 MiB from guix size, 232M from du -hs <podiki[m]>btrfs compression? compsize shows roughly the same figures <podiki[m]>newbie at btrfs though, not sure all the differences between du, guix size, and compsize <apteryx>but I get teh same on berlin, and its tree is not yet on Btrfs + zstd <podiki[m]>Type Perc Disk Usage Uncompressed Referenced <podiki[m]>btw, thanks for the mangohud push! happy to have that in <podiki[m]>yet apparently I don't know how to alphabetize, coulda sworn I did that <apteryx>no compression on the computer I'm looking at: /dev/sdh1 on /gnu/store type ext4 (ro,noatime,stripe=320) <apteryx>find -links +0 -> lists files that have more than 0 hard links <apteryx>thanks for that command, it's nice. so the discrepancy was indeed attributable to hard links <apteryx>I guess that's due to store dedepulication <podiki[m]>between hard links and compression, that's a lot of space saving <apteryx>for me with compsize I get: TOTAL 31% 67M 213M 929M <podiki[m]>so guix size is not what you recover if you remove a package, unless you also remove all other references to anything it is also hard linking? <apteryx>so it's using 67M on disk after hard links store deduplication + zstd compression <podiki[m]>though I think in my overall disk usage the biggest stuff wouldn't gain much or anything (already compressed stuff like art for games, music, photos) <Ribby>I donated to guix's development. I did attempt os installation from the latest release, but something is bugged? Still, the stable release is at least working to some degree. I think maybe a improper usb reformat in volume or partition table/space from exFat/exa4, might have contributed to the glitch in my beta download. I might try the test release again, see if something works. Maybe the next number will at least have constant <Ribby>internet connection for ethernet? <cedb>hey how do i find what herd service a package corresponds to? im trying to start avahi here <Ribby>When I meant, bugged, the os installation network connection failed? Could not connect to either network or router? I'm just saying. <cedb>also i keep getting the hint so install glibc-locales and defining "GUIX_LOCPATH" while i have done both? <cedb>ahh i had installed it with sudo but not in the user's profile <cedb>im new to the guix|nix, and find having multiple profiles a bit confusing, are there any guidelines for what to install with sudo and what to install for a given user? <AwesomeAdam54321>cedb: It's recommended to use `sudo -i` and not `sudo` if you want to run guix as root, so that all the environment variables are from root's environment and not mixed with your user <cedb>AwesomeAdam54321: ahh that disables the warnings <cedb>how about my avahi thingy, im not sur how to find which shepherd services are installed by a given package... <AwesomeAdam54321>cedb: You could try `guix shell shepherd avahi` and test with `herd status` <cedb>AwesomeAdam54321: can you enlighten me as to what the point of running a guix "shell" in this context is? <AwesomeAdam54321>cedb: `guix shell` makes a temporary profile of the packages specified, and it's completely isolated from your system <cedb>also i get the ".../socket: no such file or director" when i run herd as user, i take it from a little googling i need to start herd in "userland" (sorry for bad terminology ;) ) but not sure how <cedb>but i mean if in sudo -i mode "avahi" "could not be found" im not sure thats really the root of the issue here <AwesomeAdam54321>cedb: You do `shepherd --socket=socket` and then `herd status --socket=socket` <AwesomeAdam54321>So that it uses a file called "socket" from within the guix shell for those commands <cedb>right right, is there a way to attach/detach from those "envs" ala screen/tmux ? <cedb>(also avahi could not be found in the shell too) <AwesomeAdam54321>the -C option is what makes the guix shell isolated in a container so that you can figure out the problem <cedb>cool thanks (rtfming for guix shell atm, very neat feature) <cedb>welp avahi is not showing up in that "container" <AwesomeAdam54321>cedb: I don't know a lot about the Guix System, but I think the services are defined outside of the package definition and actually in the system configuration <cedb>any idea where the system .scm file is? <podiki[m]>cedb: you are on guix system right? your earlier warnings are usually when guix is on top of another distro (as a package manager) <cedb>this is driving me nuts i might resort to guix on top of debian or something <cedb>i dont understand why its so hard to "discover" installed services <podiki[m]>the .scm file from the installer by default is in /etc/config.scm, guix system list-generations will also show you in the store each config file for a system configuration generation <cedb>yeah right now im trying guix system <Ribby>Isn't there a app store or something like that? <podiki[m]>there is a way to search services, but I forget and usually use emacs-guix or the manual <cedb>im just trying to find out what the avahi package does tbh at this point <Ribby>Oh, everybody, I managed to resolve the /dev/loop0 usb and usb drives error due to usb misreformat. Whew! <cedb>podiki[m]: yeah i get this describes the semantics of defining services, but could you tell me where are the files that actually define them? <cedb>like id expext "guix install <someservice>" to run a hook that defines those services somewhere in a scm file no? <podiki[m]>no, services are set up in your system configuration <Ribby>Avahi is zero configuration? <podiki[m]>you can also run "user services" with shepherd, but I don't think that's what you are looking for <Ribby>I hope you got the hardware down though. <podiki[m]>again, I think you can jump to it from a guix command, but I'm not sure for services. if you use emacs, emacs-guix let's you explore and see that stuff easily too <podiki[m]>but the manual is where you want to see what services are available and their options <cedb>podiki[m]: my system configureation as in /etc/config.scm has no traces of aditional services beyond what i specified in the installation (e.g. dhpc) <podiki[m]>to modify it, you can edit that file (or put it somewhere else) and then do sudo guix system reconfigure /path/to/that/configfile <Ribby>Personally, zero configuration entails no configuration, but by what extent, I wouldn't know. <podiki[m]>generally you'll want to edit your config file and do a reconfigure to change any system stuff, like those services, users, kernel stuff, and so on. regular guix install stuff will be run as a regular user for installing packages <cedb>podiki[m]: you mean adding a sexp with (service <avahi-service-type>?) as an argument to the list proc in services def in /etc/config.scm then sudo guix system reconfigure /etc/config.scm? <cedb>lmao i love scheme but id expect the package manager to handle services <podiki[m]>likely you are using %base-services or %desktop-services, so you might have avahi in there already; then you can modify what's in there instead (see modify services in the manual) <podiki[m]>well guix handles it all, but the system comes from a scheme file that defines it <podiki[m]>so all the system stuff lives in that configuration file (which is saved each time you reconfigure so you can go back to previous ones) as it is part of the system definition <cedb>i didnt install the desktop-services thing cause i wanna use it headless <cedb>but i might, sometimes installing a huge metapackage just sorts this stuff out <podiki[m]>the power is that it captures the system services configuration too --- no editing random config files and hoping you keep track of them <podiki[m]>that's up to you, you can always change it of course <podiki[m]>there are some examples people have of their configs if you search online (mine has some non-free stuff so I won't share it here) <podiki[m]>and you can modify e.g. %desktop-services to delete services you don't want (I do that for example) <cedb>hmm interesting, might catch you on nonguix then ;) ? <cedb>huh "avahi-service-type" unbound variable <cedb>i dont really care about avahi that much it's just id rather understand how services work on guix-system <cedb>i just shot up guix system reconfigure /etc/config.scm with the original unmodified file and a bunch of stuff is happening watt <podiki[m]>avahi-service-type will be from some module to include in the top, (gnu services avahi) <podiki[m]>if you reconfigure with even the same file, likely it is updating everything in there to the latest version you have (guix pull just gets info, doesn't update things) <podiki[m]>it is a pretty different experience than a "regular" distro, so takes a while to get the hang of it <cedb>yeah i can see that heh, thanks for helping btw <podiki[m]>gotta run for now, but good luck! plenty of people here to help (bit of an off hour right now, I think europe day/evening is more active) <podiki[m]>happy to! I was very new just a short while ago <cedb>okay now it wont boot after reconfigure lmao <podiki[m]>oh, found the service search "guix system search" <podiki[m]>well, you can pick a previous generation in grub and should be back to where you were before <cedb>podiki[m]: hmm it says "sherperdnames: avahi-daemon" but sudo herd start avahi-daemonsays could not be found <cedb>whats another service i could try to install to see if this is really just a problem related to this specific package? <podiki[m]>sorry, off to bed here, but plenty in the manual you can just try <jpoiret>cedb: if you're booting a previous generation that didn't have avahi you won't be able to start it <phf-1>Hello Guix! Is `guix deploy' used in production somewhere? ***rgherdt_ is now known as rgherdt
***Xenguy_ is now known as Xenguy
<phf-1>Hello! Anyone had this error? `guix deploy: error: failed to deploy XXX: no signing key '/usr/local/etc/guix/signing-key.pub'. have you run 'guix archive --generate-key?'' <phf-1>and yes, I've done `guix archive --generate-key' <phf-1>as there is `/etc/guix/signin-key.pub' <avp>phf-1: '/usr/local/' part of the paths is looking suspicious to me. Shouldn't the key be in '/etc'? <phf-1>of course a solution would be to use `/etc/guix/signin-key.pub' instead of: `/usr/local/etc/guix/signing-key.pub' but how? `guix deploy --help' does not help. <phf-1>avp, yes... I don't know why it's like that. <avp>How did you install the Guix on your machine? <phf-1>the Guix I'm using is the devel one <avp>I mean there could be a problem with './configure' part if you installed it from the source directly. <phf-1>./pre-inst-env guix deploy -v 10 /home/phf/tmp/guix-deploy/test.scm <phf-1>avp, thanks! that's probably it! <balbi>hi folks, what's the proper way to have `cargo' and `rustfmt' installed in guix? I noticed `rustup' is not part of guix and install rust:rustfmt and rust:cargo installed the binaries but didn't link them to /run/current-system/profile/bin/. <singpolyma>balbi: normally you find things you install in ~/.guix-profile <balbi>singpolyma: I added `rust' to my system profile, though. So it would be available to all users <balbi>I'll change for a quick test <singpolyma>So you added rust-cargo to your os definition and ran system reconfigure? <singpolyma>You could try installing to a normal profile first to make sure you have the right prckage <singpolyma>I'm not really familiar with adding things globally is what the tricks are there <balbi>okay, when I install as a regular user, then I see `rustfmt' and `cargo' on the path <singpolyma>Ok. So something about the way you added to it definition that is being different <singpolyma>Hmm. Maybe something about using specification->package like that? Could try putting the package directly <balbi>perhaps... I'll play with this a little more, thanks <balbi>seems like i get the expected output in guix repl <balbi>in fact, this works fine for git send-email <bricewge>phf-1: Did you authorize your local guix singing key on your remote host? <phf-1>bricewge, I did that: `cat /etc/guix/signing-key.pub | ssh root@$ip guix archive --authorize' <phf-1>bricewge, so, the answer is yes I guess. <bricewge>Is it actually in the remote `/etc/guix/acl`> <phf-1>so, for some reason it's not in the /etc/guix/acl ... <bricewge>It point to the store isn't it? `namei -l /etc/guix/acl` <phf-1>bricewge, ho, that's strange <phf-1>bricewge, I added the key on the remote <phf-1>bricewge, then, guix deploy $file <phf-1>bricewge, error as before, checked the acl in the remote and the key was gone <phf-1>ok restarting the guix deamon on the remote <bricewge>Actually the proper way is to specify the `guix-configuration-authorized-keys` field in your OS <bricewge>I think 3b6e4e5fd05e72b8a32ff1a2d5e21464260e21e6 broke the imperative way to authorize signing key <phf-1>bricewge, Ok, I've just `guix system reconfigure' ... waiting to finish things up. <bricewge>I've stumbled upon this bug several times <phf-1>bricewge, Ok, /etc/guix/acl seems ok. Trying the guix deploy $file thing. <phf-1>So, I did the `guix system reconfigure' adding the pub key to the operating-system config <phf-1>and the key was gone on the remote in /etc/guix/acl ! <phf-1>here is the config to be sent <phf-1>bricewge, maybe I should add the local pub key to that conf <bricewge>I don't understand why it didn't worked first. But it's great that it finally worked for you <phf-1>bricewge, it makes sense somehow but it's a bit circular like that... the local.pub key should be present at first then added to the conf to be sent. <phf-1>bricewge, anyway, thank you! I'm documenting all the things, so will share that. <phf-1>bricewge, After a guix deploy, one needs to restart services by hand like nftables ? <phf-1>The conf was deployed but nmap told me that it was not effective <phf-1>I issued: herd restart nftables then nmap told the new config was running <phf-1>so... the best bet is to reboot I guess. <Kolev>KeePassXC keeps crashing on foreign distro. <attila_lendvai>are there any geiser users around? is it working for you on a rencentish Guix? for me the repl opens up as expected, but it doesn't respond to pressing ENTER. all i can do is C-c C-c several times and eventually it quits with some errors in *geiser messages*. <attila_lendvai>err, wait, it works when starting with emacs -q. i guess i'll need to take a deep look into my rather innocent-looking init.el <gnoo>which package provides aclocal? <gnoo>hmm, i do have autoconf as an input and yet this package says it can't be found... <gnoo>checking for working aclocal-1.4... missing <gnoo>checking for working autoconf... found <nckx>aclocal is provided by automake, but I don't think we have an old-enough version for -1.4… <nckx>-1.16 seems to be our oldest. <gnoo>also, i have gtk+-2 as an input but this package says: checking for g_signal_emit in -lgtk-x11-2.0... no <nckx>This package is positively ancient, it's not suprising that it won't build with current tools. <nckx>You might need to package similarly old autotools/gtk+ packages :-/ <gnoo>nckx: thanks, i'll get on that tommorow. <bricewge>phf-1: Cool, c'est en français en plus :) <sneek>bricewge, you have 2 messages! <nckx>gnoo: Sorry for the disappointing answer 😉 <gnoo>nckx: also i have these errors, can i use a prepackaged version or package my own? <gnoo>checking for g_malloc in -latk-1.0... no <gnoo>checking for g_module_open in -lpangox-1.0... no <phf-1>bricewge, Excellent ! Il y a visiblement pas mal de francophones. <gnoo>checking for g_free in -lgobject-2.0... no <phf-1>bricewge, je ne sais pas s'il est possible de traduire automatiquement du français à l'anglais comme c'est le cas de l'anglais au français dans la doc Guix ... enfin, nous verrons. N'hésite pas si tu vois des bêtises à me les faire remonter. <phf-1>bricewge, peut-ête qu'un jour ça finira dans le Cookbook ou ailleurs. <gnoo>nckx: also, i think the pspp package is broken in that no icons show up, i tried to have it built using glib-or-gtk-build-system while adding adwaita and hicolor as inputs but that didn't gave positive results. anyway, it still should probably be built with glib-or-gtk-build-system instead of the current gnu-build-system <nckx>Hm, I don't *think* ‘checking for g_signal_emit in -lgtk-x11-2.0... no’ et al are version-related, but I'm not sure (nor do I know what they could be). <nckx>gnoo: I'm really not a Gstuff person… <gnoo>ok thanks! i'll package them all, then <nckx>Esp. not for old packages of voting age. <rekado_>apteryx: please let me know when you want to reboot with me watching the serial console. I won’t be on #guix, so please let me know via email in advance. <dominicm>Hello all; I sent in my first patch (both for Guix and for a mailing list in general) a few days ago. I think I kind of messed it up because I didn't know that ~git send-email --compose~ sends out multiple emails, so I accidentally created two bugs that were weirdly formatted on the mailing list. I closed out the mistakenly created bug, but I'm not sure if I should also close out the patch and resubmit it so it looks correct in the <dominicm>mailing list. Would anyone be able to take a look and tell me what I should do? Sorry I'm super new to this stuff. It's bug #54104 ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<cedb>hey i keep getting the "set env variables by setting guix profile and sourcing it" hint even though I did it like three ways (e.g. added the lines to my bashrc and sourced it, manually, did the guix package --search-paths thingy too) <cedb>anyone know what is triggering that? <viivien>cedb, you need to add them in .profile or .bash_profile, not .bashrc <viivien>If you log out and log in again, they should be set <cedb>i get a "no such file or directory when I add the lines to profile" ? <nckx>A different rendering, I mean? <nckx>cedb: Can you be more specific? <jgart>hi guixers! wdyt of being able to run individual build phases from the CLI? guix build --phase=configure, guix build --phase=build, guix build --phase=check, guix build --phase=install, etc... <jgart>above is just a quick hypothetical API for what this could look like <cedb>nckx: Last login: Sun Feb 27 14:30:52 2022 from fe80::bde0:98cd:d8c:64cf%eno1 -bash: /home/ced/.guix_profile/etc/profile: No such file or directory <SeerLite[m]>I think you have to `guix pull` to create the .guix-profile <Michal_Atlas[m]><jgart> "hi guixers! wdyt of being able..." <- Yes, please, whenever I hear this I'm more surprised that It doesn't exist yet, than anything <cedb>SeerLite[m]: but the file /is there/ <cedb>ahh guix pull worked, i think the guix_profile/etc/profile was sourcing another file in term which wasnt there <jgart>See: nix develop --configure, etc... <podiki[m]>ugh, stupid formatting, but guix dash profile, not guix underscore profile *cedb blames his fucked up sleep cycle <podiki[m]>jgart: I like the idea, maybe as a simple first pass, it simple injects a new phase after the one you want to build up to, where it errors out there? or maybe you want it to dump you into the temporary environment (like using -K and then going to the /tmp directory with sourcing the env it set up) <jgart>podiki[m], Yes, that would be awesome :) <podiki[m]>or maybe something that builds off of guix shell? <jgart>(sh/$ ./configure --without-bash-malloc "--prefix=" ^ (dyn :pkg-out)) <nckx>Unexplained Mysteries of the Fucked-Up Sleep Cycle. <jgart>instead of most build systems being based off of modifying gnu-build-system phases you just call what you need to build the package in question. <podiki[m]>for testing/debugging would be good to have something that just builds up to a certain phase and lets you go in that environment <podiki[m]>I'm not sure about revamping the build systems, though yes, can be confusing to know each part of some build system <dominicm>nckx: It looks fine on the issue tracker, but it's weirdly formatted on the mailing list. I'm assuming that's what the reviewers would be looking at, hence my concern. <dominicm> 02/21/2022 S guix-pa... dom@dominicm.dev [bug#54103] <dominicm>�37487� 02/21/2022 S dom@dominicm.dev o [PATCH] gnu: Add fcitx5-anthy <dominicm>�37947� 02/22/2022 RS GNU bug Tracking Sy... └>bug#54103: Acknowledgement () <dominicm>�37831� 02/22/2022 S guix-pa... Dominic Martinez └>bug#54103: Acknowledgement () <nckx>Well, I don't know what you mean by ‘the mailing list’. Threading looks OK in my RoundCube, my mu4e being out of order for the moment. <nckx>I think that's OK. You now know how to send-email to Guix's debbugs in future? <jgart>How should we open discussion on the nix daemon rewrite? Do people fully understand what the daemon does to reimplement it? Do we have a spec of some sort? <nckx>I don't think we do, and it would be decades out of date compared to Nix. You're aware of the previous rewrite attempt by reepca? Else I'd start there, see if they wrote a dirty-room spec of some kind. <nckx>The ‘good’ news is the daemon's been practically stagnant since then. <dominicm>For a patch with one commit yes, I think I'd either use ~--annotate~ or just send the patch manually. Do you know how you would send a patch with multiple commits though? It looks like you have to send the first one, wait for an acknowledgement, and then somehow send the rest to <patch-number>@debbugs.gnu.org right? <nckx>--to=NNN@debbugs.gnu.org being the ‘somehow’. <jgart>nckx, is the reepca attempt the one in the guile-daemon branch? <nckx>reepca being Caleb Ristveld(sp?). <jgart>I gave it a quick glance tbh <nckx>It was an internship, and there might've been some problems during it, I don't remember so will remain vague. <nckx>Communication was suboptimal and I don't know if we got everything that was in Caleb's head back then properly backed up ☹ <jgart>Reading through the 7 commits, it would be great if there was some bird's eye view of what the idea for the guile rewrite is on a specification/concept/architectural level <drakonis>the patches all reimplement a 1:1 mapping of the nix daemon in guile <nckx>I'm with you. I think it's a good idea to start a (new is fine) guix-devel thread where such information can be gathered if it exists, and new plans made. <jgart>It's hard to see the forest for the trees without high level documentation on what they did or were aiming to do <drakonis>but there isnt anything in place for a daemon to function <nckx>Just a question; I'm not browsing the codez or anything. <jgart>Ok, let's collect our knowledge on what a nix daemon is supposed to do and what we need to build in the future on guix-devel <drakonis>basically, it is a series of procedures that implement pieces of the functionality the daemon possesses <jgart>Might be good to get in contact with Caleb in order to not reinvent the wheel <singpolyma>The daemon basically exists for suid purposes, right? <nckx>I think that's a good approach. On ‘too grand’: while the result of the internship was disappointing for everyone, it's not like anyone's done anything close or better. <drakonis>the pitfall would be doing anything grand <Kolev>Apps are crashing because of the file chooser. <drakonis>since it would require pervasive rewriting of guix to do it <nckx>That's why it's a root-run daemon, but the code is not just some thin suid stuff. The deamon exists to abstract the store, that's quite a bit more. <jgart>would going daemonless be a viable approach for Guix? <nckx>Drop in first, then we have an excellent test suite (all of Guix and its innocent users) to make sure we're good before the ‘innovation’ starts :) <nckx>jgart: I dunno what that buzzword means. <nckx>‘Maybe’, but also ‘why’. <jgart>that is, using a setuid binary instead <drakonis>going daemonless also requires pervasive changes <singpolyma>jgart: I mean, the difference there is just the kind of IPC. So should be doable if someone cared <drakonis>basically, anything short of a almost total rewrite of its inner guts for anything like this <nckx>It sounds like a slightly different way of achieving the same thing (with roughly the same pros/cons). <jgart>Do we know/understand everything that the current guix daemon does? <jgart>Maybe we should start by writing technical docs to see what we understand. <nckx>I'm not impressed by Hermes but that doesn't mean we can't steal the good parts. <jgart>Yup, that's what I mean. We can borrow the good parts <nckx>jgart: I think ‘we’ do, collectively (as long as Ludo' doesn't go bus hunting), but it's not written down. <drakonis>i had been going through the source code for the remains of the nix daemon and there's still plenty of things that exist in a sort of a impedance mismatch <drakonis>i don't know where the daemon begins and guix ends <jgart>We should try to make the guix daemon technical knowledge to be easily available. I think the way to do that would be excellent technical public docs/notes on what it currently does. <drakonis>just a sec, let me look up the source for the existing daemon rewrite patches <drakonis>i get the feeling that it is still missing a lot of things <drakonis>build-derivations.scm is what you need to look into <SeerLite[m]>Hi! Should packages be fully functional in `guix shell --container`, or are "missing command" errors expected? <SeerLite[m]>I feel like Kakoune is missing coreutils, findutils and sed <roptat>depends on packages, sometimes we replace the call to a tool with a direct path to the store <sneek>Welcome back roptat, you have 1 message! <sneek>roptat, blake2b says: if he happened to save the discussion notes from day 1 of guix days <roptat>oh I need to have a look at the logs :) <singpolyma>SeerLite[m]: inputs are things needed at build time for the package <singpolyma>SeerLite[m]: does kakoune actually fail to run without sed? <roptat>SeerLite[m], I think there are two things we consider: do we want to tie the tool to a specific version of these programs, or do we prefer to let it find anyone that's available in the environment <SeerLite[m]>singpolyma: Oh, then I misunderstood what inputs are haha <singpolyma>I think if sed were a hard dependency it should be written in. But if it's just "a tool you're likely to want that it knows how to use" then it makes sense to leave floating <SeerLite[m]>It doesn't fail to run but it haves errors and warnings at startup, some functionality that may be considered important could fail <singpolyma>Hmm. Printing errors at startup but still working feels like a grey area to me <SeerLite[m]>Kakoune uses POSIX shell scripts for some built-in functionality not written into the core <singpolyma>Right. It's possible those scripts need to have their tools substituted in for store paths in the package build <SeerLite[m]>findutils may be very important, as it's used to load some startup .kak files IIRC <singpolyma>If you wanted to propose a change that's where I'd go poking to make the patch <SeerLite[m]>singpolyma: Alright thank you (and roptat), this makes sense. I'll have a look in a bit to see what dependencies are important <roptat>I was very busy lately doing administrative work and finishing my LFS translation <ajarara>is there a way to check a package builds on other systems? I want to contrib another one and noticed that one I contributed earlier doesn't build on GNU/Hurd. <ajarara>A command to fan out and build/test on containers would be great. <ajarara>Although I guess not sufficient? Since there are plenty of cpu architectures. <paul_j>Evening all! I am hitting a problem with mpd, starting as a home shepherd service. It looks to all intents and purposes like the issue identified at the end of 2020: #44820. In that case, there was an issue with the ownership of /var/run/mpd, and the problem was overcome with a new commit. (full details at https://issues.guix.gnu.org/44820). What I am finding which is different - there doesn't seem to be a /var/run/mpd directory created <paul_j>anywhere I can identify - ~/.guix-home/profile/ or /run/current-system/. Can anyone point me to where the log file should be written? Thanks! <SeerLite[m]>singpolyma: Yup, all three dependencies are important. I think the startup script exits on the first error encountered so the following stuff doesn't get loaded. Syntax highlighting, for example, doesn't work <Michal_Atlas[m]>ajarara: You should be able to use --target to select an architecture and there's a service that is able to do that through qemu locally, there's even a guide to get it offloaded to a Hurd vm in the docs <paul_j>mpd runs from a shell with no issues. <ajarara>Michal_Atlas[m]: actually, would I get this kind of thing 'for free' if I just got a cuirass instance going? I've wanted my own anyway. <ajarara>yep, seems like that's a thing in the cuirass info pages. I'll give it a try.