[00:04] <wgrant> ಠ_ಠ
[00:47] <wgrant> Yay
[00:48] <wgrant> BugTaskFlat now passes all bug search tests./
[00:48] <lifeless> sweet
[00:48] <wgrant> 3000 lines of refactoring later
[02:19] <wgrant> StevenK: Good evening.
[02:19] <wgrant> Some of <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search--1/+merge/102416>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-0/+merge/102417>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-1/+merge/102419>, <https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-2/+merge/102421> may be of interest
[02:45] <jtv> huwshimi: g'day!  Had you seen this bug?  https://bugs.launchpad.net/maas/+bug/965058
[02:45] <_mup_> Bug #965058: Long error throws add-node form off balance <ui> <MAAS:Triaged> < https://launchpad.net/bugs/965058 >
[02:50] <StevenK> wgrant: -1 and 0 approved
[02:50] <wgrant> StevenK: I wouldn't go so far as to say "good".
[02:50] <wgrant> "not terrible", perhaps
[02:53] <wgrant> It's all preeeetty ugly
[02:53] <StevenK> But *fast* :-)
[02:53] <wgrant> And temporary :)
[03:11] <lifeless> ?
[03:35] <huwshimi> jtv: I think that bug is invalid as we no longer use an overlay.
[03:36] <huwshimi> (Unless I'm missing something.)
[03:36] <jtv> huwshimi: maybe I got the terminology wrong.
[03:36] <jtv> I _thought_ it was an overlay but whatever it is, it didn't stretch well.
[03:37] <jtv> I need to go afk for a bit.
[04:16] <wgrant> lifeless: Around?
[04:22]  * StevenK stabs Zope form handling.
[04:25] <bigjools> it's already dead, that won't help
[04:25] <wgrant> lifeless: In 7675.1045.191 you declared that Bug.id and BugTask.bugID are unambiguous sort columns, when that's clearly false.
[04:25] <wgrant> Do you recall why you did that?
[04:26] <StevenK> bigjools: The stabbing is merely therapeutic.
[04:26] <wgrant> Therapeutic stabbing? That's a new one.
[04:26] <StevenK> Therapeutic for *me*.
[04:27] <bigjools> Dexter Kowalik
[04:27] <nigelb> "Stabbing a dead Zope"
[04:27] <StevenK> wgrant: http://pastebin.ubuntu.com/934982/ since I'm obviously missing something.
[04:27] <bigjools> oh yay now my adsl is syncing at 2mb
[04:28] <bigjools> *stab*
[04:28] <wgrant> StevenK: What's not working?
[04:29] <StevenK> wgrant: I get an OOPS:
[04:29] <StevenK>     return self.__FormFields_byname__[name]
[04:29] <StevenK> KeyError: 'information_type'<br />
[04:30] <lifeless> wgrant: hi
[04:30] <StevenK> bigjools: I'm not so sure I want to watch Dexter.
[04:30] <lifeless> wgrant: that was contextual - I had to bend my head to get it
[04:30] <lifeless> wgrant: in a single context, bug.id is unambiguous, otherwise it isn't
[04:32] <wgrant> lifeless: Right, but there was already an 'if unambiguous_context: add(Bug.id)' block afterwards
[04:32] <wgrant> So I'm confused
[04:37]  * StevenK revokes his 1024D key.
[04:38] <wgrant> StevenK: Bah, nasty lifeless distracted me by answering my question.
[04:38] <lifeless> wgrant: I have no idea
[04:38] <wgrant> StevenK: What's the traceback? is it the custom widget declaration?
[04:39] <wgrant> lifeless: It'll affect index use, so I'll just remove it for BugTaskFlat.
[04:39] <lifeless> fbm
[04:39] <lifeless> we'll see what happens
[04:39] <wgrant> Yeah
[04:39] <wgrant> Also
[04:39] <StevenK> wgrant: http://pastebin.ubuntu.com/934992/ is the traceback, and I've +1'd 1.
[04:39] <wgrant> What does everyone think about the assignee-visiblity thing?
[04:39] <lifeless> doowop
[04:40] <lifeless> wgrant: what about it ?
[04:40] <wgrant> That is, currently there's a special case where the assignee can see a bug even if they don't have a subscription.
[04:40] <wgrant> Seems like that should go away.
[04:40] <StevenK> wgrant: I've reviewed -1, 0 and 1. I'd prefer you find another review for 2.
[04:40] <lifeless> they should get a grant; we should forcibly unassign if the grant is removed.
[04:40] <wgrant> StevenK: Sure, thanks.
[04:41] <wgrant> Meh, until we do that they just don't get access when BugTaskFlat is in use :)
[04:43] <wgrant> StevenK: Um
[04:43] <StevenK> wgrant: Hm?
[04:43] <wgrant> StevenK: Is that a conditional in the root of a class?
[04:43] <wgrant> That's slightly unconventional.
[04:44] <wgrant> However, I suspect the error is because the schema's field names end in _field, but field_names' do not.
[04:44] <StevenK> wgrant: But it works with the flag off for private and security_related.
[04:49] <StevenK> wgrant: So I'm confused too.
[04:51] <StevenK> Right, simple test written for it.
[04:52] <StevenK> Bah, Vim needs M-x comment-region
[04:53] <lifeless> StevenK: ^V,select,:s/^/#
[04:54] <StevenK> wgrant: Changing class schema just have information_type_field = copy_field() makes the new test pass (and all of the current tests blow up :_)
[04:58] <wgrant> StevenK: That's not surprising.
[04:58] <wgrant> The class isn't defined in the function as I initially thought.
[04:58] <wgrant> It's a conditional in a class in a class.
[04:58] <wgrant> So the feature flag is evaluated at module load time.
[04:59] <StevenK> Oh, right.
[04:59] <StevenK> So I can't use schema?
[04:59] <wgrant> I'd define two
[05:01] <StevenK> How do I tell the form the right schema?
[05:02] <wgrant> @property
[05:02] <wgrant> def schema(self):
[05:02] <wgrant>    return foo if getFeatureFlag('blah') else bar
[05:02] <wgrant> or similar
[05:11]  * StevenK stabs FreeNode.
[05:12] <wgrant> freenode
[05:12] <huwshimi> jtv: If you get a chance can you try and reproduce that bug and if so attach a screenshot to the bug?
[05:12] <jtv> Sure
[05:14] <StevenK> wgrant: It works when I define two classes in the schema property
[05:15] <wgrant> Or if you define them outside it :)
[05:15] <StevenK> If I define them outside it, I get NameError
[05:15] <wgrant> Then fix the NameError.
[05:16] <jtv> huwshimi: ahh, I see now: the form extends to the right-hand edge of the page already.  So the bug couldn't occur in the form I reported.
[05:16] <jtv> (But why does it let me create two nodes with the same hostname?)
[05:17] <StevenK> wallyworld: I've moved two of your cards from Deployment-Ready to Done-Done due to the NDT, can you check the other two cards?
[05:18] <StevenK> wgrant: http://pastebin.ubuntu.com/935014/
[05:19] <wgrant> StevenK: self
[05:19] <StevenK> Oh, doh, of course.
[05:20] <huwshimi> jtv: I think I remember there being a bug for that.
[05:20] <jtv> Maybe it's normally an error coming from the backend.  I was running against a fake pserv.
[05:20] <StevenK> wgrant: Last step is to add in the vocab, which requires defeating AssertionError: The vocabulary must implement IEnumeratedType
[05:21] <StevenK> wgrant: And adding implements(IEnumeratedType) hasn't helped
[05:24] <jtv> [wild unsolicited guess] classProvides?
[05:35] <StevenK> It's strange. If I use vocabulary='InformationTypeVocabulary' or vocabulary=InformationTypeVocabulary() I get the AssertionError. If I use vocabulary=InformationTypeVocabulary I get a TypeError in the guts of itemwidget.
[05:36] <wallyworld> StevenK: ok
[05:37] <StevenK> And none of classProvides, implements or alsoProvides changes the AssertionError. :-(
[07:56] <adeuring> good morning
[08:59] <wgrant> Hm
[08:59] <wgrant> Test failures
[10:11] <nigelb> Isn't there something tricky about bug status?
[10:11] <nigelb> It's not exactly attached to a bug, is it?
[10:13] <nigelb> aha. bug_task.
[11:47] <rick_h> is the smtp server running on qa staging?
[11:48] <wgrant> rick_h: qastaging and staging outbound email is captured in the staging mailbox.
[11:49] <rick_h> wgrant: ok, thanks. will look for that on the wiki.
[11:49] <wgrant> https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox
[11:50] <rick_h> ty
[11:54] <wgrant> jcsackett: Hi, around yet?
[11:54] <wgrant> I guess not, rich_h is just strange :)
[11:55] <rick_h> yea, I tend to start early for most US based people I think
[11:56] <czajkowski> rick_h: you really do
[11:56] <rick_h> I like it that way, start early, hit the road early.
[11:56] <rick_h> time with the boy and all that jazz :)
[11:56] <rick_h> meanwhile...my thunderbird hate grows...
[12:18] <bac> jml: when you have time can you look at this updated MP for testrepository?  i've included your suggestions from yesterday.  https://code.launchpad.net/~bac/testrepository/bug-949950-2/+merge/102383
[12:18] <jml> bac: soon
[12:18] <jml> bac: sorry for the delay
[12:19] <bac> jml; np, it wasn't ready until late my afternoon y'day
[12:20] <StevenK> Is it sad when I saw "y'day", I immeadiately thought it was something like "y'all" ?
[12:59] <jml> bac: I've got to head to a call now, but I've looked at your patch, like it and am trying to figure out something better than checking the return type
[13:07] <deryck> Morning, everyone.
[13:07]  * deryck lives!
[13:08] <rick_h> woot!
[13:08] <rick_h> blame the kids deryck, it's what I do.
[13:09] <deryck> oh, it was absolutely the little one's fault. :)
[13:45] <rick_h> jml: ping, looks like landing failed
[13:46] <jml> rick_h: in what fashion?
[13:46] <rick_h> jml: tests passed, but the commit was rejected, this bug it's tied to is listed as fix released on teh 14th
[13:46] <rick_h> so guessing it had no [bug=] and it wasn't set [no-qa]
[13:46] <jml> ah ok.
[13:47] <rick_h> http://paste.mitechie.com/show/624/ for the full output
[13:47] <rick_h> so do we need to mark the bug as open again? Is that the right bug?
[13:47] <rick_h> and I can pqm submit it under that?
[13:47] <jml> rick_h: yes it's the right bug
[13:48] <rick_h> ok, so going to open back up as triaged and then pqm submit, it'll go through qa/etc again then
[13:48] <jml> rick_h: that sounds like a good idea
[13:48] <wgrant> jcsackett: Hi
[13:52] <rick_h> jml, ok, pqm seems satisfied now.
[13:53] <jml> rick_h: yay
[14:43] <jml> crap
[14:45] <czajkowski> jml: thats never good to see after silence, you just know things aren't going well
[14:46] <jml> czajkowski: just realized I'd forgot about bac's branch
[14:47] <czajkowski> :/
[14:49] <czajkowski> hmm wgrant is it possible to change the registered by in a team ?
[14:56] <sinzui> czajkowski, NO. The SQL uses to tamper with the database causes issues later.
[14:57] <sinzui> I would sooner remove the registered information from projects then tamper with it
[15:03] <adeuring> abentley: fancy a review? https://code.launchpad.net/~adeuring/launchpad/celery-config/+merge/102535
[15:04] <abentley> adeuring: sure.
[15:04] <adeuring> thanks
[15:05] <rick_h> deryck: ping for call
[15:07] <abentley> adeuring: I think we want the timeout to be 5 minutes.  That's what it's currently set to, and it will ensure that ~99% of tasks run in the fast lane.
[15:08] <adeuring> abentley: yeah, I suspected that I got the timeout values wrong ;) So, 300 seconds for the fast lanes.
[15:09] <adeuring> abentley: I am also not 100% conviced that a timeout of one day for slow jobs is reasonable...
[15:10] <abentley> adeuring: Somewhere between an hour and a day seems reasonable.  I think we'll need to experiment.
[15:10] <adeuring> right
[15:12] <abentley> adeuring: It's generally a bad idea to assume that sys.argv is defined.  It won't be when Python is loaded as an extension.
[15:13] <abentley> adeuring: I've been bitten by that in Launchpad work before.
[15:13] <adeuring> abentley: ok, we can avoid this -- but is this a real concern here, in a test?
[15:14] <adeuring> abentley: gahhh
[15:14] <abentley> adeuring: You are doing it in lib/lp/services/job/celeryconfig.py which is not a test.
[15:15] <adeuring> ups, right
[15:15] <abentley> adeuring: Can you access Celery's interpretation of the config instead?  Or is that applied after loading celeryconfig?
[15:16] <abentley> adeuring: I mean  Can you access Celery's interpretation of the *arguments*
[15:16] <adeuring> abentley: no, the celery config is not yet available when this module is loaded. this is the reason why I used sys.argv
[15:17] <abentley> adeuring: That is a shame, but if you must use sys.argv, you need to handle the case where it's not defined.
[15:17] <adeuring> abentley: ok, I'll do this
[15:19] <abentley> adeuring: Is there value in defining the binding key explicitly when it's the same as the queue name?
[15:20] <adeuring> abentley: not really. But I wanted to explicitly defined the set of known queues (for sanity checks), and having the binding key available might make sense if we want a more complex rabbitmq setup (but I am not sure if we will ever have such a setup :)
[15:21] <adeuring> abentley: diff so far: http://paste.ubuntu.com/935579/
[15:23] <abentley> adeuring: I have difficulty anticipating what facilities we would want if we made it more complex, so let's keep it simple for now.
[15:24] <adeuring> abentley: ok, so, something like [job_queues] queues: job, jobslow,... ?
[15:24] <abentley> adeuring: Right.
[15:25] <abentley> adeuring: I think set() is the natural type for linked_queues, since we only care about whether a queue is already present in it.
[15:26] <adeuring> abentley: I think a list has the avdantage that you can see where the circle "closes".
[15:26] <abentley> adeuring: okay.
[15:32] <adeuring> abentley:  current diff: http://paste.ubuntu.com/935587/
[15:36] <abentley> adeuring: I think it would be nicer if configure accepted "argv" and returned a dict.  Then you could do "globals().update(configure(getattr(sys, 'argv', [''])))" to actually set it.
[15:37] <abentley> adeuring: That would make it easier to test, and also shorter.
[15:38] <abentley> adeuring: You could even pull the function into a different module so that testing didn't have to actually set the globals.
[15:39] <adeuring> abentley: well, ok...
[15:42] <abentley> adeuring: check_job_specific_celeryd_configutartion is misspelled.
[15:42] <adeuring> fixed
[15:43] <jml> gary_poster: have just merged bac's branch into testr. you guys should be good to go.
[15:43] <bac> jml: sweet
[15:43] <jml> bac: oh cool, you're here :)
[15:44] <abentley> adeuring: Could you give ConfigurationError a docstring?  That will remove the need for the "pass".
[15:44] <gary_poster> jml, thank you!  Is there a place where subunit is in a PPA somewhere?  We need revno 158 and I *think* that's not officially released yet; double checking.  But ISTR that there is a PPA for this stuff...?
[15:44] <adeuring> done
[15:44] <jml> gary_poster: https://launchpad.net/~testing-cabal
[15:44] <gary_poster> jml, ah-ha, I thought it was something like that. :-) thanks again
[15:45] <jml> gary_poster: if it's not up to date, probably best to hassle jelmer
[15:45] <gary_poster> ok
[15:45] <jml> gary_poster: if it's not up to date, probably best to hassle jelmer
[15:45] <bac> jml: your test additions are quite an improvement.  thanks.
[15:46] <jml> one piece of software thatI use has a bug where sometimes the middle part of my screen gets covered by a a white block :(
[15:47] <gary_poster> me too!  I suspect chrome
[15:50] <gary_poster> jelmer, IWBNI the testing cabal had the newest subunit in its PPA.  No biggie though; I'll make one myself for ours.
[16:04] <jelmer> gary_poster: requested a new build
[16:04] <gary_poster> thank you very much jelmer
[16:23] <adeuring> abentley: another look?
[16:34] <gary_poster> subunit builds fail becuse of test failures :-/
[16:36] <rick_h> 553343
[16:41] <jelmer> gary_poster: testing cabal PPA build seems to have succeeded
[16:41] <jelmer> (including tests)
[17:13] <abentley> adeuring: sure.
[17:14] <abentley> adeuring: Is the tearDown still necessary?
[17:14] <adeuring> abentley: argh, sure, that method can go....
[17:39] <rick_h> lifeless: ping when you get in, trying to figure out how to get the oops tools LP talking nice. oops-tools seems fine, but LP isn't dumping messages on the queue and wonderingif I'm missing a step of setup on the LP side.
[17:42] <czajkowski> rick_h: would matsubara be able to help
[17:44] <rick_h> czajkowski: well I guess anyone that knows how LP dumps oops to the rabbit queue would be cool
[17:44] <rick_h> just know lifeless has the keys so lighting up his IRC :)
[18:18] <rick_h> lifeless: czajkowski ok, got it hacked to just use my main rabbitmq instance and got oopses processed so in business I think
[18:23] <gary_poster> jml, if you are around, https://launchpadlibrarian.net/102495365/buildlog_ubuntu-precise-i386.python-testtools_0.9.14%2Bbzr253~ppa37~precise1_FAILEDTOBUILD.txt.gz shows that testtools is not building because py3 does not support destructuring in args ("def _merge_tags(existing, (new_tags, gone_tags))").  Fix is easy, of course (http://pastebin.ubuntu.com/935815/ for instance, if it speeds things along).  However, ht
[18:23] <gary_poster> tp://pastebin.ubuntu.com/935822/ suggests that the build will still fail--and I don't see a python3.2-bzrlib.  I think I'm going to pursue making a branch locally that does not try to support py 3.
[19:21] <lifeless> rick_h: hi
[19:22] <rick_h> lifeless: hey
[19:22] <lifeless> rick_h: the oopssetup doc on the wiki covers this
[19:22] <rick_h> sorry, I was referencing the readme since that seeme dto have all the setup
[19:25] <rick_h> lifeless: so yea, I went through these, but the issue I was running into was that the LP rabbit instance isn't what my rabbit is running at. e.g. default 5672 port vs 56720
[19:25] <rick_h> lifeless: so I had to tweak the rabbit-server stuff to use the existing running rabbitmq instance.
[19:25] <rick_h> lifeless: I think this is because of the install issues I had around the rabbit mgt package stuff in precise
[19:26] <rick_h> lifeless: so I got things running, but basically by telling LP not to start up rabbit, but use the one already running from the system.
[19:26] <lifeless> make run starts a local rabbit
[19:26] <rick_h> the oops-tools stuff went peachy
[19:26] <lifeless> so my notes (referenced from that wiki page) link oops-tools to that rabbit
[19:26] <lifeless> 6/1 1/2 of the other
[19:27] <rick_h> lifeless: right, I want to look at it better because I couldn't tell how to have things like rabbitctl point to a second rabbit instance
[19:27] <rick_h> part of the issue in debugging was trying to figure out if the queu exist/was getting populated and rabbitctl list-queues showed nothing because that was talking to the rabbit on 5672
[19:27] <rick_h> I don't see it accepting a --port parameter, so I didn't realize LP was firing off a second one, etc
[19:28] <lifeless> rabbitctl is influence by environment variables
[19:28] <rick_h> ah
[19:28] <lifeless> it talks to a erlang multiplexer
[19:28] <lifeless> which talks to potentially multiple rabbits
[19:28] <lifeless> its fugly.
[19:28] <lifeless> but there it is
[19:29] <rick_h> gotcha, and I fell down that 'rabbit-hole' and yea I went there
[19:29] <rick_h> :)
[19:29] <lifeless> here - starting point : https://dev.launchpad.net/QA/OopsToolsSetup
[19:29] <lifeless> links to my notes https://lists.launchpad.net/launchpad-dev/msg08183.html
[19:29] <rick_h> got those, thanks!
[19:32] <sinzui> jcsackett, lets qa bug 982539 to verify your branch also fixed it
[19:32] <_mup_> Bug #982539: Losing access to private bugs recently <bugs> <disclosure> <privacy> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/982539 >
[20:45] <benji> lifeless: if you have a minute today I would appreciate your comments on https://code.launchpad.net/~benji/testrepository/add-worker-id-tagging/+merge/102574
[20:48] <lifeless> benji: I'll give it a shot
[20:48] <lifeless> I've a bit of review debt again
[20:48] <benji> thanks
[22:02] <deryck> night, everyone.
[22:03] <sinzui> jcsackett, mumble?
[22:05] <wgrant> sinzui, jcsackett: lib/lp/bugs/stories/bug-privacy/xx-bug-privacy.txt and lib/lp/bugs/doc/initial-bug-contacts.txt fail intermittently with jcsackett's rev
[22:28] <sinzui> StevenK, is this the branch: lp:~stevenk/launchpad/bugs-information_type-ui-secrecy
[22:28] <StevenK> sinzui: That is the first one, yes.