<fusion809>Hi folks in a GuixSD 0.14.0 VM SLiM keeps restarting even though I've killed its processes with `kill -9`. Tried running `herd stop slim` but it couldn't find the service. See my config file tries to autologin in with it and the autologin is failing. How do I stop it for now? It's difficult to see a TTY terminal for more than 5 seconds at a time as it keeps alternating between that and the SLiM screen.
<fusion809>So a quick simple command would be much appreciated.
<str1ngs>ok, its not that then. just I was thinking pam won't allow a login unless a password is set.
<fusion809>Well I removed the autologin and I can't log in manually either. Tried resetting pass in case somehow it got deleted or w/e and still can't log in. Must admit this seems like quite the illusive problem.
<str1ngs>I personally use light desktop. just wondering if it's gnome related
<fusion809>Na haven't. Well my host system is Arch Linux with i3 so I do like light wm but what can I say GNOME is the GNU Project's official DE so it felt fitting that GNU's official distro should run GNU's official DE :P
<str1ngs>you could maybe add i3-wm to packages and reconfigure
<fusion809>Nope, not to my knowledge anyway. From what I can tell it's just command-line.
<fusion809>Tried running gnome-session and xinit and neither started anything so yeah seems command-line only
<str1ngs>I used a foreign distro to install myself. my notebooks wifi was not supported I had to build my own kernel. I'll probably burn in hell now :P
<str1ngs>actually I'll probably dual boot for sometime, just encase
<fusion809>Rofl my PC uses a BCM4352 chip so proprietary Broadcom drivers are required to connect to the net. 'tis why I haven't installed GuixSD on my hard disk. Going proprietary free sounds dangerous to me.
<fusion809>I wish my hardware compatible with OSS-only but regrettably it's not.
<str1ngs>it's not easy to do. my desktop is running OSS though
<fusion809>Did the rebuild and same problem. This time when I kill SLiM with the kill command it just keeps restarting
<fusion809>by rebuild I mean I created a new GuixSD installation in a new VM
<str1ngs>would need GUI for them. I personally don't need them myself
<str1ngs>actually I tend to like distro that have non GUI. guix is unique with declarative approach
<fusion809>True, but if GuixSD gets an automated installer and a nice polished ISO it would be suitable for them, at least in theory.
<fusion809>Ya I'm quadruple booting four distros on this PC. Arch, deepin, Gentoo and Void Linux. deepin is the only one of them with a GUI by default.
<fusion809>So I do like minimal distros but it's also nice to check out polished distros from time to time, for me anyway
<str1ngs>I personally use Fedora. I used Arch for ten years though. other then that I just use docker
<fusion809>Ah Fedora I gave that a go several times. I like chrooting into systems, like to install Broadcom drivers onto system as strict on open-source as Fedora, whenever I chroot into and install software on Fedora I find several systemd services fail to start on boot.
<str1ngs>if you like chrooting. you should checkout docker, it's declarative with Dockfiles
<str1ngs>when building with vm I get guix system: error: canonicalize-path: No such file or directory: "/etc/guix/sudoers"
<str1ngs>I'm removing it for now. could just be vm relatated
<fusion809>Same 'ere. Sorry I should mentioned I commented it out. When I rebuild post-install with the /etc/guix/sudoers file in place (essentially the auto-generated /etc/sudoers file with NOPASSWD: ALL in its %wheel line) I was going to uncomment it.
<civodul>before the next release i'd like to propose to bump the requirement to 2.0.14, which is already relatively old
<mb[m]1>civodul: The (our) README says Guile 2.0.9 and up is supported.
<bavier>I think requiring 2.0.14 is reasonable, if it can allow us to remove some compatibility code
<civodul>yes it would allow us to remove quite a few workarounds
<efraim>Would we need to bump the bootstrap binaries?
<bavier>I know we like to suggest the binary installation method, but I think it would be nice to get a survey of the guile versions supported by other distros, so that people can still easily build guix with as many native packages as possible
<efraim>Debian has guile2.2 in testing, 2.0.13 in stable and 2.0.11 in oldstable
<efraim>I assume we don't care about debian LTS and oldoldstable with 2.0.5
<christopher74837>hi, I installed guix-0.14 on a Debian 9 system, compiled from source. I installed asciinema but when I run it I get error
<christopher74837>+ /gnu/store/zks71a4dzfs9bkniq3l8ya39a26gz5lw-python-wrapper-3.5.3/bin/python: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory
<christopher74837>that must be a bug, right? Missing dependency from either asciinema or python package...?
<boegel>civodul: also, I want to solicit feedback from you on my yet to be written presentation that got accepted to the HPC devroom at FOSDEM, where I intend to compare conda, EasyBuild, Guix/Nix, Spack & Singularity...
<boegel>seems like rekado can't make up his mind whether he's around or not...
<adfeno>Just a question to see if I'm doing this right: How do I list all packages which I have (directly or indirectly) and which have a dependency on, for example, qtbase (either directly or indirectly)?
<civodul>adfeno: you could do "guix graph -t references $(readlink -f ~/.guix-profile) | dot -Tpdf > graph.pdf"
<adfeno>civodul: Strange... it just tells me the path to qtbase store item.
<adfeno>I think I'll reuse the advice related to graphviz ,but instead try inspecting the raw graphviz file, not the PDF....
<adfeno>... I hope there are IDs inside for which I can search for...
<adfeno>civodul: Apparently, one can use GraphViz to filter nodes... but I still have to find out how to do so in such a way that only the ones which depend on qtbase (directly and indirectly) are made into the graph.
<civodul>adfeno: that would mean that nothing depends on qtbase
<adfeno>From the output of `guix graph -t references ...' I found out (although I already know) that Mumble depends on some Qt package (I think it was only "qt", but that's just for demonstration)...
<adfeno>I'll try the `guix gc ...' with "qt" only now.