| poolie | o/ huwshimi, lifeless | 00:17 |
|---|---|---|
| huwshimi | poolie: Hey | 00:17 |
| lifeless | hi y'all | 00:31 |
| wgrant | Hmmm. | 00:50 |
| StevenK | wgrant: Your description for fix-patch-number is a little harsh :-) | 00:57 |
| poolie | does anyone know if curl checks ssl certs by default? | 00:58 |
| spiv | I think so, hence various bzr bugs where the workaround was "use https+urllib" | 00:59 |
| poolie | to not verify it? | 00:59 |
| spiv | Right | 00:59 |
| poolie | oh, this is because we didn't depend on the ca-certs packgae | 01:00 |
| poolie | ok | 01:00 |
| wgrant | StevenK: Hardly! | 01:02 |
| lifeless | wooo, death to stories | 01:14 |
| LPCIBot | Project db-devel build #707: STILL FAILING in 4 hr 4 min: https://lpci.wedontsleep.org/job/db-devel/707/ | 01:23 |
| mwhudson | lifeless: \o/ | 01:25 |
| jtv | wallyworld_: I'm in Europe, so won't be much good to you today! | 01:38 |
| wallyworld_ | jtv: np. there's no reviews yet anyway | 01:39 |
| jtv | Not sure that's good news, but I'll take it. :) | 01:39 |
| lifeless | mwhudson: yeah, bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/storylayers is landing | 01:47 |
| lifeless | 70 files changed, 4513 insertions(+), 4618 deletions(-) | 01:47 |
| mwhudson | lifeless: i guess this doesn't rip out the story infrastructure? | 01:48 |
| lifeless | yeah, it goes | 01:48 |
| mwhudson | ah cool | 01:48 |
| lifeless | the function that walks a directory and makes the suite stays | 01:48 |
| lifeless | but its just DocFileSuites now | 01:48 |
| mwhudson | and the cruft in the databaselayer that sometimes doesn't reset the db? | 01:49 |
| lifeless | thats where I started | 01:52 |
| lifeless | https://code.launchpad.net/~lifeless/launchpad/storylayers/+merge/66738 | 01:52 |
| lifeless | the tests for that cruft were not parallel safe | 01:52 |
| lifeless | and I was making parallel testing more reliable | 01:53 |
| mwhudson | ahh | 01:53 |
| mwhudson | hooray | 01:53 |
| * wgrant lunches. | 02:05 | |
| LPCIBot | Project devel build #872: STILL FAILING in 3 hr 54 min: https://lpci.wedontsleep.org/job/devel/872/ | 02:07 |
| wgrant | StevenK: Your conflict resolution failed. | 04:55 |
| wgrant | bug-tags.txt failed. | 04:55 |
| StevenK | Damn | 04:56 |
| StevenK | wgrant: Having a poke at it | 04:58 |
| wgrant | StevenK: Thanks. | 04:58 |
| StevenK | wgrant: When does staging need a swift kick? | 04:58 |
| wgrant | StevenK: Once the rev after yours passes buildbot. | 04:59 |
| wgrant | Well. | 04:59 |
| wgrant | I guess we could do it now. | 04:59 |
| StevenK | It's adding back id and deleting one row from LDR, right? | 04:59 |
| wgrant | UPDATe launchpaddatabaserevision SET minor=77 WHERE major=2208 AND minor=99 AND patch=0; | 05:00 |
| StevenK | Or that, yes | 05:01 |
| StevenK | And there is the failure mail | 05:03 |
| wgrant | Yup. | 05:03 |
| wgrant | Just that one failure. | 05:03 |
| * StevenK is waiting for make | 05:04 | |
| StevenK | So I can run it again | 05:04 |
| StevenK | wgrant: One line fix :-/ | 05:17 |
| StevenK | Not sure why bzr merge didn't pick it up | 05:17 |
| * wgrant seeks opinions. | 05:21 | |
| * StevenK submits it to PQM anyway | 05:22 | |
| wgrant | Should I put the reset code in rabbitfixture itself? If so, do I make it mandatory? It depends on an unpackaged plugin. | 05:23 |
| wgrant | Test isolation without it is very slow. | 05:23 |
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv) | Critical bugs: 210 - 0:[######=_]:256 | ||
| wgrant | lifeless: Opinions? | 05:29 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | slow is bad | 05:49 |
| lifeless | other things will want rabid fixtures | 05:49 |
| StevenK | Rabid or rapid? | 05:49 |
| lifeless | both! | 05:53 |
| wgrant | Grar | 05:56 |
| wgrant | LP needs custom suites. | 05:56 |
| StevenK | Hm. I don't think I can change the vocab using a feature flag :-( | 06:11 |
| wgrant | You would have to override it in the view. | 06:13 |
| StevenK | How? | 06:17 |
| StevenK | From what I can see +distrotask (for example) uses BugAlsoAffectsDistroMetaView which is *tiny* | 06:17 |
| wgrant | Right, but you can probably do stuff in setUpWidgets. | 06:19 |
| wgrant | Override the defaults. | 06:19 |
| * spiv wonders how hard it would be to write some js goop to automatically add tooltips to every 'bug NNNN' link on every page, to show the bug title. | 06:21 | |
| lifeless | theres a bug for that :) | 06:23 |
| === al-maisan is now known as almaisan-away | ||
| StevenK | wgrant: BugAlsoAffectsDistroMetaView is a MultiStepView and it doesn't seem to call setUpWidgets at all | 06:38 |
| wgrant | It's not a LaunchpadFormView at all? | 06:40 |
| StevenK | The only thing in bugalsoaffects that uses LFV is BugAlsoAffectsProductWithProductCreationView | 06:41 |
| wgrant | Directly. | 06:41 |
| StevenK | Right | 06:42 |
| wgrant | lifeless: You never gave a real opinion on which version of rabbit we should target. Do you have one? | 06:43 |
| wallyworld_ | spiv: should be easy since there's code to parse bug nnnn and linkify it using an XHR call. the title would just need to be added to the json data sent back from the server | 06:43 |
| wgrant | (2.2.0 is in CAT, but not in any Ubuntu release, so ew) | 06:43 |
| lifeless | wgrant: easiest meeting all the constraints | 06:44 |
| lifeless | wgrant: that *is* my opinion. | 06:44 |
| wgrant | :( | 06:45 |
| wgrant | My preferred option is to go with the latest stable Ubuntu release, 2.3.1. Trivial to put it in lucid-cat-lp. And it has not historically been a high-maintenance package, so shouldn't be a problem if LS wants to stay on 2.2.0 forever. | 06:47 |
| lifeless | I bet ls will upgrade happily | 06:47 |
| wgrant | Hopefully. | 06:51 |
| spiv | wallyworld_: tempting! I'm trying to resist the urge to grow my todo list rather than shrink it though… | 07:09 |
| lifeless | wgrant: ls would be happy to upgrade | 07:13 |
| nigelb | spiv: I remember that bug. But I doubt if there's a lookup now. Adding that lookup was deemed more expensive the last time I asked. | 07:15 |
| nigelb | Because, theoretically a page could be slowed down by having a lot of bug numbers | 07:16 |
| wgrant | It's fairly cheap to do it by AJAX afterwards. | 07:16 |
| wgrant | It's expensive to do it during page rendering serverside, due to the way the nested views work. | 07:16 |
| nigelb | In that case, if the solution is easy - moderate and someone can mentor, I might be interested in picking it up | 07:17 |
| spiv | The main thing I'd worry about is making sure the calls are reasonably batched; I don't think one AJAX call per bug link would be great. | 07:19 |
| wgrant | Sure. We'd need to introduce a new API call to get details of a set of bugs. | 07:19 |
| spiv | But if it were one for all the links present at domready time, then maybe a couple more as other ajax things add more to the page, I think that'd be fine. | 07:20 |
| lifeless | note that this is then less efficient than supplying the data when we ender | 07:20 |
| lifeless | *render* | 07:20 |
| spiv | Yeah. | 07:20 |
| lifeless | we already look up the bugs | 07:20 |
| nigelb | BUt we also linkify nonexistent bugs | 07:20 |
| lifeless | to decide to linkify or not | 07:20 |
| nigelb | I thought that was because we don't look up | 07:20 |
| spiv | lifeless: even for e.g. merge proposal comments? | 07:20 |
| wgrant | lifeless: I don't think we do any more. | 07:21 |
| lifeless | hmm, I may be out of date | 07:21 |
| lifeless | spiv: theres a cluster of bugs around this | 07:21 |
| wgrant | We used to display titles in tooltips. | 07:21 |
| wgrant | But it was killed for being too slow. | 07:21 |
| lifeless | yah | 07:21 |
| spiv | nigelb: so, wallyworld_ reckons it should be easy… maybe he'd be willing to mentor? :) | 07:22 |
| wallyworld_ | spiv: nigelb: of course, no problem | 07:22 |
| spiv | Sweet! | 07:23 |
| spiv | Looking forward to it already ;) | 07:23 |
| nigelb | \o/ | 07:23 |
| wallyworld_ | ping me when you want to start work on it and i can provide some pointers | 07:23 |
| nigelb | Hopefully, Monday. | 07:23 |
| wallyworld_ | np. i wrote the code to do the linkification via the XHR call so I can tell you where to hook stuff up. any performance issue will be separate to that and will need to be considered of course | 07:24 |
| wallyworld_ | spiv: just been reading the backlog - from memory there's only one XHR call to return details for all the bugs on a page so it should come together nicely | 07:27 |
| nigelb | this particular bug has been a long term itch of mine, just didn't know there was a way to fix it without affecting performanc | 07:27 |
| nigelb | +e | 07:27 |
| wallyworld_ | nigelb: out of curiousity, how long standing? the linkification via XHR call was only put in about 6 months ago | 07:28 |
| nigelb | wallyworld_: Its from the old days of doing this server side | 07:29 |
| wallyworld_ | ugh | 07:30 |
| lifeless | and its landed \o/ | 07:41 |
| lifeless | a fitting time to end the week | 07:41 |
| === mrevell-lunch is now known as mrevell | ||
| adeuring | good morning | 08:12 |
| LPCIBot | Project db-devel build #708: STILL FAILING in 5 hr 57 min: https://lpci.wedontsleep.org/job/db-devel/708/ | 08:13 |
| LPCIBot | Yippie, build fixed! | 08:30 |
| LPCIBot | Project devel build #873: FIXED in 6 hr 2 min: https://lpci.wedontsleep.org/job/devel/873/ | 08:30 |
| === almaisan-away is now known as al-maisan | ||
| === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv), adeuring | Critical bugs: 210 - 0:[######=_]:256 | ||
| jtv | Anyone else seeing JS test failures that happen _only_ on the command line, _not_ in the browser? http://paste.ubuntu.com/639998/ | 09:04 |
| jtv | It sounds like a test isolation problem. | 09:04 |
| jtv | But when I comment out a different test testMultiple, which consists of just a single assertion, it passes. | 09:04 |
| rvba | jtv: which branch? | 09:04 |
| * jtv digs | 09:04 | |
| danilos | allenap, hi, did you see my reply for the review? :) | 09:05 |
| jtv | I haven't pushed it. Let me just do that. | 09:05 |
| bigjools | Gavin is off today | 09:05 |
| rvba | danilos: allenap is off today. | 09:05 |
| jtv | he knows :) | 09:06 |
| jtv | rvba: just pushed to lp:~jtv/launchpad/bug-806946 | 09:06 |
| jtv | Still waiting to be scanned… | 09:07 |
| jtv | danilos: do we have foldable branch revisions yet? It'd be really helpful at this point. :) | 09:07 |
| danilos | I didn't | 09:08 |
| danilos | jtv, nope, expander-anim is still in review :/ | 09:08 |
| danilos | jtv, as is spiv's branch the last I heard of it (it was, yesterday) | 09:08 |
| jtv | Goes to show how much better this will make the world. | 09:08 |
| danilos | adeuring, wallyworld_: anyone want to take on the review of https://code.launchpad.net/~danilo/launchpad/expander-anim/+merge/67161 now that Gavin is off? | 09:09 |
| wallyworld_ | danilos: i'll grab it but someone else will need to +1 | 09:09 |
| danilos | wallyworld_, right, thanks, hopefully jtv or adeuring will do that :) | 09:10 |
| jtv | wallyworld_: my job I think :) | 09:10 |
| wallyworld_ | jtv: hey, you're there | 09:11 |
| jtv | More amazingly, you're still here. :) | 09:11 |
| wallyworld_ | jtv: yeah, i should have eod but am tidying up some failing tests in a branch i really want to get landed | 09:12 |
| * jtv knows the feeling | 09:12 | |
| wallyworld_ | danilos: so is gavin not around today? | 09:12 |
| jtv | Nope | 09:13 |
| jtv | Well, shouldn't be. | 09:13 |
| wallyworld_ | bollocks. i was going to ask him to +1 on a mp. he did the prerequisite one yesterday | 09:13 |
| bigjools | wallyworld_: ! | 09:13 |
| bigjools | I need your halp with this pycharm thing | 09:13 |
| wallyworld_ | bigjools: no cricket today :-( | 09:14 |
| bigjools | ! | 09:14 |
| wallyworld_ | bigjools: give me a bit of time to clean up some stuff, i'll ping you | 09:14 |
| bigjools | ok ta | 09:14 |
| wallyworld_ | jtv: could you possibly +1 this mp for me. it looks big but its a lot of moving code around in yui tests more than anything else | 09:15 |
| wallyworld_ | https://code.launchpad.net/~wallyworld/launchpad/yui-test-cleanup-807294/+merge/67281 | 09:15 |
| * jtv looks | 09:15 | |
| wallyworld_ | thanks | 09:15 |
| jtv | Oh what the !? | 09:15 |
| wallyworld_ | when landed, our yui tests will be a lot better and all lazr-js stuff will be integrated | 09:15 |
| wallyworld_ | jtv: it's not as bad as it looks - a lot of code deletion | 09:16 |
| wallyworld_ | and it's only in the tests | 09:16 |
| jtv | rvba: that breaking JS test passes for me when I run it with "lp.registry -t javascript" instead of "lp.registry -t test_distroseries." | 09:16 |
| jtv | (Sorry about that — on to the MP now) | 09:16 |
| jtv | wallyworld_: actually, I may have been running into the exact race that you've been fixing. | 09:18 |
| wallyworld_ | with the test_distroseries test? | 09:18 |
| jtv | Yup. | 09:19 |
| jtv | And by the way, did you raise hell about the long-poll test that isn't being run? | 09:20 |
| jtv | File a bug? | 09:20 |
| jtv | wallyworld_: ^ | 09:24 |
| wallyworld_ | jtv: i will speak to wgrant or bigjools about the long poll stuff. we need to move the javascript to the "standard" place or change the find_test rules | 09:25 |
| jtv | Also, I'm surprised that the Y.on('domready', run_me) that you're cleaning up worked. I'd imagine that event would already have fired by the time that executed. | 09:25 |
| jtv | wallyworld_: especially if the long poll will take time, make sure it isn't forgotten when a high-priority job comes along. Better file a bug. | 09:26 |
| jtv | I wonder if "the tests are never run" qualify as Critical. | 09:26 |
| wallyworld_ | jtv: with the domready event, i more or less cargo culted the old lazr-js implementation | 09:26 |
| jtv | Well, the whole thing looks tons better now. | 09:27 |
| wallyworld_ | jtv: i checked that it works by hand, but.... | 09:27 |
| wallyworld_ | yeah, easier to write tests, waaaaaay less cut'n'paste | 09:27 |
| wallyworld_ | i will file a bug about the long poll test too | 09:27 |
| jtv | Great | 09:28 |
| jtv | I'm not sure the bit about lock, stock, and barrels still makes sense now that lock, stock & barrel are no longer pasted everywhere. | 09:29 |
| jtv | Another thing that really excites me to bits is that this should open the door to log divs that, *gasp*, would be wide enough to read. | 09:30 |
| jtv | Or is that not the "log" div? The one that the green/red markers appear in. | 09:32 |
| wallyworld_ | jtv: bug 807426. i've marked as critical since i agree that tests not running is bad | 09:34 |
| _mup_ | Bug #807426: Long poll yui tests not run automatically <Launchpad itself:Triaged> < https://launchpad.net/bugs/807426 > | 09:34 |
| jtv | Thanks. | 09:35 |
| wallyworld_ | jtv: the log is sent to *both* the browser console and the log div, so it is really *very* readable now | 09:35 |
| wallyworld_ | the lock, stock thing is from curtis so i am loath to remove it :-) | 09:36 |
| jtv | I think it's specifically about the situation you rectified though. | 09:38 |
| jtv | By the way, we're supposed to have clear criteria to say whether a bug is critical. | 09:39 |
| jtv | I'll just submit my MP vote and then I'll look into it. | 09:39 |
| rvba | wallyworld_: I had to modify the way the Makefile finds js files to include the js long poll stuff ... so I suppose we should do the same for the tests to be found and modify "find_yui_tests" ... | 09:40 |
| jtv | https://dev.launchpad.net/BugTriage#Critical | 09:41 |
| wallyworld_ | rvba: yes. the method to change is build_yui_unittest_suite. or you could move the location of the javascript. but if you change the build_yui_unittest_suite, try and keep it generic so that other new code that puts javascript elsewhere can also work | 09:42 |
| wgrant | wallyworld_: rvba is more relevant for the JS stuff. | 09:43 |
| wgrant | I only know it from a little while struggling with a French keyboard. | 09:43 |
| rvba | wgrant: ;) | 09:44 |
| wallyworld_ | we need to decide our packaging methodology. is it lib/lp/<silo>/javascript/<vertical> (like it is now) or lib/<silo>/<vertical>/javascript | 09:44 |
| wallyworld_ | there's arguments for and against both | 09:45 |
| wallyworld_ | even though lp uses the former almost exclusively, i prefer the latter (like longpoll has done) | 09:46 |
| wallyworld_ | it keeps everything related together better | 09:46 |
| rvba | wallyworld_: +1 | 09:49 |
| poolie | o/ wallyworld_ | 09:50 |
| wallyworld_ | hi poolie | 09:51 |
| rvba | wallyworld_: what is the outcome of Dublin's big javascript reorg? | 09:54 |
| wgrant | wallyworld_: IMO the latter is better. | 09:54 |
| wgrant | wallyworld_: But we need to be aggressively factoring out non-specific stuff. | 09:54 |
| wallyworld_ | rvba: the main branch to do the reorg has landed. i've just got the one to clean up the tests approved | 09:55 |
| rvba | wallyworld_: Great! I'll check them out then :) | 09:56 |
| wallyworld_ | jtv: thanks for the review. with the tests, i'm confident that fixing increasing that timeout will ensure the tests pass ok, so my comments in the mp may be a little too pesimistic | 09:57 |
| wallyworld_ | rvba: the upcoming branch will cut large chunks of code from the yui tests. but the main refactoring has landed | 09:58 |
| === al-maisan is now known as almaisan-away | ||
| rvba | jtv: have you figured out your js problem? | 10:12 |
| wallyworld_ | danilos: this new expander is the one to replace all the other older implementations? | 10:17 |
| rvba | wallyworld_: maybe this has been discussed earlier but did you do something to address the intermittent test_distroseries.html.TestDeriveDistroSeriesActionsWidget.testSuccess issue? | 10:20 |
| === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 210 - 0:[######=_]:256 | ||
| wallyworld_ | rvba: yes. i increased the wait timeout to 90ms (from 30ms). i seems to have fixed it for me. it could even be set a bit higher but let's see if 90 works for everyone | 10:23 |
| rvba | wallyworld_: ok ... it would be nice if we could come out with a proper strategy to test things like this (things with an animation) ... maybe the code should fire an event when the animation is done and then tests could perform verifications only when the event is fired. | 10:25 |
| rvba | I think this wasted too much of your time for a simple animation :) | 10:25 |
| wallyworld_ | rvba: yes, that sort of strategy is better. i just wanted to do the minimum to get the test passing since it was not the focus of my branch | 10:25 |
| rvba | wallyworld_: sure, I get it. | 10:26 |
| wallyworld_ | and the current implementation used a wait() | 10:26 |
| danilos | wallyworld_,yep | 10:42 |
| danilos | wallyworld_, few other branches with it have already been reviewed and are waiting for the animation to land | 10:43 |
| lifeless | gmb: hi | 11:02 |
| lifeless | gmb: I'll look more closely on monday | 11:02 |
| lifeless | but | 11:02 |
| lifeless | + if linked_branches.is_empty(): | 11:02 |
| lifeless | + return EmptyResultSet() | 11:02 |
| lifeless | isn't needed | 11:03 |
| lifeless | is it? | 11:03 |
| danilos | jtv, could you ok the wallyworld_'s review on https://code.launchpad.net/~danilo/launchpad/expander-anim/+merge/67161 please? (if you agree, of course :) | 11:03 |
| lifeless | gmb: if it is needed, you should listify: is_empty performs a query, as does __iter__ | 11:03 |
| lifeless | gmb: so you're querying the same thing twice | 11:03 |
| lifeless | as for whether you need to eager load, I suspect that you'll need to test - check the query counter on the templates that trigger foo.linked_branches, and see if it changes when you toggle eager loading on/off | 11:04 |
| lifeless | gmb: (and you have 3 or 4 linked branches, maybe one private, that sort of thing. | 11:05 |
| lifeless | gmb: I suspect you don't need it as the callers will be eager loading themselves, but IMBW | 11:05 |
| gmb | lifeless: Ah, good point re the is_empty. It's only needed because the store.find() blows up if you pass it an empty list of branch IDs. | 11:12 |
| gmb | So I'll listify early. | 11:13 |
| gmb | And yes, I'll play with the query counter and see what comes out. Thanks. | 11:13 |
| gmb | Anyway, tengo hambre. | 11:15 |
| * gmb -> lunch | 11:15 | |
| jtv | danilos: was having lunch, coming now | 11:21 |
| jtv | danilos: does JS have different relative priorities between the ?: and = operators compared to C? In C, "cfg.from = cfg.from ? cfg.from : {}" would evaluate as "(cfg.from = cfg.from) ? cfg.from : {}" | 11:23 |
| danilos | jtv, that's all copy-pasted from the old slide-out/in animations, I haven't questioned its sanity | 11:26 |
| jtv | always a big mistake :) | 11:26 |
| danilos | jtv, fwiw, we might want to drop that altogether if we don't care about users being able to set starting/ending points up front | 11:26 |
| jtv | danilos: at any rate, I'm afraid I won't have time to go through all this today. :( | 11:27 |
| danilos | jtv, that sucks because branch is getting pushed around, and I might just as well land it then because I had two reviewers on it already :/ | 11:27 |
| danilos | jtv, I'll find a different reviewer then, thanks | 11:28 |
| danilos | adeuring, hi, I need you so much :) | 11:28 |
| jtv | Very sorry; bad timing. | 11:28 |
| danilos | adeuring, can you perhaps ok wallyworld_'s * review at https://code.launchpad.net/~danilo/launchpad/expander-anim/+merge/67161? | 11:29 |
| danilos | adeuring, I've also got https://code.launchpad.net/~danilo/launchpad/replace-expanders-2/+merge/67314 up for a full review :) | 11:32 |
| === jtv is now known as jtv-away | ||
| adeuring | danilos: sure | 11:40 |
| adeuring | (sorry for the delay; had lunch) | 11:40 |
| danilos | adeuring, cool, thanks | 11:41 |
| danilos | adeuring, fwiw, if you haven't started yet, I'd prefer getting a review for expander-anim branch first, because that one is a prerequisite for another 3 of mine branches, and for spiv's branch as well | 12:04 |
| === matsubara-afk is now known as matsubara | ||
| adeuring | danilos: r=me on the animation branch. great work! | 12:21 |
| danilos | adeuring, yaay, thanks | 12:22 |
| === matsubara is now known as matsubara-afk | ||
| adeuring | danilos: your other branch looks also good, but there is one issue: On the +filebug page, I see the behaviour: for the first "expand" click on an item, the expand animation runs ... and then the collapse animation runs. On a second click, only the expand animation runs. And if you try one expand click on collapsed item A, then try another expand click on item B, then then click again on item A, you still get "expand/close" animation | 13:00 |
| danilos | adeuring, sounds pretty weird, what browser is that? (so I can try to reproduce) | 13:01 |
| adeuring | danilos: firefox 5.0 (natty) | 13:01 |
| adeuring | monring deryck | 13:02 |
| deryck | morning, adeuring | 13:02 |
| danilos | adeuring, can you try the same thing in a webkit browser (epiphany, chromium) to see if it happens there as well (while I start up firefox and get the proper branch running :) | 13:02 |
| adeuring | danilos: just tried epiphany -- same behaviour | 13:03 |
| danilos | adeuring, hum, very weird | 13:03 |
| danilos | well, tbh, I did merge with the latest stable and haven't tried it with that, and now I have to run make schema as well (are we letting them on stable already, or did we merge db-stable back into stable already) | 13:04 |
| wgrant | danilos: Some patches can be run live nowadays. | 13:05 |
| wgrant | So we put them in devel. | 13:05 |
| wgrant | https://dev.launchpad.net/Database/LivePatching | 13:06 |
| danilos | adeuring, ok, I still can't reproduce this behaviour | 13:06 |
| adeuring | danilos: so... what shall we do? | 13:06 |
| danilos | wgrant, oh, cool (we could run some patches live in the past as well, but we did it in a very manual way :)) | 13:06 |
| danilos | adeuring, can you look at the console to see if there are any problems being reported perhaps? | 13:06 |
| wgrant | danilos: Right. It's still pretty manual now, but at least they get landed in the tree properly. | 13:06 |
| wgrant | danilos: One day we will automate it. | 13:06 |
| danilos | wgrant, cool, sounds nice (and it also means that the pqm constraint is removed stopping DB patches getting to devel) | 13:07 |
| danilos | wgrant, it might make development a bit more annoying with more frequent 'make schema' steps | 13:07 |
| jcsackett | morning, all. | 13:07 |
| wgrant | danilos: Well, we should probably have a script to run upgrade.py over everything quickly. | 13:08 |
| wgrant | launchpad_dev_template, launchpad_dev, launchpad_ftest_template, launchpad_ftest_playground should do, I guess. | 13:08 |
| danilos | wgrant, I found upgrade.py to be very off-and-on for development systems | 13:08 |
| spiv | danilos: I'm not really here atm, but I love the commit message on expander-anim | 13:08 |
| danilos | spiv, heh, thanks :) | 13:08 |
| wgrant | danilos: But make schema is much faster these days. | 13:08 |
| wgrant | danilos: So it's not *that* bad. | 13:08 |
| danilos | wgrant, indeed it is | 13:08 |
| adeuring | danilos: the only messages I see are: "yui: NOT loaded: lp.app.longpoll" and "Y.lp.app.longpoll is undefined Y.lp.app.longpoll.setupLongPollManager(); " | 13:09 |
| danilos | adeuring, can you perhaps re-run 'make jsbuild' or something along the lines (though that should have happened anyway) | 13:10 |
| adeuring | sure | 13:10 |
| adeuring | danilos: no change... | 13:12 |
| wgrant | May be worth a make clean_js as well. | 13:12 |
| danilos | adeuring, oh, indeed, wgrant has a point considering this also does some fixing to the newly integrated lazr JS inside the tree | 13:13 |
| wgrant | Considering what has been done to the JS build system in the last week, I think it's worth a try. | 13:13 |
| adeuring | danilos: I did not follow your conversation.... make schema?? | 13:14 |
| adeuring | gaa make clean_js | 13:15 |
| danilos | adeuring, right :) | 13:15 |
| adeuring | just a second... | 13:15 |
| adeuring | danilos: no change. | 13:17 |
| adeuring | danilos: but one more detail: | 13:17 |
| adeuring | danilos: (1) click "expand" on a collapsed item -> expand/collapse runs (2) click into any other desktop window (3) click on the _title bar_ of firefox -> the collapsed item opens. | 13:18 |
| adeuring | danilos: same behaviour with epiphany | 13:19 |
| danilos | adeuring, hum, this sounds very weird and considering this code had some funny stuff even before, can you try out the clean "stable" tree and see how it behaves there? | 13:20 |
| adeuring | danilos: sure | 13:20 |
| danilos | adeuring, thanks a lot and sorry for the trouble with this | 13:20 |
| danilos | adeuring, the existing code has an event handler for the focus event so it expands when it's focused even without a click, and also some code to stop propagation of click events for different parts of the item as well, and I haven't really touched that | 13:21 |
| danilos | adeuring, so I am worried that it'd be hard to debug this but we can at least establish if it's the new code or the old code | 13:21 |
| gary_poster | deryck, hey, are you going to reply to jml's question about thunderdome status? I ask both because I could help with it if you wanted, and because I want to know how your changes are going :-) | 13:22 |
| deryck | gary_poster, yeah, I was going to reply. | 13:25 |
| gary_poster | cool, I look forward to it deryck :-) | 13:25 |
| deryck | cool :) | 13:25 |
| adeuring | danilos: the expander behaves "normally" on stable | 13:30 |
| adeuring | danilos: one more details: The "expand/collapse" show runs only for a click on the green link text. Clicks onto the xepander icon or onto the text line "New (0 commentnts) cause a regular expansion | 13:36 |
| LPCIBot | Project db-devel build #709: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/709/ | 13:51 |
| danilos | adeuring, ah, I can reproduce the problem now, I'll look into it, thanks | 14:05 |
| adeuring | danilos: cool, and sorry for spotting the exact issue so late... | 14:08 |
| danilos | adeuring, no worries, it's very nice to catch bugs like these early on | 14:09 |
| danilos | adeuring, the problem is that there's a big area to click (anything below the green line also works, and the actual expander icon) | 14:10 |
| danilos | adeuring, so the problem is with the focus handling and I'll look into that right now | 14:11 |
| danilos | adeuring, and this doesn't happen in chromium which I mostly use for testing :/ | 14:13 |
| === almaisan-away is now known as al-maisan | ||
| === matsubara-afk is now known as matsubara | ||
| gary_poster | deryck, thanks for update, cool! btw, my fix for the funky asyncore errors and hangs landed on devel yesterday. I don't know how often you are encountering them, but for me it was obviously frequent enough to be annoying. What I did seemed to make things much better for me. | 14:23 |
| gary_poster | So, merging with devel might help | 14:23 |
| deryck | ok, cool. will do that. | 14:27 |
| === al-maisan is now known as almaisan-away | ||
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| flacoste | bac: are you OCR today? | 16:33 |
| benji | flacoste: bac is on vacation today | 16:40 |
| === micahg_ is now known as micahg | ||
| === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 210 - 0:[######=_]:256 | ||
| dobey | is it just me, or is merge proposal diff generation broken today? | 16:51 |
| wgrant | It is. | 17:01 |
| wgrant | The script is hung. | 17:01 |
| wgrant | Any maintenance people around? | 17:01 |
| wgrant | (an email has been sent about it every 20 minutes for the last 3.5 hours) | 17:05 |
| wgrant | But as it is 3am, I shall sleep. | 17:05 |
| flacoste | gary_poster: ^^^^ | 17:06 |
| === beuno-lunch is now known as beuno | ||
| gary_poster | flacoste, ack. | 17:23 |
| gary_poster | flacoste, we have no code people on our team to ask for details. Do you know them | 17:40 |
| gary_poster | flacosete belay that :-) | 17:40 |
| gary_poster | hm | 17:43 |
| === salgado-lunch is now known as salgado | ||
| flacoste | gary_poster: we'll have to start to figure them out by ourselves, as the only remaining code people is abentley and he's also on leave today :-) | 18:15 |
| gary_poster | flacoste, yeah, I figured :-) | 18:16 |
| gary_poster | flacoste, as best I can tell from looking at the logs, the code has some problems, but it is often able to recuperate, even if it has to lose a few jobs along the way. However, there was something like a perfect storm of errors at the time of failure, and the last log that isn't simply waiting for the log file is this: | 18:59 |
| gary_poster | File "/usr/lib/python2.6/traceback.py", line 57, in print_tb | 18:59 |
| gary_poster | if hasattr(sys, 'tracebacklimit'): | 18:59 |
| gary_poster | exceptions.AttributeError: 'module' object has no attribute 'tracebacklimit' | 19:00 |
| gary_poster | This is indicatative of the interpreter having gone a bit insane to my mind | 19:00 |
| flacoste | yeah, looks like it | 19:00 |
| flacoste | is it now always failing with this? | 19:00 |
| flacoste | as this is run every 20 minutes | 19:00 |
| gary_poster | No, it is silent now, other than staring at the lock file (every minute, it seems) | 19:01 |
| gary_poster | 2011-07-08 17:26:06 DEBUG Cronscript control file not found at file:cronscripts.ini | 19:01 |
| gary_poster | 2011-07-08 17:26:06 INFO Creating lockfile: /var/lock/launchpad-merge-proposal-jobs.lock | 19:01 |
| gary_poster | 2011-07-08 17:26:06 DEBUG Lockfile /var/lock/launchpad-merge-proposal-jobs.lock in use | 19:01 |
| gary_poster | 2011-07-08 17:27:04 DEBUG Cronscript control file not found at file:cronscripts.ini | 19:01 |
| gary_poster | 2011-07-08 17:27:04 INFO Creating lockfile: /var/lock/launchpad-merge-proposal-jobs.lock | 19:01 |
| gary_poster | 2011-07-08 17:27:04 DEBUG Lockfile /var/lock/launchpad-merge-proposal-jobs.lock in use | 19:01 |
| gary_poster | My immediate recommendation is to have losas kick the process and its subprocesses | 19:02 |
| gary_poster | Then I can file bugs for the two or three errors that seem to have led up to this state | 19:02 |
| gary_poster | Do you agree? | 19:02 |
| gary_poster | well, kick the process and remove the lock file, I should say | 19:02 |
| flacoste | gary_poster: sounds good | 19:04 |
| gary_poster | ok thanks flacoste | 19:05 |
| LPCIBot | Yippie, build fixed! | 19:25 |
| LPCIBot | Project db-devel build #710: FIXED in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/710/ | 19:25 |
| m4n1sh | gary_poster: I am working on a small writeup of LP | 19:30 |
| m4n1sh | is it right to name the correct the various components of LP | 19:30 |
| gary_poster | hi m4n1sh | 19:30 |
| m4n1sh | e.g. malone or soyez | 19:30 |
| m4n1sh | or the name has been deprecated? | 19:30 |
| gary_poster | "soyuz" fwiw | 19:30 |
| m4n1sh | gary_poster: hope your are fine thesedays | 19:30 |
| m4n1sh | :) | 19:30 |
| gary_poster | yes, thank you m4n1sh, and you too :-) | 19:31 |
| m4n1sh | can I have the name of various components | 19:31 |
| m4n1sh | cant recall | 19:31 |
| m4n1sh | soyez | 19:31 |
| m4n1sh | malone | 19:31 |
| m4n1sh | malone - bug tracking | 19:31 |
| m4n1sh | soyez - package management | 19:31 |
| dobey | soyuz :) | 19:31 |
| m4n1sh | ah | 19:31 |
| dobey | rosetta is translations | 19:31 |
| gary_poster | I don't think they are deprecated. Some internal names that you see in the code base (poppy and some other names) are not really encouraged | 19:31 |
| m4n1sh | ah that. just slipped | 19:31 |
| gary_poster | but yeah | 19:31 |
| dobey | i would just call them by what people see them as in the UI | 19:32 |
| gary_poster | soyuz, malone, rosetta, but then "answers" "blueprints" | 19:32 |
| gary_poster | yeah, I'd be inclined to agree with dobey | 19:32 |
| m4n1sh | I am writing a detailed explanation of what good things are there in Launchpad | 19:32 |
| m4n1sh | I am writing like | 19:32 |
| m4n1sh | 1) Code hosting | 19:32 |
| m4n1sh | 2) Bug tracker - Malone | 19:32 |
| dobey | bugs, code, archives, translations, answers, blueprints, etc | 19:32 |
| m4n1sh | 3) Question and Answers | 19:32 |
| m4n1sh | 4) Package Management - Soyuz | 19:33 |
| m4n1sh | 5) Translations - Rosetta | 19:33 |
| gary_poster | "blueprints", fwiw | 19:33 |
| m4n1sh | I can count only 6 till now | 19:33 |
| m4n1sh | any other? | 19:33 |
| * gary_poster looks for product manager's feature list :-) | 19:34 | |
| m4n1sh | lol | 19:34 |
| lifeless | hmm | 19:34 |
| lifeless | I need some nuance explained to me with the js security model | 19:34 |
| lifeless | who has a minute or two ? | 19:34 |
| gary_poster | m4n1sh, try https://dev.launchpad.net/FeatureChecklist | 19:34 |
| gary_poster | the only thing you left out was what we call registry | 19:35 |
| * m4n1sh can only understand jQuery when he hears Javascript is mentioned remotely | 19:35 | |
| m4n1sh | if the end user does not see registry, then it is useless to mention | 19:35 |
| gary_poster | well... | 19:35 |
| gary_poster | they see projects | 19:35 |
| gary_poster | and code | 19:35 |
| m4n1sh | ah yeah | 19:35 |
| gary_poster | I mean | 19:35 |
| m4n1sh | and teams? | 19:35 |
| gary_poster | yeah teams | 19:35 |
| gary_poster | but | 19:35 |
| m4n1sh | can I also add Mailing lists in one more feature? | 19:36 |
| gary_poster | yeah, that's another registry-ish thing | 19:36 |
| m4n1sh | oh | 19:36 |
| gary_poster | m4n1sh, I'd only use the "code" names if it helps you in your write-up | 19:36 |
| lifeless | <script type="text/javascript" language="javascript" src="http://...." async=True /> - what data on the page can that loaded script access ? I assume it can read the DOM because its been explicitly loaded by the page. | 19:36 |
| gary_poster | (like "soyuz" and stuff) | 19:36 |
| gary_poster | because from Launchpad's perspective, we do not talk about them | 19:36 |
| m4n1sh | i am mentioning in brackers (codenamed Soyuz) | 19:36 |
| gary_poster | sure | 19:37 |
| m4n1sh | *brackets | 19:37 |
| gary_poster | lifeless, le looks | 19:37 |
| gary_poster | me | 19:37 |
| m4n1sh | it is like a academic paper | 19:37 |
| dobey | gary_poster: hrmm, branch rescanning doesn't happen to be stuck now too, is it? | 19:37 |
| m4n1sh | so details are appriciated | 19:37 |
| m4n1sh | thanks everyone | 19:37 |
| gary_poster | lifeless yes, afaik. iframes can complicate things a bit | 19:38 |
| lifeless | as in it might not be able to access the content of an iframe, even if the iframe is from the same site as the page, because its not part of the dom and its not same-site as the script | 19:38 |
| gary_poster | right lifeless | 19:39 |
| lifeless | however the script can't access the cookies, nor make new json requests to the pages site | 19:39 |
| lifeless | gary_poster: the cookies of the main page I mean, moving on from iframes | 19:40 |
| gary_poster | dobey, the only failure we had reported was merge-proposal-jobs | 19:40 |
| gary_poster | that may be related; me looks at logs | 19:41 |
| dobey | yeah i didn't see any rescnning issues earlier, but i'm seeing one that seems stuck now | 19:42 |
| dobey | lifeless: is the javascript and html hosted from the same domain? | 19:42 |
| lifeless | dobey: no | 19:42 |
| dobey | lifeless: that would be why | 19:42 |
| lifeless | dobey: I'm exploring the security implications of using a service that wants us to load their js remotely | 19:43 |
| lifeless | dobey: so there are rhetorical questions, not 'I tried and it couldn't' | 19:43 |
| dobey | ok | 19:44 |
| dobey | gary_poster: ah, there, it finally rescanned | 19:44 |
| gary_poster | dobey, whew I couldn't find anything wrong :-) | 19:44 |
| gary_poster | lifeless: https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript ? | 19:44 |
| dobey | gary_poster: i guess it's just being slow for some reason. :) | 19:45 |
| lifeless | gary_poster: frustratingly they don't talk about the nuance here | 19:45 |
| gary_poster | more or less cool then | 19:45 |
| lifeless | gary_poster: that is loaded document vs included script | 19:46 |
| lifeless | I may be incorrectly assuming that there is a difference | 19:47 |
| lifeless | gary_poster: its easy to reason about the case where you have two tabs and one tab wants to access the other, or make new requests | 19:48 |
| lifeless | gary_poster: but this is the case where we load a script from an arbitrary site into the tab we have sensitive data on; I welcome corrections to my paranoia | 19:48 |
| gary_poster | lifeless, I get where you are coming from. This is questions of the sort "if we include Google site analysis code, do they own our data and our users?" I should know this, and I feel like I did at one point, but I've forgotten. rockstar would know I bet. | 19:53 |
| lifeless | right | 19:53 |
| lifeless | I've replied to mrevell in the relevant thread | 19:53 |
| gary_poster | lifeless, since one of the standard ways of using YUI and similar libraries is to include it in the page from a source supplied by another provider (like Yahoo's CDN), I would be strongly inclined to guess that it runs, security-wise as if it were code that were written in the page | 19:58 |
| gary_poster | all your Dom, cookies, etc. belong to us | 19:58 |
| lifeless | gary_poster: I share that guess - its why I'm concerned | 19:58 |
| gary_poster | yeah | 19:58 |
| flacoste | m4n1sh: malone, rosetta and soyuz are really deprecated names | 20:11 |
| flacoste | m4n1sh: we removed all references to them from the UI | 20:11 |
| flacoste | so they should be called Bugs, Translations, Packages | 20:12 |
| flacoste | Soyuz is the only one that doesn't want to die | 20:12 |
| flacoste | the fact that we never put it in the UI in the first place probably makes this harder | 20:12 |
| rockstar | gary_poster, yes, bringing third party CDN code into HTTPS means you give them access to everything you're putting behind HTTPS. | 20:13 |
| lifeless | rockstar: thanks | 20:14 |
| gary_poster | thanks rockstar! | 20:14 |
| lifeless | rockstar: cookies as well ? | 20:14 |
| rockstar | Basically, they could load some malicious javascript that reads data right off your page. | 20:14 |
| rockstar | lifeless, yes. | 20:14 |
| lifeless | righto | 20:15 |
| lifeless | so we probably want to stop using analytics too :( | 20:15 |
| gary_poster | well | 20:15 |
| rockstar | Yeah, I mean, you're assuming google is reputable. | 20:15 |
| rockstar | And they probably are. | 20:15 |
| gary_poster | as you said for the other company "we've got no particular reason to trust them deeply" | 20:16 |
| rockstar | But you give them access to things that you might not want to give them access to. | 20:16 |
| gary_poster | It could be argued that we do have reason to trust Google. It's a matter of degree | 20:16 |
| rockstar | Ubuntu One is using Analytics, but I'm hoping to start using some better services soon. | 20:16 |
| gary_poster | (I'm inclined to trust them; ruining our day would not be in their best interests, AFAIK) | 20:17 |
| gary_poster | rockstar, with JS served by you? | 20:17 |
| gary_poster | ("better analytics") | 20:18 |
| gary_poster | uh, "better services" :-P | 20:18 |
| rockstar | gary_poster, not sure. Most of the services want you to use their site. | 20:18 |
| gary_poster | yeah that's what I've seen too | 20:18 |
| rockstar | But then we've got another request. | 20:18 |
| rockstar | These sites would be "pay for" services, so at that point they would also not really want to ruin our day. | 20:19 |
| gary_poster | heh | 20:19 |
| m4n1sh | flacoste: thanks | 20:29 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | rockstar: well we don't use their search appliance for lp private data because of potential data exposure | 20:35 |
| lifeless | rockstar: so I think you probably want to talk with ISF :) | 20:35 |
| gary_poster | flacoste: do you have an opinion about what LP should do if all a person's registered email addresses have been disabled due to repeated email bounces? Email activity is so central that it might not be too crazy to disable the user, or at least put them in a state that is identical to being disabled except that leaving the state is done in a special way (simply stating that an email address is no longer disabled, for | 20:35 |
| gary_poster | On the other extreme, we could simply silently stop delivering emails to this person (silently other than the bounce processor trying to contact them once a week for N=4 weeks), and continue normally if they log in. | 20:36 |
| * gary_poster decides lifeless meant http://en.wikipedia.org/wiki/Information_Security_Forum | 20:38 | |
| rockstar | lifeless, I'm much better at asking forgiveness. :) | 20:38 |
| gary_poster | Iraqi Security Forces were another option | 20:38 |
| lifeless | gary_poster: I meant elmo :) | 20:38 |
| gary_poster | heh | 20:38 |
| lifeless | IS foundations | 20:38 |
| gary_poster | ah | 20:38 |
| flacoste | gary_poster: yeah, if it's primary contact address that is bouncing, we might as well disabled them until they sort their email out | 20:41 |
| flacoste | gary_poster: but it's not a strong opinion ;-) | 20:41 |
| gary_poster | cool thanks flacoste. yeah, fair enough :-) | 20:41 |
| lifeless | that kindof implies showing them an explanation when they attempt to log in, and a way to fix | 20:43 |
| lifeless | FWIW I'm easy | 20:43 |
| gary_poster | :-) | 20:44 |
| gary_poster | I agree fwiw lifeless--if we were to go down the disabling road, we should provide a nice path for cleaning the situation up. | 20:45 |
| * gary_poster realized about 10 minutes ago that he was writing a LEP ;-/ | 20:45 | |
| lifeless | it is a nontrivial chunk of work | 20:48 |
| lifeless | long overdue though, and worth doing | 20:48 |
| gary_poster | bye all | 21:14 |
| === matsubara is now known as matsubara-afk | ||
| === Ursinha is now known as Ursinha-afk | ||
| thedac | staging on asuka is down. It errors out when attempting to start: https://pastebin.canonical.com/49528/ | 22:55 |
| === al-maisan is now known as almaisan-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!