[00:03] <maxb> Purely ooi, and because I'm attempting to copy it for use in my own project, is it correct that db patches don't necessarily land in numerical order?
[00:06] <wgrant> Correct.
[00:31] <maxb> wgrant: Does Launchpad work with python2.6/lucid at all for you now? I am now getting the distribute pain on multiple lucid machines, and it looks like it ought to reproduce 100%
[00:32] <wgrant> maxb: I forget if I still have everything downgraded.
[00:32]  * wgrant tries.
[00:32] <wgrant> I appear to have the latest version of python-distribute and python-pkg-sources.
[00:32] <wgrant> er, *resources
[00:33] <wgrant> There is still the zope.interface issue, but that's all I have held.
[00:33] <maxb> Hmm. I wonder if I apt-get install python-distribute, it will work for me
[00:33] <wgrant> And I did a tree build (not from scratch, but from a fresh branch) this morning.
[00:33] <maxb> zope.interface issue?
[00:33] <wgrant> I don't have python-distribute installed.
[00:33] <maxb> huh
[00:34] <wgrant> Builds were failing a couple of weeks ago for me because LP wants zope.interface 3.5.2, while Lucid has 3.5.3.
[00:34] <maxb> how odd. I can't even run bootstrap.py without hacking ez_setup.py
[00:34] <wgrant> What's the error you're getting now?
[00:34] <wgrant> Right, I was in that situation for a while.
[00:34] <wgrant> But it works now.
[00:35] <maxb>     PYTHONPATH=ws.find(pkg_resources.Requirement.parse('setuptools')).location)
[00:35] <maxb> AttributeError: 'NoneType' object has no attribute 'location'
[00:35] <maxb> ugh, how mysterious
[00:36] <wgrant> Yeah, that one...
[00:36] <wgrant> It was never particularly reproducible.
[00:37] <maxb> perplexing. ok.
[00:38] <sidnei> maxb, i think gary was working on that issue. he helped me get past that on lazr-js
[00:39] <maxb> I would imagine so. Poor gary gets stuck with all the buildout insanity :-)
[00:39] <sidnei> maxb, if you fetch the bootstrap.py from lp:lazr-js it *might* work, though the command line options changed a little bit.
[00:39] <maxb> that could be interesting
[00:57]  * thumper drags attention back to email jobs
[01:24] <thumper> utilities/ec2 land --dry-run lp:~james-w/launchpad/export-code-import
[01:52] <thumper> mwhudson: do you remember the simple way we should be getting a store now? (in a test)
[01:52] <mwhudson> thumper: IStore(ModelClass) ?
[01:53] <thumper> ta
[01:54] <thumper> oh FFS, why is it in canonical.launchpad.interfaces...
[02:07] <wgrant> Is there a place for all that Foundations stuff to go?
[02:13] <thumper> wgrant: like what?
[02:14] <wgrant> thumper: Most of the Foundations stuff still lives in canonical.$NONLOGICALCONGLOMERATIONOFPACKAGES
[02:14] <thumper> wgrant: well, specifics?
[02:14] <wgrant> c.l.webapp
[02:15] <thumper> wgrant: most foundational stuff should go into lp.services
[02:15] <wgrant> The Storm utilities.
[02:15] <thumper> we should probably have lp.services.storm
[02:15] <thumper> lp.app.webapp maybe?
[02:15] <wgrant> Probably.
[02:15] <wgrant> Maybe.
[02:15] <thumper> or lp.services.webapp
[02:15] <mwhudson> and call it something else
[02:17] <spm> lp.services.AAAAAAAAA
[02:18] <spm> oops. did I type that in? sorry....  >:)
[03:36] <mwhudson> gara!
[03:37]  * mwhudson fights the database restore
[03:38]  * wgrant is bemused by the existence of lib/canonical/not-used
[03:38] <wgrant> It contains only an empty directory -- hctapi, of all things.
[03:39] <spm> at least the naming is self-referentially correct :-)
[03:39] <mwhudson> wgrant: i
[03:39] <mwhudson> 'll review a branch removing it
[03:40] <thumper> spm: heh
[03:41] <wgrant> It's also tempting to kill canonical.doap and lp.archivepublisher.library. Both have been untouched and unused for at least four years.
[03:45] <thumper> ✁☹
[03:45] <thumper> silly team inconsistencies with the rest of the codebase
[03:45] <thumper> .teamowner vs .owner for *everything* elase
[03:55]  * thumper pushes up pipe 2 of 4 for email job work
[03:57] <wgrant> thumper: Well, teamowner is special, given that it defines the type of the object.
[03:57] <thumper> wgrant: yeah, I know
[03:58] <thumper> wgrant: it could just be called owner and have the same impact
[03:58] <wgrant> Possibly.
[03:59] <spm> mwhudson: ref the DB restore; also triggered a nagios alert on "staging in restore mode for > 1 hour"; the actual "outage" part of a staging restore was 62 minutes. ouchies. ie sync new code; build it; (~45 mins) alter _new DB's and re-start, ~ 17mins.
[03:59] <mwhudson> spm: ugh
[04:00] <mwhudson> it would be really nice to ratchet make build time down some
[04:11]  * thumper EODs the 1/2 day
[07:59] <jtv> Is launchpad totally unresponsive (beyond the front pages) for anyone else?
[08:00] <wgrant> jtv: WFM
[08:01] <adeuring> good morning
[08:10] <jtv> wgrant: for example, do you get https://code.edge.launchpad.net/launchpad/+activereviews ?
[08:10] <jtv> hi adeuring
[08:10] <adeuring> ji jtv!
[08:14] <spm> jtv: I do/can
[08:15] <jtv> hmm...
[08:15] <jtv> I've got no problem with https to our wikis, or to the front page, but I can't access anything useful on LP
[08:15] <spm> diff browser? and or sniff network traffic?
[08:15]  * wgrant can too.
[08:15] <jtv> time to check /etc/hosts
[08:16] <jtv> /etc/hosts is fine.  :/
[08:16] <spm> jtv: is "I can't access anything useful on LP" some sort of reference to the info hosted by LP? or a network access type of comment? :-P
[08:16] <jtv> spm: I can't access code, bugs, or translations pages for any projects I've tried.
[08:16] <spm> awesome
[08:16] <spm> try a different browser?
[08:16]  * wgrant deletes 10KLOC
[08:17] <spm> wgrant: only 220K more to go!
[08:17] <jtv> spm: heyy, that did the trick!
[08:17] <jtv> so... why doesn't it work in chromium!?
[08:18] <spm> jtv: seriously? oh my. in that case, flush your cache for starters/restart that browser; and if still no joy; zot cookies as well. if STILL no joy; rename that .<browser> dir and start afresh
[08:18] <spm> jtv: you're the developer. debug it! :-P
[08:19] <spm> man, I am *so* going to hell....
[08:19] <jtv> I just did.  It was the browser I had the kanban board open in.
[08:19] <jtv> spm: as opposed to the people who have to work with you?  I wonder what we're being punished _for_ though
[08:19] <snaggen> I'm trying to get launchpad codereviews to work on my own launchpad setup. It currently works on the web and it is sending mails. But how is the replying to the mail part working?
[08:19] <spm> jtv 2, spm 0.
[08:20] <spm> snaggen: there's a processmail script that runs that processes incoming email
[08:20] <jtv> spm: so the trick turns out to be, don't keep leankitkanban.com open any longer than you have to.  With chromium at least you don't need to restart the browser to undo its damage, so that's progress.
[08:21] <spm> snaggen: cronscripts/process-mail.py fwiw
[08:22] <snaggen> spm: but the reply goes to some mp+1@code.launchpad.dev. So I guess I have to have some mailserver running on that host. But is there some procmail to get the mails in to the database or how does that work? or does teh process-mail.py script access to the mailboxes?
[08:22] <spm> jtv: I tried chromium, but with the number of tabs I typically have open; it (impressively!) eats even more memory than firefox
[08:22] <wgrant> snaggen: process-mail.py looks in a mailbox.
[08:23] <spm> snaggen: latter; pop3 I think...
[08:23] <wgrant> See mailbox.txt.
[08:23] <snaggen> wgrant: spm: Thanks for the pointers...
[08:24] <spm> np
[08:24] <spm> and on that note. dinner beckons. night all.
[09:01] <mrevell> Morning
[09:26] <bigjools> morning
[09:26] <wgrant> Morning bigjools.
[09:27] <wgrant> bigjools/noodles775: What do you think of https://code.edge.launchpad.net/~wgrant/launchpad/show-package-sets-in-queue/+merge/21521?
[09:28] <bigjools> wgrant: looks great, my only question is did you look at the difference in the number of queries made?
[09:28] <bigjools> that page is very, very sensitive to query count
[09:29] <bigjools> i.e. it's close to the timeout limit
[09:29] <wgrant> Hm, I thought that was only when accepting stuff.
[09:32] <bigjools> it's displaying the page
[09:32] <wgrant> It renders in 3 seconds SQL time on edge.
[09:32] <bigjools> we fixed the acceptance issue by making it redirect when the txn finishes
[09:32] <wgrant> Oh, it didn't before?
[09:32] <bigjools> what I am interested in is the increase in queries needed for each row
[09:33] <bigjools> it never used to
[09:33] <wgrant> Crazy.
[09:33] <bigjools> it was fixed just before karmic
[09:33] <bigjools> yar
[09:39] <bigjools> stub: when all references to a libraryfilealias have gone, the gc deletes the files automatically right?
[09:41] <wgrant> bigjools: It adds just one query per source row.
[09:41] <wgrant> And it's pretty trivial as well.
[09:42] <bigjools> wgrant: ok that's fine then cheers
[09:51] <wgrant> bigjools: Do you have a solution to build start time estimation with builder pools?
[09:51] <bigjools> wgrant: nope
[09:52] <bigjools> wgrant: btw can you get another reviewer to check out your +queue change please, I am sprinting
[09:52] <bigjools> soryr
[09:52] <wgrant> I've been wondering how to do it for multi-arch builders, and it seems to be a similar sort of problem :/
[09:52] <bigjools> sorry, too
[09:52] <wgrant> bigjools: Oh, I intended to.
[09:52] <bigjools> yes it's kinda hard
[09:52] <wgrant> Just wanted you to OK it.
[09:53] <bigjools> cool thanks for asking :)
[09:53] <wgrant> I can't see an obvious way to do it apart from a full simulation.
[09:53] <bigjools> it's a *estimation* :)
[09:55] <wgrant> jtv: The 'building' icon spacing on https://edge.launchpad.net/builders seems a bit broken. Is that related to your changes?
[09:56] <jtv> wgrant: yes, it is.  How appropriate it is depends a bit on your perspective: it's the build status, so I'm displaying it as part of the link to the build.  It did simplify the code.
[09:57] <jtv> wgrant: in fact this is the subject matter of a UI review that's currently somewhere in limbo.
[09:57] <wgrant> jtv: The current spacing is definitely broken. I think the ordering is too, but that's up for debate.
[09:58] <jtv> wgrant: I don't think I changed the ordering... did I?
[09:58] <wgrant> It was '( ) Building _blah blah blah i386_'
[09:58] <wgrant> It is now 'Building ( )_blah blah blah i386_'
[09:59] <jtv> wgrant: oh, sorry, misunderstood you earlier.  That's the part I was talking about all along.
[09:59] <wgrant> jtv: Why does it make the code simpler?
[09:59] <wgrant> Because it was looking at the build status to generate the icon?
[10:00] <jtv> wgrant: and because it was easier to have a link formatter for builds.
[10:01] <wgrant> jtv: Argh, where's the template for that?
[10:01]  * wgrant cannot find it.
[10:01] <jtv> builder-index.pt
[10:03] <wgrant> jtv: Looks like buildfarmbuildjob-current.pt
[10:03] <jtv> ah yes, that's where the link happens now.
[10:03] <jtv> That was another thing: we can't show that icon for a buildless job.
[10:04] <jtv> So that's another way in which it belongs to the build, not the builder.
[10:04] <wgrant> So, I think we should do what is done for the rest of the states.
[10:04] <wgrant> And just use the currentlybuilding icon if there's a job assigned.
[10:04] <wgrant> Regardless of state.
[10:04] <jtv> That's fine by me.
[10:04] <noodles775> jtv: did you update the MP with the instructions for demoing it that we discussed? I won't get to it while sprinting, but there are quite a few people around who can do it?
[10:04] <stub> bigjools: yes, after while.
[10:04] <noodles775> Although, I now it'll be a separate MP.
[10:05] <jtv> noodles775: alas, no.  Catastrophic system failure & bad telephone line.
[10:05] <noodles775> aha.
[10:05] <jtv> Not fun, being negotiated down to 1mbps when you're paying for 12
[10:06] <jtv> while your main system won't boot
[10:06] <wgrant> Ow.
[10:06] <bigjools> stub: ok ta
[10:06] <wgrant> jtv: Ah, so you already hardcode that icon form non-build BFJs?
[10:07] <jtv> wgrant: I _think_ I did that in an earlier iteration but it didn't seem appropriate.
[10:07] <wgrant> It appears to be in devel's buildfarmjob-current.pt
[10:08] <gmb> stub: Question for you re: checkwatches holding transactions open, if you've got a sec.
[10:08] <stub> sure
[10:08] <jtv> wgrant: there was a lot of exploring to get it all in a sort of minimal working shape... I don't mind moving things around a bit now that we have a working situation.
[10:09] <wgrant> Yep.
[10:14] <jtv> henninge: weird...  following the pbuilder instructions, when I exit my chroot and login to it again, I've lost my /etc/hosts patch that ntp needed.  Wasn't --save-after-login supposed to preserve that?
[10:15] <henninge> jtv: yes, I thought so
[10:15] <jtv> maybe --save-after-exec instead?
[10:15] <henninge> but may --login takes the system files and overwrites them on each login?
[10:15] <henninge> jtv: I have not tried that too many times, I admit.
[10:16] <henninge> jtv: try putting it in your own /etc/hosts ...
[10:16] <jtv> will the chroot talk to my local dns!?
[10:17]  * wgrant again points out that you can change the NTP host.
[10:18] <jtv> wgrant: you mean in /etc/ntp.conf?  Or by running an explicit ntpdate?
[10:19] <jtv> Hmm... ntpdate isn't likely to work if it'll compete for a port with the host ntpd
[10:19] <stub> Damn Internet is a yoyo. I must be wearing the wrong colour shirt.
[10:19] <wgrant> jtv: By altering /etc/launchpad-buildd/default
[10:19] <jml> http://paste.ubuntu.com/397153/
[10:19] <jml> http://paste.ubuntu.com/397153/
[10:19] <jml> http://paste.ubuntu.com/397153/
[10:20] <jml> http://paste.ubuntu.com/397153/
[10:20] <jtv> wgrant: ntphost?  That's set to pool.ntp.org btw
[10:20] <jtv> wgrant: which is what I'd hope for, I guess
[10:20] <wgrant> jtv: Then you shouldn't need stuff in /etc/hosts.
[10:20] <henninge> jtv: that's true
[10:22] <henninge> jtv: I suspect that pbuilder updates the /etc/hosts, /etc/hostname, /etc/resolv.conf on each --login. That's why I was suggesting putting it there.
[10:23] <jtv> wgrant: I have to get some food soon...  could you file a bug for the build[er] status icon?
[10:23] <wgrant> jtv: Will do.
[10:23] <jtv> thanks.
[10:23] <jtv> noodles775: how about we call wgrant's feedback a UI review?
[10:23] <wgrant> Hmm. There is no appropriate project any more :(
[10:24] <jtv> wgrant: yeah... I've been dealing with that by calling it Soyuz.
[10:24] <wgrant> I guess the views live in soyuz until somebody bothers to move them, so it can go there.
[10:28] <jml> mwhudson, are you still around?
[10:28]  * jml wants to know in how many places we've implemented two-stage kill
[10:35] <noodles775> jtv: yeah, it's definitely valuable, so add it to the MP (when you create it, it'll make it much easier for a ui-reviewer to approve it :)
[10:38] <gmb> stub: Sorry; didn't see your reply. So, my question:
[10:39] <bigjools> jtv: are you going to fix that icon problem on /builders?
[10:39] <gmb> stub: We know that checkwatches has a habit of holding transactions open whilst it does network stuff, which is Bad. However, we're not sure under what circumstances the transaction killer will come in and stomp on us. As far as we can tell, the first time we access a Storm object a new transaction is started, is that correct?
[10:40] <gmb> (assuming there isn't a transaction already)
[10:42] <stub> gmb: yes
[10:43] <gmb> stub: So if we have a storm object locally, even if we're not updating it, just accessing its attributes, we're essentially going to hold a transaction open whilst we do network stuff that might require data from that object, correct?
[10:43] <stub> From the Zope transaction side of things, yes, from the DB side of things, maybe.
[10:44] <stub> 'maybe' because it will depend if Storm decides it needs to refresh something from the DB for some reason.
[10:44] <stub> Oh... not accessing the store... just the object...
[10:45] <stub> 'maybe' on both counts in that case :)
[10:45] <gmb> stub: Hmm. allenap did some testing last night and it appeared that Storm *always* refreshes from the DB if you access anything other than the ID. Is that not necessarily the case?
[10:46] <allenap> stub: I'll forward you the example I wrote.
[10:46] <stub> I don't know.
[10:46] <gmb> allenap: Ta.
[10:46] <stub> I used to be the one campaigning to not keep objects alive over transaction boundaries :)
[10:49] <jml> heh
[10:50] <jml> why isn't hitchhiker packaged in karmic, dammit
[10:52] <stub> allenap, gmb: Look like it is refreshing, yes. Same behavior with aborting and committing the transaction. Not sure if this is Storm or Storm+SQLObject compatibility standard.
[10:55] <stub> def commit(self):
[10:55] <stub>         """Commit all changes to the database.
[10:55] <stub>         This invalidates the cache, so all live objects will have data
[10:55] <stub>         reloaded next time they are touched.
[10:55] <stub> Looks like Storm default behavior
[10:55] <gmb> Hmph.
[10:55] <gmb> stub, allenap: So, looks like local caching is the way to go. Feels like a bodge, though.
[10:55] <stub> Running checkwatches in autocommit mode might be the simplest solution. It doesn't seem like the sort of problem you need transactional integrity for.
[10:56] <allenap> gmb: Right, the floor is covered in egg shells.
[10:56] <allenap> stub: That sounds good.
[10:56] <stub> Also, consider pulling your objects from the slave and casting them to IMasterStore(obj) before making changes.
[10:56] <allenap> stub: That also sounds good. Will the transaction killer not kill transactions from slave stores?
[10:57] <allenap> stub: And, what's the right way to get checkwatches to run in autocommit mode?
[10:58] <stub> It will, but there is no reason not to use the slave given you are already using possibly out of date information.
[10:58] <stub> We are less aggressive on the slaves, and can be more lenient if necessary.
[10:58] <stub> Sorry... IMasterObject(obj)...
[10:58] <stub> Hmm... it is twisted isn't it.
[10:59] <stub> Oh... it is also using LaunchpadScript as a base. There is an argument in there you can set.
[11:01] <stub> isolation=ISOLATION_LEVEL_AUTOCOMMIT argument to run()
[11:01] <stub> the constant imported from canonical.database.sqlbase
[11:02] <jtv1> bigjools: I'd like to fix that, yes
[11:04]  * gmb -> rebooting for updates
[11:07] <stub> allenap, gmb: Using the slave would be quite simple. Just install the SlaveDatabasePolicy(), and cast objects you need to write to using writable_obj = IMasterObject(object).
[11:08] <stub> with SlaveDatabasePolicy(): [...]
[11:08] <allenap> stub: You're awesome, thank you.
[11:36] <jml> any keen reviewers for https://code.launchpad.net/~jml/launchpad/sftp-poppy/+merge/21627
[11:39] <allenap> jml: I'll do it.
[11:40] <jml> allenap, thanks, but I've already swapped with noodles. your comments are still welcome though.
[11:46] <jtv> henninge, wgrant: http://pastebin.ubuntu.com/397192/  :-(
[11:47] <jtv> slave goes through:
[11:47] <jtv> Iterating with success flag 0 against stage INIT
[11:47] <jtv> Iterating with success flag None against stage UNPACK
[11:47] <jtv> Iterating with success flag 0 against stage CLEANUP
[11:47] <wgrant> jtv: Your verifySlaveBuildID is probably buggy.
[11:47] <wgrant> It's being told to abort.
[11:47]  * jtv looks at the master log
[11:50] <jtv> wgrant: yup, that looks plausible!
[11:50] <jtv> 2010-03-18 18:13:05+0700 [-] Builder 'bob' rescued from 'bf-test-5': 'BuildQueue 5 is not available: Object not found'
[11:54] <jtv> wgrant: I rather suspect that ended up being the job id instead of the buildqueue id...
[11:54] <jtv> Did we mention that this stuff was unnecessary complex?  :-)
[11:54] <jtv> Yup, it's the job id.
[11:57] <wgrant> Heh.
[12:04]  * jtv has to run off for a bit
[12:05] <jtv> make that quite a bit
[12:05] <jtv-afk> danilos: confirmed 539499, fix is on the way.
[12:06] <danilos> jtv-afk, it'd be better if you said "confirmed it's a fluke, fixed it in the wiki page" :)
[12:06] <jtv-afk> danilos: better in what way, given that it's not the truth?
[12:06] <danilos> jtv-afk, better if it was the truth ;)
[12:06] <jtv-afk> wel duh!
[12:09] <wgrant> jtv-afk: There is of course the other matter of lp-buildd being unhappy about being aborted during unpack.
[12:11] <jtv-afk> wgrant: who wouldn't be?
[12:11] <wgrant> Heh.
[12:15] <jtv-afk> It's *just* *not* *fair*.  I tested against this exact problem, and the only way it could have failed to fail is if the job and the buildqueue happened to get the same id.
[12:15] <wgrant> I wondered about how the tests managed to pass.
[12:21] <jtv-afk> Yup.  Same id.  Pure, dumb coincidence.
[12:21] <jtv-afk> I wonder how I'm going to explain this to my reviewer.
[12:21] <jtv-afk> but first, afk.
[12:24] <jml> noodles775, btw, the doc I was showing you is http://www.muthukadan.net/docs/zca.html
[12:24] <jml> noodles775, it's an excellent guide to zope component architecture, imho
[12:30] <jml> the buildbot is broken, is anyone working on it?
[12:38] <jml> bigjools, http://www.kieranholland.com/code/documentation/nevow-stan/#the-tags-module
[12:38] <noodles775> jml: I'm disabling the test that is (apparently) causing the issue.
[13:55] <gmb> noodles775: Did you disable that failing test? db_lp is still in [testfix]
[13:56] <gmb> I mean, I know I can force a build so that I can land a branch, but that seems to be the wrong thing to do.
[14:58] <allenap> stub: Hi. transaction.get()._resources seems to still contain stuff even when isolation is set to auto-commit. Checking with the psycopg connection seems to give me valid information. Do you object if I go back to checking with the raw connection?
[14:58] <stub> In autocommit mode, there is no point doing the checks at all.
[14:59] <stub> I have no objections to reverting to checking the raw connection. You probably need to query the IZStorm utility for all stores and check each of them.
[15:01] <allenap> stub: Okay, cool. It's useful at the moment, during development, to make sure that tests are valid (i.e. using auto-commit). I also want to prevent regression in the future.
[15:02] <rockstar> matsubara-lunch, Ursinha, are we having a production meeting this week?
[15:02] <Ursinha> rockstar: yes sir
[15:02] <Ursinha> rockstar: why?
[15:02] <rockstar> Ursinha, because I'm wondering where everyone is.
[15:03] <rockstar> Oh crap, nevermind.  I forgot that the rest of didn't jump on the DST bandwagon yet.
[15:04] <Ursinha> rockstar: :)
[16:02] <Ursinha> matsubara, stub, check, gary_poster, rockstar, bigjools, sinzui, allenap: hey! what about a production meeting now? #launchpad-meeting @ Freenode
[16:02] <rockstar> Hi
[16:02] <gary_poster> Ursinha: :-) matsubara standing in for me today
[16:02] <Ursinha> thanks gary_poster :)
[16:02] <bigjools> Ursinha: soyuz is sprinting, can you ping me if you need anything
[16:03] <Ursinha> sure bigjools, thanks
[16:03] <bigjools> thanks Ursinha
[16:47] <noodles775> gmb: As you've probably figured by now, I disabled the test with the testfix on devel only.
[16:47] <noodles775> (missed your message earlier).
[16:49] <kfogel> sinzui, in lib/canonical/launchpad/emailtemplates/email-processing-error.txt there is a URL ("https://help.launchpad.net/EmailInterface") that is to a non-existent page.  I can just fix it to include "Bugs", as in "https://help.launchpad.net/Bugs/EmailInterface", but the text around it implies that it's about more than bugs.  Are there any other email interfaces to Launchpad?
[16:49] <kfogel> deryck: (if you know the answer to above, feel free to chime in)
[16:50] <sinzui> kfogel: There is a page about review email command
[16:50] <kfogel> sinzui: thanks
[16:50] <kfogel> https://help.launchpad.net/Code/Review/#Email%20interface
[16:52] <kfogel> frustrating that search (https://help.launchpad.net/HelpOnActions?action=fullsearch&context=180&value=email+interface) doesn't find that page!
[16:55] <sinzui> I only search google to find our content. moin suck
[16:55] <sinzui> kfogel: https://help.launchpad.net/Code/Review
[17:01] <kfogel> sinzui: thanks.  see above; I found it
[17:45] <james_w> is https://code.edge.launchpad.net/~james-w/launchpad/code-imports-use-ibranchtarget/+merge/21651 too big for a single branch?
[17:48]  * james_w thinks of a better way to do it anyway
[17:51] <jml> james_w, it's probably not too big for a branch like that.
[17:51] <jml> james_w, you might want to arrange something with the reviewer though.
[17:51] <james_w> I dropped the makeAnyCodeImport as makeCodeImport means the same thing essentially
[17:51] <jml> james_w, ok.
[17:51] <james_w> if we want the distinction then I can do it as a followup branch
[17:52] <jml> james_w, yeah.
[18:00] <james_w> ok, less than half the size, much better
[18:24] <mwhudson> jml: hi
[18:24] <jml> mwhudson, hi
[18:25] <kfogel> aaaargh.  Is there no way in the help wiki to do a relative link to an anchor on a different page?  E.g., "[[Code/Review/#Email interface|foo]]" ?  It will come out as "https://help.launchpad.net/Code/Review/#Email+interface", which will not work.  But if you put in %20 for the space, it will escape the % and you'll get %2520.
[18:26] <jml> kfogel, don't know, I'm afraid. #moin will probably be able to help though.
[18:27] <kfogel> jml: I'm just adding a manual anchor "<<Anchor(EmailInterface)>>" and linking to that.  Harrumph.
[18:28] <mwhudson> jml: you pang
[18:28] <jml> mwhudson, I did?
[18:28] <jml> mwhudson, hmm. let me consult my oracle.
[18:28] <mwhudson> jml: about 8 hours ago, it has to be said
[18:28] <jml> mwhudson, oh yes. in how many places have we implemented two-stage kill?
[18:30] <jml> mwhudson, because I did a thing.
[18:31] <jml> mwhudson, https://code.edge.launchpad.net/~jml/launchpad/sftp-poppy/+merge/21627
[18:31] <jml> mwhudson, guess why the librarian was always taking 5s to shut down?
[18:34] <james_w> jml: I don't think tachandler can import from lp
[18:35] <jml> james_w, why not?
[18:35] <james_w> I'm just finding the bug
[18:35] <james_w> it's used on machines that don't have the full lp source tree available
[18:36] <jml> james_w, !!!
[18:36] <mwhudson> jml: um, did it send a signal then wait 5 seconds to see if it had died yet?
[18:36] <mwhudson> there should be a comment in tachandler saying this
[18:36] <jml> mwhudson, it sent a signal, didn't allow the zombie to be reaped, then kept polling every .1s for 5s to see if the zombie had gone yet (which it won't have)
[18:36]  * mwhudson cries
[18:37] <jml> there should be a comment in lp.services.osutils and maybe a unit test
[18:37] <jml> or we could just fix whatever bug it is that forces us to duplicate code this way.
[18:38] <mwhudson> the issue is that tachandler is used on the buildds
[18:38] <jml> I mean, exactly how many more things do we need other than the vast size of our code base to block us from having a well organized code base
[18:40] <jml> mwhudson, so tachandler should be in a separate tree then, I guess.
[18:40] <mwhudson> there is a difference between what we want and what we get :/
[18:41] <jml> mwhudson, indeed.
[18:42] <james_w> jml:  bzr diff -r 10137..10137.2.2
[18:42] <mwhudson> jml: as a hack to get this landed, you could define the functions in tachandler, but still put them in lp.services.osutils.__all__
[18:42] <jml> mwhudson, yeah, that's what I was thinking
[18:42] <jml> mwhudson, although, it's running through ec2 test right now
[18:43] <jml> is there a test that will block this landing?
[18:43] <mwhudson> unlikely
[18:44] <mwhudson> i
[18:44] <jml> :( :( :(
[18:45] <mwhudson> i'm not really sure how you could write one, i guess you could execute a script that goes "import _pythonpath; from daeamons import tachandler; import sys; assert 'lp' not in sys.modules"
[18:45] <jml> well, it's not even clear to me what the constraints are for the buildd
[18:45] <jml> or what bits of launchpad it actually uses.
[18:47] <mwhudson> jml: i believe you are physically close to people you can beat into telling you
[18:47] <jml> mwhudson, yes. I might have to do that.
[18:47] <jml> mwhudson, anyway, aside from that
[18:47] <mwhudson> i think the only think it uses outside canonical/launchpad/build is tachandler though
[18:47] <jml> mwhudson, how many two-stage kill implementations do we have in Launchpad?
[18:47] <mwhudson> s/think/thing/
[18:47] <james_w> I guess at one point it may have been desirable to stop people catting the LP tree while their package was building
[18:48] <mwhudson> james_w: also, launchpad doesn't install so well on HPPA
[18:48] <mwhudson> jml: um, at least two i guess>
[18:48] <mwhudson> ?
[18:49] <jml> mwhudson, where's the other one?
[18:49] <mwhudson> jml: twistedsupport
[18:49] <jml> oh of course
[18:49]  * jml looks
[18:51] <jml> mwhudson, btw, did you see the dependency graph?
[18:51] <mwhudson> jml: only enough to notice that eog is an awful svg viewer
[18:54] <jml> mwhudson, use dotviewer from pypy
[18:57] <mwhudson> jml: if you insist
[18:59] <jml> mwhudson, pypy is a python interpreter written in python, it's pretty cool
[18:59] <jml> mwhudson, :P
[18:59] <mwhudson> heh heh
[18:59] <jml> mwhudson, Although see their current topic, "PyPy is a actually a visualization project, we just build interpreters to have interesting data to visualize"
[18:59] <mwhudson> :)
[19:00] <mwhudson> #pypy has a history of nicely surreal topics
[19:00] <mwhudson> jml: it is entertaining how lp.testing is in the centre
[19:04] <jml> mwhudson, yeah. also canonical.launchpad needs to die.
[19:05] <mwhudson> well yes
[19:09] <jml> man this buildd thing has made me angry
[19:24] <kfogel> intellectronica: ayt?
[20:15] <mwhudson> thumper: hello?
[20:38] <james_w> jml: perchance still around?
[20:48] <thumper> morning
[20:51] <james_w> morning thumper
[20:52] <thumper> hi james_w
[20:52] <james_w> thumper: could you perhaps provide a little SQL help?
[20:53] <thumper> sure
[20:54] <james_w> CodeImportSet.composeQueryString() assumes a Product, but that will no longer always be true in my branch
[20:54] <james_w> I need to rewrite the query to allow for using SourcePackage as well
[20:55] <thumper> ok
[20:55] <thumper> james_w: I'm just looking at your code import target branch
[20:55] <thumper> hmm.. seems to have gone
[20:55] <james_w> great
[20:56] <james_w> I keep screwing up the initial settings and forgetting things like prerequisite branches
[20:56] <thumper> :)
[20:56] <thumper> james_w: can you paste me a link?
[20:56] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/code-imports-use-ibranchtarget
[20:56] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/code-imports-use-ibranchtarget/+merge/21651
[20:57] <james_w> the intention of that one is just to refactor, not allow any new behaviour
[20:58] <james_w> and to make the tests more explicit about if they require the code import to be against a product
[21:06] <thumper> james_w: reviewed
[21:06] <james_w> thanks
[21:06] <mwhudson> flacoste: so buildbot farted again
[21:06] <mwhudson> flacoste: did you read my mail yet? (i only sent it a minute or so ago)
[21:07] <thumper> james_w: composeQueryString needs to die
[21:07] <james_w> even better
[21:07] <flacoste> mwhudson: switching to email...
[21:08] <mwhudson> thumper, james_w: it's used for the search box on https://code.edge.launchpad.net/+code-import-list
[21:08] <mwhudson> but maybe that page needs to die now
[21:08] <mwhudson> (now that (a) we disable failing imports (b) +code-imports is more useful)
[21:08]  * thumper looks at the page
[21:09] <thumper> my vote is kill the page
[21:10] <thumper> +code-imports is where we should add stuff now
[21:10] <james_w> right, a search box isn't too useful as you could go from search->project->branch->info
[21:10]  * james_w starts a new branch
[21:12] <mwhudson> # XXX SteveAlexander 2005-04-11:
[21:12] <mwhudson> # This is a total mess.  I need to work out what this all means.
[21:12] <mwhudson> that's just the sort of thing you want to find!
[21:20] <StevenK> Tests with errors:
[21:20] <StevenK>    test_import_bzrsvn (lp.codehosting.codeimport.tests.test_workermonitor.TestWorkerMonitorIntegration)
[21:20] <StevenK> Awwwww! But I didn't change that bit :-(
[21:22] <mwhudson> StevenK: those tests have a history of intermittently failing :(
[21:22] <mwhudson> StevenK: what was the error?  was this in ec2 ?
[21:22] <flacoste> mwhudson: i followed-up by email with more info
[21:23] <flacoste> mwhudson: i have a solution which looks too good to be true
[21:23] <StevenK> mwhudson: Looks to be "DirtyReactorAggregateError: Reactor was unclean."
[21:23] <mwhudson> flacoste: ah, this patch http://paste.ubuntu.com/397470/ makes the two tests that failed in ec2 pass with the mailqueue read-only
[21:23] <mwhudson> StevenK: !
[21:23] <mwhudson> StevenK: can you pastebin it?
[21:24] <flacoste> mwhudson: good! you'll find a simpler ZCML in my reply
[21:25] <flacoste> mwhudson: i'm fine with you landing this with the simpler ZCML file, we can leave the removal of the possible dead code in sendmail.py for a separate time
[21:25] <mwhudson> flacoste: ah ok
[21:25] <flacoste> since it would require extensive QA to make sure that we didn't break all mail-sending scripts
[21:25] <StevenK> mwhudson: Right, a clag from the log around the error: http://paste.ubuntu.com/397471/
[21:28] <mwhudson> StevenK: interesting
[21:28] <mwhudson> StevenK: looks spurious though
[21:28] <mwhudson> StevenK: can you file a bug with that output in it?
[21:28] <StevenK> mwhudson: Against which bit?
[21:29] <mwhudson> StevenK: launchpad-cpde
[21:30] <mwhudson> flacoste: erm, did you mean include or includeOverrides in your zcml?
[21:30] <mwhudson> oh, it needs to be files= not file= for the glob to work
[21:33] <StevenK> mwhudson: Done, bug 541526
[21:33] <mup> Bug #541526: Test error in test_import_bzrsvn <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/541526>
[21:34] <mwhudson> StevenK: thanks
[21:38] <flacoste> mwhudson: yeah, sorry, this was untested :-)
[21:39] <mwhudson> flacoste: i'll have a merge proposal for you in about 10 seconds...
[21:39] <mwhudson> flacoste: https://code.edge.launchpad.net/~mwhudson/launchpad/more-direct-delivery-pls/+merge/21685
[21:40] <james_w> thumper: what count should be on https://code.edge.launchpad.net/ for imported branches?
[21:40] <james_w> (see the bottom if you have forgotten it was there :-)
[21:41] <flacoste> mwhudson: didn't you want to include something about running tests with chmod -w on the mailqueue dir?
[21:41] <mwhudson> flacoste: hm, maybe, not sure how to arrange that though
[21:42] <flacoste> mwhudson: how did you do it in your tests?
[21:44] <mwhudson> flacoste: i hacked it in ec2test's testrunner and then removed the line from the makefile
[21:44] <flacoste> hmm, right
[21:45] <flacoste> mwhudson: we could check in the BaseLayer.testTearDown that the directory is empty
[21:45] <flacoste> mwhudson: or change permission in BaseLayer.testSetUp and restore them in testTearDown
[21:46] <mwhudson> flacoste: so something like this: http://paste.ubuntu.com/397482/
[21:46] <flacoste> mwhudson: that's even simpler
[21:48] <mwhudson> i guess it won't help people who don't use ec2 for their tests
[21:48] <thumper> james_w: my suggestion would be working code imports
[21:48] <flacoste> mwhudson: one problem at a time :-)
[21:48] <mwhudson> flacoste: heh ok
[21:49] <mwhudson> flacoste: ok, pushing that change, merge proposal diff will update in a sec
[21:49] <james_w> thumper: just a count of all imports in the REVIEWED state?
[21:49] <thumper> james_w: yeah
[21:49] <thumper> what is it now?
[21:49] <james_w> all "active"
[21:50] <james_w> so REVIEWED and not for deactivated products/projects
[21:50] <james_w> and tried at least once
[21:50] <kfogel> Do we have a standard javascript equivalent of python's string.strip() method?  (strip leading/trailing whitespace, including newlines)?
[21:50] <james_w> so REVIEWED is a fine approximation in my opinion
[21:51] <mwhudson> REVIEWED is a decent approximation now we mark imports failing automatically
[21:54] <kfogel> ah, trim()
[22:02] <james_w> thumper: https://code.edge.launchpad.net/~james-w/launchpad/code-imports-use-ibranchtarget/+merge/21651 now with less sampledata if you want to re-review
[22:07] <mwhudson> flacoste: ping? https://code.edge.launchpad.net/~mwhudson/launchpad/more-direct-delivery-pls/+merge/21685
[22:08] <flacoste> mwhudson: sorry, forgot to approve it!
[22:08] <flacoste> done
[22:08] <mwhudson> ta
[22:14] <james_w> and I'm throwing https://code.edge.launchpad.net/~james-w/launchpad/remove-code-import-list/+merge/21690 at ec2 to look for fallout
[22:19] <maxb> jml: launchpad-dependencies shouldn't have an ubuntu1 suffix
[22:50] <mwhudson> that didn't help
[22:51] <thumper> mwhudson: the split?
[22:51] <mwhudson> thumper: hi
[22:51] <mwhudson> that was all a bit off
[22:51] <mwhudson> odd
[22:51] <mwhudson> thumper: i reviewed your branch anyway
[22:51] <thumper> mwhudson: yeah, saw that, thansk
[22:54]  * thumper goes to fire off three headless tests