IRC channel logs
2025-05-16.log
back to list of logs
<redacted`>I'm trying to get database dumps to run before my restic backup jobs. Right now I'm just running a different timer 30 minutes before the backup, but I'd like to make backup job runs trigger the dumps and wait for them to finish. <redacted`>I'm considering patching the restic backup service with some pre- and post- hooks in the config <redacted`>Is that the way to do it, or is there some way to cause timers to trigger a one-shot service or something? <apteryx>do we have a means to --rounds=N with system tests? <azval>maybe a silly question but why guix pull always build derivation for x86_64-linux ? <azval>(its on a non Guix distro, simply guix package manager on Alpine Linux) <azval>because thats the part that takes the longest every single time <ruther>civodul: I will open the issue with xs-mesboot timeout, but just so we are on the same page - I think the core-packages-team branch is blocked by it, that's why I sent it there initially <ruther>also I don't understand why my mmessages aren't showing in #75518 while my messages are showing fine in other threads <janneke>ACTION just wonders if --disable-silent-rules should be used/added by default <sneek>mghackerlady, you have 1 message! <sneek>mghackerlady, apteryx says: re gnome updates; there's a gnome-team if you'd like to join and contribute to keeping our GNOME stack fresh. Some packages can already be updated to version 48, but in some cases it'll need some bigger libs updates, such as glib or gtk or the likes. <mghackerlady>Is it possible to change the display manager from gnome to lightdm? I really dont like all the gnome dependancies <mghackerlady>I think I tried once before but the manual wasn't very good <ruther>azval: why is it surprising that it builds x86_64 derivation? Are you not on x86_64 or what is the issue? <ruther>is QA down completely or only the web interface? <look>Hi, is ci.guix stuck? The master specification has been on 46% for a couple days <futurile>not getting anything back from QA though <apteryx>is anyone using the snd-pcsp kernel driver? <polyedre>Hello all, I'm trying to create a Guix virtual machine and run it in OpenStack. I build a qcow2 locally, upload it as a new Openstack Image, then start a Vm from that image. However, the virtual machine does not boot and the console output shows "waiting for partition '<a random uuid>' to apprear..." before opening a rescue REPL. Here is my configuration: https://paste.debian.net/1375056/. I wonder if I'm missing a kernel configuration, <polyedre>or if the partition name is wrong. I was able to list all files in the `/dev/` directory and `/dev/sda` is not there, or any other standard partition that looks like a disk. Could someone point me in a direction I can investigate please? <yelninei>configure: error: C compiler cannot create executables : havent seen that one in a while <ruther>polyedre: it is expected that there is no /dev/sda, qcow will end up as /dev/vdX <ieure>That shouldn't matter if it's looking for a disk by UUID though. <ruther>sure, but I am unsure OP was checking for correct disk files under /dev. Also it's strange something would be lookin for uuid in the first place, there are no uuids in the config <ieure>Well, they said "the console output shows "waiting for partition '<a random uuid>' to appear [sic]..."" <ruther>I know, I am merely pointing why it's strange <ruther>I wouldn't expect that message to appear with that config <ieure>Well, that's only the OS definition, how's the qcow image getting created? You can specify that stuff on the CLI or declaratively. <polyedre>ieure: I created the image with: "guix system image --root=guix-result --image-type=qcow2 image.scm" <ruther>ieure: right, the uuid is made and placed in the configuration in operating-system-for-image, so the root file system device specified doesn't really matter <polyedre>Because the VM boots properly locally, I guess the issues is after. I probably messed up something while uploading the image or when I started the VM. I'll check that, sorry to bother you. I'll update here if I find something <polyedre>I was my fault! I copy-pasted an openstack command to create the image that included specific hardware configuration for the disk bus. After removing those specific options, I worked perfectly. I'm so happyyyyyy <Tadhgmister>what is `/var/guix/profiles/system/parameters` normally supposed to look like? <Tadhgmister>I seem to have ended up with that file (which is stored in the gnu/store) to be empty and it is stopping me from reconfiguring my system <Tadhgmister>oh I see it for my older revision, ok once `guix gc --verify=contents,repair` finishes assuming it doesn't manage to repair the latest system version how can I remove it and reconfigure my system? <ruther>Tadhgmister: switch to generation that is not damaged. Then remove the damaged generation with guix system command. Then guix gc <ruther>guix gc verify is not going to fix it, this file is not substitutable. Still good to run it as other items might be corrupted <Tadhgmister>`guix system roll-back` and `guix system switch-generation 1` are both failing because it wants to read the corrupted boot parameters of the latest system even though that isn't even the one that is booted to <ruther>right, just delete the generation's file - /var/guix/profiles/system-X-link and if your current generation points to it, just remove the /var/guix/profiles/system and make the symlink to a correct generation <ruther>you will end up with an inconsistent state with these steps - specifically the generation will still show up in boot, but as long as you know that, it's fine <Tadhgmister>do I then also do `guix system switch-generation` to update grub config file and possibly other stuff? <ruther>after you do this you should be able to reconfigure and that ought to fix that inconsistent state, or guix system switch generation etc. <civodul>look: i had a look at ci.guix: ‘cuirass remote-server’ had +/- crashed but i’ve restarted it now <civodul>so it should be back to work real soon now