[00:19] Anyone know where the the text that was in http://goo.gl/O4CQ4 went to? [00:19] (as in, where I might find it now) [00:54] wgrant: Hmmm, my pdb isn't firing. [00:56] StevenK: Where is it and why isn't it firing? [00:56] wgrant: http://pastebin.ubuntu.com/1203852/ [00:59] StevenK: Oh, right [00:59] StevenK: That view isn't /+archivesubscriptions/$ID [00:59] It's ArchiveSubscription:+index or so [01:01] team_sub, '+index' doesn't fire it either [01:27] Oh, bah, ArchiveSubscription:+index is the edit view [01:38] wgrant: I think this is a race. [01:38] wgrant: They all back onto IArchiveAuthTokenSet.getActiveTokenForArchiveAndPerson() [01:40] So when the guard checks, self.active_token is an EmptyResultSet, then IArchive.newAuthToken() is called, and when it calls the same method, it returns a token and raises [01:45] s/an EmptyResultSet/None/ [01:47] StevenK: But it's not a unique violation from the DB, is it? [01:48] wgrant: No, it's newAuthToken raising it === Ursinha is now known as Ursinha-afk [01:49] StevenK: Each appserver transaction sees an isolated snapshot of the DB [01:49] StevenK: If newAuthToken can see it in the DB (and not by a unique constraint violation error), then it's not a race [01:49] The appservers are not READ COMMITTED [01:49] wgrant: Both the view's self.active_token and IArchive.getAuthToken() back onto the same method [01:49] So I don't get how it could return None and then a token [01:49] wgrant: StevenK: sinzui: are we supporting embargoed specs for private projects? [01:49] wallyworld__: IMO no, but it seems like we are [01:50] i'm reviewing a branch which has them [01:50] There's already code landed that permits them [01:50] So don't block this on that [01:50] ok [01:52] wgrant: Can you think of a scenario? Because I can't, but it happens. :-( [01:53] I think it's coming out of the need for Private Projects to have public, embargoed, proprietary options [01:53] all of the apps will get default apps that match the project ootb I believe [01:53] Why? Embargoed is special [01:53] Public and Proprietary sure, sounds good [01:53] The debate over whether Embargoed makes sense for a project is still raging [01:53] because it's strange to have a new project setup with one option and see something you didn't select somewhere else [01:53] right [01:54] agreed, so easier to take it into account and remove than to fit back in [01:54] If Embargoed makes sense for a project, then it makes sense for blueprints [01:55] but if you stick to the idea that embargoed imples one day being public while proprietary does not, then it seems there's a niche for it [01:57] Other way around [01:58] StevenK: huh ? [01:59] StevenK: No, rick_h correctly portrays the other side of the argument [02:00] That Embargoed should also be used for Proprietary stuff that may become public [02:00] I tend to disagree [02:03] But there are reasonable arguments both ways [02:03] wgrant: So I can't think of how to write a test for this issue, and you rejected my current fix. [02:05] StevenK: can you link me back to an oops? [02:05] wgrant: https://oops.canonical.com/oops/?oopsid=OOPS-3607c5f44e382d14bd9ff678dbc51097 [02:05] Suppressing an exception when we don't know why it happens is a good reason to reject a fix :) [02:05] StevenK: Do you have a recent one? [02:06] Or maybe that URL is just bad [02:06] That was the most recent one I could find, I can re-grep on neem if you wish [02:06] Because it's not there any more [02:06] Oh, sigh [02:06] I even mentioned it in a bug [02:07] Yeah, 2012-09-10 has been deleted [02:08] it shouldn't have pruned then ! [02:08] Well, it did [02:08] ugh [02:08] I bloody hope it has turned up again, because that was the only OOPS we had [02:08] Wait [02:08] -10? [02:09] That's not yet 5 days old [02:09] Is the pruning threshold like 2 days now or something>? [02:09] drwxr-xr-x 2 oops_tools oops_tools 2.1M Sep 11 10:28 2012-09-06 [02:09] drwxr-xr-x 2 oops_tools oops_tools 704K Sep 14 02:07 2012-09-11 [02:10] didn't we lower it when we had that huge batched? [02:10] may not have been re-raised [02:10] In either case, I linked it to a bug and it pruned it [02:11] StevenK: You may have linked it while the prune was happening [02:11] It can take a while [02:11] It worked this morning while I was on the call [02:13] Mysterious [02:13] prune.log is modified at 11:41 today [02:13] The last line in the log: [02:13] INFO:root:Querying OOPS references on auditorclient from 2012-09-10 01:40:01.689000+00:00 to 2012-09-11 01:40:02.192021+00:00 [02:13] I wonder if it's pruning to -3 days [02:14] And it also only looks at references up to -3 days [02:14] Hee hee [02:14] Yes [02:14] That explains a bit [02:14] * StevenK can't convince his browser to show him the cached copy either [02:15] prune_until = datetime.datetime.now(utc) - one_week [02:15] references = finder.find_oops_references( [02:15] prune_from, prune_until, options.project, options.projectgroup) [02:15] (I suspect one_week may be cowboyed) [02:16] right, it only needs to look at references made after the oops was created [02:16] Right, it pruned the only ArchiveSubscriptionError OOPS we had. [02:16] Which is just awesome. [02:16] lifeless: Right, but it also only looks at references made until the pruning threshold [02:16] lifeless: The start bound is correct [02:16] The end bound shouldn't exist [02:17] wgrant: oh, should be now() ? [02:17] Right [02:17] wgrant: probably a bad cowboy [02:17] hloeung: yo [02:17] lifeless: No, it's in trunk [02:17] My paste was from trunk [02:17] hloeung: unping [02:17] wgrant: dow; can has fix ? [02:18] Confirmed that neem has one_week cowboyed to be days=3 [02:18] So this explains it [02:18] I wonder how many other OOPSes have been pruned that were referenced [02:19] Not too many [02:19] Anything referenced within 24h should be safe [02:30] So I'm guessing I should find something else to work on [02:31] Since we don't understand what caused it, and the only OOPS we had has been deleted. [02:36] Hi StevenK, wgrant — can I bounce a problem & solution for format-imports off you? [02:36] format-imports doesn't have problems, only bad input [02:37] Sure [02:38] StevenK: then try "from . import foo" :) [02:38] Blows up. [02:38] Use imp for that [02:38] imp? [02:39] http://docs.python.org/library/imp.html#module-imp [02:40] Why use imp for that? [02:40] What William said. [02:41] jtv: Django uses imp in it's manage.py [02:41] Not a reason in itself. It also doesn't believe in database transactions. :) [02:41] well [02:41] so . is definitely local [02:41] format-imports just needs to be taught [02:42] That's what I just did. [02:42] In a nutshell: the first level of an import is either an identifier, or a series of dots. [02:42] (Previously: just an identifier) [02:42] And I list "." as one of the known local packages. [02:43] Still leaves ".." wide open, but watch me not care. [02:45] Any objections to that solution? I'm implementing it in MAAS, but since the script was copied from LP, I'd like to share the fix. [02:46] seems fine, I'd like that. [02:46] StevenK: "its" [02:46] Would MAAS use the script if it was in lp-dev-utils ? [02:46] or would it still want a local copy ? [02:47] Thank you bigjools :) [02:47] jtv: I knew you'd be itching after reading it too [02:47] I was so proud of suppressing it. [02:47] haha [02:47] lifeless: lp-dev-utils sounds like a better place. [02:48] jtv: is there any delta between the scripts ? [02:48] But maybe that's a separate issue; this is really just a distraction for me so I'm very much looking for a quick fix. [02:48] * jtv checks [02:48] jtv: if so, could it be made into data - a config file or something ? [02:48] jtv: yes, it is a separate issue. [02:49] There are several isolated changes. :( [02:50] Changes the MAAS version makes compared to the LP version: http://paste.ubuntu.com/1203983/ [02:51] One of those is a typo fix in LP; the rest looks like modernizations in the maas version. [03:22] hm, where has Y.lazr.activator.Activator gone [03:23] lazr is gone gone gone [03:23] yeah i saw that commit [03:24] it broke my greasemonkey work item editor :) [03:24] lp.ui.activator [05:12] wgrant: Re: bug 966205, do you think it's sensible to delete all logintoken's on merge? [05:13] Bug #966205 [05:13] Oh right [05:13] That one [05:13] Private [05:14] I'd just delete them all, yeah [05:22] purple, I have to run, C stuff; perhaps one of you could help #newbie in #bzr [05:24] * StevenK tries to find the person merge tests [05:26] wgrant: https://pastebin.canonical.com/74532/ [05:35] StevenK: There's no action there [05:36] I thought it POST'd to the same URL [05:37] Right [05:37] But I see no POST to the same URL [05:39] Odd, since there was POST, the OOPS had it. [05:39] What did you grep for? [05:40] ~thomas-guest/+archivesubscriptions/39008/+index [05:40] Why +index? [05:41] That wouldn't normally be there [05:41] It obviously was, there was three matches [05:41] None of which we were looking for [05:41] So I'd drop the trailing /+index [05:55] wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-logintokens-on-merge/+merge/124338 [05:56] * wallyworld__ sad, conflict ahead [05:57] wallyworld__: Oh? [05:58] person-merge.txt - it's being nuked for new unit tests [05:58] for a bug i'm ficing [05:58] yay django [05:58] File "/home/robertc/source/launchpad/oops-tools/working/eggs/Django-1.4-py2.6.egg/django/contrib/auth/management/__init__.py", line 85, in get_system_username [05:58] return getpass.getuser().decode(locale.getdefaultlocale()[1]) [05:58] TypeError: decode() argument 1 must be string, not None [05:58] wallyworld__: That's awesome, and sorry [05:58] StevenK: no problem :-) [05:58] no need to apologies [05:58] bah, can't type [05:59] wallyworld__: You aren't fixing the linked bug? [06:00] no, i checked :-) [06:00] i'm fixing 1019975 [06:00] bug 1019975 [06:00] <_mup_> Bug #1019975: AttributeError: 'NoneType' object has no attribute 'displayname' requesting people merge < https://launchpad.net/bugs/1019975 > [06:01] fix is easy, but adding a test is a pain until i convert the doctest [06:03] wgrant: 3 out of 4 appserver logs grepped, waiting for gac [06:12] grah [06:13] wgrant: in your lxc travels, did you see lxc choosing POSIX as the locale, no matter what /etc/environment and /etc/default/locale say ? [06:17] StevenK: Great [06:17] lifeless: I don't believe so [06:17] By POSIX you mean C? [06:17] no [06:18] robertc@lucid-test-lp:~$ locale [06:18] LANG= [06:18] LANGUAGE= [06:18] LC_CTYPE="POSIX" [06:18] ... [06:18] LC_IDENTIFICATION="POSIX" [06:18] LC_ALL= [06:18] Well that's odd [06:18] I have en_AU etc available [06:18] language pack en base installed [06:18] I could understand C [06:18] But POSIX is a bit odd [06:18] lifeless: Not en_NZ? :-) [06:19] of course, my environment outside of LXC is latin and klingon [06:19] StevenK: habits. [06:19] lifeless: tlh_LA ? :-) [06:19] robertc@lifeless-64:~$ locale [06:19] LANG=en_AU.UTF-8 [06:19] LANGUAGE=la_AU:tlh_GB:tlh:en [06:20] Oh [06:21] $ LANGUAGE="en_US:en" LANG=en_US.UTF-8 ssh -A -X lucid-test-lp.local [06:21] Last login: Fri Sep 14 06:21:22 2012 from lifeless-64.local [06:21] robertc@lucid-test-lp:~$ locale [06:21] LANG= [06:21] LANGUAGE= [06:22] LC_CTYPE="POSIX" [06:23] lifeless: You haven't changed sshd's AcceptEnv default or something? [06:23] hah [06:23] AcceptEnv LANG LC_* [06:24] *I* did not set that. [06:24] That's normal [06:24] The default [06:24] ... Why is my LANG en_US.UTF-8 ? :-( [06:25] StevenK: Because you're terrible [06:25] Mine is correct :) [06:25] I'm trying to remember where it is set. [06:26] /etc/default/locale, usually [06:26] steven@undermined:~% cat /etc/default/locale [06:26] LANG="en_AU.UTF-8" [06:26] steven@undermined:~% echo $LANG [06:26] en_US.UTF-8 [06:26] thats the same kind of FUNK I'm seeing [06:32] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330500 [06:32] is looking similar [06:32] Yeah, but that one's from 2005 [06:32] If it's the one I just looked at [06:32] And SSH should be overriding that [06:34] ssh was present in that bug [06:34] and message 65 says it still happens [06:34] Hm, true [06:45] wgrant: https://pastebin.canonical.com/74533/ [06:48] StevenK: Right, that makes a bit more sense [06:49] Though the +index bits are suspiciously missing now [06:52] oh charming [06:52] for some reason I've ended up with django 1.4 in my oops-tools setup [06:52] rather than 1.3 which I think it was running [06:53] wgrant: So it doesn't look like a race [06:53] ImproperlyConfigured at /oops/ [06:53] Error importing template source loader django.template.loaders.filesystem.load_template_source: "'module' object has no attribute 'load_template_source'" [06:57] StevenK: Right, as expected [06:58] I knew it couldn't be, but evidence is good :) [06:59] wgrant: So then I should be able to trigger it with a test case. :-( [06:59] StevenK: Yes, if it's correctly set up [07:02] wgrant: But I still don't get it -- both methods back onto IArchiveAuthTokenSet.getActiveTokenForArchiveAndPerson() [07:08] Hmmm [07:10] I wonder if there is a value that date_deactivated can be set to that isn't None [07:20] morning [09:02] good morning === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: ∞ [09:58] hi adeuring, would you have time to review https://code.launchpad.net/~dpm/launchpad/translations-exporter/+merge/124373 ? Thanks! [09:58] dpm: sure, I'll look [09:59] excellent, thanks! [10:56] dpm: You can validate the distroseries by using getUtility(IDistributionSet).getByNameOrVersion() [10:56] I think. [10:56] I'm a little fuzzy on the details [10:56] StevenK, ah, great, will look into that, thanks for the feedback! [10:57] Sorry, getUtility(IDistroSeriesSet).findByName() [10:57] The first one is for finding distributions [10:58] ok [11:17] hrm [11:17] I know there's a bug report about "Can't search for the absence of a bug tag", but I can't find it [11:18] It's not in [11:20] oh, it's bug 81575, Fix Released [11:20] <_mup_> Bug #81575: no way to search for absence of a tag

< https://launchpad.net/bugs/81575 > [11:20] * mpt scours the search form again [11:21] aha, "To search for the absence of a particular bug tag, place a minus sign before its name: e.g. -test" [11:36] dpm: comment sent. Ping me if you have any questions [11:42] dpm: LP "censored" much of the replay. Use the "download full text" link [11:43] thanks adeuring. I can't see any more text in the downloaded text file than the textbox in LP, though. [11:44] dpm: weird... But the mail you'll get sould be complete ;) [11:44] adeuring, hm, the mail has exactly the same text as the textbox and the downloaded link, nothing additional [11:46] dpm: maybe I am too stupid to find all of my own comments in the web browser. WHat I don't see in the web browser is your Python code with some comments from me. [11:46] adeuring, ah, wait, I was missing the inline comments in the diff, sorry, all good, now. Sorry... [11:46] np ;) [11:47] adeuring, thanks a lot for the detailed review. Who should I best talk to to go past the "thou shalt not increase the LOC count for.." step? [11:49] dpm: get some support first (the admins would probably appreciate a cron job, i assume), then talk with flacoste [11:50] dpm: do you know who the team leads are? [11:51] dpm: bigjools, sinzui gary_poster|away jam gmb [11:52] czajkowski,dpm: https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts says "needs a waiver from the LP Project lead or CDO Technical architect " [11:52] i.e. Francis or Robert [11:52] cjwatson: nods [11:54] I'll grant a waiver [11:54] this code already exists in the wrong place [11:55] its not adding debt to move it into LP [11:55] dpm: ^ [11:55] its reducing debt by getting it into the right place. [11:55] :) [11:55] thanks lifeless [11:56] dammit, buildbot is starting to get on my last nerves. === gary_poster|away is now known as gary_poster [12:09] ok, so how did rev 15954 land when it's got a broken test in it I hit in both of my ec2 test runs? /me is so confused [12:12] sinzui: it looks like the doctest cleanup in https://code.launchpad.net/~sinzui/launchpad/mailman-email-addresses/+merge/124273 breaks the doctest because it removes list_four but there's another test using it. Shold that bit just be reinstated ok? [12:13] damn [12:13] yes [12:13] I was going to rewrite that as unittests to day too [12:13] oh well [12:14] how could the change have landed with a broken doctest in there though? [12:17] sinzui: ok, added it back in and test passes, going to submit it as a testfix [12:18] You are a life saver [12:33] It looks like LP has changed where it stores text for some pages now, any idea where the text for goo.gl/O4CQ4 might be located now [12:33] ? [12:38] cjohnston: rather than starting mid sentence, perhaps explainign what you are doing and what is wrong [12:39] cjohnston: lib/lp/blueprints/interfaces/specificationsubscription.py [12:39] Trying to change the text, it's not there.. Based on the conversation I had on the mailing list in the past [12:39] (I grepped for 'Participation essential' and it was the first of a small number of hits) [12:43] thanks cjwatson.. I guess grepping half the sentence was what got me. :-/ [12:48] sinzui: sorry, but I evidently fail. I've tried to submit this with pqm-submit and lp-land and not getting any email/pqm action I can see [12:48] sinzui: can you see if you can push https://code.launchpad.net/~rharding/launchpad/testfix_message_holds/+merge/124405 through lp-land as testfix please? [12:51] okay [12:51] * rick_h__ is about to start tossing things out windows gah! [12:52] rick_h_, I think I have a note about the obscure bzr pqm syntax to submit other peoples branches. [12:53] I had thought that bzr lp-land --testfix --no-qa https://code.launchpad.net/~rharding/launchpad/testfix_message_holds/+merge/124405 [12:53] would do the thing [12:53] but no success or fail email so I'm not even sure I guess that it's getting there [12:53] rick_h_ try this [12:54] bzr pqm-submit -m "[testfix][r=sinzui] Revert doctest." [12:55] * sinzui is watching https://pqm.launchpad.net/ for old-time sake [12:56] pqm saw it [12:57] That it. Today I am taking a torch and pitchfork and raising an angry mob on mailing list doc tests [13:02] yay the pqm gods have accepted my offering [13:02] What sacrifice did you offer? A whale? ;) [13:03] :) [13:03] 10 pqm-submits and a "@$#@$@ you" [13:03] lol [13:15] adeuring: Here is an example where the web UI cannot protect you from entering disallowed values: https://blueprints.qastaging.launchpad.net/specs/+new [13:17] abentley: do you mean that "embargoed" might be undesired/invalid? Or that somebody crafts the POST request manually to send USERDATA or whatever else? [13:18] adeuring: I mean that "embargoed" may be undesired/invalid. [13:18] abentley: anyway, transititonToInformationType() should check that the new value is valid [13:18] abentley: ok, if EMBAGOED is undesired, we should not present it to the user [13:19] adeuring: We don't know that it's undesired at the time we present it to the user. Look at the form. One of the inputs is "target", which is the project or distro. [13:20] adeuring: Where we know it's undesired, we hide it, of course. This is an example where we cannot do that. [13:20] adeuring: (target is listed as "For: The project for which this proposal is being made." [13:21] abentley: ah, sure. But we can (1) add a a warning to "Only shared with users permitted to see embargoed information. " that this might not work, and (b) if the value is selected but not usable, we should show an error. [13:21] adeuring: My point is that we are currently showing an error-- an OOPS. [13:22] abentley: sure, that's bad. But getting undesired data into the DB is bad too [13:24] adeuring: Right, but an assertion due to a missing AccessPolicy is the wrong way to defend against that. [13:25] abentley: the other artifacts raise a dedicated exception [13:25] we can do that too [13:25] for spec [13:27] adeuring: When deryk's code lands, we'll have that. Until then, I don't know if I can QA my code. [13:27] abentley: so what should we do? [13:28] adeuring: There's no way to add an access policy on qastaging, right? [13:28] I don't know [13:29] My guess is: create a product which uses EMBAGOED for bugs too [13:29] adeuring: Oh, yes, that might work. [13:31] rick_h_96, rick_h__ rick who? ping for standup. [13:31] deryck: I'm in there? [13:32] or not... [14:20] deryck, adeuring: private & embargoed blueprints break the front page: https://blueprints.qastaging.launchpad.net/ [14:21] abentley, oh, ouch. that's a bad one. [14:21] deryck: Blocker for the beta? [14:22] seems that we need to filter properly... [14:22] abentley, yes, we should fix that first. but let's make that fix the priority. [14:22] sinzui: i am looking at bug 808952 and wondering, is there any reason we haven't exposed all Message types on the API? [14:22] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments < https://launchpad.net/bugs/808952 > [14:23] abentley, do you want that one next, or shall I? [14:23] deryck: Could you? I'm still on QA. [14:23] abentley, I absolutely can. I likewise am not free yet. Still fixing a couple tests. But when I get free I can take it next. [14:24] jcsackett, we only expose those that are needed. I think this case is differnt though [14:25] jcsackett, Our views can show objects without a canonical url, but the api requires that we define one, and that Lp provide the objects consistently to make the url [14:26] so you think we should update the API to handle situations more like our views? [14:27] no [14:27] I am saying that comments do not match what we put in the zcml [14:27] for="lp.bugs.interfaces.bugmessage.IBugComment" [14:27] path_expression="string:comments/${index}" [14:27] attribute_to_parent="bugtask" [14:27] rootsite="bugs"/> [14:29] jcsackett, I think bug 210821 might be easier to fix. We know the portlet that shows the active project. I think we can walk backwards to find the code that put there [14:29] <_mup_> Bug #210821: bug tracker list shows inactive projects <404>

< https://launchpad.net/bugs/210821 > [14:30] sinzui: fair. === james_w` is now known as james_w [15:00] deryck: I'm done QA for now. Shall I work on the front page query so you can work on the blog post? [15:01] abentley, if you have the bandwidth, I would appreciate that! I'm still fighting trying to figure out why a test is failing too. [15:01] deryck: Okay. I'm also filing a bug and adding a card. [15:02] abentley, I added a red card, but didn't file a bug yet. [15:02] deryck: ack [15:04] deryck: What do you think about hiding Proprietary/Embargoed from the front page entirely, even if you have permission to see them? Would be a simpler fix. [15:05] abentley, I was going to take that approach. simple and naive for now. [15:05] deryck: Cool. [15:05]