<DynastyMic>Do any of you know why IceCat is not rendering numbers in EXWM?
<leoprikler>not sure if specific to EXWM, but a lot of users report icecat missing fonts
<leoprikler>you'd need to install a font with good glyph coverage and then refresh the fc-cache
*leoprikler reported the lp stuff, now going to bed.
***iyzsong-- is now known as iyzsong-w
<sundbry>Hey guix friends i have a novel new go-download method for Guix. It implements `go get` to download all of the transitive dependencies of a go project. I am not sure if it is worth submitting as a patch since golang dependencies are inherently unstable. The hashes are subject to change at any time because golang dependencies always point at "master" so a commit on any single project can throw the go-get-download method hash
<sturm>I've just installed a new Guix System, but after running `guix pull` and `reconfigure` as root, running `guix describe` complains "guix describe: error: failed to determine origin" - any thoughts?
<efraim>sturm: what's the output from 'which guix'
<leoprikler>sundbry: I don't think moving tarballs and unstable hashes will do you any favor. Guix also has a rather firm stance against bundled libraries.
***sorki is now known as srk
<sundbry>leoprikler: I figured as much. I suppose it might be more useful if it was ported into a tool that extracts the dependencies from the go package and then bundles packages for each of the dependencies individually? I have heard there is such a tool for ruby deps that generates guix packages for dependencies?
<sundbry>I would like to eventually take the same approach for npm + maven as well, since I am building some polyglot apps on guix using all of these languages.
<civodul>anyway, i think (hope?) it was a transient failure
<civodul>problem is that guix-publish doesn't stop when the connection the guix-daemon is broken
<abcdw>civodul: Seems search-paths works in following way. If defined for a packageA then guix environment --ad-hoc packageA will autmatically set respective environment variables to paths relative to this environment's profile.
<mothacehe>civodul: I agree about the transient failure, yesterday I had to restart the guix-daemon multiple times because evaluations where stuck, maybe it's the cause
<mothacehe>but I also think guix-publish should stop when the connection is lost
<roptat>and guix substitutes should not crash when receiving a 500 :)
<civodul>roptat: it's like asking for a licence on the GPL
<civodul>mothacehe: "herd restart guix-daemon" restarts everything that depends on it, including guix-publish, but if guix-daemon restarts independently (as in "killall guix-daemon"), we can end up in that situation
<civodul>apteryx: in the for-each at the bottom, i left the message unchanged
<civodul>so it says "phase failed" but then keeps going
***sneek_ is now known as sneek
<morgansmith>so I'm packaging a packet that has a few origins in its input. This works great as I can just point it to the folder for it to find the files. However, on one of my origins I added a little substitute snippet that I needed. Suddenly my origin was built in the store as a tar.xz and now everything is ruined :/. I think my woes are possibly caused by the patch-and-repack function at guix/packages.scm:583.
<ekaitz[m]>I just read the article morgansmith sent me, pretty clear and straight to the point, but it makes me wonder: why don't we provide those configurations as part of the packages?
<ekaitz[m]>some packages provide udev rules, others provide their own configuration files, desktop files... why do users need to configure their own user services from scratch if the package is know to run as a service?
<apteryx>morgansmith: it doesn't get rid of the repacking though; I considered it but the gexp would need to know the file name ahead of time, which is currently done after unpacking... Not impossible but need to be refactored.
<dustyweb>mroh: I can get my patches to the list, one sec
<dustyweb>(sadly the blender update didn't fix my graphics issues)
<dongcarl>Hey all, any way to figure out how many workers my guix-daemon has in a script?
<doctor_rodik>Hi! I wanted to add Hunspell dictionary for Russian to packages, but found a number of places where dictionaries are declared: gnu/packages/aspell.scm, gnu/packages/libreoffice.scm, gnu/packages/hunspell.scm (dictionary for Italian). What is preferred place? It seems to me that libreoffice.scm is the most suitable one, as Russian hunspell dictionaly I want to add originates from Libreoffice.
<Ikosit>ekaitz: Such a server would be better placed in the guix-home-manager
<Ikosit>ekaitz: You may also want to look how the redshift deamon is defined in home-manager
<jgart[m]>what is preventing guix-home-manager from being packaged upstream? Is there a way to simplify the installation of guix-home-manager so that it could be installed similarly to nix's home-manager?
<roptat>jgart[m], the way it works, it wouldn't be "packaged", it would be integrated :)
<roptat>i think I need to re-work the definition of services, then the system and the home-manager could both use the same service types
<roptat>or at least share most of their infrastructure
<ekaitz[m]><Ikosit "ekaitz: Such a server would be b"> Interesting! should be solved with that for sure
<apteryx>is there something different between the copy-build-system and the gnu-build-system w.r.t. what inputs end up in %build-inputs?
<andre_>hello, i'm really new to this whole guix and scheme concept (and guix system in general). I'm trying to reconfigure my system to enable printing and when i try to `sudo guix reconfigure /etc/config.scm` i get the following error: guix system: error: the following groups appear more than once: scanner lp
<andre_>i've added "lp" to supplementary-groups of my user
<andre_>the first reconfigure worked... now it seems it doesn't work because i'm in the lp group already?
<Sharlatan>I have intersting question on how to pack CommonLisp package which requires forign-library?
<lfam>andre_: We were dealing with this bug yesterday, but I think the error was changed to a warning so that nothing would be blocked. When is the last time you did `guix pull`? What is the commit from `guix describe`?
<andre_>The Commit is b8c3fa315a4140524d71bb12961ac83f300f1e17
<civodul>i didn't follow anything over the past week or so
<lfam>civodul: Based on "manual testing", it's working well on x86_64 and aarch64. I consider these to be the important platforms. However, Cuirass keeps having major problems building things, with many failures that can't be reproduced locally. So, the branch seems to be okay, but substitute availability is poor
<lfam>For example, it seems that all SBCL / Common Lisp packages fail to build on aarch64 on berlin, but efraim was able to build them fine on his hardware
<civodul>lfam: did you try "guix weather -c 10 -s aarch64-linux" and similar to see what the major blockers are on these other arches?
<apteryx>phew! docbook-utils building the doc of fontconfig. What a rabbit hole that was.
<civodul>aecepoglu[m]: even nicer is to use (local-file "/path/to/file-or-directory")
<aecepoglu[m]>I was reading up on "local-file" but felt like its usage wouldn't be this trivial.
<aecepoglu[m]>because I couldn't wrap my head around g-expressions yet
<apteryx>rekado_: I've managed to have composable texlive trees without unions! Made possible via kpathsea brace expansion and good defaults in our texmf.cnf config (shipped with our texlive-bin package).
<lfam>Substitute availability for the staging branch, compared to the master branch, ranges between 58% (armhf) and 86% (x86_64)
<lfam>Absolute values, for example, 51% availablity for armhf on master vs 30% availability on staging