[01:23] hloeung: thanks for the pointer, though === zbr|rover is now known as zbr [08:38] dkg: answered [12:00] cjwatson: thanks! [12:01] dkg: Incidentally do you know if xenial's gnupg2 (i.e. 2.1.11) is sufficient for this kind of thing or whether we'd need to update that too? [12:01] As of a few days ago LP does pass its tests on bionic (which has 2.2.4) but we haven't yet upgraded production and that's a fairly big job [12:29] cjwatson: my impression is that 2.1.11 was not really ready for a stable release -- too many bugs were found in it during its stint in testing. I've heard from many people that xenial's 2.1.11 fails with some ECC keys, for example (e.g., https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1778770 and related bugs) [12:29] Ubuntu bug 1778770 in gnupg2 (Ubuntu) "GnuPG segfaults when encrypting mail to key with ed25519 / cv25519 subkeys" [Undecided,Confirmed] [12:30] dkg: Mm, I thought as much. This might have to wait until we're on bionic then [12:33] it's pretty sad that xenial's GnuPG situation is so unmaintained that those bugs aren't getting fixed :( [12:34] glad to hear that LP might make this work on bionic though -- presumably that means it just automagically inherits GnuPG 2.2 and the test suites actually pass -- that's good to hear! [12:34] (and it suggests that we have actually managed to address at least some of the issues that ian was complaining about, though we haven't heard back that they're fixed) [12:42] dkg: Well, no, on bionic the tests only pass because we force gnupg1 [12:43] dkg: You really can't infer anything about the state of the agent interaction bugs from that :) === zbr is now known as zbr|pto [13:59] cjwatson: is the buildd-manager still alive? [14:02] acheronuk: Possibly not, but I have a deployment in progress at the moment that will restart it anyway [14:02] So I might as well let it get on with it [14:03] cjwatson: indeed, thanks [14:16] acheronuk: should be happier [14:19] cjwatson: ty === viv`d is now known as vivid [23:41] cjwatson: oh, it's sad that you're forcing gnupg1. why do you need the agent at all? can you point me to the test suite failures if you use gnupg2? [23:43] dkg: I wasn't under the impression that it was possible to use gnupg2 without the agent being involved [23:44] dkg: I can dig up test failures in a bit, though not tonight. My current working diff has "gpgconf --kill gpg-agent" at a point in the code where we want to reset gpg's state for tests, which I think helped somewhat but I do have a few left [23:45] cjwatson: the agent is for secret key usage: signatures and decryption [23:45] dkg: Sure, which LP's test suite does [23:45] if you're not signing or decrypting, you shouldn't need the agent [23:46] at any rate, you should be able to just use it -- if you want to reset gpg's state, the best thing is to just delete the GNUPGHOME entirely. [23:47] What will happen to the gpg-agent processes left lying around? Seems best to kill them [23:48] We also sign things in non-test situations, for example Release files [23:48] Kind of vital [23:54] ok, signing Release files makes sense [23:55] do you actually decrypt? [23:55] you can always "gpgconf --kill gpg-agent", but it's not clear to me why you need to if there are long-running launchpad processes [23:56] for the test suite, i can see why you'd want to make sure the processes go away, but deleting the GNUPGHOME should cause any associated agents (for modern GnuPG) to terminate automatically anyway (based on inotify events) [23:58] We do decrypt, but only in tests [23:58] Just the other end of things that involve encryption [23:58] Good to know about inotify; that might help [23:59] At the moment we only remove some important files from GNUPGHOME to reset state, but if removing and reinitialising the whole thing will work better then we can probably do that