IRC channel logs


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.".
<lfam>I saw that myglc2 reported the same issue last month, no resolution AFAICT:
<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:
<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/
<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/`, 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 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 file which is in the same folder as Strangely one of its function is called correctly, but stepping in is not possible.
<marusich>Hello, Guix!
<civodul>Hello Guix!
<civodul>Hello Guix!
<rekado>Hello to both civoduls!
<civodul>rekado: thoughts on ?
<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>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
<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
<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>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>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>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>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>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, says nothing about `make` alone, only `make check`.
<thorwil> 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`
<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:
<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>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?
<hooverville>lfam: debian
<lfam>hooverville: It's probably an instance of this bug: <>. The solution is to either use nscd, or edit /etc/nsswitch.conf, as described in this message:
<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 :)
<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.
<ng0>i don't use savannah.
<ng0>you can force push to anything when you have the remote like that
<snape>like what?
<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":
<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! 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>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> wat
<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.
<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>And here:
<oreloznog>I have made this log Gnu Linux Hurd
<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 :-)
<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.
<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>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
<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
<vagrantc>yup :)
<civodul>it's been there for way too long already!
<lfam>It's a hard problem :)
<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 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>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>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