IRC channel logs
2025-06-25.log
back to list of logs
<kkremitzki>Does this channel have the bot that re-sends messages with mentions to offline users when they re-join? <dajole>When creating vms using `guix system vm config.scm`, is there a way to mark the packages required as 'used', so that they don't get garbage collected? <jlicht>sneek: later tell janneke: something silly seems to have happened with icu4c-73 in icu4c.scm on core-updates-team (it's actually icu4c at version 71) <kkremitzki>sneek: later tell vagrantc: Thanks for maintaining Guix in Debian and good luck backporting the security patches :) <dtx>So anybody else getting an error with a "guix pull": guix pull: error: aborting update of channel 'guix' to commit ee8be372972bc1e84b5870df738c6e0bbdd975ff, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <meaty>trying to do the security upgrade but nothing is built }:'( <dajole>dtx: I'm running into exactly the same error. I'm still trying to figure out what caused it, though. <wdwdfwfwf64>Hi everyone. One of my friend were updating (guix pulling) from 102,161 commits before the current commit, and she encountered guix pull: error: signature verification failed for commit e6d6bc40961a32eb5bd71ca36007931d76232804, what could be the solution to her problems? <untrusem>wdwdfwfwf64: have they changed the repo url <wdwdfwfwf64>untrusem: thanks, I will try finding solutions there first <inline>guix pull hangs and i get a derivation couldn't be built error <ruther`>dajole: dtx: there has been a mistake few weeks ago that a maintainer pushed commit to savannah after the migration to codeberg. So if you still used savannah at that time, you end up with that commit. The resolution now is to just allow downgrades <apteryx>How can I configure a PDF printer in GNOME? <janneke>so, everyone is [attempting to[ build a new guix package themselves this morning? <sneek>janneke, you have 1 message! <sneek>janneke, jlicht says: something silly seems to have happened with icu4c-73 in icu4c.scm on core-updates-team (it's actually icu4c at version 71) <csantosb>Hi Guix ! When using agit flow and codeberg, pushing with "-o topic=TOPIC" creates a pr, great. <csantosb>What happens in 6 months if I contribute another upgrade to the same package, and I still use "-o topic=TOPIC" ? I replace the previous ? <janneke>jlicht: yeah, i guess rebasing on 303c729836a47ca4516b174010a615d02d65a45b gnu: Make icu4c 73.1 the default. broke that <jlicht>janneke: wasn't meant to call you ouor single you out, but rather to ask you if you knew what happened there <Deltafire>"building /gnu/store/p3rpp5zrnmpa9v5a79rjl166hpvwbwdx-icecat-128.12.0-gnu1.tar.xz.drv" - that'll take days on this machine :/ <Deltafire>is there a way to skip derivations that require the packages to be compiled? <Deltafire>"Occasionally you’re grumpy because substitutes are lacking and you end up building packages by yourself." - haha, too right <z572`````>janneke: Now the default version of icu4c on master is 73. Maybe we need to modify the default version of icu4c on core-packages-team. <janneke>z572`````: right, that makes some sense -- assuming everything still works when we do that <jlicht>using gitnex on my phone, I may have fat-fingered and broken a milestone to merge core-packages into master. apologies if so, I'll be back on a PC 2 hours to look into this <z572`````>I have selected some fixes that do not affect many packages in the core-packages-team and placed them on the master branch <futurile>apoorv569: the project they reference gocix is worth checking out - I don't know the status of the service merge <janneke>my offload build silently failed, attempting a local build now <apoorv569>z572`````: for the service? I don't have any idea how docker or podman works, i wouldn't be or any help. <untrusem>something going on with substitute server <untrusem>we can use guix inferiors in this case but that a workaround <z572`````>apoorv569: You can ask the author under this patch <PotentialUser-57>Hello. I was wondering what are these empty files with names like 'stats.totals.2rqpn5sm' on my /tmp. <jlicht>z572`````: thanks for fixing the mess <janneke>ACTION still trying to upgrade...now building iceccat-minimal... <janneke>as great as having home-services integrated in your system config is...it can make reconfiguring terribly more expensive <janneke>my system config is alsmost empty...but then home config has browser[s]... <janneke>ACTION wonders how civodul manages this or thinks about it <viaken>I suspect getting the security patch integrated a ~week in advance of the announcement could ameliorate the substitute pains here. I dunno if that was possible in this case, but maybe for the future? <viaken>Maybe! What makes it a bad idea? <viaken>Someone reverse engineering to exploit it? <identity>viaken: fixing security issues without communicating the need for an update is a bad idea <viaken>You still communicate the need, just once all the substitutes are built and ready for the mass upgrade. <identity>in my books ~week of silence is not timely communication <viaken>It wouldn't have to be silence. This round, we had 4 days' warning. If the patch had been ready when the first announcement was made, people could upgrade over those 4 days before the public disclosure. <viaken>Rather than, "Here's the patch. Update now. Also, here's all the details for the black hats to work with." <identity>viaken: the patch is all the details the so-called 'black hats' need to work with <reepca>the rebase workflow means that we don't know what commit the updated guix package will be built from. We'd have to either freeze commits out for as long as it took to get substitutes available, then push the fixes, or else use a merge commit with the commit used for the guix package off in another branch. <pfd>are the listed dependecies for the pinebook pro raw image necessary for using the image within another O/S, or for builing the image? <qbit>trying to boot on the starfive vision2, dd'd the image to a µsd card but it doesn't seem to boot (nothing on the uart) <pfd>qbit: I too just woke up to the fact that 'raw' images are virtual images for qemu, virtualbox, etc. I guess that's why both vision five 2 and pinebook pro are still raw and in development. <qbit>explains why there was no u-boot or other boot kinda stuff on the image after dd'ing <qbit>wonder if i can dd another OS on.. and then just rm the root and put these files in.. <untrusem>This was not a good experience building everything <untrusem>ACTION checkn if thinkpad t480 has taken any damage or not <ieure>Oh, huh. I pulled/reconfigured my stuff last night, I didn't have to build much. <untrusem>for me it was qemu and icecat, I made a silly thing and stop qemu build halfway to try out guix inferior, so yeah <untrusem>btw, I am trying to run windows on vm, guix runs the vm fine but virt-manager does not, /me wonders why <kkremitzki>qbit: I have booted the raw image on my vision five 2. Did you just receive it? I seem to recall some firmware update is needed out of the box before I could boot Debian <pelzflorian>qbit: Months ago I successfully used the visionfive 2 image, too. The first µsd cards were faulty, though. <qbit>nice, just by dd'ing the image onto the card? <qbit>sweet, i am attempting other images now .. and the same thing happens.. so i might have bad.. sd cards.. or .. bad board <pelzflorian>qbit: Or the board's boot mode is not configured as in the Quick Start Guide for visionfive 2. <qbit>I have tried all the combos for the dip switches, none produce anything on uart <qbit>(i know only some will without sd card) <qbit>ah, there we go - my uart cable was bad :D <bavier>qbit: I got one of the DeepComputing riscv laptops a while back; having difficulty figuring out how to update the "official" os <inline>can't i use bare ext2 with guix ? <bavier>I'm glad the vision five has Guix images <inline>not sure if disabling has_journal is a good option <qbit>bavier: nice, I have a milkv pioneer i wanna try and get things running on (.. time pending :P) <qbit>Failed to load '/gnu/store/6809nyvcysrl2mrjkbnw6z0gllqiaydh-linux-libre-6.14.9/lib/dtbs/starfive/starfive_visionfive2.dtb' <qbit>nice, updated the fw payload and it boots \o/ <bavier>anyone familiar with authentication can tell me if I need to do anything on Guix's end after resetting the expiration date on my GPG signing key? <podiki>shouldn't need to do anything, the key fingerprint is the same if you just renew <podiki>(i do this every year, about due too) <vagrantc>the commit signatures are not expiration-tied <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, kkremitzki says: Thanks for maintaining Guix in Debian and good luck backporting the security patches :) <vagrantc>kkremitzki: gonna need more than luck on this one... <bavier>podiki, vagrantc: great, thanks! <vagrantc>i mean, "guix git authenticate" essentially ignores expiry ... git log --show-signature will complain that they are expired or invalid or whatever <bavier>right, so `git log` would need fresh keys <kkremitzki>Suppose I have 2 machines with fresh Guix 1.4.0, e.g. via `sudo apt install guix`. The first `guix pull` is super long, but in principle, if I do it on one machine, I should have what I need on the second machine to skip this... is there an easy way to transfer that over, e.g. some payload I can just `scp`? <ruther>kkremitzki: that's good question. definitely! You can copy ~/.cache/guix <inline>this is totally not ok man, when i choose whole disk for cryptsetup, there's no swap partition created <ruther>specifically ~/.cache/guix/authentication and ~/.cache/guix/checkouts, I wouldn't copy the other folders, they can point to the store <kkremitzki>inline: A partial workaround is to use a swapfile on the root partition until that's improved <inline>and when i use a swap partition which is outside of the encrypted root partition ? will it get used ? <ruther>inline: sure if you configure that it will get used <inline>cause i chose the graphical install method, i don't have a way to issue a swapon beforehand <kkremitzki>I don't think that's advisable though since it could leak contents of the encrypted partition though right? <inline>yes, but what would leak exactly ? <ruther>inline: what do you mean that you don't have a way to issues a swapon beforehand? You can just switch tty and do swapon if you need to do that <pastor>Hello, what do you guys think of adding a new feature to `guix pull' so we can do `guix pull -f manifest.scm --weather=90', and it will only pull the latest commits of channels whose substitutes for the packages the channel provides, reach at least 90% for the packages needed for building `manifest.scm'/`operating-system.scm', etc. <ruther>inline: anything can leak there in principle, it's not possible to say exactly <kkremitzki>pastor: Seems like an interesting idea, one thing the recent "more frequent releases" discussion had me thinking of was the idea of a "more stable channel" form of release where you for example never want to build anything that could be provided by a substitute server <kkremitzki>So for example with pinning to a yearly, monthly, weekly, you'd have "almost never", "quite unlikely", "possibly" <pastor>kkremitzki: that would be great for users. I'm not sure if we have enough computing power to provide that though. <kkremitzki>Yep, in this case my thinking comes from being in the Debian world, so for example if we have a whole bunch of usesrs on a particular release, we could patch the substitutes list with e.g. a `substitutes.guix.debian.net`, to offload the associated burden with that type of approach <pastor>kkremitzki: do you mean providing binaries from Debian? <kkremitzki>Something like that, but also sort of a downstream/offshoot "Guix (System) LTS" project... they're not fully formed ideas <kkremitzki>Again taking inspiration from the relationship between Debian and Debian LTS (which enables the support company Freexian and Debian developers to get paid for sustaining the distro) <pastor>kkremitzki: I think doing that cannot work with Guix. Debian binaries won't be linked against the correct libraries <kkremitzki>I don't mean through apt, but rather a Debian project/community effort <pastor>But why would they do that for us? <kkremitzki>I.e. a Debian project-ran substitutes server tuned specifically for the fact that it's having a ton of people pull from 1.4.0 and needs to support that somehow <kkremitzki>Well they is potentially I in this case, I'm a Debian developer, the idea interests me and might too for others <pastor>kkremitzki: it would be great if colaboration was possible! <kkremitzki>Agreed, I think for the general idea of "Guix on a foreign distro", Debian is a kind of paragon case, and a good proving ground <kkremitzki>And I just personally find it super useful so hey <viaken>pastor: --weather=90 isn't enough. I have 155 packages in my system profile. If 90% of it is available, but that 10% includes qemu, icecat, and the kernel,, it's bought me little. <viaken>Do the substitute servers keep metadata about build time? That's what's really needed. "Only pick commits that will require less than 10% total compile time." <viaken>It wouldn't be a perfect measure, but it'd be much closer than a package count. <inline>well i can crypetsetup luksFormat the partition and then mkfs.swap on it right and then swapon on it and create the entries in config.scm right ? <inline>which i have to then put a managed devices entry too i think <apoorv569>does shepherd-system-log-service-type support sending logs over tcp or udp to some server, like graylog? <identity>apoorv569: (info "(shepherd) System Log Service") might be of interest <inline>no file system check procedure for /dev/mapper/cryptsetupswap but that's all <AidenIsik>Does anyone here know how to specify git as a build-time dependency in a package? <ieure>AidenIsik, (native-inputs (list git)) or (native-inputs `(,git)) <ekaitz>AidenIsik: try to read about the differences between ' (quote) and ` (quasiquote) so you are not in doubt ever again <AidenIsik>Thanks, I thought the site I was reading just messed with the quote formatting