<axd-v>Hey, so if I want to replace slim dm with just manually running startx to execute my .xinitrc, how would I go about that? I use EXWM so in order to make things like changing and setting proper xkb layouts and startup items run like redshift and owncloud-client I need to have access to add things to my .xinitrc manually, or how else is it proper to make this work in guix? Maybe creating a herd service.. doesn redshift already have one
<axd-v>predefined for example? Usually these things would be in my .xinitrc or as a systemd service file.
<axd-v>Unrelated: qemu is failing to build on the latest guix commit with these messages:
<axd-v>I love this machine honestly. Been thinking a bit about doing a 1080p mod to the screen and then it would be even more perfect.
<lfam>And I'm at the same Guix version. I think the test failure may be non-deterministic. Can you try again with the '--keep-failed' option? That way, if it fails, we can see exactly which test failed and how and work around or disable the faulty test
<axd-v>I have the info on which test failed since it's only 1 out of 91
<lfam>No, mine is stock, running Debian with Guix. My screen is not very good, really. I've thought about upgrading the screen for better colors
<axd-v>lfam: yeah, I'm just not used to using a graphical dm. With slim I would have to inherit the package and change its config in order to change what stuff gets brought up? How would I get slim to make redshift start at login and setxkbmap to run?
<axd-v>with startx workflow I just modify the .xinitrc bash script. Straight forward, but gotta get rid of slim first.
<lfam>I'm not sure. I think other people have discussed it though. I would search the archives of guix-devel and help-guix
<axd-v>So I just ran `guix package --keep-failed -u` again, during which a test during compilation of qemu's dependency failed earlier, and nothing came up about qemu, but keepassx failed with this message: "https://paste.debian.net/1027530/"
<axd-v>I still have the build directory thanks to the flag, but I'm not sure where to find a relevant log about this particular failure.
<axd-v>I don't know why there is such undeterministic behavior at the moment, using the latest guix commit version, but I'm gonna rerun the command to see if it fails on something else this time.
<axd-v>Now `guix package -u` fails reliably on keepassx compilation with the same message as the one in the above pastebin link.
<soundtoxin>I've noticed some things that come to mind, suvh as openarena, are not packaged, so I jiust wanted to see what was there
<axd-v>So I have found a way to disable slim, just by excluding it from the %desktop-services list, but now startx fails to work. It complains that /gnu/store/*xinit-1.4.0/bin/X doesn't exist so it doesn't know which xorg to use.
<axd-v>The error message before the one I described above is actually about xauth and home there isn't some file in my home directory that's needed for it. Don't know what that's about, maybe it's the culprit since it's the first printed error.
<axd-v>Xauth complained about $HOME/.serverauth.1436 file being missing.
<civodul>could you run "readelf -a /tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/bin/qvkgen | grep RUNPATH"?
<civodul>Rust takes *ages* to build and it's sequential
<efraim>Yeah, it was about 12 hours for each one on aarch64
<rekado_>ldd shows me that libQt5Core.so.5 is not found.
<rekado_>readelf shows me that this is the RUNPATH: $ORIGIN/../lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..
<cbaines>I think I've got this Elixir issue nearly wrapped up! The /bin/sh patches turned out to be needed in the erlang package, all that changes with the elixir package is just removing all the deletion of tests :D
<rekado_>Copenhagen_Bram: that depends on your configuration and on availability of binaries.
<rekado_>we recommend installing a minimal system first to reduce the initial setup time.
<rekado_>once you *have* your initial system you can conveniently reconfigure it and benefit from roll-backs.
<rekado_>installing a big system (with desktop environment and so on) right from the start may take a long time and end with errors that you’d have to fix in the uncomfortable environment of the primitive installer system.
<rekado_>civodul: I wanted to merge master into core-updates, but the changes to the tests are not obvious to me.
<Copenhagen_Bram>Oh. So how is GuixSD installation different to an Arch/Parabola installation?
<rekado_>frankly, I think it’s nothing like Gentoo.
<civodul>yeah, transactional upgrades and rollback, etc.
<Copenhagen_Bram>pkill9: Well, it *can* be if you make it FSF compiant. Except I bet their minimal live distribution uses Linux with blobs, and I know for a fact because I tried it, the full livedvd gentoo thing uses Linux and Firefox.
<rekado_>even when it comes to compiling from source: you *can* build everything from source with Guix and sometimes you need to let Guix build things for you locally, but the experience really is quite different.
<rekado_>FWIW we also don’t have iceweasel in Guix ;)
<uniq10>Hi, I have having a little trouble in designing the scheduler/worker for building derivations. The C++ code maintains a lot of state and state updates and I end up passing all of it around. I don't know if that is a good approach. What style would be more appropriate while doing it in scheme?
<rekado_>Copenhagen_Bram: they are not privileged in any way and follow the same process that real users would follow.
<rekado_>uniq10: sometimes the most appropriate thing is to use a monad (e.g. the state monad for serializing actions that operate on complex state).
<rekado_>sometimes it is fine to pass around an alist.
<rekado_>yet other circumstances may be best represented with a fold that accumulates state as a composite object.
<rekado_>uniq10: can you describe what the state that needs to be captured looks like?
<rekado_>Copenhagen_Bram: we currently have two build farms. One is the distributed hydra.gnu.org (and a caching mirror at mirror.hydra.gnu.org). The other is a more centralized cluster of 20+ servers at the institute where I roam the corridors during the day.
<uniq10>rekado_: For example when a set of derivations is given to the daemon to build, if the inputs to those derivations are not present they need to be built too. To proceed with the target derivation build I need to keep track of the input derivation build status.
<rekado_>uniq10: can this be determined before the build starts?
<rekado_>I’m imagining a procedure that takes a single derivation (or a set of derivations) and returns all derivations it depends on that haven’t been built yet.
<rekado_>(I think something like this already exists.)
<rekado_>uniq10: we have “derivation-prerequisites-to-build” — does this help at all?
<uniq10>rekado_: Yes we know that before the build starts, but in the C++ code the builders of an input derivation (of a target) check if any of the other input derivations (of the same target) failed and if so they terminate immediately. How will I be able to do this?