| wgrant | wallyworld: Hum, interesting regression | 00:25 |
|---|---|---|
| wgrant | wallyworld: https://code.launchpad.net/~timkross/cjdns/cjdns | 00:25 |
| wgrant | wallyworld: Look at the "Edit import source or review import" link | 00:26 |
| wallyworld | you mean it's split? | 00:27 |
| wgrant | wallyworld: It's overridden by JS to display a bug picker | 00:27 |
| wallyworld | ah, i had logged out, just a sec | 00:27 |
| wgrant | Ah | 00:28 |
| wallyworld | so it is :-( | 00:29 |
| wallyworld | i'll have to fix it | 00:29 |
| wallyworld | it's got an id of linkbug, that can't be sensible | 00:30 |
| wgrant | Heh | 00:32 |
| maxb | How... special :-) | 00:53 |
| === bigjools-afk is now known as bigjools | ||
| * mwhudson wonders if that is his fault | 01:19 | |
| wgrant | wallyworld: Thanks for the quick fix | 01:22 |
| wallyworld | needed to be done | 01:22 |
| StevenK | wgrant: Is POLICY_ALLOWED_TYPES in branchnamespace private? I'm using it, but it's not in __all__. | 01:34 |
| wgrant | StevenK: That's a very good question | 01:34 |
| wgrant | StevenK: I'd rename and expose it | 01:35 |
| wgrant | StevenK: Same with the stuff in bugtarget | 01:35 |
| wgrant | Which I added a few hours ago | 01:35 |
| StevenK | Has that landed? | 01:35 |
| wgrant | Yeah, at 4am or something | 01:35 |
| wgrant | Not through buildbot yet | 01:36 |
| StevenK | Right, I'll rebase this on current devel | 01:36 |
| lifeless | flacoste: http://www.amazon.com/Running-Lean-Iterate-OReilly-ebook/dp/B006UKFFE0/ref=pd_sim_kstore_1 | 02:08 |
| lifeless | flacoste: looks intruiging | 02:08 |
| bigjools | lifeless: it does | 02:23 |
| StevenK | steven@undermined:~/launchpad/lp-branches/destroy-security-contact% bzr di -r submit: | diffstat -s | 04:00 |
| StevenK | Using submit branch /home/steven/launchpad/lp-branches/devel | 04:00 |
| StevenK | 52 files changed, 61 insertions(+), 1240 deletions(-) | 04:00 |
| StevenK | Right, I think that's security contact eradicated | 04:01 |
| StevenK | ForbiddenAttribute: ('remove', <storm.store.ResultSet object at 0x114dfa90>) | 06:04 |
| StevenK | Hm. I thought that worked. | 06:04 |
| wgrant | No | 06:05 |
| wgrant | It's usually used on an unproxied resultset | 06:06 |
| wgrant | Not one that was returned from a model object | 06:06 |
| StevenK | Well, I don't care about the APGs I get back, I want to remove them | 06:06 |
| StevenK | Maybe I want to add revokeByPolicy() | 06:07 |
| wgrant | That would be the correct thing to do, yes. | 06:08 |
| === almaisan-away is now known as al-maisan | ||
| wallyworld | wgrant: i've got things all working for the team access policy stuff. one point to note - the bug says private teams need an APG but in fact any team needs an APG to see +junk private branches | 06:45 |
| wallyworld | perhaps I should check non teams as well | 06:46 |
| === al-maisan is now known as almaisan-away | ||
| StevenK | Non teams? | 06:48 |
| StevenK | The owner can implicitly access a personal +junk private branch | 06:48 |
| wallyworld | StevenK: when the owner was a team, they couldn't | 06:49 |
| wallyworld | without a subscription | 06:49 |
| StevenK | wallyworld: Right. The owner of the team can | 06:50 |
| StevenK | wallyworld: So non teams has to be people | 06:50 |
| wallyworld | sure, s/non team/person | 06:50 |
| wallyworld | i'm wondering now though, it we create an APG for +junk, we don't need to create the subscription anymore | 06:50 |
| wallyworld | it's sort of pointless subscribing to one's own +junk branch i would think | 06:51 |
| StevenK | wallyworld: We don't subscribe the team to a +junk branch | 06:51 |
| StevenK | The owner or the team owner do get subscribed | 06:52 |
| * StevenK refactors the garbo job to work on sets rather than looping | 06:52 | |
| wallyworld | StevenK: incorrect i think - we do a subscribe(self.owner....) | 06:52 |
| wallyworld | and self.owner may be a team | 06:52 |
| wallyworld | so if we do the APG for +junk, then we can forget the subscribe(self.owner...) for +junk | 06:53 |
| StevenK | Hm, probably | 06:54 |
| wallyworld | well, that's my theory right now. i'll do the tests for it all and see how it pans out | 06:55 |
| wallyworld | actually, i wrote the tests for the team owners first, i need to add other tests | 06:55 |
| wgrant | wallyworld: Well, private +junk branches on public teams aren't meant to exist, but they can | 07:03 |
| wgrant | The default subscription is partly there for MP notifications, IIRC | 07:03 |
| wgrant | check the initial mail settings | 07:03 |
| wallyworld | yes, it's nominally for MP notifications. but that then also grants access | 07:04 |
| wallyworld | i guess if the subscription were to be deleted | 07:04 |
| wallyworld | we would then rely on the APG | 07:04 |
| wgrant | Right, exactly | 07:04 |
| wgrant | And the owner loses access | 07:04 |
| wgrant | And everyone is sad because nobody can recover it except ~admins :( | 07:04 |
| wallyworld | ok. i'll incorporate that into the tests. i'll also only create the AGP for private teams | 07:05 |
| wallyworld | APG | 07:05 |
| wgrant | I'm not quite sure when the AP/APG should be created. It's a bit of a difficult question | 07:05 |
| wallyworld | i do it in transitionVisibility | 07:05 |
| wallyworld | if visibility == private | 07:05 |
| StevenK | Which isn't called if say the team is private? | 07:06 |
| StevenK | I think PersonalNamespace.createBranch() is the right place | 07:06 |
| wallyworld | it's called when the team is created. we do need data migration for existing teams | 07:06 |
| StevenK | I don't think we want an AP for every team | 07:07 |
| wallyworld | i create the AP in transitionVisibility and the APG in _reconcileAccess | 07:08 |
| wallyworld | i could move it though to all be done in createBranch | 07:08 |
| wallyworld | i guess when the branch is deleted, or the team is deleted, stuff needs to be cleaned up also. plus merges too? | 07:09 |
| wgrant | wallyworld: I'd suggest renaming AP.team to AP.person | 07:16 |
| wgrant | As it's conceivable that we might want them for people as well, if we permit people to move private branches to their person | 07:16 |
| wallyworld | i did have that originally but it is a team | 07:16 |
| wallyworld | hmm. ok | 07:17 |
| wgrant | We only clearly need them for private teams right now | 07:17 |
| wgrant | But it may end up that we need them for others | 07:17 |
| wgrant | I suspect | 07:17 |
| wallyworld | ok | 07:17 |
| wallyworld | wgrant: with deletions and merges, the AP and APG will need to be cleaned up to right? | 07:17 |
| wgrant | wallyworld: Yeah... | 07:18 |
| wgrant | I think we currently forbid merges if there are private branches involved | 07:18 |
| wgrant | So you should be able to just delete the APG and AP | 07:19 |
| wgrant | Since they can't be referenced. | 07:19 |
| wallyworld | do we clean up now for pillar APGs for deleting bugs and branches, i can't recall? | 07:19 |
| wgrant | No | 07:20 |
| wgrant | StevenK's working on a garbo job that will remove unused APs and APGs if the project policy forbids them | 07:21 |
| wallyworld | so i propose i don't to the cleanup in this branch and defer it to another | 07:21 |
| wgrant | So | 07:21 |
| wgrant | I would suggest that we actually put it in _reconcileAccess or BranchNamespace or something, maybe | 07:22 |
| wgrant | It'll work for any person, then | 07:22 |
| wgrant | and a counterpart to StevenK's garbo job can clean them up if they're unused | 07:22 |
| wgrant | It's slightly evil | 07:22 |
| wgrant | But it's consistent. | 07:22 |
| wallyworld | the APG bit is in _reconcileAccess | 07:26 |
| wallyworld | the AP creation for the team is in transitionVisibility | 07:26 |
| wallyworld | for if i do it in createBeanch, both can be done together | 07:26 |
| wallyworld | s/for/but | 07:26 |
| wgrant | Oh | 07:26 |
| wgrant | The APG and AP stuff should really be together | 07:26 |
| wgrant | Why the difference? | 07:26 |
| wallyworld | AP and APG for pillars are not done together | 07:27 |
| wgrant | Also, not just createBranch, but moveBranch, and transitionToInformationType :/ | 07:27 |
| wgrant | wallyworld: Do you mean APG or APA? | 07:27 |
| wallyworld | APG | 07:27 |
| wallyworld | no | 07:27 |
| wallyworld | APA | 07:27 |
| wgrant | That makes more sense :) | 07:28 |
| wallyworld | yeah, sorry too many TLa for disclosure | 07:28 |
| wgrant | For non-pillars, each AP has one immutable APG | 07:28 |
| wgrant | So they should probably be managed together | 07:28 |
| wallyworld | wgrant: fuck, forget what i said just above. yes, the AP and APG are done together | 07:29 |
| wgrant | Right | 07:29 |
| wallyworld | the APA is done in _reconcileAccess | 07:29 |
| wgrant | So the only concern is where we put them. | 07:29 |
| wgrant | Yep | 07:29 |
| wallyworld | the code is right, but i lose something in he translation typing into irc for some reason | 07:30 |
| wgrant | Easy to do :) | 07:30 |
| wgrant | I'm really not sure which is the best place to put this | 07:30 |
| wgrant | _reconcileAccess is the safest | 07:30 |
| wallyworld | i put the AP and APG in transitionVisibility because we only want to do that for private teams | 07:30 |
| wallyworld | and then the APA in _reconcile can assume the AP/APG is all set up | 07:31 |
| wgrant | wallyworld: It's not actually clear that we only want to do that for private teams. | 07:33 |
| wgrant | The immediate problem is only for private teams, though | 07:33 |
| wgrant | But what if I make my team public | 07:33 |
| wgrant | Or move a private branch to my public team | 07:33 |
| wallyworld | you lose access to the private branch for public teams since we don't support that i thought | 07:33 |
| wgrant | That might be a reasonable answer, yeah | 07:34 |
| wgrant | But letting artifacts go into an unrecoverable situation is bad, if we can easily avoid it | 07:34 |
| wallyworld | you mean when a team goes private -> public? | 07:34 |
| wgrant | I guess we should check on branch move that the information type is legal in the target | 07:36 |
| wallyworld | yes, i think that's best | 07:36 |
| wallyworld | like we do for bugs | 07:36 |
| wgrant | Currently I can do something like https://code.qastaging.launchpad.net/~wgrant/+junk/test6 | 07:37 |
| wgrant | Which is a private branch on my person | 07:37 |
| wgrant | By setTarget()ing it from a project with private branches | 07:37 |
| wgrant | That reminds me | 07:38 |
| wgrant | We should probably add a safeguard in reconcile_access_for_artifact | 07:38 |
| wgrant | That the correct number of APs is returned | 07:38 |
| wgrant | Otherwise eg. if a bug happens to get a task added on a project that doesn't have a matching policy, it'll silently work but be partially invisible | 07:39 |
| wgrant | Should probably crash instead | 07:39 |
| wgrant | If you're near that code atm and it looks easy, could you throw that into your current branch? If not I'll do it | 07:40 |
| wallyworld | ok, i'll take a look. but i probably won't to it till tomorrow, since i want to write some more tests etc | 07:41 |
| wgrant | Sure | 07:42 |
| === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| === almaisan-away is now known as al-maisan | ||
| adeuring | good morning | 08:24 |
| jelmer | mørgen | 08:33 |
| adeuring | frankban: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/specification-auth-check/+merge/120430 ? | 08:45 |
| frankban | sure adeuring | 08:45 |
| adeuring | thanks! | 08:46 |
| jam | jelmer: I just saw a failure on your build, will it actually stop it? | 09:08 |
| jam | jelmer: http://paste.ubuntu.com/1158664/ | 09:08 |
| jelmer | jam: doesn't look like it has :) | 09:08 |
| jam | jelmer: would it fail at the end, there is also: http://paste.ubuntu.com/1158667/ | 09:09 |
| jam | (running bzr selftest vs bzr selftest -1) | 09:09 |
| StevenK | jelmer: You didn't look at my branch :-( | 09:09 |
| mgz | jam: the python test suite is less fancy than ours | 09:10 |
| jam | mgz: sure, but it can a) Stop on first failure or b) Record a failing test suite at the end | 09:10 |
| jelmer | StevenK: Sorry | 09:11 |
| jam | or c) have failures and just ignore all of them | 09:11 |
| jelmer | StevenK: I did look :) | 09:11 |
| jelmer | StevenK: Just not get back to you | 09:11 |
| jelmer | StevenK: The changes all seem reasonable to me | 09:11 |
| jelmer | Including switch subvertpy to 0.9.0 | 09:12 |
| jelmer | *switching | 09:12 |
| StevenK | jelmer: Ah ha. I'll land it tomorrow then, thanks. | 09:13 |
| jam | jelmer: hmm.. interesting, looks like lots of failures, but still a clean pass | 09:34 |
| jam | mgz: looks like it is (c) after all | 09:34 |
| jam | why run a test suite if you aren't going to have it pass | 09:34 |
| mgz | for giggles! | 09:34 |
| jam | mgz: yeah, but it would save a lot of time building python if we don't do steps that just get ignored anyway :) | 09:34 |
| jam | jelmer: so, next step is python-defaults? | 09:35 |
| jam | also, *my* lucid vm is 32-bit. so I can't actually use the amd64 one... :( | 09:36 |
| === al-maisan is now known as almaisan-away | ||
| rick_h_ | morning | 10:56 |
| jam | jelmer: so where are we at for the python-2.6/7 stuff? need to dput python-defaults and ping to get it to jump the queue? | 11:14 |
| jelmer | jam: Yes, that's what I'm on atm | 11:15 |
| jelmer | jam: since 2.6 built ok | 11:15 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| jam | jelmer: how's it going? (Just finished up a couple of interviews) | 13:02 |
| BjornT | how long does the staging.launchpad.net code update usually take? | 13:05 |
| jelmer | jam: about to do another upload | 13:06 |
| wgrant | BjornT: About five minutes, but there's nothing usual about this one | 13:09 |
| wgrant | BjornT: staging currently has no database due to the DC move. It'll be another day or so before it's rebuilt | 13:09 |
| wgrant | BjornT: Can you use qastaging instead? | 13:09 |
| BjornT | wgrant: ok. i guess i could try qastaging instead. | 13:11 |
| wgrant | jelmer: Do you want a score boost on that build? | 13:20 |
| jelmer | wgrant, that would be awesome | 13:20 |
| jelmer | wgrant, I'll ping one of the buildd admins once I've done the upload | 13:20 |
| jelmer | I guess you're still a buildd admin? | 13:20 |
| wgrant | Yeah | 13:21 |
| cjwatson | Or I can if wgrant's asleep | 13:21 |
| abentley | wgrant: Did lifeless have the right explanation of why you marked bug #1032717 "in progress"? | 13:22 |
| _mup_ | Bug #1032717: blueprint schema doesn't support private projects <qa-ok> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/1032717 > | 13:22 |
| wgrant | I marked the model one in progress | 13:23 |
| wgrant | Oh | 13:23 |
| wgrant | It was renamed :) | 13:23 |
| * wgrant checks IRC logs | 13:24 | |
| abentley | wgrant: It was really intended for the schema change, I just vague it up because lifeless doesn't like bugs that request a particular technical solution. | 13:24 |
| wgrant | Ah, missed the ping, sorry | 13:24 |
| wgrant | Yeah, lifeless' explanation was correct | 13:24 |
| abentley | wgrant: np. | 13:24 |
| wgrant | Sorry if I misunderstood the bug | 13:24 |
| abentley | wgrant: Okay, np. Perhaps my fault for vague bug. | 13:25 |
| abentley | rick_h_: I don't know if this would be too much work, but it might be nice to mess with the other links on the walkthrough so that you can't wander off onto qastaging by accident. | 13:48 |
| rick_h_ | abentley: yea, if I have time I'll try to hook up the ones that I end up with pages for | 13:49 |
| rick_h_ | for instance, as I create the code mockup, the code links in the heading cam go somewhere | 13:49 |
| abentley | rick_h_: right. | 13:50 |
| rick_h_ | but after that, I'll probably just set something to kill other links if I get time to clean it up | 13:50 |
| abentley | rick_h_: Maybe you could just rewrite qastaging links dynamically onload :-) | 13:50 |
| rick_h_ | some delegate listener for all links that check for qastaging in the url and just halt() on that | 13:50 |
| abentley | rick_h_: or that. | 13:50 |
| rick_h_ | or that, but yea | 13:50 |
| === al-maisan is now known as almaisan-away | ||
| cr3 | hi folks, I pushed changes to a branch over an hour ago, but the branch page on launchpad still shows "updating branch..." and the recent revisions doesn't show the one I pushed yet. is this a known problem? | 14:58 |
| === deryck is now known as deryck[lunch] | ||
| abentley | cr3: that does happen occasionally. The branch may have taken too long to scan and the scan been terminated. | 16:11 |
| cr3 | abentley: anything I can do to help things alog, like push again or something? | 16:23 |
| cr3 | s/alog/along/ | 16:23 |
| abentley | cr3: Yes, pushing again will re-trigger the scan. | 16:23 |
| cr3 | abentley: thanks, and we are just talking about a branch and not a merge request, right? | 16:23 |
| abentley | cr3: yes. | 16:24 |
| cr3 | even though I've had similar problems with merge requests, I don't mind exceptionally setting those to "merged" manually | 16:24 |
| abentley | cr3: Could you be more specific about "similar" problems? | 16:25 |
| cr3 | abentley: instead of "updating branch..." in the branch, I would see "updating diff..." in the merge request | 16:26 |
| abentley | cr3: It will say that if a scan is needed, i.e. the branch page says "updating branch". | 16:27 |
| cr3 | abentley: makes sense, so the problems are related. | 16:28 |
| abentley | cr3: right. The fact that "merged" isn't set is because the scan hasn't completed, not because the diff hasn't been updated. | 16:29 |
| abentley | cr3: however, if you can specify *which* branch we're talking about, we can check the logs and see what happened. | 16:30 |
| cr3 | abentley: this is the breanch I'm talking about: https://code.launchpad.net/~canonical-hw-cert/checkbox-editor/trunk | 16:33 |
| cr3 | abentley: I tried pushing again, when you suggested it a few minutes ago, and we can still see: updating branch... | 16:33 |
| abentley | cr3: So, it looks like scans of your branch are oopsing, but the root cause is being masked by a database exception: https://oops.canonical.com/?oopsid=OOPS-20a29e8a7bf4295727dddba3ddb75792 | 16:37 |
| cr3 | abentley: permissions on the project relating to that branch were changed recently, might that be a reason? I can't imagine it would be because of the size of the branch, it's tiny and not many revisions | 16:40 |
| abentley | cr3: It's really hard to say, since we can't see the actual failure. I'm not aware of any cases where permisions would affect branch scans, but... | 16:43 |
| cr3 | abentley: branching the project returns the right revision, so only having the web interface updating the branch will not prevent me from getting work done. is there anything I should do to help, in case this might be a real bug that might affect other projects? | 16:45 |
| abentley | cr3: Bug 1039556 also involves checkbox. | 16:47 |
| _mup_ | Bug #1039556: No diff generated when making a merge request or just uploading a branch <Launchpad itself:New> < https://launchpad.net/bugs/1039556 > | 16:47 |
| cr3 | abentley: the symptoms look the same but, for your information, the checkbox-editor branch I mentionned earlier and checkbox don't share anything as far as bzr is concerned. however, they might have similar project configurations like driver, maintainer, etc. | 16:50 |
| abentley | cr3: The actual failure in the oops is different, too. Very strange. | 16:50 |
| cr3 | abentley: should I added a comment about the checkbox-editor branch mentionned earlier to the same bug report? | 16:55 |
| abentley | cr3: I'm filing a new bug report. | 16:56 |
| cr3 | abentley: thanks! | 16:56 |
| === deryck[lunch] is now known as deryck | ||
| abentley | cr3: bug 1039638 | 17:01 |
| _mup_ | Bug #1039638: Scans of ~canonical-hw-cert/checkbox-editor/trunk oops with a database error <Launchpad itself:Triaged> < https://launchpad.net/bugs/1039638 > | 17:01 |
| cr3 | abentley: should bug #1039556 be deprecated by that one? | 17:02 |
| _mup_ | Bug #1039556: No diff generated when making a merge request or just uploading a branch <Launchpad itself:New> < https://launchpad.net/bugs/1039556 > | 17:02 |
| === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| abentley | cr3: No, they could be separate issues. | 17:03 |
| cr3 | abentley: ok, thanks! | 17:03 |
| abentley | cr3: np. | 17:03 |
| cr3 | is it possible to build arm packages in a public personal ppa? | 18:54 |
| jelmer | cr3: IIRC yes, but there's a flag in the PPA that has to be enabled by a commercial admin to allow ARM building | 18:58 |
| cr3 | jelmer: excellent, so I should open a question against launchpad itself then. thanks! | 18:59 |
| === matsubara is now known as matsubara-afk | ||
| === lifeless_ is now known as lifeless | ||
| === matsubara-afk is now known as matsubara | ||
| lifeless | fun - bug 1039702 | 20:34 |
| _mup_ | Bug #1039702: Comments not posted <Launchpad itself:New> < https://launchpad.net/bugs/1039702 > | 20:34 |
| === Ursinha` is now known as Ursinha | ||
| sinzui | StevenK: This is my quick change to reconcile API and mail with UI | 22:19 |
| StevenK | sinzui: Found it and approved it. | 22:20 |
| wallyworld | sinzui: https://pastebin.canonical.com/72614/ | 22:57 |
| wallyworld | sinzui: StevenK: https://pastebin.canonical.com/72745/ | 23:00 |
| sinzui | wallyworld: +1 from me | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!