<joshuaBPMan_>Hello, I'm dual booting guixSD and Parabola. I'm having trouble logging into gnome as a normal user. I can login as "joshua" in a free tty, but I cannot log into gnome as the user "joshua".
<joshuaBPMan_>I should not that my Parabola and GuixSD installs are sharing the same /home partition but have different / partitions.
<joshuaBPMan_>I've recently updated all of my packages, and run 'sudo guix system reconfigure /etc/gnome-xfce.scm', but I still can't log into gnome as "joshua". Anyone have any ideas?
<joshuaBPMan_>i just search syslog, and I couldn't find anything with "gnome" in it. Does guix use something sdm login utility?
<lfam>joshuaBPMan_: GuixSD uses the SLiM login manager
<lfam>joshuaBPMan_: Sorry I can't help more :/ My GuixSD system is non-graphical for now. If you can't figure it out, please send a message to email@example.com
<joshuaBPMan_>lfam: That's ok. And you use a non-graphical guixSD. May I ask why? server stuff?
<lfam>joshuaBPMan_: It's just an always-on laptop "server" at home. It used to be graphical but there was a bug in Guix 0.11.0's glibc package that I didn't want to work around, so I built everything from source for a few months. I could do that faster without the graphical stuff.
<lfam>I should reconfigure it now that that bug is fixed on the master branch and I can use substitutes again
<joshuaBPMan_>lfam: Ok. That makes sense. I've actually just thought of something. I going to log off now. try to log in as my normal user, log in as root and check the syslog file for any changes. That might point me in the right direction. Be back in 10 minutes or so.
<joshuaBPMan_>Well I've found some errors in my syslog. Looks like I have some permissions errors with gnome-keyring and parsing a desktop file.
<lfam>Wooow, I guess that 21531add3205e400707c8fbfd841845f9a71863a was a long time coming!
<civodul>thomasd: "guix lint -c derivation" will tell you if there's any circular-dep style issue
<civodul>it's a good idea to rebuild the relevant KDE packages though, to make sure they still builds, ofc
<rekado_>I'd like to learn how to use Geiser better when doing Guix work.
<rekado_>To be able to use M-. I need to have all Guix modules loaded into Geiser first, no?
<branko>'lo folks. Guide suggested sharing experience, so just a small comment that current installation instructions include command "ifconfig interface up" - this one by itself did not obtain IP etc (had to run dhclient manually).
<davexunit>so it works quite well for me! getting the "broadband adapter" feature to work is a pain, though. it's no fault of guix, but it requires root privileges to setup a bunch of virtual network devices.
<roelj>In a couple of days we may get root access on our HPC for guix-daemon, but now that it's almost there, the non-root solution is working quite streamlined and well that I almost feel bad to give that up.
<civodul>roelj: giving up on that brings tangible benefits too :-)
<davexunit>ludo likes to say something and then drop the mic
<roelj>It would be great fun to have the CI system deal with git pushes to package repositories. Something like git push -> CI server builds tarball -> CI server builds package with new tarball -> CI installs that package in a per-program profile -> user can directly access it through that per-program profile.
<doktaNG>okay, I think I'll send this updated epic5 package
<thomasd>Petter: though it won't magically work on every symbol. I believe expressions which are to be run by the build daemon and are quoted in the package descriptions are not analysed. (Other people on this channel should be able to provide a more proper explanation :-) )
<Petter>It looks like some configuration is needed, it says "no documentation available" for everything I've tried so far.
<thomasd>ah, yes, you need to add the path to your guix source to geiser-guile-load-path
<alezost>ng0: I mean it will work inside (with-directory-excursion (string-append (assoc-ref outputs "out") "/bin") ...). Here is a simple guile script that you can test: http://paste.debian.net/900959
<alezost>(assuming you have "/usr/bin/env" and guix modules in your GUILE_LOAD_[COMPILED_]PATH)
<ng0>ah right, the directory excursion i asked for in the mail i've just sent
<civodul>lfam: does it fail to new offload issues or something else?
<civodul>i just fixed an offload issue as i wrote on guix-sysadmin
<lfam>There was a spurious failure of gobject-introspection on staging. It succeeded when I restarted the build of that package. But the thousands of failures that resulted are still failing. Should I request a new evaluation?
<civodul>instead you should request to "restart all dependency-failed jobs"
<civodul>in the "actions" menu of the evaluation page
<ng0>there was this gentoo tool I used for this, you could list all builds, all builds of a certain application and the build which is currently happening and depending on wether there was previous recorded data it would give you an ETA
<lfam>david1: Supporting interactivity in the builds would break the functional packaging model? How would the human interaction be accounted for?
<lfam>And yes, building webkitgtk takes a very long time
<lfam>david1: Do you get what I mean? The functional packaging model tries to take all the inputs (source code, build scripts, etc) of a build into account, so that binaries can be substituted for building from source, but still be expected to provide the equivalent result. If a human do interact with the build process non-deterministically, this breaks the model
<lfam>Where do you think it would be useful to have a yes-no dialog?
<davidl>yeah I see kind of. I have programmed some haskell but Im not a developer.
<davidl>while invoking the guix system init command with a flag.
<davidl>I used --fallback so it would build packages from source which it couldn't download as binaries for some reason.
<davidl>but since those build processes take so long in case of webkit then maybe you would want to individually say to not build some packages.
<lfam>I typically use --dry-run before "big" things, to make sure I'm ready
<davidl>I was gonna do full disk encryption but needed lvm2 for grub to notice mapped devices.
<lfam>I was going to suggest `guix pull` after explaining some caveats. But since you already did that, I think that we must have made some change recently that requires a webkitgtk rebuild, and that rebuild is not done yet
<lfam>My best recommendation is to initialize with an OS configuration that doesn't require any graphical packages. Once you have the system installed, then reconfigure into a graphical system.
<davidl>The build can run overnight =) not a big problem really.
<lfam>Initialization is still somewhat brittle, so I prefer to init with the simplest system possible. Once installed, the system is very robust and you can reconfigure, roll-back, etc
<lfam>But, if you are willing to run your x200 overnight, I think that webkitgtk will be done by then :)
<davidl>mhm. Ill try that if it doesn't when I wake up.