IRC channel logs
2018-03-27.log
back to list of logs
<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[1]: Service ssh-daemon could not be started.". <mbakke>Disconcerting. Hopefully you'll be able to reproduce it with debug logging enabled. <lfam>Yes, I already eliminated some other "variable", like my custom openssh package <mbakke>Perhaps it requires udev, or something. <mbakke>The OpenSSH service currently has no service dependencies. <lfam>It does require syslogd, right? <lfam>I would guess it should require networking, like the lsh and dropbear services <lfam>For some reason shepherd kills (15) the sshd after it starts :/ <lfam>The debug log shows a successful start and then ends with "Received signal 15; terminating." <mbakke>The networking requirement was removed by yours truly a while back, so that we could include the service in the installation image without static-networking or dhcp-client-service. <lfam>(the requirement removal) <lfam>I guess that the recent update of shepherd could be the culprit <mbakke>Maybe... But then it's a different issue from what myglc2 had. <lfam>Yes, but they didn't provide enough info in their report to say <mbakke>lfam: In the Shepherd code, I see it sends SIGTERM if it fails to read the PID file. <lfam>And I lack the PID file at /var/run/sshd.pid <lfam>It should be created by the openssh-activation <mbakke>I wonder if it even needs the PID file, since the service runs in foreground. <mbakke>But it hints at a race condition in Shepherd regardless. Maybe. <lfam>I was mistaken. The openssh-activation create the PID-file directory (/var/run) <mbakke>Does the failure to start only happen on boot? <mbakke>(make-forkexec-constructor ...) takes a #:pid-file-timeout argument as well. <lfam>mbakke: With recent Guix (3c1ae2a6370f3d2554fe4e8e8a52f404bcde680e), the failure only seems to happen on boot. I can manually start the service as root with `herd start ssh-daemon` <mbakke>lfam: Can you see if adding a #:pid-file-timeout makes a difference? <lfam>I had added some debugging flags to the sshd invocation, and that caused the service to always be killed by shepherd after starting (-d -E /tmp/sshd.log) <lfam>I touched `/var/run/sshd.pid`, but after trying to start the service, that file is gone <mbakke>Did you get anything in the log? <lfam>I don't know where to set the pid-file-timeout <lfam>The /tmp/sshd.log just shows normal sshd startup before being killed with 15 <mbakke>lfam: Add it in (gnu services ssh), around line 461. <lfam>Thanks. I think 30 seconds should be enough <lfam>Hm, I tried the following, but it failed with "extraneous field initializers (pid-file-timeout)" <lfam>(start #~(make-forkexec-constructor #@openssh-command #:pid-file-timeout 30 #:pid-file #$pid-file)) <lfam>I reverted to my last good GuixSD generation, and in that case, Shepherd is at version 0.3.2, and the sshd.pid is created <lfam>There's no way to figure out which commit I built it from, right? <lfam>Well, knowing my habits, it was a commit from that date (March 21) <lfam>There are not very many commits since then. I will bisect <mbakke>You can try to revert the Shepherd 0.4 upgrade to verify whether that's the issue. <lfam>I tried that, no luck :( <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. <civodul>i'd say "merge it all", but then again i don't know much about ghc <jboy>oh, will this make it easier to have a pandoc package for guix as well? <rekado>civodul: I wasn’t sure about “ghc-haskeline” and “ghc-process”, but I’ll check them and merge if it’s okay. <rekado>does that show module dependencies from (gnu packages guile) to other modules? <jboy>rekado: oh cool, somehow I missed that. <civodul>there's 'music', 'haskell-check', etc. <rekado>obvious culprits are (gnu packages sdl) and (gnu packages python) <rekado>we could separate the language packages from the packages using Guile. <rekado>maybe that would be a good thing to do for all language implementations. <civodul>try out something new! guix pull --branch=wip-pull-multiple-derivations <rekado>ah, so *that* is why you asked :) <civodul>i have a patch to do "guix graph -t modules guile" <rekado>since Guile is a bit special I’d just split the module. <civodul>but then we'll have gcc, and linux, and... <rekado>Hmm, I don’t know if it’s doing anything. It tells me that two derivations will be built, but that’s all output I see. <civodul>it's building the module closure for compute-guix-derivation :-/ <roptat>is it to reduce memory usage of guix pull? <rekado>first progress is indicated with messages like this: “Failed to autoload make-session in (gnutls)” and similar. <rekado>and a bunch of other warnings which probably should be suppressed. <rekado>now it’s downloading guile-git, guile-ssh, libgit2, libssh, openssl (static and doc). <rekado>and then it grafts, prints deprecation warnings and starts compiling 40 files, then 105 files, then 407 files. <rekado>I don’t know what these files are. <rekado>It would be good if it said what it is doing there. <civodul>so the first part with its warnings and all is module-imported-compiled.drv <roptat>it seems to be working for now even with only 512MB of RAM <roptat>it's better than 2GB required for building master <roptat>it's dangerously approaching 100% <roptat>compiling... 8.1% of 407 filesbuilder for `/gnu/store/8qx67jnpy9ln9vgzhjv2gpq7yqk95r2p-guix-packages.drv' failed due to signal 9 (Killed) <civodul>i suppose this part still needs 1G or so <civodul>we should be able to split it further by analyzing the module graph <rekado>it completed here after about 15 mins, not including the git fetch, but including the download and grafting of some packages. <civodul>in the worst case where you have to rebuild everything, it takes as much time as before <rekado>improved reproducibility is worth the change, in my opinion. <civodul>hopefully we won't always be in the worst case <rekado>having that trampoline is very neat. <civodul>but then the thing that remains silent for minutes isn't great <rekado>I’m measuring the time for “guix pull” now. <mbakke>The builder for "guix-packages.drv" failed with: <mbakke>In procedure private-lookup: No variable bound to define-module* in module (guile) <mbakke>This is an offloaded build FWIW, I have a "native" pull still running. <civodul>i've since that once, and it's very likely a guile multithreading issue <civodul>why it shows up in this case and not with the "big" guix pull is a mystery <civodul>for now, if you retry, it may work... <bytes83>Does "guix pull" and "guix system reconfigure" work with sudo ? Or should i relogin as root and execute these commands <Apteryx>if anyone has a good suggestion to fix those tests, feel free to chim in! <Apteryx>another reason to dislike summer time ;) <mbakke>Does the daemon use the local time? Perhaps it should set TZ=UTC? <civodul>the build env doesn't contain tzdata unless you explicitly add it and set TZDIR, which i guess is the case here <mbakke>civodul: Retrying the pull did indeed work. <mbakke>I have a 75% success rate now ;-) <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>civodul: civodul, correct, mu does that setup (pull tzdata and sets TZDIR) before running the tests. <mbakke>Ooh, pulling again did not rebuild anything at least. <civodul>i found a source of discrepancies while comparing on different machines <civodul>%guix-register-program in (guix config) could differ from machine to machine <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 <Apteryx>looks like I could probably just take time_t t = time(NULL); tm tlocal = localtime(&t); or something like this <mbakke>Oooh, I never knew how much I missed `guix gc --derivers`. <civodul>i got used to using 'valid-derivers' at the REPL and then realized we could do better :-) <thorwil>a guile repl started via `guile --` doesn't react to (quit)?! <thorwil>what's the least effort way to test a single service addition to desktop.scm? <thorwil>i guess i could `make`, point ~/.config/guix/latest to the edited checkout. adjust my config to use said service and do a reconfigure <thorwil>so you more or less require the reader to infer that `make check` will trigger a build on one page. elsewhere it is suggested to use separate `make` and `make check` <rekado>sneek: later tell civodul Regular “guix pull” took 22 mins, so the new guix pull is an improvement in that regard as well. <nckx>Apteryx: I feared such a silliness. Impressive debugging :-) <nckx>‘guix pull’ in... under 2 hours? :-o April fools is still some days away, peoples. <rekado>it only takes 2 hours if your system is swapping, but even then I think 2 hours is optimistic ;) <rekado>davexunit: guix pull --branch=wip-pull-multiple-derivations <davexunit>rekado: cool. looking for the mailing list thread that will explain what the changes are... <davexunit>rekado: is there a thread for this? having trouble finding it <davexunit>what a great solution to a bootstrapping problem <davexunit>now it's possible for someone to run 'guix pull' and actually get substitutes for it. brilliant! <ng0>what happened? I just saw a guix pull bug report I made a while ago jump into activity view in my inbox again :) <ng0>I mean: what exactly? I only read as far as "Oh no, guix package builds crash on 512 MB RAM" <rekado>ng0: just read to the end then :) <ng0>(and I agree, we have strange standard when 512 MB is considered small :)) <ng0>okay.. no tl;dr? then I'll read it i nthe next days <rekado>there are only two new messages. <ng0>blame my email client. <ng0>pulling with a different unix account now, see how far this gets. <ng0>guix pull: error: Git error: cannot locate remote-tracking branch 'origin/wip-pull-multiple-derivations' <ng0>git fetch'ing all of upstream in my guix repository shows no such branch <ng0>the most recent ones are staging and the rhel branch. maybe ludovic didn't push it. <nckx>I thought I saw it being deleted on git-commits (?) <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>hooverville: What distro are you using? <lfam>Our recent glibc update removed some obsolete interfaces still used on Debian (and maybe other distros) <lfam>I did `apt-get install nscd` and everything has worked since then :) <nckx>lfam: Ah so, tx. Didn't know that the prohibition extended to wip- branches. <lfam>Yes, and the wip- branches are the only ones where this sort of thing is "allowed". I think the wip- means "history may be rewritten". <nckx>lfam: Right, but allowed by convention, not technically, right? <lfam>Definitely by convention! I've never tried deleting the master branch, so I don't know if there are technical restrictions on it <nckx>Yeeeah... that crossed my mind right now :-) <lfam>Definitely a case where it's better to ask for permission than forgiveness :) <nckx>ACTION 's brain has that creepy edge-of-cliff ‘oh go on...’ vibe goin' on. <ng0>master is just a naming convention <lfam>Yes, it's true. We could call it whatever we like <mbakke>Bah, #:configure-flags is broken in meson-build-system. <nckx>ng0: Eh? No reason you can't set up per-branch rules, no matter what the name. <snape>Yes, but it's a usual practice to setup rules based on branch names. I don't think it's possible to force-push on master for example. <ng0>i don't use savannah. <ng0>you can force push to anything when you have the remote like that <ng0>what my problem was before I walked away: what ludovic mentions doesn't work. <ng0>merged into master then? or another branch? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado says: Regular “guix pull” took 22 mins, so the new guix pull is an improvement in that regard as well. <thorwil>how can i take a separate, edited guix clone to a test-drive, while making use of what's in the current store? <lfam>thorwil: By "edited guix clone" do you mean a Guix you built yourself from source? <mbakke>civodul: Adding #:configure-flags causes it to be appended to the "build-dir": <mbakke>Build dir: /tmp/guix-build-zathura-cb-0.1.8.drv-0/build/install_dir=/gnu/store/lly5952fq3qdfa7xfxwgpv7f4dq9zsxa-zathura-cb-0.1.8/lib/zathura <mbakke>I don't immediately see why though. <mbakke>But we may need a staging round before core-updates. <civodul>mbakke: well i guess we still have a couple of days to fix it in core-updates <mbakke>(the configure-flag I added was "install_dir") <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>ACTION tests the build of OpenSSL 1.0.2o <mbakke>civodul: I'd prefer to fix it before core-updates though, since we may need the fix on 'master' before core-updates can be merged. I'll bring it to guix-devel. <lfam>Is it expected that replacement packages need the 'name' field set again? <civodul>well, it depends how you create them <lfam>Ohhh, I see! name is used to create the uri <lfam>How many ways are there to create them? :) <lfam>Another question: I need to remove the snippet from openssl-1.0.2n. Is the right way to make another snippet that just contains (begin #t)? <lfam>(the snippet doesn't apply anymore) <ng0>maybe we need something like the 2nd edition of the "Absolute BSD" book one day, only for Guix and GuixSD.. not that it should replace good documentation.. <thorwil>it has been too long since i last used git. the way to a patch is: git add /changed/file; git commit -m "reasonable message"; git format-patch master ? <ng0>in our case the commit doesn't fit in a one line message <ng0>and git format-patch HEAD~ if it's one cange. <nckx>thorwil: That's exactly what I do. <nckx>Well, almost. ‘git send-email’ replaces ‘format-patch’, and I usually use git -am "foo" / -pm "foo". I find git add tedious. <snape>(Or, if you use Emacs, you might want to use Magit :-)) <snape>(If you don't, it's worth switching just to use Magit.) <civodul>/gnu/store/nscnmzb0xkl5jsmiwfgzvqgp6qpca5n0-gawk-4.2.1.tar.xz.drv fails (fail to apply io.c patch, i think that's on core-updates) <lfam>`git add --patch` is the way to go :) <thorwil>i used magit before. great if used constantly. more a hindrance, if not. like many things emacs, actually. now i happen to be not in the continued-use camp :} <mbakke>Nvm, apparently meson appends all arguments that does not start with '--' to the build directory(??). <mbakke>So the problem is that I don't actually have a way to override the installation dir for this package. It uses a custom install target instead of --prefix. Yay. <nckx>I feel many conflicting emotions. <snape>nckx: GuixSD is designed to work with other kernels by the way :-) <snape>The Penguin is Linux's mascot <nckx>Yes, because THAT's what's wrong with that image. <lfam>Where did that come from... <nckx>The absolute bowels of hell. <lfam>So Guix appeals to both heaven and hell ;) <nckx>All I wanted was a pretty “guixsd logo” for my desktop... *cries* <lfam>We have some logs in the guix-artwork git repo :) <lfam>But, they come from SVGs in the repo <lfam>That's pretty nice oreloznog <mbakke>nckx: The "guix-artwork" repo contains the logo in a few different background colors IIRC. <nckx>lfam: Yeah, I know. I was simplifying somewhat :-) <lfam>I love the scrubbing penguin from the boot screen <nckx>I've used the SVG on Wikipedia IIRC (but sssh, don't tell them that) <nckx>lfam: I like Freedo too, but the gnu/freedo heads in the % just make it silly IMHO. <lfam>Do you remember the link to that file? I always waste so much time looking for it in our source code <lfam>Found it, in (gnu packages linux) <nckx>lfam: If you're talking to me: it's distributed as a patch. <lfam>It reminds me there is a PPM interpreter buried somewhere <nckx>So this <weird pepe-ass penguin> ‘...for your PC’ seems to be an actual 4chan meme. <nckx>Whatever else, it's crazy that GuixSD has made it that far. <lfam>Life is so weird ¯\\_(ツ)_/¯ <civodul>actually the pre-push hook wrecked havoc for some reason <civodul>it was spinning, invoking gpg and all, which is why pushing never happened <civodul>never happened before, not sure what happened <lfam>civodul: When pushing a new branch, it checks a lot of the history. This fails because there are signatures with expired keys, and even bad signatures <lfam>I turn it off when pushing a new branch <lfam>This is mentioned in the comment on line 43 <lfam>Unfortunately, I don't think there is a way to ignore signatures with expired commits. They count as "bad" from Git's perspective <lfam>We could update the hook to only check from the last release, but I'm not sure it's worth it. Pushing a new branch is such a rare case <lfam>And this is just a tool for catching mistakes <mbakke>I wonder if we can make the hook detect when we're pushing a new branch, i.e. when the number of commits to check is in the 10k range. <lfam>We can certainly do that. But what would be the correct behaviour? <lfam>The hook could print a warning in that case <lfam>"WARNING: You are pushing a new branch, and the commit signature verification is going to fail due to signatures made with expired keys. Consider disabling the hook temporarily." <lfam>"Be sure to manually verify the signatures of your commits." <mbakke>Maybe check if the remote branch already exists? Not sure what's available. <lfam>If the remote branch already exists, then it's not a new branch :) <mbakke>Or, if we know it's a new branch, just skip it and print the warning. <lfam>The local Git client tells you the branch doesn't exist remotely by setting the variable $remote_sha to an all-zero hash <mbakke>Ooh. That sounds like something we can use? <lfam>Check the else branch at line 40 <lfam>But I guess that the action we take in this case may not be the best one... <lfam>Since HACKING instructs users to copy the hook into place (rather than symlinking), I'm wary of making changes that aren't necessary, since they won't get deployed for existing repos <mbakke>Yeah, expired signatures are inevitable. <ng0>at most 630MB RAM usage. And significant faster than what we have now. At least an improvement there already. <lfam>I don't really want any diversity in the hook as deployed <lfam>I wonder if it can be symlinked <ng0>lfam: what, the hook? <ng0>I have hardlinked and symlinked hooks locally for git repos I have <ng0>depending on if they change, etc <lfam>For me a symlink has been working <lfam>It lets us deploy any changes to the hook automatically. But users may not like that? <mbakke>I think we might as well just print a warning, instead of trying to verify all commits since signatures were enforced. I always worry about forgetting to re-enable it. <lfam>Ultimately, the hook only is only going to work for very recent commits. Git doesn't expose the verification procedures in enough detail to make long-term verification feasible <lfam>Okay, how about printing warnings in that case, and changing HACKING to suggest a symlink? <lfam>And a followup announcement to guix-devel? <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 <civodul>oh, i didn't expect to generate such a discussion :-) <vagrantc>is this discussion about guix actually attempting to verify signatures from the git repository? or just about verifying signatures as they come in? <mbakke>vagrantc: The guix repository has a git hook that does a PGP verification of all the commits you're trying to push. See HACKING. <mbakke>The server side enforces that commits are signed, but does not perform verification. <lfam>vagrantc: We are discussing verifying signatures locally, before pushing. It's intended to avoid mistakes <lfam>Ultimately, we need to verify signatures on the Guix client when updating, but that is hard to get right and we haven't implemented it yet <vagrantc>is there a bug about that that i could subscribe to? <ng0>have you considered signify wrt guix pull instead of just gpg? I'm exploring the possibilities of it at the moment. I know there was some discussion on tofu or something? <civodul>it's been there for way too long already! <mbakke>We could sidestep the problem by making `guix pull` only serve substitutes. <mbakke>Then users running without substitutes would have to use a git checkout and verify manually. <vagrantc>you also don't have to verify every commit, only the commit you're building <vagrantc>does NNN-subscribe@debbugs.gnu.org allow me to subscribe to a bug? <vagrantc>or any other way to subscribe to a single bug? <lfam>Right now, Git doesn't really do what we need in this area. It counts signatures with expired keys as bad, and so many old commits will the verification. <lfam>Well, I don't know if this policy is in Git or GPG. <vagrantc>if there are any expired keys anywhere in the history? <lfam>And there are many. As time goes by and contributors leave the project, all their commits may become "bad" according to Git <lfam>To clarify, there are no keys in the history. But there are signatures made with keys that have since expired. <vagrantc>but does git really verify all of the signatures of all of the commits, or just the commit/tag you're asking it to verify? <mbakke>vagrantc: 378640ec37301de84f0ac7183aa88c52b25338c1 is a commit with a good signature, but with expired key. <vagrantc>since the commit or tag contains a history of which other commits it relies on... <lfam>vagrantc: It depends on what you ask it to do <mbakke>vagrantc: If you pass `--show-signature` to any git command, it will verify commits as needed. <vagrantc>ACTION would ask the simplest possible thing to implement :) <nckx>ng0: Why update alpine to a .999 release? (Just curious, I neither mind much nor know their versioning policies.) <mbakke>For guix pull, I suppose verifying HEAD would suffice. <vagrantc>maybe with something as complicated as rolling back to the last verifyable commit ... but that has some issues, i'm sure <ng0>nckx: it's what all the other systems have <lfam>Part of how we use commit signatures is to tie each commit to an authorized committer. This is the only way to do this with a Git commit. <ng0>and that's the latest "version" since the maintainer currently does no tags (have they ever used some?) and no tarballs <ng0>and the homepage went down the trashcan of the internet, gone <vagrantc>lfam: due to key expiry, that's probably not going to be possible in the long-run no matter how clever you get <lfam>vagrantc: It works if you choose to ignore failures caused by expired keys <nckx>ng0: OK, good points, thanks! <vagrantc>lfam: but then the point of key expiration is severely compromised <lfam>This requires us to improve the tools we use, but we need to do that anyways <ng0>nckx: let me check the git if there are tags <ng0>at least last time I checked none were used ever <lfam>Overall, the signing model we use now is inadequate. Dealing with signatures from expired keys in the context of code-signing is a solved problem, but we just don't handle it yet <lfam>However, it's better than nothing <ng0>nckx: so the commit 349642a84039a4b026513c32a3b4f8594acd50df starts with: <ng0> * New version 2.21.999 <ng0>but: version 2.21.9 reads: <ng0> * Upgrade to new version 2.21.9. Version 2.22 will be a bug release <ng0>so.. it's a version in any case <nckx>Ugh... Treasure hunt-based release management. <ng0>nromally there were just tarballs