<Kabouik>I know most Guix users would use emacs but I trying to get my kakoune config to work on Guix and am having trouble, for some reason even after copying my ~/.config/kak from a Debian computer where it works, on Guix the syntax highlighter fails and some other plugins too, and I really don't understand the debug buffer.
<Kabouik>They're very helpful and keen to help usually, but since they're obviously not emacs user (like me!), I don't know if they'll know much about Guix
<lfam>So, we do set PREFIX... let's see if the Makefile uses it in a way that would cause this issue
<lfam>Regarding asking them for help, they might at least already know how Kakoune looks for these things, and so we could take that information and apply it to Guix, to understand what's wrong
<lfam>Also, they can interpret Kakoune error messages more easily than us
<Kabouik>It may very well be a local issue on my side too, since I got no issue with the fresh kakoune install, just when using my kakrc (which works on Debian); but I'll wait for their answers too yup
<lfam>You said that you think there is not a problem finding plugins, but your errors show that it can't find 'surround'. Isn't that a plugin?
<Kabouik>But that one apparently is not loaded with the plugin manager currently in my config, I'll see if they changed something in the source of that plugin
<lfam>I guess I'm still trying to understand what the problem is
<Kabouik>I'm not sure what is the source problem either, I just see my debug buffer filling up and my syntax highlighter not working
<Kabouik>Yeah surround works, it's just that it no longer needs "require-module surround" in my kakrc since some update, and on Guix I had the updated version. That solves one issue in the debug but I still have the others
<Kabouik>Okay, seems most issues are due to plugin updates that changed the way to enable them or their special features, I'm slowly solving the different issues.
<Kabouik>The highlighter is still broken though, which is the most annoying
<lfam>And do you know if the highlighter is an external plugin, or supposed to be part of Kakoune?
<Kabouik>I think it's builtin at least form base languages, like that in kakrc
<Kabouik>I'm not raingloom, just xfce4 right now while configuring things, then i3 when I'll consider it ready for real use, and then hopefully StumpWM (although I read it doesn't allow multimonitor workspaces, which is a dealbreaker)
***Xenguy_ is now known as Xenguy
<Kabouik>Is there a way to get cargo nightly? The guix package is stable and installing through rustup fails
<jgart>hi guixers! when setting up a channel, is it possible to add the gpg keys in the same branch as the channel instead of a separate keyring branch?
<jgart>I haven't tried but I was just wondering if anyone has made a channel this way?
<raghavgururajan>jgart: Yes! You just have to have specify the branch name in the .guix-channel file
<jgart>I'm just brainstorming how much I can automate for a cookiecutter template for a Guix Channel
<nckx>Maybe I'm reading your question too much in the context of rek ado's message. ‘Tags are mutable’ does not mean ‘upstream has unreliable tags’, it means *all* tags are mutable. That was the context of my earlier messages at least.
<robin>Kabouik, they're not packaged at present, but if you only need rust beta/nightly packages to be available for access to cargo nightly it'd likely be fairly straightforward (depending on what changes upstream, of course -- most rust packages need at least small modifications, though in the ideal case a new version only requires a three-line package definition)
<robin>(having multiple guix-packaged versions of crates would be rather more complicated, but i'm assuming, perhaps incorrectly, that one would just use cargo directly for beta/nightly-based development)
<gnoo_>hello, i messed up the efi-entry on config.scm while doing guix system init /mnt/etc/config.scm /mnt, I then rm -rf /mnt/boot, now, is it possible to only install grub and not other packages from the live-image?
<gnoo_>from looking at the documentation guix system build looks like what i want but can it work for /mnt instead of /?
<gnoo_>(i'm away from that pc but will see your replies with this nick and my other nick (gnoo))
<ns12>lfam: Thanks. How many times is the default GCC upgraded each year? From my understanding, it cannot be very often because changing the GCC version will trigger the rebuild of a great many packages that are built using GCC.
<lfam>I don't recall if that happened on core-updates or not ns12. My understanding is the style change was done in a way that wasn't expected to cause any rebuilds, so it could be done freely without disruption
<lfam>That's partly why the change is incomplete. Only the parts that could be automatically and without causing rebuilds have been done yet, for the most part
<cbaines>this makes it really inconvinient to update systems using the prometheus-node-exporter
<Kabouik>Thanks robin. I just needed nightly for some crates (namely broot) and I assume that's the issue with Rust, some packages do *need* nightly and just don't build with stable.
<PotentialUser-3>Hi, I would like to know if there is a converter/translator for AUR build scripts to Guix Scheme. Or is it realistic to create some kind of script that will do.
<Kabouik>Another issue: I'm confused as to what is the workflow to compile programs from sources on Guix. On Debian I would install a bunch of -dev packages and build in the git folder (which I know is not great, I clutter my system with dev packages, I should use a VM I guess). On Guix I don't see -dev packages.
<jpoiret>what do you source exactly in your .profile (eg .bash_profile, .zprofile, etc)?
<jpoiret>if the profile doesn't explicitly export EMACSLOADPATH=, then it's not the culprit
<jpoiret>I wish there was a way in bash to track where env variables are set :)
<ns12>jpoiret: Okay. I'll investigate in more detail. Thank you for your help. I'll ask again if I encounter anything weird.
<rekado_>if any of you has some time to help me understand something about cmake I’d be very happy
<rekado_>our tensorflow package uses the cmake-build-system
<rekado_>we’re building a whole bunch of stuff in the 'build phase and then proceed to install things in the 'install phase.
<rekado_>however, the 'install phase takes about as long as the 'build phase
<rekado_>and it looks like it performs some of that work a second time
<rekado_>is this … expected? or is the package definition doing something silly that would invalidate the previous build phase?
<Kabouik>Thanks jpoiret. I still face issues trying to compile nnn (I know there's a package, but I need special compilation options). make, ncurses and readline are installed.
<jpoiret>you don't need to install any packages to work on something, you have `guix shell` for that
<jpoiret>i'd suggest (especially if there is a package already) running `guix shell -D nnn`
<Kabouik>I am not familiar with guixx shell, I'm checking it
<Kabouik>I think it fails, the shell closes itself immediately. I'll try after installing the nnn package first. But while it installs, I noticed the "building profile with xx packages..." step of `guix install` takes very long. I think it's taking more than 5 min with just 55 packages in my case.
<Kabouik>Same after installing nnn, I'm confused with guix shell
<Nazar>Hello there, does anybody know how i can start the notification-daemon as dbus service ?
<Nazar>mannually i can trigger it like that /gnu/store/s8yizsqn07y9pg7141b9gmb8aa0rkj6f-notification-daemon-3.20.0/libexec/.notification-daemon-real
<Nazar>and its's work as expected, but how i can put this into config ?
<rekado_>Nazar: is there a corresponding dbus service file?
<jpoiret>which can be a bummer if you plan on using that `guix shell` often, in that case i recommend using `--root=<gc-root-filename>` to register a gc root for that profile. you can look up what gc roots are in the manual
<jpoiret>if you want to use a modified package, you can simply modify the package definition (either by using your own checkout of the guix source code, which can be a bit unwieldy, or simply by inheriting the initial package in a .scm file and then using `guix build/package/shell/... -f your-package.scm`)
<jpoiret>it might look like a lot of information at once but once you get used to all of this you'll be even more delighted :)
<Kabouik>You're right jpoiret, I'm just use to other distro's paradigm, and that led me to accept a lower vigilance level when compiling from sources. I just make install programs I truste. With guix shell, this isn't necessary anyway, I can compile in a shell, then ln -s thebinary to my ~/.local/bin for instance
<drakonis>i forgot now, but there's a way to include variables into the environment when installing a package, yeaH?
<Kabouik>I'd actually prefer deleting those shells/profile jpoiret, I'm not a dev and just compile when upgrading stuff, or occasionally when I try to contribute. Nothing that prevents me from recreating the shell when needed. But I guess I could still make one "permanent" with most frequent dependencies like ncurses and such.
<jpoiret>well, it's entirely up to you again, but personally i just run `guix gc` when i notice i'm running out of space
<Kabouik>Re: modifying package definitions for my own preference: that looks very interesting, but indeed a bit overwhelming. Typically I'd just need to apply a .patch file to nnn sources and compile with an extra option (O_CTX8=1).
<jpoiret>well, that's exactly what it would be used for!
<jpoiret>you can't really have concurrent versions of one package installed (they would conflict in the profile), but you can have multiple versions of one package in the store
<Kabouik>I think I could understand a bit guile, but it's hard to me to understand special chars like #, ', or to discover commands (or are they arguments?). And in the case of package definition, it's not clear to me where to store my custom changes and take them into account for future package installations.
<jpoiret>the GC would just remove anything that is not being used by any live profile/system generation
<Kabouik>That's what I wanted to say about verions, but I used the wrong words. :p
<jpoiret>you don't need to worry about the GC, it will only remove things that you shouldn't be using
<jpoiret>Kabouik: rather, the GC will never remove something that's in use, it's literally impossible (unless there's a bug of course). No toggle or "manual way" out of it (the store is even mounted read-only, so you can't rm -rf unless you remount it)
<Kabouik>I guess I could add other `string-append` there to add my compile option, and probably change the version so that it always pulls master
<lilyp>PotentialUser-78: Depends on what upstream considers the source of truth. If it has a dedicated release page that serves tarballs not generated by github, use that. If it's just git tags, then git-fetch is to be preferred.
<morgan>In the guix manual it says to make a swap file using `dd if=/dev/zero`. Does the swap file actually need to be zeroed? It takes a while for large swap files and I'm wondering if we could suggest fallocate instead
<jpoiret>not all fses support fallocate iirc, but that's an alternative for sure
<rekado_>nckx: FYI: I started an rsync process to copy from /var/cache to /mnt_test/var/cache.
<rekado_>we just got 5TB more on /mnt_test, so I think it makes sense to continue copying.
<rekado_>the rsync over the internet probably should use the data at /mnt_test instead of /var/cache, as the former is much faster
<morgan>Anyone know why my gpg isn't decrypting stuff for me anymore? Probably my fault but idk if there's a bug going around or something.
<lfam>Basically, if you are using GnuPG 2.2.30, symmetric encryption and decryption will not work
<morgan>I start gpg-agent by using the gnupg variable in my home.scm. It seems I'd have to change the variable I'm using to the new one. Although maybe gpg-agent should be a herd service thingy anyways...
<morgan>Well I have an ssh-agent that talks to gpg-agent. idk if the ssh-agent would start itself
<lfam>Anyways, the bug should be fixed when you update your gnupg package
<lfam>And yes, if you are specifying a particular package variable, you'll need to change it to use the gnupg-2.2.32 variable
<morgan>Well I don't really want to do that because then I'll have to change the variable back in the future when the gnupg package is updated proper. I'll look into gpg/ssh agent stuff and maybe guix service stuff (but that scares me a little) and see if I can't find a better solution.
<jacereda>If I have a ~/src/guix checkout, do I still need to deal with channels or should I just have no channels and use that checkout? And if so, how can I checkout the latest commit that has already built by the CI and available in the caches?
<morgan>jacereda: I'd recommend reading the "Running Guix Before It Is Installed" section of the guix manual if you haven't already. When running guix from your git checkout it won't have access to channels. If you want to use channels you always add "-L path/to/channel" to your command.
<jacereda>morgan: that seems oriented towards development, which I intend to do sooner or later, but I was wondering if channels are redundant when you have a checkout. On NixOS I used to get rid of channels and point NIX_PATH to my git checkout, I was wondering if the same is possible/usual on Guix
<morgan>So are you trying to save bandwidth by pulling updates from local git repositories instead of from online?
<jacereda>my approach was then to visit the hydra builds and update the checkout to the latest built hash to ensure a `nixos-rebuild switch` would find everything in the caches, probably there're better ways to do that though
<jacereda>morgan: no, I just find it somewhat confusing to have 2 places defining the packages, if I want to visit the sources for a package I don't want to be wondering which one am I visiting...
<jacereda>I mean, before checking out the sources M-. on emacs was showing me the sources for some symbol from the channel, now it's showing the ones from the checkout because I changed geiser-guile-load-path. If I´
<morgan>are you currently using channels? I'm wondering if the nix terminology is different from the guix terminology because I am royally confused right now.
<jacereda>I'm visiting some symbol I'd like to be sure that's the definition I'll use in my config.scm
<morgan>oh ok I think I understand your question now but it doesn't involve channels at all :P
<jgart>Is there a way to search for packages filtered by a custom guix channel?
<jpoiret>sneek, later tell mothacehe: I'm nearly done implementing a per-installer `run-command`, with configurable line-hooks: you can chose what to do with each line of the output, ie giving it to syslog and displaying it, be it in newt or in the tty. I'll try figuring out how to buffer and handle refreshing in newt properly next, but it should be good
<jgart>Or even something like the following would be nice: `guix show -L . '*'`
<morgan>guix pull and git pull are kinda similar. Both will just grab the latest commit and I don't think there is a good way to wait on CI but I could be wrong. Guix has a builtin way of pulling up package definitions by using "guix edit". So you can do "guix edit emacs" to see the definition of emacs that the installed guix has.
<jpoiret>sneek, later tell mothacehe: Also, do you think a parameter (run-command-in-installer) is good enough? I don't really see how we could pass the installer-specific procedure down to the steps.
<jgart>The above command is executed in the custom guix channel's root directory
<jpoiret>jacereda: we have a built in switch to `guix pull` to the last built commit i think
<jpoiret>in any case, you can just do `guix pull --commit=<SHA>` to pull the commit you want. You can check the CI to see which commit good for you (remember to `--allow-downgrades` if you need to)
<jacereda>morgan: so "guix edit" will show whatever the particular commit in the channel has, and that could be different to the commit I have in ~/src/guix, that's what I'd like to avoid by having a single source of package definitions
<jpoiret>jacereda: you can do `./pre-inst-env guix edit`, which will bring up the one in your checkout
<jacereda>jpoiret: that switch doesn't seem to be present in --help
<jpoiret>yes, I haven't managed to find it. But I seem to remember something of the sort