[00:03] StevenK: also, any reason why you didn't go with the symlink? i really think we should have each yui version explicitly untarred into a dir reflecting the version so it's obvious what's what [00:03] wgrant: Hmm... actually it looks like it is branching just not running the make or something so I should be able to just fix the makefile and I'll be fine [00:04] wallyworld_: *Land*? [00:05] StevenK: yes, without the ff, the original launchpad.js will stil lbe used. did you see deryck's email? [00:05] huwshimi: bzr branch devel some-branch [00:05] cd some-branch [00:05] wallyworld_: Not yet [00:05] utilities/link-external-sourcecode ../devel [00:05] make [00:06] StevenK: ok. will let you have a read [00:06] That's basically all rf-branch does [00:06] I've never used rf-branch [00:06] wgrant: Great, thanks [00:10] wallyworld_: The apache config is set in my use-convoy branch -- that's why you had to 'sudo make copy-apache-config' [00:11] StevenK: yeah, that's cool, all sorted yesterday. i think the email was just a summary for everyone else to being them up to speed [00:12] StevenK: so for testing, my plan is to unpack all the yui tarballs to build/js/yui and symlink by default to the prod version. the html files will be updated and tests run by default against prod version [00:13] but we can easily run yuitests locally against another yui version by changing the symlink [00:14] with the combo loader, we can do the same thing, use a symlink for now or just put the yui version in the path in the base-layout-macros tal [00:16] I don't like hacking the base-layout-macros template [00:16] wgrant: OK, hopefully my final issue, but any idea what's up with make run? http://paste.ubuntu.com/809206/ [00:16] it would be hacking - we use a ${yui-version} string substitution [00:16] wouldn't [00:17] You want to edit the template during buildout? [00:17] no, it's done at runtime [00:17] based on the yui version feature flag [00:17] huwshimi: Looks like memcached is not installed [00:17] wgrant: Oh, a few things did get removed with the upgrade [00:18] huwshimi: Try to reinstall launchpad-developer-dependencies [00:18] You may need to reenable ppa:launchpad [00:18] The upgrade probably disabled it. [00:18] wallyworld_: Right [00:18] wgrant: launchpad-developer-dependencies : Depends: launchpad-messagequeue-dependencies (= 0.103~precise1) but it is not going to be installed [00:19] wgrant: I did re-enable the ppa but it 404s [00:19] wgrant: I guess I need to use the oneiric ppa for now? [00:19] huwshimi: Hm, everything should be in precise. What's the 404? [00:19] I fixed it up for wallyworld last week. [00:19] StevenK: so originally we were going to just use a "yui" dir for the prod version, but i do want to use versioned dir names [00:21] wgrant: Oh, nevermind that was for bzr and a couple of other things [00:21] i think that will be much better [00:21] wallyworld_: Right. [00:21] StevenK: so, you could use your "cp -a" and my symlink stuff in rootdir script [00:22] wgrant: So when I try to install the dependencies it gives me the previous error and also says "E: Unable to correct problems, you have held broken packages." [00:22] huwshimi: sudo apt-get -f install [00:22] wallyworld_: Right [00:23] StevenK: so, once your stuff lands, i'll hook off that and update the yui test stuff as proposed above. sound like a plan? [00:24] wgrant: Didn't help [00:24] huwshimi: sudo apt-get install launchpad-messagequeue-dependencies [00:25] wgrant: Oh, that fails because it requires "rabbitmq-management" which doesn't exist [00:25] StevenK: and then another next step would be to update rocketfuel to do the apache config mod, and we can also just disceminate how to do it manually also [00:26] huwshimi: Ahh, of course. Give me a moment. [00:27] hi all [00:28] hellooooo [00:28] wallyworld_: Like I keep saying, we don't need to. [00:28] wallyworld_: I've updated the config -- rf-setup will just pick that up, but people with a development environment already set up will need to do the sudo make I mentioned. [00:28] ok [00:29] ok [00:29] hey wallyworld_ and StevenK how goes? [00:30] * StevenK is Ubuflu'd [00:30] rick_h: hi. goes good. we are just discussing landing the use-convoy branch [00:30] Thinking about complex problems is making me feel worse [00:30] wallyworld_: cool! [00:31] wallyworld_: StevenK did the email summary from deryck make sense? [00:31] StevenK: hopefully no more thinking required :-) just one more tweak to combo-rootdir and the tal [00:31] rick_h: yes [00:31] it reflects my understanding of where we are at [00:32] wallyworld_: ok cool [00:32] I am concerned that our LPS -> YUI change has impacted launchpad.js [00:32] huwshimi: That should be fixed if you apt-get update in about 5 minutes [00:32] StevenK: very good point [00:33] wgrant: Sweet. Thanks a lot [00:33] StevenK: so what the LPS thing did was set the config variables, and carry that on to everyong using LPS() [00:33] We've been so focused on the combo loader that we haven't checked if it's safe to land [00:33] StevenK: so now that we set YUI_config and all LPS. are changed to YUI(). [00:33] StevenK: rick_h: we attempted to make out YUI replacement functionally equivalent to LPS, no? [00:33] StevenK: we shold be ok [00:33] wallyworld_: So, what do I need to do? [00:34] StevenK: we should be good where we are at currently. As long as the YUI_config is set with the old optoins passed into the LPS() call, we're ok [00:34] StevenK: i can do the work locally, push up to my branch, and you can just merge if you like [00:34] StevenK: which the feature flag switch does [00:34] rick_h: Right, which we did. [00:34] StevenK: if you turn off the feature flag and try out the site it should work just peachy still as is with the YUI() [00:34] StevenK: i also need to merge in trunk and update those new cases of LPS usage [00:35] wallyworld_: So I'm waiting for you? [00:35] Right, LPS just goes away [00:35] for both launchpad.js and the combo loader [00:35] StevenK: yes. i'll do it now and ping you when done [00:36] rick_h: and hopefully by SOD for you it will be merged [00:36] wallyworld_: excellent, so reading the traceback the apache stuff is in place? [00:36] wallyworld_: can you note that step in the email exchange for deryck and I? [00:36] It has been since last week [00:36] that was the only thinking keeping me from getting it running today [00:36] well, packaging deps need to be done too etc [00:37] wallyworld_: right [00:37] wallyworld_, rick_h: We need to get it reviewed too? [00:37] yes [00:37] StevenK: did you see the branch of convoy I've got with the directory parsing stuff? [00:37] I chatted with rockstar about it and either he or another guy will review it soon hopefully [00:37] rick_h: I saw that it existed, I've not looked at it [00:37] StevenK: i can review if you do the mp if you want [00:37] StevenK: yea, I think I'd like to get a final run of it locally and run it through some paces as review before we pushed [00:38] rick_h: part of my review would also have been to test locally [00:38] and I'm sure there must be a test or two somewhere that will blow up [00:38] wallyworld_: gotcha, ok cool [00:38] getting nervous myself now :) [00:38] rick_h: tests won't use combo loader to start with [00:39] wallyworld_: right, but I'm assuming something goes boom. Maybe we get lucky :) [00:40] rick_h: hope so. we'll find out soon enough when we do the final pre-land testing [00:40] rick_h: worst case, we hand off something to you because we find issues today [00:41] and you/deryck can land tomorrow [00:41] ok awesome [00:41] * rick_h crosses fingers for you guys [00:41] or if we get nervous and wimp out, we wil lhand off also :-) [00:42] * wallyworld_ goes to set up in a cooler room. it's hot here today [00:42] 24 here [00:42] coolish here but *humid* [00:43] But due to Ubuflu, I feel like I'm burning up [00:43] StevenK: i'll try not to bother you anymore. you should go away from keyboard and lie down [00:44] * StevenK is sorely tempted [00:45] I could also walk to the doctors, but that may require too much effort [00:45] go do that. i'll do everything from here and put up the mp. and it can be review by the us guys tomorrow [00:46] bah. plugged laptop into dock and mouse all fucked up. can't click anywhere [00:47] rick_h: i'll email where we get to today [00:48] StevenK: [00:48] wallyworld_: ok, sounds like a plan. I'm hacking with some guys on other stuff tonight for the next couple of hours. Ping me if you need anything [00:48] rick_h: will do. having trouble typing now. need to reboot :-( [00:49] random windows getting focus [00:57] * StevenK kicks wallyworld_ for top-posting [00:57] StevenK: sorry, my keyboard and mouse got all stuffed up [00:58] and the wrong window captured by Enter keypress [00:58] wallyworld_: https://code.launchpad.net/~stevenk/meta-lp-deps/use-convoy/+merge/89174 but the diff isn't generating [00:59] * wallyworld_ looks if ff would start without consuming 100% cpu [00:59] love the description [01:00] wgrant: Awesome. Dependencies installed and make run is working. Thanks for you help :) [01:02] StevenK: so that looks ok to me. should we land it now? [01:03] meta-lp-deps? No [01:04] Hmm. importfascist still has database_root = 'canonical.launchpad.database', and is thus presumably ineffectual [01:07] I think utilities/migrater can die too [01:12] StevenK, I started on that. I am porting rename_module because it provides refactoring goodness [01:13] Heh. I just put up a branch and MP that removes it [01:13] StevenK: you are supposed to be sick remember [01:14] cjwatson, importfascist does not know about model or the many security checkers. It needs an overhaul [01:14] wallyworld_: Silence. [01:17] * wallyworld_ happy that there were only 2 conflicts merging trunk into use-combo branch [01:24] sinzui: Oh, right, your tool is seperate. I shall land it then [01:24] yes. [01:24] bazaar.lp.net seems to be having several timeouts atm [01:25] I used my own tool, to refactor my plugins over the weekend, then thought, I should incorporate it into the plugins when I am sure it works [01:50] huwshimi: Great. [01:51] StevenK: rename-module is important. Must keep that [01:51] cjwatson: Yeah, most of the fascist is useless nowadays. [01:51] cjwatson: There were rumours a couple of years back that we were going to steal landscape's import guardian. [02:26] StevenK: Are you arranging for someone to apply the index live today? [03:04] wgrant: I was going to talk to stub about it now that the patch has landed. [03:04] OK. It need to be today or tomorrow morning. [03:06] To not impact on FDT? [03:07] wgrant: combining those three into one is fine; as long as we land; qa; etc one patch, I don't really care how big it is (textually that is :P) [03:08] StevenK: Yes [03:08] Although I may end up doing ppa/ftpmaster tomorrow night instead, depending on what happens. [03:42] wgrant: No, you should destroy EmailAddress.account harder [03:48] StevenK: Need a ppa/ftpmaster deployment first. [03:49] Pity. [03:49] BAH, using Link doesn't work. [03:49] Why is this bug so hard? It should be easy. :-( [03:49] Which? [03:49] Tags? [03:52] Yup [03:53] \n <lp.services.webapp.menu.LinkData object at 0x113c1850>\n [03:54] Why are you trying to use Links? [03:54] They're for menus. [03:54] I should build the entire Or just the URL. [03:55] Oh, a dict of tag: url? [03:55] Possibly, yes. [04:01] wgrant: I can't say tal:repeat="tag url view/official_tags" for a dict? [04:02] Recall that iterating over a dict gives the keys. [04:02] Right, what I'm unsure about is how to get out the value in the tal [04:04] You may have to use python: [04:05] Unless you can unpack the tuple from .items() in TAL [04:10] Maybe we just make a list of 2-tuples [04:11] That provides no benefit over .items [04:13] * StevenK tries .items() [04:16] zope.tal.taldefs.TALError: Invalid variable name "official_tags.items()" in expression u\'url view/official_tags.items() [04:16] Do you mean view/official_tags/items? [04:16] This is TALES, not Python. [04:17] Everytime I learn something about TALES, my brain rejects it as pure crack. [04:18] zope.tal.taldefs.TALError: Invalid variable name "items" in expression u\'url view/official_tags/items\' [04:31] wgrant: tal:repeat="tag view/official_tags/items" throws a KeyError of items [04:32] StevenK: Is it a dict? [04:33] view/official_tags is, yes [04:34] In devel it's not. [04:35] It is in this branch I'm hacking on [04:37] Can you pastebin the diff or push the branch? [04:40] wgrant: http://pastebin.ubuntu.com/809335/ [04:45] StevenK: Oh, of course. [04:45] StevenK: It's a dict, so it tries to look up the 'items' key rather than looking up an attribute. [04:47] Hah [04:49] tal:repeat="tag url view/..." didn't work either. I guess tal only wants one item [04:50] ZPT doesn't do tuple unpacking, no. [04:50] But we can't even get to that stage, since we can't call items() [04:51] So, iterate of the keys and then do lookups. [04:51] s/of/over/ [04:51] I'm unclear how to do the lockups [04:51] *lookups, sigh [04:51] view/official_tags/?key [04:52] ? uses the rest of the path segment as a variable name. [05:33] wallyworld_: Can haz review? https://code.launchpad.net/~stevenk/launchpad/link-bug-tags-correctly/+merge/89187 [05:34] StevenK: one sec otp. [05:38] sinzui: Do you mean [ `lsb_release -c -s` = "precise" ] ? :) [05:43] StevenK: canonical_url you can pass +bugs as the view_name [05:47] StevenK: does "view/unofficial_tags/?tag" do a dict lookup? [05:47] wallyworld_: Fixed locally. And yes, it does. [05:48] Because TAL is just fucked. [05:48] cool. i didn't know that [05:48] wallyworld_: [15:17] < StevenK> Everytime I learn something about TALES, my brain rejects it as pure crack. [05:48] lol [05:49] StevenK: i'll go in and +1 it [05:49] StevenK: i've found and fixed a number of things with the use-combo branch, just a couple more to go [05:50] wallyworld_: Excellent. I shall commit and push the view_name change. [06:01] rick_h: WRT to your convoy MP, I was expecting we'd have /+combo/r14335/ and then something like /+combo/r14436/ ? [06:03] wallyworld_: I've tossed that branch at ec2. Thanks for +1. [06:03] wallyworld_: I've also tossed a Lucid package of convoy at my PPA. [06:04] StevenK: np. excellent. it's all coming together :-) [06:04] wallyworld_, is it now the case that private bugs can have only one task? [06:04] poolie: yes, unless you are in oem or whatever the team is we have excluded form that [06:04] from [06:04] k [06:05] poolie: is that ok? do you have a case where it's not? [06:05] wallyworld_: I thought sinzui said the footgun was no longer required? [06:05] it's fine [06:05] i have a thing affecting a private project that will also affect another [06:05] but it's fine to create a second bug [06:05] in fact better [06:05] StevenK: the current implementation still has the restriction [06:06] poolie: when "we" do bug linking, a lot of the reasons for any bugs to have more than one bug task should hopefully be a lot less [06:06] yep [06:06] poolie: did you see that translation question in #bzr [06:07] wallyworld_: What sort of issues have you seen, by the way? [06:08] StevenK: calendars were broken. there was a case where a conflict resolution cut out a bunch of tal. milestone timelines were broken. some legacy js issues resulting in yui load errors with the rejigging in the tal [06:08] that sort of stuff [06:09] wallyworld_: With the FF disabled or enabled? [06:09] there's now just a build issue wrt a symlink and all those cannot load sam-asset messages [06:09] StevenK: disabled [06:09] wallyworld_: I misunderstood your use of the symlink, so feel free to make that change. [06:10] wallyworld_: Although I don't like the idea of putting the yui versions in buildout.cfg [06:10] StevenK: i think its a different issue [06:10] can a superuser please change the maintainer of /awsproxy from ~jelmer to ~awsproxy-core? [06:10] StevenK: we can iterate on that [06:13] StevenK: i've best testing with ff off so we can deploy asap. most of the issues found would also have been there with ff on [06:13] s/deploy/land [06:14] Right [06:21] * wallyworld_ needs to go and buy more coffee [06:35] Hi stub. [06:36] yp [06:36] yo even [06:36] Can you live-apply that new index some time today? [06:36] It has landed. [06:37] ok [07:19] * StevenK stabs the messaging indicator [07:58] morning folks [07:58] wgrant: I see that TTBJ.updateBuild_WAITING lacks read-write transaction policy. [07:59] jtv: Quite possibly. [07:59] But I thought there was a bug on that. [08:51] Anyone mind if I upgrade dogfood? [08:56] cjwatson: Go ahead [09:01] good morning [09:09] Hi === almaisan-away is now known as al-maisan [09:55] Why is the oops-tools project deactivated in Launchpad? [09:55] jtv: Because it was replaced by python-oops-tools [09:55] Ah [09:55] thanks [09:55] (which is a continuation of the same codebase, but without the proprietary history) === al-maisan is now known as almaisan-away [10:01] OMG. [10:01] The new oops page is *AMAZING* [10:05] It's the DB outage page. Sadly the OOPS page hasn't been upgraded to be pretty yet. [10:05] All huwshimi's work. [10:06] :) [10:06] I should find him and give him a hug. [10:06] If that's the baseline for how launchpad will be in the near future, I'm going to be very happy :) [10:07] the sad face page? [10:07] Yeah. [10:07] yeah, that's cute [10:07] Its got a fresher UI than *cough* most of Launchpad [10:08] wgrant: did we ever switch LP monospace fonts to ubuntu font? [10:08] nigelb: Yeah, because we have bugs about how small it is :) [10:08] But I don't think we use webfonts for them. [10:09] Webfonts is what I meant. [10:09] * nigelb contemplates doing that after finshing existing branches [10:10] Laney: Your DB patch is deployed. [10:10] And now in devel. [10:10] cool [10:10] what is next? Trying to land the other one? [10:10] The code that uses the patch? Yep? [10:10] s/?$/./ [10:10] Laney: https://dev.launchpad.net/Contributions \m/ [10:11] (look at 16) [10:11] heh [10:15] Eventually, someone will beat wgrant :P [10:16] I hope so :) [10:16] If only I had more free time. [10:16] hey, did I hear that longpoll was done? [10:17] It works, but it has one remaining major bug. [10:17] Which is pretty easily fixable. [10:17] (client-side per-host connection limits suck) [10:17] So if you open a few MPs, all Launchpad requests hang. [10:17] Because the browser tries to avoid DoSing. [10:17] dammit. [10:18] That's counterproductive :) [10:18] wgrant: heh, so it's a matter of fixing the bug and then flicking a switch for MPs? [10:18] jml: Yup [10:18] jml: Well, more of a gradual dial. [10:18] wgrant: heh :) [10:19] wgrant: that's cool. [10:19] We have little idea how this will scale. === almaisan-away is now known as al-maisan [10:21] yeah, fair enough. [11:14] morning folks [11:15] Morning rick_h. === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [11:52] Morning rick_h! [11:52] howdy nigelb [11:54] rick_h: i sent you a big email, let me know if there's anything needed clarification [11:55] wallyworld_: yea looking. I was curious if the not loading messages were due to http://yuilibrary.com/projects/yui3/ticket/2530983 [11:55] but that's for 3.4 so guess not [11:55] wallyworld_: did you see if the modules were missing from the combo'd file? [11:55] sigh, this QA is going to involve comparing three getPublishedSources calls on dogfood [11:55] * cjwatson snoozes [11:55] cjwatson: why not qastaging? [11:56] rick_h: i'm almost sure they were there. but that ticket looks suspiciously familair to others i saw. i think the warnings in our case are bogus [11:56] hmm, I suppose Archive.copyPackages mght work on qas? [11:56] wallyworld_: I'm hesitant to go with the LP_YUI change because it's not what's going on in U1 and I've not seen that as a regular pattern. So I'm wondering if there's something else that's the root in there [11:57] wallyworld_: right, that's what I'm wondering if the warnings are more a YUI bug than our bug [11:57] rick_h: i don't understand why we would want to incur the cost and overhead of instantiating multiple yui instances, plus the not loaded warnings/errors are a direct result of doing that [11:57] wallyworld_: I guess I'd be curious if we upgraded to 3.4 and ran to see if they still occurred [11:57] wallyworld_: right, but there's potential for one LP_YUI instance to change a config/setting that blows up down the road [11:58] in our usage, i don't think that's an issue [11:58] wallyworld_: so it's the old cost of keeping the blocks independant other than the global config, or running into potential issues chasing bugs in one .pt files that's caused by something somewhere else entirely [11:58] moving forward, we would want to consolidate all those little snippets anyway [11:58] wallyworld_: and we're not hitting any performance issues atm anyway [11:59] wallyworld_: true [11:59] rick_h: remember that till now, we've always operated on asingle YUI instance [11:59] wallyworld_: ok, I'll peek at it. Thanks for the hard work and the summary. [11:59] so we are just sticking with our current modus operendi [11:59] wallyworld_: right, I'm just trying to "do the right thing" if we're heading down this path anyway [11:59] np [12:00] while we're blowing up the world, blow it up all the way :) [12:00] agreed, we do need to start adopting best practice [12:00] I'll peek at what I can find. It might be the best thing to do, just saying my initial reaction is "ugh, that doesn't seem right" [12:00] but i don't follow how creating all these yui objects is best practice [12:01] like I was saying, each YUI() sets up it's own wrapped JS world that [12:01] no other YUI() should be able to interfere with another [12:01] so you're safe to defined your own requires, your own settings, etc. No global leakage, etc. [12:01] it's not a ton since really there's 3-6 of those a page [12:02] so 3-6 new JS objects per page isn't going to cause any issues [12:02] agreed. but in our case, all these little snippets really belong together i nthe one sandboc [12:02] yea, eventually we'd want to have some sort of system for injecting JS/requires into a single YUI()... block on each page [12:02] it would be ok ig yui didn't pollute the console with all these bloody errors [12:02] hard t know if they're really genuine :-( [12:06] wallyworld_: right. thanks for the heads up. We'll get it worked out. [12:06] ok :-) [12:14] I wonder if there is a way to get the template name in a global tal macro [12:14] And then include