IRC channel logs
2025-04-10.log
back to list of logs
<piethesailor>Having a small issue with docker setup. Ive added docker to use-service-modules, and (service docker-service-type) to services. getting an error <piethesailor>guix system: error: service 'dockerd' requires 'containerd', which is not provided by any service <ajarara>piethesailor: try (service containerd-service-type) -- when I added that I also needed to add in (service elogind-service-type) though be warned _that_ made me have to reboot the machine to ssh back in <ajarara>like add those two in addition to docker-service-type <lechner>Hi, when does the Shepherd start running, please? Is it before /var/ becomes writable, or perhaps even before pivit_root in the initrd? <trevdev>My Guile %load-path is so nice in Guix. It includes many things that are just there seemingly by default. Things like gnutls, json and more in the current-system. Are these all just dependencies for Guix to work? <adanska>with `gnu-build-system`, arent `autoconf`, `automake`, `libtool` meant to be included in the native imputs implicitly? im finding i have to add them on my own. is this normal? <Rutherther>adanska: It is normal. Most packages are packaged from release tarball, where you don't use those tools <adanska>i see. thank you! that makes sense, I'm fixing a package that originally had a tarball source and now has a svn source. <meaty>has anyone here found a use for their ipfs system service? the concept is cool but it seems like there's nothing to host <apteryx>is it possible to create private keys in a one-shots shepherd service without leaking them to the store? <apteryx>a gexp wouldn't work as it's built in a containerized environment, but if it accepts just quoted scheme code to execute when it runs it could work, by producing the files under /etc/xxxx <yelninei>sneek later tell janneke: The test-symlink/symlinkat failure from gnulib is caused by glibc 8ef17919509e909746b0ad6465e9c6c952a3fe34 which causes a subtest to fail with ENOTDIR instead of the expected EINVAL. Not sure what to do about this. <Rutherther>apteryx: of course a gexp would work, its just like quoting. What executes it is determined by how it is used, it is not inherently executed in a containerzed environment <Rutherther>apteryx: the start script of shepherd service is executed on runtime <apteryx>Rutherther: doesn't a gexp always end up being built as a derivation, with its result a store output? <apteryx>I see; so the store output would be a script to run for example, and the execution of the script doesn't happen in a container <apteryx>(that's how every Shepherd service works out of the box after all, unless you use a least-authority-wrapper to get a containerized service). thanks, Rutherther! <cbaines>apteryx, is elogind-updates ready to push to master today? <cbaines>unfortunately QA isn't showing very useful information, but I think the builds have pretty much finished <andreas-e>cbaines, how about reopening the python-team branch? It would not preclude elogind or node from being pushed. It makes me nervous to see the build farm idling :) <cbaines>andreas-e, yeah, that sounds good to me <cbaines>unfortunately there's probably going to be a similar issue with python-team, where the QA data service has probably already deleted the build information <andreas-e>Ah! How could this be prevented? It sounds difficult to decide whether a branch will still be relevant in the future. Not delete build information for branches that are still around in git? <andreas-e>Merged branches are supposed to be deleted, although many teams just keep a permanent branch around, which is bad style. <sneek>janneke, you have 1 message! <sneek>janneke, yelninei says: The test-symlink/symlinkat failure from gnulib is caused by glibc 8ef17919509e909746b0ad6465e9c6c952a3fe34 which causes a subtest to fail with ENOTDIR instead of the expected EINVAL. Not sure what to do about this. <cbaines>but I think that needs separating out so that builds are kept for some period regardless, then deleted if they're unreferenced after that <janneke>yelninei: interesting, i'd ask samuel (youpi in #hurd) if they saw (or are getting) this gnulib test failure and if they did something about it? <janneke>fwiw, i found that debian/hurd skips running of tests in many cases, so possibly youpi isn't even aware this broke something? <andreas-e>cbaines: It depends on what is meant by "unreferenced". One could reference all builds belonging to named non-wip branches. <andreas-e>janneke, do you have an idea how to continue with the core-packages-team branch? Did you manage to contact Timothy for the gash bug? <andreas-e>cbaines: There are currently only three patches being handled by QA. Since the build farm has spare capacities when no branches are built, do I deduce correctly that the data service has a bottleneck in evaluating a guix tree? <janneke>andreas-e: not really and we haven't heard from samplet <janneke>then we've seen the glibc-2.41 update getting pushed to core-packages-team just when everything seemed to work and stable, which broke the hurd, which yelninei has been looking at <cbaines>andreas-e, you could, and this is what used to happen, but it takes time and space to process those branches and store that information <janneke>if you ask me, glibc-2.41 should have gone to core-packages-team-NEXT, but yeah, dunno <andreas-e>janneke: Maybe we could just revert the glibc addition then? <janneke>possibly...i believe yelninei has most regression breakage covered except for their question above about gnulib tests, although i'm not sure about the year2038 (and one other thingy), that could have been a problem with glimc-2.40 already too <Kabouik>I want to provide a reproducible environment based on Guix with my next paper. This'll be the first time for me, so I want to make sure I do things correctly. Is it considered acceptables to include in the manifest some utilities that are not necessary to the analyses per se, like tree, ls, etc. ? <janneke>ACTION hasn't been able to spend much time on this lately :-( <Rutherther>where can I see the current queue priority of team branches? <Rutherther>cbaines: oh so it's ordered already based on the priority? I always thought it's just a list of the jobs to do <futurile>andreas-e: what do you think needs to be done for python-team to be ready to merge? <cnx>hi, how do i make my function availble for ungexp'ing? <andreas-e>But merging does not need to follow this order; I understood that python-team is not yet completely ready, while elogind-updates and node-team may or may not be ready (there is some breakage, but it is up to the team to decide whether this is acceptable or not). So any of these three can be merged first if the team thinks it is ready. <futurile>andreas-e: I'm still working through some of the patches that Nicolas sent. Trying to keep it to only things that "fix a build" <andreas-e>futurile: I do not know :) For instance, if you are working on changes to be incorporated, then I would say that you are not ready. But I think it is the team's job to decide, they have the best perspective to see whether something important is broken. <Rutherther>cnx: what does that mean exactly - what are you using the procedure for? <andreas-e>Fixing builds is definitely good. And in a sense does not hurt: It intervenes close to the leaves of the build graph, and nothing we successfully build now will be broken. So we waste no CPU cycles when having the branch built again. <futurile>andreas-e: ok, well I'm not really in the team - just helping out. As soon as there are evaluations I'll compare the builds versus master and can at least try and fix stuff that's regressed. <cnx>Rutherther, I use to procedure to manipulate the make-flags inside substitute-keyword-arguments, and since it's to be reused i don't want to inline the logic everywhere it's used <andreas-e>Maybe you should add yourself to the team :) In any case, you can coordinate through the debbugs issue, team member or not. <Rutherther>cbaines: so QA builds lowest issue number first? What if the lowest issue is closed, the one above it is partially built, and the lowest is opened again? Does it stop the build, or will it finish and go back only afterwareds? <cbaines>Rutherther, currently QA works on the top two branches in the queue, so reopening an issue would push out the branch that's second in the queue <Rutherther>cnx: so I suppose you just want to execute a function that you give the arguments, and it returns new ones, then I don't think there is anything 'to make it ungexpable', you just ungexp it like it is <cnx>Rutherther, yes, but it's not found by what's evaluating the gexp. I tried exporting the function in the same module and use with-imported-modules and use-modules but the module cannot be found either. <Rutherther>cnx: with imported modules is irrelevant here, that is passing modules to the daemon. Based on what you said so far you don't need to do that at all <Rutherther>cnx: same goes with use-modules in the gexp, that is for the build time. The relevant use-modules are in the whole file you have the gexp in <cnx>Rutherther, I only tried that after #$f gave me error: #<procedure f (...)>: invalid G-exp input <cnx>If I'm calling only f then I get unbound variable, which is expected (?). <cbaines>cnx, can you put f in to the gexp, rather than trying to ungexp it? <Rutherther>importing the module and not ungexping would definitely help here, but I think it's unnecessarily complicated <cnx>cbaines, with #~(f ...) then I get Unbound variable: f <cbaines>cnx, that looks wrong, it would be useful to see some context <cbaines>... (I'm also going to drop off IRC as I'm restarting the server running my bouncer) <Rutherther>cnx: you were talking about ungexping it,but you're using it inside of a gexp <Rutherther>those are completely different things, whereas one quotes and sends it to the build side, the other will evaluate it and send the result to the build side <Rutherther>since you have the original flags on the 'evaluation' side, you can do the latter <cnx>sorry for the confusion, what should i be doing then <cnx>but with flags being a gexp, how do i manipulate it? <Rutherther>cnx: 'flags' is just a variable that you typically ungexp, because you're doing the operations on the build side, it's not the case here though <Rutherther>cnx: if you want to do it on the build side, you would have to put the procedure to other module that you then use with-imported-modules, and do someting like #~(begin (use-modules (your-module)) (the-function #$flags your-additions)) <allana>Hi guix! I tinker a lot with packaging but I am still quite the beginner. I have a package that I distribute as a docker container a la "guix pack -f docker". Running that container expects a "nobody" user, which is not present since there is no /etc/passwd in the container image. Would it be a good idea to create a minimal passwd-nobody package with a simulated "nobody" user using plain-file? then I could potentially create a symlink <allana>to /etc in "guix pack -f docker" and potentially serve my own interests. Question: How would one go about making this very simple package based on (plain-file)? Or should this be an additional build phase of my original package? <janneke>later tell yelninei: seen the remark above about asking youpi about the glibc commit that breaks the symlink test? possibly mailing bug-hurd is even better <janneke>snuik: later tell yelninei: seen the remark above about asking youpi about the glibc commit that breaks the symlink test? possibly mailing bug-hurd is even better <janneke>sneek: later tell yelninei: seen the remark above about asking youpi about the glibc commit that breaks the symlink test? possibly mailing bug-hurd is even better <civodul>allana: though perhaps we should fix it in ‘guix pack’ itself, if this is a common issue <allana>I would certainly like that, but I am not sure how common it is <jA_cOp_>if it's the same problem I think it is, it's only a problem if your container runs programs which use getpwnam or getpwuid, which is somewhat common but certainly not all programs do this <z572`>What is the current status of gcd 002? <jA_cOp_>it's kind of tricky to make the right password database with Dockerfile-style tooling, because the UID of the user in the container depends on how the container is started... <allana>jA_cOp_: I am doing something very specific, following something called the KRM function specification and it requires that containers be able to run as user "nobody" <Rutherther>cnx: sorry I might have been wrong earlier saying flags is not a gexp. I realized it can be when the packager puts in gexp. And in that case you do have to make it on the build time. With splitting the function to a different module and with use-modules, executing it inside of the gexp <jA_cOp_>allana: yeah - but surely it's the job of the orchestrator, like k8s, to arrange for the container to run as nobody, right? as in, it's not the container that starts as, say, root, and then changes user to nobody? <jA_cOp_>I think kubernetes defaults to running containers as the user specified in the image metadata <jA_cOp_>I don't know if the image created by Guix contains a specified user, or if it defaults to UID 0 maybe, but you can override the user in the pod's security context <jA_cOp_>populating /etc/passwd should only be necessary if your container contains code that actually reads that file <jA_cOp_>the libc function getpwnam is one such example (but often accessible in standard libraries of other languages, like the standard pwd module in Python) <civodul>i’ll have to update the ‘guix’ package for another fix, so we could have that too <z572`>futurile: Thanks, I was wondering if I could add a page on guix.gnu.org to show gcd <z572`>This way gcd can have more exposure <futurile>z572`: yes, it's hard to quickly remember where they are. Maybe propose it on guix-devel <cnx>thanks, Rutherther, putting it in another module works <cnx>ACTION wonders why the procedure being defined in the same module wouldn't be recognized tho <aitzkora>Hi, I'm looking for a build tools like find-files , but regarding the content, such as a grep ? Is there anyone, or should I write a ad-hoc function using grep or another tool ? <ekaitz>aitzkora: kaixo! what do you mean? you want to find some lines in the source of the package? <apteryx>so, I'm trying to use a one-shot? shepherd service to create some tls cert/key, and Shepherd doesn't like my script it seems: Attempt to suspend fiber within continuation barrier <lee-thomp>Not sure if there's something obvious in the manual I'm missing but for writing packages why would I use a '+' variant of a license? e.g. gpl3 vs glp3+? <identity>lee-thomp: gpl3 is "GPL v3", gpl3+ is "GPL v3 or later" <identity>lee-thomp: if it's the same license as redis then just copying what the redis package in guix has should be fine, don't forget to add other licenses too <lee-thomp>is it wise to comment parts of a license list explaining what they apply to? <aitzkora>ekaitz: I fact, i'm writing a recipe for a new package and the configure script (an some others) contains bad paths like /bin/rm. I started to use substitute* to replace them by "(which rm)" but I'm must find all files containing the "bad paths". <identity>aitzkora: doesn't the patch-shebang phase do that already, or am i missing something? <allana>Hi everyone, just wanted to say that using "guix pack -f docker" and symlinking a dummy /etc/passwd as part of my package allowed me to bundle a KRM function for use with Kustomize, very happy about that! <apteryx>civodul: hello! invoking 'certool --help' (from gnutls) in a one shot service appears to give me "Attempt to suspend fiber within continuation barrier" <apteryx>simply calling (system* #+(file-append gnutls "/bin/certool") "--help") in the start slot gexp appears to trigger it <apteryx>I'll come up with a simple diff to apply to our bare-bone.tmpl and send it to #77115 if it reproduces <apteryx>of course, I cannot reproduce it in a minimal example. <apteryx>so let's relax, I'm probably just PEBCAKing this. <apteryx>haha! I think this can happen when you forget to make the start slot a procedure (I made that mistake) <apteryx>hm.. is it possible that with-directory-excursion has no effect on the CWD of binaries invoked via 'invoke' ? <apteryx>at least that seems to be what I'm seeing working on my one-shot? service start script <apteryx>chdir being stateful to the process at hand (and inherited ones), it seems it should be effective, that's odd <apteryx>I think with-directory-excursion + invoke (fork+exec) is problematic in shepherd, since it uses threads or something <apteryx>at least it doesn't work as expected <apteryx>phew, I'm discovering odd stuff tonight <yelninei>janneke: I put all of the things in #77709 . Please take a look when you have some time. Was able to build almost the entire manifest for i586-gnu now. I think i need to take a bit of a break before looking more into the ENOTDIR issue <janneke>yelninei: lovely, also cc: civodul #77709 <janneke>sneek: later tell andreas-e, re core-packages-team also see #77709 <lechner>sneek / later ask apteryx / Thanks for the procedure idea in Shepherd's 'start'! Am I supposed to add a lambda to 'stop', as well? <lechner>sneek / later ask apteryx / Are those lambdas documented anywhere? They wreak havoc on my system <ekaitz>sneek: later tell aitzkora run `guix build -K` of your package, jump to the folder, find the files yourself and list them by hand if `patch-shebang` doesn't work with them. Your sources are always going to be the same, there's no need to search when the package is built. You can just search by hand beforehand. <Kabouik>What do I need to include in a manifest to have `/usr/bin/env`? coreutils is already listed. <simendsjo>Kabouik: Try "realpath $(which env)" to see the package name as part of the store name. I don't have my computer handy. <Rutherther>Kabouik: if you're talking about a container, you would have to make your own package. There is no package providing /usr/bin/env. Only /bin/env. <Kabouik>Thank you both. Unfortunately I'm hitting a roadbloack I didn't expect, ggsave() in R doesn't seem to work when run from a script sourced with Rscript. This was the whole point of the reproducible environment, I don't expect people to run the scripts interactively. <Rutherther>I realized the container actually symlinks /usr/bin to /bin, so it's fine to just add coreutils <lilyp>Kabouik: do you provide a plot argument? <lilyp>because I'm fairly certain the default is only meaningful in interactive settings <Kabouik>I just confirmed that if I exit the guix container, ggsave() works both in R console and with Rscript. Inside the Guix container, it only works from the R console. Else, it throws: In grDevices::dev.off() : agg could not write to the given file <Kabouik>So something must be missing in my manifest, I don't know what. <Kabouik>If you have any idea, please let me know, I wanted to submit tonight (though I don't have to) <lilyp>hmm, this sounds vaguely familiar to the matplotlib backend problem we have over at python <lilyp>maybe check your backend inside or outside the container? <lilyp>other than that: check the permissions of folders shared with the container <Kabouik>Permissions look ok, the script can create folder, but can't create the plots in it (I assume it's more a graphic or png issue). Also the script sourced from within the R console *will* create the plots (and even show the graphics window, which Rscript won't do; probably related) <Kabouik>I think the issue is that the Rscript doesn't open graphics window, and so ggsave/dev.off() fails even if it was provided a plot name. <Kabouik>Though outside the container, Rscript doesn't open a graphic window either (I just tested), but it succeeds saving the plot. <eikcaz>Kabouik, when running from outside a container, did you try with guix shell --pure --check? <eikcaz>Just to make sure there isn't something leaking in from some other profile <Kabouik>I'm not sure what you mean (but it's my fault): if I run with guix shell --pure --check, I'm no longer outside the container, so I would need to make a manifest again and I'll end up in the same situation as with the container, no? <eikcaz>I assume you get the container with guix shell -C? I'm saying to try the same thing but without -C, and instead include --pure --check, so we can narrow down if the issue is actually caused by the container <Kabouik>eikcaz: guix shell --pure --check -m manifest.scm followed by Rscript script.R does produce the png files <eikcaz>This SHOULDN'T fix it, but since your problem is graphics adjacent, try adding `--preserve='^DISPLAY$' --share=/tmp/.X11-unix/` to your `guix shell -C` invocation <graywolf>Hm, this is interesting, on my laptop I have a path in /gnu/store with 755, but on the other machine after guix deploy it is 555. <ieure>graywolf, Someone else mentioned this semi-recently. <graywolf>Would that affect result of guix gc --verify? Or it does not check permissions? <Rutherther>Kabouik: you shouldn't set env vars in your rc file <Kabouik>Which one are you referring to? It's a collaborative project and I don't remember doing that, but maybe someone did <Rutherther>Kabouik: I am referring to your rc in your home, it doesn't have anything to do with any project <Kabouik>I'm confused, I didn't post my rc file. Is it the symptoms that make you think this is the cause? <Rutherther>yes of course. If pure shell is getting different env, it's the rc file <Kabouik>I see nothing R-related though, most of it is nnn vars <Rutherther>to be clear, I am not saying it's cause of the issue. I am just saying it's why you're getting that text with --check <Kabouik>Thanks, I overlooked it; I'll try to sort this out at some point <Kabouik>The fact that this works out of a Guix container makes me think this may be a package missing in the manifest? <Kabouik>I got to go (but am staying online), I will resume later. Thanks for the help, lilyp, eikcaz. <Rutherther>could also be env var if you're talking about a window <Rutherther>you need to preserve your display env var and possibly also xauthority <Rutherther>yeah, for wayland it's WAYLAND_DISPLAY, and /run/user/$USER/$WAYLAND_DISPLAY <Kabouik>But I mean, tht it works differently when running the script inside R console, or executing it with Rscript; and it doesn't from my usual environment, sounds weird. What env variable would make ggsave() work differently depending on how it's run, within a same container? <civodul>sneek: later tell yelninei hey, would you like to give a hand with the Hurd on the build farm(s)? we need substitutes :-) <Rutherther>I don't know R, so I have no idea, just saying why you wouldn't be able to get a window inside of a pure shell / container shell as opposed to no shell at all <gabber>(how) do packages and TERMINFO env vars relate? <Rutherther>in the pure shell it's still possible wayland-0 will be the default tried <futurile>gabber: isn't that all 'runtime' information, that a binary uses? <cow_2001>i want to copy some files from a package. what are the relevant guile procedures? copying files i know, but how do i get the right /gnu/store/... path? something with (string-append #$name-of-package "/some/path/to/files") inside a gexp, but into which procedure do i feed this gexp? <Rutherther>cow_2001: so you want to make a new package that will copy those files to its output? <cow_2001>i want to get the path to the store and copy the files from it into somehere in my home directory <Rutherther>for that, one way would be to use program-file with the approach you've outlined. This will produce a script that, when ran, will do the operations you want <cow_2001>into what do i feed the result of program-file? <cow_2001>okay, this works in listing all my needed files! ls -l "$(guix build -e '(@ (gnu packages guile-xyz) guile-hoot)')"/share/guile-hoot/*/{reflect-js/reflect.js,reflect-wasm/*.wasm}