[00:01] wgrant: Bwahahaha [01:37] * StevenK stabs buildbot [01:50] wgrant: Maybe you are the monitoring :) [01:50] I'm contemplating writing a vagrant script for LP. [01:50] So that it spins up a virtual machine in one command. [01:51] Because I'm lazy. [01:51] StevenK: A local python job posting wanted "experience with Launchpad" [01:55] Haha [01:55] I was tempted to apply and ask if my "experience" was sufficient ;-) [02:04] nigelb: elliot wrote one. [02:04] lifeless: oh. Is it around somwhere? [02:05] dunno [02:14] lifeless: around? Want to check on the info I should be looking into with rt combo loader/convoy? [02:16] -> ops [03:46] nigelb, lifeless: the vagrant script I wrote didn't actually bring up LP, it was when I was experimenting with the microservice stuff [03:46] some good docs here though https://speakerdeck.com/u/mitchellh/p/develop-and-test-configuration-management-scripts-with-vagrant [03:47] ah! [03:49] StevenK: around? [03:57] nigelb: in NZ now? [03:57] statik: o/ wotcha. Off the boat now? [03:59] lifeless: not yet :) [03:59] I hope I get to NZ in time for kiwipycon. [04:02] cool [04:02] I might get to entertain you then :) [04:02] I heard :) [04:03] wallyworld_: Was noming. What's up? [04:03] StevenK: i think there's a 2nd issue with the change to bug info type in the privacy portlet but i wanted a 2nd opinion [04:04] the issue is that we are now calling the transitionToInfoType api directly [04:04] but previously the view would have been used via a post [04:04] and the view would have published a change event [04:04] but we don't do that now [04:04] and in fact, the non js version does use the view so does do the event [04:05] am i missing something? [04:05] Which event? [04:05] ObjectModifiedEvent [04:05] That should be fired via the JS calls transitionToInformationType over the API [04:06] i couldn't see where in transitionToInformationType it was fired [04:06] It isn't [04:06] It's done in the LAZR machinery [04:06] oh, so the api layer fires the event? [04:06] Yah [04:06] ah, ok. makes sense now. thanks [04:07] i didn;t realise the lazr stuff didi that [04:07] lifeless: yep, back in real life, finishing up an 18-hour first day on the new job :) [04:07] enjoying it ? [04:07] wallyworld_: Neither did I, until I figured out why the heck I was getting two visibility change events for a bug. [04:07] yeah man I love the firehose feeling at the start of a project [04:08] StevenK: ah yeah, i do recall that now [04:13] * StevenK stabs buildbot and sets it on fire. [04:14] statik: nice. And you said it was rails ? [04:15] building [04:15] ETA in [04:15] ~ 6 hrs 53 mins [04:15] heya statik! [04:16] Really, buildbot? REALLY? [05:05] Why do I get the feeling Launchpad is not playing nice with my virtualhosts [05:09] wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/no-proprietary-multi-pillar-bug-vocab/+merge/113149 [05:11] StevenK: do you need both context and IBug.providedBy(context) or does providedBy error on being passed None? [05:12] wallyworld_: IBug.providedBy(None) returns False, so I'll drop the first bit [05:12] StevenK: i'd replace 'PROPRIETARY' in the test by InformationType.PROPRIETARY.value or whatever the correct expr is [05:13] wallyworld_: How? It isn't there! [05:13] I'm trying to look it up by the token [05:13] sure but you can get the token from the enum [05:14] wallyworld_: The existing test for proprietary_information_type.disabled uses PROPRIETARY [05:14] you mean 'PROPRIETARY' with the ''? [05:14] Yup [05:14] ok then [05:15] StevenK: i'd also simplify the if statement for the proprieryary_allowed, i don't think it adds much value having 2 booleans [05:15] wallyworld_: We need them. The first one is backed onto the feature flag [05:16] It will be simplified when proprietary_information_type.disabled dies [05:16] so why no 'if not proprietary_disabled and IBug.providedBy(context)....' [05:16] not [05:16] Oh [05:16] I get it [05:17] just a thought since it's verbose with the extra boolean and it reads ok without i think [05:18] wallyworld_: http://pastebin.ubuntu.com/1072538/ [05:18] It reads better against -r submit:, but meh [05:19] i think it's not quite right? [05:19] The test passes [05:20] ah, i missed the () around the 2nd bit [05:21] I'm looking forward to display_userdata_as_private.enabled dying, the vocab will shrink in the wash remarkably. [05:21] i think it will read better without the (). if not proprietary_disabled or not IBug.providedBy(context) or len(context.bugtasks) < 2 [05:22] wallyworld_: That will cause PROPRIETARY to leak [05:22] it's meant to the equivalent to your condition, but with the () removed [05:23] i think i have an or where i want an and [05:23] whatever works [05:24] wallyworld_: So I'm going to need brackets anyway, since there is a line break in the middle [05:24] yeah, maybe put the () bit on the second line [05:24] so it's all together [05:24] if not proprietary_disabled and not ( [05:24] IBug.providedBy(context) and [05:25] Sigh [05:25] IBug.providedBy(context) and len(context.bugtasks) > 1): [05:25] That will likely cause wgrant to murder me. [05:26] if not proprietary_disabled and [05:26] not(....) [05:27] whatever you feel is best, i don't mind [05:28] r=me anyway [05:29] wallyworld_: Did you notice me fixing your test? :-) [05:29] oh, didn't realise it was my test. thans :-) [05:29] wallyworld_: I thought test_vocabulary_items_project was yours [05:30] it may have been [05:30] probably was [05:30] i just can't recall right at the moment [05:30] my head is stuck in info type js mollasis [05:31] StevenK: Wrong [05:32] StevenK: The bugtask count isn't relevant -- it's the number of distinct pillars that matters. [05:32] wgrant: Ah, so I need .affected_pillars [05:37] wallyworld_: http://imgur.com/gallery/L29C6 [05:38] StevenK: lol. i had heard about a google streetview car crashing === matsubara-afk is now known as matsubara [05:49] wgrant: http://pastebin.ubuntu.com/1072565/ is more to your liking? === Guest65630 is now known as Ursinha === Ursinha is now known as Guest68258 [06:15] StevenK: Something like that, yeah [06:17] ssl.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol [06:17] zsh: exit 1 ec2 land --no-qa [06:17] Blink [06:32] Someone please approve this: https://code.launchpad.net/~huwshimi/launchpad-news-wordpress-theme/hold-me-back-im-fixing-the-type/+merge/113159 [06:35] * huwshimi is ducking out for a minute, will be back later [07:17] good morning === gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugs: 4.0*10^2 [09:00] gmb: where was yellow's launchpad kanban updating script? [09:01] mgz lp:lp2kanban. [09:01] ta [09:09] maxb: gmb morning [09:09] Morning czajkowski. [09:11] gmb: hows things up north [09:11] is it grimm and wet like London :/ [09:12] czajkowski, That's what we call "summer" [09:12] But I can spot a teeny tiny bit of blue sky [09:12] So all is not lost. [09:18] czajkowski: a bit grey today, I suppose, but Saturday was lovely at least :-) [09:18] maxb: lets hope it's nice this Saturday too :) [09:28] gmb: you're on-call today? I think mgz has 3 nice-and-tiny branches up for review if you feel like starting off easy [09:30] jam, I'll take a look presently. Thanks for the heads-up. [09:30] (I'm trying to see if I can get a clean run on precise today on my desktop, we're pretty close) [09:30] Awesome [09:30] well, it won't happen *today* given the commit queue, but something like that. [09:31] jam Incidentally, when run in parallel, I said we only ran 1800 tests. That's not true; it's just that buildbot only _reports_ that many tests. We ran 18,000. So the stream is broken again somewhere. [09:31] Haven't had chance to try looking into it yet though. [09:31] gmb: joy... but i'm glad to hear that the test suite is running without hanging/etc. [09:31] Indeed [09:32] reminds me, I haven't checked what subunit does with NUL characters yet [09:32] I don't think it minds. [09:34] binary safe stream [09:34] particularly if you are using the chunk serialiser [09:34] (which LP is) [10:36] mgz, Approved all your branches. [10:38] ta... will have to create these cards in the next lane then :) === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb, rick_h | Firefighting: - | Critical bugs: 4.0*10^2 [10:50] * gmb -> afk for an appointment [10:50] gmb, hi, I wonder if you can please ec2 submit https://code.launchpad.net/~danilo/launchpad/bug-1000642-drop/+merge/112306 for me (stub submitted it but it seems to have failed with something unrelated to the branch: https://pastebin.canonical.com/69307/) [10:50] damn, bad timing :) [10:50] danilos: I can take a peek [10:50] rick_h_, thanks === matsubara is now known as matsubara-afk [11:02] danilos: ok, off to ec2 land [11:10] rick_h_, ta [12:32] gmb,rick_h_: Might an OCR be able to have a look over https://code.launchpad.net/~cjwatson/launchpad/queue-api-readonly/+merge/113202 ? [12:32] Extracted from a previous much bigger branch. [12:32] cjwatson: looking up [12:32] Still 920 lines, oops, I thought it would be a bit shorter than that. [12:34] I can split it up further if I have to. This seems like a fairly reasonable logical chunk though. [12:34] ok, will take a peek. I'll feel better knowing it could have been worse :) [12:35] The original was 1647 [13:27] cjwatson: r=me with two points to bring up [13:30] rick_h_: Thanks. Do you think len() is preferable there then? It was within the same object so I figured the "privacy" (insofar as Python has any) didn't matter. [13:30] cjwatson: yea, especially since you changed the other cases, it's one part consistant at that point as well [13:30] len(self.sources) will involve constructing a concrete list, although maybe that doesn't matter since it's short and will be cached. [13:31] I guess when I wrote the point I initially wondered if you were doing that to avoid the cache [13:31] but then didn't seem like it so figured if you were going to use/go through the cache everyone should [13:31] Fair [13:32] to avoid one method saying one thing "there's 2 here" but the cache not saying that [13:32] #245 was a drive-by what-I-thought-was-a-bug-fix, but I can't prove off the top of my head that it's correct so how about I just drop it - it's not required as part of this branch [13:32] not that I see a bug with mix matched results/etc but just letting you know where my brain's at reading it [13:32] Yeah [13:33] yea, sorry I'm just not all a pro enough at this and chaning r/o on stuff makes me want to find a list of people writing to it to make sure no one is [13:33] Not a problem [13:34] adeuring, https://plus.google.com/hangouts/_/3ac5f6358bc446e2018dedac8a0d188891410910?authuser=0&hl=en === benji___ is now known as benji [14:52] rick_h_: could you please review this MP: https://code.launchpad.net/~adeuring/lazr.jobrunner/bug-1015667/+merge/113228? [14:53] adeuring: sure thing [14:57] abentley: didn't you do some magic to look at the queue payload without pulling it out of the queue? [14:59] rick_h_: Yes, you basically just read the queue without confirming that you've read the messages. It's the core of from lazr.jobrunner.celerytask import list_queued, and abel's already looked at it. [15:00] ok, so my thing with this is that the function is called 'inspect-queue' which seems innocous, but it clears things. [15:00] should it stick things back on the queue? [15:01] rick_h_: well... the fact that the messages are gone can be a positive side effect [15:01] in our case [15:01] right, I understand in our use case, but I'm looking at this from the outside as someone who gets this package and tries to use it [15:02] would clear-queues be better? [15:02] at least then someone coming along would be a bit more hesitant to run the command [15:02] rick_h_: ok, makes sense [15:04] adeuring: ok r=me with naming clarification. Thanks. [15:04] rick_h_: thanks! [15:04] rick_h_: It's mystifying to me that drain_queues(retain=True) doesn't work, but abel says it doesn't. [15:05] abentley: yea, I'm not tinkered with any of this so taking that stuff at face value as far as review goes. [15:11] abentley: is there some way to tell what the local branch name was from a branch pushed to LP? [15:12] rick_h_: The branch nick in the revisions defaults to the last component of the path. [15:13] right, but I pushed it to a manual name and don't have that branch locally so I must have messed up and been on an existing branch [15:13] now in the confusion can't tell where the changes I made yesterday are :/ [15:14] rick_h_: Pushing it up to a manual name is not going to change the branch nicks in the revisions. [15:15] rick_h_: could you take a look at this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-921901/+merge/113234 [15:15] rick_h_: "bzr log --long -l1 lp:$BRANCHNAME" should tell you the last path component of the branch. [15:15] ty much abentley [15:23] ivory: I'm not following the bug that you're fixing here. When I look at the current live site, the tag links match what the bug says they should. [15:24] ivory: what was the difference in the generated urls you altered? [15:27] rick_h_: as i understand it they should link to a project group [15:28] ivory: so I'm seeing: http://pastebin.ubuntu.com/1073255/ [15:29] the only difference I can see is there's a trailing / in the "Should be" urls [15:31] rick_h_: thats weird because i'm at launchpad/+bugs/... if i click on a tag [15:31] instead of launchpad-project/+bugs/... [15:32] oh oh ok, I was looking at the tags in the sidebar, not in the buglisting themselves [15:32] I don't have those enabled by default in my buglisting so missed the reference. [15:33] ah ok i should have said that they must be enabled [15:34] naw, my fault "bug column tags" should have been my clue [15:34] thanks, anyway, reviewing right now :) [15:35] ivory: r=me [15:48] rick_h_: another review. please: https://code.launchpad.net/~adeuring/launchpad/bug-1015667/+merge/113245 [15:49] if ! tmux has-session -t coms; then tmux new-session -s coms -n email -d mutt \; new-window -n irc -d "ssh db" [15:49] fi [15:49] adeuring: on it [15:49] oops [15:49] rick_h_: thanks! [15:53] adeuring: r=me [15:53] rick_h_: thanks again! [16:31] hi,all [16:31] I am installing launchpad in my local envirenment [16:32] now everything works well except for mail serivces [16:32] all mail are send to localhost [16:32] so the user can not receive any mail notifications [16:33] i have installed postfix and mailman [16:33] and i can send mail by using the CLI mail tool [16:33] can any one help me on configing mail === matsubara-afk is now known as matsubara [16:43] any one? [16:49] yaguang, the development instance is not designed to send out emails [16:50] yaguang, Lp distributed version is for testing and development so it is does not provide the entire Lp stack and configuration needed to run for production use. [16:50] so if I like to deployment a local launchpad just the same as https://launchpad.net [16:51] shouldn't I use a development branch ? [16:51] is it ? [16:52] I think this is just a config issue, but I do not know what must be set. yaguang the files under lib/canonical are not free. You need to replace the images to run the instance for any non-testing use [16:52] yaguang, everything under lib/lp is free to change and distribute [16:53] thanks [16:54] now I see all mail is send to localhost [16:54] yaguang, There are 2 kinds of config in each dir under ./configs [16:55] the zcml sets up zope services, of which mail might belong. there is also a -lazr.conf file that sets most of the host names and certainly knows about email [16:57] the mail header now is like this [16:57] From root@localhost Fri Jun 29 05:42:06 2012 [16:57] X-Original-To: root@localhost [16:57] MIME-Version: 1.0 [16:58] Content-Type: text/plain; charset="utf-8" [16:58] Content-Transfer-Encoding: quoted-printable [16:58] Date: Fri, 29 Jun 2012 05:42:04 -0000 [16:58] From: Launchpad Bug Tracker <21@bugs.launchpad.sinasws.com> [16:58] To: freedomhui@gmail.com [16:58] Reply-To: Bug 21 <21@bugs.launchpad.sinasws.com> [16:58] <_mup_> Bug #21: "Display Settings:" "untranslated" shows translated entries < https://launchpad.net/bugs/21 > [16:58] Sender: bounces@canonical.com === deryck is now known as deryck[lunch] [17:47] jcsackett: heh so spoke too soon, these tests in test_distroseriesdifferences are going to need some updates for wait()/timing issues. === Ursinha is now known as Ursinha-lunch [18:04] rick_h_: well damn. [18:04] jcsackett: just a heads up since you were asking about it. I've filed an XXX and will try to get back to it, but a bit much atm. [18:12] dig. === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugs: 4.0*10^2 === deryck[lunch] is now known as deryck === matsubara is now known as matsubara-afk [20:51] jcsackett, do you have time for a talk? [20:52] sinzui: sure. give me a moment to find a google+ compatible device. :-) [21:00] sinzui: had a few flubs, hangout started now [21:01] * sinzui no see you [21:01] it's telling me you're not online. [21:02] * sinzui restarts [21:03] Well I see a whole lot of black screen after I joined your hangout [21:03] huh. [21:03] i'm not even in a hangout now. [21:03] * jcsackett bummed that in the 21st century video chat still involves so much faffing about. [21:03] I just got that message [21:04] create another hangout and I will poll for it [21:06] ok. [22:04] wgrant: sinzui: http://people.canonical.com/~ianb/enhanced-newteam-picker.png [23:42] Hi, on https://dev.launchpad.net/Running/LXC it says that the usage of 12.04 is highly adviced, however the command to create the lxc container has lucid and not precise in it, is this a mistake ? [23:45] The host should be precise, the container should be lucid [23:45] StevenK: could you tell me why the container is best to be lucid ? [23:45] Because the production environment of Launchpad is still lucid for the time being. [23:46] I see, perfect [23:52] wgrant: Getting confused -- I want to check getUtility(IAccessArtifactGrant).findByArtifact([self], [user]) , or am I missing something? [23:53] wallyworld_: Your QA for r15542 is up. [23:54] StevenK: That will check artifact grants for that user, ignoring team memberships and policy grants. It is useless for access checks. [23:56] wgrant: I couldn't figure what the heck IBug.userCanView() was calling, I got to bugtasksearch and went cross-eyed. [23:57] StevenK: get_bug_privacy_filter [23:58] Ah [23:58] You can see what the job does. [23:58] I am for some reason not able to login to the newly created lxc container, not with ubuntu ubuntu or my regular login (which I get from ldap), is this normal ? [23:59] Bert_2: lxc-create copies the system user across by default. If it has no local password that's probably not going to work well.