IRC channel 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.".

<lfam>I saw that myglc2 reported the same issue last month, no resolution AFAICT: https://bugs.gnu.org/30622

<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?

<mbakke>Ooh, you're 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.

<mbakke>Very odd

<lfam>That makes sense

<lfam>(the requirement removal)

<mbakke>The system test seems to be stable: https://hydra.gnu.org/job/gnu/master/test.openssh.x86_64-linux

<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

<lfam>Sure

<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))

<mbakke>Hmm.

<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?

<mbakke>lfam: Not to my knowledge :/

<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.

<marusich>Hello, Guix!

<civodul>Hello Guix!

<civodul>again!

<rekado>Hello to both civoduls!

<civodul>:-)

<civodul>rekado: thoughts on https://bugs.gnu.org/30501 ?

<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>jboy: we have one: ghc-pandoc

<rekado>(we even have two versions)

<rekado>civodul: this seems fine to me.

<rekado>civodul: I wasn’t sure about “ghc-haskeline” and “ghc-process”, but I’ll check them and merge if it’s okay.

<civodul>cool!

<civodul> http://web.fdn.fr/~lcourtes/tmp/gnu-packages-guile.html

<civodul>what can we do with that?...

<rekado>does that show module dependencies from (gnu packages guile) to other modules?

<jboy>rekado: oh cool, somehow I missed that.

<civodul>rekado: yes

<civodul>there's 'music', 'haskell-check', etc.

<rekado>obvious culprits are (gnu packages sdl) and (gnu packages python)

<civodul>python is for guile-wisp

<civodul>sdl for guile-sdl

<rekado>is this a problem?

<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>maybe, dunno

<civodul>try out something new! guix pull --branch=wip-pull-multiple-derivations

<civodul> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27284#133

<rekado>ah, so *that* is why you asked :)

<civodul>yup :-)

<civodul>i have a patch to do "guix graph -t modules guile"

<civodul>i wonder if we should add it

<civodul>thoughts?

<rekado>yes, that seems useful.

<rekado>since Guile is a bit special I’d just split the module.

<civodul>"35 insertions", that's reasonable

<civodul>we could do that

<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.

<rekado>already 3 minutes

<civodul>it's building the module closure for compute-guix-derivation :-/

<civodul>we can already tell that UX is bad

<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>building 65 files now.

<rekado>It would be good if it said what it is doing there.

<civodul>yeah

<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

<civodul>"only"

<civodul>:-)

<civodul>we have terrible expectations

<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>yeah :-/

<civodul>i suppose this part still needs 1G or so

<civodul>we should be able to split it further by analyzing the module graph

<civodul>but that's future work, i guess

<rekado>it completed here after about 15 mins, not including the git fetch, but including the download and grafting of some packages.

<civodul>ok

<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

<civodul>yes, i think so

<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.

<rekado>(the old one)

<mbakke>The builder for "guix-packages.drv" failed with:

<mbakke>In procedure private-lookup: No variable bound to define-module* in module (guile)

<mbakke>No further backtrace.

<mbakke>This is an offloaded build FWIW, I have a "native" pull still running.

<mbakke>(also, is it Christmas already)

<civodul>heya mbakke!

<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>hehe: https://github.com/djcb/mu/issues/1214

<Apteryx>if anyone has a good suggestion to fix those tests, feel free to chim in!

<Apteryx>another reason to dislike summer time ;)

<civodul>Apteryx: oh, fun

<civodul>bytes83: they work with 'sudo', yes

<mbakke>Does the daemon use the local time? Perhaps it should set TZ=UTC?

<civodul>guix-daemon doesn't touch the time

<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.

<mbakke>(on the different user)

<Apteryx>civodul: civodul, correct, mu does that setup (pull tzdata and sets TZDIR) before running the tests.

<civodul>mbakke: 75%, not bad! ;-)

<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

<civodul>fixing that

<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>See: https://github.com/djcb/mu/blob/master/lib/parser/test-utils.cc#L81

<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>use something which is localized.

<civodul>hmm, could be

<Apteryx>looks like I could probably just take time_t t = time(NULL); tm tlocal = localtime(&t); or something like this

<Apteryx>hmm. later!

<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>btw, https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html#Building-from-Git says nothing about `make` alone, only `make check`.

<thorwil> https://www.gnu.org/software/guix/manual/html_node/Running-the-Test-Suite.html#Running-the-Test-Suite says "After a successful configure and make run, it is a good idea to run the test suite."

<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`

<thorwil>bbl

<rekado>sneek: later tell civodul Regular “guix pull” took 22 mins, so the new guix pull is an improvement in that regard as well.

<sneek>Got it.

<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 ;)

<davexunit>there's a new guix pull?

<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

<rekado>davexunit: it starts here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27284#133

<davexunit>thanks

<davexunit>rekado: holy hell that is a wonderful hack!

<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 :)

<davexunit>ludo came up with a clever hack

<pkill9>what happened

<ng0>davexunit: oh?

<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>ah!

<ng0>blame my email client.

<ng0>thanks

<ng0>awesome

<ng0>pulling with a different unix account now, see how far this gets.

<ng0>huh.

<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 (?)

<nckx>*guix

<nckx> https://lists.gnu.org/archive/html/guix-commits/2018-03/index.html

<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?

<hooverville>lfam: debian

<lfam>hooverville: It's probably an instance of this bug: <https://bugs.gnu.org/30298>. The solution is to either use nscd, or edit /etc/nsswitch.conf, as described in this message: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30298#35

<lfam>Our recent glibc update removed some obsolete interfaces still used on Debian (and maybe other distros)

<hooverville>lfam: thnk you, will theck those links out

<lfam>I did `apt-get install nscd` and everything has worked since then :)

<hooverville>gotcha

<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".

<hooverville>lfam: that did it :)

<lfam>Great, hooverville :)

<nckx>lfam: Right, but allowed by convention, not technically, right?

<nckx>...right? Whoops.

<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.

<nckx>(Don't worry.)

<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.

<nckx>^

<ng0>i don't use savannah.

<ng0>you can force push to anything when you have the remote like that

<snape>like what?

<ng0>nvm

<ng0>what my problem was before I walked away: what ludovic mentions doesn't work.

<ng0>merged into master then? or another branch?

<civodul>mbakke: broken how?

<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":

<civodul>oh

<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

<thorwil>lfam: yes.

<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")

<rekado>ng0: we tested this already.

<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

<ng0>rekado: ok

<thorwil>lfam: ah, thanks! https://www.gnu.org/software/guix/manual/html_node/Running-Guix-Before-It-Is-Installed.htm could do with a note that the store can be reused that way

<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.

<civodul>ok, makes sense

<lfam>Is it expected that replacement packages need the 'name' field set again?

<civodul>nope

<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? :)

<civodul>heheh :-)

<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

<snape>git format-patch -1

<ng0>and git format-patch HEAD~ if it's one cange.

<ng0>well or that.

<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 :}

<thorwil>oops, grammar

<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> https://i.warosu.org/data/g/img/0576/31/1479844001273.png wat

<mbakke>Lol?

<nckx>I feel many conflicting emotions.

<snape>nckx: GuixSD is designed to work with other kernels by the way :-)

<nckx>snape: ?

<snape>The Penguin is Linux's mascot

<nckx>Yes, because THAT's what's wrong with that image.

<nckx>Pepenguin.

<lfam>Where did that come from...

<nckx>The absolute bowels of hell.

<nckx> / 4chan

<nckx>I guess.

<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>logos

<lfam>And here: https://www.gnu.org/software/guix/graphics/

<oreloznog>I have made this log Gnu Linux Hurd https://www.hubert-lombard.website/vignettes/GnuLinuxHurd.png

<lfam>But, they come from SVGs in the repo

<oreloznog>*logo

<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 :-)

<oreloznog>Thanks lfam :)

<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.

<nckx>Yup.

<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>ng0: the branch is back! :-)

<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

<ng0>oh, thanks

<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

<civodul>ok

<civodul>weird that i didn't notice before

<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>We already do :)

<lfam>Check the else branch at line 40

<mbakke>Oh.

<lfam>But I guess that the action we take in this case may not be the best one...

<mbakke>Oh, right!

<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>Or, I want to limit it

<lfam>I wonder if it can be symlinked

<mbakke>"this check will fail"

<ng0>lfam: what, the hook?

<lfam>ACTION brb

<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>I think that is best

<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?

<mbakke>Sounds good to me. Any takers?

<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

<mbakke>Sounds good!

<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.

<vagrantc>ah, not on the recieving end

<vagrantc>e.g guix pull

<lfam>vagrantc: We are discussing verifying signatures locally, before pushing. It's intended to avoid mistakes

<vagrantc>also a good thing

<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>yeah, i'd love to see that part :)

<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>vagrantc: it's https://bugs.gnu.org/22883

<vagrantc> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883

<vagrantc>yup :)

<civodul>:-)

<civodul>it's been there for way too long already!

<lfam>It's a hard problem :)

<civodul>yeah

<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.

<mbakke>But, not a great option :P

<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?

<vagrantc>that doesn't seem reasonable

<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>sure

<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 :)

<vagrantc>that gets *some* improvement

<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>exactly

<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> version

<ng0>so.. it's a version in any case

<nckx>Ugh... Treasure hunt-based release management.

<ng0>nromally there were just tarballs

IRC channel logs

2018-03-27.log