[08:16] <jtv> wgrant: how does the self.home[1:] work?  Just strip off the leading slash to get a relative path?
[08:17] <wgrant> jtv: Right. There's probably a better way to do that, though.
[08:18] <jtv> wgrant: my first choice would probably have been re.sub, but I guess a key point is that there's nothing sensible to do in cases where it's a relative path.  So I'm thinking an assertion may be enough to turn weird "known path with missing letter" errors into clearer ones.
[08:19] <jtv> o-kayyyy... feature request for lucid: plug-n-play USB mouse support.
[08:19] <wgrant> jtv: It works. Restart X -- you probably had an incompatible evdev driver update.
[08:20] <wgrant> So it will have tried to dynamically load the driver, and failed.
[08:20] <jtv> I'll do without for now.  The macbook pro has a wonderful huge, buttonless touchpad.  Now if only the "disable touchpad while typing" worked a little more reliably.  :)
[08:23] <jtv> wgrant: there is a test for updateBuild_WAITING...  I'd guess that all it needs is a tarball to upload and you'll have an integration test that exercises the _uploadTarball fix.
[08:24] <wgrant> jtv: Oh, I forgot you actually had useful tests.
[08:24] <jtv> \o/
[08:24] <wgrant> Soyuz is rather deprived.
[08:24] <jtv> Rather.  :)
[08:25] <jtv> It's funny how that seems to be infectious.  Sometimes in Wellington I heard things like "we'll know when it breaks."  But me, I often find myself stumped by _how_ it breaks when it does.
[08:26] <jtv> Have a look at lib/lp/translations/tests/test_translationtemplatesbuildbehavior.py, test_updateBuild_WAITING
[08:27] <wgrant> jtv: That explicitly clobbers _uploadTarball.
[08:28] <wgrant> It sounds like I'm going to need to set up a real branch with translation-capable projects attached.
[08:29] <jtv> wgrant: hmm... yes, that sounds very true.
[08:30] <jtv> I don't know of any good way to inject "pretend this is the project we're looking for" into the utility.
[08:30]  * wgrant doesn't actually know how Rosetta works.
[08:30] <wgrant> It's the one part of LP that I remained completely ignorant of until Saturday.
[08:31] <jtv> wgrant: you could consider cross-breeding this test with an existing one for _uploadTarball.
[08:31] <jtv> wgrant: then welcome!
[08:31] <wgrant> jtv: Is there an existing one for _uploadTarball?
[08:31] <jtv> Has to be...
[08:32] <jtv> test_uploadTarball may be our baby; same file.
[08:32] <wgrant> Oh. That's conveniently short.
[08:32] <jtv> Most of the meat is in the setup.  :-)
[08:33] <wgrant> yeah.
[08:33] <wgrant> Any hints?
[08:33] <jtv> You need all of the setup.
[08:34] <jtv> Whereas the updateBuild_WAITING test does not rely on any implicit setup at all.
[08:35] <wgrant> Although it does need makeBehavior.
[08:35] <jtv> So I'd create the integration test by copying test_updateBuild_WAITING right behind the _uploadTarball test.
[08:35] <wgrant> Ah, but that's in the mixin.
[08:35] <wgrant> Didn't notice that.
[08:35] <wgrant> That's easy, then.
[08:35] <jtv> yay for mixins  :)
[08:36] <jtv> It's already in the ancestry of the test class we're looking to extend, I believe.
[08:36] <wgrant> Exactly.
[08:37] <jtv> So you can copy test_updateBuild_WAITING in there, remove all the assertions, and tack on the final paragraph from test_uploadTarball.
[08:38] <wgrant> Yep.
[09:09] <noodles775> stub: Do you know if there is any performance benefit to using CREATE TABLE AS SELECT... to create and populate a table from *lots* of existing data, as opposed to the normal method of create table, then a migration function to iterate and insert lots of data?
[09:09] <wgrant> Pfft, it's only 1.6 million rows.
[09:10] <noodles775> Just interested :)
[09:10] <stub> inserting rows one at a time is slower. Inserting them in bulk is faster. Building the indexes after populating the table with data is a win.
[09:10] <noodles775> Thanks.
[09:12] <stub> CREATE TABLE AS SELECT is the same as CREATE TABLE; INSERT INTO [...]
[09:13] <noodles775> stub: except that the indexes are added afterwards right? (and the INSERT INTO is * 1.6 million for the data migration).
[09:13] <noodles775> stub: here's a very early WIP that I was toying with: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-build-generalisation-db-changes/+merge/22527
[09:13] <stub> Indexes are created when you create them. You might create them as part of the CREATE TABLE statement, or you might create them after.
[09:13] <noodles775> Right.
[09:15] <noodles775> stub: OK, so there's no difference between the above create table as select... and the equiv. create table, followed by a function that does 1.6 million inserts into those tables, as long as the indexes are created afterwards in both cases?
[09:15] <noodles775> s/tables/table
[09:15] <stub> Yup. But 1.6 million doesn't take long anyway unless the rows are particularly wide.
[09:16] <noodles775> Yep. Thanks for the info!
[09:25] <noodles775> jtv: I know it should be the other way around, but do you mind r or rs'ing a trivial testfix for the db-devel failure: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-test-fix-timebomb/+merge/22595
[09:25] <jtv> noodles775: hadn't noticed the failure, but hang on, I'm looking
[09:26] <noodles775> Thanks. It's what's holding up devel being re-synced after the rollout.
[09:26] <jtv> noodles775: when you say it should be the other way around, do you mean I/we broke it?
[09:26] <noodles775> jtv: no, I should be reviewing right now :/
[09:26] <noodles775> But there's just been a whole bunch of un-expected things, so I haven't started yet.
[09:26] <jtv> noodles775: well you couldn't have reviewed your own, and I don't recommend sitting around waiting for someone else to fix it either.  :)
[09:26] <jtv> same here
[09:27] <jtv> noodles775: one question: doesn't this risk undermining the test?  A ... could be hiding an entire line of output.
[09:28] <noodles775> Yes, if an extra line suddenly appeared in the output, it would be swallowed.
[09:28] <noodles775> Any other easy fixes?
[09:31] <jtv> Either leaving the date out of the output altogether, I guess, or replacing it with a yes/no
[09:31] <noodles775> OK, doing so now.
[09:33] <jtv> thanks for bearing with me.
[09:42] <jtv> wgrant: any luck with that test?
[09:43] <wgrant> jtv: Sorry, got distracted.
[09:43] <wgrant> Yes, it works.
[09:43] <jtv> cool!
[09:44]  * jtv always feels a warm glow whenever integration-testing of the build farm in the test suite is extended
[09:44] <jtv> wgrant: not showing up in the diff yet though
[09:45] <wgrant> jtv: No, just pushed now.
[09:45] <wgrant> I wrote it, fired off the tests, and forgot.
[09:45] <jtv> wgrant: you're just not pushy enough :P
[09:46] <wgrant> Heh.
[09:46] <jtv> (I assume there's an implicit "committed" in that story)
[09:46] <wgrant> Yes.
[09:46] <jtv> Just being pedantic, never mind me anyway
[09:49] <wgrant> jtv: Can you think of a way to test the slave change?
[09:50] <wgrant> I'm not sure of what tests you have around there.
[09:50] <jtv> wgrant: maybe you could do a test where you fake addWaitingFile, and see that it gets a sensible path?
[09:51] <jtv> Feel free to extend FakeMethod to record its last args and kwargs.
[09:51] <wgrant> jtv: I was hoping there was existing infrastructure around there.
[09:52]  * jtv searches
[09:53] <jtv> Not really infrastructure, but if you extend FakeMethod in this way, then lib/canonical/buildd/tests/test_translationtemplatesbuildmanager.py already fakes gatherResults for testing—should provide a usable base.
[10:10] <noodles775> jtv: I'm push the changes, but the MP hasn't updated yet.
[10:10] <jtv> noodles775: thanks
[10:11] <noodles775> jtv: http://pastebin.ubuntu.com/407482/
[10:11] <noodles775> That's the incremental.
[10:13] <jtv> noodles775: approved.
[10:13] <noodles775> jtv: Thanks.
=== noodles775 changed the topic of #launchpad-reviews to: on call: noodles775 || reviewing: wgrant || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== noodles775 changed the topic of #launchpad-reviews to: on call: noodles775 || reviewing: wgrant || queue: [jtv] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== ctrlsoft changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: wgrant, jtv || queue: || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== noodles775 changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: mvo, jtv || queue: || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== wgrant changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: mvo, jtv || queue: [wgrant,wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
[11:46] <mrevell> Hello. I have a fairly simple text change branch, if anyone would like to review it! https://code.edge.launchpad.net/~matthew.revell/launchpad/maintenance-notice
[11:47] <noodles775> Sure! Just add it to the queue pls.
[11:56] <noodles775> wgrant: would you have time to go over a review I'm doing and adding any comments (I'll be finished in a minute, but I'd like a second opinion from someone more familiar with germination etc.)
[11:56] <noodles775> s/adding/add
[11:56] <noodles775> And it doesn't need to be today.
[11:57] <wgrant> noodles775: Sure. mvo's?
[11:57] <noodles775> wgrant: thanks, yep. I'll be finished soon and will add you as a reviewer.
=== ctrlsoft changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: mvo, wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
[12:03] <ctrlsoft> hmm, this is my third week of reviews and so far I've only done soyuz reviews for some reason :-)
[12:04] <noodles775> ctrlsoft: yeah, and active reviews is all soyuz stuff too!
[12:05] <ctrlsoft> wgrant: do you need me to land move-lots-of-buildd-master-to-queuebuilder ?
[12:05] <noodles775> wgrant: ok, I've posted my comments and requested a review from you.
[12:06] <wgrant> ctrlsoft: When PQM opens, that would be lovely.
[12:06] <wgrant> For now, maybe just mark it Approved so it drops off +activereviews.
[12:06] <wgrant> Thanks.
[12:06] <wgrant> Ah, you already have.
=== noodles775 changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: mrevell, wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== noodles775 changed the topic of #launchpad-reviews to: on call: noodles775,jelmer || reviewing: lunch, wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== mrevell is now known as mrevell-lunch
[12:39] <wgrant> noodles775: I don't like the way it uses python-apt when it could just use internal LP APIs, but I guess that's reasonable given that it's not really part of LP.
[12:39] <wgrant> Otherwise it's fine.
[12:56] <cjwatson> noodles775: I'd like to work on fixing bug 294846, since it's annoying me.  Do you have a moment for a pre-impl chat?
[12:56] <mup> Bug #294846: Setting to Won't Fix is ACLed but unsetting it isn't <ubuntu-qa> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/294846>
[12:57] <wgrant> Is it actually desirable? It's unprecedented.
[12:58] <cjwatson> How so?  We have existing ACLs
[12:58] <wgrant> Nothing that prevents users from rectifying triage mistakes and reopening bugs.
[12:58] <wgrant> (there's of course the obvious problem that that sometimes isn't wanted, but...)
[12:59] <cjwatson> The current pattern is: developer says they don't intend to fix a bug, and rather than trying to persuade them that they're wrong in comments, the user just slams it back to New
[12:59] <cjwatson> repeat until very bored
[12:59] <wgrant> Well, there's discussion about introducing a new status for that, which looks less obviously closed.
[12:59] <wgrant> So users will hopefully not try to reopen it.
[12:59] <cjwatson> That seems like a silly workaround to me
[12:59] <wgrant> Unless Mark starts Won't Fixing my bugs without comment again :P
[12:59] <cjwatson> users will sooner or later figure out that it means closed, and then we're back where we started
[13:00] <wgrant> Hmm.
[13:00] <cjwatson> reopening bugs rather than engaging in discussion with the developer is a community anti-pattern
[13:01] <wgrant> Indeed.
[13:01] <cjwatson> the Debian BTS even says in the mail you get when a bug is closed that if you think it's wrong you should discuss it with the developer, who'll reopen if needed
[13:02] <cjwatson> that said I don't think people should be prevented from reopening Fix Released - Won't Fix is different because it's generally the result of a genuine difference of opinion, in which case simply reopening it is unlikely to be useful
[13:04] <cjwatson> still, if it's controversial, then I suppose a pre-impl chat is premature
[13:04] <wgrant> https://dev.launchpad.net/LEP/CloseBugsLeaveDiscussionsOpen
[13:04] <cjwatson> aha
[13:04] <cjwatson> bizarre summary though.  Discussion remains open on Won't Fix bugs too.
[13:05] <cjwatson> I'll just link to that from the bug, then
[13:05] <wgrant> Yes, I thought that a little odd too.
[13:06] <cjwatson> distinction between socially open and technically open, I suppose
=== matsubara-afk is now known as matsubara
[13:07] <cjwatson> While I'm here, is it reasonable/acceptable/common to submit Launchpad patches having run *only* EC2 tests, not local tests?  I find that I don't have the resources at the moment to keep enough local infrastructure for running Launchpad tests, since I do it only occasionally
[13:09] <wgrant> Not common, but if it passes EC2 then it's fine... but that sounds like an inefficient way of running tests unless your change is tiny and you're really sure.
[13:12] <cjwatson> mm, it tends to take me at least an hour to clear enough space for Launchpad tests, update all the dependencies and such, and then I'm less efficient at whatever else I'm meant to be doing
[13:12] <cjwatson> if I were doing it all the time then that would be different
[13:13] <wgrant> Yeah.
=== daniloff is now known as danilos
[13:29] <noodles775> cjwatson: is it worth updating that LEP or chatting with jml regarding the bug? (at least so the LEP indicates why the decision has been made to allow unsetting from Wont Fix or similar)?
[13:29]  * noodles775 can't see a comment related to it there.
[13:34] <jml> we hadn't even thought of ACLs for the status change
[13:34]  * jml makes a note
=== mrevell-lunch is now known as mrevell
[13:49] <jml> wgrant, cjwatson, I've just commented on the bug. I think the ACL on wontfix is separate from the OPINION status discussion.
[13:51] <deryck> interesting discussion.
[13:51]  * deryck looks at bugs....
[13:51] <jml> deryck, oh yeah :) I was surprised to find a discussion like this on #launchpad-reviews
[13:51] <deryck> yeah, I don't watch this channel unless pinged ;)
[13:52] <jml> but I'm firmly stuck in my "fewer channels" heresy
[13:53] <jml> deryck, the keyword highlight on "bug" not working out for you so well? :P
[13:53] <deryck> So I fall in the camp of bdmurray and cjwatson on this.  The ACL is pointless when unset.  I didn't realize we had this bug even.  Sorry.
[13:53] <deryck> jml, I droped that after 4 hours ;)
[13:53] <jml> it's been pleasing to me watching my "package branch" keyword watch become increasingly useless as people use them more.
[13:54] <deryck> heh
[13:54] <deryck> jml, I take it you favor the ACL on unsetting WONTFIX as well?
[13:55] <jml> deryck, yep.
[13:55] <cjwatson> I was working on http://paste.ubuntu.com/407546/, but then it occurred to me that I probably ought to talk about it with somebody, and I hadn't got close to testing it yet
[13:55] <jml> deryck, wgrant has a good point that it makes it gardening mistakes harder
[13:56] <cjwatson> just means you have to find somebody minimally competent to fix it for you ...
[13:56] <jml> deryck, I can't think of how to resolve that tension though.
[13:56] <jml> cjwatson, for Ubuntu, sure.
[13:56] <cjwatson> mm, true
[13:56] <cjwatson> (I wouldn't have brought it up in this channel if I'd realised it was controversial, sorry)
[13:57] <cjwatson> do many other LP pillars have Ubuntu's problem of simply being unable to keep up with bug mail?
[13:57] <deryck> jml, yes, I definitely see wgrant's point.  but it's a "mistake" of semantics, though.  Do bug supervisors regularly accidentally set something to WONTFIX?
[13:58] <deryck> or is it a matter of "no, you're wrong, this should be fixed." :-)
[13:58] <jml> cjwatson, too much in LP is controversial. some strange alchemy makes them less controversial once they are done though.
[13:58] <deryck> cjwatson, I don't think anyone has the level of problem Ubuntu has.  Both others certainly complain about the mail.
[13:59] <jml> deryck, you mean "LP cannot be expected to tell the difference between an accidental status change and a genuine difference of opinion"?
[13:59] <deryck> jml, exactly.
[14:00] <jml> deryck, I'd agree. How do users discover who has bug-triaging powers for a given pillar?
[14:00] <cjwatson> if accidental setting to WONTFIX is a concern, then leave it out of the AJAX thing?
[14:00] <cjwatson> (not that that wouldn't be confusing in other ways ... but most of the accidental changes seem to be AJAX mis-clicking)
[14:00] <jml> cjwatson, tbh, I don't think it's a major concern.
[14:01] <deryck> cjwatson, I'm also suggesting that I don't think there is much if any accidental setting of WONTFIX.  bug supervisors aren't generally careless.
[14:01] <deryck> jml, ^^
[14:01] <jml> agreed.
[14:01] <jml> ok, I'll drop it.
[14:01] <deryck> I think if a user disagrees and we have this ACL preventing unsetting, then a user should add a comment:  "hey, you dofus this should be fixed." :-)
[14:01] <deryck> hyperbole, but you get the idea.
[14:02] <cjwatson> deryck: while I'm generally in your camp, there's quite a lot of bug triager carelessness in Ubuntu, unfortunately
[14:02] <cjwatson> (but this is a problem we should fix!)
[14:02] <deryck> cjwatson, ah, true.  You have a large group of people doing this.
[14:03] <cjwatson> and a social misdesign in which triage is marketed as something that's an easy way to start helping out Ubuntu
[14:03] <deryck> agreed!
[14:03] <cjwatson> but I could rant about this for hours
[14:03] <deryck> every project does that.  and it's sooooo bad.
[14:04] <deryck> I wonder, too, if it's not self correcting, i.e. once people realize they can't easily unset it if bug traigers become more careful.
=== noodles775 changed the topic of #launchpad-reviews to: on call: jelmer || reviewing: wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
[14:04] <jml> hmm
[14:04] <jml> that's given me a completely irrelevant idea
[14:07] <deryck> cjwatson, so I would welcome the branch here for this.  I don't think you need the BUG_SUPERVISOR_OLD_BUGTASK_STATUSES, though.
[14:07] <deryck> just self.status not in BUG_SUPERVISOR_BUGTASK_STATUSES and new_status not in BUG_SUPERVISOR_BUGTASK_STATUSES, right?
[14:07] <cjwatson> deryck: I felt that it should be OK to set status away from Triaged
[14:08] <deryck> ah, right
[14:08] <cjwatson> this is just a gut feel
[14:08] <cjwatson> if you disagree I don't feel strongly
[14:08] <deryck> cjwatson, what do people normally transition to from triaged?
[14:08] <cjwatson> but it seemed to me that we might want those to be independently controllable
[14:09] <cjwatson> either in-progress etc. (developer) or something like "oh, hang on, this isn't clear after all" incomplete (not sure)
[14:09] <deryck> right
[14:09] <cjwatson> it just didn't seem as obviously final as wontfix is meant to be
[14:09] <deryck> I agree with you on this.  it's just the CONSTANT for WONTFIX that I'm not crazy about.
[14:09] <cjwatson> CONSTANT?
[14:09] <deryck> maybe just `self.status is not BugTaskStatus.WONTFIX`
[14:10] <cjwatson> oh right
[14:10] <cjwatson> if you like, sure
[14:10] <deryck> instead of adding BUG_SUPERVISOR_OLD_BUGTASK_STATUSES
[14:10] <deryck> keep someone from chasing down what that is later :-)
[14:11] <deryck> cjwatson, now one issue that will complicate this...
[14:12] <deryck> cjwatson, if it's in WONTFIX, I think the AJAX widget should not allow selecting any other statuses.  and I'm not sure how the js code consults canTransitionToStatus
[14:12] <cjwatson> I think it excludes anything for which that returns False
[14:13] <cjwatson> browser/bugtask.py:status_widget_items
[14:15] <deryck> yes, good spot.
[14:15] <deryck> cjwatson, so when you're ready, I'll happily review this for you. :-)  many thanks for the fix!  jml -- are you ok with this?  Or further discussion is required?
[14:15] <jml> not from me.
[14:15] <deryck> excellent.
[14:17] <cjwatson> I'll need to set up ec2test, so ... see you in a bit ;-)
[14:22] <deryck> ok :-)
=== salgado changed the topic of #launchpad-reviews to: on call: jelmer || reviewing: wgrant || queue: [wgrant,salgado] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== matsubara is now known as matsubara-lunch
[15:51] <jml> salgado, why the 'tee' change?
[15:52] <salgado> jml, to use sudo, I guess
[15:52] <salgado> before that command was executed as root
[15:52] <jml> oh, duh. I should have seen that :)
[15:52] <salgado> not it's as ubuntu
[15:52] <jml> *nod*
[15:52] <jml> salgado, r=me
[15:53] <salgado> thanks jml!
=== salgado changed the topic of #launchpad-reviews to: on call: jelmer || reviewing: wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== matsubara-lunch is now known as matsubara
=== stub1 is now known as stub
=== henninge changed the topic of #launchpad-reviews to: on call: jelmer || reviewing: wgrant || queue: [wgrant, henninge] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== henninge changed the topic of #launchpad-reviews to: on call: jelmer || reviewing: wgrant || queue: [wgrant, henninge(oversized)] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== salgado is now known as salgado-lunch
=== deryck is now known as deryck[lunch]
=== salgado-lunch is now known as salgado
=== gary_poster is now known as gary-lunch
=== deryck[lunch] is now known as deryck
=== rockstar changed the topic of #launchpad-reviews to: on call: rockstar, jelmer || reviewing: henninge, wgrant || queue: [wgrant] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
=== gary-lunch is now known as gary_poster
=== mup_ is now known as mup
=== rockstar changed the topic of #launchpad-reviews to: on call: rockstar || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews
[21:14] <rockstar> bac, can I have you do a quick review for me?
[21:15] <bac> rockstar: for you?  sure!
[21:16] <rockstar> bac, https://code.edge.launchpad.net/~rockstar/launchpad/code-js-move/+merge/22656
[21:19] <bac> rockstar: :(
[21:19] <bac> your rename of the code js directory is going to break branches that sinzui and i have in progress
[21:20] <bac> rockstar:  so, lp-deps.py is meant to be general purpose, right?  each app will have to add themselves to JS_DIRSET?
[21:21] <rockstar> bac, yes.
[21:24] <bac> rockstar: can i get you to talk to sinzui tomorrow before landing this?  i want to ensure his changes to discover JS tests will still work.
[21:24] <rockstar> bac, well, we talked about it at the UI meeting, but yes.
[21:24] <bac> we may have to move our js too.
[21:24] <bac> thanks.
[21:24] <rockstar> In fact, I think I'm going to have to move everyone's javascript is moved soon.
[21:24] <rockstar> bac, does that me r=you then?  :)
[21:24] <bac> yeah, that makes sense
[21:25] <bac> rockstar: yeah, r=bac but chat with curtis
[21:25] <bac> he won't say not to land it but may need to coordinate some stuff
[21:25] <rockstar> Yeah, I suspected as much.
[21:26] <rockstar> bac, although I bet he's tired of that branch.  :)
[21:26] <bac> yes
[21:26] <bac> we all are
[22:08] <cjwatson> should I be expecting to get a mail from ec2-abuse@amazon.com about going over a limit on volume of sent e-mail after a full ec2test run?
[22:14] <salgado> I've never got one
[22:15] <cjwatson> seems odd for it to be sending any mail out of the instance
[22:16] <salgado> indeed; on test runs we use the stub mailer
[22:16] <ctrlsoft> I've never had one either; it shouldn't be sending email other than the success/failure email and email to PQM
[22:16] <mwhudson> it certainly shouldn't
=== matsubara is now known as matsubara-afk
=== salgado is now known as salgado-afk
[22:52] <wgrant> bac: Can you please re-approve https://code.edge.launchpad.net/~wgrant/launchpad/refactor-slavestatus/+merge/22285?
[22:53] <bac> wgrant: it looks fine
[22:54] <bac> wgrant: do you want me to send it off to ec2 and land now?
[22:55] <wgrant> bac: Ah, I didn't realise it had reopened. Yes please!
[22:55] <wgrant> Thanks.
[23:04] <wgrant> Can someone please also send https://code.edge.launchpad.net/~wgrant/launchpad/move-lots-of-builddmaster-to-queuebuilder/+merge/22009, https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288 and https://code.edge.launchpad.net/~wgrant/launchpad/filter-apt_pkg-deprecationwarnings/+merge/22317 off to EC2?
[23:05] <bac> wgrant: off she goes.  let me know if you don't get an email in 4-5 hours
[23:05] <wgrant> bac: Thansks.
[23:05] <bac> wgrant: ask rockstar about those others.  part of ocr, you know.
[23:05] <wgrant> bac: Hm, true. rockstar ^^
[23:21] <jpds> bac: Can you send: https://code.edge.launchpad.net/~jpds/launchpad/fix_361650_model_changes/+merge/20785 ?
[23:28] <jpds> bac: Actually, I should probably let sinzui re-review.