IRC channel logs
2025-03-22.log
back to list of logs
<civodul>well i’m not familiar with Prometheus, but i thought that having something to monitor resource consumption of running services would be nice <graywolf>I was currently more aiming at getting alerting for services crashing. I need to spend some time on this, I currently do not understand shepherd nearly enough. <graywolf>(For Prometheus, serving metrics boils down to HTTP endpoint serving data in simple, text based format. So that part is easy. What I need to do is figure out how to get the data. :) <vagrantc>how can i add a phase that just causes a build to fail ... <ieure>vagrantc, My go-to "make the build fail" is (lambda _ (/ 1 0)) <lechner>i've also wished in the past that build phases would fail on #f <ieure>lechner, I suppose, but it's also the most succinct way to get a failure. <ronqui>it's been so long since i originally specified my system that like 5 parts of the operating-system specification are different <lilyp>mine is (lambda _ oops) where oops is any unbound symbol :) <untrusem>So I deleted the gdm service type and reconfigured my system, It will be configured successfully without any errors, and I use encrypted drives, so when I try to start the system it says `error: file /boot/grub/x86_64-efi/normal.mod´ not found <untrusem>I think I will need to use rescue distro, do debugging stuff from there, am I right? but what could have caused this? <untrusem>So as I have the encryted drive, so I found the boot directory, in (crypto0) <untrusem>But no one dot mode couldn't be found in either (crypto0)/boot/grub or (crypto0)/boot/efi <xelxebar>untrusem: Was your configuration booting before the reconfigure? <untrusem>I don't actually remember. I think it was uninterrupted. <xelxebar>GRUB better be sitting on an unencrypted partition, because you need GRUB just to decrypt the partition in the first place. <xelxebar>It seems like you're reasonably comfortable using the recovery console. <xelxebar>What drives does GRUB think it has available? <xelxebar>Ah, so you used cryptomount to decrypt that? <untrusem>So, what is happening? I am successfully entering the passphrase for the msdos2 and it is successfully opening the slot, but then it says the normal.mod not found and it enters the grub rescue mode. <xelxebar>Ah, okay. Thanks for the explanation. That makes the situation much clearer for me. <untrusem>There are 5 drives, 1st is Crypto0, 2nd is proC, 3rd is hd0, 4th is hd0, msdos2, 5th is hd0, msdos1. <untrusem>Out of these 5, only crypto 0 can be accessed <xelxebar>FWIW, normal.mod usually sits under /boot/grub/<arch> (e.g. /boot/grub/x86_64-efi) <xelxebar>Does that directory even exist on your system? <untrusem>Yep, so I'd set the root to crypto0 and the prefix to the boot folder and did insmod normal, still couldn't find the file. <untrusem>Yes, the boot folder does exist on crypto0 <xelxebar>And you see normal.mod under that folder when you ls it? <untrusem>There are lots of .mode but let me check one by one <xelxebar>Cool. So we know that your filesystem looks correct. That's encouraging. <xelxebar>Wait, not normal.mod, but ~normal.mod or normal.mod~? <xelxebar>Yikes. So almost *all* your modules have trailing tildes on the filename. That's definitely not right. <xelxebar>untrusem: I wonder if insmod can take a file path instead of a module name. <xelxebar>Cool. Since your module filenames are messed up, you won't be able to use the normal command, since grub.cfg almost certainly runs insmod. <xelxebar>However, you could manually run the kernel and initrd commands to execute a manual boot. <xelxebar>GRUB should have a cat command, so you can just manually copy the arguments from grub.cfg <xelxebar>Not sure if cat, echo, etc are part of some module, though... <xelxebar>I think they should be available once you load the normal modulee. <untrusem>Where is the kernel and intrid image in geeks? <xelxebar>untrusem: They're under some output in the store, so under /gnu/store somewhere. <xelxebar>Can read grub.cfg now, and I assume you can figure out the rest <xelxebar>Obviously, that will just get your system booted. You'll want to fix your grub module filenames once before rebooting, obviously. <ulfvonbelow>is python-pydata-sphinx-theme failing to build for anyone else? <xelxebar>untrusem: There might be a head command or some other that pages for us. <xelxebar>If you load the help module, that'll give you the help command, which mentions this variable. <untrusem>I turned off the machine and went for a walf <untrusem>xelxebar: so, I tried entering commands from grub.cfg <untrusem>I couldn't load modules like luks2, cryptmout etc. <Rutherther>so your grub couldn't load the modules from the module folder. It's not surprising if it hasn't loaded the config either. They are at the same place <Rutherther>and if you can't really load modules I don't see other way than booting to live iso and reconfiguring your system from a chroot <Rutherther>(unless it can't load them only because you haven't set the partition with modules as current one) <untrusem>I set up everything on one partition in guix installer <Rutherther>it's impossible to do everything on one partition with efi <untrusem>Never tried live iso, so if you can link me to a guide to it, it would be helpful. <untrusem>efi is on another partition / is on another <Rutherther>yes, I expected one disk. But you still have multiple partitions. And it's a question where the grub modules are. For example I have my efi partition mounted at /boot and guix puts grub modules there, so I have my grub config files unencrypted. If you have them encrypted, your grub should have the modules available in the grub .efi file directly <Rutherther>how have you installed guix if not from live iso then? <Rutherther>but earlier you said you see the disk contents of your encrypted disk with the /boot folder. So I am confused why you're now saying you can't load cryptomount, you must have already loaded it to get encrypted disk content <untrusem>Yes, I tried but I still can't load crypto module. because most of the module have `~´ after them <Rutherther>because from what you said earlier it sounded to me like you do have it unencrypted. And if that is the case, just don't load luks nor cryptomount, you already have them, so there is no point. Only call the linux initrd and kernel, nothing else is necessary after opening the disk <gabber>is it possible to declare (additional) guix channels in the operating system definition? <futurile>gabber: bah that's completely the wrong link - it's in the 'Base Services' section of the manual. <gabber>futurile: do you know if there is any example code of that floating around? i get "unbound-variable" for (channel) even though i import (guix channels) and (gnu services base) <futurile>gabber: it defines a 'system-channels' variable line 59 <futurile>gabber: line 214 - configures the guix service - specifically 229 and the authorized keys in 226 <futurile>gabber: other bits you can ignore - it's just setting up to use my local workstation for substitutes <csantosb>Hi Guix emacsers, out of curiosity, are you using scheme-mode or guix-scheme-mode ? Just discovered the later, a bit too invasive I'd say <lilyp>I use emacs with geiser; what is "guix-scheme-mode"? <csantosb>Comes with emacs-guix, in guix-scheme.el; similar to guix-build-log-mode, etc. <hako>guix-scheme-mode is used for visiting builder scripts in /gnu/store I think <csantosb>Unrelated: is it possible to remove default config flags (say CONFIG_SHELL) in gnu-build-system (other than `replace 'configure`) ? <csantosb>hako: "This mode is the same as `scheme-mode', except it also reindents the current buffer after it is enabled" <lilyp>csantosb your own flags are appended so you could probably override them? not sure if make supports last shadowing first <csantosb>lilyp: tried that, but I get an `unknown option CONFIG_SHELL' <lilyp>ahhh, in that case you're dealing with a non-GNU style configure script and have to override the phase <csantosb>ok, not a big deal, just trying to understand, thanks <futurile>hako: is it safe to commit to the rust-team branch while you and efraim make changes to the build-system? Or should I hold-off adding packages? <xelxebar>untrusem: Yes, your module filenames are broken, so any insmod commands will have to directly reference the filename, just like you did with insmod /path/to/normal.mod~ <xelxebar>That said, you really shouldn't need any of the graphics modules. <xelxebar>You should be able to simply set root=whatever and then run the linux and initrd commands from the top menuentry in grub.cfg <apteryx>is it possible fetch sources from a github PR with the source transformation options, e.g.: --with-branch or the likes? <apteryx>so far I'm failing, e.g.: guix build falcosecurity-libs --with-branch=falcosecurity-libs=pull/2314/head:pkgconfig-fix-again -> cannot locate remote-tracking branch 'origin/pull/2314/head:pkgconfig-fix-again' <Rutherther>apteryx: it is, because you can just put .patch at the end of url for a pr and that will give you a patch file. So then you can just use --with-patch. <Rutherther>apteryx: if you wanted to use with branch, you would have to change the git url as well to the fork repo. Then for the branch you would need to use the branch the author used for opening the PR (it's listed in the PR's page) <apteryx>I guess that could work, if it applies cleanly on top of what is currently packaged <apteryx>but from the git cli it's possible to fetch 'pull/ID/head' from the origin remote, so I thought this must be possible using guix directly as well <Rutherther>I wasn't aware that github ships custom refs. Maybe it's possible use them then. But if it's so, you would have to start your specification with 'refs/' I am pretty sure. And that :pkgconfig-fix-again is definitely not going to be supported as that is a git feature to make it into a branch in a local checkout, so it would be just something like "refs/pull/1234/head". <Rutherther>nope, doesn't work, so I don't think so. I think that git-reference doesn't support refs directly, only the regular ones like refs/tags <Rutherther>apteryx: I was trying to come up with a quick patch to support remote refs but it looks more complicated than I anticipated. I don't even know how to let guile-git fetch custom reference. The thing is that while branches and tags are available locally and all fetched with the repo, it's not like that with those custom refs that are just omitted and you have to request them separately via git fetch. <apteryx>I see. So it'd need some new code paths. <apteryx>Assuming guile-git already has what's needed <untrusem>Rutherther: ok so grub rescue doesn't have tab completion and typing the full Command will be hard <Rutherther>but yeah, the grub rescue is not very user friendly, that's why it's usually easier to just boot into another system and do system reconfigure from chroot <ronqui>guiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiix <Rutherther>also... make sure to mount the efi partition at correct place, while the manual lists the /boot/efi, you can actually put it wherever, so it depends on your config, specifically what you have in targets field of the bootloader-configuration <untrusem>So I have encrypted drives and do I need to first open them in the live distro? <Rutherther>yes of course, you need to have your disks mounted as is in the manual <untrusem>i am booted into rescatux.org live distro <graywolf>I would suggest to just use archlinux install image. <graywolf>It runs fully from RAM and has all the tooling required. <graywolf>At least that is the distro I usually use for this type of work. <muaddibb>I would also sugest using Ventoy if you're using a thumb stick <futurile>muaddibb: I've heard Ventoy mentioned a few times, what does it do that's really good? <Rutherther>it gives you the ability to add multiple systems (merge them) you can boot into on one thumb stick <futurile>oh that sounds cool - huh, should check it out <muaddibb>futurile: in short, it creates a partition on your thumb stick where you can add or remove multiple system images freely. you select which system you want to use from a menu when booting up. You can also add regular files and use like any other thumb stick. It uses vfat, I think <futurile>muaddibb: pretty useful for testing different distros then - or for me testing different guix system images <futurile>Rutherther: were you able to confirm whether that unclean umount problem was solved with the new shepherd? <untrusem>Rutherther: checked my config, The port partition is in "/boot/efi" <untrusem>I unlock the partition and mount it to /mnt <untrusem>So I guess I should mount the boot partition to /mnt/boot/efi <Rutherther>futurile: if my reproducer got the same issue as ieure, then yes and it was solved <untrusem>So do I need to change something because something happened with grub or should I just reconfigure the system? <Rutherther>it's hard to say without knowing the cause. I would just reconfigure and inspect the grub files afterwards <Rutherther>if you currently have grub files ending with ~, it shouldn't be the case afterwards <Rutherther>if it is, something is wrong and will need attention <untrusem-on-resc>guix system: error: error parsing derivation `/gnu/store/q98qs8330q32v94dmzrckmx8zf6792ji-switch-to-system.scm.drv': expected string `Derive([' <Rutherther>please update to newest guix so that you don't get disk corruptions anymore <Rutherther>I think it's quite reasonable to then conclude that your grub issue is also a disk corruption <hako>futurile: The change itself is compatible with existing packages so there won't be conflict on my side. <Rutherther>yes, guix pull. But you can actually do that after you boot into a working guix system. The thing is that in chroot you will be manually unmounting the disks, so there is no risk of corruption <Rutherther>right now you will need to fix the disk (guix gc --verify=contents,repair) <Rutherther>you can also try switching to earlier generation because that one might not have corrupted files. But you should still get rid of the corrupted files eventually <Rutherther>also could you tell me what guix commit you're on? (guix describe) <futurile>hako: OK, thanks for confirming. Looking forward to the changes you're working on! <Rutherther>it's up to you, it's better to make sure there are no corruptions <Rutherther>switching won't fix the files, but could give you a bootable system <df>I'm a bit confused on the relationship between services and packages <df>for example, I'm trying to fix this issue with tlp when run as a service <df>but my change (adding an input) is to the package config <df>yet I can't see anywhere in either the tlp service definition or my own system config that actually touches the tlp package <df>something that tells it that the tlp package is a requirement <df>it has made it into /gnu/store somehow but I can't see what put it there <df>(also my fix hasn't worked but I feel like I need to understand this more fundamental issue first) <Rutherther>df: services don't have 'packages as requirements'. They just reference packages. Tlp specifically has field called tlp in tlp-configuration. Then in the shepherd service (tlp-configuration-tlp config) is ungexped to get path to the store written to the service definition <apteryx>wow, what happened; gnome shell stopped working <apteryx>try e.g. launching the VM with: /pre-inst-env guix system vm gnu/system/examples/desktop.tmpl <df>Rutherther: ok, so which bit of the code actually gets tlp into the store? <df>the shepherd service code? <ieure>df, Packages are either substituted or built on demand when something needs them. <Rutherther>df: that is not easy to answer. It goes all the way up to an open connection to the store from making the operating-system-derivation. <apteryx>maybe my update of mutter from 46.8 to 46.9 <df>ieure: but the necessity for them to be there (whatever it's called) must be declared somewhere? <df>Rutherther: ok, back to the books... :D <apteryx>nevermind, it works on 46.9. I was forgetting the -m 4g of qemu <df>ieure: well, tlp-service-type won't work if it doesn't have a tlp package available in the store right? <ieure>df, Yes, but that situation is impossible. <df>btw my fix (adding coreutils-minimal to the inputs) doesn't seem to have helped, I still get errors from tlp that id and mktemp aren't available <Rutherther>df: where did you change tlp specifically - are you sure tlp service type is using it? <df>ieure: yeah so I guess that's my question, what makes it impossible? <df>Rutherther: no, not sure at all, I changed the package definition <ieure>df, Because tlp-service-type has a reference to the Scheme variable defining the package, so when it needs the package, Guix either substitutes or builds it. <Rutherther>df: changed in guix source and then ran ./pre-inst-env or what? <df>ieure: ok, and that reference is in (define-configuration tlp-configuration ? <Rutherther>df: just having something in a record doesn't make make it impossible. Referencing it properly does, in this case ungexping. <ieure>df, The variable holding the reference to the TLP package is in tlp-configuration. The *value* of that variable determines which precise TLP package is used. The default is the TLP package in Guix, but you can specify a different one. <df>ok, but if the default is the standard tlp package, that is what I should be focusing my efforts on fixing? <ieure>df, Well, that's the one that's broken, right? <ieure>df, The thing here is that you can do stuff like define a fixed package in a separate channel, then use that package instead of the Guix default one, by referencing it in your operating-system config. <Rutherther>the default is the symbol tlp in gnu/packages/linux.scm, so if you changed it directly there and used it for the build, then your tlp is used <df>so as far as I know I haven't changed which tlp package is used <df>that is, I'm using the one in the guix source tree, which I have modified <df>and all I've done (apart from reformat the input list to use the new style) is add coreutils-minimal to the list of inputs <df>is there an easy way for me to check that change has taken effect? <df>because as far as guix package is concerned, tlp isn't installed <Rutherther>df: if you meant to add coreutils-minimal to the running script then just adding to inputs is not enough. You need to wrap the resulting binary with a PATH prepending path to coreutils <ieure>Or update the scripts to point into the store -- IMO this is preferable to wrapper scripts. <df>hence my question about the relationship between packages and services <Rutherther>ieure: oh yeah, definitely. Now that you mention it I think I remembered it's just shell scripts since I was investigating it few weeks ago <df>ok, I've found a bunch of existing changes I should be able to crib from <ngz>df: I don’t think adding coreutils to inputs will help <ngz>df: I think the issue is that only scripts from "bin" <ngz>However, tlp-func-base, from "share/tlp/" also needs to be patched. <df>ngz: well it looks like it is already patched to some extent <df>readonly CONF_DEF=/gnu/store/zmncvx80hsj2d8c0a209dxvk9frl7jnn-tlp-1.8.0/share/tlp/defaults.conf <ngz>Look at the 'wrap phase <df>although that comes from a variable actually... <ngz>It only takes care of bin-files. <ngz>I’m not sure it is the best fix, but also wrapping "share/tlp/tlp-func-base" would help. <df>ngz: I was thinking of changing the set-absolute-locations-phase to put the right values in tlp-func-base <df>does that make any sense? <df>that's the wrong package <df>ok so I change wrap to modify tlp-func-base? will that work though, it looks like tlp-func-base is a lib rather than a standalone script <ngz>Hmmm… you are right. Then binaries locations need to be changed piece wise in the file. <ngz>df: the problem only arises when using tlp service, not tlp package, right? <ieure>ngz, I don't think that's the case. <ieure>ngz, I think the problem exists in the package, but you don't typically use it in the ways the service does. <ngz>Well, it’s still not clear to me, but I trust you. <ngz>The thing is all entry points in bin/ have access to the correct $PATH. So calling those should not be a problem. <ngz>Now, if there’s an entry point elsewhere, such as in <ngz>tlp.d, the PATH is not set <Rutherther>it is sbin directory that is important as it has tlp executable <ngz>Recent TLP probably introduced sbin/ directory <untrusem>Rutherther: I rebooted into the live distro again because the previous one just gave me blank screen and did the steps when I ran the guix gc verify command it couldn't repair any path and when I tried to switch generation it can't do that <untrusem>so it can't repair stuff in that generation <graywolf>You can repair only substitutable items iirc. <ngz>Rutherther: It looks good. Can you send it to the ML so I can apply it? <Rutherther>ngz: sure thing, but I will have to test it first for my conscience to allow me to send it there :) <Rutherther>untrusem: for unsubstitutable paths getting rid of them with gc is the easiest option, basically switching to different generation and then deleting the newer one. But you can do it after being in the guix system <Rutherther>because if so... then it's not a good outcome of switch, the bootloader has to be installed, if not, your files will not be repaired... are you sure you didn't get this error the last time you ran reconfigure in the booted system? Because if so, then that explains it all <ieure>Rutherther, Taking a look at it now. <untrusem>I didn't switch generation in booted system <untrusem>and when I did one time it was in the beginning <Rutherther>I wasn't talking about executing switch-generation, but about reconfigure <Rutherther>ieure: great, thanks. Did I write the commit message properly? <Rutherther>I have serious trouble following the changelog rules :) <ieure>Rutherther, Yes, though your fill-column looks like it was set lower than I'd expect. <untrusem>Rutherther: I did get something like this, when I reconfigured the system <Rutherther>ieure: I actually broke the line by hand xD I somehow started doing that initally and cannot get used to the auto wrap stuff <Rutherther>untrusem: okay, so that explains the whole issue. And for future: don't reboot if you get error especially in install-bootloader if you don't have to, rather try switching to previous generation if that will reinstall the bootloader properly... <Rutherther>for now, does switching to earlier generation produce this error as well? <Rutherther>alright, can you try deleting the generation 12? <Rutherther>and does the switch work now or still same issue? <Rutherther>I am thinking that the errors could be fine as they come after the bootloader is installed. Can you check if grub files look alright? <Rutherther>but the last command you run definitely should be switch-generation to an older one, not reconfigure, we've already established you can't reconfigure properly <untrusem-on-live>ok so the modules directory now have alll modules and modules with `~` at last in their name <Rutherther>okay so if there are both, it could be fine. The ones with ~ will probably have to be removed manually <Rutherther>they shouldn't really matter except for the space they take <Rutherther>okay then I am out of guesses and you can try lsof to see the processes using it <untrusem>What should be my steps to repair the system <Rutherther>yeah, something like that. But your verify will probably fail to repair all and you will need to remove the paths it doesn't repair (using guix gc with -D or no arguments to just delete everything that is not gc rooted) <Rutherther>in case some of the things that are corrupted are gc rooted, you will need to also remove those. But I think that if you've removed all newer generations than what you're on currently, it shouldn't be gc rooted <Rutherther>if you don't mind deleting everything that's not gc rooted, you can just run guix gc as second step and only then the verify as third to just see if everything corrupted has been deleted <Rutherther>can I somehow ensure the guix installation iso will load fully to ram memory? I have a usb stick that's not very reliable with making contact with the pins, but I can hold it in place with my hand <Rutherther>it seems to me that if I use something, it gets somehow loaded and I can use it even after the usb is disconnected. But stuff I haven't used becomes unavailable and thus the system unusable after the usb is disconnected <untrusem>you are more knowledgeable than me in this <untrusem`>so getting this `error: executing SQLite query: database disk image is malformed` while running guix gc verify <Rutherther>I mean you can try like this - https://stackoverflow.com/a/5316540. The db is at /var/guix/db/db.sqlite, but db corruption usually means a lot of trouble and at that point it might be easier to just reinstall your system (deleting /gnu/store and /var/guix before reinstalling, rest of the disk can stay the same) <Rutherther>yeah you can definitely do that but the thing is that when it goes corrupt, data is missing, and that is an issue <untrusem`>yeah, this is not related to my actual ssd, is it? <Rutherther>it's hard to say, but probably not. There was a bug recently that led to root filesystem not unmounting cleanly. That leads to disk corruptions of new generations expecially if your process is to reconfigure and reboot right away. <Rutherther>the issue is probably gone, because I was able to reproduce it in a vm with older guix, and with newest the issue is gone <untrusem`>so what are the things I can do to make reinstallation as painless as possible? <Rutherther>guix reinstall is pretty much the same as reconfigure. It's definitely better to backup your data, but they should stay intact if nothing goes wrong <Rutherther>so it's easiest to just use the guix installation iso, not other distro. But even other distro can be used, you just have to install guix <untrusem`>So the process wil be > mount into guix live distro > mount stuff as today > remove /gnu/store and /var/guix directory contents > cow-store -rw /mnt > system init <untrusem`>will I need to mount proc,dev,sys as well like today? <Rutherther>also note that you won't be able to "rm -rf /mnt/gnu/store", you will first need to make it writable with "chmod -R +w /mnt/gnu/store" <Rutherther>and this all of course means losing your previous generations <untrusem`>I have to remove the directory contents for /gnu/store and /var/guix or the whole directory? <Rutherther>you won't lose sdd contents as long as nothing goes wrong, that's why it's better to backup <attila_lendvai>did something related to ssh key management change recently? after a pull i need to type in my ssh key password every time (as opposed to a single time per boot) <Rutherther>with gnome update the agent isn't included anymore <lilyp>yes, you have to run it manually now; it's hidden in the libexec folder of gcr <attila_lendvai>so, the full recepie is: 1) $(guix build gcr)/libexec/gcr-ssh-agent --base-dir=$XDG_RUNTIME_DIR/keyring/ -- and 2) export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/keyring/ssh <attila_lendvai>now the question is, where should i put it? simply in ~/.profile? <Rutherther>think someone has already written a home service and sent it here a few days ago <Rutherther>btw I think it's better to replace the #$profile with #$gcr in the sourcecode of the service to not rely on system profile having gcr <attila_lendvai>yep, good point. thank you all for the help! BTW, is it possible to use something like #$(file-append ...) in home services? how do i reference a package's store path in a non-gexp context? i tried to use a #~() as e.g. aliases, but it is unexpected there <attila_lendvai>that service doesn't work for me as-is. seemingly runs fine, even restarts, but `ps afxu | grep ssh` comes back empty. <attila_lendvai>wait, i noticed a mistake i made (but shepherd gives zero feedback about it) <Rutherther>attila_lendvai: it is definitely possible to use #$(file-append ...), but there is already that string-append which is also suitable <attila_lendvai>Rutherther, i meat in a home.scm file that is the input to guix home reconfigure. in the services it's possible. <Rutherther>attila_lendvai: oh... well that depends where you want to put it exactly <attila_lendvai>it works finally... FTR, that make-systemd-constructor is some lazy magic that delays starting it until the first use <Rutherther>attila_lendvai: yup definitely possible to use file-append in aliases, ie. (aliases `(("name" . (file-append package "/bin/pkg")))) <Rutherther>like this: (aliases `(("name" . ,(file-append package "/bin/pkg")))) <vagrantc>hrm. really struggling to define a system service that just calls a single script from a single package ... <attila_lendvai>i failed to make that work last time, but now it works. thanks Rutherther! <attila_lendvai>vagrantc, i do something like: (fork+exec-command (list #$(file-append bash "/bin/bash") "--login" "-c" "cd /srv/zigbee2mqtt && npm start") ...) <Rutherther>vagrantc: simple-service already returns a service, not a service type, so you should put it to your list directly as "reform-hw-setup-service" rather than "(service reform-hw-setup-service)" <vagrantc>or at least, looks the same to my weary eyes <vagrantc>the sheer number of hours wasted on that ... <vagrantc>wondering if i can leave the /bin/bash bit out <Rutherther>vagrantc: you can't leave it out, you will get reference to the gnu store path folder. Also note that you don't have the slash before bin, that's not right <vagrantc>well, no traceback on reconfigure ... let's see if it actually runs <vagrantc>the simple-service-type is a bit deceptive in the name <vagrantc>well, it worked once i changed "(service reform-hw-setup-service)" to "reform-hw-setup-service" ... <attila_lendvai>ACTION has alway found that part super confusing... there are two entirely different things called service there <Rutherther>one is service-type, the other is service. Service is like an instantiation of service-type, along with a config. simple-service makes a type and creates a service out of it, hence the name doesn't contain -type at the end <Rutherther>is anyone able to get the efi-raw guix system image type working? I don't know if my system definition is missing something essential for it, but I am getting "/gnu/store/2r800qm879lvwd4cbr517njmq4hdrbdf-grub-2.12/sbin/grub-bios-setup: error: cannot find a device for . (is /dev mounted?)". <attila_lendvai>my confusion was mostly between shepherd services (i.e. something that runs, that is alive and responds), and guix services (i.e. components of an OS definition). and they are often used in the very same context <ieure>attila_lendvai, Many Guix services manage Shepherd services, its seems like a common mistake. <futurile>we have some terrible naming - 'services' used multiple ways is one of them heh <attila_lendvai>if it had been up to me, i would have called them 'components', or anything else than 'services'... <futurile>and the hilarious 'home services' which aren't services at all <Rutherther>futurile: could you elaborate? in my viewpoint they are the mostly the same as system services, only working on home level <attila_lendvai>the issue is with the gnome-extension only. the rest seems to work fine. <futurile>Rutherther: generally (in my opinion) people use the word 'service' to mean something that runs continuously (yeah I know there are one-shots), so it makes sense for an inetd / systemd / Shepherd. But for 'home services' the majority are things that run once and make changes to files - e.g. alter bashrc. We're overloading that word a lot imho. I'm not sure what the right word is, and I understand the <podiki>well there are also people like me that use guix home for everything but one-shot/configs <podiki>(currently mostly stuff i haven't upstreamed, but also gpg, pipewire) <futurile>podiki: yeah, I know it is capable - that's why I'm not sure what the better solution was - I just think it's conceptually a bit confusing given the 'assumption' people bring. Something that doesn't have an assumption would have been better <podiki>naming things is hard, of course <ieure>futurile, Don't agree, there are many of home services that run daemons. redshift, pulseaudio, mpd, gpg-agent, etc. <Rutherther>futurile: I agree with that, but don't really see what it has to do with home services that also wouldn't apply for system services. The system and home services work very similarly, there is an activation service built from them, and executed once, there is for example the etc service is about that, privileged programs in system that do exactly this... <futurile>yeah, it maybe that I approached the home capability with the expectation that it was a "dotfile manager". <futurile>Anyway, I'm not proposing anything - we have enough problems reviewing/improving home services without any attempt at a mass-rename - and as we see I can't imagine we'd get to consensus <podiki>that's a big thing people use it for i would assume, though many already had their own <civodul>speaking of home services :-) anyone has an offlineimap service? <podiki>i have a goimapnotify service i use, it gets push notifications for emails essentially <podiki>so goimapnotify knows when there are new messages and runs mbsync, and mbsync runs on a timer for general syncing via emacs <vagrantc>hrm fails to start. i probably never had this working. only looked like it worked when i ran the command manually and rebooted <vagrantc>ah, bash needs a full path ... or something. <podiki>though my goimapnotify service is mostly a simple thing to call goimapnotify, didn't put the config in scheme <ieure>podiki, offlineimap service is easy, the difficult thing is secrets management. <vagrantc>but should i not be able to just call the script directly? it has the appropriate #!/gnu/store/.../bin/bash in the script <ieure>Which you gotta have to do offlineimap safely. <podiki>my msync config file just uses the passwordcmd or whatever entry to call pass <df>Rutherther: sorry, got distracted by that irksome 'real life' thing <df>thanks for the fix, works great :) <ieure>podiki, Yeah, that works for some usecases, but not if you keep your private key on a hardware token and the encrypted password in a private Git repo. <podiki>i assume you could do similar with offlineimap? <podiki>upon service start or after resume, i have to tap my hardware key <podiki>(well the git repo is local/on my own server, but either way it is via pass to handle the gpg-ing) <df>have to do some more Real Life stuff now but I will try to understand *how* it works tomorrow <Rutherther>ieure: why doesn't it work with a hardware token and encrypted password in a private git repo? <Rutherther>podiki: yes you can do it milarly with offlineimap, you define a python function that will call pass and then just call that function from the offlineimap config <podiki>Rutherther: i think i stole the wayland home service from you, did you see #76058? <podiki>actually #76619 has the full discussion (somehow ended up in a bunch of threads) <vagrantc>is there no way to run a service with PATH available? i need id, cat, grep, insmod, rmmod, modprobe, sleep, echo, gpioset, amixer ... <Rutherther>podiki: yeah I saw it few minutes ago. I like it, maybe would like an option to not auto start it (I like to start my display service myself out of my compositor startup script). But probably better to have some kind of generic service finalization rather than exposing it through the services themselves... <podiki>vagrantc: you can specify environment variables to a service with #:environment-variables (or something like that) <vagrantc>think i am done with this for now ... thanks folks for nudging me in some right directions :) <jA_cOp>vagrantc: if you're packaging the program being run, you may want to use wrap-program in a phase to add the necessary PATH entries <podiki>Rutherther: i think that is the key question, of ordering. using hyprwm, there is a variable it sets when it runs, which somethings will depend on to talk to the compositor, but other things you want running first maybe <jA_cOp>that way, those tools are proper dependencies of your package <vagrantc>jA_cOp: yeah, i guess so. i thought guix would pick that up from references ... but i guess not for shell scriots? <podiki>vagrantc: only if there are store paths, that's how guix knows there is a reference after all <Rutherther>podiki: yeah, that's definitely true. I start my services with a custom service called wlr-services that starts multiple services, including wayland display service. It's to replicate sort of a systemd target option. Something that I miss with shepherd a bit. Also I would be happy if the auto-start #f of service X applied to services that require X, but I don't think it does (or at least last time I checked few months ago) <podiki>Rutherther: i recall that from browsing your config :) i think i basically combined what you had with the x11-display home service style for myself. along with manually setting some variables as i got lazy. it is a tricky area <Rutherther>_oh I see that they actually discuss that point about propagating auto-start in the thread for #76619 sent, that's nice_ <attila_lendvai>vagrantc, fork+exec-command has #:environment-variables, you can set PATH from there to sg that contains coreutils, etc <meaty>Is there a way to retrieve binaries built by the substitute servers without having guix installed? <vagrantc>attila_lendvai: might poke at it another time, thanks! <podiki>meaty: sure, just curl or wget if you know what file exactly to get <podiki>but the trick would be to somehow know the path of what you want <attila_lendvai>what do i need inside a container for mDNS (foo.local) lookup work? it works outside, but not inside the container. <futurile>attila_lendvai: one of the template files has this in it which is supposed to do that: (name-service-switch %mdns-host-lookup-nss)) <attila_lendvai>futurile, but that is for OS definitions, right? i'm dealing with a simple guix shell --container <attila_lendvai>BTW, `guix shell --container --emulate-fhs --user=hacker --no-cwd --network ...` is great stuff! good enough to run e.g. esphome in it to compile firmwares and update esp32 devices. <futurile>yeah, mmm no idea why it doesn't find that as you're using the 'hosts' networking stack 
