<mikadoZero>So I do not realy want to make my own package I want to make a patch for emacs-xyz.scm that adds ace-link. I am using ace-window in emacs-xyz.scm as a template because it has the same dependency.
<mikadoZero>Looking at that as an example a specific release was used. So the most recent release for ace-link is from Nov 8, 2017. Melpa is using the most recent commit which was 16 days ago. Which should I be using the release or the most recent commit?
***renich_ is now known as renich
<reepca>anyone else had difficulties with geoclue? The where-am-i demo program times out after 30 seconds for me. I added (geoclue-application "redshift") to the whitelist of my geoclue-configuration and reconfigured, but it gets stuck at "Waiting for initial location to become available...".
<nckx>reepca: I don't think (years ago) redshift + geoclue ever worked for me.
<mikadoZero>reepca: You could set up something comparable to having it adjusted over the course of the day by using something like cron to adjust redshifts command line arguments as the time of day changes.
<OriansJ>mikadoZero: redshift automatically adjusts over the course of the day, unless you One-shot mode (which disables its continuously adjust color temperature behavior)
<OriansJ>redshift -l 55.7:12.6 -t 5700:3600 -g 0.8 -m randr -v is really all you need
<mikadoZero>OriansJ: Yes. I have used the one shot approach.
<OriansJ>mikadoZero: if you wish for it to change over the course of the day automatically, you need to not use the One-shot mode
<apteryx>could someone remind me about the minimum kernel version required for Guix?
<apteryx>I guess that requirement is established from the version of the glibc used in Guix?
<OriansJ>apteryx: well I don't think anyone has gone archive diving to figure that out exactly but given the start date of the project and the basic functionality expected; I'd say everything after 2.6.11
<vagrantc_>sometimes "guix pull --dry-run" feels anything but dry
<vagrantc_>e.g. on an armhf machine that hasn't run guix pull within the last 24 hours ... it's "guix pull --dry-run" is apparently feeling the need to compile gcc...
<efraim>i seem to have gotten stuck with my perl6 build system so I think it's time to send off soon what I have for review
<allana>Hi Guix. I am having trouble with emacs on guix recognizing my spell checker. I have hunspell and hunspell-dict-en-us installed in my profile. emacs doesn't seem to know about this installed dictionary. Has anyone ran into a similar problem? I did not find anything in the guix-devel mailing list.
<roptat>allana, aspell requires ASPELL_DICT_DIR to be defined, so maybe hunspell would need a similar variable? or maybe it's emacs-specific in which case I can't help you :/
<ConfusedLizzard>Hello, i have trouble understanding how modules defined in additional channels work. I have set up an additional channel and called guix pull. "guix pull -l" returns a generation that references the channel and actually tells me, that there are the packaages defined in the channels module are now avaible. Despite that, guix package -s example1 does
<ConfusedLizzard>I know that channels are supposed to be debugged by the channel provider. But i have trouble understanding how package visibility works. For example the "use-package-modules" function found most system definitions only looks for packages inside (gnu packages)
<ConfusedLizzard>Since my packages are now compiling just fine, i have another question.
<ConfusedLizzard>When users can redefine channels and even kick out the gnu one, they can install arbitrary software. So far this not less secure than an installtion of wget and gcc. But why does a user have the permission to invoke a system reconfigure? I'm currently replacing the kernel as user
<ng0>you need privileges for that to conclude successfully
<ng0>a normal user without sudo or su can't just arbitrarily reconfigure the system
<ng0>a user can build a new system generation, but the reconfigure requires privileges.
<bgardner>Hey guix; I'm having fun building Guix installations but I'm getting enough deployed that I'm starting to fall behind in my periodic updates - is there anything today or on the roadmap for something guix-equivalent to unattended-upgrades?
<ConfusedLizzard>bgardener, "enough deployed"? Do you mean you have so many machines running, that you can not run updates on all of them?
<wednesday>What is the best way for me to set my XDG_RUNTIME_DIR, can I do it in my config.scm somehow?
<bgardner>ConfusedLizzard: Just that I am discovering the occasional server in the rack that hasn't been updated recently. So, I guess, yes.
<notnotdan[m]>Hm, I am running `./pre-inst-env guix ...` commands from an environment that I made with `guix environment guix`, but it seems that it still consults the package databased of the actual, installed guix
<ConfusedLizzard>bgardner: what is your current managment solution? Keeping your profile in a git, fetching with cron / mcron is not an option?
<bgardner>ConfusedLizzard: Most of these servers are deployed in a fashion where the users don't have any personal packages, and I haven't found any documentation that seems to indicate that calling 'guix system reconfigure' in a cron is the right way to do things. Is it?
<notnotdan[m]>Can someone help me out with testing a package upgrade? I've upgraded a particular package, and now I want to check if the dependencies build. I have a local git checkout, in which I set up a `guix environment guix` and ran `./configure` and `make`. I am not trying to do `./pre-inst-env guix refresh -l coq`
<notnotdan[m]>but it returns an error: guix refresh: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory
<notnotdan[m]>trying to open the staging area in Emacs basically hangs magit :/
<notnotdan[m]>why are there all these .po and .texi file that are updated with ./bootstrap and ./configure
<jackhill>ebrasca: awesome :) What was happening before, is that when you didn't specify a command it was picking the path to your shell in the guix store which doesn't exist in the non-guix chroot (or even probably a different guix chroot)
<rekado>notnotdan[m]: you can get rid of them with “git checkout -- po”
<roptat>notnotdan[m]: if needed we could have both coq versions for swme time if you need 8.9
*nckx is unsure whether allowing users to override TMPDIR through a new RPC would be a security hole.
<notnotdan[m]>thanks roptat for your help :) I decided that I will first try to update all the coq packages to more recent versions, as this will have to be done eventually anyway. I don't need to use the latest Coq version yet.
<nckx>^ not a list of recommended fonts, just what I happen to have installed over the years.
<quiliro>nckx: how to know which to install and what the name of the package is?
<nckx>quiliro: Well, I trust (Guix+nckx) more than (FreeBSD+nckx) at the moment :-) FreeBSD has a great sleep-at-night factor, but it's not worth much if I never find the time to keep that one special snowflake up to date and configured when all my other servers run Guix System from a central git configuration.
<nckx>quiliro: You don't :-) You just know that those are the fonts I have, *and* I can read everything on that page, so it's now up to you to find the magic font!