IRC channel logs
2025-07-15.log
back to list of logs
<luca>Hi, does anyone have an example of a cuirass setup? I gave it a shot but in particular I get this error when accessing the dashboard `Resource not found: /eval/latest/dashboard`. Just plain cuirass locally, no nginx or anything <luca>Oh nevermind. I guess it just had to fully complete at least one job to show up <jmes>Is there a guile package that has a scheme module output (as is default for guile-build-system) and a script (bin) output that I can reference? I want users to be able to specify "package:bin" if they just want to install a scheme script that runs the "main" function of the module. <jmes>Also, is it possible to have something like a ‘guix-system-container-service-type’ that accepts an OS definition and maybe optional networking config options? The use case would be to set up a machine (or deploy multiple machines) which run one or more predefined guix system containers. <mange>jmes: Your :bin output would still need to have all the Guile modules, right? What's the benefit to splitting into separate outputs, given you won't save any space? <meaty>can someone help me get a handle on how services "are"? so it seems there is the "service" which is a procedure, then there is the "-service-type" which is a type (record?) which "extends" the "-service" procedure, right? <meaty>what does it mean to "extend" in this context? and why do we need a type? type=record? <meaty>there's documentation on writing service configs for standalone shepherd and there's the services already in guix as examples, but there seems to be a hole where there should be a description of how shepherd services slot into guix' configuration <mange>A service type is a record, but it specifies the interface of a service (i.e. its extension points, its configuration format, and what other services it extends). It is then instantiated by the "service" procedure to actually do something in a system. <mange>A Guix service is not the same thing as a Shepherd service. Guix services which want to create Shepherd services need to extend the shepherd-root-service-type. <meaty>so what is the difference, purpose-wise? what makes a guix service a guix service aside from implementation? <meaty>i presume it's that guix services only write/place files and make sure that they're there? <mange>Guix services can do lots of things, but they broadly reduce down to "run some code when the system is activated". They define a higher-level interface to communicate intent, and then the Guix service sorts out the details of making that happen. They can also do that by "extending" other services. <mange>So the shepherd-root-service-type (which is a bit special, from memory) sets up Shepherd to run at boot, and start daemons/timers/etc., but other services can extend the shepherd-root-service-type to add their own daemons (like nginx, or an ssh server, or whatever). <mange>But then other services, like the cgit-service-type, can extend the nginx service to create a HTTP server, without knowing the details of how the nginx-service-type sets up its Shepherd services, or whatever. <mange>So in the end we have a DAG of services which extend each other to create the system that we've declared. <mange>Guix services do whatever they need to do to set the system up how it's declared. Shepherd services manage daemons/timers/etc. and are one part of what the Guix services are setting up. <meaty>I see, guix services are the machinery that translates, e.g, an operating-system expression into a real "unix" system. And "extending" in this sense means defining a dependency (its existence and mechanism)? is there a better definition? <meaty>do the guix services use shepherd to help set up? or does that part stay on the "guix" side? <mange>Some Guix services define "one-shot" Shepherd services, which are scripts that run once as part of booting the system. <Rutherther>No, guix services do not inherently use shepherd <mange>One key thing is that Guix might build the system (via "guix system build" or similar) at a completely different time to when the system is booted/activated. <mange>So there's no assumption that we're doing this "live". The system definition can be built without being started. <mange>There might not even be a herd to interact with when you're building. If you're on a foreign distribution, for instance, there's no guarantee there is any Shepherd process running on your machine. <meaty>I see, so technically guix just "configures" shepherd like any other software <meaty>and it does so via "guix services", distinct from "shepherd services" <mange>Yep! If you're interested you can see the code in gnu/services/shepherd.scm. shepherd-boot-gexp defines the code that runs at boot, and it puts together its configuration file using shepherd-configuration-file. <mange>There's an extra bit of complexity when running "guix system reconfigure", because it has some knowledge of how to use "herd" to reload things, but you can mostly ignore that when you're trying to understand the basic model of how things work. <meaty>I see. so for example, a hypothetical "php-app-service" would consist of a guix service component setting up the data directories, config, and a shepherd service which would then run the server process <mange>Yeah, I have several custom services which define a Shepherd service for a process, and an nginx server block to operate as a reverse proxy, and set up a user account/dirs to run the service. <meaty>which is why there is a seperate service procedure and service type? are the service types and extension/dependency model on the guix side, the shepherd side, or both? <mange>Service types are "blueprints", and the "service" procedure instantiates them with a concrete configuration. <mange>You can think of it as if service types are classes and "service" is the "new" operator. <meaty>and this is on the "guix" side <meaty>and extensions are in this analogy? sorry i'm hung up on the term <mange>Yes. I am only describing the Guix side. None of what I'm saying here applies to the Shepherd. <meaty>are extensions a guix thing or shepherd thing <mange>Guix. Everything I'm talking about is a Guix thing. <mange>The Shepherd is only for managing processes - daemons, timers, etc. <mange>Extensions don't really fit the analogy, but they're very loosely like dependency injection? Maybe? <mange>Unfortunately I'm going AFK for at least an hour now, so I'm going to stop responding. :) Hopefully someone else will be able to answer your questions before I get back. <meaty>re. extensions are a guix thing: so the shepherd itself wouldn't know, e.g. not to kill a compositor service without killing a gui app service first? <meaty>oh no worries! I am very grateful for the tutorage :) <Rutherther>Shepherd knows to do that by knowing the requirements of a service, you configure those when you specify the service. This is not related to guix service extensions <meaty>oh, the "provision" argument? <meaty>no, the "requirement" field of shepherd-service <mange>Yep, that's right. Requirements for Shepherd services are just straightforward dependencies (which is different from extensions, as we've discussed above). <mange>... And, to avoid all doubt, there's no "extension" concept for Shepherd services. That's only for Guix services. <jmes>mange: right, yeah, there's no point splitting it. So I just need to figure out how to install both the guile module and the script, which I should be able to find in docs, thanks! <jmes>Rutherther: good to know there aren't any theoretical barriers, thanks! <mange>jmes: You can take a look at packages in Guix which already do that. guile-documenta is one (just the first one I found, I don't know if there's a better example elsewhere). <ekaitz>futurile: your mutt tutorials are really making me leave icedove <ekaitz>apteryx: 21aa23d5 is this yours? why? <ekaitz>sneek: later tell apteryx 21aa23d5 broke sioyek :) <futurile>ah yes, they were here recently - setting up that new mirror as well which is cool <futurile>I basically 'pin' the commits in my system configuration, and I guess I would do the smae in my guix-home config <futurile>I really should try Nix so I understand the comparison with Nix commands: `nix flake update` is mentioned <civodul>i think it’s essentially ‘guix time-machine -- describe -f channels > channels.pinned.scm’ <Rutherther>But not just that, flakes do provide lock mechanism, but they also have a scheme you output programs, dev shells, etc., and then nix command understands those. Additionally flakes also are by default pure evaluation. Pure evaluation can of course be used outside of flakes as well, though flakes are easiest <Rutherther>Are there any plans for pure eval in guix/guile? <Rutherther>The inputs of the evaluation are declared, you cannot use arbitrary files from the system, actual architecture of the system etc. <Rutherther>Cpu, memory size... All those systém information are hiddeb in pure eval <civodul>i think concepts do not necessarily translate between Nix and Guix <futurile>and that's different from 'lazy evaluation <civodul>so it’s not just “Nix does X; can Guix do X?” <futurile>and that's different from 'lazy evaluation' is it? (sorry was meant to be a Q) <civodul>i think one familiar with both systems has to sort of abstract the features of one to see how it could be transplanted in the other <Rutherther>Lazy evaluation is just that something is not evaluated, when it is not needed <Rutherther>civodul: right, but are you mentioning it because of the pure eval? Because I dont see why that wouldnt translate <Rutherther>I think it is quite an important feature for functional build systems as you cannot guarantee the inputs are the same in build as long as the evaluation itself does not have fixed inputs <jlicht>Rutherther: so stuff like kernel version, cpu-specific stuff like SIMD etc etc, also being captured as part of the inputs? <jlicht>among (many) other things I guess <Rutherther>You cannot access kernel version in pure evaluation mode. As for simd and other features like that, I do not know, but I would expect nix is not compiled with them to begim with, no matter pure eval or not <andreas-e>Throw to key `decoding-error' with args `("peek-char" "input decoding error" 84 #<input: src/ttsubset/sft.h 11>)'. <andreas-e>Does it ring a bell? The file seems to be in ISO-8859 instead of UTF, so I suspect a problem there. <jlicht>andreas-e: (with-fluids ((%default-port-encoding "ISO-8859-1")) (substitute* ...)) <andreas-e>civodul: Nice! By "system tests" you mean it runs "make check"? <civodul>andreas-e: no, rather “make check-system” <andreas-e>That does not even work on master for me - it speaks of a record ABI mismatch. Maybe I need a "make clean". <andreas-e>civodul: Concerning your email, I am having problems on CI. For the core-packages-team branch, it regularly complains that some .drv file (for a fixed output derivation) is missing. It can be handled by "guix build ... -S", but next time it complains about a different missing derivation. <andreas-e>uncaught throw to %exception: (#<&store-protocol-error message: "reading file `/gnu/store/j329j4c03fhg94ap73kiry6fk529xhma-st-0.9.2.tar.gz.drv': No such file or directory" status: 1>) <andreas-e>And the button "Action" -> "Retry the evaluation" does not work. <andreas-e>Now I would do a "./pre-inst-env guix build st -S", and next time something else will be missing. <andreas-e>Is there a more comprehensive way of solving the problem? <andreas-e>path `/gnu/store/w82pb8zghwyfx11b29r8lh5aigss5x1b-totem-pl-parser-3.26.6.drv' disappeared, removing from database... <andreas-e>path `/gnu/store/a7qzdmbkxs7g7vmcbbix4jh3w294991j-src-firefox-tor-browser-128.11.0esr-14.5-1-build3.tar.xz.dis-builder' disappeared, but it still has valid referrers! <andreas-e>guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed <jlicht>andreas-e: Is the store on that system using the ext4 FS? <bvd>Is there a general advised route for creating an FHS container with Guix running on Ubuntu host? General internet comments don't seem to work, haven't tried disabling AppArmor, seems overkill, is it necessary? <futurile>bvd: if you get the apparmor thing to work that would be interesting - no-one's really verified it <futurile>I couldn't get guix shell container to work <futurile>Q: I'm trying to set #:tests? to be false if it's i686 - does anyone know why this doesn't work: #:tests? #~( (string=? "i686-linux" #$@(%current-system))) ) <futurile>I keep getting invalid field specifier, but if I play in the repl it returns #t which is what the field should be. <futurile>all the other examples I can find create a custom phase, but that seems like overkill - gah! <jlicht>futurile: you can't use #:tests? (string=? "i686-linux" (%current-target-system)) <jlicht>seeing as arguments is a thunked field, AFAICT <jlicht>futurile: `guix edit grub' shows something similar <futurile>oh thanks! that grub one's also great. Dang I really need a better mental model about how some of it works <bvd>Yeah Ubuntu is stupid, but here we are. <ekaitz>futurile: aren't here some querying tools for the sexps? <aethor>Hi all. I am new to guix and have been interested for a while because of lisp and reproducible research. I have been trying to create a custom channel, but I'm encountering an odd behaviour I cannot explain despite reading the doc... <futurile>aethor: feel free to ask here - if you want to cut-n-paste in code please use the debian paste (see channel header). <futurile>aethor: if you don't get an answer tehre's also the mailing list (help-guix) :-) <aethor>I created a git repository (https://gitlab.com/Aethor/guix-aethor/) where I put a .guix_channel and .guix_authorizations. I signed the first commit with my pgp key, so that it is a valid channel introduction. Now if I add the channel in ~/.config/guix/channels.scm and use guix pull, everything is fine. But here comes the issue... <aethor>If I add a second commit, signed with the same pgp key, guix pull complain that this second commit is not signed by an authorized key. Even weirder, if I update the ~/.config/guix/channels.scm to make the channel introduction point to the *second* commit, guix pull does not complain anymore! This is really weird to me. <aethor>futurile: thanks for having me :) <aethor>(also I added a keyring branch with my key as indicated in the doc. If that matters I am using Fedora.) <futurile>ekaitz: thanks for that, yeah makes it simpler <yelninei>i think the introduction commit is always trusted <ekaitz>futurile: no probs, they were introduced later so they are underused in the codebase, but they are cool <aethor>yelninei: That would make a little more sense. In that case, I guess both commits may have an issue? <futurile>aethor: are you intending to share your channel with other people, or is it just for your own systems. You don't need that machinery for your own systems etc <futurile>you can also actually use a file:// url if you don't need to push to a git forge etc <aethor>futurile: For now it's for my own usage. But I would prefer to use a git forge to have access to the channel wherever I go. You mean it's possible to setup without all the trust setup? <aethor>although I could clone the git repo and use file://, for sure. <mange>I use a few custom channels of my own with none of the signing stuff. If you just leave off the (introduction ...) bit then Guix will happily clone the channel without checking signatures. <futurile>yes. Technically, you don't need to have a 'channel' at all. Channels are for sharing really. You could just use a module (e.g. guix system --load-path=/some/location reconfigure myconfig.scm) <luca>Have you tried `mv .guix_authorizations .guix-authorizations`? <aethor>luca: oh no don't tell me I misnamed the file... <aethor>(but thanks for the lighter solutions as well, if I can't figure it out I will make something simpler, I don't have complex needs for now) <luca>Personally I prefer remote git hosting. Be it gitlab/codeberg/cgit/ssh/whatever. I just find it easier than file paths. Maybe I just have a messy system :P <aethor>luca: you're my saviour, it seems that I indeed misnamed my files <aethor>now I feel stupid, but also happy to know that it works :) thank you <luca>nah, mistyping/misreading is in my top 3 most common mistakes for sure <luca>I once did rm -r /mnt/photos ~/Desktop to copy some pictures over from my camera <aethor>It's nice that it works because in the future I *might* share the channel, I'm trying to package some software for research (sometimes outdated things that might not be accepted as a contribution to guix) <luca>I also have a couple of packages in my own little channel. idk maybe I should upstream them, but it feels like throwing maintanance work on someone else :/ <luca>I wish I would update some existing packages, but unironically it has been harder to update stuff than to package new things for me <identity>luca: you could still be the one submitting patches for them <futurile>luca: we can always do with more people updating existing packages <kratacoa>luca: I can't answer directly, but one way to find some is to run `guix refresh` <kratacoa>on a sidenote: is there any undocumented reason why the telegram-desktop update to 6.x hasn't been done? Or is it just lack of a good pair of hands to do it? <kratacoa>(undocumented in the issues tracker, I mean. I haven't found anything) <identity>kratacoa: likely nobody got their hands on it <futurile>luca: you can run guix refresh on a section of the archive and it will tell you which ones need to be updated. The main thing it doesn't tell you is how many other packages depend on one - and that's often the reason why something isn't updated (or no-one really cares about it) <luca>So I guess the most realistic way for me would be to guix refresh all installed packages and see what's low hanging fruit to update <andreas-e>luca: I suppose there will be so many that you will have the difficulty of choice :) <andreas-e>Something I would like to see more is cleaning up of packages of which we have many copies (like ffmpeg or catch2): Sometimes a package needs a newer version, which gets added. <andreas-e>But then rarely do we move all other packages to the new dependency and remove the old one. <kratacoa>luca: I've only run it once just for fun and one other way you could contribute to it is to add new ways to check for updates for the ones that can't be checked (checkers that are general enough and not ad hoc) <andreas-e>We are at 91% for x86_64, 66% for aarch64 and 64% for i686. <andreas-e>Yesterday's updates should unlock quite a few packages for aarch64. <luca>Really great presentation! <aethor>Nice to learn about Software Heritage <ekaitz>(it was only missing the qt3d for my case hehe) <andreas-e>3D is overrated. The earth is flat anyway :) <viaken>Well, it is mostly uncarbonated. <ekaitz>sneek: later tell apteryx i updated sioyek, so no need to worry <ekaitz>but this is a very interesting case of the commits not being useful for giving context so nobody actually reads them <ekaitz>(my comments try to have some context, though) <zimoun>sneek, tell later futurile: Thanks! DebConf is really great. Very cool experience. It’s like Guix Days on HUGE steroids. ;-) <sneek>later, zimoun says: futurile: Thanks! DebConf is really great. Very cool experience. It’s like Guix Days on HUGE steroids. ;-) <zimoun>sneek, later tell futurile: Thanks! DebConf is really great. Very cool experience. It’s like Guix Days on HUGE steroids. ;-) <vagrantc>anyone have a guess how i can make my config.scm initrd modules section conditional depending on which kernel version will be installed? <nigko>vagrantc: you can access version of any package with package-version procedure from (guix packages). <sneek>futurile, you have 1 message! <sneek>futurile, zimoun says: Thanks! DebConf is really great. Very cool experience. It’s like Guix Days on HUGE steroids. ;-) <podiki>does anyone have a handy command for finding all packages which propagate a certain package? <podiki>nevermind, i think i found the package that was propagating... <umanwizard>Hi, I have a conceptual question. Why does "sudo guix system reconfigure" need to fetch the git repos for my channels? Shouldn't it just use whatever is the present version of guix? <sneek>Welcome back umanwizard, you have 1 message! <sneek>umanwizard, csantosb says: what about creating the shell, then `guix package --export-manifest > manifest.scm`, and using this manifest to create a profile ? <umanwizard>If I do something like "guix pull && sudo guix system reconfigure ~/config-desktop.scm" is the guix pull redundant? <umanwizard>csantosb: thanks, just saw the message, that's a nice idea. <futurile>umanwizard: you may have something that doesn't cache in your config? <orahcio>ekaitz: sorry, I choose the wrong slash <ekaitz>orahcio: just joking, it's ok haha <orahcio>ekaitz: Could you help me with a question? If I want to wrap ZNC in znc-home-service-type using proxychains-ng, how would I do that? <ekaitz>orahcio: i don't use guix-home (yes, shameful) yet <orahcio>ekaitz: guix has messaging services outside guix home like pounce-service-type, I want to do the same, znc-home-service was jast a example <futurile>umanwizard: do you alter the guix service configuration (guix-service-type) in your os config definition? <umanwizard>futurile: yes, to add the nonguix substitute server to the list of substitute urls <futurile>umanwizard: not using guix-for-channels ? <umanwizard>anyway, what's going on here? Why does modifying guix-service-type cause this behavior? <ieure>umanwizard, It doesn't. I have also observed the thing you're saying, where a `guix system reconfigure' seems to fetch commits for the Guix channel, even though `guix pull' just did that. <ieure>umanwizard, I have less frequently seen a reconfigure download substitutes, that can happen if some of the stuff reconfigure needs has been gc'd. <futurile>I think the only thing you can do is try turning bits-on-and-off-again to see if you can find the culprit