IRC channel logs
2026-03-09.log
back to list of logs
<graywolf>How would I debug `guix pull: warning: importing module (srfi srfi-26) from the host' warning? The message does not really give much hints where I should look <ieure>I cannot build Guix from Git, it fails on the documentation. <graywolf>ieure: make clean does not seem to remove the doc/guix.de.info file <graywolf>can you try the build after git clean -xffd (warning, will nuke all untracked files)? <ieure>graywolf, Thanks, you're right. Editing the bug to reflect this. <darthlukan>qtbase takes such a long time to build on this machine, only to fail for some non-obvious reason - Usually trying again (sometimes 4 times) gets passed it. <darthlukan>Just venting, there's nothing to be done - I just have a weak system :P <bdunahu>darthlukan: not able to use substitutes for what you're doing? <tomenzgg>I don't know if others have seen the same but substitutes have been incredibly sparse for today and yesterday; weather still reports lacking substitutes for most of what upgrade needs to update for me, right now. <darthlukan>bdunahu: Substitutes are configured, but qtbase derivation is consistently built/rebuilt <darthlukan>tomenzgg: Yeah, I noticed the same. Thi odd thing is that it worked this morning for my `guix system reconfigure` but after 3 attempts is just not happening for my `guix home reconfigure` <darthlukan>My `guix system reconfigure` required 2 attempts because of qtbase <darthlukan>Worst case scenario I just have to attempt it when I get back from GDC at the end of the week - I just wanted to try and have things buttoned up before I left is all :P <bdunahu>I haven't pulled for a few days so haven't noticed anything <ieure>bdunahu, darthlukan, tomenzgg, There was a problem with qtbase tests failing with the unprivileged Guix daemon which I believe negatively impacted substitute availability. But yes, it's been a rough week -- I tried reconfiguring a machine midweek and still haven't gotten it current. <adanska>Would anyone with commit rights be able to merge #6942? It's preventing me and anyone else who uses GNOME from reconfiguring their systems. \ <Guest7>anybody have experience with audio not working with flatpaks? Started using sway today and it completely broke audio on tor browser, whereas before with x11 i could get around it by playing anyhing with audio before starting tor. i ran flatpak run with --verbose -vv and it says pulseaudio cannot be found. I tried adding <Guest7>PULSE_SERVER=unix:/run/user/1000/pulse/native based on pactl info since there wasn't any enivironment variable, but that didn't help. this is all new to me though so i'm probably doing something wrong. any ideas? <czan>Are you using Guix Home? I have (service home-pipewire-service-type (home-pipewire-configuration (enable-pulseaudio? #t))) in my config and things seem to work okay? <sunless>i'm unable to install ice-cat because of qt not building, it either freezes my pc or returns a build error <Guest7>czan i am but, i haven't done much the with the stock config yet. most of my attention has been directed at the system config, so the sound home services didn't even occur to me. i'll try what you said. thank you! <kestrelwx>sunless: There are ready substitutes for `qtbase` and `icecat` on Berlin, can't you use these? <sunless>i've just found out that adding substitutes is harder than i expected (thought it was just adding extra channels), i'll rollback for now and learn about adding substitutes in the weekend <sunless>kestrelwx: thanks for showing what to look for <janneke>test202020: any (simple-service ...) listed in config.scm, you can just remove <janneke>test202020: can you share your config.scm via paste.debian.net, and tell us which service you're trying to remove? <test202020>network-manager-applet by delete in modify-services %desktop-services <test202020>efraim: i do know working that or not, but i think that applet is one dependency in my system required qtbase, but last is try to rebuild again <adanska>efraim, I checked out #6942 and it works on my machine. No-one has taken a look at it yet for merging, so I was wondering if you could have a look at it? No pressure, only asking because you are here :) <test202020>efraim: libnm required qtbase, need to change network connection tool <efraim>adanska: it doesn't affect me directly so I wasn't sure about testing and applying it, but I'll go ahead on your OK :) <adanska>efraim, all okay with me! Thanks a bunch, I appreciate it :) <test202020>i cannot find whats depends by qtbase in my system... <yelninei>corrupt input while restoring from archive. I think this happens when the build gets interupted because of the daily reboot <yelninei>not sure what to do with the x86_64-gnu builds as these first need updated builders which is currently blocked on cross compiling info-reader <test202020>gnome is broken by qtbase, but i cannot switch another de because something else broken by qtbase on system side <czan>Is it at all expected for po4a to run at 100% CPU for ages on a bunch of the .texi files in doc/ in the Guix repo? I've been compiling Guix on my machine for years and can't remember having run into this before. I'm at 5min so far on this run, which seems excessive. <Rutherther>test202020: do guix graph on output of guix system build --derivation --no-grafts config.scm <civodul>ACTION just ran ‘etc/teams.scm sync-codeberg’ <civodul>so you may find yourself adding to new teams :-) <czan>Ah, thank you! cnx has had to go around tagging me on PRs for the past few days, so this will save them some work. :) <andreas-e>cbaines, csantosb: There has been another evaluatiuon failure of hpc-team by the data service; for the time being I have just rebased it on master once more, since master now evaluates. <andreas-e>cbaines: data.guix.gnu.org has not evaluated anything for the last few days, so that we do not build new bordeaux substitutes for master (except for those coming in through the branches). I think this one is hosted at Hetzner, right? Could you restart the service or check whether there is a problem? <cbaines>andreas-e, last time I checked it was stuck trying to compute channel instance derivations <cbaines>because of the way grafts are handled, that involved trying to build python-minimal for riscv64-linux which failed <andreas-e>But it does work on data.qa; what is the difference? non-determinism in python-minimal? <andreas-e>Could we copy over the package from one to the other? <andreas-e>Or just retry, after all the recent changes to master. <cbaines>andreas-e, the data.guix.gnu.org machine is setup with QEMU for riscv64, so it ends up attempting these builds, compared to hydra-guix-130 which I don't think is setup like this <cbaines>I'll restart things with data.guix.gnu.org, which should get it processing recent revisions, which will have the additional benefit of skipping those broken with the builtin:git-download related issue (at least for now) <andreas-e>Hm, indeed QA does not seem to look at riscv. Should we disable riscv as well for data.guix.gnu.org? We have a substitute availability there of about 15%, so it does not really seem worth it to sacrifice all other architectures for this. <andreas-e>cbaines: Thanks, this was my argument; and also we will have a more recent data point. <cbaines>I've disabled architectures in the past when this issue around performing builds for computing derivations causes problems, but it just makes my life more difficult in the long run <cbaines>it just means that when I come to try and update or reconfigure the riscv64-linux build machines, I'll have more problems <andreas-e>We can see whether it works now; but I would say that providing substitutes for the users is a very important goal here, even more so with the cuirass baking problems on berlin. <Rutherther>I think even disabling riscv64-linux for the time being until it's fixed could be fine workaround <Rutherther>cbaines: until the machine is capable of obtaining riscv64-linux builds somehow... I don't know, offloading, substitutes, something <cbaines>without the data service computing the derivations, the builds don't happen <cbaines>but the data service struggles to compute the derivations because of this issue with grafts <andreas-e>Rutherther: This is about data.guix.gnu.org, without the qa. <cbaines>maybe, but that's not something currently setup for either of the data service instances <andreas-e>I think cbaines has just stopped the service. <andreas-e>Should I build guix with guile-3.0.11 now? I am seeing incompatible bytecode versions from /run/current-system/... <Rutherther>cbaines: also, what step exactly needs the riscv64-linux builds? When I do "guix pull" on x86_64 machine, I have builds only for x86_64. Then I can do --system=riscv64-linux with my guix built for x86_64. Does the data service do something differently here? <andreas-e>After updating the system, but not my user profile from which I compile Guix. <cbaines>Rutherther, the data service is effectively trying to compute the derivations involved in doing guix pull on riscv64-linux <cbaines>one reason for this is so these derivations can be built to provide substitutes for guix pull <Rutherther>I get that on one hand, but on the other hand it seems to me this could be handled differently, you could have a separate jobs for the guix pull derivations, not as part of the 'main' evaluation <cbaines>over the last few years, I've been splitting the revision processing the data service does up, mostly to add parallelism <cbaines>and it's actually already in two parts, with the channel instance derivations being added in to the database before everything else <Rutherther>andreas-e: seems that guix has indeed been switched to 3.0.11. But the comment that we cannot switch remained :) I don't know what's the oversight here, if the comment has been left or if the switch shouldn't have happened <cbaines>trying to pull things apart even more though requires handling replacing bits of data when retrying revision processing <Rutherther>andreas-e: but I don't think that you should necessarily build with 3.0.11, the /run/current-system guile files shouldn't be used in the first place when working with user guix. How exactly are you using guix here? In a checkout or the pulled one? <cbaines>having things in big transactions avoids some of that complexity <Rutherther>cbaines: okay, so if channel instance derivations fail for any architecture no builds are scheduled? <cbaines>Rutherther, failures are fine, what's happening here is slowness because the builds are taking ages, then failing <cbaines>so the first part relates to the channel instance derivations <cbaines>the second part is everything else, so package derivations, lint warnings, ... <Rutherther>couldn't it be split to sort of three parts: 1. channel derivation for native arch, 2. all the derivations for all architectures computed from the 1., 3. channel derivations for other architectures, instead? Where the third part could be even more split off from the process, the evaluation showing as finished already after second part has passed <cbaines>that sounds feasible, you have to take clients of the data service in to account though. Like the bffe is looking at the channel instance derivations when the revision processing has finished, so you can't really call it finished if you're going to add data later. <Rutherther>okay, I now see data.guix.gnu.org, I wasn't aware of this page. So substitutes are built from there, not from the evaluations made by data.qa.guix.gnu.org? <cbaines>the bffe submits builds based on data.guix.gnu.org for the master branch <cbaines>and the qa-frontpage submits builds based on data.qa.guix.gnu.org for other branches (and previously patches) <andreas-e>Rutherther: My guile problems appear only when running ./etc/committers.scm, so they are not serious; some files end up being interpreted. <andreas-e>So as I understand this, without bffe submissions, we only have master branch substitutes "by chance", since the QA branches end up being the master branch. <cbaines>yeah, plus QA might end up submitting some builds that should be associated with the master branch with some other branch <Rutherther>so the master branch on data.qa.guix.gnu.org is not used for builds? <cbaines>since it makes the assumption that the builds for the master branch will have already been submitted <cbaines>Rutherther, indeed, data.qa mostly processes the master branch as a point of comparison for the other branches/patches <Rutherther>Huh! interesting, I was always looking on data.qa.guix.gnu.org and treating that as the main source for master builds :) <cbaines>both data service instances get sent the build events by the coordinator, so they both should have build information <civodul>oh, we have substitutes for qtbase and libreoffice now, how neat <andreas-e>qtbase-5 is still missing. qtbase-6 failed its tests in my local build, but apparently has been built and baked by CI now. <andreas-e>No, privileged one. I think, unless the default has been changed. How do I find out? <Rutherther>you can look at who is running the guix-daemon process, ie. in "ps aux | grep guix-daemon" <Rutherther>anyway the default on Guix System is still privileged, so it's going to be that <janneke>yelninei: if "we" were to create a milestone for the hurd, what would it be? i'd like to suggest: minimal support for guix/hurd as a daily driver? <Rutherther>it's just that on unprivileged daemon it fails consistently. Not sure about issues with privileged one <andreas-e>Then are we sure it depends on the privileges and not on something else? <janneke>yelninei: and for that we'd need: guix pull, guix system reconfigure, coping with file-system corruption, x.org and exwm? <janneke>i would like to leave out any hardware requirements; wdyt? <janneke>oh, and arguably, but also arguably just "nice to have" containerized builds <andreas-e>Rutherther: Two other tests, but I do not remember which ones. <andreas-e>cbaines: On the data service, python-minimal failed again on riscv. Time to disable the architecture? <andreas-e>Rutherther: Numbers 81 and 122, or close to them. <andreas-e>Rutherther: 81 - tst_qprocess and 122 - tst_qlatin1stringmatcher <cbaines>I can look at deploying (plus sorting out the uncommitted configuration changes) <Rutherther>andreas-e: then it seems unrelated to the unprivileged daemon failure <andreas-e>In #7002 I remove packages and services that are deprecated since 2020 or 2024; it passes the cuirass bot, which essentially means I have not overlooked references. Is it okay to push it? I am hesitant because of the postgresql-service (not service-type), so if someone still uses it, they may end up with an update hassle from postgresql-10. Maybe even more so since I also remove postgresql-11. But besides <andreas-e>deprecation, I do not see any other way of informing people that finally we remove this for good. <cbaines>andreas-e, maybe say "gnu: Remove postgresql-service procedure." rather than "gnu: Remove postgresql-service." <cbaines>I did a double take until I looked at the diff <cbaines>andreas-e, as for removing the older postgresql versions, I think that's OK, since the configuration has to explicitly set the postgresql version, if users hit this, it'll be reconfiguring rather than when the attempt to restart the service <andreas-e>cbaines: Okay, thanks. Well, technically, I am removing the variable named postgresql-service... In a sense, this echoes my confusion with things being named "service-type" without being a type. <andreas-e>I just realise I forgot to remove the exportation of the deleted variable; strange that this does not break compilation. <civodul>andreas-e: qtbase 5 and 6 available now! <andreas-e>Now I am a bit surprised about the lack of work on the bordeaux build farm; hpc-team was successfully finished about an hour ago, and the second branch in line, kde-team, already last night. Should the jobs not be arriving with the build coordinator? <andreas-e>qa-frontpage shows lots of &port-read-timeout-error. <yelninei>janneke: Sounds doable. guix pull has the issue with the callback getting gced, guix build guix has the issue of running all expensive tests and huge ram needs, emacs-mimimal has failing tests and libfaketime <cbaines>andreas-e, sudo herd status guix-gc tells me guix-gc is running, which will block builds being submitted <andreas-e>cbaines: I always fall into this trap! When things are slow I check for "guix gc" and it is not running, and then I forget checking it when things stop completely. <andreas-e>I have killed it as usual. It has been running for two days, and probably without actually removing much (and we have plenty of space). <csantosb>I see that "With branch changes" is at 0 everywhere <andreas-e>cbaines: Now that guile is at 3.0.11, should we not drop all the guile-next, guile-fibers-next and so on? This could be a step to stabilising our "infrastructure packages" so that they simply depend on releases in regular Guix packages. <andreas-e>Hm, we may have to wait until everything Guile is compiled by 3.0.11. <cbaines>andreas-e, maybe, although this is more about the recency of releases for those projects, plus the benefits of unreleased features and fixes for some things in Guix <cbaines>so we might just end up adding them back again <andreas-e>Well, this is the argument - if we want to mature and stabilise our tools, they should run with older releases and not just the latest git commits of their inputs. <Rutherther>isn't guile-next older than guile at the moment? <andreas-e>Yes, it should be called guile-past. But guile-3.0/pinned is still at version 3.0.9. <janneke>yelninei: i also took a short stab at cherry-picking https://issues.guix.gnu.org/43857 (Supporting chroot builds on GNU/Hurd), as i've been carrying that patch along for a long time on my private `wip-hurd` branch... <janneke>...but i gave up and just opened a new issue for it, only referring to the debbugs issue <janneke>oh no, will hurd also get infested with rust? <csantosb>civodul: In case you have some time to kill, #7010, before we run hpc-team branch <test202020>now i am upgrade to latest master branch/ but xannot to login gnome. logs have JS Error gio.ioerrorenum connection is closed by authpromt.js <gabber>test202020: have you rebooted after the upgrade? <gabber>i'd roll-back to the previous generation <gabber>and then first try your configuration with the new checkout in a vm <gabber>e.g. `guix time-machine -- system vm your/config.scm` <janneke>well, i guess a port of anything to the hurd should be applauded and i should be thankful for... <test202020>hmm, looks like i am comment gnome service while try to solve problems with migration from qtbase dependency... <janneke>it's just that i'd like this fad of rewriting the world in "yet another imperative programming lagnuage that's almost memory safe, except when you really need it, stripping-away copyleft protection" to be over sooner rather than later <gabber>janneke: fighting those wind-mills, aren't we? <gabber>jokes aside, don't you think there's (or could be) a great improvement in software quality when compilers don't just happily produce binaries but force programmers to adequately specify what is supposed to happen in the executable? <janneke>gabber: yeah i guess that for our amazing lisp machine, we won't be rewriting c programs, but rust programs -- big deal <janneke>gabber: we've had completely memory safe languages for some 70y now, and we've also known for just as long that imperative programming should be avoided as much as possible? <janneke>and then theres' the anti-copyleft in the rust community, having "us" do the bidding for big tech? <yelninei>when do we start rewriting things in java? <janneke>well, significant parts of the corporate world have been (or are being) rewritten in microsoft java... <yelninei>hmm the i586-gnu build failed again on ci :( <m4xxed>Heya, anyone else having issues running `guix pull` due to `guile-gcrypt-0.5.0` today, or is it just me? :) <cbaines>m4xxed, what system are you guix pulling on? powerpc64le-linux, aarch64-linux, x86_64-linux, ...? <m4xxed>cbaines building on ` x86_64-linux` <m4xxed>Yesterday evening I was still able to do a `guix pull` without issues, but today it fails, telling me that `guix shell: error: corrupt input while restoring archive from #<closed: file 7f1a944f6e70>` <cbaines>m4xxed, sounds like it's maybe trying to fetch a substitute and failing, can you tell from which server? <m4xxed>cbaines seems like the substitute that is unreachable is `substitutes.nonguix.org` , which doesn't respond when I ping it... but since this is now `nonguix` territory, I guess I'll refrain from asking further :) <cbaines>note that the order of the substitute servers matters, so maybe put this substitutes.nonguix.org one after the default ones, that might avoid the issue in this case <Rutherther>since it doesn't respond at all, it shouldn't be that one <Rutherther>but you better disable it because it adds up delay trying to get it to respond <m4xxed>How can I check the order of the substitutes from the command line? Is there a way? <sneek>graywolf, you have 1 message! <sneek>graywolf, old says: primitive-load indeed does not load any compile file. It only expand and evaluate on the fly <ieure>qtbase substitutes... yesssss <test202020>try to get big debug info for qtbase, but connection is slow and get exception on connection abort. another try start afain from sratch. how to donwload that? <yelninei>does anyone else find the milestones page hard to read? the markdown formatting makes it hard to find where a new one starts <gabber>janneke: (after trying to figure out all of your references) word! <abbe__>Having a trouble with guix (revision: 6861d60b87d03d9cea91234999613f167d8a96dd) with (use-modules (ice-9 custom-ports)) in a gexp: In procedure dlsym: Error resolving "scm_init_custom_ports": "/gnu/store/nbn6j7qbxk2mh22bszvpy2ypgazmj12q-guile-3.0.9/lib/libguile-3.0.so.1: undefined symbol: scm_init_custom_ports" <Kabouik>I have no idea what this boost-0001-unordered-fix-copy-assign.patch is, definitely not something I added explicitly in my config.scm, but the hash is broken: https://0x0.st/PewD.txt <ieure>Kabouik, It's a bug in the boost package. <ieure>Kabouik, Looks like it will compute an origin for some patches, and the code in that origin has changed vs. when the package was created. <Kabouik>I didn't know I had the boost package, but looking at its description, I see it's probably something everyone has on their system anyway. So no system reconfigure until this is fixed right? <ieure>Kabouik, It's a popular library for C++ projects, so likely low in the package graph. And yeah, if it's not building, likely won't be able to do much. <Kabouik>I see no corresponding issue on Codeberg, will report it. I'm surprised to be the first though if it's low in the graph. <Kabouik>I don't understand Rutherther, will that not be the same content for everyone since that patch is online? <Rutherther>anyway likely other people are using substitutes so they do not see this issue <Kabouik>Yeah that's what I was thinking. I had issues with nonguix substitutes last week so I had --no-substitutes, and my system reconfigure did not complete due to file collisions (issue #6938), so I reused the same command today from shell history and was thinking that using --no-substitutes made the bug visible to me. <test202020>no, after append gnome services i cannot to login to gdm <podiki>perhaps the boost patch url sometimes fails/is down/something else? was seeing issues getting that file on manual builds but wasn't consistent <test202020>only gnome xorg can login/ but display Error with logout button <test202020>in log i see /run/982/keyring/control no suck file or directory <Rutherther>I think the only difference between the files is a trailing whitespace <Rutherther>there was a trailing whitespace on line 6. Now it's not there anymore <ieure>test202020, I haven't been able to reconfigure due to missing substitutes. <test202020>i have many bugs with fprintd, but now try to turn off. i do not unstand whats problem <test202020>this cannot connect to pipewire, keyring/control no such file <test202020>gdm-password gio ioerrornum the connection is closed <test202020>why guix gc -d removing non existense in system packages? <ieure>test202020, Are you asking why `guix gc -d' isn't deleting items from the store? <test202020>yes, that save like delete ~70 GB, but i not remembered that i download so much. <ieure>test202020, You have the opposite question, why is it deleting so much from the store. <ieure>test202020, Likely inputs for local builds of things. <test202020>that not fashion quastion. gnome is broken that really problem and i cannot to fix that <ieure>test202020, You should roll back until it's fixed. <test202020>ieure: currently i delete all generations... but that broken two days ago and difficult to find rifgt generarion for restore <test202020>i thibk like generations derivations can conflict with new gnome and remove them <ieure>test202020, You can still go back, `guix pull --list-generations' if you still have those, then switch to a non-broken one. Or find the commit before the one that broke and `guix pull -C the-commit-sha'. Then reconfigure. <test202020>after purge all generation is show only last generation <ieure>You can pull to a previous commit. <test202020>only i have problem with gnome on master branch? <ieure>Pull to the commit before that. <ieure>Look up the gnome-team merge, then `guix pull -C the-master-commit-before-the-merge'. Then reconfigure. <test202020>download old gnome is very slow. i do know how times that broken, maybe early commits <test202020>i think fast way is replace gnome with somethink light <ieure>test202020, Generations can't interfere with each other. You should keep the last working generation when reconfiguring, for exactly your situation. <ieure>If a new generation doesn't work, I roll back until I can figure out what's wrong. <test202020>that broken while i install somethink in user home, i remember somethik like that <lilyp>is codeberg broken atm? why do i get notifications for prs outside my teams? <ieure>lilyp, Seems to work for me. I think contributors get notified for everything. There was IIRC an issue with the team sync code removing those settings (it was removing and readding users, which removed the preference), not sure if that's still the case. <Rutherther>lilyp: at the top line, where you see guix/guix there is Watch / Unwatch button. Depending on the state you're in. Maybe it got changed to watching for you? <Rutherther>ieure: contributors do not have to get notified for everything. That's up to the settings of the watch and subscription in PRs/issues. But it is true that once you become a team member it will automatically switch to watching the repository. It is easily turned off, though <ieure>Rutherther, I'm not watching guix/guix and have a bunch of irrelevant stuff in my notifs. <ieure>It's *mostly* relevant, but there's definitely stuff I don't expect. <Rutherther>ieure: can you show examples? And if you open them, do you see that you're subscribing under "Notifications" for the associated PR/issue? <ieure>(I do not need a solution at this time) <Rutherther>my initial guess would be that at the time the PR has been open you were watching the repository, possibly because of some issues with the addition script, not by your action. And that subscribed you to this PR. But it's just a wild guess based on the fact that I have never gotten a notification on something I did not subscribe to explicitly <Rutherther>although no, I discard that guess on the basis that you're listed as 'participant' there and that's probably why you got subscribed. But why you became participant, I do not know <Rutherther>I am wondering if you get added as a participant when a commit you authored is added to the PR <PotentialUser-0>How do I install `javac` on Guix? I installed `openjdk@25` and I can run `java`, but not `javac`. <ieure>test202020, I just pulled and reconfigured and I'm able to log into a GNOME session, FYI. <lilyp>yup, qtbase is finally substitutable <PotentialUser-0>Where can I get the key that signs the releases? It seems like the one in 3.3 USB Stick and DVD Installation is not the right key. <lilyp>(still wish it was buildable, but ain't gonna waste my cpu) <yelninei>hmm harfbuzz seems to want to link to libstdc++ and there is a test that explicitly checks that taht does not happen <n|phreak_mob>Hello I am trying to get connman to work on guix system , I put in the following (service connman-service-type (connman-configuration (disable-vpn #t))) then I reconfigured config.scm and got this error "guix system: error: aborting reconfiguration because commit 7866294e32f1e758d06fce4e1b1035eca3a7d772 of channel 'guix' is not a descendant of <n|phreak_mob>hint: Use `--allow-downgrades' to force this downgrade." <n|phreak_mob>So I was looking at service-types and how they work , I did add the networking module to use-modules <n|phreak_mob>On my other device I just configured wpa_supplicant and it worked but I would like to use a network manager if I can.