[02:04] <lifeless> oh hai
[02:04] <nigelb> Morning!
[02:05] <lifeless> o/~
[02:44] <poolie> hi nigelb
[02:52] <nigelb> Hey poolie
[02:53] <nigelb> Back to normal after Budapest? :)
[02:54] <poolie> slept til 11 :)
[02:54] <poolie> something about this trip really messed me up
[02:54] <nigelb> Heh
[03:21] <lifeless> flacoste: bug 772954
[03:21] <_mup_> Bug #772954: "Opinion" bug status causes user confusion <opinion-status> <Launchpad itself:Triaged> < https://launchpad.net/bugs/772954 >
[03:22] <nigelb> Would that bug be marked as opinion?
[03:22]  * nigelb runs
[03:23] <poolie> heh
[03:23] <poolie> lifeless, the plan is to delete it?
[03:23] <poolie> or that was the plan?
[03:25] <lifeless> that was jml's intent
[03:26] <lifeless> I believe it needed a sign off that didn't happen before he moved on
[03:26] <lifeless> flacoste and I were talking about it with the Ubuntu qa folk in Budapest
[03:26] <poolie> ..
[03:26] <poolie> a 'lock' flag still seems attractively simple to me
[03:27] <poolie> rather than having policy per state
[03:27] <poolie> i think there were some arguments against it though
[03:29] <lifeless> thats a rather separate discussion
[03:29] <lifeless> opinion has no policy associated with it - it is identical to invalid and wontfix.
[03:29] <poolie> hm, really
[03:30] <poolie> i thought the point of it was unprivileged users could not move things out of that state?
[03:30] <lifeless> no
[03:30] <lifeless> it was purely a different way of saying wontfix / invalid
[03:31] <poolie> ah ok
[03:34] <poolie> so bug 772954 could probably be low, unless you still want it high
[03:34] <_mup_> Bug #772954: "Opinion" bug status causes user confusion <opinion-status> <Launchpad itself:Triaged> < https://launchpad.net/bugs/772954 >
[03:35] <poolie> it causes some noise edits but it's not that much of a problem
[03:35] <lifeless> I think it is still high, as it speaks to the usability of LP and is shallow (barring political aspects)
[04:13] <lifeless> wgrant: bug 767258 - got 2c?
[04:13] <_mup_> Bug #767258: weird PPA stats before Feb 10 <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/767258 >
[04:28] <wgrant> lifeless: 'sup?
[04:29] <lifeless> do you have any idea what the story is?
[04:30] <wgrant> Nope :/
[04:51] <wallyworld_> StevenK: your lp meta deps changes mean that convoy is installed automatically when upgrading launchpad-dependencies, tight?
[04:56] <StevenK> wallyworld_: It should be, yes.
[04:57] <wallyworld_> StevenK: to test, i uninstalled convoy and reinstalled lp-deps (after apt-get update) and it's didn't install convoy
[04:57] <wgrant> wallyworld_: launchpad-developer-dependencies
[04:57] <wgrant> Not launchpad-dependencies
[04:57]  * wallyworld_ headdesks
[04:57] <wallyworld_> ok, sorry
[05:02] <StevenK> So I can cause an oops by browsing to "launchpad.net/~/+archivesubscriptions/foo", but if I attempt the same thing in a test, I get a much different traceback?
[05:03] <wallyworld_> how different?
[05:07] <lifeless> 919 high bugs; only have to get 2/3 more
[05:07] <StevenK> wallyworld_: OOPS-1ff1f2efe2aad173a4eb3eb85bdd679d versus http://pastebin.ubuntu.com/813964/
[05:08]  * wallyworld_ happy that lp-oops login is fixed
[05:14] <wallyworld_> StevenK: apart from the test browser setup difference which is explainable, they both enter publish at the same point and  barf on traverseName differently. i have no idea why
[05:14] <wallyworld_> either
[05:15] <wallyworld_> perhaps devel trunk has changes not yet in prod
[05:58]  * wgrant slays the inventor of timezones, and the author(s) of Python datetime handling.
[06:24] <wallyworld_> wgrant: if it's any consolation, it's also broken in Java :-/
[06:51] <nigelb> wgrant: Isn't part of python datetime handling written by stub? :D
[06:54] <wgrant> nigelb: pytz is his, yes.
[06:54] <wgrant> It's not terrible -- it has to work around the horror that is the standard library's datetime handling.
[06:55] <nigelb> Heh, yeah.
[07:25] <wgrant> Hmm
[07:25] <wgrant> https://github.com/elasticinbox/elasticinbox appeared about two weeks before we started grackle, but after I last looked for similar things :/
[07:25] <wgrant> Although it doesn't seem to do much yet.
[08:09] <lifeless> wgrant: hah!
[09:01] <adeuring> good morning
[10:15] <Laney> can somebody help me unbrick qastaging? :-)
[10:15] <Laney> for example https://qastaging.launchpad.net/ubuntu/+source/quilt
[10:24] <cjwatson> there was activity on the ops channel that suggested StevenK/spm already did?
[10:26] <Laney> works now
[10:26] <Laney> didn't when I pasted it ...
[10:26] <Laney> but regardless, yay, thanks.
[11:14] <Laney> can someone accept one of the banshee syncs in qastating/oneiric/unapproved? Didn't realise it was frozen.
[11:14] <Laney> I need the SPPH.
[11:16] <cjwatson> Laney: done
[11:17] <cjwatson> hmm, oops, rejected
[11:17] <cjwatson> I'll accept the other one :)
[11:18] <Laney> heh
[11:18] <cjwatson> Laney: hmm.  I think, queue or not, you need to sync it into the Proposed pocket, not Release
[11:19] <cjwatson> actually no, sorry
[11:19] <cjwatson> it's in accepted now
[11:20] <Laney> waiting for it to appear on https://qastaging.launchpad.net/ubuntu/+source/banshee/+publishinghistory
[11:20] <cjwatson> qastaging's oneiric is only frozen not current
[11:20] <Laney> yeah
[11:20] <cjwatson> you won't get an SPPH until process-accepted runs, and I'm not sure that will ever happen on qas
[11:21] <cjwatson> bigjools: ^ ?
[11:21] <Laney> maybe I won't bother QAing the non-sponsored case ...
[11:21] <bigjools> the PCJ has to run again
[11:22] <Laney> is it all going to happen automatically?
[11:22] <cjwatson> oh, it doesn't require process-accepted?  curious
[11:26] <rick_h> morning
[11:29] <bigjools> p-a is not used for syncs
[11:29]  * bigjools otp, soryr
[11:29] <cjwatson> Laney: ah, it was rejected because it's older than oneiric's version on qas
[11:29] <cjwatson> Laney: https://qastaging.launchpad.net/ubuntu/+source/banshee/+publishinghistory - you tried to sync 2.1.4-1
[11:33] <Laney> oh, I fail at comprehension
[11:37] <Laney> cjwatson: for some reason I always get banshee versions out-of-order in my head. Anwyway, synced ghc which should be OK to accept.
[11:44] <cjwatson> Laney: done
[11:47] <cjwatson> Laney: https://qastaging.launchpad.net/ubuntu/oneiric/+source/ghc/7.2.1-1
[12:14] <Laney> cjwatson: great, thanks: http://paste.debian.net/153313/
[12:16] <cjwatson> cool
[12:17] <Laney> should I do the non-sponsored case to make sure it is None? I guess so.
[12:20] <wgrant> cjwatson: I'm not sure that copyPackage likes binaries very much.
[12:20] <wgrant> It certainly hasn't been tested with them to any significant extent.
[12:20] <wgrant> Which may be relevant.
[12:22] <cjwatson> aha
[12:22] <cjwatson> noted
[12:23] <Laney> argh, forgot to remove sponsor. If someone could accept the more recent mono-uia sync from https://qastaging.launchpad.net/ubuntu/oneiric/+queue?queue_state=0&queue_text= that'd be great.
[12:25] <cjwatson> Laney: done
[12:26] <Laney> bonus
[12:27] <Laney> qa-ok
[12:27] <wgrant> rick_h: Can you organise an ndt once you QA your regression fix?
[12:28] <rick_h> wgrant: sure, is there a doc for that? /me hits the wiki
[12:29] <rick_h> wgrant: if not I can get abently to walk me through it as I'm sure he's done it before
[12:29] <StevenK> rick_h: Add a line to the Requested Deployments table on LaunchpadProductionStatus
[12:30] <StevenK> rick_h: The fields should be self explanatory, and the docs are the paragraph before the table
[12:30] <rick_h> StevenK: ok thanks, and then ping a webops?
[12:30] <rick_h> ok
[12:30] <StevenK> rick_h: Right
[12:35] <StevenK> rick_h: Are you good WRT the NDT?
[12:35] <rick_h> StevenK: looking/reading
[12:37] <rick_h_> not to self, you can't 'undo' in irssi with ctrl-z...that will just kill irssi
[12:37] <rick_h_> StevenK: I think I'm ok.
[12:43] <cjwatson> ctrl-z will suspend irssi, not kill it, surely ...
[12:44] <cjwatson> use 'fg' to get it back
[12:45] <rick_h> ah, nice
[12:45] <rick_h> ok cool
[12:57] <rick_h> StevenK: ping, still around? With the use-convoy I should be able to remove your ppa, uninstall convoy,and get it picked up from the lp deps repo?
[14:33] <bigjools> cjwatson: any ideas what might be wrong with this build? python setup fail...   https://launchpadlibrarian.net/90814529/buildlog_ubuntu-precise-i386.maas_0.1-0%2B36%2B4~precise1_FAILEDTOBUILD.txt.gz
[15:19] <cjwatson> bigjools: looks like a package bug to me - have you tried in an up-to-date sbuild?
[15:20] <bigjools> cjwatson: we figured it out - unicode issue...
[15:20] <cjwatson> ok
[15:20] <bigjools> when I say "we" I meant allenap of course :)
[15:26] <rick_h> anyone familiar with the db error handling here: b/lp/services/webapp/tests/test_error.py ?
[15:26] <rick_h> we've got a failing test: (at the end of this very very long test report) https://pastebin.canonical.com/58603/
[15:29] <rick_h> adeuring: so this is the bit that's doesn't like the feature flag in some of the oops blocks "Expression: <NotExpr u'request/features/js.combo_loader.enabled'>"
[15:29] <rick_h> it's in the features/flags.py and works when running.
[15:30]  * adeuring is looking
[15:31] <rick_h> adeuring: I think it's this part: https://pastebin.canonical.com/58605/
[15:31] <rick_h> some how the feature flag bit is getting traversed?
[15:32] <adeuring> rick_h: so this is not the regular context but an error, right?
[15:33] <rick_h> right, this is an error that comes out of a test checking if the db disconnect handling is working right
[15:34] <rick_h> so somehow in the process of trying to handle this error, and respond with a noce 503, it blows up on the feature flag bits and instead returns a 500 with the oops dump it looks like
[15:34] <rick_h>  /noce/nice/
[15:34] <adeuring> rick_h: I am not very familiar with LP's error handling -- but it could simply be that this error is raised even before the feature machinery is configured.
[15:35] <rick_h> yea, that's what I'm beginning to think. Ok, so the *fix* would be to add some logic to check for the feature flag exists before checking the value I suppose
[15:35] <adeuring> rick_h: so, a possible fix would be to check if request/features exists.
[15:39] <adeuring> rick_h: the test is about a broken database, and we store feature flag values in the database
[15:39] <rick_h> adeuring: right, I gotcha. Took me a bit to go through all the traceback info and put it together. Thanks, I'll look up the tal to do a pre-check and see if that's enough to bypass that logic in the base-layout-macros.pt
[15:40] <adeuring> rick_h: yes, you could do something like <tal:condition request/features ¦ nothing" -- but that is a bit ugly because it can hide other errors
[15:41] <adeuring> rick_h: something like a property "features_are_ready" would be more clean
[15:42] <rick_h> ok
[15:43] <adeuring> rick_h: or even an empty features object that is later replaced by the "real one"
[16:34] <rick_h> benji: ping, wonder if you can give me a hand.
[16:34] <benji> rick_h: sure, what's up?
[16:34] <rick_h> benji: so first I'm trying to fix test failures from wallyworld_'s branch he tried to land. I'd like to get them reviewed on their own without tying you to his full branch
[16:34] <rick_h> https://code.launchpad.net/~rharding/launchpad/updated_wally_use_convoy
[16:35] <rick_h> benji: but then once I get past that, I'm trying to figure out how I can get the branch through ec2 land. I'd need to either do a new MP? or can I somehow try to land his branch?
[16:35] <rick_h> I supposed I'd just have to do a new MP, get a new sign off, and then run the land command from there?
[16:35] <rick_h>  /supposed/suppose
[16:38] <rick_h> benji: here's basically would I would do as a MP description for my changes if that helps: https://pastebin.canonical.com/58616/plain/
[16:39] <benji> rick_h: looking now
[16:44] <benji> rick_h: I think the best approach would be for you to do an MP for your branch, making his branch a prerequisite so the diffs show just your changes.  Then you can EC2-land your branch.
[16:44] <benji> given your description of the changes, the review should be quick and easy
[16:44] <rick_h> ooh, I cna make his a pre-req? ah cool I've not used that.
[16:44] <rick_h> ok, will do thanks.
[16:50] <benji> gary_poster: file_append adds a line at the end; that's what "append" means ;P
[16:50] <benji> pfft!  wrong chan
[16:51] <benji> I can blame sleep deprivation this time.
[16:58] <rick_h> benji: ok, here you go when you get time: https://code.launchpad.net/~rharding/launchpad/updated_wally_use_convoy/+merge/89732
[16:59] <rick_h> benji: I'm in particular wondering if I should do the change for the feature flag issue differently
[17:01] <benji> rick_h: cool, I'll take a look in a little while
[17:01] <rick_h> benji: ty
[18:39] <lifeless> morning
[19:26] <nigelb> mrevell: Happy Birthday!
[19:26] <nigelb> (off all the things, skype reminded me its your birthday)
[19:27] <nigelb> lifeless: Morning!
[19:36] <lifeless> hiya
[19:38] <mrevell> nigelb, Oh thanks. Not til the 25th :)
[20:38] <wallyworld_> sinzui: hi, did you see my email?
[20:50] <sinzui> wallyworld_, I did, I guess this means you did not get my reply
[20:51] <sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/export-private-bugs-0/+merge/89784
[20:51] <benji> sinzui: sure
[20:57] <sinzui> wallyworld_, to repeat my reply, I like your suggestion, but we track access to bugs and branch by subscription to those objects, and in the future, in the accesspolicyartefact table for reporting in the disclosure pages. I do not think we should introduce a change to how we grant access to things now. We need to talk to wgrant about the time to start switching to the new rules
[21:13] <rick_h> wallyworld_: ping, you see my MP/email?
[21:13] <lifeless> flacoste: http://www.akamai.com/
[21:14] <rick_h> oooh, we getting serious about some cdn fun?
[21:14] <benji> sinzui: your branch looks good
[21:15] <wallyworld_> sinzui: what you say is true i did think along the same lines. i was trying to avoid introducing another situation requiring porting to the new methodology, and doing it in the security adaptor seems cleaner. but i'll do it the current way and we can deal with it later
[21:15] <wallyworld_> rick_h: yes, thanks. a bit of chaos in my house this morning so no reply yet sorry. but looks good. as soon as we get the rt sorted, i'll land
[21:16] <rick_h> wallyworld_: k, tests are still running. I'm going to be off to get the boy from day care soon, but will check back in after he hits bed in about 3 hours
[21:17] <wallyworld_> rick_h: given it was only 4 failing tests and you fixed those, i think we will be good :-) i may end up just merging your branch into mine and landing that, depending on timing of it
[21:17] <rick_h> wallyworld_: yea, all for that. I just wanted to get my changes reviewed because I was a little unsure of my fix for the 503'ing tests
[21:18] <wallyworld_> will look before I merge :-)
[21:18] <rick_h> so setup the MP and hit ec2 test hoping I could get a solid answer that it doesn't bork anything else before you came around
[21:18] <wallyworld_> yep, i hear ya. thanks :-) haven't looked in too much detail  yet
[21:18]  * wallyworld_ now has to run away - raining hard here, first day of school year, limited parking, lots of books, will be chaos
[21:22] <abentley> lifeless: When a comment is too large for us to render, I plan to provide a download link instead.  Do you think that link should be the plaintext message body or the raw email text (where applicable)?
[21:29] <lifeless> abentley: I think either would be fine, but the raw email text would include email addresses which the user may have set to 'hidden' in the DB schema.
[21:30] <lifeless> abentley: so I would lean towards the plaintext version
[21:30] <abentley> lifeless: I prefer that, too.
[22:05] <StevenK> rick_h: Yes.
[22:08] <cjwatson> benji: thanks for the approval of https://code.launchpad.net/~cjwatson/launchpad/kill-old-switchdbuser/+merge/89459 - do you think you could land it for me?
[22:09] <benji> cjwatson: sure, let me kick it off real quick
[22:13] <wgrant> cjwatson: Ah, nice, thanks!
[22:24] <benji> cjwatson: torpedoes away!  I'll let you know how the tests turn out.
[22:26] <cjwatson> I should get mail
[22:26] <StevenK> benji: But so will ec2 ...
[22:28] <benji> StevenK: I wasn't aware of that.  Cool.
[22:31] <rick_h> StevenK: did my update to convoy look ok to you? The updated url routing bits?
[22:33] <StevenK> rick_h: Ah, I was just thinking about that.
[22:35] <sinzui> http://pastebin.ubuntu.com/814808/
[22:36] <wallyworld_> rick_h: your mp looks good. will merge into mine and land today since i'm hopeful i can also get bb updated. wish me luck :-)
[22:36] <rick_h_droid> wallyworld tests all passed!
[22:36] <rick_h_droid> just got the email
[22:37] <wallyworld_> rick_h: bloody marvellous!
[22:37] <StevenK> rick_h: Link me your MP for convoy?>
[22:37] <StevenK> s/>$//
[22:37] <rick_h_droid> land this SOB
[22:37] <wallyworld_> yep
[22:38] <rick_h_droid> SteveK not handy. check in convoy for the latest bug with the MP against it
[22:38] <StevenK> rick_h: Did you want a small review, by the by?
[22:40] <rick_h_droid> SteveK if you've got feedback. waiting for the convoy folks to review/merge
[22:40] <StevenK> rick_h: https://code.launchpad.net/~stevenk/launchpad/better-error-+archivesubscriptions/+merge/89798 is what I was talking about ... :-)
[22:42] <rick_h_droid> ah, not at the moment sorry dinner time
[22:43] <StevenK> rick_h: That convoy MP looks good -- I'd suggest you update the bug, which still has revno as the first directory
[22:46] <rick_h_droid> ah thanks. updated the merge proposal but not the bug
[22:57] <StevenK> wallyworld_: Do you want to review https://code.launchpad.net/~stevenk/launchpad/better-error-+archivesubscriptions/+merge/89798 ? wgrant helped, so he can't really review it.
[23:09] <wallyworld_> StevenK: ok, will look