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