<yenda>ACTION now needs to reboot to test but doesn't want to screw his pomodoro timer :D
<davexunit>bavier: I'm fixing the issue with 'setns' on old glibc versions right now. if you run 'make check TESTS=tests/containers.scm' now, does it pass?
<davexunit>my guess is that all the tests will be skipped, which is good.
<davexunit>I can't think of a system that would have user namespaces available but not have a 'setns' glibc function.
<sbidin`>A package I'm trying to build expects /bin/sh to be accessible during compilation, and fails because it's not. I though adding coreutils as an input would fix this, but it doesn't seem to. How should I proceed?
<yenda>i3 is just a set of very basic tools, a menu bar, a window manager, dbus, dmenu to start an executable that is in the path
<mark_weaver>well, to be more clear: xmodmap and setxkbmap are both X specific afaik, but .xsession is something that the display manager (slim, etc) runs, so it's not necessary X specific, despite the name.
<davexunit>if emacs xwidgets ever gets upstream, we could have a webkit browser in emacs.
<mark_weaver>I also prefer icecat and will switch back to it, but for now, the version of icecat we have might have some known unpatched holes.
<mark_weaver>or at least there were some security fixes for 38 released recently, but no one has ported them to 31, and it seems no one ever will.
<yenda>mark_weaver: helm is difficult to explain because it's really big. It is a completion engine like ido but also much more. You have helm-M-x for instance that replace M-x and help you dynamically search through function, helm-grep to dynamically grep though dir
<davexunit>I use smex to replace the built in M-x function
<yenda>helm-circe for instance is binded to my f8 key and shows me the irc channels with activity so I can jump in quickl
<davexunit>projectile recognizes .git directories and things for other vcs systems and uses them to denote the roots of source trees so that you can, for example, quickly open files for a given project via fuzzy matching
<davexunit>it's a port of a feature from a proprietary editor
<davexunit>I think it would be useful, but I have C-x C-f so ingrained in my muscle memory that I need it to play nice with that
<davexunit>but I haven't been able to come up with something to make it work
<yenda>c-x c-f is binded to helm-find-file in my conf, I think I will add projectile as the first source
<yenda>that way c-x c-f will do that and also be normal out of projects
<mark_weaver>regarding gnus: it was a steep learning curve, and it works differently than most traditional email clients, but I eventually became accustomed to it, and it's the most featureful emacs mail/news/other reader
<mark_weaver>at this point, it's hard for me to switch to anything else, because I've become so accustomed to it
<paroneayea>mark_weaver: I think mu4e is pretty comparable, and even has some features gnus doesn't (I'm a former gnus user) but it doesn't have the newsreader and "things that are not mail" features gnus has
<sbidin`>rekado-: I assumed so, but feared the automatic process that triggers on packages beginning with "ghc-" (that I don't yet understand). For instance, xmonad is used as a library by (ghc-)xmonad-contrib.
<mark_weaver>but if you want to take care of it, please feel free!
<davexunit>too many things right now. maybe one of the more experienced elisp hackers will do it. :)
<davexunit>sometimes if I mention things here they magically happen shortly thereafter. ;)
<rekado->the only thing I recall about the upgrade is a popup that asks you to confirm new behaviour by adding a line to the init file. If this line is not added the popup appears again the next time Emacs starts.
<enno__>Hello everyone. I do my very first steps with guix sd and the usb stick is booting fine. But unfortunately my network adapter is not working. The r8169 module is probably not working. I want to use r8168 instead. Where can I find this?
<enno__>@mark_weaver r8168 is for ethernet. So I am stuck at the moment.
<alezost>I think there is a problem in packaging magit 2: it requires dash. We have emacs-dash package, but "dash.el" (which is required for compiling magit files) is placed in /gnu/store/…/share/emacs/site-lisp/guix.d/dash-<version> ← this file name can't be defined, i.e. we can't use (string-append <dash-input> "/share/…")
<mark_weaver>alezost: I don't understand what the problem is. can you elaborate?
<alezost>mark_weaver: Look at the current "magit" package recipe: there is (setenv "EMACSLOADPATH" (string-append ":" git-modes "/share/emacs/site-lisp")). git-modes are not needed anymore, but there should be something similar for dash, but "/share/emacs/site-lisp/guix.d/dash-2.11.0" can't be defined because of the version
<alezost>emacs-build-system put dash files to that directory
<mark_weaver>well, if you think something should be changed in 'emacs-build-system', we should probably discuss it on the ML.
<yenda>davexunit: I installed circe with guix but I'm still hesitant to switch because I use the (use-package) macro in emacs which takes care of all the dowloading and configuring of the packets
<mark_weaver>maybe in the meantime we could just use (package-version emacs-dash)
<yenda>mark_weaver: I packaged a few emacs packages for myself but I used git while guix import "encourages" the use of melpa
<yenda>I was wondering if guix can still look-up for potential upgrades when using a git repo instead of melpa
<mark_weaver>unless something has changed since I last checked, our current lookup for newer versions only works for GNU packages, and furthermore only GNU packages that are in ftp.gnu.org.
<mark_weaver>at some point we should try to make this work for as many packages as we can.
<mark_weaver>yenda: I think it's okay (maybe even preferable) to use a tarball or git repo over melpa for guix packages.
<mark_weaver>but I'd like to hear what other people think about this also.
<alezost>On my opinion there is another ugliness with emacs-build-system: along with *.el[c] files you will get other files from the upstream tarball.
<alezost>Try for exmaple "guix build emacs-dash" and look at /gnu/store/ic22a0y8v5hs8m2vinb9wqig10rjpfgl-emacs-dash-2.11.0/share/emacs/site-lisp/guix.d/dash-2.11.0/ directory
<sbidin`>I ran guix system reconfigure, but it failed building base-initrd.drv. I got a large backtrace ending with "ice-9/boot-9.scm:106:20: no code for module (guix build syscalls)". Not sure what's wrong exactly.
<yenda>I asked forcer about circe and he prefers the use of his github over melpa
<mark_weaver>yenda: I think that's fine. several of our existing emacs packages use git or tarballs already
<mark_weaver>alezost: yeah, I agree that's not so good. I'd encourage you to post to the ML about it.
<mark_weaver>btw, there's an (IMO) better way to do this, and necessary if you want to contribute to guix anyway: build guix from a git checkout and use that one. then 'git pull' and 'make' is vastly faster.
<pizzaiolo>I want to publish them on Wikipedia, so they need to be CC BY or CC BY SA, for instance
<pizzaiolo>heh, I know it's wrong but I can't help but pronounce GUI-ks
<sbidin`>Is there a reason why "guix pull" doesn't just fetch a binary?
<sbidin`>I'm hoping the reason is "nobody just got around to implement that yet". :)
<yenda>it's funny at the beginning the commit messages were not as codified
<yenda>I think the most common commit message is "Doh"
<sbidin`>My root's guix pull finished compiling, and then I started my other user's as well. It seems things haven't been cached after all. :D The last commit is 2 hours ago though, so I don't know what has changed these past 20 minutes.
<mark_weaver>sbidin`: if you want, you can just make ~root/.config/guix/latest a symlink to ~/.config/guix/latest
<mark_weaver>and then root will always use the same version of guix as your normal user account
<yenda>For those using magit what do you use when you have unpushed commits and want to integrate latest commit from master ?
<mark_weaver>I *never* use "guix pull", so I don't have direct experience with it.