[05:36] Not sure if this right place to ask but how can I get yaml-cpp 0.6.0 back ported to trusty in a ppa or whatever for my travis-ci instance? [11:38] doko, that gobject-introspection upload is a bit unfortunate, it was almost a candidate for migration and now it's back to having 30 lines of regressions to sort out :-( [11:38] doko, libffi isn't going to migrate any time soon === ricab is now known as ricab|lunch [14:10] rbalint: could I have a quick review please? Our squad is short today: https://code.launchpad.net/~ahasenack/ubuntu/+source/talloc/+git/talloc/+merge/378122 [14:10] er [14:10] rbalint: sorry [14:10] the other rb [14:10] rbasak: ^ [14:17] Sure [14:20] ahasenack: done [14:22] rbasak: thanks [14:22] ah, update-maintainer [14:22] always that === ricab|lunch is now known as ricab [17:22] rbasak: same thing for ldb, if you still have a moment? https://code.launchpad.net/~ahasenack/ubuntu/+source/ldb/+git/ldb/+merge/378136 [17:25] looking [17:26] ahasenack: +1 - MP updated [17:26] thx [17:31] hmpf, I just raced debian and lost [17:32] rbasak: I'm gonna have to rebase on top of https://launchpad.net/ubuntu/+source/ldb/2:2.0.8-1 [17:45] ahasenack: OK. No need for another review just for that IMHO [17:45] rbasak: ok, thanks [17:50] bryce: in the git-ubuntu release process, I'm not sure we need "push a copy of the branch up to launchpad under your own namespace for Continuous Integration (CI) testing". Since the only change is the version string, and we're already running daily CI and only publish from those builds. The only testing I'd be doing is already done by CI anyway. Thoughts on replacing all of that with just "check [17:50] that daily CI is already green; if not fix it"? [17:51] it depends on the change you are making, sometimes the release is fix+release, other times it's just bump-version + release like you are doing now [17:53] If it's fix+release, then the process will still be the same - do the steps, but you can only proceed if CI passed in the (possibly manually triggered extra) daily to fetch the actual snap for publication. [17:53] Either way, I think additional testing is superfluous. [17:54] IOW, if we drop the part of the process I'm proposing, a release would still have passed CI before it happens [18:28] rbasak, in an ideal situation I agree, that's a superfluous check. But IIRC the reason I added it was because we had some existing build failures in the tree that needed resolved [18:28] you're right though that those issues are probably spottable looking at the already running daily CI [18:28] rbasak, if nothing else, that can be marked optional [18:31] bryce: OK, thanks. I skipped for now, and I'll make an MP to adjust the notes later [18:32] seb128: you are wrong, your upload didn't even build. https://launchpad.net/ubuntu/+source/gobject-introspection/1.62.0-2ubuntu2 [18:44] doko, that url is an upload from you, https://launchpad.net/ubuntu/+source/gobject-introspection/1.62.0-2ubuntu1 was the previously in proposed one [18:44] doko, anyway, that just set back the ffi transition and I've no time this week to sort out gobject-introspection problems again :/ [18:47] desktop isn't even subscribed to that package [18:48] well, I tried to be nice and spent some hours tried to get it ready for migration [18:49] which was wasted/reset back by the new upload :/ [18:49] but it's fine, you can fix it this round :) === jdstrand_ is now known as jdstrand [22:19] cjwatson i am probably just not finding it, but it seems like the LP api provides no way to reach the signing key for a private ppa that a person is subscribed to (but not part of the private ppa's owner person/team), is that correct? [22:21] ddstreet: The signing_key_fingerprint attribute has somewhat too tight permissions for some reason, but you should be able to use the getSigningKeyData method on such an archive [22:21] yeah, but the archive isn't reachable if you're not part of the team/person that owns the archive [22:21] that's the problem [22:22] ddstreet: The whole archive isn't, but I think that method should be ... [22:22] ddstreet: Well, unless the owning team is itself private [22:22] lp.people(owning_team_name) certainly fails, and i'm trying lp.me.getArchiveSubscriptions() but i can't lp.load() the corresponding subscription's archive_link [22:23] exactly [22:23] that's extremely common, at least for my team's use case of private ppas [22:23] People with a subscription on a private team's private PPA get LimitedView on that private team though, precisely in order to make traversal work [22:24] if the archive_subscriber object provided the signing key fingerprint, that would handle it i think [22:24] Baroque and shouldn't be necessary here [22:24] hmm, it's failing for me [22:25] e.g. i'm subscribed to this ppa https://api.launchpad.net/devel/~canonical-sustaining-merged/+archive/ubuntu/ppa-testing-deletedppa [22:25] but i can't reach the canonical-sustaining-merged team [22:25] maybe it's a bad example though [22:26] it was the first one i found where i'm not part of the private team [22:26] It's 10:26pm here, could you email me please? [22:26] but subscribed to the private ppa [22:26] sure [22:26] With sample code [22:27] Because I just tried it for a private PPA I'm subscribed to where I'm not part of the private team, and it works exactly as I predicted [22:27] lp.load('/~canonical-livepatch/+archive/ubuntu/updates').signing_key_fingerprint → gets me a redacted thing because of the excessively-tight permissions I mentioned [22:27] lp.load('/~canonical-livepatch/+archive/ubuntu/updates').getSigningKeyData() → works [22:28] Also full transcripts, especially including any OOPS IDs that you get [22:28] (because then I can look at tracebacks and see if there's anything interesting in them) [22:28] will do, sorry for the late pings [22:29] no problem - but AFAICS this is probably some special-case oddity rather than it not working in general [22:29] admittedly I have a lot of assorted permissions on things so it can be slightly difficult for me to see sometimes [22:30] it may just be a bad example, i tried canonical-livepatch and it works same as you said; so if you don't see an email from me then it was just my mistake :) [22:33] Oh, so uh [22:33] deletedppa [22:33] Maybe relevant? [22:34] Not sure why the subscription is still listed but the PPA is gone [22:34] So I expect that's all that is [22:35] yep - sorry again for the lateness! [22:35] and thnx for the help [22:35] A bug about deleted archives showing up in your subscriptions would be appreciated though, as that's weird [22:36] ack i'll open that