[00:00] <wgrant> lifeless: Sure.
[00:00] <lifeless> skype?
[00:00] <wgrant> sec
[00:21] <lifeless> wgrant: http://www.salmon-protocol.org/
[02:26] <wgrant> OOPS reports MIA?
[02:26] <wgrant> LOL
[02:26] <wgrant> Date: Tue, 25 Oct 2011 02:26:19 +0000 (UTC)
[02:27] <lifeless> ask and ye shall receive
[02:27] <wgrant> Half an hour late :/
[02:38] <wgrant> wallyworld: Ahh, I think I see now why canAdd*Task ignored the current privacy status.
[02:38] <wgrant> So that AJAX privacy changes show/hide them?
[02:39] <wallyworld> wgrant: yes
[02:39] <wallyworld> but it works either way
[02:39] <wgrant> Huh, does it?
[02:39] <wgrant> If the bug is public and I make it private by AJAX, the links will not disappear.
[02:39] <wallyworld> hmmm. maybe not, i've confused myself
[02:40] <lifeless> wallyworld: quick question on bugtask deletion
[02:40] <wallyworld> no, i think it works. if it is private, a css class gets added to the links
[02:40] <lifeless> wallyworld: do you guard against deleting the last non-series bug (in a given context) ?
[02:40] <wallyworld> wgrant:  and the css rule then hides those if body.private is true
[02:41] <wgrant> A comment explaining this would be handy.
[02:41] <wgrant> That the hiding is done through CSS based on body.private.
[02:41] <wallyworld> lifeless: perhaps not. i guard against deleting the last task
[02:41] <wgrant> wallyworld: And if it's not private, then the link class doesn't get added.
[02:41] <wgrant> wallyworld: So if I make it private later, the links won't hide until I refresh the page.
[02:41] <wallyworld> wgrant: ok, i'll add a comment somewhere, perhaps in the tales
[02:42] <lifeless> wallyworld: hopefully we'll do seriesonlytasks (or decide we won't do that at all), but I think we should, until then, honour the data model
[02:42] <wgrant> Before you changed it after my suggestion, this worked.
[02:42] <wgrant> lifeless: Which data model?
[02:42] <lifeless> wallyworld: you cannot create a bug with only series tasks today
[02:42] <wallyworld> wgrant: ah, that's why i left out the public check
[02:42] <lifeless> wgrant: ^
[02:42] <wgrant> lifeless: That's true, but only because our API is terrible.
[02:42] <wallyworld> wgrant: i'll revert that change
[02:42] <lifeless> wgrant: no, and we went round this a fortnight back
[02:42] <wgrant> wallyworld: Revert the change, but add comments :)
[02:43] <wallyworld> wgrant: yes, sure. i knew how it worked but got myself confused
[02:43] <wgrant> lifeless: It's true that you can't obtain a bug with only series tasks, but you can create orphaned series tasks.
[02:44] <lifeless> wgrant: retargeting a non-conjoined non-series task ?
[02:44] <wgrant> lifeless: Right.
[02:44] <wgrant> Or through legacy.
[02:44] <wgrant> eg. bug #43150
[02:44] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 >
[02:44] <lifeless> ouch
[02:44] <lifeless> so, I'm merely saying that the current UI and docs and queries assume this isn't the case
[02:45] <wgrant> We discussed this some months ago, remember? :)
[02:45] <lifeless> we've fixed it a bit
[02:45] <wgrant> And we agreed that it was reasonable to allow.
[02:45] <lifeless> I recall agreeing that it exists and we need to handle it gracefully
[02:45] <lifeless> it seems to go against the intent of the conjoined work to encourage it
[02:45] <wallyworld> lifeless: wgrant: so, do i need to make a change to the deletion check? or leave it as is? ie i simply disallow deleting the last task
[02:45] <wgrant> lifeless: Which conjoined work?
[02:46] <lifeless> wgrant: the original :)
[02:46] <wgrant> Disregard that.
[02:46] <lifeless> wallyworld: I'm torn, on the one hand there is an escalated bug which would be solved by having non-series-less bugs
[02:46] <lifeless> (SRU's)
[02:47] <lifeless> wallyworld: on the other hand this will make those bugs unique and inconsistent with the vast majority of the rest of the system
[02:47] <wgrant> That's true.
[02:47] <wallyworld> i'm all for consistency :-)
[02:47] <wallyworld> unless there's a really good reason
[02:47] <wgrant> We're sitting just before a number of major model reworks.
[02:48] <lifeless> wallyworld: tightening the check up a little would aid consistency in the short term. Like I say, I'm torn.
[02:48] <lifeless> I don't *know* that we'll get fallout from having the check looser than the rest of the UI/model behaviour
[02:48] <lifeless> I don't *know* that its safe either given how few examples of series-less bugs we have
[02:51] <wallyworld> lifeless: so if i create a bug with target=launchpad project, isn't that a series-less bug?  product series = trunk may be implied but the BugTask  object simply references the project, no?
[02:51] <lifeless> wallyworld: yes, I said non-series-less bugs
[02:51] <lifeless> wallyworld: its not a double negative!
[02:51] <lifeless> make a bug on launchpad
[02:52] <lifeless> nominate to a series other than trunk
[02:52] <lifeless> delete the non-series task leaving only the newly nominated task
[02:53] <wallyworld> ah, ok. i did discuss this with wgrant and he should me how this is now handled in the ui (a recent change) so it was thought that it is ok to procede
[02:54] <wallyworld> s/should/showed
[02:54] <StevenK> lifeless: You made a comment on an MP of mine yesterday -- I couldn't find anything in my grep'ing, and Curtis couldn't remember anything like that -- happy to be pointed at something.
[02:54] <lifeless> StevenK: which MP ?
[02:54] <lifeless> could someone run bin/test -vvt BranchChangedErrorHandling
[02:54] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173
[02:54] <lifeless> tell me if it has any test stiplle (unusual output)
[02:55] <lifeless> StevenK: ah no, I was noting the abstraction leaks in passing
[02:55] <lifeless> StevenK: if there isn't something, there isn't (but perhaps you should create one)
[02:55] <StevenK> lifeless: http://pastebin.ubuntu.com/718460/
[02:56] <lifeless> ah good, I haven't messed up the branch
[02:56] <lifeless> thanks
[02:56] <lifeless> OTOH test noise fail
[02:56] <StevenK> Agreed
[03:04] <lifeless> grr!
[03:04] <lifeless> tests fail in ec2
[03:04] <lifeless> don't fail here.
[03:04]  * lifeless hates 
[03:05] <mwhudson> isolation fail?
[03:05] <lifeless> mwhudson: presumably
[03:05] <lifeless> mwhudson: its my use-oops-twisted branch FWIW
[03:05] <mwhudson> bet it's a thread local :-P
[03:06] <lifeless> mwhudson: if by that you mean a utility....
[03:06] <lifeless> mwhudson: then I won't take the bet :)
[03:06] <mwhudson> heh
[03:06] <StevenK> wgrant: Mr OCR, do you feel like reviewing https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 ?
[03:07] <lifeless> \o/
[03:07] <lifeless>     1173  OOPS-2123ED1193  BugTask:+nominate
[03:07] <wallyworld> wgrant: i've updated the comments in that branch
[03:16] <lifeless> mwhudson: fortunately the culprit is in the previous 100 or so
[03:16] <lifeless> mwhudson: \o/ subunit and \o/ --load-list
[03:19] <lifeless> mwhudson: testworkermonitorrunnoprocess.test_failure
[03:20] <mwhudson> i guess the oops system doesn't even store state in thread locals, but on disk instead
[03:20]  * mwhudson goes to collect the car after its wof
[03:20] <lifeless> mwhudson: IErrorReportingUtility
[03:21] <lifeless> mwhudson: utility & global, for the combined win of brain-fuckage
[03:21] <mwhudson> oh yes
[03:23] <lifeless> which isn't isolated by the default machinery
[03:23] <lifeless> so reconfiguring that utility -> boom
[03:23] <lifeless> was a foot gun by me in the branch, but still. FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
[03:49] <StevenK> How do I get the HTML out of a view?
[03:49] <StevenK> view = create_initialized_view() ; html = view() ; I thought?
[03:52] <lifeless> StevenK: test_request_daily_build_oops
[03:52] <StevenK> What about it?
[03:52] <lifeless> StevenK: would you happen to know why it generates two oopses, not one, when it only creates one test recipe ?
[03:52] <StevenK> Nope
[03:52] <lifeless> ah well, thanks
[03:53] <StevenK> I didn't touch that bit of r-d-b
[03:53] <lifeless> (another reason why getLastOops causes headaches)
[03:54] <lifeless> grr
[03:54] <lifeless> Launchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal.  It was logged with id OOPS-2124MPJ1.  Sorry for the inconvenience.
[03:54] <lifeless> really must track that down. its getting tiresome
[03:56] <StevenK> lifeless: *Please*
[03:58] <lifeless> hah
[03:58] <lifeless> it was logging at exception level
[03:58] <lifeless> and manually raising
[03:58] <lifeless> *fixes*
[04:00] <poolie> lifeless: non-urgent review some time on https://code.launchpad.net/~mbp/testscenarios/module-scenarios/+merge/80287
[04:07] <lifeless> hmm
[04:07] <lifeless> I don't think job retries should generate oopses
[04:07] <lifeless> still, ESCOPE
[04:08] <StevenK> view() is returning "" :-(
[04:08] <wgrant> StevenK: It probably relies on being executed inside a METAL template.
[04:08] <StevenK> view = create_initialized_view(team, '+index')
[04:08] <wgrant> Right, Person:+index can't be used that way.
[04:09] <lifeless> ugh, and job running also generates 2 oopses per error
[04:09]  * lifeless files an XXX
[04:10] <StevenK> Just remove the job system
[04:10] <StevenK> Please
[04:11] <StevenK> wgrant: Thank you for the approve. If you want to help me collapse those two queries into one, that sounds excellent.
[04:11] <wgrant> StevenK: Find any bugs that are private and there is a subscription or an assigned task.
[04:13] <lifeless> beware over-combining
[04:14] <lifeless> e.g. test the performance of separate vs together
[04:14] <StevenK> wgrant: If I can't use Person:+index in create_initialized_view(), what should I be doing?
[04:19] <poolie> is bug 871596 really still open? is there any workaround?
[04:19] <_mup_> Bug #871596: Not handling administrative shutdown under Oneiric <build-infrastructure> <librarian> <Launchpad itself:Invalid by allenap> <Storm:In Progress by allenap> < https://launchpad.net/bugs/871596 >
[04:43] <huwshimi> Do we have any code for generating thumbnails in Launchpad?
[04:44] <lifeless> huwshimi: probably not, depending on what you are meaning
[04:47] <huwshimi> lifeless: I'm investigating whether we can show small versions of images that are uploaded to Launchpad (e.g. for images attached to a bug). For that we need some code that resizes and probably caches the image.
[04:47] <huwshimi> lifeless: I'm guessing such code probably doesn't exist
[04:48] <poolie> !!
[04:49] <poolie> that'd be nice
[04:51] <lifeless> huwshimi: its been written many times :)
[04:51] <lifeless> huwshimi: this is a perfect candidate for a separate service, it should be a fairly small amount of work to do it
[04:52] <lifeless> huwshimi: librarian for storage, separate link in the bugattachment to the thumbnail, backend to process and upload
[04:52] <lifeless> I don't think we're at the volume to need e.g. haystack yet
[04:53] <lifeless> brb
[04:57] <huwshimi> lifeless: (for when you get back) how long might this take (roughly)? A couple of days, a week?
[04:59] <poolie> :) i like your estimation scale
[05:01] <huwshimi> poolie: If it's outside that scale, it's not ever happening :)
[05:02] <huwshimi> poolie: actually if it's outside of a couple of days it's probably never happening
[05:02] <poolie> :)
[05:02] <poolie> that was my concern about markdown :)
[05:03] <poolie> i suspect you could write it in under a week but it would take a while to get deployed
[05:04] <huwshimi> poolie: Wow, you think there's a week's worth of work for the first stage of markdown?
[05:04] <poolie> i think for it to succeed it would have to be tightly scoped so that you could get something done in under a week
[05:05] <poolie> have there been any LEP/feature type things ever done in less than a week?
[05:06] <huwshimi> poolie: That's pretty depressing really
[05:07] <lifeless> huwshimi: week(s)
[05:07] <huwshimi> lifeless: Ok, sure
[05:07] <huwshimi> lifeless: That also is very depressing
[05:07] <lifeless> huwshimi: you need two schema changes (add field, index it).
[05:07] <poolie> lifeless: re bug 878140, does logging a warning inherently generate an oops?
[05:07] <_mup_> Bug #878140: process-mail.py failed to resolve dns. Raised NXDOMAIN <dkim> <oops> <Launchpad itself:Triaged by mbp> < https://launchpad.net/bugs/878140 >
[05:07] <lifeless> huwshimi: then you need a job to walk things that need doing them and do it
[05:08] <poolie> could https://lp-oops.canonical.com/oops.py/?oopsid=2116INBOUNDEMAIL2 have come from that?
[05:08] <lifeless> huwshimi: lastly you need the actual image resizing code itself (and I would make it a microservice for reusability)
[05:09] <huwshimi> lifeless: Ah, so writing the code wouldn't take a week or more, just the whole process?
[05:10] <lifeless> huwshimi: yes
[05:12] <poolie> huwshimi: another option is to just serve the whole image and rely on the browser to resize them
[05:12] <poolie> for version 0
[05:12] <huwshimi> lifeless: But maybe close to a week for the code?
[05:12] <lifeless> poolie: see OopsHandler in the codebase. (short story -yes, warnings -> things we need to see -> OOPS)
[05:12] <poolie> i see, and it logs the last exception?
[05:13] <lifeless> yes
[05:14] <huwshimi> poolie: We could, but that would mean loading some rather large images at times
[05:14] <poolie> yep
[05:14] <lifeless> huwshimi: the code duration could be a matter of hours, depending on soft things like 'minimum time to get the image resized' and 'do we need parallelisation'
[05:15] <lifeless> huwshimi: there is lots of latency in the landing story today: 4 hours for the column through ec2, 4 hours for it through buildbot, then wait for a fastdowntime window.
[05:15] <lifeless> huwshimi: then for the index on the column, 4 hours for ec2, 4 hours for buildbot, then apply live
[05:16] <lifeless> huwshimi: then for the background job to grab and resize, 4 hours for ec2, 4 hours for buildbot, then wait for a nodowntimedeploy
[05:16] <huwshimi> lifeless: I'm really trying to judge whether this is something that I want to do myself. If it was something that I could code in about 2 days that would be an ok use of my time, if it was much longer, probably not
[05:17] <poolie> lifeless: ok so like https://code.launchpad.net/~mbp/launchpad/878140-dkim-nxdomain/+merge/80289 ?
[05:17] <lifeless> huwshimi: and for the image resizing aspect, depending on whether the dev inlines it (simple but grows the LP codebase) or makes a service (more initial overhead, easier management and tuning thereafter) the same ec2 etc, or the delay with LOSAs to get a new service deployed.
[05:17] <huwshimi> lifeless: So there's no window for actually getting it deployed
[05:17] <poolie> huwshimi: i think it depends a bit how much you want to learn how to write microservices in lp
[05:17] <poolie> etc
[05:18] <lifeless> huwshimi: like most things in LP, its going to touch the whole vertical stack: db, deployment, middleware, object model, security rules, interfaces, and thats ignoring whatever template/js changes you want to support the UI
[05:18] <huwshimi> poolie: Well I would want to do it in a useful way, I also don't want to over optimise
[05:19] <lifeless> huwshimi: I would say, if you're fairly familiar with that vertical stack, then yes, the actual coding aspect could be <= 2 days. If you're not, you'll spend considerable time fumbling and learning (which is perhaps good in its own right)
[05:20] <huwshimi> lifeless: Right, so I'm interested in getting to delve into the code base a bit more, I'm not sure building a whole service would be a good thing to start with
[05:25] <lifeless> huwshimi: yes, its hard to find truely small-but-involves-learning things in LP
[05:25] <lifeless> :(
[05:25] <huwshimi> lifeless: haha, yes
[05:28] <poolie> maybe we can quasi-pair on md?
[05:28] <poolie> lifeless: thanks for the review
[05:29] <poolie> would it be easy to add a test saying "this doesn't oops/warn"?
[05:33] <lifeless> poolie: sure, you need to use one of the logging test helpers, simulate the situation, and check that nothing was logged at or above WARN
[05:33] <lifeless> of course, this is vulnerable to skew, as we're assuming that OOPSHandler won't be given a level= parameter when its added in script setup
[05:34] <lifeless> personally, I would hesitate to test this
[05:34] <huwshimi> poolie: I'm keen to help out if there's a way we can do that
[05:35] <poolie> are you going to uds (i'm not)
[05:35] <lifeless> any test here is vulnerable to two forms of skew I think - the oopshandler config, and the actual exception raised.
[05:35] <poolie> perhaps we could spike it for a day or something , maybe next week
[05:35] <poolie> right
[05:36] <lifeless> so you'd need to make sure you test deeply enough to insulate from that
[05:36] <poolie> i found it confusing the oops is unclear about whether the exception traceback indicates the program stopped at that point
[05:36] <poolie> to me it certainly does look like it stopped, but apparently it did not
[05:36] <lifeless> a bug explaining the confusion would be good
[05:37] <lifeless> I think its right to show the tb it did, but not to confuse you
[05:37] <poolie> a bug against which project?
[05:37] <huwshimi> poolie: No I'm not, I'd be keen for that
[05:37] <lifeless> poolie: to start with LP, which is where OopsHandler is
[05:38] <lifeless> poolie: and/or python-oops-tools which does the rendering
[05:39] <lifeless> poolie: the emit() method on OopsHandler could usefully include the logging level in the message, and whether there was an exception attached
[05:40] <lifeless> => cooking
[05:43] <poolie> lifeless: ok https://bugs.launchpad.net/launchpad/+bug/881243
[05:43] <_mup_> Bug #881243: oops display doesn't make it clear whether the exception stopped the process <Launchpad itself:Triaged> < https://launchpad.net/bugs/881243 >
[05:53] <nigelb> Morning.
[05:54] <nigelb> stub: You'll find this entertaining :)
[05:54] <nigelb> http://thedailywtf.com/Articles/The-Query-of-Despair.aspx
[05:55] <stub> nigelb: I just hope an ORM was involved or my remaining faith in humanity will dwindle.
[05:56] <nigelb> "legacy" application.
[05:56] <nigelb> I doubt if an ORM was involved.
[06:57] <jtv> Who knows about LP's mailing lists?  Need help with this question: https://answers.launchpad.net/launchpad/+question/175718
[07:49] <lifeless> wgrant: 2704 lines
[07:49] <wgrant> lifeless: :(
[07:49] <lifeless> jtv: the mailing list archiver gets rather behind
[07:50] <jtv> lifeless: ?
[07:50] <lifeless> jtv: I'm not sure if we've got a bug for that yet; moving it to a backend JSON server is the planned approach to fix it
[07:50] <jtv> Ah, the question
[07:50] <lifeless> yes :)
[07:50] <jtv> Thanks for looking into it.  “Rather behind” doesn't really cover it in this case though.
[07:50] <lifeless> jtv: days isn't uncommon. Its been weeks on occasion
[07:50] <jtv> IIRC the last archived message there was a year old.
[07:51] <lifeless> jtv: ah! that may need checking by a losa then on the list in question - check that mailman hasn't blerched itself
[07:51] <lifeless> jtv: There are probably logs you can poke at on carob to start with
[07:51] <jtv> Hmm
[07:51] <lifeless> s/probably//
[07:51] <jtv> I'll try that, thanks.
[07:52] <lifeless> the key thing to know is that mailman handles the mail and forwards it etc
[07:52] <lifeless> the list archive is really just another recipient - it queues it up and then rewrites the index page to link it in when it gets to it
[07:55] <jtv> Any chance that it might even be a spam filter?
[07:55] <lifeless> wgrant: it could be worse
[07:55] <lifeless> wgrant: its mostly mechanical
[07:55] <lifeless> jtv: I don't believe so; I would expect no-delivery to list members in that case
[07:57] <wgrant> It's only known to be 4 days out of date.
[07:57] <wgrant> I haven't seen any suggestion that an email was sent to the list between the last one in the archive and October 21st.
[07:57] <wgrant> That's very much within mhonarc-is-slow-and-ubuntu-x-swat-is-huge-so-nevermind territory.
[07:58] <wgrant> Indeed, October 21st is the first email since then.
[07:58] <wgrant> http://www.mail-archive.com/nunit-dev@lists.launchpad.net/
[08:02] <jtv> I wonder why the process-mail.log for the 21st seems to be binary garbage.
[08:03] <wgrant> That sounds irrelevant.
[08:03] <wgrant> mailman doesn't have anything named process-mail.log, AFAIK.
[08:03] <jtv> What are the relevant logs?
[08:04] <mrevell> Hallo
[08:04] <wgrant> All the mailman logs on forster.
[08:06] <adeuring> good morning
[08:06] <jtv> hi mrevell, hi adeuring
[08:06] <adeuring> hi jtv
[08:06] <jtv> wgrant: hasn't forster retired?
[08:07] <StevenK> What gave you that idea?
[08:07] <jtv> I thought that was the server that loganberry replaced.
[08:08] <wgrant> It was.
[08:08] <wgrant> It is no longer the scripts server.
[08:08] <wgrant> It continues to be the mailman server, however.
[08:08] <jtv> So I'm looking for scripts/forster/mailman-xmlrpc/
[08:08] <wgrant> No.
[08:08] <wgrant> Well, probably not the xmlrpc bit.
[08:08] <wgrant> xmlrpc is irrelevant here.
[08:09] <jtv> Okay, what other mailman logs are there?
[08:09] <wgrant> The logs from mailman, which are probably somewhere.
[08:09] <wgrant> mailman/forster
[08:10] <jtv> Ah, thanks.
[08:11] <jtv> Some timeouts there.
[08:30] <lifeless> wgrant: also, no more getLastOops
[08:30] <lifeless> wgrant: more than makes up for size IMO :)
[08:31] <nigelb> poolie: Hey, you guys had a circuit breaker thing for the "should make tea" bug right?
[08:32] <nigelb> poolie: Can you link me to that bug if you have it handy?
[08:32] <poolie> bug 795321
[08:32] <_mup_> Bug #795321: udd importer should make tea while launchpad is down <fastdowntime-later> <Launchpad itself:Invalid> <Ubuntu Distributed Development:Fix Released by vila> < https://launchpad.net/bugs/795321 >
[08:32] <nigelb> poolie: Thanks!
[08:32] <nigelb> I ended up needed something like this for work :D
[08:32] <poolie> are you going to use it somewhere else?
[08:32] <poolie> oh ok
[08:33] <nigelb> Implementing it in bash is going to be loads of fun.
[08:37] <lifeless> \o/
[09:26] <poolie> mrevell, danhg, https://code.launchpad.net/~mbp/launchpad/jobs-link/+merge/80307
[09:26] <poolie> lifeless: ?
[09:27] <lifeless> there is a config setting to put stuff in the footer
[09:27] <lifeless> I'd just set that directly on prod
[09:27] <wgrant> Can't do links, though.
[09:27] <wgrant> I don't think.
[09:27] <lifeless> wgrant: I thought it was html it took
[09:27] <wgrant> I hope not.
[09:28] <wgrant> Anything that I see that takes HTML gets added to my hitlist.
[09:29] <poolie> are you referring to site_message?
[09:29] <poolie> i thought that was meant for "end of the world imminent"
[09:29] <poolie> s//eschaton
[09:29] <poolie> that would be too heavy for this, i think
[09:29] <lifeless> all hail our future light cone
[09:29] <wgrant> site_message is used on staging/qastaging/dogfood
[09:29] <wgrant> To say that changes will be lost.
[09:30] <wgrant> It used to be used on edge to say it was running pre-release code.
[09:30] <wgrant> It was originally along the top of the page, but was demoted to the bottom for 3.0
[09:30] <lifeless> its tasteful but may not support a link
[09:31] <lifeless> anyhow, I have no strong objection, it just seems like something better done in config than in code
[09:31] <poolie> iswym
[09:31] <poolie> otoh there's a fuzzy line between code and config
[09:33] <poolie> lifeless: i was actually wondering about your \hooray emoticon
[09:33] <poolie> was that for me?
[09:34] <danhg> Hi poolie: what am I looking at on that link?
[09:34] <poolie> ah welcome :)
[09:34] <mrevell> danhg, We can talk about that on the phone now. It's your first merge proposal.
[09:34] <poolie> you can do your first code review
[09:34] <lifeless> poolie: implementing circuit breaker in bash.
[09:35] <lifeless> poolie: it was a little ironic
[09:35] <poolie> danhg: mostly if you talk it over with mr that's be good
[09:35] <poolie> don't be too rough on me :)
[09:35] <poolie> night all
[09:36] <danhg> ok
[09:36] <danhg> goodnight
[09:42] <lifeless> zomg use-oops-twisted landed.
[09:42]  * lifeless dances the happy dance
[09:49] <bigjools> wgrant: thanks for QAing 747558 for me - only just saw my bug mail.
[09:51] <lifeless> wgrant: btw, don't know if you saw but collapsing those private-asset queries into one using joins took it up to 5seconds hot (vs 4ms hot using a union all)
[09:52] <wgrant> lifeless: The query was wrong. Not sure if that would make much of a difference, though.
[09:52] <lifeless> wgrant: yah, table scans R us
[09:53] <wgrant> bigjools: That was the ddeb thing?
[09:54] <wgrant> Bug #747558
[09:54] <_mup_> Bug #747558: PPAs should create backtracable packages <escalated> <ppa> <qa-ok> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/747558 >
[09:54] <wgrant> Right.
[09:55] <bigjools> wgrant: did you test just the upload changes I made?
[09:56] <bigjools> I need to add the copying safeguard and then it's probably ok to release
[09:56] <bigjools> but I want to see it working on DF myself
[09:56] <wgrant> bigjools: Yeah, I just built a package with some ddebs and checked that the overrides matched.
[09:56] <bigjools> cool
[09:56] <bigjools> where is it~?
[09:56] <wgrant> Didn't try superseding, because I didn't want to sneak concordia away for too long.
[09:57] <wgrant> https://dogfood.launchpad.net/~wgrant/+archive/dogfood/+packages <- aalib there
[09:57] <bigjools> concordia is still on DF anyway
[09:57] <wgrant> Needs process-accepted run, but I checked the BPR overrides in the DB.
[09:57] <bigjools> running it
[10:30] <nigelb> bigjools: lolcricket :D
[10:30]  * nigelb ducks
[10:30] <bigjools> (_._)
[10:31] <nigelb> hrm, what's that stand for?
[10:31] <nigelb> Or should I not be asking :D
[10:31] <bigjools> I was mooning you :)
[10:31] <nigelb> ha
[11:02] <bigjools> nigelb: still laughing?
[12:37] <bac> hi mrevell
[12:38] <mrevell> hey bac
[12:55] <thumper> morning
[12:58] <deryck> Morning, all.
[12:59] <allenap> Morning deryck.
[13:11] <bac> yo mrevell
[13:13] <abentley> allenap: how's that storm bug coming?
[13:14] <allenap> abentley: I've resolved most of the issues; only one very stubborn one remains.
[13:15] <abentley> allenap: oh dear.  Anything I can help with?
[13:17] <allenap> abentley: I don't think so... but I'll ping if there is something. Thanks. As of about 10 seconds ago I think we might need to move to a newer psycopg2.
[13:18] <abentley> allenap: Okay.  Good luck with it.
[13:18] <allenap> And now I'm not so sure!
[13:25] <abentley> allenap: I hate that.
[14:11] <thumper> flacoste: ping
[14:57] <danilos> flacoste, hi, I am Danilo from the Linaro team :)
[14:59] <danilos> flacoste, asac mentions how there is a very important regression that hits us in https://bugs.launchpad.net/launchpad/+bug/881144, which is time critical; do you think it'd be possible to get someone to look at it today/tomorrow to at least get any idea if we can get some results by Thursday?
[14:59] <_mup_> Bug #881144: field.tags_combinator=ALL gives same results as with ANY <bugs> <regression> <search> <Launchpad itself:Triaged> <Linaro Android:Triaged> <Linaro-Ubuntu:Triaged> < https://launchpad.net/bugs/881144 >
[14:59] <danilos> flacoste, if not, perhaps we need to focus on a work-around on our side (we can load bug-by-bug through API and filter stuff out that way)
[16:03] <nigelb> drat. no bigjools.
[16:03] <nigelb> I wanted to poke fun at england's cricket team :D
[17:12]  * sinzui sends all spam to himself before sending to the user so that he shares their pain
[17:16]  * sinzui plants face in palm
[17:41] <nigelb> sinzui: If you shoot your self in the foot...and then complain... :P
[17:42] <sinzui> nigelb, My test went fine
[17:42] <sinzui> But I left my name in one of the headers in the real send.
[17:43] <nigelb> :)
[19:53] <thumper> sinzui: hi
[19:53] <sinzui> Hi thumper
[19:53] <thumper> sinzui: how do I get project associations on the stakeholder list?
[19:54] <thumper> sinzui: distro really want it now I told them what it is
[19:55] <sinzui> thumper, you need to find stakeholder reps to bring it to the list.
[20:01] <lifeless> thumper: Sounds like a handwave rather than a LEP :) [I mean, theres a lot of things it -might- mean]
[20:02] <lifeless> thumper: its going to be feature level work I think, which means that the various stakeholders have to all agree its position on the list for it to get scheduled [more or less]
[20:03] <thumper> I've been told there hasn't been a stakeholders meeting of 6 months
[20:03] <lifeless> the queue already has items in it, and noone has proposed removing them
[20:05] <lifeless> the stakeholder process is about prioritisation, not about getting things done more quickly
[20:05]  * thumper nods
[20:05]  * thumper goes back to the drawing board
[20:07] <lifeless> [theory being that with consensus about what to do next, we can avoid chopping and changing mid-project, letting us deliver the projects more smoothly and with less defects]
[20:25] <sinzui> thumper, I can brief people were we were in 2009. We had a proposal that Mark asked for UI changes to
[20:30] <deryck> abentley_, hi.
[20:30] <abentley_> deryck: hi.
[20:30] <deryck> abentley_,  I see you got mail for the feature branch passing, but not clear on my end if you got the upgrade branch mail also.
[20:31] <abentley_> deryck: No, I didn't get that one.
[20:31] <deryck> abentley_, ok, I'll forward to you then.
[20:37] <abentley_> deryck: did you know that {foo: 'bar', baz: 'qux'} is different from {baz: 'qux', foo: 'bar'} in Javascript?  Objects used as mappings apparently preserve ordering.
[20:37]  * lifeless headdesks
[20:45] <deryck> abentley, are you sure it's the ordering that matters, and not just that js sees two different objects?  i.e. how are you testing this?
[20:46] <abentley> deryck: I'm producing query strings from a mapping, and the order of the items in the query string matches the order the items are added to the mapping.
[20:48] <abentley> deryck: I think I saw this earlier with JSON stringification, too.
[20:51] <deryck> abentley, so I'm having a little trouble following the specific example here of how ordering matters, sorry.  But....
[20:52] <deryck> abentley, I did know directly comparing the same objects in js won't work.  it sees different objects.
[20:52] <deryck> abentley, but this is to do with how js creates/sees objects.  and you usually just compare properties and values, not object to object.
[20:53] <abentley> deryck: {foo: 'bar', baz: 'qux'} => "foo=bar&baz=qux",  {baz: 'qux', foo: 'bar'} => "baz=qux&foo=bar"
[20:54] <abentley> deryck: So even when you serialize it, you get different values for equivalent mappings.
[20:56] <deryck> abentley, you would expect {baz: 'qux', foo: 'bar'} to come out "foo=bar&baz=qux" ?
[20:56] <abentley> deryck: I would like a consistent order.  I don't have a particular order in mind.
[20:58] <deryck> abentley, is this something in the language causing the issue, though?  Or in how you're doing the serialization?
[20:59] <abentley> deryck: Something in the language is causing the issue, because if mappings were unordered, as in Python, it would be impossible for a serialization to preserve ordering.
[21:02] <deryck> abentley, are you doing the serialization yourself or relying on something in yui3?
[21:04] <lifeless> abentley: have you seen ordereddict in python 3 ?
[21:04] <abentley> deryck: I don't understand why that's relevant, but I'm using something in YUI3,
[21:05] <deryck> abentley, I guess it's not relevant.  Just curious mostly.
[21:05] <abentley> lifeless: No, but I have occasionally encountered situations where that would be useful.
[21:05] <deryck> abentley, I guess it's not that shocking to me either because js objects aren't really the same as python dicts, even though they seem similar in ways.
[21:07] <abentley> deryck: It was surprising to me, because it's the first language I've encountered that had ordered mappings by default.
[22:23] <sinzui> wallyworld_, wgrant, StevenK: Gerald the Gorilla http://www.youtube.com/watch?v=beCYGm1vMJ0
[22:44]  * StevenK assumes gmb is no longer reviewing.
[23:01] <StevenK> wgrant: When you have a tick, glance at the query in https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 , lines 51 to 62
[23:10] <wgrant> abentley: Any reason you didn't use IJSONRequestCache for storing the mustache template?
[23:10] <wgrant> abentley: Using dumps directly is not safe.
[23:12] <wgrant> StevenK:
[23:12] <wgrant> tables=(
[23:12] <wgrant>     Bug,
[23:12] <wgrant>     Join(BugSubscription, BugSubscription.bug_id == Bug.id)),
[23:13] <wgrant> Same with the multi-line where.
[23:14] <wgrant> I also find the execute(Union syntax distasteful.
[23:14] <wgrant> Particularly since you then have you use .rowcount afterwards.
[23:21] <StevenK> wgrant: I've fixed the tables and where. I don't really want to reflow the entire block though. :-/
[23:21] <poolie> jesus team roles are such a mess
[23:22] <poolie> how can i find out what access an open team actually has?
[23:23] <wgrant> You can't.
[23:23] <poolie> yeah that was really a way of saying "i wish i could"
[23:28] <wgrant> StevenK: What reflowing are you talking about?
[23:29] <wgrant> StevenK: Also, when you raise the exception on line 68, what sort of string does the policy turn into?
[23:29] <wgrant> Open? OPEN?
[23:32] <StevenK> I think it's 'open'
[23:32] <poolie> lifeless: re bug 881237, would it be too tasteless to just catch Exception around the call to dkim
[23:32] <_mup_> Bug #881237: broken dkim key on qq.com causes mail to be dropped <dkim> <mail> <oops> <Launchpad itself:Triaged by mbp> <pydkim:In Progress by mbp> < https://launchpad.net/bugs/881237 >
[23:32] <wgrant> Please try to check.
[23:33] <poolie> so that random bad input, causing eg a KeyError or ValueError, doesn't result in the mail being dropped
[23:33] <StevenK> wgrant: Hold on, I'll do it now.
[23:33] <poolie> this is kinda papering over pydkim not handling those things cleanly but perhaps it's good to be defensive
[23:33] <wgrant> poolie: Have you read pydkim's code? :)
[23:34] <wgrant> s/good/necessary/
[23:34] <poolie> there are no tests
[23:34] <wgrant> I agree completely with catching Exception.
[23:34] <poolie> presumably because the code has been formally proved to be correct
[23:34] <poolie> ok thanks
[23:35] <StevenK> Formal proof nothing. LP has taught me that you *NEED* tests.
[23:35] <wgrant> Our fork is no longer a several-hundred-line function, and it's more correct and tested, but it's still awful awful.
[23:35] <poolie> now that upstream seems to have appeared again perhaps we can push them up
[23:36] <wgrant> Indeed, I was surprised to see it on github.
[23:36]  * StevenK kills SSO
[23:36] <wgrant> Since we had no response from him for several months.
[23:36] <poolie> yeah, but isn't that always the way?
[23:36] <poolie> actually doing something yourself prompts others into action
[23:43] <StevenK> wgrant: What does it mean when icons in the dock have a green background?
[23:43] <wgrant> StevenK: s/dock/Launcher/?
[23:43] <StevenK> Right
[23:44] <wgrant> It means either that it decided the primary colour of your icon was green, or possibly that your graphics drivers suck.
[23:44] <StevenK> Sorry, one icon is green
[23:44] <StevenK> And it changes
[23:45] <StevenK> wgrant: The text is "The team subscription policy cannot be Open Team because it is subscribed to or assigned to one or more private bugs."
[23:45] <wgrant> I guess that's OK.
[23:45] <wgrant> We really should s/subscription/membership/ everywhere :(
[23:46] <StevenK> If you're happy enough with it, I'll land it.
[23:46] <wgrant> Sounds OK.
[23:48] <wgrant> wallyworld_: But the action *can* be mostly undone.
[23:48] <wallyworld_> sort of
[23:49] <wallyworld_> i was adhering to the instructions in the bug report
[23:49] <wgrant> As it stands, the statement is a lie.
[23:50] <wgrant> It says that it will mark the bug as not affecting that target, and this action cannot be undone.
[23:50] <wgrant> I can create a counterexample by clicking "Also affects project"
[23:50] <wallyworld_> i think the intent is to make people really sure they want to delete something
[23:50] <wallyworld_> in most all other cases, delete is permanent
[23:51] <wallyworld_> perhaps good to be consistent with the warnings
[23:51] <wgrant> In this case the task deletion is permanent.
[23:51] <wgrant> The not-affectingness is not.
[23:51] <wgrant> The only information that is deleted permanently is metadata that probably <10 people look at.
[23:52] <wallyworld_> you may be best to take it up with the author of the bug report?
[23:52] <wgrant> Perhaps.
[23:52] <wgrant> sinzui: Still around?
[23:52] <wallyworld_> i don't mind either way what is decided
[23:59] <wallyworld_> so why can't i use the construct <p tal:define="foo context/bar"  tal:content="string:${foo}"/>  ? it only likes <p tal:content="string:${context/bar}"/>