| timrc | bigjools, thanks :) | 00:18 |
|---|---|---|
| wgrant | timrc: Why do you need to? | 00:19 |
| wgrant | timrc: PPA packages by default build against all components. | 00:19 |
| timrc | wgrant, You won't like it... we want to upload proprietary packages to project PPAs and when we pull them into our archive "downstream" route them into a private component | 00:22 |
| timrc | wgrant, it would be easy to do this if we could publish packages to different components in the PPA | 00:22 |
| wgrant | timrc: You're not wrong :) | 00:22 |
| wgrant | Perhaps use different PPAs? | 00:22 |
| timrc | wgrant, that's an option.. was hoping for something more "elegant" | 00:23 |
| wgrant | I campaigned years ago for custom component support in PPAs. | 00:23 |
| wgrant | But ended up satisfied when they relented and implemented multiple PPAs per person | 00:23 |
| wgrant | It works well for most things | 00:23 |
| timrc | Yeah, there is a certain appeal as it naturally enforces a good separation | 00:25 |
| timrc | I'll list it as an option for my team to discuss... we basically don't have a good way of handling this scenario right now, though | 00:25 |
| timrc | people should quit making proprietary software :) | 00:26 |
| wgrant | That sounds like the easiest solution :) | 00:28 |
| timrc | Hm my 8 mo old daughter is trying to eat the heads off the meerkats on this 10.10 shirt... guess I better go feed her. Thanks for the assistance | 00:36 |
| === timrc is now known as timrc-afk | ||
| lifeless | it would be a step towards consistency to let ppas do components | 00:38 |
| wgrant | Letting PPAs have Ubuntu's components is not particularly useful | 00:42 |
| wgrant | Letting them have custom components might be | 00:42 |
| cjwatson | Except for PPAs intended to be copied to Ubuntu | 00:44 |
| cjwatson | I mean, custom components wouldn't hurt if done right, but in that case letting them have Ubuntu's components is useful | 00:45 |
| lifeless | letting them have the same components would permit removing special case code | 00:45 |
| cjwatson | components do still need to be per-archive | 00:46 |
| cjwatson | (e.g. Debian) | 00:46 |
| lifeless | yes indeed | 00:46 |
| wgrant | Exactly. | 00:46 |
| wgrant | They need to be per-archive | 00:46 |
| wgrant | (DDs had some of this vaguely specced out, even up to dependencies between components and archives) | 00:48 |
| lifeless | one month f changes to devel: | 00:53 |
| lifeless | 586 files changed, 13951 insertions(+), 5928 deletions(-) | 00:53 |
| lifeless | not so much stable on loc | 00:53 |
| wgrant | 3659 files changed, 97472 insertions(+), 95512 deletions(-) | 00:56 |
| wgrant | 2011-12-01 -> 2012-03-31 | 00:56 |
| wgrant | Not so bad | 00:56 |
| lifeless | thats better yes | 00:56 |
| wgrant | 2345 files changed, 58185 insertions(+), 59554 deletions(-) | 00:57 |
| wgrant | 2012-01-01 -> 2012-03-31 | 00:57 |
| cjwatson | 1025 files changed, 40735 insertions(+), 35055 deletions(-) | 00:58 |
| cjwatson | since new policy (so 2012-02-10 -> now) | 00:58 |
| bigjools | lifeless: PPAs used to have components and we removed them | 00:59 |
| bigjools | it confused the heck of out a lot of users | 00:59 |
| wgrant | lifeless: https://lpstats.canonical.com/graphs/SourcherryCPU/20120314/20120413/ is interesting | 01:15 |
| wgrant | 9.1 stabilised CPU usage and cut it by 40% | 01:15 |
| wgrant | I wonder if it was the new slony | 01:16 |
| wgrant | Nope, not slony | 01:19 |
| lifeless | pg 9.1 perhaps | 01:20 |
| === timrc-afk is now known as timrc | ||
| wgrant | It was clearly at the time of the upgrade, and slony wasn't upgraded at the same time, so it was probably 9.1 itself, yes. | 01:20 |
| lifeless | did pages get faster tho? | 01:21 |
| timrc | in theory I could just use a derived distribution overlay with no packages and upload a package to restricted, right :)? | 01:21 |
| lifeless | yes | 01:22 |
| wgrant | timrc: Hahahahaha | 01:22 |
| wgrant | lifeless: We don't have a staging PPR, do we? | 01:22 |
| lifeless | don't think so | 01:23 |
| lifeless | pick a search thats slow hot and try it | 01:23 |
| lifeless | on both prod & qas | 01:23 |
| timrc | cjwatson, when creating a PPA you could define the PPA as an Ubuntu archive or a Customer archive or something, but seeing as how this will never get developed, probably not worth discussing | 01:24 |
| timrc | Customer? Custom | 01:25 |
| wgrant | lifeless: Bug searches aren't faster AFAICR | 01:25 |
| timrc | At any rate we'll figure out some way to horribly abuse LP, jk | 01:25 |
| lifeless | flacoste: http://www.forbes.com/sites/stevedenning/2011/07/08/the-five-big-surprises-of-radical-management/ | 02:18 |
| lifeless | wgrant: do you know where the bug is about lazr.restfulclient not respecting the type of resources in collections? | 02:29 |
| wgrant | lifeless: wadllib | 02:34 |
| wgrant | Bug #340935 | 02:35 |
| _mup_ | Bug #340935: Resources are only instantiated using the WADL predicted type, not the actual found type <wadllib:Triaged> < https://launchpad.net/bugs/340935 > | 02:35 |
| * wallyworld__ is sad that his computer has started to spontaneously reboot after the latest updates were applied :-( | 02:42 | |
| lifeless | wallyworld__: maybe its building up credit | 02:43 |
| lifeless | wallyworld__: so it won't have to reboot layer | 02:43 |
| wallyworld__ | hah | 02:43 |
| wallyworld__ | like LOC | 02:43 |
| lifeless | indeed | 02:44 |
| wallyworld__ | if i'm lucky i can work for say 10 minutes each time | 02:44 |
| lifeless | anything in syslog? | 02:44 |
| lifeless | you could try putting tail -f /var/log/syslog in a terminal, pinned to top | 02:44 |
| lifeless | might catch a glimpse | 02:44 |
| wallyworld__ | haven't looked yet, just trying to quickly land some branches first | 02:45 |
| * bigjools hides the Boris Spike code from wallyworld__ | 02:47 | |
| wallyworld__ | who is Boris? | 02:47 |
| bigjools | have you seen Goldeneye? | 02:47 |
| wallyworld__ | a long time ago | 02:47 |
| lifeless | rick_h: around ? | 02:51 |
| rick_h | lifeless: yea, just got home | 02:52 |
| lifeless | hey | 02:52 |
| lifeless | so I'm curious why you used PersonNotification manually | 02:52 |
| lifeless | like | 02:52 |
| lifeless | its a background sending thing | 02:52 |
| lifeless | other uses of it use PersonNotificationSet.add(..) and don't call send | 02:52 |
| lifeless | (I'm also curious why you used it at all vs just sending the message) | 02:53 |
| wallyworld__ | anyone know where traversal stuff like stepthrough is tested? | 02:53 |
| wallyworld__ | or the ++model++ stuff | 02:53 |
| rick_h | lifeless: so for part 1, not sure. I just loaded up the object and that seemed to be the use. I could have misused it I suppose. loading it up now. | 02:53 |
| rick_h | lifeless: for part 2. I used it after discussing ways of sending emails. A background process sounded good so requests weren't hung up on smtp/in band stuff | 02:54 |
| rick_h | lifeless: I forget who pointed it out to be as a pretty light easy to use way to get emails scheduled | 02:54 |
| wallyworld__ | found the ++model++ tests | 02:54 |
| rick_h | lifeless: either deryck or sinzui I think since I chatted with both of them in pre-impl. | 02:55 |
| rick_h | lifeless: but yea, you're right, I shouldn't have called send and I shouldn't have patched send to override the email since it's not backgrounding like I wanted and defeats the purpose | 02:56 |
| rick_h | compleetely missed that | 02:56 |
| rick_h | except spelled better | 02:56 |
| lifeless | so the reason we have background stuff is for teams | 02:58 |
| rick_h | lifeless: ah, I see where I went wrong. So most code uses the Set object, but I wanted to override the To addr so I went after the raw PersonNotificatoin object | 02:58 |
| lifeless | that may notify thousands | 02:58 |
| StevenK | wgrant: LP.cache.context.information_type == undefined :-( | 02:58 |
| lifeless | this is for notifying of changes to individuals | 02:58 |
| rick_h | lifeless: ok, I just assumed it's good practice since things like slow/delayed smtp servers could cause request timeouts/etc | 02:58 |
| lifeless | rick_h: we have local smtp on every server | 02:59 |
| lifeless | rick_h: sending hundreds of mails is a problem, sending a fixed number isn't | 02:59 |
| lifeless | rick_h: thanks, this helps me out | 02:59 |
| rick_h | lifeless: ok, I did notice there seems to be a few ways to send emails out and when I mentioned background this was pointed out to me | 02:59 |
| wgrant | StevenK: Ah, possibly because this is a bugtask, not a bug. | 02:59 |
| wgrant | StevenK: Hopefully the bug is there as well. If not, put it there :) | 03:00 |
| rick_h | lifeless: but yea, I did it wrong because when a user wants to change their preferred email I needed to send to their previous addr and PersonNotification doesn't support it | 03:00 |
| rick_h | which is why I couldn't copy what other uses were doing directly | 03:00 |
| StevenK | wgrant: self_link is the bug. | 03:00 |
| StevenK | wgrant: Just trying to find where is defined | 03:01 |
| wgrant | StevenK: Try LP.cache.bug.information_type | 03:02 |
| StevenK | Ooh, that looks good. | 03:03 |
| * StevenK nails wallyworld_ to IRC. | 03:03 | |
| wallyworld_ | can you make my pc stop rebooting? | 03:04 |
| rick_h | lifeless: so while I'm fixing that in the morning the goal is to ditch the event as well? | 03:04 |
| StevenK | I'd watch tail -f /var/log/syslog like lifeless suggested | 03:04 |
| StevenK | Or downgrade what you recently upgraded | 03:04 |
| wallyworld_ | it just happens to quickly for me to see what syslog says | 03:06 |
| wallyworld_ | i will try downgrading but it was a large number of packages that were upgraded | 03:06 |
| lifeless | rick_h: well, I'm doing a sketch on it as you're past EOD | 03:06 |
| StevenK | Do you have another machine? | 03:06 |
| wallyworld_ | > 50 or 60 | 03:06 |
| wallyworld_ | nope | 03:06 |
| rick_h | lifeless: yea, I've got to hit the sack soon. Couple of late nights for me | 03:06 |
| StevenK | wallyworld_: No even running Windows? | 03:06 |
| wallyworld_ | my home theatre pc | 03:07 |
| rick_h | lifeless: thanks, shoot me a message on status and I'll pick up/finish whatever needs doing in the morning. Thanks for pointing out my misuse of the notification. | 03:07 |
| rick_h | missed in code review and my own look through it today | 03:07 |
| StevenK | wallyworld_: Install PuTTy on it, ssh into your laptop and tail syslog over it? | 03:07 |
| wallyworld_ | StevenK: you are an ideas man. i may just try that. thanks | 03:07 |
| StevenK | Joustling sticks? | 03:08 |
| StevenK | 'Ideas man' just reminds me of The Castle. | 03:08 |
| wallyworld_ | tell him he's dreamin' | 03:09 |
| wallyworld_ | that's going straight to the pool room | 03:09 |
| wallyworld_ | why would you eat out? | 03:09 |
| StevenK | wallyworld_: Does 'if (some boolean) {' do what I expect in JS, or should I say === true ? | 03:11 |
| wallyworld_ | StevenK: it will evaluate to false if undefined also | 03:12 |
| wallyworld_ | StevenK: so if that's what you want then that's ok | 03:13 |
| lifeless | wow we are so inconsistent about From: | 03:14 |
| lifeless | rick_h: btw, why does this generate multiple emails in those doc tests? | 03:15 |
| lifeless | rick_h: are we also notifying separately to the new address? | 03:15 |
| lifeless | rick_h: nvm, figured it - we're doing a token challenge | 03:15 |
| lifeless | what stops teams getting ssh keys / gpgkeys ? | 03:18 |
| wgrant | if params.distroseries is not None: | 03:26 |
| wgrant | parent_distro_id = params.distroseries.distributionID | 03:26 |
| wgrant | else: | 03:26 |
| wgrant | parent_distro_id = 0 | 03:26 |
| wgrant | wat | 03:26 |
| * wgrant blames lifeless | 03:26 | |
| wgrant | wtf is this | 03:27 |
| lifeless | I don't recognise that | 03:30 |
| lifeless | parent_distro sounds like UDD | 03:30 |
| wgrant | It's in the structsub searching that you reworked | 03:30 |
| wgrant | No | 03:30 |
| lifeless | sorry, I mean DD | 03:31 |
| wgrant | Still not :) | 03:31 |
| wgrant | It's just the distro that owns the series | 03:31 |
| wgrant | In this case | 03:31 |
| wgrant | The constraint that uses it doesn't make much sense | 03:31 |
| wgrant | Not to mention the whole defaulting to 0 thing | 03:31 |
| lifeless | you've annotated the pre-move search to see it was me ? | 03:32 |
| wgrant | No/ | 03:32 |
| lifeless | revno: 14485 [merge] | 03:34 |
| lifeless | I was on lave | 03:34 |
| lifeless | leave | 03:34 |
| lifeless | wgrant: sinzui | 03:34 |
| wgrant | Still your fault :) | 03:35 |
| lifeless | hah! | 03:35 |
| lifeless | rick_h: btw telling folk that an ssh key *can't* be used anymore isn't important | 03:37 |
| lifeless | rick_h: it doesn't open up security holes ;) | 03:37 |
| wgrant | I think it's still interesting. | 03:38 |
| lifeless | *adding* one is crucially important | 03:39 |
| wgrant | Certainly | 03:39 |
| rick_h | lifeless: yes, deryck thought that if someone removed your ssh key and potentially locked you out of things like bzr access you'd want to know why. | 03:44 |
| rick_h | lifeless: but I agree, it's on the lower end of the notification scale | 03:44 |
| lifeless | I think its nice in an auditord sense | 03:46 |
| lifeless | I'm not sure its worth an email | 03:46 |
| lifeless | not to worry, I'm keeping it | 03:47 |
| rick_h | lifeless: yes, this discussion brought out a new bug I filed on adding some auditing support because if someone does change your email we can't verify what it was/you are who you say you are easiliy | 03:47 |
| lifeless | stevenk has an auditord nearly ready | 03:47 |
| rick_h | lifeless: or that we can generate a list of all the data a malicious user changed so that we make sure we can revert all the changes, etc | 03:47 |
| lifeless | rick_h: log files :> | 03:48 |
| rick_h | lifeless: ah, good to know then | 03:48 |
| rick_h | lifeless: on the sql queries? Not sure what all we have there. | 03:48 |
| rick_h | lifeless: it was brought up that we could try to do some sql backup/etc pulling, but painful | 03:48 |
| rick_h | lifeless: but yea, that was deemed outside the scope of the current branch and the idea is to prevent it from happening | 03:49 |
| lifeless | huh, no. | 03:49 |
| lifeless | we email on these things | 03:49 |
| lifeless | they are all important | 03:49 |
| lifeless | so there should be email logs for them all | 03:49 |
| lifeless | not in smtp, in our email engines. | 03:49 |
| lifeless | that said, its 3 settings | 03:50 |
| lifeless | preferred mail | 03:50 |
| lifeless | (and all contact addresses arguably) | 03:50 |
| lifeless | ssh keys | 03:50 |
| lifeless | gpg keys | 03:50 |
| rick_h | right, but we can restore data based off the email logs? | 03:50 |
| lifeless | I think saying to someone 'we've nuked the settings, please set up the way you want' is a simple and solid answer | 03:50 |
| lifeless | its not like restoring complex data | 03:50 |
| rick_h | lifeless: ah ok | 03:50 |
| lifeless | or to put it another way | 03:51 |
| lifeless | even if we *did* restore it | 03:51 |
| lifeless | any Ubuntu dev worth their salt would manually verify it all anyway. | 03:51 |
| rick_h | right, I think the idea was more someone jumps in irc "I can't login!" "who are you? what's your email?...that doesn't match what I've got, let's see if it's changed and what it was?" | 03:51 |
| lifeless | rick_h: another thing we should notify on is adding oauth tokens | 03:51 |
| lifeless | rick_h: an audit trail for that would be good, and I'm +1 on having an audit trail | 03:52 |
| rick_h | lifeless: ok, haven't seen taht | 03:52 |
| lifeless | (again, StevenK :)) | 03:52 |
| rick_h | lifeless: yea, cool | 03:52 |
| lifeless | rick_h: when you allow an app access to your account, would you object to being told that that has happened ? | 03:52 |
| rick_h | sorry, haven't seen the oauth stuff, cool on the WIP audit trail | 03:53 |
| rick_h | lifeless: not sure, I've got to check the oauth use. Is that just for apps? scripts using api? | 03:56 |
| rick_h | lifeless: I guess it should be rare I get these right? Changing keys, email is pretty rare. Annually maybe in practice worst case? | 03:56 |
| lifeless | right | 03:57 |
| lifeless | generally its one-time setup | 03:57 |
| lifeless | rick_h: did you do GPG keys when you did this ? | 03:59 |
| lifeless | rick_h: or do they already notify ? | 03:59 |
| rick_h | yea, they already get an email because you have to decrypt your email with the key to verify | 03:59 |
| rick_h | so gpg keys aren't in this | 03:59 |
| lifeless | does that go to the preferred address | 03:59 |
| lifeless | or the address in the key | 04:00 |
| rick_h | preferred | 04:00 |
| lifeless | cause if it goes to the address in the key it would be useless | 04:00 |
| rick_h | I believe, I'll have to dbl check I guess | 04:00 |
| lifeless | I believe it goes to the address in the key | 04:00 |
| lifeless | so we know they aren't impersonating someone via the key | 04:01 |
| rick_h | k, I'll double check. It's hidden in some browser action so I've got to find it again. | 04:03 |
| lifeless | now where is that doc on Launchpads voice | 04:03 |
| rick_h | https://dev.launchpad.net/UserInterfaceWording/CanonicalStyleGuide?highlight=%28voice%29 looks like what you might mean? | 04:04 |
| lifeless | https://dev.launchpad.net/UserInterfaceWording | 04:05 |
| rick_h | bah, I fail at going to bed during the right day | 04:07 |
| rick_h | I'm really gone to bed this time. Will look over the wording docs lifeless, thanks for pointing out. Looks like I wrapped wrongly off the bat | 04:08 |
| lifeless | rick_h: :P | 04:09 |
| lifeless | rick_h: gnight | 04:09 |
| lifeless | oh wow | 04:24 |
| wgrant | ? | 04:24 |
| lifeless | thats a fun hole | 04:24 |
| lifeless | we validate a preferred but unvalidated email address when a different preferred email address is set | 04:25 |
| wgrant | Preferred but unvalidated? | 04:25 |
| wgrant | what? | 04:25 |
| wgrant | lifeless: Anything setting an unvalidated email to PREFERRED without first validating it is a bug. | 04:26 |
| wgrant | Preferred > validated | 04:26 |
| lifeless | wgrant: as I said | 04:30 |
| lifeless | 'thats a fun hole' | 04:30 |
| lifeless | person.py | 04:31 |
| lifeless | look for existing_preferred_email.status = EmailAddressStatus.VALIDATED | 04:31 |
| wgrant | lifeless: An existing preferred email is by definition already validated. | 04:31 |
| wgrant | Because we're setting it from preferred to validated | 04:31 |
| lifeless | wgrant: oh, I see, right | 04:31 |
| lifeless | so this could be more clear | 04:31 |
| wgrant | And preferred is stricter than validated | 04:31 |
| lifeless | also, we have to totally different concepts conflated. Win. | 04:31 |
| wgrant | Yes. | 04:31 |
| wgrant | Win | 04:31 |
| lifeless | I would model this with preferred as a pointer from person, constrainted by trigger checks to be validated. | 04:32 |
| lifeless | anyhow | 04:32 |
| lifeless | thats then, this is now | 04:32 |
| wgrant | The idea was to avoid triggers, I believe. | 04:32 |
| wgrant | Or you could also have a preferred flag | 04:32 |
| lifeless | and a composite unique index | 04:33 |
| lifeless | or whatever | 04:33 |
| wgrant | With UNIQUE emailaddress(person) WHERE preferred | 04:33 |
| wgrant | Right | 04:33 |
| wgrant | It's insane. | 04:33 |
| wgrant | But 2005 | 04:33 |
| wgrant | So we sort of have to live with it | 04:33 |
| StevenK | It doesn't sound that hard to shift away. | 04:34 |
| lifeless | its straight forward | 04:34 |
| lifeless | little returns | 04:34 |
| lifeless | probably not the most significant thing to improve right now | 04:34 |
| StevenK | More straight-forward than bug.{private,security_related} -> bug.information_type :-) | 04:34 |
| wgrant | No | 04:35 |
| wgrant | Only a few places touch that | 04:35 |
| wgrant | There are dozens upon dozens of places that touch emailaddress.status == 4 | 04:35 |
| lifeless | rick_h: I've pushed an opinionated branch to https://code.launchpad.net/~rharding/launchpad/email_notice_959482/+merge/99995 | 04:45 |
| lifeless | rick_h: its about half the size, a significant chunk of which was the event overhead + the need for dedicated per-event tests. | 04:45 |
| StevenK | wallyworld_: O hai. | 04:46 |
| lifeless | rick_h: let me know what you think, I obviously don't want to be blocking you in any way. | 04:46 |
| StevenK | wallyworld_: Since I moved the ChoiceSource stuff into its own module, Y.one('body') seems to return the enclosing div. | 04:47 |
| wallyworld_ | StevenK: that seems strange at first thought | 04:47 |
| StevenK | wallyworld_: It seems to be strange. If I change it to a private type, the enclosing div turns red. | 04:48 |
| wallyworld_ | StevenK: Y.one('body') should return the html element <body> | 04:49 |
| StevenK | Yes, agreed. | 04:49 |
| wallyworld_ | fiik what's up then :-( | 04:50 |
| wallyworld_ | have you looked at the html source in the browser to make sure there isn't anything stupid in there? | 04:51 |
| wallyworld_ | or tun it through an html validator? | 04:51 |
| wallyworld_ | run | 04:51 |
| StevenK | Now it works. I think it's toying with me. | 04:52 |
| wallyworld_ | like my pc hardware | 04:52 |
| StevenK | wallyworld_: Oh, could I get your help with the JS fallback? If I set href to the link in the TAL, the JS never fires. | 04:53 |
| wallyworld_ | StevenK: you have set the onclick handler? | 04:53 |
| StevenK | I thought the ChoiceSource does that for me? | 04:53 |
| wallyworld_ | yes, should do | 04:54 |
| wallyworld_ | i have a quick look at the source code to see if it is doing anything dumb | 04:54 |
| wgrant | Instance i-4ea81529 starting................................................................................................................................................................................... started on ec2-67-202-7-98.compute-1.amazonaws.com | 04:56 |
| wgrant | Started in 15 minutes 46 seconds | 04:56 |
| wgrant | odd | 04:56 |
| StevenK | wgrant: Orsum. | 04:56 |
| StevenK | wallyworld_: Sigh, that works now too. | 04:57 |
| wallyworld_ | StevenK: maybe browser caching issue? | 04:57 |
| StevenK | Hm. Maybe. | 04:57 |
| StevenK | AssertionError: The vocabulary must implement IEnumeratedType | 05:03 |
| StevenK | :-( | 05:03 |
| wgrant | blink | 06:16 |
| wgrant | lp.bugs.model.bugtasksearch._build_pending_bugwatch_elsewhere_clause | 06:17 |
| wgrant | First bit, 'if params.product' | 06:17 |
| wgrant | AND RelatedBugTask.id = BugTask.id | 06:18 |
| wgrant | Am I not thinking it through correctly, or is that inverted? | 06:18 |
| wgrant | Ah | 06:23 |
| wgrant | @property | 06:23 |
| wgrant | def pending_bugwatches_url(self): | 06:23 |
| wgrant | if not IProduct.providedBy(self.context): | 06:24 |
| wgrant | return None | 06:24 |
| wgrant | So that codepath is never exercised, I guess | 06:24 |
| lifeless | wgrant: did you sstart a thread on tag sort order on the list ? | 06:27 |
| wgrant | No, I'll do that now. | 06:28 |
| adeuring | good morning | 07:44 |
| === almaisan-away is now known as al-maisan | ||
| gmb | Does anyone have a spare second to run a test for me in their lp dev environment? | 08:45 |
| lifeless | gmb: p'rhaps | 08:45 |
| gmb | lifeless, bin/test -t externalbugtracker-bug-imports.txt if you'd be so kind. | 08:46 |
| lifeless | hah, out of date schema | 08:47 |
| lifeless | making new | 08:47 |
| gmb | lifeless, Oh ,wait. | 08:47 |
| gmb | No need. | 08:47 |
| gmb | I see why it's failing | 08:47 |
| gmb | It's because I'm stupid. | 08:47 |
| lifeless | do -not- give me straight lines like that | 08:47 |
| gmb | :) | 08:48 |
| lifeless | I won't be able to help myself if you do | 08:48 |
| gmb | Turns out that it helps if you're running tests in a Lucid (or Oneiric) container, not on Precise. My lxc container had exited and I hadn't noticed. | 08:48 |
| lifeless | ah yes, that will mess you up | 08:48 |
| lifeless | I don't have a non-lxc postgresql, helps avoid that confusion | 08:49 |
| gmb | Yeah, I think this is my cue to nuke mine :) | 08:49 |
| gmb | Otherwise I'm going to do this again. | 08:49 |
| lifeless | ah, insanity! | 08:49 |
| gmb | :) | 08:50 |
| czajkowski | it's wrong to be so happy with only having 1 ticket in my RT queue but I am :D | 08:54 |
| czajkowski | rt queue has been fully smacked :D | 08:54 |
| === al-maisan is now known as almaisan-away | ||
| StevenK | jml: Hai. Are you able to QA r15074 today? | 11:27 |
| jml | StevenK: I guess. | 11:28 |
| jml | StevenK: I'm surprised that's how it works though | 11:28 |
| StevenK | jml: Really? Developers are mostly responsible for their own QA. In this case, you should be able to ask the webops to make you an admin on qas for short amount of time. | 11:29 |
| jml | StevenK: I'm trusted as a judge of behaviour but not of code quality? | 11:30 |
| jml | anyway | 11:30 |
| StevenK | jml: In what way, that you need a review? | 11:30 |
| jml | StevenK: yes. | 11:31 |
| StevenK | jml: Everyone has their branches reviewed, except if the change is small and well-understood, in which case, graduated reviewers can self-review. So don't feel like it's just you. | 11:32 |
| StevenK | jml: And you wrote the feature so you should have a very good understanding of how it is supposed to behave. | 11:33 |
| jml | Yeah, that's exactly how it works. | 11:33 |
| jml | StevenK: anyway, I can QA the feature today (UK). | 11:34 |
| StevenK | jml: Thanks. If you don't feel comfortable QA'ing, then please feel free to hand it off to a LP dev if they agree to do it -- we just tend to assume the developer who wrote it will do the QA. | 11:35 |
| === matsubara-afk is now known as matsubara | ||
| === almaisan-away is now known as al-maisan | ||
| benji | jml: are you available to review my branch which will (soon) bring the TSFM tests inline with the improved tests on your branch? | 12:54 |
| jml | benji: yes, roughly speaking | 12:54 |
| jml | benji: I mean, I can do it today. A synchronous review is probably beyond me. | 12:54 |
| benji | jml: that's cool, thanks | 12:55 |
| benji | jml: while I have you on the line, do you know anything about TestThreadSafeForwardingResult.test_forwarding_methods and why it does what it does (testtools/tests/test_testresult.py) | 12:56 |
| benji | I don't understand the underlying intent of the test. And the sparse comments in the test seem to disagree (or at least are irrelevent) to what the test actually verifies. | 12:56 |
| jml | looking | 12:56 |
| === rick_h changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| jml | benji: No idea, sorry. | 12:58 |
| benji | jml: thanks anyway | 12:58 |
| jml | benji: perhaps ask lifeless when he gets back online. | 12:58 |
| benji | yep | 12:58 |
| === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett, rick_h* | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| adeuring | abentley: mumble? | 13:58 |
| abentley | adeuring: coming | 13:59 |
| abentley | adeuring: https://pastebin.canonical.com/63588/ | 14:02 |
| === al-maisan is now known as almaisan-away | ||
| rick_h | abentley: comments on teh review, please also make the LoC note in the MP. | 14:58 |
| deryck | rick_h, hey, dude. I can chat about your branch now. 2 minutes to warm coffee and meet in a hangout, cool? | 15:01 |
| === salgado is now known as salgado-lunch | ||
| rick_h | deryck: sounds god | 15:03 |
| rick_h | good | 15:03 |
| benji | jml: https://code.launchpad.net/~benji/testtools/modernize-tsfr/+merge/101749 awaits when you have a moment. | 15:08 |
| jml | benji: ta | 15:09 |
| jml | benji: have looked at it long enough to know that I need to have a detailed look. | 15:12 |
| benji | jml: ok; thanks | 15:12 |
| jml | benji: will try to get to it today (UK) | 15:12 |
| benji | jml: I appreciate it. | 15:12 |
| abentley | rick_h: Thanks. done. | 15:18 |
| abentley | jcsackett: The imports in runner are explained by the comment "Avoid importing from lp.services.job.celeryjob where not needed, to avoid configuring Celery when Rabbit is not configured." | 15:34 |
| * jcsackett looks again | 15:35 | |
| jcsackett | abentley: so it is, ignore my blind eyes. :-) | 15:35 |
| abentley | jcsackett: cool. I'll add a comment to the other one, though. | 15:35 |
| jcsackett | thanks, abentley | 15:35 |
| adeuring | rick_h: could you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/abort-transaction-in-job-queue/+merge/101762 ? | 15:42 |
| rick_h | will do adeuring I'll put it next on my list | 15:42 |
| adeuring | rick_h: thanks! | 15:42 |
| deryck | gary_poster, hi. got a sec? | 15:48 |
| sinzui | Looks like wordpress's autosave feature is broken on Lp's blog and I just lost 90 minutes of writing when it's JS went tits up. It then insults me by saying "howdy" when I log back in. If I could accomplish one thing today, please let me stab the cowboyism to death. | 15:58 |
| jml | benji: have replied. am available to chat in real-time if you want. | 16:00 |
| benji | jml: cool, I'll read it now | 16:00 |
| benji | jml: interesting; if your understanding of TSFR is correct, I don't see that it ever achieved it's aim, which is entirely possible | 16:02 |
| jml | benji: I'm pretty sure it's got very close. | 16:02 |
| benji | my understanding (gained only though reading the code) is that it intended only to make sure individual calls did not overlap, not that calls for different tests didn't overlap | 16:03 |
| jml | benji: startTest() sets the test start tim, and then on receiving $RESULT, then runs some semaphore-protected code that does (ignoring tags): | 16:04 |
| jml | * time(start_time) | 16:04 |
| jml | * startTest(test) | 16:04 |
| jml | * time(now) | 16:04 |
| jml | * add$RESULT(test, *args, **kwargs) | 16:04 |
| jml | * stopTest(test) | 16:05 |
| jml | multiple threads, each with their own TSFR, but with a shared semaphore and a shared target result object, ... | 16:06 |
| jml | imagine the target result object dumping subunit output | 16:06 |
| jml | it *has* to be: | 16:07 |
| jml | test: foo | 16:07 |
| jml | success: foo | 16:07 |
| jml | test: bar | 16:07 |
| jml | success: bar | 16:07 |
| jml | and since the parallel runner isn't completely broken, I'm assuming that's how it behaves now. | 16:07 |
| jml | granted, that might be quite a hefty assumption | 16:07 |
| benji | :) | 16:08 |
| benji | jml: right, it works now, and I think I can preserve that contract (start/result/stop occur atomicly), but it won't be able to comply with the other general contracts, for example, start/tags/success/tags/stop won't work correctly unless we go to great lengths (as far as I can tell) | 16:09 |
| jml | hmm. | 16:10 |
| jml | benji: I haven't really thought about tags in that context, so I couldn't say one way or another. | 16:10 |
| jml | benji: I *think* I can address your original concern about a thing that applies a constant set of tags to each test though. | 16:10 |
| benji | jml: now that I have a deeper understanding of what TSFR needs to do, let me take a stab at it and follow up with you when I succeed or fail | 16:12 |
| jml | benji: ok. | 16:12 |
| jml | benji: I think all you need is something like this though: http://paste.ubuntu.com/926640/ | 16:13 |
| benji | I hope it's that simple. | 16:13 |
| === salgado-lunch is now known as salgado | ||
| === matsubara is now known as matsubara-lunch | ||
| jml | benji: I've merged forward-current-tags into testtools trunk, fwiw. | 16:30 |
| rick_h | adeuring: ping, so the MP talks a lot about the abort_transaction, but what about hte manage transaction? | 16:34 |
| adeuring | rick_h: that paramater existed a bit longer; it was just not yet tested. | 16:44 |
| adeuring | rick_h: we need this parameter because... | 16:44 |
| rick_h | adeuring: right, but just added to the start/complete/fail, etc. | 16:44 |
| rick_h | it seems that it'd be the same for all methods of a job. More of a job "starts_transaction" parameter on the job itself | 16:45 |
| rick_h | can you have that set on start but not complete for instance? | 16:45 |
| adeuring | the job runner in the main LP code managed the transactions, while the lazr.jobrunner does not do this, so we had to move this to Job.start(), complete() etc | 16:45 |
| adeuring | rick_h: no, the settings should be consistent in the call sites, and it is | 16:46 |
| rick_h | ok, so I'm not seeing the tie in. Ok | 16:46 |
| rick_h | adeuring: yea, just looking here it seems you could have a mix up of manage_transaction in one place but not another and I worry about that being consistant | 16:46 |
| rick_h | rather than method params it checking an object level attribute that it has a transaction to manage or something | 16:47 |
| adeuring | rick_h: you are right, but there is only a minor risk. Most status handling is done now in lazr.jobrunner, which always sets manage_transaction=True; there are a few calls in the main LP code like Job.wueue(), where manage_transaction is not specified at all, i.e., it is False. (to avoid "premature" commits) | 16:48 |
| adeuring | rick_h: Using something like Job.teansaction an interesting suggestion, but I would prefer to implement that in a differnt branch... | 16:50 |
| === deryck is now known as deryck[lunch] | ||
| rick_h | adeuring: ok, thanks | 16:50 |
| gary_poster | deryck[lunch], sorry, was lunching myself | 16:51 |
| rick_h | adeuring: ok, noted my question, can you reply with that possibly follow up branch and the LoC notes and I'll mark ok | 16:53 |
| adeuring | rick_h: ok | 16:53 |
| rick_h | adeuring: ty | 16:53 |
| adeuring | rick_h: answered | 17:15 |
| rick_h | adeuring: ok, thanks for the discussion. Ok'd | 17:16 |
| adeuring | rick_h: thanks! | 17:16 |
| === matsubara-lunch is now known as matsubara | ||
| === deryck[lunch] is now known as deryck | ||
| deryck | hi, gary_poster. just wondering a bit about our fork of python-openid and seeing branches from you and wgrant. | 17:54 |
| deryck | gary_poster, wondering why we forked and stayed behind current release. if any patches were applied upstream. that kind of thing. | 17:54 |
| gary_poster | deryck, hey. um, I don't remember openid forks but that doesn't mean I didn't do it. :-) I just did python-memcached. Lemme see if versions.cfg says anything interesting | 18:03 |
| deryck | gary_poster, versions suggests wgrant has the latest fork. which looked to be off your branch. | 18:04 |
| jml | benji: how goes it? | 18:05 |
| benji | jml: I've decided to leave TSFR be for the moment and implement my worker ID tagging result wrapper and then see if the bugs I expect in TSFR's tag handling really exist and actually bite me; if they do, then I'll at least have a concrete idea of what is wrong with TSFR and what I want it to do | 18:07 |
| jml | benji: a sound plan. | 18:07 |
| gary_poster | deryck, I'm afraid I think I need to point you to flacoste. Perhaps he remembers. According to wgrant's branch (https://code.launchpad.net/~wgrant/python-openid/python-openid-2.2.1-fix676372) he branched off of flacoste's branch from Nov 2008, which was very soon after I started work here. bzr log versions.cfg only mentions what wgrant did ("[r=lifeless][bug=676372][rollback=12290] Use a custom python-openid") AF | 18:13 |
| gary_poster | AICT. I'm still digging more, but perhaps it would help to know why you thought it was my branch? Maybe I can dig from there | 18:13 |
| deryck | gary_poster, ah, guilt by assumption then. :) | 18:15 |
| gary_poster | heh, deryck :-) | 18:15 |
| deryck | gary_poster, I looked at https://code.launchpad.net/python-openid/ and saw your branch there was older. | 18:16 |
| gary_poster | deryck, ah. Well, that looks like it had a reason at the time, but is no longer needed | 18:17 |
| deryck | gary_poster, I can email wgrant on list then and see if he recalls the details here. thanks. | 18:17 |
| gary_poster | cool, welcome | 18:17 |
| deryck | fwiw, I need a fixes in a recent python-openid, and either need to backport or apply our forked patches. | 18:17 |
| sinzui | jcsackett, what is blocking us from showing the links to view bugs and branches that are shared with users? | 18:21 |
| jcsackett | sinzui: not sure what you mean. +sharing does have links to the details page, details page does have links to the various bugs and branches. at least on qastaging. | 18:23 |
| jcsackett | sinzui: i'm assuming i'm misunderstanding your question. | 18:23 |
| sinzui | not in production? did you not ask for the feature flag to be enabled? | 18:23 |
| sinzui | https://launchpad.net/launchpad/+sharing | 18:24 |
| lifeless | rick_h: hi | 18:25 |
| jcsackett | sinzui: we hadn't turned it on b/c there were some bugs to be addressed, but it looks like wallyworld_ took care of them. | 18:25 |
| jcsackett | so, nothing's blocking us. shall i make the request? | 18:25 |
| rick_h | lifeless: howdy (/me ducks from sinzui) | 18:26 |
| sinzui | jcsackett, yes pleased. I will second it | 18:26 |
| lifeless | rick_h: what did you think of my sketch? | 18:37 |
| rick_h | lifeless: I've only had a quick change to glance at it so far. Busy OCR day. | 18:38 |
| lifeless | kk | 18:38 |
| rick_h | lifeless: think it's good and I'll be using that to clean up and try to get my branch finished up by tomorrow. | 18:39 |
| lifeless | if you want to talk about it at any point, I'll be around, slightly offset-earlier day today | 18:39 |
| rick_h | lifeless: yea, np. I think it's been a process, but good stuff. | 18:39 |
| lifeless | rick_h: so the '1 callsite' comment i made the other day - thats a heuristic - didn't apply in this case, but when it does, its just another bit of evidence that an event may be the wrong fit | 18:40 |
| rick_h | lifeless: yes, and I mentioned during impl calls with deryck that it didn't feel quite right since it wasn't really an event off of the Person as it started out once we hit things like logintoken/ssh keys | 18:41 |
| rick_h | lifeless: but change some names and you try to make yourself feel better. | 18:41 |
| rick_h | but it's been good, I've learned a lot about how stuff works in this branch | 18:41 |
| rick_h | lifeless: appreciate the time you've taken with me over the last few days on it | 18:42 |
| lifeless | my pleasure | 18:46 |
| bac | jcsackett, rick_h: have time for a review of a short change? https://code.launchpad.net/~bac/launchpad/bug-974617/+merge/101797 | 19:04 |
| rick_h | bac: looking | 19:06 |
| bac | thanks rick_h | 19:07 |
| lifeless | flacoste: hiya | 19:07 |
| rick_h | bac: ok'd and commented | 19:12 |
| bac | rick_h: thanks | 19:13 |
| bac | thanks jcsackett | 19:34 |
| bac | rick_h: i implemented both of your suggestions | 19:34 |
| rick_h | bac: cool, thanks | 19:35 |
| lifeless | flacoste: http://www.infoq.com/presentations/1000000-Daily-Users-and-No-Cache | 19:46 |
| lifeless | and | 19:46 |
| lifeless | flacoste: http://www.forbes.com/sites/stevedenning/2011/07/08/the-five-big-surprises-of-radical-management/ | 19:47 |
| gary_poster | lifeless, we have some tests that fail if bzr whoami is not set (and not guessable). Is this an indicator of a bug in the test, or should we set up a whoami value? | 19:56 |
| lifeless | those tests are incorrectly isolated | 19:57 |
| gary_poster | lifeless, cool, we will file bugs, thanks | 19:57 |
| lifeless | they need to either isolate a number of things themselves, or derive from one of the bzrlib TestCase base classes (e.g. TestCaseWithTransport or TestCaseWithTemporaryDirectory) | 19:57 |
| gary_poster | ack | 19:58 |
| lifeless | I wonder if we should special case subscription of open lists | 20:13 |
| lifeless | that is, make subscribing, or assigning, an open team to anything be a privileged (admin) action | 20:13 |
| lifeless | (see the recent shenanigans with the debian-ppas bug where the launchpad-dev *mailing list* was subscribed by a random list member | 20:14 |
| abentley | rick_h: could you please review https://code.launchpad.net/~abentley/launchpad/celery-job-layer/+merge/101806 ? | 20:14 |
| rick_h | abentley: sorry, EOD. | 20:20 |
| === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| rick_h | thanks, was just editing that. jcsackett might still able to/around | 20:20 |
| abentley | jcackett: are you up for solo reviewing? | 20:21 |
| jcsackett | abentley: sure. be a little bit but i can get to it before EOD. | 20:27 |
| abentley | jcsackett: cool, thanks. | 20:27 |
| jcsackett | np. | 20:27 |
| jcsackett | abentley: looked at the branch. r=me. | 21:12 |
| timrc | I'm getting an oops on staging... 1d44c531f28a13c40cb562e401dd7cf2 | 21:41 |
| timrc | effecting my ability to test a build in a PPA | 21:41 |
| timrc | hm ok, 3rd or so reload at least showed me the PPA page | 21:41 |
| lifeless | timrc: the OOPS- is part of the id | 21:45 |
| lifeless | timrc: just copy and paste the whole thing please | 21:45 |
| timrc | lifeless, It would just be OOPS-1d44c531f28a13c40cb562e401dd7cf2 but I was finally able to copy / re-build packages so I'm fine | 21:46 |
| SpamapS | OOPS-71384b1baaee6bfd54172741bf834dc7 | 21:46 |
| SpamapS | Anybody know why retrying a build would cause a timeout? | 21:46 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | SQL time: 8962 ms | 21:51 |
| lifeless | Non-sql time: 141 ms | 21:51 |
| lifeless | Total time: 9103 ms | 21:51 |
| lifeless | Statement Count: 35 | 21:51 |
| lifeless | 1. 8887.0 1 SQL-main-master | 21:52 |
| lifeless | UPDATE BuildFarmJob | 21:52 |
| lifeless | SET builder=NONE, date_finished=NONE, status=$INT, date_started=NONE, log=NONE | 21:52 |
| lifeless | WHERE BuildFarmJob.id = $INT | 21:52 |
| lifeless | row contention | 21:52 |
| SpamapS | lots of builds going on right now | 21:52 |
| lifeless | yet another symptom of the builddmaster being not-an-API-client | 21:52 |
| SpamapS | seems like that should be async entirely. like I'm not saying "tell me when you're done updating your database" I'm saying "tell me that you're going to retry that build" | 21:53 |
| lifeless | well, duh | 21:53 |
| lifeless | :) | 21:54 |
| SpamapS | same thing happens when I try to build anything it seems | 21:56 |
| lifeless | if you try a couple of times does it come good? | 21:58 |
| SpamapS | no | 21:58 |
| lifeless | if it doesn't, then we may have a melting down buildd manager, and I'll go chase that | 21:58 |
| lifeless | ok | 21:58 |
| SpamapS | after 3 I figured I'm part of the problem | 21:58 |
| lifeless | oh you are, fo'sure | 21:58 |
| wgrant | lifeless: Unrelated to buildd-manager | 22:01 |
| wgrant | SpamapS: That means it's already been retried by retry-depwait, but not committed yet | 22:01 |
| === jelmer_ is now known as jelmer | ||
| * timrc shakes fist at staging.launchpad.com... I hit reload and got the "code update in progress" | 22:11 | |
| * timrc will try this all again after his child goes to sleep, ttyl | 22:11 | |
| StevenK | Tis not .com | 22:12 |
| lifeless | timrc: staging.launchpad.net | 22:13 |
| lifeless | timrc: of course, if you mistyped, then again, COpy-paste is your friend ;) | 22:13 |
| timrc | I meant .net | 22:13 |
| lifeless | timrc: as for the timeout | 22:14 |
| lifeless | 1. 8355.0 1 SQL-main-master | 22:14 |
| lifeless | SELECT * | 22:14 |
| lifeless | FROM (( | 22:14 |
| lifeless | SELECT BinaryPackageBuild.distro_arch_series, | 22:14 |
| lifeless | you can see it https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1d44c531f28a13c40cb562e401dd7cf2#longstatements | 22:14 |
| timrc | lifeless, thanks | 22:15 |
| wgrant | ">From a data integrity perspective, we must not have two different | 22:18 |
| wgrant | sorts of data arguing: if there is a subscription, the user must have | 22:18 |
| wgrant | a grant." | 22:18 |
| wgrant | lifeless: false | 22:19 |
| wgrant | lifeless: That is at most an argument from usability | 22:19 |
| wgrant | Not integrity | 22:19 |
| lifeless | wgrant: actually it is integrity if you think from a services perspective. | 22:20 |
| wgrant | It's not. | 22:20 |
| wgrant | Implicit subscriptions mean we pretty much have to do permission-based filtering of subscriptions anyway | 22:21 |
| wgrant | Probably at the service level | 22:21 |
| lifeless | nope | 22:23 |
| lifeless | I have a flat out day | 22:23 |
| lifeless | so I can't spend a lot of time digging into this, sorry. | 22:23 |
| lifeless | The notification service will do precisely *one* callback to LP to expand team subscriptions. The rest is assumed accurate | 22:24 |
| lifeless | it is up to LP to maintain its integrity. | 22:24 |
| wgrant | Then LP will filter the subscriptions based on privacy | 22:24 |
| wgrant | It already has to do that for implicit ones. | 22:24 |
| lifeless | I'd like you to operate on that basis. | 22:24 |
| lifeless | you've got the proposed language in mail and in my branch | 22:27 |
| lifeless | if you can't represent what you need, we'll need to iterate that. | 22:27 |
| lifeless | What we can't sensibly do is multitenant with multiple services determining visibility of notifications | 22:27 |
| lifeless | its a denorm, it needs to be treated as such | 22:27 |
| SpamapS | OOPS-936e37e9194377d4c49cfcf1314896b5 ... | 23:13 |
| SpamapS | this is trying to tell a recipe to build now... | 23:14 |
| wgrant | SpamapS: It's trying to build against maverick | 23:20 |
| wgrant | maverick is no longer supported | 23:20 |
| SpamapS | Shouldn't that just automatically fall out? | 23:20 |
| wgrant | You'd think. | 23:20 |
| SpamapS | Had to click the widget to select series and then save it unchanged. That worked. Thanks. | 23:21 |
| lifeless | SpamapS: please file a bug | 23:28 |
| lifeless | SpamapS: I suspect we're going to have hundreds of those soon | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!