[00:10] wgrant: Ah ha. The five queries come from package_upload_source_dict[source_file.sourcepackagerelease.id].packageupload.id [00:10] Trying to key SPRF to upload id [00:11] Ah [00:11] To get changesfiles? [00:13] No, that is fed into CPU so it can populate the objects [00:15] Ah === slank is now known as slank_away [00:18] Which it builds by using IPackageUploadSet.getSourceBySourcePackageReleaseIDs() [01:30] * StevenK breaks DistroSeries:+queue :-( [01:30] What did you do to it? [01:31] I changed one part of it to no longer use IPackageUploadSet.getSourceBySourcePackageReleaseIDs(), and too make use of PUS only, and now the next method called is looking up SPRF.sourcepackagerelease.id and raising a KeyError when it isn't in the dict. [01:33] It just wants a mapping of PU id to a list of SPRFs [01:33] So I might just rewrite it to not be dreadful [01:53] wgrant: 62 == NEW, 66 == DONE [01:53] 3 of those are going to be PackageDiff [01:58] Great. [02:48] wgrant: I've shifted https://code.launchpad.net/~stevenk/launchpad/moar-preload-distroseries-queue-redux/+merge/142056 back to Needs Review, but it's currently cowboyed onto DF. [03:49] wgrant: Can haz review, if you're undistracted? [03:51] Soon :) [03:52] wgrant: Shall I pick up bug 1095982 and make AAGs work for lp.View? [03:52] <_mup_> Bug #1095982: Person.getAffiliatedPillars doesn't filter out inaccessible private projects <403>

< https://launchpad.net/bugs/1095982 > [03:52] StevenK: Maybe, or work out why LimitedView wasn't sufficient to render the link [03:53] StevenK: You can probably grep for the OOPSes [03:57] wgrant: Well, an AAG should allow it, by rights [03:58] StevenK: An AAG should certainly allow LimitedView, and I think it should allow View, but the private projects implementation assumes that an AAG does not give View [03:58] But I think LimitedView should have been enough to render that page [03:59] Unauthorized: (, 'displayname', 'launchpad.LimitedView') [03:59] https://oops.canonical.com/oops.py/?oopsid=OOPS-c2e7d50102a3b7d7aca70d699226ebee [03:59] Clearly not. displayname should remain under View [04:00] Should it? [04:00] I wonder how BugTask:+index works [04:00] Maybe the task table shows title rather than displayname [04:00] Likely, just thinking about it [04:10] wgrant: IProduct.userCanView() uses ISharingService.checkPillarAccess [04:17] wgrant: And checkPillarAccess only checks APGs [04:18] StevenK: Doesn't the LimitedView adapter do something different? [04:18] It checks userHasGrantsOnPillar [04:19] Right [04:19] That's what I suspected [04:22] wgrant: So I'm not sure how to tackle this [04:22] StevenK: How does BugTask:+index render? [04:22] I assume it uses Product.title rather than Product.displayname [04:22] Which must mean that title is LimitedView [04:23] Oh [04:23] But displayname is LimitedView too, from that exception [04:25] StevenK: Perhaps userHasGrantsOnPillar doesn't respect team participations [04:28] That calls IAccessPolicyGrantFlatSource.findArtifactsByGrantee(), which doesn't check TeamParticipation. [04:28] tsk [04:29] LimitedView for an AAG, and View for an APG just sounds wrong [04:33] wgrant: The only that I can see that uses TeamParticipation under APGF is _populateIndirectGranteePermissions [04:37] StevenK: I don't think AAG == LimitedView && APG == View is feasible to implement fully, but there's nothing fundamentally wrong with the idea and it's what is mostly implemented today [04:37] So we would do well to preserve it for now [04:37] StevenK: _getSharedPillars uses TP and APGF [04:37] wgrant: Well, it isn't what happens for bugs and branches [04:38] StevenK: Sure, but bugs and branches don't have subordinate objects that can have their own grants [04:38] The idea is that a grant on a bug gives you access to just that bug, not all details about the product [04:38] *cough* stacked branches [04:38] While a grant on the product gives you access to all [04:38] :-) [04:38] Stacked branches are not subordinate [04:42] Yes, I was mostly trolling badly. [04:43] It probably feels wrong due to bugs and branches acting differently. [04:44] _getSharedPillars uses TP and APGF for the owner, but not the grantee [04:45] So it does [04:45] It's not quite clear why it checks owner or driver at all [04:46] Oh [04:46] Right [04:46] The owner/driver check is to verify that the current user is allowed to see that the grant exists [04:47] getSharedProducts lists all direct grants for the *given person* to a product that the *user* owns or drives [04:47] checkPillarAccess is the privilege checking implementation [04:47] So from what I can see, there is no mtheod that looks for an AAG while respecting TP. [04:47] You'll want something similar to that, except on APGF [04:48] Sure [04:48] getVisibleArtifacts is probably the only thing that uses AAG+TP [04:49] (though it shouldn't; all artifacts should have it denormed) [04:57] Specification [05:04] Hmm? [05:04] What about it? [05:05] It isn't denormed [05:05] Sure [05:05] Hence "should" [05:05] Right [05:05] Can haz review now? [05:05] Am looking [05:05] Is long [05:06] You're not stuck with 3G tethering [05:06] source_dict is one of the most useless methods ever, and its name is wrong [05:06] Can it be inlined? [05:07] Sure. [05:07] It is leftovers, effectively [05:29] Oh [05:29] I can use a selection of Storm "validators" to do my evil [05:29] Though I shall probably never be forgiven [05:37] OMG, you wouldn't dare [06:14] * StevenK stabs buildbot and it's poller === Ursinha_ is now known as Ursinha === _mup__ is now known as _mup_ === almaisan-away is now known as al-maisan [08:46] stub: Are you going to QA r16409 today? [08:52] * stub wonders if it is untestable [08:52] I guess if we can retrieve stuff from the Librarian, it is qa-ok [08:54] good morning [09:11] StevenK: qa-ok'd === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban | Firefighting: - | Critical bugs: <150 === al-maisan is now known as almaisan-away === salgado is now known as salgado-brb === slank_away is now known as slank [14:47] gary_poster: yep, that is a bug in the backend; I was just trying to figure out where to file that and whether or not I should dig into it [14:47] pfft === almaisan-away is now known as al-maisan === salgado-brb is now known as salgado === al-maisan is now known as almaisan-away === yofel_ is now known as yofel === alexlist` is now known as alexlist [20:14] * dobey wonders who to bug about bzr dailydeb having issues only on launchpad :-/ [20:27] dobey: what do you mean? [20:33] lifeless: https://launchpadlibrarian.net/127602321/buildlog.txt.gz [20:34] lifeless: this seems to only happen on lp. the recipe for that build works fine locally, it's just a simple recipe to reubild lp:ubuntu/ubuntuone-client on older versions of ubuntu that we (u1) still need to support. [20:34] dobey: that looks like a pristine-tar failure [20:34] dobey: there is no exception thrown from bzr routines, so presumably the tags etc were all recreatable [20:34] yes, but why would it fail only on launchpadk, and not locally? how am i supposed to debug it further? [20:35] dobey: clean quantal chroot should let you reproduce it [20:35] but I presume you tried that and couldn't ? [20:37] i've tried dailydeb on quantal and on raring; though not in an empty chroot [20:49] brb [21:26] back