IRC channel logs
2025-06-04.log
back to list of logs
<lispmacs[work]>Hi, I'm trying to use fj.el to interact with codeberg, as indicated in the migration GCD. I am able to view my own repos and issues, but I'm confused as which command allows me to view the guix repo and issues. Can somebody help me out? <apteryx>maybe we should have code that detect such situation and print an error/hint <apteryx>hm, not trivial because gdm can be used with many desktop environments <apteryx>so you'd have to check whether *any* desktop environment was provided, which doesn't make much sense given someone could use something from a channel that guix knows nothing about, but still be usable as a desktop environment <eikcaz>why would a guix system reconfigure need to pull from git.savannah.gnu.org? Shouldn't that already be handled by guix pull? <eikcaz>cobra: not sure about latest, but substitutes are available for guix commit 0e51c6547ffdaf91777f7383da4a52a1a07b7286 (a couple months old) <Guest44>Hello guys. I have two machine guix installed on ubuntu. One machine, m1 where guix pull is done. Can i pull changes from m1 to m2 ?. <eikcaz>Guest44: In theory, you should be able to `guix copy' the profile over (guix pull just makes a profile with only guix and guix-daemon). <eikcaz>However, I'm running into an issue right now where a guix profile already exists, but using it is causing some sort of guix pull to be performed. IDK if that issue will affect your use case. <Tadhgmister>woot! I got my cross compiled guix deployed to my router and running syncthing and transmission! <Tadhgmister>it supports extlinux so I did kind of cheat regarding the bootloader <Tadhgmister> but figuring out all the kernel config flags to support the right firmware and hacing together a way for guix deploy to work on cross compiled code was an interesting challenge <Tadhgmister>I now heed to push my changes to syncthing to allow it to be cross compiled for everyone <Tadhgmister>*submit patch / pull request for changes to guix's syncthing package <Guest23>have different histories, which is the official/newer one <Guest23>saw the blog post, codeberg is the newer one. <adanska>Hi Guix! I'm looking to submit a patch using the new PR workflow, and I was wondering if I could have some guidance as to how thats done. How do I use the 'AGit workflow'? Is there a guide on how to do it for Guix? I've submitted a few patches by email before, but I want to modernise. <lilyp>adanska: my source on the workflow is in the gcd itself; you 'git push <upstream> HEAD:refs/for/<upstream-branch>/<downstream-branch>', where <downstream-branch> need not exist yet <adanska>thanks lilyp, i just submitted it! its really easy, this is nice :) <csantosb>Morning all, I remember there is a good reason why guix's wireshark in a foreign guix setup needs to be launched as root, anyone remembers this ? <csantosb>I'm pretty sure wireshark is not the only one in this case <untrusem>so I see some people use tmpfs as their root file system, I am using btrfs on `/` partition, can it be changed? <futurile>csantosb: as I recall apps like that need to change the ethernet device, only root has the permission to do that <csantosb>futurile: I have both, arch native app (/usr/bin/wireshark), and guix app (~/.guix-profile/bin/wireshark); the former runs as user, the later needs sudo <csantosb>I need to 'sudo usermod -a -G wireshark username' before, sure <futurile>csantosb: is the arch one setuid or something - well limit of my knowledge I'm afraid <Kabouik>How should I proceed to edit Pulseaudio's default.pa in Guix with config.scm? I need to disable suspend-on-idle but can't edit the file directly. <csantosb>I wonder if guix system has the same behaviour <civodul>indeed, thanks for the heads-up jakef <attila_lendvai_>i'd be happy for a hint what package/output i need to fix this: ld: cannot find crtbeginS.o <attila_lendvai_>same with -lgcc, -lgcc_s, and some ld: skipping incompatible /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libc.so when searching for -lc <efraim>no, I mean i'm pretty sure crtbeginS.o sounds like it would come from a libc implementation <efraim>try with just clang-toolchain; take out llvm and glibc <attila_lendvai>i found this, but according the little i understand of this, it shouldn't be gcc specific... /gnu/store/dgc2gvm6mr8kg0q5rw08clpnf1ggkpzw-gcc-15.1.0-lib/lib/gcc/x86_64-unknown-linux-gnu/15.1.0/crtbeginS.o <attila_lendvai>if i try "gcc:lib" for that file, then some automatism guides me to a wall: guix shell: package 'gcc' has been superseded by 'gcc-toolchain'; guix shell: error: package `gcc-toolchain@11.4.0' lacks output `lib' <attila_lendvai>FTR, crtbeginS.o is present in the following package outputs: gcc, libgccjit, gfortran. shouldn't it be in only one place? <untrusem>▏guix pull: error: Git error: SSL error: syscall failure: Resource temporarily unavailable <attila_lendvai>untrusem, that smells like a local problem on your machine. does pulling something else work? <untrusem>I asked because it failed after `receiving objects 100%` <civodul>(i think there were further discussions in that thread) <untrusem>I am trying using `git://` instead of `https://`, if its not successful either, I will just wait <untrusem>guess i will wait, does any else facing error while doing guix pull? <ruther`>untrusem: everyone who is using savannah mirror is facing error on pull <ieure>I don't know if Codeberg supports git:// or not -- if it does, it doesn't advertise it to logged-out users. <untrusem>▏guix pull: error: Git error: SSL error: syscall failure: Resource temporarily unavailable <apteryx> hm, I thought I was connected to the chat and sending updates about rebooting and stuff, but I wasn't, apologies if someone wondered what was going on with berlin. <apteryx>I'll reboot the machine again shortly, if that's OK. If I got my file system flags/option right it shouldn't take long. <apteryx>(sadly this can't be tested in a VM due to the VM code overriding the fs/options and all) <ieure>untrusem, https://git.guix.gnu.org/guix.git is the correct URI for the Guix channel now. It points to Codeberg, but since it can be directed elsewhere, if you use that, it shouldn't require changes from users in the future. <ieure>apteryx, If you get a chance to look in the Cuirass logs for the nss-updates specification, I'd be interested to see what those say. <untrusem>ieure: I will try with this new url later <ieure>untrusem, It's the default now, but you may need to reconfigure in order to pull the commit with the change in the first place. <ieure>untrusem, I would `guix describe -f channels > channels.scm', edit that to point at the new repo and remove the (commit ...) fields, then `guix pull -C channels.scm', then `guix system reconfigure'. <ieure>After that, you should be pointed at the right place, and it should work. <yelninei>hello, i cant seem to skip tests for hidden packages with the --without-tests flag. Is this intended? <civodul>apteryx: thanks for the maintenance work! <apteryx>I hope the new mount option will help a bit! <civodul>yelninei: yes, see ‘package-input-rewriting/spec’ (which is what ‘--without-tests’ uses under the hood) <apteryx>btrfs balance does seem fundamentally slow though, se maybe we'll have to do as Efraim suggested and run it less often, or with more filters (limits). We'll see. So far the system has rebooted with noatime for most subvolumes. I've also cleared a couple @publish test snapshots I had laying around from 2023 <civodul>the problem is that this and ‘guix gc’ are two intensive workloads <civodul>when they run, the machine is basically unresponsive <civodul>then there’s also rsync (debbugs + substitutes) <apteryx>yes, maybe we should try harder not to run 'guix gc' and balance at the same time <apteryx>ideally 'guix gc' should complete first, then 'balance' recover the freed blocks <apteryx>so far balance is running an 'avio' in atop is staying in the us, so that's good <apteryx>but maybe there aren't many tasks that have been picked up yet post reboot <civodul>we should separate out some of the services though <civodul>issues.guix could run on a dedicated Hetzner instance <civodul>likewise for the web site backup (set up for active replication, except the last bit is missing) <apteryx>issues.guix will be retired at some point so I'm not sure it's worth a dedicated instance <civodul>it will probably be retired in a few years at the earliest, though <mra>wasn't it that patches will stop being accepted in december? <mra>maybe civodul means that issues.guix will remain up as an issue tracker, it just won't accept patches? <yelninei>civodul: Thanks, I see, there is an optional #:replace-hidden? option but transform-package-test just uses the default variant. Guess Ill have to disable tests manually <apteryx>I'd rather have issues.guix redirect to codeberg.org/guix/guix/issues after that 6 months, otherwise it's needlessly confusing <apteryx>and we'd still have bugs.gnu.org to see Debbugs issues in a browser <civodul>it’s still early to discuss this :-) <civodul>i think the GCD say “at least two years” <apteryx>I'll try these again later when there's no balance going on <apteryx>1500 MiB/s in random writes is good! <mra>civodul: btw, thinking about substitutability. i agree with the changes that you proposed to #127, but was wondering if you know of an example of a derivation which should be substitutable despite taking non-substitutable inputs <mra>i think that #127 is good to merge in its current form, but this would inform how the initrd stuff gets developed <civodul>apteryx: good to know; thanks for benchmarking it <civodul>mra: at least at work we have free packages that depend on proprietary packages (the latter cannot be substitute but the former can and should) <civodul>but then there are the examples i gave, like monolithic texlive <civodul>and probably things that depend on <computed-file>, which is non-substitutable by default IIRC <mra>civodul: okay, that's good to know. i agree that non-substitutability shouldn't be viral then <civodul>mra: i’m sorry this is not a satisfactory answer wrt. the ZFS situation <mra>civodul: all's good! i want to make sure that any solution is a good one. i'm wondering about maybe just explicitly marking an initrd as non-substitutable if it takes zfs as an additional module <mra>might not be so bad to treat zfs as sort of a special case. it kind of is one <mra>it just comes down to how to make sure that the correct derivations have #:substitutable? #f set <mra>sorry for being such a broken record on this issue :P <civodul>mra: no worries; it would be nice to find a solution, and perhaps a special case as you suggest is the way to go <mra>civodul: to that end, do you know if there's a good notion of equality for packages? like, does something like (if (equal? package zfs) ...) make sense? <mra>the special case stuff is somewhat complicated by the fact that all of this needs to happen above the level of derivations, i think <yelninei>civodul: After skipping some tests in dependencies shepherd@1.0.5 also passes all tests on x86_64-gnu (on core-packages-team) <identity>mra: i think equal? should work on all records, but i think (string=? (package-name package) "zfs") is the better way <identity>my most common word combination is "i think", i think <mra>identity: bless. i'll try tinkering with this tonight <mra>gotta submit my thesis before i can go home lol <mra>big fan of "i think". every time i say "i know" i end up being wrong :) <civodul>identity: ‘equal?’ won’t work on <package> records because they have thunked fields etc. (and they’re also expensive to compare since that involves a graph traversal) <identity>civodul: the more you know, i guess; the expensiveness of equal? was one of the reasons why i suggested string=? instead <lilyp>Kabouik: re pulseaudio, there is pulseaudio-service-type to edit these config files <Kabouik>Thanks lilyp. Found it in the manual, I'll keep a tab open and try that later. <elb>I'm trying to update my local guix packages (guix package manager on a debian foreign system), but guix pull is failing for my user (it worked fine for root). I am getting this error: <elb>guix pull: error: aborting update of channel 'guix' to commit ed5988f0d2cf14e3cc35a32e6ad91d7cbf535e2f, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <elb>it does give me hints on how to resolve this, but ... how did I get into this state <ruther>elb: you're currently trying to pull from savannah, right? <elb>I assume so, it has not told me that it updated to codeberg <ruther>elb: updated? wdym? What is the output of guix pull? <ruther>elb: like what url does guix pull say it uses? <elb>the blog post said that at some point it would tell me it was updating <ruther>elb: currently codeberg and savannah are diverging, savannah having 'invalid' commits. They won't even build if you tried pulling from it. <elb>" But don’t worry: guix pull will tell you if/when you need to update your config files and the old URL will remain a mirror for at least a year anyway." <elb>I guess it actually says it will tell me when I need to update myself <elb>that line I just quoted is from the post <ruther>elb: whether codeberg will be used automatically depends on how your channels.scm looks like. But as I am saying, just look at the output, don't assume... <elb>ok, let me clarify; I am aware that there is a migration, I read the documentation, I was under the impression from the words in the documentation that I didn't need to change anything yet <elb>my current config is using git.guix.gnu.org, which is savannah <ruther>elb: so guix pull says that it is pulling from git.guix.gnu.org? <ruther>elb: okay. git.guix.gnu.org is codeberg, not savannah <elb>interesting; I didn't change that <ruther>elb: you didn't, git.guix.gnu.org has been changed <ruther>elb: what is your current guix commit you're on - guix describe? <elb>ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <elb>it looks like it actuallly did update (?) <elb>this generation says it's Jun 04 <elb>but when I ran guix pull it failed with the above error <elb>.... my update scripts may have more than one pull in them, I update a variety of things, maybe an earlier pull succeeded, or maybe it built a new profile from whatever ws there before <ruther>ad8cb is commit on savannah. I was under the impression it doesn't build, so I am not sure how you could update to it <ruther>elb: since the commit is wrong one, you will want to switch to newest codeberg commit forcingly <elb>ok looks like my root guix is also on that rev <elb>and I absolutely only updated that using exactly the command `sudo -i guix pull` <Tadhgmister>if I wanted to get interned files ( `guix download local_file` or `(local-file ...)` ) to use --rellink so it reduces disk space where would I even look <Tadhgmister>is like a hard link but editing one doesn't touch the other <Tadhgmister>I have figured out I can get the file into the store and then override the original with a reflink to the copy in the store but that feels inelegant and fragile <Tadhgmister>I can't even tell if that is handled by guile code or the underlying nix daemon C code <elb>OK, I just reproduced this problem on a machine that was running 0b754ce updated on April 4, by simply running `guix pull` <elb>on this machine the repo URL remains git.savannah.gnu.org, though; on the other machine I was able to get myself out of it with `guix pull --allow-downgrades`, but on this one I guess I'll have to figure out how to update my channels if I've never configured or edited a channels.scm <elb>ahh no, `guix pull` uses git.guix.gnu.org now, I can just do the same --allow-downgrades <elb>I suspect I'm not the only user that will run into this <elb>OK, no, it did not use git.guix.gnu.org, it used savannah <ieure>elb, I wrote this earlier today: I would `guix describe -f channels > channels.scm', edit that to point at the new repo and remove the (commit ...) fields, then `guix pull -C channels.scm', then `guix system reconfigure'. <elb>ieure: thanks! with --allow-downgrades, that does it <ieure>elb, There were some extra commits pushed to Savannah somehow... you probably ended up pulling those, which is why you had to allow downgrades. <elb>I've now update my org notes with this magic ;-) <civodul>do we have here one of the “collaborators” who fails to push to Codeberg guix/guix? <civodul>i’m trying to debug it and it would help if we could interact live <jjba23>hi all, I was wondering if someone could maybe review a <jjba23> tiny PR where I add a new Guile library, for building <jjba23>I also need someone to explain to me how to properly use .dir-locals.el when working on guix <civodul>vagrantc: can you try: ssh git@codeberg.org ? <vagrantc>PTY allocation request failed on channel 0 <vagrantc>Hi there, vagrantc! You've successfully authenticated with ... <identity>jjba23: emacs should prompt you to confirm you want to use the directory local variables, and, well, you should confirm that you do <vagrantc>civodul: that seems more-or-less expected ... <civodul>vagrantc: so right login and right key? <civodul>could it be that you have several Codeberg accounts and/or several configured SSH keys? <vagrantc>civodul: it is also the "vagrantc" account, which is the one associated with guix <vagrantc>(even if i did secretly have another somewhere) <jjba23>yah thanks identity ! my problem is also i think i don't know how one marks for example the dir "/home/joe/fork/guix" as trusted. <vagrantc>civodul: also, for the record, i did successfully push to guix on May 26th, the day after hte migration <vagrantc>i *definitely* did not set up any accounts between then and now :) <identity>jjba23: the `safe-local-variable-directories' variable <civodul>vagrantc: then i’m clueless; my theory about team permissions doesn’t hold because some of the other “collaborators” are also members of read-only teams <vagrantc>civodul: are these "collaborators" also "owners" ? <civodul>no, “collaborators” are per-repository whereas “owners” are org-wide <jjba23>ah! i see makes all sense now , thanks identity <vagrantc>civodul: i still have no idea where the "collaborators" comes from ... i have seen the term nowhere in my codeberg interface <vagrantc>all i can see are "Member role" ... set to either "Owner" or "Member" <vagrantc>and i see a "teams" view, of which I can only see the one team I am a part of <vagrantc>civodul: i am also blocked from making pull requests through the web interface <vagrantc>although AGit is very nice, that seems like something is amiss :) <civodul>vagrantc: oh, blocked for pull requests? <vagrantc>civodul: yeah, i can only submit pull requests via AGit <vagrantc>civodul: well, the "New pull request" button is dimmed and unclickable <vagrantc>it's only been 9 people who've signed commits since my last successful push, too <vagrantc>many of them in large batches, e.g. R and python updates <civodul>as i wrote on guix-devel, avp, ekaitz, ieure, hako are in a situation similar to yours <civodul>they are “collaborators” but not “owners” <civodul>well maybe i should just open an issue with the Codeberg team <ajarara->hi #guix, I think that the install ISO is broken because of an expired cert? I get 'crlfile: None' (amongst other things) on guix pull, so I can't get an updated definition of nss-certs (which is what the section on X.509 Certificates says). This is both the guided, graphical installation and doing things manually. <ajarara->A workaround I'm thinking of is to guix copy nss-certs from another machine running guix <vagrantc>ajarara-: is the the 1.4.0 ISO, or the development ISO ? <ajarara->ooh, 1.3 on an old stick I never reflashed. Didn't expect it to have been updated <vagrantc>yeah, there were some certificate timb bombs a while back ... cannot remember when exactly <ajarara->hm grub entry does say 1.4.0. Reflashing anyway, will try 1.4.0 off of guix.gnu.org/download. I don't see a 'latest' there or in the ftp listing. Is latest in CI? <vagrantc>yeah, the latest is basically built from CI <vagrantc>not sure how often it is built, but should be a fairly recent git commit <ajarara->kk will try that next if this 1.4.0 doesn't work. <ajarara>yep a fresh flash of 1.4.0 fails to pull because 'crlfile: None', even after an install of nss-certs + SSL_CERT_{DIR,FILE} exports. Trying latest, but before I do gonna try on another computer. <ajarara>strange thing is substitute downloading works fine, I can download git from a substitute for example even though the URL listed is https <ajarara>yeah it's computer specific (a x1 carbon gen 6 works, a desktop ryzen build does not). <ajarara>it was the time in the bios, it was set to Jan 1st 2025. Working now :)