[00:26] cody-somerville: Are you able to QA r14876, which is on qas now? [00:38] wgrant: The notfound template already says: "This page does not exist, or you may not have permission to see it." [00:38] StevenK: IN about 10 tonnes of other text. [00:39] It's the first text after the heading [00:51] StevenK, How do I QA it? [00:52] cody-somerville: You added an attribute to the webservice. Can you get it and set it in the way you expect? [00:53] StevenK, Cool. Okay. I can do that. Do I tag the bug or something if successful? [00:54] cody-somerville: Yes. There is currently a 'qa-needstesting' tag on the bug. If it works fine, remove that tag and add 'qa-ok' [01:15] * StevenK smacks wallyworld [01:15] ? [01:15] wallyworld: 116+from lp.app.interfaces.services import IService right at the top of lib/lp/registry/browser/tests/test_product.py ? [01:16] auto import fail [01:16] will fix in current branch [01:17] wallyworld: I spent hours fixing imports yesterday and the next feature branch gets it wrong. :-( [01:17] it's only one of many i added, easily fixed :-) [01:28] wgrant: Tempted to do distribution via SQL. There are less than 50. [01:30] StevenK: Possibly. [01:30] lifeless: staging should have my first patch in about 30 minutes. [01:30] http://people.canonical.com/~wgrant/launchpad/flatbugtask.sql is the second one which I described yesterday. [01:31] It's missing triggers on the access policy bits, and there's no handling of toggling of Product.active, but it should otherwise be reasonably consistent. [01:32] wgrant: drop that in a file on devpad [01:33] lifeless: carob:~wgrant/flatbugtask.sql [01:35] is it dependent on the first patch ? [01:35] It'll apply and partly work without it, but none of the access stuff will be there. [01:37] Once the first patch is applied we need to build its data (SELECT bug_mirror_legacy_access(id) FROM bug), then build the second lot of data (SELECT bugtask_flatten(id) FROM bugtask). [01:38] ok, ping me [01:38] Yup, just prewarning you. [01:41] lifeless: I also need a way to do mass async updates when Product.active changes. Jobrunner job? Dirty flag with garbo job? The latter is a bit evil but somewhat lighter than the current jobrunner situation. [01:42] jobrunner [01:42] :(] [01:42] should be light enough [01:42] 2KLOC later... [01:42] I'm sure you'll make it lighter as you go [01:42] Heh [01:47] I guess we need a pattern for this sort of thing anyway. [01:52] StevenK: Bah, I said I had created a card already :) [01:52] 2012-02-29 01:42:39 INFO 2209-11-3 applied just now in 0.4 seconds [01:54] lifeless: https://pastebin.canonical.com/61200/ are the incantations. [02:18] wgrant: do you want them run now ? [02:18] lifeless: Please. \timing would be handy too. [02:19] lifeless: Will be interested to see how long the two mass function calls take in a single batch. [02:20] one transaction? [02:20] Might as well run it in three, just in case one fails. [02:21] heh, started it a begin [02:21] will do over if it fails [02:21] lifeless: You applied flatbugtask.sql, right? :) [02:21] It defines the last function. [02:21] no, not yet [02:27] wgrant: [02:27] INSERT INTO accesspolicy (product, type) SELECT id, 3 FROM product; [02:27] INSERT 0 34729 [02:27] Time: 3833.312 ms [02:27] INSERT INTO accesspolicy (product, type) SELECT id, 4 FROM product; [02:27] INSERT 0 34729 [02:27] Time: 4182.285 ms [02:27] INSERT INTO accesspolicy (distribution, type) SELECT id, 3 FROM distribution; [02:28] INSERT 0 36 [02:28] Time: 9.049 ms [02:28] INSERT INTO accesspolicy (distribution, type) SELECT id, 4 FROM distribution; [02:28] INSERT 0 36 [02:28] Time: 9.061 ms [02:31] lifeless: Looks reasonable. [02:32] SELECT bug_mirror_legacy_access(id) FROM bug; [02:32] Time: 228686.012 ms [02:33] SELECT bugtask_flatten(id) FROM bugtask; [02:33] Not too bad, considering a lot of it was probably cold. [02:49] (1097473 rows) [02:49] Time: 994126.901 ms [02:49] bugtask_flatten(id) returns a pile of null :P [02:52] Hmmm, slower than it should have been. [02:52] But thanks. [02:52] So. [02:52] You should now have a marvellous bugtaskflat with 20 or so indices [02:54] select count(*) from bugtaskflat; [02:54] count [02:54] --------- [02:54] 1097473 [02:54] Excellent. [02:55] Try https://pastebin.canonical.com/61202/ [02:57] 102984, 1238ms [02:57] :( [02:58] explain analyze 625ms [02:58] So 500ms planning? [02:58] Or 1238 cold? [02:58] 9ms [02:58] coldish, that is [02:58] 1238 coldish [02:58] Ah [02:58] So it's now 600ms? [02:58] ish? [02:58] 420, 500, etc [02:59] That's more like it. [02:59] Care to throw in a bit of FTI? [02:59] Like BugTaskFlat.fti @@ ftq('kernel hang') or so? [03:02] (yes, the privacy constraint is hideously structured, but it works it out -- I need to rework the Python to spell it better) [03:03] The SQL I provided uses gist for fti, but it might be interesting to compare it to gin on sourcherry. [03:03] pastebin what you want :) [03:09] lifeless: https://pastebin.canonical.com/61204/ [03:10] Aggregate (cost=82175.45..82175.46 rows=1 width=0) (actual time=637.165..637.166 rows=1 loops=1) [03:10] Well that sucks. [03:11] Can I have the whole thing? [03:11] Limit (cost=82182.00..82182.19 rows=75 width=8) (actual time=527.338..527.366 rows=75 loops=1) [03:12] https://pastebin.canonical.com/61205/ [03:12] Thanks. [03:13] A [03:13] Ah [03:13] * wgrant blames gist. [03:13] A bit of planner stupidity too, but mostly gist. [03:15] lifeless: DROP INDEX bugtaskflat__fti__idx; CREATE INDEX bugtaskflat__fti__idx ON bugtaskflat USING gin (fti); and retry? [03:15] Will probably take a while [03:15] GIN generation is slooooow. [04:13] wgrant, lifeless: O hai, can we have a mumble about ArchiveAudit? [04:14] sure [04:14] skype? [04:14] or fanout ? [04:14] You can't do mumble? [04:14] it hates me [04:15] Hangouts still don't work for me, and are even less tasteful than Skype. [04:15] it needs http://www.rowetel.com/blog/?page_id=454 [04:15] It worked last time :-P [04:15] So I suggest we Skype :) [04:15] StevenK: it was traumatic [04:15] StevenK: and I've got Cynthia beside me at this time of day [04:15] I can make it more trauatic and turn on the webcam [04:16] *traumatic [04:16] I know what you look like already [04:18] I can hear you [04:19] lies [04:19] precise [04:19] diaf [04:19] sound panel sees my input [04:20] what command ? [04:20] pavucontrol [04:23] lifeless: https://code.launchpad.net/~stevenk/launchpad/db-add-archiveaudit/+merge/94726 is the WIP MP [05:15] lifeless: Any chance you could recreate the FTI index as GIN as I described above? [05:18] * StevenK peers at his garbo test [05:20] CREATE INDEX [05:20] Time: 159917.895 ms [05:21] Limit (cost=82270.96..82271.14 rows=75 width=8) (actual time=1031.584..1031.633 rows=75 loops=1) [05:21] Limit (cost=82270.96..82271.14 rows=75 width=8) (actual time=183.615..183.666 rows=75 loops=1) [05:21] lifeless: blink [05:21] So it's 3x faster? [05:21] looks like it [05:22] Might try with GIN straight away, then [05:22] what about table scans [05:22] Given that we're going to be restrictedly testing this for a while anyway. [05:22] ok [05:22] They're unlikely to happen given the other indices. [05:22] But yes, it is a concern. [05:23] We can drop in GIN already if we don't care about occasional searches breaking, but in the past we have :-) [05:24] stub: The new table has strategic indices. [05:24] Haha [05:24] Rather than random ones that are mostly useless, like bug and bugtask. [05:25] The 'all stopwords' query is the usual one that breaks things. [05:40] we could take a calculated risk [05:41] easy enough to change index style [05:41] and hell, 1 second is still >> 8 seconds [05:44] StevenK: I had a quick look for a audit service, couldn't see one [05:44] wgrant: let webops know if/when you want that stuff dropped from staging [05:45] lifeless: Easy enough to change index style, and easy enough to turn the feature flag off :) === almaisan-away is now known as al-maisan [06:24] lifeless, wgrant: If we are rebuilding the search, I think we should a) use GIN indexes wherever possible and b) catch the exception we see when it attempts a full scan and return a 'too many results' type page. [06:24] wfm [06:25] Probably, yeah. [06:25] Might as well stick a LIMIT in the query too, generating the 'too many results' thing even if the index hit did work. Nobody wants page 1 of 600. [06:26] Well [06:26] Hopefully we'll be using StormRangeFactory soon [06:26] Which will remove the COUNT(*) entirely. [07:28] bug_fti is off the 'most bloating indexes' list, yay! [07:50] stub: yup :) === al-maisan is now known as almaisan-away [08:44] buildbot failure is mine, I'm on it. [08:52] good morning [09:05] aloha [09:39] <[reed]> wgrant: throw in IE's X-XSS-Protection as well [09:39] <[reed]> Chrome supports it, too [09:40] <[reed]> wgrant: depending on how that gets presented, you may wish to add "; includeSubDomains" to the HSTS header, too [09:41] [reed]: Can't use includeSubDomains, due to some questionable historical decisions. [09:41] Will look into X-XSS-Protection, though -- didn't realise Chrome did it too. Thanks. [09:43] oh wow. totally did not expect [reed] in here ;) [09:43] <[reed]> I'm everywhere. [09:44] Yes, TIL. [09:44] <[reed]> also, I've been complaining about some of these things for a while, at least in LDS [09:44] Wait, you come to UDSes and LDSes? [09:44] <[reed]> LDS == Landscape Dedicated Server [09:44] Ahhhhhh. [09:44] <[reed]> I have come to two UDSes, though [09:45] X-XSS-Protection looks like a bit of a misfeature. [09:45] <[reed]> I'll probably stop by the Oakland one [09:45] Potential for security issues, even. [09:45] <[reed]> wgrant: I think most of those issues have been worked out... it's been around for a while now [09:46] <[reed]> "Registration for the next UDS opens on 24th February 2012." [09:46] <[reed]> it's a bit past that [09:46] <[reed]> lol [09:55] <[reed]> wgrant: if you want to be super-awesome, send an appropriate CSP header ;) [09:58] [reed]: Isn't that thoroughly unstandard and still in flux? [09:58] Ahhh [09:59] I see X-XSS-Protection has evolved a bit since I dismissed it as completely insane a couple of years ago [09:59] Notably with the addition of mode=block [10:00] <[reed]> indeed [10:00] Anyway, yeah, was looking at doing CSP, but it's going to be a bit less trivial to ensure everything still works, and it seems like there's work on making it more sensible and standard. [10:00] <[reed]> sure [10:00] But since you're suggesting it, I might have to look again :) [10:00] <[reed]> hah [10:01] <[reed]> I know a bunch of Mozilla sites implement it [10:01] Because you added it? :) [10:01] <[reed]> but I also know it took them quite a while to do the right thing [10:01] haha [10:01] <[reed]> hah, not for CSP, but I did add other headers ;) [10:01] Heh [10:01] <[reed]> pretty much every security "feature" Bugzilla has gained in the past several years was because I wrote a patch for it :p [10:02] I've wanted to do this to LP for 18 months, but there were various bits of stupidity that needed to be fixed first. [10:02] Like certain URLs which were forced to HTTP for no good reason. [10:02] <[reed]> wanna fix Landscape as well? :P [10:02] And crufty bits of Zope that needed upgrading. [10:02] sigh [10:02] Heh [10:02] <[reed]> don't get me started on how terrible Landscape is from a security perspective ;) [10:06] Yeeeeeah [10:07] It's the one major Canonical webapp that I haven't tried to poke holes in. [10:07] I'm not entirely sure I want to try :) [10:08] <[reed]> I'd appreciate it if you would! ;) [10:08] <[reed]> I've poked a bunch of holes in it already [10:08] <[reed]> but I know there are plenty more [10:08] <[reed]> it's never had a formal security review, as far as I can tell [10:09] juju is the next target of my wrath. [10:49] wgrant: you still up ? [10:50] czajkowski: Vaguely. [10:50] can you help me in launchpad with a question:/ re merge proposals [10:50] please [10:55] czajkowski: mgz is one of us :) [10:55] Well, bzr. [10:55] But close enough. [10:58] wgrant: aye thats what I thought too === stub1 is now known as stub [11:57] morning [11:58] rick_h_: morning === stub1 is now known as stub [12:18] rick_h_, good morning. :) since there's no ocr can I pester you with another review? or perhaps could you point me to someone I could bug? ;) https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-widget/+merge/94790 [12:57] mabac: sure thing, will peek at it [13:02] rick_h_, cool, thank you very much! === lcanas_ is now known as lcanas [13:29] File "/home/salgado/launchpad/lp-branches/workitems-migration-script/lib/lp/services/database/bulk.py", line 244, in create [13:29] IStore(cls).execute(Insert(db_cols, expr=db_values)) [13:29] TypeError: __init__() got an unexpected keyword argument 'expr' [13:30] has anybody seen this before? [13:33] hmm, looks like I'm using an old version of storm (storm-0.19.0.99_lpwithnodatetime_r404-py2.6-linux-i686.egg) [13:33] that's the version I should be using, in fact, but my branch is using storm-0.19.0.99_lpwithnodatetime_r402-py2.6-linux-i686.egg [13:35] I thought rocketfuel-get would update the generated scripts (bin/test, etc) to use the latest source but I guess that wouldn't make sense -- I should probably do that manually when I merge devel [13:35] is make clean; make the correct way to deal with that? [13:37] salgado: yea, think you'd need rocketfuel get, but then to merge with devel to lget the latest versions.cfg or what not. Not sure if storm is a packaged thing or a source dep [13:39] rick_h_, yeah it's in lp-sourcedeps, not deb-packaged. I guess there's nothing faster than to "make clean" and rebuild from scratch? [13:40] salgado: might get away with a bin/buildout [13:40] but not tried it so not sure [13:40] oh, right, I'll try that next time [13:41] reading and working on makefiles a lot lately, but still some voodoo on what fits where to me :) [14:12] mabac: ok, notes posted, I ping'd jcsackett for a follow up [14:14] rick_h_, great thanks! will have a look asap! [14:16] mabac: most of my feedback just surrounds how I like to test things that parse like this: https://pastebin.canonical.com/61235/ [14:16] mabac: so that as bugs/issues are found it's very trivial to add a new test case and see at once what works/doesn't kind of thing [14:16] if that makes sense [14:16] but it's a preference thing on my end [14:17] rick_h_, thanks. I don't have access to the canonical pastebin though [14:17] ah, sorry sec [14:17] http://paste.mitechie.com/show/552/ mabac [14:18] but anyway, for that to work our parsing/raising exceptions need to be a bit split/etc [14:19] I didn't really know if I should always raise LaunchpadValidationErrors or perhaps let parse errors pass through as well [14:19] yea, not sure on the standard since I've not done much with it [14:23] I'll see if I can use a regexp for the assignee as well. and move the work items header re to a module level constant [14:25] mabac: awesome [14:29] rvba: ping, just wanted to toss out a heads up that on the js builder stuff. Not sure if you guys can use that over in maas land. [14:29] rick_h_: pong [14:29] rvba: I've got to update the wiki with some notes, but give it a shot with what you guys are doing and let me nkow how I can make it more 'general' for other projecs [14:30] I want to find out what's too LP specific so I can hit up the other JS people out there and figure I can bug your team first :) === olli_ is now known as olli [14:33] adeuring, https://plus.google.com/hangouts/extras/talk.google.com/orange-standup [14:36] how do I tell the test runner to drop into pdb on the first failure? [14:37] salgado: -D [14:37] rick_h_: I'm in the middle of something right now, can you please paste the link to the page you want me to have a look at and I'll get back to you shortly. [14:38] benji, and that's an argument to bin/test I guess? [14:38] salgado: yep [14:38] rvba: https://lists.launchpad.net/launchpad-dev/msg09077.html no hurry, just more fyi [14:38] benji, great, thanks! [14:39] benji, it doesn't seem to work if I use it with testr (raises BdbQuit immediately), but I guess that's known/expected? [14:40] deryck, abentley, rick_h_sorry, again a crash... [14:40] adeuring, np, we'll wait on you. [14:40] rick_h_: I see. The problem with maas is that it's a distributed package. To add a dependency: either it's packaged in precise or we have to include the source code in our tree. [14:40] rvba: ok, gotcha [14:41] salgado: it's not known by me, and expectations lie at the root of suffering. [14:41] rick_h_: But I keep track on what you guys do on lp :). [14:41] rick_h_: We have the same dilemma about using/not using convoy. [14:42] deryck: can you send me the link to the hangout again? [14:42] adeuring: https://plus.google.com/hangouts/extras/talk.google.com/orange-standup [14:45] deryck abentley rick_h_ seems that i should this machine for the hangout; haven't installed the plugin yet... [14:47] rvba: sorry, standup. Ok cool, I wasn't sure how you guys were doing the JS stuff but know you asked about the combo loader bits at the epic [14:48] rvba: so yea, the convoy stuff in the jsautobuild probably doesn't help you guys at all then if you're not going combo loader/convoy [14:49] rick_h_: I really would like to use the combo loader/convoy but I'm not sure it's going to happen for 12.04 for the reasons mentioned above. [14:49] rvba: right [14:50] abentley: let's use mumble... [14:50] adeuring1: sure [14:50] rick_h_: I'll benchmark what it costs us (in terms of page load time) to not use it. [14:51] rick_h_: if this is really significant, I'll try to get someone to package it or we will include the code in our tree. [14:51] yea, you guys are on disk/local right so I doubt it's horrible. [14:51] We will see. [14:51] but the pyinotify stuff is cool if you guys do hav a make jsbuild type step that you don't want to have to run on ever save [14:52] but ok cool. thanks for thinking/taking a peek if it fits into your stuff at all. [14:52] Looks very useful indeed. [14:52] Hi, I'd like to test a bug that occurs when reporting bugs, but staging.launchpad.net times out when doing something as simple as showing a package page [14:53] Is it likely that staging will work again soon? [14:53] rick_h_: I'll keep you in the loop when I'll do the benchmark. [14:58] mpt: I'll ask and find out [14:59] czajkowski, actually, I found a package that has hardly any bug reports (which I guess was causing the timeouts), so it's not urgent for me now. But staging seems rather underpowered for meaningful testing. [14:59] mpt: no harm in asking and finding out for sure [15:07] (The bug I was testing I have now reported as bug 943321) [15:07] <_mup_> Bug #943321: Private bug report wrongly says "Subscribed by " for automatic subscribers < https://launchpad.net/bugs/943321 > [15:08] hi folks, launchpad uses a special syntax in brackets to identify the person approving in commit messages for example. where might this be documented? [15:12] cr3: somewhat here: https://dev.launchpad.net/PQMCommitMessages [15:12] cr3: basically it's [r={lpuser}] [15:14] rick_h_: thanks! === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10 [15:57] cr3: There are tools that will generate this for you: "bzr lp-land" from the bzr-pqm plugin, and ec2 land in the LP tree. [15:59] abentley: why use things like [bug=90791] when you can use bzr commit --fixes lp:90791 instead? [16:00] cr3: I don't believe that PQM respects that revision property. It goes strictly on the basis of the message. [16:01] abentley: ok, so in practice, nobody really types any of those bracketed messages, right? [16:01] cr3: right. [16:01] abentley: that makes sense then, thanks! [16:02] cr3: And if you use commit --fixes, then ec2 land or lp-land will include [bug=] for you. [16:04] abentley: sweet, so the developers are encouraged to use bzr properly and get lots of benefits for free === salgado is now known as salgado-lunch === Ursinha` is now known as Ursinha [16:46] mrevell, flacoste: so, we're having some problems with answers.launchpad.net: 1. there are packages linked to some of our projects, so we get weird pages like https://answers.launchpad.net/linaro — I don't seem to have permissions to remove those Packaging records anymore; 2. there are requests to either make "external" setting for answers app do something useful, or get rid of the tab — I know that Launchpad is not designed as a p [16:46] roject hosting service directly, but we want to be able to clearly point people at support resources [16:46] hi, btw :) [16:49] mrevell, flacoste: fwiw, for 1, I'm asking czajkowski in #launchpad if she can help remove them, but I am mentioning that as a more general problem for things we don't have control of [16:52] thanks danilos, I'm otp, so slow to respond [16:52] mrevell, sure thing, just raising this as it's becoming an issue for us and I'd like your general opinion on it when you find the time === salgado-lunch is now known as salgado === matsubara is now known as matsubara-lunch [17:38] * deryck goes offline for lunch, back soon [17:43] Hi im messing around with Oauth and launchpad and was curious if we could add ability to return some user data when grabbing the access_token? [17:43] Right now there is no way to dynamically pull an id/display_name from an initial access token request [17:44] so people will need to know their display name ahead of time [17:47] hmm i guess i could do a /people/+me [17:52] stokachu: so once you have an OAuth token you can request details from /~ exactly. [17:55] lifeless_: ok so when calling api.staging.launchpad.net/people/+me it'll response with json from /~username automatically? [17:55] i think thats how im reading it in docs === lifeless_ is now known as lifeless [17:56] stokachu: yes, likewise /people/+me [17:56] ok sweet [17:56] let me hack it some more -- ive almost got a drupal plugin going [17:57] ahhh i think im adding a json format by accident 'data' => 'Object: , name: u\'+me.json\'', [17:57] it already does json without me telling it [17:59] stokachu, correct [18:00] stokachu, out oauth/launchpad lib code is think of most things as simple string and numbers. dates have to be written as strings I think [18:01] ah gotcha [18:02] if i authorize against launchpad.net and attempt to call api.staging.launchpad.net that will fail b/c of auth correct? [18:02] correct [18:03] Lplib scripts will prompt you to authorise for the new host [18:03] ok [18:04] crap still getting unauthorized [18:05] so here is my header information http://pastebin.com/uB4axged [18:05] stokachu, pastebin the script or the part that does the login/auth [18:05] ok [18:07] http://pastebin.com/8RdQruEi - so this is my library [18:08] line 137-149 is where im having the issue [18:08] im wondering if im not providing enough header information [18:10] Ah I see you are implementing a PHP lib that duplicates part of LaunchapdLib. You will need to manage the JSON serialisation yourself [18:11] stokachu, I think you should look at http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/files/head:/src/launchpadlib/ which shows how credentials and serialisation is done [18:11] ok ill check that [18:15] i dont think im getting to the point of parsing the response yet [18:16] when i do 'request' => 'GET /1.0/people/+me HTTP/1.0 it gives me unauthorized [18:16] even though +request-token and +access-token succeeds [18:17] stokachu, I think the request is missing the Lp cookie that contains who you are. +me looks for the user in the interaction of the request, and that will come from a cookie [18:19] ok, i may be using the wrong scheme here.. i see launchpad uses http authorization scheme [18:19] and i may be pushing it through just post === matsubara-lunch is now known as matsubara [18:21] our oauth module is homebrewed; its possible we only implemented the Authenticate header approach for OAuth [18:32] ok i see, lifeless, i think youre right i dont see anything related to the authorization in the headers [18:32] hmmmmm [18:33] lifeless, stokachu. I think partial implementation is the case here. I recall something came up a a few years ago where where made a change to stay compatible, but did not elect to do a full implementation [18:35] abentley, rick_h_, jcsackett, wallyworld (Ian) has three important in the review queue. I am mentally challenged at the moment. I can review the disclosure rules that are in the branches, but most of the implementation is better reviewed by a rocket scientists [18:35] :P [18:35] sinzui: I'll have a look. [18:36] * sinzui has taken a second dose of cough medicine and now has that disconcerting feeling of contentment. [18:36] haha [18:36] * sinzui fears that when he yawns, a hole will open up behind him and will fall out of the universe [18:36] sinzui: rofl. [18:36] what are the request bugs? i'd like to see all 3 consumer requests methods [18:37] or at least the one where you send as HTTP POST === almaisan-away is now known as al-maisan [18:38] abentley, I am not kidding. me + cough syrup = mescaline induced hallucinations. I never want that to happen again [18:38] sinzui: I'm sorry. "disconcerting feeling of contentment" was too much for me. [18:39] * sinzui does want to re-enact the Odyssey again [18:39] abentley, it is okay to laugh. my wife does [18:39] I am serious that I am mentally challenged [18:41] ok im going write a helper routine to implode my parameters into an Authorization request [18:41] see if i can get authed then === danhg_ is now known as danhg === danhg_ is now known as danhg === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Ursinha is now known as Ursinha-bbl [22:36] james_w: O hai [22:37] hi StevenK [22:38] james_w: lifeless said you guys have a standard way of bringing Django apps, is that right? [22:41] StevenK, ish [22:41] we have what we currently think to be the best way [22:41] but none of our apps probably comply fully with that :-) [22:42] james_w: Are you able to point me at some details? [22:43] StevenK, lp:pkgme-service is the newest one which you may want to use as an example [22:43] https://wiki.canonical.com/JamesWestby/DjangoDeploymentBestPractices has some notes [22:44] james_w: Thanks, I'll look over both