IRC channel logs
2025-01-18.log
back to list of logs
<lfam>podiki: Regarding CI build performance, I do think it's possible that the build farm could do thousands of builds per day *and* be mostly idle. It's incredibly powerful <lfam>But we definitely shouldn't be waiting for builds while it is mostly idle. That's a super annoying bug <podiki>right, it's not the number of builds i've looked at, just when it is mostly idle yet there are pending builds <podiki>seems to be at least a day behind, yet not using all workers. so perhaps some bottleneck in distributing jobs? or getting jobs that need workers <lfam>Yeah, something is definitely wrong. I just wanted to point out that the capacity is counterintuitively vast <lfam>And we should use it freely. The CPUs are not getting any younger <podiki>i want the workers working all the time, if they have capacity we should use them and let us do more automated stuff with patch testing <elb>the documentation for defining packages is a little confusing around the area of arguments and quoting <elb>I just did a build that needed modify-phases, and I had to quote my arguments form to do that, but I had to _unquote_ my configure flags because they used a gexp, and the whole thing is kind of opaque to me <elb>I don't know how to express it better because I kind of just looked at what some other packages did and pushed it around until it worked <elb>but if anyone wants to dig into that I'm happy to help, I think the documentation could use a little more exposition for us noobs <ieure>elb, Paste of your package definition would be helpful. In general, you just get the hang of it. <ieure>I understand this is not a very satisfying answer. <elb>I originally had (list #:configure-flags #~(list ...)) and the only plist entries were #:configuire-flags and #:tests? <elb>when I added #:phases, I was getting a failure to resolve %standard-phases, but the documentation seemed to be doing more-or-less what I was doing <elb>when I started looking at packages, most of them were using quasi-quotes _with no unquotes_; I changed to that and it died on a gexp error, so I just unquoted my gexp (intuitively, no reasoning I could justify) and it all worked <ieure>elb, I've most often seen (arguments (list ...) so you don't have to deal with unquoting the containing list, only the gexps inside that list. <elb>yeah I think I could probalby use list and then '(modify-phases) or maybe `(modify-phases) <elb>but that's not what I mostly saw in (gnu packages) <ieure>elb, There's a lot of older stuff in (gnu packages) that isn't up to the current standards. <elb>if I could find those standards I would use them ;-) <elb>(or even a list of known-good exemplar packages) <elb>ohhh with just modify-phases in a gexp <ieure>elb, Yeah, I think this is a definite gap. You can get some good mileage out of `guix import' for feeling out the right shape of a package, but the one-size nature of that tool means you aren't going to encounter the specific stuff you're encountering. <elb>hmmmm guix build returns immediately, I assume that means the compiled description of the package is byte-for-byte identical <ieure>Yeah, nothing material about it changed. So it works :) <elb>I changed from `() to (list), un-unquoted the #~(list ...), anad put a gexp reader prefix on (modify-phases ...) <ieure>Nice, sounds like that's going to be quite a bit nicer to read. <elb>I dunno, it doesn't have any unquotes <elb>and that's always a plus <elb>all the little reader prefixes line up nicely ;-) <elb>it's not fully clear to me what is and isn't a gexp in these things <elb>anyway, I guess my feedback is that I got to where I needed to be, and that's good, but I didn't really feel good about how I got there, and I think that means that there's some missing or unclear documentation <elb>but because my handle on what I did is shaky I can't just fix it and send a patch <ieure>Anything with the #~ prefix is a gexp, so, the value of #:phases and #:configure-flags are gexps. <nathan-web>Can anyone point me to a working `wgreetd-wlgreet-session` configuration, or tell me why ```(greetd-terminal-configuration (terminal-vt "1") (default-session-command (greetd-wlgreet-session)))``` results in a `invalid G-expression input` error? <elb>oh no I know that, but clearly something _inside_ modify-phases expects to be a gexp, too, and I don't know why <elb>like why did putting #~ on the front let %standard-phases resolve? <elb>(I understand that #~ is the gexp reader macro, but I don't understand what it has to do with %standard-phases or expanding the body of the lambda (if anything, although it smells to me like copy-recursively might be a gexp-using-thing?)) <ieure>elb, %standard-phases is a macro, when you quote it, it needs to eval in the context of the builder, so it doesn't work when it evals in the context of the package definition. <elb>when I looked at (guix build gnu-system) it just plain exports %standard-phases, so that confused me <ieure>Uh, delete "when you quote it, "from that sentence. <elb>yeah that was my understanding of gexps, is that it's like define-time versus build-time <elb>but it seems like they also have some other magic? <elb>or maybe just some forms expect to be build-time, and there's no other magic? <ieure>elb, I believe it's the interaction of magic of gexp and magic of %standard-phases. Just because it's exported doesn't mean it's not magic. <elb>I'm rereading the gexp docs now and I'm actually getting more out of them than I did the last time <elb>(this is a persistent experience for me, the depth of layers in the guix documentation is significant, it kind of requires a few passes to resolve all the connections, for me) <ieure>elb, I agree, it's hard to approach as a beginner. <elb>part of my problem is that I go months and use only very trivial things, and then I do something like try to add a package and have to _re-learn_ things I allegedly knew before ;-) <elb>there's an example in the G-expressions info node that uses (with-imported-modules '((guix build utils))) and then #$output in the enclosed gexp, am I correct that that's roughly equivalent (or identical to?) what I did with (assoc-ref outputs "out") ? <elb>ok, so, the next, more important (becasue I got the last one to work) question is <elb>what I'm heading toward is installing a guix system that uses this package, and I'd like to describe that all declaratively, because I anticipate deploying this system more than once (it's for a course I'm teaching, there will be bumps in this road) <elb>I can upstream this package (and I'm happy to do so), but in the intermediate term I think I need to continue to work on it locally, and be able to deploy it in that system <elb>what's the Right Way to deploy a local package into a system? <elb>create a channel? include the package definition in the same file that defines the system? something else? <elb>it needs to be something I guess that persists through to /etc/config.scm <zeropoint>is anyone here aware of a guide to linking libraries inside guix shell? <zeropoint>I need openssl for a project I'm working on and struggling a bit to find exactly what to pass to the linker/configure script <elb>zeropoint: can you just `guix shell openssl pkg-config` and then use pkgconfig normally? <elb>(e.g., in this case, `pkgconfkg --libs openssl`) <elb>it's probably what configure is wanting to use by default :-) <zeropoint>oh, I'm stupid, I was using the wrong library name :/ <wakyct>elb I think one way to go about it is use build --load-path while you work on the pkg, once you have it in a final state you could add it to a personal channel <wakyct>I haven't seen pkg defs mixed with configs, that seems wrong but I don't know <vhns>I could be wrong, but from what I could gather in the documentation, the ssh key used for guix offloading has to be readable by any user on the computer wishing to use it, right? <vhns>As it, it can't be readable exclusively by guix-daemon or root <elb>wakyct: I don't love the idea of mixing it with the config, either <meaty>technically I could name it "woof!" but idk if that would rock the naming scheme boat too much <apteryx>hm, I've used deprecated-package as documented in our contributing node to keep a renamed package available, but testing via './pre-inst-env guix show old-name' says no such package ? <apteryx>weird, doesn't work with 'show', but 'install' picks it up <podiki>show just searching the "name" field? <meaty>nvm, it's in a newer version <apteryx>ACTION wonders why gdb insists prompting to look for debug info servers just to abort later saying support for it is not built