[01:24] <StevenK> wallyworld_: O hai
[01:24] <wallyworld_> hellooooooo
[01:26] <StevenK> wallyworld_: I'm on mumble and ready when you are.
[02:12] <wgrant> wut
[02:12] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-006ee065b5671473827829630f869283
[02:12] <wgrant> Why is something trying to serialise a bug into rabbit?
[02:13] <StevenK> wgrant: I was about to ask you about that.
[02:14] <wgrant> Unless we're for some reason deciding to send notifications for all objects to rabbit.
[02:14] <StevenK> Why would we do that? It makes no sense.
[02:16] <wgrant> So it was making the bug private.
[02:16] <wgrant> s/private/public/
[02:16] <wgrant> Which somehow fires off a rabbit notification because why not.
[02:17] <wgrant> Huh
[02:17] <wgrant> So indeed
[02:17] <wgrant> Anything with a base class of Storm will get rabbit notifications.
[02:18] <wgrant> If the changed fields are JSONable, the world ends.
[02:18] <wgrant> aren't.
[02:19] <StevenK> Strange.
=== poolie_ is now known as poolie
[02:40] <lifeless> poolie: would you have time for a chat today?
[02:40] <lifeless> poolie: in an hour or two from now ?
[02:45] <poolie> lifeless, sure
[03:30] <lifeless> poolie: how about now ?
=== matsubara is now known as matsubara-afk
[04:43] <poolie> lifeless, oops, how about now?
[04:46] <lifeless> poolie: sure, ring me?
=== almaisan-away is now known as al-maisan
[04:52] <poolie> lifeless, engaged?
=== al-maisan is now known as almaisan-away
[05:44] <wallyworld_> wgrant: with access policies and bugs - access policies are associated with pillars, a bug has bug tasks associated with pillars, what is a person is denied access to a pillar, it seems that they can still see the bug even if it has a bug task they cannot see
[05:44] <StevenK> Access to a bug is defined via bugtasks
[05:44] <wgrant> An access grant is for a bug, not a bugtask.
[05:45] <wgrant> You can never see a partial bug.
[05:45] <wgrant> The people who can see a private bug are anyone with a grant on the related policies or an explicit grant for the bug.
[05:45] <wgrant> This means that revoking a policy grant may leave access to some bugs.
[05:46] <wallyworld_> that's the crux of my question i think
[05:46] <wgrant> (this can't happen with a true proprietary project, because bugs can't be shared)
[05:46] <wgrant> Also, fuck bug tasks, seriously.
[05:47] <wallyworld_> wgrant: the sharing details page emits bugtask urls at the moment - the page is associated with a pillar, it iterates over the bug tasks and picks the one for that pillar. i should change it to just emit the bug url i think
[05:48] <wgrant> wallyworld_: It's not a problem either way.
[05:48] <wgrant> You can either see all bugtasks (modulo those on deactivated projects), or you can't see any at all.
[05:48] <wallyworld_> it is because the exported api on sharing service breaks
[05:49] <wallyworld_> it has a param which is a List(Ibug)
[05:49] <wallyworld_> and instead it is getting IBugTask from the XHR call
[05:49] <wgrant> Ah
[05:49] <wgrant> Sure
[05:50] <wallyworld_> so i should just change the logic on the sharing page - if *any* bugtask is associated with the pillar, emit the bug url
[05:50] <wallyworld_> sharing details page i should say
[05:50] <wgrant> No need to consider bugtasks at all in that case.
[05:50] <wallyworld_> well, the page has a context which is a pillart
[05:51] <wgrant> If APGF references an AA that references a Bug, that Bug is relevant.
[05:51] <wgrant> You are already context-filtered by APGF
[05:51] <wallyworld_> so the url is lp.net/pillar/+sharingdetails/person
[05:51] <wgrant> Sure
[05:51] <wallyworld_> the details page should only show bus and branches associated with the pillar
[05:52] <wgrant> And that will say SELECT bug from apgf join aa join bug where apgf.policy IN (SELECT id FROM accesspolicy WHERE product=pillar)
[05:52] <wallyworld_> so how to tell if a bug is associated with the pillar - it has a bugtask targetted at the pillar
[05:52] <wgrant> You're already only getting bugs that are associated with the pillar.
[05:52] <wgrant> AccessPolicyArtifact (which is flattened into APGF) already handles that.
[05:52] <wgrant> There are triggers which mirror BugTasks' pillars into APAs.
[05:53] <wallyworld_> right ok. so there's some existing erroneous logic in the view code i'll just remove. cool. i like deleting code :-)
[05:53] <wallyworld_> i didn;t write it originally so wasn't 100% sure, just wanted to check
[05:54] <wallyworld_> thanks
[06:03] <StevenK> wallyworld_: Setting the link has FF follow it explicity
[06:08] <StevenK> wallyworld_: And moving to the JS module has broken it, so I guess I'll grab you after the call tomorrow and work through it.
[06:17] <nigelb> bigjools: re:timezone, it was mentioned as part of a talk that I'm supposed to be listening to.
[06:17] <bigjools> yes...? :)
[06:19] <nigelb> bigjools: so... I have no clue what timezone :P
[06:19] <bigjools> heh
=== almaisan-away is now known as al-maisan
[06:40] <wallyworld_> StevenK: ok. if i get a chance before then i'll look
[07:35] <wgrant> lifeless: Around?
[07:36] <lifeless> kinda
[07:36] <wgrant> lifeless: Is the pgbouncer ProgrammingError hack in Storm your doing?
[07:37] <lifeless> no
[07:37] <StevenK> wallyworld_: I can paste a diff if you want to look?
[07:37] <lifeless> allenap I think
[07:37] <wgrant>         if isinstance(exc, disconnection_errors):
[07:37] <wgrant>             # When the connection is closed by a termination of pgbouncer, a
[07:37] <wgrant>             # ProgrammingError is raised. If the raw connection is closed we
[07:37] <wgrant>             # assume it's actually a disconnection.
[07:37] <wgrant>             if isinstance(exc, ProgrammingError):
[07:37] <wgrant>                 if self._raw_connection.closed:
[07:37] <wgrant>                     return True
[07:37] <wgrant> Ah
[07:37] <lifeless> possibly stub
[07:38] <lifeless> I wrote the pgbouncer fixture
[07:38] <lifeless> that was all
[07:38] <wgrant> Ah, I see.
[07:40] <wgrant> Bug #959699
[07:40] <_mup_> Bug #959699: test failure: test_pgbouncer_stopped <Storm:New> < https://launchpad.net/bugs/959699 >
[07:40] <wgrant> lifeless: Any opinions?
[07:41] <wgrant> Upgrading psycopg2 to 2.4 seems painless except for that.
[07:48] <lifeless> wgrant: I think upgrading is mandatory isn't it ?
[07:50] <wgrant> lifeless: Yes.
[07:50] <wgrant> lifeless: Well
[07:50] <wgrant> I could backport the changes.
[07:50] <wgrant> But that seems like just delaying the inevitable.
[07:51] <wgrant> Extending the check to also allow DatabaseError unbreaks everything.
[07:51] <wgrant> But seems bad.
[07:55] <adeuring> good morning
[07:58] <allenap> wgrant: That's mine (the pgbouncer hack).
[07:59] <wgrant> allenap: Yeah, I see you also filed a bug upstream about this thing and disabled the relevant Storm tests.
[08:00] <wgrant> The new exception seems legitimate.
[08:00] <wgrant> So I think I'll fix Storm to accept it and undisable the tests.
[08:00] <allenap> wgrant: Tip top.
[08:00] <allenap> Thank you.
[08:06] <mabac> StevenK, hi there! thanks for reviewing the team-engineering view. I've run format-imports on the changed files. is there anything else that needs fixing?
=== al-maisan is now known as almaisan-away
[09:20] <StevenK> mabac: I'd prefer the feature flag change name since it isn't reigstry. But mabac: I'd prefer the feature flag change name since it isn't reigstry. But mabac: I'd prefer the feature flag change name since it isn't reigstry. But that isn't a requirement.
[09:21] <nigelb> StevenK: Is there a joke I'm missing? Or did you just type that out 3 times?
[09:22] <StevenK> No, I just fail at keyboard.
[09:23] <nigelb> Haha. FAIL.
[09:24] <mabac> StevenK, ok thanks. I'll scratch my head on that one. is there any guidelines about feature flags I can have a look at? that bit is all new to me
[09:27] <nigelb> There's a wiki.. somewhere.
[09:29] <mabac> thanks
[09:29] <mabac> https://dev.launchpad.net/FeatureFlags#Naming_conventions
[09:30] <nigelb> Ohman. I fail at finding things on launchpad wiki.
[09:32] <mabac> StevenK, so it's the "area" part that you'd prefer to change? this is a page for a team which displays blueprint work items and bugs for upcoming milestones. can the feature flag be named 'team.upcoming_work_view.enabled' ?
[09:59] <jml> is it actually possible to do Launchpad development on precise?
[09:59] <jml>  launchpad-developer-dependencies : Depends: launchpad-messagequeue-dependencies (= 0.110~precise1) but it is not going to be installed
[10:04] <lifeless> jml: does precise still have python2.6?
[10:04] <lifeless> jml: my usual recommendation - lxc - will be made now.
[10:04]  * lifeless recommends lxc
[10:04] <nigelb> heh
[10:09] <jml> lifeless: it has python 2.6
[10:18] <cjwatson> it may have python 2.6 but it won't have many useful modules for it
[10:18] <cjwatson> (afaik)
[10:42] <jml> I'm following instructions on https://dev.launchpad.net/Running/LXC
[10:42] <jml> but I don't seem to be able to log in to the lxc I've created.
[10:43] <wgrant> jml: Your normal username and password should work
[10:43] <wgrant> root/root used to work, but I don't think it does any more.
[10:43] <jml> wgrant: ah right. my password too, that was the trick.
[11:26] <matsubara> morning!
[11:28] <rick_h> morning
[11:34] <lifeless> nn
[11:42] <mabac> rick_h, hi there! would you land the team-work-ui for me? we've discussed the feature flag name but will leave it as is. the formatting has been fixed. https://code.launchpad.net/~linaro-infrastructure/launchpad/team-engineering-view-ui/+merge/100707
=== jtv1 is now known as jtv
[11:43] <rick_h> mabac: sure thing
[11:44] <mabac> rick_h, cool, thanks!
[11:45] <rick_h> mabac: can you set the commit message on your MP please?
[11:45] <mabac> rick_h, oh sure
[11:48] <mabac> rick_h, done
[11:48] <rick_h> is there a bug to link this to?
[11:51] <rick_h> mabac: ^^ or should I land this no-qa?
[11:51] <jml> I'm getting a recursion error when running 'make schema': http://pastebin.ubuntu.com/914410/
[11:52] <mabac> rick_h, we have tested it a bit on staging but I'm not sure.
[11:52] <mabac> salgado, do you think it can land as no-qa?
[11:52] <salgado> rick_h, mabac, the new page is protected by a feature flag, so I think so?
[11:53] <mabac> rick_h, that's right it's just us who are going to see it now anyway
[11:53] <rick_h> mabac: how about just creating a quick bug to link it to noting about adding it and then we can go through the normal qa process
[11:53] <mabac> rick_h, so yes, it's ok
[11:54] <rick_h> not checked out the change, but just to play it safe
[11:55] <mabac> rick_h, ok will do
[11:56] <rick_h> thanks mabac, sorry to drag through the process more.
[11:56] <mabac> rick_h, no problem
[12:03] <mabac> rick_h, bug 973322
[12:03] <_mup_> Bug #973322: We need a UI for the team engineering view <Auditor:New> < https://launchpad.net/bugs/973322 >
[12:03] <jml> ah, ok
[12:04] <jml> the version of bzr in Launchpad doesn't support colocated branches.
[12:04] <jml> bugger.
[12:04] <StevenK> mabac: It should not land as qa-ok
[12:04] <jml> you guys really do like to make things hard for yourselves.
[12:04] <StevenK> mabac: You want to link the bug to the MP, have the webops enable the feature flag and give it a bit of testing on qas, just to make sure.
[12:05] <mabac> StevenK, ok thanks
[12:05] <StevenK> When it hits qas, of course. :-)
[12:07] <rick_h> StevenK: yep, that's where we're headed
[12:09] <mabac> rick_h, StevenK salgado I've linked the bug to the branch
[12:09] <rick_h> mabac: awesome, thanks
[12:10] <mabac> rick_h, salgado I'll drop offline for half an hour to go home. will resurface asap and look out for trouble ;)
[12:11] <rick_h> mabac: ok, landing has started, waiting on ec2 to kick up
[12:11] <mabac> rick_h, great thanks!
[13:28] <jml> wuu, running tests locally
[13:30] <jml> uhhhhh
[13:30] <jml> why does the Launchpad  PPA have dpkg?
[13:30] <jml> Get: 1 http://ppa.launchpad.net/launchpad/ppa/ubuntu/ lucid/main dpkg 1.15.5.6ubuntu4.5+launchpad1 [2,193kB]
[13:32] <jelmer> jml: support for .orig.tar.xz files in source packages or something IIRC
[13:33] <jelmer> jml: have you checked the changelog ? :)
[13:33] <jml> jelmer: I don't really know how to do that without installing
[13:34] <StevenK> Download the diff and zcat it
[13:34] <jelmer> jml: you can see it on the PPA page
[13:34] <jelmer> or, at least the last entry, which is usually the most relevant
[13:34] <jelmer> https://launchpad.net/~launchpad/+archive/ppa/+packages
[13:36] <jml> jelmer: thanks.
[13:43] <cjwatson> StevenK: native packages don't have a diff
[13:44] <cjwatson> dpkg in the LP PPA is mostly my fault.  It can go away once LP upgrades to precise (at least until the next time there's a requirement for a new dpkg feature)
[13:53] <jml> heh
[13:53] <jml> I have an approved branch, could someone please land it? https://code.launchpad.net/~jml/launchpad/create-commercial-ppa/+merge/100635
=== almaisan-away is now known as al-maisan
[14:09] <rick_h> jml: can you create/link the MP to a bug so it goes through normal qa please?
[14:10] <rick_h> jml: after that I'll ec2 land it for you
[14:16] <rick_h> jml: ty, running ec2 land now
[14:16] <rick_h> see you tomorrow lol
[14:16] <jml> rick_h: thank you.
=== abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2
[14:45] <jcsackett> sinzui: you free for a short chat?
[14:55] <salgado> abentley, I've got a small-ish one up for review if you've got some time: https://code.launchpad.net/~linaro-infrastructure/launchpad/upcoming-work-progress-bars/+merge/100808
[14:55] <abentley> salgado: sure.
[14:55] <sinzui> jcsackett, I am, but let me kill some windows processes to be certain I have CPU and memory to chat
=== al-maisan is now known as almaisan-away
[14:58] <jcsackett> sinzui: ok.
[15:04] <czajkowski> sinzui: is this something the new privacy stuff will address on bugs do you think?  https://bugs.launchpad.net/launchpad/+bug/973228
[15:04] <_mup_> Bug #973228: "Affects me too" text should acknowledge that you are affected by a duplicate <Launchpad itself:New> < https://launchpad.net/bugs/973228 >
[15:04] <sinzui> czajkowski, no, that is a feature request
[15:05] <sinzui> affects me too never manages duplicates. I suspect the bug is already reported
[15:06] <sinzui> jcsackett, my experiment is making this difficult. Can we try a hangout via google messenger
[15:06] <czajkowski> sinzui: thanks
[15:09] <abentley> salgado: can items ever be 0?
[15:11] <jcsackett> sinzui: we can try, sure.
[15:12] <salgado> abentley, you mean a container having no items?  that would be a bug in our code
[15:13] <abentley> salgado: Okay.  Your tests need docs, but r=me.
[15:13] <salgado> abentley, thanks a bunch, I'll add them
[15:38] <abentley> adeuring: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-rabbit-config/+merge/100813 ?
[15:38] <adeuring> abentley: sure
[15:43] <adeuring> abentley: r=me
[15:44] <abentley> adeuring: Thanks.
=== matsubara is now known as matsubara-lunch
=== deryck is now known as deryck[lunch]
[16:20] <salgado> abentley, added docs and fixed one of the tests to create specs explicitly and with different priorities so that they're always in the same order
[16:21] <salgado> abentley, the prerequisite branch is being ec2-landed now.  would you mind ec2-landing this one as well?  if the prerequisite one fails on ec2 this one will fail as well, but if they both pass they will land in the correct order
[16:22] <salgado> there's a chance that the ec2 run of the first one may die or have spurious failures and the second one goes through, though
=== salgado is now known as salgado-lunch
=== salgado-lunch is now known as salgado
[16:59] <salgado> abentley, actually, the prerequisite branch just landed
[16:59] <abentley> salgado: Ah.
[17:00] <abentley> salgado: Even if it hadn't, it doesn't matter to me whether two reviewed branches land in a single revision or separately.
[17:01] <salgado> abentley, I was concerned it could affect the qa-tagger but I guess both bugs would still be linked to that single revision?
[17:01] <abentley> salgado: they should.
[17:27] <bac``> sinzui: you should go back to bed ... until monday.
=== bac`` is now known as bac
=== deryck[lunch] is now known as deryck
[17:34] <timrc> you guys gave sinzui a bed? wow, nice
[17:36] <sinzui> timrc, my bed has a computer and tablet next to it. I just work reclined
[17:36]  * sinzui sometimes wishes that was not true
[17:40] <timrc> sinzui, lol
=== matsubara-lunch is now known as matsubara
[17:55] <rick_h> deryck: working on getting python-ooptools going and when it has you create the user the passwordless bit isn't owrking right
[17:55] <rick_h> deryck: it has a -a flag which --help doesn't show, should that be something else?
[17:55] <rick_h> deryck: from: sudo -u postgres /usr/lib/postgresql/8.4/bin/createuser --port 5433 -a -d $USER
[17:56] <deryck> rick_h, seems like there was a step before that.  schema and migrations.
[17:57] <rick_h> that seems to come afterwards
[17:57] <rick_h> deryck: I'm working on getting the second cluster up and need to create the db
[17:57] <rick_h> but need my account to have perms to do so
[17:59] <deryck> rick_h, I think I did this straight out of the README. let me look at bash history
[17:59] <rick_h> deryck: thanks, yea what I'm trying to follow. In the end I'm tempted to just create a user with -s -P and move on since it's a local dev env and it's how I've setup my account before on other dbs
[18:00] <rick_h> deryck: but if I'm missing someting would like to fix the README
[18:01] <deryck> rick_h, too long ago now for me to have bash history, but I really don't think I changed anything in the commands...
[18:01] <deryck> rick_h, but it does seem like I reordered someone them to what logically made sense, and things "just worked."
[18:02] <rick_h> deryck: ok
=== almaisan-away is now known as al-maisan
[18:03] <deryck> rick_h, I also used an email from lifeless to launchpad-dev as reference too.  let me see if I can find that
=== al-maisan is now known as almaisan-away
[18:05] <abentley> deryck: I want to test some jobs that send emails, but we usually test email in-process.  Any idea how to do this?
[18:06] <rick_h> deryck:  probably https://lists.launchpad.net/launchpad-dev/msg08183.html and the email "shortcut for getting python-oops-tools running"
[18:06] <deryck> rick_h, yup, was just about to paste you a bit of that.
[18:06] <deryck> abentley, thinking....
[18:07] <rick_h> deryck: ok, both seem to assume the current db notes are correct so I'll give it another go, maybe I've missed something. -a just doesn't show up in --help so seemed might be a typo.
[18:08] <deryck> rick_h, same version of postgres as readme, i.e. 8.4 and not 9?
[18:08] <rick_h> yea, the command has the full path to the 8.4/bin
[18:10] <deryck> abentley, you want to test the mail sent by the job? i.e. inspect the mail? Or test that the job fires off mail?
[18:11] <abentley> deryck: I am okay just testing that the job fires off mail.  Unit tests handle the actual text.
[18:11] <rick_h> deryck: doh, my fault. I didn't use the patch but manually edited pg_hba.conf and didn't do it right
[18:11] <rick_h> deryck: thanks, sorry for the timesink
[18:11] <deryck> rick_h, np! :)
[18:12] <deryck> abentley, use some sort of faker mailer that stores what's sent in a variable you can inspect after the job completes?
[18:12] <deryck> s/faker/fake/
[18:14] <rick_h> deryck: abentley I keep meaning to try this out sometime: http://bazaar.launchpad.net/~bloodearnest/+junk/test-email-server/view/head:/README
[18:14] <abentley> deryck: I guess, but then the problem is convincing an arbitrary Launchpad job to use a fake mailer.
[18:15] <rick_h> ah right, running that on qa would be a bit out of the ballpark
[18:16] <deryck> abentley, yeah, true.
[18:18] <deryck> abentley, do all jobs use the same mechanism to send mail? Can you monkeypatch orotherwise intercept the thing sending mail before or after and test that somehow?
[18:19] <abentley> deryck: potentially yes, but it's a subprocess, so you have to trigger the monkeypatching somehow.
[18:20] <deryck> abentley, ah.  yuck.  it is kind of messy then.
=== beuno is now known as beuno-lunch
[18:20] <deryck> abentley, sorry, I'm a bit stumped myself.
[18:21] <abentley> deryck: Well, worst case, I guess we can do an environment variable like USE_FAKE_MAILER.
[18:22] <deryck> abentley, ah, yeah, that would work.
[18:23] <abentley> deryck: Oh, I've got it.  I can write a celery Task that does mail_helpers.pop_notifications.
[18:24] <deryck> abentley, nice!
[18:35] <lifeless> moin
[18:59] <rick_h> jml: heads up, emailed ec2 test results to you
=== beuno-lunch is now known as beuno
[20:47] <salgado> abentley, in case you still have some time today, I have another branch for review (https://code.launchpad.net/~salgado/launchpad/person-upcoming-work-view/+merge/100878).  It looks big but ~95% of it is just moving code around
[20:48] <abentley> salgado: looking
[20:54] <abentley> salgado: 320-321 can be written containers_by_date.setdefault(milestone.dateexpected, [])
[20:57] <salgado> abentley, I'm not a big fan of setdefault() but I can do that
[20:58] <abentley> salgado: I'm just mentioning it.  I like it.  Especially since it returns the value, and you can do setdefault(x, []).append('y')
[21:01] <abentley> salgado: It might be nice to use adaptation for GenericWorkItem.  Then you could make SpecificationWorkItem implement IGenericWorkItem directly, and provide an adapter for BugTask.
[21:03] <abentley> salgado: But since this is just shufffling pre-existing code around, r=me.
[21:07] <salgado> abentley, thanks!  (fwiw, I've considered using adapters for that, but didn't see much advantage in doing so)
[21:10] <salgado> abentley, would you mind landing this one for me as well?
[21:14] <abentley> salgado: Sorry, EOD.
=== abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
[21:21] <salgado> hmm
[21:21] <salgado> anybody willing to ec2-land https://code.launchpad.net/~salgado/launchpad/person-upcoming-work-view/+merge/100878 for me?
[21:33] <salgado> lifeless, maybe you as you seem to be the on call reviewer today? ;) (^)
[21:44] <lifeless> salgado: my landing environment is a little horked just now
[21:45] <lifeless> salgado: but I can find a victim for you
[21:46] <salgado> lifeless, cool, that works as well :)
=== matsubara is now known as matsubara-afk
[22:01] <lifeless> gary_poster: hi; is there anything you guys need from me at the moment ? just asking as we have a long weekend coming up
=== salgado is now known as salgado-afk
[22:34] <wgrant> salgado-afk: Your branch is holy and being reverted.
[22:34] <jelmer> wgrant: we have a problem with holy branches?
[22:56] <jml> rick_h: thanks.
[22:56] <jml> my recent lp branch failed a bunch of doctests because it changed login_person to return the person who is logged in
[22:56] <jml> (meaning you can do 'with celebrity_logged_in("admin") as admin_person:' and other fun things)
[22:57] <jml> so all of the doctests that do:
[22:57] <jml> >>> login_person(foo)
[22:57] <jml> >>> # something else
[22:57] <jml> fail, because login_person isn't supposed to be returning anything, according to them
[22:57] <jml> I think this is a stupidity of doctests
[22:58] <StevenK> ign = login_person(foo) ?
[22:58] <jml> just wondering if anyone has any opinions on what would be the cleanest thing to do
[22:58] <jml> change all the call sites
[22:58] <jml> or revert the API call, creating a private _login_person that *does* return and having the public login_person keep its None-returning behaviour.
[22:58] <StevenK> You could do that too
[22:59] <jml> StevenK: ign = ... would wok, but it would also flag pyflakes.
[22:59] <StevenK> I didn't think pyflakes dealt with doctests?
[22:59] <jml> StevenK: you can get it to if you want.
[23:01] <jml> obviously I want to do the thing that's the least work, but I also think LP has had one too many cracks papered over.
[23:02] <jml> I guess >>> ign = login_person(foo) is better than >>> login_person\n<Person ...>
=== salgado-afk is now known as salgado
[23:14] <salgado> wgrant, what's wrong with it?
[23:15] <wgrant> salgado: There's an XSS in the work item title rendering.
[23:16] <wgrant> There's a reason I questioned your foo_link stuff a couple of days back -- it inevitably leads to mistakes like this.
[23:17] <salgado> oops, indeed
[23:17] <salgado> had you told me the reason I could've avoided the mistake
[23:24] <salgado> wgrant, there's another branch being ec2-landed (under abentley's account) which includes the changes you're reverting as well.  not sure there's anything to be done about that before it lands as abentley is gone
[23:25] <wgrant> salgado: It'll hopefully conflict in PQM.
[23:33] <StevenK> Hm, qas seems faster.
[23:33] <StevenK> Of course, as I say that, it times out 3 times in a row.
[23:40] <rick_h> 041510
[23:41] <rick_h> ok, I didn't even touch the yubikey that time...it's on crack
[23:41] <StevenK> Hm. That reminds me, when is that call ...
[23:41] <rick_h> StevenK: so 9pm your time I think if I used the time website right
[23:41] <rick_h> 6am my time, and should hit the other two in the morning
[23:41] <lifeless> wgrant: sanity check me: the SCA stuff isn't hung off of Ubuntu, its a global concept in the code base today, right ?
[23:41] <rick_h> I didn't hear back from anyone though StevenK
[23:42] <wgrant> lifeless: Yes :(
[23:42] <lifeless> thanks
[23:42] <lifeless> jml: and theres the ack.
[23:42] <wgrant> celebrities ftl
[23:42] <StevenK> rick_h: Perhaps not enough notice
[23:43] <rick_h> StevenK: yea, was the battle of getting the process started in time to beat convoy to produciton while giving a day or two to make sure you can show up
[23:43] <rick_h> but two days should be good for yay/nay I'd think
[23:43] <StevenK> You'd think