***fusion809_ is now known as fusion809
<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. <ofosos>Does someone read the new bug reports from guix-patches, or do I have to ask someone to review this? <fusion809>Well in the mean time I'm going to see if installing pam-krb5 fixes this error as DuckDuckGo'in returned some results that suggested pam-krb5 may be related <fusion809>Well that didn't work. Must admit I didn't think it'd be that easy. <str1ngs>fusion809: have you set the user to have a password? <fusion809>Oh yes, before I changed config I had managed to log in to SLiM manually. <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. <fusion809>Ya sounds like it, the only thing I know I could try is re-installing pam. <fusion809>Well I ran `guix package -i linux-pam` and oddly it didn't seem to be re-installing the package, seemed like it wasn't installed. Then I rebooted and still can't log in. <str1ngs>anything in /var/log/messages or /var/log/secure <fusion809>There's some "couldn't access control socket" errors in /var/log/messages, are they relevant? <str1ngs>not seeing an error in that paste. just looks like your ssh-agent is not being evaluated <fusion809>Rofl I thought I copied that paste properly. That's not it. I'll pastebin /var/log/messages /var/log/secure and the error I got from gnome-session. <str1ngs>also you might have a ~/.xsession-errors <str1ngs>how do you start X with xinit? startx? I could not figure that out with guixSD <fusion809>Well I was going to use xinit but I decided to go with starting GNOME on Wayland instead. <fusion809>Apparently ol' wgetpaste doesn't want to paste /var/log/messages, says there's no input. <fusion809>Decided to comment it out to see if I could log in manually. <str1ngs>I think it's still trying to autologin <str1ngs>Dec 14 13:32:00 localhost su[397]: Successful su for fusion809 by root <str1ngs>Dec 14 13:32:00 localhost su[397]: pam_elogind(su:session): Cannot create session: Already running in a session <str1ngs>it seems to su to user, then tries to create a seesion but one exists <fusion809>Ah that could be because I'm issuing su commands. Logging into my user account from root and vice versa. <fusion809>TTY, I can't seem to start GNOME so I'm at the command-line. <str1ngs>can you login as your from virtual terminal? <fusion809>Would it potentially be a good idea to try to do a fresh install with my custom config file? Maybe then SLiM will login well. <str1ngs>sorry I meant, can you login as your user from virtual terminal <fusion809>Oh yes I'm managing to log in as my user fine <str1ngs>I think some state is borked with reconfigure <str1ngs>would it be a real pain to do a fresh init? <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 <str1ngs>then F1 to i3 session see if that works <str1ngs>you might need to add wm to use-package-modules as well <str1ngs>barring that, then maybe start with a fresh init. <fusion809>Must admit I'm surprised that the GuixSD live ISO doesn't come with a more advanced editor like GNU Emacs or Vim. I doubt many developers like using Zile as their primary editor. <fusion809>and GuixSD is oriented more towards power users which are often developers <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 <fusion809>Decided to revert back to the vanilla one with no autologin <fusion809>Can't wait 'til GuixSD 1.0 comes out, I wonder if it'll be suitable for beginners or at least less intermediate users (like those that can manage Fedora, Mageia, OpenMandriva Lx, etc.) <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>I only use docker when I need to test some specific distro for something though <str1ngs>For my other workflows, I'll probably switch to guix now <fusion809>Done that too, it's a great way to test the speed of several package managers in a nice and fair way. <str1ngs>speed, I think archlinux is still the fastest. dnf though is best of both worlds. but I think guix super seeds in-terms of features. <str1ngs>I personally wrote my own package manager. which I'll probably discontinue now that guix is getting more polished. <str1ngs>somethings to take into account is transactions. which pacman is bad at <fusion809>True my article is somewhat outdated as in the mean time I've tried out several other package managers Guix, Nix and XBPS included. <str1ngs>guix and nix are pretty much on par. short of declaration language. <str1ngs>fusion809: did you use guix system vm to build this? or using a boot ISO in a vm? <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. <fusion809>I wonder if the fact that whenever I run chsh -s $(which zsh) I get: "chsh: PAM: Authentication failure" (and yes zsh is installed) <efraim>Are you trying to change your shell? It should be set in your os config <efraim>Not sure how much shells other than bash are supported though <fusion809>G expressions confuse the hell out of me, I read the docs, but goes right past me, I just want to know how I define it for the shell. <rekado_>fusion809: there is no state that could be borked. A reinstallation would be pointless. <fusion809>OK well I was just told that changing shells should be done in my config file, so how else do I effect such a change? <rekado_>you reconfigure, but you wouldn’t reinstall. <fusion809>Yeah that's what I was doing... guix system reconfigure. Sorry if I mislead ya somehow <fusion809>I need to know how to write a "G expression" for setting my shell. <fusion809>Using (shell "path-to-shell") under (operating-system doesn't do it. <g_bor>rekado_: I'm looking around this issue with hamcrest-core. It build fine on master, and from Chris's log it seemd to build on core-updates a few days ago. <g_bor>rekado_: I'm now checking if it still builds on core-updates. <fusion809>Got it, had to add the shell line to the (users section. The problem is how does one that do that for the root account. After all there's no root entry (users. <civodul>fusion809: it should be something like (file-append zsh "/bin/zsh") <fusion809>OK, that sounds like a great way of making it easier to find zsh on my system but are you sure that'll change root's default shell to zsh? <fusion809>That expression gives the error: 'error: invalid field specifier' <civodul>specifically you need (user-account ... (shell (file-append ...))) <civodul>but you're right, that doesn't change the shell for root <civodul>because that one is added automatically <efraim>mb[m]1: I tested the latest updates to core-updates, gtk[23] and qtbase build fine on aarch64 <rekado_>g_bor: with the fix for 29700 we’d have to rebuild all Java packages. <rekado_>cuirass was weird again: there were dozens of offload processes, but cuirass was idle and none of the build nodes were actually doing anything. <rekado_>one of the build nodes died — maybe that one was important and cuirass didn’t detect that it died? <rekado_>there are two HPC sysadmin positions in Berlin. <efraim>If I had a degree and lived in Berlin I'd be all over that <mnn>hey guys, it would be great is you added wvdial so that people with modems only can access the internet during installation <wingo>guix grumble: i need gobby at version 0.4, not 0.5. they are incompatible. every time i guix package -u though it upgrades me <g_bor>do we have an easy way to find out what derivations are currently being built? <snape>fusion809: you can stop slim with "herd stop xorg-server" <fusion809>Thanks I'll keep that in mind next time I'm in that sort of situation with SLiM <snape>I think it's the kind of info that should be reported by "guix system search"... Maybe I'll file a bug. <g_bor>wingo: I think you can use the --do-not-upgrade switch of guix package. <rekado_>wingo: this won’t happen if you use manifests <g_bor>wingo: something like guix package -u --do-not-upgrade gobby <g_bor>And rekado is also right, it can be done with manifests. <rekado_>g_bor: but this will keep old references in gobby, so by not upgrading it you would accumulate vulnerabilities. <rekado_>so manifests are better in this situation. <wingo>interesting, i will read up on that <g_bor>rekado_: regarding the java packages, I think for now I will assume, that merging core-updates to my java8 branch won't break new package, I will try to fix what is broken, then try a merge. <g_bor>If that work, then we could talk about how to get that to a build farm for evaluation. <g_bor>If in the meantime something broke because of new things in core-updates, then we can fix that. <efraim>I think my store on my laptop is publishing on ipv6 only <efraim1>hmm, if I just put (service guix-publish-service-type) then it should just work, right? <efraim1>right now i'm specifying port 3000, and it shows: publishing store /gnu/store on ::1 port 3000 <snape>efraim1: it seems that guix-publish uses make-socket-address once, so it won't be able to listen both ipv4 and ipv6. I believe the easiest way to get both protocols is to do an nginx proxy. <efraim1>snape: thanks, i'll have to think about that <snape>the nginx proxy will also give you https support :-) <rekado_>I started building webkitgtk on berlin and the node that built it died. <rekado_>that’s the second time this has happened. <rekado_>two nodes down because of webkitgtk, hmm. <sneek>civodul, you have 2 messages. <sneek>civodul, wingo says: i think we need to release a 2.2.4 soon, i think the fresh-auto-compile that was committed does the wrong thing <sneek>civodul, wingo says: as the documentation notes, setting %fresh-auto-compile should only invalidate the auto-compilation cache (the one in ~/.cache), not all precompiled .go files <roptat>I've finally built the latest groovy :) <roptat>now there's an issue with gradle: I've built a few components, but looking at how it starts, it expects to find all its jars and its dependencies' jars in the same directory <roptat>I've looked for a way to give it a list of directories where it can find its dependencies, but I didn't find anything <rekado_>some build.xml files override the CLASSPATH <roptat>I'm confident I can build gradle without any issue <rekado_>easiest way to satisfy them is to link dependencies into the expected directory. <roptat>because it requires all its dependencies in the same directory at runtime <rekado_>you could install links to the dependencies into the output directory <roptat>ok, I think it would work, thanks :) <buenouanq>(audacity:31603): GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is not installed <g_bor>The Hungarian FSF group asked me to hold a persentation on guixsd in February. <g_bor>I wonder if we have a beamer template, or some other form of artwork for things like this. <civodul>hopefully you can find something useful there <mb[m]1>bavier: Did you manage to fix the remaining Guile 2.0 problems? <mb[m]1>Whoa nvm, I was actually able to build current guile2.0-guix. <bavier>mb[m]1: yeah, the last fix was pushed Sunday <mb[m]1>bavier: Sweet, thanks for your work on that. Not sure why building the current 2.0 snapshot worked though, since it's from an older commit. <bavier>mb[m]1: maybe a commit prior to "download: Improve efficiency of 'write-request' over TLS."? <mb[m]1>Maybe. It's the v0.14.0 tag IIRC. Too lazy to check. Did that commit break things again? :P <civodul>mb[m]1: any particular reason for using 2.0? <mb[m]1>civodul: after splitting up the huge modules and forcing parallelism not to exceed 8 jobs, probably not on this 40-core server. <bavier>I was wanting to put together a sort of "guix-minimal" package that uses guile@2.0.9 and leaves out guix's optional dependencies, as a sort of CI test <mb[m]1>But compiling package modules is much faster, so no good reason to switch back to 2.2 ;) <bavier>but I discovered that guile@2.0.9 has a failing test that I haven't figured out how to fix :/ <civodul>with 2.2.3 it's faster than with 2.2.2, but still slower than with 2.0 <bavier>civodul: because we advertise support down to 2.0.9 <civodul>i'm asking because it would make sense to require 2.0.14, or so i thought <civodul>ok, but you use 2.0.9 not just because Guix claims to support it i guess <civodul>i suppose that's because your distro ships 2.0.9? <civodul>bavier: re guix-minimal, i'm all for it <bavier>but have a package build with 2.0.9 would keep our support statement honest <civodul>we need to find a maintainable way to do that <civodul>but you're saying it's guile@2.0.9 that fails to build, right? <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 <bavier>current stable Trisquel 7 has 2.0.11 <bavier>arch and parabola have 2.2 and 2.0.14 <bavier>the systems I have at $dayjob are stuck at 1.8.5, ha <str1ngs>fedora 27, has guile 2.0 guile-tls 2.0 also guile 2.2 but no guile-tls 2.2. <bavier>efraim: "close to ready but still pending some important tasks" <bavier>str1ngs: do you know the subminor/patch version? <civodul>bavier: it Should Be Easy™ to fix, though it's unclear to me how useful that is :-) <boegel>any of the guix@hpc folks around? <boegel>close to releasing EasyBuild v3.5.0 <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...? <bavier>christopher74837: seems like a bug, yes <bavier>christopher74837: do you have libexpat in your profile? <bavier>christopher74837: you could try installing it and pointing LD_LIBRARY_PATH to the lib directory in your profile <efraim>guix gc --references $(guix build asciinema) doesn't show libexpat <christopher74837>hmm... might be more trouble than it was worth... just was installing it to try and install something <efraim>I was actually on my way to bed, just thought I'd check if it even referenced it <g_bor>graph.scm still fails on core-updates <adfeno>Geess.... Qt-related stuff takes a long time to build.... <adfeno>Strangely enough our package for GNU R seems to depend indirectly on Qt. <adfeno>(I wasn't able to find where the true dependent package is) <cbaines>Does anyone know if GuixSD supports setting up both v4 and v6 IP addresses on the same interface? I just tried it, and the shepherd service names conflicted. <boegel>I've been wanting to shoot you, Ricardo and Pjotr a mail to invite you to pass by at the EasyBuild User Meeting in Amsterdam (week before FOSDEM'18) to give a talk on Guix@HPC <civodul>that's a bit of extra traveling but perhaps we could arrange something <civodul>it'd be interesting to hear the EasyBuild perspective, i think we could learn a lot from your experience <boegel>civodul: there'll be people using Nix in HPC context too <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... <civodul>i don't really know conda, rekado_ knows it quite well i think <civodul>(i won't solicit feedback on mine because it's far from ready ;-)) <boegel>civodul: I haven't even started mine yet, but it's something I've wanted to do for a while <boegel>oh excellent, I'm still looking for someone who has experience with conda :) <boegel>yeah, many people are wondering how these tools compare, if we can't come up with a decent comparison, nobody can ;) <civodul>so yeah i think rekado_ and probably Pjotr are quite familiar with it <boegel>I plan to make it an objective comparison, which is exactly why I need feedback from others, I'm obviously biased <boegel>btw, the Spack lead dev will be at FOSDEM too (sadly not at the EB user meeting though) <civodul>we'll all biased, so if you get feedback from everyone, it'll be somewhat balanced ;-) <boegel>I definitely plan to get feedback from everyone, which means I need to start well ahead (which is unusual for me) <civodul>i'll forward the user meeting link to the guix-hpc cabal <boegel>civodul: well, there's definitely a talk slot for someone to present Guix@HPC <civodul>i don't know yet if i can make it myself (work, family, etc.) <boegel>it may be easy for Pjotr to make it, since he's in .nl <boegel>well, I'm off, we'll be in touch! <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>I once tried to open a big PDF that came from GraphViz, and it was so big that the OS froze. :S <civodul>you can also try: guix gc --referrers $(guix build qtbase) <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.