[00:01] <lifeless> who is vikram
[00:01] <lifeless> and why are they marking malone bugs 'in progress'
[00:01] <lifeless> bug 420799 and bug 420807
[00:01] <mup> Bug #420799: bug lists - undecided complete bugs should sort above critical <Launchpad Bugs:In Progress> <https://launchpad.net/bugs/420799>
[00:01] <mup> Bug #420807: in bug lists, fix committed bugs should sort higher <Launchpad Bugs:In Progress by dhillon-v10> <https://launchpad.net/bugs/420807>
[00:04] <lifeless> abentley: evening
[01:37]  * wgrant wishes for an "undo that user's actions" button in malone.
[05:31] <lifeless> wgrant: oh?
[05:36] <wgrant> lifeless: Some triagers like to do bad things.
[05:37] <wgrant> Like removing bugwatches and invalidating all three tasks on a needs-packaging bug, just because a five-year-old version was removed two years ago.
[05:38] <wgrant> (even though that bug had a comment a week ago saying that the new package was almost done)
[05:39] <lifeless> ugh
[05:40] <lifeless> wgrant: have you seen this dhillon-v10 around?
[05:40] <lifeless> 09:01 < lifeless> who is vikram
[05:40] <lifeless> 09:01 < lifeless> and why are they marking malone bugs 'in progress'
[05:40] <lifeless> 09:01 < lifeless> bug 420799 and bug 420807
[05:40] <mup> Bug #420799: bug lists - undecided complete bugs should sort above critical <Launchpad Bugs:In Progress> <https://launchpad.net/bugs/420799>
[05:40] <mup> Bug #420807: in bug lists, fix committed bugs should sort higher <Launchpad Bugs:In Progress by dhillon-v10> <https://launchpad.net/bugs/420807>
[05:41] <wgrant> lifeless: I wondered that myself.
[05:42] <wgrant> All I've seen is those two.
[05:42] <wgrant> Makes no more sense to me than it does to you.
[05:42] <wgrant> Ah, there's a post on lp-users.
[05:47] <lifeless> he sure is enthusiastic
[05:48] <lifeless> [just catching up on bug mail :P]
[05:51]  * wgrant ventures into the buildd code.
[06:03] <jml> wgrant, good luck!
[06:44] <wgrant> 'ubounty'. Nice.
[06:45] <lifeless> its a bit like ubuty
[06:45] <wgrant> I'm disappointed that there were only two different spellings.
[06:45] <wgrant> Not creative enough.
[06:45] <jml> :)
[06:45] <jml> hmm. that reminds me, I should fix up the failing tests in my bounty removal branch.
[06:46] <lifeless> ubuty would be valid straine though
[06:46] <wgrant> jml: Kill it!
[07:02] <wgrant> Why's db-devel so out of date?
[07:05] <jml> wgrant, the normal answer is conflicts between stable & db-devel
[07:05]  * jml checks to see if the answer is correct this time
[07:06] <jml> hooray, both builds are broken.
[07:06] <wgrant> Yay!
[07:09]  * jml misses PQM
[07:39]  * wgrant looks for the 'spin and eat disk for several minutes' statement in security.py
[07:43] <lifeless> 'sql'
[07:56] <mwhudson> looks like i killed the db_lp builder yesterday :(
[07:58] <mwhudson> and the thing that merges stable into db-devel seems to have gone away too ?
[07:59] <wgrant> mwhudson: Ahah. That would explain it.
[11:14] <lifeless> anyone else seeing the top of edge pages borked /
[11:18] <thekorn> yes
[11:22] <wgrant> lifeless: That's normal.
[11:22] <wgrant> lifeless: It's the new breadcrumbs interacting badly with the old 2.0 views.
[11:22] <wgrant> Hopefully they'll all be 3.0 in a couple of weeks.
[11:23] <lifeless> \o/ hit the bottom the yak shaving stack for today
[11:24] <lifeless> 'glue subunit to pqm' -> 'update pqm clean bugs prep the work area' -> 'release new config-manager' -> 'update the package cause it was removed from debian' -> 'uploaded!'
[11:24] <wgrant> Nice.
[11:24] <lifeless> so, we're down to wrapping up  'glue subunit to pqm' -> 'update pqm clean bugs prep the work area'
[11:25] <lifeless> then I can finally do what I wanted to do.
[11:45] <lifeless> I spoke to soon
[11:46] <lifeless> need to do a subunit snapshot :P
[16:53] <maxb> I see devel != stable at the moment, what's broken, the buildbot or the tests?
[16:59] <gary_poster> maxb: for that side, the tests.  devel has 14 failures and 10 errors.  (meanwhile, db-devel had a bzr failure, so on that side the machinery failed rather than the tests)
[17:01] <gary_poster> for ref, http://pastebin.ubuntu.com/261505/
[17:02] <gary_poster> (we'd like buildbot to be public too; need some work to do that, particularly upgrading to recent buildbot deb.  That might be in progress.)
[17:23] <maxb> thanks
[17:23] <maxb> ooi, do you have plans for severing the remaining dependencies on non-egg zope?
[17:23] <maxb> (ThreadedAsync and docutils)
[18:03] <maxb> Is anyone else being bombarded by 'lp-sourcedeps/eggs/zope.viewlet-3.4.2-py2.5.egg/zope/__init__.py:3: UserWarning: Module lazr was already imported from None, but /home/maxb/launchpad/lp-branches/python2.5/lib is being added to sys.path' ?
[18:16] <gary_poster> maxb: bombarded: no, but I know the general cause of that symptom.  I have a branch that should make that particular example of it go away (by moving lazr.* stuff to zc.buildout).  I actually tried to land it Friday but there are some broken lazr.* distributions (they build by trying to go over the net, and we don't allow that) that I'm fixing now.
[18:17] <maxb> hmm. I get it in several tests, which causes them to then fail since their output is not as expected
[18:20] <gary_poster> maxb: docutils is already provided by eggs.  Not removing the docutils symlink was an oversight, probably of mine.
[18:20] <maxb> easy to fix, then :-)
[18:21] <gary_poster> maxb: yeah. :-) zope has moved past ThreadedAsync, and it is not packaged.  ISTR we still use it.  That should be investigated, and removed now if easy, soonish if not so easy.
[18:21] <maxb> grep suggests only used by poppy
[18:29] <maxb> Well here's a bit of a headscratcher... lib/lp/bugs/tests/../doc/bug-export.txt is broken by splitting a single try: except: block across multiple doctest examples by erroneously using all >>>, instead of ... for the continuation lines.
[18:29] <maxb> Except it passes when run under the lp testsuite under python2.4
[18:29] <maxb> But the syntax does NOT parse with plain old python2.4 doctest!
[18:29] <gary_poster> maxb: broken tests: we already filter that warning out *lots* of places.  if you grep for 'was already imported from' you'll see 'em.  I'm surprised we haven't caught the ones you see, because yeah, they make the tests fail.  Maybe it is a 2.5 thing.  You can at least see how to silence the warnings from the grep results.
[18:30] <gary_poster> maxb: we use zope's fork of doctest with new features.  perhaps it has the usual problems with a fork.
[18:31] <maxb> Aha... whereabouts in all of zope should I be looking for that?
[18:31] <gary_poster> zope.testing.doctest
[18:33] <gary_poster> maxb: Is the ThreadedAsync/poppy thing a problem for py 2.5/2.6?
[18:34] <maxb> No - it's just a little crazy to be depending on the zope branch just for 2 files
[18:41] <gary_poster> maxb: eek!  the fact that it is working for everyone is an accident, then.  Deployment is accidentally fine because we use a different mechanism for sourcecode, and old dev instances are fine because they still have zope hanging around, but if somebody new tried to build lp right now it would break for them because it wouldn't get zope, and poppy needs it apparently.  I removed the code that updates the zope branch.
[18:41] <gary_poster> thanks for bringing that up.  That's probably my first priority now.
[18:42] <gary_poster> buildbot and ec2 use the same mechanism as deployment, kinda sorta
[18:42] <gary_poster> ec2test I mean
[18:45] <gary_poster> so on the bright side, those symlinks will be gone no later than Tuesday ;-)
[19:11] <ddaa> Hey there
[19:11] <ddaa> I'd like to know if it's something wrong here, or if it's a known problem
[19:12] <ddaa> but the windmill test suite does not appear to pass here
[19:12] <ddaa> I run it with bin/jstest
[19:13] <ddaa> And it ends telling me "Failed: 3 test suites failed"
[19:13] <ddaa> I ran a rocketfuel-get to get the latest code just before starting the test suite
[19:14] <ddaa> currently launchpad r9264
[19:14] <ddaa> Are the jstests deprecated?
[19:14] <ddaa> Or something?
[19:15] <gary_poster> ddaa: last I heard about this was when someone was talking about starting to fix this, about three weeks ago.  That person has had to go to other plans for now.  I would not be surprised if it fails, but I do not know.  It won't truly be part of our system until the test pass and buildbot (or something else like that) runs them regularly.  It's worth asking Monday when more folks will be around.  If you ask me then I can try
[19:15] <gary_poster> direct you.
[19:15] <gary_poster> direct the question I mean
[19:16] <ddaa> yeah, I figured that it was not run by the pqm because it's not in what "make check" does.
[19:16] <gary_poster> right
[19:17] <ddaa> Right now I'm in a sprint with afpy folks (the french python user group) and I'm in a track to evaluate selenium/windmill etc.
[19:17] <ddaa> I figured I should start by looking at how launchpad did it, knowing how the folks are fanatical about test coverage.
[19:17] <ddaa> Frankly, I'm very disappointed by what I say.
[19:18] <ddaa> By what I saw.
[19:21] <ddaa> To get those failure I needed to fix a very trivial import bug.
[19:24] <ddaa> http://python.pastebin.com/m34a9f134
[19:24] <ddaa> It's kinda weak to find a bug like this in launchpad mainline :(
[19:27] <gary_poster> ddaa: Thank you for highlighting this (and the patch).  We are fairly fanatical about test actually, yes, but the person in charge of that part of the effort has been pulled away from it unavoidably (and temporarily), and we've had some other changes that made us drop that ball.  We'll pick it back up starting Monday.
[19:27] <gary_poster> meanwhile, must run.
[19:44] <maxb> LP thinks the development focus series for LP itself is 2.1, someone should probably flip that to 3.1