IRC channel logs
2024-09-13.log
back to list of logs
<meaty>w/e ill just package it for guix-gaming for now <nckx>No, shitty wannabe DRM in the engine doesn't change whether the assets are functional data. <bdju>I have an issue upgrading my system packages related to swaylock, but not sure if it's a normal swaylock issue or related to the workaround I had from last time someone broke swaylock. <bdju>>../source/meson.build:39:11: ERROR: C shared or static library 'crypt' not found <bdju>someone from here had helped me with said workaround so if that no longer works I'm not really sure what to put instead. hopefully it's just a normal swaylock build failure <bdju>can packages be skipped when doing a system reconfigure..? I suspect not since it's more of a declarative thing <bdju>I can report to bug-guix if someone can confirm it's a normal swaylock issue and not related to my setup <bdju>maybe I'll just report it anyway and someone can close it later if it's invalid <bdju>if I got myself blocked from lists.gnu.org from refreshing too many times how long does that last <bdju>that seems to be what happened anyway <apteryx>nckx: I thought we didn't; looking back, I even acked some related commit: b8af6694b9bbea96e8b0d1c9aea64b7f8e690812 <apteryx>what do you people use to author your CV/resume? <apteryx>I have an old LaTeX-based one... I'm not that found of it; especially translating it in other languages is a copy paste job <apteryx>I guess I could have fancy classes to abstract the structure away... I'm not there :-) <aswjrisp>apteryx: There are many things you could write a resume in plain text, html and css, texinfo, mdoc, ... <aswjrisp>apteryx: I did some looking at btrfs after you mentioned it recently. I like the snapshots feature. So I decided to install guix on a computer with a btrfs filesystem in a luks partition. <aswjrisp>The layout is a luks partition with a btrfs filesystem in it. The btrfs filesystem has three subvolumes root, home and swap. The sway subvolume has a swapfile in it. <aswjrisp>I am able to succesfully complete `guix system init /mnt/etc/config.scm /mnt`, but when I reboot I get errors "no such device: <UUID>" and "unknow filesystem". Then it enters grub rescue mode. <aswjrisp>Interestingly it is using the UUID for the btrfs filesystem inside of luks partition instead of the luks partition /dev/sda2. The btrfs UUID is also not in my system config. <aswjrisp>For the error no such device it mentions the UUID of 3b69857a-6b71-4846-b967-4ebcf2676f0e <aswjrisp>What I expect it to do at the beginning of the bootup process is to prompt me for the password for the luks partition. But instead it is going into grub rescue. <aswjrisp>I think I am very close to having this sytem booting and working. I am just not sure what is preventing it from finding the luks partition and prompting for the password. Any suggestions on what I should try or look into? <apteryx>aswjrisp: is this on your local machine? <apteryx>you need the mapped-devices for LUKS also, using their correct UUID <apteryx>and then the btrfs file system records should use the Btrfs UUID (not the sub-uuid) <apteryx>blkid should show you the correct information <apteryx>does GRUB prompt for the LUKS password? <aswjrisp>apteryx: Yes it is a local machine. Thanks for the tip, <aswjrisp>GRUB does not prompt for the LUKS password. <apteryx>your config looks OK from a quick look <apteryx>so GRUB doesn't find a bootable device? <apteryx>is this a UEFI machine, or good old BIOS one? <apteryx>another gotcha -- if you are using guix from the 1.4.0 installer to init the machine, it won't be able to read LUKS v2 <apteryx>so what I do if you want that is 'guix pull' from the installer environment to get the latest one <apteryx>(or you could change LUKS to the older v1 to avoid this issue for now -- I think a simple command is able to do that though I forgot the details) <user2>I'm running into issue #73081. Figured I could just apply the patch to my local git tree and use "./pre-inst-env guix system image ..." to build a working installler image, but that hasn't worked. Still seem to be getting the old, broken installer. Am I missing a step? <aswjrisp>apteryx: It is BIOS grub. I am using the 1.4.0 installer to init the machine. <apteryx>did you specify the LUKS version when encrypting the partition? <aswjrisp>I will try a pull and system init, after I fix the UUIDs based on your suggestions. <apteryx>you need to specify it to use v1; otherwise it will use v2 by default. If you want to use v2 you'll have to 'guix pull' before running 'guix system init' <apteryx>'it will use v2 by default' -> I'm talking about cryptsetup <aswjrisp>No I did not specify the LUKS version when encryting the partition. I used the command from the manual. <aswjrisp>I used luks2 based on the command from the manual. `cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sda2` <aswjrisp>I think it might just be that I did not do a pull before I did the system init. <apteryx>another thing; how large is your storage disk? <apteryx>probably not this problem you're hitting since GRUB should at least prompt to decrypt your LUKS partition, but BIOS can only find things addressed before the 2TiB mark, IIRC <apteryx>on an old BIOS machine with a 2.5 TiB array I had to keep /boot on a separate partition to avoid boot issues <apteryx>should we have a metapackage for the default tex package used by org tex latex exports? <apteryx>I'm hunting them down; not super fun <apteryx>especially if everyone has to do that on their own <meaty>has anyone tried to package mopidy yet? <meaty>I'm trying right now but I don't know enough about python build systems to figure out how to tell it to stop trying to build the documentation <aswjrisp>Yes I saw something about the 2TiB recently when I was reading the gentoo wiki. <aswjrisp>36,978 new commits when pulling from the 1.4.0 install image. <mirai>meaty: what's the problem with building the doc? <mirai>I think if you can get it to work the better <meaty>mirai: it's like 80-100MB more store space, and I can't get it to compile :P I get that build error where it tries to gunzip a ...profile.drv, which I don't understand <meaty>no, but all the extra packages to build it is <mirai>you can always split the output <mirai>ah, there's no problem with that <meaty>that's what I'm trying to figure out how to do <mirai>feel free to balloon the build deps <apteryx>aswjrisp: great! I hope simply 'guix pull' to get the newer GRUB 2.12 will be enough to get your machine to boot <meaty>wait nevermind im an idiot who forgot build logs could be not-compressed <meaty>but it's not any more comprehensible <apteryx>ACTION tested 'git format-patches -o patches -2' && 'mumi new' && 'mumi send-email patches/*'; it worked! <meaty>is it a good idea to install a dependency manager as a dependency to a package? <meaty>AwesomeAdam54321: nevermind I'm giving up on mopidy for now lol <aswjrisp>meaty: looks llike mopidy is music streaming. Have you tried `mpv <stream-url>`? mpv is already packaged for guix. <meaty>aswjrisp: more importantly mopidy can be an aggregate interface between Spotify, soundcloud, beetz, etc. presented as an MPD server <aswjrisp>When I try to pull while using the install image I have repeatedly got a substitute died unexpectedly error. <aswjrisp>guix system: error: 'gnu/store/hash-guix-command substitute' died unexpectedly <aswjrisp>My mistake that error message was when I ran a system init. <aswjrisp>Okay so I was able to do a pull and system init after many attempts with errors. <aswjrisp>When I turn the computer on it still goes straight to grub rescue without prompting for a password to decrypt the luks partition that houses the root filesystem. <mirai>meaty: what are you looking for in mopidy that can't be satisfied with mpd? <mirai>right now guix has mpd ready to use <meaty>mirai: mpd can't interface spotify or other streaming services right? I don't have the storage space right now (or a spare compy to use as a media server) to keep my music library "in-house" so to speak <apteryx>so your partition table is plain DOS, and you've left 2 MiB at the start of the disk for GRUB to install itself in the MBR and then some? <apteryx>there is currently some reliability issue with 'guix pull'; one is now handled but not yet released <Gooberpatrol66>why are shepherd services divided into service-type and service extensions <Rutherther>Gooberpatrol66 because there are not only shepherd services, and this makes it more generic <bdju>meaty: you could mount remote storage with sshfs and then point any local music player to that directory as if it were locally stored. if you don't need advanced library/sorting features you can also just use mpv to play stuff <sepeth>Hi Guix, happy Friday! Just an apprecitation message, I am loving Guix and its community, thanks for all the effort that you put into them ^-^ <mange>Can you boot from a previous generation? <rovanion>Afraid not. This is a newly rescued Guix System. Before the rescue/reinstall the machine was bootcycling. <mange>Mmm. I'd be interested to know what that /gnu/store/40p2k... file is, to try to guess where it might be trying to symlink it. Unfortunately I don't have any good advice. I'm assuming ,q doesn't continue to boot? (I don't think it ever has for me, but the message says ",q to continue".) <rovanion>I'll take a look if I can see the contents of 40p2k... from a live environment. <rovanion>The file ends in acl and seems to contain scheme code. <Rutherther>rovanion: you can try booting into live iso an clearing up most of /etc - what do you have in there currently? <Rutherther>(it's just a guess based on it failing in /etc service) <rovanion>A total of 72 files/folders. I guess I could empty it except for config.scm and then do a rebuild. <rovanion>The amount of giggles that must have been had when the programmer named the service cow-store must have been wonderful. herd start cow-store <mihec>Hi I've been struggling with initial guix system setup for quiet a while now. I installed it with graphical installer with XFCE but now I can't get system reconfigure to finish. It says there is a build error with fonts-dir <mihec2>miha@miha-t480 ~$ cat /var/log/guix/drvs/p2/a4vi7vq3n23ic4mmvvfnqsyzkhibln-fonts-dir.drv <nckx>apteryx: Hmkay. My experience was with the latest bcachefs-tools package (now available for review!), where I first tried without labels and it failed. Mayhaps I held it wrong. <Rutherther>don't delete or change anything in the store yourself, that only leaves bigger possibility for errors. Try try "guix gc --verify="contents"" and if it finds something wrong, then "sudo guix gc --verify="contents,repair"" <Rutherther>or maybe since the path is known here this is too excessive <Rutherther>try just "sudo guix build --repair /gnu/store/p1f2s96izldcyibmh4n1w45na4r21kci-libfontenc-1.1.4" <mihec2>another thing...why do I see gnome-shell in output when I installed XFCE, does that get pulled in by GDM? <Rutherther>in output of guix gc verify? everything is there, so if you first pulled gnome-shell and then went to xfce, it would stay there <Rutherther>if there is lots of errors in hashes that is very strange. Did you do someting with the store yourself? or left some files there before guix system init? <mihec2>I'm not sure why is that, I'm also suspicious of disk since this is new refurbished laptop <Rutherther>yeah, these are not on the substitute I think. But it might be okay, try rerunning the reconfigure <Rutherther>for sure better to get rid of those completely so they are not used accidentally, but it's not very pressing if the reconfigure succeeds now <Rutherther>(to remove them you can use guix gc command with the path to them, but you might have to also remove bunch of other stuff that could refer to them) <mihec>reconfigure now fail because of gnome-control-center...should i just guix gc delete it? <Rutherther>it probably won't work if it's required, but yeah, try guix gc'ng the stuff. Try also guix gc --referrers to see what refers to it, and first gc that <Rutherther>yes, it should for sure try to build it, just without incorrect build path <mihec2>its 1 byte long: -rw-r--r-- 1 root root 20 sep 13 11:21 dx3xhx1rhsramyfl62xi6ahkd29drp-gnome-control-center-44.4.drv.gz <Rutherther>okay did you try gc'ng that? but if the verify didn't find that it seems like it occured only after you tried the repairing, so I would really be afraid of bad disk <Rutherther>I've looked into how nix-index works. It's a tool for obtaining what files are available in nix derivation outputs. I found out Nix cache server actually has information about files in built derivations - see https://cache.nixos.org/hs3yxdq9knimwdm51gvbs4dvncz46f9d.ls as an example for the hello package. I suppose guix cache doesn't have something like that? at least not on the similar path (the hash of output .ls) <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, ArneBab says: so you mean *others* should apply for a 6 hour maintenance grant to better distribute responisibilities? <civodul>‘guix publish’ doesn’t produce such files <civodul>it could, but i’m not sure it would scale <civodul>the plan for ‘guix locate’ is to allow it to download a pre-baked database <civodul>does ‘nix-index’ really browse those ‘.ls‘ files? <Rutherther>yes, it does. It looks at all packages available through nix-env, specifically they out paths. Then iterates over all theirs .ls files in the cache. Also iterates through their .narinfos to see dependencies (since those may not be exposed in nix-env as they do not have an attribute) <Rutherther>"nix-serve" also doesn't produce such file. It's hydra that produces it, the normal nix-serve that people can use to expose their store is not outputting them, I just checked. Are the guix ci's just running "guix publish"? <civodul>Rutherther: it must be terribly slow to browse all these .ls files, no? <Rutherther>yes, it takes maybe even few hours to build the database, that's why someone made a project that just builds it once per week and exposes it publicly <civodul>ci.guix.gnu.org is running ‘guix publish’ (that’s often the case), but bordeaux.guix is running nar-herder <Rutherther>where should the database be made for guix locate to use? <civodul>well, ci.guix and bordeaux.guix could build one and produce one <civodul>currently ‘guix locate’ has two methods, and both consist in browsing the store <civodul>it could have a 3rd method to browse a set of nar files locally, since not everything is in the store on those machines <Rutherther>hmm, but it seems quite excessive to generate it for all files on those machines, since there will be many duplicities of all versions of packages <civodul>‘guix locate --method=store’ generates it for current packages <Rutherther>current meaning the ones that are available from within current channel source? <Rutherther>alright, that's good then. What's pending for this? Can I do something? <civodul>Rutherther: sure :-) the plan was to download the pre-baked database, so you could look into that if you want? <civodul>it should be signed, which complicates things a bit <civodul>actually looks like i had discovered those ‘.ls’ files back then <Rutherther>thanks for the pointers, I will try to look into it, but no guarantees, especially if signing is involved I will probably have to learn some new stuff even before I can start thinking of the exact implementation <yelninei>civodul: Do we know where the libgc warnings are coming from? guile itself? <apteryx>lilyp: I can't seem to be able to create an agenda and define events in it in the GNOME Agenda <apteryx>I'm not connecting any online account, just trying to create an offline one <lilyp>it depends on evolution-data-server – perhaps we ought to export that from the service? <aswjrisp>apteryx: yes the partition table is DOS and the first partition /dev/sda1 is 1GiB with a xfs filesystem on it. The /dev/sda1 is marked as bootable. <apteryx>Guix only supports /boot on the root partition <apteryx>unless you manually copy stuff and update /boot/grub/grub.cfg <apteryx>so your bootable partition should be the Guix root one <Rutherther>I have a separate boot partition, specifically it's esp, guix copies grub/grub.cfg just fine <apteryx>lilyp: export from what service? you mean propagated 'evolution-data-server' as part of the gnome metapackage? <aswjrisp>Yes my guix root is /dev/sda2 which is a luks2 partition with a btrfs filesystem. <apteryx>Rutherther: you are right it works for that use case, but it's not copying kernel files for example like on traditional boot partitions used on other systems, IIRC <apteryx>Rutherther: aswjrisp is using a BIOS machine and is having problems with GRUB not finding the boot device if I got it right <Rutherther>okay, if by "/boot" you meant that the kernel and initrd are located in /gnu/store, then yeah, it's the case, but it's still possible to have /gnu on a separate, unencrypted partition, since it isn't supposed to contain secrets. I am going to try to implement behavior of copying them, but for now I've just went through the source code and started thinking about possible implementation routes. <aswjrisp>Rutherther: I am getting stuck with a grub rescue as soon as I boot this new system. I am able to run a pull and system init from the install image. <apteryx>Rutherther: yes I've meant to do that as well, but it's not so easy it seems <lilyp>apteryx: as one of its sub-meta packages, yes (particularly utilities) <aswjrisp>The system is configured for bios instead of uefi. <aswjrisp>apteryx: Are you suggesting that I repartition the drive so that there is only one luks partition. Eliminating the first partition of 1GiB that has a xfs filesystem and a boot flag. <Rutherther>at least if bios is not able to unencrypt anything, and I thought that was the case <aswjrisp>I went with bios instead of uefi based on the suggestion in the guix manual. There was no /sys/firmware/efi. <Rutherther>if you are on a hardware that supports uefi, but there was no /sys/firmware/efi it just means you booted into the bios variant instead of uefi one <aswjrisp>Rutherther: if directory /sys/firmware/efi exists do efi otherwise do bios, in the disk partitioning section. <aswjrisp>On this system that directory did not exist so I went with bios based grub. <Rutherther>that's unfortunate note. If on a uefi compatible hardware you usually should prefer uefi, not legacy bios. If you are on uefi compatible hardware it can still happen you use legacy boot acidentally when booting into live iso. <Rutherther>and when you do that, that directory won't exist <Rutherther>~... not that legacy bios or uefi would be related to you not being able to boot, that's a separate issue) <aswjrisp>Rutherther: In the bios it has an option to support bios and uefi so I guess I should have ignored that note and gone with uefi. <aswjrisp>I get errors "no such device: <UUID>" and "unknow filesystem". Then it enters grub rescue mode. <aswjrisp>The UUID is for the btrfs filesystem inside the /dev/sda2 luks2 partition. <aswjrisp>I do not get a prompt to enter a password to open the luks partition. <Rutherther>can you also send your grub.cfg? it should be in /boot/grub/grub.cfg <aswjrisp>Okay, it will be whatever the insall image used. Let me get it. <Rutherther>what do you mean with "whatever the install image used"? <aswjrisp>What I should have said was that I have made no changes to the grub.cfg file. <Rutherther>it's generated automatically when building guix system, it's different for each generation <aswjrisp>Rutherther: the grub.cfg is termbin.com/gq89 <Rutherther>so is the uuid it cannot find that d88f7... or is it 3b698...? <aswjrisp>For the error no such device it mentions the UUID of 3b69857a-6b71-4846-b967-4ebcf2676f0e <Rutherther>that is not even mentioned in the grub.cfg, so I am quite confused it would search for it <aswjrisp>The 3b69... UUID is for the btrfs file system in the luks partition. <Rutherther>yes, but it's referred to only by its partition label, not by uuid <aswjrisp>I will reboot they system to comfirm the UUID in the grub error. <Rutherther>you can also try manually executing cryptomount to mount the luks filesystem, and then "insmod normal", "normal" and see if then you can boot or not <apteryx>aswjrisp: I've had GRUB look for an unknown (not part of grub.cfg) UUID before; this was caused by reinstalling GRUB from outside of a chroot; I think it must get baked in the MBR or something. <aswjrisp>Rutherther: Unknow command 'cryptomount'. <olndrxyz>aswjrisp: Did you add the UUID that you get with `# cryptsetup luksUUID /dev/<root-part>`? <Rutherther>but this really shows that nothing from that grub.cfg is getting executed. Which makes sense since it's on an encrypted partition, but I thought the first part of it should somehow get copied to somewhere where grub will be able to read it <Rutherther>olndrxyz: the uuid that grub mentions is not used anywhere in their config nor in grub.cfg <aswjrisp>Rutherther: `insmod luks` results in "error: unknow filesystem." <aswjrisp>olndrxyz: I am checking the output for luksUUID. <Rutherther>aswjrisp: okay that seems even the modules did not copy. Are you sure you bootloader has been installed for the variant of config you sent? <aswjrisp>olndrxyz: the output of `cryptsetup luksUUID /dev/sda2` is d88f7 which is the UUID I use in my config as a mapped device. <aswjrisp>Rutherther: after setting up the partitions, btrfs filesystem and config I ran the two commands from the guix manual. `herd start cow-store` and `guix system init /mnt/etc/config.scm /mnt`. <aswjrisp>Both of those commands ran without error output. <aswjrisp>Then the manual says to reboot and that is where I run into those two error messages and grub rescue. <aswjrisp>I typoed the cow-store command above but I am pretty sure that I just copied it with gpm mouse daemon. I am very happy that the pgm mouse daemon is available in the install image. I would not want to manually copy those UUIDs. <aswjrisp>I think I will retry doing all four steps: pull, system init, start cow-store and system init. Maybe I made a mistake typing one of them, although I do not think I did. <aswjrisp>in order: pull, start cow-store, system init. <aswjrisp>Rutherther: where should I check for the bootloader? <Rutherther>aswjrisp: I don't understand, could you rephrase? <aswjrisp>Rutherther: e you sure you bootloader has been installed for the variant of config you sent? <aswjrisp>Rutherther: you asked "are you sure you bootloader has been installed for the variant of config you sent?". How should I check? <Rutherther>aswjrisp: ah. Yeah. It's written to the beginning on MBR, but if you've not edited the config I would not worry about it. I have not used mbr for a long time, so I don't really know how to properly extract its contents <aswjrisp>Rutherther: Do you think I should start from scratch and go with a uefi setup as it looks like the bios has support for it? <aswjrisp>I wonder if it is a bios setting that is interfering. Not expecting to use legacy bios. <Rutherther>aswjrisp: I think uefi will be easier since there the grub image is on the esp partition instead of being copied to beginning of mbr without the full config. <aswjrisp>I think I will start from scratch with uefi after I check the bios settings. <Rutherther>aswjrisp: my suspicion is that the image generated for grub contains wrong partition uuid, probably because the root partition contains the /boot/grub files along with configuration and also the modules. It first has to get that partition. I don't think it would be related to a bios setting. I am trying to get over the code but unfortunately I am not very successful with understanding what is going on <aswjrisp>It is not the bios settings as it is currently set for try legacy boot first. Which I am going to switch to try uefi boot first, as I am going to start from scratch and do a uefi setup. <aswjrisp>apteryx: olndrxyz: Rutherther: thanks for the help. <PotentialUser-62>Hello everyone! I'm just starting out with Guix, and planning on using it to create development environments. <PotentialUser-62>As I understand it, to do so one would add a manifest.scm and a channels.scm to the project folder to declare the dependencies and to pin the git revision of the channel so that the dev environment works in the future. However I'm a little concerned that nowhere in the manifest file do I declare which package version my project, or dev environment <PotentialUser-62>for that matter, requires. Coming from a JS background, I'm inclined to think of manifest.scm files as sort of like package.json files, where I declare using semver the dependencies my project needs, and whether I'm willing to automatically receive updates to libraries. So for example declaring that I need ("some-lib": "^1.2.3") would mean that I <PotentialUser-62>want some-lib 1.2.3 at the time I write the package.json but that every time I run `npm update`, I want to get the latest minor revision, e.g. "1.2.10". In guix the way I would get specific versions of packages seems to be using inferiors, but there seems to be no mechanism like the one used in npm to declare the specific package version I want. <PotentialUser-62>Instead I need to find the git commit which has the version I want, create an inferior, and specify that the package should come from there. This seems unweildly for projects with many dependencies. Is there something I'm missing? Maybe I'm wrong in trying to fit guix into this model, and the way guix does things may even be superior. What I'm <PotentialUser-62>worried about is that when I write a project, I want the dev environment to always work into the future (subject of course to the original sources or substitutes being still available). What do you think about a syntax for declaring package versions in a manifest.scm directly? <olndrxyz>Does anyone running Sway get "recovering journal" during boot after reconfiguring the system and restarting? I'm experiencing this weird issue that I already reported a few days ago, with Gnome it does not happen. <Rutherther>PotentialUser-62: it's not about a syntax for that. The problem is that different versions require different dependencies. Maintaining many versions is quite hard, so that's why it's better to just continue rolling everything in Guix. You can of course always just stay on a specific commit as you mentioned already, or inherit from the packages and change the minor version yourself if you need an update. If it's a minor version, it should be enough to... <fireking04>Hi guys, just wanted to ask, I created a package variation of qemu to enable pipewire. Is there a way guix way of doing things I can use to let ~libvirt-service-type~ use my ~qemu~ variation easily? I cannot find it in ~libvirt-configuration~ anywhere :/ Or do I have to modify both the libvirt service and package myself? Thanks! <PotentialUser-62>Rutherther: Maybe the way npm avoids the maintenance burden is by shifting the responsibility of ensuring packages work well with each other to users. If a new version is released for a package, the author just pushes that to npm and anyone who runs `npm update` is responsible to get their project to a working state. <Rutherther>fireking04: libvirt-configuration takes qemu package <fireking04>Rutherther: Thanks, I did not see that under ~libvirt-configuration~ in docs. It worked <PotentialUser-62>Also a different, but related question, how do I make sure that if in, say a month later, I recreate the dev environment using the manifest and channel files, that the pulled packages are identical to the ones I previously tested. I understand that I could verify the signatures of the commit, but there's an element of trust there that could be <PotentialUser-62>avoided by some sort of mechanism where I specify the hashes of the packages I originally tested against. <cricri>hi! I ruined my guix daemon installation :( I decided to mount a bigger partition to /gnu because /gnu/store got full. Then I reinstalled the guix daemon. However, now guix pull fails with: "error: reading file `/gnu/store/psv1j490rzfxv6r55qk3ap7rnajgrgmy-guile-3.0.7.drv': No such file or directory'. How can I reinitialize the guix daemon? Thank you! <Rutherther>cricri: so did your store end up empty or did you somehow try to copy the files? <cricri>nope, I didnt backup the store. It is in the data heaven now. <Rutherther>okay, then you've removed everything your profiles used. So I suppose you are not on Guix System? <Rutherther>since none of it exists, you should probably remove all the profiles (symlinks to store) as well. As for the daemon... how did you install guix and the daemon? <Rutherther>~/.guix-home, ~/.guix-profile, stuff under~/.config/guix, and also /var/guix. Basically completely reset the state, and start over <Rutherther>the store is not supposed to be touched, so you can encounter errorful states when you just delete the store and not the accompanying files with it <cricri>I installed guix via the 'services.guix.enable' switch. First I stopped all guix related services. Then I removed the switch in the nixos config, rebuilt nixos and switched to the new config. Then I reorganized the partition. Then I enabled the guix switch and rebuilt again and switched to the new nixos. <cricri>ok, thanks a lot! I think, I am getting there. <tschilp>Hi guix! I anyone having success using the builtin gnome screen-recorder? Since my last pull to b46256b162e15420bb034a9e6d65ec46f1c03343, I finally see the 'camera button' when pressing the 'print'-key. Once I click the red record button, things just disappear and no recording is done. I tried both on xorg and wayland, with the same result. Any ideas how to debug this? On the terminal I only have 'gnome-screenshot' available -- this <dariqq>tschilp: Do you have pipewire enabled (e.g. via the home service)? <dariqq>just also add (service home-dbus-service-type) to your home environment <tschilp>dariqq: thanks a lot, this works indeed :) <rmnull>Hi, I was going through guix home services and came across "home-dbus-service-type", there's already a dbus running for my user that is provided by my host OS, where will it make sense for me to use this dbus service instead <Rutherther>rmnull: some guix home services require shepherd dbus service that's provided by home-dbus-service-type, unfortunately for you. If you wanted to use them you could expose a dummy shepherd dbus service, but you still need to make sure shepherd picks up the correct DBUS_SESSION_BUS_ADDRESS env var <rmnull>Rutherther thanks, that makes sense