[00:04] <poolie_> whos' the on-call reviewer? does that concept still exist?
[00:06] <lifeless> thumper: http://nosql.mypopescu.com/post/619181345/nosql-graph-database-matrix
[00:06] <lifeless> poolie_: it does, check #launchpad-reviews or the wiki page
[00:07] <poolie_> it's '-'
[00:07] <poolie_> ok
[00:07] <mwhudson> poolie_: that concept exists, but not really in this timezone
[00:08] <lifeless> poolie_: that means noone is on.
[00:08] <mwhudson> poolie_: i can probably take a look for you
[00:08] <lifeless> mwhudson: lp in pypy would be intereseting
[00:08] <lifeless> mwhudson: so would lp in jython
[00:08] <mwhudson> lifeless: right away, you need psycopg2
[00:08] <poolie_> thanks mwh
[00:09] <mwhudson> i'm not sure what else we have in the way of mandatory c extension modules
[00:09] <poolie_> mwhudson, could you sponsor landing https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173
[00:10] <mwhudson> poolie_: i think you meant to propose against devel, not db-devel?
[00:10] <poolie_> yes
[00:10] <poolie_> i don't know why db-devel is the defalut
[00:10] <poolie_> (well, i do; i think it's a bad default though)
[00:11] <poolie_> i guess i can re-propose it?
[00:12] <mwhudson> that's probably easiest
[00:13] <poolie_> ok https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
[00:13] <rockstar> wallyworld, I've made myself available for you this evening in case you get stuck, although you may have plenty of people around.
[00:13] <poolie_> hello rockstar
[00:13] <mwhudson> poolie_: ta
[00:14] <rockstar> poolie, hi
[00:14] <wallyworld> rockstar: thanks for the kind offer. i don't think i'll need you. feel free to have a glass or three of good wine without any guilt :-)
[00:15] <mwhudson> that would not be the guilt you are looking for, i suspect
[00:15] <rockstar> Hello quotes page...
[00:16] <mwhudson> poolie: i don't mean to be a pain, but i'm not sure that comment you're adding makes sense, has it lost its first line or something?
[00:20] <mwhudson> make is blowing up for me
[00:20] <mwhudson> IOError: [Errno 2] No such file or directory: 'lazr-js/build/choiceedit/assets/skins/sam/choiceedit-skin.css'
[00:21] <rockstar> mwhudson, is this in launchpad or lazr-js?
[00:21] <mwhudson> rockstar: launchpad
[00:21] <rockstar> mwhudson, shite.
[00:22] <mwhudson> rockstar: ah
[00:22] <mwhudson> $ ls -l lazr-js/build/choiceedit/assets/skins/sam/
[00:22] <mwhudson> total 8
[00:22] <mwhudson> -rw-r--r-- 1 mwh mwh 871 2010-09-24 11:20 choiceedit.css
[00:22] <mwhudson> lrwxrwxrwx 1 mwh mwh 101 2010-02-26 13:42 choiceedit-skin.css -> ../../../../../../eggs/lazr_js-0.9.2-py2.5.egg/lazrjs/choiceedit/assets/skins/sam/choiceedit-skin.css
[00:22] <rockstar> mwhudson, yeah, this is stuff I'm going to attack tonight.
[00:22] <mwhudson> rockstar: i just thought "you know, why don't i delete all these py2.5 eggs"
[00:23] <rockstar> mwhudson, hahaha.
[00:23] <rockstar> mwhudson, I HATE HATE HATE that we have to eggify javascript.
[00:23] <mwhudson> so this is one of those, we use make, kinda sorta problems
[00:23] <mwhudson> rockstar: yeah, i know
[00:23] <wgrant> mwhudson: Local codebrowse worked for me last week.
[00:23] <wgrant> But I haven't tried it since.
[00:23] <mwhudson> wgrant: ok cool
[00:30]  * rockstar relocates
[00:43] <mars> mwhudson, what exactly is a 'we use make' sorta problem?
[00:45] <mwhudson> mars: make traditionally tracks dependencies
[00:45] <mwhudson> so if you edit foo.c, foo.o gets rebuild and the foo binary gets relinked
[00:45] <mwhudson> mars: but if you edit versions.cfg and run make, we don't get that kind of effect
[00:45] <mwhudson> well maybe in that precise case we do, but in general we don't
[00:45] <mars> ah, yes.  foo.js gets lint, minified, concatenated, etc.
[00:46] <mars> yes, that makes sense, especially since most projects treat JavaScript as a compiled language now
[00:46] <lifeless> we could use make properly if we wanted
[00:47] <mwhudson> let's use automake!!1!
[00:47] <mars> as for make versus bin/buildout - that is something I haven't managed to figure out - both have advantages and drawbacks
[00:47] <mwhudson> (not really)
[00:47] <lifeless> mwhudson: I said properly.
[00:48] <mwhudson> one of the things i always liked about the cpython dev community: the appropriate amount of disdain for automake and libtool
[00:50] <mars> lifeless, the problem with Make is that we did use it, but it is a rather special language, and I gather not everyone knows how to use it well
[00:50] <poolie> mwhudson: i'll look
[00:50] <mars> lifeless, so our use of Make was not great
[00:50] <poolie> mwhudson: i have an autographed copy of the autotools goat book saying "I hope you never use this book -- Ben"
[00:51] <mwhudson> :-)
[00:52] <poolie> mwhudson: it's not cropped, it's just not a complete punctuated sentence
[00:52] <poolie> which jml told me the other day is the lp style
[00:52] <poolie> i can fix that
[00:52] <mwhudson> poolie: thanks
[00:53] <mwhudson> poolie: i'm not sure being a grammar nazi to the extent lp does is wise, but i do actually find that comment a bit hard to interpret
[00:54] <poolie>     166     while open_readers:
[00:54] <poolie>     167         # select() blocks for a long time and can easily fail with EINTR
[00:54] <poolie>     168         # <https://bugs.launchpad.net/launchpad/+bug/615740>.  Really we
[00:54] <poolie>     169         # should have EINTR protection across the whole script (other syscalls
[00:54] <poolie>     170         # might be interrupted) but this is the longest and most likely to
[00:54] <poolie>     171         # hit, and doing it perfectly in python has proved to be quite hard in
[00:54] <_mup_> Bug #615740: test_on_merge.py doesn't handle eintr <Launchpad Foundations:In Progress by mbp> <https://launchpad.net/bugs/615740>
[00:54] <poolie>     172         # bzr. -- mbp 20100924
[00:54] <poolie> is that clearer?
[00:55] <mwhudson> poolie: yes, that's much nicer, thanks
[00:55] <poolie> when you start insisting on passive voice i'll worry :)
[00:55] <mwhudson> poolie: i think i just wanted a subject for "blocks" really
[00:55] <poolie> 'lego'
[00:59] <poolie> anything else?
[01:04] <lifeless> how busy is staging db right now ?
[01:06] <wgrant> Hm.
[01:06] <wgrant> Debian just started running apt-ftparchive in parallel.
[01:06] <wgrant> That's actually not a bad idea.
[01:12] <rockstar> bzr is MUCH slower when I run `make schema` at the same time.
[01:12] <mars> rockstar, check your loadavg
[01:13] <rockstar> mars, I'm being a bit facetious.  EVERYTHING is much slower when running `make schema`
[01:13] <mars> :)
[01:13] <rockstar> I just wanted to rag on the bzr team for not being fast enough.
[01:14] <lifeless> :(
[01:15] <rockstar> lifeless, :)
[01:31] <poolie> rockstar: you could iorenice psql
[02:16] <lifeless>     Hard / Soft  Page ID
[02:17] <lifeless>      129 /  224  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[02:17] <lifeless>      108 /   19  DistributionSourcePackage:+filebug
[02:17] <lifeless>      107 /  319  BugTask:+index
[02:17] <lifeless>       58 /   13  Distribution:+search
[02:17] <lifeless>       18 /   15  Archive:+copy-packages
[02:17] <lifeless>       16 /   44  Milestone:+index
[02:17] <lifeless>       16 /    9  DistroSeries:+queue
[02:17] <lifeless>       13 /    5  Person:+bugs
[02:17] <lifeless>       11 /  103  RootObject:+login
[02:17] <lifeless>       11 /   29  Archive:+packages
[02:40] <rockstar> poolie, ah! iorenice is quite cool.
[02:49] <rockstar> For creating new database models, do we still want to use SQLBase?
[02:49] <rockstar> lifeless, ^^ I seem to recall some discussion about performance issues with the sqlobject compatibility layer.
[02:53] <wgrant> All my new stuff has descended from Storm.
[02:53] <rockstar> wgrant, yeah, that's what I was wondering.
[02:54] <lifeless> we need a base class
[02:54] <lifeless> anything using just storm is buggy
[02:54] <wgrant> Even if you're not using cachedproperty?
[02:54] <rockstar> lifeless, ELACKOFCLEARANSWER
[02:54] <lifeless> because it doesn't do IPropertyCacheManager(self).clear() on __storm_invalidate__
[02:56] <lifeless> rockstar: so, I guess I'm saying 'use SQLBase' or 'add a base class we can use with no gunk, and a storm invalidate hook'.
[02:56] <lifeless> it would be nicer still to tell storm to have a global invalidate hook, I guess
[02:58] <rockstar> lifeless, is there an example of a storm invalidate hook somewhere?  I guess I have no idea what that entails.
[03:07] <mars> lifeless, how ofter are you running manual rollouts of revs that have passed QA?
[03:07] <mars> 'ofter' - there's a new word
[03:57] <poolie> "works well with otters"
[04:02] <rockstar> mars, lifeless, the test suite seems to be running faster on ec2.  If you did that, THANK YOU.  If you didn't, say you did.
[04:21] <wgrant> mars: Why are the QA reports private?
[04:21] <wgrant> They aren't for production-stable, so it seems unnecessary.
[04:23] <mars> wgrant, they don't have a good public home yet - we want to set up lp-qa.canonical.com as a public place to publish them
[04:23] <wgrant> Aha.
[04:38]  * stub wonders where last night's ec2 test run ended up
[05:31] <poolie> mwhudson: can you help me understand the failure from mbp-trivial?
[05:31] <poolie> is it spurious?
[05:31] <mwhudson> poolie: hadn't seen it, one sec
[05:34] <poolie> maybe i should keep a count of how many spurious rejections i get? my guess is around 50% of attempted landings
[05:35]  * mwhudson stares at offlineimap
[05:35] <mwhudson> i wonder what it's doing
[05:35] <poolie> i pasted the summary on https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
[05:36] <mwhudson> poolie: what a helpful failure mode!
[05:38] <poolie> yeah, there are some nasty cases in subunit where it falls in to "lost connection" like here
[05:39] <mwhudson> poolie: i have no reason at all to think that this is anything other than spurious
[05:39] <mwhudson> poolie: i can just shove it back in again if you'd like?
[05:39] <poolie> i guess so :(
[05:39] <poolie> thanks
[05:40] <mwhudson> doing so
[05:41] <mwhudson> having stuff like this officially being Someone Else's Problem is one of the nicest things about no longer being an official launchpad developer
[05:41] <mwhudson> :/
[05:42] <poolie> yeah
[05:42] <poolie> i'm especially grateful for you doing it when you don't really have to
[05:44] <poolie> there's no more information in the subunit stream afaics
[05:53] <poolie> lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/646563 from your comments about testbrowser yesterday
[05:53] <_mup_> Bug #646563: want a way to make a TestBrowser logged in as a particular user <testing> <Launchpad Foundations:New> <https://launchpad.net/bugs/646563>
[06:33] <wgrant> mwhudson: Ahem.
[06:33] <wgrant> Something is wrong with Launchpad, then? :P
[06:34] <mwhudson> wgrant: probably
[06:34] <mwhudson> wgrant: but launchpad at least has the moral position of being large
[06:34] <wgrant> But yes, I don't get that Django thing.
[06:34] <wgrant> It's stupid.
[06:35] <mwhudson> are you criticizing the runserver thing or the whole project? :)
[06:36] <wgrant> The fact that it doesn't serve static media.
[06:36] <wgrant> And its URL system is painfully awful.
[06:36] <wgrant> But apart from that it's not bad.
[06:38] <mwhudson> i think a global settings module is an idea that deserved to be strangled at birth
[06:39] <wgrant> Yes.
[06:39] <wgrant> And its mandatory app structure is inconvenient.
[06:39] <wgrant> I'm struggling with that at the moment.
[07:28] <poolie> if i want to make the feature-rules page visible to only developers, what would be a tasteful way to do that?
[07:29] <poolie> add permission launchpad.Developer and then register an adaptor for it?
[07:32] <wgrant> Hmm.
[07:32] <wgrant> Difficult.
[07:33] <wgrant> Do you have a FeatureFlagSet sort of thing?
[07:33] <poolie> and, to be tasteful, does ~launchpad need to become a celebrity?
[07:33] <poolie> what sort of thing do you mean?
[07:33] <wgrant> ~launchpad should already be a celebrity
[07:33] <wgrant> Well, what does this view live on?
[07:33] <wgrant> ILaunchpadRoot, or something else?
[07:34] <poolie> ILaunchpadRoot
[07:34] <poolie> i'm open to moving it
[07:34] <wgrant> You could for now reuse ILaunchpadRoot's launchpad.Edit
[07:35] <wgrant> It's ~admins + ~registry
[07:35] <poolie> ah yes, so it is
[07:35] <wgrant> It's currently used for managing featured projects.
[07:35] <poolie> ok
[07:35] <wgrant> And is roughtly ~launchpad + ~canonical-bazaar + a few others.
[07:35] <poolie> brilliant
[07:36] <poolie> so it would be launchpad.Edit on the readonly mode
[07:36] <poolie> and launchpad.Admin on the edit mode
[07:36] <poolie> s/mode/form
[07:36] <wgrant> It's a bit of an abuse.
[07:36] <wgrant> Probably.
[08:04] <poolie> wgrant: works for me, thanks
[08:11] <maxb> wgrant: On the offchance you're still around, do you know who needs to be poked about builds that bounce between buildds whilst only pretending to start?
[08:12] <wgrant> maxb: It needs a LOSA to fix, but the first step is to get someone with log access...
[08:12] <wgrant> noodles775: Can you see what's going on?
[08:12] <wgrant> It's been failing like this a bit lately.
[08:13] <noodles775> wgrant, maxb: sure, I'll check the logs - maxb do you have a specific build I can look for?
[08:13] <maxb> noodles775: bzr/proposed PPA, bzr 2.2.1-0~bazaar1~{karmic,jaunty,maverick}1
[08:13] <noodles775> wgrant: do you know the background to the issue (what has been the cause for other builds doing this lately?) - I've been a bit out of the loop.
[08:14] <wgrant> noodles775: I don't know, sorry.
[08:14] <wgrant> adare and ross are known to be problematic, but that doesn't explain PPA builds.
[08:14] <noodles775> Thanks.
[08:15] <noodles775> losa: Hi! is devpad down? I can't ssh to access logs.
[08:16] <spm> yup. probably because yout logged into it noodles775,  you should know by know it's senistive!!!!!
[08:16] <StevenK>   File "/home/steven/launchpad/lp-branches/ids-limit-packagesets/lib/lp/testing/__init__.py", line 78, in <module>
[08:16] <wgrant> devpad seems to have been rather unwell lately.
[08:16] <StevenK>     import fixtures
[08:16] <wgrant> StevenK: make
[08:16] <StevenK> Why does this keep turning up?
[08:16] <wgrant> A new egg was added a few days ago.
[08:16] <noodles775> spm: ;)
[08:16]  * StevenK blames lifeless 
[08:16] <wgrant> That's right.
[08:16] <spm> wgrant: indeed it is. I think everything in the h/w has been replaced and it still smashes.
[08:17] <wgrant> spm: Is crowberry at least happy again now?
[08:17] <spm> not sure. I know stuff was done overnight to make things happier.
[08:23] <noodles775> wgrant, maxb: the most recent build of that package that I can see was dispatched to americium without an issue, but then the next entry for that buildd is: 2010-09-24 07:00:49+0000 [-] <americium:http://americium.ppa:8221/> communication failed (User timeout caused connection failure.)
[08:24] <wgrant> Yay.
[08:26] <maxb> "User timeout" ?
[08:26] <noodles775> losa: it looks like the last build that finished on americium was 3 hours ago: https://edge.launchpad.net/builders/americium/+history
[08:27] <noodles775> Do you have instructions for resetting the buildd, or is it something only lamont does?
[08:27] <spm> depends on how wedged they are
[08:27] <noodles775> It's still trying to build new items.
[08:27] <spm> noodles775: but supposedly it started on a new bzr build 8 mins ago?
[08:28] <spm> or is that the problem? starts but barfs?
[08:28] <maxb> ALSO, the PPA publisher hasn't published something that was accepted 88 minutes ago
[08:28] <noodles775> Yeah, it seems to be.
[08:28] <spm> ahh that sounds like the fun we noticed yesterday
[08:29] <spm> noodles775: can you ensure bigjools knows about the repeat of the fun with find/xargs?
[08:29] <jtv> jelmer: did you Q/A your branch for bug 128259?  The bug is still marked qa-needstesting.
[08:29] <_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
[08:29] <noodles775> jtv: jelmer is not available this week.
[08:29] <noodles775> spm: sure, is there a bug we can collect info on?
[08:29]  * noodles775 looks
[08:30] <jtv> noodles775: argh… afaict that branch is probably keeping >200 revisions from being deployed, including a pressing one I'm trying to get in.
[08:30] <spm> noodles775: unsure. he knows what it is tho. i think he emailed the dev list as well
[08:30] <noodles775> spm: great.
[08:31] <spm> basically publishing/cron.daily-ppa is locking and blocking the publishing for 2+ hours
[08:31] <spm> we don't actually know HOW long for, as we kill it before it finishes.
[08:31] <jtv> noodles775: of course there's more branches waiting for q/a, but I think if we could get this one out of the way it'd make a big difference.
[08:31] <spm> maxb: that should happen "RSN" for values of 'soon'
[08:32] <noodles775> jtv: k - let bigjools know, he'll organise QA for it I'm sure (I can't do it right now).
[08:33] <jtv> noodles775: will do, thanks
[08:33] <wgrant> jtv: Last I heard the plan was to QA that, get it individually CP'd on Monday (so we can roll back easily if necessary), then resume normal mass-CPing once we're confident it works.
[08:33] <wgrant> Since it's a big, risky change.
[08:34] <maxb> spm: thanks
[08:34] <maxb> titanium hasn't built anything for four days
[08:34] <jtv> wgrant: I see…  maybe lifeless will make an exception and still let me cherrypick my fix then.
[08:34] <jtv> (There's a few other branches less far behind that are also blocking mine.  I'm Q/A'ing one of them now.)
[08:35] <maxb> charichuelo nothing for 22 hours
[08:36] <maxb> an awful lot of other buildds claim to not have built anything in 3 hours
[08:37] <noodles775> maxb: yeah, I'm just creating a bug listing all the builders showing that same error... I'll ping you when it's done in case you've more to add.
[08:40] <adeuring> good morning
[08:48] <noodles775> wgrant, maxb, spm: bug 646635 - but checking the histories now looks like communication has been restored between the buildds and the buildmaster?
[08:48] <_mup_> Bug #646635: communication failed - user timeout caused connection failure <Launchpad Auto Build System:New> <https://launchpad.net/bugs/646635>
[08:50]  * wgrant blames Nafallo sleepwalking through the DC and tripping over cables.
[08:51] <noodles775> heh
[08:52] <wgrant> It does look fairly happy now.
[08:52] <wgrant> Hopefully on Monday the latency will disappear, and problems will be a lot more obvious.
[08:59] <mrevell> Good morning
[08:59] <jtv> hi mrevell!
[09:17] <lifeless> wgrant: my bugtask:+index is on on prod, if you're interested.
[09:18] <lifeless> 370 queries for bug/1 still
[09:18] <lifeless> jtv: normal process for cp's applies if the cp isn't listed in https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
[09:18] <lifeless> bbiab
[09:19] <wgrant> ,lifeless It was 600, so that's not too bad.
[09:19] <jml> Greetings Earthlings
[09:19]  * noodles775 wonders what the air is like today in "the hut"
[09:21] <wgrant> Heh.
[09:21] <jml> relatively clear.
[09:22] <jml> updateBuild gets called 12 times over the course of 600 lines of doctest.
[09:23] <poolie> hello jml
[09:23]  * jtv wonders if he falls under "earthlings"
[09:23] <jtv> hi jml
[09:24] <wgrant> jml: Please destroy buildd-slavescanner.txt :)
[09:24] <jtv> lifeless: the one I want to deploy (codehosting only) is 11599.
[09:25] <jml> wgrant, that's basically happening slowly.
[09:25] <wgrant> It's soooo big :(
[09:25] <jml> the problem for me is that I'm not sure whether it's testing the builder itself or binary package build behaviour
[09:25] <jml> probably both. :(
[09:25] <wgrant> Well, they were one and the same.
[09:25] <wgrant> So it's both.
[09:27] <noodles775> I'd assume both - when we factored out the separate behaivours I didn't take the time to do more than ensure the current doctests still passed.
[09:28] <jml> yeah. that sounds right.
[09:28] <wgrant> We destroyed bits of it.
[09:28] <wgrant> But there was so much of it there.
[09:32] <jml> yeah.
[09:32] <jml> in our work here we're getting a little bit closer to separating out the tests into the two layers
[09:32] <maxb> noodles775: shipova just ejected my build, it's now starting again on thorium
[09:32] <jml> there's probably still more that could be done to make the separation of concerns clearer for both for tests and for the interfaces themselves
[09:33] <wgrant> jml: Even just splitting it into unit tests would be a huge step forward.
[09:33] <noodles775> maxb: I'll check the log and confirm whether it's the same and updated the bug. Thanks.
[09:33] <wgrant> So you don't move one test out, and find that something breaks 1000 LINES later.
[09:34] <jml> well also, perhaps it will make the intents of the tests clearer
[09:34] <maxb> noodles775: for the record, that build on shipova had most definitely started. It had been running for an hour, and was displaying build log output
[09:34] <jml> that's the biggest problem here
[09:35] <bigjools> we've already murdered a couple of doctests
[09:35] <wgrant> jml: Right, but making the intet of tests clearer is easier if you can actually change them.
[09:35] <bigjools> it felt good
[09:35] <jml> :D
[09:35] <wgrant> Which is much easier when the doctest isn't 3000 lines.
[09:35] <wgrant> Or was that archive.txt? I forget
[09:37] <bigjools> there are problems in the air today
[09:39] <jml> buildd-slavescanner is now ~800 lines
[09:41] <noodles775> maxb: so you build on shipova looks like something went wrong with the builder itself (or it was manually set to not-ok) - 2010-09-24 08:30:53+0000 [-] shipova was made unavailable, resetting attached job
[09:41]  * noodles775 checks for thorium
[09:44] <bigjools> a load of builders went to Enablement not that long ago
[09:45] <noodles775> bigjools, maxb: that would certainly fit with the fact that shipova is no longer listed.
[09:45] <bigjools> they have the ability to pull builders out of the pool at any time
[09:45] <bigjools> the build has to be re-dispatched elsewhere
[09:47] <jtv> Why does this show devel 11566 as the oldest undeployable revision?  AFAICT r11399 hasn't gone through Q/A yet (though at least one branch for the same bug has)
[09:48] <jtv> Damn, lost the bug now.  Maybe I got it all wrong.
[09:48] <lifeless> jtv: so, 11566 is jelmers half-landed branch
[09:49] <lifeless> jtv: julian is cping it monday
[09:49] <lifeless> jtv: your thing you can cp with the normal process; what I'm doing is doing stuff thta passes under the *new process* which is less exception orientated: I'm finding the glitches so we don't have a panic when we start doing more of it.
[09:51] <jtv> lifeless: I guess this is also going to reduce a lot of the risk of conflicts and false conflicts with cp candidates…  I actually based my branch on devel instead of productiond-devel.
[09:51] <lifeless> jtv: it will help, as long as we don't let it fall behind :)
[09:51] <jtv> quite :)
[10:21] <stub> jml: Seen anything like this? http://paste.ubuntu.com/499557/
[10:22] <jml> stub, what in particular?
[10:22] <stub> It exploded and it is very unclear why
[10:23] <jml> stub, oh, I see it's a make run
[10:23] <jml> stub,
[10:23] <stub> its ec2 land output
[10:23] <jml> stub, I've seen errors like "Usage: test [options]" before. That means zope.testrunner has become confused and isn't spawning child processes properly.
[10:24] <stub> I've tried to submit the branch a few times - same failure each time.
[10:24] <jml> hmm.
[10:24] <jml> stub, what happens when you try locally?
[10:25] <stub> I just did test_layers locally - fine.
[10:26] <stub> I'll try ./test_on_merge.py -vv "--subunit -vvv"
[10:26] <jml> stub, may I see the full subunit output?
[10:27] <jml> stub, I'd be surprised if it's an issue with ec2 test per se.
[10:27] <jtv> Is there any way to figure out if the branch scanner on staging is invoking my ITipChanged handler?
[10:28] <stub> http://paste.ubuntu.com/499560/
[10:30] <jml> looks like it fails fast, at least.
[10:44] <jml> stub, when I try to test your branch locally, I get the same crash with or without subunit
[10:45] <stub> Sorry, distracted. Yes. Fails here too with test_on_merge
[10:48] <jml> stub, I tried "./bin/test -vvv" and "./bin/test -vvv --subunit" fwiw.
[11:59] <deryck> Morning, all.
[12:08] <jtv> good night & good weekend, everyone
[13:14] <gmb> So... now that I've put some code in lazr-js - woot, etc. - how on earth do I get my local copy in my LP branches to use that code?
[13:15] <jml> gmb: versions.cfg; ./bin/buildout; see doc/buildout.txt
[13:17] <gmb> jml, Ta.
[13:17] <deryck> gmb, oh but wait ;)
[13:18] <gmb> Oh bother.
[13:18] <deryck> gmb, you'll have to coordinate with rockstar.  He's updated yui in the latest release and there are some blockers to deploying a new lazr-js.
[13:18] <gmb> *facepalm*
[13:18] <deryck> yup
[13:18] <deryck> I've got a fix about to land in lazr-js, too.
[13:18] <gmb> deryck, Okay. I'll hang fire.
[13:19] <deryck> gmb, so I would suggest work on the lp stuff you need to support the widget, and I'll coordinate with rockstar on getting this landed ASAP.
[13:19] <gmb> deryck, Right. Will do.
[13:19] <deryck> gmb, great, thanks.
[13:19] <gmb> deryck, Shall I mark the integration card for the Wizard blocked?
[13:19] <deryck> gmb, yes, indeed.
[13:20] <gmb> RIghto
[13:20] <deryck> gmb, and once you get stuff in lp you want to play with in the widget, you can symlink to your lazr-js build from lp tree, I think.
[13:20] <deryck> just to keep working
[13:20] <gmb> Cool. Will do.
[13:48] <deryck> gmb, regarding bug 575911 and a bugwatch referenced in a bug message with no imported comments.... is this something we're doing when setting up bug watches from links in comments?
[13:49] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/575911>
[13:53] <gmb> deryck, Aaaaah, this is the other half of my problem with the deletion of bug watches. Thanks; I was just trying to debug that.
[13:53] <gmb> deryck, Yes, it's caused by us being too strict about what counts as deletable.
[13:54] <deryck> cool, glad my question helped your thinking then.
[13:54] <gmb> Don't know why it doesn't OOPS, but that blows my theory about mangling the response before the OOPS machinery gets to it away.
[13:54] <gmb> deryck, Amusingly, I triaged it. I appear to have no memory of this.
[13:55] <deryck> heh
[13:55] <deryck> Too many bugs.
[13:55] <deryck> I appreciate you helping triage malone's bugs, though, gmb.
[13:56] <gmb> deryck, Natch. I think it's an easy bug to fix for a Friday afternoon. I'll look into it and if it's as simple as I think, I'll fix it today.
[13:57] <deryck> good deal
[13:57]  * deryck steps away for a few minutes to dress the waking baby and hand her off to grandparents
[13:57] <gmb> deryck, Ah!
[13:58] <gmb> Oh, no.
[13:58] <gmb> Wait.
[13:58] <gmb> Damn.
[13:58] <gmb> Clever thought was not clever.
[13:58] <gmb> Never mind.
[14:06] <gmb> deryck, So, I think the thing that causes the problem is an easy fix, but we'll have to do some data cleanup to make the currently non-deletable watches deletable.
[14:06] <gmb> I'll update the bug once I'm sure, but I'll fix the initial problem now since it's quick and easy.
[14:26] <deryck> gmb, sounds good.
[14:33] <cr3> gary_poster: hey dude, I hope your stack is better now :)
[14:48] <gmb> adeuring, Were you able to solve your OOPS-not-being-raised error?
[14:49] <adeuring> gmb: not really. But spooted another missing OOPS report
[14:49] <adeuring> s/spooted/spotted/
[14:50] <gmb> adeuring, Are you getting the Please Try Again page?
[14:50] <gmb> (instead of an oops)
[14:50] <salgado> sinzui, I'm getting http://paste.ubuntu.com/499723/ when make running.  any idea what's wrong?
[14:50] <gmb> I'm asking because that's what happens when you try to delete a bug watch https://bugs.edge.launchpad.net/malone/+bug/575911, and the error being raised there is an IntegrityError. Don't know if that helps you any.
[14:50] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
[14:51] <adeuring> gmb: the problem appeared in connection with the speical Librarian error message ("feng shui in the server room")
[14:51] <adeuring> that page does not mention an OOPS ID
[14:51] <sinzui> salgado, I have seen that on a dirty shutdown. I kill all procs, then rm /var/tmp/*.pid
[14:52] <adeuring> but an OOPS _should_ have been raised. problem was that I found IIRC one OOPS report where I would have exected 10 or 20
[14:52] <sinzui> salgado, the mailman pid could be from weeks ago if you have not use run all in a while
[14:53] <salgado> sinzui, right, that made it possible to run, but I was wondering about the "ImportError: No module named mailman.monkeypatches.defaults" error
[14:53] <salgado> that one persists
[14:53] <sinzui> salgado, sorry, I see another error. is your trunk up to date. I moved moneypatches to lp/services/mailman a few days ago
[14:54] <salgado> yeah, I just ran rf-get
[14:54] <salgado> sinzui, looks like lib/mailman/Mailman/mm_cfg.py wasn't updated?
[14:55] <sinzui> salgado, I think that is generated
[14:55] <gmb> adeuring, That is indeed "special." Where "Special" translates as "Nutzlos."
[14:56] <adeuring> gmb: exactly ;)
[14:56] <sinzui> salgado, regardless, I have a new pristine branch and will try now
[14:56] <salgado> oh, indeed it is auto-generated.  I'll try removing it
[14:57] <sinzui> salgado, I have from lp.services.mailman.monkeypatches.defaults import *
[14:59] <salgado> can't seem to get it to be generated again, now that I've removed it
[15:00]  * sinzui thinks
[15:01] <sinzui> salgado, make compile should call buildmailman,py
[15:01] <sinzui> salgado, make clean will purge the whole mailman dir
[15:01] <salgado> yeah, but that's called by make run
[15:02] <salgado> I was trying to avoid a make clean because it takes too long to rebuild after that.  I'll live without that file for now and once it causes problems I'll rebuild
[15:02] <salgado> thanks sinzui
[15:02] <sinzui> np
[15:04] <salgado> jcsackett, do you have some sample URLs for the pages you've changed in unknown-translations-service-643545-0?
[15:05] <jcsackett> salgado: yes, i've posted links in the MP
[15:05] <jcsackett> salgado: my last comment on it is a list of links and what's on them.
[15:05] <salgado> jcsackett, oh, as comments, I see them now.  was looking at the description
[15:06] <jcsackett> salgado: ah, yeah. sorry about that.
[15:06] <salgado> no worries.  thanks for adding the demo data to exercise the changes. :)
[15:08] <jcsackett> salgado: thanks for the suggestion of doing that in your last review. :-)
[15:11] <gmb> Ursinha, matsubara: Do either of you have any idea why the OOPS machinery wouldn't catch an IntegrityError raised by BugWatch.destroySelf()?
[15:12] <matsubara> gmb, don't know. how do you know it's raising an IntegrityError and no oopses is being generated?
[15:12] <gmb> matsubara, I'm reproducing it locally and instead of an OOPS page I get a ProxyError.
[15:13] <gmb> matsubara, I can talk you through reproducing it if that helkps.
[15:14] <gmb> (Also, nothing is showing up in my /var/lperr directory)
[15:14] <matsubara> gmb, I can try to reproduce locally
[15:14] <gmb> matsubara, Okay. I'll paste some instructions for you, hang on...
[15:14] <matsubara> thanks
[15:15] <gmb> matsubara, This is https://bugs.edge.launchpad.net/malone/+bug/575911, FTR.
[15:15] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
[15:17] <gmb> matsubara, http://pastebin.ubuntu.com/499735/
[15:22] <sinzui> mars, retarget questions, not assign them. https://answers.edge.launchpad.net/launchpad/+question/126444 need to be in launchpad-registry so that all answer contacts are notified
[15:23] <mars> sinzui, garh, sorry
[15:23] <mars> done
[15:29] <matsubara> gmb, looks like it's failing before the oops code have a chance to log it. line 568 in webapp/publication.py. not sure why though
[15:30] <matsubara> gary_poster, can you help gmb diagnose why an IntegrityError is not being logged correctly as an oops report?
[15:32] <gary_poster> on call will ping
[15:33] <gmb> matsubara, gary_poster: Thanks.
[15:41] <rockstar> deryck, have you landed your patch I reviewed yesterday yet?
[15:42] <deryck> rockstar, yup.  Just did an hour or so ago.
[15:42] <rockstar> deryck, good.  I'm wrangling lazr-js and our launchpad build system as we speak.
[15:43] <deryck> awesome!
[15:51] <bdmurray> as zope's test browser doesn't correctly set the referrer how can I test "ReturnToReferrerMixin" in a story?
[15:53] <gary_poster> bdmurray: have you already surveyed similar tests?  I don't remember if the answer is there, but I remember confronting it. :-/
[15:53] <gary_poster> gmb, ok looking now...
[15:55] <bdmurray> gary_poster: yes, I didn't find anything obvious
[15:55] <gary_poster> gmb, ok so the only way to get a traceback is to dupe, eh?  Trying.
[15:56] <gary_poster> bdmurray: did you find the tests dealing with REFERER, and they used another mechanism, or you didn't find pertinent tests?
[15:59] <bdmurray> gary_poster: All the clicking of Cancel tests I could find didn't seem to use ReturnToReferrer in the view
[16:00] <gary_poster> bdmurray: lemme do a grep; I probably can't help easily, but I'll give it a quick whirl...
[16:04] <gary_poster> bdmurray: see if lib/canonical/launchpad/pagetests/standalone/xx-offsite-form-post.txt helps
[16:10] <bdmurray> gary_poster: looks like it will thanks
[16:10] <gary_poster> cool, np
[16:13] <bigjools> gary_poster: do you know of a context manager (or similar) that does the same as the @write_transaction decorator?
[16:14] <gmb> gary_poster, Yes (sorry, was OTP)
[16:14] <gmb> gary_poster, I don't know why that IntegrityError isn't becoming an OOPS.
[16:15] <gmb> I know why the error is happening, and I'm fixing that, but I think it's worth making sure that this not-oopsing issue doesn't happen elsewhere, too.
[16:16] <gary_poster> bigjools: no, I don't think we have one.  If you look at the write_transaction impl in lib/canonical/librarian/db.py, you can see how to manage it manually.  a context manager might be nice.
[16:16] <gary_poster> gmb: understood and agreed
[16:17] <bigjools> gary_poster: yeah I am going to move it out of that location, it causes circular imports :(
[16:17] <gary_poster> ah :-/
[16:17] <bigjools> (I need it in a database class)
[16:17] <gary_poster> gotcha
[16:17] <bigjools> I'll maybe write a context manager sometime
[16:17] <gary_poster> it would be reasonable to put in the transaction library
[16:17] <gary_poster> as would a CM
[16:17] <bigjools> maybe in the next century when I get some free time
[16:17] <gary_poster> :-)
[16:18] <bigjools> gary_poster: I am looking at putting it in lp/services/database/__init__.py
[16:19] <gary_poster> sounds very reasonable bigjools
[16:19] <bigjools> ok thanks gary_poster
[16:19] <gary_poster> np
[16:20] <gary_poster> gmb, I don't see how to do step 2 in http://pastebin.ubuntu.com/499735/
[16:22] <gmb> gary_poster, Expand the top bug task using the little expander thing on the left hand side
[16:23] <gmb> (Old school, this)
[16:23] <gary_poster> ah@
[16:23] <gary_poster> !
[16:23] <gary_poster> got it thanks
[16:23] <gmb> gary_poster, And yes, "None, the report is updated manually" is listed twice. It's age-old, that bug.
[16:23] <gary_poster> ah ok, so it doesn't matter which one
[16:24] <gmb> gary_poster, Nope. I just use the first one.
[16:24] <gary_poster> cool
[16:24] <gary_poster> ok yay, duped
[16:30] <gary_poster> gmb, the reason is that the error happens within the transaction commit, which is outside of the application code.  This is a bug, though not one that will be solved soon, because it will involve replacing or changing the core Zope publication library (I'd like to replace, but as you might expect, that's not a small project).
[16:30] <gary_poster> I don't think we have a bug for this particular instance of OOPS tools not catching things.  Would you be up for creating one, or shall I?
[16:31] <gmb> gary_poster, Can you do it please? I'm desperately trying to to switch context in the middle of a ZCML horrorshow.
[16:31] <gmb> trying *not
[16:31] <gary_poster> gmb, will do.
[16:32] <gmb> gary_poster, Thanks.
[16:32] <gary_poster> np
[16:35] <EdwinGrubbs> abentley: ping
[16:35] <abentley> EdwinGrubbs, pong
[16:37] <EdwinGrubbs> abentley: hi, I've finally wrapped my head around the TwistedJobRunner, so I wanted to discuss with you the two possible ways I see to have it run multiple different job types in parallel.
[16:37] <cr3> in launchpad tests, should Fake classes for testing purposes be located in the tests themselves, like in test_foo.py, or under a testing directory? does it depend on whether the Fake class can be reused across more than one test module?
[16:37] <abentley> EdwinGrubbs, okay.  Did you want to do this on IRC or voice-to-voice?
[16:37] <jml> cr3, pretty much.
[16:38] <jml> cr3, also you should look for test doubles that already exist before writing your own.
[16:39] <EdwinGrubbs> abentley: mumble might be easier.
[16:39] <cr3> what about Fake implementations for interfaces, so that getUtility(IFoo) returns the Fake implementation in a testing context, I haven't noticed Fake utilities registered in ftesting.zcml
[16:40] <EdwinGrubbs> abentley: I added the ampoule channel to mumble. Can you join that?
[16:57] <salgado> sinzui, deryck[lunch], have you seen that the heading text is broken on https://bugs.edge.launchpad.net/launchpad?
[16:58] <sinzui> salgado, I do not see that
[16:58] <deryck[lunch]> me either
[16:58] <salgado> the "There are currently no open bugs filed against Launchpad itself."?
[16:58] <salgado> might be a chromium isssue
[16:58] <sinzui> that is true
[16:59] <sinzui> salgado, the bugs were retargeted to the app
[16:59]  * deryck fires up chromium
[16:59] <deryck> ah ha
[16:59] <salgado> it works on epiphany
[16:59]  * sinzui is using chromium
[16:59] <deryck> thought this was fixed already.  Must have regressed.
[17:00] <salgado> sinzui, I mean that the sentence is broken here; the first two works show up beside the search form
[17:00] <salgado> and the rest below it
[17:00] <salgado> s/works/words
[17:01] <salgado> deryck, you see that too?
[17:03] <sinzui> epiphany and chromuim look identical to me. I see the search box, and below it I see a bold statement and below that I see a link a report a bug link
[17:04] <deryck> salgado, yes, I see it.  Sorry on call now.
[17:09] <salgado> sinzui, are you on chromium 7.0.531.0 (nightly build)?
[17:18] <deryck> salgado, I'll reopen the bug about float issues in chromium.
[17:23] <salgado> deryck, cool, thanks
[17:23] <deryck> np
[19:19] <abentley> gary-lunch, I have some questions about how view configuration works when there are multiple potential matches.
[19:35] <mars> sinzui, jinx!
[19:36] <sinzui> ha
[19:38] <gary_poster> abentley: having another conversation/pursuing bug, but can follow along here too probably
[19:41] <abentley> gary_poster, We have shared code for "comments", where comments can actually be bug comments, code review comments, revisions, package diffs, and I'm adding incremental diffs to the list.
[19:42] <abentley> gary_poster, There's a "default" comment header that I don't want incremental diffs to use.  But it's being used anyway.
[19:43] <gary_poster> how is it registered, and how is the one you want registered?  Alternatively...
[19:44] <abentley> gary_poster, here are the configurations: http://pastebin.ubuntu.com/499890/
[19:45] <gary_poster> the order of preference for a multi-adapter like a view is to try to match the first element (context in this case) as much as possible, and then go to the second (request).  For eact item, interfaces directly declared on the instance have precedence, after which interfaces declared on the class, in __iro__ order for each interface and standard Python base class resolution order for the bases
[19:45] <gary_poster> looking
[19:46] <gary_poster> abentley: my guess is that class effectively resolves so that lp.services.comments.interfaces.conversation.IComment comes before lp.code.browser.branchmergeproposal.IIncrementalDiffComment
[19:47] <abentley> gary_poster, I will examine that.  It could be that it's declared to implement ICodeReviewComment directly, I guess.
[19:47] <abentley> s/ICodeReviewComment/ICommeng/
[19:47] <gary_poster> k
[19:50] <abentley> gary_poster, thanks.  That looks like it solved it.
[19:50] <gary_poster> great, abentley
[20:25] <cr3> heh, just came across this comment from 2005: if steveIsFixingThis :)
[20:53] <rockstar> gary_poster, if I make a library available in PyPI, do I need to worry about putting an egg into lp-sourcecode-whatever?
[20:54] <gary_poster> yes, but very easy: comment out "install-from-cache = true" from buildout.cfg, specify version in versions.cfg, and run buildout.  Then it will be in lp-sourcecode-whatever
[20:55] <gary_poster> (then uncomment)
[21:04] <rockstar> gary_poster, so then I have to commit the egg in lp-sourcecode-whatever?
[21:04] <gary_poster> rockstar: yes (or if you want to test it on ec2 first there's a flag for that)
[21:05] <rockstar> gary_poster, hm.  I fail to see the benefit in putting it on PyPI then.
[21:05] <gary_poster> sharing?
[21:05] <gary_poster> open source?
[21:05] <gary_poster> collaboration in the Python community? :-D
[21:05] <rockstar> gary_poster, yeah, I'm not sure that these tools would be of use to anyone else.
[21:06] <gary_poster> then there is no benefit.
[21:06] <rockstar> gary_poster, at least in this case, I'm probably going to eggify locally first, and then worry about PyPI later.
[21:06] <gary_poster> cool
[21:06] <rockstar> (I'm sure we can make the tools effective enough to be of value to others)
[21:06] <gary_poster> good.
[21:06] <gary_poster> bye all.  back Wed.
[21:38] <EdwinGrubbs> abentley: did you get a chance to look at my email?
[21:39] <abentley> EdwinGrubbs, I started, but got distracted.  Lemme look again.
[21:39] <mwhudson> poolie: that branch landed the second time :/
[21:42] <abentley> EdwinGrubbs, yeah, that's the basic idea.
[21:42] <EdwinGrubbs> abentley: ok, I'll try to get that into review by Monday.
[21:44] <abentley> EdwinGrubbs, Be careful of lock files.  It would be easy to have each forked process prevent the others from running.
[21:44] <EdwinGrubbs> abentley: good point
[21:45] <abentley> EdwinGrubbs, if you make queued-job-runner a commandline argument, it becomes easy to configure different JobSources for different machines.
[21:47] <abentley> EdwinGrubbs, I might do if getattr(section, 'runner_class', 'JobRunner') == 'JobRunner'.
[21:47] <rockstar> Since when does Launchpad INCORPORATE GAME MECHANICS?
[21:47]  * rockstar goes to a corner to sob.
[21:50] <abentley> EdwinGrubbs, oh, and I think you want to _exit() if pid == 0 after script.lock_and_run
[21:51] <abentley> rockstar, stand-up?
[21:51] <EdwinGrubbs> abentley: yes, there are plenty of bugs in it still.
[21:51] <rockstar> abentley, absolutely.
[21:52] <rockstar> abentley, hm, I seem to have forgotten my skype headset.  Lemme see if it would be cheap to POTS call you.
[21:52] <abentley> rockstar, I can SkypeOUT you.
[21:52] <rockstar> abentley, yeah, but then you have to pay for my absentmindedness.
[21:53] <abentley> rockstar, yeah but so little I don't really care.
[21:53] <rockstar> abentley, if it's alright, then sure.
[22:17] <abentley> rockstar, there's also Truephone, which is a lot like Skype, but supports Android.  We could try that next time you forget your headset.
[22:17] <rockstar> abentley, oh yeah.  That would be good.
[22:18] <rockstar> abentley, I try to come down and cowork on Fridays. Otherwise, I start having long philosophical conversations with my dog.
[22:18] <abentley> rockstar, :-)
[22:56] <poolie> thanks mwh
[22:57] <mwhudson> poolie: actually i didn't land
[22:57] <mwhudson> poolie: because of testfix
[22:58] <poolie> oh ok, but we know it passed
[22:58] <poolie> so lp-land will send mail direct to pqm, assuming that you have already run the tests on ec2 or locally?
[22:59] <mwhudson> poolie: yeah, i think lp-land is the tool for this job