[00:04] ಠ_ಠ [00:47] Yay [00:48] BugTaskFlat now passes all bug search tests./ [00:48] sweet [00:48] 3000 lines of refactoring later === jtv1 is now known as jtv [02:19] StevenK: Good evening. [02:19] Some of , , , may be of interest [02:45] 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 < https://launchpad.net/bugs/965058 > [02:50] wgrant: -1 and 0 approved [02:50] StevenK: I wouldn't go so far as to say "good". [02:50] "not terrible", perhaps [02:53] It's all preeeetty ugly [02:53] But *fast* :-) [02:53] And temporary :) [03:11] ? [03:35] jtv: I think that bug is invalid as we no longer use an overlay. [03:36] (Unless I'm missing something.) [03:36] huwshimi: maybe I got the terminology wrong. [03:36] I _thought_ it was an overlay but whatever it is, it didn't stretch well. [03:37] I need to go afk for a bit. === jtv is now known as jtv-afk === jtv-afk is now known as jtv [04:16] lifeless: Around? [04:22] * StevenK stabs Zope form handling. [04:25] it's already dead, that won't help [04:25] lifeless: In 7675.1045.191 you declared that Bug.id and BugTask.bugID are unambiguous sort columns, when that's clearly false. [04:25] Do you recall why you did that? [04:26] bigjools: The stabbing is merely therapeutic. [04:26] Therapeutic stabbing? That's a new one. [04:26] Therapeutic for *me*. [04:27] Dexter Kowalik [04:27] "Stabbing a dead Zope" [04:27] wgrant: http://pastebin.ubuntu.com/934982/ since I'm obviously missing something. [04:27] oh yay now my adsl is syncing at 2mb [04:28] *stab* [04:28] StevenK: What's not working? [04:29] wgrant: I get an OOPS: [04:29] return self.__FormFields_byname__[name] [04:29] KeyError: 'information_type'
[04:30] wgrant: hi [04:30] bigjools: I'm not so sure I want to watch Dexter. [04:30] wgrant: that was contextual - I had to bend my head to get it [04:30] wgrant: in a single context, bug.id is unambiguous, otherwise it isn't [04:32] lifeless: Right, but there was already an 'if unambiguous_context: add(Bug.id)' block afterwards [04:32] So I'm confused [04:37] * StevenK revokes his 1024D key. [04:38] StevenK: Bah, nasty lifeless distracted me by answering my question. [04:38] wgrant: I have no idea [04:38] StevenK: What's the traceback? is it the custom widget declaration? [04:39] lifeless: It'll affect index use, so I'll just remove it for BugTaskFlat. [04:39] fbm [04:39] we'll see what happens [04:39] Yeah [04:39] Also [04:39] wgrant: http://pastebin.ubuntu.com/934992/ is the traceback, and I've +1'd 1. [04:39] What does everyone think about the assignee-visiblity thing? [04:39] doowop [04:40] wgrant: what about it ? [04:40] 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] Seems like that should go away. [04:40] wgrant: I've reviewed -1, 0 and 1. I'd prefer you find another review for 2. [04:40] they should get a grant; we should forcibly unassign if the grant is removed. [04:40] StevenK: Sure, thanks. [04:41] Meh, until we do that they just don't get access when BugTaskFlat is in use :) [04:43] StevenK: Um [04:43] wgrant: Hm? [04:43] StevenK: Is that a conditional in the root of a class? [04:43] That's slightly unconventional. [04:44] However, I suspect the error is because the schema's field names end in _field, but field_names' do not. [04:44] wgrant: But it works with the flag off for private and security_related. [04:49] wgrant: So I'm confused too. [04:51] Right, simple test written for it. [04:52] Bah, Vim needs M-x comment-region [04:53] StevenK: ^V,select,:s/^/# [04:54] 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] StevenK: That's not surprising. [04:58] The class isn't defined in the function as I initially thought. [04:58] It's a conditional in a class in a class. [04:58] So the feature flag is evaluated at module load time. [04:59] Oh, right. [04:59] So I can't use schema? [04:59] I'd define two [05:01] How do I tell the form the right schema? [05:02] @property [05:02] def schema(self): [05:02] return foo if getFeatureFlag('blah') else bar [05:02] or similar [05:11] * StevenK stabs FreeNode. [05:12] freenode [05:12] jtv: If you get a chance can you try and reproduce that bug and if so attach a screenshot to the bug? [05:12] Sure [05:14] wgrant: It works when I define two classes in the schema property [05:15] Or if you define them outside it :) [05:15] If I define them outside it, I get NameError [05:15] Then fix the NameError. [05:16] 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] (But why does it let me create two nodes with the same hostname?) [05:17] 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] wgrant: http://pastebin.ubuntu.com/935014/ [05:19] StevenK: self [05:19] Oh, doh, of course. [05:20] jtv: I think I remember there being a bug for that. [05:20] Maybe it's normally an error coming from the backend. I was running against a fake pserv. [05:20] wgrant: Last step is to add in the vocab, which requires defeating AssertionError: The vocabulary must implement IEnumeratedType [05:21] wgrant: And adding implements(IEnumeratedType) hasn't helped [05:24] [wild unsolicited guess] classProvides? [05:35] 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] StevenK: ok [05:37] And none of classProvides, implements or alsoProvides changes the AssertionError. :-( [07:56] good morning === almaisan-away is now known as al-maisan === StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [08:59] Hm [08:59] Test failures [10:11] Isn't there something tricky about bug status? [10:11] It's not exactly attached to a bug, is it? [10:13] aha. bug_task. [11:47] is the smtp server running on qa staging? [11:48] rick_h: qastaging and staging outbound email is captured in the staging mailbox. [11:49] wgrant: ok, thanks. will look for that on the wiki. [11:49] https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/ConnectToStagingMailbox [11:50] ty [11:54] jcsackett: Hi, around yet? [11:54] I guess not, rich_h is just strange :) [11:55] yea, I tend to start early for most US based people I think [11:56] rick_h: you really do [11:56] I like it that way, start early, hit the road early. [11:56] time with the boy and all that jazz :) [11:56] meanwhile...my thunderbird hate grows... [12:18] 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] bac: soon [12:18] bac: sorry for the delay [12:19] jml; np, it wasn't ready until late my afternoon y'day [12:20] Is it sad when I saw "y'day", I immeadiately thought it was something like "y'all" ? [12:59] 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] Morning, everyone. [13:07] * deryck lives! [13:08] woot! [13:08] blame the kids deryck, it's what I do. [13:09] oh, it was absolutely the little one's fault. :) [13:45] jml: ping, looks like landing failed [13:46] rick_h: in what fashion? [13:46] jml: tests passed, but the commit was rejected, this bug it's tied to is listed as fix released on teh 14th [13:46] so guessing it had no [bug=] and it wasn't set [no-qa] [13:46] ah ok. [13:47] http://paste.mitechie.com/show/624/ for the full output [13:47] so do we need to mark the bug as open again? Is that the right bug? [13:47] and I can pqm submit it under that? [13:47] rick_h: yes it's the right bug [13:48] ok, so going to open back up as triaged and then pqm submit, it'll go through qa/etc again then [13:48] rick_h: that sounds like a good idea [13:48] jcsackett: Hi [13:52] jml, ok, pqm seems satisfied now. [13:53] rick_h: yay === al-maisan is now known as almaisan-away [14:43] crap [14:45] jml: thats never good to see after silence, you just know things aren't going well [14:46] czajkowski: just realized I'd forgot about bac's branch [14:47] :/ [14:49] hmm wgrant is it possible to change the registered by in a team ? [14:56] czajkowski, NO. The SQL uses to tamper with the database causes issues later. [14:57] I would sooner remove the registered information from projects then tamper with it [15:03] abentley: fancy a review? https://code.launchpad.net/~adeuring/launchpad/celery-config/+merge/102535 === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 [15:04] adeuring: sure. [15:04] thanks [15:05] deryck: ping for call [15:07] 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] abentley: yeah, I suspected that I got the timeout values wrong ;) So, 300 seconds for the fast lanes. [15:09] abentley: I am also not 100% conviced that a timeout of one day for slow jobs is reasonable... [15:10] adeuring: Somewhere between an hour and a day seems reasonable. I think we'll need to experiment. [15:10] right [15:12] 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] adeuring: I've been bitten by that in Launchpad work before. [15:13] abentley: ok, we can avoid this -- but is this a real concern here, in a test? [15:14] abentley: gahhh [15:14] adeuring: You are doing it in lib/lp/services/job/celeryconfig.py which is not a test. [15:15] ups, right [15:15] adeuring: Can you access Celery's interpretation of the config instead? Or is that applied after loading celeryconfig? [15:16] adeuring: I mean Can you access Celery's interpretation of the *arguments* [15:16] 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] 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] abentley: ok, I'll do this [15:19] adeuring: Is there value in defining the binding key explicitly when it's the same as the queue name? [15:20] 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] abentley: diff so far: http://paste.ubuntu.com/935579/ [15:23] 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] abentley: ok, so, something like [job_queues] queues: job, jobslow,... ? [15:24] adeuring: Right. [15:25] 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] abentley: I think a list has the avdantage that you can see where the circle "closes". [15:26] adeuring: okay. [15:32] abentley: current diff: http://paste.ubuntu.com/935587/ [15:36] 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] adeuring: That would make it easier to test, and also shorter. [15:38] adeuring: You could even pull the function into a different module so that testing didn't have to actually set the globals. [15:39] abentley: well, ok... [15:42] adeuring: check_job_specific_celeryd_configutartion is misspelled. [15:42] fixed [15:43] gary_poster: have just merged bac's branch into testr. you guys should be good to go. [15:43] jml: sweet [15:43] bac: oh cool, you're here :) [15:44] adeuring: Could you give ConfigurationError a docstring? That will remove the need for the "pass". [15:44] 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] done [15:44] gary_poster: https://launchpad.net/~testing-cabal [15:44] jml, ah-ha, I thought it was something like that. :-) thanks again [15:45] gary_poster: if it's not up to date, probably best to hassle jelmer [15:45] ok [15:45] gary_poster: if it's not up to date, probably best to hassle jelmer [15:45] jml: your test additions are quite an improvement. thanks. [15:46] 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] me too! I suspect chrome [15:50] jelmer, IWBNI the testing cabal had the newest subunit in its PPA. No biggie though; I'll make one myself for ours. [16:04] gary_poster: requested a new build [16:04] thank you very much jelmer [16:23] abentley: another look? [16:34] subunit builds fail becuse of test failures :-/ [16:36] 553343 [16:41] gary_poster: testing cabal PPA build seems to have succeeded [16:41] (including tests) === salgado is now known as salgado-lunch [17:13] adeuring: sure. [17:14] adeuring: Is the tearDown still necessary? [17:14] abentley: argh, sure, that method can go.... [17:39] 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] rick_h: would matsubara be able to help [17:44] czajkowski: well I guess anyone that knows how LP dumps oops to the rabbit queue would be cool [17:44] just know lifeless has the keys so lighting up his IRC :) === deryck is now known as deryck[lunch] [18:18] lifeless: czajkowski ok, got it hacked to just use my main rabbitmq instance and got oopses processed so in business I think === salgado-lunch is now known as salgado [18:23] 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] 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. === deryck[lunch] is now known as deryck [19:21] rick_h: hi [19:22] lifeless: hey [19:22] rick_h: the oopssetup doc on the wiki covers this [19:22] sorry, I was referencing the readme since that seeme dto have all the setup [19:25] 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] lifeless: so I had to tweak the rabbit-server stuff to use the existing running rabbitmq instance. [19:25] lifeless: I think this is because of the install issues I had around the rabbit mgt package stuff in precise [19:26] 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] make run starts a local rabbit [19:26] the oops-tools stuff went peachy [19:26] so my notes (referenced from that wiki page) link oops-tools to that rabbit [19:26] 6/1 1/2 of the other [19:27] 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] 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] I don't see it accepting a --port parameter, so I didn't realize LP was firing off a second one, etc [19:28] rabbitctl is influence by environment variables [19:28] ah [19:28] it talks to a erlang multiplexer [19:28] which talks to potentially multiple rabbits [19:28] its fugly. [19:28] but there it is [19:29] gotcha, and I fell down that 'rabbit-hole' and yea I went there [19:29] :) [19:29] here - starting point : https://dev.launchpad.net/QA/OopsToolsSetup [19:29] links to my notes https://lists.launchpad.net/launchpad-dev/msg08183.html [19:29] got those, thanks! [19:32] jcsackett, lets qa bug 982539 to verify your branch also fixed it [19:32] <_mup_> Bug #982539: Losing access to private bugs recently < https://launchpad.net/bugs/982539 > [20:45] 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] benji: I'll give it a shot [20:48] I've a bit of review debt again [20:48] thanks === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [22:02] night, everyone. === salgado is now known as salgado-afk [22:03] jcsackett, mumble? [22:05] 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] StevenK, is this the branch: lp:~stevenk/launchpad/bugs-information_type-ui-secrecy [22:28] sinzui: That is the first one, yes.