<mothacehe>davidl:looks like cargo is using "-j1", any reason not to use "parallel-job-count"?
<mothacehe>oops I wasn't targeting you David, tabulation error!
<zalox>Hi. I'm getting an error when running guix pull. Could someone point me in the right direction to solve? guix pull: error: Git error: object not found - no match for id (c2e2107d73f153793f2486739e39393ef4f19d5b)
<abcdw>Hi guix! connected to repl with `guix repl -L . --listen=tcp:37146` using geiser-connect. Every operation works veeeery slow, even simple evaluation of (pretty-print "test").
<mothacehe>and single CPU are propably pretty weak on build machines
<cbaines>and yeah, I noticed the influx of rust stuff, seems my desktop computer has built them all now I think, it's building common lisp stuff now I think
<mothacehe>I'm also thinking about prioritizing guix-modular and guix-master over other specifications
<cbaines>I've been thinking on how to get the Guix Build Coordinator agents to dynamically do more or less builds depending on the free CPU time/memory, but I don't think I've thought of a good approach yet
<cbaines>another approach to packing builds on to machines would be to try and predict the peak resource usage, based on historical data.
<cbaines>mothacehe, does zmq have some ordering/priority mechanism?
<mothacehe>cbaines: that's interesting, but really hard to get right I think
<mothacehe>not per se, but with the remote building stuff, Cuirass now has build queues per architectures
<cbaines>mothacehe, indeed, I might try something simple first, like deplaying builds if the load is high perhaps
<mothacehe>so if Cuirass can compute a priority of each derivation, then it's just a matter of ordering the build queue
<mothacehe>my idea is to have a priority for each "job" and each "specification"
<cbaines>In the Guix Build Coordinator, each build has a priority, and the allocators look at the graph, so if a low priority build's outputs are needed by a high priority build, then that low priority build will be treated as high priority
<cbaines>It works enough to prioritise building the Guix pull related derivations
<cbaines>I need to look in more detail at what's actually going on with trying to build patches/staging/core-updates stuff
<mothacehe>cbaines: yeah, I must admit I'm really focused on substitutes availability for now
<mothacehe>but it would be nice to see those tools converging on day
<cbaines>on one level, I'm not sure it's even a tooling issue. I think building things for substitutes benefits from stricter controls than doing QA stuff
<cbaines>and that alone may justify separating out the infrastructure
<cbaines>dftxbs3e connected a VM they have to the Guix Build Coordinator I run for patches/staging/core-updates stuff, which is great for helping out do quality assurance, and because I run a separate Guix Build Coordinator instance for builds for substitutes, there's no risk of things getting mixed up
<civodul>cbaines: yeah! i like it when i see pause-less substitute downloads :-)
<mbakke>davidl: in many cases you can simply s/systemd/elogind
<GewaltDisney>so I was just chatting with a friend, a nixos enthusiast, who wrote off guix as "elitist" considering it is FOSS-only-firmware at times prevents potential users who can only afford a used PC. I tried to convince him that guix makes the practical case for rigour and truth in a world where science is increasingly computational, as closed firmware can potentially let in side effects that can't be simply reproduced. He said I'm wrong and it
<GewaltDisney>comes from a misunderstanding of the relation between machines and the processes they implement. He's a computer science MA, whil i'm just a lowly hacker with a phd in philosophy. who is closer to the truth?
<cbaines>GewaltDisney, in some ways it would almost be nice if there was expensive hardware that didn't require non-free software to work properly, but I don't think that's the case
<cbaines>firmware is still software, and as hardware becomes more complicated, the issues around firmware become more important
<rekado_>firmware can become equivalent to circuitry; the distinction is very small.
<rekado_>FWIW Guix does not *prevent* the use of blobs. It’s just that it neither comes with them nor guides people to install them.
<sneek>guixy, guix-vits says: sometimes things broken by itselves on arm. cheer up.
<GewaltDisney>cbaines, you don't think its the case that closed firmware introduces contingencies that potentially pose problems for scientific experimentation, or you don't think its the case that i misunderstood?
<cbaines>GewaltDisney, I was saying in some ways it would almost be nice if there was expensive hardware that didn't require non-free software to work properly, but I don't think that's the case
<GewaltDisney>thanks rekado_, i know this and *shame* have some installed myself
<jonsger>how can I pretty-print guix builder files?
<jsoo>cbaines: I think the emacs-next patch i sent so many months ago was actually to upgrade to what is now just emacs. Perhaps a few items can be fixed with emacs-next variants as they exist now but the original can be closed I think
<davidl>mbakke: thx. The package I tried to install - crush - I just tried to install via "cargo build" in the source-dir, and I have no experience with the rust build system. However, I removed systemd from Cargo.toml and did export CC=$(which gcc); cargo build and then it starts compiling but still fails with some error about a file not found which clearly exists - I have no idea how to proceed.
<joshuaBPMan>GewaltDisney: I believe this cult already exists...? Ludites meditate whilst reading the little schemer, and then make jokes about Rust.
<davidl>mbakke: only the very last step fails, seems like its close to work.
<dftxbs3e>cbaines, maximizing utilization of both RAM, CPU and disk/network IO is a really tough problem, not sure any package management system has really solved it well. Maybe Gentoo's good at that I think.
<cbaines>dftxbs3e, yeah, I haven't used Gentoo, so if you have any references to what they do, that would be great
<civodul>jonsger: re pretty-print, if you use Emacs, emacs-guix does it automatically when you open a *-builder file
<jonsger>civodul: I don't use emacs and try to write some `guile -c ...` which I can pipe into ^^
<dftxbs3e>cbaines, That --load-average flag of Portage/Emerge they have is really good I think.
<civodul>jonsger: then yes, you can do like "cat *-builder | guile -c '(use-modules (ice-9 pretty-print)) (pretty-print (read))'"
<ngz>cbaines: Let's start a roleplaying game! ;) I want to review bug#45247. I go to patchwork.cbaines.net, look for the bug, see all lights are green, click on patch, click on "View comparison", see that there is no introduced lint warning, click on "compare packages" and then…
<ngz>(am I right so far?) then I notice there is no colored square on the right. Does that mean the commit has not been processed yet?
<ngz>If I may, I'd suggest to but a quick recap on this page for people like me… :)
<cbaines>PotentialUser-37, I don't think Guix provides a simpler way of registering nicknames on Freenode. If you don't understand Freenode's documentation on the process, there's probably other documentation that might be more detailed.
<ngz>Ideally, it would be nice to have some dashboard accessible from patchwork that lets you know 1. if the patch introduces linting issues 2. if it has been built already 3. if it introduces build failures in dependents
<cbaines>ngz, yeah, maybe that can be some other thing that uses information from the Guix Data Service, or maybe those can be reported to Patchwork as checks
<cbaines>The current "Checks" are really just me abusing the Patchwork interface to link to other things
<ngz>IMO, they do not really belong to patchwork, indeed.