IRC channel logs
2026-03-08.log
back to list of logs
<ekaitz>gabber: linux-module-build-system you can take a look to tuxedo-keyboard (gnu/packages/linux.scm) <ekaitz>gabber: np, you have many more examples in that file <gabber>i will when i get this interface working (: <gabber>n|phreak: this module does not seem to exist (in my recent checkout) <gabber>maybe it has moved or you misspelled? <gabber>what services are you trying to use? <gabber>search them using `guix home search FOO`, then adjust that use-module[s] part on top of your config where this error message comes from <gabber>n|phreak: don't hesitate to ask if you have further questions <apteryx>and the package is rather overwhelming <zyd>Does Guix have an official policy on LLM contributed/assisted/generated code? If not, has there been any discussion on adopting a policy, especially anything public that can be linked to? <zyd>untrusem: thanks (for both) but how do you know my site lol <untrusem>zyd: I have seen you in fedi quite a lot actually, i follow #emacs hashtag <ampinga>hello , I tried to reconfigure my guix system yesterday and unfortunately it conduct me to grub rescue mode after reboot with this error: " File /boot/grub/x86_64-efi/normal.mod don't found". I checked the content of the directory and it seems majority of the files (including normal.mod) changed to something like that: normal.mod~. does anyone know how to repair it quickly(not renaming each files <zyd>untrusem: Nah, just have various mututals from there. my fediverse history is emacs.ch, followed by a brief stint at tenforward.social. been self hosting with gotosocial ever since <untrusem>ampinga: ohh sad to hear that, I have faced this before <untrusem>zyd: ohh yess I know you from emacs.ch days, was sad to see its gone, it should have been archived <untrusem>ampinga: I will try to look up logs about how i fixed that <untrusem>ampinga: what's the content of /etc/acl file? <untrusem>ampinga: you could boot into another live distro and chroot in the guix one and reconfigure again to fix this issue i guess <ampinga>untrusem: okay thank you I will try the live distro option <ampinga>untrusem: do you know the reason it happenned concretely? <untrusem>ampinga: whats the content under /etc/guix ? <ampinga>untrusem: acl, signing-key.pub, signing-key.sec <untrusem>hanker: I can review it later, not on my machine <untrusem>ampinga: ok do the steps about chrooting from the manual <ampinga>untrusem: thank you, I will do it. unfortunately, I can't repair it now. <test202020>replace package with my version on system level with my channel <andreas-e>Just give it a different name and use it instead. <test202020>i am trying replace libcamera with my definition <andreas-e>The dependencies are fully described in each package recipe. <andreas-e>I see, so you do not want to only replace one package (say, emacs by my-emacs), but define a different version of libcamera and use it also for all packages that depend on libcamera? <andreas-e>That is more difficult; it requires to rewrite all packages. It can be done programmatically (replace input libcamera by my-libcamera), but I do not see a simple way. <identity>i am on 7d6e9ee, when i try to ‹guix build emacs-next-pgtk› it tries to build pia48ph…-emacs-next-pgtk-31.0.50-2.509228f locally, even though a substitute is seemingly available <https://ci.guix.gnu.org/build/19121251/details>. ‹guix weather emacs-next-pgtk› shows 50% substitute availability, whatever that means. what am i missing? <identity>what is, the one guix build is trying to build locally? i do not think so, it looks like a full build to me, compiling emacs-lisp/macroexp.elc and other stuff <Rutherther>identity: 'whatever that means'. It means that one of the two outputs is available for substitution. While with guix build, you're requesting both. So it needs to build it <identity>ah, so emacs-next-pgtk:doc is available but not emacs-next-pgtk:out? <Rutherther>gives 404 with text we're baking it. Meaning it's in the store, but there is not yet a narinfo / archive for it <efraim>sneek: later tell ekaitz gcc-cross-boot0/gcc-boot0 is where I've been failing too <efraim>ugh still having build issues on my visionfive2 running ubuntu 24.04 <Rutherther>efraim: hmm, with 1.5.0 installation, not with an old one? <Rutherther>there have been two reports recently about apparmor issues <efraim>[259411.832207] audit: type=1400 audit(1772961515.298:130): apparmor="DENIED" operation="exec" class="file" profile="guix-daemon//guix-builder" name="/tmp/guix-build-openssl-3.0.8.drv-0/openssl-3.0.8/config" pid=9544 comm="guile" requested_mask="x" denied_mask="x" fsuid=999 ouid=999 <Rutherther>the fix is to change the policy to allow execution under /tmp <Rutherther>it's already in the pr, so you can just copy it to the policy and test it out <efraim>do you remember how to apply an apparmor profile? <Rutherther>the profile has to be in /etc/apparmor.d, you modify it there. Then it's apparmor_parser --warn=all -r /etc/apparmor.d/guix-daemon <efraim>oh, I drop it in /etc/apparmor.d/ <efraim>If I make it past the 'configure phase then I know its working <efraim>ok, looks good. I'll comment and apply it soon <efraim>sneek: later tell ekaitz although right now I'm also failing on liststdc++-boot0@7.5.0 for riscv64 <sneek>ekaitz, you have 2 messages! <sneek>ekaitz, efraim says: gcc-cross-boot0/gcc-boot0 is where I've been failing too <sneek>ekaitz, efraim says: although right now I'm also failing on liststdc++-boot0@7.5.0 for riscv64 <ekaitz>efraim: but are the errors reproducible? <ekaitz>i had the cross error first and then gcc-muslboot <ekaitz>idk if it was me that I misread or what <efraim>libstdc++-boot0 is an input for gcc-cross-boot0 <efraim>I think that's where I was getting stuck before. I'm going to look through my git stash and see what I've tried before <csantosb>Hi ekaitz ! When you'll get some free time, I'm interested on your opinion about github.com/riscv-collab/riscv-gnu-toolchain; worth wasting my time with it or not ? <ekaitz>i tried removing your patches that take my changes and using my GCC release instead <ekaitz>that triggers other kind of errors <ekaitz>csantosb: what do you mean by wasting time or not? <ekaitz>csantosb: if you want to build things for riscv I think we have that kind of tooling here in guix <csantosb>Given your background of Guix on riscv, I suspect we already have it somehow <czan>test202020: I doubt we'll be able to help with just that information. <ekaitz>csantosb: look at the end of gnu/packages/cross-base.scm <ekaitz>you can create cross-toolchains using that <ekaitz>you can choose a libc and everything <test202020>czan: i define my fixed package library for gta in my channel, but guix upgrade handle package definition from <czan>test202020: I don't really understand what you mean. Can you put your code in a paste (see channel description), with the commands you're running to get that error? <ekaitz>csantosb: be aware that cross compilation has been problematic in guix before. There are special cases that don't work very well. I have had issues with aarch64 in the past. <csantosb>I see; let me play with it to see how it goes <lilyp>hi folks, is there a way to force a substitution? <civodul>yelninei: hi! yeah, i noticed it with info-reader@7.3, which prevented me from redeploying the build machines (due to childhurds) <Rutherther>lilyp: --max-jobs=0 forces no local builds. Though it still builds origins for some reason. But on packages it aborts when there are no substitutes <civodul>ACTION checked ‘guix build -P1 guile@3.0.11’ on ‘guile-team’, looks ready to merge <efraim>always confusing when 0 means 0 and not unlimited <janneke>otoh, in-band signalling is always less than great <lilyp>okay, max-jobs is not working <lilyp>I know for a fact that /gnu/store/2g8sv7wnmrpbk0a2wk2vkr90l7v33zhw-qtbase-6.9.2.drv is on ci, but it still won't download it <Rutherther>lilyp: oh you mean it like that. Yes. So what exactly are you building? The debug output is not on CI. So if you're downloading both outputs, it will have to build instead. <Rutherther>lilyp: since glibc is grafted, the qtbase debug output is necessary for any package that depends on qtbase <lilyp>then we should put the debug output on CI?!? <Rutherther>because my email to guix-sysadmin didn't really spun much attention <Rutherther>but I do not expect it to be fixed soon. It's probably going to be tough to even identify what's going on that the publish takes so long <Rutherther>it's almost 40 hours since it built qtbase and it's still not there <yelninei>civodul: Ive removed the info reader to be able to reconfigure my machine. Not sure what goes wrong, looks like something with gnulib <lilyp>I can push a hotfix for the broken qtbase build on unprivileged daemons, but it's gonna annoy a lot of people <Rutherther>lilyp: maybe it could be pushed on a branch that ci will build first and only then to master? <yarl>lilyp: I don't understand what you want exactly. <Rutherther>oh you already did that if I understood correctly. So then it would be just about waiting for it to appear. It should appear at one point. Not sure how long it will take though <yarl>I just followed the same form as "~A: download failed". <yarl>I say "parse" because I'm parsing the downloaded xml file. <Rutherther>lilyp: note that this situation is currently on master as well, the debug output is not available. So you aren't going to annoy anyone since it doesn't change the situation. Maybe you will prolong the situation, though (but that's pretty much invisible to users) <yarl>I don't see what you want to be explicit. <yarl>No, I don't think the user want that information. If there's a failure here, that's because the xml is not in right form. Either because there's a bug out there (elpa) or because the form is new so that's a bug "in there". <yarl>Do we understand each other? <lilyp>Rutherer: I will annoy those with a privileged daemon and the resources to build qtbase <Rutherther>lilyp: I understand what you mean, but they have to build it now as well. Unless they did it already and in that case, yeah, they will have to do it agein <lilyp>yeah, but they'll have to build it plus dependents again <Rutherther>hm, are the dependents not substitutable as well for your branch? <test202020>i try to upgrade pipewire without qtbase, but not can to replace libcamera by graft( <lilyp>is the failing test by any case "tst_qstandardpaths"? <test202020>i try to make my definiton in my channel and use guix upgrade --with-graft=libcamera=libcamera -L ~/src/my-channel pipewire but that always try to rebuid qtbase. <lilyp>scroll up in your terminal, it should still tell you the file <lilyp>run `zless /var/log/guix/drvs/2g/8sv7wnmrpbk0a2wk2vkr90l7v33zhw-qtbase-6.9.2.drv.gz` <test202020>this log overrited by my try with guix upgrade where i cancel build <lilyp>do you have a local guix checkout? <lilyp>then pull from gnome-team and try to build qtbase there <lilyp>if you have a weak machine, use -c1, as it will build from source <test202020>wait, i do not need qtbase itself. i can try to cut qtbase from system by replace libcamera package <test202020>some days ago i replace pulseaudio with pipewire and qtbase placed in my system <lilyp>as I said before, qtbase is *deep* <lilyp>you absolutely want a building qtbase <test202020>for what? i currently rebuild libcamera without qtbase and that success. <test202020>i try to replace libcamera with qtbase input for my libcamera without qtbase input <Rutherther>test202020: 1. do you realize that grafts are applied after the build, meaning that if you replace libcamera with graft, you still have to build the original packages?. That will never work, you need to actually change the package, not graft it, ie. with-input, 2. do you realize with-graft=libcamera=libcamera replaces the same package with the same package? <Rutherther>if you want to use specifications for this, that those --with transformations use, you will have to rename your package <test202020>Rutherther: you can present example how to make that? <test202020>but for what? my define-public? i try to use with (replacement libcamera/fixed) <Rutherther>1. as I said, grafts are not going to help you, 2. yes, for the 'fixed' libcamera package that you want to refer to, ie. --with-inputs=libcamera=my-libcamera <civodul>yelninei, janneke: i see gnumach has a .forgejo subdir; do you know if there’s Forgejo instance somewhere for Hurd stuff? <test202020>Rutherther: i can try --with-input but pipewire again try to use original libcamera <ekaitz>efraim: do you know if my commencement.scm still works? <Rutherther>test202020: so what are you using if not --with-input? <janneke>civodul: it seems like damo22 added it, maybe ask them in #hurd? <test202020>Rutherther: i mean right now with --with-input=libcamera=my-libcamera that not replaced. while my libcamera building withiut qtbase, pipewire still used guix channel libcamera and try to rebulld qtbase... <efraim>ekaitz: I haven't tested it recently <Rutherther>test202020: and if you do guix build pipewire --with-input=libcamera=my-camera, does that work? <test202020>Rutherther: hmm, looks like that. wait for finish build of pipewire <Rutherther>test202020: I am not really sure how guix upgrade handles transformations, maybe it doesn't handle them for already installed packages, so you might need to reinstall pipewire <Rutherther>or there is a different package using qtbase other than pipewire as well <test202020>Rutherther: local build for pipewire is complete succes. but how to provide that for upgrade? <civodul>yelninei: re #6966, i uploaded the tarballs so we should be able to bring a “proper fix” now <test202020>Rutherther: manual install is solve problem, thanks! wireplumber too. <Rutherther>looking into the source upgrade ignores the transform options. Whether that's a bug or a feature, I can't say <jbnote>Rutherther: thanks for the information about qtbase narinfo yesterday. The build failure on my machine is on some test (and it looks like i'm not the only one). I've tried to lower the core count to no avail. The bisect with guix time-machine gives me the following commit as culprit: d18d6e07e5af73092c75a81cf3e89ac010ba545e. I'm double-checking this currently, because the commit seems completely unrelated. <Rutherther>jbnote: there is currently an issue with the qtbase build on unprivileged daemon <jakef>i wonder if it would be possible/good to add man-db to every shell <jbnote>Rutherther: the fix just disables the problematic check... it's a problem if nonpriviledged daemon does not yield the same results as the priviledged one, isn't it? Or are such things expected? <test202020>Rutherther: pipewire cannot just provide self for all dependencies without mass rebuild? <Rutherther>test202020: no, when you change something, all dependents are rebuilt as well. This is solvable by grafts, but with grafts you need to build the original packages first and then graft them. So you would have to build qtbase. <Rutherther>this is how functional package managers work. Since it's unknown if the result would be the same with the change, the packages are rebuilt completely <Rutherther>yes, you would have to use the original libcamera first that will trigger qtbase build <Rutherther>grafts are effective only after everything is built first <test202020>i see in my logs about piprwire grafts dependencies <lilyp>Rutherther: did you already build the fix? Because I pushed it without confirmation atm to give CI a head-start <test202020>Rutherther: guix graph --path --with-graft=pipewire=pipewire dino qtbase, i see expected output, but install try rebuild dino and others. <lilyp>I'm at ~50% of the build atm <lilyp>CI has built it for i686 already (lol) <Aurora_v_kosmose>Eww. Guile DBI has no support for prepared statements. Sure got to love SQLi <janneke>it doesn't seem to have the concept of CC_FOR_BUILD, and yet it builds c tools to use during build... <janneke>yelninei: thanks for opening that issue! <janneke>wow, it seems we even don't have all sources to build texinfo from source... <janneke>(ie, from git instead of from tarball) <efraim>`guix import cpan XSTexinfo::Parsetexi` failed, more likely it's in there somewhere <janneke>efraim: yeah, tried that too; it's indeed bundled with texinfo <janneke>it possibly fails because another library is missing... <yelninei>phase `build' succeeded after 25591.5 seconds <yelninei>thats the regular gcc-14, it used to take ~4h, maybe i should stop give my childhurds a break <janneke>ACTION hopes to have texinfo move from tarball->git and cross build to the hurd some time soon... <efraim>I will point out it's worse on powerpc-linux, but it's not really a competition <yelninei>well i have 3 more to build, gccgo-15 and my wip gdc-11 and gdc-14 <efraim>does gccgo-15 still just provide go-1.18 ? <yelninei>yes i think so, but the regular go does not support the hurd yet <efraim>the patch I wrote to build with gccgo if go isn't supported assumed that gccgo would keep up <efraim>plus I don't think i ever got the log right that both (%current-system) and (%current-target-system) needed to be supported by go, and only 1 is set at a time <adanska>upon trying to reconfigure my system, i get this message: https://paste.debian.net/hidden/77833632 complaining that guix/build/json.scm cannot be found. I see that a week ago a commit was made that got rid of this, but i dont see any references to this module that should be causing problems. <adanska>would anyone be able to point me in the right direction to fix this? <adanska>wow that was quick!! thanks efraim :) <efraim>I was deciding if I should take a look at that today or see if someone else would take it :) <untrusem>hello I have a query related to rust packaging <efraim>yep, for about the next half hour <yelninei>efraim: cross compiling with go-build-system does not work currently: "cannot install cross-compiled binaries when GOBIN is set", but yes both the system and target need to be supported. For cross compiling i assume id would need to be a cross-gccgo? <untrusem>so I am making a hidden package in rust-sources.scm and importing the module in rust-crates.scm but it still can't find the package <efraim>yelninei: go is supposed to work without needing any cross go package, so it might need some changes similar to the ones that syncthing got to make that cross compile <efraim>untrusem: for building it with -e or once it's imported? make sure to prefix it with package: <janneke>wow, [cross-]building texinfo from git is really broken.. <efraim>I'd next try removing gnu/packages/rust*go and then running make to see if it spits out any errors <efraim>just registered, watching the into video now <yelninei>efraim: I tested a simple hello world go package when I fixed gccgo for Hurd recently (i added a patch to gcc, updated to gccgo-15 by default to not having to add another patch for x86_64-gnu) , ofc more complex packages might be a problem. I think all other targets should already be supported by the regular go? <efraim>untrusem: ah, it's in your channel, not in upstream <untrusem>I changed things according to that though <efraim>yelninei: I would assume that even though go can cross-build with the same one go binary that gccgo would behave more like gcc and you would need a cross-gccgo <efraim>I have this line for my inputs (inputs (cargo-inputs 'python-adblock #:module '(dfsg main rust-crates))) <janneke>yelninei: yay, i've cross-built texinfo-7.3 for the hurd <efraim>hmm, that would be for (rain-and-roses packages rust-apps), not sure if you'd need anything like that for rust-crates <efraim>I would remove the extra imports in (rain-and-roses pacakges rust-sources) and add the #:modules flag in (rain-and-roses packages rust-apps) and see if that makes the difference <ekaitz>efraim: in gcc-muslboot0 we don't use flex, and I had it as an input. Is it possible to build gcc without flex? <efraim>ekaitz: we need to fix the naming, we have gcc-musl-boot0 and gcc-muslboot0. I have gcc-musl-boot0 building without flex. should wehave it? <efraim>and does flex need bison or will any yacc work? <ekaitz>efraim: i just tried to replace your patches with my sources and they complain with some tokenizer issues <adanska>efraim, I tried building gnome-user-share from #6942 but I'm getting a really strange failure... my best bet is that this is related to the now missing (guix build json) module, but I'm not sure. I posted the logs under the PR. <efraim>this one? build/read-md.o:(.rodata._ZTV9md_reader[vtable for md_reader]+0x20): undefined reference to `__cxa_pure_virtual' <janneke>why is native-inputs #f when not cross-building? <ekaitz>efraim: tcc: error: undefined symbol 'lexer_line' <efraim>ekaitz: I haven't seen that one before <ekaitz>this is why i didn't try to package the bootstrapping myself... it's so convoluted...! <efraim>is it git sources vs tarball sources? <Rutherther>janneke: I expect the answer be that it is sort of not needed to distinguish them, most of the time. But I am not completely sure <ekaitz>efraim: that might be something! i was using my release of gcc 4.6.4.1 from github, that doesn't include flex and bison inside <ekaitz>maybe the official release does include them! <efraim>it sounds like something I would've done, to switch from git to tarball to drop flex/bison <janneke>Rutherther: sure they need to be distinguished, but i'd guess that when not cross-building, everything is native <Rutherther>janneke: or everything is an input. They are the same. So either of them can be chosen, arbitrarily... <janneke>yelninei: hard to say, i hoped that building from git would magically solve the problem -- and it sort of did -- but building from git presented its own problems -- so yeah <janneke>ACTION still struggles to resurrect the native build %-/ <janneke>bash/bash-minimal/inputs/native-inputs/ yuck <janneke>why is bash available when cross-compiling, but otherwise not? <Rutherther>how are you supplying bash and how are you looking for it? <janneke>Rutherther: for the cross-build, i didn't supply it, and i found it using (search-input-file native-inputs "bin/bash") <janneke>ACTION is now using (string-append #$(this-package-native-input "bash-minimal") "/bin/bash") <janneke>that seems to work for the native build <Rutherther>yes, using this package native input sounds like the best solution to me. However you ungexp is wrong <janneke>otherwise the cross build will fail again <yelninei>janneke: i see some things with (search-input-file (or native-inputs inputs) ...) <janneke>yelninei: yes, i tried that, but i've now switched to using this-package-native-input... <janneke>In procedure %search-path: path is not a proper list: /gnu/store/9pi8kah55s964qfik4cqysjdq74ll4sv-bash-minimal-5.2.37/bin/bash <lilyp>locally confirmed qtbase on gnome-team <janneke>okay, path-shebang takes a PATH rather than an executable's file-name <janneke>ACTION wishes guix would follow GNU standards and never use "path" for a file-name <theesm>hi guix o/ if a package provides a lib amongst other things, would it always be a good idea to have a separate output for it? upgraded ddcutil in https://codeberg.org/guix/guix/pulls/6972 and noticed that we have some adjacent packages that only pull it in as a dependency for its lib <lilyp>theesm it's often pragmatism over purity here; if it makes sense size-wise, go for an extra "lib" output, otherwise keep stuff in "out" <janneke> accentêd:7: warning: làng is not a valid language code <janneke>+Cannot find a locale compatible with document strings translations <janneke>yay, /me has a fix for texinfo -- will create a pull request <yelninei>janneke: oh god that patch looks like a lot of work, thanks a lot <janneke>yelninei: yeah, it took more time than i hoped :) <janneke>no worries, civodul and you also did a lot of good work; happy to help! <janneke>ACTION never imagined a GNU package to be so terrible/buggy wrt cross-building... <janneke>it's very "interesting" in a way, the cross-build relies on the auto*tools caching and GNU policy of providing pre-built info and manual pages <janneke>drop those, try to cross-build from git, and...boom <yelninei>janneke: one thing is that a texinfo is built in commencement.scm for the libc manual. When I tried updating the default texinfo to 7 it broke in commencement because of a for loop declaration (so c99+) <janneke>yelninei: yeah, i can imagine -- is it an option not to update to 7? <yelninei>yeah i downgraded the texinfo-boot0 to inherit from texinfo-6 instead of texinfo <janneke>we'd like commencement / the full-source bootstrap to be able to use latest-greatest versions of all packages... <janneke>...but that's only possible if upstream's `latest-greatest' actually supports being bootstrapped... <janneke>...and that's not true for at least gcc > 4.7, which cannot be bootstrapped <janneke>so then, we're stuck with some ancient versions of packages... <janneke>i'd really like to get a discussion about this going in the gcc community, but yeah <yelninei>why do we have to build a manual for a libc that nobody is ever going to read because the libc in commencement is uninstallable? <janneke>building docs, and also running tests, as part of any package is a big source of dependencies <janneke>it would make much sense, to me, to not build docs, to not run tests when building a package <janneke>and then, in a separate build, run the tests and build the docs <janneke>but current build systems aren't really helping with that... <avigatori>Is there documentation about how to reed the function signatures in the docs? Like e.g. <avigatori>`open-connection [uri] [#:reserve-space? #t]` <lilyp>fn required-arg [optional-arg possible-default?] [#:keyword possible-default] <csantosb>Hi, I'm trying to fix Guix SourceHut image breakage, see builds.sr.ht/~sircmpwn/refresh/guix <csantosb>I'm confused, `guix system image` always produces an image with `guix describe` 230aa37, which corresponds to v1.5.0, is that correct ? <lilyp>you mean like [optional-arg (this-thing-calls-a-function)]? <avigatori>lilyp: I think so. Example: `build-expression->derivation store name exp [#:system (%current-system)] ...` <lilyp>indeed, %current-system is a "parameter" which means it's a function whose result may change due to runtime parameterisation <janneke>yelninei: headsup, also looking at info-reader <janneke>ACTION cannot wait for old and pastor to fix this nonsense in our log files.. <janneke> 2 (link "/gnu/store/y6bn8702m2daz8gwg6f76mw3qrbibph0-inf…" …) <janneke>In procedure link: No such file or directory <janneke>"some file doesn't exist, but i won't tell you which one" <yelninei>janneke: i am still 2 gdc builds away from using my pc again <yelninei>ACTION still needs to contact bug-hurd and the D community about that <janneke>is there a way to have codeberg to `automagically' add the correct team-* labels, like we had for git send-email using etc/teams referencing the files that were touched? <janneke>ACTION saw an issue that had 10+ labels and couldn't imagine someone would have done that by hand... <janneke>yelninei: ah, so i can just wait for it <janneke>ah, we're building the d compiler by default? or do you have a specific use for it? <janneke>ACTION wanted to "help" for an hour of so and "wasted" all afternoon on it, oh well... <janneke>all for a good cause, and i'm prolly not the only one, hehe :) <yelninei>no just got interested in D and found that the Hurd support is minimal. I have 2 giant patches to bootstrap gdc-14 with gdc-11 for the 32bit Hurd <janneke>yelninei: oh, that's great; scratching your own itch <janneke>yelninei: i haven't really kept up with D, but it's basically c++ with garbage collection, right? <janneke>has it been keeping up with the functional programming support that c++ has been gaining the past decade? <janneke>ACTION hopes they're not offending anyone here :) <yelninei>the gc is disableable if you dont want it. to me it feels like a more modern C/C++, a bit sad it not more popular when go has a very similar nieche <yelninei>i also made dmd work, have not looked what would be need to for ldc because llvm is currently a nightmare to build on guix/hurd <graywolf>Hello :) Is there a way to start user's shepherd on a system boot? I am thinking about one-shot service in the system shepherd that runs /home/user/.guix-home/on-first-login (yes, the /run/user/... will exists). <graywolf>Is there a common way to do this? If not, will ^ work? <lilyp>why the f does qtbase need to be rebuilt again? <lilyp>nah, the suspect is nss-certs <lilyp>yup, got a ninja world rebuild right there <Rutherther>hmm, is nss certs for tests supposed to depend on nss certs? <ieure>I don't see a nss-certs update? <Rutherther>hm, it has it in its native inputs, so I guess so <Rutherther>ieure: I think we're talking about a team branch <lilyp>0e1cd35d6e0908529e5dbfca77bc3830312dc909 <lilyp>though f6c4dbdf5d151abf001e05d56081c8b65776edc2 is also sus, and not just because of the broken ChangeLog <ieure>I tried to pull+reconfigure last night, it wanted to build two qtbases. <Rutherther>lilyp: I think that should affect only hurd, though <lilyp>Rutherther: right, then it must be certs <Rutherther>definitely, there is a path from qtbase to nss-certs-for-tests <Rutherther>I am wondering if this has been through ateam branch, because it's 5k rebuilds <lilyp>anyway, more work for CI, I'm not gonna do this on my local machine again <yelninei>f6c4dbdf5d151abf001e05d56081c8b65776edc2 is to fix the data service which does not use builtin:git-download and should be irrelevant for anything else <cbaines>the master branch can't be processed by data.qa.guix.gnu.org at the moment, so this is going to delay QA quite a bit <yelninei>cbaines: I think this is fixed since today? unless there are more problems than I thought <cbaines>data.qa is currently still processing two revisions from yesterday, but maybe after they've finished/failed, then it'll try processing revisions including the changes from today <cbaines>csantosb, you might want to rebase the hpc-team branch since it doesn't include that fix <postroutine>Is it possible to ask Guix which package depend on a package ? I tried with `guix graph`, but the graph drawing with dot never end. <postroutine>I have only one end to the path, I cannot ask for a path. <efraim>guix graph --path will show you the "path" from one package to the other, based on which package depends on it <efraim>I can never remember the order the packages are supposed to go in <ieure>postroutine, You're asking to know every dependency *of* a package? <ieure>postroutine, All its inputs, that is. <ieure>(Assuming you want this recursively) <ieure>csantosb, That's all the packages which depend on PACKAGE, not ones it depends on. <postroutine>My `guix home reconfigure` fail during the `check` phase of the `qtbase` package build. `guix weather qtbase` tell me their is no substitute, so local build only for `qtbase`. So, I wanted to know which package required in my `home-environment` depend on `qtbase`. So I can temporarily remove it. <postroutine>So, I finally run the command `guix graph --path X qtbase`, where I replaced `X` with package listed in my `home-environment`. I found it was `cava`. <postroutine>I commented the line in my `home-environment` that require `cava` and now I can run `guix home reconfigure`. <Rutherther>it redirects to the latest build. But the frontend is unresponsive again. Someone will have to restart <Rutherther>civodul: the first time I saw someone mention it, I think cbaines restarted it. And it wasn't much better <civodul>the problem is that the rate of incoming store items may be higher than what it can handle <Rutherther>what to do about it, though? This situation is not scalable into the future <cbaines>I forget exactly about how Cuirass moves store items between machines, but I think nars are baked on the worker machines, but only used to substitute the store item on the head node, then baked again to provide substitutes <civodul>though efficient enough until now i guess :-) <civodul>Rutherther: this is mitigated by the “cache bypass” mechanism, but things like qtbase:debug must be above the cache bypass threshold <Rutherther>imo ideally the debug output should not be necessary even when there are grafts. But even if that was the case, there will be issues, ie. the emacs next pgtk out output. And this also affected librewolf out output some time ago <civodul>Rutherther: i changed some of the *-team jobsets to x86_64-linux-only, because that too was a waste of resources