<mange>Well, the error message is accurate - the gcc-toolchain package doesn't have a lib output. However, that blog post never tries to use it, it always uses gcc:lib alongside gcc-toolchain. Are you sure you're copying the commands correctly?
<mange>Ah, you missed the crucial line just before that: "package 'gcc' has been superseded by 'gcc-toolchain'". I think the gcc package has been hidden since that blog post, because people would install the gcc package and expect to be able to compile code. I'm not sure of the solution to this, but give me a few minutes to check the mail archives.
<Guique>mange: Sorry, I tried to fit the error message onto one line...
<mange>liberdade: Is xfce listed in your system's config.scm? If so, you'll have to remove it from there. But doing that won't immediately free up space in your image, you'll also need to run "guix gc".
<gabber>in that service conf you specify which --system= you want to build for
<gabber>not sure how you could compare the actual qemu versions used in the process, though
<gabber>and i am also not sure which qemu a $(guix time-machine --commit=.. -- build foo --system=..) might use (the current system-wide one from the qemu-binfmt service type or the one from the time-machine)
<futurile>Guest55: syncthing has 'version control' doesn't it - I seem to recall a setting where it will store versions of files
<gabber>nckx: bummer - i've tried it with the commit i've posted here, my current generation and the current HEAD but i've never gotten that error? the newer commits seem to fail to build gawk-mesboot...
<gabber>ekaitz: the qemu-binfmt-service-type has a (qemu) field, you could patch your own qemu-package (with (inherit qemu) and the wanted (version) field) and pass it to your system configuration and reconfigure
<gabber>if you extend %desktop-services, then modify them to use your adjusted GDM config, otherwise append them to your services (you should be able to find the relevant passages in the reference manual)
<Kabouik>Just to disambiguate, I asked yesterday about the Flipper Zero. This was indeed a dialout issue, and is now solved. The thing today with Python is another topic: running Python code against a Yoctopuce module plugged as USB.
<jpoiret>mirai: i don't remember off the top of my head but I guess dovecot itself wants to use pam?
<Lumine>I can't see how tampering with resolv.conf would affect a malformed URL for guix pull either, since that's the only network related action I did recently, where I changed some nameservers. gabber
<jpoiret>I don't remember exactly how I arrived at the list of services that need it
<pastor>lilyp: is it not manually reviewed for responses as well?
<lilyp>in that case it should show up after some waiting
<Lumine>Guest43: kind of same with me, it was cumbersome with some stuff, with i3 most of my problems just vanished
<Lumine>Actually I have zero problems as of today, the only thing that is a mystery to me is how can a web browser's DNS queries reset resolv-conf which is managed by Proton to its default nameservers. I'm sure you could fix it with dnscrypt or dnsmasq but I don't know enough about those yet.
<nckx>pastor: I've approved your mails. I don't get the 'responses' comment.
<nckx>2h is really not a delay worth reporting when meatpersons are involved, unless you've successfully delivered mail to the same list before. Oh, and if you haven't subscribed in the meantime, due to a quirk in Mailman moderation.
<nckx>ACTION approves another mail to that list that doesn't reach my threshold for devnulling, but probably should not have been sent.
<nckx>futurile: Nonmembers aren't moderated more strictly. Why do you think you're moderated?
<nckx>If your messages are consistently not being delivered, PM me your address.
<futurile>nckx: OK - my message didn't show up yesterday (but someone replying to it did show up) - it shows now - thank-you. I just assumed it was due to me not being a member.
<futurile>nckx: stg is the 'porcelain' command (so you do 'stg new' to create a new patch), but to create a new branch, to create a new patch - to use it generally - it's expecting to find 'git' in the environment. I just tested this by creating a shell with nothing in it but the command, and for many commands it says `could not execute git`. So it's essentially useless without git in the env.
<futurile>nckx: so as a newbie packager I think that means I should add git as a propagated input?
<nckx>(Anyone not a newbie knows what's coming, since I'm notoriously anti-propagation whenever it can be avoided. ;-)
<nckx>Propagation is the easiest way to make stg find git, but it's not the only one. All that the error message (probably) means is that git wasn't in $PATH. You can create a wrapper using wrap-program that will add <git>/bin to $PATH and then exec stg.