=== Ursinha is now known as Ursinha-afk [00:28] sinzui: I think you should just self-review https://code.launchpad.net/~sinzui/launchpad/bad-malone-0/+merge/49325 [00:28] Any ideas where the package input widget being referred to in this comment is? https://bugs.launchpad.net/launchpad/+bug/591274/comments/1 [00:28] <_mup_> Bug #591274: tags field is too small < https://launchpad.net/bugs/591274 > [00:29] huwshimi: On an Ubuntu bug page, click the drop down arrow on the left of a row on the task table. [00:29] eg. https://bugs.launchpad.net/ubuntu/+source/wxmaxima/+bug/43150 [00:29] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect < https://launchpad.net/bugs/43150 > [00:30] wgrant: Cheers mate [00:31] I wish the death-to-ZConfig policy had been seen through to completion. [00:46] lifeless: ping [00:48] mwhudson: ping [00:49] thumper: hi [00:49] lifeless: I've got windmill hung here locally, and I want to debug where it is with gd b [00:49] lifeless: can you help? [00:49] sure [00:49] first thing to try is strace [00:49] it can often be surprisingly informative [00:50] lifeless: assume I'm a dumb code monkey [00:50] strace how? [00:50] ok [00:50] first thing is ps :) [00:50] find out what processes you have [00:50] identify the ones we care about: [00:50] - the python driver [00:51] looking for the one running the windmill test [00:51] - the ff slave [00:52] tim 18086 1943 4 13:43 pts/1 00:00:19 /usr/bin/python2.6 -S ./bin/test --layer=Windmill -vvt TestRecipeSetDaily [00:52] that should be the driver [00:52] that tells it the layer to continue from [00:52] it might be a child of this [00:52] pstree will show [00:53] can I get pstree to show me pids [00:53] ? [00:53] pstree --show-pids [00:53] or -p [00:55] so if this has not spawned another bin/test runner [00:55] then yes, its the one that is hung [00:55] what version of gdb do you have installed ? [00:58] 7.2-ubuntu [00:59] apt-get install python2.6-dbg [00:59] already got it [01:00] gdb /usr/bin/python2.6 18086 [01:00] thread apply all py-list [01:01] and threat apply all py-bt [01:01] Could not attach to process. If your uid matches the uid of the target [01:01] process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try [01:01] again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf [01:01] ptrace: Operation not permitted. [01:01] but the uid matches [01:01] cat /proc/sys/kernel/yama/ptrace_scope [01:02] 1 [01:02] thumper: >= Maverick have security settings to prevent processes from ptraceing each other. [01:02] sudo it. [01:02] ack [01:02] or push 0 into /proc/sys/kernel/yama/ptrace_scope [01:03] lifeless: ok, I've got gdb running and did the thread apply thingies [01:03] pastebin [01:04] https://pastebin.canonical.com/43168/ [01:06] might be slightly useful to get a thread apply all bt [01:06] might be slightly useful to get a thread apply all list [01:06] because we're getting the usual noise around python traces :( [01:07] sinzui: Still around? [01:09] https://pastebin.canonical.com/43169/ [01:09] thumper: ok, so the higher frames are new [01:09] opposite to pdb [01:10] thread one is trying to read from a socket [01:10] ok, so how do you look for value in this? [01:11] thread x to switch to a thread [01:12] frame x to go to a frame [01:12] py-locals for the python locals [01:12] info locals for the C locals [01:13] thread 2 is doing a 0.25 second sleep. [01:13] which is zomg bad programming [01:13] lol, yea I was just looking at that. [01:13] thats in _wsgi_jsorpc [01:13] windmill runs up a server of its own for ff to talk to [01:15] thread 3 is doing nonblocking IO [01:15] inside a socketserver [01:15] which is a little odd. [01:15] at best [01:16] not entirely sure what its about [01:16] but [01:16] perhaps its trying to read the entire request [01:16] and stuck getting it [01:16] we should get the sockets it has open [01:17] thread 4 looks like its the smtp server test harness thingy [01:18] so threads 2 and 3 are candidates for the hang [01:19] I don't suppose we can break a pdb into it? [01:19] I'd like to be able to inspect the python itself [01:20] thumper: pong [01:20] mwhudson: I've got lifeless "helping" me with gdb [01:20] you can tell the process to evaluate some python code [01:20] but its a little hacky [01:20] although I don't feel like I understand much how gdb works [01:21] never been much for command line debugging [01:21] thumper: https://code.launchpad.net/~pygdb-hackers/pygdb/trunk ? [01:22] mwhudson: what does that give me? [01:22] thumper: a back trace [01:22] mwhudson: have those ;) [01:22] mwhudson: live session [01:22] I may have that already [01:22] https://pastebin.canonical.com/43168/ [01:22] https://pastebin.canonical.com/43169/ [01:23] oh yeah, gdb gives you the python code these days [01:23] (unreadably) [01:24] lifeless, Why isn't thread 1 a candidate for the hang? recv is blocking, isn't it? [01:29] thumper: what is fd 20 for this process? [01:29] (lsof -p $windmill_pid i think) [01:30] localhost.localdomain:53395->localhost.localdomain:4444 (ESTABLISHED) [01:32] netstat -tp and look for those ports? [01:32] 4444 is the http server [01:32] is it talking to itself, i wonder [01:32] 53395... looks like thats from Thread 2 [01:33] tcp 0 0 localhost.localdo:53395 localhost.localdom:4444 ESTABLISHED 18086/test --layer= [01:33] and there is one with the other order too [01:33] ugh... no line wrap makes navigating this output disorientating, lol [01:34] ah yeah indeed [01:34] so thread 2 is serving http, thread 1 is trying to read part of the headers from thread 2 and not getting anything? [01:34] potentially [01:35] ok, I'm going to kill everything and get some more work done now [01:35] awwww [01:36] * cody-somerville is having fun. :-( [01:36] and I think we're close to debugging it [01:37] cody-somerville: well, it isn't gone yet [01:37] cody-somerville: if you want more fun [01:38] Would someone be able to point me in the direction of the code which determines whether or not a recipe daily build is needed on a given day? [01:38] mwhudson, I think thread 3 is serving and thread 2 is either the request or the request handler [01:38] thumper, did you ever manage to get a strace? [01:38] Yippie, build fixed! [01:38] Project devel build (433): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/devel/433/ [01:39] cody-somerville: oh right yes [01:39] probably right there [01:39] Operation not permitted [01:39] thumper, sudo su and then try [01:40] sudo strace doesn't work, do I need a root shell? [01:40] thumper: sudo strace does work :( [01:40] getting the same as root [01:40] thats odd. you're on maverick? [01:40] yep [01:41] sudo strace -p works fine for me [01:41] Me too. [01:41] On maverick and natty. [01:41] Hmmm. [01:41] Surely not. [01:41] could it be that gdb is connected? [01:41] Could it be because launchpadlib loads keyring loads gnome-keyring which might forbid ptraceing? [01:44] No. [01:44] It could be that gdb is connected, I suppose. [01:44] An odd errno for that, though. [01:45] only one process can ptrace a process at a time, i think [01:45] so yeah, having gdb attached would break it [01:46] so... most likely a race condition in windmill [01:46] man ptrace says it returns EPERM in this case [01:46] nothing I'm likely to fix today [01:46] mwhudson: That's a bit opaque. [01:47] I would have expected EBUSY. [01:47] wgrant: i guess ptrace comes with a big "we hope you know what you are doing" sticker [01:47] Or something like that. [01:47] detached gdb, strace said: recvfrom(20, ^C [01:47] i don't know how threads and ptrace interact [01:48] If a system call is being executed and meanwhile another one is being called from a different thread/process then [01:48] strace will try to preserve the order of those events and mark the ongoing call as being unfinished. When the call [01:48] returns it will be marked as resumed. [01:48] ah yes [01:48] so if there's no output, then it really is totally hung [01:49] or aren't making any syscalls at least ;) [01:50] yeah, but all threads in the gdb trace were in syscalls, no? [01:51] and if it's talking to itself and one thread is calling recv and nothing is calling write... it could be waiting a while [01:54] * mwhudson wonders how easy it is to write a website that accesses the launchpad api over js [01:54] https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295 anyone? [01:55] Thread 1 is the first thread and is blocked waiting for data - it looks like its waiting for the response to a json-rpc call it made [01:56] looks like its the.... dragDropElemToAbs test its hung onn? [01:56] oh wait [01:56] maybe thats the action its asking to have performed or something [01:57] so, its actually the test_inline_recipe_daily_build test that its hung on [01:59] which happens to be the test thumper is adding in his MP, lol [02:12] cody-somerville: thread 1 is the thing making an http request [02:12] cody-somerville: its trying to read the response [02:12] another way of thinking about this is 'blocking w/o timeout is bad' [02:13] * cody-somerville nods. [02:19] ah [02:23] while not resolution_suite.resolved.get(uuid): [02:23] sleep(.25) [02:23] ^^ that doesn't look so great. [02:26] cody-somerville: so thread 1 might be the cause of the hang [02:26] we should make that call have a timeout [02:26] which wouldn't fix the test [02:26] but it would stop a complete hang [02:34] People who review things: if I want to fix several (fairly minor) bugs relating to a particular thing in launchpad but are unrelated themselves, is it better for you if I use different branches? [02:35] huwshimi: I think the answer is really about the cover letter and the diff [02:36] It's common to stick a few small changes in one branch. [02:36] But if they're intertwined I prefer to split them. [02:36] huwshimi: we often want one branch per change so that both are clear. Several small changes can be in a branch and have a clear diff [02:38] sinzui: Three years ago you added althostnames of 'launchpad' and 'www.launchpad.net' to most non-appserver configs. Do you recall why? Is there a good reason not to just inherit launchpad.net from the global lpnet config? [02:38] Er. [02:38] s/'launchpad'/'localhost'/ [02:38] hi wgrant. Sorry was was away. I did not mean to be, My daughter killed pulseaudio I could not hear [02:38] Haha. [02:38] hi [02:39] speaking of hostname [02:39] AFAICT the machine hostname isn't needed in launchpad.conf [02:39] am I wrong? [02:39] Not even for nagios checks? [02:39] That's my presumption for why they are there. [02:39] wgrant: I really do not recall why I did that. I cannot think of a reason why www in in there [02:40] (the production configs pissed me off for the last time this morning, so I am purging cruft... I will gladly remove the althostnames from the appservers as well as non-appservers) [02:40] lifeless, it sort of looks like it already does [02:41] lifeless, would thread 2 stuck in a loop prevent the timeout from occurring in thread 1? [02:41] sinzui: Non-appservers need *a* hostname. But they get that from lpnet-lazr. It seems pointless to have the others (perhaps they were automatically added?) [02:41] cody-somerville: rarely, it *is* possible though to have a thread spinlock prevent other threads executing in python [02:42] wgrant: sysadmins don't know why they are there [02:42] wgrant: nagios can be told what hostname to use, i'm pretty sure [02:42] lifeless: Probably. [02:42] We should check the nagios config and try cowboying it out on one server, perhaps. [02:42] wgrant: that is certainly possible. The configs were partially built (and separated) by scripts I wrote [02:42] sinzui: That's what I gathered from the somewhat massive and partially insane diff. [02:43] utilities/lsconf is all that renames of those scripts [02:43] remains [02:47] Hrrngh. [02:48] (that's a "why do the production configs inherit production-specific domains from the config schema?" sort of hrrngh, FWIW) [02:48] it looks like thread 2 has added something to a queue to be executed and is now waiting for it be executed... but whats processing that queue? [02:52] * cody-somerville realizes that its now almost 10 and so puts the windmill hang problem away for another day. [03:21] die ec2, die in a fire [03:21] Who has it killed this time? [03:21] no freaking way did I hit ctrl-C after 5 hours of tests [03:22] lifeless: You saw a KeyboardInterrupt around a windmill test? [03:25] mailed the output to you [03:25] I saw no other tests and this was a tobesuretobesure so I'm just landing directly now. [03:25] please don't hate me when this turns out to be a bad idea [03:25] Right. [03:25] I just land directly in that case. [03:26] Windmill tests hang in a subprocess, root process notices lack of activity, root process sigints child. [03:28] * thumper looks up [03:34] AARRGGHHHHH!!!!!! [03:38] :(( [03:42] the lazr.restful 0.16 egg isn't 0.16 [03:42] * thumper is confused [03:42] clucking bell [03:43] * thumper looks for someone to smack around [03:43] thumper, yeah, this was my thing with oauth too: 1.0 != 1.0 [03:44] it seems that the 0.16 tarball was created from a branch of lazr.restful that wasn't trunk [03:44] is there any way to introspect the egg to see what it was created with? [03:46] ok... so how do I make these egg things [03:46] sdist? [03:46] sdist for most things. [03:46] Except bzr. [03:47] And meliae. [03:47] And some other stuff. [03:47] Try sdist. Then diff it with the old one. [03:48] wgrant: it will create a different result, I know that [03:48] wgrant: as it is missing at least two revisions of data [03:48] wgrant: is there a way to add a suffix? [03:48] thumper: I extract the two and diff the trees to make sure they have the same files. [03:48] thumper: Hmmm. [03:48] wgrant: they won't have the same files [03:48] that is the problem I'm trying to fix [03:48] trunk has r171 tagged with 0.16.0 [03:48] I mean more that the tree is roughly the right shape. [03:49] which isn't the revision that made the 0.16.0 egg in our download cache [03:49] oh [03:49] Is it the revision on https://launchpad.net/lazr.restful/+download? [03:51] sinzui: ping [03:51] sinzui: or are you gone? [03:54] wgrant: I don't suppose there is an MD5 hash of it somwhere [03:54] duh [03:54] I see it [03:55] :( [03:56] lp has: 925128c13ada9e7cbb50ae86538c6812 lazr.restful-0.16.0.tar.gz [03:56] download cache has: 9469c4b0081ab0bd8796dc52ee1c2353 lazr.restful-0.16.0.tar.gz [03:56] and my new one is: 7daed9cea664e564386381da320b3519 lazr.restful-0.16.0.tar.gz [03:56] Awesome. [03:56] Diff the trees. [03:56] * thumper sighs... [03:56] Hopefully the first and last are identical, and you can wipe your new tarball from existence. [03:57] 3 tars... fark [03:58] Whatever you do, do not let a third file with that name leave your system :) [03:58] Or people from Ubuntu will hunt you down. [04:00] ok, my one from trunk matches the launchpad one [04:01] so at least that is good [04:01] the download cache one is wrong [04:02] so... [04:02] * thumper updates download-cache [04:06] ok, so I've update the download cache to have the correct lazr.restful [04:06] lifeless: do you know how that'll impact rolling out? [04:07] Did you give it the same name? [04:08] it is the correct 0.16 [04:08] Yes. [04:08] Don't do that. [04:08] so yes [04:08] It confuses things. [04:08] Uncommit, give it a new version number, recommit. [04:08] (dev systems won't ever see the changes in the new, because they have already built 0.16.0) [04:08] :( [04:09] * thumper uncommits [04:09] Just like Debian archives: do not ever use the same version twice, and if you see someone lying about version numbers, slap them. [04:09] do the tarball names need to match the folders on the inside? [04:09] No. [04:09] ok [04:10] You probably need to change the version number in setup.py. [04:10] thumper: it won't impact anything right now [04:10] because we've already cut the tree to deploy. [04:10] but it will impact the nodowntime. [04:10] I think nodowntime will see the new tarball. [04:10] as will qastaging and staging. [04:11] But dev/ec2/buildbot won't. [04:11] * thumper nods [04:12] I've fixed the download [04:12] Hopefully nobody saw the bad rev except me. [04:12] lifeless: if you want to review my daily-ajax, I'll fix the versions.conf in that [04:15] i wonder if we can set a hook on the download-cache branch to reject commits that change an existing file [04:16] Getting distribution for 'lazr.restful==0.16.0-r171'. [04:16] Installing lazr.restful 0.16.0-r171 [04:16] Caused installation of a distribution: [04:16] lazr.restful 0.16.0 [04:16] with a different version. [04:16] Got None. [04:16] with make build [04:16] thumper: Did you change setup.py? [04:16] arse [04:17] no... you didn't say to! [04:17] 15:10:19 < wgrant> You probably need to change the version number in setup.py. [04:17] :( [04:17] er [04:17] versions.cfg surely [04:17] not setup.py [04:17] The tarball is called 0.16.0-r171, but internally versioned 0.16.0 [04:17] I changed versions.cfg, but it seems that it is expecting a differnt directory on the inside [04:17] yes [04:17] oh [04:18] * thumper uncommits again [04:22] * thumper read the scrollback for deryck's magic incantation [04:22] python setup.py egg_info -b-r171 sdist FTW! [04:24] hmm... [04:24] perhaps I'll just submit the right lazr-restful branch directly [04:24] as in, with a self review [04:25] Sounds reasonable. [04:25] * thumper is doing so right now [04:28] lifeless: Can you see any reason not to drop the hostname-based althostnames? [04:29] nagios doesn't use them. [04:29] Normal requests don't. [04:29] I guess haproxy might? [04:29] wgrant: want to review a branch of mine? [04:29] thumper: Sure. [04:30] https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295 [04:30] aaaaaaa [04:30] But OK. [04:31] wgrant: whazzup? [04:31] thumper: JS! [04:31] :) [04:31] there isn't that much actual JS [04:33] * thumper is EODing, but will be back later [04:48] wgrant: we'll stage a test in a bit [04:48] wgrant: I'll remove them using make-appserver.py [04:53] lifeless: They also need to be removed from the non-appserver configs. [04:54] sure [04:59] Does anyone know what I'm supposed to do when making changes to lazr-js stuff for launchpad? Do I need to make a branch of lazr-js directly and wait for the changes to be merged back into LP? [05:00] thumper did that recently. [05:00] But yes, fix lazr-js, then upgrade or get someone to upgrade the Launchpad version of it. [05:01] wgrant: ok thanks. [05:08] poolie: its pretty consistently 50/50 [05:08] poolie: its achieving that at the overcommit level - 4 threads, 4 backlogged requests [05:09] Couple of reviews for someone who is kind enough to do them: https://code.launchpad.net/~huwshimi/launchpad/tag-field-length-591274/+merge/49341 and https://code.launchpad.net/~huwshimi/launchpad/tag-field-space-394342/+merge/49342 [05:10] nice [05:10] lifeless, good to see we're not wasting mark's money having hardware sit around idle ;-) [05:11] huwshimi, can has screenshots? [05:11] poolie: Of both? [05:11] yeah [05:11] poolie: coming up [05:11] i have this not-well-substantiated theory that attaching screenshots will be a cheap way to get better ui oversight [05:12] (or more bikeshedding :-) [05:12] poolie: Well the tag field length one is not really going to show much :) [05:12] poolie: Also fixed bug #580404 but need to figure out how to get that review in lazr-js first. [05:12] <_mup_> Bug #580404: pressing enter in tags field doesn't save them < https://launchpad.net/bugs/580404 > [05:13] sorry [05:13] poolie: https://lpstats.canonical.com/graphs/SoybeanCPU/ https://lpstats.canonical.com/graphs/WampeeCPU/ https://lpstats.canonical.com/graphs/PalladiumCPU/ https://lpstats.canonical.com/graphs/PotassiumCPU/ https://lpstats.canonical.com/graphs/GandwanaCPU/ [05:13] i thought that was a different bug [05:13] the length will but the stray space won't, right? [05:14] poolie: Yes it's a different bug... I was mostly telling you cause you reported it. [05:14] oh, 580404 is my bug! [05:15] thanks, that always annoys me [05:15] and one other person apparently [05:15] poolie: ^ the two that are idle will be getting 'fixed' soon. [05:16] two idle cores? [05:16] 4 per box [05:16] they are 8 core machines [05:16] not enough memory on one atm [05:16] the other we have the memory, haven't had cycles to do the reconfig [05:16] huwshimi, so what i should have said is that i think a screenshot on https://code.launchpad.net/~huwshimi/launchpad/tag-field-length-591274/+merge/49341 would exemplify a good practice [05:17] even if it is probably pretty obvious how it would turn out [05:17] poolie: I can't attach an image directly can I? [05:17] poolie: Or am I missing something [05:18] unfortunately you need to attach it to the bug [05:18] poolie: Ok [05:21] poolie: https://bugs.launchpad.net/launchpad/+bug/591274/comments/2 [05:21] <_mup_> Bug #591274: tags field is too small < https://launchpad.net/bugs/591274 > [05:21] sorry, this is probably the worst ui change to ask for this on since it's so simple [05:22] poolie: Nah all good. [05:22] that misaligned help button looks a bit naff [05:23] RIP facets. [05:23] not your fault though [05:23] poolie: I know. I need to think about a plan for how fix our sprite generator so that it doesn't make everything look so ugly [05:24] poolie: The screenshots are probably a good idea so the reviewer can make sure they get the same thing as the commiter [05:25] wgrant: Did you just pull my changes or something? [05:25] huwshimi: I saw the commit fly past. [05:25] wgrant: Ah right [05:27] huwshimi, unofficial +1s from me [05:27] with tweaks on the space thing [05:29] poolie: Oh right [05:29] * huwshimi facepalms [05:37] poolie: Fixed if you want to take another look [05:39] i forget, semicolons before } are optional in js, aren't they? [05:39] +1 now [05:39] but i'm not an official reviewer [05:40] poolie: semicolons are completely optional in js. In that case I just forgot to add it. [05:52] so optional in the syntax but required by convention? [05:54] i guess you can treat this as an optionally reviewed patch [05:57] poolie: Yeah, few people code javascript without semicolons. [05:58] poolie: I'm not sure I follow about the optional review [06:00] i can't give you an official approval but if you wanted you could treat this as being optionally reviewed and land it anyhow [06:00] up to you; it depends how confident you are [06:00] or maybe wgrant's still here [06:02] I am still here. But I am but a code*. [06:02] Which MP? [06:02] tag-field-length-591274? [06:03] wgrant isn't a full reviewer yet either, but if he reviews, I'll mentor [06:03] and https://code.launchpad.net/~huwshimi/launchpad/tag-field-space-394342/+merge/49342 [06:03] you could mentor me too, if you don't mind [06:03] * wgrant does them. [06:03] lifeless: Could you also mentor https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295? [06:03] sure, I'll cook dinner first === almaisan-away is now known as al-maisan [06:04] poolie: you should let bac know you want to be a reviewer; I'm happy to be your mentor [06:04] Does anyone know who can review lazr-js stuff? [06:05] I think it's the normal LP reviewers. [06:05] wgrant: Ah right thanks. [06:05] Can someone review this then: https://code.launchpad.net/~huwshimi/lazr-js/autocomplete-enter-580404/+merge/49351 [06:05] huwshimi: everything listed on https://launchpad.net/launchpad-project/ is reviewable by LP reviewers. [06:05] Many thanks [06:05] huwshimi: some have additional reviewers on top of that [06:06] lifeless: Ah right. [06:09] huwshimi: Both reviewed. [06:09] wgrant: Cheers mate, thanks a lot [06:10] wgrant: Are you changing the status or should I do that? [06:11] huwshimi: lifeless needs to mentor my review first. [06:11] wgrant: ok right [06:12] 2x ui* == ui, but 2x code* < code === al-maisan is now known as almaisan-away [06:16] stub: btw [06:17] stub: you might find bug 716760 an interesting one for your when-coding time [06:17] <_mup_> Bug #716760: no measurement of in-datacentre queue timings < https://launchpad.net/bugs/716760 > [06:24] huwshimi, i don't totally understand your fix to bug 580404 yet [06:24] <_mup_> Bug #580404: pressing enter in tags field doesn't save them < https://launchpad.net/bugs/580404 > [06:28] poolie: So the change is that instead of checking that there is a query (i.e. someone has typed in a string) we check if there are results for the string (which includes a check for the string) otherwise the autocomplete will always capture the enter event even when we're typing in a tag that doesn't exist. [06:29] poolie: Does that shed any light or am I just confusing things? [06:29] poolie: Oh and another spelling mistake :( [06:29] that makes sense [06:32] poolie: My comment in the code was slightly wrong as well as the grammar mistakes (of which there were few) [06:33] poolie: Just pushed those changes [06:38] OK, heading off. Have a good one people. [06:39] cheerio huw [06:39] spm: could you please set qastaging cron.hourly to run, well, every hour ? [06:40] crazy talk [06:40] I know we've load issues [06:40] but we have a db patch in the pipeline that needs db migration completed [06:40] otherwise Bad Things will happen [06:41] (you know the one) [06:42] btw. what cron.hourly? cronscripts/? and where? [06:43] Which patch? [06:48] wgrant: bugmessage.index [06:48] spm: qastaging garbo-hourly is what I meant [06:48] ah. righto. [06:49] lifeless: Oh, missed the 'qastaging' bit. Sorry. [06:49] it has the migration job for bugmessage.index, and we can't do the db constraint for bugmessage.index NOT NULL until that migration is complete. [06:49] wgrant: no, it is a db patch [06:49] lifeless: I know. But I knew it was nowhere near prod. [06:49] wgrant: the ui will tolerate (enough, given its qastaging) nulls being present. [06:50] wgrant: next week we can use the column [06:50] We could, alternatively, restore qastaging from today's DB dump. [06:50] Which already has the data. [06:51] we should do that too, but there is still at least one run needed [06:51] + the patch to ensure it needs to be live [06:51] Right. [06:51] But it has no chance of catching up without the restore. [06:51] lifeless: enabled. 13 past the hour. same as prod. [06:51] spm: thanks === mthaddon changed the topic of #launchpad-dev to: Launchpad down/read-only from 09:00-10:30 UTC for a code update | https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [08:11] lifeless, just so you know, i'm still getting rejection messages regarding reviews of bzr [08:12] bzr! [08:12] poolie: thats very unexpected === almaisan-away is now known as al-maisan [08:13] poolie: is loggerhead-team perhaps in one of the bzr teams? [08:14] sorry [08:14] i'm confused/tired [08:14] it's a different problem [08:43] good morning === al-maisan is now known as almaisan-away [09:18] Hello [09:19] hi mrevell === jtv-afk is now known as jtv === adeuring changed the topic of #launchpad-dev to: Launchpad down/read-only from 09:00-10:30 UTC for a code update | https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews === almaisan-away is now known as al-maisan [09:46] :((( [09:47] why so sad thumper [09:48] my simple branch to fix the lazr.restful version to be 0.16 proper failed a bunch of tests [09:48] due to a change that I did in lazr.restful [09:48] to be more sensible about adding tracebacks to errors [09:48] I'm not going to fix it tonight [09:48] it can wait until Monday [09:49] thumper: The update_preview_diffs MP job still uses the update_preview_diffs config for errors, not the merge_proposal_jobs config that everything else uses. Do you know of a reason for that? [09:49] It's all that uses that config now. [09:49] wgrant: no idea [09:50] * wgrant removes the config override. [09:51] thumper: you did leave the prior tarball in place right ? [09:51] yes [09:53] wgrant: did you look at that php-uploadprogress build with the bad dependencies that's generating 24 oopses a day? [09:54] bigjools: I saw it in the OOPS reports. [09:54] Didn't look at the build. [09:54] ok [09:54] It's going to be at the top tomorrow :) [09:54] yeah [09:54] I need to work out what caused the bad dependencies [09:55] whether it's a dodgy package or bad sbuild [09:55] talking of which, did you get the newer sbuild working? :) [10:01] I haven't looked at that lately. The lp-buildd branch is on LP, but the (fairly tiny) sbuild changes are not. === mthaddon changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews [10:28] poolie: do you get the render times too ? [10:37] morning [10:47] hi wgrant! [10:47] Hi jtv. [10:47] Your change looks good. [10:47] I tried it on a couple of pockets on mawson. [10:47] But gave up waiting for it to finish on the release pocket. [10:47] wgrant: thanks! Sorry to trouble you—someone thought that archive publication was something to take extra care with, pah [10:48] I've already broken it once this evening :) [10:48] Ahem. :) [10:48] Julian tried it too, thought it felt quicker, but wasn't sure whether all binary files were published. [10:49] It only affects the dists tree, and that looked identical except timestamps. [10:49] We might want to try it over some larger pockets just in case. [10:49] But that takes forever, and I needed mawson for other things. [10:50] Then I'm marking it as qa-ok. [10:50] wgrant: I pocket copied stuff from release to proposed and it published everything ok [10:50] 4 arches [10:51] bigjools: Great. [10:51] I published lucid-updates and diffed the dists tree. [10:51] All fine. [10:51] but a second pair of eyes is never wasteD on the publisher [10:51] nice [10:52] Let's hope the other optimization comes through as nicely. === al-maisan is now known as almaisan-away === jtv is now known as jtv-eat [11:18] lifeless, i do get them [11:19] Is anyone else having trouble pulling branches from LP? [11:19] losa ping [11:20] gmb: yes, and pushing does not work at all for me atm. [11:20] gmb: We're just reverting the codehosting change. [11:20] Should be back in just a moment. [11:20] wgrant: Ah, okay, cool. [11:20] Thanks. [11:20] thanks === matsubara-afk is now known as matsubara [11:37] adeuring: can I poke this in your direction please: https://code.launchpad.net/~julian-edwards/launchpad/builder-history-timeout-bug-631206/+merge/49374 [11:39] bigjools: sure, I'll look [11:39] thank you [12:02] bigjools: the branch looks good, I think, just a minor remark: you need inner_privacy_query only for non-admin users, i.e., in the "else" parts of the "if user is None: ... elif is user_is_admin: ... else: ...". What about moving the definition of inner_privacy_query into this "else:" block? [12:03] adeuring: I put it there to get more width on the screen as it's less indented :) [12:03] bigjools: ah, right, makes sense for this monster ;) [12:03] indeed [12:04] although it would only affect one line === jtv-eat is now known as jtv [12:04] storm syntax is .... [12:04] thanks for looking at it adeuring [12:04] Hi jtv! [12:04] hi henninge! Saw your email about the bug. [12:05] I'm about to start on the XPI problem. [12:05] Ah yes, thanks for the comment. [12:05] bigjools: and one question, more out of curiosity: There is no privacy check if packagebuild.id is None. What does this mean? [12:05] jtv: can you re-review my branch first, please? [12:05] oh, OK [12:05] adeuring: only package builds are private [12:05] https://code.launchpad.net/~henninge/launchpad/devel-710591-importer/+merge/48682 [12:05] s/are/can be/ [12:06] bigjools: Ah, ok, thanks. [12:06] r=me [12:06] jtv: I am not sure if I should re-submit it. I have added quite a few changes. [12:06] cheers [12:06] henninge: I'm surprised :) [12:06] jtv: Let me add a comment to explain the changes. [12:06] Thanks, that'd help. [12:10] adeuring: can you mark the MP reviewed please [12:10] bigjools: sure, sorry... [12:10] henninge, an unfortunate complication: when you steal a flag, you also need to set a flush order. [12:11] jtv: you mean, whenever I change flags? [12:11] henninge: only when you clear one TM's flag in order to set the same flag on another. [12:12] jtv: yes, what I meant. ;-) [12:16] henninge: this should have been a separate branch and a separate MP… you're adding a whole new script! [12:16] jtv: yes, it was its own branch at first. [12:17] right now I cannot really remember why I merged it ... [12:17] the script, I mean [12:18] my bzr-foo was insufficient to sort things out correctly ... [12:19] henninge: better resubmit then. The MP's documentation trail *and votes* have very little to do with the branch now. [12:20] jtv: yeah, what I thought. I will have to do that after lunch, though. Thanks for looking into this. [12:20] ok [12:20] * henninge feels slightly dizzy, time to add some calories ... === henninge is now known as henninge-lunch [12:44] adeuring: Do you have time to review the addition of a vestigial page? https://code.launchpad.net/~gmb/launchpad/add-+subscriptions-page-bug-715802/+merge/49385 [12:50] gmb: sure [12:50] Thanks === henninge-lunch is now known as henninge [13:09] gmb: r=me [13:10] adeuring: Thanks. === almaisan-away is now known as al-maisan === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji | https://code.launchpad.net/launchpad-project/+activereviews === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring,bac | https://code.launchpad.net/launchpad-project/+activereviews [13:14] heh, topic race === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji*, bac | https://code.launchpad.net/launchpad-project/+activereviews [13:14] you won but i got the last word! [13:14] :) [13:14] good morning adeuring [13:24] benji: the review backlog doesn't look too intimidating. you want to work through the MPs and i'll mentor them? (as opposed to me taking some branches myself.) [13:24] sounds good [13:24] huw's looks interesting... [13:26] hi bac [13:28] benji: hello - can I talk about keyrings widya [13:30] bigjools: sure, on a call at the moment, I'll ping you when I get done [13:30] nae prob === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [13:48] bigjools: don't forget to mention that your keyring issue appears very similar to the one i had, may be a pattern there === henninge_ is now known as henninge [13:50] wallyworld_: you bet. Did you see it end up with a password of [0] ? [13:50] perhaps. could be. not sure [13:51] wallyworld_: have you got gnome desktop installed as well? or bits of it [13:52] bigjools: yes. i need the gnome keyring for ubuntu one sso in particular [13:52] wish ubuntu one supported kde :-( [13:52] wallyworld_: that's a bit annoying that it has to use that :/ [13:52] someone in the community did a port [13:52] there was an attempt, but i think it was aborted [13:52] the port was aborted [13:53] :( [13:53] yeah :-( [13:53] You could pick it up again ... [13:54] persia: thought about it. need some spare time though [14:25] henninge, did you resubmit? [14:25] jtv: almost [14:25] losa ping [14:26] jtv: hi [14:26] whoops, wrong channel === al-maisan is now known as almaisan-away [14:40] bigjools: what's up with keyring? [14:40] benji: yo [14:40] so, I had the same problem as wallyworld_ apparently [14:41] "had" or "still having"? [14:41] using ec2 land, it was picking up the Gnome keyring instead of kwallet and then throwing a weird error [14:41] still having - it's mutated :) [14:41] the original error is: ConfigParser.NoOptionError: No option 'consumer_key' in section: '1' [14:42] that's familiar [14:42] which seems to be because the password itself is [1] [14:42] which is somewhat odd! [14:42] I deleted the password from the keyring, re-authed with launchpadlib and it puts the same thing back, which breaks next time [14:42] I've made a keyringrc.conf to force kwallet and I now get a different error [14:43] here's the conf: http://pastebin.ubuntu.com/565888/ [14:43] and the error: http://pastebin.ubuntu.com/565889/ [14:44] ok, I have a diagnostic script I asked Ian to run, but he had already (accidentally) fixed his problem by that time, I'll dig it up and see what it tells us [14:45] oh, and what does "dpkg -l gnome-keyring" report? [14:46] 2.92.92.is.2.31.91-0ubuntu4.1 [14:46] here's the script: http://pastebin.ubuntu.com/565891/ [14:46] I see someone cocked up the versioning :) [14:47] it sure is an odd version string [14:47] benji: last output is: [14:47] [{'item_id': 18L, 'domain': 'service', 'password': '[1]\nfoo\nbar', 'keyring': 'default', 'user': 'username'}] [14:48] oh arse [14:48] I am still configured for kwallet, let me remove that, one sec === almaisan-away is now known as al-maisan [14:49] benji: so now I get: [14:49] [{'item_id': 18L, 'domain': 'service', 'password': '[1]\nfoo\nbar', 'keyring': 'default', 'user': 'username'}] [14:49] looks the same :) [14:49] man, that is really odd; I expected this to be a problem with older versions of gnome-keyring and newlines in the stored value, but apparently not [14:50] and the first line of output is something like ? [14:50] yes [14:50] [14:50] I'll get you a full backtrace [14:52] aaand now it decides to start working [14:52] pfft [14:53] t [14:53] you could try removing the dummy data the diagnostic script added to your gnome keyring; if it starts failing again then that's at least something [14:54] anyway, I still have the wallet problem [14:54] the backend is found ok, it doesn't seem to initialise it === matsubara is now known as matsubara-lunch [14:56] let me look at the code for that bit... [15:01] jtv: resubmitted. Thanks for your patience. [15:01] ok [15:01] henninge: URL? [15:01] check your mail! ;-) [15:01] https://code.launchpad.net/~henninge/launchpad/devel-710591-importer/+merge/49399 [15:04] bigjools: using the same Python you're running keyring under, run this import and see if it succeeds: from PyKDE4.kdeui import KWallet [15:06] benji: I'm not sure which python it's using - it's the ec2 script so I guess 2.6 [15:07] benji: that gives an error about kdeui not existing [15:08] I thought so. The keyring package is taking your word that kwallet will work, when in fact it can't import the library. [15:08] That's a bug (I'll file one). [15:09] benji: aha [15:09] the KDE bits are apparently not installed [15:09] benji: mmm they should be [15:09] and I should be king of the world [15:10] benji: I have a /usr/lib/pyshared/python2.6/PyKDE4/kdeui.so [15:10] and a /usr/lib/pymodules/python2.6/PyKDE4/kdeui.so it seems [15:10] you can peek at the shebang of the ec2 script and see if you're using the same python as it [15:10] yeah I copied it [15:11] maybe a python path problem then? [15:11] most likely [15:11] hmm [15:12] it works on my other box.... (which I can't start right now because of a power cut, sorry) === Ursinha is now known as Ursinha-lunch === al-maisan is now known as almaisan-away [15:16] grar netsplit [15:21] *sigh* [15:21] bad day? [15:22] I'm running Launchpad locally for the first time in a couple of months. [15:22] aaah. [15:22] And of course, it's not working straight away. === NCommander is now known as Guest28688 === almaisan-away is now known as al-maisan [15:24] what's the hangup? I just had to rebuild an lp dev environment. [15:24] jcsackett: well, it was a js build problem. have just run 'make clean' and am running 'make schema' now in stable so I can debug fo' realz. [15:25] dig. [15:27] you can make -j2 for a good speedup now [15:29] bigjools: ooh, that's good to know. [15:30] higher numbers are slower for some reason, but thank jtv [15:30] http://paste.ubuntu.com/565909/ [15:30] just got this. [15:30] run rocketfuel-setup lately? [15:31] and this in the logs: http://paste.ubuntu.com/565911/ [15:31] bigjools: no, should I? === bac` is now known as bac [15:32] I think it added some extra hosts [15:32] hmm. [15:32] the openid hosts [15:33] I have testopenid.dev. Will look at rf-setup and see if it has anything new. [15:34] lots new, apparently. [15:34] I bet lots of these are cruft. [15:34] I wonder how I could tell. [15:34] divination [15:38] There must be a better way. [15:38] grep, perhaps. [15:41] jam: your edit on the IR implies that there's a bug in Twisted wrt ReactorNotRunning. Is there a ticket for that? === al-maisan is now known as almaisan-away [15:43] jml: not that I know of [15:43] jml: I did file https://bugs.launchpad.net/launchpad/+bug/717205 [15:43] losa ping, I'm trying to dig out the log file for the bzr-forking-server running on production. [15:44] the qastaging one is at: /srv/launchpad.net-logs/code/tellurium/qastaging-codehosting/codehosting/bzr-lp-forking-service.log [15:44] But I don't see a similar file in [15:44] /srv/launchpad.net-logs/code/tellurium/codehosting/codehosting/bzr-lp-forking-service.log [15:45] jam: can I share that bug with other Twisted developers? (Can I make it public?) [15:45] ah, I see a crowberry/codehosting/log [15:45] jml: I didn't think I made it security private [15:45] no problem with me to make it public [15:45] I must have checked something I didn't mean to [15:45] jam: yeah, that log will be from crowberry. [15:46] mbarnett: I think I was just confused by tellurium also having a "codehosting" rather than just "qastaging-codehosting" [15:46] mbarnett: is that staging- files, then? [15:46] (just not marked as such) [15:47] yeah, that's staging. [15:48] jcsackett: seen this one http://paste.ubuntu.com/565920/ ? [15:49] jtv: any questions about the mp? [15:49] henninge: not at the moment, no [15:50] jml: i saw something go wrong with min on a rocketfuel-get this morning, but a make clean && make got around it. [15:50] I'll try that again, I guess. [15:51] well, if you just did it and are still in an error state... [15:52] one sec, i'm rolling my devel directory back and getting again; i'll see if i get the error and then can poke it with a stick. [15:52] jml: i assume you do have the file in question? [15:52] jcsackett: I did make clean; make; bzr merge ../stable; make. Trying make clean & make again. [15:53] jml: dig. [15:53] henninge: here's one question now—when determining whether upstream has templates, shouldn't we ignore deactivated ones? [15:53] hm, probably [15:53] jtv: I'll file a bug to add that later. [15:54] It is not very important for the current bug because we are looking at upstream projects that never had any translation activity. [15:55] I see. [15:57] bug 717220 [15:57] <_mup_> Bug #717220: Translation sharing info should ignore deactivated templates. < https://launchpad.net/bugs/717220 > [15:57] OK [16:00] jtv: please email any further comments. I have to leave now. Sorry. [16:00] ok === matsubara-lunch is now known as matsubara === beuno is now known as beuno-lunch === Ursinha-lunch is now known as Ursinha [16:49] grrrrr hanging ec2 from windmill .... [16:57] bigjools: I haven't seen that hanging recently (although I haven't done many runs recently), and I don't know much about windmill. The way to diagnose is probably to shell in and start using unix tools [16:57] since the email you get when that happens should contain everything that the ec2 test tools know about what's going on. [16:58] jml: the instance is down after the email though [16:58] bigjools: yeah. you'd have to try again. [16:59] ok thanks [17:01] np. sorry I can't really help more. [17:06] bac: I finished the review of https://code.launchpad.net/~huwshimi/lazr-js/autocomplete-enter-580404/+merge/49351 [17:15] jkakar, I'm using a ClassAlias in Storm, with no apparent effect. Is this a bug? http://pastebin.ubuntu.com/565962/ [17:18] * jkakar looks === beuno-lunch is now known as beuno === jelmer_ is now known as jelmer [18:13] g'night all [18:26] so apparently running for i in `seq 10`; do my windmill test; done was not a good idea. [18:31] bac: another review for your review: https://code.launchpad.net/~jameinel/loggerhead/pygment-annotate-fail/+merge/49312 (there's a yo dawg joke in there somewhere) [18:31] benji: thanks [18:31] benji: would you add me as a 'code' reviewer to the ones you need me to do? [18:31] sure thing [18:33] bac: is there a way to change a reviewer type after choosing another reviewer? I didn't type anything and now I can't even remove you to try again. [18:33] it is pretty hinky [18:33] bac: nevermind, if I add you again it overwrites the old one [18:33] as long as i'm added it doesn't matter. [18:33] great [18:37] bac: I've looked over the other reviews and they seem to be mid review with another reviewer, so I'll skip those [18:37] benji: ok [18:47] jkakar, how's it look? [18:48] benji, https://code.launchpad.net/~gary/launchpad/refactoractivitylog/+merge/49444 is ready when you are [18:49] gary_poster: cool [18:49] thanks === deryck is now known as deryck[lunch] [19:01] bac: I manually applied the patch to lazr-js/build/autocomplete/autocomplete.js and ran make to rebuild icing [19:01] bac: I also talked to you in the wrong channel, that helps too [19:10] gary_poster: reviewed, only one small comment [19:13] ack benji, thank you. For single and double quotes, I generally prefer single except when I need to use double. I needed to use double for "attribute" because there is a single in the string acting as an apostrophe. I'll leave that as it is. I can adjust the spacing, sure. [19:13] gary_poster: I missed that, thanks. === almaisan-away is now known as al-maisan [20:19] benji: bac. can either of you review https://code.launchpad.net/~sinzui/launchpad/prf-connection-0/+merge/49456 === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: benji*, bac | https://code.launchpad.net/launchpad-project/+activereviews [20:19] sinzui: ooh ooh, Mr. Kotter, Mr. Kotter [20:20] yes horshack [20:20] deryck: bugs question for you [20:21] lifeless, sure. sup? [20:21] deryck: the portlet, why does it show 'new' bugs but not 'untriaged' (e.g. those in new|confirmed|undecided-importance) [20:21] deryck: if its oversight, do you see any issue in adding an 'untriaged' link (or even just replacing new with untriaged) ? [20:22] actually (new|confirmed|undecided-importance|incomplete-with-reply) === Ursinha is now known as Ursinha-afk [20:26] I seem to be having connection issues.... lifeless, am I still here? :) [20:27] deryck: no [20:27] heh [20:27] ok, so untriaged.... [20:27] new has always been equated to untriaged. [20:27] that's why the current portlet setup [20:28] deryck: status=new is a subset of untriaged, for Ubuntu and for us - for most of our users I suspect. [20:28] lifeless, how are you defining untriaged? [20:29] confirmed and/or undecided importance ? [20:29] new|confirmed|undecided-importance|incomplete-with-reply [20:30] would you drop anything from the portlet, or just add those? [20:30] well [20:30] I dunno [20:30] to me, 'new' is uninteresting [20:30] I'd be interested in s/new/untriaged/ and put that criteria behind it [20:31] so replace "new" with "untriaged" and have the untriaged link go to a list of bugs that includes the list: new|confirmed|undecided-importance|incomplete-with-reply [20:31] ? [20:31] yes [20:31] * deryck is thinking [20:32] or add a row, but that seems less interesting, because its really that 'new' isn't inclusive enough [20:32] I'll discuss this in a wider forum when you and I are in agreement [20:32] basically I want to replace the two searches on https://dev.launchpad.net/BugTriage [20:33] there are equivalent searches in the Ubuntu docs [20:33] for our use and I imagine Ubuntu's, this makes sense. I'd like wider discussion to decide the fate of new. Some folks may really like new all on its own. [20:34] so I'm +1 on an "untriaged" link. Whether or not it replaces "new" or sites alonside it, we need more input, I think. [20:34] I propose to put a blog post up and a thread on lp-users [20:34] https://wiki.ubuntu.com/Bugs/HowToTriage#Untriaged%20bugs [20:35] sinzui: mentored approval, bac will review my review for final approval [20:35] lifeless, sure. I think it would be worth pinging a couple larger users of lp beyond us and ubuntu for feedback, too. [20:35] if reaction is limited in those two places [20:35] do we have a canned list of such users ? [20:37] no, not really [20:37] mrevell would be a good resource there [20:37] k [20:37] thanks [20:37] np === al-maisan is now known as almaisan-away [21:03] later on. enjoy the weekend everyone! === Ursinha-afk is now known as Ursinha [21:40] lifeless: it looks like whatever is generating https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/20110210/20110212/ [21:40] doesn't see the bzr processes that are spawned by the forking server [21:40] and we don't have a graph similar to that for qastaging [21:40] It is a bit hard to see [21:41] but at 10:00 and 10:30 there are no green dots in that graph [21:41] I would guess it is doing some sort of "ps" grepping, and the signature changed [21:42] thats possible [21:42] you can tell by checking the lp tuolumne branch, I think. [21:43] lifeless: more info would be good there [21:43] That is supposed to be the script that generates the graphs? [21:44] tuolumne is what runs lpstats [21:44] we have a branch of it that adds data gatherers [21:44] talk to a losa for the raw info [21:45] weird, the project itself isn't marked as private, but all branches for it are [21:45] only branch on lp is trunk [21:45] lp does not support private projects yet [21:47] anyhow, I'm fuzzy on this [21:47] I think you need to talk to a losa, or flacoste, to get more info [21:51] https://wiki.canonical.com/Launchpad/PolicyandProcess/AddLPStatsGraph [21:51] is part of the code [21:51] which talks about getting db items tracked [21:52] but lp:tuluomne-lp-configs doesn't seem to have anything like "bzr ping" stats [21:55] "There are any number of other data gathering processes that work in different ways. All they need to do is dump data into a file in the "name:value@timestamp" format in the /srv/lpstats.canonical.com/data directory. " [21:55] but it certainly looks like all of that isn't versioned with everything else [21:56] jam: like I say, /talk/ to a losa [21:56] I have to afk for a while [tis saturday] [21:56] lifeless: sure, but you've mentioned them about 4 times now, and you're the only one still talking here [21:56] have a good weekend [21:57] jam: will do, you to. They don't highlight losa in public channels or something [21:57] needs an explicit ping in -ops. === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews === Ursinha is now known as Ursinha-afk === matsubara is now known as matsubara-afk [22:48] how does one push branches and test mp diffs on lp.dev? [22:49] jcsackett, https://dev.launchpad.net/Code/HowToUseCodehostingLocally [22:49] james_w: thanks. clearly my search-fu is weak this evening. [22:49] don't know if that covers mp diffs though [22:50] it will get you the branch, then you can propose the merge, and then run the script by hand I assume