[00:06] <wgrant> cody-somerville: Hi, can you QA your authorized_size thing?
[00:06] <StevenK> And jelmer's thing
[00:07] <wgrant> jelmer's QAed half of his, but bug #296153 is still pending
[00:07] <_mup_> Bug #296153: does not mirror bzr branches over ftp <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/296153 >
[00:08] <StevenK> wgrant: Your testfix switched to rSP() in the factory?
[00:08] <wgrant> No, rSP doesn't work there.
[00:09] <wgrant> I logged in as an admin instead.
=== matsubara is now known as matsubara-afk
[00:22] <wallyworld> abentley: hi, with the mustache/handlebars template in a file, i notice there's no reference to it in the buglisting yui tests
[00:24] <wallyworld> so it doesn't appear the rendering aspects are tested in that case, whereas in the pillar sharing stuff, i have yui tests for the rendering and therefore need the load the template in the tests
[00:25] <wallyworld> that was one of the reasons for having the template in the javascript
[00:25] <wallyworld> i guess i could pull in the template in the test html
[00:30] <jelmer> StevenK, wgrant: bug 296153 is qa-ok
[00:30] <_mup_> Bug #296153: does not mirror bzr branches over ftp <lp-code> <qa-ok> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/296153 >
[00:31] <rick_h_> wallyworld: yea, that's a big issue we've got to figure out for JS testing as we move more client side rendering
[00:33] <wallyworld> rick_h_: i'll seeing how it flies pulling it out in a file, as per the code review request. i was happy enough to leave it in the js for now but there's been a couple of objections
[00:33] <wallyworld> rick_h_: in this case, there's NO server side rendering, it's all client
[00:34] <rick_h_> wallyworld: right, but you want the tests and the live site using the same template if possible so that they match and test correctly
[00:34] <rick_h_> but it'sa bit tough/pia
[00:34] <rick_h_> pita that is
[00:35] <wallyworld> rick_h_: of course i want to use the same stuff :-) that's why it was in the js
[00:35] <wallyworld> i think i can put in a file and load the file in the test html
[00:35] <wallyworld> trying that now to see if it has legs
[00:46] <wgrant> jelmer: Thanks.
[00:48] <rick_h_> wallyworld: yea, that's what I've done in my app is create a jstemplate file that I include in both places
[00:53] <wallyworld> rick_h_: if i have a script element with a src attribute, what's the magic to get yui to be able to get at the contents of the referenced file?
[00:54] <rick_h_> Y.one('#id').getContent() I think
[00:54] <rick_h_> oh, it's got a src attribute? hmmm, not sure if that works
[00:54] <wallyworld> yeah, getContent() fails
[00:55] <wallyworld> well, i used src since i wanted to reference the single copy of the mustache template file
[00:55] <wallyworld> that same copy that the view passes to the js in prod
[00:57] <wallyworld> maybe ScriptNodeDataSource
[00:59] <wgrant> wallyworld: I would hope that you couldn't get at the content.
[00:59] <wgrant> That would be a security issue unless very carefully restricted.
[00:59] <wallyworld> wgrant: it's in the test html
[00:59] <wallyworld> to load the mustache template data from a file to pass to the widget
[01:00] <wallyworld> on prod, the pythov view does this
[01:00] <wallyworld> but i want to use the same template for testing
[01:00] <wgrant> Ah, interesting.
[01:00] <wallyworld> i currently have the template in the js but people don't like this
[01:01] <wallyworld> so i'm trying to find another way
[01:01] <wallyworld> buglistings does it this way but there' no yui rendering tests using the template
[01:01] <wallyworld> so they didn't need to solve this
[01:05] <wallyworld> so it appears html5 has a File api which may be useful
[01:07] <wgrant> rofl
[01:07] <wgrant> glwt
[01:08] <wallyworld> well spec draft is from oct 2011 so it's "ancient" :-)
[01:28] <wgrant> Hmm
[01:28] <wgrant> I can't talk to bits of the DC
[01:30] <wgrant> Ah, there we go.
[01:33] <lifeless> wallyworld: hi
[01:33] <wallyworld> lifeless: hello
[01:33] <lifeless> wallyworld: you should deliver the template via the API/view involved - combo loader eventually
[01:33] <lifeless> wallyworld: is there a reason that that won't work ?
[01:34] <wallyworld> lifeless: that's all well and good but i need the same content for yui tests
[01:34] <lifeless> I don't see the problem
[01:34] <wallyworld> that's the issue here
[01:34] <wallyworld> tests have a html file and a js file
[01:34] <wgrant> There's no API or view in a YUI test.
[01:34] <lifeless> the yui tests are loaded and run by the lp test driver which is part of our regular python stack
[01:35] <lifeless> how will the yui tests work in a non-launchpad.js world ?
[01:35] <wallyworld> yui tests don't have our python stack, just html and javascript
[01:35] <rick_h_> the yui tests are just calling .html files iwth JS that runs on them
[01:35] <rick_h_> our test stack is just a vessel to load .html files and parse response
[01:35] <wallyworld> eg you can load the test html file in a browser
[01:35] <lifeless> rick_h_: and the html5-browser wrapped around that
[01:35] <wallyworld> and the tests will run
[01:35] <wallyworld> with no lp running at all
[01:36] <wallyworld> just pure js
[01:36] <rick_h_> we'd need to find some way to write templates to a .html file and include it into the test.html file (iframe or something?) and pull that html file into the zope template as required for the JS on page to use
[01:36] <lifeless> no yui ?
[01:36] <wallyworld> yui, yes
[01:36] <lifeless> rick_h_: guh what
[01:36] <wallyworld> but reasd off disk locally
[01:36] <rick_h_> I've not had a chance to think it through 100% yet. I just know I hit it when updating the tests and it's on my list.
[01:37] <wallyworld> lifeless: so you see the problem now?
[01:37] <lifeless> rick_h_: so lets skip mustache
[01:37] <lifeless> wallyworld: I see the corner we've painted ourselves into
[01:37] <rick_h_> so for instance, in my outside application, tests are run via the application so that I can import the same template file in the tests that the application uses
[01:37] <lifeless> wallyworld: we've violated abstractions and are now suffering
[01:37] <wallyworld> lifeless: well, it's how yui tests have been written since day 1
[01:38] <wgrant> lifeless: You might be thinking of YUIXHR
[01:38] <wgrant> Which uses an appserver.
[01:38] <lifeless> I might be
[01:38] <lifeless> so, lets break this into bits
[01:38] <wallyworld> lifeless: there's no server side rendering here
[01:38] <lifeless> unit tests should not be testing the template outputs; thats orthogonal
[01:38] <wallyworld> so involing the view is bogus
[01:39] <lifeless> testing that a template is rendered and executed is sensible, but the code under test is supplied the template by the server
[01:39] <wallyworld> the view unit tests do need to test the rendering of data
[01:39] <wallyworld> sure, but we need a way to test without the server where the yui unit tests can get at the template
[01:39] <wallyworld> single sourced
[01:39] <wallyworld> and that's the issue
[01:40] <lifeless> so, I think I'm going to get my nose out of this discussion, because I clearly have a different model for whats going on
[01:40] <wgrant> lifeless: What about the unit tests for the template rendering?
[01:40] <wgrant> Surely they need to be testing the template output.
[01:40] <lifeless> I will throw a few key constraints in though to save us later
[01:41] <lifeless> firstly, the templates -must not- be inline in our js or tal files
[01:41] <wallyworld> impossible to write yui unit tests without code copying then
[01:41] <lifeless> we will be compiling them and shipping the compiled result as js to use, accessed probably via the combo loader, or in a pinch via the json cache
[01:42] <lifeless> if the template is inline in our js or tal, that won't work, and we'd be screwed. This is just around the corner when the combo loader comes live && YUI 3.5
[01:42] <wallyworld> nope, the combo loader can handle that ust fine
[01:42] <lifeless> orly
[01:43] <wallyworld> the template is built up inside our javascript
[01:43] <wallyworld> and accessed via a method on the view widget
[01:43] <lifeless> it will extract the template from another file, compile it with nodejs, write that to a temp file and then we'll serve that?
[01:44] <lifeless> I feel very confused.
[01:44] <wallyworld> no, and we use this in several places, we use Node.create(template) where template is a concatenated string of html
[01:44] <lifeless> I'm talking about handlebars templates.
[01:44] <wallyworld> on in the case of mustache, to_html(template)
[01:44] <wgrant> wallyworld: The template is rendered
[01:44] <wallyworld> same thing
[01:44] <wgrant> The rendered template is given to Node.create
[01:44] <wallyworld> yes, i was using an example
[01:44] <lifeless> wallyworld: its not the same thing, the template gets *compiled*
[01:44] <lifeless> wallyworld: it comes down as javascript, in its own source file.
[01:45] <wallyworld> i was trying to issultrate that the template does not have to come from server side
[01:45] <wallyworld> it can be constucted the the js
[01:45] <wallyworld> we use that right now in the code
[01:45] <wgrant> The template has to.
[01:45] <wallyworld> no
[01:45] <wgrant> The JS can't calculate it client-side.
[01:45] <wallyworld> yes, it does
[01:46] <wgrant> No.
[01:46] <wallyworld> we use it now
[01:46] <lifeless> wgrant: handlebars compiler can run client-side, but it is overhead
[01:46] <wgrant> It can't, because we have to specify it somehjow.
[01:46] <wgrant> I mean a (potentially compiled) template.
[01:46] <wgrant> Has to be transmitted from the server
[01:46] <wgrant> at some point.
[01:46] <wallyworld> no, let me find the example
[01:46] <lifeless> we wouldn't want a compiled template from a foreign site, but from LP itself, we want compiled templates I think.
[01:47] <lifeless> this 'no' business doesn't really elucidate the issues
[01:47] <wgrant> wallyworld: You are *rendering* the template client-side.
[01:47] <wallyworld> we concatentate strings to form a mustache template and then call to_html
[01:47] <wgrant> Oh god
[01:47] <wgrant>  /wrists
[01:47] <lifeless> wallyworld: thats a creative use of mustache
[01:47] <lifeless> wallyworld: its not how it is intended to be used though, so I'm curious why that is done
[01:47] <wallyworld> lifeless: it's an extenstion of a prior "pattern" in our js
[01:48] <lifeless> wallyworld: Possibly, but humour me
[01:48] <lifeless> wallyworld: assume I've no prior knowledge and need to be taught why we do this to a mustache template
[01:48] <wallyworld> lifeless: going way back, people used Y.Node.create(html) where the html was ['stuff', 'stuff'].join(' ')
[01:49] <lifeless> wallyworld: ok; but what joins that into how we use mustache? why is it relevant?
[01:49] <wallyworld> then, in some previous code review, it was suggested that a mustache template be used to get the html
[01:49] <wallyworld> so, html = Y.lp.mustache.to_html(template) where template = [xxx].join(' ')
[01:49] <lifeless> wallyworld: ok, I'm clear on what is being done, I'm not clear on why.
[01:49] <wallyworld> it was used for a local popup dialog or something
[01:50] <lifeless> wallyworld: you may not know, which is fine.
[01:50] <lifeless> wallyworld: if you don't, we can skip trying to understand as a group, and move on; if you do know, I'd really like to grok this.
[01:50] <wallyworld> lifeless: so, it wasn't for main view content, but for a confirmation dialog
[01:51] <wallyworld> where the data to ask for confirmation for was best rendered using mustache
[01:51] <wallyworld> since it contained a list of things
[01:51] <wallyworld> easier than building the html by hand
[01:51] <lifeless> wallyworld: that would normally be to_html(template, data)
[01:51] <wallyworld> yes
[01:51] <lifeless> where data has that list in it
[01:51] <wallyworld> yes
[01:51] <lifeless> so why was this done differently ?
[01:51] <wallyworld> define "this"?
[01:51] <lifeless> 14:49 < wallyworld> so, html = Y.lp.mustache.to_html(template) where template = [xxx].join(' ')
[01:52] <wallyworld> i left out the data param
[01:52] <wallyworld> pseudo code and all that
[01:52] <lifeless> why isn't template static though ?
[01:52] <wallyworld> it is
[01:52] <lifeless> Perhaps I misunderstand
[01:52] <rick_h_> it is, but it has to live somewhere. Usually, you write out a <script type="text/template"> block that contains the static html.
[01:52] <lifeless> template = [xxx].join(' ') looks like it is string joining to create the template
[01:52] <lifeless> that is not static
[01:52] <rick_h_> that ends up getting made available on the page via your template
[01:52] <lifeless> its dynamic
[01:53] <lifeless> rick_h_: not helping
[01:53] <wallyworld> lifeless: our coding standard dictate that approach
[01:53] <wallyworld> lifeless: no static, but coding standards force us to do it that way
[01:53] <wallyworld> break up the string into bits
[01:53] <rick_h_> lifeless: ok, can we do a hangout or something? I can hop on the phone. wallyworld is correct, this is a known issue I've seen coming.
[01:53] <wallyworld> line length and all that
[01:53] <lifeless> rick_h_: sure, we can do that
[01:53] <rick_h_> and I can walk through it
[01:53] <wallyworld> mumble ?
[01:54] <wgrant> Oh
[01:54] <rick_h_> I can't, I'm out at a coffee shop without headset/etc
[01:54] <rick_h_> I can use skype or hangout via my cell
[01:54] <wgrant> You mean just as a replacement for """?
[01:54] <lifeless> skype or hangout - they have echo cancellation
[01:54] <wallyworld> wgrant: js dorsn't have """
[01:54] <rick_h_> yea, but in a noisy coffee shop with 10 other techies talking/hacking
[01:54] <wgrant> Right, but that's a faaaaaaaaaaaaaaaaaaaaaaar more restricted case than what you said :)
[01:54] <wallyworld> let's try skpe but mine is flakey
[01:55] <rick_h_> ok, my skype is mitechie
[01:55] <wgrant> It made it sound like you were generating the template dynamically, rather than just concatenating strings in a static way because JS is hideous.
[01:55] <wallyworld> wgrant: oh, i didn't mean to imply that
[01:55]  * wallyworld installs skpye
[01:55] <lifeless> wallyworld: you said it had to be in the js file because it was built up like this
[01:56] <lifeless> wallyworld: but if it is only built up like this because it is in the js file, then that is circular logic
[01:56] <rick_h_> lifeless: it *needs* to be in the JS file for the unit test .html file to have access to it
[01:56] <wgrant> Exactly.
[01:56] <wallyworld> lifeless: i meant to convey it was in the js to avoid code cut and paste for tests
[01:56] <wgrant> @lifeless
[01:56] <wallyworld> i believe that's what i said, but it has been misinterpreted :-)
[01:56] <lifeless> rick_h_: I get that, but see my point about compilation above.
[01:57] <lifeless> who wants in on this kall ?
[01:57] <wallyworld> me as soon as i install skype
[01:58] <timrc> I have a general yui testing question (that I also asked in #yui) and since you guys have a bit of experience, perhaps you would know... I'm trying to test DOM events on a form, e.g. when I select an item from this dropdown it updates a textarea based on the choice, but do not know how to do this short of embedding the tests in the page
[01:59] <lifeless> timrc: sounds like you are testing across abstractions
[02:00] <timrc> probably ;) I accomplished this with jasmine using fixtures, but now I must yui
[02:00] <rick_h_> timrc: check out node-event-simulate to trigger events and then check callbacks are run/processed
[02:00] <timrc> rick_h_, but can I actually load the form into the dom in a seperate test page?
[02:01] <rick_h_> timrc: so no, you'd use the setUp of the suite to generate the html required
[02:01] <rick_h_> the .html page the tests run on is a giant fixture
[02:02] <rick_h_> you can preload with html, use setup/teardown to setup html/clear it between tests
[02:02] <rick_h_> timrc: see lib/lp/app/javascript/indicator/tests/test_indicator.js
[02:03] <rick_h_> if you can access the LP source for an example
[02:03] <timrc> rick_h_, will do. damn typing with a 7 mo old in your lap is challenging
[02:03] <rick_h_> heh, understand completely :)
[02:03] <wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/indicator/tests/test_indicator.js
[02:03] <rick_h_> thanks wgrant, wifi here is awesome and didn't want to try to pull it up on my phone :)
[02:04] <lifeless> short urls R us
[02:04] <rick_h_> by awesome I mean fail
[02:04] <wgrant> rick_h_: What sort of phone do you have?
[02:04] <rick_h_> nexus
[02:04] <wgrant> rick_h_: I need someone with an iPhone to try that page
[02:04] <lifeless> handheld
[02:04] <wgrant> Ah
[02:04] <rick_h_> sorry, galaxy nexus
[02:04] <lifeless> wgrant: grab anyone from design
[02:04] <wgrant> iOS Safari doesn't like my CSS
[02:04] <wgrant> Making the line numbers crap.
[02:04] <wgrant> lifeless: Hah
[02:04] <rick_h_> guy here has one, sec let me get him the url
[02:05] <rick_h_> wgrant: have a guy tring it out
[02:06] <wgrant> rick_h_: Ah, thanks. We've had one report that it sucks, mostly want confirmation before I work out how to dig further.
[02:06] <wgrant> But I suspect that I have to throw it at someone else, since I don't have any way of running iOS Safari
[02:06] <wgrant> I love Apple so much.
[02:07] <rick_h_> wgrant: well it *looks* ok, the only issue is that the line number font is < code font so they don't line up
[02:07] <timrc> rick_h_, no way to say "load this url into the DOM" and then test the result? :)
[02:07] <wgrant> rick_h_: Yeah, that's the issue.
[02:07] <rick_h_> wgrant: so you run out of line numbers, but it reads ok otherwise
[02:07] <wgrant> Thanks.
[02:08] <rick_h_> timrc: so what'd you'd have to do is iframe into the .html page the content you want loaded, and then copy it out via JS in your setUp method
[02:08] <wgrant> The CSS needs redoing, but it works on desktop Trident/WebKit/Gecko/Presto :(
[02:08] <rick_h_> timrc: off the top of my head, the issue is that it's raw plain .html so you can't *include*
[02:08] <timrc> rick_h_, ah clever, but I can sort of see where lifeless is comin from when he says "testing across abstractions"
[02:08] <rick_h_> wgrant: yea, I mean the colors/etc look ok
[02:08] <rick_h_> timrc: definitely
[02:09] <timrc> rick_h_, maybe jasmine encouraged bad behavior... typically you would test form interactions with selenium, no?
[02:09] <rick_h_> timrc: so if your code is responsible for the generation of the html it's less an issue
[02:09] <rick_h_> timrc: well you're hitting BDD vs TDD
[02:09] <rick_h_> timrc: it's a root thing that behaviour is much higher up the stack of a functional test
[02:10]  * wallyworld stabs apt-get update... sooooo sloooow
[02:10] <rick_h_> timrc: so the stuff you're doing with jasmine are really where the sst type stuff would come into play, or in YUI would be if you're creating full Y.Widgets that the html/interactions are tied into a single unit to test with
[02:10] <timrc> rick_h_, I think what I'll do for at least now is take my jasmine fixture and copy-paste it into my yui test html file that should achieve what you're talking about
[02:11] <rick_h_> timrc: rgr
[02:11] <rick_h_> timrc: it's something we've got to work on as we start to get more complicated and need higher level behavior tests than we currently run
[02:12] <lifeless> mmm
[02:12] <lifeless> so BDD doesn't want to test the whole stack
[02:12] <lifeless> thats a false meme
[02:12] <timrc> apparently people want to build armhf images yesterday, so I'll take the path of least resistance, here
[02:12] <rick_h_> timrc: yea, like that example wgrant posted, we generate bootstrap html in the test to run against, it's a common 'fixture' practice
[02:12] <lifeless> BDD wants to test the interactions between components - e.g. when A is the SUT test that asking A to do X results in A asking B for help
[02:13] <lifeless> TDD might also look at the state of A before and after, and BDD frowns more on that than pure TDD does
[02:13] <lifeless> but even within TDD there are huge differences of opinion there
[02:13] <rick_h_> right
[02:13] <lifeless> the key thing that *both* TDD and BDD say here
[02:13] <lifeless> is that if you are using a known good component
[02:13] <lifeless> DO NOT TEST IT
[02:13] <lifeless> test /how/ you use it.
[02:14] <rick_h_> right, so he's starting with a BDD "fixture" and wanting to copy/pull that into his TDD somehow as a "fixture"
[02:14] <lifeless> not what it does
[02:14] <rick_h_> in jasmine, it's including an external html file so he wants to "import" that into the YUI .html test file, but not a good way to do that since it's raw .html without server side includes/imports of any sort
[02:17] <lifeless> yeah
[02:17] <timrc> jasmine structures tests as it("should do this when this condition is met", function())
[02:17] <rick_h_> timrc: yea, and you can create a test in YUI that's "should do this ..." that get run after setUp()
[02:18] <rick_h_> we use the test_something_does_something: function format
[02:18] <rick_h_> but the text string "this should that" also work
[02:18] <rick_h_> it just doesn't nest like a jasmine tests would
[02:18] <lifeless> so I think I'm saying that testing here is really checking that the event is raised, and that the widget is subscribed to it
[02:19] <lifeless> testing between them is a bit odd
[02:19] <timrc> so maybe this is actually a job for something higher up the stack, when the user selects item A, the textarea is populated with X, Y, Z ?
[02:19] <rick_h_> yea, normally we'd split the test. One that the event is fired by mocking the callback
[02:20] <rick_h_> and secondly, that given a method with the right/wrong input data that the callback does what we think it should do
[02:20] <rick_h_> timrc: right, that starts to sound like a live functional test which might be run via sst
[02:20] <rick_h_> or you could test that when the user selects an item, an event is fired with A's data
[02:21] <rick_h_> and then, firing a custom fake event with data XXX, the textarea will populate with other stuff
[02:21] <rick_h_> so two different sets of tests, one against the select/drop down, and one against the textarea
[02:21] <rick_h_> that'd be breaking it more into unit tests, using two suites, you could have different setUp() and tearDown() and those would bootstrap a select element to test against
[02:22] <rick_h_> and the second suite would setup a textarea that you test against
[02:22] <wgrant> StevenK: How goes the AccessPolicy creation?
[02:23] <rick_h_> oh StevenK so I heard convoy RT is right after the librarian san stuff fyi
[02:26] <timrc> rick_h_, I'm quickly learning why QA is its own discipline, but I'm happy to learn.  I fear that the complexity of testing is going to prevent me from getting very flashy in Offspring :)
[02:26] <rick_h_> timrc: yea, I mean that's why it's a giant can of compromise
[02:26] <wgrant> rick_h_: librarisan is hopefully only a couple of days away :)
[02:26] <rick_h_> the idea is that you get somehting that tests, you can add things you break to, but it's always going to have gaps/wholes
[02:27] <rick_h_> wgrant: ooh, that makes me so happy
[02:27] <rick_h_> it sounded like it was something rather large/far out
[02:27] <wgrant> Well
[02:27] <wgrant> It's actually running partly on the SAN atm
[02:27] <wgrant> Just on the old machine via NFS.
[02:27]  * timrc hisses at the mention of NFS
[02:27] <wgrant> The firewall was opened this morning, so it's just a couple of deployment and monitoring things left before we can switch.
[02:29] <wallyworld___> rick_h_: lifeless: finally got skype installed
[02:29] <rick_h_> wallyworld___: cool
[02:30] <lifeless> wallyworld___: rick_h_: ok, gimme a couple minutes to put a load of washing on
[02:30] <wallyworld___> ok
[02:30] <rick_h_> lifeless: rgr
[02:31] <rick_h_> I've got 30min before close
[02:31] <wallyworld___> rick_h_: i tried calling you but my request was rejected
[02:32] <rick_h_> wallyworld___: sorry, missed your request, added you to my contact list now
[02:36] <lifeless> wallyworld___: ah, if you're hosting, call me in
[02:38] <timrc> rick_h_, anyway, thanks for the help, I think I have enough to go forward.  Really appreciate it
[02:53] <StevenK> wgrant: I still have test failures. :-(
[02:53] <wgrant> StevenK: Oh?
[02:54] <StevenK> wgrant: Let me pastebin a diff and the failures
[02:54] <wgrant> That would be ideal.
[02:57] <StevenK> wgrant: http://pastebin.ubuntu.com/862865/
[02:59] <wgrant> StevenK: What happens if you try to run it manually?
[03:00] <wgrant> It's also not inconceivable that you might have to commit/abort the transaction before you can see the result.
[03:00] <StevenK> wgrant: http://pastebin.ubuntu.com/862870/
[03:01] <StevenK> But __call__ in the job calls commit :-(
[03:01] <wgrant> That's in the job.
[03:02] <wgrant> Which is hopefully a separate process, and therefore a separate transaction.
[03:02] <StevenK> No other test calls commit after self.runHourly()
[03:03] <wgrant> Ah
[03:03] <StevenK> I'm of the opinion that I've missed something utterly stupid and I've been chasing it for hours.
[03:03] <wgrant> You've run make schema to ensure that the security change made it to launchpad_ftest_template?
[03:03] <StevenK> Yup.
[03:04] <wgrant> Ensure that statement logging is enabled and watch your postgres log during the test run.
[03:04] <wgrant> also, most of __call__  can be replaced with a list comprehension.
[03:04] <StevenK> Oh?
[03:05] <StevenK> I'm already using one in what I thought was a clever way.
[03:05] <wgrant> You construct an empty list, then iterate over a tuple, on each iteration adding some tuples to the list.
[03:06] <wgrant> policies = [(distro, policy) for distro in self.findDistributions()[:chunk_size] for policy in (USERDATA, PROPRIETARY)]
[03:07]  * StevenK sprinkles in AccessPolicyType
[03:07] <wgrant> Although this is unfiltered, so you can also just use itertools.product
[03:08] <lifeless> ok, skype call done
[03:08] <lifeless> tl;dr for folk here:
[03:08] <lifeless>  - handlebars really wants to be treated more like C - server side compile, separate source, mustache is a middle ground
[03:09] <lifeless>  - can possible just use an iframe to suck in templates we need, ian is trying that, should work on mustache too [for the tests]
[03:10]  * StevenK laughs at bigjools new profile picture
[03:10] <wgrant> Heh, yes.
[03:11] <StevenK> wgrant: LP_DEBUG_SQL=1 isn't good enough?
[03:11] <wgrant> StevenK: Not sure if that works for garbo subprocesses in tests.
[03:11] <StevenK> Right
[03:11] <wgrant> We often run subprocesses in a sanitised env.
[03:11]  * StevenK reaches for postgres' conf
[03:12] <lifeless> can whitelist that parameter probably
[03:13] <StevenK> I leave it off so /var doesn't fill up after a days test runs
[03:14] <lifeless> sure
[03:14] <lifeless> I meant for subprocs
[03:14] <lifeless> so that when you set it, it wrks
[03:14] <wgrant> I leave it on because my hard disk isn't from 1990.
[03:14] <StevenK> /dev/mapper/sys-var   4.6G  1.6G  2.8G  37% /var
[03:17]  * StevenK sighs at the hidden scrollbars crap
[03:17] <StevenK> Makes dealing with long output bloody tedious
[03:18] <wgrant> Does gnome-terminal have scrollbars at all any more?
[03:18] <wgrant> Oh, it does.
[03:18] <wgrant> But the thumb is invisible afaict.
[03:19] <StevenK> Right, 100,000 lines of output later
[03:19] <StevenK> (I wish I was joking)
[03:20] <lifeless> rick_h_: oh, and the site I was pointed at demoing yui_handlebars has the precompiled templates referenced by its combo loader
[03:21] <lifeless> rick_h_: so I think that is actually more common than you may think :)
[03:23] <StevenK> wgrant: http://pastebin.ubuntu.com/862893/
[03:24] <wgrant> StevenK: So, garbo seems to be behaving properly. What about the test?
[03:25]  * StevenK is just about to dump everything containing accesspolicy into a paste
[03:28] <StevenK> wgrant: http://pastebin.ubuntu.com/862902/
[03:30] <wgrant> StevenK: So, I would suggest breaking with pdb and then poking around in psql
[03:30] <wgrant> Or potentially from within pdb if you are brave.
[03:30] <StevenK> Perhaps my find* and isDone methods are to blame
[03:31] <wgrant> I doubt it.
[03:31] <wgrant> We can see they're being inserted.
[03:32] <wgrant> Ah, you may be right.
[03:32] <wgrant> Distro 3 is not new.
[03:32] <StevenK> Oh?
[03:33] <wgrant> Also, calling AccessPolicy.create like that is illegal
[03:33] <wgrant> getUtility(IAccessPolicySource).create
[03:38] <StevenK> What the? Now it's working?
[03:39] <rick_h_> lifeless: linky?
[03:39] <rick_h_> lifeless: on the precompiles template stuff?
[03:39] <StevenK> rick_h_: I think's awesome you're using using convoy with bookie
[03:39] <StevenK> s/'s/ it's/
[03:40] <rick_h_> StevenK: yea, getting some good tests out of it and swapping code back/forth
[03:40] <rick_h_> StevenK: though it's nginx vs apache
[03:40] <rick_h_> well, gunicorn in dev, but in prod nginx
[03:40] <StevenK> The nginx fanbois turn me off trying it
[03:41] <rick_h_> heh, I'm a fan. I read through an apress book (I think) and since I"m running ec2, lower memery usage ftw
[03:41] <StevenK> There are a bunch of them in #linode and anytime someone turns up with an Apache problem, regardless of the problem, they spend hours trying to convert the guy to use nginx
[03:41] <rick_h_> heh
[03:42] <rick_h_> yea, well I know apache has a lot more uses
[03:42] <rick_h_> but for lower memory it's a win
[03:43] <StevenK> wgrant: So here's an interesting data point. If I run test_AccessPolicyDistributionAddition in isolation it works, but running test_garbo causes it to fail
[03:48] <lifeless> rick_h_: grah, uhm, lets see
[03:48] <rick_h_> lifeless: np, just curious
[03:50] <lifeless> rick_h_: beta.tdp.me
[03:50] <lifeless> rick_h_: http://tdp.me/combo?template/template-goal-table/template-goal-table-min.js
[03:51] <rick_h_> lifeless: ah cool
[03:52] <lifeless> irssi-2012-02-09:09:00 #launchpad-dev: < rick_h> lifeless: so this guys in #yui gave me this for some handlebar exapmles: http://beta.tdp.me/static/scripts/bundle.js http://beta.tdp.me
[03:53] <lifeless> :)
[03:53] <rick_h_> yea, I remember seeing it now
[03:53] <lifeless> dunno who, jshirley I think
[03:53] <rick_h_> yep
[03:53] <lifeless> the nginx casual approach to http turns me off :)
[03:55] <StevenK> wgrant: Running under garbo I never see the created distribution
[03:57] <rick_h_> wallyworld___: http://jsfiddle.net/83xZY/ seems to work
[03:59] <rick_h_> wallyworld___: note that it's running off the on load event
[03:59] <wallyworld___> rick_h_: i get an internal yui error
[03:59] <wallyworld___> will try of the onload
[03:59] <wallyworld___> i also tried via the dom element directly but got a permission error
[04:00] <rick_h_> wallyworld___: bah, that's what I was afraid of, it has to be same domain and prefix
[04:00] <rick_h_> file://
[04:01]  * wallyworld___ tries that
[04:01] <wgrant> sameorigin on the file scheme is a bit awkward :/
[04:02] <rick_h_> yea, but it's meant to prevent http/https crossing
[04:02] <rick_h_> I'm guessing more https making http calls
[04:02] <wgrant> I mean I don't think any two URLs from the file scheme are considered same-origin.
[04:02] <rick_h_> ah, yea I'm not sure of that
[04:03] <rick_h_> I was hoping maybe the issue he hit was that the browser was file:// while his iframe src="../../" without an explicit file:// :/
[04:03] <wgrant> (the scheme distinction is most often useful to prevent HTTP from doing HTTPS XHR)
[04:03] <wgrant> Ah
[04:03] <wgrant> "Starting in Gecko 1.9, files are allowed to read only certain other files.  Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however."
[04:03] <rick_h_> but I'm guessing at this point
[04:03] <wallyworld___> rick_h_: nah, still permission denied
[04:04] <rick_h_> heh, because it's not hard enough...
[04:04] <rick_h_> well then ajax requests won't fly either...
[04:07] <StevenK> Why the heck isn't this new distro turning up in the store? :-(
[04:07] <wallyworld___> rick_h_: i'm about to give up and say that i need to land the mp with the template in the js
[04:08] <rick_h_> wallyworld___: I'll +1 that with a note that it's something I'll investigate as I work on fixing hte combo loader going forward
[04:08] <wallyworld___> ok, excellent. thanks
[04:09] <rick_h_> it'll be a large todo item so it doesn't fall away, but as part of the combo loader completion story
[04:09] <rick_h_> it's going to require more testing than I can do past my bedtime :)
[04:09] <wallyworld___> yeah :-)
[04:09] <rick_h_> sorry again that it fell into your lap like this
[04:09] <wallyworld___> i just want to get myself unblocked for now
[04:09] <rick_h_> wallyworld___: definitely
[04:10] <wallyworld___> rick_h_: no need to say sorry, i was dreading this issue as well
[04:10] <StevenK> What's the issue?
[04:10] <rick_h_> StevenK: long story :)
[04:10] <rick_h_> wheee, and mailman day approacheth!
[04:10] <wallyworld___> StevenK: we want to have the mustache template in one place
[04:10] <wallyworld___> availabole for yui tests
[04:10] <wallyworld___> and for prod
[04:10] <StevenK> rick_h_: It's been Mailman day here for 15 hours
[04:11] <wallyworld___> and it's hard to do
[04:11] <rick_h_> StevenK: heh, just got my first one of the day
[04:11] <StevenK> Oh yeah, mail. I guess I should read that.
[04:11] <rick_h_> wallyworld___: you try out the auto js builder bits I emailed the list about?
[04:12] <rick_h_> I need to find people that can try/test that if you get some future JS work to tinker with
[04:12] <stub> w00t. pg9.1.3 packages out, containing the plpythonu fix we want for inplace upgrades
[04:12] <rick_h_> wallyworld___: or someone else on your team
[04:12] <wallyworld___> rick_h_: not yet, but it looks nice
[04:12] <rick_h_> wallyworld___: k, let me know if you guys can give it a spin and such
[04:13] <rick_h_> eventually want to see if we can mail the -tech about it if it works out ok
[04:13] <wallyworld___> rick_h_: will do. it's on my todo list to try out for sure
[04:13] <rick_h_> ok, time to go pass out, night
[04:13] <wallyworld___> rick_h_: see ya. thanx for your time
[04:25] <wgrant> oops
[04:25] <wgrant> Was wondering why one of my triggers was taking 25ms to reflatten a bug and all its tasks.
[04:25] <wgrant> Forgot that I hadn't removed the 250 tasks I'd created on the bug yesterday.
[04:41] <stokachu> http://pastebin.com/ah8aLQdL - ive managed to setup the authorization header which then seems to redirect me properly from /people/+me to /~adam-stokes
[04:41] <stokachu> but then i get a 303 see other error
[04:41] <stokachu> any ideas
[04:41] <wgrant> stokachu: 303 is the redirect
[04:42] <wgrant> It's not an error.
[04:42] <wgrant> Also, *really* not a good idea to give your OAuth tokens to the world.
[04:43] <wgrant> You probably want to revoke that one.
[04:43] <stokachu> i will
[04:43] <stokachu> is staging still down?
[04:43] <wgrant> It should be up.
[04:44] <wgrant> Has only been down for a couple of hours over the last few weeks.
[04:44] <stokachu> ah , there was a code update an hour ago
[04:44] <wgrant> Hmmm
[04:44] <wgrant> That should only take it down for a couple of minutes, I'd expect.
[04:44] <wgrant> Perhaps something is going wrong with the updates.
[04:45] <wgrant> It's up now.
[04:45] <stokachu> ah ok... so im in this redirect from the last response
[04:45] <stokachu> but should i be calling ~adam-stokes directly?
[04:46] <wgrant> Depends on your HTTP library.
[04:46] <wgrant> Some will follow the redirect automatically, others won't.
[04:46] <stokachu> hmm let me try to hardcode my name in and see what i get
[04:47] <wgrant> /people/+me does an HTTP redirect to the current logged in user.
[04:47] <StevenK> Or /~
[04:48] <stokachu> ah yea so this oauth library isn't following redirect
[04:48] <stokachu> i dont guess anyone is familiar with drupal 7 and its oauth stuff
[04:49] <StevenK> There's a Drupal 7 now?
[04:49] <StevenK> :-)
[04:49] <stokachu> lol
[05:04] <wgrant> You know
[05:04] <wgrant> It would be really nice if we had a sensible data access layer.
[05:04] <wgrant> So we could, like, not be terrible.
[05:06] <stokachu> its only a little complicated
[05:06] <stokachu> not to bad
[05:06] <wgrant> Not talking about the API, but that's not ideal either :)
[05:06] <stokachu> haha
[05:08] <StevenK> Hmmmmm, what database user does mail handling use?
[05:09] <wgrant> StevenK: Should be processmial
[05:09] <wgrant> processmail
[05:16] <stokachu> so if anyone is curious i have a 90% working drupal module for launchpad
[05:17] <stokachu> it just doesn't do anything yet but auth
[05:17] <stokachu> :X
[05:19] <wgrant> stokachu: What are you planning to use it for?
[05:20] <StevenK> wgrant, wallyworld___: Either of you feel like reviewing https://code.launchpad.net/~stevenk/launchpad/change-bug-privacy-via-mail/+merge/95312 ?
[05:20] <stokachu> mainly a dashboard between lp private and salesforce
[05:20] <wallyworld___> StevenK: i'm deep in some code changes, can do soon
[05:20] <wgrant> StevenK: OMG SOMEONE FIXED IT
[05:20]  * wgrant +1s
[05:20] <StevenK> Hahah
[05:21] <StevenK> I tagged the bug disclosure, I figured it was tiny enough we could claim it as a feature branch
[05:21] <stokachu> and possibly some helper stuff for submitting SRU's
[05:40] <StevenK> wgrant: So, looking at the not found page, you'd like some vertical whitespace between the heading and the first paragraph?
[05:41] <wgrant> StevenK: I don't know.
[05:41] <wgrant> Users currently don't get it.
[05:41] <wgrant> So the page needs *some* change.
[05:42]  * StevenK sprinkles in <strong> along with changing the heading to "Not Found" and puts it up for review
[05:43] <StevenK> IE, let's make a token effort and see what Dan comes back with
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[07:46] <czajkowski> aloha
[07:49] <stub> Didn't I add a 'previous OOPS' feature?
[07:50] <stub> OOPS caused due to thread state, so I need to know the previous screwup. Could have sworn I added that into the OOPS already...
[08:04] <stub> Did... so why isn't it in my OOPS?
[08:05] <lifeless> stub: you did
[08:07] <stub> Yer, found other OOPSes with the key. But the one I'm interested in doesn't have it. Might mean it was the first OOPS generated by that thread, but I somehow doubt it.
[08:08] <stub> But it is generated from beforeTraverse, so things might get weird.
[08:52] <adeuring> good morning
[09:02] <mrevell> hi
=== almaisan-away is now known as al-maisan
[10:14] <StevenK> danhg: Hai, have you seen https://code.launchpad.net/~stevenk/launchpad/not-found-page/+merge/95313 ?
[10:15] <danhg> Hmmm.... thanks StevenK
[10:21] <mabac> StevenK, hi there. did you get a chance to look at salgado's changes on https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 ? just wondering if there's anything I can handle it before he wakes up. :)
[10:28] <StevenK> mabac: Hai. I have commented.
[10:29] <mabac> StevenK, cool, thank you
[10:36] <mabac> StevenK, let's see if I understand that. :) you don't want us to revert the last change, it's only about setting that feature flag, right?
[10:41] <StevenK> mabac: So, I'd like to see the loop move from the experimental loops to the usual one, and a feature flag a guard when it runs
[10:42] <mabac> StevenK, ok got it. thanks
[10:43] <StevenK> mabac: Of course, along with adding two tests, one to see the job doesn't run with no feature flag, and the inverse.
[10:44] <mabac> StevenK, of course
=== al-maisan is now known as almaisan-away
=== matsubara-afk is now known as matsubara
=== Ursinha-bbl is now known as Ursinha
[12:51] <rick_h_> morning
[12:54] <czajkowski> rick_h_: ello
=== almaisan-away is now known as al-maisan
[13:33] <mabac> rick_h_, good morning. thanks for reviewing my branch! I have separated the parsing and validating parts of parseLine but don't know if there is a better error to raise when parsing than LaunchpadValidationError?
[13:34] <rick_h_> mabac: I'm not sure on that end. I'll see what jcsackett brings up on that front
[13:34] <mabac> rick_h_, ok thanks
=== rick_h_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett, rick_h* | Firefighting: - | Critical bugtasks: 4*10
[14:55] <jcsackett> rick_h_, mabac: almost done with that MP. i see no problem with LaunchapdValidationError, since ulitmately the method is only used as part of the set of calls from validate.
[14:55] <jcsackett> if you didn't raise it as such there, you would probably want to reraise from within validate anyway.
[14:56] <rick_h_> jcsackett: ok cool
[14:57] <mabac> jcsackett, cool thanks.
[15:10] <jcsackett> mabac: questions/comments posted on your MP.
[15:11] <mabac> jcsackett, thank you. I'm on it
[15:11] <jcsackett> mabac: cool. there's nothing major, just a few little things.
[15:16] <mabac> jcsackett, doesn't look to bad. ;) I'll fix it up today.
[15:16] <jcsackett> mabac: awesome. thanks. :-)
[15:17] <mabac> jcsackett, I can remove that assert entirely btw. it can just catch programming errors as you noted
[15:17] <jcsackett> mabac: that's what i thought.
[15:17] <jcsackett> glad i wasn't off base.
[15:33] <salgado> mrevell, did you see my email about announcing the work items changes we're doing in LP?
[15:35] <mrevell> salgado, Sorry yes. I'll be on the phone for another 20-30 minutes then I'll replu.
[15:35] <mrevell> s/replu/reply
[15:36] <salgado> mrevell, that's cool, thanks!
=== al-maisan is now known as almaisan-away
=== danhg_ is now known as danhg
[15:51] <salgado> jcsackett, StevenK reviewed https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 and said he was happy with it but wanted a new feature flag to prevent it from running on production until we're ready.  I was wondering if you'd be willing to review the feature flag changes and land it for me so that we can start QAing it in production?
[15:51] <salgado> s/production?/staging?/
[15:52] <sinzui> danhg, do you want try a screen share where we build a mockup together?
[16:07] <danhg> Hey sinzui, That sounds great. I'm also working with Matthew on a broader process for testing -> mock-ups -> implementation.
[16:08] <sinzui> danhg, great We can try this now and when you are ready
[16:08]  * sinzui has never tied hangouts screen sharing
[16:12] <salgado> matsubara, if you'd like to try and break the new work-items UI, it's at lp:~linaro-infrastructure/launchpad/workitems-widget
[16:12] <matsubara> salgado, thanks
[16:12] <matsubara> salgado, is it being reviewed?
[16:15] <salgado> matsubara, yes, although most of the changes requested were in tests
[16:15] <matsubara> ok
[16:16] <matsubara> salgado, by tomorrow it'll be on qastaging, do you think?
[16:17] <salgado> matsubara, that depends on QAing the migration script, I'd say.  do you need to wait until it's there to QA it?
[16:17] <matsubara> yeah, it's better to do it on staging or qastaging with the full db
[16:18] <jcsackett> salgado: sure, i'll take a look at it.
[16:19] <salgado> matsubara, in this case the UI is just a text entry, similar to the whiteboard.  the only way to break it is by entering unparsable stuff and hoping for the worse, so having it on staging won't make any difference
[16:20] <matsubara> ok
[16:25] <salgado> mrevell, I guess you also didn't have time for the help text (https://bugs.launchpad.net/launchpad/+bug/944119)?
[16:25] <_mup_> Bug #944119: Add help popup to the new work-item editor <Launchpad itself:New> < https://launchpad.net/bugs/944119 >
=== matsubara is now known as matsubara-lunch
[16:31] <mrevell> salgado, Hey, I can still do this. Is it okay if I just give you the text?
[16:31] <salgado> mrevell, definitely!
[16:32] <salgado> mrevell, as for the announcement, do you guys take care of that as well or should we write it ourselves?
[16:33] <mrevell> salgado, We can take care of that. It'd be great to have an idea of anything in particular you want us to say, though. When do you expect to be ready to make the announcement?
[16:33] <salgado> mrevell, ok, I'll write down the important points.  hopefully early next week
[16:34] <mrevell> Thanks. I'll get the help text to you tomorrow.
[16:34] <salgado> mrevell, great, thanks!
=== salgado is now known as salgado-lunch
[16:37] <mabac> jcsackett, there I believe I've fixed your suggestions for lp:~linaro-infrastructure/launchpad/workitems-widget
[16:39] <mabac> jcsackett, I'll clock off now but if there's anything that's not clear salgado-lunch will be able to answer and I'm back online in ~14 hrs :)
[16:40] <czajkowski> salgado-lunch: give me a shout when you;'re back
[16:40] <czajkowski> we should talk :)
[16:41] <abentley> adeuring: I've got tests that prove a job runs under Celery.  Any advice on how to clean them up? ~abentley/lazr.jobrunner/run-via-celery
[16:41]  * adeuring is looking
[16:46] <adeuring> abentley: "make check" just gives me "TypeError: 'NoneType' object is not callable" ...
[16:46] <abentley> adeuring: Yeah, I talked to barry about that and he couldn't help me, so for now I'm using nosetests.
[16:46] <adeuring> abentley: how do I start one?
[16:47] <abentley> bin/python `which nosetests` should do it.
[16:47] <adeuring> ah, got it
[16:48] <abentley> adeuring: I particularly dislike the way I'm finding the celeryd binary.  Seems there should be a better way.
[16:49] <abentley> adeuring: Also, the fact that config files are python modules prevents me from generating a config in a temp directory as I normally would.
[16:52] <adeuring> abentley: what is your problem with the cleanup?
[16:53] <abentley> adeuring: I don't know what you mean.  The 'NoneType' is not callable thing?
[16:53] <adeuring> abentley: I menat your quetion "Any advice on how to clean them up?"
[16:55] <abentley> adeuring: I think the implementation is dirty, particularly the way I find the celeryd binary and the fact that the testing config is a file in the tree.
[16:56] <abentley> adeuring: Do you have any suggestions for improving the test implementation?
[16:56] <adeuring> abentley: "cmdname = os.path.join(get_root(), 'bin/celeryd')" ? I don't see any better option
[16:59] <adeuring> abentley: regarding the configuration of celeryd: the config module could read the parameters from a temp file, in order to set things like BROKER_HOST etc
[16:59] <abentley> adeuring: How would it find the temp file?  Environment variables?
[17:00] <adeuring> abentley: rigt. Or use some hard wired path: /tmp/celery_test.cfg or whatever
[17:02] <adeuring> abentley: slightly crazy idea: pipe the config data: you use popen()...
[17:03] <abentley> adeuring: And then config.py reads stdin?
[17:03] <adeuring> abentley: yes, but may be soimply crazy...
[17:03] <adeuring> I don't know if celeryd itself checks stdin...
=== matsubara-lunch is now known as matsubara
=== deryck is now known as deryck[lunch]
=== salgado-lunch is now known as salgado
[17:46] <salgado> hi czajkowski
[18:09] <czajkowski> salgado: howdy
[18:09] <czajkowski> salgado: are you free tomorrow to talk re getting information out about blurprints?
[18:10] <jelmer> pun intentional ? :)
[18:11] <salgado> czajkowski, sure. tomorrow around 11:00 UTC ok with you?
[18:16] <czajkowski> salgado:
[18:16] <czajkowski> salgado: you on the canonical calender?
[18:18] <salgado> czajkowski, yep, salgado should be my username there
[18:18] <salgado> I see you've found me already :)
[18:19] <wilx> Hi.
[18:20] <jelmer> hi wilx
[18:20] <czajkowski> salgado: lovely talk tomorrow so
=== deryck[lunch] is now known as deryck
[18:44] <salgado> deryck, hi there. do you have any idea how hard it'd be to fix bug 415365?
[18:44] <_mup_> Bug #415365: Errors are not handled properly in inline text editing <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/415365 >
[18:44] <deryck> salgado, hey, let me look....
[18:47] <deryck> salgado, by fix, do you mean prevent the error, or do you mean cope with the error better?
[18:48] <salgado> deryck, just display the body of the http response when it's not a 200, I'd say
[18:49] <deryck> salgado, right.  so to do that, it should be fairly straightforward, making showError do the right thing, rather than inserting into the inline widget as it's trying to do now.
[18:49] <salgado> deryck, some of those widgets are used on fields that have validators (e.g. bug tags and the new blueprint work-item) so there will always be errors; we just need to display them
[18:51] <salgado> deryck, oh, so showError already has the error message from the response? I thought that's what we were missing and I'd have to get that
[18:52] <deryck> salgado, I think it has the error, and just not dealing with it well.
[18:52] <deryck> salgado, but it's been awhile since I touched that :)
[18:54] <salgado> deryck, yeah, and I'm completely clueless when it comes to YUI.  can I stick a "debug" call in there to inspect it in the browser?  I seem to recall doing something like that
[18:54] <deryck> salgado, yup.  add "debugger;" on the line you want to break on and firebug or chrome console with break there.
[18:54] <salgado> ah, debugger
[18:54] <salgado> cool, will try that
[18:54] <deryck> salgado, you can also open the file in those tools and manually click lines to add break points without editing code.
[18:57] <salgado> deryck, sounds more promising as it looks like I'd need to regenerate launchpad.js after changing showError in the code itself, no?
[18:57] <deryck> salgado, yes, you'd need to run make jsbuild again.
[19:03] <salgado> deryck, what's weird is that the validate() method uses showError (when the widget doesn't accept empty input) and in that case it works fine, correctly displaying the message passed to it
[19:04] <deryck> salgado, so maybe the message is getting dropped somehow?
[19:05] <salgado> deryck, nope, showError is being passed the body of the response
[19:15] <salgado> deryck, showError inserts the error on the correct place but since this is a multi-line field the text area appears on top of that
[19:18] <deryck> salgado, I'd have showError open an overlay, rather than try to insert into the page.
[19:18] <deryck> there's tons of error_overlay examples lying around
[19:18] <salgado> yeah, that makes sense; /me tries that
[19:24] <lifeless> james_w: you should show pkgme to gary_poster
[19:24] <james_w> lifeless, for use in something
[19:24]  * gary_poster googles pkgme
[19:24] <james_w> lifeless, or just to get some stuff packaged?
[19:25] <lifeless> james_w: I believe he is, or has, someone packaging up a new thing
[19:25] <lifeless> james_w: which is in python
[19:25] <lifeless> james_w: and so a prefect candidate
[19:25] <gary_poster> james_w, yes.  Very simple package, and bac is writing up descriptions on how to do it
[19:25] <james_w> gary_poster, a standard setup.py app?
[19:25] <gary_poster> yes james_w
[19:26] <james_w> it should work then
[19:26] <gary_poster> and bac found the existing packaging instructions worthy of simplifying and rewriting
[19:26] <james_w> that's a good thing to do anyway
[19:26] <gary_poster> cool
[19:26] <james_w> but pkgme may take the pain out of simple things entirely
[19:27] <gary_poster> thanks lifeless, james_w .  bac, http://pkgme.net/ fwiw
[19:27] <james_w> lp:pkgme
[19:27] <gary_poster> saw that too, but the instructions seemed nicer to link to :-)
[19:27] <lifeless> right, thats my good deed for the day, off to create havoc
[19:28] <gary_poster> heh
[19:31] <rick_h_> jcsackett: ping, can you peek at: https://code.launchpad.net/~rharding/launchpad/911857_extract_js/+merge/95438
[19:31] <rick_h_> sorry for the big add/remove due to tabbing in
[19:36] <jcsackett> sure, rick_h_.
[19:36] <rick_h_> jcsackett: ty
[19:48] <bac> thanks gary_poster and james_w
[19:50] <bac> gary_poster: it may be useful for the py part of charm-tools
[19:50] <gary_poster> bac, makes sense
[19:56] <bac> james_w: should pkgme work for precise?  there is no ppa and the description says only natty and oneiric
[19:57] <james_w> bac, yes it should
[19:57] <bac> great
[19:57] <james_w> bac, where do you see natty and oneiric?
[19:57] <james_w> I'll update it
[19:58] <bac> james_w: https://launchpad.net/~pkgme-committers/+archive/dev/+packages ... but now that i look closely that seems to be generated text
[19:58]  * james_w copies forward
[19:59] <james_w> done
[19:59] <james_w> yeah, the text is autogenerated, it has updated now
[20:03] <salgado> jcsackett, if you have a few more minutes, I've just proposed a new one. this time it's trivial: https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447
=== almaisan-away is now known as al-maisan
[20:12] <salgado> how do I run a test under lib/lp/app/javascript/tests/?
[20:12]  * salgado tries lading the html files on his browser
[20:12] <rick_h_> salgado: yep, that works for dev
[20:13] <rick_h_> and then you can load it with the test runner based on the filename
[20:13] <rick_h_> which test file are you running?
=== al-maisan is now known as almaisan-away
[20:13] <jcsackett> rick_h_: r=me.
[20:14] <rick_h_> jcsackett: ty
[20:14] <jcsackett> salgado: can you include a screenshot, since this is changing some of what's displayed on error?
[20:17] <salgado> jcsackett, sure, https://bugs.launchpad.net/launchpad/+bug/415365/+attachment/2798570/+files/overlay-error.png
[20:17] <_mup_> Bug #415365: Errors are not handled properly in inline multi-line text editing <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/415365 >
[20:18] <salgado> rick_h_, inlineedit/tests/test_inline_edit.js (adding a test for the bug above)
[20:18] <rick_h_> salgado: yea, so ./bin/test -x -cvvt inline_edit would run those tests
[20:19] <salgado> rick_h_, nice, I'd never have expected that to work
[20:19] <rick_h_> salgado: but yea, I'd just run from the browser usually in dev and the cmd line just to make sure things are cool from the html5 browser
[20:19] <rick_h_> autoreload makes the browser version nice
=== matsubara is now known as matsubara-afk
[20:30] <rick_h_> salgado: replied to your MP
[20:30] <rick_h_> let me know if it doesn't make any sense
[20:31] <salgado> rick_h_, heh, just found that out myself; one of the tests was failing :)
[20:31] <salgado> I added lp.app.errors but that wasn't enough
[20:31] <rick_h_> salgado: yep, figured you were onto that when you asked about running tests
[20:31] <rick_h_> right, errors requires someoverlay modules
[20:32] <rick_h_> make sure you link to them out of the build directory like the others pls
[20:36] <bac> hi james_w, i've grabbed the trunk of pkgme and installed it with setup.py.  attempting to run errors due to non-execute bits on all of the 'wants'.  i manually chmod all of them but get a different error.  did i do something fundamentally wrong?
=== jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10
=== rick_h_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10
[20:38] <rick_h_> salgado: running away, but ping me if you hit any issues and I'll be checking in later
[20:38] <salgado> rick_h_, link to what?
[20:38] <james_w> bac, nope
[20:38] <rick_h_> salgado: ok, just that the html files links should be like the current ones, through build/...
[20:38] <james_w> bac, the executability thing is a known problem with distutils
[20:39] <james_w> bac, what's the other error you got?
[20:39] <rick_h_> salgado: such as <script type="text/javascript" src="../../../../../../build/js/lp/app/formoverlay/formoverlay.js"></script>
[20:39] <salgado> oh, I see
[20:39] <bac> james_w: vala backend returning non-integer
[20:39] <james_w> bac, hmm, odd
[20:39] <salgado> rick_h_, let me double check, but I guess it'd fail if I had it wrong (I copied from another test.html file)
[20:39] <james_w> bac, did it say what it did return?
[20:40] <rick_h_> salgado: you should be good then if you copied since I updated them all recently
[20:40] <salgado> rick_h_, yep, it looks just like the others in that template :)
[20:40] <rick_h_> salgado: coolio
[20:41] <bac> james_w, wait that seems to be another permission problem with with auto_conf_config
[20:42] <bac> james_w, i'll go forward fixing the execute privileges
[20:42] <james_w> bac, ah, helpers/* will need to be +x too
[20:42] <bac> ok
[20:44] <rick_h_> deryck: jcsackett had to run, can you second my ok on this please? https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447
[20:46] <deryck> rick_h_, done.
[20:46] <rick_h_> ty
[20:46] <salgado> I'm trying to run js tests inside an lxc and am getting "RuntimeError: Gtk couldn't be initialized".  any ideas what I'm missing?
[20:49] <rick_h_> salgado: http://bazaar.launchpad.net/~sinzui/html5-browser/trunk/view/head:/README installed?
[20:49] <salgado> rick_h_, I think I do; I get that when import html5browser
[20:49] <rick_h_> ok
[20:50] <rick_h_> so most of these things need  xvfb  but not sure why you'd get a gtk issue
[20:50] <rick_h_> sinzui: any ideas? ^
[20:50] <rick_h_> salgado: have a traceback to paste perhaps?
[20:51] <salgado> this is what actually happens when the test imports html5browser: http://paste.ubuntu.com/864114/
[20:51] <lifeless> folk who would like a nicer deploy report should check out lp:~james-w/+junk/deploy-tracker
[20:52] <salgado> rick_h_, seems to work with xvfb-run
[20:53] <lifeless> http://ec2-23-20-113-165.compute-1.amazonaws.com/ - turn on 'team info' during SSO handshaking
[20:56] <sinzui> salgado, that looks like the wrong screen.
[20:57] <sinzui> salgado, does html5browser work when run from a console on out owne machine?
[20:57]  * sinzui should have added the show_browser option so we could see it run
[20:58] <salgado> sinzui, I tried 'bin/test -t inline_edit' inside a container and it failed with that traceback when html5browser tried to import Gtk.  running with xvfb-run worked
[20:58] <salgado> I don't have html5browser installed on my machine; only on that container where I run LP
[20:59] <sinzui> salgado, okay. This is a bit out of my realm of confidence
[20:59] <sinzui> salgado, Is this lucid, oneiric or precise in the container
[20:59] <salgado> sinzui, oneiric
[21:00] <sinzui> okay, that is the version I wrote first and actually expect to work
[21:04] <sinzui> salgado, the official answer is that Gtk cannot find the display. If you always run in a container you may need to pass the display in the env. Maybe we need to smarten up our test script to warn if there is no display set
[21:04] <salgado> rick_h_, would you mind landing https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447 for me as well? :)
[21:07] <sinzui> I think html5browser should catch the check error and explain the display it thinks it has.
[21:08] <salgado> sinzui, indeed, with the DISPLAY set it works
[21:12] <sinzui> salgado, I reported Bug #944348 about this
[21:12] <_mup_> Bug #944348: warn when display is not set. <HTML5-browser:Triaged> < https://launchpad.net/bugs/944348 >
[21:14] <salgado> sinzui, nice, thanks!
[21:16] <rick_h_> salgado: ok, working on getting landing going
[21:23] <salgado> rick_h_, great, thanks again :)
[21:24] <rick_h_> salgado: np
[21:37] <abentley> deryck: There's no OCR.  Would you be able to review https://code.launchpad.net/~abentley/lp-dev-utils/ec2/+merge/95468 ?
[21:37] <deryck> abentley, sure.
[21:38] <abentley> deryck: thanks.
=== salgado is now known as salgado-afk
[21:42] <deryck> abentley, that's alot of python. :)  Is it all straight cut over from lp tree, except for the change about commit tags in MPs?
[21:44] <abentley> deryck: Here are the changes I made: http://pastebin.ubuntu.com/864191/
[21:44] <deryck> abentley, ah, that's very helpful thanks.
[21:45] <abentley> deryck: Mostly it's import name changes, but there are some minor tweaks.
[21:49] <deryck> abentley, looks fine.  And we know it works. :)  r=me
[21:51] <abentley> deryck: thanks!
[21:52] <lifeless> abentley: btw the location of trunk has changed
[21:52] <lifeless> abentley: its now lp:~canonical-launchpad-branches/lp-dev-utils/trunk (if you aren't using hte lp:lp-dev-utils alias)
[21:52] <abentley> lifeless: I used lp:lp-dev-utils
[21:58] <mtaylor> lifeless: hey! is it worth filing a ticket about slowness of mailing list messages?
[21:59] <lifeless> no
[21:59] <lifeless> we like it slow
[21:59] <mtaylor> awesome
[21:59] <lifeless> mtaylor: actually, there is one I think, and its a well known issue
[21:59] <lifeless> mtaylor: I can point you at the discussion on the -dev list if you like
[21:59] <lifeless> we're || close to a solution
[22:00] <mtaylor> I'll just take your word for it that you're aware and have it almost fixed
[22:00] <mtaylor> as you rarely lead me astray
[22:00] <lifeless> quadratic archive page writes
[22:00] <lifeless> sinzui has a grackle.
[22:00] <mtaylor> jeez
[22:00] <bigjools> has he seen a doctor?
[22:00] <mtaylor> that doesn't sound good
[22:01] <sinzui> I have not, but having spent about 9 hours out of my skull I think I might
[22:01] <sinzui> I still fear that If I yawn, the a hole in the universe will open and I will fall though it again
[22:02] <deryck> Later on, everyone.
[22:02] <sinzui> mtaylor, There is a specific critical bug that is the causes of slowness. I speculated about how to address the immediate concern
[22:04] <mtaylor> sinzui: awesome
[22:04] <sinzui> mtaylor, lifeless, wgrant: I think this bug needs fixing: bug #942305 right away
[22:04] <_mup_> Bug #942305: forster is load spiking due to LP mailman integration <canonical-losa-lp> <mailing-lists> <Launchpad itself:Triaged> < https://launchpad.net/bugs/942305 >
[22:05] <sinzui> I have an idea in it that need validation
[22:10] <lifeless> looking
[22:10] <mtaylor> sinzui: looking as well - as is jeblair
[22:10] <lifeless> sinzui: which lists are key?
[22:11] <sinzui> ubuntu-x-swat is the leading cause
[22:11] <wgrant> It was a few months ago, at least.
[22:11] <wgrant> By a significant margin.
[22:12] <wgrant> Similar to the way we don't generate ubuntu-bugs@lists.u.c HTML archives.
[22:12] <sinzui> we can look at the messages in the arch queue to see which are the pathological lists
[22:14] <wgrant> lifeless: Heh, slony takes 80%+? Try 98-99.5%
[22:14] <lifeless> wgrant: understate overdeliver
=== wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 4*10