[01:00] wgrant, there's still a BRANCH.TODO in that patch [01:00] jml: I was about to fix that. [01:00] I must have used the wrong prereq. [01:00] :) [01:00] r something. [01:00] I'll review the branch then. [01:01] Thanks. [01:01] Ah, yeah, I based it on the integration branch, but forgot ther was still that one change remaining. [01:02] * wgrant pushes. [01:06] jml: Diff is fixed now. [01:06] wgrant, cool. [01:07] Hm, odd import diff. [01:07] wgrant, I've reviewed it. Thanks for the patch :) [01:09] jml: Why not 'queueBuild'? [01:09] wgrant, that could work. Took me a moment to see that 'queue' was a verb though... [01:10] wgrant, but it is a better name. :) [01:10] _estimateDuration was private before, so it wasn't on the interface. [01:10] 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] gargling stabby lungs === jamalta-afk is now known as jamalta [01:31] jml: Want to review the second bit? It's 500ish lines [01:32] wgrant, sure. It'll be a couple of minutes before I start though. [01:41] wgrant, ok. ready [01:41] woot. [01:43] This is landable, as thefinal in a series of three unmerged branches. [01:43] The first is noodles', and was reviewed last week. [01:43] (that's the remaining unmerged bit of the integration branch) [01:45] wgrant, why the new tests in lib/lp/soyuz/tests/test_sourcepackagerecipebuild.py ? [01:45] wgrant, also, is there a bug filed for the bad names? [01:45] jml: There is a bug filed. Shall I add it there with an XXX? [01:46] wgrant, that'd be nice, thanks. [01:46] The new tests are because there are new bits on the interface that have been implemented. [01:47] wgrant, ah, I see now. [01:48] wgrant, r=jml [01:49] jml: Thanks. I'll add the XXX, then convince you to ec2 land it. [01:49] wgrant, ok. [02:04] jml: OK, pushed (also with the year corrected in all of my XXXs. oops) [02:04] Can you please ec2 land it? [02:04] wgrant, sure. got a commit message on the MP? [02:04] jml: Yep. [02:05] wgrant, just to be clear, I'm landing lp:~wgrant/launchpad/ibuildbase-compliance right? [02:06] jml: That's the one. [02:06] cool. [02:09] jml: How's your process-upload branch? [02:09] * jml does some local make build crap [02:10] I had forgotten about it. [02:14] That's all that's unlanded, apart from my Friday afternoon hacks which I'm isolating now. [02:17] ok. [02:41] wgrant, ec2 land is broken :( [02:41] wgrant, or maybe I am. [02:46] jml: What went wrong? [02:46] I gave it the url of the branch, not the mp [02:46] it raised a stupid error message [02:46] Ah. [02:47] process-upload-checks had some conflicts [02:47] I've resolved them fairly brainlessly, but I think correctly [02:47] So, bug #507783, bug #507784 and bug #507363 remain as blockers for a full run-through. [02:47] Bug #507783: RecipeBuildBehaviour has no security declarations [02:47] Bug #507784: SourcePackageRecipeBuild.getLogFilename() is not implemented [02:47] Bug #507363: Generalise rescueBuilderIfLost [02:47] Yeah, it was trivial to merge that. [02:48] jml: Since jelmer's branch has landed, somebody should probably sneak that first one in. [02:48] wgrant, the process-upload-checks branch is waiting for a review, but no one has [02:48] * wgrant fixes the middle one. [02:48] jml: Ah. I guess that's probably a bigjools thing. [02:51] yeah [02:51] wgrant, I think my branch fixes bug 507783 [02:51] Bug #507783: RecipeBuildBehaviour has no security declarations [02:51] 12 conflicts encountered. [02:52] :( [02:52] jml: Your p-u-c? [02:52] yeah, after merging db-stable in [02:53] jml: Merge ibuildbase-compliance into it. It is reasonably up-to-date. [02:53] (and will be landed soon... maybe) [02:53] the instance is up & running, fwiw. [02:53] Great, thanks. [02:54] merging your branch in doesn't really help [02:55] Hmmm. [02:55] I'll do db-stable & get that going [02:57] I have nfi why I get code import conflicts [02:58] criss-cross ftl [02:58] Yay criss-cross? [02:58] Yeah. [02:59] jml: I need a common base class for BuildFarmJobs that have an associated BuildBase. Any hints for names that don't suck? [02:59] wgrant, start by picking a non-crappy name for BuildBase, I guess. [03:00] Julian's against renaming that for the foreseeable future. [03:00] wgrant, such BFJs are building package stuff, right? [03:00] jml: Yes. [03:00] SourcePackageRecipeBuildJob and BuildPackageJob, but not TranslationsRecipeBuildJob or whatever they call it. [03:00] wgrant, PackageBuildFarmJobs? [03:01] oh wait [03:01] They're not necessarily building packages, but all the current candidates do. [03:01] BuildPackageJob is _also_ terribly named [03:01] It is. [03:01] We intend to rename it. [03:01] to BinaryPackageBuildJob. [03:01] wgrant, what's the thing they have in common? [03:01] other than building packages? [03:01] jml: {SourcePackageRecipeBuildJob,BuildPackageJob}.build is an IBuildBase [03:02] _handleStatus_OK should be on Build, right? [03:02] No, it should be on BuildBase. [03:02] Well, until somebody else needs a different implementation. [03:02] wgrant, yeah, but conceptually -- you say they aren't necessarily for building packages? [03:02] Right. [03:02] I don't want to make the inheritance hierarchy more horrible than is necessary. [03:03] If somebody wants to add a BuildBase derivative that doesn't do package stuff, they can create another layer. [03:03] what could they possibly be for other than building packages? [03:04] jml: Is there anything package-specific on IBuildBase? [03:04] Just about any other job running in an archive context could use it. [03:04] wgrant, I guess not. [03:04] wgrant, there's nothing about archives there either. [03:05] jml: Not in trunk. Check my branch. [03:05] wgrant, I'll take your word for it :) I want to resolve these conflicts before digging into even more code. [03:05] Ah, yeah, good idea. [03:06] wgrant, perhaps the name should have something to do with archives. [03:06] It also has distroseries, pocket, etc. [03:09] yeah. that sounds pretty package-y to me. [03:09] or at least, very focused on stuff to do with debian-derivatives. [03:09] Mm, possibly. [03:09] Yeah. [03:10] Hmm. [03:11] We actually have some build-specific stuff in BuildFarmJobBehaviorBase. [03:11] Julian suggested that when we asked him about a name for the build-specific version of that. [03:11] I wonder if we should do the same here. [03:11] another thing to consider is that maybe our current object/class model is forcing us to choose bad names. [03:18] on db-stable, which is correct: [03:18] specific_class = self.specific_job_classes[self.job_type] [03:19] specific_class = specific_job_classes()[self.job_type] [03:19] * jml picks one [03:20] OK. After that bloody merge, I'll run the tests. [03:20] hmm. I should have done that merge in the 'wellington' branch. [03:21] Possibly. [03:21] or I should abandon the branch. [03:21] Once my branch lands, the branch is merged. [03:23] fair enough. [03:23] I'll abandon it then. [03:23] So probably best to abandon it. [03:23] Yep. [03:25] * jml goes back to gtg hacking [03:25] jml: Before you vanish, do you have anything more to say on the naming thingy? [03:26] wgrant, I think I'd give it a name that emphasises the archive-y or package-y nature of it. [03:26] jml: OK. Thanks. [03:26] 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] Probably, yes. [03:27] 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] (also, subclassing for code sharing sucks) [03:27] What's a better solution? [03:28] wgrant, often composition is a better solution. [03:28] wgrant, but also sometimes just having different kinds of objects :) [03:28] True. [03:29] C++ folks have some sort of proverb for this, IIRC. thumper might know. [03:42] jml: for what? === jamalta is now known as jamalta-afk [07:09] 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] 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] spm: ok, thanks [07:21] guess I need to learn zope then :) === Ursinha is now known as Ursinha-afk [07:48] Anybody around who can check if PQM knows about my branch? [07:48] An ec2test started 5 hours ago, but I haven't been emailed either way yet. [07:48] jml: ^^? [07:51] Yay, landed. [07:51] Yep! [07:52] 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] hmm.. [07:53] 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] .. and need to land [07:54] I might, yeah. i'm just proposing my latest branch now. [07:54] * al-maisan goes back to packing [07:55] Oh, yeah, you're leaving :( [07:55] yup, tomorrow, bright and early :) [07:56] 6am? [07:56] from the hotel, yes. [07:59] wgrant, hi [07:59] henninge: Hi, regarding bug 507498 , any idea why the bug was not catched by xx-potemplate-index.txt test ? [07:59] Bug #507498: AttributeError on potemplate page [07:59] wgrant, my branch has broken zcml, so doesn't get past the build step [07:59] wgrant, I'll look at it tomorrow or maybe later tonight, off to dinner now. [08:00] jml: OK, thanks. [08:19] Hi adiroiban! [08:28] henninge: hi. I'm investigating why the bug 507498 was not prevented by the current tests (xx-potemplate-index.txt) [08:28] Bug #507498: AttributeError on potemplate page [08:29] adiroiban: yes, I am looking at that [08:30] adiroiban: it's because that permission got only checked on a corner case that the page test does not cover. [08:31] adiroiban: it is only checked if the project has rosetta *not* enabled and the template is *not* active (current). [08:31] henninge: but why. I can see the potemplate-index, is accessing a POTemplateSubset (+pots) using anon_browser [08:32] adiroiban: then, in the check itself the owner check was only done if the potemplate was not for a productseries. [08:33] adiroiban: consider these two lines: [08:33] if ((official_rosetta and potemplate.iscurrent) or [08:33] check_permission('launchpad.Edit', potemplate)): [08:34] adiroiban: check_permission will only be called if on of official_rosetta iscurrent is false. [08:34] s/on/one/ [08:35] (there was a term for that but I forget) [08:35] henninge: thanks. got it now :) [08:36] so normal user are not linked to that page... wondering how Diogo spoted this bug [08:36] adiroiban: also, for anon_browser, checkAuthenticated will not be called at all. [08:37] adiroiban: Diogo is just looking at oopses that occur on the production, edge and staging servers. [08:37] adiroiban: so this did not happen to Diogo but a user on edge. [08:37] :) [08:37] yes, but since that page is not linked from any other page visible to normal users [08:38] then is should have been a webcrawler or such :) [08:38] thanks for the explanations :) [08:38] adiroiban: or a book mark or a user hacking the url ... [09:08] bigjools: Morning. [09:08] morning [09:08] Did that buildd-manager warning actually cause any problems/ [09:09] not that I can tell [09:09] hmm. [09:09] but I wasn't paying much attention [09:09] Might just be the generally broken logging. [09:09] yeah the logging is pitiful [09:09] I mean, we broke it somehow last week. [09:09] 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] Hi! [09:27] eyup mrevell [09:28] bigjools, Back in GMT yet? [09:28] mrevell: yeah since sunday [09:28] He abandoned us. [09:28] well - my body is in GMT [09:28] bigjools, Yeah, I meant your mind, rather than your body :) [09:28] I've been waking up at 5am every day since sunday [09:29] nice [09:29] wgrant: how's lca? [09:29] bigjools: Pretty good. Some very interesting talks. [09:29] and do you have any unlanded branches from last week? [09:29] And the wireless even works now. [09:29] gosh [09:30] bigjools: Three branches landed a couple of hours ago. [09:30] One is outstanding -- the one I linked 15 minutes ago. [09:30] ok [09:30] 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] E_too_many_new_classes [09:31] Then everything is merged. [09:31] YES. [09:31] I'll review his todau [09:31] today even [09:31] bigjools, thanks. [09:31] was busy fixing that private build cockup yesterday [09:31] jml: Any idea what's wrong with the diff? [09:31] bigjools: What was the actual problem? Private->public PPA copies worked fine here... [09:31] jml: no problem Stephen [09:31] wgrant, no, I'm working on other more interesting failures right now [09:32] wgrant: the bug you reported about the missing _sendFileToSlave [09:32] bigjools, :) [09:32] bigjools: Oh, that one. [09:32] yes that one :) [09:32] 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] bigjools, such a doc would show us quite clearly the bits where it's All Too Hard [09:33] +1 [09:33] I want to document all the new classes separately [09:33] and then we can rename them if needed [09:33] it's too bloody confusing [09:33] Yep. [09:34] And we can shuffle stuff out of lp.soyuz. Once everything is merged. [09:34] jml: where do we normally put mixin classes in our hierarchy? [09:34] yep [09:34] At least the Translations jobs seem to be keeping to lp.translations [09:34] 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] bigjools, probably lp.services normally. lp.buildmaster seems a good place for a lot of these though. [09:35] 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] I suspect that lp.buildmaster actually wants to go to lp.services.buildfarm eventually. [09:36] or just rename buildmaster -> buildfarm [09:36] oh right [09:37] bigjools, on the 'model' or not, opinion is divided [09:37] bigjools, I personally think that the word 'model' means more than just "db wrappers" [09:37] well I don;t mind either way, as long as it's clear :) [09:38] and that we all know where to put them and look for them [09:38] bigjools, probably 'model' [09:38] hardly anyone actually uses the 'adapters' subpackage [09:38] apart from Soyuz :/ [09:38] which wasn't my doing [09:39] 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] I don't like lp.services [09:42] it seems ill-defined [09:43] If the build farm isn't a service, what is? [09:44] what's a service? [09:44] Good question. [09:45] wgrant: ok I'll approve your branch - is jml landing it? [09:45] 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] it's a terrible name [09:46] yeah [09:46] but I haven't heard anyone come up with a better one, or a better place to put generally useful code. [09:46] lp.stuff would even be better :) [09:46] bigjools: I've not organised a landing. [09:48] 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] Bug #507783: RecipeBuildBehaviour has no security declarations [09:48] feel free [09:50] wgrant, it's in my branch. [09:52] (I think) [09:52] I remember fixing it at the sprint anyway [09:54] jml: You attached a patch to the bug. [09:54] oh. [09:54] * wgrant checks your branch, though. [09:54] I didn't see it when I merged it earlier. [09:55] no, that makes sense. [10:00] bigjools, wgrant: ok. I'm running my branch through ec2 test, now that its zcml is fixed [10:01] bigjools: OK, security stuff there. Can you ec2 land it? [10:01] jml: Great. [10:01] wgrant: I can't ec2 land it :) [10:01] * wgrant will look at rescueBuilderIfLost tomorrow. [10:01] bigjools: Oh, true. [10:01] * bigjools runs into the house and turns on the beast [10:02] wgrant: so the branch I just reviewed, you added zcml stuff? [10:02] bigjools: Right. http://bazaar.launchpad.net/~wgrant/launchpad/bug-507784/revision/10203 [10:02] ok [10:02] Stolen from jml's diff. [10:02] I guess I should sort my ec2 access out [10:03] It's pretty handy. [10:03] jml: Is it expected that I didn't receive an email about the earlier test completion? [10:04] wgrant, umm. no. [10:06] It looks like I normally do, but this time I did not. [10:10] wgrant, I didn't get one either. [10:10] Odd. [10:10] yeah. [10:10] I'm not going to debug ec2 test / land now though [10:11] Good policy. [10:21] I suppose we should fix the data model this week. [10:44] * wgrant considers the whole sleeping thing. [10:50] wgrant: you can sleep when you're dead [10:58] hi. any idea why factory.makeProduct() is getting an error for wikiurl, when running from make harness ? http://paste.ubuntu.com/359492/ === matsubara-afk is now known as matsubara [12:03] jml: still around? [13:26] BjornT, what format was the js-play.prof file that you took? Firebug Profiler? === jamalta-afk is now known as jamalta [14:27] hi henninge_ === henninge_ is now known as henninge [14:32] Hi bac! === mrevell-lunch is now known as mrevell [14:32] hi henninge -- i'm re-reviewing the branch adi worked on yesterday. he had a problem with date_last_updated [14:33] yes [14:33] henninge: i recall you advised him to use removeSecurityProxy instead of updating the permission [14:33] henninge: problem is you can't set the new value using rSP [14:34] i was wondering why not just move date_last_updated to use lp.Edit [14:35] bac: The reason I opted for rSP is that date_last_updated should only be changed in that context. [14:35] henninge: right, but it just doesn't work. :) [14:35] a = removeSecurityProxy(b) [14:35] a = new_value [14:35] does not change b [14:36] bac: but if that 's not possible, allowing lp.Edit is ok. [14:36] bac: hm, something about flushing or comitting? [14:36] henninge: ok, i just wanted to run it by you to ensure i wasn't missing something [14:37] henninge: on the phone be right [14:42] adiroiban: what's the login on that virtual machine? [14:43] henninge: good question :) [14:43] something like d3v3l0p3r [14:43] user: developer [14:43] henninge: nm, i found out what he was doing wrong [14:44] bac: oh, what was it? [14:44] henninge: he was calling rSP(context.date_last_updated) ... getting an unwrapped attribute not the unwrapped object [14:45] bac, adiroiban: oh, I thought we had talked about that. === Ursinha-afk is now known as Ursinha [14:46] adiroiban: the login was correct [14:46] bac: thanks === salgado is now known as salgado-afk === salgado-afk is now known as salgado-lunch [14:48] adiroiban, henninge: http://pastebin.ubuntu.com/359563/ [14:49] bac: yes, that's what I would have expected. [14:50] ok, I'm a bit confused by our setup docs here. maxb, around? [14:50] hello [14:51] hi maxb. Do you have a moment to help untangle the docs for a system reinstall? [14:51] maxb, I'm trying to figure out why the 'launchpad-developer-dependencies' package isn't mentioned anywhere in the setup docs [14:51] and it is no longer in the ~launchpad PPA? [14:52] ! [14:52] 'launchpad-developer-dependencies' is a binary package built by the 'launchpad-dependencies' source package. the PPA webpages display source packages [14:52] It is in the PPA [14:52] ah [14:53] that makes sense [14:53] 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] bac: I've pushed the change [14:54] adiroiban: ok, i'm including a few other bits in my review. [14:54] 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] maxb, because the docs don't even mention the ~launchpad PPA [14:55] hmm [14:55] Unless you're missing something really fundamental, like bzr, it should be fine to let rocketfuel-setup add the PPA [14:56] ah, it does? [14:56] * mars checks the source again [14:56] adiroiban: MP updated [14:57] maxb, got it, ~line 177 in rf-setup. Cool, thanks for the help! [14:59] "2 packages upgraded, 153 newly installed, 0 to remove and 11 not upgraded. [14:59] Need to get 310MB of archives. After unpacking 737MB will be used." [14:59] ! [15:00] ^ that is the launchpad dev system footprint. [15:19] tell me about it, my nice lean VM image ballooned after installed the deps :( [15:22] well, that nixes the idea of downloading a full VM. You'll have to grow the VM from a seed image. [15:22] yep [15:22] I have a script to make one [15:22] bigjools, how big is a 'lean' VM? [15:23] I can't really remember [15:23] at a guess it was about 30MB [15:23] maybe less [15:24] wow [15:24] big size difference there === matsubara is now known as matsubara-lunch [15:25] gary_poster, ^ so that makes the story around "downloading a seed VM for LP developers" sound a little more appealing, eh? [15:27] argh. rocketfuel-setup went without a hitch, but 'make schema' barfed on a CSS error: make: *** [css_combine] Error 1 [15:28] 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] yeah we could [15:29] bigjools, and what does your "script to make one" do? Build the VM, or the VM+lp-dev ? [15:29] I was using the vmbuilder script to make mine [15:29] just the VM, running rf-setup obviously bloats it [15:29] just the VM [15:30]