[00:58] <jml> lifeless, have you seen the recent T-I-P post?
[00:59] <jml> lifeless, there's a python-ideas thread on introducing setUpClass to the stdlib
[01:01] <mwhudson> jml: noooooooooooooooooooooooooooooooooooooooooooooooooooooo
[01:02] <jml> yeah, I know.
[01:02] <jml> I have to follow python-ideas now :(
[01:02] <mwhudson> well
[01:02] <mwhudson> isn't it basically a write-only mailing list?
[01:03] <jml> yeah, but Michael Foord kind of likes the idea, from scanning.
[01:04] <jml> http://article.gmane.org/gmane.comp.python.ideas/6715
[01:04] <jml> I'm not sure how to actually reply.
[01:05] <jml> since I'm not subscribed
[01:05] <mwhudson> oh dear
[01:15] <mwhudson> jml: maybe a small tactical nuclear weapon
[01:16]  * mwhudson stabs the interwub
[01:25] <lifeless> jml: I've seen it, no time to fire appropriate responses.
[01:25] <lifeless> jml: the argument I'd present is that class is the wrong scope.
[02:04] <jml> ok. replied.
[02:05] <mwhudson> to python-ideas?
[02:06] <wgrant> jml: Um, I'm getting that LocationProxy thing now.
[02:07] <jml> mwhudson, yes
[02:07] <jml> wgrant, change launchpad.Admin to zope.Public in the zcml (or merge my branch again)
[02:07] <jml> wgrant, this is for adapters specifically
[02:07] <wgrant> jml: Ew. OK.
[02:09] <wgrant> jml: I suspect that this is symptomatic of a deeper issue, though...
[02:09] <jml> wgrant, yes.
[02:09] <jml> wgrant, BjornT understands
[02:10] <wgrant> Ah, good.
[02:10] <wgrant> So I'll fix that in my earlier branch, then.
[02:12] <wgrant> Actually, I might as well just drop the permission entirely if it's in yours.
[02:38] <jml> wgrant, yeah. it's probably worth merging mine in again.
[02:41] <jml> does anyone know how I can use buildout to manage a library that includes Python stuff but is built with autotools?
[02:54] <BjornT> jml: this might help: http://pypi.python.org/pypi/zc.recipe.cmmi
[02:57] <jml> BjornT, thanks! there's also a bug filed on subunit https://bugs.edge.launchpad.net/subunit/+bug/499775
[02:57] <mup> Bug #499775: build easy_install/pip installable packages at release time <subunit:Triaged> <https://launchpad.net/bugs/499775>
[03:18]  * mwhudson has an impossible failure in his bzr-2.1c1 integration branch
[03:19] <jml> :(
[03:22] <wgrant> Do people get spammed if I create an in-progress MP?
[03:23] <mwhudson> i think currently yes
[03:23] <mwhudson> wgrant: why don't you ask halfway through thumper's talk, coming up next?
[03:23] <mwhudson> :)
[03:38] <wgrant> jml: Lots of conflicts merging from you :(
[03:39] <jml> :(
[03:52] <wgrant> jml: Want to review my hopefully final non-slave branch?
[03:52] <jml> wgrant, sure.
[04:12] <jml> wgrant, I've done the review (although not changed the status)
[04:13] <wgrant> jml: OK, thanks. I don't have an email yet, oddly.
[04:14] <jml> wgrant, let's see if we can get it approved before thumper's talk ends
[04:14] <wgrant> ... where did you ask the questions?
[04:14] <wgrant> I see no questions.
[04:14] <jml> (I honestly can't believe that he chastised people for not having good cover letters!)
[04:14] <jml> wgrant, via email
[04:15] <wgrant> Ah, it's there now.
[04:16] <lifeless> argh
[04:23] <jml> lifeless, ?
[04:25] <lifeless> p-i
[04:54] <jml> BjornT, that recipe thing hurts my brain.
[08:57] <rockstar> stub, hi, you around?
[08:57] <stub> like a donut
[08:57] <rockstar> stub, :)
[08:58] <rockstar> stub, I accidentally landed a branch on devel that I wanted to land on db-devel instead (don't want it rolling to edge).  Can I have you rs to revert it on devel and re-land on db-devel?
[08:58] <stub> Sure
[08:58] <rockstar> stub, cheers.
[09:08] <mrevell> Morning
[09:22] <henninge> Hi all!
[09:23] <henninge> I have updated the  launchpad-dependencies package in the launchpad ppa for karmic.
[09:23] <henninge> https://dev.launchpad.net/LaunchpadPpa tells me that I should now copy it to the other series on +copy-packages.
[09:24] <wgrant> Why is intltool a dependency now?
[09:25] <henninge> never mind
[09:25] <henninge> wgrant: for the automatic template generation code.
[09:25] <wgrant> I suspected that.
[09:25] <wgrant> But that's wrong, then.
[09:26] <wgrant> intltool is run inside the chroot, on the slave.
[09:26] <henninge> wgrant: oh
[09:26] <wgrant> Not outside the chroot, on the master.
[09:26] <henninge> wgrant: ah yes, but  the code has tests in the test suite.
[09:26] <henninge> wgrant: I could not land my code so far because the test won't pass on ec2
[09:27] <henninge> wgrant: what other option could I have?
[09:27] <wgrant> Hmmm, I see.
[09:28] <wgrant> I guess that's not too unreasonable, then.
[09:28] <henninge> wgrant: maybe we need to add "lp-slave-dependencies" and "lp-test-dependencies" ?
[09:29] <henninge> to get this more fine-grained
[09:29] <henninge> btw, I managed to copy the ppa to all series now
[09:30] <wgrant> It's not a slave dependency; the script needs to install it itself.
[09:30] <wgrant> I think lp-test-dependencies' purpose is fulfilled by lp-dev-dependencies, but I'm not quite sure of that.
[09:31] <henninge> wgrant: you mean that the ec2 test code pulls in lp-dev-dependencies?
[09:31] <henninge> then I guess that would suffice
[09:32] <wgrant> I believe so.
[09:32]  * henninge wonders where to find that out.
[09:32] <wgrant> ec2test images do, but I'm not sure about buildbot.
[10:31] <stub> BjornT: So I'm creating a stub in scripts/page-performance-report.py which bootstraps code in pageperformancereport.py. Where should pageperformancereport.py live.
[10:32] <wgrant> jml: That ec2 test seems to have fallen into an abyss. This time it hasn't landed or emailed.
[10:36] <bigjools> wgrant: hey
[10:38] <wgrant> bigjools: Hi.
[10:38] <bigjools> what's up with not landing aaron's branch?
[10:38] <wgrant> bigjools: You suggested that it shouldn't land until it's all been well tested on dogfood.
[10:38] <wgrant> Which, AFAICT, it has not.
[10:39] <wgrant> And it doesn't actually matter much whether the slave is merged...
[10:39] <bigjools> ok
[10:39] <bigjools> well it doesn't matter if it is, either, because it's rolled out separately
[10:40] <wgrant> Right.
[10:40] <bigjools> actually do you know if the 58~1 image had these changes in?
[10:41] <bigjools> because these are 58~0
[10:41] <bigjools> and I tested 58~1 on DF
[10:41] <wgrant> 'these are'?
[10:41] <wgrant> I think 58~1 contains the latest recipe changes.
[10:41] <bigjools> these changes
[10:42] <bigjools> so the MP has the changelog bumped to 58~0, so I am guessing I have tested that branch
[10:42] <wgrant> So they are. I wonder if that last increment just didn't get committed.
[10:43] <wgrant> Anyway, I need to sleep.
[10:43] <bigjools> I don't see 58 in the committed code
[10:43] <bigjools> it's up to 54
[10:43] <bigjools> so who has ~1
[10:47] <wgrant> https://code.edge.launchpad.net/~abentley/launchpad/build-recipe
[10:48]  * wgrant 's internet connection is about to die.
[10:48] <wgrant> That doens't have the ~1 changelog entry, but it is the latest code.
[10:48] <bigjools> hmm ok
[10:48] <bigjools> so wtf did the ~1 come from!
[12:58] <beuno> good morning
[13:22] <mars> morning beuno
[13:31] <mars> BjornT, around?  Trying to investigate the windmill speed issue as well
[14:16] <mars> BjornT, around yet?
[14:16] <mars> or salgado?
[14:16] <salgado> mars, ?
[14:17] <mars> hi salgado.  Just looking through the css_combine makefile target, to look at removing Mochikit from the JS rollup
[14:18] <mars> salgado, for excluding an individual file, I'm guessing an exception in buildout-templates/bin/combine-css.in, correct?
[14:19] <salgado> mars, erm, you talking about css roll up or JS roll up?
[14:19] <mars> salgado, nm, looking at the JS combination would help :)
[14:20] <salgado> mars, just remove Mochikit.js from the jsbuild target in the Makefile
[14:21] <mars> salgado, ah, I see, Mochikit.js is explicitly included in the Makefile, in the jsbuild step.  So excluding it there should kill it
[14:21] <mars> ?
[14:21] <mars> salgado, so I'll assume you agree :)
[14:21] <salgado> heh
[15:36] <Ursinha> Chex, gary_poster, rockstar, bigjools, sinzui, allenap: hi, are you able to join the prod. meeting that should happen in 30 minutes?
[15:36] <sinzui> I am
[15:37] <gary_poster> Ursinha: I am not
[15:37] <Ursinha> gary_poster: do you have a replacement? :)
[15:38] <gary_poster> Ursinha: not yet :-) I'll try to arrange one
[15:38] <Ursinha> thanks gary_poster :)
[15:40] <bigjools-afk> Ursinha: yep
[15:41] <allenap> Ursinha: I'm sprinting, but I'll watch for pings, if that's okay?
[15:45] <Ursinha> allenap: sure, thanks :)
[15:54] <Ursinha> Chex, someone from foundations, jtv, rockstar, bigjools, sinzui, allenap: prod. meeting in 8 min. @ #launchpad-meeting
[15:56] <rockstar> Has anyone done anything about the failed build on devel buildbot?
[16:01] <Ursinha> Chex, someone from foundations, jtv, rockstar, bigjools, sinzui, allenap: prod. meeting now @ #launchpad-meeting
[16:02] <Ursinha> s/jtv/henninge/ :)
[16:02] <jtv> Ursinha: s/ indeed
[16:02] <salgado> matsubara-afk, come back, dude, you've got a meeting to run. ;)
[16:29] <salgado> Ursinha, is there a bug for https://lp-oops.canonical.com/oops.py/?oopsid=1479S1000 ?
[16:36] <leonardr> gary: i just discovered something odd
[16:37] <leonardr> i can use type() to define a class whose name contains invalid characters like periods
[16:38] <gary_poster> not surprised :-) leonardr.  on call, though
[16:38] <leonardr> gary: np, just thought i'd mention it
[16:40] <allenap> Ursinha: gmb and I are creating a new job-based cronscript to calculate bug heat, and we wondered if we needed to give it a specific oops_prefix? It's set to none in schema-lazr.conf for now.
[16:42] <Ursinha> salgado: I don't think so
[16:44] <Ursinha> allenap: matsubara would be the best person to ask
[16:44] <Ursinha> allenap: he's out today but might return later, I can ask him
[16:45] <allenap> Ursinha: Thanks.
[16:46] <Ursinha> allenap: no problem, sorry not being more helpful
[16:46] <allenap> Ursinha: As far as I'm concerned, that's very helpful :)
[16:46] <Ursinha> allenap: :) I meant now :)
[16:52] <salgado> Ursinha, the typeerror OOPS is bug 403281
[16:52] <mup> Bug #403281: public xmlrpc requests broken during read only period <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/403281>
[16:53] <salgado> it happened because mthaddon was testing the new read-only switch on staging
[16:54] <Ursinha> salgado: oh, I see
[16:55] <Ursinha> thanks for investigating
[16:55] <salgado> np
[17:09] <beuno-lunch> rockstar, ping
[17:09] <beuno-lunch> re: upgrade icon
[17:09] <rockstar> beuno-lunch, pong
[17:09] <rockstar> beuno-lunch, I was gonna ping you about that, I swear.
[17:10] <beuno-lunch> rockstar, the icon I had made before, wasn't *that* for upgrading a branch?
[17:11] <beuno-lunch> or do I need to find better quality crack?
[17:11] <rockstar> beuno-lunch, you told me it was for when a branch already had an upgrade in process.
[17:11]  * beuno-lunch looks
[17:11] <rockstar> beuno-lunch, I thought one with a red exclamation point where the green animated arrow is would be good.
[17:12] <beuno-lunch> rockstar, I'm worried that something like that conveys that something is wrong
[17:12] <beuno-lunch> like a warning
[17:12] <rockstar> beuno-lunch, on another note, do you have balsamiq mockups for current pages?  Something I can build off of?
[17:12] <beuno-lunch> and not hthe positive action of "Upgrade it!"
[17:13] <rockstar> beuno-lunch, well, according to kiko, something is wrong.  The branch needs upgrading.
[17:13] <rockstar> beuno-lunch, personally, I think a big red button would be the best.  "This branch is out of date and should be upgraded!"
[17:13] <beuno-lunch> right
[17:13] <beuno-lunch> so we can use the standard warning icon
[17:13] <rockstar> "If you don't upgrade, we're going to come to your house and give you two slap."
[17:14] <beuno-lunch> "This branch is using an old format. _Upgrade now_"
[17:14] <rockstar> beuno-lunch, essactly.
[17:15] <beuno-lunch> so no special icon for that, and use the current icon for "This branch is currently upgrading"
[17:15] <beuno-lunch> rockstar, will branches be read-only while upgrading?
[17:15] <rockstar> beuno-lunch, nope.
[17:15] <beuno-lunch> rockstar, shouldn't they be?
[17:15] <rockstar> beuno-lunch, nope, not according the mark.
[17:15] <rockstar> beuno-lunch, this is the reason it's taken so long.
[17:16] <beuno-lunch> ok, as long as people don't get into trouble for using it the the meantime
[17:17] <beuno-lunch> so, we can decide wether to use the icon for "Upgrade now" or "Upgrading"
[17:17] <rockstar> beuno-lunch, basically, it upgrades on the side, pulls in all the revisions that have been committed, and then replaces the branch.
[17:17] <beuno-lunch> maybe upgrading is better, although it will be rarely seen
[17:17] <rockstar> beuno-lunch, yes, and then, wherever we use the icon, we need another icon for the other.
[17:17] <beuno-lunch> rockstar, I think we don't
[17:17] <kfogel> beuno-lunch: see new screenshot at end of https://bugs.edge.launchpad.net/malone/+bug/506018 when you get a chance
[17:17] <mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/506018>
[17:17] <beuno-lunch> rockstar, in fact, we may not need any icon at all. We could use the standard warning and info icon
[17:18] <rockstar> beuno-lunch, okay.  If we don't do you have a proposal?  I'm installing balsamiq right now to make a mockup.
[17:18] <beuno-lunch> rockstar, as for balsamiq, in the balsamiq branch, I committed all the mockups I have
[17:18] <rockstar> Where's the balsamiq branch?
[17:18] <beuno-lunch> rockstar, I don't think I have mocked anything up
[17:18]  * beuno-lunch looks for the branch and looks at kfogel's screenshot
[17:19] <beuno-lunch> kfogel, I worry that it may be hard to click on the overlay
[17:19] <beuno-lunch> is that actual code?
[17:19] <kfogel> beuno-lunch: yeah, that's in our branch right now
[17:20] <kfogel> beuno-lunch: may be hard to click on the link in the box?
[17:20] <beuno-lunch> kfogel, it's an overlay, right?
[17:20] <beuno-lunch> rockstar, https://code.edge.launchpad.net/~launchpad/launchpad/ui-wireframes
[17:20] <kfogel> beuno-lunch: hey, one sec, we'll give you a live page you can play with, would that help?
[17:20] <rockstar> beuno-lunch, great, thanks.
[17:20] <beuno-lunch> kfogel, that would be awesome
[17:21] <beuno-lunch> rockstar, feel free to commit to it
[17:21] <rockstar> beuno-lunch, okay, will do.
[17:21] <beuno-lunch> so we can all share  :)
[17:25] <kfogel> beuno-lunch: does this load for you? http://www.red-bean.com/kfogel/canonical/patches-view-popup.html
[17:25] <beuno-lunch> I'll check
[17:25] <beuno-lunch> yes
[17:25] <beuno-lunch> no CSS though
[17:25] <beuno-lunch> so it breaks a lot  :)
[17:26] <beuno-lunch> the CSS links to launchpad.dev
[17:26] <kfogel> beuno-lunch: oh, heh, yeah.  is it useable?
[17:26] <beuno-lunch> well, it is, but I can't tell if the overlay will work or not  :)
[17:27] <kfogel> beuno-lunch: (start up a launchpad.dev instance?  you don't need it to be our branch, just to get the CSS loading)
[17:29] <rockstar> beuno-lunch, in branch listings, should we also show a warning icon for out of date branches?
[17:29] <beuno-lunch> kfogel, I'll try that. Did you add any CSS?
[17:29] <beuno-lunch> rockstar, yes, but only for people who have permissions to upgrade it  :)
[17:30] <kfogel> beuno-lunch: no, just some javascript in the page itself (which you should get via the page, of course)
[17:30] <beuno-lunch> starting up an instance...
[17:31] <kfogel> beuno-lunch: so, enjoying that lunch? :-)
[17:31] <rockstar> beuno-lunch, okay.
[17:32] <beuno-lunch> kfogel, it's looking good on the table
[17:33] <beuno-lunch> tasty, but I can't say that for certain yet  :)
[17:33] <beuno-lunch> making schema is slow
[17:33] <kfogel> beuno-lunch: (there's a throughout-Launchpad problem whereby in a vertical list, a popup on one item blocks you from mousing down to the next row's item.  It happens on ~person/branches page too, for example.  It would be nice if the popup could pop up somewhere else other than the mouse pointer -- that's exactly the place where the popup is most likely to get in the way :-) ).
[17:34] <beuno-lunch> kfogel, yeah, that's why I asked  :)
[17:35] <beuno> I'll stop pretending I'm going to eat lunch
[17:35]  * kfogel hopes we get to fix that bug in the default popup behavior
[17:35] <kfogel> beuno: we can wait, go eat
[17:35] <kfogel> beuno: it's not like we don't have other stuff to do.
[17:37] <beuno> kfogel, I'd rather unblock you
[17:37] <beuno> kfogel, it feels ok
[17:37] <beuno> just add some padding between the borders of the bos and the content
[17:38] <beuno> and, it comes up when hovering the row, not the link
[17:38] <beuno> making it a bit suprising
[17:38] <beuno> and it's not intuitive, so if we can think of something that points to there being information, cool. Otherwise, file a bug for the future  ;)
[17:50] <kfogel> beuno: thanks.  what's a "bos", btw?
[17:51] <kfogel> beuno: for pointing to there being information, I was thinking: let's put that patch band-aid icon to the right or left of the patch age, and do the popup only on the icon?
[17:51] <beuno> s/bos/box
[17:52] <kfogel> beuno: got it.  we've fixed that already by using class="listing"
[17:52] <beuno> kfogel, I think that's a good idea. You can see that information on the page you click on anyway, so it's just a convinience thing to have the popup
[17:52] <kfogel> beuno: based on Bryce's reactions, I think the popup may be a bit more than a convenience optimization.  The users are expected to have a very much scan-and-only-tentatively-dive-in kind of workflow.
[17:53] <beuno> super
[17:53] <beuno> this is great work kfogel
[17:53] <kfogel> beuno: thank abel, sitting next to me :-)
[17:53]  * beuno waves at abel
[18:02] <leonardr> gary: the goal is in sight, i have one more zope problem i'd like to sort out with you when you have time
[18:02] <gary_poster> leonardr: cool.  maybe on call soon?
[18:02] <leonardr> whenever you're ready
[18:03] <leonardr> it's code-intensive so i think starting out in irc would be better
[18:03] <gary_poster> ok
[18:03] <mrevell> night!
[18:08] <leonardr> it's code-intensive so i think starting out in irc would be better
[18:09] <dobey> is it me, or is launchpad having some issues right now?
[18:28] <rockstar> mars, ping
[18:28] <mars> hi rockstar
[18:29] <rockstar> mars, where are we with the js issue?
[18:29] <mars> rockstar, I am slicing the Mochikit code out of launchpad.js, with the intent on pulling the code in only on pages that need it
[18:30] <rockstar> mars, is that going to land today?  I have a rather urgent branch that is being held up by this issue.
[18:32] <mars> rockstar, need to figure out context, but I can work with you to figure this out
[18:32] <mars> rockstar, so you can't land your branch because windmill will go nuts and block everything if you do?
[18:32] <rockstar> mars, apparently, yes.
[18:32] <mars> ok
[18:33] <rockstar> mars, if I run the tests that fail on ec2, they fail locally.  However, if I run with -D, they all pass.
[18:33] <mars> rockstar, two options: wait for me to finish excising Mochikit, or put your JS in a separate file that is not part of the rollup.  I  assume you are landing JS, correct?
[18:33] <mars> eh?
[18:33] <mars> rockstar, oh, a different issue from Bjorns then
[18:34] <mars> rockstar, then lets work on your problem
[18:34] <rockstar> mars, no, I think it's the exact same issue.
[18:34] <rockstar> thumper and I were working on parallel branches, and we both saw the problem at the same time.
[18:34] <mars> rockstar, can you successfully run the windmill tests in trunk?  or a subset of them?
[18:34] <rockstar> mars, yes.
[18:34] <mars> interesting
[18:35] <mars> rockstar, do a subset of the tests, such as a single test, fail?
[18:35] <rockstar> mars, in my branch?  Yes.
[18:35] <rockstar> Unless I run with -D, in which case it passes swimmingly.
[18:35] <mars> rockstar, and they fail locally?  Tim and Bjorn can both run them fine locally.
[18:35] <mars> afaik
[18:35] <rockstar> I think it's all fishy.
[18:35] <mars> lol
[18:36] <mars> ok
[18:37] <rockstar> mars, technically, the tests SHOULD pass, as they pass if I work through them interactively.  The functionality is fine, windmill just pukes.
[18:37] <rockstar> Nothing's technically broken.
[18:37] <rockstar> ...'cept Windmill's ability to find out if it's broken.
[18:39] <mars> why would *any* test you run on your system fail?
[18:39] <mars> rockstar, do they fail because of... what?
[18:39] <mars> please elaborate
[18:40] <rockstar> mars, I can't.  Windmill is just weird.
[18:40] <rockstar> I don't know why Windmill thinks they fail.  I am 99% sure this is the same issue that Bjorn and thumper are seeing.
[18:40] <mars> rockstar, do the individual test assertions time out?
[18:41] <rockstar> mars, I guess.  It waits for elements that I can see show up, but it just decides they aren't there.
[18:41] <rockstar> And it spikes my CPU.
[18:41] <mars> ok
[18:42] <mars> rockstar, if it is the same issue as Bjorn and Tim, then the workarounds I proposed still stand
[18:42] <rockstar> mars, yes, but the workarounds aren't too much of an option, since I'm editing a file already in the rollup.
[18:43] <mars> rockstar, what is the scope of the code? Page, App, or Core?
[18:43] <mars> the scope of the code you added
[18:43] <rockstar> Page.  Branch merge proposal page specifically.
[18:43] <beuno> intellectronica, by any chance, is there any log of the people who say me too?  dates they clicked?
[18:44] <wgrant> bigjools: I presume that the ~1 changelog entry is an uncommitted change on abentley's laptop.
[18:44] <mars> rockstar, then if you have to land it ASAP, you can probably split out the code you added into a new, non-rollup module.  Or, you could include it inline on the page itself.
[18:44] <mars> rockstar, the latter option works very well in a pinch
[18:44] <rockstar> mars, so can I pull it out of the existing rollup, and how do I go about that?
[18:45] <mars> rockstar, I assume you have a diff
[18:45] <mars> since you changed something to trigger this bug :)
[18:45] <rockstar> mars, yes, lemme find it.
[18:45] <bigjools> wgrant: it could also be a version bump after we'd already installled ~0 as I remember them wanting to poke a tweak in
[18:46] <wgrant> bigjools: Possibly.
[18:46] <wgrant> Hmm, I think all the necessary master code is now in db-devel.
[18:46]  * wgrant tries a recipe build on that.
[18:47] <bigjools> dogfood is pretty much up to date as well
[18:47] <bigjools> I can try and poke something in there
[18:47] <rockstar> mars, https://code.edge.launchpad.net/~rockstar/launchpad/update-review-table-on-comment/+merge/17439
[18:48] <wgrant> bigjools: Does it have a local codehosting setup?
[18:48] <wgrant> I don't think it does.
[18:48] <bigjools> anyone here use a Logitech Harmony remote and got the software running in wine?
[18:48] <mars> rockstar, so comment.js is core: but this functionality in particular is only used on the MP page?
[18:48] <bigjools> wgrant: why does it need that?
[18:48] <bigjools> it can pull from staging
[18:49] <wgrant> bigjools: Well, it references branches in the DB.
[18:49] <bigjools> oh.  cock.
[18:49] <rockstar> mars, well, the one line in comment.js needs to be there.  The other stuff should be moved to a lp-code javascript space.
[18:49] <bigjools> bb in 10m
[18:51] <mars> rockstar, is anything in comment.js used anywhere else?
[18:51] <mars> ah ha!  lp.CodeReviewComment!  So I assume "no"? :)
[18:52] <rockstar> mars, I think the bug comments use it as well.
[18:53] <mars> rockstar, ok
[18:53] <wgrant> Hm, what did I break in db_lp?
[18:53] <mars> rockstar, this is a simple refactoring then: extract lp.CodeReviewComment to a new module.
[18:54] <mars> rockstar, that new module should not be part of the rollup by default.
[18:54] <rockstar> mars, where's the rollup code?  This has all seemed like magic to me.
[18:54] <mars> rockstar, don't worry about minification or any of that junk if you want it to land.  Just refactor, test, and go.
[18:55] <rockstar> mars, so I create a js file and then include it in the bmp page itself, and not in the main template.  Is that correct?
[18:56] <EdwinGrubbs> sinzui: ping
[18:56] <mars> rockstar, ah, wait a minute, looking at the rollup code: Makefile:124
[18:56] <sinzui> Hi EdwinGrubbs
[18:56] <mars> rockstar, confused: why is there an '-s' argument, and then a bunch of positional args...
[18:57] <rockstar> mars, hellifiknow.  I don't know how this stuff works.
[18:57] <mars> rockstar,  maybe '-s' is "grab everything", and the positional args are cherry-picked files?
[18:57] <mars> rockstar, just thinking out loud.  mumbling doesn't work so well in text-based mediums...
[18:58] <rockstar> mars, no, I see what you're saying.
[18:58] <rockstar> mars, I always just thought that I put a js file in the folder, it gets rolled up.  Apparently, that was a correct assertion.
[18:59] <mars> ok
[18:59] <mars> so.. hm
[18:59] <mars> rockstar, jsbuild takes a '-x' option....
[19:00] <rockstar> mars, yeah, I saw that.  I should probably add an XXX comment.
[19:02] <mars> rockstar, so refactor to extract the module, then use the -x option on it.
[19:02] <mars> rockstar, first test the -x option with something benign, see if it does what you need
[19:05] <mars> rockstar, pick any JS file in the rollup that you don't need on your MP page, pass it through -x, see that it is excluded.  Then run windmill on one previously failing test: the new, smaller rollup should pass, right?
[19:08] <rockstar> mars, I'll go on an adventure.
[19:09] <mars> rockstar, if it isn't too much bother, could you please try the fix first?  :)
[19:09] <rockstar> mars, that's the adventure.
[19:10] <bigjools> wgrant: so since DF is a copy of production from just before Christmas, it will have branches in the DB
[19:21] <beuno> I love seeing the patch icon in bugs
[19:21] <beuno> it's so much clearer now
[19:28] <sinzui> damn. This stupid last bread crumb bug is killing my test
[19:28] <wgrant> bigjools: I wonder how the config is set up, though.
[19:28]  * wgrant checks.
[19:30] <wgrant> Hm, it might just work.
[19:30] <wgrant> It looks like it doesn't override the production codehosting URLs.
[19:31] <wgrant> So lp: URLs in recipes should Just Work.
[19:41] <intellectronica> beuno: i'm not sure i understand exactly what you're looking for. we don't save the dates in the db but i suppose we could mine it from the web logs if we really want
[19:43] <beuno> intellectronica, dates on the db
[19:43] <beuno> there's a bug someone filed and I commented on
[19:43] <beuno> sinzui triaged it
[19:44] <sinzui> I am sure it is on the first page of malone bugs
[19:47] <lifeless> jml: the setUpClass discussion is making me sad
[19:57] <bigjools> wgrant: when you tested copying private<->ppa copies did you select source only?
[20:01] <wgrant> bigjools: I tried both, I think.
[20:01]  * wgrant tries agao.
[20:01] <wgrant> s/o/in/
[20:01] <bigjools> wgrant: the original problem was when the guy selected rebuild
[20:01] <bigjools> dunno if that's a coincidence
[20:06] <wgrant> bigjools: The target was ~ubuntuone/ppa?
[20:06]  * bigjools plays hunt the oops
[20:06] <wgrant> ~ubuntuone/beta, sorry.
[20:08]  * bigjools fails
[20:08] <bigjools> I think it was from memory
[20:09] <jml> lifeless, :(
[20:10] <jml> wgrant, your revision looks like 8903
[20:10] <wgrant> Although I guess you probably had to destroy the history to fix the publisher.
[20:10] <jml> bigjools, hi
[20:11] <wgrant> jml: Yeah, it landed 20 minutes after I asked. Very, very late.
[20:11] <jml> wgrant, late how, I wonder.
[20:12] <wgrant> ~5.5 hours after you kicked it off.
[20:12] <wgrant> And it doesn't look like it was stuck in the queue, unless PQM was landing to something other than (db-)devel
[20:12] <mars> rockstar, let me know if you have any luck with the refactoring
[20:15] <jml> wgrant, that's about the same time as the other one.
[20:15] <intellectronica> beuno, sinzui: yeah, saw the bug. i have no opinion about this right now, and i'll defer to deryck to decide how to triage and schedule it, but no, we don't have that now
[20:16] <bigjools> jml: hi - I'm not really here
[20:16] <jml> maybe the test suite has become three hours longer :(
[20:16] <jml> bigjools, hi
[20:16] <jml> bigjools, I guess this means I'm not going to be able to land the branch before the week 4 freeze
[20:16] <bigjools> wassup?
[20:16] <bigjools> meh, it's friday
[20:17] <bigjools> there
[20:17]  * deryck looks at the bug intellectronica beuno and sinzui are discussing....
[20:18]  * wgrant looks at bug #507751 and wonders if we can slip that in.
[20:18] <mup> Bug #507751: New ISourcePackageRecipeBuild fields <wellington> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/507751>
[20:19] <sinzui> I marked it low because it is not essential to linking ubuntu to upstream. It is somewhat on topic though. The model change is a deterrent from classifying it as trivial and giving it a bump in priority
[20:19] <sinzui> ^ deryck, intellectronica, beuno
[20:19] <deryck> sinzui, right
[20:19] <deryck> sinzui, beuno -- I also wonder if we really want this, or if heat is an indication of last affected time?  Tangentially it is, I realize, but I wonder if that isn't good enough?
[20:20] <deryck> intellectronica, see my suggestion/question above, too. ^^
[20:20] <intellectronica> yes, i also can't see that it's very useful and would rather weigh age into heat instead
[20:22] <sinzui> beuno: I just fixed the last item in the breadcrumbs is linked bug. It would have been fixed 6 months ago if I understood that it was trivial.
[20:29] <beuno> deryck, I think heat may help, but it's hard to tell "since my last release"
[20:29] <beuno> sinzui, woooooo!
[20:29] <beuno> which one?
[20:30] <sinzui> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/83613 and https://bugs.edge.launchpad.net/launchpad-foundations/+bug/480473
[20:30] <mup> Bug #83613: last breadcrumb item shouldn't be a link if you're there already <locationbar> <ui> <Launchpad Foundations:In Progress by sinzui> <https://launchpad.net/bugs/83613>
[20:30] <mup> Bug #480473: Breadcrumb underlines include trailing whitespace <post-3-ui-cleanup> <Launchpad Foundations:In Progress by sinzui> <https://launchpad.net/bugs/480473>
[20:30] <jml> gror batteries :(
[20:30] <deryck> beuno, I don't disagree that it's nice to know.  Just wondering if the heat indication is enough.
[20:30] <deryck> beuno, do you have a UI idea for how to expose the info?
[20:31] <sinzui> beuno: My test was broken by presence of a pointless link. The bug had to be fixed to satisfy my test-sensibilities
[20:31]  * deryck has to go.... phone.... sorry
[20:31] <beuno> deryck, I think it's not enough, no.  I'd show it in the activity log.
[20:34] <lifeless> jml: what patch can't you land?
[20:34] <jml> lifeless, huh?
[20:37] <deryck> beuno, ok, can you update the bug with that recommendation, i.e. activity log?  And we'll schedule it during bug Q&A, where it kind of makes sense, I think.
[20:38] <lifeless> 07:16 < jml> bigjools, I guess this means I'm not going to be able to land the branch before the week 4 freeze
[20:38] <lifeless> jml: I'm just being curious
[20:38] <jml> lifeless, bigjools just reviewed a branch of mine that I submitted last week, and he needs an answer before it lands
[20:39] <jml> lifeless, I won't be able to reply for the next couple of hours
[20:39] <beuno> deryck, yes, thank you
[20:40] <bigjools> jml: can you reply today and I'll get to it in an hour or so
[20:40]  * bigjools brb
[20:40] <jml> lifeless, thanks. but my laptop is almost dead.
[20:57] <EdwinGrubbs2> sinzui: sorry I didn't see your reply earlier. It seems like I can make most of the tests for +addpackage work with +ubuntupkg except where packagings are created for non-ubuntu distributions. Is there any other reason to keep PackagingAddView around?
[20:58] <sinzui> I can think of one case...
[20:59] <sinzui> EdwinGrubbs That view is the only view that allows someone to specify the INCUDES type of packaging. Ubuntu does not care about it, so I am think we can really ignore it
[21:00] <sinzui> EdwinGrubbs2: If my assumption is wrong, we can resurrect the Packaging field as an advanced option on the ubuntu form.
[21:01] <EdwinGrubbs2> sinzui: I can probably get it into review in about an hour. Do you want to look at my current changes or review it later? I can always ask rockstar, who owes me.
[21:01] <sinzui> EdwinGrubbsI will be happy to review it
[21:01] <sinzui> maybe we can trade, I am putting the second branch of my +needs-packaging view into review
[21:08] <mars> wow. rockstar, you were right, it /does/ spike the CPU.  But on my dual-core system, the tests can still pass I guess.
[21:08] <mars> rockstar, tried unbundling MochiKit, and the CPU usage is much lower.
[21:08] <rockstar> mars, I'm an dual and quad core systems.  I suspect there's a timing issue.
[21:08] <rockstar> mars, why do we still need mochikit?
[21:09] <mars> when I pulled a test run into the debugger I found the majority of time was spent spinning on socket.read
[21:09] <mars> rockstar, a bit of code in Bugs mostly
[21:09] <mars> old code
[21:10] <mars> and some in Translations
[21:10] <rockstar> mars, yea, socket issues are hard to track down.
[21:10] <rockstar> mars, maybe we need to set a higher priority on getting rid of Mochikit entirely?
[21:10] <mars> at least, the JS was for Translations.  The original integration point could be dead now.
[21:10] <beuno> KILL MOCHIKIT
[21:11] <mars> rockstar, if you want to give it a shot, merge this branch: lp:~mars/launchpad/unroll-mochikit
[21:11] <rockstar> mars, okay, I'll see what happens.
[21:11] <mars> beuno, we're getting there, don't worry :)
[21:12] <mars> we just needed a gentle stab in the back to get moving
[21:15] <rockstar> mars, I think this is as good as any stab in the back.
[21:15] <rockstar> I bet all the MochiKit code is untested anyway.
[21:28] <jml> hi
[21:28] <mars> hi jml
[21:29] <mwhudson> jml: good morning
[21:30] <mwhudson> jml: apologies for the incoherent text messages last night
[21:30] <rockstar> mwhudson, are you working today?
[21:30] <jml> mwhudson, I didn't notice any incoherence :)
[21:31] <mwhudson> jml: there may be several non-mutually exclusive reasons for that :-)
[21:31] <jml> mwhudson, heh heh
[21:31] <mwhudson> jml: it would be hard for me to have given sensible directions in any case -- i'm not sure i could find my way back :-)
[21:31] <jml> :D
[21:31] <mwhudson> rockstar: well, it's the last day of LCA, so "sort of"
[21:32] <mwhudson> right, /me --> talk
[21:32] <rockstar> mwhudson, just wondering.  I didn't expect anyone to be around today.
[21:34] <lifeless> åaa
[21:35] <Ursinha> sinzui: I see that the updated file is in https://devpad.canonical.com/~lpqateam/burndown/test-plan-report-10.01.html
[21:35] <Ursinha> sinzui: the script that runs in cron generates them in there
[21:37] <mwhudson> bah, still at "14 failures, 72 errors" for the bzr upgrade :/
[21:37] <sinzui> Ursinha: I see that the numbers are correct now
[21:38] <Ursinha> sinzui: in devpad.canonical they are, but not in people.canonical
[21:38] <sinzui> Ursinha: I did not see my untested items for two days and assumed the script was broken by the move from rookery
[21:39] <Ursinha> sinzui: oh, I see
[21:39] <sinzui> Ursinha: I link to the people.canonical.com pages so that users can see the milestone QA progress from all the projects I am managing
[21:39] <Ursinha> sinzui: got it
[21:39] <sinzui> Oh, that is the reason, the server moved
[21:39] <Ursinha> :)
[21:42] <rockstar> Is anyone working on a fix for db-devel's buildbot failure?
[21:43] <wgrant> What is the failure?
[21:43] <wgrant> I seem to be the only one to blame.
[21:43] <rockstar> test_min_time_to_next_builder (lp.soyuz.tests.test_buildqueue.TestMinTimeToNextBuilderMulti)
[21:44] <wgrant> Full exception?
[21:44] <mwhudson> hmmm
[21:44]  * mwhudson thinks his emacs is failing to do the right thing with branches made with --hardlinks
[21:45] <rockstar> wgrant, http://pastebin.ubuntu.com/360283/
[21:46] <jml> mwhudson, yeah, mine was for a while -- stopped using hardlinks
[21:46] <mwhudson> hm
[21:46]  * mwhudson stops
[21:47] <wgrant> Hmmm.
[21:48] <rockstar> Ursinha, where are the test plans being held now?  I don't see them on the wiki.
[21:49] <Ursinha> rockstar: they're in the same place, I guess
[21:49] <rockstar> Ursinha, I looked.  They aren't there.
[21:50] <rockstar> Ursinha, oh, they're labled 10.01, which threw me off.
[21:50] <Ursinha> rockstar: https://dev.launchpad.net/CodeTeamTestPlans/
[21:51] <Ursinha> rockstar: yeah, according to the name of this cycle we're at the moment :)
[21:51] <rockstar> Ursinha, yeah, it didn't match my mental heuristics of what I would have thought this cycle was called.
[22:11] <wgrant> I cannot reproduce that db_lp failure.
[22:12] <mars> rockstar, any luck?
[22:13] <rockstar> mars, still running tests.
[22:13] <mars> ok
[22:13] <intellectronica> i can't seem to reproduce it either
[22:14] <wgrant> My branches didn't really touch that area, either.
[22:15] <mwhudson> timing dependent?
[22:15] <mars> rockstar, so you may be interested to know that LP has 380 lines of Mochikit-dependent JS.  But a fair bit of it is overlapping functionality: 3 ways to do it, instead of one :(
[22:16] <sinzui> I was thinking the problem was timing dependant
[22:16] <mars> rockstar, so there are two issues there: rewrite to YUI, and have 3 ways to do it in YUI
[22:16] <wgrant> mwhudson: Actually, it's possible.
[22:16] <wgrant> IIRC 2min is the time we use when a build has exceeded its estimated duration.
[22:17] <mars> rockstar, and then pull together the 3 ways to do it into one function in the LP JavaScript core.
[22:18] <mwhudson> biab
[22:19] <rockstar> mars, well, however it gets done, it just needs to get done.
[22:19] <mars> yep, that's why it should be in 2 steps - bite-sized chunks
[22:19] <rockstar> mwhudson ported all the Mochikit in loggerhead to yui-3 quite quickly.
[22:21] <jml> I'd like to change Launchpad to depend on subunit trunk
[22:21] <jml> but subunit trunk has an incompatible repository format to the subunit fork that we're using.
[22:23] <mars> jml, I thought you are subunit core contributor? can't you bend the project's CM system to something more compatible?
[22:23] <jml> mars, no.
[22:23] <jml> mars, we're doing it right. Launchpad's fork is doing it wrong.
[22:24] <mars> jml, so why can't we change Launchpad?
[22:24] <jml> mars, I don't know how.
[22:25] <mars> that is an excellent reason
[22:26] <jml> I think maybe I can get away wit hit by hacking the update-sourcecode script to detect incompatible repo errors and just blow the old branch away
[22:26] <jml> but I don't know if that will fly in production.
[22:30] <intellectronica> is it time to force the buildbot out of testfix mode? several devs can't reproduce the problem, and we've got heaps of branches to land
[22:32] <wgrant> +1. I don't see how my change could have broken anything, and it hasn't happened before.
[22:34] <intellectronica> oright, forced a build
[23:17] <jml> lunch plans?
[23:18] <mwhudson> well, i've just had breakfast :)
[23:19] <spm> mwhudson: sounds like you'd be ready for lunch then!
[23:20] <mwhudson> heh heh
[23:27] <rockstar> mars, I'm just going to merge your branch and submit through ec2 - The Windmill tests take for freaking ever.