<mbakke>civodul: yes, pango@1.42 is the failing version, aka the special librsvg 2.40 variant <mbakke>the joys of maintaining legacy software :-) <mbakke>probably we should make librsvg work with the newer pango instead <mbakke>reverting both the freetype and fontconfig patches made it work <mbakke>but, providing the old versions as inputs did not <slimjim>hey #guix, I'd thought about trying to package python-cherrypy (webserver framework) - anyone know if there is any prior work here? A comment in the python-cachecontrol package disables tests because "Versions > 0.11.6 depend on CherryPy for testing; It's too much work to package CherryPy for now." <slimjim>any tips on why it's too much work and if anyone started looking at it before? <dustyweb>mbakke: slimjim: feel free to pick up that work from where I dumped it on the floor <jorge[m]>Hola,no puedo entrar a bajar la imgen de Guix con hurd -502 Bad Gateway <guixy>hi guix. For a final project of the semester I need to do machine learning on a large data set of my choice, and I chose all guix packages :) I need to get certain data points from a package structure, including the arguments to the build system. I am writing a function to use matching to turn it into an alist, but I thought I would ask here, is there already a better way to do that? <ryanprior>guixy: I have a janky method of doing this that's part of guix-packaging.el <ryanprior>The non-janky version would involve actually using a Guile parser, and I may go that route eventually <guixy>The arguments is just in the form '(#:key val ...) so I figured I could run reduce with matching to make it the form '((key val)...). It's already mostly done, and I think it might be easier to finish it than make a parser. Thanks though <guixy>Maybe when I'm done with my project I'll publish my findings. I love the guix kernel for jupyter, but I think I need a colab-compatible notebook for this project, meaning I need to do everything in python and probably include calls to !pip install... <guixy>But that doesn't mean I can't use the guix kernel to generate a file to be loaded by the notebook I turn in, or to draft what I'll put in there. <guixy>I'll admit, the guix kernel is missing some basic functionality though, like "kernel->restart & clear all" <kozo[m]>Greetings, I am getting "guix system: error: service 'guix-publish' requires 'avahi-daemon', which is not provided by any service". Does anyone know what needs to be added to provide it? I tried (gnu packages avahi) and (gnu services avahi) <lfam>Hm, maybe the guix-publish service should do that automatically? ***amfl_ is now known as amfl
***amfl_ is now known as amfl
***apteryx_ is now known as apteryx
<civodul>cbaines: looks like we're missing mothacehe <civodul>perhaps we'll skip the discussion today? <cbaines>I'm busy trying to unmuddle my Prometheus metrics <cbaines>it would be good at some point to talk about making better use of bayfront, milano-guix-1 and harbourfront though, I don't think they're building much at the moment <cbaines>which I'm guessing is because of the unreliability you can see when you look at the evaluations <civodul>i thought bayfront had more x86_64 substitutes than berlin a few weeks ago? <cbaines>although there's been quite a lot of changes lately <civodul>number of pending builds keeps growing on ci <civodul>perhaps in part because completed builds are not properly accounted for <cbaines>well, as far as I understand, that accounting issue comes from Cuirass not having attempted to build those things yet <cbaines>even if they have already been built <cbaines>I guess ci.guix.gnu.org hasn't switched to using the Avahi based discovery yet, as I'm guessing the machine hasn't been rebooted <vldn>hi folks, it seems link i messed my USB stick up. It says that the cow-store service isn`t found by shepard so the stick complains about not enough space while Installation <vldn>is it possible to start the copy on write GNU store without the service? <vldn>or can i Copy the content of the stick manual to the HDD and run grub install vor sth? wiped my whole system before.. so generating a New stick is not possible :D <vldn>i created it with a custom config scm i know where the Problem is but now i can't make a New stick and have to work with it :D <vldn>everything works but the cowstore service From the install.scm is missing <civodul>like you write, the cow-store service comes from (gnu system install) <vldn>true and i missed to include it <vldn>so its like an installed guix system on a writeable stick <vldn>so can i move the GNU store manual to the harddisk? <vldn>or add the cow-store service without rebuilding? <civodul>no, you cannot move /gnu/store manually <dftxbs3e>cbaines, civodul, rekado: it seems issues.guix.gnu.org doesnt get new bugs since a little while now (a day or more) <dftxbs3e>to be more precise, it doesnt list new bugs in home page or search results <dftxbs3e>but if I enter the bug id in the URL it works <civodul>ah, so it must be the thing that updates the Xapian database that's dead <rekado>I’ll try to look into this today <maav>vldn: if you really cannot create a new image nor download one of the ones available, you could do manually the steps from (@ (gnu build install) mount-cow-store): create an overlay with the new folders, giving them the right owneship beforehand, and move the mount for /gnu/store to that new overlay <vldn>maav: thats what i want to try next, seems like there is no other way like Copy stick partition as whole to disk and update grub mountpoints? <nly>Anyone feel like updating zfs to 2.0? it uses linux-module build-system <maav>vldn: nope, that shouldn't work, e.g. there are store files for the system generation that reference file-sytems and mapped-devices <mbakke>civodul: reverting 2dfb16150e11f273fd6f991bb563bf02a8a69402 worked for pango@1.42 <mbakke>replacing the 'fontconfig' input with a gs-fonts one is not sufficient <civodul>mbakke: ah, so that means there's a deeper issue? <mbakke>civodul: yes, not sure what needs that fix ... I tried a sledgehammer approach with package-input-rewriting, but got into circular module dependency troubles. <civodul>what did you want to rewrite though? <ces>Hey, how would one package a binary file? I am trying to make a package for =handlr=, but packaging the source turned out to be a major pain (also i am not familiar with rust/cargo). I found there was also a binary release, but i haven't tried packaging a binary yet, and i can't find any examples to copy. <mbakke>civodul: tried both font-dejavu -> gs-fonts, and fontconfig -> fontconfig/gs-fonts :P <mbakke>and defining pango@1.42 in terms of a 'with-fontconfig+gs-fonts' procedure... <civodul>mbakke: ah so pango@1.42 still needs the gs-fonts-based fontconfig? <mbakke>civodul: yes, but indirectly :-) <mbakke>yes, not sure what to do about it <civodul>why indirectly though? "guix graph --path pango@1.42 fontconfig" shows a direct dependency <civodul>to avoid the module circular dependency, you could use package-input-rewriting/spec <rekado>ces: packaging a binary is easy in theory: you just copy the binary to the target location (e.g. with the trivial-build-system) <rekado>ces: but practically speaking things can get really difficult <rekado>ces: if the binary is linked with other libraries it will likely expect them to be in certain locations that don’t exist on Guix <rekado>ces: it may also be built to use a certain location for the loader, which can be patched with patchelf. <rekado>so ultimately it may really be *easier* and more reliable to build from source. <mbakke>civodul: yes, but overriding the fontconfig input directly makes no difference <mbakke>good idea wrt spec, will try it later today <civodul>ah yes, because there are other paths to fontconfig, such as pango -> cairo -> ghostscript -> fontconfig <civodul>another option is to just skip the offending test, no? <civodul>it seems to be checking the location of glyphs or something along these lines <jeko>git pull… guix pull… too close, I do the wrong one so often ! <pineapples>I'm having a problem with the unattended-upgrade-service. I set a variable containing a channel definition in my config.scm, and passed it to the 'channels' field of the service definition, and this is the error that I'm getting in the unattended-upgrade.log: "error: %my-list-of-channels: unbound variable". I examined the contents of /gnu/store/xxxx-channels.scm, and it literally contains the string "%my-list-of-channels" inste <civodul>pineapples: the %my-list-of-channels variables lives at the time your config.scm is evaluated <civodul>whereas the 'channels' field is evaluated when the unattended upgrade happens: in a different process, at a different point in time. <civodul>so what you should do instead is "stage" your list of channels so it's available when unattended upgrade happens <civodul>the way to do that is, in your config.scm: (define %my-list-of-channels #~(cons (channel ...) %default-channels)) <civodul>and then you can have: (unattended-upgrade-configuration (channels %my-list-of-channels) ...) <zzappie>Yesterday I found packages that won't compile with curent guix's go-1.14. Apparently 1.15 is the "stable" thing today <zzappie>I've updated go package locally but when I try to run './pre-inst-env guix build --rounds=3 go' guix just spits out currently installed go-1.14 store directories <zzappie>am I missing something? It supposed to work like that? <nixo_>Hi guix! I packaged weblate and wrote a service for it, the way before being able to send the patches upstream is still long, but in the meanwhile if anybody wants to host an instance I pushed the code here: https://git.nixo.xyz/nixo/weblate-guix <mekeor[m]><nixo_ "Hi guix! I packaged weblate and "> that's so cool, thank you nixo_! love to see the number of guix-packages and especially -services grow :) <mekeor[m]>i didn't know about weblate before but it looks awesome! <nixo_>mekeor: Yeah I'd love to see more guix services, too, but it always takes *so* long for me to write one. Also, this one is really ugly, I should put even more hours fixing it <civodul>i think roptat & fellow translators will love that :-) *jeko fires pk command to find where things get nasty <civodul>nixo_: i'd recommend getting patches upstream incrementally <civodul>that often works better than sending a 50-patch series :-) <pineapples>civodul: I do have one more question if you don't mind. It's okay if you don't reply at all; I'll assume you're just really busy, and will try to figure this out on my own. So, I'd like to make my configuration as compact as I can (by setting as few variables as possible to achieve the same outcome), and I'm wondering if I could directly insert a scheme-file object, such as the one from this thread: https://lists.gnu.org/archive/ <civodul>pineapples: the 'channels' field expects a gexp, not a file-like object, so you cannot insert such a thing <euandreh`>Is there a downside of putting (keyring-reference "master") in the .guix-channel? <civodul>euandreh`: it just means you'll have .key files in the same branch as the source <euandreh`>yep, that was expected. For a tiny channel, this shouldn't be a problem <civodul>just slightly annoying maybe because the two things live their lives independently of one another <civodul>the keyring-reference is just a key store, and you might need to update keys sometimes <euandreh`>yes, failing to understand that even though they live in the same branch, they're not tied together <euandreh`>failing to understand that would be a problem <efraim>can the keys be shoved into a directory? <luis-felipe>Hi. Do you know which package provides the "dig" command? <mdevos>luis-felipe: guix show bind looks promising <mdevos>install the "utils" output, not "out" <luis-felipe>mdevos: Ah, I was searching bind-utils and didn't find it. Thanks :) <mdevos>how to find dig: try "guix search dig dns". <efraim>Do we have the phoronix test suite? <abcdw_>Am I understand correctly the following about channels?: <abcdw_>1. `guix pull` downloads all the channels to the store, builds guix with load-path equal to all those channels and creates a new profile generation with guix-wrapper, which can call compiled code. <abcdw_>2. `guix time-machine` do the same, but doesn't create a new generation of current profile. <abcdw_>3. The information about profile generations is just a bunch of symlinks /var/guix/profiles <abcdw_>4. `guix pull` uses current-guix profile, `guix package -bla-bla` uses guix-profile. <mbakke>abcdw_: pretty much, although each channel is built separately, and are added on load-path by the guix wrapper script <abcdw_>mbakke, Thank you for confiramtion! <jorge[m]>Hola,no puedo entrar a bajar la imgen de Guix con hurd -502 Bad Gateway <civodul>jorge[m]: hay un problema con estas imágenes, discuple las molestias <nalaginrut>And how can I modify the default url of `guix pull` <jorge[m]><civodul "roptat: possibly useful referenc"> Seguro se resuelve, me cambie a GNU Guix para contar con hurd y mis 4 libertades por supuesto, esto me ha gustado mucho. <nly>if you compile a custom kernel how does linux-module build system find the kernel? <nly>(default-linux) -> (resolve (gun packages linux) 'linux-libre) ***stikonas_ is now known as stikonas
<dissoc>how does guix determine whether or not to rebuild a package for an inherited package? i inherit the parent and make changes to the config flags and phases, but it seems like it doesnt rebuild when i change just those things <nalaginrut>abcdw_: it seems there's no ~/.config/guix/channels.scm in default <lfam>dissoc: That usually means that your development environment isn't set up right <lfam>dissoc: You can check if it's going to build with your changes by doing `guix build foo --derivations` and reading the derivation to make sure <lfam>A common way for a development environment to stop working is having garbage collected the development dependencies <dissoc>im not sure i understand what development dependencies are <dissoc>package dependencies? or guix dependencies? <lfam>They are what is provided by `guix environment guix`. The software that Guix depends on to build and run <lfam>Are you using the ./pre-inst-env setup? <dissoc>there's a strong possibility i might've done that. considering i dont really know what im doing <lfam>Okay. If you'd like some help, let us know what you tried and how it failed <dissoc>and i've tried to install it. but it seems like my wrap-program or any other changes i've made dont work <dissoc>i did guix package --install-from-file=myfile.scm and in the file i returned that package (not shown in dpaste link) <lfam>Do `guix build --no-grafts zabbix-agent-jmx --derivations` <lfam>Open the .drv file returned by that command <lfam>Find the part that says something like "/gnu/store/...-zabbix-agent-jmx-version-guile-builder" <lfam>Read that guile-builder file <jackhill>woo! I have a working ppc64 machine for use of a guix port. This is different than the ppc64el that we talked about at Guix Days and efraim's ppc, but hopefully still useful. <lfam>dissoc: If your package definition is written correctly, the guile-builder file will contain the 'enable-java' string <nckx>jackhill: ppc64 == ppc64be(-only)? <lfam>dissoc: The derivation .drv file is what the guix-daemon actually builds, and the guile-builder is one of several files that go into that process <jackhill>nckx: yes. Not sure about only, but be is how it's supposed to be run. (Apple G5 computer, which IIRC is mostly POWER4) <dissoc>lfam: this is great. my changes to the configure-flags works fine. but it looks like my modiifications to phases didnt work. at least i can understand now <dissoc>and that makes sense why i tried to do other stuff under phases for sanity check but they didnt appear to do anything <lfam>Hm... I'm not sure what's wrong, but I think you are on the right path. <dissoc>i can look around at other packages and see what i did wrong <dissoc>thanks for the help. at least i have an understanding now <lfam>Don't hesitate to ask for more help! <dissoc>is there a way to build a package to a specific directory and not install? like how you add -K and if it fails the files can be found in /tmp ? <mdevos>dissoc: maybe guix build package-name instead of guix install package-name? It buids without installing <lfam>dissoc: What do you mean by "not install"? <dissoc>i guess not add to store is what i really mean <mdevos>dissoc: why would it mateter whether it's added to the store? <dissoc>i guess it doesnt really matter. it is pretty nice just going to /tmp when a build fails with -K. easier to navigate <mdevos>dissoc: I seem to misunderstanding what you're saying. What do you want not to be added to the store? *lfam still chuffed about the substituter improvements <dissoc>mdevos:i dont even know. not important <mdevos>dissoc: the only difference between adding build products to the store you don't want and not adding these builds would be disk usage *mdevos away-from-chat (but still on keyboard) <mroh>dissoc: I think, the "java-bin" variable isn't right in your snippet, it should point to "jdk" not "out", no? <dissoc>mroh: haha yeah. that's probably it <dissoc>not sure how i messed that one up <mroh>evolution has shown: humans are build to messed things up ;) <pinoaffe>is there something in guix that can unpack rar archives? <lfam>pinoaffe: I believe that file-roller can handle some RAR archives <lfam>Unfortunately unrar is not free software <lfam>Maybe Debian's unrar is in a good state now, idk <leoprikler>If there war a free version of unrar, that could handle newer archives, that code would already be in libarchive (which is used by file-roller) <dissoc>i got my package building correctly from copy pasting the parent and modifying it. but for whatever reason i couldnt get the modified phases to work with inherit. something i guess im doing wrong but it looks the same as similar packages <pineapples>Anyone have an idea whether it's possible to have realtime mcron jobs not expire in the scenario, in which a machine was powered down prior to the job running? <pinoaffe>I wrote some emacs lisp to "toggle" which profiles to enable emacs-wide, thought some of y'all might have a use for it https://bpa.st/F5UA ***amiloradovsky1 is now known as amiloradovsky
<civodul>pinoaffe: nice! would be great to have something like this in Emacs-Guix <pinoaffe>civodul: the issue with that is that this only works due to certain assumptions on how your profile- and manifests are stored on the filesystem, so I don't know how well this would work as a general-purpose package <civodul>yes it would need to allow you to choose a manifest etc. <mbakke>sneek: later tell apteryx I saw you had done some work towards bootstrapping Rust 1.29 directly, do you still have that patch around? <cbaines>I've got an odd issue where I can't reconfigure one machine, because it tries and fails to build /gnu/store/4d4ndvs1265b8b6zz2i17j5azsni4f6d-qemu-minimal-5.1.0.drv for some unknown reason... <civodul>cbaines: d'you have a build log for that one? <cbaines>civodul, I can upload it if that's useful <cbaines>I don't know why it's building this derivation though, it's not one the Guix Data Service knows about, which is a bit odd <cbaines>It's an input to /gnu/store/7r15ch35ls1jfgvblg6ykvhcdns670ns-grub-2.04.drv which it's trying to build <civodul>isn't it just a graft/no-graft thing that explains the different .drv? <civodul>you could first find out where it comes from, or where the grub.drv comes from, with "guix graph --path -t references" <dongcarl>Hi all, when doing `guix time-machine` to a past where guix authorization didn't exist... Is `--disable-authentication` the recommended option to specify? <civodul>dongcarl: hey! i think it works without it, no? <civodul>if the target commit is a ancestor of the introductory commit, it's considered authentic <mbakke>civodul: in the end I settled on just disabling that one Pango test (pushed!) <dongcarl>civodul: Oh... But the repository needs a keyring branch? <civodul>mbakke: awesome, thanks for taking the time to go through all this! <vagrantc>finally used guix time-machine to build a one-off commit rather than having to actually pull it or mess around with a git checkout <civodul>lesson learned: even "just" ungrafting is work <vagrantc>so it also handles parallel universes, not just time <mbakke>np btw; I'm warming up for "core-updates" ;-) <dongcarl>Encountered it several times now and would like to avoid re-installing to work around it <jonsger>dongcarl: did you tried an intermediate pull hop? <dongcarl>jonsger: I have not yet. Could you explain how that might fix it? <mbakke>vagrantc: those are closer related than you might expect! <mbakke>and "guix parallel-universe" is reserved for a future (or past) version of guix <civodul>dongcarl: there are substitutes for /gnu/store/plgzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv but i presume you've disabled them, right? <civodul>oh weird, i've just run "guix build /gnu/store/plgzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv" and it pulled substitutes for me <dongcarl>civodul: Looking at logs... I see: substitute: guile: warning: failed to install locale <dongcarl>but I have locale installed on both home and root profiles... <civodul>you'll no longer have them if you update your daemon <vagrantc>it's tricky to get the right set of locales in your profile, as guix requires different locales based on glibc version <ryanprior>that warning is meaningless afaict, it comes and goes and people who follow all the instructions still see it <dongcarl>Still, in any case, it should work without substitutes... <vagrantc>so when transitioning between glibc versions... you get those surprises <dongcarl>My invocation: guix pull --branch=version-1.2.0 <civodul>dongcarl: yes, so i wonder if there's a non-deterministic build failures here, like parallel builds <civodul>my --check run completed but that's on my 4-core laptop <dongcarl>Huh! The substitute still doesn't work! Bizzare! <ryanprior>I tried building something with check and rounds the other day and it just completed immediately instead of building anything. lemme try again <mbakke>ryanprior: you'll typically need --no-grafts <civodul>ryanprior: could it be that it just rebuilt the grafted derivation, whereas you were expecting the ungrafted one? <dongcarl>civodul: Very well could be... I'm building on 48 cores, and it seems to trigger things at times <jonsger>the `G_` in our website source code is for translating or? <ryanprior>ah yes that was the issue, now that I run it with no-grafts it's actually building <mbakke>sss2: it's hard to tell what's going on from that error, perhaps a transient (network) issue? <mbakke>sss2: is the error repeatable for you? <mbakke>sss2: can you paste 'guix describe'? <civodul>ryanprior: the two things are unrelated <ryanprior>so if I run `guix build --check --rounds=10 mypkg` Guix is like "ah, he wants to check 10 times whether a graft works" and that's the correct behavior? <cbaines>civodul, turns out the mystery derivation actually just has the inputs jumbled around a bit, the output is identical to the "guix build --no-grafts -d qemu-minimal" derivation *vagrantc somesimtes wonders if --max-jobs=NUMBERCPUS and --cores=1 is more reasonable *dongcarl will be back in 2 mins <mbakke>lle-bout: did you have a chance to do any work towards GCC 10? <mbakke>sss2: can you try disabling the other channels and trying again? I can't reproduce the error. <sss2>i have removed channels.scm, but it does not helped <sss2>i am new to guix, so may ask stupid questions... <mbakke>sss2: removing channels.scm should suffice <mbakke>sss2: do you have any other substitute servers configured? <cbaines>sss2, mbakke that error is very odd: guix pull: error: got unexpected path `hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and' from substituter <cbaines>That's the guix-daemon tripping over a locale hint presumably from the guix substitute script <mbakke>indeed, the error comes from nix/libstore/local-store.cc <mbakke>there were some changes to the daemon recently, possibly related *mbakke haven't restarted their guix-daemons in ages <sss2>any ideas how to fix/workaround it <cbaines>sss2, are you running Guix as a system or another distro? <dongcarl>Oh no I spoke too soon... Still broken... trying --cores=1 <sss2>i am not able to solve my complicated boot scenario with guix yet <cbaines>sss2, I'm pretty sure this is a bug in Guix, but you might be able to work around it by fixing the broken locales <sss2>what exactly i need to fix ? <cbaines>sss2, do you know what guix your guix-daemon is using? It's usually guix from root's profile. <sss2> /root/.guix-profile/bin/guix-daemon <sss2>system-wide guix installation is already broken i think <sss2>linking breakage due to host os update <cbaines>sss2, have you ever run guix pull as root? does /root/.config/guix/current exist? <sss2>yes, i am doing so from time to time <cbaines>sss2, does /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon exist? <jonsger>vagrantc: is guix already on it's way to debian unstable? <sss2>yes /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon <sss2>. /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: symbolic link to /gnu/store/m9g44zk20n2dnfzgfdgfdmbx9rbqrvak-guix-daemon <cbaines>sss2, OK, are you running guix-dameon through some init system (systemd, openrc, ...)? <vagrantc>jonsger: no, stuck on a guile-gnutls dependency <sss2>currently running from systemd <cbaines>sss2, OK, what I'd try is updating your systemd service file <sss2>it's worked fin until yesterday i guess <cbaines>sss2, it's probably here /etc/systemd/system/guix-daemon.service <sss2>not related to service, i have made it by hand during guix initial installation <cbaines>sss2, what I'm suggesting is switching to using guix-daemon at /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon rather than the one installed in root's profile <cbaines>sss2, I'd also add Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <cbaines>sss2, that goes in the [Service] section <cbaines>sss2, ah, you'll probably have to work that in to your existing Environment line <civodul>dongcarl: good! could you email bug-guix, along with the build log you pasted earlier, so we remember to make it #:parallel? #f <sss2>understood, few minutes.... <dongcarl>civodul: Unfortunately the #:parallel? #f didn't fix it... <dongcarl>I'm a bit stumped how this seems to work on everyone else's system <dongcarl>Will upload a full log to the original bug tho <sss2>yes, i have applyed changes ) <cbaines>sss2, I'd double check the guix-daemon is definatly running from /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon now <sss2>yes, it os, but it still failing to see locales <sss2>дек 11 00:31:50 sss-desktop guix-daemon[20427]: guile: warning: failed to install locale <dongcarl>sss2: did you set GUIX_LOCPATH for the daemon? <cbaines>sss2, that seems like a different issue now though? Do you get the same error when doing guix pull? <sss2>but looks like it does not have effect <sss2>i will check if locale path exists, minute <sss2>do we have some way to check current environment of guix daemon ? <apteryx>is anyone else using Geeqie as a picture viewer? <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, mbakke says: I saw you had done some work towards bootstrapping Rust 1.29 directly, do you still have that patch around? <cbaines>sss2, if you can guix pull now, I'd try doing that as root, and then restart your guix-daemon process <mbakke>sss2: also try 'guix install glibc-utf8-locales' (as root) <sss2>mbakke, already done (when i first swa this weird error) <sss2>but guix daemon seems still does not see locales ( <mbakke>sss2: actually, if your user locale is ru, as it seems to be, it should be 'guix install glibc-locales' (without the utf8) <sss2>i have forced us locale for service <sss2>also, error seems saying what locale path is not accessible <sss2>if i deciphered it properly <cbaines>sss2, ah, so guix pull still isn't working. <cbaines>I was confused if that was still the error you were getting <sss2>is here any othe way to tell guix-daemon where to search for locales ? <cbaines>sss2, so I believe you have locales for glibc 2.31 <cbaines>sss2, what do you get if you run this as root: guix size guix | grep glibc <cbaines>sss2, you need to follow the guix symlink in root's $PATH to find the /gnu/store/... entry <cbaines>then run guix size on that, and look for the glibc version mentioned <cbaines>I think that'll tell you if the locales you have are compatible with the glibc version <mbakke>I thought these locale issues were solved with recent guix-daemons <cbaines>sss2, so run guix size /gnu/store/24qbpkwbhw0sbax3m7cgz5lxp1l4dl9v-guix-command | grep glibc <sss2>looks like it is made even worse ) <mbakke>ah, it's only solved for users that happen to use one of the locales in 'glibc-utf8-locales' <sss2>looks like working now, thx all for help <mbakke>still a terrible bug and failure mode, thanks for the report :) <cbaines>sss2, I'm glad you've got it working :) <mbakke>I'm not able to reproduce that error by changing to an invalid locale on an old daemon <mbakke>on a newer daemon, I'm getting SELinux troubles that don't show up in the audit log, hmm <apteryx>mbakke: I just rebased what I had for the mrust bootstrap on top of current core-updates and sent an attached patch to the issue 38110. <cbaines>mbakke, is the the locale that the old daemon is running that you're changing? <mbakke>cbaines: the daemon locale in guix-daemon.service <mbakke>I'm getting some nasty warnings, but at least 'guix pull' completes <cbaines>I guess there's the version of the guix-daemon in play, and also whatever guix it finds to do the substitute queries, I don't know if that's fixed? <mbakke>huh, guix-daemon works like a charm without LC_ALL in the environment <mbakke>(old daemon at beba9ff82123c4a82721b2ed14df2c7576e22e85) <mbakke>db48x`: have you upgraded your guix-daemon recently? :) <pineapples>While I'm still here: any thoughts on adding the lvm2 and git-minimal packages to the installation ISO? Now that we support LVM configuration in Guix, the former should definitely land in it; as for the latter, it'd be just very nice to have. <civodul>it's that plus the fact that lex shouldn't be called in the first place i guess, and it gets called because of a parallel build issue i guess? <dongcarl>Still _super_ perplexed why it works on everyone else's machine... This should be reproducible... <mbakke>what the ... I just tried rebooting a RHEL8 machine with Guix, and now I got the same error sss2 reported <mbakke>why did it not show up when just reloading systemd and restarting the daemon, weird <sss2>good what we have found solution for this <rekado>mbakke: the audit log might show it as (x-daemon) or similar. I remember that from when I first worked on the policy. <civodul>dongcarl: but you said --cores=4 fixed it, right? <mbakke>rekado: thanks! I found the issue, somehow audit.log was no longer updating on that system, a reboot fixed the logging.... <dongcarl>civodul: Nope, that didn't work (I spoke too soon) <sunova>Hello. What is the fastest way to learn guile? *dongcarl builds again with --cores=4 to make sure I don't make a bigger fool of myself <rekado>mbakke: huh, so this is where we are now: magic reboot fixes things. If only I could remember where I’ve seen this before… <sss2>reboot to fix things sounds just like windows ... *mbakke tries hard to not make jokes about systemd