[00:01] steven@liquified:~/launchpad/lp-branches/kill-launchbag-with-fire% bzr grep ILaunchBag | wc -l [00:01] 555 [00:01] :-( [00:01] wgrant: QA done [00:02] StevenK: Thankyou sir. [00:02] sinzui: XMLRPC is implicated, which concerns me [00:02] skip it then. change the ones that keep slowing us down [00:03] StevenK, I looked at the template that makes the bug links [00:03] lib/lp/xmlrpc/application.py: caller = getUtility(ILaunchBag).user [00:04] I think the view's .unofficial_tags and .official_tags could make make sane links instead of the template. That would be easier to test [00:04] lib/lp/app/browser/launchpad.py: self.user = getUtility(ILaunchBag).user [00:05] Bah [00:05] StevenK, just focus on bugtask and maybe bugnomination [00:05] StevenK, the bag is not 100% 20% is useful. We get stuck when it is used instead of the context information. [00:07] BugTasksAndNominationsView.current_bugtask == return getUtility(ILaunchBag).bugtask [00:14] sinzui: http://pastebin.ubuntu.com/808023/ [00:19] StevenK: could you "bin/ec2 land" this for me? my precise system is borked https://code.launchpad.net/~wallyworld/launchpad/subscription-policy-text-912159/+merge/88808 [00:20] StevenK, I think it needs some checking. For example I see in configure.zcml that IBugNomination is the thing that is passed to some the nomination views [00:24] StevenK, and why would get_assignee_vocabulary_info have self.user, it is an 8 line function [00:25] StevenK, the two callsites of get_assignee_vocabulary_info are Lp views and do know the user, so they should pass the user with the context [00:25] sinzui: Right, which I just did. [00:25] sinzui: http://pastebin.ubuntu.com/808035/ is a updated diff [00:29] StevenK, BugListingBatchNavigator is not an Lp view. it I think we could use request.user though [00:30] wallyworld: It has been tossed at ec2. [00:31] StevenK: thanks. looking at your use-combo branch now [00:31] use-*convoy* [00:31] StevenK, the other option is the make some of the classes inherit from UserAttributeCache which provides .user to lp views [00:31] yeah, typo [00:31] sinzui: Using request.user sounds fine to me [00:36] I thought after create_initialized_view(), you could call view() to get the actual HTML out? [00:37] sinzui: If you think my launchbag diff is good I can commit, push and create an MP === StevenK changed the topic of #launchpad-dev to: devel broken until r14681 | https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 3*10^2 [00:37] StevenK, I think the bug nomination changes will break the bugtask ones might work [00:40] cjwatson: r=me for https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942 , shall I land it for you? [00:42] StevenK: use-convoy doesn't load the yui stuff properly for me, looking to find out why [00:43] wallyworld: Did you 'make clean' and 'make'? [00:43] StevenK: yep [00:44] it appears the bootstrap yui.js file is not loaded because of a wrong url [00:44] wgrant: I'd be happier if authenticateUsingBasicAuth wasn't *called* outside the test runner [00:44] wallyworld: Which wrong URL? [00:44] wallyworld: OH! [00:44] wallyworld: You to run sudo make copy-apache-config [00:44] lifeless: It isn't [00:44] lifeless: Which is why it crashes. [00:45] StevenK: right, i'll do that [00:45] lifeless: See the next hunk, which adds an config.isTestRunner() check to the call [00:45] wgrant: ok, so uhm, comment there that it shouldn't be called [00:45] StevenK: yes please, thanks [00:45] Sure. [00:45] I was thinking we could put something in the test runner zcml [00:45] but I see its not componentised [00:46] I considered that, but it would need a bit of refactoring. [00:47] StevenK: apache restart fails with: Invalid command 'WSGIScriptAlias' [00:47] missing module [00:48] wallyworld: Install libapache2-mod-wsgi [00:49] * wallyworld does that === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 3*10^2 [00:49] cjwatson: Right, I've reviewed all four of your branches, I'll toss them all at ec2. [00:52] StevenK: neat, thanks [00:52] StevenK: still issues, trying make clean again [00:53] wgrant: anyhow, I don't have anything significant to say [00:53] obviously there is a risk [00:53] StevenK: i assume we need to include the libapache2-mod-wsgi package as a launchpad dep now [00:54] wallyworld: That can be done at the same time we add convoy [00:54] wallyworld: I don't think so [00:54] it'll be a convoy dep [00:54] Mmmmm [00:54] I don't think convoy should depend on it. [00:54] It can be run in any WSGI server... [00:55] ah, right. and we're serving out of the same apache anyway [00:55] lifeless: I think we should eliminate it eventually, but there are so many tests to migrate. [00:55] And it's not clear what's best to migrate to. [00:55] StevenK: so, still broken. i'll see if there's anything in the apache logs [00:57] wallyworld: What does wget --no-check-certificate https://launchpad.dev/combo?yui/yui/yui-min.js give you? [00:57] +combo, please [00:57] StevenK: will try that. btw, saw this in apache error log [00:57] Traceback (most recent call last): [00:57] File "/home/ian/projects/lp-branches/devel-sandbox/scripts/branch-rewrite.py", line 15, in [00:57] import _pythonpath [00:57] ImportError: No module named _pythonpath [00:57] * StevenK stabs wgrant [00:57] wallyworld: Unrelated [00:59] wgrant: I'm going to start working on the convoy parsing the path tomorrow. I'll see if I can get the +combo going. I want to try to keep consistant somewhat with the other teams using it [00:59] StevenK: it gets me a file containing [00:59] rick_h: Right. [00:59] rick_h: LP is sort of special, though, in that our top-level namespace is user-controlled. [00:59] rick_h: I can switch to +combo pretty easily [01:00] StevenK: https://pastebin.canonical.com/58279/ [01:00] wgrant: yea, I need to look into the best way to parse the url our to split on host/$disk_path/$ignoreme_or_something [01:00] wallyworld: ok that means that it can't find the files on disk you asked for [01:01] wallyworld: find /var/tmp/convoy -type f [01:01] rick_h: yeah, figured as much [01:01] wallyworld: but that means it did get served via the combo loader application [01:01] so yay for partial success [01:02] Sucessful failure! [01:02] lol, that's what we decided to call it wasn't it [01:03] rick_h: StevenK: i suspect the yui tarball is not being unpacked correctly. i think my/deryck's last buildout mods are missing, looking now [01:03] wallyworld: We do that ourselves [01:04] wallyworld: Using bin/combo-rootdir [01:04] ah ok. our buildout mods are for the legacy launchpad.js then [01:04] Yes. [01:04] And therefore pointless [01:04] Since LP has no hope to build against 3.4.1 [01:05] rick_h: /+combo changes pushed [01:05] StevenK: rick_h: so here's what's under /var/tmp/convoy/yui: https://pastebin.canonical.com/58280/ [01:06] StevenK: the idea was that we would just unpack from the tarball the yui build dir [01:06] which is all the combo loader needs IIUC [01:06] ie we don't want to copy across all the src etc [01:06] so we may have a slight disconnect here [01:07] since what is under /var/tmp/convoy now is not what i was expecting to see [01:07] /var/tmp/convoy/yui i mean [01:07] wallyworld: Well, everytime I tried to get involved, deryck told me to shush [01:08] he did didn't he [01:08] wallyworld: bin/combo-rootdir is built from a buildout template, and it will unpack the yui in versions.cfg [01:08] wallyworld: Oh, and be careful running bin/combo-rootdir [01:09] If you run it with no arguments, it will attempt to remove /* [01:09] StevenK: so, why that script and not a buildout recipe? [01:09] wallyworld: Because buildout recipes are a pox [01:09] but we have one that works [01:09] that we were expecting to be used [01:10] that unpacks the yui files in downlaod cache - the versions we wan tto switch between [01:10] wallyworld: Then you and deryck made lovely assumptions [01:10] so we can use the feature flag to switch between yui versions on the fly [01:10] And now you get to keep both pieces [01:11] StevenK: we talked with rick_h about it, and i thought you as well? [01:11] wgrant: I have a suggestion [01:11] wallyworld: I think that work is premature -- we can't switch to 3.4.1 until we are using the combo loader anyway [01:12] wgrant: in BaseLayer set a global variable somewhere. [01:12] StevenK: exactly, that's what we were prepping for [01:12] wgrant: on nmodule load have it initialize to None [01:12] wgrant: IFF it is set, it is the basic password [01:12] wgrant: if it is not set, basic auth cannot work [01:12] honestly wallyworld, I don't think StevenK and I "got" what you guys were headed towards at the time [01:12] wallyworld: In either case, you need to debug what bin/combo-rootdir is doing [01:13] lifeless: I don't think that will work for testrunner-appserver [01:13] wallyworld: since we were honestly figuring out things ourselves as far as the plan for the on disk layout/setup [01:13] rick_h: Given deryck kept shushing me, I kept my opinions to myself. [01:13] wgrant: well, set it in the config then [01:13] wgrant: *that* will work using the same thing we do for transient rabbit etc [01:13] StevenK: rick_h: ok. i'll debug it. seems like there was a communications fail there [01:13] wallyworld: definitely [01:13] wallyworld: sorry about that [01:14] rick_h: no need to apologise - it was a collective failure [01:14] wallyworld: I had hoped to get that stuff merged in to "see" what it was up to while we were together but ran out of time [01:14] rick_h: StevenK: although, i'm trying the use-convoy branch "out of the box" and it's still failing [01:14] ie it should work as is [01:15] It can't, so far [01:15] but i'll find out what's happening in the process of trying to fit the other stuff in [01:15] It needs changes to lp-meta-deps [01:15] wgrant: this then does not depend on the config name, it only depends on us not setting the global basic password in production configs [01:15] something I think we can manage [01:16] StevenK: what changes? so far, i've installed tne missing deb and updated the apache configs, other than that, it's the vanilla use-convoy branch [01:16] wallyworld: It's *very* rough, currently [01:16] lifeless: Right, but then we depend on lazr.config's somewhat ambiguous behaviour of mapping 'none' -> None [01:16] But I guess [01:16] (I still don't know how that works) [01:16] wallyworld: And installed mod-wsgi [01:16] wgrant: you don't want to. [01:17] StevenK: yes, that's the deb i was referring to [01:17] wgrant: you can check 'if basic_password and basic_password.upper() != 'NONE':' [01:17] wallyworld: yea, something is up with your paths for the yui files that got unpacked. I don't think "yui-yui3-f332140/src/" should be in the path [01:17] wallyworld: There's two -- convoy and mod-wsgi [01:17] wgrant: if you want less reliance [01:17] lifeless: That's what I was planning. [01:17] But still, ew. [01:17] StevenK: he's getting successful requests from convoy via apache [01:17] StevenK: ah right, sorry. that's what i meant [01:17] StevenK: it's just saying that it can't find the .js files [01:18] rick_h: yes, the unpacking of the tarball appears wrong, or incompatible with what the combo loader expects [01:18] rick_h, wallyworld: I've pushed a small change to bin/combo-rootdir that will blow up if you run it with no arguments, rather than attempting to remove /* [01:18] wallyworld: the lp and the yui2 directoryes look right from that pastebin [01:19] rick_h: yes, agreed [01:19] StevenK: thanks [01:19] wallyworld: but the yui3 isn't correct, I'm not sure why off the top of my head. I've not pulled StevenK's latest stuff yet. On the docket for tomorrow [01:19] I'm not looking forward to merging devel [01:19] rick_h: StevenK: so, the buildout recipe unpacks the yui tarballs to build/js/yui [01:20] wallyworld: right, which should now be /var/tmp/convoy/yui [01:20] and then i expect this will be what's copied over to /var/tmp/convoy [01:20] All tarballs? [01:20] StevenK: yes, so we can switch between them [01:20] using the js.yui-version feature flag [01:20] At the moment, we don't deal with multiple yui versions in our use of the combo loader [01:20] This is why I said it's premature [01:21] We haven't even figured out all the pieces and stuff is moving out from under us [01:21] ok, for now we just need to get it working with the expected version for prod [01:21] but one of the value props here is the ability to easily test qastaging against another yui version for example [01:22] Sure [01:22] or locally as well of course [01:22] But let's get the combo loader working first before we start changing other stuff [01:22] that was my plan for now :-) [01:23] and a fine plan that is [01:24] wallyworld StevenK, I'm going to head offline in a bit for the night. Shoot me an email with where things are so I can pick them up tomorrow. I've got a call with deryck to go over the details on where to head from here [01:24] rick_h: StevenK: so, i don't think i'll have to do much - just take the tarball unpacking out of combo-rootdir and replace with a copy from the buildout stuff [01:24] rick_h: np. goodnight. thanks [01:25] wallyworld: ok, let me know where that's at once working and I'll make sure to pull that in locally as well [01:25] wallyworld: or get StevenK to update his branch with it before EOD for you guys [01:25] wallyworld: build/js/yui/yui-3.3.0 is empty for me [01:25] rick_h: will do. [01:25] StevenK: let me poke a bit on my disk to have a look [01:27] StevenK: my dir has all the expect yui stuff. try rm .installed.cfg and rerun buildout [01:31] wallyworld: make clean and make results in the jsbuild stuff being unable to find lib/canonical/launchpad/icing/yui/yui/yui.js [01:32] * wallyworld scratches head [01:32] StevenK: did you rm .installed.cfg to force buildout to run from scratch? [01:32] wallyworld: Yes [01:33] StevenK: maybe try manually rm the yui dir in icing? [01:34] i'm not sure what's happening to be honest. i'm running directly off the use-convoy branch [01:36] wallyworld: lib/canonical/launchpad/icing/yui links to build/js/yui/yui-3.3.0 which is empty [01:36] StevenK: is your download cahce up to date? [01:37] StevenK: the tarball has been renamed [01:38] Which was a pointless renaming [01:38] there's a yui-3.3.tar.gz and also a yui-3.3.0.tar.gz the 3.3.0 version is new [01:38] StevenK: no, not pointless. the contents are different [01:38] the 3.30 version is hand packed to contain just the yui build files [01:38] the 3.3 version i mean [01:38] ಠ_ಠ [01:38] ಠ_ಠ [01:38] ಠ_ಠ [01:38] ಠ_ಠ [01:38] the 3.3.0 version is a direct download off github and the untar cmd is modified [01:39] ಠ_ಠ [01:39] wallyworld: Which is why bin/combo-rootdir is broken [01:39] ah, that makes sense [01:40] So you changed all this stuff out from under me, complains when it breaks, and you didn't tell me any of this? [01:40] StevenK: so we wanted to eliminate the need for a manual packaging step. better to just download straight of github [01:40] StevenK: no, it would have worked if your download cache was up to date [01:40] i think? [01:40] or maybe not [01:40] The make would have worked. [01:40] this was done last thing friday and we ran out of time for a proper wrap up :-( [01:40] But then my convoy rootdir would be wrong, like what you see. [01:41] if we had not lost 5 hours on thursday..... [01:41] wallyworld: What annoys me is that you didn't tell me anything [01:41] all this is a symptom of rushing to get stuff done right at the end :-( [01:41] Right, I finally have a test case [01:41] StevenK: it wasn't deliberate [01:42] We really don't handle tags with a + in them [01:42] we really needed to have another few hours on the day [01:42] wallyworld: Anyway, I'm looking [01:43] StevenK: i don't mind hacking on it [01:43] i can get it work with the buildout stuff [01:43] steven@liquified:~/launchpad/lp-branches/devel% bin/ec2 ls | tail -n 1 [01:43] Summary: running: 5 [01:43] if you want [01:43] wallyworld: Just waiting for my download-cache, and I'll push [01:43] ok [01:44] sorry about the confusion [01:50] wgrant: So my test fails, we do just spit out unencoded tag names and slap it into a generated URL in TAL. [01:51] StevenK: Of course :) [01:52] wgrant: ${tag} => ${tag/fmt:url} ? [01:52] It's not an fmt:url. [01:53] wgrant: Or am I better off doing this in the view? [01:53] lifeless: It's all in the config now. [01:53] StevenK: Probably the view. [01:54] wgrant: cgi.escape, or will that make you kill me? [01:56] It won't even do what you want :) [01:57] wgrant: urllib.urlencode? Or is that wrong too? [01:58] That sounds more likely. [01:58] Or urllib.quote if you just want to use it to generate the value, not the full k-v list [02:08] wgrant: great [02:16] * wgrant stabs postgres in the eye. [02:17] Morn[B24 [02:17] err [02:17] Morning! [02:17] Clearly, I need coffee. [02:19] wallyworld: use-convoy fixed [02:19] StevenK: i'm just about to push a change to fix it also [02:19] using the new buildout stuff [02:19] StevenK: how about i push my change and you have a look [02:20] StevenK: there's a few issues in the console logs i was looking at [02:20] the sorttable js is not being loaded [02:20] nor are some of the lazr-js assets [02:23] StevenK: lp:~wallyworld/launchpad/use-convoy https://pastebin.canonical.com/58281/ [02:28] wallyworld: You can't use ln [02:28] ? [02:28] works for me [02:28] Oh, I see what you've done [02:29] I shall ponder that [02:29] it's sort of an interim step, till we support specifying the yui version [02:29] not sure why the sorttable stuff isn't getting found [02:30] that's under lp [02:30] and i think we're missing copying some of the lazr-js stuff across [02:32] StevenK: also, merge in trunk so you get the last of the mochi fixes from yerterday [02:32] there will be a few LPS usages to change [02:34] StevenK: ah, sorttable.js doesn't have a requires [02:34] do you want to add an empty one? [02:34] in your branch? [02:50] StevenK: Could you find some time to review https://code.launchpad.net/~wgrant/launchpad/hardcoded-password/+merge/88966 and https://code.launchpad.net/~wgrant/launchpad/no-passwords/+merge/88971 this afternoon? [02:54] is sorttable stuff broken on production currently? [02:54] because it certainly isn't working for me [02:54] It's not meant to be, but it quite possibly is. [02:54] e.g. try to sort by assignee on https://launchpad.net/lava/+milestone/2011.12 [02:55] Hm [02:55] WFM [02:55] In Firefox [02:55] hm [02:55] More attractive than the old version, too. [02:55] * wgrant fires up Chromium. [02:55] messed up in both chrome and ff for me [02:55] well chromium [02:55] wgrant: Does lifeless still have objections? [02:55] StevenK: Doesn't seem to. [02:56] mwhudson: Oh [02:56] mwhudson: It's all off by one column. [02:56] hah yes [02:56] wallyworld, StevenK: ^^ sorttable regression [02:56] well [02:56] it's off by one for the blueprint listing [02:57] not sure about the bug listing, that seems a bit more random [02:57] Hm, indeex. [02:57] Importance sorts by summary, status by project. [02:57] s/indeex/indeed/ [02:57] wgrant: Do we need to revert prod again? [02:58] Not if we fix this now. [02:58] there was a change to de-mochi sorttable or something recently? [02:58] Yes [02:59] [r=deryck][no-qa] Make sorttable a proper YUI module. Also updates to [02:59] latest version, which fixes sorttable on our site for Chrome users. [02:59] 14671 [02:59] Yes, the origin of the breakage was reasonably obvious :) [02:59] It's just not clear why it's broken. [02:59] Or how wide it is. [03:02] Hmmm [03:02] Why can't I save MP comments? [03:03] Oh no not again. [03:03] Oh, there we go. Just took *ages* [03:03] It does that sometimes :/ [03:03] I think it's unrelated. [03:03] wgrant: r=me * 2, but you may want to wait until we sort this crap out [03:04] chrome's developer tools doesn't like launchpad.js very much [03:05] I wonder why that is. :-P [03:05] Who would have thought a 3.3MiB JS file was a good idea. [03:06] wgrant: I fear my lack of JS knowledge won't help debugging sorttable [03:06] It's unlikely to be a very javascripty sort of thing. [03:07] a brand new version of upstream sorttable was used [03:07] since the previous one was broken in chrome [03:07] s/\(JS\)\(.*\)\(sortable\)/\3\2/ [03:10] The new one doesn't seem to handle colspan at all. [03:10] aaah [03:11] that would explain some things [03:12] looks like it works on the new bugs listings [03:12] but those pages perhaps use their own sorting [03:12] They don't use sorttable. [03:12] my money is on wgrant's observation [03:12] explains that then [03:12] o_O [03:12] - colspan = td.getAttribute("colspan"); [03:12] - if (colspan) { [03:12] - SORT_COLUMN_INDEX += parseInt(colspan) - 1; [03:12] - } [03:12] The new one doesn't even respect sortkey [03:12] It's useless. [03:12] with no corresponding +s [03:12] (they were local patches, AFAIK) [03:13] ah [03:13] so um [03:13] timestamp: Mon 2007-03-19 17:14:53 -0300 [03:13] message: Fix for bug 62495: Milestone bug list doesn't sort properly. Make the Javascript sorting code cope with COLSPANs. Based on a patch by BjornT. Also adds a sortkey to ensure that the sorting by bug number works. [03:13] <_mup_> Bug #62495: Milestone bug list doesn't sort properly < https://launchpad.net/bugs/62495 > [03:13] rewrite it in YUI? [03:14] wgrant: so you saying we did local patches to upstream? [03:14] wallyworld: Yes [03:15] This apparently wasn't checked before we upgraded. [03:15] http://www.kryogenix.org/bugs/sorttable/colspan-rowspan.html [03:15] we could port those to the current version [03:15] maybe we can just set fire to the west midlands! [03:15] That may be the best plan for now. [03:15] mwhudson: we ultimately want to go all yui, but were not planning on a rewrite just now [03:16] it's only 450 lines, and would be ~200 with yui? but sure [03:16] i'm certainly not going to fix it :) [03:17] mwhudson: it's just that we have no bandwidth atm [03:17] sure [03:17] we are supposed to be working on disclosure - the sorttable stuff came up with the move to a combo loader, a project meant to be completed at last week's Epic [03:20] wallyworld: sinzui said we should work on stuff from last week so it actually gets finished. [03:20] StevenK: sure, but not a rewrite in yui, that's all i meant [03:20] i just was saying we could do the minimum - port the previous fixes [03:22] Dammit Ubuntu, why do you have so many bugs :( [03:24] * wallyworld has got the sorttable diff from r 3970 and will port across [03:25] wallyworld: There are two [03:25] At least [03:25] sortkey and colspan [03:25] Diff from the original version. [03:25] sure [03:25] Hmm [03:26] The diff is 316 lines :) [04:28] StevenK: objections t ? [04:28] *to* [05:31] -> dinner for familty [05:42] wgrant: quick look at this? https://code.launchpad.net/~wallyworld/launchpad/sorttable-fix/+merge/88982 [05:43] bah, just saw a mistake, fixing [05:55] fixed [06:03] wallyworld: It works for sorting by dates, and on milestone pages (which have complex columns)? [06:04] wgrant: the branch listing has date columns and the first header has colspan = 2. but i could see any milestone pages with data on lp.dev [06:05] couldn't [06:05] wallyworld: Firefox apparently has some. [06:05] so i thought [06:06] i'll see if i can some something [06:11] ha ha hahahhahhah [06:12] Been debugging a test for ages. [06:12] Query count ends up larger with hardcoded-passwords [06:12] Turns out it was authenticating with 'test' as the password before, but that was in fact incorrect. [06:12] So it was inadvertantly making an anonymous request. [06:34] wgrant: i creaed some sample data and it appears ok sorting blueprints and bugs tables on a milestone page [06:36] wallyworld: With all columns? Great. [06:36] yep [06:37] wgrant: if you +1 it could you please lp-land since lp-land is broken on my precise atm [06:42] wallyworld: Will land. [06:43] Seems like it would be about 80% smaller in YUI, though. [06:44] lifeless: Bah. We're the Purple squad [06:44] wgrant: yes, yui would be better. but no time. thanks for landing [06:44] Actually just going to test it a bit more first. [06:44] StevenK: i already sent a correction :-) [06:44] But it looks good. [06:45] yeah, there was a corner case of two due to the new codebase [06:46] Hm [06:46] wallyworld: So lp-land is broken. Why is ec2 land broken? [06:46] No point ec2 landing that [06:46] StevenK: same issue [06:46] missing method [06:47] Strange [06:50] wallyworld: Just read your MP for your fix to the ITeam:+edit bug I reported -- the screenshot looks awesome [06:50] StevenK: thanks. [06:50] wallyworld: I don't think sortkey is working properly. [06:51] eg. modify a few branches on https://code.launchpad.dev/firefox 30s apart [06:51] (just change the description) [06:51] You'll see that "a moment ago" sorts between "33 seconds ago" and "2007-12-06" [06:51] it will use the sortjey if one is provided [06:51] sortkey [06:52] [06:52] 2012-01-18 08:50:13 SAST [06:52] a moment ago [06:52] [06:52] hmmm. not sure why it's misinterpeting it then [06:52] will have to look [06:53] i tested the sortkey stuff with enum columns eg bug status [06:57] bah, the whole code structure around guessing column types is different [06:57] more work needed [06:58] How much more? [06:59] It may be worth landing this anyway. [07:00] just had a more thorough look. i think it just may be a change to the re used to guess that a column is a date [07:01] it doesn't like datettimes [07:01] i think worth landing now, with another landing to fix the dates [07:04] submitted [07:04] thanks! [07:16] mwhudson: fix for sorttable is merged into trunk. date columns still need a little work but other than that it's ok i think [07:16] hopefully will be out of buildbot etc by tomorrow [07:17] * wgrant is confused about bug #918037 [07:17] <_mup_> Bug #918037: launchpad: please enable some shorter URLs for bugs < https://launchpad.net/bugs/918037 > [08:37] StevenK: bah, sorry. [08:51] stub: Sorry, channel fail [08:52] stub: If you have a look at the branch linked to bug 909240, you can see that I've rewritten the query that the method uses. [08:52] <_mup_> Bug #909240: Can't display New queue due to timeouts < https://launchpad.net/bugs/909240 > [08:53] Yay. Loaded a LP page and firefox crashes [08:53] stub: wgrant and I did some investigation and we both think the a new index on BPPH will speed up the query a lot. I have a WIP MP at https://code.launchpad.net/~stevenk/launchpad/db-add-bpph-index/+merge/88824 [08:56] StevenK: ok. That looks fine. Got an example query handy for me to test? [09:00] Or have you already done tests on staging and know the new index wins out over the existing index just on binarypackagename? [09:01] stub: I tried on dogfood, and it cut it down to 30ms. [09:01] I don't remember exactly what it was without the index, but it was more than 10x that. [09:01] * wgrant digs up the query. [09:01] Ok. Sounds like we just want to land it and apply live then. [09:02] MP is WIP though... what still needs to happen? [09:02] http://pastebin.ubuntu.com/807147/ [09:24] StevenK: I'm failing to comprehend that failure mail about archive-copy-packages-source-series [09:24] Tests hung, but doesn't seem to be related to my change? [09:29] cjwatson: Let me have a dig. [09:29] * StevenK nails bigjools to IRC. [09:29] Stay! [09:30] precise hates me [09:30] usb kernel module crashes which takes out the mouse and keyboard [09:30] StevenK: lol [09:31] cjwatson: Hm, that is strange. === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2 [09:32] cjwatson: Nothing is jumping out to my flu-alded brain, sorry. [09:33] stub: MP is WIP because I wanted to talk to you, if you came up with a better index or so [09:34] bigjools: It seems my nail helped. Did I catch any important bits? :-P [09:49] StevenK: is it worth throwing it against the wall again, or is this unlikely to be transient? [09:50] Where was the hang? [09:51] successful: lp.testing.tests.test_zope_test_in_subprocess.TestZopeTestInSubProcessLayer:tearDown [09:51] WARNING: A test appears to be hung. There has been no output for 600 seconds. [09:52] last real test was lp.translations.utilities.tests.test_superfastimports.TestSuperFastImports.test_query_timeout [09:52] (which succeeded) [09:52] stub: I shall fiddle with the MP and toss it at db-devel [09:53] Hmm [09:53] I haven't seen that one in a long time. [09:53] Probably over a year. [09:53] Throw it at ec2 again, I say. [09:53] http://people.canonical.com/~cjwatson/tmp/archive-copy-packages-source-series-r14656.subunit.gz [09:54] cjwatson: Link me the MP again and I'll re-toss it along with my db patch [09:54] StevenK: https://code.launchpad.net/~cjwatson/launchpad/archive-copy-packages-source-series/+merge/87942 - ta [09:56] Which just got hit with FDT [09:57] good morning [09:59] since the dev wiki seems to be joining the blackout, what do I need to do to QA my db change branch which has landed on qastaging? [10:02] Laney: Hm, works for me. [10:03] yeah, back now [10:03] was down for at least 30 minutes :-) [10:03] But DB change branches don't land on qastaging, but staging itself. For this sort of thing we mostly just check that it applies. [10:03] I'll check once fdt is over. [10:03] oh, http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html says qastaging [10:04] It's a lie :( [10:04] boo [10:06] 2012-01-18 05:44:34 INFO 2209-02-0 applied just now in 5.5 seconds [10:06] qa-ok [10:07] A little on the slow side, but it'll do. [10:07] tidy === matsubara-afk is now known as matsubara [11:32] Laney: The dev wiki issue was a firewall misconfiguration that lasted about 15 minutes, I believe. [11:32] Laney: I've scheduled that patch for deployment tomorrow [11:32] wgrant: Oh OK, thanks. How will I know when it's done? The bug will be flipped to Fix Released? [11:33] I'll comment and flip the bug back to In Progress. [11:33] Since it requires further landings. [11:34] bonus, thanks a lot. [11:34] Maybe I'll look into UI for creator and sponsor next ... [11:35] but that would probably require figuring out how to get test data into my local instance. [11:35] Filling in sponsor is probably more important than displaying it. [11:35] Since there's not much to display at present :) [11:35] Ursinha: Your patch is now live on production, so if you need help with the code, or anything, give me a prod. [11:35] it would be nice to have it on +source [11:35] Laney: Indeed. [12:27] \o/ [12:27] thanks StevenK [12:27] morning all [12:31] Morning rick_h. [12:56] allenap: would it be worth doing a lazr.uri release? It, er, doesn't seem to get changed very often ;-) [13:55] cjwatson: Yes, a very good idea. I am waiting for flacoste to appear so he can authorize me on PyPI. [14:03] Morning, all. [14:03] party on [14:04] allenap: what package? [14:04] lazr.uri [14:04] on it [14:06] allenap: what's your pypi username? [14:06] flacoste: gavinpanella [14:06] Thanks! [14:07] allenap: done [14:07] flacoste: Right, now to try and remember the runes, thanks. [14:16] wallyworld, you around still? [14:17] rick_h, wallyworld says in email we need "apache wsgi lib" in dependencies.... he means mod_wsgi? Or something else? [14:18] deryck: right, libapache2-mod-wsgi [14:18] rick_h, right, ok, cool. [14:18] it's not currently a dep since LP doesn't use it yet in the default setup [14:18] rick_h, I'm about to paste you my notes for remaining work, and if it looks good, we can coordinate on launchpad-dev list. [14:18] deryck: ok, sounds good. I'm working on getting their changes from last night up and running [14:19] deryck: they hit issues getting your branch and ours to combine/work [14:19] rick_h, my branch being the multi-yui buildout stuff? [14:19] deryck: right [14:20] deryck: honestly StevenK and I weren't sure what you guys were up to and we never got to merge them before we left [14:20] deryck looks like they got it sorted out last night though, so merging with devel, StevenK, and wallyworld right now to build a super branch with everything together [14:21] rick_h, right, that's what I was going to say.... I read wallyworld's email as saying it was sorted out now. [14:21] deryck: yea, just need to see it to believe it at this point lol [14:23] rick_h, ok, so here's my notes: http://pastebin.ubuntu.com/808615/ [14:24] rick_h, we can discuss on list, but generally, does it look like I've got everything there. anything glaringly missing? [14:24] deryck: looking, sec [14:24] cjwatson, flacoste: lazr.uri 1.0.3 is out. [14:27] allenap: cool. shall I file a Debian bug or have you already done so? [14:27] bah, is there really no way in the pastebin to reply/change a paste without manually copying/pasting? [14:27] nope [14:28] cjwatson: I didn't realise I had opened a can of worms ;) I haven't filed a bug and I don't really know the form for doing so; I'd be grateful if you could do it. [14:28] allenap: it's not a can of worms, just the next step - OK, I'll take care of it [14:29] done [14:29] cjwatson: I was joking, but I started this thinking "I know, I'll do a quick review". I'm happy that it's progressing. [14:31] deryck: http://pastebin.ubuntu.com/808625/ [14:32] abentley, adeuring -- http://pastebin.ubuntu.com/808615/ [14:39] jelmer: how does dailydeb find upstream tarballs? [14:40] bigjools: by tags in the branch [14:40] bigjools: generally speaking, recipe builds should be native [14:41] jelmer: ah ok, I won't worry then, thanks [14:42] allenap: hey, *I* started thinking "I know, I wonder what I can do to help port launchpadlib to Python 3" ... [14:42] still a fair bit left in that stack [14:42] Haha :) [14:42] * bigjools chortles === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 3*10^2 [15:05] sinzui: have a few moments to chat? [15:05] yes [15:06] rick_h: Why do you say to test in google chrome, when the bug is Firefox? Google Chrome is not available on Ubuntu AFAIK. [15:07] abentley: sorry, just force of habit. I ran the updated tests in both browsers and copied the last command I ran [15:07] abentley: updated [15:11] deryck: is there anything we can do to help https://answers.launchpad.net/launchpad/+question/184522 by manually touching the data? [15:11] * deryck looks [15:12] deryck: he's in #launchpad asking and the book is still in progress, but not finding any way to help him right now [15:12] rick_h, I think we need to refer him to ubuntu-sso. sinzui, can you confirm that? (from ^^ question) [15:12] /book/bug/ [15:12] rick_h: r=me [15:12] abentley: ty much [15:15] rick_h, I'll take over on IRC and handle it. [15:15] deryck: ok, thanks [15:20] deryck: I'm the person who has to fix the data in these cases. We had one of these at the Epic and wgrant tracked down and filed bugs on why these problems keep happening. [15:21] stub, ah, ok. Can I assign you the question then? [15:21] deryck: Sure [15:21] stub, awesome! Thanks! [15:22] Just email me if you do that in the future as I seem to never see emails from Questions for some reason I haven't been bothered to investigate. [15:22] stub, will do. [15:25] deryck: fyi, I've done all the merging/conflict resolution and pushed to my use-convoy branch in case you want to shortcut all that [15:30] rick_h, ok, will do, thanks. [15:30] rick_h, and your branch is different from StevenK's branch now? [15:31] deryck: yea, it's merged with devel and the js branch from wallyworld, etc [15:31] rick_h, oh, ok. I thought StevenK had already done that in his branch. [15:31] rick_h, np, though. we just need to let him know. Almost done with my coordination email. === salgado is now known as salgado-brb [15:53] hi sinzui, you doing lp development on precise? [15:54] bac, in a manner of speaking. I am about to put a branch up for review that permits me to run lp and the the test suite. [15:54] sinzui: what did you do about python-tickcount, which precise only packages for 2.7 [15:55] sinzui: i'll be happy to review your branch [15:58] bac, this is my hack http://pastebin.ubuntu.com/808705/ [15:59] sinzui, wow, so LP works with 2.7 with your branch? [16:00] gary_poster, walks, not runs [16:00] :-) [16:00] very cool [16:00] gary_poster, bac: some tests do fail [16:01] good start then === salgado-brb is now known as salgado [16:16] sinzui: your makefile patch does not work for 2.7. it returns 'pythonpython2.6' [16:17] bac: damn. I gave you the non-commited change to support lucid. [16:17] sinzui: oopsie [16:17] it does not work [16:19] bac: this one includes the anchors to only match the full string [16:23] sinzui: cool. so you have a diff? [16:23] http://pastebin.ubuntu.com/808739/ [16:24] ^ That is my entire change to make my branch and run tests [16:36] bac: if my hack works for you, maybe you can approve this so that I can send it to ec2 https://code.launchpad.net/~sinzui/launchpad/precise-makefile-python/+merge/89074 [16:51] lifeless: Any chance of a testresources release? I'd like FixtureResource and use of super(). [16:56] allenap: you expect lifeless to be awake at 6am in NZ? Oh, wait ... [16:56] bigjools: Precisely. [16:56] Pangolin === deryck is now known as deryck[lunch] [18:05] sinzui: done, with one question === deryck[lunch] is now known as deryck [19:17] allenap: yes, sure [19:30] so let's just say someone accidentilly blew away their lp-branches directory... [19:30] and they recreated it using a normal bzr branch as they find in the rocketfuel-setup script [19:30] but now making branches takes forever and a day [19:31] what would someone look at? to get things back where a branch wasn't such a big deal? [19:32] you need a shared repository [19:33] lp-branches should be 'bzr init-repository [--no-trees] lp-branches' [19:33] ah, up a level. Ok, was searching branch options [19:36] then bzr branch lp:launchpad lp-branches/devel [19:36] and you're back to the starting point [19:37] rgr, running that now. Thanks lifeless [19:37] the --no-trees thing is largely personal preference - whether you want to run multiple wokring trees, or one that you switch between [19:37] the rf default is with trees [19:38] yea, I still need to spend some time on my bzr setup to find a happy place === mwhudson_ is now known as mwhudson [20:23] rick_h: If you're starting again, I recommend using bzr-colo instead. Been using it for weeks. [20:24] rick_h: It implements the git-style layout where you have one working tree and many branches. [20:25] lifeless: Thanks. [20:28] rick_h: Also, it can fluidly switch to using pipelines. [20:30] deryck: hey [20:31] hi lifeless [20:33] deryck: a thought on pages that were timing out and don't when we reevaluate; might like to still check for warning signs [20:33] deryck: like high query counts (> 30), slow page (multi second rendering) [20:34] deryck: when I'm not ill, I would also like to catch up w.r.t. root-cause-fix-opportunities, but probably next week is best [20:35] lifeless, ok, sure. I did a basic assessment like that. but re: the 30 count page, we have many that are more than that, right? in fact most, no? [20:35] deryck: I wouldn't say most [20:36] deryck: many pages have a fixed amount of content and a high query count; they generally don't get better or worse; things with batches on them are where it gets bad rapidly [20:36] ok, I'm just going by the query count at the top of the page. I don't find a page with 30 queries or less. [20:37] deryck: aiee :P So, pick a number, 70 then :) [20:37] lifeless, also, I'd love to catch up about the root-cause opportunities stuff as you say. [20:37] deryck: the main thing is the number should be less than the rows in a batch [20:37] lifeless, ah, I follow now. gotchas. [20:50] abentley: thanks, I'll check out the colo stuff. [20:51] rick_h: Cool. Let me know if you have any questions. [21:03] sinzui: do you know why we have both test_team and test_team_view in browser/tests? they seem to be a random selection of browser tests in each. [21:06] jcsackett, both tests were created in separate places, then apocalypse happened [21:06] jcsackett, They can be merged, and maybe checked for duplication [21:06] sinzui: hurray! [21:06] * jcsackett goes to collapse files. [21:06] * sinzui did the same for personset a few weeks ago === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2 [23:14] Hello Precise users, how do I resolve the import errors when doing rocketfuel-get? [23:14] (I'm assuming these are standard issues) [23:16] huwshimi: sinzui was working on that. [23:17] huwshimi: But try hacking Makefile to use python2.7 instead of python2.6 [23:17] Then make clean && make [23:18] lifeless: Around? [23:18] wgrant: OK thanks. It's definitely a version thing because the packages exist [23:18] huwshimi: Yeah, Precise doesn't really do python2.6 [23:19] wgrant: Ah I see [23:29] wallyworld_: Worked out the sorttable date sorttkey stuff? [23:30] nope. on my agenda after breakfast [23:30] Great. [23:30] That's a good idea, actually. [23:31] yeah, can't work when hungry [23:31] at least sorting is mostly fixed after next NDT [23:31] Yeah [23:31] Should be done soon. [23:33] lifeless: Am I likely to be slain if I combine three marginally related DB patches into one for deployment efficiency? [23:33] (-AccountPassword, -EmailAddress.account, +Person.account_status) [23:49] wgrant: The make clean and make worked fine but rocketfuel-get is still failing. Is there another way I can update that might work or something? [23:50] huwshimi: How's it failing? [23:51] wgrant: Sometimes it fails with "ImportError: No module named bzrlib" [23:51] huwshimi: Hm [23:51] wgrant: and others it fails with ImportError: No module named tickcount or something like that [23:51] Sounds like it's still running with python2.6 [23:51] wgrant: I modified the Makefile in devel [23:52] wgrant: And did the make clean/make there [23:52] wgrant: Is that what I was supposed to do? [23:52] So, rocketfuel-get basically just: bzr pull -d ~/launchpad/lp-branches/devel; bzr up ~/launchpad/lp-sourcedeps/download-cache [23:53] And then make [23:56] StevenK: we should land your use-convoy branch today. with your latest change, we should use ${buildout:yui-directory} instead of hardcoding to build/js/yui [23:57] wgrant: Well that all appeared to work [23:58] wgrant: So now how do I do the equivalent hackery instead of doing rocketfuel-branch?