[00:31] <mwhudson> aaaaa
[00:31] <lifeless> bbbbb
[00:31] <mwhudson> want to make /bin/py start up in 0.07 seconds (ish) rather than 0.5 ?
[00:32] <mwhudson> touch lib/site.py
[00:32] <mwhudson> in other news: setuptools is bad
[00:32] <lifeless> orly
[00:32] <lifeless> does lib/site.py exist normally?
[00:33] <mwhudson> it has some behaviour that is quadratic in the length of sys.path
[00:33] <mwhudson> lifeless: no, touching it prevents setuptools' site.py from loading
[00:33] <lifeless> hah
[00:41] <maxb> The other reason setuptools is bad? I can't find any way to make its namespace package support compatible with having system installed lazr.* and buildoutified lazr.*
[00:42] <lifeless> well
[00:42] <lifeless> eggs are bad
[00:42] <lifeless> the rest follows
[00:51] <mwhudson> maxb: "the" other? :)
[00:52] <lifeless> someone should write a rant
[00:52] <maxb> well, I was thinking more *immediate* reasons :-)
[00:54] <mwhudson> the overriding problem with setuptools is that people use it
[00:54] <mwhudson> which is not the correct thing to do with software from pje
[00:54] <lifeless> LOL
[00:54] <lifeless> quotes page....
[00:54] <mwhudson> the correct thing is to be inspired by it
[00:55] <mwhudson> heh
[06:38] <al-maisan> Good morning!
[08:45] <thumper> morning
[08:46] <spm> yo
[08:46] <thumper> spm: how goes the puller?
[08:46] <spm> thumper: as expected. problem free now we have sufficient logging to detect the actual problem.
[08:47] <thumper> spm: excellent
[08:48] <thumper> mwhudson: hi
[08:48] <mwhudson> thumper: hello
[08:49] <thumper> mwhudson: were you able to glean any extra info from that puller log?
[08:50] <mwhudson> thumper: no
[08:50] <mwhudson> thumper: it looks totally impossible :/
[08:50] <thumper> :(
[08:50] <thumper> did you cowboy any more logging?
[08:50] <mwhudson> no, no more yet
[08:51] <spm> sun spots?
[08:53] <bigjools> I hear that Dallas has the right kind of hats for us
[08:59] <thumper> spm: what is the branch puller delay?
[09:00] <spm> thumper: I think it's this one: select greatest(0.0, extract(epoch from (CURRENT_TIMESTAMP AT TIME ZONE 'UTC' - min(next_mirror_time)))) from branch where branch_type <> 4; or a variant of.
[09:58] <jtv> mrevell: why does staging *still* say it's 2.2.7?  To confuse the enemy?
[09:58] <jtv> Same for edge, actually
[10:00] <mrevell> jtv: I think danilos or beuno have a branch to fix that
[10:00]  * beuno has no suck branch
[10:00] <beuno> *such
[10:01] <beuno> wow
[10:01] <beuno> I have filed a bug though
[10:02] <jtv> We could file one automatically for every cycle.
[10:02] <jtv> (No, _not_ serious)
[11:57] <Fly-Man-> rockstar: *ping*
[11:58] <Fly-Man-> I managed to pinpoint the error back to Python that doesn't like to be inside a Vmware Server 2.0.1
[11:59] <Fly-Man-> The people from VMware were shocked to see that this could happen and are thinking about ways to make sure this keeps working
[12:19] <barry> jtv: or we could just not /have/ a version number in the footer <wink>
[12:19] <barry> Fly-Man-: wow.  what did vmware say was the problem?
[12:20] <Fly-Man-> Python version 2.6 from Jaunty
[12:20] <Fly-Man-> It seems that over the period of time
[12:20] <Fly-Man-> with the rocketfuel setup
[12:20] <Fly-Man-> it sets up 2.4, 2.5 and 2.6
[12:20] <Fly-Man-> and those seems not to be happy with each other and the tools that VMware released
[12:21] <barry> huh.  interesting.
[12:21] <Fly-Man-> at least, not with the machine i'm running it on :p
[13:14] <stub> select milestone.name
[13:14] <stub> from milestone,product
[13:14] <stub> where product.name='launchpad'
[13:14] <stub> and product.id = milestone.product
[13:14] <stub> and dateexpected < current_timestamp at time zone 'utc'
[13:14] <stub> order by dateexpected
[13:14] <stub> limit 1;
[13:14] <stub> which would work if we bothered to keep our data up to date ;)
[13:15] <stub> oh - we do. I just forgot the desc
[13:15] <stub> select milestone.name
[13:15] <stub> from milestone,product
[13:15] <stub> where product.name='launchpad-foundations'
[13:15] <stub> and product.id = milestone.product
[13:15] <stub> and dateexpected < current_timestamp at time zone 'utc'
[13:15] <stub> order by dateexpected desc
[13:41] <barry> kfogel: i am an idjit :)  see my last follow up on that thread.  i think there's no bug there
[13:44] <kfogel> barry: so, uh, what was the bug Henning saw, though?
[13:49] <barry> kfogel: i don't know
[13:57] <thumper> abentley: hello
[13:57] <thumper> ?
[14:04] <abentley> thumper: Hi.
[14:05] <thumper> abentley: hey, how's it going?
[14:05] <abentley> It's going fine.  Today just started, but I'll be trying to get an improved bzr cherrypicked.
[14:06] <abentley> thumper: And then back to the inline-commenting stuff.
[14:06] <thumper> abentley: how much faster is the preview diff generation with your patch?
[14:06] <thumper> abentley: and has that patch gone/going into bzr.dev?
[14:07] <thumper> abentley: it is bzrlib isn't it?
[14:07] <abentley> thumper: On my example test, it is 22x faster, but that will vary a lot because it changes O(n^2) scaling to O(n) scaling.
[14:07] <thumper> excellent
[14:07] <thumper> example test was what?
[14:07] <thumper> not the mysql test?
[14:07] <thumper> I have the mysql branches locally
[14:08] <thumper> if you want me to compare
[14:08] <abentley> thumper: It has landed in the 2.0 branch, and will propagate to bzr.dev and appear in the next release.
[14:08]  * thumper nods
[14:08] <thumper> has an official tarball available, or are we going to add our own?
[14:09] <abentley> thumper: I don't have the patience to run the sql merge without the patch, but with the patch, it completes in about a minute.
[14:09] <thumper> awesome
[14:09] <thumper> without the patch it is over an hour
[14:09] <thumper> (on my machine)
[14:09] <abentley> thumper: Just under an hour on loganberry.
[14:10] <thumper> that's awesome
[14:10] <thumper> so...
[14:10] <thumper> adding a new bzr tarball to the download cache?
[14:11] <thumper> how is the inline editing widget work coming along?
[14:11] <jtv> code folks!  How do I create a stacked branch in a test?  Is passing stacked_on to factory.makeBranch enough?
[14:11] <abentley> thumper: Yes, and setting up a corresponding branch.
[14:11] <thumper> jtv: yes, if you just want a stacked test branch
[14:11] <thumper> jtv: it won't create the branch on disk
[14:12] <abentley> thumper: I've got it working just for comments, and it puts the comment in the wrong place, and it doesn't support replies.
[14:12] <thumper> oh kay...
[14:12] <jtv> thumper: I want to reproduce bug 375013 in a test, basically
[14:12] <mup> Bug #375013: Commit to a stacked branch does not work <commit> <stacking> <Bazaar:Triaged> <https://launchpad.net/bugs/375013>
[14:12] <thumper> jtv: ah
[14:13] <thumper> jtv: you want to create real branches
[14:13] <jtv> yes
[14:13]  * thumper tries to remember test examples
[14:14] <thumper> jtv: lib/codehosting/scanner/tests/test_bzrsyncd.py:537
[14:14] <thumper> jtv: is an example of creating a real stacked branch
[14:15] <jtv> thumper: just what I was hoping for, thanks.
[14:15] <jtv> separate call to set_stacked_on_url, I see.
[14:15] <jtv> That'd do it, yes  :)
[14:16] <jtv> thumper: stacked_on_branch is kinda sucky as a variable name... why not call your branches "pea" and "mattress"?
[14:17]  * thumper shoots jtv with a pea shooter#
[14:17] <jtv> (Of course since I'm testing a stacking limitation, my test would be called Princess)
[14:17] <thumper> jtv: i'd have to reject that branch
[14:17] <jtv> On *no* account look up "It's Princess!" (by the makers of South Park) on the intertubes
[14:17] <jtv> thumper: but you'd be grinning while doing so
[14:24] <gmb> Anyone got any idea why I'd be seeing timeouts in googletestservice.py during a test run?
[14:26] <thumper> ah netsplit
[14:30] <thumper> gosh isn't bigjools annoying
[14:31] <thumper> heh
[14:46] <thumper> gmb: ping
[14:47] <gmb> thumper: Hi
[14:47] <thumper> gmb: https://code.edge.launchpad.net/launchpad/+activereviews
[14:47] <thumper> gmb: you have two old approved branches
[14:47] <thumper> gmb: have they landed?
[14:47]  * gmb looks
[14:48] <thumper> gmb: they may be not identified correctly as we switched formats around then
[14:48] <gmb> thumper: No, they're branches that are waiting on subsequent branches before they can be landed. They're still unmerged.
[14:48]  * gmb wishes there was a way to express that that +activereviews could understand.
[14:50] <thumper> gmb: why can't they be landed?
[14:50] <thumper> gmb: what would happen now if you land them?
[14:50] <thumper> gmb: will it break something, or just be unused code?
[14:52] <gmb> thumper: Things would break.
[14:52]  * thumper wonders how to show this
[14:53] <gmb> thumper: They're large branches, or rather they're logical blocks of large branches.
[14:53] <gmb> Which I had to leave because of more pressing work.
[14:53] <thumper> hmm..
[14:54] <thumper> ideally we'd want to have a way to say "this is approved but blocked"
[14:54] <thumper> so you won't get people like me bitching about it
[14:54] <gmb> Heh.
[14:54] <gmb> Right :)
[14:55] <gmb> thumper: Want me to file a bug for this so that you can get on with team leadery things?
[14:55] <thumper> sure
[14:56] <gmb> Will do.
[15:10] <gmb> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/440011
[15:10] <mup> Bug #440011: There should be a way to say that a merge proposal is approved but blocked <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/440011>
[15:21] <thumper> ta
[15:23] <henninge> maybe I should ask here ...
[15:23] <henninge> I want to use a TAL formatter in a view and I found out I can do it this way: https://pastebin.canonical.com/22831/
[15:23] <henninge> Is that the right way to do it? Or should I go through the registration somehow? I remember seeing an example once that was different ...
[16:27] <rockstar> Ursinha, sorry about missing the meeting.  Drop off at the vet took longer than expected.
[16:28] <Ursinha> no problem rockstar
[16:28] <Ursinha> do you know why is update_review_diffs script failing?
[16:29] <rockstar> Ursinha, yes, and abentley had a hack to fix it, and I think a correct fix as well.
[16:30] <abentley> rockstar: The "correct" fix stops it failing in this case, but not all cases.
[16:30] <rockstar> abentley, yeah, I think you mentioned that last night.
[16:34] <abentley> Ursinha: It's been discussed on the list.  See the threads under Scripts failed to run: loganberry:update_preview_diffs
[16:46] <Ursinha> thanks abentley and rockstar
[17:01] <poolie> my first MP for launchpad! :-) https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/12732
[18:15] <thumper> beuno: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk-rich
[18:15] <beuno> thumper, I LOVE YOU
[18:43] <kees> gmb: /me is here now.  :)
[18:43]  * kees waves to bryce__ 
[18:44] <bryce__> whew
[18:45] <bryce__> debug output and test script posted to https://bugs.edge.launchpad.net/malone/+bug/329917
[18:45] <mup> Bug #329917: Changing a task's target using the API OOPSes as NotImplementedError <api> <oops> <ubuntu-qa> <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/329917>
[18:48] <gmb> kees: I think we might have discovered a race condition here.
[18:48] <gmb> kees: Normally, that NotImplementedError will only get called if you try to access the bug using a target on which it isn't reported.
[18:49] <gmb> kees: e.g. https://bugs.launchpad.net/evolution/+bug/42 when bug 42 isn't reported on evolution.
[18:49] <mup> Bug #42: Bug description listed in task is not the correct description <Launchpad Bugs:Fix Released by bradb> <https://launchpad.net/bugs/42>
[18:49] <mup> Bug #42: Bug description listed in task is not the correct description <Launchpad Bugs:Fix Released by bradb> <https://launchpad.net/bugs/42>
[18:50] <gmb> kees: So it's almost as if the new bugtask is being accessed before it actually exists, which seems strange.
[18:52] <kees> gmb: I haven't caught any OOPSes myself (how can I find an OOPS via the API?) but I always see the HTTP-500 error.
[18:52] <gmb> Hrm.
[18:52] <gmb> kees: OOPSes aren't available via the API because they're not part of LP, as such; that's a separate system that Launchpad links to.
[18:53] <kees> ah-ha.  do they show up in the html test from the API failure?
[18:53] <bac> barry: have you run ec2 lately?
[18:53] <gmb> kees: I'm not sure; I'll find out for you.
[18:54] <gmb> kees: So, I don't know what's causing the problem but I at least understand the root cause of the problem. I'll update the bug and we'll get someone on it tomorrow.
[18:54] <gmb> (since we're all in the UK atm)
[18:54] <kees> gmb: ok, great, thanks!
[19:05] <maxb> bzr 2.0.0-lp-1?
[19:24] <EdwinGrubbs> BjornT: ping
[19:32]  * kees hugs matsubara for r9611 :)
[19:32] <matsubara> kees, it's probably not me who you want to hug :-)
[19:32] <kees> matsubara: oh, er, well, you touched the bug.  :)
[19:32] <matsubara> kees, I just run a script that parses commit logs for bug and mark them as fix committed
[19:33]  * kees looks for Muharem
[19:47] <mwhudson> good morning
[19:52] <kees> intellectronica: uhm... bug 329917 is certainly not invalid.
[19:52] <mup> Bug #329917: Changing a task's target using the API OOPSes as NotImplementedError <api> <oops> <ubuntu-qa> <Launchpad Bugs:Invalid> <https://launchpad.net/bugs/329917>
[19:53] <intellectronica> kees: read my explanation? it's a different bug from the one described originally and marked as duplicate, and needs to be fixed client-side
[19:53] <intellectronica> kees: i'm looking at the real bug as we speak
[19:53] <kees> intellectronica: which should be the master for the issue pitti, me, bdmurray, and bryyce are seeing?
[19:54] <kees> intellectronica: aH, 342355
[19:55] <intellectronica> kees: i think bug #342355 is the real bug. the one Ursinha-afk filed is a red herring. it would be nice to fix it (in launchpadlib, not launchpad) at some point, but it's not a show stopper
[19:55] <mup> Bug #342355: transitionToTarget for an Ubuntu package yields HTTP 500 error <Launchpad Bugs:New> <https://launchpad.net/bugs/342355>
[19:55] <intellectronica> i also described a workaround
[19:56] <kees> intellectronica: ok, cool.  I'm interested in 342355 then.  :)  can you milestone/confirm/high that one instead?
[19:56] <mwhudson> maxb: you there?
[19:57] <intellectronica> kees: i'm investigating that one now and will update as soon as i know what's involved. i suspect it's an easy one and can get a fix out quickly
[19:57] <kees> intellectronica: rockin'!  thanks :)
[19:58] <intellectronica> kees: do you happen to have the foo to make me part of the ubuntu-bugs team (on staging)?
[19:58] <kees> intellectronica: let me see
[20:00] <kees> intellectronica: doesn't look like it, let me poke bdmurray
[20:01] <abentley> rockstar: Have you tried "make sync_branches" recently?
[20:01] <kees> intellectronica: bdmurray is afk for lunch, it seems... let me see if I can find jcastro
[20:02] <rockstar> abentley, no, but I remember that thumper and I had an issue with it when we were messing with the branch rewrite stuff.
[20:02] <intellectronica> matsubara: can you? ^^^^^ i think you've got admin foo powers?
[20:02] <rockstar> abentley, I think there was a configuration issue.
[20:02] <rockstar> abentley, although it looks like mwhudson is awake and alert, so he might have some insight.
[20:03] <abentley> mwhudson: Have you tried "make sync_branches" recently? (It's not scanning the branches for me)
[20:03]  * mwhudson tries to work out what's in trunk
[20:03] <matsubara> intellectronica, I don't have lp admin powers
[20:03] <mwhudson> abentley: it's possible the "pull_branches" rule isn't right
[20:03] <mwhudson> abentley: does 'make pull_branches' seem happy?
[20:04] <kees> intellectronica: hrmpf, all the admins are idle.  :P  is there some action you need to take that I can help with instead?
[20:04] <mwhudson> abentley: another problem can be that /var/tmp/bazaar.launchpad.dev/mirrors/ ends up 0700 for some reason
[20:04] <mwhudson> kees: mbarnett should be here
[20:04] <abentley> mwhudson: Yes.  Earlier runs of sync_branches reported successful mirroring.
[20:04] <mwhudson> abentley: odd
[20:04] <intellectronica> kees: no big deal. i'll need to reproduce it locally anyway, just wanted to see what actually happens one you run your script and get a stack trace, but i can get that from the oops report
[20:05] <kees> intellectronica: I take it back, ogasawara fixed it.  you should be in now
[20:05]  * mbarnett looks around
[20:05] <kees> mwhudson, mbarnett: sorry, I meant ubuntu-bugcontrol admins.  :)
[20:05] <intellectronica> kees: awesome, thanks
[20:05] <mwhudson> mbarnett: ah, sorry
[20:06] <abentley> mwhudson: This looks like 0755
[20:06]  * mbarnett wanders off again 
[20:06] <mbarnett> mwhudson: np
[20:07] <mwhudson> abentley: when you say "not scanning" do you mean the scanner isn't even looking at the branches you think it should?
[20:08] <abentley> mwhudson: the branch scanner script reports 2009-10-01 18:54:29 INFO    OOPS-1370BS1: Not a branch: "lp-mirrored:///~mark/bzr/bzrtools-silly". (~mark/bzr/bzrtools-silly)
[20:08] <abentley> mwhudson: I think the puller is putting the branches in the wrong place...
[20:09] <mwhudson> abentley: or cocking up the stacked_on_url
[20:09] <abentley> mwhudson: No stacking enabled for this project.
[20:10] <mwhudson> ok, that's one thing down :)
[20:10] <abentley> mwhudson: I looked at /var/tmp/bazaar.launchpad.dev/mirrors/ and the branches weren't there.  (there were two presumably very old branches)
[20:10] <mwhudson> ok that's screwy
[20:14] <mwhudson> huh, the puller isn't working at all for me for some reason...
[20:16] <mwhudson> abentley: need to have coffee before looking at this more, brb
[20:16] <abentley> mwhudson: cool
[20:26] <abentley> mwhudson: I have an idea-- I bet you apache's mad at me.
[20:34] <rockstar> abentley, you could say that all the time and 60% of the time you'd be right.
[20:41] <intellectronica> kees: i have a fix for your bug. review and test run, and if everything goes ok it should be fixed on edge after the next rollout
[20:45] <mwhudson> abentley: working now
[20:45] <mwhudson> ?
[20:46] <abentley> kinda working.  It's got the wrong branch data, but that might be my fault.
[20:46]  * kees hugs intellectronica
[20:46] <abentley> mwhudson: It may be because I didn't have an /etc/hosts entry for bazaar-internal.launchpad.net
[20:47] <mwhudson> yes, that would certainly prevent the scanner from working
[20:47] <mwhudson> (i presume you mean bazaar-internal.launchpad.DEV ?)
[20:47] <abentley> mwhudson: Yes.
[21:14] <abentley> mwhudson: Up for a chat about jobs and code import?
[21:15] <mwhudson> abentley: ok, one sec
[21:21] <Ursinha> intellectronica, I understand what you mean in that bug, I think we should create one bugtask for launchpadlib, and mark the bug as dupe in case we find the lplib bug you mentioned
[21:21] <intellectronica> Ursinha: i think that's a good idea
[21:22] <Ursinha> intellectronica, done, then :)
[21:23] <intellectronica> Ursinha: great, thanks
[21:34]  * rockstar lunches
[21:34] <leonardr> james_w, version 1.5.2 of launchpadlib has been released for your packaging enjoyment
[21:40] <matsubara> cprov-afk, when you're around could you take care of https://answers.edge.launchpad.net/launchpad/+question/81974 please?
[21:42] <cprov-afk> matsubara: uhm ... sure
[21:43] <matsubara> cprov-afk, thanks!
[21:43] <cprov-afk> matsubara: actually, I can't
[21:43] <cprov-afk> matsubara: I'm not a soyuz-member anymore :`(
[21:43] <matsubara> cprov-afk, oh!
[21:44] <matsubara> well, since the user is OK with the team being deleted, I think I'm going to suggest that.
[21:45] <matsubara> cprov-afk, do you know if merging the team away be blocked by the ppa linkage?
[21:46] <cprov-afk> matsubara: merging is allowed
[21:46] <matsubara> cool. I'll ask the losas then
[21:46] <matsubara> thanks cprov-afk
[21:46] <cprov-afk> matsubara: np
[21:58] <mwhudson> abentley: lib/canonical/twistedsupport/processmonitor.py
[23:16] <wgrant> Oh, cprov's leaving? :(
[23:16] <mwhudson> left, even :)
[23:16] <mwhudson> :( rather
[23:17] <mwhudson> i think
[23:17] <rockstar> Yea, his last day was yesterday.
[23:17] <wgrant> Wow.
[23:18] <mwhudson> however what with launchpad now being open source, i'm sure he won't escape that easily :)
[23:22] <wgrant> Heh.
[23:29] <barry> rockstar: ping
[23:30] <barry> EdwinGrubbs: ping
[23:36] <rockstar> barry, yo
[23:37] <barry> rockstar: hi.  do you have a few minutes to look at some screenshots?
[23:37] <rockstar> barry, yes.  I still plan on being around for a bit.
[23:38] <barry> rockstar: cool, thanks.  i'm playing around with some fixes for bug 440220
[23:38] <mup> Bug #440220: registering slot interferes with watermark <post-ui-3-cleanup> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/440220>
[23:38] <barry> rockstar: there are some screen shots attached to that bug report.  the first one is a snap of the current problem, then three snaps of some fixes
[23:39] <barry> rockstar: i'm very interested to know what you think.  note that this approach is keeping the registering slot where it currently is and just playing with layout and nowrap
[23:39] <barry> rockstar: but another possibility of course is to move the registering slot to a different location
[23:39] <barry> rockstar: anyway EOT