| rick_h | lifeless: ok, that looks a bit nutty and I can't think of a real use case I'd do that atm | 00:00 |
|---|---|---|
| rick_h | lifeless: but if you go through to the block helpers I think that idea is sound to be able to help with the iteration and such. | 00:01 |
| rick_h | that's where I get into I like a tpl tool that lets me build helpers to be used site wide for consistancy | 00:01 |
| rick_h | so for instance, I could seee creating a block that's part conditional to help make sure output without any data provides a decent "no results found" consistant bit of html | 00:02 |
| lifeless | sure | 00:05 |
| lifeless | does moustache allow nested templates? | 00:05 |
| lifeless | (because that seems both less general (and more optimisable) and a bit easier to reason about | 00:05 |
| * rick_h dbl checks, I didn't hink so but it's on the ticket "wishlist" | 00:05 | |
| lifeless | anyhow | 00:07 |
| lifeless | having looked at it | 00:07 |
| lifeless | I think we can easily implement a handlebars compiler | 00:07 |
| rick_h | lifeless: looks like it's got "partials" which are kind of like it | 00:07 |
| lifeless | obviously the extension bits are going to need some idiomatic translation to python | 00:07 |
| lifeless | depending on how efficient we want the compiler etc | 00:07 |
| rick_h | lifeless: but yea, the one thing to think about is that when you get to doing a lot of client side rendering you're getting dump data dumps from an api and you're not going to get a ton of logic ability from that end | 00:07 |
| lifeless | rick_h: well, I want LP's main tier to also be just an API consumer :) | 00:08 |
| lifeless | so I don't see a great deal of tension there | 00:08 |
| rick_h | lifeless: ok | 00:08 |
| lifeless | rick_h: one of the nasty tricky performance things zope has, for instance | 00:09 |
| lifeless | is this model: | 00:09 |
| lifeless | outer template, inner template for e.g. 'view of a bug' | 00:09 |
| rick_h | lifeless: end of the day I'm not the best person to ask. I'm a fan of SqlAlchemy, Mako, Pyramid, things that give me enough rope to shoot myself, but I can't stand a tool that tops out and I end up doing stupid hacks around the tool to get something done. | 00:09 |
| lifeless | the outer template iterating over views of the inner template | 00:09 |
| StevenK | rick_h: You shoot yourself with rope? Really? | 00:09 |
| lifeless | indeed, totally with you on that | 00:10 |
| rick_h | StevenK: heh, cold meds are going to my head finally :) | 00:10 |
| StevenK | Haha | 00:10 |
| lifeless | rick_h: ubuflu? | 00:10 |
| StevenK | rick_h: Ugh, you're sick too? | 00:10 |
| rick_h | lifeless: yea, and I do some of that in my app be nesting views in views | 00:10 |
| rick_h | not sure, might be toddler disease | 00:10 |
| rick_h | he had pink eye over the weekend | 00:10 |
| lifeless | rick_h: this tends to perform terribly unless you decide upfront what is needed | 00:10 |
| rick_h | and today I'm running on E | 00:11 |
| rick_h | lifeless: right, it's much more memory intensive and such | 00:11 |
| * StevenK raises one eyebrow | 00:11 | |
| lifeless | rick_h: which to me, speaks to having a single simple top level template, more or less | 00:11 |
| lifeless | rick_h: not memory so much - late evaluation / lazy loading | 00:11 |
| lifeless | rick_h: death by 1000 cuts | 00:11 |
| rick_h | lifeless: right, but then you're template is going to have to be smarter in order to intellegently handle corner cases/etc | 00:11 |
| lifeless | rick_h: something, yes | 00:11 |
| lifeless | rick_h: I guess I'm not satisfied with the answers we have yet | 00:12 |
| rick_h | lifeless: let's find a use case and go to town :) | 00:12 |
| lifeless | rick_h: and I'm trying to figure out if we want to say 'use moustache (and no handlebars features)' or 'use handlebars (and port to python)' or 'lets roll a third thing' | 00:12 |
| rick_h | lifeless: yea, and not sure we will. These decisions tend to show if they work/not more in real use cases with real fire going by | 00:12 |
| * StevenK spies rick_h as the last requested deployment | 00:12 | |
| rick_h | StevenK: yea, I did my first NDT request :) | 00:13 |
| StevenK | rick_h: You found it was pretty easy? | 00:13 |
| rick_h | lifeless: right, I've hit limitations in mustache and especially issues with pystache so I'm pretty much in the "anything but stache" camp atm :) | 00:13 |
| rick_h | helpful, aren't I | 00:13 |
| rick_h | StevenK: well I screwed up, I thought approval was from webops and I missed getting teh bugs linked/etc | 00:14 |
| rick_h | but after a few tries and wgrant holding my hand I got it | 00:14 |
| wgrant | :) | 00:14 |
| wgrant | lifeless: ha hahhhahahh hah ' | 00:15 |
| wgrant | fewfw | 00:15 |
| wgrant | fwef | 00:15 |
| wgrant | So, as it turns out, the date logic is fine. | 00:15 |
| * wgrant backs up the oopses and tries it. | 00:17 | |
| lifeless | rick_h: conceptual or implementation issues? | 00:18 |
| rick_h | lifeless: implementation for the most part. | 00:18 |
| StevenK | wgrant: Then what's the bug? | 00:18 |
| rick_h | it's slow, the pystache implementation is broken compared to JS, and I don't see how we'd port over a lot of the .pt logic over to it (so that part is conceptually) | 00:18 |
| lifeless | rick_h: by .pt you mean [me]tal templates | 00:20 |
| lifeless | ? | 00:20 |
| lifeless | rick_h: the js version or the py version is slow? | 00:21 |
| lifeless | rick_h: the py version looks horrendously slow: see _render_sections | 00:22 |
| rick_h | lifeless: yea, a lot of things like the macros and such you'd have to look at porting over | 00:27 |
| lifeless | right | 00:28 |
| lifeless | I think there is substantial work to do | 00:28 |
| lifeless | However, what we have now with a mix of: | 00:28 |
| lifeless | - hand rendered | 00:28 |
| lifeless | - tal | 00:28 |
| lifeless | - metal | 00:28 |
| lifeless | - stache | 00:28 |
| lifeless | - chameleon | 00:28 |
| lifeless | is pretty much unmaintainable | 00:28 |
| rick_h | heh, you won't find me arguing there | 00:28 |
| lifeless | so I think for now the best solution is to say 'take stache and run with it *gathering up data where it does not fit well*' | 00:29 |
| rick_h | ok, time to go take more meds and hit the pillow. Sorry. | 00:29 |
| lifeless | I'm open to the idea of different (tiny) DSL's for different problem domains | 00:29 |
| lifeless | ciao, get well | 00:29 |
| rick_h | lifeless: understand | 00:29 |
| StevenK | lifeless: You have mostly recovered? | 00:32 |
| lifeless | StevenK: yeah, still a bit snuffly & cold sweats but nothing like I was | 00:34 |
| lifeless | StevenK: lynne is coming down with it now though :( | 00:34 |
| StevenK | :-( | 00:35 |
| StevenK | I'm still coughing, but due to asmtha, it takes me a while to shake them off | 00:36 |
| lifeless | yeah, me too - asmtha sucks | 00:39 |
| * wgrant escaped the plague this time. | 00:40 | |
| * StevenK ships wallyworld to wgrant's house so he can share in the misery. | 00:40 | |
| wgrant | Although I did get whooping cough in Wellington, so I guess it's fair. | 00:40 |
| lifeless | https://dev.launchpad.net/PageTemplateHacking | 00:41 |
| wallyworld | i love sharing | 00:41 |
| lifeless | this talks about mochikit | 00:41 |
| lifeless | :( | 00:41 |
| wgrant | lifeless: :D | 00:41 |
| StevenK | lifeless: Hey, we got Mochi out of the codebase, it can be up to others to remove it from the docs | 00:41 |
| * wallyworld didn't even know there were docs | 00:42 | |
| lifeless | wgrant: so, not date ranges. | 00:42 |
| lifeless | there is also this page https://dev.launchpad.net/Web/TemplateCodeReuse (it doesn't talk about mochikit, but abou ttemplates) | 00:42 |
| wgrant | lifeless: The fix is http://paste.ubuntu.com/815998/ :) | 00:42 |
| * lifeless headdesks | 00:43 | |
| wgrant | Myes. | 00:43 |
| lifeless | wgrant: +1 | 00:43 |
| lifeless | sorry | 00:43 |
| wgrant | Currently testing on a hardlinked copy of the production oopses. | 00:43 |
| wgrant | Seems to be working. | 00:43 |
| StevenK | Hardlinks? | 00:43 |
| StevenK | You bad man. | 00:43 |
| wgrant | With 6GB of free space and 100GB of OOPSes, I had little choice :) | 00:44 |
| lifeless | StevenK: get well :) | 00:51 |
| james_w | lifeless, did you have an opinion on whether oops should change bson libraries? | 01:03 |
| lifeless | nope | 01:10 |
| lifeless | (no opinion) | 01:11 |
| lifeless | james_w: ^ | 01:16 |
| james_w | ok | 01:16 |
| james_w | it's rather annoying having the two of them | 01:16 |
| lifeless | I agree | 01:17 |
| lifeless | I think a patch to work with either would be pretty easy to do | 01:17 |
| lifeless | and avoid the question entirely | 01:17 |
| lifeless | well, it would leave open questions for debugging like 'which one does THIS WEIRD THING' etc | 01:18 |
| lifeless | james_w: all I did was grab the first one that I found on pypi | 01:18 |
| james_w | yeah, it's understandable | 01:19 |
| james_w | unfortunately it's the pymongo one that got packaged | 01:19 |
| lifeless | its daft that the mongo guys didn't register the name on pypi | 01:19 |
| lifeless | daft and ANNOYING | 01:19 |
| wgrant | And very much in the style of the rest of the NoSQL DBs :) | 01:20 |
| james_w | well, it's another top level in pymongo which is registered, so it's annoying that pypi lets this happen | 01:21 |
| lifeless | james_w: how do you mean ? | 01:21 |
| james_w | http://pypi.python.org/pypi/pymongo | 01:21 |
| wgrant | That's insane. | 01:21 |
| james_w | if you pip install pymongo you get bson too | 01:21 |
| lifeless | aiee | 01:21 |
| james_w | and nothing complains at any point | 01:21 |
| wgrant | :D | 01:21 |
| lifeless | so thats not pypi's problem | 01:22 |
| lifeless | it /could/ be, but it isn't :) | 01:22 |
| james_w | and apparently "pip install pymongo; pip install bson" != "pip install bson; pip install pymongo" | 01:22 |
| lifeless | of course it isn't. | 01:22 |
| lifeless | the pymongo packaging is doing something nobody expects | 01:22 |
| lifeless | (which you know, and I know you know :P) | 01:23 |
| lifeless | anyhow | 01:23 |
| lifeless | like I say, I have no opinion | 01:23 |
| lifeless | whatever works | 01:23 |
| wgrant | lifeless: btw, pycassa 1.4 (which I packaged yesterday) incorporates the concurrent schema change workaround that you have in oops-repository. | 01:23 |
| lifeless | wgrant: \o/ | 01:23 |
| wgrant | It was also only released a day or two ago, but it seems to work fine. | 01:23 |
| lifeless | I can't remember if I filed that as a bug or whinged in private email or whatever. | 01:24 |
| wgrant | I also packaged new python-thrift and cassandra, because having an outdated new stack seems silly. | 01:24 |
| lifeless | but its cool they have seen sanity | 01:24 |
| wgrant | Not sure what U1DB are doing. | 01:24 |
| lifeless | wgrant: have you tossed a delta to elmo ? | 01:24 |
| wgrant | But I couldn't see anything even vaguely modern in PPAs. | 01:24 |
| wgrant | Not yet, no. | 01:24 |
| lifeless | he might appreciate that | 01:24 |
| lifeless | he was mumbling about updating | 01:24 |
| wgrant | Yeah. | 01:24 |
| wgrant | I think I might drop support for <precise or at least <oneiric and try to get rid of some of the jars. | 01:25 |
| wgrant | elmo's already only support >= natty. | 01:25 |
| wgrant | Because JAVA! :D | 01:25 |
| lifeless | I'd check with elmo about that (so that we can share packaging) | 01:26 |
| wgrant | Of course. | 01:26 |
| wgrant | But everything relevant should be precise in like 4 months. | 01:26 |
| wgrant | So I don't imagine too much resistance. | 01:27 |
| wgrant | Hmm. | 01:28 |
| wgrant | Is our bson library very slow, I wonder. | 01:28 |
| wgrant | Because this prune is taking forever. | 01:28 |
| wgrant | It's only doing a few per second. | 01:28 |
| james_w | anyone looked at https://bugs.launchpad.net/python-oops-tools/+bug/903573 at all? | 01:28 |
| _mup_ | Bug #903573: TypeError: start_response() takes no keyword arguments <python-oops-tools:Triaged> < https://launchpad.net/bugs/903573 > | 01:28 |
| james_w | wgrant, jam says it is slow | 01:28 |
| wgrant | :( | 01:29 |
| lifeless | james_w: that looks like the broken django stack | 01:32 |
| james_w | lifeless, I don't think so | 01:32 |
| james_w | the django.py replaces a different method | 01:32 |
| lifeless | bah | 01:33 |
| lifeless | I meant mod_wsgi | 01:33 |
| james_w | yeah, that's what I'm thinking | 01:34 |
| james_w | but I think "broken" may just be "old" | 01:34 |
| lifeless | well | 01:34 |
| lifeless | WSGI has been like this for a -long- time | 01:34 |
| lifeless | so what is happening here is that an oops in oops-tools itself is generated and is trying to be shown to the user, but mod_wsgi is barfing | 01:35 |
| james_w | yes | 01:36 |
| james_w | ah, it's a bug in oops-wsgi by the look of it | 01:39 |
| lifeless | oh? | 01:40 |
| james_w | I'll send an MP in a minute | 01:40 |
| lifeless | cool; could you use english in the meantime? | 01:41 |
| james_w | it's pretty simple | 01:45 |
| james_w | there are two locations where it calls start_response with exc_info | 01:45 |
| james_w | one passes it positionally, the other as a keyword | 01:45 |
| james_w | the latter is wrong apparently | 01:45 |
| lifeless | bah | 01:46 |
| lifeless | thanks for spotting that | 01:46 |
| lifeless | '(As with all WSGI callables, the arguments must be supplied positionally, not by keyword.) ' I swear that wasn't in PEP 3333 last time I looked | 01:47 |
| james_w | lifeless, have you looked in to how to encourage django to use a response with the oops id on an uncaught exception? | 01:47 |
| james_w | if you don't provide a 500 template then you get the oops one, but the oops it points to is an exception complaining that you don't have a 500 template | 01:48 |
| lifeless | jamesh: has | 01:48 |
| lifeless | oh, for oops-tools itself I know we need to provide a 500 template | 01:48 |
| lifeless | there is a patch for django, last I checked it was a bit stalled | 01:49 |
| lifeless | https://code.djangoproject.com/ticket/16674 | 01:49 |
| james_w | oh, I thought that was what the django.py fixed | 01:50 |
| lifeless | it works around it | 01:50 |
| james_w | http://ec2-107-22-92-8.compute-1.amazonaws.com/pkgme/+oops is what I'm getting currently | 01:51 |
| lifeless | https://code.djangoproject.com/attachment/ticket/16674/wsgi-expose-exc-info-v2.patch | 01:51 |
| lifeless | thats the actual fix | 01:51 |
| lifeless | the django module in oops-wsgi sniffs the exception to ensure you get an oops | 01:51 |
| lifeless | but it can't influence django to make it expose the error to the wsgi stack | 01:52 |
| jamesh | james_w: you mean to display the OOPS ID on the error page? | 01:52 |
| lifeless | so the main oops module just sees a successful reponse | 01:52 |
| james_w | jamesh, yeah | 01:52 |
| james_w | lifeless, ah, I see | 01:52 |
| jamesh | james_w: I haven't been able to work out a good way to solve that with the new infrastructure | 01:52 |
| james_w | so if it were properly fixed then oops' response would take over | 01:52 |
| james_w | ok, it's not so important to us at this point | 01:52 |
| lifeless | james_w: do you get an OOPS emitted to (rabbit|disk) | 01:53 |
| james_w | lifeless, yep | 01:53 |
| jamesh | the old oops code we have in U1 can preallocate the oops IDs on demand, so we can use that in the error page | 01:53 |
| lifeless | jamesh: we could allow that too, if you wanted to use a timeuuid or something, and put the id in the context | 01:54 |
| jamesh | one idea I had for the new code might be to set a short lived cookie in the WSGI middleware, and look that up with JS in the error page | 01:54 |
| lifeless | jamesh: ooh, nice. | 01:54 |
| jamesh | that has the downside that cookies are shared between all tabs in a browser | 01:54 |
| james_w | lifeless, for this patch, how much do you care about a test? | 01:54 |
| james_w | it's not the easiest thing to test after all | 01:54 |
| lifeless | 'meh' | 01:54 |
| jamesh | so if you open 20 pages at once and five fail, you might see the same OOPS ID on each | 01:55 |
| lifeless | yeah | 01:55 |
| lifeless | uhm | 01:55 |
| lifeless | wonder if you can inspect the response headers from the page itself | 01:55 |
| lifeless | jamesh: shoving id in the context would be fine. | 01:55 |
| lifeless | james_w: should be easy to test if you want to; just have an outer start_response(*args, **kwargs) and check kwargs is empty | 01:55 |
| james_w | lifeless, ah, good point | 01:56 |
| jamesh | I don't think there is a way to inspect response headers unfortunately | 01:56 |
| lifeless | so, a django error template that puts content['oops.context']['id'] = str(uuid.uuid1()) => win | 01:59 |
| lifeless | jamesh: ^ | 01:59 |
| wgrant | Hmm | 02:00 |
| wgrant | Regression | 02:00 |
| wgrant | 5633 AssertionError: Ambiguous view name. | 02:00 |
| wgrant | GET: 5629 Other: 4 Robots: 98 Local: 239 | 02:00 |
| wgrant | 168 http://feeds.launchpad.net/%7Ebarry/latest-bugs.atom (Person:latest-bugs.atom) | 02:00 |
| wgrant | OOPS-00033c67366d1e7513397953f71c9b29, OOPS-001af265e7d5322fdd12c9b12b4fed8c, OOPS-00ae6fedb93aa14a7fc508d51b9fa6a7, OOPS-010f606986cdc5008d999fabe085e6aa, OOPS-01432c961a9928b26bb0d210d723a53b | 02:00 |
| wgrant | Ah | 02:02 |
| wgrant | I bet it's the bug listings release | 02:02 |
| wgrant | It doesn't work with feeds. | 02:02 |
| wgrant | Which are always anonymous, so were never tested. | 02:02 |
| wgrant | lifeless: ^^ | 02:02 |
| lifeless | grah | 02:03 |
| lifeless | I guess we need to rollback | 02:03 |
| jamesh | lifeless: I guess that would work. Do we lose anything by having the view assign an ID instead of the publisher doing so? | 02:03 |
| wgrant | lifeless: It's been broken for a day, and it's a major thing. | 02:03 |
| wgrant | "it" == bug listings | 02:03 |
| wgrant | So I think we should keep it on. | 02:03 |
| wgrant | It's not as if anybody uses feeds anyway. | 02:03 |
| lifeless | well, 5633 polls for them | 02:04 |
| lifeless | wgrant: lets start with a bug | 02:04 |
| lifeless | jamesh: I think its fine to allow the earliest point that knows an error is on the way to assign an id - the hash based aproach is just one way to get a unique id | 02:04 |
| lifeless | jamesh: oops can render errors itself | 02:05 |
| lifeless | jamesh: or you could pass a django template into oops | 02:05 |
| lifeless | jamesh: or you can assign the id earlier, if the framework really wants to render its own errors | 02:05 |
| lifeless | jamesh: the existing facilities are the trivial string template that oops has itself or a callback you can supply to the middleware constructor | 02:08 |
| jamesh | lifeless: I think giving frameworks the ability to render their own error pages makes python-oops-wsgi more appealing, since it can be dropped into an existing app | 02:09 |
| lifeless | jamesh: I think the first thing I would attempt would be to discard the django error page but wire up the callback to let me use a django template to render the error page | 02:09 |
| james_w | so, I can't do this patch as I am yet to get close to having a working buildout | 02:09 |
| wgrant | lifeless: Hm | 02:09 |
| lifeless | james_w: oh? what happens? | 02:10 |
| wgrant | 'bugs.dynamic_bug_listings.enabled pageid:Person:latest-bugs.atom 2 '? | 02:10 |
| lifeless | wgrant: might work, we should try | 02:11 |
| wgrant | That seems to be the only popular affected page. | 02:11 |
| jamesh | lifeless: well, once we've got that django bug report I filed fixed, that should be possible: if start_response() is called with an exc_info, just re-raise it | 02:11 |
| lifeless | jamesh: that seems to be slightly different | 02:12 |
| jamesh | then present an error page after the exception bubbles back up to the middleware | 02:12 |
| lifeless | oh right | 02:12 |
| lifeless | so yes, get the middleware's start_response to be called with exc_info | 02:13 |
| jamesh | with that in mind, the debug error page Django presents is pretty nice | 02:13 |
| lifeless | ah, make_app(template=...) | 02:13 |
| jamesh | so when developing an app, I'd prefer to see that than an oops-wsgi error page | 02:13 |
| lifeless | jamesh: sure, but not for deployed apps ? | 02:14 |
| lifeless | jamesh: so have dev mode eat the exceptions and render itself | 02:14 |
| lifeless | jamesh: anyhow, I'm happy to let the app allocate ids | 02:14 |
| lifeless | pragmatic | 02:14 |
| james_w | lifeless, confusing error messages | 02:14 |
| jamesh | lifeless: I'm of two minds there. The error pages we've got wired up in U1 don't do much , so would be pretty easy to reimplement in the middleware | 02:15 |
| lifeless | james_w: pastebin ? | 02:15 |
| james_w | apparently when it said I might have misspelled a dependency, it really meant that it couldn't install from the cache because the cache is currently empty | 02:15 |
| lifeless | james_w: you're using the LP cache, right ? | 02:15 |
| jamesh | on the other hand, if I could just get/create an OOPS ID in the existing error page code, that would be a much smaller change | 02:15 |
| james_w | lifeless, nope | 02:15 |
| lifeless | james_w: use the LP cache | 02:15 |
| jamesh | and I suspect other people trying to integrate python-oops would feel the same | 02:15 |
| lifeless | jamesh: these are not exclusive options | 02:15 |
| jamesh | lifeless: I understand that. | 02:16 |
| lifeless | :) | 02:16 |
| lifeless | I think we should make it easy to get going | 02:16 |
| jamesh | I'm just thinking out loud about why I might pick one option over the other | 02:16 |
| lifeless | with better/more organised stuff being something you can grow into | 02:16 |
| lifeless | jamesh: I'm glad you are doing so :) I was just adding commentary | 02:16 |
| lifeless | my cat wants to eat my galaxy tab | 02:19 |
| lifeless | its a little disconcerting | 02:20 |
| james_w | lifeless, https://code.launchpad.net/~james-w/python-oops-wsgi/start_response-exc_info/+merge/90031 | 02:31 |
| lifeless | jthanks; I have some feedback | 02:35 |
| lifeless | its a little more than trivial, or I'd just do it | 02:35 |
| StevenK | wgrant: Have you seen bug 921175? | 03:15 |
| _mup_ | Bug #921175: Bug overview page tag links are not properly escaped, thus made useless <404> <bugtag> <tales> <Launchpad itself:Triaged> < https://launchpad.net/bugs/921175 > | 03:15 |
| StevenK | And no, it's not a dupe. :-( | 03:16 |
| wgrant | I have indeed. | 03:17 |
| wgrant | lifeless: How should I do the case-insensitivity in python-oops-tools? | 03:17 |
| wgrant | There's no iin :) | 03:17 |
| wgrant | And I don't seem to be able to lower() or upper() it first. | 03:17 |
| lifeless | wgrant: this is the db query ? | 03:18 |
| wgrant | yes. | 03:18 |
| wgrant | to_delete = set(Oops.objects.filter( | 03:18 |
| StevenK | I don't want to perform the same fix in the same way within a few days. :-( | 03:18 |
| wgrant | date__gte=prune_from, date__lte=prune_until).exclude( | 03:18 |
| wgrant | oopsid__in=references)[:10000]) | 03:18 |
| lifeless | wgrant: I'm curious what is mangling the case in the first place; is it just fimble-fingered copy-pastes ? | 03:18 |
| wgrant | lifeless: Hmm? | 03:18 |
| wgrant | lifeless: Your LP API upper()s them before they're returned. | 03:18 |
| lifeless | wgrant: it does? Ok, so I am stupid. | 03:18 |
| lifeless | I have -no- idea what I was thinking. | 03:19 |
| lifeless | just checking the schema | 03:19 |
| wgrant | oops-tools was already upper()ing them in parts. | 03:20 |
| StevenK | wgrant: So I guess I write a IBugTag and then a tales adapter? | 03:20 |
| lifeless | wgrant: that was eliminated a while ago | 03:20 |
| wgrant | StevenK: No. There's no sensible way to do a fmt:url here. | 03:20 |
| lifeless | wgrant: it does that on input only, for old-style oopses | 03:21 |
| lifeless | wgrant: the db is case sensitive, and indexed case sensitively | 03:21 |
| wgrant | lifeless: Ah, right, I remember that now. | 03:21 |
| lifeless | wgrant: I'd fix the API TBH | 03:21 |
| wgrant | I only didn't fix it because I presumed you had your reasons :) | 03:21 |
| wgrant | I'll not land the datedir-repo fix, then. | 03:21 |
| * lifeless is apparently a camel toenail smoking crackhead | 03:22 | |
| wgrant | Just cowboy it and prune to get us out of immediate peril.. | 03:22 |
| wgrant | And fix the API this afternoon :) | 03:22 |
| StevenK | wgrant: There isn't? We can create an object with the context and the tag and we can construct an URL quite easily? | 03:22 |
| lifeless | which is another way to say I have -no- idea why I did that. Probably to make some test pass or something | 03:22 |
| wgrant | StevenK: FSPOEVO "quite easily" | 03:22 |
| StevenK | wgrant: It's the same code as the view uses? canonical_url() + urllib.quote() ? | 03:25 |
| wgrant | POE == Probably Over-Engineered | 03:25 |
| wgrant | Introducing a new content class and interface for this seems like utter overkill. | 03:26 |
| wgrant | Particularly since it's just a special case of a search. | 03:26 |
| lifeless | what I don't understand | 03:26 |
| lifeless | is how the tags are getting into the template without escaping | 03:27 |
| lifeless | are we manually rendering the links? | 03:27 |
| wgrant | lifeless: They're (HT|X)ML-escaped. | 03:27 |
| wgrant | They're not URL-escaped. | 03:27 |
| lifeless | ah | 03:27 |
| lifeless | fairy nuff | 03:27 |
| wgrant | People don't understand escaping :( | 03:27 |
| lifeless | well | 03:28 |
| lifeless | doesn't help that two different escape rules are needed | 03:28 |
| lifeless | because two different bodies created the dsl's for presentation and linking | 03:28 |
| wgrant | Well, our code shouldn't lead us to sin. | 03:28 |
| wgrant | We shouldn't have to think about escaping :) | 03:29 |
| wgrant | Anyway. | 03:29 |
| wgrant | Time to prune 70GB of OOPSes. | 03:29 |
| wgrant | forrealz | 03:29 |
| StevenK | wgrant: I'm just unhappy that I you're suggesting I propagate my horrible python:tag[x] madness from the last fix. | 03:30 |
| wgrant | StevenK: You could do it in the view if you want. | 03:31 |
| wgrant | And for this you will probably have to. | 03:31 |
| wgrant | Because of mustache. | 03:31 |
| StevenK | wgrant: And then use structure and you'll probably kill me | 03:31 |
| wgrant | But introducing 100 lines of code where three will do is silly. | 03:31 |
| wgrant | No structure. | 03:31 |
| StevenK | TBH, I've not looked at the the view or mustache template | 03:32 |
| lifeless | moustache renders on the client side | 03:32 |
| lifeless | so you'll have to fix the data dict it renders from (or the moustache template itself) | 03:32 |
| lifeless | it also renders server side :) | 03:32 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 3*10^2 | ||
| wgrant | Yay | 03:34 |
| wgrant | 360 criticals | 03:34 |
| wgrant | We can round up! | 03:34 |
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| nigelb | :| | 03:38 |
| nigelb | what's wrong with 3*10^2+60 | 03:38 |
| wgrant | om nom nom oopses | 03:39 |
| lifeless | nigelb: future proofing | 03:43 |
| StevenK | /wrists | 03:44 |
| StevenK | nigelb: 3.6*10^2, ITYM? | 03:45 |
| nigelb | ooh. that wworks too! | 03:46 |
| StevenK | nigelb: Haha. Haddin comes out and hits a six for his first shot | 03:47 |
| nigelb | StevenK: For a guy who doesn't like cricket, you sure watch lot of it... | 03:47 |
| StevenK | Australia is win, incredibly comfortably, so I like it. | 03:48 |
| StevenK | s/win/winning/ | 03:48 |
| nigelb | haha, troll! | 03:49 |
| nigelb | StevenK: out! :D | 03:51 |
| StevenK | Yes, bah. | 03:51 |
| nigelb | I like how that happened just after you trolled :D | 03:51 |
| * StevenK sends Ponting a cranky e-mail | 03:52 | |
| * StevenK tries to work out *HTF* this mustache template is populated. | 03:55 | |
| mwhudson | australia are practically collapsing now | 03:56 |
| nigelb | StevenK jinxed it! | 03:56 |
| StevenK | mwhudson: And you love it | 03:56 |
| mwhudson | heh well | 03:56 |
| mwhudson | this series is not especially interesting any more | 03:57 |
| StevenK | mwhudson: So tell me, do you go for NZ as well, or just whoever is playing Australia? | 03:57 |
| nigelb | lol | 03:57 |
| nigelb | I'm going to save these logs to show back to StevenK when he says he doesn't like cricket the next time | 03:57 |
| StevenK | nigelb: I can't just sit and watch a full test match, because I *will* go mad. But I can wonder past and see what the score is every 15-20 or so | 03:59 |
| nigelb | I can't watch a full test match ever. | 03:59 |
| nigelb | My roommates can watch a full test match and the highlights :/ | 03:59 |
| nigelb | s/can/will/g | 03:59 |
| StevenK | Haha | 04:00 |
| StevenK | nigelb: TBH, this isn't so much a test match as a routing | 04:00 |
| nigelb | Hah. | 04:01 |
| nigelb | we need #ubuntu-cricket :D | 04:01 |
| wgrant | StevenK, lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-911520/+merge/90040 | 04:15 |
| StevenK | wgrant: r=me, but no fair including my complaints in it | 04:18 |
| wgrant | Bah, I missed one. | 04:18 |
| wgrant | I removed a couple of irrelevant lines. | 04:18 |
| wallyworld | StevenK: In Python 2.6, round(0.29999999, 5) = 0.29999 whereas it works in Python 2.7 ie gives 0.3 :-( | 04:20 |
| StevenK | Bwaha | 04:20 |
| wallyworld | so i'm commenting a line of a doc test so that use-convoy can lp-land | 04:21 |
| wallyworld | that was the only ec2 land failure | 04:21 |
| StevenK | Don't bother | 04:22 |
| wgrant | wallyworld: that's a new test? | 04:23 |
| wallyworld | wgrant: nope. that's why i'm very confused. lib/lp/app/widgets/doc/location-widget.txt | 04:23 |
| wallyworld | we didn't touch that file | 04:23 |
| wallyworld | apart from trying to get it to pass testing | 04:24 |
| wgrant | Don't randomly comment out bits of tests because you don't understand why they're broken :) | 04:24 |
| wallyworld | very strange | 04:24 |
| wgrant | It will fail on your machine. | 04:24 |
| wgrant | But should pass on ec2. | 04:24 |
| wallyworld | nope. fails on ec2, passes locally | 04:24 |
| wallyworld | and it's a one line, meaningless test | 04:24 |
| wallyworld | we need to get this landed | 04:24 |
| wallyworld | will fix after | 04:24 |
| wgrant | Can you pastebin the failure? | 04:25 |
| wgrant | I have a change in my 2.7-fixes-0 branch to fix that very test. | 04:25 |
| wgrant | But we need to work out why it's failing for you. | 04:26 |
| wallyworld | https://pastebin.canonical.com/58721/ | 04:26 |
| wallyworld | it works for me | 04:26 |
| wallyworld | it doesn't work for ec2 | 04:26 |
| wallyworld | also works for rick | 04:26 |
| wgrant | Confused | 04:26 |
| wgrant | That test does not match devel | 04:26 |
| wgrant | >>> widget.center_lng | 04:26 |
| wgrant | 0.29... | 04:26 |
| wgrant | That's devel. | 04:26 |
| wgrant | So you have changed the file, to something that only works in 2.7. | 04:27 |
| wallyworld | yes, and it failed the first time because it wanted 0.3 | 04:27 |
| wgrant | It didn't :) | 04:27 |
| wgrant | It only does that on 2.7 | 04:27 |
| wgrant | Which ec2 is not yet. | 04:27 |
| wallyworld | we only changed it because ec2 complained from memory, but not sure now | 04:27 |
| wallyworld | but round(0.299999) should always give 0.3 ffs | 04:28 |
| wallyworld | regardless of pythin version | 04:28 |
| wgrant | round returns a float, not a str | 04:29 |
| wallyworld | which should print sensibly you would think | 04:29 |
| wgrant | floats are a little more complicated than that :) | 04:30 |
| wallyworld | sure, but a rounded value should print out as expected | 04:30 |
| wallyworld | i'm not sure what rick is running, 2.6 or 2.7 | 04:31 |
| wgrant | wallyworld: What does rounding mean for an IEEE754 number? | 04:33 |
| wgrant | It's a float, not a decimal. | 04:33 |
| wgrant | You'd have to somehow work out the shortest sequence of digits that lossily evaluates to the same thing. | 04:34 |
| wgrant | Which I guess must be what 2.7 does. | 04:34 |
| wgrant | But that has little to do with rounding. | 04:34 |
| wallyworld | guess so. but i'm still surprised given the low percison it is being rounded to that it doesn't work as expected | 04:35 |
| wallyworld | we still have more cleanup to do, so we'll fix it as part of that. it's one line of a test for a very peripheral feature | 04:35 |
| wgrant | http://bugs.python.org/issue1580 | 04:39 |
| wallyworld | seems like a right royal mess | 04:41 |
| * StevenK grumbles at the RMS | 04:41 | |
| StevenK | (New name for the RTA) | 04:41 |
| wgrant | Non-base-10 floats are, yes. | 04:41 |
| wallyworld | StevenK: can you land ~wallyworld/launchpad/use-convoy for me? pqm-submit doesn't work either :-( | 04:42 |
| StevenK | wallyworld: What's the error? | 04:43 |
| wallyworld | same thing as with lp-land | 04:43 |
| wallyworld | missing get function | 04:43 |
| StevenK | Didn't the update of bzr-pqm fix it? | 04:44 |
| wallyworld | i had thought so, but then i apt updated. and it seems broken again. but not sure. let me check | 04:45 |
| StevenK | wallyworld: Are you right for me to land this? | 04:47 |
| wallyworld | StevenK: just updated my .bazaar/plugins/pgm checkout and there was one update but it's still broken | 04:47 |
| wallyworld | StevenK: yes please | 04:47 |
| * StevenK sighs at lp-land and branches it locally | 04:48 | |
| wallyworld | don't forget to edit the commit message to remove the duplicated tags | 04:49 |
| wallyworld | that lp-land puts there | 04:49 |
| StevenK | Yes, thanks, I've used it before. | 04:50 |
| wallyworld | sorry, didn't mean to tell you to suck eggs | 04:51 |
| StevenK | My tree is WADLing | 04:52 |
| wallyworld | StevenK: this branch includes a make switch to disable the WADL stuff | 04:54 |
| StevenK | Yes, I know that too. I've read the entire MP. | 04:55 |
| wallyworld | ok, i'll shutup now | 04:56 |
| StevenK | I don't believe that. :-P | 04:56 |
| wallyworld | well, stranger things have happened | 04:57 |
| StevenK | wallyworld: Merged. | 04:57 |
| StevenK | wallyworld: Did you want the PQM message? | 04:57 |
| wallyworld | \o/ thanks :-) | 04:57 |
| wallyworld | nah | 04:58 |
| nigelb | oh, one of those days when I wwant to have a bash.org like site for LP. | 04:58 |
| StevenK | r14722 for reference | 04:58 |
| wallyworld | StevenK: thanks. just in time for bb too :-) | 04:58 |
| StevenK | What? Oh crap | 04:59 |
| wallyworld | uh oh | 04:59 |
| wallyworld | ? | 04:59 |
| StevenK | Oh well, WCPGW | 04:59 |
| wallyworld | you mean with buildbot? | 05:00 |
| nigelb | StevenK: Famous last words. | 05:00 |
| StevenK | wallyworld: I mean if it fails buildbot, it gets reverted | 05:00 |
| StevenK | nigelb: Yes, that's why I said them | 05:00 |
| wallyworld | let's hope the bb updates worked then i guess | 05:00 |
| nigelb | StevenK: Also, "lets see what this button does" | 05:00 |
| StevenK | It makes the Indian cricket team lose every mat.... OH. | 05:01 |
| nigelb | dammit. | 05:01 |
| wallyworld | StevenK: at least it will fail during make so we'll know soon enough | 05:01 |
| StevenK | Damn it, laughing a lot sends me into a coughing fit | 05:02 |
| * wallyworld goes to get the kid from school and hopes bb is still green when he gets back | 05:02 | |
| * StevenK can't work out how this mustache template is populated | 05:02 | |
| wgrant | StevenK: Find both things that render it and see where they get their data? :) | 05:07 |
| StevenK | wgrant: I just found it | 05:07 |
| StevenK | - 'tags': [{'url': base_tag_url + tag, 'tag': tag} | 05:07 |
| StevenK | + 'tags': [{'url': base_tag_url + urllib.quote(tag), 'tag': tag} | 05:07 |
| wgrant | Right. | 05:08 |
| * StevenK stabs the messaging indicator more | 05:16 | |
| wgrant | Ewww | 05:18 |
| wgrant | lp.mustache | 05:18 |
| wgrant | Is there not a way to do that that isn't a crime against humanity? | 05:18 |
| StevenK | I already asked | 05:20 |
| StevenK | But yes, it's incredibly disgusting | 05:20 |
| wgrant | wallyworld: Some bits use YUI.add, some YUI().add. Why? | 05:20 |
| StevenK | Sigh. Python needs Data::Dumper | 05:25 |
| StevenK | And no, pprint doesn't count, it's utterly poor in comparsion. | 05:25 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/link-bug-tags-correctly-redux/+merge/90044 | 05:39 |
| wgrant | StevenK: Done | 05:40 |
| StevenK | wgrant: Thanks | 05:40 |
| wallyworld | wgrant: they are not supposed to use different forms. i thought i had found and fixed them all | 06:34 |
| wallyworld | the codebase was a bit of a consistency mess | 06:34 |
| wgrant | Heh, yes. | 06:35 |
| wgrant | It's certainly no worse than it was. | 06:35 |
| wgrant | I just hoped it would make it perfect :) | 06:35 |
| wallyworld | it will be. i'm pissed that i missed some | 06:35 |
| wallyworld | i'll let rick know and he can clean up during his day | 06:35 |
| wgrant | That's nice of you :P | 06:36 |
| wallyworld | well, we want it done asap :-) | 06:36 |
| wallyworld | and he's working on the next steps | 06:36 |
| wallyworld | so it won't be much to fix | 06:36 |
| wallyworld | if he can't then i will for sure | 06:36 |
| wgrant | Yup | 06:37 |
| wallyworld | at least buildbot is running the tests, so that's one hurdle overcome | 06:39 |
| wallyworld | meaning the bb update worked :-) | 06:39 |
| stub | I'm adding Lucid PG 9.1 to the PPA and will be adding PG 9.1 to the database-deps | 07:53 |
| wgrant | stub: Slony likes it now? | 07:58 |
| wgrant | I'm not sure we can sensibly upgrade until we acquire more CPUs :/ | 07:59 |
| stub | Good enough to get started - fixes are in, might need to upgrade our slony if we see the 9.1 issues | 07:59 |
| stub | Why do we need more CPUs? | 07:59 |
| wgrant | stub: Unless we want to do an in-place upgrade on wildcherry, we'd have to switch the master for a day. | 08:02 |
| stub | Yes. I'm investigating inplace. Looks fine except for plpython stored procedures, so I need to investigate if the workarounds are sane. | 08:03 |
| wgrant | Seems a bit sad to do that. | 08:03 |
| wgrant | But I guess. | 08:03 |
| stub | (perhaps waiting for PG to fix the plpython pg_upgrade bug is best - discussions ramping up again after the break) | 08:03 |
| stub | The work around is creating a symlink. I need to determine if that is going to break future inplace upgrades | 08:04 |
| stub | In place isn't sad - looks like minutes, but of course will need to confirm timings on staging once I've got the glitches ironed out | 08:05 |
| wgrant | Well, we would presumably miss out on some of the improvements on unrebuilt DBs. | 08:07 |
| stub | But before we go upgrading production and staging, we need the test suite passing | 08:07 |
| wgrant | Bah. | 08:07 |
| wgrant | Where's the fun in that. | 08:07 |
| stub | Yes, bloated would remain bloated. | 08:07 |
| wgrant | Is there anything much apart from the string escaping thing? | 08:07 |
| stub | Some minor work in database/schema so far, nothing unexpected. I want to get ec2 able to run the test suite since I can't be arsed running the full test suite locally. | 08:08 |
| stub | lp:~stub/launchpad/postgresql-9.1 | 08:09 |
| wgrant | Ah, not too bad. | 08:11 |
| === jtv is now known as jtv-eat | ||
| === jtv-eat is now known as jtv | ||
| adeuring | good morning | 09:02 |
| lifeless | wgrant: we don't have capacity to switch masters atm | 09:27 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | lifeless: That was why I asserted that we couldn't sensibly upgrade until we acquired more CPUs. | 09:39 |
| wgrant | I guess we need to get used to in-place upgrades if we're going to drop slony at some point. | 09:40 |
| wallyworld | rick_h: you thre yet? | 10:18 |
| === mpt_ is now known as mpt | ||
| rick_h | wallyworld: what's up? | 11:23 |
| wallyworld | rick_h: THE branch is almost through buildbot :-D | 11:23 |
| rick_h | yay | 11:23 |
| wallyworld | i missed a couple of places where it used YUI().add instead of YUI.add | 11:24 |
| rick_h | that's ok, YUI().add should be safe | 11:24 |
| wallyworld | yeah, but it would be cool to clean up | 11:24 |
| rick_h | k | 11:24 |
| wallyworld | also, i had to disable a test | 11:24 |
| wallyworld | you know that location-widget.txt test where round() was used? | 11:24 |
| rick_h | ok, which test and I'll go back at it | 11:24 |
| rick_h | yea | 11:25 |
| wallyworld | well, round() is broken on 2.6 | 11:25 |
| wallyworld | but it works in 2.7 | 11:25 |
| rick_h | lol, but of course it is. hmmm, I ran it in 2.6 and it passed? | 11:25 |
| wallyworld | that's what i thought. but i tried it in 2.6 and it failed, as did ec2 | 11:25 |
| rick_h | oh, no guess I'm on 2.7 | 11:25 |
| rick_h | sorry, don't even know which python version I'm on | 11:25 |
| wallyworld | so, i commented that line of the doc test | 11:25 |
| rick_h | ok | 11:26 |
| wallyworld | and we will be on 2.7 soon | 11:26 |
| wallyworld | i fell dirty doing that but we needed to land this thing | 11:26 |
| rick_h | rgr | 11:26 |
| wallyworld | would be nice to fix in 2.6 if we could do so feasibly | 11:26 |
| rick_h | something is up with that test anyway, forever and ever it's just always spit out perfect 3.0 and suddenly it's doing 2.999999 consistantly? strange | 11:26 |
| wallyworld | yeah | 11:27 |
| rick_h | yea, I can look at what with round is broken and a different way to do it | 11:27 |
| wallyworld | the pressure will be off a bit IF this passes qastaging once bb has finished with it :-) | 11:27 |
| === al-maisan is now known as almaisan-away | ||
| rick_h | yea, will be nice | 11:27 |
| wallyworld | how long do you think we will need to get the final convoy stuff sorted? | 11:28 |
| rick_h | it's actually fine | 11:28 |
| rick_h | convoy dev reviewed it yesterday and I fixed (added a test) and resubmitted for review | 11:28 |
| rick_h | I'd feel comfy using that brach for our own ppa | 11:28 |
| wallyworld | so it's just the deployment coordination that needs doing | 11:28 |
| rick_h | so we can do that any time, just have to change to their upstream once they merge it in | 11:29 |
| wallyworld | i mean getting prod systems all set up | 11:29 |
| rick_h | right | 11:29 |
| rick_h | I'm sure we can get our hands held through that processes without too much trouble | 11:30 |
| wallyworld | we should send an email to dev and ask a few suckers ^H^H^H^H^H^H guinea pigs to try it | 11:30 |
| rick_h | yep, I've got a couple of people actually from my ubuntu loco ready | 11:30 |
| wallyworld | cool | 11:30 |
| rick_h | and jcastro has suckered me into enough stuff I can try to get him as well. He owes me and should be in lots of places of LP I don't go every day | 11:30 |
| wallyworld | ok. i think the intent is to turn on the ff on prod for at least ~launchpad | 11:31 |
| wallyworld | initially | 11:31 |
| StevenK | So we need the MP merged in, a new release -- if upstream actually make a tarball, that would be awesome. | 11:31 |
| rick_h | StevenK: yea, I submitted my changes back after their review like 1hr later | 11:32 |
| wallyworld | yeah :-) | 11:32 |
| rick_h | so hopefully they're looking at it soon | 11:32 |
| StevenK | Then we need to work out the deployment strategy -- I think I understand that | 11:32 |
| wallyworld | i think we will need about a week for that? | 11:32 |
| rick_h | StevenK: but at the end of the day, he only wanted an extra test so no complaints from the changes themselves | 11:32 |
| wallyworld | to get everything done | 11:32 |
| StevenK | rick_h: Sure, but it was still marked Needs Fixing | 11:32 |
| rick_h | is it? I marked it back to needs review yesterday? | 11:32 |
| StevenK | rick_h: His vote was Needs Fixing, I mean | 11:33 |
| StevenK | What I'm not clear about is how to set the convoy root url in the code | 11:33 |
| StevenK | /+combo/r..../?... | 11:33 |
| rick_h | StevenK: ah right | 11:33 |
| StevenK | rick_h: wallyworld and I are off tomorrow | 11:33 |
| rick_h | StevenK: right, so my understanding is that the .wsgi file will set a combo root of /var/tmp/convoy and our application code (LP) will set the root to /+combo/$revno | 11:34 |
| StevenK | rick_h: So you have today and tomorrow to beat sidnei with a stick. | 11:34 |
| StevenK | rick_h: On qas and prod, it probably won't be /var/tmp/convoy, but sure. | 11:34 |
| rick_h | so on disk will be /var/tmp/convoy/rev12345 and /var/tmp/convoy/rev12346 | 11:34 |
| rick_h | ok, well whatever that dir is, but that's my understanding of how that works out atm | 11:35 |
| StevenK | rick_h: The disk stuff I'm fine with -- that's the easy bit. | 11:35 |
| StevenK | What I'm not clear about is the *code*. | 11:35 |
| rick_h | what part weren't you sure about then? | 11:35 |
| rick_h | so the code is in the YUI.GlobalConfig that the base and the combo roots are '/+combo/rev12345' | 11:35 |
| rick_h | with a prefix of yui or lp based on the group | 11:35 |
| wgrant | rick_h: round() returns a float. | 11:36 |
| wgrant | It's not broken. | 11:36 |
| wgrant | It's just impossible to represent most decimal fractions as non-decimal floating point formats :) | 11:36 |
| rick_h | wgrant: right, that's cool. expected even. | 11:36 |
| StevenK | Oh, we have a TAL define for revno | 11:36 |
| rick_h | StevenK: right | 11:36 |
| wallyworld | i've never had an issue like this in Java for example | 11:36 |
| wgrant | wallyworld: You probably don't use doctests in Java :) | 11:37 |
| StevenK | rick_h: Right. So we add a combo_url of string:/+combo/r${revno}; | 11:37 |
| wallyworld | yes, but i print stuff out | 11:37 |
| wgrant | It's still == 0.3 | 11:37 |
| rick_h | StevenK: exactly | 11:37 |
| * StevenK is no longer concerned | 11:37 | |
| rick_h | that's ok, one day I'm going to be at pycon with the guy that invented doctests and he's going to miss the rest of the conference because I've locked him in a closet with a handful of saltines | 11:38 |
| wgrant | wallyworld: And whatever method you use to print probably performs rounding. | 11:38 |
| StevenK | rick_h: BWAHAHA | 11:38 |
| wgrant | wallyworld: Whereas here in the doctest we're just using __str__/__repr__, which need to return something that is equal. | 11:38 |
| wgrant | Not just vaguely correct. | 11:38 |
| cjwatson | hmm. last night's generate-contents-files run: | 11:38 |
| cjwatson | 2012-01-25 07:05:13 DEBUG Installing new Contents file for precise/amd64. | 11:38 |
| cjwatson | 2012-01-25 07:05:17 DEBUG Installing new Contents file for precise/armel. | 11:38 |
| cjwatson | 2012-01-25 07:05:20 DEBUG Installing new Contents file for precise/armhf. | 11:38 |
| cjwatson | 2012-01-25 07:05:23 DEBUG Installing new Contents file for precise/i386. | 11:38 |
| cjwatson | 2012-01-25 07:05:26 DEBUG Installing new Contents file for precise/powerpc. | 11:39 |
| cjwatson | but the versions in dists/ are dated 2012-01-24. | 11:39 |
| wgrant | It probably raced. | 11:39 |
| wallyworld | wgrant: sure, but that web page you pasted earlier talks about how the algorithm for strigification needs improving | 11:39 |
| wallyworld | StevenK: are we going to upgrade the apache wsgi lib from suggests to depends? | 11:39 |
| wgrant | wallyworld: Well, FSVO "needs" | 11:39 |
| wallyworld | :-) | 11:40 |
| StevenK | rick_h: Is there a flag in your convoy MP to turn on the dir walking stuff? | 11:40 |
| StevenK | wallyworld: My jury is still out. | 11:40 |
| rick_h | StevenK: no, not a flag. It *just works* | 11:40 |
| cjwatson | hmm, yes, 07:05 is just after the start of a publish-ftpmaster run. | 11:40 |
| StevenK | rick_h: Fair enough | 11:40 |
| rick_h | if the extra bits are in the url it routes, if the url only has a /convoy then it doesn't | 11:41 |
| wgrant | 2012-01-25 07:03:05 INFO Creating lockfile: /var/lock/launchpad-publisher.lock | 11:41 |
| wgrant | cjwatson: ^^ from publish-ftpmaster.log | 11:41 |
| wgrant | cjwatson: Is the extra arch making g-c-f take too long? | 11:41 |
| StevenK | rick_h: Then beat sidnei with a stick, get his +1 and get him to land it. | 11:41 |
| wallyworld | StevenK: ok. i'm just asking because it will affect the "how to" instructions | 11:41 |
| rick_h | will try | 11:41 |
| StevenK | wallyworld: Sure. | 11:42 |
| * rick_h goes to look up what TZ he's in | 11:42 | |
| cjwatson | It takes three hours. It's probably dumb luck whether it happens to run when publish-ftpmaster is running. | 11:42 |
| cjwatson | Now that we're on half-hour publishing I guess the odds have got worse. | 11:42 |
| cjwatson | Maybe it should copy into dists.new if it exists. | 11:42 |
| wgrant | cjwatson: The publisher deliberately skipped an hour a day for this reason. | 11:42 |
| wgrant | Does it not still? | 11:42 |
| cjwatson | It doesn't, but in any case it would have to skip rather a lot ... | 11:43 |
| gmb | Has anyone seen this before when trying to pull devel? https://pastebin.canonical.com/58731/ | 11:53 |
| gmb | I can't tell if it's a codehosting problem or a local bzr problem. | 11:53 |
| wallyworld | rick_h: buildbot just completed, branch should be on qastaging in around 45 minutes or maybe a bit sooner | 11:55 |
| gmb | Oh, it's a "I don't get prompted for my SSH key" problem. | 11:55 |
| gmb | Weird. | 11:55 |
| StevenK | We need the new convoy, and we need to change the base template before we can think about talking to a webop to configure qas/staging | 12:02 |
| wallyworld | yes | 12:04 |
| wgrant | gmb: See #-ops | 12:05 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| StevenK | rick_h: https://code.launchpad.net/~stevenk/launchpad/combo-url/+merge/90093 | 12:26 |
| rick_h | wallyworld: awesome | 12:30 |
| rick_h | StevenK: looks good to me. I'd approve but I'm in mentor mode anyway so someone would have to second it | 12:31 |
| StevenK | rick_h: It even works, so you can +1 if you wish | 12:32 |
| rick_h | StevenK: ok, made my comment and marked it as needs review ok? | 12:33 |
| wallyworld | StevenK: how does it work in dev mode where revno is "unknown"? | 12:34 |
| rick_h | hah, wallyworld for the block. Yea, because in dev mode the path is /var/tmp/convoy and the revno will need to be empty/non-existant | 12:35 |
| StevenK | wallyworld: In make run, the revno is expanded out, but the current convoy ignores the path | 12:36 |
| wallyworld | yes, but when we upgrade it will break, no? | 12:36 |
| StevenK | When we upgrade it, combo-rootdir will change | 12:36 |
| StevenK | So this can land now, and will not need to change. | 12:37 |
| rick_h | StevenK: but if you have make run, and then you make some changes/commit | 12:37 |
| rick_h | will the revno get incremented? | 12:37 |
| rick_h | I'm not seeing how that'll be easy to manage | 12:37 |
| wallyworld | rick_h: in dev mode, revno is always "unknown" IIRC | 12:37 |
| StevenK | Then the new rootdir will be populated | 12:37 |
| StevenK | wallyworld: It is not | 12:37 |
| wallyworld | i could have sworn it displayed as such on lp.dev | 12:38 |
| wallyworld | or something similar | 12:38 |
| rick_h | StevenK: ok, well we'll need to test/verify that 100% and figure that out to go with that MP change | 12:38 |
| StevenK | I did test it | 12:38 |
| rick_h | StevenK: with the new convoy branch? | 12:39 |
| rick_h | because the current convoy doesn't care about anything in the url, while the new one will end up with missing files if the path isn't right | 12:39 |
| StevenK | rick_h: Right, which is why it's okay to land now. | 12:39 |
| rick_h | right, I'm just saying that I want to make sure we don't *forget* that there's a future breakage there | 12:40 |
| rick_h | and we'll want to think ahead a step and have a plan for getting it to work | 12:40 |
| StevenK | After we switch to new convoy, combo-rootdir will change to populate into CONVOYROOT/rev<revno> | 12:40 |
| rick_h | StevenK: right, but I'm not sure that'll work out in real development | 12:40 |
| StevenK | It sounds okay to me | 12:41 |
| StevenK | rick_h: But we can kick that around when the new convoy turns up | 12:47 |
| deryck | Morning, all. | 14:09 |
| deryck | bigjools, ping | 14:53 |
| bigjools | deryck: o/ | 14:57 |
| mabac | stub, I'm about to propose a patch for the launchpad db schema and would like to ask you about the table permissions. Should I make up a name for a script user and put that in the security.cfg? I notice that there was en email thread about perhaps not having per script table permissions. Did anything happen with that? | 15:05 |
| stub | mabac: Every script or process needs to use a unique database user defined in security.cfg. This is unrelated to creating new tables. | 15:07 |
| === mpt_ is now known as mpt | ||
| stub | mabac: If you create a new table, the security.py script will complain if nothing has permissions to it so you will need to add something to security.cfg (even if it is just adding an entry to the [public] section stating nobody has access). | 15:08 |
| stub | mabac: Assuming you are going to be creating a new table and a new script, you are probably best adding the new database user with permissions in the same branch as your db patch. | 15:08 |
| mabac | stub, aha, I was wondering how to add the new user. thanks, I'll dig for that | 15:09 |
| mabac | stub, and yes, we'll be adding new tables and new scripts | 15:09 |
| stub | mabac: We still have per script table permissions, but feel free to inherit permissions from elsewhere to make life easier. Not the 'write' group though, as that is a real mess. | 15:09 |
| stub | mabac: I'm trying to find a middle road between annoyed developers and throwing out all access controls | 15:10 |
| * jelmer wonders if it's a coincidence that the lp branch scanner doesn't scan anything beyond revision 99999 in lp:~vcs-import/chromium-browser/trunk | 15:10 | |
| mabac | stub, :) that's not trivial, I get that. | 15:11 |
| mabac | stub, so to inherit permissions, I just make the new user part of a suitable group? | 15:11 |
| stub | mabac: If your scripts are related, they each will need a unique user. They all might be clones of each other though, all inheriting their permissions from one place. | 15:12 |
| stub | mabac: Yes, exactly. | 15:12 |
| stub | mabac: user and group is interchangeable - the terminology dates from when they were separate in PostgreSQL. Now there are just roles so you should be able to have a group inheriting from a user and vice versa. | 15:12 |
| mabac | stub, cool, I didn't know that. thanks. I'll give it a go and let you know when I have something for you to review | 15:13 |
| stub | mabac: np. let me know if you need a hand, here or email or whatever. | 15:14 |
| mabac | stub, I'll certainly let you know | 15:16 |
| mabac | stub, thanks! | 15:16 |
| mabac | ls | 15:23 |
| mabac | oops | 15:23 |
| === matsubara is now known as matsubara-lunch | ||
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| === jml is now known as jml` | ||
| === jml` is now known as jml | ||
| === kornbluth.freenode.net changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| === bdmurray_ is now known as bdmurray | ||
| === mabac is now known as Guest83705 | ||
| abentley | sinzui: I would like to stop using the fictional "application/text" content type for downloading the CoC, and instead use "text/plain". Is this a good idea, or the greatest idea ever? | 16:08 |
| === Guest83705 is now known as mabac_ | ||
| sinzui | abentley, I think the issue is that users are exceedingly adept at copy and paste errors. I think the hack is to ensure that the user gets an untampered file. | 16:09 |
| abentley | sinzui: The content-disposition field should ensure the users save the file. | 16:10 |
| sinzui | abentley, This is only half the problem. These same users still paste a tampered signature into the forms and Lp tells them to go jump in lake of jello | 16:10 |
| sinzui | abentley, Then you have the greatest idea ever | 16:10 |
| abentley | sinzui: Okay. I will verify that users are prompted to download in Firefox, Chromium and Opera. | 16:11 |
| abentley | sinzui: Prompted to save, rather. | 16:11 |
| sinzui | fab | 16:12 |
| mabac_ | stub, do you think something like this looks acceptable? http://bazaar.launchpad.net/~mabac/launchpad/workitems-schema-changes/revision/11322 | 16:13 |
| mabac_ | salgado, ^^^ I'm not sure what scripts we will have to add, trying to create something to start from | 16:14 |
| salgado | I think we'll only need the one to maintain specificationworkitemstats, no? | 16:15 |
| stub | mabac_: That is fine. As these are scripts, you will also need to inherit from the 'scripts' group at a minimum so it has permission to update the script activity table. | 16:17 |
| mabac_ | salgado, that's what I think too. just my cautious nature, expecting more unexpected things ;) | 16:17 |
| mabac_ | stub, aha I missed that. thanks. | 16:20 |
| mabac_ | stub, and for read access from lp code, I can just add SELECTs to the public section, right? | 16:20 |
| stub | mabac_: For the appserver, add it to the [launchpad_main] section | 16:22 |
| === Ursinha` is now known as Ursinha | ||
| stub | mabac_: It is truely needed to be read by everything, public would be appropriate but I don't think we have any tables in that state apart from featureflag | 16:22 |
| mabac_ | stub, yes, this is nothing special in that respect. | 16:23 |
| === mpt_ is now known as mpt | ||
| === SpamapS_ is now known as SpamapS | ||
| === james_w` is now known as james_w | ||
| === deryck is now known as deryck[lunch] | ||
| === matsubara-lunch is now known as matsubara | ||
| === beuno_ is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === mpt_ is now known as mpt | ||
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 | ||
| === micahg_ is now known as micahg | ||
| === _thumper_ is now known as thumper | ||
| lifeless | . | 20:41 |
| === salgado is now known as salgado-afk | ||
| === kirkland` is now known as kirkland | ||
| lifeless | james_w: are you using the django ORM ? | 22:18 |
| james_w | lifeless, yes | 22:21 |
| lifeless | james_w: you might like to do a oops-django package providing django ORM integration for oops. | 22:26 |
| james_w | yes | 22:26 |
| lifeless | james_w: erm, rather timeline-django is what I menat. | 22:26 |
| james_w | in this case we don't really care | 22:26 |
| lifeless | (oops-timeline already exists, so timeline-django is the right join) | 22:26 |
| james_w | give jml a few more days and he's likely to rip the db out of this project | 22:26 |
| james_w | but it would be nice to have anyway | 22:26 |
| lifeless | heh | 22:26 |
| lifeless | what will you be using for persistence? | 22:28 |
| james_w | nothing | 22:28 |
| james_w | this project as it stands doesn't need it | 22:29 |
| lifeless | I'm intruiged | 22:29 |
| james_w | it's a webhooks-based interface to celery (rabbit) bascially | 22:29 |
| james_w | in fact we'd probably have been better off with just celery | 22:29 |
| lifeless | oh, interesting | 22:30 |
| lifeless | you know about txlongpoll right ? | 22:30 |
| james_w | so there's persistence in rabbit for the lifetime of the job, and there's persistence in the other service | 22:30 |
| lifeless | (long poll interface to rabbit) | 22:30 |
| james_w | I've heard of it | 22:30 |
| james_w | I'd like to discuss if it's a good fit, but I've got to dash now | 22:30 |
| lifeless | ciao | 22:31 |
| lifeless | ping me whenever, or drop me a mail | 22:31 |
| james_w | ok | 22:31 |
| wallyworld__ | sinzui: was that a typo in the team lead notes? | 23:23 |
| sinzui | wallyworld__, about wgrant? | 23:24 |
| wallyworld__ | sinzui: the test suite running in *8* seconds? | 23:24 |
| sinzui | wallyworld__, not lp's testsuite | 23:24 |
| sinzui | wallyworld__, MaaS | 23:24 |
| wallyworld__ | right, makes more sense now | 23:24 |
| sinzui | I countered with GDP's testsuite now runs in half the time, 1 second | 23:25 |
| wallyworld__ | i was thinking maybe a few 000's were left off | 23:25 |
| * wallyworld__ wonders if qastaging is broken - it's been down a while | 23:33 | |
| wgrant | rm: cannot remove `/var/tmp/convoy/yui2/event/event.js': Permission denied | 23:33 |
| wgrant | So, yes. | 23:33 |
| wgrant | qastaging is quite broken :) | 23:33 |
| wgrant | wallyworld__: ^^ | 23:33 |
| wgrant | wallyworld__: Also, aren't you not here today? | 23:33 |
| wallyworld__ | wgrant: neither are you :-) | 23:34 |
| wgrant | Yeah, but I had to check that oops-prune finished :) | 23:35 |
| wallyworld__ | hmmm. not sure of the reason for that error off thr top of my head | 23:35 |
| wgrant | Why is it trying to touch /var/tmp? | 23:36 |
| wgrant | On prodish? | 23:36 |
| wallyworld__ | /var/tmp is where convoy looks to load yui from | 23:36 |
| wallyworld__ | like how we use /var/tmp/bazaar etc | 23:37 |
| wgrant | Yes, but not outside dev. | 23:37 |
| wgrant | /var/tmp is not used on anything vaguely productionish. | 23:37 |
| wallyworld__ | let me check something | 23:38 |
| wallyworld__ | wgrant: so there's a CONVOY_ROOT var that needs to be set up | 23:39 |
| wgrant | o_O | 23:39 |
| wallyworld__ | it's set in the Makefile to /var/tmp/convoy | 23:39 |
| wgrant | Is there precedent for that? | 23:39 |
| wallyworld__ | yes, CODEHOSTING_ROOT | 23:40 |
| wallyworld__ | also set in the Makefile | 23:40 |
| wgrant | That's not precedent. | 23:40 |
| wgrant | That's only used in dev targets. | 23:40 |
| wgrant | It looks like we now have to set this variable on every machine. | 23:41 |
| wgrant | Which is a bit silly. | 23:41 |
| wallyworld__ | yes, it should be in .conf somewhere | 23:41 |
| wgrant | Anyway, seems like we need to revert it, or check if LPCONFIG=development, or something like that. | 23:42 |
| wallyworld__ | if it is in .conf, can the Makefile get access to that setting? | 23:42 |
| wgrant | Or split it into a target that isn't jsbuild. | 23:43 |
| wallyworld__ | can we get it going without reverting | 23:43 |
| wgrant | I don't know. How do we get it going? | 23:43 |
| wallyworld__ | if it's "just" a setting that can be tweaked | 23:43 |
| wgrant | What is the desired end goal? | 23:43 |
| wallyworld__ | to have the combo loader root set to something that works ie not /var/tmp/convoy if that doesn't work | 23:44 |
| wgrant | Isn't the real goal at present probably to have it not built at all? | 23:44 |
| wgrant | Since we're some way from using it. | 23:44 |
| wgrant | And don't have deployment sorted out yet. | 23:44 |
| wallyworld__ | yes, but we want to use it locally, so need a way to have it built | 23:45 |
| wallyworld__ | we could also use a flag | 23:45 |
| kirkland | wgrant: so back to https://bugs.launchpad.net/bugs/919241 | 23:45 |
| _mup_ | Bug #919241: Sources published in a private ppa are downloadable by any subscriber <Launchpad itself:Triaged> < https://launchpad.net/bugs/919241 > | 23:45 |
| wgrant | Sure, but until it's finalised you can use a separate Makefile target, or an envvar to enable it. | 23:45 |
| wallyworld__ | yes, that would work | 23:46 |
| kirkland | wgrant: what about dropping a 2-line .htaccess rule in the PPA's pool/.htaccess that 403 denies *.gz? | 23:46 |
| kirkland | wgrant: ie: | 23:46 |
| kirkland | RewriteEngine On | 23:46 |
| kirkland | RewriteRule .*\.gz$ - [F,L] | 23:46 |
| kirkland | wgrant: this isn't something i need all the time, so I could just ask the LOSA to turn that on when s/he sets up my private PPA | 23:46 |
| kirkland | wgrant: and profit! | 23:47 |
| wgrant | kirkland: That would break builds. | 23:47 |
| wgrant | And they could still be downloaded through the web UI. | 23:47 |
| kirkland | wgrant: builds do wgets? | 23:47 |
| wgrant | They get the private sources from ppa.launchpad.net, yes. | 23:47 |
| kirkland | wgrant: hmm, seems like that could be further handled through another rule that whitelists the build requests | 23:49 |
| wgrant | kirkland: But the builders are untrusted :) | 23:49 |
| wgrant | Unless we restrict it to the buildd user. | 23:49 |
| wgrant | Which could work. | 23:49 |
| wgrant | But we'd still have to fix permissions in the app. | 23:50 |
| wgrant | Since they were inappropriately loosed just before I joined. | 23:50 |
| wgrant | loosened. | 23:50 |
| kirkland | wgrant: so this issues is really, really causing major headaches as to how we're trying to use commercial launchpad ppas | 23:50 |
| kirkland | wgrant: it seems so simple to me on the outside | 23:50 |
| wgrant | Everything seems simple from the outside :) | 23:51 |
| kirkland | wgrant: though I appreciate that there's complexity i don't understand | 23:52 |
| kirkland | wgrant: from my PoV, just deny public (outside) downloads of .tar.gz, one way or another | 23:52 |
| wgrant | Sure, but there are at least two ways that need to be stopped. | 23:52 |
| wgrant | And one of them is complex because the buildds use it. | 23:52 |
| wgrant | And we have to work out how it works with PPA dependencies etc. | 23:52 |
| wallyworld__ | wgrant: the icing dir is set to lib/canonical/launchpad/icing. we could use perhaps lib/canonical/launchpad/convoy for now just to get make going ? | 23:55 |
| wgrant | wallyworld__: I'd prefer build/convoy or something like that. | 23:55 |
| wgrant | You'll need to hack everything qastaging script to set it. | 23:55 |
| wgrant | And staging. | 23:56 |
| wgrant | And production. | 23:56 |
| wgrant | So possibly unwise. | 23:56 |
| wallyworld__ | if i understand correctly, it's just the make that is failing | 23:56 |
| wgrant | Right. | 23:56 |
| wgrant | But most things will do a make. | 23:57 |
| wallyworld__ | so we can cowboy the makefile? | 23:57 |
| wgrant | And this affects asuka/gandwana/tellurium | 23:57 |
| wallyworld__ | to get it working | 23:57 |
| wgrant | And every production machine. | 23:57 |
| wgrant | We don't want to unbreak qastaging, because then we'll deploy and fuck production :) | 23:57 |
| wallyworld__ | or i can just lp-land a tweak | 23:57 |
| wgrant | I would lp-land a tweak to split it into a separate target for now. | 23:58 |
| wgrant | Until you sort out how deployment will work. | 23:58 |
| wallyworld__ | i'll come up with something just to get going and get you to +1. | 23:58 |
| wgrant | Great. | 23:58 |
| wgrant | kirkland: So, I'm glad to see thsi being looked at, but it's not as easy as it seems. | 23:59 |
| wgrant | kirkland: And there may even be things I haven't thought of. | 23:59 |
| wgrant | kirkland: Because PPAs were not designed to do what you want. | 23:59 |
| wgrant | They can be made to, and it's very doable, but it's by no means trivial. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!