<SeerLite[m]>f1refly: I had to install lxappearance and my themes in my system configuration so it could see them. It's still kinda glitchy though, it seems to "forget" what my theme is whenever I launch it, but it applies the theme fine otherwise
<fnstudio>hi there! i'm in the process of setting up a personal guix channel and i'm working on the authentication part (adding my key to the repo and configuring it as the required signing key in my channels.scm)
<fnstudio>now... as it happens, i actually have a separate gpg sub key for signing
<fnstudio>when creating my .key file (to be added to the keyring branch of my channel/repo), should i only use the subkey?
<fnstudio>never mind, i think i'm not making sense
<fnstudio>but i might have figured out what the problem was...
***jonsger1 is now known as jonsger
<vagrantc>i haven't tried writing a system service before, but i need a service that can set the date if the date is older than, say, 2020 or something
<vagrantc>because NTP refuses to update the clock when it's 1970 even though it's configured to force-set the time
<kitty1>Has anyone managed to get kmonad working (and managed via system)? Looks like it requires some guix-specific instructions and im struggling to get it to like me so was wondering if anyone here knew lol
<kitty1>if not I will look for their chatroom and ask them xD
<bdju>vagrantc: iirc the date command can manually set the time and then whatever tries to sync it should kick in since you're close enough
<bdju>the_tubular: do upgrade commands with --dry-run to see how much would be built or use `guix weather` to see how much stuff is built / if a particular thing is built. if something big isn't built yet, wait 1-3 days and upgrade again
<bdju>if I do a fresh guix install on a new drive sometime soon would the "latest" iso be the way to go? I know often the release ISOs get some installer bugs in them
<vagrantc>bdju: yes, that's what i do manually, but i just need to wrap my head around a system service that does that :)
<vagrantc>date --set --date=2022-01-01 would probably work well enough
<bdju>zamfofex: well, it's to go on a new SSD for my machine already running Guix System, so if something was wrong I would just redo the install another way I guess. it would just be easier for me this way than to go find a different drive to wipe clean
<taxuswc>Hello! I'm trying to install a few LaTeX packages with guix. Is there any sort of cross-match list between guix texlive-latex-* packages and CTAN packages? In particular where can I find pdflscape.sty?
<lilyp>I haven't read it all, but re: cross-profile search paths, that's not something you can achieve without invoking a guix command
<lilyp>guix package --search-path -p profile1 -p profile2 should give you what you want and you can stuff it into eval and everything, but it's not something guix can bake into the relevant etc/profile files
<thang>hi, I've downloaded the guix vm disk image. I'm already running it and seeing the xfce desktop environment. But there's no /etc/config.scm file in it. Am I supposed to write a completely new config.scm or can I get it elsewhere?
<thang>my bad, I've seen the path under /run in doc. Never mind
<florhizome[m]><lilyp> "I haven't read it all, but re..." <- The issue has nothing to do with cross compiling, it was just sth I didn’t understand (bc native inputs)
<florhizome[m]>also, you wanna tell me if my patch works or not when I tested it?
<Christoph[m]>Hi guix! The output of guix pull is kind of opaque for me. Most of the time, it's only a list of new and updated packages, most of which I don't know. Would there be a possibility to highlight the ones that I have installed, and maybe those which trigger rebuilds or grafts of
<lilyp>And I thought CPSC 432 was a requirement...
<florhizome[m]>nckx: Me, i feel like these discussions are way out of scope.
<singpolyma>nckx: I agree you are right and my words were bad. I was trying to get at this "when would a user need the search path to make it to the profile when running guix install" question.
<singpolyma>For example installing ghc-text I would need GHC_* to be set to use it (but I also need ghc to use it, so it works out). But for pandoc I don't need GHC_* for anything set. But of course the builder needs them set when building pandoc
<singpolyma>So this kind of search path does not propagate in the ideal case. But a plug-in path kind of one, ideally does
<singpolyma>Which makes me feel like there are "two kinds" in some sense I'm obviously not communicating well
<lilyp>well, ideally the GHC_* would propagate, but match nothing :P
<singpolyma>lilyp: I don't think I would say ideally there, but maybe that works out to the same result in practise
<singpolyma>I mean, by that logic search paths could be global instead of attached to a package
<florhizome[m]>I just want foot to be treated like alacritty, i don't need that to be for every terminal emulator ;P
<nckx>singpolyma: Sorry, got called away, but did not mean to imply ‘badness’. I think we were all somewhat confused and trying to figure out what the other meant (which seems to have happened, somewhat, in my absence).
<nckx>florhizome[m]: <the conflict at whole> I might be wrong but I don't think there's a conflict here. As for scope, I'm not sure which scope you mean, but ‘doing things right’ is a Guix value, and that includes discussions that go beyond ‘this code works because we got result X — ship it!’. Reflecting on the nature of things is not a waste of time, although it's important that patches do follow at the end.
<nckx>But the real patches are the friends we make along the way.
<florhizome[m]>nckx: i understand that but i meant to implicate exactly that i consider the discussion to have gotten derailed. TERMINFO_DIRS of foot is not INCLUDE_PATH for all profiles. There seem to be better solution for the case of terminal emulators though, maybe, although it seems to be out of hand.
<florhizome[m]>Then there is QT_PLUGIN_PATH or ROFI_PLUGIN_PATH where i would still think using search-paths seems to be viable.
<florhizome[m]>In my understanding it's enough to set them at runtime and if search-paths is not a good solution then i don't understand what to use it for anymore :)
<nckx>M-hm. That unsatisfying guess is as good as any of mine, lilyp.
<nckx>florhizome[m]: It's not clear to me which properties of TERMINFO_DIRS and INCLUDE_PATH you're comparing. They are certainly quite different in some respects, but it's not clear to me why they need to be handled differently. I don't understand why having TERMINFO_DIRS as a search path is not ‘viable’, once the permabug of to propagate or not to propagate is decided.
<nckx>This ‘propagation’ not necessarily related to the propagated-inputs ‘propagations’ to be clear.
<lilyp>I clearly wrote search path propagation *and* explained the concept.
*nckx shrugs, I don't get why this of all topics seems to be the heated one…
<gnoo>how do you use wpa-supplicant properly in guix? i used wpa-supplicant-service-type but after it connects to the wifi i have to manually 'sudo herd restart networking'
<nckx>florhizome[m]: I know that many terminal emulators include it — I added some of them. What I'm saying is this should not be necessary in a more perfect world: everybody using ncurses should get its terminfo search path for free, and this is what ‘propagation’ means in this context.
<ss2>But Samba’s config style is as such that everything is defined in smb.conf, where the parameters can be freely placed.
<ss2>And the sections are interchangable too (hope that makes sense)
<ss2>anyway, so I’d like to write the serialiser so, that it basically reimports all the smb-conf fields.
<ss2>yeah, not so sure if this is a bit complicated for me. :)
<florhizome[m]>> * <@nckx:libera.chat> shrugs, I don't get why this of all topics seems to be the heated one…
<florhizome[m]>bc we started from a patch I sent that would add said variables to foots search paths, as alacrity has it now, and i asked, how to progress with it. And I have some more packages that I got working by using search paths (you might remember wayfire), and some patches (for qt5ct, lxqt–qtplugin, qtwayland), that add search paths.
<ss2>anyway, hope somebody wants to have a look at it. ^^
<lilyp>florhizome[m]: Again, the solution is not to litter search paths everywhere.
<lilyp>I'm sorry if I misunderstand something here, but the way you're talking suggests to me that you just recently discovered search-paths and are trying to hammer every vaguely nail-shaped issue with it.
<lilyp>"We can solve this with search-paths" != "We should solve this with search-paths"
<jgart>Guix packaging meetup today. Come join us for some free software wrangling 🦬 🤠
<lilyp>If there's a list, you might want to splice it
<jgart>danialbehzadi[m], It's just more work to have to mirror the event on some Mobilizon instance that few people will see and I'm too busy/lazy. Much easier to just send out an email from my terminal to guix-devel than have to fiddle with a graphical UI.
<jgart>Does Mobilizon have an API endpoint I can use to automate event creation?
<civodul>mbakke: i'd say it's okay to use source-module-closure in package definitions, though it's nice if it can be avoided (source-module-closure does a bit of i/o and cpu that's best avoided on the host path)
<civodul>or, you can call 'source-module-closure' outside of 'arguments' and keep its result around
<florhizome[m]><lilyp> "And yes, it wouldn't be literall..." <- I am simply thinking it is underused, as it’s documented pretty poorly. the foot/terminfo thingy might not to be a very good example.
<luishgh>hi guix! i have been working on updating the neovim package from 0.4.4 to 0.6.1, the newest release. i already managed to build it with lua 5.1, but wanted to try writing a modified version using luajit, as it is vital to many plugins. i found this patch  on the guix bug tracker, but it doesn't work on my updated definition. the main problem is that the error is a guile exception and i don't have a clue how to inspect it better or
<luishgh>interpret it. i wanted to post the build logs here (through a pastebin link of course) in case anyone can help me understand what's wrong, but i'm not sure which flags to use in order to provide the best output. thanks!
*efraim is building the ~55 packages with python-pillow as a direct input
<rekado_>lfam: since today I also see the Guile 2.0.14 build — not a build failure, but there’s no substitute and I know my i686 doesn’t have enough memory to build it.
<lfam>rekado_: I haven't paid close attention to these issues, but I think the build fails despite how much memory the x86_64 host system has. The memory available to the build is being limited to a 32-bit limit, IIUC
<vivien>Would someone with python knowledge look at my patch? I have made python-mne available: 53402, and in the process I discovered a slight imperfection in the pypi importer that I think I fixed: 53395
<vivien>That would be a nice break from all your rust annoyances :P
<luishgh>now there is only one question left. it was discussed before on the guix bug tracker if guix should package neovim with luajit or remain with lua 5.1. The problem with the latter being that a lot of lua plugins for neovim abuse luajit only features and the problem with the former being that luajit is not available in all platforms supported by guix. what if we maintain the neovim package using lua 5.1 and use a modified version with
<luishgh>luajit that only is avaliable at the supported platforms?
<mhj[m]>What are the best eMacs packagesto use with guix?
<mhj[m]>s/What are the best eMacs packagesto use with guix?/What are the best eMacs packages to use with guix?/
<attila_lendvai_>speaking of Rust, i have 49 cust commits, most of them additions, but some updates were also needed. maybe someone can take a quick look and apply if appropriate, before too many merge conficts develop... https://issues.guix.gnu.org/53401
<luishgh>ok guys, just managed to transform my neovim with luajit to a package. i'll just study how to format a patch with git and send it to the guix bug tracker. thanks a lot for your help lfam and lilyp!
<luishgh>i guess at first i'll try to git send-email following jgart's link, if it gets to daunting i'll try these other options. anyhow, i'll come back here if i get into trouble haha. thanks everyone and have a great week!
<tschilptschilp23>I almost fully migrated to guix-home now and like it a lot. One thing I miss though -- how would I get this neat 'package-version-overview' that can be retrieved through 'guix package --list-installed' when the packages are installed via 'guix install'?
<lfam>Because `guix shell` works by starting a new shell, you can imagine it might get clobbered by things in ~/.bashrc
<rekado_>sneek: later tell apteryx The problem with kreuzberg (10.0.0.9) was that it doesn’t do the wireguard handshake regularly. All of them have that problem. And I can’t upgrade the systems because ‘guix deploy’ sends x86_64 binaries to them.
<drakonis>that's what the author has set out to fix
<ngz>civodul: OK. Hmmm, then what about creating a cargo.toml-union function that would take care of creating the guix-vendor directory necessary for Rust build-system, using its arguments as sources: (inputs ,rav1e ,(cargo.toml-union rust-foo rust-bar))? (I'm grasping at straws here)