[01:00] <jml> wgrant, there's still a BRANCH.TODO in that patch
[01:00] <wgrant> jml: I was about to fix that.
[01:00] <wgrant> I must have used the wrong prereq.
[01:00] <jml> :)
[01:00] <wgrant> r something.
[01:00] <jml> I'll review the branch then.
[01:01] <wgrant> Thanks.
[01:01] <wgrant> Ah, yeah, I based it on the integration branch, but forgot ther was still that one change remaining.
[01:02]  * wgrant pushes.
[01:06] <wgrant> jml: Diff is fixed now.
[01:06] <jml> wgrant, cool.
[01:07] <wgrant> Hm, odd import diff.
[01:07] <jml> wgrant, I've reviewed it. Thanks for the patch :)
[01:09] <wgrant> jml: Why not 'queueBuild'?
[01:09] <jml> wgrant, that could work. Took me a moment to see that 'queue' was a verb though...
[01:10] <jml> wgrant, but it is a better name. :)
[01:10] <wgrant> _estimateDuration was private before, so it wasn't on the interface.
[01:10] <jml> ahh ok.
[01:11]  * mwhudson stabs buildmailman in the lungs
[01:14]  * mwhudson widens his stabbing to the build process in general
[01:21]  * elmo joins in the stabbing from the sidelines
[01:21]  * wgrant stabs both the Launchpad and Soyuz build processes.
[01:24] <jml> gargling stabby lungs
[01:31] <wgrant> jml: Want to review the second bit? It's 500ish lines
[01:32] <jml> wgrant, sure. It'll be a couple of minutes before I start though.
[01:41] <jml> wgrant, ok. ready
[01:41] <jml> woot.
[01:43] <wgrant> This is landable, as thefinal in a series of three unmerged branches.
[01:43] <wgrant> The first is noodles', and was reviewed last week.
[01:43] <wgrant> (that's the remaining unmerged bit of the integration branch)
[01:45] <jml> wgrant, why the new tests in lib/lp/soyuz/tests/test_sourcepackagerecipebuild.py ?
[01:45] <jml> wgrant, also, is there a bug filed for the bad names?
[01:45] <wgrant> jml: There is a bug filed. Shall I add it there with an XXX?
[01:46] <jml> wgrant, that'd be nice, thanks.
[01:46] <wgrant> The new tests are because there are new bits on the interface that have been implemented.
[01:47] <jml> wgrant, ah, I see now.
[01:48] <jml> wgrant, r=jml
[01:49] <wgrant> jml: Thanks. I'll add the XXX, then convince you to ec2 land it.
[01:49] <jml> wgrant, ok.
[02:04] <wgrant> jml: OK, pushed (also with the year corrected in all of my XXXs. oops)
[02:04] <wgrant> Can you please ec2 land it?
[02:04] <jml> wgrant, sure. got a commit message on the MP?
[02:04] <wgrant> jml: Yep.
[02:05] <jml> wgrant, just to be clear, I'm landing lp:~wgrant/launchpad/ibuildbase-compliance right?
[02:06] <wgrant> jml: That's the one.
[02:06] <jml> cool.
[02:09] <wgrant> jml: How's your process-upload branch?
[02:09]  * jml does some local make build crap
[02:10] <jml> I had forgotten about it.
[02:14] <wgrant> That's all that's unlanded, apart from my Friday afternoon hacks which I'm isolating now.
[02:17] <jml> ok.
[02:41] <jml> wgrant, ec2 land is broken :(
[02:41] <jml> wgrant, or maybe I am.
[02:46] <wgrant> jml: What went wrong?
[02:46] <jml> I gave it the url of the branch, not the mp
[02:46] <jml> it raised a stupid error message
[02:46] <wgrant> Ah.
[02:47] <jml> process-upload-checks had some conflicts
[02:47] <jml> I've resolved them fairly brainlessly, but I think correctly
[02:47] <wgrant> So, bug #507783, bug #507784 and bug #507363 remain as blockers for a full run-through.
[02:47] <mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
[02:47] <mup> Bug #507784: SourcePackageRecipeBuild.getLogFilename() is not implemented <wellington> <Soyuz:Triaged> <https://launchpad.net/bugs/507784>
[02:47] <mup> Bug #507363: Generalise rescueBuilderIfLost <wellington> <Soyuz:New> <https://launchpad.net/bugs/507363>
[02:47] <wgrant> Yeah, it was trivial to merge that.
[02:48] <wgrant> jml: Since jelmer's branch has landed, somebody should probably sneak that first one in.
[02:48] <jml> wgrant, the process-upload-checks branch is waiting for a review, but no one has
[02:48]  * wgrant fixes the middle one.
[02:48] <wgrant> jml: Ah. I guess that's probably a bigjools thing.
[02:51] <jml> yeah
[02:51] <jml> wgrant, I think my branch fixes bug 507783
[02:51] <mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
[02:51] <jml> 12 conflicts encountered.
[02:52] <jml> :(
[02:52] <wgrant> jml: Your p-u-c?
[02:52] <jml> yeah, after merging db-stable in
[02:53] <wgrant> jml: Merge ibuildbase-compliance into it. It is reasonably up-to-date.
[02:53] <wgrant> (and will be landed soon... maybe)
[02:53] <jml> the instance is up & running, fwiw.
[02:53] <wgrant> Great, thanks.
[02:54] <jml> merging your branch in doesn't really help
[02:55] <wgrant> Hmmm.
[02:55] <jml> I'll do db-stable & get that going
[02:57] <jml> I have nfi why I get code import conflicts
[02:58] <jml> criss-cross ftl
[02:58] <wgrant> Yay criss-cross?
[02:58] <wgrant> Yeah.
[02:59] <wgrant> jml: I need a common base class for BuildFarmJobs that have an associated BuildBase. Any hints for names that don't suck?
[02:59] <jml> wgrant, start by picking a non-crappy name for BuildBase, I guess.
[03:00] <wgrant> Julian's against renaming that for the foreseeable future.
[03:00] <jml> wgrant, such BFJs are building package stuff, right?
[03:00] <wgrant> jml: Yes.
[03:00] <wgrant> SourcePackageRecipeBuildJob and BuildPackageJob, but not TranslationsRecipeBuildJob or whatever they call it.
[03:00] <jml> wgrant, PackageBuildFarmJobs?
[03:01] <jml> oh wait
[03:01] <wgrant> They're not necessarily building packages, but all the current candidates do.
[03:01] <jml> BuildPackageJob is _also_ terribly named
[03:01] <wgrant> It is.
[03:01] <wgrant> We intend to rename it.
[03:01] <wgrant> to BinaryPackageBuildJob.
[03:01] <jml> wgrant, what's the thing they have in common?
[03:01] <jml> other than building packages?
[03:01] <wgrant> jml: {SourcePackageRecipeBuildJob,BuildPackageJob}.build is an IBuildBase
[03:02] <jml> _handleStatus_OK should be on Build, right?
[03:02] <wgrant> No, it should be on BuildBase.
[03:02] <wgrant> Well, until somebody else needs a different implementation.
[03:02] <jml> wgrant, yeah, but conceptually -- you say they aren't necessarily for building packages?
[03:02] <wgrant> Right.
[03:02] <wgrant> I don't want to make the inheritance hierarchy more horrible than is necessary.
[03:03] <wgrant> If somebody wants to add a BuildBase derivative that doesn't do package stuff, they can create another layer.
[03:03] <jml> what could they possibly be for other than building packages?
[03:04] <wgrant> jml: Is there anything package-specific on IBuildBase?
[03:04] <wgrant> Just about any other job running in an archive context could use it.
[03:04] <jml> wgrant, I guess not.
[03:04] <jml> wgrant, there's nothing about archives there either.
[03:05] <wgrant> jml: Not in trunk. Check my branch.
[03:05] <jml> wgrant, I'll take your word for it :) I want to resolve these conflicts before digging into even more code.
[03:05] <wgrant> Ah, yeah, good idea.
[03:06] <jml> wgrant, perhaps the name should have something to do with archives.
[03:06] <wgrant> It also has distroseries, pocket, etc.
[03:09] <jml> yeah. that sounds pretty package-y to me.
[03:09] <jml> or at least, very focused on stuff to do with debian-derivatives.
[03:09] <wgrant> Mm, possibly.
[03:09] <wgrant> Yeah.
[03:10] <wgrant> Hmm.
[03:11] <wgrant> We actually have some build-specific stuff in BuildFarmJobBehaviorBase.
[03:11] <wgrant> Julian suggested that when we asked him about a name for the build-specific version of that.
[03:11] <wgrant> I wonder if we should do the same here.
[03:11] <jml> another thing to consider is that maybe our current object/class model is forcing us to choose bad names.
[03:18] <jml> on db-stable, which is correct:
[03:18] <jml>         specific_class = self.specific_job_classes[self.job_type]
[03:19] <jml>         specific_class = specific_job_classes()[self.job_type]
[03:19]  * jml picks one
[03:20] <jml> OK. After that bloody merge, I'll run the tests.
[03:20] <jml> hmm. I should have done that merge in the 'wellington' branch.
[03:21] <wgrant> Possibly.
[03:21] <jml> or I should abandon the branch.
[03:21] <wgrant> Once my branch lands, the branch is merged.
[03:23] <jml> fair enough.
[03:23] <jml> I'll abandon it then.
[03:23] <wgrant> So probably best to abandon it.
[03:23] <wgrant> Yep.
[03:25]  * jml goes back to gtg hacking
[03:25] <wgrant> jml: Before you vanish, do you have anything more to say on the naming thingy?
[03:26] <jml> wgrant, I think I'd give it a name that emphasises the archive-y or package-y nature of it.
[03:26] <wgrant> jml: OK. Thanks.
[03:26] <jml> wgrant, I also think that once the translation stuff lands, it would be worth writing a document that explains the current system, and how to add a new type of job
[03:27] <wgrant> Probably, yes.
[03:27] <jml> wgrant, by seeing all of the cruft described to other humans, we'll all suddenly get good ideas on how to make it better.
[03:27] <jml> (also, subclassing for code sharing sucks)
[03:27] <wgrant> What's a better solution?
[03:28] <jml> wgrant, often composition is a better solution.
[03:28] <jml> wgrant, but also sometimes just having different kinds of objects :)
[03:28] <wgrant> True.
[03:29] <jml> C++ folks have some sort of proverb for this, IIRC. thumper might know.
[03:42] <thumper> jml: for what?
[07:09] <freim> Hi. I have installed launchpad as described on launchpad.net and it seems to be running correctly. I do however start to wonder if I got the right branch build since everything seems hardcoded to launchpad.dev, has dummy data in it, mail configured to only go to local root, etc. Should I use a different branch for a production server?
[07:17] <spm> freim: no you have the right code - same as what we use on the prod servers; you should (I believe) have a file configs/README.txt that should take you thru some of the config stuff and vaguely how it all works. The defaults are all wired for .dev as you've noticed.
[07:20] <freim> spm: ok, thanks
[07:21] <freim> guess I need to learn zope then :)
[07:48] <wgrant> Anybody around who can check if PQM knows about my branch?
[07:48] <wgrant> An ec2test started 5 hours ago, but I haven't been emailed either way yet.
[07:48] <wgrant> jml: ^^?
[07:51] <wgrant> Yay, landed.
[07:51] <al-maisan> Yep!
[07:52] <wgrant> This leaves jml's branch, my other branch, and two more diff hunks until trunk can do an end-to-end recipe build.
[07:52] <al-maisan> hmm..
[07:53] <al-maisan> wgrant: maybe it would be worthwhile sending a bigjools an email outlining what you just said i.e. what branches are still outstanding and mee
[07:54] <al-maisan> .. and need to land
[07:54] <wgrant> I might, yeah. i'm just proposing my latest branch now.
[07:54]  * al-maisan goes back to packing
[07:55] <wgrant> Oh, yeah, you're leaving :(
[07:55] <al-maisan> yup, tomorrow, bright and early :)
[07:56] <wgrant> 6am?
[07:56] <al-maisan> from the hotel, yes.
[07:59] <jml> wgrant, hi
[07:59] <adiroiban> henninge: Hi, regarding bug 507498 , any idea why the bug was not catched by xx-potemplate-index.txt test ?
[07:59] <mup> Bug #507498: AttributeError on potemplate page <oops> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/507498>
[07:59] <jml> wgrant, my branch has broken zcml, so doesn't get past the build step
[07:59] <jml> wgrant, I'll look at it tomorrow or maybe later tonight, off to dinner now.
[08:00] <wgrant> jml: OK, thanks.
[08:19] <henninge> Hi adiroiban!
[08:28] <adiroiban> henninge: hi. I'm investigating why the bug 507498 was not prevented by the current tests (xx-potemplate-index.txt)
[08:28] <mup> Bug #507498: AttributeError on potemplate page <oops> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/507498>
[08:29] <henninge> adiroiban: yes, I am looking at that
[08:30] <henninge> adiroiban: it's because that permission got only checked on a corner case that the page test does not cover.
[08:31] <henninge> adiroiban: it is only checked if the project has rosetta *not* enabled and the template is *not* active (current).
[08:31] <adiroiban> henninge: but why. I can see the potemplate-index, is accessing a POTemplateSubset (+pots) using anon_browser
[08:32] <henninge> adiroiban: then, in the check itself the owner check was only done if the potemplate was not for a productseries.
[08:33] <henninge> adiroiban: consider these two lines:
[08:33] <henninge>         if ((official_rosetta and potemplate.iscurrent) or
[08:33] <henninge>             check_permission('launchpad.Edit', potemplate)):
[08:34] <henninge> adiroiban: check_permission will only be called if on of official_rosetta iscurrent is false.
[08:34] <henninge> s/on/one/
[08:35] <henninge> (there was a term for that but I forget)
[08:35] <adiroiban> henninge: thanks. got it now :)
[08:36] <adiroiban> so normal user are not linked to that page... wondering how Diogo spoted this bug
[08:36] <henninge> adiroiban: also, for anon_browser, checkAuthenticated will not be called at all.
[08:37] <henninge> adiroiban: Diogo is just looking at oopses that occur on the production, edge and staging servers.
[08:37] <henninge> adiroiban: so this did not happen to Diogo but a user on edge.
[08:37] <adiroiban> :)
[08:37] <adiroiban> yes, but since that page is not linked from any other page visible to normal users
[08:38] <adiroiban> then is should have been a webcrawler or such :)
[08:38] <adiroiban> thanks for the explanations :)
[08:38] <henninge> adiroiban: or a book mark or a user hacking the url ...
[09:08] <wgrant> bigjools: Morning.
[09:08] <bigjools> morning
[09:08] <wgrant> Did that buildd-manager warning actually cause any problems/
[09:09] <bigjools> not that I can tell
[09:09] <wgrant> hmm.
[09:09] <bigjools> but I wasn't paying much attention
[09:09] <wgrant> Might just be the generally broken logging.
[09:09] <bigjools> yeah the logging is pitiful
[09:09] <wgrant> I mean, we broke it somehow last week.
[09:09] <wgrant> It works in the tests, but not in real life.
[09:13]  * wgrant hunts for a reviewer for https://code.edge.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722
[09:27] <mrevell> Hi!
[09:27] <bigjools> eyup mrevell
[09:28] <mrevell> bigjools, Back in GMT yet?
[09:28] <bigjools> mrevell: yeah since sunday
[09:28] <wgrant> He abandoned us.
[09:28] <bigjools> well - my body is in GMT
[09:28] <mrevell> bigjools, Yeah, I meant your mind, rather than your body :)
[09:28] <bigjools> I've been waking up at 5am every day since sunday
[09:29] <mrevell> nice
[09:29] <bigjools> wgrant: how's lca?
[09:29] <wgrant> bigjools: Pretty good. Some very interesting talks.
[09:29] <bigjools> and do you have any unlanded branches from last week?
[09:29] <wgrant> And the wireless even works now.
[09:29] <bigjools> gosh
[09:30] <wgrant> bigjools: Three branches landed a couple of hours ago.
[09:30] <wgrant> One is outstanding -- the one I linked 15 minutes ago.
[09:30] <bigjools> ok
[09:30] <wgrant> Then jml's needs to land (he's requested a review from you, but the diff looks utterly broken), and somebody needs to fix rescueBuilderFromSlave.
[09:30] <bigjools> E_too_many_new_classes
[09:31] <wgrant> Then everything is merged.
[09:31] <wgrant> YES.
[09:31] <bigjools> I'll review his todau
[09:31] <bigjools> today even
[09:31] <jml> bigjools, thanks.
[09:31] <bigjools> was busy fixing that private build cockup yesterday
[09:31] <wgrant> jml: Any idea what's wrong with the diff?
[09:31] <wgrant> bigjools: What was the actual problem? Private->public PPA copies worked fine here...
[09:31] <bigjools> jml: no problem Stephen
[09:31] <jml> wgrant, no, I'm working on other more interesting failures right now
[09:32] <bigjools> wgrant: the bug you reported about the missing _sendFileToSlave
[09:32] <jml> bigjools, :)
[09:32] <wgrant> bigjools: Oh, that one.
[09:32] <bigjools> yes that one :)
[09:32] <jml> bigjools, I was saying to wgrant (re the too many classes thing) that it'd be good to write a doc on how to add a new build farm job after this & the translations one are done
[09:32] <jml> bigjools, such a doc would show us quite clearly the bits where it's All Too Hard
[09:33] <bigjools> +1
[09:33] <bigjools> I want to document all the new classes separately
[09:33] <bigjools> and then we can rename them if needed
[09:33] <bigjools> it's too bloody confusing
[09:33] <wgrant> Yep.
[09:34] <wgrant> And we can shuffle stuff out of lp.soyuz. Once everything is merged.
[09:34] <bigjools> jml: where do we normally put mixin classes in our hierarchy?
[09:34] <bigjools> yep
[09:34] <wgrant> At least the Translations jobs seem to be keeping to lp.translations
[09:34] <jml> bigjools, well, a "how to" guide might show you why some of them don't need to be separate (or exist!) at all. Or maybe not.
[09:35] <jml> bigjools, probably lp.services normally. lp.buildmaster seems a good place for a lot of these though.
[09:35] <bigjools> well wgrant has added one in the model dir.  I question if that taints the purity of everything actually being a model class
[09:35] <wgrant> I suspect that lp.buildmaster actually wants to go to lp.services.buildfarm eventually.
[09:36] <bigjools> or just rename buildmaster -> buildfarm
[09:36] <jml> oh right
[09:37] <jml> bigjools, on the 'model' or not, opinion is divided
[09:37] <jml> bigjools, I personally think that the word 'model' means more than just "db wrappers"
[09:37] <bigjools> well I don;t mind either way, as long as it's clear :)
[09:38] <bigjools> and that we all know where to put them and look for them
[09:38] <jml> bigjools, probably 'model'
[09:38] <jml> hardly anyone actually uses the 'adapters' subpackage
[09:38] <bigjools> apart from Soyuz :/
[09:38] <bigjools> which wasn't my doing
[09:39] <jml> also, lp.services.buildfarm would better fit the intent of the new tree than lp.buildfarm. But I'll save that argument for when someone gets around to moving it. :)
[09:42] <bigjools> I don't like lp.services
[09:42] <bigjools> it seems ill-defined
[09:43] <wgrant> If the build farm isn't a service, what is?
[09:44] <bigjools> what's a service?
[09:44] <wgrant> Good question.
[09:45] <bigjools> wgrant: ok I'll approve your branch - is jml landing it?
[09:45] <jml> bigjools, lp.services is supposed to be stuff that the rest of Launchpad uses that isn't really worthy of an external library
[09:46] <jml> it's a terrible name
[09:46] <bigjools> yeah
[09:46] <jml> but I haven't heard anyone come up with a better one, or a better place to put generally useful code.
[09:46] <bigjools> lp.stuff would even be better :)
[09:46] <wgrant> bigjools: I've not organised a landing.
[09:48] <wgrant> I wonder if I should sneak the fix for bug #507783 in with it, given that it wasn't included in jelmer's branch.
[09:48] <mup> Bug #507783: RecipeBuildBehaviour has no security declarations <wellington> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/507783>
[09:48] <bigjools> feel free
[09:50] <jml> wgrant, it's in my branch.
[09:52] <jml> (I think)
[09:52] <jml> I remember fixing it at the sprint anyway
[09:54] <wgrant> jml: You attached a patch to the bug.
[09:54] <jml> oh.
[09:54]  * wgrant checks your branch, though.
[09:54] <wgrant> I didn't see it when I merged it earlier.
[09:55] <jml> no, that makes sense.
[10:00] <jml> bigjools, wgrant: ok. I'm running my branch through ec2 test, now that its zcml is fixed
[10:01] <wgrant> bigjools: OK, security stuff there. Can you ec2 land it?
[10:01] <wgrant> jml: Great.
[10:01] <bigjools> wgrant: I can't ec2 land it :)
[10:01]  * wgrant will look at rescueBuilderIfLost tomorrow.
[10:01] <wgrant> bigjools: Oh, true.
[10:01]  * bigjools runs into the house and turns on the beast
[10:02] <bigjools> wgrant: so the branch I just reviewed, you added zcml stuff?
[10:02] <wgrant> bigjools: Right. http://bazaar.launchpad.net/~wgrant/launchpad/bug-507784/revision/10203
[10:02] <bigjools> ok
[10:02] <wgrant> Stolen from jml's diff.
[10:02] <bigjools> I guess I should sort my ec2 access out
[10:03] <wgrant> It's pretty handy.
[10:03] <wgrant> jml: Is it expected that I didn't receive an email about the earlier test completion?
[10:04] <jml> wgrant, umm. no.
[10:06] <wgrant> It looks like I normally do, but this time I did not.
[10:10] <jml> wgrant, I didn't get one either.
[10:10] <wgrant> Odd.
[10:10] <jml> yeah.
[10:10] <jml> I'm not going to debug ec2 test / land now though
[10:11] <wgrant> Good policy.
[10:21] <wgrant> I suppose we should fix the data model this week.
[10:44]  * wgrant considers the whole sleeping thing.
[10:50] <bigjools> wgrant: you can sleep when you're dead
[10:58] <adiroiban> hi. any idea why factory.makeProduct() is getting an error for wikiurl, when running from make harness ? http://paste.ubuntu.com/359492/
[12:03] <bigjools> jml: still around?
[13:26] <mars> BjornT, what format was the js-play.prof file that you took?  Firebug Profiler?
[14:27] <bac> hi henninge_
[14:32] <henninge> Hi bac!
[14:32] <bac> hi henninge -- i'm re-reviewing the branch adi worked on yesterday.  he had a problem with date_last_updated
[14:33] <henninge> yes
[14:33] <bac> henninge: i recall you advised him to use removeSecurityProxy instead of updating the permission
[14:33] <bac> henninge: problem is you can't set the new value using rSP
[14:34] <bac> i was wondering why not just move date_last_updated to use lp.Edit
[14:35] <henninge> bac: The reason I opted for rSP is that date_last_updated should only be changed in that context.
[14:35] <bac> henninge: right, but it just doesn't work.  :)
[14:35] <bac> a = removeSecurityProxy(b)
[14:35] <bac> a = new_value
[14:35] <bac> does not change b
[14:36] <henninge> bac: but if that 's not possible, allowing lp.Edit is ok.
[14:36] <henninge> bac: hm, something about flushing or comitting?
[14:36] <bac> henninge: ok, i just wanted to run it by you to ensure i wasn't missing something
[14:37] <bac> henninge: on the phone be right
[14:42] <henninge> adiroiban: what's the login on that virtual machine?
[14:43] <adiroiban> henninge: good question :)
[14:43] <adiroiban> something like d3v3l0p3r
[14:43] <adiroiban> user: developer
[14:43] <bac> henninge: nm, i found out what he was doing wrong
[14:44] <henninge> bac: oh, what was it?
[14:44] <bac> henninge: he was calling rSP(context.date_last_updated) ... getting an unwrapped attribute not the unwrapped object
[14:45] <henninge> bac, adiroiban: oh, I thought we had talked about that.
[14:46] <henninge> adiroiban: the login was correct
[14:46] <adiroiban> bac: thanks
[14:48] <bac> adiroiban, henninge:  http://pastebin.ubuntu.com/359563/
[14:49] <henninge> bac: yes, that's what I would have expected.
[14:50] <mars> ok, I'm a bit confused by our setup docs here.  maxb, around?
[14:50] <maxb> hello
[14:51] <mars> hi maxb.  Do you have a moment to help untangle the docs for a system reinstall?
[14:51] <mars> maxb, I'm trying to figure out why the 'launchpad-developer-dependencies' package isn't mentioned anywhere in the setup docs
[14:51] <mars> and it is no longer in the ~launchpad PPA?
[14:52] <maxb> !
[14:52] <maxb> 'launchpad-developer-dependencies' is a binary package built by the 'launchpad-dependencies' source package. the PPA webpages display source packages
[14:52] <maxb> It is in the PPA
[14:52] <mars> ah
[14:53] <mars> that makes sense
[14:53] <mars> I know I have to install 'launchpad-dependencies' as a dep of lp-dev-deps, but I didn't know they came from the same source
[14:53] <adiroiban> bac: I've pushed the change
[14:54] <bac> adiroiban: ok, i'm including a few other bits in my review.
[14:54] <mars> maxb, cool, thanks.  You wouldn't happen to know if installing the ~launchpad PPA, and then installing launchpad-developer-dependencies must be done *before* running rocketfuel-setup?
[14:54] <mars> maxb, because the docs don't even mention the ~launchpad PPA
[14:55] <mars> hmm
[14:55] <maxb> Unless you're missing something really fundamental, like bzr, it should be fine to let rocketfuel-setup add the PPA
[14:56] <mars> ah, it does?
[14:56]  * mars checks the source again
[14:56] <bac> adiroiban: MP updated
[14:57] <mars> maxb, got it, ~line 177 in rf-setup.  Cool, thanks for the help!
[14:59] <mars> "2 packages upgraded, 153 newly installed, 0 to remove and 11 not upgraded.
[14:59] <mars> Need to get 310MB of archives. After unpacking 737MB will be used."
[14:59] <mars> !
[15:00] <mars> ^ that is the launchpad dev system footprint.
[15:19] <bigjools> tell me about it, my nice lean VM image ballooned after installed the deps :(
[15:22] <mars> well, that nixes the idea of downloading a full VM.  You'll have to grow the VM from a seed image.
[15:22] <bigjools> yep
[15:22] <bigjools> I have a script to make one
[15:22] <mars> bigjools, how big is a 'lean' VM?
[15:23] <bigjools> I can't really remember
[15:23] <bigjools> at a guess it was about 30MB
[15:23] <bigjools> maybe less
[15:24] <mars> wow
[15:24] <mars> big size difference there
[15:25] <mars> gary_poster, ^ so that makes the story around "downloading a seed VM for LP developers" sound a little more appealing, eh?
[15:27] <mars> argh.  rocketfuel-setup went without a hitch, but 'make schema' barfed on a CSS error: make: *** [css_combine] Error 1
[15:28] <gary_poster> mars, yes.  bigjools, is that lean vm something we could offer to open source devs?  Or does it at least show us a way we could do it?
[15:29] <bigjools> yeah we could
[15:29] <mars> bigjools, and what does your "script to make one" do?  Build the VM, or the VM+lp-dev ?
[15:29] <bigjools> I was using the vmbuilder script to make mine
[15:29] <bigjools> just the VM, running rf-setup obviously bloats it
[15:29] <mars> just the VM
[15:30] <bigjools> however we could work out a minimal set of scripts that sets up basic stuff
[15:30] <mars> and then some sort of easy way to run rf-setup inside of it
[15:30] <bigjools> then let the dev run rf-setup
[15:30] <bigjools> or a subset of it
[15:30] <bigjools> it's very easy to set up with vmbuilder
[15:30] <mars> bigjools, how do you access the vm from your local system?  Fuse?
[15:30] <gary_poster> bigjools: I hadn't heard of vmbuilder.  That's cool.  What does the vm run in?
[15:31] <bigjools> mars: I run it as a VM and ssh into it
[15:31] <gary_poster> oh, I guess, many of them...
[15:31] <bigjools> gary_poster: any vm manager :)
[15:31] <mars> bigjools, how do you hack on the source tree then?
[15:31] <bigjools> I used qemu
[15:31] <gary_poster> yeah, nice little script!
[15:31] <bigjools> mars: it's COW
[15:31] <mars> surely you don't run the editor in the VM
[15:32] <bigjools> what editor?
[15:32] <mars> bigjools, "I need to hack on this feature, then run the branch".  How do I hack the branch with my local editor, but run the branch using the VM?
[15:33] <mars> fuse is one way to do it
[15:33] <mars> seamless integration
[15:33] <bigjools> I think I was pulling off my host, or pushing to the VM
[15:33] <gary_poster> I use fuse for my vm stuff.  It is nice.
[15:33] <bigjools> I guess you can use fuse
[15:34] <bigjools> but if the VM is running...
[15:34] <mars> right, if the branch resides on the VM, then it needs to be running
[15:34] <gary_poster> bigjools, I don't understand how the vm is only 30M.  Does it rely on the Ubuntu source hanging around?
[15:34] <mars> but if the branch resides locally, and fuse pulls it into the VM...
[15:34] <bigjools> gary_poster: it's only that size until you install the lp deps
[15:35] <bigjools> and yes it pulls in a load of packages to build it in the first place
[15:35] <bigjools> it helps if you have apt-proxy
[15:35] <bigjools> for repeated runs!
[15:36] <mars> bigjools, trying to work on your xvfb problem.  Does 'make css_combine' work in your copy of trunk?
[15:37] <bigjools> mars: let me check
[15:37] <bigjools> mars: yep it's fine
[15:37] <mars> crap
[15:38] <bigjools> mars: my big problem now is that I can't even run my tests using bin/test :(
[15:38] <bigjools> it won't start the browser over an ssh-proxied X session
[15:38] <mars> bigjools, yeah.  Did you see my reply?
[15:38] <bigjools> oh not yet
[15:38] <bigjools> mars: I replied to your reply, I have a different problem
[15:39] <bigjools> unless you replied to my reply to your reply
[15:41] <mars> bigjools, maybe an xset command is called for?
[15:42] <kfogel> gmb: when you get a chance, take a look at our fix for that "XXX" in https://code.edge.launchpad.net/~kfogel/launchpad/505845-affects-person-from-dups/+merge/17721 (which I've resubmitted, so you should get a new diff)
[15:42] <bigjools> mars: to do what?
[15:42] <bigjools> I mean, other X stuff works fine over ssh
[15:42] <bigjools> it's very odd
[15:42] <mars> hmm
[15:43] <bigjools> I think we should remove js tests from blocking landings until this is all resolved
[15:48] <gmb> bigjools: +1.
[15:49] <bigjools> gmb: do you find it flaky as well?
[15:50] <gmb> bigjools: Not on this system, but I've had it do weird things to me last week (which I got around nicely by just killing the Windmill process)
[15:54] <mars> bigjools, is that the correct display number in your error message?  10:0 ?
[15:54] <Ursinha> bigjools: hello :)
[15:54] <Ursinha> bigjools: is this a known error? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1480EC819
[15:55] <bigjools> mars: yes, it's the ssh proxy
[15:55] <bigjools> Ursinha!
[15:56] <bigjools> Ursinha: hmmm that's odd
[15:57] <bigjools> Ursinha: someone is copying between private/public yet again
[15:57] <bigjools> it's not really tested
[15:57] <bigjools> I need to disable it :(
[15:57] <Ursinha> bigjools: :(
[15:57] <Ursinha> bigjools: may I file a bug about it?
[15:58] <bigjools> I already have one
[15:58] <bigjools> Ursinha: bug 509333
[15:58] <mup> Bug #509333: LP should not allow a user to copy from a private to a public PPA <Soyuz:Triaged by julian-edwards> <https://launchpad.net/bugs/509333>
[15:59] <bigjools> you can add the oops there if you like
[16:00] <Ursinha> bigjools: just did that :)
[16:00] <Ursinha> bigjools: thank you very much
[16:00] <bigjools> thank you
[16:34] <mars> bigjools, I'm wondering if some debugging info in test_on_merge.py, around line 140, may be in order
[16:34] <bigjools> mars: happy to help
[16:35] <mars> bigjools, perhaps a call to subprocess.call(['/usr/bin/bash'], shell=True) ?
[16:35] <mars> to open a shell on the terminal
[16:36] <mars> bigjools, either that, or a print statement
[16:38] <bigjools> mars: which? :)
[16:38] <mars> bigjools, still reading.  does the xvfb-run script use xauth?
[16:40] <bigjools> mars: looks like it
[16:41] <mars> bigjools, can you call something like "xvfb-run -s '-screen 0 1024x768x24' /usr/bin/xclock" on the local/remote sysytem?
[16:41] <mars> bigjools, run xclock in the same way that windmill would run
[16:42] <bigjools> mars: it just exits with no error
[16:42] <mars> bigjools, I guess it would have to run on the remote system, because that is where test_on_merge.py is run
[16:42] <bigjools> I tried local and remote
[16:44] <mars> bigjools, how about: xvfb-run -s '-screen 0 1024x768x24' /home/ed/canonical/lp-branches/missing-slave-method-bug-509383/bin/test -vv
[16:45] <bigjools> mars: same thing, it just exits
[16:45] <mars> bigjools, no processes left over?
[16:45] <bigjools> and leaves an xvfb running in the background
[16:46] <mars> no test process, eh?
[16:49] <mars> bigjools, ok.  So you get a "cannot connect to display" error when running bin/test on the remote system
[16:50] <mars> and 'make check' fails on the remote system when you use the xvfb-run step
[16:50] <bigjools> mars: yes, after about 3 hours when it starts the windmill layer tests
[16:50] <mars> :)
[16:50] <bigjools> so I landed the fucker anyway :
[16:50] <mars> bigjools, 'make jscheck' on the remote system does... ?
[16:50] <mars> heh
[16:50] <bigjools> one sec
[16:52] <bigjools> mars: working fine over the ssh tunnel
[16:52] <bigjools> my screen is full of FF
[16:52] <mars> hmmm
[16:55] <mars> bigjools, reading man xvfb-run:  The following command should execute successfully: "$ xvfb-run --auto-servernum --server-num=1 xlogo"
[16:55] <mars> bigjools, if it does not, grab the exit code
[16:56] <mars> echo $?
[16:57] <bigjools> one sec
[16:58] <bigjools> mars: exit code is 1
[16:59] <mars> ok, perhaps something with the way that xvfb-run is using server numbers
[16:59] <mars> bigjools, I had to ^C that call on my local system, and it gave an exit code of 130
[17:00] <bigjools> both my remote and local boxes have the problem here
[17:00] <bigjools> I suspect you have a package installed I don't
[17:01] <mars> bigjools, does it say anything in the terminal?  ""Xvfb failed to start" >&2
[17:02] <mars> bigjools, you do have the xlogo program on your system, right?
[17:02] <mars> the remote system
[17:02] <bigjools> yes :)
[17:03] <bigjools> mars: ok this is weird, now it works locally
[17:04] <bigjools> but nothing in the terminal for the remote system that fails
[17:05] <mars> bigjools, ok, "$ cp /usr/bin/xvfb-run $home/xvfb-run", edit the script, around line 182 add 'echo "Return value: $RETVAL"'
[17:05] <mars> bigjools, then chmod +x $home/xvfb-run && bash $home/xvfb-run
[17:05] <mars> er
[17:06] <mars> and finally, run it with: $ xvfb-run --auto-servernum --server-num=1 xlogo
[17:06] <mars> bigjools, that should give you /something/ in the terminal
[17:07] <mars> there is a slight confounding of the script return variables at work here
[17:07] <mars> I can't tell if xvfb-run is failing, or if the command you are passing to it is failing
[17:08] <bigjools> mars: on a call now, I'll be intermittent, one sec
[17:08] <mars> ok
[17:11] <bigjools> mars: line 182 is "exit 1", is that the right place?
[17:11] <mars> bigjools, uhm, no.  "exit 1" is line 175 on my system
[17:12] <mars> $ apt-cache policy xvfb
[17:12] <mars> xvfb:
[17:12] <mars>   Installed: 2:1.6.4-2ubuntu4.1
[17:12] <mars> bigjools, ^ ?
[17:13] <bigjools> 2:1.6.4-2ubuntu4
[17:13] <mars> running lucid?
[17:13] <bigjools> hell no :)
[17:14] <mars> ah, wait
[17:14] <bigjools> ah but wait!
[17:14] <mars> 2:1.6.4-2ubuntu4.1 is greater than 2:1.6.4-2ubuntu4
[17:16] <mars> bigjools, so it looks like there is at least some teeny, tiny ten line difference between our xvfb-run scripts.  I wonder what the .1 package version bump did?
[17:17] <bigjools> mars: I have that version in an update
[17:17] <bigjools> let me try again
[17:17] <mars> I lack the apt-fu to pull the change from the command line
[17:18] <bigjools> mars: ok line 182 is "set -e"
[17:19] <mars> bigjools, ok, then please add: echo "Proxied command return value: $RETVAL"
[17:19] <mars> bigjools, and then you should be able to see if command failed, or if xvfb-run failed, or if Xvfb failed
[17:20] <bigjools> well it doesn't fail any more
[17:20] <bigjools> lol
[17:22] <bigjools> mars: https://edge.launchpad.net/ubuntu/+source/xorg-server
[17:22] <bigjools> see the changelog for karmix
[17:23] <bigjools> it was published 14 mins ago and fixed xvfb
[17:23] <mars> 'Universal Troubleshooting Process, Step 1: "Is your system up to date?"'
[17:23] <mars> bigjools, what?!
[17:23] <bigjools> quite :)
[17:32] <mars> ok, next up: converting Bjorn's .prof file to KCacheGrind
[17:57] <leonardr> flacoste, gary: we have declarations @operation_returns_entry and @operation_returns_collection_of
[17:58] <leonardr> we do not have @operation_returns_nothing_in_particular
[17:58] <leonardr> which means that in a multiversion scenario you can go from returning nothing in particular (ie. nothing the wadl needs to know about) to returning an entry, and then to returning a collection, but you can't go back to returning nothing in particular
[17:58] <leonardr> should i define @operation_returns_nothing_in_particular as part of this work, or just mention it in case we need it later?
[18:02] <gary_poster> leonardr: I don't really understand.  flacoste is away.  What does the wadl not need to know about?  Is this for the case of a function that returns None?  Or...
[18:03] <leonardr> gary: if a named operation returns a data model object, we put that information into the wadl
[18:03] <leonardr> otherwise it's assumed that the operation returns arbitrary json
[18:03] <gary_poster> leonardr: but if it returns a scalar we do not?
[18:03] <gary_poster> ah
[18:03] <leonardr> and launchpadlib does not make any attempt to wrap the json in a launchpad object
[18:04] <gary_poster> leonardr, so, @operation_returns_json
[18:04] <leonardr> so we're talking about the unlikely case where a named operation returns a data model object in one version and arbitrary json in the next
[18:04] <leonardr> yeah
[18:04] <leonardr> good name
[18:04] <leonardr> except it doesn't even have to be json
[18:04] <gary_poster> example?
[18:05] <leonardr> it could return html (assuming the client requested html)
[18:09] <gary_poster> OK, I'm assuming we have these already.  It sounds like these methods are specifically for returning to the webservice?  @webservice_operation?  @direct_webservice_operation?  If it is easy to do this, it seems reasonable to do this now.  If it takes more than an hour, and we don't need it, move on.
[18:09] <gary_poster> with a note
[18:09] <gary_poster> leonardr: ^^^
[18:10] <leonardr> gary: we do have such methods already
[18:10] <gary_poster> ack
[18:10] <leonardr> it's somewhat likely that they will trend towards returning data model objects
[18:10] <leonardr> it's less likely that anything will go in the opposite direction
[18:10] <leonardr> but it should be easy to add
[18:11] <gary_poster> leonardr: are the methods typically specifically for the webservice?
[18:12] <leonardr> gary: yes, these declarations only apply to methods _as published in the webservice_
[18:14] <leonardr> now that i think about it, if a method changes that heavily, it's more likely that we'll define two different methods and expose them as the same name in different versions
[18:16] <leonardr> we've got a similar problem with @mutator_for. what if the method stops being a mutator?
[18:16] <gary_poster> leonardr: I don't think that's what I mean.  Yes, operations_* describe the webservice.  However, typically, they are annotating methods that are often used in other ways, yes?  They are often just internal API methods for which we say "expose this".  My question was whether these methods that return JSON or HTML are methods that are typically written for the webservice, rather than merely exposed by the webservice.  ...If i
[18:16] <gary_poster> important, then whatever.
[18:16] <leonardr> gary: in a multi-versioned environment you will not longer be able to just 'expose this'
[18:17] <leonardr> depending in how serious you are about backward compatibility you will have to keep old code around
[18:20] <leonardr> gary: i'm leaning towards just implementing a general @not_exported or @reset declaration, which i believe i was going to implement anyway
[18:20] <leonardr> yes, it's @no_longer_exported
[18:21] <gary_poster> leonardr: ok sounds good
[18:21] <leonardr> gary: so you can use @no_longer_exported to stop it, and then if you want to be really crazy you can use @export_*_operation again to bring it back
[18:22] <gary_poster> +1
[18:29] <gary_poster> Is anyone around who can tell me how bzr-builder is supposed to be knit into the db-devel tree?
[18:40]  * maxb knows nothing, but really hopes it's the same way as the other bzr plugins
[18:44] <wgrant> gary_poster: Run update-sourcecode.
[18:44] <wgrant> Before yesterday you would have needed to run it in db-devel, but the changes seem to have been pushed into devel yesterday as well.
[18:46] <gary_poster> wgrant: yeah, I was the one who pushed them into devel to work around lameness in some of our test scripts.  what I actually need to know is how bzr-builder is supposed to find its way into optionalbzrplugins, because db-devel is failing, I've duped locally, and it is because bzr-plugins is not importable, and I can't figure out how it should have gotten into optionalbzrplugins, or the python path.  do you know?
[18:47] <gary_poster> eh, should have been a period after "is failing."  Blame it, and other run-on constructions, on writing too fast :-)
[18:48] <maxb> I thought it was in bzrplugins, not optionalbzrplugins?
[18:49] <gary_poster> (to be clear, my two concrete observations are that I don't see it in optionalbzrplugins, though I assume it should be there; and it is not importable by lib/lp/soyuz/model/sourcepackagerecipedata.py during wadl generation)
[18:50] <gary_poster> maxb: ah, yes, builder is in bzrplugins, and hg, git, and the like are in optionalbzrplugins
[18:51] <mwhudson> builder should be in bzrplugins
[18:51] <mwhudson> oh
[18:51] <mwhudson> maybe you have to import lp.codehosting before you import it?
[18:51] <mwhudson> goddamn import order dependencies
[18:51] <gary_poster> mwhudson, ok will try :-/
[18:53] <wgrant> Is buildbot happy now?
[18:53] <gary_poster> wgrant, no it is sad
[18:54] <gary_poster> mwhudson: no, did not solve
[18:55]  * mwhudson actually looks at buildbot
[18:55] <gary_poster> mwhudson: will try looking at python path before import...
[18:55] <mwhudson> gary_poster: i think bzrlib.plugins.__path__ is also worth looking at
[18:57] <gary_poster> mwhudson: ack, that would be more pertinent thanks
[18:59] <gary_poster> disabling SHHH would help...
[18:59] <gary_poster> ...sigh, or maybe not...
[18:59] <mwhudson> gary_poster: 'make' in db-devel works for me, of course
[18:59] <gary_poster> :-) of course
[19:00] <gary_poster> mwhudson: here is the recipe that worked for me fwiw
[19:00] <gary_poster> get db-devel
[19:00] <mwhudson> though that's perhaps because i have bzr-builder installed in ~/.bazaar...
[19:00] <gary_poster> oh, maybe
[19:00] <mwhudson> nope
[19:01] <gary_poster> ok, so to continue recipe, link-external-dependencies
[19:01] <gary_poster> rm the symlinks to the new packages (bzr-hg and bzr-builder) in sourcecode
[19:01] <gary_poster> run update-sourcecode-dependencies
[19:01] <gary_poster> and, if you are me or buildbot, fail when you try to run make
[19:02]  * mwhudson tries
[19:05] <gary_poster> mwhudson (and any others): http://paste.ubuntu.com/359690/ shows sys.path followed by bzrlib.plugins.__path__
[19:06] <mwhudson> bzrlib.errors.BzrError: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 302 Found
[19:06] <mwhudson> yay hotel internet!
[19:06] <gary_poster> mwhudson: so, bzrplugins/builder/ is empty for me
[19:06] <mwhudson> !?
[19:06] <gary_poster> it is also a real, not symlink
[19:06] <gary_poster> hard
[19:06] <gary_poster> I am guessing it should be a symlink?
[19:07] <mwhudson> yes
[19:07] <gary_poster> mwhudson, who was supposed to put it there?
[19:07] <mwhudson> !?
[19:07] <mwhudson> i _did_ put it there
[19:07] <gary_poster> heh
[19:07] <mwhudson> but it seems db-devel 8894 unsymlinked it
[19:08] <gary_poster> oh!
[19:08] <mwhudson> kind changed:
[19:08] <mwhudson>   bzrplugins/builder@ (symlink => directory)
[19:11] <gary_poster> mwhudson: I assume that should be a symlink to sourccode/bzr-builder?  Would you like me to do the honors?
[19:11] <gary_poster> Or I can go have lunch :-)
[19:11] <mwhudson> gary_poster: i would like to go and have breakfast, so if you could...
[19:11] <gary_poster> mwhudson: sure.  Thanks so much for your help
[19:12] <mwhudson> fwiw it was gmb in db-devel r8889.1.1 that done it
[19:12] <gary_poster> yeah, I saw :-)
[19:12] <mwhudson> i guess related to the general sourcecode confusion
[19:12] <mwhudson> oh well
[19:12] <gmb> gary_poster, mwhudson: sry.
[19:12] <mwhudson> gmb: not to worry, at least it's easy to fix :)
[19:12] <gmb> :)
[19:12] <gary_poster> absolutely :-)
[19:12]  * mwhudson goes to see if loggerhead explodes over the kind change
[19:14] <mwhudson> hm, doesn't display it usefully, but at least it doesn't go bang
[19:14]  * mwhudson breaks fast
[19:15] <gary_poster> ok, not out of woods yet, fwiw
[19:15] <gary_poster> Changing the symlink reveals the following
[19:16] <gary_poster> http://paste.ubuntu.com/359700/
[19:16] <gary_poster> of which the important bit is ImportError: No module named debian_bundle
[19:16] <gary_poster> oh
[19:16] <gary_poster> duh
[19:16] <gary_poster> I bet I need to update my dependencies
[19:17] <mwhudson> yes
[19:17] <mwhudson> that's in python-debian which is depended on by launchpad-dependences 0.62
[19:17] <gary_poster> yes, should have done that first, sorry
[19:17] <mwhudson> np
[19:17] <flacoste> so the failure was because of a bad merge conflict resolution i guess
[19:17] <gary_poster> yeah
[19:17]  * mwhudson really goes away
[19:17] <gary_poster> :-)
[19:18] <gary_poster> flacoste: actually, probably because gmb was trying to get things to work before devel had the sourcecode branches, and did so by mutating the tree
[19:19] <gmb> Yep.
[19:47] <bac> rockstar: hi, you're the only one from the asiapac reviewer meeting who's around, right?  what say we cancel this week?
[19:48] <bac> gary_poster: do we have a build engineer this month?
[19:49] <gary_poster> bac: no.  Considering canceling the program.  Maybe will ask for volunteers for next cycle, give it one more whirl, then discuss.
[19:50] <bac> gary_poster: so your team would just pick it up?
[19:51] <gary_poster> bac: yes.
[19:52] <bac> gary_poster: ok.  i may hunt you down for a  pre-imp call for a fix i want to do to ec2 in my spare time.
[19:54] <gary_poster> bac: cool
[20:04] <jamalta> so is login_anonymously gone from launchpadlib?
[20:04] <jamalta> i can't find it in help() and it tells me the method doesn't exist
[20:04] <jamalta> or is it a new feature that isn't in the karmic version of launchpadlib?
[20:05] <salgado> jamalta, it's brand new
[20:06] <jamalta> salgado: ah ok, thanks
[20:06] <dobey> how do i get a bug_target for a project, with launchpadlib? i don't see how in the +apidoc on edge
[20:11] <wgrant> dobey: A project *is* a bug_target.
[20:13] <dobey> ok, well i didn't know that, and it's in no way clear from the documentation that it is the case
[20:14] <wgrant> "Examples include an IDistribution, an IDistroSeries and an IProduct.
[20:14] <wgrant> "
[20:14] <dobey> yes
[20:16] <thumper> wgrant: perhaps it should say "examples include distributions, series, and projects"
[20:16] <dobey> there are only vague insinuations that IProduct == "project" in other places in the doc. nothing concrete, or that makes me say "oh, a project, ok"
[20:17] <dobey> thumper: indeed. i'm seeing lots of places where the docs could be clearer in that respect :)
[20:17] <wgrant> Probably. A lot of Launchpad docstrings are awful.
[20:17] <thumper> :)
[20:17] <wgrant> Even moreso when exposed over the API.
[20:17] <dobey> guess i'll file bugs about them
[20:17] <thumper> dobey: DO IT!
[20:18] <wgrant> thumper: Why does make run_all sometimes clobber my push branches?
[20:18] <thumper> wgrant: I dunno
[20:18] <thumper> look at the Makefile
[20:18] <dobey> i will. have to file all these bugs to track my own work first, since i barely have enough time to get it all done by feature freeze :)
[20:19] <jamalta> regarding, https://help.launchpad.net/API/launchpadlib
[20:19] <dobey> thanks
[20:19] <jamalta> you can't bzr branch lp:oauth
[20:19] <jamalta> because it doesn't have a main branch
[20:44] <thumper> jamalta: should it have?
[20:45] <jamalta> thumper: well, the instructions in the wiki say to branch lp:oauth
[20:45] <jamalta> but you can't
[20:45] <thumper> I'm looking at it
[20:45] <thumper> although I'm tempted to change the trunk branch to use bzr-svn
[20:46] <jamalta> thumper: to pull from code.google.com?
[20:46] <thumper> jamalta: yeah, currently the import is using cscvs
[20:46] <thumper> but we'd have to change our launchpad branch if I did that
[20:46] <thumper> I'll take it to the dev list
[20:47] <jamalta> thumper: cool :)
[20:47] <jamalta> also, it seems that lazr.restfulclient is broken (or my pull is)
[20:47] <jamalta> it fails to import from lazr.restfulclient.authorize
[20:48] <jamalta> http://paste.ubuntu.com/359738/
[20:48] <wgrant> Can somebody please ec2 land https://code.edge.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722, since it looks like bigjools ran into issues last night?
[20:49] <thumper> jamalta: email sent
[20:50] <jamalta> thumper: thanks :)
[20:50] <thumper> jamalta: are you on the launchpad dev list?
[20:50] <jamalta> thumper: yeah
[20:50] <thumper> ok
[20:52] <jamalta> should i just report a bug for the lazr.restfulclient issue?
[21:03] <thumper> jamalta: yep
[21:07] <jamalta> thumper: thanks
[21:27] <dobey> thumper: i think leah might have moved the "canonical" trunk for python-oauth to github now
[21:50] <jml> eoasuheoasuheoauseoathisuaheosnideoasuhaei
[21:50] <jml> !!!##!$$#@!#!$!$#@#!
[21:50] <jml> I'm unhapppy.
[21:50] <leonardr> gary: i think the next step is to start building multiversioned adapter classes for named operations
[21:51] <gary_poster> leonardr: cool, sounds good
[21:52] <leonardr> jml, why unhappiness?
[21:52] <jml> because merging db-devel into my branch has 16 conflicts
[21:52] <jml> even though I merged db-stable in yesterday and resolved about the same number of conflicts.
[21:53] <wgrant> Morning jml.
[21:53] <jml> it makes me very upset.
[21:53] <wgrant> More criss-crosses?
[21:53] <jml> wgrant, good morning
[21:53] <jml> yes.
[21:53] <jml> ok, down to ten with some smarter merging.
[21:54]  * wgrant violates the mandatory community pre-imp call rule and puzzles over how to do rescueBuilderIfLost.
[21:58] <gary_poster> heh
[22:03] <wgrant> Can someone please ec2 land https://code.launchpad.net/~wgrant/launchpad/bug-507784/+merge/17722?
[22:05] <wgrant>         channel = logging.StreamHandler(log.StdioOnnaStick())
[22:05] <wgrant> Huh?
[22:06] <jml> almost done
[22:06] <jml> wgrant, what's the huh about?
[22:06] <wgrant> jml: StdioOnnaStick
[22:06]  * wgrant finds it.
[22:07] <jml> it's a Twisted thing
[22:07] <wgrant> I see.
[22:07] <jml> on the whole, I think it's a better name than SourcePackageRecipeJobBuild
[22:07] <wgrant> s/JobBuild/BuildJob/
[22:07] <wgrant> But yes.
[22:08] <wgrant> How bad were the conflicts?
[22:10] <jml> wgrant, some of them were the same as the ones I fixed the other day
[22:10] <wgrant> Fun.
[22:10] <jml> wgrant, lots of them were because of your renames to stuff in my branch.
[22:10] <wgrant> Ah :(
[22:11] <mwhudson> darn it, --headless should just be the default for ec2 test
[22:18] <jml> pain pain pain.
[22:19] <mwhudson> jml: good morning
[22:19] <jml> mwhudson, pain
[22:19] <jml> zcml is such a terrible, terrible idea
[22:19] <wgrant> Martian, Martian, Martian.
[22:19] <mwhudson> jml: i see
[22:22] <jml> someone added zcml declarations for the classes added in my branch in the same file but a different location
[22:23] <ajmitch> jml: is zcml causing you a world of pain?
[22:23] <BjornT> mwhudson: you know a lot about pdb and python. if i have a multithreaded app that is using 100% CPU, is there an easy way of seeing which thread is busiest, and what it is doing atm?
[22:24] <mwhudson> BjornT: you can attach to it with gdb and wangle your way to a (python) stack trace
[22:24] <BjornT> mwhudson: do you have time to show me how?
[22:24] <mwhudson> if one thread is using 100% cpu, it's pretty likely to be the one that you get when you attach, i guess
[22:24] <mwhudson> BjornT: even better, it's documented on wiki.c.c i think
[22:25] <mwhudson> BjornT: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BacktraceFromCoredump
[22:26] <mwhudson> BjornT: going offline for a bit now, biab
[22:26] <BjornT> ok, let me try that
[22:30] <BjornT> mwhudson: hmm, didn't work. when doing apply pystack, it complains with: No symbol "t_bootstrap" in current context
[22:38] <wgrant> Arrrrgh massive doctests kill kill kill.
[22:42] <jml> jelmer_, how do you feed testr failing stuff into ./bin/test
[22:42] <jelmer_> wgrant: good morning to you too :-)
[22:43] <jelmer_> jml: ./bin/test --subunit | testr load
[22:43] <jml> the other way around
[22:43] <jml> run the tests that just failed
[22:43] <jelmer_> jml: Oh, I haven't done that
[22:43] <jml> ok. me neither.
[22:43] <jelmer_> I'm not aware of a way to do that yet
[22:44] <wgrant> Morning jelmer_
[22:46] <BjornT> mwhudson_: hmm, didn't work. when doing apply pystack, it complains with: No symbol "t_bootstrap" in current context
[22:47] <mwhudson_> hm
[22:47] <mwhudson_> that means threading isn't loaded
[22:47] <mwhudson> BjornT: are you connecting to the right process?
[22:47] <mwhudson> there's a bit of a forest in make check
[22:47] <mwhudson> alternatively,,,
[22:48] <mwhudson> BjornT: try this .gdbinit instead: http://pastebin.ubuntu.com/359793/
[22:49] <BjornT> mwhudson: i think so. i'm running bin/test manually. i'm attaching to it with 'gdb /usr/bin/python2.5 $procid'
[22:50] <mwhudson> BjornT: just gdb -p $pid should be enoough
[22:50] <mwhudson> BjornT: i guess you can check which process is hogging the cpu in top...
[22:53] <BjornT> mwhudson: right. i'm attaching to the process with 100% CPU. with the new .gdbinit i get this output, which i guess isn't expected: http://pastebin.ubuntu.com/359796/
[22:54] <mwhudson> BjornT: which gdbinit is that with?
[22:54] <BjornT> mwhudson: http://pastebin.ubuntu.com/359793/
[22:54] <mwhudson> BjornT: try the one from the wiki page
[22:55] <jml> what's the right way to make a distroarchseries?
[22:56] <wgrant> jml: In a test?
[22:56] <jml> wgrant, yeah.
[22:56] <wgrant> jml: I think there's IDistroSeries.newArch
[22:56] <jml> wgrant, thanks.
[22:56] <wgrant> But normally we just use sample data.
[22:57] <BjornT> mwhudson: with the one from the wiki page i get: http://pastebin.ubuntu.com/359798/
[22:57] <wgrant> (yes, evil, but so is the Soyuz data model)
[22:57] <mwhudson> BjornT: :(
[22:58] <mwhudson> maybe it's a 2.4/2.5 difference or something
[22:59] <mwhudson> BjornT: where are you?
[22:59] <mwhudson> i can come and try to help in person after the talk
[22:59] <jml> wgrant, the problem is that the test_recipebuilder tests no longer work now that processor info is used :)
[23:00] <mwhudson> BjornT: oh
[23:00] <mwhudson> BjornT: do you have python2.5-dbg installed?
[23:00]  * jml pounds away
[23:00] <wgrant> jml: Ah :(
[23:01] <BjornT> mwhudson: i'm in the main auditorium now. although, i don't have that package installed... let me try installing that
[23:01] <mwhudson> BjornT: i'm in renouf1 so it should be easy enough to meet up after the talks if needed
[23:03] <mwhudson> although i'm running out of battery
[23:05] <BjornT> mwhudson: ok. i'll try to grab you after the talks. installing python2.5-dbg mad things better, but still no information from pystack :(
[23:05] <mwhudson> bah
[23:08] <jml> is it too late to say "don't use threads"?
[23:12] <mwhudson> jml: yes
[23:12] <deryck> sinzui, ping
[23:12] <mwhudson> BjornT: catch you in a bit
[23:12] <mwhudson> enobatter
[23:13] <jml> :( :(
[23:14] <jml> mwhudson, str(self.build.recipe.builder_recipe) doesn't do what I thought it should do
[23:15] <sinzui> hi deryck
[23:15] <deryck> sinzui, so I have a failing registry test in a new branch for me, that I think we should remove...
[23:15] <deryck> sinzui, see http://pastebin.ubuntu.com/359803/
[23:16] <jml> all of these tests passed last week
[23:16] <deryck> sinzui, the work flow is no longer supported because of my changes.  if a project doesn't use LP for bug tracking, there is only a message on the bugs page saying "you don't use LP for bug tracking, enable bug tracking here." type link
[23:16] <deryck> sinzui, and this is well tested in the bugs tests.  so I think we should kill the bits I show you in the paste.  you okay with this?
[23:17] <sinzui> deryck: great: I was writing that I think that test is a bogus exercise of a form
[23:17] <deryck> sinzui, excellent.  thanks, sir!
[23:19] <sinzui> deryck: the registry team will re-invent the set bug tracker forms in March as a part of our effort to improve drive-thru-registration
[23:19] <deryck> sinzui, sounds good
[23:30] <jml> lifeless, do you have any thoughts on making test selection better?
[23:45] <jml> does anyone have any idea at all about this error? http://pastebin.ubuntu.com/359816/