[00:12] wgrant: http://sourceforge.net/apps/trac/sourceforge/wiki/API => no bugs [00:13] Ah [00:13] There's a bug RSS feed, but that's it [00:14] Which doesn't help === micahg_ is now known as micahg [03:28] wgrant: So I just created two bugwatches pointing to libav, bug 16 had a invalid bug number, and bug 17 had a valid one. After running checkwatches, bug 16 is still Unknown/Unknown but bug 17 is Fix Released/Medium [03:28] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language < https://launchpad.net/bugs/16 > [03:28] <_mup_> Bug #17: System error < https://launchpad.net/bugs/17 > [03:28] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language < https://launchpad.net/bugs/16 > [03:28] <_mup_> Bug #17: System error < https://launchpad.net/bugs/17 > [03:28] _mup_: Go away [03:28] wgrant: So I guess bug 634906 is fixed [03:28] <_mup_> Bug #634906: An invalid remote bug ID can cause a checkwatches run to break completely

< https://launchpad.net/bugs/634906 > [03:33] StevenK: Excellent. [03:33] So that's two nailed shut today [03:33] Three if we deploy === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~180 [03:41] wgrant: Turns out urlopen that initializeRemoteBugDB calls uses the default timeout value. Perhaps we should set it to 180 and move on? [03:42] It might be more sinister [03:42] StevenK: Perhaps block the connection locally and see if you can reproduce the behaviour? [03:43] The urlopen call has a ensure_no_transaction decorator [03:46] Sure, we know it has no transaction open [03:46] Since it doesn't get idle-killed [03:46] Right [03:47] I was wondering if that was what was causing the spining [03:52] wgrant: Right, I have forbidden my computer to talk to libav's bugzilla [03:53] -j DROP, I hope? [03:53] Well, duh [03:53] I don't want checkwatches getting port unreachable or wind of it [03:58] It's still trying [03:58] 36 dropped packets [03:58] Hmm hmm [03:58] Leave it for half an hour and see what happens :) [03:58] It hasn't logged anything about libav [03:58] Which is naughty [03:59] It usually does [03:59] Oh, unless it's hung on some preprobe [03:59] Which is likely, it's trying to get the version [03:59] 2012-11-20 03:59:01 INFO Updating 1 watches for 1 bugs on http://bugzilla.libav.org [03:59] It seems it gave up [04:00] Now it's probably POSTing [04:03] 2012-11-20 04:01:08 INFO Error updating http://bugzilla.libav.org/: http://bugzilla.libav.org: [04:03] That's disappointing [04:19] urlopen uses socket._GLOBAL_DEFAULT_TIMEOUT if it isn't set, which is defined as object() [04:19] socket.create_connection will only call socket.settimeout if the timout isn't that [04:23] It could be a proxy thing [04:24] squid just keeps a open connection [04:24] But I'm grasping at straws [04:28] Possibly [04:30] wgrant: It may explain why neither of us can reproduce it locally [04:38] And the squid I just installed gives a 504 [04:38] But that's default config [04:40] IIRC I even tried it from behind squid.internal [04:40] And it worked [04:42] Strange [04:42] Have you checked the last couple of hangs? [04:42] I have not [04:43] But I'll stop scratching my head over this and move onto glaring at Redhat XMLRPC [05:58] wgrant: Ah ha. We send Bugzilla.time as a XMLRPC to redhat's tracker and get back Fault -32000 [06:00] StevenK: So the method to get the remote tracker's current time fails? [06:01] Yeah [06:01] \n\nBugzilla.time\n\n\n\n' [06:01] Oh, not even any params? Nice [06:01] Is what we send [06:01] I guess we'll need to file a bug with them :) [06:02] I can't find any docs about Bugzilla.time [06:02] What's the full traceback we get from them? [06:02] I assume it works on other bugzillae [06:02] but theirs is broken [06:03] wgrant: Yeah, it seems fine with others [06:03] Let me hack xmlrpclib [06:04] ({'faultCode': -32000, 'faultString': 'Cannot compare a datetime to a regular scalar at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/DateTime.pm line 1385.\n'},) [06:05] That's the full stack in xmlrpclib.close [06:07] https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=4.2 might be your friend [06:07] I suspect [06:07] * StevenK stabs bugzilla [06:09] wgrant: http://pastebin.ubuntu.com/1371847/ [06:09] The first run is with the ooo proxy commented out, the second with the redhat one [06:09] yep [06:10] Bleh [06:10] Create an account? :-( [06:10] Yeah [06:10] If only all bugtrackers supported arbitrary third-party OpenID providers :) [06:12] bugzilla-owner@redhat.com is the registered owner, we could just mail them ... [06:12] Well [06:12] You know we always ask for bugs to be filed [06:12] Let's extend the same courtesy to them! [06:24] wgrant: Bugzilla bug filed, LP bug updated, card created and marked as blocked [06:24] Did you create a bugwatch so we can check its status? :P [06:25] I can't! [06:26] And noted that in the LP bug, so bugger off [06:26] Hm, why can't you? [06:28] The watch will never get updated [06:28] The RedHat bugtracker is disabled [06:28] So there is little point [06:28] Ah, right, I was thinking that if they'd fix it then we'd know [06:28] But not if it's disabled [06:31] Not turning it back on, either. We can do without an extra 2500 OOPSes a day [08:50] good morning [09:56] Trying to bludgeon buildout into running in offline mode is a real pain in the arse [09:58] Something is seriously broken when you get download errors when running in offline mode. WTF were you looking there in the first place stupid? [09:59] stub: you're being a bit harsh on yourself today === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban | Firefighting: - | Critical bugs: ~180 [10:26] Umm... don't we stop bugs being duplicates of each other? [10:27] oh, nm === almaisan-away is now known as al-maisan === rick_h changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: ~180 [13:17] Hmm yesterday I asked about the release date of CoC not correct on Launchpad QAstaging. Now CoC 2.0 is official, but then the date is still not changed.... [13:21] smartboyhw: date doesnt need to change [13:21] it's up to date. [13:22] czajkowski, you can't say that the CoC 2.0 is released in 2005 (or can you?) [13:22] I can and I did :) it needs to be done that way for reasons like making sure anyone who has signed previous versions are still valid. [13:24] czajkowski: ah ok. Yea missed the date thing when I pushed [13:24] rick_h: no tis fine [13:24] checked with wgrant and co that it needs to be that way [13:24] so tis grand [13:24] thanks rick_h [13:24] does look strange. been many moons since I did CoC stuff (e.g. signed it) [13:24] rick_h: like the blog post :) [13:25] ok, well I'll stop looking at what to fix then. [13:25] rick_h: :) [13:25] dont fix what's not broken :) [13:26] I can find lots of bugs if you want to fix stuff :p [13:26] heh, I'll just go back to fixing the bug I've been working on [13:34] adeuring: ping, have time to help me out with something? [13:34] rick_h: sure [13:34] hangout ok? [13:35] rick_h: sure [14:38] rick_h: you see errors like this before https://bugs.launchpad.net/launchpad/+bug/1081131 [14:39] <_mup_> Bug #1081131: Specifications privacy: error when trying to change sharing settings < https://launchpad.net/bugs/1081131 > [14:39] czajkowski: stand up, but will peek in a few [14:39] np [14:57] czajkowski: I've not seen that exactly and the bug wanders a bit so not 100% sure. Most things consider owner. [14:58] I've not looked at the sharing ui itself which is seems he got access to bug couldn't change. Maybe deryck or abentley can speak more to that specifically [14:58] nods [14:58] sorry for pinging you just saw you online :) wasnt picking on you :p [14:59] that's ok, I'm more than happy to play flight directing guy and wave you over away :P [14:59] lol [14:59] deryck: how is the little one post op ? [14:59] all good I hope [15:00] I haven't worked on the sharing UI. It does sound like it should only be shown as editable to folks with Launchpad.Edit on the appropriate members. [15:09] czajkowski, hi. she's good, thanks! A little sore this morning as you'd expect but she's getting better with each moment. [15:09] great to hear [15:10] I had mine out as an adult and was back to eating as normal 3 days later. [15:10] but bf had his out there last year, took him 2 weeks to recover [15:10] everyone recovers differently [15:10] she's eating pretty good now herself, albeit soft stuff like mac-n-cheese and mashed potatoes. [15:11] good going [15:11] she was starving. but my little would consume the doors of the kitchen if we'd let her. [15:11] deryck: while you're here you might be able to shed some light on https://bugs.launchpad.net/launchpad/+bug/1081131 [15:11] <_mup_> Bug #1081131: Specifications privacy: error when trying to change sharing settings < https://launchpad.net/bugs/1081131 > [15:12] czajkowski, yes, was just looking at that. I agree with abentley's assessment above. we need to ensure we don't show the edit icons to the wrong folks. [15:12] czajkowski, but it does sound like we already block the action, per the bug's description/ [15:13] czajkowski, I've traiged it now. [15:13] triaged it even [15:14] grand job thanks folks === matsubara is now known as matsubara-lunch [15:15] new title to make it clearer, too. bug 1081131 [15:15] <_mup_> Bug #1081131: +sharing should not show edit icons if you don't have launchpad.Edit < https://launchpad.net/bugs/1081131 > [15:40] deryck: or abentley either of you have a sec to review since I'm OCR? I'm particularly want to make sure I'm saying that the ProjectGroup part is correct. https://code.launchpad.net/~rharding/launchpad/filter_more_products/+merge/135164 [15:40] rick_h: I can have a look. [15:40] abentley: thanks [15:48] rick_h: You are right about ProjectGroups. [15:49] abentley: ok cool. The use in top_projects had me thinking I was missing a connection that I would allow leakage through [15:49] rick_h: Where possible, I've been updating APIs to accept a user parameter, rather than using ILaunchBag.user. Have you looked at that option? [15:50] abentley: no, I didn't look. I'll chase it up to browser and see if I can add the user [15:50] cargo culting usage fml heh [15:50] rick_h: If you could, that would be great. [15:51] abentley: rgr, makes sense now that you say it === matsubara-lunch is now known as matsubara [16:13] rick_h: Could you please review https://code.launchpad.net/~abentley/launchpad/proprietary-karma/+merge/135188 ? [16:14] sinzui, I'm about to head out to lunch, but would love to catch some voice time with you after that if you have time. [16:14] abentley: sure thing [16:14] rick_h: Thanks. === al-maisan is now known as almaisan-away === deryck is now known as deryck[lunch] [16:31] abentley: r=me, I bow before your storm-fu turning the manual sql into storm [16:31] though ugh at reading it [16:31] rick_h: was a multi-step process, and I had to check with curtis about the meaning of the original. Do you think I should try to clean up the storm version more? [16:33] abentley: I think it's just more I can read sql ok. So no, I think it's ok [16:33] as is [16:34] rick_h: Okay. Thanks for the review. === yofel_ is now known as yofel === Ursinha-afk is now known as Ursinha === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: rick_h | Firefighting: - | Critical bugs: ~180 [17:40] abentley: I'm looking at trying to update the usage to include the user in the call but hitting a TAL wall: https://pastebin.canonical.com/78762/ [17:40] any idea or example where the method in the TAL gets a parameter passed in? [17:40] I'm bzr grep'ing through but not coming up with an example I can see [17:44] rick_h, We don't want python in tal. It is difficult to test [17:44] rick_h, add a helper to the view to call the context with the user [17:44] sinzui: yea, I'm thinking of punting on the suggest for my branch tbh. It's just going to be a giant pita to make user a param to the changes [17:44] rick_h, or ... [17:45] * sinzui looks for cheat code [17:45] sinzui: because doing that I hook the portlet to the view [17:46] which I guess is ok since it's the one use but that seems dirty as well [17:47] rick_h: is this so you can get user in that method to do the privacy filter? [17:47] rick_h, we have several cases where the mode must have a user, but the callsite will not pass it. The code will get the current request to find the user. maybe [17:48] request = get_current_browser_request() [17:48] user = request.user [17:48] you can also get the user from the launchbag, can't you? [17:48] oh, it is person = IPerson(request.principal) [17:48] jcsackett: yea, that's what I did but the suggestion was to avoid it [17:48] rick_h: ah. [17:48] so trying to figure out the best way to replace the launchbag with direct calls because hte usage is in a portlet .pt [17:49] yeah, the launchbag is used too much [17:49] I think sinzui is right. The best thing is to add a helper on the view, but then it's ugly because the portlet is making the view api change === deryck[lunch] is now known as deryck [18:29] abentley: ok, comment added. Updated one of the 3 change points. === rick_h changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~180 === gary_poster|away is now known as gary_poster [21:55] deryck: are you around, and can you review https://code.launchpad.net/~jcsackett/launchpad/404-project-milestones-privacy/+merge/135252 [21:55] jcsackett, yes and yes :) [21:55] deryck: awesome. thanks! [21:55] jcsackett, on call now but will look shortly [22:01] deryck: works for me. [22:31] wgrant, StevenK: https://pastebin.canonical.com/78751/ [22:34] http://launchpadlibrarian.net/122750088/qxTB0SY4SJMb6haWptIok9Gyind.txt [22:41] StevenK, https://bugs.launchpad.net/launchpad/+bug/665307 [22:41] <_mup_> Bug #665307: cronscripts/expire-bugtasks.py fails trying to put backtrace in librarian < https://launchpad.net/bugs/665307 > [22:45] webops: The NDT r16286 deployment is done, can you move it to Past Deployments? [22:45] wgrant, StevenK: https://bugs.launchpad.net/launchpad/+bug/687446 [22:45] <_mup_> Bug #687446: process-mail dies on malformed email addresses

< https://launchpad.net/bugs/687446 > [22:47] jcsackett, r=me === matsubara is now known as matsubara-afk [22:52] deryck: Awesome, thanks. [22:52] jcsackett, np. sorry it took me so long. had back to back calls. [22:55] good night, everyone. [22:57] StevenK: I had trouble finding your ping again ... that NDT is moved in productionstatus [22:58] BAH, wrong window after all, too. [22:58] slank: Thanks