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 <abbe>is there a configuration for mdadm RAID1 setup ? unfortunately, as i'm reprovisioning getting off the btrfs, it fails to start the mdadm raid, complaining about lack of exclusive lock <abbe>and i get dropped to a guile prompt in initrd <yarl>abbe, what's your configuration now? <yarl>And what's the exact error? <abbe>yarl: it was LVM over mdraid (raid1, with the latest metadata), which I realize was not supported by grub, but somehow I was able to load the kernel <abbe>unfortunately i don't remember the exact error, but if I boot into any gnu/linux distro's rescue mode, the raid array gets recognized, and started without any intervention <abbe>yarl: but it was failing to get an exclusive lock <abbe>i'm now trying without lvm <abbe>mdraid /boot and mdraid / . both ext4 <abbe>appreciate your help, or any ideas you might have. <abbe>i was looking for working guix configurations shared by folks with mdraid <abbe>i use nonguix channel with microcode-initrd <abbe>in case this is a known issue with nonguix channel <yarl>abbe: I have no experience with this but I thought it lacked context. There is an example of RAID 1 in guix cookbook (3.9 Running Guix on a Kimsufi Server) <abbe>i'm on hetzner atm, but it's similar <abbe>i wonder if it's to do with me having two raid devices <abbe>i wonder if this is it: (initrd-modules (cons* "raid1" %base-initrd-modules)) <cdb-bugman>hey friends, coming from gentoo and loving guix so far. however one thing i miss is being able to have custom patches applied during a packages install. is there anything like this in guix? <Rutherther>cdb-bugman: yes, guix is source based, you can modify anything. For this, you can use transformations if in cli --with-patch for guix build, guix install etc., or package-with-patches function from guix packages if you want something in guile code <Rutherther>sorry, package-with-extra-patches function is probably more suited usually. That will just append patches, whereas the first one will replace existing ones. That could lead to issues <stochastic>is there a way to change ulimits inside a guix shell? <apteryx>I wonder; if a file-hierarchy-standard mode could make sense for some builds (e.g. building a router image). It could be nice to have a Guix package to build librecmc, for example, but I doubt everything can be reasonably patched <apteryx>(and it doesn't matter for the end result) <Rutherther>stochastic: I don't think you can do that inside the shell. But they should be inherited, so you can change ulimits in the process you start guix shell container from <Rutherther>janneke: there is no permissions to change ulimit in guix container, try it yourself <janneke>sh: fork: Resource temporarily unavailable <Rutherther>janneke: this particular example works. Some stuff doesn't work since there is nopermissions for that in the container. I assumed that's what stochastic is asking about since otherwise they would just use ulimit directly <Rutherther>for some values you can't extend above the soft limit in container <janneke>Rutherther: i'm just answering their question <janneke>if stochastic ran into a problem, they should name that problem <janneke>s/they should/it were so much more helpful if they would/ <stochastic>> stochastic: I don't think you can do that inside the shell. But they should be inherited, so you can change ulimits in the process you start guix shell container from <stochastic>i was also looking for pam-limits-service-type to raise the ulimit hard limit <abbe>any ideas what to do about btrfs filesystem corruption (esp. empty files) on a raid1 situation with 6.12.x ? or if there is a guide on how to properly configure btrfs for reliability <abbe>scrub shows no errors, nor anything in dmesg <abbe>i'll look at periodic trim instead <Deltafire>abbe: i thought you said yesterday that you had the same problem with other machines/file systems? <abbe>yep, once had it with xfs, but in other cases, it's btrfs (on different platforms) <abbe>going to disable discard (nodiscard), and enable flushoncommit, and will make a daily cron job about empty files <Deltafire>i had pacman destroy a system once when the disk became full, switched distro after that <abbe>i reinstalled another host today, where it seemed to just move to ext4 over mdraid <cassio>Hi! Does anyone know where the variable `%base-home-services` is defined? <abbe>grep -FR %base-home-services guix/gnu/ <civodul>i think it should be visible by default in config files, isn’t it? <h4>I have a profile ready to use and I want to load it up under a guix shell, how to? <h4>Maybe there is a guix shell --flag=/gnu/store/hash-profile <janneke>h4: if you just need a shell, you can do export GUIX_PROFILE=/gnu/store/..profile; source $GUIX_PROFILE/etc/profile <janneke>otherwise there's guix profile [-p ...] --export-manifest <h4>janneke: So I can't `guix shell`? <janneke>err guix package [-p profile] --export-manifest <janneke>h4: then you can do guix shell --manifest=<exported-manifest> <h4>Oh okay! I have to produce a manifest then use it <h4>It's weird, when the profile was naturally created and used by Guix itself it was able to find glxinfo but now that I source it, he won't find it <janneke>h4: mesa-utils provides glxinfo, is that package in the manifest? <h4>janneke: export-manifest don't use a profile that we have, it just try to reproduce it and re create it. And the other method weirdly don't seems to source evrfything it seems <h4>janneke: The manifest only give one package, and from there all its dependencies that have what is needed are pulled <h4>And it has in its deps mesa (not utils) <janneke>h4: doing guix package --profile=/full-profile-name --list-installed and guix package --profile=/full-profile-name --export-manifest should be quite similar <h4>janneke: Exactly, both list only one package. That package has many deps but it's the only one called per se <janneke>h4: if you installed just one package <the-package> in your profile, then you don't really need a manifest, you can just do: guix shell <the-package>? <janneke>usually a profile inherits the current environment, maybe that's what you've been seeing? <janneke>if you also need mesa-utils, you can just do: guix shell <the-package> mesa-utils <h4>janneke: I want to use one particular profile. Just using the package with shell will create a new profile <h4>Inherit current env? With source my env should inherit the profile, no? <h4>janneke: Normally I don't need anything but the profile, that was created calling only one package and was working right as is. It shouldn't need anything more, curious <janneke>h4: if you look at ../etc/profile, you'll see that it extends the current environment <h4>janneke: You mean that something from my current environment creates a problem? In what way? <janneke>h4: you mentioned that mesa-utils was available when your profile "was ready", just guessing what you might have seen <h4>janneke: So the creator of the manifest of the package forgot someting that my inherited environment was compensating but not anymore? <janneke>h4: i really have no idea, can't begin to guess what you might have seen anymore <polyedre>Hi, does anyone know if someone already tried to implement a `guix deploy` target for OpenStack? <h4>janneke: I mean that a well formed package manifest is supposed to be self sufficient, like a dockerfile. And here we are saying that my old environment had something needed and now it's not there. But the profile should provide it if the package needs it <cassio>a maybe stupid question: shouldn't I have a default `.zprofile`in some `etc`directory somewhere on my system? <Rutherther>cassio: I am not sure what you mean by should here. Guix system doesn't give you zsh service by default, not only that, it doesn't even have a service like that. So you would have to use service from other channel / make your own simple one <cassio>I have zsh as my shell in the user declaration in the systems `config.scm`. Then I have a `home-zsh-service-type`declaration in my `home-config.scm`. But I have no `.zprofile`, and since zsh doesn´t read `.profile`, things were not working OK. To start, I created a `.zprofile`with the same content as my `.profile` , which at least adds the <cassio>`.guix-home` directory to the `$PATH`. But I can't tell if this is all that my home environment expects from `.zprofile`... <h4>anyhting missed after 17:02:48? <h4>cassio: logs guix is slow idk if it would have cathed up, so yeah plz <simendsjo>Is there a way to make Guix she'll reproducible? I cannot see a way to specify channels.