IRC channel logs

2019-03-01.log

back to list of logs

<nckx>Dun.
<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.
<nckx>On Guix SD/System.
<mikadoZero>reepca: I have used redshift on the command line. I just set how red shifted I wanted it and left it at that amount. It did not adjust over the day.
<nckx>mikadoZero: So… did you use geoclue?
<mikadoZero>reepca: I did not use geoclue.
<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
<mikadoZero>OriansJ: Thanks
<mikadoZero>OriansJ: Do you know of an alternative to redshift that would work in a tty (virtual terminal) C-M-F1 through F6? Or when there is no x-org installed.
<OriansJ>mikadoZero: for the color tinting or the dimming or both?
<mikadoZero>OriansJ: I am just using the one shot color tinting. So just that is enough. I do not need it to change over time.
<OriansJ>mikadoZero: use this to determine the color range of your terminal https://paste.debian.net/1070746/
<OriansJ>if it is good enough, you can simply set your terminal color directly
<OriansJ>But if not, fbterm might give you the color range you want
<OriansJ>(in fbterm it would be echo -ne "\E[2;${i}} " )
<mikadoZero>OriansJ: Thanks I will look into both and try putting one of them in place.
<OriansJ>mikadoZero: if you are a into reducing GUI use, I recommend checking out https://kmandla.wordpress.com/
<OriansJ>Although it is no longer being updated, it still has some gems worth reading
<mikadoZero>OriansJ: Thanks I will check that out as well.
<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...
<vagrantc_>guess it's the openssl changes
<vagrantc_>fairly low in the dependency chain...
<lfam>vagrantc_: The openssl change should only require recompilation of openssl
<lfam>Everything else should be "grafted" which is pretty quick
<vagrantc>maybe i misread it and it was just rebuilding openssl
<lfam>Hm, let us know. Otherwise there is a bug :)
<vagrantc>hard to know retroactively
<vagrantc>but it was way to fast to actually be recompiling gcc
*vagrantc probably jumped to invalid conclusions
***vagrantc_ is now known as vagrantc
***MinceR_ is now known as MinceR
<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> not return anything.
<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>The channel uses its own namespace
***rekado_ is now known as rekado
<rekado>ConfusedLizzard: “use-modules” works for any module.
<rekado>ConfusedLizzard: does it work with GUIX_PACKAGE_PATH?
<ConfusedLizzard>Yes i have used use-modules.
<ConfusedLizzard>Nevermind. I forgot to reboot for the new generation. Now it seems to work.
<ConfusedLizzard>Before the reboot the entire module was not visible even in "guix repl".
<rekado>I don’t think you need to reboot, generally.
<ng0>usually you only need to reboot for guix daemon changes or kernel updates
<ConfusedLizzard>This is what caught me. Neither channel or guix system metions rebooting. Going back a generation supposedly requires a reboot.
<ConfusedLizzard>What if the package is a kernel?
<rekado>going back a *system* generation requires a reboot
<rekado>you can choose a previous system in GRUB upon booting.
<rekado>but that’s a bit of a special case
<rekado>often you wouldn’t reconfigure the system just to install a package into your profile.
<ConfusedLizzard>i only went forward generation wise.
<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.
<ConfusedLizzard>Ok, so the reconfigure will fail after the compile step?
<rekado>reconfigure switches the current system to the newly built one. That requires root permissions.
<rekado>yes.
<rekado>as a user you can only build systems.
<ConfusedLizzard>makes perfect sense, thank you.
<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
<notnotdan[m]>maybe i should run `make` the guix directory as well
<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]>wew compiling guix takes a lot of time actually
<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]>what am i doing wrong here?
<roptat>your ./configure was wrong
<roptat>you need ./configure --localstatedir=/var
<notnotdan[m]>oh
<notnotdan[m]>thanks roptat. i assume i need to re-make
<roptat>probably, but not too many files hopefully
<ebrasca>How I can chroot to other system from GuixSD?
<notnotdan[m]>roptat: I was wondering, if I am installing packages through `./pre-inst-env guix package -i ..`, then how can I clean them up afterwards?
<roptat>I think you can always run "guix package -d"
<roptat>but why do you want to install stuff from your git checkout?
<roptat>if you updated coq and you were able to build dependents (with guix build), you should send patches to the ML and we'll push them
<notnotdan[m]>some dependencies are broken, so i need to update them anyway
<notnotdan[m]>s/dependencies/dependents/
<rekado>python-matplotlib-documentation is broken. I’m trying to fix it (and remove the need for the big “texlive” package).
<rekado>looks like various parts of the documentation generation procedure require Internet access.
<ebrasca>Can GuixSD chroot to other system?
<rekado>can you rephrase the question? It is not clear what it means for a distribution to chroot to another system.
<ebrasca>I like to chroot from GuixSD to other system to fix it.
<ebrasca>Can I do it from GuixSD?
<ebrasca>Normal "sudo chroot /mnt/" don't work.
<rekado>can you say how it doesn’t work?
<ebrasca>( chroot: failed to run command ‘/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash’: No such file or directory )
<jackhill>ebrasca: what happens if you specify which bash to run inside the chroot? "sudo chroot /mnt /bin/bash"
<notnotdan[m]>roptat: it appears that there are some packages that are just not updated for Coq 8.9 yet. I guess I should just postpone the upgrade process?
<ebrasca>jackhill: It works. Thanks!
<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
<roptat>why am I rebuilding guile?
<roptat>unless they have changed, I have imported the keys for berlin and hydra
<ebrasca>Is it better chroot or qemu for fixing someting in other system?
<roptat>and they are in the list of substitute-urls of my daemon...
<rekado>roptat: the keys don’t change.
<phenoble>Hi #guix
<phenoble>So I tried to build/install the bootstrapping rust package on a system that has a 3.7gb /tmp partition. Which, apparently, is not enough
<phenoble>I can't enlargen /tmp. Can I temporarily make guix use another folder for building its packages?
<nckx>phenoble: guix-daemon respects TMPDIR, but you have to set it wherever you launch the daemon.
<nckx>TMPDIR=/foo guix build … won't work.
<phenoble>fun.
<roptat>ah, that's because I was on a very old branch!
<nckx>(phenoble: If you're using Guix System, add it to GUIX-CONFIGURATION.)
<phenoble>nckx: I'm not, and I don't always have root access. This sucks.
<nckx>O… K. Sorry to be the bad news bear then :-/
<phenoble>nckx: Thanks for the input, nckx o/
*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.
<roptat>ok, cool :)
<roptat>notnotdan[m], thanks for the patch!
<roptat>you should have made that two patches I think (unless one fails to build without the other?)
<roptat>but I can take care of that :)
<mbakke>rekado: Any idea why core-updates is failing on berlin?
<mbakke> https://berlin.guixsd.org/jobset/core-updates-core-updates
<nckx>mbakke: I see you already updated OpenSSL on c-u. Thanks!
<mbakke>nckx: NP! Currently trying a commit that changes the default OpenSSL to 1.1.
<mbakke>Apparently I did not have enough build failures on c-u yet :)
<notnotdan[m]>roptat: I think coq-interval needs to have an updated version of coq-flocq, but I haven't tried updating them the other way around
<notnotdan[m]>roptat: and thank you for all the guidance you give me on irc
<Richard[m]>hey, is anyone already working on an installer for guixsd? I'm interested in working on one for it.
<bavier`>Richard[m]: there's a GUI installer being worked on
<nckx>T(ext G)UI. Just to set expectations.
*bavier` has really low expectations
<Richard[m]>bavier`: hmm where can I find the repository, can't seem to find anything online.
<lfam>Richard[m]: It's this branch of our Git repo: https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-newt-installer
<lfam>The 'wip-' prefix indicates that history may be rewritten on that branch, FYI
<pkill9>a GUI installer would be neat
<nckx>Oh, and it also didn't work on amdgpu cards last time I tried.
<liminal18>hey what are the advantagees of guix over nixos?
<tune> https://ambrevar.xyz/guix-advance/index.html this page lists some, IIRC
<liminal18>thanks
<pkill9>imo, better commandline interface
<lfam>To me the primary advantages are 1) a more discoverable and easy command-line tool, 2) the use of Scheme and 3) 100% free software
<lfam>It's largely a new imlementation of the same ideas behind Nix, so there are pros and cons to both projects
<pkill9>also I think the package definitions are better organised, e.g. all package names are lowercase
<liminal18>yeah on nix right now when I ran into guix something said time to change
<liminal18>anyways we'll see
<liminal18>how good is node support in guix?
<pkill9>the node ommandline tool is packaged in guix, but i don't think any node software itself is packaged
<liminal18>interesting
<nckx>liminal18: Unfortunately, for various reasons, Guix is still missing many packages available in Nix.
<liminal18>yeah
<apteryx>OriansJ: I think Guix makes use of specific kernel features that call for 3.4 or newer IIRC.
<apteryx>maybe we should add this information to the manual, I can never remember ;-)
<kmicu>liminal18: it is mostly the same stuff but less. That could be a good or bad thing. Matter of perspective.
*kmicu *uses* both. It’s the same thing modulo details which can be relevant for some or not.
***renich_ is now known as renich
<rekado>apteryx, OriansJ: the glibc requires Linux 3.2 or later.
<apteryx>rekado: so glibc 2.28 requires linux 3.2 in general?
<rekado>yes
<apteryx>OK! Thanks :-) Now I'll remember how to find this information if I forget again, eh!
<cbaines>Just sent another brain dump to guix-devel, but the bit I'm excitied about is that I've convinced my Cuirass instance to build some things! https://cuirass.cbaines.net/
<quiliro>hello
<quiliro>nice to be back
<nckx>
<quiliro>hey nckx! what's up?
<nckx>Getting ready to power off my last FreeBSD box
<nckx>and replace it with Guix System.
<quiliro>i am using epiphany...it is nice...but i have a fonts issue...i think it is that... some sites like http://www.elerno.cn/audio/auskultado.htm show squares on some places....am i correct that it is a font issue?
<quiliro>nckx: cool!
<quiliro>that means you trust guix
<quiliro>what do you use freebsd for now?
<quiliro>or user to
<quiliro>used to
<nckx>quiliro: Yes, sounds like missing fonts. Works fine (in Epiphany!) here. My installed fonts: http://ix.io/1CmY, and what fc-list knows about: http://ix.io/1CmX
<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!
<quiliro>ok...i understand
*nckx is hence quite busy and won't say much more.
<nckx>quiliro: Don't forget to run ‘fc-cache -f’ after installing new fonts.
<quiliro>i found the font for that page on the code...it is arial
<quiliro>ok...
<quiliro>thank you
<nckx>quiliro: Fonts don't work like that. The CSS might request Arial, but Guix doesn't even provide that font.
<quiliro>what should i read then to understand
<quiliro>?
<nckx>The problem is your system can't find *any* font with those characters so it can't display anything.
<nckx>I don't know.
<quiliro>ok...i won't bug...considering you are busy
<nckx>Imagine if you had to have every single font installed that some Web designer decided to use… You'd be unable to read most of the Web :-)
<nckx>So your browser falls back to whatever it has. It won't use Arial, but whatever it has.
*nckx → AFK.
<quiliro>so the problem is in the compilation of epiphany? but icecat has the same problem
<nckx>quiliro: I never said that. And no, it's in the fonts in your environment. Install them like regular packages and run fc-cache -f & restart Epiphany & retry. Good lukc.
<nckx>s/the fonts/the lack of suitable fonts/
*nckx → really AFK.
<quiliro>ok...thank you very much
<OriansJ>rekado: thank you for correcting me
<quiliro>is fc-cache -f needed on GSD as well as on foreign distro?
<rekado>(The name “GSD” was never adopted)
<quiliro>is it wrong? i like its shortness
<quiliro>'guix package -i font-dejavu font-gnu-freefont-ttf' for problems displaying certain web page...is that correct?
<quiliro>on GuixSD
<quiliro> http://www.elerno.cn/audio/auskultado.htm
***bmpvieira_ is now known as bmpvieira
***d1rewolf_ is now known as d1rewolf
***ocharles_ is now known as ocharles