=== cpaelzer_ is now known as cpaelzer === jamespag` is now known as jamespage === ant_ is now known as Guest45561 [13:22] Laney, pitti: may i inquire about the bug #1615039 [13:22] bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,In progress] https://launchpad.net/bugs/1615039 [13:23] i have a merge done, testing at the moment, but i'm ready to upload it. Thinking to block it in proposed for a little while to see the fallout. [13:23] some say that cdimage infra and some such may blow up. [14:07] infinity: looks like I'm not attending the sprint, so any lts discussion would have to be online :) [14:08] xnox, that sounds like the sort of breakage that won't be detected in -proposed ? [14:11] xnox: Might want to do it closer to the start of a cycle than the end? [14:11] Unless you have a very good idea of what might break and how to fix it [14:12] (and if you do, I'd like to know how to noninteractively delete a secret key using gnupg2, for test suite purposes ...) [14:18] Laney, all packages in the archive are fixed to deal with gnupg2 and our gpg-agent.service is solid (unlike debian's) [14:18] Laney, we already see syncs in 16.10 with versioned breaks that assume that gnupg2 -> gnupg migration has happened. [14:20] Laney, i don't know where gpg in invoked, and if that will affect anything.... launchpad signs things by itself. Somebody mentioned that livecd building may be using gpg for some things... but i'm not sure if that is happening in yakkety chroot or not. [14:20] ditto cdimage, i thought it's doing everything on the host and not inside chroots. [14:26] cjwatson, good question [14:28] it feels a bit broken that seahorse in xenial suddenly uses gpg2 (only) so running gpg from the command line and running seahorse show different results [14:29] (of course, the gnupg2>gnupg migration in yakkety doesn't help xenial) [14:30] is that a recent change in xenial due to a SRU? [14:30] no, it was like that on release [14:31] k, I didn't parse what you wrote correctly then [14:35] xnox: snapd uses gpg1 because AFAICT this problem cannot be handled sanely in gpg2 as it stands ... (but seriously, don't spend huge amounts of time on it, I wasted half a day and gave up) [14:35] (but snapd can cope with the gnupg2 -> gnupg migration having happened, I was careful) [14:36] and yes, LP/cdimage does all the signing in the fixed base system and won't immediately be affected by a change in yakkety, AFAIK [14:37] cool. [14:42] xnox: there you go [14:43] cjwatson, gpg2 --batch --yes --pinentry-mode loopback --delete-secret-and-public-key 0x28E7DEFB99F919E1145F18F381565D68A1290D19 [14:44] works... but public key is gone too. [14:44] so if you want to keep public key, export it first, stash, and re-import just public key. [14:46] xnox: --pinentry-mode loopback didn't work for me [14:46] I forget the exact details but I did try that and IIRC the error message was something like that the loopback mode was disabled [14:46] horum. [14:48] isn't the public key in the normal place, and the secret key in its own per key file, you might be able to just remove those directly (what could go wrong) [14:50] ... yeah, um, not doing that. [14:51] apw, still cached in the agent, so one needs to kill the agent too. [14:51] even if I thought it would get past review which it wouldn't :) [14:51] but yeah rm private_keys-v1.d/*.key works [14:51] (i made typo above, for sake of people not copy & pasting) [14:52] cjwatson, i truly hope not indeed :) [14:55] arges: Could you have a look at my livecd-rootfs upload in the Xenial queue? [14:56] bdmurray: sure [14:58] xnox, i am supprised --delete-secret-keys --yes doesn't work from teh manual, but i assume that has been tested [15:00] yeah. [15:04] cjwatson, gpg --batch --delete-secret-and-public-key $fingerprint gpg --batch --delete-secret-key $fingerprint too [15:05] when I tried that I'm pretty sure I got a pinentry prompt, but I'll try again at some point, thanks. [15:06] yeah, i get pinentry prompts or errors here on ubuntu desktop with gnupg 2.1.11 [15:11] cjwatson, some documentation implies --yes will prevent pinentry on that batch delete, though our version does not mention it [15:12] yes, the docs said that but they appeared to lie based on my experience + reading of the source [15:12] you are now about half an hour into my four-hour rabbit hole the other day :-) [15:13] * apw self flagilates [15:15] cjwatson, have you ever seen this before? http://paste.ubuntu.com/23116380/ [15:15] * xnox has reconstructed chroots already, and there is nothing special in my schroot/sbuild [15:15] xnox: afraid not [15:16] isn't ESTALE mostly an NFS thing? [15:16] true. but i don't have any NFS.... [15:56] could fcl/armhf please be removed (Debian did this too) since it's holding up the tinyxml2 transition [16:00] bug #1617835 [16:00] bug 1617835 in fcl (Ubuntu) "Please remove fcl/armhf from yakkety" [High,New] https://launchpad.net/bugs/1617835 [21:29] gave back failed packages in -proposed. at least four now built and migrated [21:43] thanks doko - i received some mails about packages that still failed - btw how much do we care about things already in yakkety that ftbfs with gcc 6? e.g. LP: #1619035 [21:43] Launchpad bug 1619035 in protobuf (Ubuntu) "FFe: Sync protobuf 3.0.0-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1619035 [21:46] ginggs_: I'm usually fine with such requests, but would like to wait until that migrated to testing [21:47] just to make sure we have a somehow clean migration [21:48] ok, thanks [22:31] slangasek: Could you merge https://code.launchpad.net/~mterry/ubuntu-archive-tools/phablet-teams/+merge/303163 [22:35] bdmurray, mterry: what's the reason for the switch from -bugs to -team? someone is eager to be overwhelmed with bug mail? :) [22:38] I suppose since unity-api-bugs has no remaining members except for the two of us, a change of some sort is needed there [22:41] slangasek: the -team teams already exist and were subscribed to packages as it was, so to eliminate confusion. People were submitting mirs with -team subscribed and didn't know about -bugs. [22:41] right [22:41] so as long as they're all happy with the resulting bug mail, that's fine [22:42] (merged) [22:42] thanks