[00:17] <nacc> is it possible to auto-subscribe to a bug if i make a comment in it?
[05:29] <bellini> hi
[14:54] <smoser> is https://bugs.launchpad.net/launchpad/+bug/1667725 anything that has a chance of being worked ?
[14:55] <cjwatson> smoser: We have about 0.25 people working on Launchpad right now, so not imminently.
[14:56] <cjwatson> smoser: But in any case Launchpad itself doesn't hold the full key material, so it would just move any unreliability around.
[15:03] <smoser> yeah, i knew not a lot of p eople working on it.
[15:04] <smoser> it'd seem possible for launchpad to keep the public key though. it seems to me it holds the long key fingerprint, the full public key is just more bytes, right?
[15:04] <smoser> its not like one changes and the other doesnt.  if for some reason the signing key changed, the long key fingerprint has to be updated so its not additional work.
[15:10] <cjwatson> We'd probably just do it by exposing a caching method instead, but it still doesn't help the problem of ENOTIME :)
[15:10] <cjwatson> We have several vitally urgent things to do in the time we don't have already, I'm afraid.
[15:10] <cjwatson> (e.g. LP is still on precise ...)
[15:59] <smoser> cjwatson, yeah, understood
[16:06] <smoser> i have another question... that you've helped me beore with . build recipes.
[16:06] <smoser> i see upload errors at
[16:06] <smoser>  https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial
[16:06] <smoser>  https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-yakkety
[16:06] <smoser> i recently changed these to use per-release packaging branches (http://paste.ubuntu.com/24131524/ for more info)
[16:06] <smoser> wondering what i am doing wrong or how i can accomplish what i'm after.
[16:10] <cjwatson> This usually happens when the version doesn't fully express everything that might change between two recipe runs when some element of the recipe changes, although I don't quite see where that would be the case here.
[16:11] <smoser> right. i'd seen it before, and you had me add the {revno} for the packaging recipe.
[16:11] <smoser> er.. packaging branch also
[16:12] <cjwatson> I don't suppose the ubuntu/xenial branch was rebased or rewound or anything?
[16:13] <cjwatson> Something that would cause its revision count to stay the same when the hash differed
[16:13] <smoser> a merge from trunk. but that should increase the revno still
[16:15] <cjwatson> It's also possible that it's a bug of the form that we're automatically dispatching a build when we shouldn't because nothing changed
[16:16] <cjwatson> Which sort of looks like it might be the case given the git history
[16:16] <cjwatson> In that case it's annoying but ignorable
[16:27] <smoser> cjwatson, ok. thanks.
[17:19] <mapreri> cjwatson: Out of curiosity, are you also considering to make launchpad accept only signed .buildinfo and have the signature validated?  The last debsign in Debian and the second last dpkg in Debian both sign .buildinfo now.
[17:20] <mapreri> Well, probably making lp forcing .buildinfo to be signed is too early, but validating the signature if it is signed sounds quite sane to me.
[17:23] <cjwatson> Haven't got that far.  I'm aware of the signatures.
[18:07] <mapreri> ack
[19:35] <nacc> cjwatson: is it true that not ever published source package publishing history record has a published_date?
[19:39] <nacc> cjwatson: i think primarily in older historical records, if i had to guess
[20:51] <cjwatson> nacc: no idea, you want wgrant for that kind of question :-)
[21:04] <saiarcot895> Hi, I've uploaded a 1.1 GB source tar.gz into my PPA using dput (sftp backend), but haven't gotten either a failure or success email. There's sufficient space in the PPA. Any ideas what might be wrong?
[21:05] <cjwatson> 2017-03-07 16:40:16 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-sftp-20170307-164003-035614/~saiarcot895/flightgear-edge/ubuntu/yakkety/flightgear-data_2017.2.0~8028+git14e41b5+dfsg-0ubuntu1~ppa1_sou
[21:05] <cjwatson> rce.changes': GPG verification of /srv/launchpad.net/ppa-queue/incoming/upload-sftp-20170307-164003-035614/~saiarcot895/flightgear-edge/ubuntu/yakkety/flightgear-data_2017.2.0~8028+git14e41b5+dfsg-0ubuntu1~ppa1_source.changes failed: Veri
[21:05] <cjwatson> fication failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"]
[21:05] <cjwatson> unsigned upload, or key not on keyserver?
[21:11] <saiarcot895> That's strange...I didn't change my public key
[21:11] <cjwatson> saiarcot895: can you double-check that the .changes file is signed?
[21:12] <saiarcot895> It's signed (otherwise, dput would have errored out), but I'll check using what key and what my settings are
[21:12] <saiarcot895> Thanks cjwatson
[21:12] <cjwatson> saiarcot895: if it all looks good your end, let me know and I'll ask for it to be reprocessed
[21:12] <cjwatson> (it> that upload)
[21:12] <cjwatson> since I imagine you don't want to reupload 1.1 GB
[21:14] <saiarcot895> Oh, I know what happened now. I created a new subkey and meant to remove it (it's meant for a different computer), but the signing took place using that subkey
[21:15] <cjwatson> aha
[21:15] <cjwatson> you might have to reupload then :(
[21:15] <saiarcot895> Ah well, luckily, it only takes 4-5 hours on my connection (it could be worse)
[21:21] <saiarcot895> Actually, can you reprocess the submission using that key? I just updated my public key, and figure I could just use that subkey for this time.
[21:22] <cjwatson> saiarcot895: did you add this key to Launchpad?
[21:23] <saiarcot895> It's the same public key, but with a new signing subkey added in. I've uploaded the new version of the key to keyserver.ubuntu.com
[21:26] <cjwatson> ok, I've asked
[21:28] <saiarcot895> thanks
[21:43] <cjwatson> saiarcot895: that's processing now
[21:58] <saiarcot895> cjwatson: Successful, thank you!
[22:03] <cjwatson> np
[23:15] <nacc> cjwatson: ok :)