[11:07] morning [11:25] hi rick_h [11:25] i suspect it may be very quiet here today [11:30] bac: yea, probably. [11:30] it was pretty darn quiet friday [11:30] almost eerily so [11:43] bac: are you running on precise? I'm still trying to figure out the way around my rabbitmq setup issues I replied to the -dev list about on friday [11:51] Morning rick_h & bac :) [11:51] good evening nigelb [11:52] rick_h: i am. didn't see your email. but i haven't run the test suite locally in a while [11:52] bac: I'm working on getting rocketfuel setup past this point === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10^2 [12:31] bac: O hai. You can remove the EC2 image with id 521. [12:31] StevenK: okay, thanks [13:42] wgrant: any word on the rabbitmq dep stuff that breaks in precise? Stupid me did a fresh install and can't get rf-setup past that [13:43] rick_h: Ah, indeed, I should fix that. For now I'd just suggest manually installing the old rabbitmq-server and rabbitmq-erlang-client, which will let the other plugins install. [13:43] wgrant: ok, thanks === salgado is now known as salgado-afk === salgado-afk is now known as salgado === deryck is now known as deryck[lunch] === salgado is now known as salgado-lunch === deryck[lunch] is now known as deryck === salgado-lunch is now known as salgado [18:05] sinzui, you around? === salgado is now known as salgado-afk [19:24] sinzui: how does registry admins end up assigned? Is it person deletions ? [19:24] lifeless, yes [19:25] We I think some linaro teams got deleted [19:26] * sinzui needs to see if ~registry now owns linaro projects [19:28] sinzui: would it be reasonable for the delete code to unassign and unsubscribe? [19:28] yes. I already reported that bug suggesting that as the solution to the problem [19:29] bug #613603 [19:29] <_mup_> Bug #613603: team merge subscribes/assigns bugs to ~registry

< https://launchpad.net/bugs/613603 > [19:30] cool cool [19:31] btw those bug numbers are -old-, way before linaro [19:31] hwenablement or something [19:32] yes, but the bugs and branches I unsubscribed ~registry mentioned linaro from the maverick period [19:32] interesting [19:32] shrug, no matter; I'm glad you cleaned it up [19:32] thank you [19:33] I am always happy to stop email arriving to my inbox [19:33] particularly this week. I am using my backup computer and I think some mail and calendar settings are 6 months too old [19:36] Speaking of registry, I'm imbued with its magical powers, but have yet to receive my wizard's hat [19:39] timrc, I think ~registry conveys more responsibility than power. You have some extra moderation powers to work with projects and teams, but it means you are on call to fix data that stop other users from serving themselves === salgado-afk is now known as salgado [19:53] more responsibility than power sounds a lot like parenting... bummer :) [20:05] deryck: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-everywhere-2/+merge/101284 ? [20:05] abentley, sure [20:18] abentley: I have a new job in a local branch; do I need to change anything in it to work with celery ? [20:18] abentley: s/do I/is it likely that I/ [20:19] lifeless: Yes, you need to provide a "config" member that points to the config section for that job type, so that we can determine the dbuser. [20:19] lifeless: does the job access branches? [20:19] abentley: no [20:20] abentley: its a stub implementation of the notification API, I wanted a low-key way to check that the API is completish [20:22] lifeless: If it's not derived from BranchJobDerived, there's extra work needed so that LP can look its class up by Job.id [20:22] lifeless: I'm working on supporting BranchMergeProposalJobDerived right now, actually. [20:23] abentley: ok. the job I have is super simple; its just got a single job type in its table [20:24] abentley: I wouldn't care if it has to be run non-celery in fact, as it should only exist long enough to validate stuff and bring up the external service. [20:24] abentley: but OTOH I don't want to hold back the cleanup of dead code [20:26] lifeless: Okay, I wouldn't worry about it, then. [20:26] cool, thanhks. [20:30] is anyone around who can help me with a private/commercial launchpad project? [20:31] perhaps [20:31] !ask :P [20:33] abentley, r=me. nice work. [20:33] lifeless: I have registered a new private/commercial project last week and I'm trying to get the bit flipped to make the code hosting private [20:33] deryck: cool, thanks. [20:33] lifeless: normally, I ask flacoste to do that, but I think he must be away on holiday or something [20:34] did you do the entitlement registration thingy? [20:34] lifeless: yepper [20:35] lifeless: but my trunk is publicly visible [20:35] ok, let me hook you up with a -ops [20:35] lifeless: okey [20:36] kirkland: you should be pm'd in a sec by thedac [20:36] lifeless: kthx [20:41] deryck: I'd like to retrieve the BranchMergeProposalJob where BranchMergeProposalJob.job = x OR the BranchJob where BranchJob.job = x. Do you know how to do that with a single SQL statement? [20:42] abentley: they are different tables? [20:42] lifeless: Yes. [20:43] abentley: if so you need to find (BranchMergeProposalJob, BranchJob) where BranchMergeProposalJob.job = x and BranchJob.job is NULL or BranchJob.job = x and BranchMergeProposalJob.job is NULL [20:43] (because its a cross join by default) [20:43] abentley: and then in your code check for which object is NULL [20:44] abentley: (this won't scale all that gracefully to many job types) [20:44] lifeless: Cool, thanks. [20:45] hmm, you might be able to say BranchMergeProposalJob.job is not distinct from x OR BranchJob.job is not distinct from x [20:45] lifeless: but I guess I can generate it programmatically from a list of job types? [20:45] you'd want to test that [20:45] abentley: possibly; I'd worry a little that it will slow down as you start getting hundreds of columns returned [20:45] s/little/lot/ [20:46] Why hundreds? [20:46] most sql queries bring back a few dozen columns at most [20:47] but each type in the storm query will be at least 2 columns (id, metadata), and more depending on the job's FK's. [20:48] things outside the common case are often slower, so I'd be worrying because we'd be doing something rather unusual. [20:48] lifeless: I doubt there are more than 10 job types. [20:49] lifeless: Most of our "types" are actually BranchJob + a distinguishing job_type attribute, rather than distinct tables. [20:49] lifeless: Or similar for merge proposal jobs, etc. [20:49] yah [20:49] well, its something to note I think [20:50] we're reconstructing data other parts of the system had, with a lookup pattern its not tuned for; thats something to at minimum put on the known defects pile [20:51] address it is obviously not urgent, nor even necessary at this stage [20:52] lifeless: Fair enough. I had assumed that such a lookup pattern would not be a problem. [20:55] lifeless: ISTM that since Job.id is a common field in all our job types, it would be elegant to be able to look things up by Job.id. [20:56] lifeless: if that actually is a problem, we could use a tuple of table and id to look up Jobs. [20:56] the problem is the schema; consider bugtask, which acts as an intermediary between bug and product/productseries/distro/distroseries [20:56] we have the FK of the related object in bugtask [20:57] so only ever have to do one index walk to find the other object for a given bugtask [20:57] abentley: if you could do that, it would be better I think [20:57] (that == tuple of table+id) [21:02] lifeless: We were going to go with a design inspired by your earlier suggestions, in that the job-running code was not even aware that the jobs were coming from a database. [21:03] lifeless: Including the table name as a parameter is going to mar that a bit, but maybe not too much. [21:04] lifeless: I'll chat with adeuring about how to adjust our approach. [21:04] ah, I see [21:05] I think if the job running code gets something opaque and hands it to a factory, and gets back a job, it shouldn't expose the db'ness of of it all [21:06] lifeless: We've been printing the ID, and assuming it is short and integery. === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 === salgado is now known as salgado-afk [22:43] pop quiz, does simple sendmail handle unicode values in headers (E.g. from, subject) appropriately ? [22:53] I'd be surprised if it did, it seems like it ought to be the submitting program's job to produce a valid MIME message [22:54] maxb: simple_sendmail is an internal API in the lp source tree [22:54] ah. The _ clarifies much