IRC channel logs
back to list of logs
<nckx>Depending on your ‘learning style’ (ralph) it might help just to bust out a REPL and try a few things. <unmatched-paren>I *think* it might be possible to define (begin ...) in terms of (let () ...)? <nckx>This is all very Scheme. <kabouik>I think I kind of understand what When serves, but since this is all new and very different to everything I know, and since the little I know I learnt myself in small steps as a simple Linux user (not programmer), I'm just bumping my forehead real hard at the Guile learning curve. <kabouik>I was quite happy to even be able to get that .scm to build (with a lot of help), but the formatting conventions for the tests phase that I can't read better before or after it's formatted, that's beyond my current level :< <unmatched-paren>kabouik: Would it help if I explained it with a hypothetical C-like syntax? <kabouik>Nope, you'd have to make it R. Good luck. :P <nckx>Scheme is not a complicated language. It helps to remember that. It can be made to look complicated and do things as complex as any language, but you should always be able to see the underlying primitives if you peer hard enough. (Something which I sorely miss in, say, Haskell.) <kabouik>I don't think R shares any common ground with common lisp really <kabouik>R is designed to manipulate data, analyze and build graphics, it's not fast and not programmable like common lisp. But it's easy to understand. You have functions, which take arguments. And when you bump into a new function that you might need, you can just type ?thatfunction to show its help, which arguments it takes, and possibly an example. This really helps improving discoverability. I miss that with Lisp, but I know it <kabouik>actually is superior to R, the latter being a bit trivial and not as potent as lisp. I mean, you wouldn't write complex software with R. <kabouik>Oh, I thought Scheme and Guile were both under the broader group of Common Lisp, misconception probably <drakonis>guile is a scheme implementation slash dialect <nckx>s/Common // and basically true. There are part of the Lisp family. <nckx>‘Common Lisp’ is a leaf on the family tree. <nckx>In fact, Common Lisp (maximalist, Stardardised™, enterprisey) is probably the most distant relative of Scheme (minimal, ‘elegant’ in the eyes of its many lovers). <nckx>(Both are stereotypes of course.) <nckx>Did you finish your lambda* yet? <kabouik>Being in #guix and #nyxt channels gives me all sorts of contradicting signs on what Lisp language is the best :p <nckx>Hey, I said nothing about that :) <nckx>They are just the two most different, I think. <kabouik>No group is talking in a bad way about the other language, don't get me wrong, but of course preferences are not the same <civodul>kabouik: there's only one correct answer though *kabouik checks if civodul is in #nyxt. <kabouik>Not yet nckx. I was thinking `(lambda* (#:key tests? #:allow-other-keys) (when tests? (invole "ctest" "--output-on-failure"))`, but I may as well just play Euromillion <kabouik>I just merged what both of you said above, and luckily each one of you took one pair of brackets so that made it easier for me to merge <kabouik>You all better install nmail and use it <nckx>It's really just (FUNCTION (ARGUMENTS [oh and ignore arguments you don't recognise]) BODY). <nckx>And BODY is just ‘when tests, then invoke tests’. <nckx>It's not as complex as it might look. <nckx>You wouldn't write it all on one line in a file, which also helps. <kabouik>No need for aerc anymore unmatched-paren, it was decided nmail is mandatory now. <kabouik>> (FUNCTION (ARGUMENTS... This actually is one of the major roadblocks for me, and also why I mentioned how ?somefunction in R really helped me learn it. In Scheme, or Lisp in general in fact, I look at words but don't know when they're arguments or functions, and when they're a function, how many arguments they take. I imagine I need to go check in the source code each time, or functions defined above, but it's not the natural <nckx>But I didn't read every single line in the convo, it is true. <kabouik>unmatched-paren said my lambda part was right, and you posted just above the when tests? part. I just concatenated them <nckx>Soon you'll find this trivial to write and understand. <nckx>Promise (if you stick with it, at least). <nckx>It is after all a teaching language. <kabouik>Hope so. I'm commited and genuinely want to embrace the Guix way, but it's not trivial for non-programmers, I think. I also hope I'm not bothering you too much; the channel has been flooded by my first world issues since a few days (and you all showed a lot of patience, thank you). <kabouik>Speaking of, I just found out about the qemi-binfmt service, and this looks very useful. <drakonis>to be fair, if it is broken, then it is worth fixing it? <drakonis>it doesnt seem like it has anything that could've broken it <pashencija[m]>With `checking for options to compile assembly... configure: error: could not compile assembly` <nckx>kabouik: It is! It's quite magical to be able to build (and run) foreign-architecture packages with such ease. <kabouik>Does that work the other way around too nckx, i.e., running x64 builds on arm machines? <pashencija[m]>drakonis: And I also cannot understand how to disable it entirely in my image. Is that possible? <nckx>What's x64? It sounds familiar but I can't place it. There is no direction, so yes, it works any->any as long as QEMU supports it kabouik. <nckx>It's Microsoft for x86_64 isn't it. <kabouik>Oh, it's a Microsoft short? I didn't know. <nckx>Not that it matters, but x86_64 is a lot more common & familiar here I think. <nckx>The whole ‘64-bit x86’ (and even ‘x86’ itself) naming is a mess anyway, so it doesn't really matter. <kabouik>That's what I usually use, just started using x64 consistently since not more than a couple weeks actually, because I was using it a lot and got tired of the long name. I thought they were exact synonyms. <drakonis>pashencija[m]: i'm reading that patch wrong <nckx>They probably are. ‘x64’ just wasn't familiar. <drakonis>anyways, the patches really werent tested for arm <nckx>And since you were speaking of ARM, of which I know little, it was possible that it was an ARM thing. <drakonis>if you could write patches to fix it, it would be quite nice <pashencija[m]>I just don't understand why is grub built on a non-grub image <nckx>Is there no CI job that would have caught this if the CI hadn't been on summer holiday? <drakonis>it'd help if you posted the image config somewhere <pashencija[m]>It's actually must be affecting any aarch64 systems, not just this one <drakonis>pashencija[m]: highly suspect that it is the presence <drakonis>of grub-efi32 in the image root initializer <pashencija[m]>I need to test an important patchset we were going to upstream <kabouik>Do I understand right that I shouldn't just paste my nmail.scm into gnu/packages/mail.scm, but just the `(define-public …)`, and then just add the missing #:use-module at the top, if any? <kabouik>And copyrights are just for the core team I assume <vagrantc>(though what is considered copyrightable may not exactly be absolutely clear) <vagrantc>e.g. bumping a version number and corresponding hash isn't exactly creative expression :) <vagrantc>but writing a package descriptiong or synopsis, definitely <kabouik>You'd consider a package is creative content? I was not even putting packages in that category <vagrantc>a guix package definition is code ... although a boilerplate package maybe not if it was programatically created <kabouik>In my example I think the real work was done by IRC and the dev who wrote the sources (but they're in the License already) <kabouik>If packagers are in the copyright, I shall add myself; I wouldn't mind at all being wiped from it either. <vagrantc>comments describing the thing, certainly <kabouik>So basically any form of creation deemed relevant by the core team that merges patches. <vagrantc>anything you write creatively is generally covered by copyright in (many? most?) jurisdictions <kabouik>If I somehow manage to smuggle a smiley in mail.scm, and claim it's mine, I should get a copyright line? :P <kabouik>Do you folks have a routine for checking modules, sorting them alphabetically, and removing duplicates? I would expect emacs to do some magic there. <kabouik>I can do the first two parts with kakoune but I'm not sure about duplicates. *vagrantc so wishes guix had a convention of sorting package definitions alphabetically <kabouik>I expect all the modules I needed for the package to be there already <kabouik> (guix build-system go) seems to be duplicated (before my commit) already <vagrantc>kabouik: good luck and have fun, gotta go <kabouik>On the other hand the addition of modules there is very error prone <efraim>I have a fix for grub-efi32 on aarch64 <pashencija[m]>Does it fix the problem with package that's not building or does it allow to build an image without grub? <efraim>it fixes the problem with building <pashencija[m]>If you're not willing to submit the patch, could you please at least send it to me so I use it here? <pashencija[m]>Is there a reason this package is built on non-grub systems? Is this intended? <kabouik>The git send-email is giving me trouble. I added the smtp and credential (except password) settings in ~/.gitconfig, but send-email doesn't ask for my password after I confirm I want to send the email. <pkill9>anyone know why pcsxr package fails to build? <Guest85>Hi all, I was trying to build llvm on guix with some modifications using `guix build llvm --with-source=./path/to/local/source` but I got a message saying that the `with-source` option has no effect on the llvm package. Anyone know why that would be? <nckx>Guest85: --with-source=llvm=… <nckx>pkill9: Apart from the linker error (missing -fcommon?), $something is pulling in pango headers which then try to include a harfbuzz header (#include <hb.h>) which of course fails. <yewscion>Hello all, I think I did a bad. I just sent a patch series to firstname.lastname@example.org, but from the email responses it looks like it may have created an individual issue for each patch in the series. <yewscion>If this is the case, I apologize. I should have sent an informative email first, and then the patch series once the issue was created, and will do so in the future. <yewscion>Yup, looks like it did indeed create 5 separate issues (56989-56993). Again, my apologies. Should I create a sixth issue in the correct way and trash the rest? <iyzsong>yewscion: i'd say no need to create another one, but that if you like to, then it's okay too, it's a common thing so don't bother with it so much :) <yewscion>iyzsong: Okay, I'll wait until it becomes clear it's necessary. Thanks for the reassurance! <yewscion>Thank for for the link! I somehow hadn't come across that. <yewscion>Weird tangentially-related packaging question: Does anyone know how I might avoid redefining a function used inside of another build system? I am looking to solve the non-determinism in one of the above-submitted packages (dbqn), and per https://github.com/dzaima/BQN/issues/14 it seems the issue is timestamps in jarfiles, which ant-build-system handles in its strip-jar-timestamps procedure. <yewscion>Can I use that procedure without using ant-build-system to build the package? Or should I just copy and paste the code into the module with my new package? <lilyp>yewscion: "...without ant-build-system" not really. What you'd typically do is import the relevant module and then use the phase from there. You can do this regardless of the build-system of the package, though, which is probably what you were asking for <yewscion>lilyp: But the issue I'm having is that this particular procedure is not public (it's a define*). Is there a similar mechanism to double colon (::) in common lisp in Guile Scheme, that lets You access a module's private symbols? <lilyp>you probably don't need to, you can access it by %standard-phases <lilyp>but sure, @@ and module-ref (with the module rather than the interface) do that <yewscion>lilyp: Thanks! I'll read up on those two mechanisms for Guile. That said, I guess I just wasn't familiar with how %standard-phases is populated within a package. I thought it would be the standard phases for the declared build system, not an amalgam of all of the build system modules listed in use-modules. <lilyp>Well, I don't think there would be a procedure to set jar timestamps without a phase that uses it. <yewscion>lilyp: There is, in ant-build-system. But my package uses gnu-build-system. <yewscion>I must be missing something, sorry. I've added #:use-modules (guix build ant-build-system) to the module declaration, and I've added (write %standard-phases) to a phase in the package in question, and it doesn't seem to be in there. <lilyp>Because #:use-modules is for the defining module, not the package. Packages have a #:modules and #:imported-modules argument <yewscion>lilyp: Is there documentation for these arguments anywhere? I've looked at some other packages, but the closest I've come to understanding what I'm looking at is getting my package to ask me to manually add each module gnu-build-system depends on to #:imported-modules. <lilyp>There should be a variable %gnu-build-system modules that you can simply splice via ,@ <lilyp>similar for other build systems <lilyp>IIRC every package that does that should ,@ it'd be weird if you found one that doesn't <lilyp>But for a humorous and simple example, see shakespeare-spl in esolangs. <yewscion>Copy that, will do! Thank You for all Your help! <vivien>Dear guix, is it OK if I fix perl for mingw to use cmd.exe instead of bash? <civodul>vivien: you'd have to do it in a way that doesn't trigger a world rebuild <vivien>civodul, I mean, what is bash used for in perl? Spawning processes? In that case maybe cmd.exe is enough. Does it need to handle file redirections? Then cmd.exe is not enough. It depends on how the shell is used by perl at run-time, and I don’t know much about perl. <vivien>Hey, visual c++ build for perl defines the shell to be "cmd /x /c" by default <civodul>vivien: dunno, you'd have to check exactly how Perl uses Bash <civodul>then again, the choice between cmd.exe and bash is maybe something better left to Perl developers? <vivien>I would like to hear about the issue from a perl point of view <vivien>But if perl devs thought cmd was good enough when building with visual c++, then maybe it is good enough for us <kabouik>Any user of dwservice (https://www.dwservice.net/en/applications.html) on Guix? It's a really convenient alternative to proprietary things like TeamViewer and other remote desktop solutions that work on WAN without a static public IP (machine are agglomerated under an account, so you don't need to know their current IP to contact them); or for one-time connections using throwable credentials. <kabouik>I'd be interested in getting it packaged but I'm not ready for that kind of complexity yet I'm afraid. <unmatched-paren>kabouik: It could be a good way to learn to write a service, but yes, it would probably be too complex at this early stage <kabouik>I already tried the agent on my Guix machine to use it as host, without installation (the agent can either be installed or run temporarily) and it works, screensharing was not working though but I could still access other applications like shell, file manager, resources, etc. It's under MPLv2 license (https://github.com/dwservice/agent) <kabouik>Thanks unmatched-paren. In the end it just worked some time later without changing my settings; I suspect git send-email was keeping in cache some wrong setting I may have tried first from CLI, or a smtp server hiccup. <kabouik>Oh but you're using disroot too, that makes your config even more interesting because I thought that was my issue last night <kabouik>Re "I already tried the agent on my Guix machine to use it as host, without installation": the installation itself does not work, presumably mostly because dwagent expects the usual file structure. But I found it intersting that just running it was mostly working, with the exception of screen sharing (again probably just because the required lib is not where it expects it). <unmatched-paren>AwesomeAdam54321: admin.scm is basically random-stuff.scm :) so probably <AwesomeAdam54321>I'm currently trying to package GNU Kart, but when the build process tries to #include SDL_image.h, SDL_image.h says it can't find SDL.h: <AwesomeAdam54321>/gnu/store/k7y6i2v5qfm161zf88ynp5amk92ylpqc-sdl-image-1.2.12/include/SDL/SDL_image.h:27:10: fatal error: SDL.h: No such file or directory <AwesomeAdam54321>hmm, if I don't pass CFLAGS+=-lm to make it provides the SDL directory as a search path again <AwesomeAdam54321>Is guix planned to be used to produce bit-for-bit reproducible tarballs for GNU projects, like GCC? <nckx>‘-I’ in CFLAGS is hella sus. <nckx>The backtrace doesn't look that useful to me, but I'll post it to the bug report if you think it is. <unmatched-paren>nckx: The last stable release was in 2010, so it's not entirely surprising <nckx>They honour both LDFLAGS & CPPFLAGS though. <nckx>Meaning there's no need to clobber CFLAGS. <nckx>Heh. I didn't… no… let's not. <nckx>I just mean the WIP package above clobbers CFLAGS (deleting -O2 -g). Even though it's not to blame for this segfault, it's a bad idea to drop upstream's CFLAGS. <nckx>They sometimes know what they're doing. <nckx>unmatched-paren: Uhm, you're deleting all upstream CFLAGS. <unmatched-paren>Well, maybe it is to blame! Optimization does strange things sometimes <nckx>Not doing so is not pointless :) <nckx>Alas, no, since I tried that. <unmatched-paren>Maybe we should try the latest non-rewrite bzr rev. Do we have bazaar-fetch stuff? <nckx>But keeps that sweet -O2 so it segfaults faster, probably. <unmatched-paren>I suppose you do need a *very* good reason to do a complete rewrite :) <nckx>Oh, we have a bzr fetcher. <nckx>I think nginx uses bzr, for one. <nckx>But I should be working and this is not working. I'll pop in later to see progress! <unmatched-paren>But we shouldn't try to bzr-fetch the latest commit, because that seems to be part of the complete rewrite. <unmatched-paren>Oh, hmm. Looks like the non-rewrite game isn't that far on in development either: <unmatched-paren>There are currently three characters that have a (incomplete) 3D model to them: GNU, guile, and icecat. <unmatched-paren>You have to run it from the command line and it only lets you go through one lap and then quits, but the computer characters will drive around the track nicely.
***civodul` is now known as civodul
<kabouik>Hey unmatched-paren, thanks for the reply! Did you drop libetpan from the list of inputs on purpose, or did it just slip when you ordered them alphabetically?
***wielaard is now known as mjw
<apteryx>I'm still a bit rusty when it comes to reporting errors in Guix; on the user side, should I raise an error via format-error, or prefere 'leave' when encountering a fatal error? <apteryx>I'd normally use 'leave', but for what I'm doing it seems perhaps easier to unit test if it's using format-error, as I can catch and match the message to something expected <Cairn>So I was yapping about terminus a couple weeks ago. Turns out the package does build the otb version. <Cairn>I'm confused though: why can't my system see it? Do I need to configure the package for it to be added? <unmatched-paren>When I install a font it just appears, though I think guix home does something with fontconfig <Cairn>Well, the pcf versions of the font appeared with no issue <Cairn>idk, that's the verbage unmatched-paren used <Cairn>When I do fc-list I only see the pcf versions <nckx>Cairn: I think you forgot to install the :otb output. <nckx>I.e. ran ‘guix install font-terminus’ instead of ‘guix install font-terminus:otb’. <gnucode>unmatched-paren: I don't know if you noticed, but I sent a patch for that debbugs-my-open-bugs to guix-pathches. bug 56987 <Cairn>nckx: That explains it. Thank you <shcv[m]>what's the recommended way for updating a really old guix install that can't complete a `guix pull`? <unmatched-paren>shcv[m]: I'm not sure whether this will do it, but maybe try `guix time-machine -- pull` if it has time-machine <yuu[m]>shcv: guix system init /mnt/etc/config.scm /mnt? <yuu[m]>unmatched-paren: well, you'd completely reinstall it ig maybe with a live iso <shcv[m]>I was thinking there might be a way to run the reconfigure from a checkout of the guix repo <shcv[m]>using pre-inst-env or whatever the script was <shcv[m]>but I'll try the time-machine idea first to see how magical the time machine is :P <shcv[m]>but yeah, my previous pull was ~520 days ago, with 24k new commits :D <rekado_>I’m older than 3 years, and I use Guix. <shcv[m]>sadly, time-machine was insufficient <AwesomeAdam54321>shcv[m]: Can you time machine 6 months into the future from your previous guix pull and guix pull that way? <shcv[m]>yeah, I need to do something like that; I can't even build guix from source with the current guix I have 😢 <shcv[m]>is there a way to pull a tag or something? maybe I could update to the minor version tags <shcv[m]>I just looked up the commit hash for 1.3.0 and the pull for that seems to be working <shcv[m]>hopefully that one can take me the rest of the way <Cairn>On ci.guix.gnu.org, there's a little dropdown on the right that says of each spec that says "Edit" and "Deactivate" <Cairn>Are people supposed to have access to that? <efraim>you need to be authenticated to actually use the buttons, so it's not a problem <yuu[m]><shcv[m]> "yeah, I need to do something..." <- reproducibility at its best. iirc nix/nixos also has such issues <unwox>hi. do you know if it's possible to use "home-channels-service-type" and import modules from custom channels in one "guix home reconfigure" command? if not then how this service is supposed to be used? currently while installing new system i manually copy channels.scm from dotfiles to ~/.config/guix, but i'd like to automate this step using guix tool
***Dynom_ is now known as Guest7377
***mark_ is now known as mjw
<atka>hi guix, are there any gotchas running non guix software (not nonguix) eg. app images, tarballs etc? <atka>basically stuff not pulled by the package manager <vagrantc>it if depends on files in /lib or /usr/lib or such, it just won't work <atka>ok, gotcha, thanks. how's the honeycomb? <atka>last I heard you had debian booted but thats all <atka>oh cool, that would be graet <vagrantc>atka: haven't done too much else with it ... lots of other things going on <atka>I hear you, I've been busy as hell too <podiki[m]>needs some rewrite/tests, but functionally is set I think <podiki[m]>there was also a discussion on guix-devel that I think had some examples of usage <podiki[m]>or feel free to ask me here (it is my patchset and I do use the fhs container) <PotentialUser-58>Hello, I have a build error installing rust-cargo. In log of the build I have this line: <blake2b>is there a good way to hack guile on checkout, the way we do with guix? <blake2b>I've fixed a bug and want to do some tests, but running ./libguile/guile won't boot from the repo, and I didn't run "make install" because I don't want to cause a namespec collision <Cairn>Does anyone know if configuring fontconfig changes the output of fc-list? Like, if I set antialiasing to true in my config, are the fonts that have antialiasing disabled supposed to say true instead? <Cairn>Or do I have to just rely on knowing that I've changed the setting <nckx>Cairn: If you are able to edit and deactivate CI things, please let us know 😉 <nckx>Oh, I didn't mean you had to expend $effort. <Cairn>No I just get 403s when I try to change anything <nckx>Cairn: <fc-list> Not as I understand it. <Cairn>I can't get the config to work I guess <blake2b>the error I get is: "Pre-boot error; key: misc-error, args: ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f)Aborted" <blake2b>I don't know if perhaps the libguile directory is not the place to run it from... it seems to be, from poking around <PotentialUser-58>Could someone try `guix shell rust-cargo`. Are you able to successfully install it? <blake2b>PotentialUser-58: cargo is installed as a separate output <blake2b>not sure why there is a rust-cargo in there tbh <nckx>Cairn: What I've noticed (but not investigated) is that fontconfig won't load anything from conf.d (*despite* printing ‘Scanning’ when FC_DEBUG=1024 is set!) but loads a fonts.conf in the same location just fine. <davidl>nckx: hi, any estimate on when the bash-bcu patch will get merged? <nckx>I'm waiting for a reply to a question about it. <nckx>I was tempted to push the dependencies, which are ready, but they make little sense without the bcu. <Cairn>nckx: Interesting. I'm using a fonts.conf file though. Probably user error. <Cairn>I just wish Terminus has larger sizes. I'm gonna make my own version someday I guess. <davidl>ok! I was just nervous things will be forgotten about, but seems like they aren't :-) <blake2b>Cairn: I know this is obvious, but just to check, did you source your profile? <nckx>blake2b: Interesting (not obvious :), could you explain? <nckx>davidl: I don't think I'll forget about BCU until the day I die. And even then. <blake2b>yeah sure, maybe "source" isn't the correct terminology <efraim>bayfront has more aarch64 substitutes than berlin does <blake2b>but the good ol' GUIX_PROFILE=/home/user/.guix-profile <pashencija[m]>efraim: I don't understand you. Do I need to enable it in my system? <efraim>pashencija[m]: you want to make sure you have #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F# in your /etc/guix/acl file <blake2b>Cairn: if you haven't run that, try it. it sets your environment variables <efraim>if you don't have an /etc/guix/acl at all then you won't get any substitutes <blake2b>(the period is just shorthand for "source", which is why I asked if you "sourced" your profile) <nckx>blake2b: I'm just curious how that affects fontconfig config… er… uration. <nckx>(Genuinely, having had less than stellar results with it in the past.) <nckx>I find it very odd that fonts.conf works fine here but conf.d doesn't. The kind of odd that random environment variables like to explain. <efraim>from the root of the guix repository you can run `sudo guix archive --authorize < etc/substitutes/berlin.guix.gnu.org` and `sudo guix archive --authorize < etc/substitutes/bordaux.guix.gnu.org` <davidl>nckx: alright ^^ even though Im not sure I fully understand what u mean by that. <blake2b>nckx: I was just scrolling through the earlier conversation, and saw something about "the system not knowing where something is", so I thought this is the obvious first remedy in case missing envars are the issue <blake2b>Cairn: if you're using Guix Home it would be "source /home/user/.guix-home/profile/etc/profile" <nckx>There are duplicate keys under etc/substitutes/ and ‘guix archive’ doesn't deduplicate the ACL, so yours will now contain duplicate entries, which is harmless but now you know. <nckx>There should be nothing to refresh. <nckx>You can purge the substitute cache with something like ‘sudo rm -rf /var/guix/substitute/cache/* ~/.cache/guix/substitute/*’ but I do not believe that authorisation status is cached. Still, can't hurt. <nckx>Very strange, as I do get substitutes for ‘guix build --system=aarch64-linux nano’. <nckx>From bordeaux.guix.gnu.org. <nckx>guix build --system=aarch64-linux nano -d → /gnu/store/0phfpqyqszax6rbnan288343mdhxdzfd-nano-6.4.drv by the way. <Cairn>blake2b: Sorry, just got back. As far as I can tell, fontconfig only needs to know the $XDG_CONFIG_HOME. And I just put my little test config in `~/.config/fontconfig/fonts.conf` which should be the right path <shcv[m]>why does `guix shell --search-paths` still take ~4s even when it should be using a cached profile? <Cairn>blake2b: I'm not using Guix Home btw. I'm not doing anything particularly Guixy right yet <pkill9>has any progress been made on adding KDE desktop environment? <pashencija[m]>Well, I have packaged some apps and libs in my repo, but there's long way of upstreaming them <blake2b>Cairn: ah ok, well in case there is a missing environment variable you're unaware of, its worth a try. it certainly wouldn't hurt anything.