IRC channel logs


back to list of logs

<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."
<mbakke>very confusing
<slimjim>any tips on why it's too much work and if anyone started looking at it before?
<mbakke>slimjim: it looks like dustyweb has done some related work in
*civodul -> zZz
<civodul>to be continued!
<dustyweb>ah yes
<dustyweb>civodul just invoked call/cc
<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
<Sharlatan>Hi folks, who's not sleeping yet :)
<slimjim>mbakke: dustyweb: thanks!
<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)
<luhux`>(service avahi-service-type)
<kozo[m]>Thank you
<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
<jeko>Hiii !
<civodul>Hello Guix!
<jeko>civodul: Hey !
<civodul>cbaines: looks like we're missing mothacehe
<civodul>perhaps we'll skip the discussion today?
<cbaines>sure :)
<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>Even though the Cuirass metrics look better I think substitute availability is worse than berlin
<cbaines>which I'm guessing is because of the unreliability you can see when you look at the evaluations
<civodul>oh weird
<civodul>i thought bayfront had more x86_64 substitutes than berlin a few weeks ago?
<cbaines>hmm, I'm unsure, I would guess not
<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 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>vor = or
<civodul>vldn: hi! are you using the installation ISO from ?
<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>could you share the custom config?
<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?
<vldn>via guix install?
<civodul>no, you cannot move /gnu/store manually
<dftxbs3e>cbaines, civodul, rekado: it seems 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>yes, it must be the worker
<rekado>I’ll try to look into this today
<dftxbs3e>no rush - thanks :-)
<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 :-)
<civodul>sounds tricky!
<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
<civodul>hey pineapples
<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
<pineapples>ad of my channel definition. What am I doing wrong?
<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.
<pineapples>Oh. I see where the problem is
<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) ...)
<civodul>does that make sense?
<pineapples>That does. Thank you very much for your help :)
<zzappie>Hello guix!
<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:
<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>nixo_: woow that's awesome!
<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:
<pineapples>html/guix-devel/2020-12/msg00033.html, into, without altering the unattended upgrades service itself too much so that its future revisions wouldn't break my (service unattended-...) definition.
<civodul>pineapples: the 'channels' field expects a gexp, not a file-like object, so you cannot insert such a thing
<pineapples>Understandable. Thanks a lot again! :)
<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>it should be fine
<euandreh`>ty :)
<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
<euandreh`>wow, that was confusing
<efraim>can the keys be shoved into a directory?
<civodul>efraim: i think so
<euandreh`>efraim: is that a .guix-channel config?
<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".
<luis-felipe>Yeah, that works, thanks.
<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
<nalaginrut>hi, folks, does guix support 301/302 redirect?
<civodul>jorge[m]: hay un problema con estas imágenes, discuple las molestias
<civodul>roptat: possibly useful reference for translators: :-)
<nalaginrut>And how can I modify the default url of `guix pull`
<abcdw_>nalaginrut, There are few ways, editing ~/.config/guix/channels.scm file, passing --url or -C parameters:
<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)
<nly>i know, it don't
***stikonas_ is now known as stikonas
<jackhill>nalaginrut: you may also be interesed in
<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
<nalaginrut>jackhill: thanks
<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>i wrote this package:
<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 ?
<kisaja[m]>is openrc a potential feature in guix
<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
<dissoc>but that's no issue
<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>dissoc: ok
*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?
<pinoaffe>unrar doesn't seem to be available
<lfam>pinoaffe: I believe that file-roller can handle some RAR archives
<lfam>Unfortunately unrar is not free software
<lfam>You can see relevant discussion here: <>
<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
<pinoaffe>lfam: thanks for the info!
<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
***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?
<mbakke>sneeky sneek
<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
<civodul>that's from master?
<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?
<cbaines>I'm pretty sure it's not
<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>yes, always
<dongcarl>Got it!
<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" ;-)
<civodul>heh :-)
<dongcarl>If anyone has the time to look into this bug when pulling from a quite-old version of Guix, I'd really appreciate it!
<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?
<sss2>hi all, what wrong here
<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?
<dongcarl>civodul: Interestingly, I did not!
<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...
<dongcarl>I'll try restarting the daemon...
<civodul>ah ha, those locale warnings...
<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>(trying --check now)
<civodul>you could try with "-c 1" to see
<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?
<ryanprior>why does check not imply no-grafts
<sss2>on all machines
<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>how can i do it ?
<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
<sss2>it does not
<mbakke>sss2: do you have any other substitute servers configured?
*dongcarl back
<sss2>i guess not
<sss2>how to check it
<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
<dongcarl>civodul: --cores=4 fixed it!
<mbakke>indeed, the error comes from nix/libstore/
<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?
<sss2>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>how ?
<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
<sss2>this error is from root
<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
<sss2>without sandboxing
<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
<sss2>ah, ok
<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
<jonsger>sss2: which distro are you using
<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>jonsger, exherbo
<sss2>nope, still failing
<sss2>yes, i have applyed changes )
<civodul>dongcarl: weird
<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>looks correct
<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>cbaines, rechecking
<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
<sss2>looks like
<sss2>is it wrong ?
<cbaines>sss2, what do you get if you run this as root: guix size guix | grep glibc
<cbaines>actually, that's a bad suggestion
<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
<sss2>do not get it
<sss2>what next ?
<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>i see typo
<sss2>in environment ...
<mbakke>ah yes, should be en_US
<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.
<mbakke>apteryx: excellent, thanks!
<cbaines>mbakke, is the the locale that the old daemon is running that you're changing?
<cbaines>or the client locale
<mbakke>cbaines: the daemon locale in guix-daemon.service
<mbakke>I'm getting some nasty warnings, but at least 'guix pull' completes
<cbaines>mbakke, hmm, that wasn't the original cause, see
<mbakke>oh right
<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>well, "old"
<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.
<dongcarl>civodul: I think this is the culprit:;h=3d961d0d3a797b4d463024a11131e96c213dee27
<civodul>dongcarl: good catch!
<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>civodul: Don't think so, I tried building with cores=1 and it still didn't work... The breakdown is here:
<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>oh, I still had the locale typo
<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
<sss2>at lease workaround
<rekado>mbakke: the audit log might show it as (x-daemon) or similar. I remember that from when I first worked on the policy.
<mbakke>sss2: I filed a bug report:
<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....
<mbakke>so much for "stable" distro :)
<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
<dongcarl>sunova: I recommend #guile
<sunova>dongcarl: tnx
*civodul -> zZz
<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