IRC channel logs
2026-03-07.log
back to list of logs
<apteryx>hm, how to share a webcam device in a Guix container? <apteryx>--share=/dev is not enough, curiously <apteryx>yep, --share=/sys fixed webcam in a guix container <amano>Is it feasible or a good idea to make a guix source package for a clojure(script) project? <amano>Lots of java dependencies and npm dependencies are already packaged, so there is an established way to make source packages for java and npm. <amano>A clojure(script) project may have java/clojure dependencies and npm dependencies and clojurescript dependencies. <amano>A new build system is probably required for a clojure(script) project. <csantosb>Good morning Guix ! Regarding HPC, I have just rebased the hpc-team branch on master, as we're now third in the queue <csantosb>Any consequent HPC improvement is welcomed in the following days, then, you'll have to wait for next round ! <czan>Nice! How did you fix it? <janneke>"Ludovic Courtès wrote 5 years ago -- Thu Sep 02 -- 2021" <janneke>ACTION then wonders how the fix came to be, sometimes a fix just seems to "presents itself" <janneke>at other times, a fix comes with /a lot/ of effort <yelninei>ACTION had shepherd SIGKILL itself again <csantosb>civodul: great, congrats ! any implication in terms of packaging ? just in case ... <janneke>civodul: indeed, this is lovely; possibly not needed all that often, but when you need it it's really a pain when you cannot have it and you need an ugly workaround with duplication <ekaitz>wanna see something cool: phase `configure' failed after 690869.5 seconds <ekaitz>janneke: i reported to gash with the full command that was run during the configure step that made gash hang <ekaitz>janneke: this one doesn't trigger the hang! <dariqq>not sure what to do with librsvg and gtk <pepss>hello, today after pull guix trying rebuid qtbase and that fail. problem with that i cannot founs whats depends on qtbase in my system. <pepss>why gnome packages require qtbase? that strange <ekaitz>efraim: with your latest patch that uses make-3.80 I managed to build make and continue, now it's building oksh <pepss>irun guix graph gnome-tour@49.0 | grep qtbase <andreas-e>pepss: Try "guix graph --path gnome-tour qtbase" <pepss>andreas-e: thanks. i see that gets thouth libcamera from pipewire( <andreas-e>It is a bit strange that something that announces itself as a library depends on Qt or GTK. <pepss>andreas-e: you have qtbase broken too? <pepss>that failing build on check phase <andreas-e>The real culprit is libcamera-tools, a second output of the package with binaries. Maybe we should drop these. Or create a variant without them. <andreas-e>I did not try it out, but indeed there are no binary substitutes for qtbase. <pepss>i mean qtbase not present on substitutes <yelninei>janneke: hurd manifest is looking good for x86_64-gnu, with the fixes to get glib tests working , there is only the "flaky" shepherd test, non-minimal grub and gdk-pixbuf remaining but "guix build guix --without-tests=guix" and "guix pull" should work now <yelninei>"flaky" because it failing is the correct thing, and it is only sometimes passing because of a race condition <janneke>yelninei: pretty nice; now we need `make check' to pass and get a new guix package! <yelninei>janneke: not sure what to do with "guix build guix" itself, because of the unsandboxed build we get all the expensive network tests and the tests that use the already present daemon and store <janneke>i believe we had an issue: hurd should have containerized builds on debbugs, but i'm not sure about that <yelninei>you can work around it by disabling the network and preventing guixbuilder group access to the guix-daemon socket but imo the guix tests should have a "check-offline" or something target and not rely on containerization to disable these <janneke>(only 5y old, i guess we should have that on codeberg too) <yelninei>janneke: I found this recently as well but gave up on rebasing it <janneke>ah, yes searching "hurd" on issues.guix.gnu.org is kind of discouraging -- a lot of bugs and problems described there... <janneke>yelninei: the next-test thing to a `check-offline' could be a `skip-online-tests' phase that removes those tess being run... <janneke>and we'd only need that phase for systems that lack containerization... <yelninei>janneke: the tests use "guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)'" or try to connect to the running daemon socket as the builder so wed have to intercept these somehow but i am not shure how to do that <janneke>yelninei: ah, i just mean a "stupid" build phase in the package description and remove/disable the tests <pepss>how to update system with my version of libcamera? <yelninei>janneke: That indeed would be easier. I was trying to make it generic as the same thing is a problem in general when the daemon is running with --disable-chroot which could also happen on linux <janneke>yelninei: yes, i got that; but that might be even as much work as getting the containerized build to work... <graywolf>Hi! Is there a way to get individual "pushes" from codeberg short of git fetching every second? I would like to track a list of commits a user could realisticly `guix pull', so just git-log is not useful for that. <graywolf>On savannah I would have used the guix-commits mailing list, and while currently it still works, I would like to have long-term solution. <Rutherther>graywolf: I think you're going to be better off actually looking at the commits evaluated by CI or bordeaux, not at the pushes. They do not have to evaluate all pushes in case there are two fast pushes right after each other <graywolf>But user could still organically pull the first pushed commit (the not evaluated one), given the right timing, correct? <Rutherther>graywolf: oh you meant it like that. Yes, that is true. I thought you wanted to see commits that you would like to pull to since they can have substitutes. <civodul>ACTION prepares to merge ‘guile-team’ <yarl>A bit sorry for asking this here but I got no answer on #guile and there's probably someone here who can. Does #:continuable? has any effect when the current exception handler is unwinding? <andreas-e>Currently all evaluations on the bordeaux build farm fail, and CI is 504. <Rutherther>andreas-e: ci 504 is quite common and from what I gathered somehow the port just closes despite the frontend running. Restart of the frontend fixes it <andreas-e>The last working commit was the update of ruby-excon; the first failing one is fa3d267dc788122e6766d978947897269b191de6; in-between are hurd commits. None of them look suspicious. <andreas-e>So this concerns all branches now. Could it be related to #6941? <yelninei>andreas-e: I removed the git-fetch-from-tarball as savannah was not serving them anymore so the hurd bootstrap requires builtin:git-download <Rutherther>graywolf: codeberg supports webhooks on push, so it should be possible to somehow capture them and note them somewhere. However the guix repo doesn't really expose these afaik <janneke>civodul: /me updated the guix package the day before yesterday, and had to revert it again :-( <andreas-e>yelninei: This is not possible right now, bordeaux has disabled this to still be compatible with an older daemon. There was discussion of requiring the builtin, but it has not yet been decided. <andreas-e>Which commit is it? Could this be reverted? It this is the problem, it breaks the bordeaux build farm for all architectures. <yelninei>andreas-e: Hmm, not sure what to do then. the savannah tarballs were not stable and now are nonexistant <andreas-e>I would rather sacrifice hurd for the time being than drop bordeaux and the data service... <civodul>janneke: ‘guile-team’ had a ‘guix’ package bump (from 2–3 weeks ago), but i saw you also bumped it on ‘master’, so i guess i can drop the one from ‘guile-team’? <Rutherther>andreas-e: are you sure it's that commit, though? I see "while setting up the child process: in phase exec: executing `/gnu/store/1qvrg8z035har3zm30ascdrb766wk50q-guile-3.0.9/bin/guile': No such file or directory" in the log. It would be worth checking out if /gnu/store/1qvrg8z035har3zm30ascdrb766wk50q-guile-3.0.9 exists and if it does, what files are under it. If it doesn't, I expect there is a record in the sqlite database saying it exists, wrongly <andreas-e>Rutherther: I do not know what it is... I have trouble finding the real error in the logs. The git builtin has been a problem in the past. <Rutherther>andreas-e: do you have access to bordeaux server? if so, can you check out that path and the database? <Rutherther>andreas-e: or like if we're sure this happened on change from url fetch to git fetch, then yeah, it's goint go be that <janneke>civodul: so i was trying to give you a headsup before making the same mistake i made... <yelninei>andreas-e: I can try to add back git-fetch-from-tarball in commencement.scm with a dummy hash but all evaluations that use the tarball fallback would be wrong <andreas-e>Rutherther: The path is there with guile binaries and libraries and so on. <yelninei>andreas-e: or maybe disable bordeaux from trying to evaluate hurd derivations for now? <andreas-e>yelninei: If we want to experiment, we could do it on top of the guile-team branch before merging it. <Rutherther>andreas-e: thanks for checking, so I presume it's just a red herring then <Rutherther>andreas-e: although... can the guile be executed? <andreas-e>But doing things with wrong derivations might not work; the bordeaux build farm computes all derivations and fails when this does not work for one of them. <civodul>janneke: i tested it this particular update back then and it built fine <janneke>civodul: yes, something must have broken pretty recently on master? <civodul>janneke: for tests, apparently yes (‘tests/home-services.scm’); for this reason, i never push a ‘guix’ package upgrade without building it before <civodul>it’s quite common to have one or two test failures due to regressions <civodul>we could do better i guess, but it’s not that easy! <janneke>civodul: yes, i forgot about that -- i built it earlier on the hurd-team branch, then rebased it and pushed... :-( <civodul>ideally we’d do everything through PRs and wait from a green light from pulls.ci <janneke>somehow i got it in my head that the newfangled codeberg/ci would probably somehow magically ensure that couldn't happen, oh well <civodul>it introduces delays, but also peace of mind <andreas-e>Rutherther: The guile in there is for armhf. <Rutherther>andreas-e: and thanks for the libssh fix pushed on master <civodul>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (libxml2)) (value #f)) <janneke>civodul: ah, yes that would be the sane thing to do <andreas-e>civodul: The libxml2 problem was fixed by rekado shortly after someone else introduced it. <civodul>why didn’t ci.guix catch up, i wonder <civodul>oh, probably because the push rate was too high <janneke>ACTION had it in their mind that a guix package bump should always be pushed back-to-back to the commit it referred to, but there's no need for that, of course -- you just cannot use the guix package update from the feature branch when something happened on master in the mean time <andreas-e>I agree with Rutherther that the problem seems to be with the armhf evaluation and not with the hurd. But the problem occurs right at the beginning, and then things continue for many lines. <Rutherther>andreas-e: I am not sure how bordeaux evaluation (I think it's data-service at this point?) works like, but it could be doing parallel evaluations for every architecture. That's that Cuirass is doing <Rutherther>so if it was like that, it could be possible that one evaluation fails, the others continue and at the end it just says error due to the one. But I cannot say for certain this is the case <andreas-e>Well, this is on the master branch. On guile-team the problem is still the non-reverted update of the guix package. <andreas-e>We could rebase, but normally I rebase on a working master commit, since otherwise we do not get a comparison. <andreas-e>Only cbaines would be able to really debug the thing, I am afraid! <andreas-e>Today, just too many things break in a row, it becomes difficult to know whether a failure is the same as before or a new one... <Rutherther>andreas-e: hm, could you also try "guix build /gnu/store/lay7l7wc4n61f9q7yz96hlj82c24mbgd-guix-daemon-1.5.0.drv"? Does that fail with the no such file or directory? <andreas-e>Rutherther: It fails with the no such file error message. <Rutherther>andreas-e: is this build offloaded to another machine? <andreas-e>No, at least not when I run it by hand. No idea why it tries to use the armhf guile. <andreas-e>yelninei: Where do you see a problem with hurd in the log file? <yelninei>at the end before the stacktrace it has i586-gnu #f: (exception ... ) ; x86_64-gnu #f: (exception ...) <andreas-e>i586-gnu #f: (exception . #<&compound-exception components: (#<&inferior-protocol-error inferior: #<inferior pipe (0 1 1) 7f81bb884cc0>> #<&knots-exception stack: #<stack 7f8143be2060>> #<&knots-exception stack: #<stack 7f80bcca6fc0>> #<&knots-exception stack: #<stack 7f80bbb2d640>>)>) <andreas-e>It makes sense to believe that this is the real problem. <civodul>janneke: ‘guile-team’ exists just because of a mistake in a random package that led to 5k rebuilds when updating ‘guile-3.0-latest’ <yelninei>can you try to make it not evaluate hurd targets for now? <janneke>civodul: ah, haha; so it's possibly a one-time thing <yelninei>ACTION is sorry for breaking things again <andreas-e>We do not build the packages anyway right now, there is no running childhurd build machine. <civodul>yelninei: no worries, you did your best! <civodul>ACTION doesn’t get what the problem is, actually <yelninei>civodul: i removed usage of git-fetch-from-tarball in commencement.scm for mig,hurd and mach as savannah does not serve them anymore and I did not know what to put there, so there is a problem without builtin:git-download <civodul>we can still reintroduce git-fetch-from-tarball as a temporary measure: the checkouts are cached anyway, so the fact that savannah doesn’t serve them is only half of a problem <yelninei>civodul: can we make that fallback to SWH immediately instead of trying git-fetch/inband <andreas-e>This is a problem one could not guess, yelninei. <andreas-e>But I have trouble reconfiguring the machine; it speaks about shepherd timer as an unknown variable. Normally cbaines reconfigures with his version of Guix, I suppose. <yelninei>to avoid the circular dependency without builtin:git-download which is how <civodul>yelninei: git-fetch-from-tarball was added precisely to avoid requiring builtin:git-download; that’s why i think the easiest solution is to reinstate it <andreas-e>And when I speak of "the machine", I only mean data.qa; there is also data for the master branch. <andreas-e>Would it just be one commit to revert, or the full packet? <yelninei>civodul: With what tarballs though? savannah disabled these recently so they dont exist <civodul>yelninei: yes, but like i wrote, it doesn’t matter (in the short term) because they are cached <civodul>andreas-e: it’s trickier than a single revert AFAICS <janneke>except, on hurd-team we bumped most of them (them all?) just now... <civodul>(BTW, with builtin:git-download, data.guix implements a policy that isn’t written anywhere, just sayin’ :-)) <andreas-e>So on qa.data.guix.gnu.org, I have for the time being disabled the guix-data-service-process-jobs service, and am running it by hand in a screen session with the same command, just with the two hurd targets added to the disabled systems. <civodul>janneke: ah yes, so they’re not cached <civodul>janneke, yelninei: let’s make these tarballs (git archive) and upload them to ftp.gnu.org/gnu/guix/mirror, how does that sound? <andreas-e>civodul: Well, the data service just emulates an older daemon, if I understand things correctly. Now after the 1.5.0 release, we could decide that everybody has to run at least the corresponding daemon and not worry about backwards compatibility. <janneke>civodul, yelninei: or setup/use a mirror on codeberg (or is there already a mirror on another ugly forge?) and use their generated tarballs <andreas-e>We will see what happens. The master branch has started to be evaluated again on QA. If it finishes, I can rebase guile-team and hpc-team. <janneke>we're going to have more updates and having to do manual tarball creation where upstream even won't is...pretty cumbersome? <andreas-e>But bordeaux will fall behind on the master branch nevertheless, since job submission for this one is handled by data.guix.gnu.org. <yelninei>civodul: thats what I meant. Instead of falling back to fetching and unpacking the tarball immediately try SWH . These automatic tarballs are not stable afaik <andreas-e>civodul: So you work with CI to decide when to push? Fine with me, but I do not know how to extract the relevant information there. I only work with QA. <civodul>yelninei: ah yes, got it (sorry for being slow :-)) <civodul>andreas-e: ah well, i’m fine either way; there are few changes on the branch and i already tested them back then <civodul>but best to wait for green light from qa. <civodul>assuming we’re talking hours, not days :-) <andreas-e>But then I would have to rebase :) Except that I do not know whether there will be a green light - since the master branch jobs will not be submitted by bffe, I am afraid we will have nothing to compare the guile-team branch to. (If I understand correctly how these things work together.) <andreas-e>So if you are confident from CI that things are fine, feel free to push whenever you want. <andreas-e>And keep us updated through the debbugs issue. <yelninei>civodul: the problem is that I dont know the wizardry to set this up, but immediate SWH fallback seems better to me then the unstable automatic tarballs <civodul>andreas-e: just rebased and pushed (i built the ‘guix’ package locally first) <civodul>yelninei: actually it’s the same: if savannah returns 404, then we fall back to SWH <civodul>we could make it more explicit, but maybe it’s not worth bothering? <civodul>ACTION hopes we can require ‘builtin:git-download’ within a few months <yelninei>civodul: No that would not work, because youd fallback for a nonexistant tarball whose hash cannot be determined <Rutherther>civodul: is that going to introduce a bootstrapping problem, or not? I am not sure <Rutherther>(I mean after url fetches are switched to git fetches) <andreas-e>civodul: I have rebased guile-team once more on commit 2bdda1ea9ad34ddda8e40e69da483d033d405cb1 ; the previous merge base was still a commit that the data service has not evaluated (and it will not go back to it and try again). <andreas-e>(I have not rebuilt the guix package ;-) But I will do so now.) <civodul>info-reader@7.3 fails to cross build <Rutherther>civodul: I am wondering, would it be possible to add cross builds to pulls.ci? <Rutherther>I suppose it would be problematic since CI doesn't cross build? <civodul>Rutherther: CI does cross build (see (gnu ci)), but pulls.ci, hmm, why doesn’t it cross-build already? <janneke>OK, i've made the mistake, again, to type a whole reply on zulip, press one wrong key and everything is gone <Rutherther>unless you've actually removed it, it should be in drafts <janneke>ACTION is going to give zulip yet another benefit of the doubt <civodul>Rutherther: ah yes, that’s because ‘forgejo-pull-request->specification’ defaults to (build '(channels …)), which doesn’t cross build <civodul>this should be configurable, but nobody’s gotten around to doing it yet <janneke>i've learnt to always type text in emacs, and then paste it into a browser text box if i must...but forgot to do that with zulip just now and was wondering if that was a workflow i would tolerate <Rutherther>civodul: as in, '(channels ...) should support cross build configuration? <civodul>Rutherther: rather, the type of build for pull requests should be configurable <civodul>here, if we could make it 'all, that would include cross builds <Rutherther>civodul: okay, and for pulls.ci, we would switch to 'all then? <civodul>i don’t know if that’s a reasonable thing to do though <Rutherther>I think that cross compiling to all architectures is not strictly necessary, even one would suffice for most cases I believe <civodul>yes, but also, cross compilation is best-effort <civodul>so doing that for every single package is overkill <janneke>"<yelninei> janneke: hurd manifest is looking good for x86_64-gnu" -- that's great; like i suggested before, the manifest comprised all basic guix development packages known to build for the hurd; as the supported package set increases, i think we should consider broadening the manifest <janneke>after the guix/build-farm/childhurd updates, of course <Rutherther>civodul: what I was going for is that it would be nice if pulls.ci assessed all packages if they cross build or not. I understand that we don't have the capacity to make all packages to support cross compilation, but it would be nice to see it in the PR. Maybe could work as sort of a motivation for making the package cross build. Or at least to monitor it better <civodul>Rutherther: yes, but it’s useless if (1) it increases pulls.ci response delays, and (2) it’s almost always red <civodul>now, qa.guix did that, so i don’t know <Rutherther>civodul: I agree, especially the delays are bad. But that could be fixed in other ways, we do not have to wait for all builds to finish for the message I think. Especially the cross builds vs native builds could be split up <Rutherther>civodul: but I see that build does not at all have a target field. I think that's a bit bad since there is no difference between native and cross builds <yelninei>janneke: some things that would be great is to put expensive builds like compilers etc in there (or evaluate if the package indeed needs a nondefault gcc) because that is a 4h commitment <cbaines>andreas-e, I'm around now, and I've read some of the IRC logs <cbaines>it's another problem with the Guix package definitions breaking without the builtin:git-download, right? <cbaines>and if so, is this affecting the master branch or not? <andreas-e>Yes, apparently. But now, when trying the evaluation without the hurd I get another message. <andreas-e>Yes, it is one of the recent hurd commits on the master branch. And thus effects master and all the team branches. <andreas-e> 0 (string-append "/gnu/store/269sh0kv4x21j65jkv9zp3ryzzq4l4dj-glibc-locales-2.41" "/lib/locale" ":" #f) <andreas-e>I will stop the data service I am running in a screen session. <janneke>yelninei: sure, "we" can (should?!) extend the manifest in steps and see how it goes <Rutherther>andreas-e: in case you're running the data service manually somehow, are you sure it's not just a missing locale env var or something? <andreas-e>I do not know what it is - I have just stopped it. It was meant as a stop-gap measure, it would be better to reconfigure the machine so that it does not do the hurd evaluations. <andreas-e>I think in the long run we will move to the daemon with git download built in; or we could just do it now as well. <ekaitz>efraim: failed to build gcc 4.6.4 <ekaitz>it says failing to build gcc-cross-boot0 <janneke>ekaitz: wow, that's a /good/ question! <janneke>ekaitz: because i believe that civodul (not wanting to assign blame, just ping) explained to me we have a gcc-cross stage to make sure nothing of the bootstrap binaries somehow "leaks into" the rest of the system <janneke>which seems like very smart engineering, and makes sense... <janneke>...except for a full-source bootstrap? <Guest21>hello, is there a way to build a package that requires download assets on the internet without disabling the chroot of the guix-daemon? <janneke>so your question presents us with the idea of possibly removing the "cross" stage from architectures that use a full-source bootstrap, wdyt civodul? <janneke>(well, only if things get easier, a part of commencment would get forked, etc, not thinking about that just now) <ekaitz>janneke: i wonder if by doing this we literally destroyed all the work I've done for 3 years :) <Rutherther>Guest21: of course, any assets are downloaded prior to the build as a fixed output derivations (you specify their output hashes). That's what you do with the source typically. In case there is not just one source, just put more origins into inputs <janneke>ekaitz: of course not, gcc-cross comes after gcc-4.6, and > 95% of the work must have gone into everything up till and including gcc-4.6? <Guest21>Rutherther, huuuum, but that would require changes in the building process, correct? <ekaitz>yes, there's also some funny work at gcc-4.6 itself <janneke>yeah, but after gcc-4.6 is built, there shouldn't have been too many changes, right? <Rutherther>Guest21: that depends entirely on what the package does during the build. It's bad design if they only support downloading the assets if you ask me. But at bare minimum you will add a phase that copies the assets, yes. <janneke>still, the gcc-cross question is interesting <janneke>although it's weird it would cause problems if gcc-4.6 is correct, so yeah; dunno :) <andreas-e>cbaines: I was looking only at data.qa.guix.gnu.org and the master branch there. <cbaines>OK, I presume data.guix.gnu.org has the same issue though, although it might be behind far enough it hasn't hit it yet <ekaitz>janneke: we have to remember the riscv64 support for gcc-4.6.4 was added by not a very good programmer (aka me) <ekaitz>janneke: so probably it would only work in specific cases <janneke>ekaitz: mes was written by a far worse programmer, and that works; so no (extra) worries <janneke>but i hear that mes is getting fixed, so all is well <ekaitz>getting serious now, the gcc build system is the hardest part (yeah, right?) and some flags might be wrong <ekaitz>what we really have under control is the same process that we followed in live-bootstrap <ekaitz>anything outside that is unknown territory <janneke>ekaitz: where does live-bootstrap come into the picture? <janneke>i thought risc-v was developmed in a copy of commencement.scm that would use regular bash, coreutils, etc instead of gash/gash-utils? <janneke>at least in the beginning, live-bootstrap was downstream from our full-source bootstrap, and yeah, they added autoconf/automake/bison/flex bootstrapping and made all kinds of other very good fixes <janneke>most of which we should take in some time <janneke>but anyway, the less variation the better to get initial working code <ekaitz>janneke: i used bash because of the gash hang. But most of the rest was what we already had in the commencement in guix <ekaitz>I just copied the file out, simplified it and avoided gash because of the hangs <ekaitz>at the time the hang was random to certain degree <janneke>right, so i don't get the "live-bootstrap" bit? <noe>phase `unpack' succeeded after 90.2 seconds <janneke>ekaitz: so, exchanging bash with gash is basically the reason this has been "stuck" for two years? <janneke>earlier versions of commencement built bash-2.05? early on instead of relying on gash... <ekaitz>janneke: no, the problem was at gcc-7/9 <ekaitz>janneke: basically, at the time when I worked on this, guix had all gcc-s inherited from the same, and the configure flags were crazy <ekaitz>janneke: in live-bootstrap we managed to make it build gcc 9 and run the rest of the process. In Guix I only managed to build gcc-9 with C support, no C++ <ekaitz>the code was some convoluted that I had issues to know how was the gcc being configured <ekaitz>the gash issue is a separate thing <ekaitz>also guix is different to live-bootstrap and the flags we need are different <ekaitz>it was basically a matter of packaging <ekaitz>and of integrating with the rest of the bootstrap <jbnote>though, which leads me to think that the CI is probably mistakenly reporting success. Would anyone with some CI background be able to help me understand what's happening? (i've started a bisection meanwhile) <cbaines>jbnote, if you do: guix build /gnu/store/jw6r1bsw5jzg61bqfrh0fb6b7d4c20dv-qtbase-6.9.2 <Rutherther>unfortunately lately baking narinfos can take up to few tens of hours, which I would consider a bug, but there wasn't really agreement when I was writing to guix-sysadmin <Rutherther>the build has finished 26 hours ago and it is still not available. Now, the debug output can be few hundred MiB, but still, it shouldn't take so long <Rutherther>since there are now grafts of like... everything... the debug output is necessary almost always when something uses qtbase <Rutherther>cbaines: do you know why we graft full packages and not always outputs? I think that would fix the debug output requirement, wouldn't it? <cbaines>Rutherther, there was a change in that direction, but I think it broke things, it might have been partially or fully reverted <Rutherther>but then if I got it right, it is the desired state, it's just that it introduced a bug we should fix <cbaines>if you start generating multiple grafting derivations for the same derivation, e.g. one that just looks at the out output, and one that looks at out and debug, then you end up with three grafted outputs in the end <cbaines>the out from the just out grafting derivation, and out and debug from the out and debug grafting derivation <cbaines>and maybe it was the difference between these out outputs from the different derivations that caused problems for some software <Rutherther>I don't get that, why would we even make an out and debug grafting? why not just do separate out and separate debug, always? <cbaines>this is my vague guess about what was going on based on things I overheard ages ago, so it's probably better I don't speculate further <Rutherther>:) no worries, thanks. I will try to find the corresponding discussions <civodul>just got “no Cargo inputs available for 'rust-web-view-0.7.3.82d7cbc'” <janneke>gnu/packages/rust-crates.scm:28562:(define rust-web-view-0.7.3 <janneke>gnu/packages/rust-sources.scm:700: (inputs (cargo-inputs 'rust-web-view-0.7.3.82d7cbc)) <janneke>there's 347c97b0ad3aa5a6f13a8f09bb50c7362f5ab30 Remove rust-web-view-0.7.3.82d7cbc. <janneke>which removes the crate, but there's apparently another user still alive? <Rutherther>I don't think it's another user. Seems more like rebase gone wrong <Rutherther>it's added in 1883063bcf64bbd2f3a7148715d2669ca0bb47d4 <janneke>Rutherther: right, it's been brought back in another commit <janneke>civodul: so rust-web-view-0.7.3.82d7cbc should be removed, possibly re-cherry-picking 347c97b0ad3aa5a6f13a8f09bb50c7362f5ab30 could even work, mostly <janneke>ACTION pushes a fixup commit, removing rust-web-view-0.7.3.82d7cbc again. <civodul>Rutherther: there’s no ETA, it depends on the size of the queue, but it’s rarely more than an hour i think <civodul>Rutherther: right now ‘guix publish’ is compressing several things, including /gnu/store/01mwhvh622qmmm17f0wcd7ghzng0dnh0-partition.img <Rutherther>civodul: I think it's rarely less than an hour for larger outputs the past few weeks <civodul>and /gnu/store/7yqi664ca05zav7562kj8ak5q10b95rr-partition.img in parallel <civodul>Rutherther: yeah, we don’t monitor it, so maybe performance dropped lately <Rutherther>I am wondering what even requested these substitutes <civodul>if it’s a system test, it could be that someone tried to run the same system test, which triggered narinfo lookup <Rutherther>ah right system tests, I was just thinking about the images jobset <simendsjo>Has anyone seen this error on system reconfigure? "guix system: error: file 'guix/build/json.scm' could not be found". <Rutherther>civodul: sorry to bug you. Do you know if there is a reason why ci.guix.gnu.org has no AAAA record? <civodul>Rutherther: that’s because the MDC, where it’s hosted, does not/did not support IPv6 <civodul>would be worth checking on guix-sysadmin or with an issue on maintenance.git tho <simendsjo>janneke: Thanks, probably the issue. Removed the import, but it triggers some rebuilds -- linux compiling now, so it's gonna work for a while. <Guest74>gonna be brave, guix on the claw A8 (nonguix method). it's pretty much my new pc now lol but i've been daily nixos user for maybe 2 years and the way I operate would be better suited for guix than for nixos <gabber>i'm packaging a kernel driver module for an audio interface. shall i use the standard linux-libre-headers as input or is there a special way to treat these (since they depend on the kernel they will be used with)? <ekaitz>gabber: i think there was a linux build system or something