<ryanprior>How's support for Guix on non-free platforms? If you have a codebase that'll build for GNU/Linux+Windows+macOS and you create a package definition for it, can you use guix to build it for all 3? Or on the hardware side, how about support for ARM, anybody testing that?
<lfam>ryanprior: Basically no support for those platforms. Guix depends on glibc, which doesn't work on macOS or Windows as far as I know. We support armv7 and armv8
<lfam>Hm, for some reason shepherd has recently begun to fail to start ssh-daemon on boot
<lfam>Does anyone know I can find the effective sshd.conf?
<mbakke>lfam: Look up the shepherd config in the process tree, then inspect the ssh-daemon.scm.
<lfam>mbakke: I did that after `herd start ssh-daemon`, which does work. I thought I'd be able to find it in /run/booted-system, but I couldn't
<lfam>Currently building a new service with -d -E /tmp/sshd.log
<mbakke>It should be the same config. Did you get anything in /var/log/messages?
<lfam>mbakke: Nothing that stands out to me, except for "shepherd: Service ssh-daemon could not be started.".
<bytes83>Does guix reconfigure remove all the packages i have installed separately which are not mentioned in the config file ?
<lfam>bytes83: No, you can still do package management with each user. The packages in your config file get installed additionally, and are available to all users
<Apteryx>Still stuggling with gdb... it's not breaking inside a utils.cc file which is in the same folder as test-utils.cc. Strangely one of its function is called correctly, but stepping in is not possible.
<mbakke>Pulling the same branch as a different user does not seem to re-use the existing builds though. But I did see a TODO about recording #:commit with Guile-Git. Are these derivations not fixed-output?
<mbakke>I don't seem to have built /gnu/store/kv8m51s68g4zl4z3crachsszzqdrjc47-guix-45c941484.drv though.
<Apteryx>is there an equivalent to <time.h>'s time that would return the *localized* number of seconds since epoch?
<Apteryx>my gut tells me if we were comparing apples to apples it might help to start with.
<civodul>Guile has things like that, but i'm not sure what you're trying to do
<civodul>isn't the problem that the test expects to be in a specific tz and in DST?
<Apteryx>I thought, I'd put words on this, but code is clearer. Basically the tests of mu are flawed in that it's using a reference of current (non localized) time for the tests but the function being checked use a localized time through g_date_time_new_now_local (a function defined in glib).
<Apteryx>the functions under test can manipulate time by going back say 2 weeks, so the test feeds '2w' to the function and observes the date returned (as the number of epoch seconds), and compares that value with the current time substracted by 2 * 7 * 24 * 60 * 60 seconds (2 weeks). So the only issue here is that the tests use <time.h> time() (non-localized, right?) to get the current time while the functions tested
<hooverville>hi guixers, most of my guix commands are resulting in: "guix pull: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist". all my commands worked prior to running a guix pull as root (ie. I had setup build-users-group correctly)
<lfam>nckx, ng0: We don't allow history rewriting on savannah, so deleting and re-pushing is how one rebases or amends commits on the savannah wip- branches
<lfam>thorwil: After you've built your Guix, there is a script in the source directory called 'pre-inst-env'. Prefix your Guix commands with that script, and you will use the Guix you built. Assuming you configured it with --localstatedir=/var, it will share the store
<lfam>Actually, I do like that the hook fails when pushing a new branch. It forces the user to think for a minute about signatures, and they may have forgotten. If it only printed a warning and pushed the branch, then we are relying on the server's receive hook
<lfam>But, we could update the range so that it happens more quickly
<mbakke>I'll bounce something off guix-patches in a few days if no one beats me to it.
<lfam>The thing is, bad signatures *have* gotten into the repo. It's not a totally esoteric concern
<lfam>I'll send a message to guix-devel summarizing the discussion and possible improvements