[00:00] <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:01] <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:02] <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:05] <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:07] <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:08] <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:09] <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.  Really?
[00:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:17]  * wgrant backs up the oopses and tries it.
[00:18] <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:20] <lifeless> rick_h: by .pt you mean [me]tal templates
[00:20] <lifeless> ?
[00:21] <lifeless> rick_h: the js version or the py version is slow?
[00:22] <lifeless> rick_h: the py version looks horrendously slow: see _render_sections
[00:27] <rick_h> lifeless: yea, a lot of things like the macros and such you'd have to look at porting over
[00:28] <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:29] <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:32] <StevenK> lifeless: You have mostly recovered?
[00:34] <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:35] <StevenK> :-(
[00:36] <StevenK> I'm still coughing, but due to asmtha, it takes me a while to shake them off
[00:39] <lifeless> yeah, me too - asmtha sucks
[00:40]  * 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:41] <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:42]  * 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:43]  * 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:44] <wgrant> With 6GB of free space and 100GB of OOPSes, I had little choice :)
[00:51] <lifeless> StevenK: get well :)
[01:03] <james_w> lifeless, did you have an opinion on whether oops should change bson libraries?
[01:10] <lifeless> nope
[01:11] <lifeless> (no opinion)
[01:16] <lifeless> james_w: ^
[01:16] <james_w> ok
[01:16] <james_w> it's rather annoying having the two of them
[01:17] <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:18] <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:19] <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:20] <wgrant> And very much in the style of the rest of the NoSQL DBs :)
[01:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <wgrant> So I don't imagine too much resistance.
[01:28] <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:29] <wgrant> :(
[01:32] <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:33] <lifeless> bah
[01:33] <lifeless> I meant mod_wsgi
[01:34] <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:35] <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:36] <james_w> yes
[01:39] <james_w> ah, it's a bug in oops-wsgi by the look of it
[01:40] <lifeless> oh?
[01:40] <james_w> I'll send an MP in a minute
[01:41] <lifeless> cool; could you use english in the meantime?
[01:45] <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:46] <lifeless> bah
[01:46] <lifeless> thanks for spotting that
[01:47] <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:48] <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:49] <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:50] <james_w> oh, I thought that was what the django.py fixed
[01:50] <lifeless> it works around it
[01:51] <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:52] <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:53] <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:54] <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:55] <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:56] <james_w> lifeless, ah, good point
[01:56] <jamesh> I don't think there is a way to inspect response headers unfortunately
[01:59] <lifeless> so, a django error template that puts content['oops.context']['id'] = str(uuid.uuid1()) => win
[01:59] <lifeless> jamesh: ^
[02:00] <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:02] <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:03] <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:04] <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:05] <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:08] <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:09] <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:10] <lifeless> james_w: oh? what happens?
[02:10] <wgrant> 'bugs.dynamic_bug_listings.enabled pageid:Person:latest-bugs.atom 2 '?
[02:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:19] <lifeless> my cat wants to eat my galaxy tab
[02:20] <lifeless> its a little disconcerting
[02:31] <james_w> lifeless, https://code.launchpad.net/~james-w/python-oops-wsgi/start_response-exc_info/+merge/90031
[02:35] <lifeless> jthanks; I have some feedback
[02:35] <lifeless> its a little more than trivial, or I'd just do it
[03:15] <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:16] <StevenK> And no, it's not a dupe. :-(
[03:17] <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:18] <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?  There's no sensible way to do a fmt:url here.
[03:21] <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:22]  * 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:25] <StevenK> wgrant: It's the same code as the view uses? canonical_url() + urllib.quote() ?
[03:25] <wgrant> POE == Probably Over-Engineered
[03:26] <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:27] <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:28] <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:29] <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:30] <StevenK> wgrant: I'm just unhappy that I you're suggesting I propagate my horrible python:tag[x] madness from the last fix.
[03:31] <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:32] <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:34] <wgrant> Yay
[03:34] <wgrant> 360 criticals
[03:34] <wgrant> We can round up!
[03:38] <nigelb> :|
[03:38] <nigelb> what's wrong with 3*10^2+60
[03:39] <wgrant> om nom nom oopses
[03:43] <lifeless> nigelb: future proofing
[03:44] <StevenK>  /wrists
[03:45] <StevenK> nigelb: 3.6*10^2, ITYM?
[03:46] <nigelb> ooh. that wworks too!
[03:47] <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:48] <StevenK> Australia is win, incredibly comfortably, so I like it.
[03:48] <StevenK> s/win/winning/
[03:49] <nigelb> haha, troll!
[03:51] <nigelb> StevenK: out! :D
[03:51] <StevenK> Yes, bah.
[03:51] <nigelb> I like how that happened just after you trolled :D
[03:52]  * StevenK sends Ponting a cranky e-mail
[03:55]  * StevenK tries to work out *HTF* this mustache template is populated.
[03:56] <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:57] <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:59] <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
[04:00] <StevenK> Haha
[04:00] <StevenK> nigelb: TBH, this isn't so much a test match as a routing
[04:01] <nigelb> Hah.
[04:01] <nigelb> we need #ubuntu-cricket :D
[04:15] <wgrant> StevenK, lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-911520/+merge/90040
[04:18] <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:20] <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:21] <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:22] <StevenK> Don't bother
[04:23] <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:24] <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:25] <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:26] <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:27] <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:28] <wallyworld> but round(0.299999) should always give 0.3 ffs
[04:28] <wallyworld> regardless of pythin version
[04:29] <wgrant> round returns a float, not a str
[04:29] <wallyworld> which should print sensibly you would think
[04:30] <wgrant> floats are a little more complicated than that :)
[04:30] <wallyworld> sure, but a rounded value should print out as expected
[04:31] <wallyworld> i'm not sure what rick is running, 2.6 or 2.7
[04:33] <wgrant> wallyworld: What does rounding mean for an IEEE754 number?
[04:33] <wgrant> It's a float, not a decimal.
[04:34] <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:35] <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:39] <wgrant> http://bugs.python.org/issue1580
[04:41] <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:42] <wallyworld> StevenK: can you land ~wallyworld/launchpad/use-convoy for me? pqm-submit doesn't work either :-(
[04:43] <StevenK> wallyworld: What's the error?
[04:43] <wallyworld> same thing as with lp-land
[04:43] <wallyworld> missing get function
[04:44] <StevenK> Didn't the update of bzr-pqm fix it?
[04:45] <wallyworld> i had thought so, but then i apt updated. and it seems broken again. but not sure. let me check
[04:47] <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:48]  * StevenK sighs at lp-land and branches it locally
[04:49] <wallyworld> don't forget to edit the commit message to remove the duplicated tags
[04:49] <wallyworld> that lp-land puts there
[04:50] <StevenK> Yes, thanks, I've used it before.
[04:51] <wallyworld> sorry, didn't mean to tell you to suck eggs
[04:52] <StevenK> My tree is WADLing
[04:54] <wallyworld> StevenK: this branch includes a make switch to disable the WADL stuff
[04:55] <StevenK> Yes, I know that too. I've read the entire MP.
[04:56] <wallyworld> ok, i'll shutup now
[04:56] <StevenK> I don't believe that. :-P
[04:57] <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:58] <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:59] <StevenK> What?  OH.
[05:01] <nigelb> dammit.
[05:01] <wallyworld> StevenK:  at least it will fail during make so we'll know soon enough
[05:02] <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:07] <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:08] <wgrant> Right.
[05:16]  * StevenK stabs the messaging indicator more
[05:18] <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:20] <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:25] <StevenK> Sigh. Python needs Data::Dumper
[05:25] <StevenK> And no, pprint doesn't count, it's utterly poor in comparsion.
[05:39] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/link-bug-tags-correctly-redux/+merge/90044
[05:40] <wgrant> StevenK: Done
[05:40] <StevenK> wgrant: Thanks
[06:34] <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:35] <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:36] <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:37] <wgrant> Yup
[06:39] <wallyworld> at least buildbot is running the tests, so that's one hurdle overcome
[06:39] <wallyworld> meaning the bb update worked :-)
[07:53] <stub> I'm adding Lucid PG 9.1 to the PPA and will be adding PG 9.1 to the database-deps
[07:58] <wgrant> stub: Slony likes it now?
[07:59] <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?
[08:02] <wgrant> stub: Unless we want to do an in-place upgrade on wildcherry, we'd have to switch the master for a day.
[08:03] <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:04] <stub> The work around is creating a symlink. I need to determine if that is going to break future inplace upgrades
[08:05] <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:07] <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:08] <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:09] <stub> lp:~stub/launchpad/postgresql-9.1
[08:11] <wgrant> Ah, not too bad.
[09:02] <adeuring> good morning
[09:27] <lifeless> wgrant: we don't have capacity to switch masters atm
[09:39] <wgrant> lifeless: That was why I asserted that we couldn't sensibly upgrade until we acquired more CPUs.
[09:40] <wgrant> I guess we need to get used to in-place upgrades if we're going to drop slony at some point.
[10:18] <wallyworld> rick_h: you thre yet?
[11:23] <rick_h> wallyworld: what's up?
[11:23] <wallyworld> rick_h: THE branch is almost through buildbot :-D
[11:23] <rick_h> yay
[11:24] <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:25] <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:26] <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:27] <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] <rick_h> yea, will be nice
[11:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <cjwatson> It doesn't, but in any case it would have to skip rather a lot ...
[11:53] <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:55] <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.
[12:02] <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:04] <wallyworld> yes
[12:05] <wgrant> gmb: See #-ops
[12:26] <StevenK> rick_h: https://code.launchpad.net/~stevenk/launchpad/combo-url/+merge/90093
[12:30] <rick_h> wallyworld: awesome
[12:31] <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:32] <StevenK> rick_h: It even works, so you can +1 if you wish
[12:33] <rick_h> StevenK: ok, made my comment and marked it as needs review ok?
[12:34] <wallyworld> StevenK: how does it work in dev mode where revno is "unknown"?
[12:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <StevenK> It sounds okay to me
[12:47] <StevenK> rick_h: But we can kick that around when the new convoy turns up
[14:09] <deryck> Morning, all.
[14:53] <deryck> bigjools, ping
[14:57] <bigjools> deryck: o/
[15:05] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <stub> mabac: np. let me know if you need a hand, here or email or whatever.
[15:16] <mabac> stub, I'll certainly let you know
[15:16] <mabac> stub, thanks!
[15:23] <mabac> ls
[15:23] <mabac> oops
[16:08] <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:09] <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:10] <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:11] <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:12] <sinzui> fab
[16:13] <mabac_> stub, do you think something like this looks acceptable? http://bazaar.launchpad.net/~mabac/launchpad/workitems-schema-changes/revision/11322
[16:14] <mabac_> salgado, ^^^ I'm not sure what scripts we will have to add, trying to create something to start from
[16:15] <salgado> I think we'll only need the one to maintain specificationworkitemstats, no?
[16:17] <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:20] <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:22] <stub> mabac_: For the appserver, add it to the [launchpad_main] section
[16:22] <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:23] <mabac_> stub, yes, this is nothing special in that respect.
[20:41] <lifeless> .
[22:18] <lifeless> james_w: are you using the django ORM ?
[22:21] <james_w> lifeless, yes
[22:26] <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:28] <lifeless> what will you be using for persistence?
[22:28] <james_w> nothing
[22:29] <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:30] <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:31] <lifeless> ciao
[22:31] <lifeless> ping me whenever, or drop me a mail
[22:31] <james_w> ok
[23:23] <wallyworld__> sinzui: was that a typo in the team lead notes?
[23:24] <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:25] <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:33]  * 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:34] <wallyworld__> wgrant: neither are you :-)
[23:35] <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:36] <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:37] <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:38] <wallyworld__> let me check something
[23:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:49] <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:50] <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:51] <wgrant> Everything seems simple from the outside :)
[23:52] <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:55] <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:56] <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:57] <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:58] <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:59] <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.


[01:20] <pygi> hey folks
[01:20] <pygi> any of you coming to akademy?
[01:44] <nixternal> I wish I was going to akademy
[01:45] <pygi> ah, hi nixternal !
[01:45] <pygi> why not? :)
[01:53] <pygi> Nightrose, wake up :)
[02:28] <nosrednaekim> uhhh are there python-bindings packes yet? (sorry, I was away for two days)
[02:58] <ScottK> nixternal: I have a spec for you (just read your blog).
[02:58]  * nixternal shivers in fear
[02:58] <ScottK> nixternal: https://wiki.ubuntu.com/ServerFlavorSpec might be useful to you if we can pull it off.
[02:59] <nixternal> I will take a gander at it
[02:59]  * ScottK can just hear nixternal saying, "Gee boss, if you'd let me put a little work time in on helping with this spec, it'd save us a ton of time and money on deployments."
[03:00] <ScottK> That and then we can conspire to make sure the tools are available for qt4, but not gtk2.
[03:47] <vorian> nixternal: blog typo!!!!!!
[03:47] <vorian> oh noes!!!!!!
[03:49] <nixternal> what was the typo?
[03:49] <vorian> first bold heading
[03:49] <vorian> Big Ban
[03:50]  * vorian thought this was pm
[03:50] <vorian> sorry about that ;?
[03:50] <vorian> pfft
[03:50] <vorian> can't type
[03:51] <nixternal> thanks, fixed it
[03:51]  * ScottK just figured he was in trouble at work already.
[03:51] <vorian> look what I've been cleaning up all day
[03:51] <vorian> http://vorian.org/?p=228
[03:52] <vorian> damn powerline came down
[03:52] <vorian> the power company let the mother live for 5 hours!
[03:53] <ScottK> Kewl.
[03:54] <vorian> yeah!
[03:54] <ScottK> How's the insurance policy looking?
[03:54] <vorian> good, they'll cover everything
[04:48] <DaSkreech> I forget
[04:48] <DaSkreech> was a kubuntu release done for the last Koffice Alpha?
[05:18] <stdin> DaSkreech: I think it keeps failing to build
[05:18] <DaSkreech> ok
[05:18] <stdin> latest in the repos is still <IP_ADDRESS> (ie: old)
[05:21]  * DaSkreech chuckles at FOSS
[06:44] <Nightrose> morning :)
[06:45] <Nightrose> pygi: I am awake now :P
[06:45] <Nightrose> what did you want?
[06:48] <DaSkreech> An autograph
[06:48]  * DaSkreech presents Mike to be signed
[06:50] <Nightrose> :P
[07:29] <\sh> bah...pykde4 you<EMAIL_ADDRESS>[07:53] <\sh> Sime: pykde4 trunk: cmake error in SIPmacros.cmake,   string sub-command REPLACE requires four arguments. (it's cmake 2.6foo version from kdesupport)
[08:03] <\sh> hmm..it works somehow when cmake started from kdebindings root dir ;)
[08:15] <Arby> morning all
[09:31] <pygi> NickNak, nothing much, just trying to organize in group, so though there'll be kubuntu group
[09:32] <pygi> ergh
[09:32] <pygi> Nightrose*
[09:33] <Nightrose> pygi: ah ;-)
[09:33] <Nightrose> i am already in the girls group
[09:34] <Nightrose> and was in the amarok group before
[09:34] <pygi> amarok group is big xD
[09:34] <Nightrose> hehe yea
[09:34] <pygi> 14 people
[09:34] <Nightrose> and probably a few who didn't join the group
[09:34] <pygi> yup
[09:34] <pygi> I should probably just register without a group
[09:35] <Nightrose> hmmm /me will have to poke some people so they register
[09:35] <Nightrose> pygi: yea probably best
[09:36] <pygi> Nightrose, are you at Z or R hostel?
[09:36] <Nightrose> Roosendael
[09:37] <pygi> ah, so you registered early :p
[09:37] <Nightrose> jea like 4 hours after registration was open ;-)
[09:37] <pygi> ha!
[09:37] <pygi> theres one bed missing on Tuesday, otherwise I could register there as well :-/
[09:37] <pygi> ups
[09:37] <pygi> on Saturday
[09:38] <Nightrose> had a free minute while working at the booth at linuxtag
[09:38] <Nightrose> so i did it
[09:38] <Nightrose> you can get a bed somewhere else for that day
[09:39] <pygi> bleh, that means moving somewhere instead of talking about good things =)
[09:39] <Nightrose> ;-) true
[09:39] <pygi> I'm getting a bed somewhere else for the last two days anyway :p
[09:45] <pygi> why this payment page couldnt be in english xD
[09:46] <Riddell> pygi: it is if you change your country
[09:46] <pygi> ah, true!
[09:47] <pygi> Riddell, you're coming I guess, and still no kubuntu group? :)
[09:47] <Riddell> I am
[09:48] <pygi> Riddell, how come there's no kubuntu group? :)
[09:48] <Riddell> for sleeping?  I like to sleep with random people, spread the love
[09:49]  * pygi knows very little KDE people actually
[09:49] <pygi> few*
[09:55] <\sh> pygi: all dancers and singers (well at least one of them ;))
[10:03] <pygi> \sh, heh :p
[10:57] <etretyak> hi everyone
[11:00] <Riddell> morning etretyak
[11:02] <\sh> bah
[11:02] <\sh> I don't get pykde4 build ... neither our version, nor the svn version...
[11:14]  * Serega waves
[11:15] <\sh> oh another try
[11:15] <\sh> there's hope
[11:16] <\sh> Riddell: btw..how do you deal with quilt and "new files"? e.g you need to add a new file, via diff,...
[11:17] <\sh> quilt add newfile -> add some things to newfile, quilt refresh doesn't help for me
[11:19] <Riddell> diff -u old new
[11:19] <Riddell> diff -u old new > foo
[11:20] <Riddell> echo foo > debian/patches/series
[11:20] <\sh> ok...so the dirty method ;)
[11:20] <\sh> I thought there is a sane way to tell quilt to behave :)
[11:25] <\sh> whooosaaaa...pykde4 builds
[11:27] <Riddell> yay
[11:27] <\sh> never ask me questions about how I did that now...
[11:28]  * \sh has to check .bash_history ;)
[11:28] <\sh> something between praying and moving files from pykde4/sip/*  svn trunk to our packages and adding some magic fixes found on the pykde4 ml
[11:31] <\sh> oh damn...too early to be happy:
[11:31] <\sh> sipkhtmlpart10.cpp: In function 'PyObject* meth_DOM_DOMString_characters(PyObject*, PyObject*)':
[11:31] <\sh> sipkhtmlpart10.cpp:689: error: 'class DOM::DOMString' has no member named 'characters'
[11:35] <\sh> getting rid of it...and go back to start and don't catch 4k €
[12:18] <\sh> woohoo...pykde4 python2.5 build finished...now for python2.4...after that testing and uploading to ppa
[12:49] <\sh> hmmm...are our kde4.1beta packages rpathed?
[12:49] <\sh> dpkg-shlibdeps: failure: couldn't find library libkdeui.so.5 needed by debian/python-kde4/usr/lib/python2.5/site-packages/PyKDE4/kdeui.so (its RPATH is '').
[12:51] <Riddell> in hardy should be yes
[12:52] <\sh> why doesn't it work then...
[12:53] <\sh> trying now with dh_shlibdeps -l<path to kde4 libdir>
[12:53] <\sh> it's the last bug...:(
[12:54] <emonkey> gogogo *cheers*
[12:55] <\sh> emonkey: /me needs to "redo" everything he did to get that package working..because right now, it's more a mess then a debian package
[12:55] <emonkey> sounds awful
[13:05] <smarter> \sh: you can see the RPATH with chrpath
[13:13] <\sh> smarter: it doesn't help when dpkg-shlibdeps is failing ;)
[13:29] <\sh> press thumbs..that it works now
[13:35] <\sh> sudo dpkg -i python-kde4_4.0.3-0ubuntu1.3~hardy1~ppa1_amd64.deb python-kde4-dev_4.0.3-0ubuntu1.3~hardy1~ppa1_all.deb python-kde4-doc_4.0.3-0ubuntu1.3~hardy1~ppa1_all.deb
[13:36] <\sh> installation: works
[13:39] <\sh> KDE Launchpad Bugs
[13:39] <\sh> Version 0.1
[13:39] <\sh> Using KDE 4.00.80 (KDE 4.0.80 >= (KDE 4.1 Beta1)
[13:39] <\sh> STRIKE!
[13:42] <\sh> now I'm uploading the crap to kubuntu-members-kde4 ppa and then I will try to find out why no menu text is set...
[13:42] <\sh> and fixing the package later to be sane again
[13:43] <\sh> there it goes
[13:45] <\sh> [PPA kubuntu-members-kde4] Accepted: python-kde4 4:4.0.3-0ubuntu1.3~hardy1~ppa1 (source) phew
[13:47] <Riddell> the no menu text is a known bug with older versions of pykde
[13:49] <\sh> Riddell: hmm..how do we overcome that?
[13:50] <Riddell> update to a newer version
[13:50] <\sh> ah
[13:50] <\sh> oxygene
[13:50] <\sh> oxygen bug
[13:51] <raphink> hi \sh & Riddell
[13:51] <Hobbsee> Nightrose: nice kitten pic you managed to find there.
[13:51] <raphink> & hi Hobbsee
[13:51] <Nightrose> Hobbsee: ;-)
[13:51] <\sh> moins raphink :)
[13:51] <\sh> Riddell: the only new version i can find is that what's in the svn trunk of kde
[13:52] <Nightrose> Hobbsee: i have a whole folder with pics like that one :P
[13:52] <Hobbsee> raphink!
[13:52] <Hobbsee> Nightrose: heh
[13:52] <\sh> Riddell: and it's not compiling cleanly...via kdebindings...(i just used some of the new stuff sime commited to it to make it actually build for kde4.1)
[13:52] <Riddell> \sh: that and kdebindings releases
[13:52] <Riddell> hi raphink
[13:53] <\sh> I wonder where Jim has it's own repository of it
[13:53] <jjesse> morning
[13:53] <Riddell> on his hard disk
[13:57] <apachelogger> Riddell: please sponsor http://pastebin.kubuntu-de.org/235 and remove the source package of kopete-plugin-otr-kde4
[13:58] <apachelogger> Riddell: oh, and if you have time, please backport quassel to hardy
[13:58] <apachelogger> build log: http://launchpadlibrarian.net/15196506/buildlog_ubuntu-hardy-i386.quassel_0.2.0%7Ebeta1-0ubuntu2%7Ehardy1%7Eppa1_FULLYBUILT.txt.gz
[13:59] <ScottK> apachelogger: It'd be much preferred if you filed that backports bug rather than randomly poke Riddell on IRC for backports.
[14:00] <apachelogger> jussi01: go file a backports bug :P
[14:00] <jussi01> apachelogger: ok then!
[14:00] <Riddell> apachelogger: ok
[14:00] <\sh> ScottK: bug #234574 ;)
[14:00] <apachelogger> ScottK: considering I am in the -backports team, would I still have to file a bug?
[14:02] <jpds> apachelogger: yes.
[14:02] <apachelogger> omg
[14:02] <jussi01> jpds: shhh... its quassel ;)
[14:02] <jpds> But you can just +1 it in the bug report
[14:02]  * apachelogger appoints jussi01 to his personal backport bug reporter
[14:02] <ScottK> apachelogger: Yes.  Please.  I do it too.
[14:03] <ScottK> apachelogger: I've been stuck more than once trying to figure out WTF on some backports issue where having even a minimal paper trial in LP would have been very nice.
[14:05] <jussi01> what package does it need to be reported against? quassel?
[14:05] <\sh> hardy backports + quassel imho
[14:06] <ScottK> jussi01: Just hardy-backports
[14:08] <jussi01> ScottK: ummm.. "hardy-backports" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[14:08] <Riddell> bugs.launchpad.net/hardy-backports
[14:09] <jussi01> hrm...
[14:11] <ScottK> Ubuntu Backports initially was on Sourceforge and only later came to Launchpad.  It's a separate project from a LP perspective.
[14:11] <ScottK> You can still find the old project on Sourceforge if you want to delve into ancient history.
[14:12] <jussi01> ok, so simply, what do I put int the feild: In what package did you find this bug?
[14:12] <jussi01> it does not accept hardy-backports
[14:12] <ScottK> jussi01: Go to hardy-backports project and file the bug there.
[14:12] <jussi01> kk
[14:13] <jussi01> bug 239165
[14:14]  * ScottK looks
[14:14] <jussi01> apachelogger: ^
[14:14] <ScottK> To get it approved, someone needs to say it builds, installs, and runs.  Presumablye apachelogger can do that and approve it.
[14:14] <ScottK> Just imagine I spelled presumably correctly there.
[14:15]  * \sh just locks up his brain now
[14:15] <\sh> and waits for pykde4 to finish building ..... dumdumdumdedummkubuntudumdedum
[14:15] <jussi01> ScottK: Ill presume you spelled it correctly
[14:16]  * jussi01 gets coat
[14:17] <jussi01> apachelogger: is the packaging the same as mine still?
[14:18] <jussi01> or have you made changes to it?
[14:18] <\sh> well, for quassel...you have to change packaging in the future...no more qmake juice, but cmake love
[14:19] <apachelogger> ScottK: done
[14:19] <jussi01> brb
[14:19] <nosrednaekim> hey
[14:19] <apachelogger> jussi01: I don't know your packaging
[14:20] <apachelogger> \sh: yeah, that is one line in rules and adapting the .install files ;-)
[14:20] <\sh> apachelogger: bah...cdbs is *censored*
[14:21] <apachelogger> :P
[14:21] <nosrednaekim> hey guys,,, i've been away for a couple days... has anyone packaged the python plasma bindings?
[14:21] <apachelogger> the what?
[14:22] <\sh> http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu/pool/main/p/python-kde4/ <---- YEEHA
[14:22] <apachelogger> how is python-kde4 related to plasma?
[14:23] <ScottK> It's not.  He's been working on it.
[14:23] <apachelogger> well
[14:23] <apachelogger> I am confused
[14:23]  * apachelogger hides
[14:24] <Riddell> nosrednaekim: where are the python plasma bindings?
[14:24] <nosrednaekim> Riddell:within python-bindings I think
[14:24] <nosrednaekim> *kdebindings
[14:25] <\sh> nosrednaekim: in kdebindings/python/ there is only pykde4 and krosspython
[14:25] <nosrednaekim> I think krosspython does it
[14:26] <\sh> na
[14:26] <\sh> it's something for interpretating python in c++ as sime yesterday told us
[14:28] <apachelogger> I really think this is exactly what is necessary
[14:28] <apachelogger> IIRC the javascript stuff for plasma also uses kross
[14:28] <apachelogger> though, that would lead to the question where krosspython is
[14:28] <apachelogger> as I packaged it just a few weeks before hardy :P
[14:29] <\sh> lol
[14:30] <nosrednaekim> well, I need it for 4.1
[14:30] <apachelogger> ah
[14:31] <apachelogger> Riddell: is kdebindings 4.0.80 not merged yet?
[14:34] <\sh> crap...
[14:34] <\sh> eric4 is now b0rked
[14:35] <\sh> because of qscintilla...*grmpf*
[14:35] <Riddell> apachelogger: waiting on qscintilla MIR
[14:36] <Riddell> apachelogger: it's kde4bindings
[14:36] <nosrednaekim> apachelogger: oh BTW... i'm on hardy, not intrepid, so i'm using the PPA
[14:36] <apachelogger> Riddell: ok, thanks
[14:37]  * \sh goes now for qscintilla for ppa
[14:37] <\sh> Riddell: how much quota do we have for the -kde4 ppa?
[14:38] <Riddell> \sh: lots
[14:39] <apachelogger> nosrednaekim: maybe kdebindings didn't get backported
[14:39] <\sh> apachelogger: eventually it will fail...check kdesvn for kdebindings when sime commited the changes for 4.1 (pykde4)
[14:40] <nosrednaekim> apachelogger: nixternal did say he was having problems with it.
[14:40] <apachelogger> no krosspython for nosrednaekim then
[14:41] <nosrednaekim> which means no tutorial session :(
[14:41] <Riddell> nosrednaekim: is there an example I can test?
[14:45] <nosrednaekim> yeah.. I keep forgetting where it is in websvn though
[14:46] <jjesse> does strigi work in kde 4.1 beta?
[14:48] <\sh> qscintilla2_2.2-2ubuntu1.1~hardy1~ppa1 uploaded to ppa
[14:52] <nosrednaekim> Riddell: wow... I can't find it... maybe someone removed it (which seems pretty unlikely)
[14:53] <\sh> nosrednaekim: playground/base/plasma/scriptengines/kross/ ?
[14:57] <nixternal> nosrednaekim: check under playground/base/plasma/applets/scripts
[14:57] <flaccid-> nixternal, what can i do about a user in #kubuntu that won't accept the shortcomings of flash?
[14:58] <nixternal> flaccid-: who is it?

[14:58] <flaccid-> i'd like to ignore but its hard..
[14:58] <flaccid-> keeps going on and on
[14:58] <nixternal> k, will keep an eye out when I can...sitting in meetings all morning
[14:59] <flaccid-> np mate
[14:59] <flaccid-> hopefully user will stop :)
[15:00] <flaccid-> hmmm im thinking the /me raises an eyebrow is better strategy than a message
[15:01] <flaccid-> nixternal, you might wanna kick this culprit atm but in the chan <administrator> #Arkor-Easy Boxxx A 4OO
[15:01] <flaccid-> all good now
[15:01] <nosrednaekim> nixternal: nothing there
[15:04]  * flaccid- sighs a relief
[15:04] <\sh> phew...
[15:04] <\sh> eric4 runs again
[15:06] <\sh> now we have a working python environment back again ;)
[15:06] <jpds> flaccid-: feel free to raise operator concerns in #ubuntu-irc
[15:08] <flaccid-> jpds, this is kubuntu
[15:11] <nosrednaekim> flaccid-: yeah... they work with #kubuntu too
[15:11] <flaccid-> i know that but its a matter of response
[15:35] <\sh> Riddell: python-kde4 for intrepid was never recompiled against 4.0.80 packages, right?
[15:35] <\sh> Copied from  ubuntu hardy in Primary Archive for Ubuntu  <- fun
[15:36]  * \sh will redo the work properly for intrepid package tomorrow somehow...
[15:36] <Riddell> \sh: intrepid uses kde4bindings
[15:36] <\sh> Riddell: ah...
[15:39] <sevtoul> I think there's a spelling mistake in the package kdesdk-dbg-kde4, it says that kdebasAe-runtime-dbg is required so the package is broken
[15:41] <sevtoul> of course, I talking about the ppa.launchpad package in hardy with kde4.1
[15:41] <sevtoul> (sorry for my english...)
[15:43] <sevtoul> any idea ?
[15:44] <Riddell> sounds like a bug indeed, probably not one we'll have time to fix
[15:45] <sevtoul> ok nevermind, I just installed all dependencies
[16:26] <Riddell> flaccid-: hmm?
[16:27] <flaccid->  sorry Riddell ?
[16:27] <Riddell> you called ops
[16:27] <yuriy> ugh kde-systemsettings *does* contain kcms?
[16:27] <yuriy> namely, defaultapplication
[18:23] <mendred> hi  i am trying to figure out which package has the debugging symbols for kwin (kde 4.1 beta 1 packages hardy). I have installed kdebase-workspace-dbg and kdebase-dbg..but those dont seem to be the ones.
[18:24] <mendred> the kwin package is kde-window-decorator...can't seem to find a dbg package for that..
[18:24] <mendred> can anyone help?
[18:25] <Riddell> it would be kdebase-workspace-dbg if it works, which it may well not
[18:26] <mendred> Riddell: i don't understamd?
[18:26] <mendred> *understand
[18:27] <mendred> i am trying to generate a backtrace...when i run ardour with around 10 -15 tracks parallely playing, kwin usage with compositing shoots to 80%..
[18:27] <mendred> and the system slows down..
[18:27] <mendred> so i am trying to attach gdb to kwin..and then generate a back trace
[18:28] <mendred> but gdb keeps complaining that there are no debugging symbols
[18:28] <mendred> for kwin
[18:28] <Riddell> kde 4 is installed to a non-standard location, the debug symbols may not work
[18:28] <mendred> what do you suggest that i do?
[18:29] <mendred> ohhhhh
[18:30] <mendred> then there is no way to get a backtrace?
[18:32] <Riddell> I don't know I'm afraid
[18:32] <mendred> ok..
[18:32] <mendred> thanks Riddell
[18:34] <stdin> usually the kde crash handler will give you a backtrace
[18:34] <stdin> at least, it does for me
[18:35] <mendred> stdin: there is no crash :(
[18:35] <mendred> the usage shoots up
[18:35] <stdin> ah, well then
[18:35] <mendred> can i trigger a crash :)
[18:36] <mendred> if that will give me a trace?
[18:36] <mendred> or does kwin have a debug startup mode or something?
[18:38] <stdin> I guess you could kill kwin and run it in gdb with "gdb --args kwin --nograb --sync --nocrashhandler"
[18:38] <stdin> should work probably/maybe
[18:42] <mendred> ok will try that
[18:53] <mendred> thanks stdin..thats working :)
[18:54] <stdin> :)
[19:02] <jjesse> why don't kde 4 windows save my settings?  example i change how the save as screen looks like and every time i open the program i have to re arrange it
[19:02] <jjesse> grrrrrrrr
[23:27] <supert0nes> is there any documentation for python plasmoids?  It would be nice to read up before the tutuorials day


[06:35] <dholbach> good morning
[07:13] <MooDoo> hello all
[08:03] <davidcalle> Morning all o/
[08:38] <czajkowski> aloha
[09:10]  * dholbach relocates to the office, brb
[12:40] <jose> dpm: ping, hangout?
[12:50] <dpm> jose, pong. Sure, I'm free in ~1h, would that still work for you?
[12:51] <jose> dpm: nope, I'll leave for university in like 25 mins :(
[12:52] <jose> just wanted to give you some updates on what was going on
[12:53] <dpm> jose, over e-mail, or later on in the day on hangout?
[12:53] <jose> sure, otherwise I'll check in with Mike :)
[12:54] <jose> I have a meeting with the university-side organizer too!
[12:56] <dpm> ok, cool
[13:20] <jcastro> marcoceppi: 25 in June, 104 all year
[13:58] <marcoceppi> jcastro: dang dude
[13:58] <marcoceppi> jcastro: 16 in june, 101 for the year
[13:58] <marcoceppi> time to turn my AC off
[13:59] <jcastro> marcoceppi: intaking from the basement-only has changed my entire profile
[13:59] <jcastro> and since I work down here, I don't need anything on for most of the day
[14:59] <dholbach> all right... I call it a day a bit earlier today - need to help my sister out by doing some babysitting - have a great weekend everyone! :-)
[19:57] <jose> mhall119: hey, can you do a hangout?
[20:06] <mhall119> jose: sure
[20:06] <mhall119> let me find AC power
[20:06] <jose> cool
[20:09] <mhall119> jose: ready when you are


[19:33] <andygraybeal> vacation at my house this weekend
[19:33] <andygraybeal> i live in the sticks
[19:33] <andygraybeal> you city folk would like it
[19:34] <Unit193> andygraybeal: Shootin'?
[19:35] <andygraybeal> it's dove hunting
[19:35] <andygraybeal> i can't afford any shot.. but you can bring your own
[19:35] <andygraybeal> i'm very poor right now
[19:35] <Unit193> Oh.
[19:35] <andygraybeal> i live in the outskirts of  coolville ohio
[19:35] <andygraybeal> i might have some shot
[19:36] <Unit193> I'm in a city, but at least it's a smaller city.
[19:36] <andygraybeal> but i'm going to be mowing this weekend
[19:36] <Unit193> Nice being not too far from the store and stuff, but I'm not fond of people.
[19:36] <andygraybeal> i got to mow my place before it gets all fallen over.
[19:36] <Unit193> Yeeah, I need to get at least another one in. >_<
[19:36] <andygraybeal> yea, come down and shoot.. you hva my permission, to shoot at doves
[19:37] <Unit193> Normally do targets, but yeah I don't like birds, could do that. :P
[19:38] <andygraybeal> yea you have to collect them though.. if you don't like'em eating.. i'll dress'em and eat'em
[19:49] <Unit193> I'd give 'em a try.


[13:04] <mup> Bug #1521618 opened: wrong subnet in DHCP answer when multiple networks are present <MAAS:New> <https://launchpad.net/bugs/1521618>
[13:10] <mup> Bug #1521618 changed: wrong subnet in DHCP answer when multiple networks are present <MAAS:New> <https://launchpad.net/bugs/1521618>
[13:13] <mup> Bug #1521618 opened: wrong subnet in DHCP answer when multiple networks are present <MAAS:New> <https://launchpad.net/bugs/1521618>
[22:43] <blahdeblah> Hi all.  I'm running into https://bugs.launchpad.net/juju-core/+bug/1412621 in different circmstances than when I originally reported it, and the consensus in that bug seems to be that it's a MAAS DNS resolution issue.  So my question is: when should I expect to be able to resolve DNS names via my MAAS server?
[22:43] <blahdeblah> This is a home lab setup with a fresh install of MAAS in a VM, and I can commission & deploy nodes with MAAS just fine.
[22:44] <blahdeblah> maas-dns is installed, and bind is running, but it doesn't respond for the name of my single MAAS physical node.