[00:03] <wallyworld_> 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] <huwshimi> 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] <StevenK> wallyworld_: *Land*?
[00:05] <wallyworld_> StevenK: yes, without the ff, the original launchpad.js will stil lbe used. did you see deryck's email?
[00:05] <wgrant> huwshimi: bzr branch devel some-branch
[00:05] <wgrant> cd some-branch
[00:05] <StevenK> wallyworld_: Not yet
[00:05] <wgrant> utilities/link-external-sourcecode ../devel
[00:05] <wgrant> make
[00:06] <wallyworld_> StevenK: ok. will let you have a read
[00:06] <wgrant> That's basically all rf-branch does
[00:06] <wgrant> I've never used rf-branch
[00:06] <huwshimi> wgrant: Great, thanks
[00:10] <StevenK> wallyworld_: The apache config is set in my use-convoy branch -- that's why you had to 'sudo make copy-apache-config'
[00:11] <wallyworld_> 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] <wallyworld_> 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] <wallyworld_> but we can easily run yuitests locally against another yui version by changing the symlink
[00:14] <wallyworld_> 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] <StevenK> I don't like hacking the base-layout-macros template
[00:16] <huwshimi> wgrant: OK, hopefully my final issue, but any idea what's up with make run? http://paste.ubuntu.com/809206/
[00:16] <wallyworld_> it would be hacking - we use a ${yui-version} string substitution
[00:16] <wallyworld_> wouldn't
[00:17] <StevenK> You want to edit the template during buildout?
[00:17] <wallyworld_> no, it's done at runtime
[00:17] <wallyworld_> based on the yui version feature flag
[00:17] <wgrant> huwshimi: Looks like memcached is not installed
[00:17] <huwshimi> wgrant: Oh, a few things did get removed with the upgrade
[00:18] <wgrant> huwshimi: Try to reinstall launchpad-developer-dependencies
[00:18] <wgrant> You may need to reenable ppa:launchpad
[00:18] <wgrant> The upgrade probably disabled it.
[00:18] <StevenK> wallyworld_: Right
[00:18] <huwshimi> wgrant: launchpad-developer-dependencies : Depends: launchpad-messagequeue-dependencies (= 0.103~precise1) but it is not going to be installed
[00:19] <huwshimi> wgrant: I did re-enable the ppa but it 404s
[00:19] <huwshimi> wgrant: I guess I need to use the oneiric ppa for now?
[00:19] <wgrant> huwshimi: Hm, everything should be in precise. What's the 404?
[00:19] <wgrant> I fixed it up for wallyworld last week.
[00:19] <wallyworld_> 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] <huwshimi> wgrant: Oh, nevermind that was for bzr and a couple of other things
[00:21] <wallyworld_> i think that will be much better
[00:21] <StevenK> wallyworld_: Right.
[00:21] <wallyworld_> StevenK: so, you could use your "cp -a" and my symlink stuff in rootdir script
[00:22] <huwshimi> 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] <wgrant> huwshimi: sudo apt-get -f install
[00:22] <StevenK> wallyworld_: Right
[00:23] <wallyworld_> 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] <huwshimi> wgrant: Didn't help
[00:24] <wgrant> huwshimi: sudo apt-get install launchpad-messagequeue-dependencies
[00:25] <huwshimi> wgrant: Oh, that fails because it requires "rabbitmq-management" which doesn't exist
[00:25] <wallyworld_> 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] <wgrant> huwshimi: Ahh, of course. Give me a moment.
[00:27] <poolie> hi all
[00:28] <wallyworld_> hellooooo
[00:28] <StevenK> wallyworld_: Like I keep saying, we don't need to.
[00:28] <StevenK> 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] <wallyworld_> ok
[00:29] <wallyworld_> ok
[00:29] <rick_h> hey wallyworld_ and StevenK how goes?
[00:30]  * StevenK is Ubuflu'd
[00:30] <wallyworld_> rick_h: hi. goes good. we are just discussing landing the use-convoy branch
[00:30] <StevenK> Thinking about complex problems is making me feel worse
[00:30] <rick_h> wallyworld_: cool!
[00:31] <rick_h> wallyworld_: StevenK did the email summary from deryck make sense?
[00:31] <wallyworld_> StevenK: hopefully no more thinking required :-) just one more tweak to combo-rootdir and the tal
[00:31] <wallyworld_> rick_h: yes
[00:31] <wallyworld_> it reflects my understanding of where we are at
[00:32] <rick_h> wallyworld_: ok cool
[00:32] <StevenK> I am concerned that our LPS -> YUI change has impacted launchpad.js
[00:32] <wgrant> huwshimi: That should be fixed if you apt-get update in about 5 minutes
[00:32] <rick_h> StevenK: very good point
[00:33] <huwshimi> wgrant: Sweet. Thanks a lot
[00:33] <rick_h> StevenK: so what the LPS thing did was set the config variables, and carry that on to everyong using LPS()
[00:33] <StevenK> We've been so focused on the combo loader that we haven't checked if it's safe to land
[00:33] <rick_h> StevenK: so now that we set YUI_config and all LPS. are changed to YUI().
[00:33] <wallyworld_> StevenK: rick_h: we attempted to make out YUI replacement functionally equivalent to LPS, no?
[00:33] <rick_h> StevenK: we shold be ok
[00:33] <StevenK> wallyworld_: So, what do I need to do?
[00:34] <rick_h> 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] <wallyworld_> StevenK: i can do the work locally, push up to my branch, and you can just merge if you like
[00:34] <rick_h> StevenK: which the feature flag switch does
[00:34] <StevenK> rick_h: Right, which we did.
[00:34] <rick_h> 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] <wallyworld_> StevenK: i also need to merge in trunk and update those new cases of LPS usage
[00:35] <StevenK> wallyworld_: So I'm waiting for you?
[00:35] <rick_h> Right, LPS just goes away
[00:35] <rick_h> for both launchpad.js and the combo loader
[00:35] <wallyworld_> StevenK: yes. i'll do it now and ping you when done
[00:36] <wallyworld_> rick_h: and hopefully by SOD for you it will be merged
[00:36] <rick_h> wallyworld_: excellent, so reading the traceback the apache stuff is in place?
[00:36] <rick_h> wallyworld_: can you note that step in the email exchange for deryck and I?
[00:36] <StevenK> It has been since last week
[00:36] <rick_h> that was the only thinking keeping me from getting it running today
[00:36] <wallyworld_> well, packaging deps need to be done too etc
[00:37] <rick_h> wallyworld_: right
[00:37] <StevenK> wallyworld_, rick_h: We need to get it reviewed too?
[00:37] <wallyworld_> yes
[00:37] <rick_h> StevenK: did you see the branch of convoy I've got with the directory parsing stuff?
[00:37] <rick_h> I chatted with rockstar about it and either he or another guy will review it soon hopefully
[00:37] <StevenK> rick_h: I saw that it existed, I've not looked at it
[00:37] <wallyworld_> StevenK: i can review if you do the mp if you want
[00:37] <rick_h> 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] <wallyworld_> rick_h: part of my review would also have been to test locally
[00:38] <rick_h> and I'm sure there must be a test or two somewhere that will blow up
[00:38] <rick_h> wallyworld_: gotcha, ok cool
[00:38] <rick_h> getting nervous myself now :)
[00:38] <wallyworld_> rick_h: tests won't use combo loader to start with
[00:39] <rick_h> wallyworld_: right, but I'm assuming something goes boom. Maybe we get lucky :)
[00:40] <wallyworld_> rick_h: hope so. we'll find out soon enough when we do the final pre-land testing
[00:40] <wallyworld_> rick_h: worst case, we hand off something to you because we find issues today
[00:41] <wallyworld_> and you/deryck can land tomorrow
[00:41] <rick_h> ok awesome
[00:41]  * rick_h crosses fingers for you guys
[00:41] <wallyworld_> 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] <StevenK> 24 here
[00:42] <wallyworld_> coolish here but *humid*
[00:43] <StevenK> But due to Ubuflu, I feel like I'm burning up
[00:43] <wallyworld_> 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] <StevenK> I could also walk to the doctors, but that may require too much effort
[00:45] <wallyworld_> 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] <wallyworld_> bah. plugged laptop into dock and mouse all fucked up. can't click anywhere
[00:47] <wallyworld_> rick_h: i'll email where we get to today
[00:48] <wallyworld_> StevenK:
[00:48] <rick_h> 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] <wallyworld_> rick_h: will do. having trouble typing now. need to reboot :-(
[00:49] <wallyworld_> random windows getting focus
[00:57]  * StevenK kicks wallyworld_ for top-posting
[00:57] <wallyworld_> StevenK: sorry, my keyboard and mouse got all stuffed up
[00:58] <wallyworld_> and the wrong window captured by Enter keypress
[00:58] <StevenK> 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] <wallyworld_> love the description
[01:00] <huwshimi> wgrant: Awesome. Dependencies installed and make run is working. Thanks for you help :)
[01:02] <wallyworld_> StevenK: so that looks ok to me. should we land it now?
[01:03] <StevenK> meta-lp-deps? No
[01:04] <cjwatson> Hmm.  importfascist still has database_root = 'canonical.launchpad.database', and is thus presumably ineffectual
[01:07] <StevenK> I think utilities/migrater can die too
[01:12] <sinzui> StevenK, I started on that. I am porting rename_module because it provides refactoring goodness
[01:13] <StevenK> Heh. I just put up a branch and MP that removes it
[01:13] <wallyworld_> StevenK: you are supposed to be sick remember
[01:14] <sinzui> cjwatson, importfascist does not know about model or the many security checkers. It needs an overhaul
[01:14] <StevenK> wallyworld_: Silence.
[01:17]  * wallyworld_ happy that there were only 2 conflicts merging trunk into use-combo branch
[01:24] <StevenK> sinzui: Oh, right, your tool is seperate. I shall land it then
[01:24] <sinzui> yes.
[01:24] <wallyworld_> bazaar.lp.net seems to be having several timeouts atm
[01:25] <sinzui> I used my own tool, <not a euphanism> to refactor my plugins over the weekend, then thought, I should incorporate it into the plugins when I am sure it works
[01:50] <wgrant> huwshimi: Great.
[01:51] <wgrant> StevenK: rename-module is important. Must keep that
[01:51] <wgrant> cjwatson: Yeah, most of the fascist is useless nowadays.
[01:51] <wgrant> cjwatson: There were rumours a couple of years back that we were going to steal landscape's import guardian.
[02:26] <wgrant> StevenK: Are you arranging for someone to apply the index live today?
[03:04] <StevenK> wgrant: I was going to talk to stub about it now that the patch has landed.
[03:04] <wgrant> OK. It need to be today or tomorrow morning.
[03:06] <StevenK> To not impact on FDT?
[03:07] <lifeless> 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] <wgrant> StevenK: Yes
[03:08] <wgrant> Although I may end up doing ppa/ftpmaster tomorrow night instead, depending on what happens.
[03:42] <StevenK> wgrant: No, you should destroy EmailAddress.account harder
[03:48] <wgrant> StevenK: Need a ppa/ftpmaster deployment first.
[03:49] <StevenK> Pity.
[03:49] <StevenK> BAH, using Link doesn't work.
[03:49] <StevenK> Why is this bug so hard? It should be easy. :-(
[03:49] <wgrant> Which?
[03:49] <wgrant> Tags?
[03:52] <StevenK> Yup
[03:53] <StevenK> <span id="tag-list">\n              &lt;lp.services.webapp.menu.LinkData object at 0x113c1850&gt;\n
[03:54] <wgrant> Why are you trying to use Links?
[03:54] <wgrant> They're for menus.
[03:54] <StevenK> I should build the entire <a href=... in the view property?
[03:55] <wgrant> Or just the URL.
[03:55] <StevenK> Oh, a dict of tag: url?
[03:55] <wgrant> Possibly, yes.
[04:01] <StevenK> wgrant: I can't say tal:repeat="tag url view/official_tags" for a dict?
[04:02] <wgrant> Recall that iterating over a dict gives the keys.
[04:02] <StevenK> Right, what I'm unsure about is how to get out the value in the tal
[04:04] <wgrant> You may have to use python:
[04:05] <wgrant> Unless you can unpack the tuple from .items() in TAL
[04:10] <StevenK> Maybe we just make a list of 2-tuples
[04:11] <wgrant> That provides no benefit over .items
[04:13]  * StevenK tries .items()
[04:16] <StevenK> zope.tal.taldefs.TALError: Invalid variable name "official_tags.items()" in expression u\'url view/official_tags.items()
[04:16] <wgrant> Do you mean view/official_tags/items?
[04:16] <wgrant> This is TALES, not Python.
[04:17] <StevenK> Everytime I learn something about TALES, my brain rejects it as pure crack.
[04:18] <StevenK> zope.tal.taldefs.TALError: Invalid variable name "items" in expression u\'url view/official_tags/items\'
[04:31] <StevenK> wgrant: tal:repeat="tag view/official_tags/items" throws a KeyError of items
[04:32] <wgrant> StevenK: Is it a dict?
[04:33] <StevenK> view/official_tags is, yes
[04:34] <wgrant> In devel it's not.
[04:35] <StevenK> It is in this branch I'm hacking on
[04:37] <wgrant> Can you pastebin the diff or push the branch?
[04:40] <StevenK> wgrant: http://pastebin.ubuntu.com/809335/
[04:45] <wgrant> StevenK: Oh, of course.
[04:45] <wgrant> StevenK: It's a dict, so it tries to look up the 'items' key rather than looking up an attribute.
[04:47] <StevenK> Hah
[04:49] <StevenK> tal:repeat="tag url view/..." didn't work either. I guess tal only wants one item
[04:50] <wgrant> ZPT doesn't do tuple unpacking, no.
[04:50] <wgrant> But we can't even get to that stage, since we can't call items()
[04:51] <wgrant> So, iterate of the keys and then do lookups.
[04:51] <wgrant> s/of/over/
[04:51] <StevenK> I'm unclear how to do the lockups
[04:51] <StevenK> *lookups, sigh
[04:51] <wgrant> view/official_tags/?key
[04:52] <wgrant> ? uses the rest of the path segment as a variable name.
[05:33] <StevenK> wallyworld_: Can haz review? https://code.launchpad.net/~stevenk/launchpad/link-bug-tags-correctly/+merge/89187
[05:34] <wallyworld_> StevenK: one sec otp.
[05:38] <wgrant> sinzui: Do you mean [ `lsb_release -c -s` = "precise" ] ? :)
[05:43] <wallyworld_> StevenK: canonical_url you can pass +bugs as the view_name
[05:47] <wallyworld_> StevenK: does "view/unofficial_tags/?tag" do a dict lookup?
[05:47] <StevenK> wallyworld_: Fixed locally. And yes, it does.
[05:48] <StevenK> Because TAL is just fucked.
[05:48] <wallyworld_> cool. i didn't know that
[05:48] <StevenK> wallyworld_: [15:17] < StevenK> Everytime I learn something about TALES, my brain rejects it as pure crack.
[05:48] <wallyworld_> lol
[05:49] <wallyworld_> StevenK: i'll go in and +1 it
[05:49] <wallyworld_> StevenK: i've found and fixed a number of things with the use-combo branch, just a couple more to go
[05:50] <StevenK> wallyworld_: Excellent. I shall commit and push the view_name change.
[06:01] <StevenK> rick_h: WRT to your convoy MP, I was expecting we'd have /+combo/r14335/ and then something like /+combo/r14436/ ?
[06:03] <StevenK> wallyworld_: I've tossed that branch at ec2. Thanks for +1.
[06:03] <StevenK> wallyworld_: I've also tossed a Lucid package of convoy at my PPA.
[06:04] <wallyworld_> StevenK: np. excellent. it's all coming together :-)
[06:04] <poolie> wallyworld_, is it now the case that private bugs can have only one task?
[06:04] <wallyworld_> poolie: yes, unless you are in oem or whatever the team is we have excluded form that
[06:04] <wallyworld_> from
[06:04] <poolie> k
[06:05] <wallyworld_> poolie: is that ok? do you have a case where it's not?
[06:05] <StevenK> wallyworld_: I thought sinzui said the footgun was no longer required?
[06:05] <poolie> it's fine
[06:05] <poolie> i have a thing affecting a private project that will also affect another
[06:05] <poolie> but it's fine to create a second bug
[06:05] <poolie> in fact better
[06:05] <wallyworld_> StevenK: the current implementation still has the restriction
[06:06] <wallyworld_> 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] <poolie> yep
[06:06] <wallyworld_> poolie: did you see that translation question in #bzr
[06:07] <StevenK> wallyworld_: What sort of issues have you seen, by the way?
[06:08] <wallyworld_> 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] <wallyworld_> that sort of stuff
[06:09] <StevenK> wallyworld_: With the FF disabled or enabled?
[06:09] <wallyworld_> there's now just a build issue wrt a symlink and all those cannot load sam-asset messages
[06:09] <wallyworld_> StevenK: disabled
[06:09] <StevenK> wallyworld_: I misunderstood your use of the symlink, so feel free to make that change.
[06:10] <StevenK> wallyworld_: Although I don't like the idea of putting the yui versions in buildout.cfg
[06:10] <wallyworld_> StevenK: i think its a different issue
[06:10] <poolie> can a superuser please change the maintainer of /awsproxy from ~jelmer to ~awsproxy-core?
[06:10] <wallyworld_> StevenK: we can iterate on that
[06:13] <wallyworld_> 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] <wallyworld_> s/deploy/land
[06:14] <StevenK> Right
[06:21]  * wallyworld_ needs to go and buy more coffee
[06:35] <wgrant> Hi stub.
[06:36] <stub> yp
[06:36] <stub> yo even
[06:36] <wgrant> Can you live-apply that new index some time today?
[06:36] <wgrant> It has landed.
[06:37] <stub> ok
[07:19]  * StevenK stabs the messaging indicator
[07:58] <jtv> morning folks
[07:58] <jtv> wgrant: I see that TTBJ.updateBuild_WAITING lacks read-write transaction policy.
[07:59] <wgrant> jtv: Quite possibly.
[07:59] <wgrant> But I thought there was a bug on that.
[08:51] <cjwatson> Anyone mind if I upgrade dogfood?
[08:56] <wgrant> cjwatson: Go ahead
[09:01] <adeuring> good morning
[09:09] <mrevell> Hi
[09:55] <jtv> Why is the oops-tools project deactivated in Launchpad?
[09:55] <wgrant> jtv: Because it was replaced by python-oops-tools
[09:55] <jtv> Ah
[09:55] <jtv> thanks
[09:55] <wgrant> (which is a continuation of the same codebase, but without the proprietary history)
[10:01] <nigelb> OMG.
[10:01] <nigelb> The new oops page is *AMAZING*
[10:05] <wgrant> It's the DB outage page. Sadly the OOPS page hasn't been upgraded to be pretty yet.
[10:05] <wgrant> All huwshimi's work.
[10:06] <nigelb> :)
[10:06] <nigelb> I should find him and give him a hug.
[10:06] <nigelb> If that's the baseline for how launchpad will be in the near future, I'm going to be very happy :)
[10:07] <Laney> the sad face page?
[10:07] <nigelb> Yeah.
[10:07] <Laney> yeah, that's cute
[10:07] <nigelb> Its got a fresher UI than *cough* most of Launchpad
[10:08] <nigelb> wgrant: did we ever switch LP monospace fonts to ubuntu font?
[10:08] <wgrant> nigelb: Yeah, because we have bugs about how small it is :)
[10:08] <wgrant> But I don't think we use webfonts for them.
[10:09] <nigelb> Webfonts is what I meant.
[10:09]  * nigelb contemplates doing that after finshing existing branches
[10:10] <wgrant> Laney: Your DB patch is deployed.
[10:10] <wgrant> And now in devel.
[10:10] <Laney> cool
[10:10] <Laney> what is next? Trying to land the other one?
[10:10] <wgrant> The code that uses the patch? Yep?
[10:10] <wgrant> s/?$/./
[10:10] <nigelb> Laney: https://dev.launchpad.net/Contributions \m/
[10:11] <nigelb> (look at 16)
[10:11] <Laney> heh
[10:15] <nigelb> Eventually, someone will beat wgrant :P
[10:16] <wgrant> I hope so :)
[10:16] <nigelb> If only I had more free time.
[10:16] <jml> hey, did I hear that longpoll was done?
[10:17] <wgrant> It works, but it has one remaining major bug.
[10:17] <wgrant> Which is pretty easily fixable.
[10:17] <wgrant> (client-side per-host connection limits suck)
[10:17] <wgrant> So if you open a few MPs, all Launchpad requests hang.
[10:17] <wgrant> Because the browser tries to avoid DoSing.
[10:17] <nigelb> dammit.
[10:18] <nigelb> That's counterproductive :)
[10:18] <jml> wgrant: heh, so it's a matter of fixing the bug and then flicking a switch for MPs?
[10:18] <wgrant> jml: Yup
[10:18] <wgrant> jml: Well, more of a gradual dial.
[10:18] <jml> wgrant: heh :)
[10:19] <jml> wgrant: that's cool.
[10:19] <wgrant> We have little idea how this will scale.
[10:21] <jml> yeah, fair enough.
[11:14] <rick_h> morning folks
[11:15] <wgrant> Morning rick_h.
[11:52] <nigelb> Morning rick_h!
[11:52] <rick_h> howdy nigelb
[11:54] <wallyworld_> rick_h: i sent you a big email, let me know if there's anything needed clarification
[11:55] <rick_h> wallyworld_: yea looking. I was curious if the not loading messages were due to http://yuilibrary.com/projects/yui3/ticket/2530983
[11:55] <rick_h> but that's for 3.4 so guess not
[11:55] <rick_h> wallyworld_: did you see if the modules were missing from the combo'd file?
[11:55] <cjwatson> sigh, this QA is going to involve comparing three getPublishedSources calls on dogfood
[11:55]  * cjwatson snoozes
[11:55] <bigjools> cjwatson: why not qastaging?
[11:56] <wallyworld_> 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] <cjwatson> hmm, I suppose Archive.copyPackages mght work on qas?
[11:56] <rick_h> 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] <rick_h> wallyworld_: right, that's what I'm wondering if the warnings are more a YUI bug than our bug
[11:57] <wallyworld_> 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] <rick_h> wallyworld_: I guess I'd be curious if we upgraded to 3.4 and ran to see if they still occurred
[11:57] <rick_h> wallyworld_: right, but there's potential for one LP_YUI instance to change a config/setting that blows up down the road
[11:58] <wallyworld_> in our usage, i don't think that's an issue
[11:58] <rick_h> 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] <wallyworld_> moving forward, we would want to consolidate all those little snippets anyway
[11:58] <rick_h> wallyworld_: and we're not hitting any performance issues atm anyway
[11:59] <rick_h> wallyworld_: true
[11:59] <wallyworld_> rick_h: remember that till now, we've always operated on asingle YUI instance
[11:59] <rick_h> wallyworld_: ok, I'll peek at it. Thanks for the hard work and the summary.
[11:59] <wallyworld_> so we are just sticking with our current modus operendi
[11:59] <rick_h> wallyworld_: right, I'm just trying to "do the right thing" if we're heading down this path anyway
[11:59] <wallyworld_> np
[12:00] <rick_h> while we're blowing up the world, blow it up all the way :)
[12:00] <wallyworld_> agreed, we do need to start adopting best practice
[12:00] <rick_h> 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] <wallyworld_> but  i don't follow how creating all these yui objects is best practice
[12:01] <rick_h> like I was saying, each YUI() sets up it's own wrapped JS world that
[12:01] <rick_h> no other YUI() should be able to interfere with another
[12:01] <rick_h> so you're safe to defined your own requires, your own settings, etc. No global leakage, etc.
[12:01] <rick_h> it's not a ton since really there's 3-6 of those a page
[12:02] <rick_h> so 3-6 new JS objects per page isn't going to cause any issues
[12:02] <wallyworld_> agreed. but in our case, all these little snippets really belong together i nthe one sandboc
[12:02] <rick_h> 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] <wallyworld_> it would be ok ig yui didn't pollute the console with all these bloody errors
[12:02] <wallyworld_> hard t know if they're really genuine :-(
[12:06] <rick_h> wallyworld_: right. thanks for the heads up. We'll get it worked out.
[12:06] <wallyworld_> ok :-)
[12:14] <StevenK> I wonder if there is a way to get the template name in a global tal macro
[12:14] <StevenK> And then include <template name>.js or something
[12:15] <StevenK> Probably complete crack
[12:15] <rick_h> StevenK: that's close to the idea I'm heading towards long term. That there's an bugs.app.js that includes the code for the bugs pages that need to run
[12:15] <rick_h> and you'd setup "views" in there that get init/run on page load
[12:15] <rick_h> and all JS goes into that view
[12:16] <rick_h> that way you get one single combo loaded JS file for all bugs pages
[12:16] <rick_h> and it's easier to see/reuse code across there
[12:16] <rick_h> and no more chasing JS in .pt files :)
[12:16] <StevenK> rick_h: Well, if you want to make our JS story not be crack cut with draino, more power to you
[12:16] <rick_h> but that's long way from here
[12:18] <rick_h> StevenK: we've got to do something. I mentioned to my coding group last night that our fancy JS paging buglisting code was going to go live soon and the first thing someone thought was "like that cool github code tree thing?" which I had to say..."um, not quite"
[12:18] <rick_h> we need the pretty JS
[12:23] <adeuring> morning rick_h, fancy a review? https://code.launchpad.net/~adeuring/launchpad/bug-904461/+merge/89230
[12:23] <rick_h> oh right, sure thing adeuring
[12:23] <adeuring> rick_h: thanks!
[12:23] <rick_h> wallyworld_: it looks like that our code is requiring modules that don't exist
[12:24] <rick_h> wallyworld_: there is no such thing as widget-position-ext that I can find in the yui3.3 src
[12:24] <rick_h> Topic for #launchpad-dev: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 3*10^2
[12:40] <wallyworld_> rick_h: widget-position-ext is in the loggerhead src. so i suspect it's leftover from an older version of yui
[12:40] <wallyworld_> and we just didn't migrate properly or something
[12:40] <rick_h> ok, I'll make sure to check through our src. thanks
[12:41] <wallyworld_> rick_h: lib/loggerhead/static/javascript/yui
[12:41] <rick_h> wallyworld_: right, so that wouldn't be part of our combo loader
[12:42] <rick_h> wallyworld_: since we don't copy that dir into our build dir
[12:42] <wallyworld_> that's not where the errors in lp would be from i don't think, but merely evidence that we may have left over crap in places
[12:42] <rick_h> wallyworld_: right, I've got more poking to do. I'm on reviews for my first time today so might be slow going through it
[12:43] <wallyworld_> ok. have fun. hopefully you won't get too many :-) so we can get this sorted :-)
[12:49] <cjwatson> Does qastaging process PackageCopyJobs created on it?
[12:49] <bigjools> yes
[12:49] <cjwatson> I'm beginning to empirically conclude it doesn't
[12:49] <cjwatson> hmm
[12:50] <bigjools> easy to check
[12:50] <cjwatson> oh, unapproved queue, not new
[12:50] <cjwatson> I *was* checking, I was just looking in the wrong place :-)
[12:50] <bigjools> :)
[13:16] <Laney> https://code.launchpad.net/~laney/launchpad/add-sponsor-field-to-spph/+merge/87930 needs review, if anyone feels like it. Be aware that this is my first (real) LP branch so gremlins may lurk.
[13:20] <rick_h> adeuring: ok, posted comments on the review. Let me know what you think. I've requested the follow up review from jcsackett before final ok
[13:21] <adeuring> rick_h: ok, thanks
[13:21] <rick_h> let me know if anything's not right so I can learn for my next review. Speaking of...
[13:21] <rick_h> Laney: ok, will take a peek. Between your first branch and my first day of reviews, we'll make a fun day out of this yet
[13:21] <Laney> :-)
[13:23] <adeuring> rick_h: well spotted issues. I'll fix them
[14:02] <rick_h> Laney: ok, only comment is that test. jcsackett will make sure I didn't miss anything else.
[14:02] <Laney> OK. I wondered that, but didn't know if there was only supposed to be one assert per test
[14:03] <Laney> thanks
[14:06] <bac> hi bigjools, do you have access to kde on natty?
[14:07] <deryck> Morning, all.
[14:08] <abentley> deryck: morning
[14:11] <bigjools> bac: I don't, I'm all upgraded to almost new
[14:17] <bac> bigjools: poo.
[14:18] <bigjools> sorry old bean
[14:21] <rick_h> bac: what do you need? I might know a kde using friend in our loco on natty
[14:22] <bac> rick_h: thanks, i may take you up.  just some testing for an SRU.  i don't think it'll be required but i'll keep it in mind.
[14:23] <rick_h> bac, ah ok
[15:17] <jcsackett> laney: i've reviewed your MP--i would really like the test duplication resolved. you can mash the tests together, but i have an alternate, somewhat preferable (to me at least) approach in my comment on your MP.
[15:18] <Laney> jcsackett: absolutely. Thanks for that. It'll have to wait until I get home but that sounds reasonable to me.
[15:19] <jcsackett> laney: cool. if i'm still on when you make the change, ping me then and i can approve.
[15:19] <Laney> 3-4 hours time
[15:30] <jcsackett> Laney: then i'll be here. :-)
[15:30] <Laney> awesome
[15:41] <adeuring> rick_h: i pushed new revision of the branch
[15:42] <adeuring> care to take a look?
[15:42] <rick_h> adeuring: sure thing, will check it out in a sec. Thanks
[15:43] <adeuring> thanks!
[15:44] <rick_h> mwhudson: ping, question for you on https://code.launchpad.net/~mwhudson/loggerhead/bug-321325/+merge/87881, why was file_id param removed?
[15:45] <rick_h> doh, always check location first.
[15:47]  * jcsackett wonders why he gets gnomekeyring errors when using ec land in tmux ...
[15:48] <rick_h> jcsackett: haven't seen that myself
[15:48] <jcsackett> it just started happening recently, but i can't remember any updates that would be relevant.
[15:49] <adeuring> jcsackett: thanks for your review!
[15:49] <jcsackett> adeuring: you're welcome. sorry i forgot to ping you when i was done. :-P
[16:00] <rick_h> adeuring: awesome, thanks. Sorry on the docstring, I didn't think to check the interface. r=me
[16:00] <adeuring> rick_h: thanks!
[16:36] <ayan> i'm new to python and the launchpad api.
[16:36] <ayan> i'm having trouble extracting the next item in a series given a series name.
[16:37] <ayan> so if i have:
[16:37] <ayan> ubuntu = lp.distributions['ubuntu']
[16:37] <ayan> and i want the series after 'maveric'.
[16:38] <ayan> how can i use ubuntu.series to extract 'natty'?
[16:39] <bigjools> ayan: you can just do ubuntu['natty']
[16:39] <bigjools> IIRC
[16:39] <ayan> bigjools: i don't know the series after maveric.
[16:39] <ayan> well -- *I* do, but I'd like to determine the next series programaticly.
[16:40] <bigjools> ayan: you need to iterate then
[16:40] <ayan> i can iterate over ubuntu.series but i was wondering if there was a simpler way.
[16:40] <ayan> right.
[16:40] <bigjools> there's no better way really
[16:49] <cjwatson> >>> [series for series in ubuntu.series if series.parent_series is not None and series.parent_series.name == 'maverick'][0]
[16:49] <cjwatson> <distro_series at https://api.launchpad.net/1.0/ubuntu/natty>
[16:49] <cjwatson> or a less densely packed version if you prefer :)
[16:51] <cjwatson> but indeed the API only links it in that direction not the other way round
[17:06] <rick_h> cjwatson: ? re https://code.launchpad.net/~cjwatson/launchpad/split-ftpmaster/+merge/89193
[17:06] <rick_h> cjwatson: on the  warned_database_imports. I'm not 100% what that's for, but you removed ftpmaster, but none of the new modules qualified to take its place?
[17:22] <cjwatson> rick_h: possibly true; it's hard to say because the importfascist is broken anyway so I can't quite tell what it's supposed to warn about
[17:22] <rick_h> cjwatson: ok
[17:23] <cjwatson> rick_h: I guess maybe obsolete_distroseries?
[17:24] <cjwatson> rick_h: I've added that - I suppose it can do no harm
[17:24] <rick_h> cjwatson: ok, sorry I'm not helpful. Trying to figure out what this is intended to do
[17:25] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/706129
[17:25] <_mup_> Bug #706129: import fascist is now ineffective and should be either reenabled or deleted <easy> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/706129 >
[17:25] <rick_h> ah, that makes sense
[17:26] <cjwatson> It's probably my duty not to make it any worse when doing something not essentially related
[17:31] <rick_h> cjwatson: so I'd expect to see something touching the database to be in the warnings there, but I'm not seeing any of the code doing a query/etc?
[17:32] <rick_h> cjwatson: I guess it's more for other code importing ftpmaster though, so nvm.
[17:33] <salgado> I'm getting "You attempted to reach launchpad.dev, but the certificate that the server presented has been revoked by its issuer." on chrome 17.0.963.33 beta when accessing launchpad.dev and the only option I'm given is to go back.  does anybody know if there's a way to tell chrome to ignore it or at least give me another option to proceed regardless?
[17:34] <salgado> I used to be given the option to proceed regardless, so maybe this is a new chrome feature?
[17:36] <salgado> the " Check for server certificate revocation" checkbox doesn't seem to change anything
[17:40] <salgado> firefox doesn't seem to think the certificate is revoked -- only that it is self-signed.  maybe chrome's change in behaviour is because it thinks the certificate is revoked?
[17:45] <salgado> hm, nevermind, seems to be working now
[17:50] <cjwatson> rick_h: I think it's any imports, so the UTC_NOW that ended up in obsolete_distroseries.ppy [D[D[Dwould have triggered it at one point
[17:51] <cjwatson> gah, ignore lag-induced junk there
[18:47] <Laney> jcsackett: Just implementing your changes now (actually there are rather more opportunities to pull that code out of). Shall I implement rick_h's suggestions too (merging the new tests into existing ones)?
[18:47] <jcsackett> laney: i think these are legitimately new tests, so the tests themselves should remain separate. just pull out the repetitive boilerplate.
[18:47] <Laney> ack, I thought the same
[19:25] <jcsackett> cjwatson: i have finished reviewing rick_h's review. all looks good, given you addressed his one issue.
[19:25] <jcsackett> i am guessing you need landing assistance? :-)
[19:46] <Laney> jcsackett: pushed. I'm sure there's more that can be done, but this is at least better.
[19:54] <jcsackett> Laney: i see several places where you've now deleted the line where a change_log_entry is set, but the _setup_copy function doesn't set that. have you verified these changes all pass without that line?
[19:55] <Laney> jcsackett: yes, I reran that entire file
[19:56] <jcsackett> deryck: the mp you've claimed may be the largest i have seen during my review times. certainly it is the largest i can remember.
[19:56] <Laney> seemed to be c+p
[19:57] <deryck> jcsackett, yeah, biggest I've done too.
[19:57] <jcsackett> Laney: awesome. r=me.
[19:58] <jcsackett> Laney: i assume you need/want landing assistance on this?
[19:59] <Laney> jcsackett: yes please. I can't do it myself.
[20:01] <jcsackett> oops, Laney, sorry if i got your hopes up. i see it's dependent on another branch hitting production, which hasn't happened yet.
[20:02] <jcsackett> when that does, we can get this branch out to land.
[20:02] <Laney> jcsackett: the db branch? AFAIK it rolled out in FDT today (or at least that's what wgrant told me)
[20:03] <jcsackett> Laney: according to the deployment report, it's clear to be deployed, but i don't think it has been yet.
[20:03] <Laney> 19/01 10:10:07 <wgrant> Laney: Your DB patch is deployed.
[20:03] <Laney> 19/01 10:10:13 <wgrant> And now in devel.
[20:04] <jcsackett> Laney: hrm. lemme go run this down.
[20:06] <jcsackett> Laney: yup, i see that the FDT through 11307 happened. alright, out this one goes.
[20:06] <Laney> awesome
[20:38] <sinzui> That replacement private team debacle has set me on edge. I cannot write an announcement about privacy/disclosure terminology.
[20:38]  * sinzui looks for a trivial bug to feel productive
[20:55] <deryck> ah, sorry, sinzui
[20:58] <sinzui> deryck, no need to apologise. I lead the commercial admin team and I have not been very good at documenting how to extract users from Lp privacy morass
[20:59] <deryck> yeah, I just hate you lost your day to it.
[21:00] <sinzui> yes. I am disappointed. Still one of the bugs I reported is definitely a social-private-teams defect that must be fixed in the next two weeks. I think we chose the wrong vocab to get the list of teams you can transfer a branch to
[21:36] <sinzui> deryck, You can set aside your guilt My trivial fix to allow changing a branch owner to a private team also fixes other bugs.
[21:36] <deryck> sinzui, ah, nice!
[21:36] <deryck> something good from the day then!
[21:43] <wallyworld_> deryck: hi. thanks for the review! just to confirm - should we prefer YUI.use or YUI.add?
[21:43] <deryck> wallyworld_, hey man.
[21:43] <wallyworld_> g'day
[21:44] <wallyworld_> we seem to use YUI.add in our js, and YUI.use in the tal
[21:44] <wallyworld_> more or less
[21:44] <deryck> wallyworld_, sorry, I wasn't clear... if it's a use block, it should be "YUI().use" -- if it's add, it should be "YUI.add"
[21:44] <wallyworld_> np. i sort of read the review comment in email and didn;t look back at code - i wanted to try and quickly catch you before youi eod
[21:45] <wallyworld_> so it was probably a stupid question based on lack of info
[21:45] <deryck> yeah, the spots we use then look right to me.  it's just YUI.use should become YUI().add and if there are any YUI().add they should be YUI.add.  if that makes sense. ;)
[21:46] <wallyworld_> ah right. yes it does. thanks. should be easy to fix. we have our standup soon and i'll do it asap after that. can't wait to land this
[21:46] <wallyworld_> that console noise suck though
[21:47] <wallyworld_> deryck: also, sinzui said in email that we used a single LPS instance previously to resolve some browser issues. are we sure there won't be an issue using YUI() all over?
[21:48] <deryck> I'm sure.
[21:48] <sinzui> wallyworld_, deryck. I recall the issue was between solid sandboxing and page rendering times. We (and landscape) chose the later
[21:49] <deryck> sort of.
[21:49] <deryck> it was browser issues, it was the only way to set a global config, before the global config option we have now....
[21:49] <deryck> so we passed in those 4 or 5 issues to prevent trying to connect to Yahoo's CDN, which helped performance.
[21:49] <deryck> that was "wasn't" browser, not was.
[21:50] <wallyworld_> ah, ok. and rendering times should be better now with the combo loader :-)
[21:50] <deryck> indeed.
[21:50] <wallyworld_> also, i justed emailed you guys directly rather than the list - we can do an email to the list once this lands
[21:50] <deryck> and we have all the global config options we need now too.
[21:51] <deryck> GlobalConfig didn't exist back when we did LPS.  That's what I was trying to say.
[21:51] <wallyworld_> deryck: so, if you are able to check back in say 90 minutes or so, hopefully i'll have made the changes. depends on how long our standup goes. then we can send to ec2 today \o/
[21:51] <deryck> wallyworld_, yay!
[21:51] <wallyworld_> thanks :-)
[21:51] <deryck> wallyworld_, I'll will check back in between 1.5-2 hours from now.
[21:51] <deryck> np!
[21:51] <deryck> so before raid night. ;)
[21:52] <wallyworld_> ok. i know it's a large mp. but i expected one of us to review and we were all across the implementation
[21:52] <wallyworld_> yep :-)
[21:52] <deryck> yeah, I wasn't worried about the size.
[21:52] <deryck> it's really a clean diff anyway.  2000 lines are the global LPS replace stuff.
[21:52] <wallyworld_> deryck: i'll raise a bug also so we have a qa trigger. is there one already that you can recall?
[21:53] <wallyworld_> i was just commenting on the concern expressed in the mp :-)
[21:53] <sinzui> deryck, thank you for your keen memory. BTW, why are you here? Have you run away from home
[21:53] <deryck> wallyworld_, no, there's not.  just make a "we should use a combo loader" bug.  and I think this in incr fix.
[21:53] <deryck> wallyworld_, we can finally close the bug when we switch it live.
[21:54] <deryck> sinzui, I start later and stay later now.
[21:54] <deryck> my EOD is in 5 minutes.
[21:54] <wallyworld_> deryck: sounds good. i just want to make sure we do all the due diligence we can :-)
[21:54] <deryck> indeed :)
[21:54] <wallyworld_> i really hope qa goes ok. i dpon't want to rollback :-/
[21:54] <rick_h> wallyworld_: do we need to get the path business on convoy setup before this lands?
[21:55] <rick_h> wallyworld_: since we'll need to be able to do upgrades and such with webops going forward?
[21:55] <wallyworld_> rick_h: no. lets just get this in as is, we won't switch on the combo loader till we are ready
[21:55] <wallyworld_> we will iterate
[21:55] <rick_h> ok, just wamted to be sure
[21:55] <wallyworld_> rick_h: see above discussion for YUI() vs LP_YUI and reasons for originally using LPS
[21:56] <wallyworld_> we will be going with YUI() as you wanted
[21:58]  * wallyworld_ fires up mumble and hopes it works this time
[22:25] <cjwatson> jcsackett: landing> yes please, thanks
[22:34] <StevenK> sinzui, wgrant: http://pastebin.ubuntu.com/810147/ :-(
[22:36] <jcsackett> cjwatson: your branch is off to land. :-)
[22:36] <wgrant> StevenK: Ah, because it's a str, not an int. You may have to use python: after all :(
[22:37] <cjwatson> jcsackett: cool, thanks
[22:46] <deryck> Night all.
[22:53] <sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bug/556680
[22:53] <_mup_> Bug #556680: attempting to create a new account with an existing team email address at login.ubuntu.com oopses <isd-logging-sprint> <lp-foundations> <openid> <Canonical SSO provider:Incomplete by stuartmetcalfe> <Canonical ISD QA:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/556680 >
[22:53]  * sinzui adding the missing openid tag
[22:56] <StevenK> sinzui: https://code.launchpad.net/~stevenk/launchpad/kill-bugtask-launchbag-with-fire/+merge/89357 but no diff yet
[22:56] <StevenK> That was quick.
[22:56] <StevenK> Something must be broken.
[22:59] <wgrant> sinzui: Ah
[22:59] <wgrant> sinzui: As I thought, the email address gets stolen from the team.
[22:59] <wgrant> In the old code.
[23:00] <sinzui> I raised the bug to critical, you can mark it as a dupe. Now we have a really TB to look at.
[23:00] <sinzui> wgrant, you can fix this if you think you have the opportunity
[23:04] <wgrant> Hm
[23:04] <wgrant> I think that same thing would actually have taken a person's last email address in some situations.
[23:08] <sinzui> wgrant, in the case of a team, the last email address could be an Lp hosted list. That would be very strange. I think there is an assumption in Lp code somewhere that lists.launchpad.net is a team
[23:14] <StevenK> sinzui: Thanks for the review, I'll toss it at ec2 after breakfast.
[23:32] <wallyworld_> rick_h: you there?
[23:41] <rick_h> wallyworld_: here, what's up?
[23:41] <wallyworld_> my reading of the yui3 docs is that there's no config option to allow setting the logLevel in the GlobalConfig object :-(
[23:42] <wallyworld_> you can go YUI({logLevel: 'info'}) but that's not a global setting
[23:42] <rick_h> wallyworld_: ok, I'll take a peek
[23:42] <wallyworld_> thanks, i may have simply missed the option
[23:43] <wallyworld_> i did try it in GlobalConfig despite the docs saying it wasn't an option and of course it didn;t work
[23:43] <rick_h> yea, not sure. I've not tried it
[23:43] <wallyworld_> we may just have to have a noisy console
[23:43] <rick_h> right, I think it won't take long to clean up
[23:43] <rick_h> I fixed the one locally on the widget-position-ext
[23:44] <rick_h> so I can merge that once this is landed right away and then it's just a matter of fixing the css ones
[23:44] <rick_h> and it's only for people behind the feature flag until I find the rest
[23:44] <rick_h> I didn't have much time to look into it today with reviews
[23:44] <wallyworld_> yeah, plus the lp.xxxxxx naming inconsistencies etc
[23:44] <rick_h> I'm a bit slow on them atm
[23:44] <rick_h> right, that was my fault. I thought the lp.xxx module name had to match the directory structure
[23:44] <rick_h> so I changed the one module deryck pointed out
[23:44] <wallyworld_> rick_h: the noisy console is with or without the ff
[23:45] <wallyworld_> it's due to us moving to YUI() all over instead of a sinlge instance
[23:45] <rick_h> wallyworld_: ah, that's right sorry
[23:46] <rick_h> but I can fix it, just need to find the issues and correct them one at a time
[23:46] <wallyworld_> rick_h: np. plus, the work last week introduced a critical regression bug 918901
[23:46] <_mup_> Bug #918901: bug page html is unparseable by XMLHttpRequest <Launchpad itself:New> < https://launchpad.net/bugs/918901 >
[23:46] <rick_h> and they show up as warnings, both chrome/FF have a filter on the debug tools to choose the level absoulte worst case
[23:47] <wallyworld_> this was part of the general cleanup stuff from lp.js was moved into tal
[23:47] <wallyworld_> i'm onto that bug next
[23:47] <rick_h> oh hmm, ok. well should be able to through the page html at a validator and see what it hates on
[23:47] <wallyworld_> it hates the unquoted & and < etc
[23:48] <wallyworld_> shit happens
[23:48] <wallyworld_> i didn't realise we were doing anything naughty
[23:48] <rick_h> where is the unquoted &/< ?
[23:49] <wgrant> Search for ' < ' on any LP app page.
[23:49] <wallyworld_> not sure - haven't looked yet tbh. wgrant raised the issue on today's standup
[23:49] <wgrant> Cry
[23:49] <rick_h> ah ok
[23:49] <wallyworld_> apparently it's all @$%@!$%! the fault if IE
[23:49] <wallyworld_> s/if/of
[23:49] <wgrant> Yup
[23:49] <wgrant> If IE didn't exist we could just use XHTML :/
[23:49] <rick_h> hmm, the only one I see is in JS code on a sample bug page
[23:49] <wgrant> rick_h: RIght
[23:50] <wgrant> rick_h: That's the problem.
[23:50] <wgrant> LP pages have traditionally been both HTML and XHTML.
[23:50] <rick_h> orly? having the           for (i = 0; i < nodes.length; i++) {
[23:50] <rick_h> in a JS tag is bad?
[23:50] <wgrant> They're no longer valid XHTML.
[23:50] <wgrant> Yes.
[23:50] <wgrant> It's invalid XML.
[23:51] <rick_h> ok, well worst case we can go back to the plan of pulling out the plain JS methods back out of the template. I figured putting them there just made it obvious since they were a bit hidden before
[23:51] <wgrant> And you can't escape using &gt;, because that doesn't work in HTML4.
[23:51] <rick_h> right, that's not valid JS at that point and it'd fail I'd expect
[23:51] <wgrant> No.
[23:51] <rick_h> really? you can use &gt; in JS and it'll parse/execute?
[23:51] <wgrant> You're not using &gt; in JS.
[23:52] <rick_h> that's where I see it at
[23:52] <wgrant> You're using &gt; in XML or SGML
[23:52] <wgrant> Which happens to have JS encoded in it.
[23:52] <rick_h> ah, gotcha
[23:52] <wgrant> The problem is that HTML4's subset of SGML is stupid.
[23:52] <wgrant> eg. if I have JS with a string containing '</script>', I can't represent that in HTML4.
[23:53] <wgrant> Because I can't encode it to &gt;/script&lt;, because HTML4 browsers won't decode it.
[23:53] <rick_h> lovely, well have to love that this little project is a demonstation of how many ways to break something :)
[23:54] <wgrant> It's similar to the problem of including ]]> in an explicit CDATA section.
[23:55] <wgrant> Except that XML is sensible, so you can just end the section, write ]]> literally, then restart it.
[23:55] <wgrant> It will still be the same text node.
[23:55] <wgrant> But for script tags in HTML4 we have no such luxury.
[23:55] <wallyworld_> so if we land the use-convoy branch, it will rebreak any fixes to trunk. i'm tempted just to fix in use-convoy since we are landing that today
[23:55] <StevenK> wgrant: <tal:official_tags tal:content="structure/view/official_tags" /> seems to not work
[23:56] <wgrant> StevenK: 'structure ', not 'structure/'
[23:56] <StevenK> Ah
[23:56] <wgrant> Just do a list of tuples, though.
[23:56] <wgrant> Much safer.
[23:56] <StevenK> We couldn't -- remember?
[23:57] <wgrant> python: isn't the end of the world.
[23:57] <wgrant> It's close, but not quite.
[23:57] <wgrant> rick_h: Ideally you should remove the JS from the page, but otherwise you can wrap it in commented CDATA tags
[23:58] <wgrant> To make XML parsers happy.
[23:58] <StevenK> I have it working with the tags in the view. I'm happy with it.
[23:58] <wgrant> You've said 'structure'
[23:58] <wgrant> The most that can make you is "awkwardly compromising"
[23:58] <StevenK> That's what sinzui suggested.
[23:58] <wgrant> By no means can that make a reasonable person in any way happy.