[00:42]  * mwhudson lunches
[00:42] <mwhudson> (not that there's anyone here to care)
[00:44]  * ajmitch cares
[00:44] <ajmitch> mostly because I have my lunch here with me :)
[03:13] <lifeless> thumper: ping
[03:13] <lifeless> thumper: re bug https://bugs.edge.launchpad.net/launchpad-code/+bug/411357 - is there an API's equivalent to +activereviews. e.g. see https://code.edge.launchpad.net/~ubuntu-main-sponsors/+activereviews which has useful content
[04:49] <MTecknology> wow - you guys have a lot of builder machines
[05:09] <lifeless> some of the time
[07:15] <beuno> gooood morning
[07:22] <al-maisan> Good morning beuno :)
[07:23] <wgrant> If only Launchpad had some easy way to turn a branch into a source package -- these release instructions would be so much easier.
[07:23] <al-maisan> wgrant: ha ha :)
[07:36] <noodles775> hi wgrant - on that note, if you have time, please go through https://dev.launchpad.net/BuildBranchToArchiveUI and see if you've any thoughts or ideas or corrections etc. I'm planning to send out a RFC/Input sometime in the next few days.
[07:36] <noodles775> Especially the "Questions still requiring thought" section :)
[07:37] <wgrant> noodles775: I think there'll need to be a new (set of?) tables for scheduled builds.
[07:37] <wgrant> Since I might want to build this recipe whenever the tip changes.
[07:37] <wgrant> Somebody else might want to build only releases of this same recipe.
[07:38] <wgrant> So storing it on the SPRecipe probably won't work well.
[07:38] <noodles775> yeah, I don't think the current schema even supports daily builds properly (see the third question still requiring thought).
[07:39] <noodles775> So your suggestion would be a good general solution.
[07:42] <wgrant> noodles775: Regarding the first and second points, the changelog in the packaging branch is irrelevant. bzr-builder concocts a new changelog entry with the information given to it by the master. That data is stored in the SPRB when it is created.
[07:42] <wgrant> (you must currently specify it when the build is requested)
[07:43] <noodles775> hrm
 noodles775, in case you missed it on #bzr, bzr-builder gets it from the changelog.
[07:45]  * wgrant checks the code.
[07:45] <wgrant> We definitely pass the suite all the way through.
[07:45] <noodles775> OK, that would make things easier - so the user specifies it, we set it on the build and it's passed through to bzr-builder? I'll have to digg a bit deeper.
[07:46] <noodles775> Great. Thanks.
[07:46] <wgrant> The package name too.
[07:47] <noodles775> But that's the question there, where do *we* specify the package name? A branch (or packaging branch) doesn't necessarily link to a source package name?
[07:48] <wgrant> A packaging branch does.
[07:48] <noodles775> But it really should be linked somehow to the packaging branch (as it is for actual distro...) oh?
[07:50] <wgrant> noodles775: SPRecipe already has distroseries and sourcepackagename columns.
[07:51] <noodles775> wgrant: yeah, I know, the question was more, "when do we fill them in, and where does the info come from?"
[07:51] <wgrant> noodles775: One probably creates a recipe at a URL like /ubuntu/lucid/+source/dpkg/+new-recipe
[07:52] <noodles775> Yeah, that's fine for a distroseries source package... but what about for my personal branch foo with my personal packaging branch bar, that I want to build into my ppa?
[07:52] <wgrant> That's where package branches fall down.
[07:52] <noodles775> (or maybe I'm trying to generalise it too far?)
[07:52] <noodles775> Oh, ok.
[07:53] <wgrant> That is a general hole in Launchpad's model.
[07:53] <noodles775> Yeah, hence the question there. I think we need to resolve it, as we need to be able to build general branches.
[07:54] <wgrant> The current solution is to have unofficial branches under the Ubuntu namespace.
[07:54] <wgrant> That probably makes a bit of sense.
[07:54] <wgrant> And since recipes are namespaced by owner, there's little-to-no problem keeping them all under Ubuntu.
[07:55] <wgrant> It's reasonably correct -- they are branches of the Ubuntu package.
[07:56] <wgrant> (the bigger problem is that Ubuntu branches are branches of Debian branches, which are branches of the upstream project. Yet all these branches are kept in independent spaces. But that's not terribly important here)
[07:56] <noodles775> OK, so that would mean that when I select my packaging branch, it is automatically implying the distroseries.
[07:56] <wgrant> Well, a packaging branch needn't really be distroseries-specific.
[07:56] <noodles775> s/packaging branch/recipe
[07:56] <wgrant> Although they must for now live in one.
[07:57] <wgrant> Yes.
[07:57] <wgrant> A recipe has a distroseries.
[07:57] <wgrant> (this is too complicated and messy and aaarrggh)
[07:57] <noodles775> But here's the problem - when I am *creating* the recipe to build a branch...
[07:57] <noodles775> +1
[07:58] <wgrant> You always create a recipe from a view or method on a SourcePackage.
[07:59] <noodles775> Yes, that may be necessary then - I was hoping the process of recipe creation could be done while requesting the build (ie. in a single step) as outlined in the ui mockups.
[07:59] <wgrant> Hmmmm, true. That is unfortunate.
[07:59]  * wgrant looks at the mockups.
[08:07] <wgrant> We can probably infer the SPN from project<->package links. But I cannot see a sane way around asking for the distroseries.
[08:08] <wgrant> That's probably something that you *always* want to ask for anyway.
[08:09]  * wgrant grabs Balsamiq.
[08:10] <noodles775> Thanks!
[08:23] <wgrant> Hrm hrm hrm.
[08:25] <noodles775> yarp.
[08:25] <wgrant> I guess that in a lot of cases the recipes will be identical between multiple series.
[08:26] <noodles775> Huh? Won't they require different packaging branches? (if the packaging branches are distroseries specificy)
[08:26] <noodles775> (ie. different merge directives)
[08:26] <wgrant> If they are, yes.
[08:35] <wgrant> It seems really awkward to ask for a distroseries which is probably redundant with information on the package branch, but I cannot think of a way around it.
[08:35] <noodles775> Yeah, and what if the information conflicts?
[08:37] <noodles775> Could we require something like the ISeriesSourcePackageBranch to be defined for personal branches also?
[08:38] <wgrant> I don't think that makes sense.
[08:39] <wgrant> The case here is that I want to build this non-distroseries-specific project branch. I might not even own that branch. It shouldn't need any magic on that branch.
[08:40] <wgrant> We shouldn't complain if the series conflict. If it works, it will work. If it doesn't, it will fail to build.
[08:40] <wgrant> Restrictions like that are more likely to be inconvenient than anything else, I think.
[08:40] <noodles775> Yep, it'd just be strange to say "you said this was for karmic but then your source package branch was for lucid".
[08:40] <noodles775> OK, true.
[08:41] <wgrant> I might be doing that because I'm (quite feasibly) reusing the hardy packaging branch all the way up to lucid.
[08:41] <wgrant> I do that.
[08:42] <noodles775> In which case it shouldn't fail, but give priority to the recipe distroseries right?
[08:43] <wgrant> I don't think we should look into the recipe data at all.
[08:43] <wgrant> So yes, the one the user specifies explicitly wins.
[08:43] <wgrant> Because we might have multiple package branches, or none.
 (this is too complicated and messy and aaarrggh)
[09:01] <mwhudson> that seems to describe the problem domain well enough
[09:01] <mwhudson> bigjools, noodles775: good morning
[09:01] <noodles775> Hi mwhudson
[09:02] <wgrant> Evening mwhudson, morning bigjools.
[09:02] <bigjools> hello
[09:03] <bigjools> not here for long, in a meeting
[09:03] <wgrant> Windows Me!
[09:03] <noodles775> lol
[09:04] <mrevell> Morning
[09:36]  * wgrant mourns the 12 i386 builders that have vanished in the last few hours.
[09:39] <al-maisan> wgrant: what do you mean? How did they vanish?
[09:39] <wgrant> al-maisan: There were 19 earlier. There are 7 now. I presume Enablement stole them back for a while.
[09:39] <wgrant> (fortunately the queue isn't too huge yet)
[09:39] <al-maisan> ah, I see.
[09:54] <asabil> Hi all
[09:56] <adiroiban> jtv, henninge Hi, I'm looking at bug 512307, and rather than filter „merged” contributors in the view, would not it be recommended to filter them in the „source” POFile.contributors ? In doing so, in the view we would just display them.
[09:57] <adiroiban> are there any place in LP where we would like to manage translations of merged accounts ?
[09:59] <jtv> adiroiban: did my reply just now get through?  having trouble with irc spam protection I guess
[09:59] <adiroiban> jtv: nope
[10:00] <jtv> ah.  First of all, I said hi.  :)
[10:00] <jtv> Second: it does sound sensible to me to do this further down, like you suggest.
[10:01] <jtv> In fact, I'm not sure mere filtering is quite right; why not display the target account instead?
[10:01] <adiroiban> jtv: because there is a list of top 20 contributors
[10:01] <adiroiban> and displaing the target will create duplicate entries
[10:02] <adiroiban> I will filter in the view then
[10:04] <jtv> Yes of course you need to filter _as well_, but _mere_ filtering has the weird effect of leaving out contributors.
[10:05] <adiroiban> I was thinking that merging two accounts will also transfer all the contribution to the new one
[10:05] <jtv> That's exactly what I mean.
[10:08] <asabil> Did anyone think about using bzr-externals with the launchpad code ?
[10:12] <asabil> for managing the download-cache and sourcecode ?
[10:20] <wgrant> noodles775/al-maisan: Can you guys see germanium's publisher logs?
[10:20] <noodles775> I just tried to check, but can't ssh in at the moment, can you al-maisan ?
[10:20] <al-maisan> wgrant: I am not sure, let me see whether they are replicated on devpad
[10:21] <al-maisan> noodles775: cannot ssh into devpad either
[10:21] <wgrant> The source and binary files in question are on disk, the binaries are listed in Packages, but the sources are not in Sources, and the source publishing statuses haven't been set.
[10:22] <wgrant> One special thing of note: the Lucid source is 3.0 (quilt), and shares its orig.tar.gz with the 1.0 sources from earlier series, that also remain unpublished.
[10:22] <al-maisan> wgrant: hmm .. maybe the publisher died before finishing its run properly
[10:27] <wgrant> al-maisan: But that would mean it would just try again on its next round.
[10:27] <wgrant> And there should have been quite a few since.
[10:28] <al-maisan> wgrant: good point. I am trying to get access to the logs and see what can be gleaned from these.
[10:28] <wgrant> al-maisan: Thanks.
[10:41] <al-maisan> wgrant: it appears the files to be published already existed on disk but the check sums did not match (see, lib/lp/archivepublisher/diskpool.py|188|)
[10:42] <wgrant> al-maisan: Argh. I checked that the sizes were all OK, but didn't bother with the checksums.
[10:43] <wgrant> al-maisan: It's the orig.tar.gz, isn't it?
[10:43] <wgrant> How was that copy not rejected, I wonde.r..
[10:44]  * al-maisan looks at the log again
[10:45] <wgrant> Yeah, that copy should have been rejected.
[10:46] <al-maisan> the copy logic probably does not look at the check sums
[10:46] <wgrant> I thought it did.
[10:46]  * wgrant looks.
[10:48] <wgrant> Well, it appears not to.
[10:48] <wgrant> I'd always assumed it did :/
[10:49] <al-maisan> wgrant: would you like to file the bug .. or should I?
[10:49]  * wgrant will.
[10:50] <al-maisan> wgrant: thank you
[10:53] <wgrant> Bug #387049
[10:55] <al-maisan> oh wow! There was a bug already?
[10:55] <wgrant> Now, how to fix the PPA... deleting the two old publications should resolve the situation once processdeathrow runs. But that seems evil.
[10:56] <wgrant> Yes, there was.
[10:56] <wgrant> No bot?
[10:56] <al-maisan> nope
[10:56] <al-maisan> "Copy backend does not detect file conflicts", https://bugs.edge.launchpad.net/soyuz/+bug/387049
[10:58] <al-maisan> wgrant: thanks for digging that bug out!
[10:59] <wgrant> al-maisan: Thanks for fighting devpad for me.
[10:59] <al-maisan> well, for us :)
[11:36] <henninge> Does anybody know where I should find the "ec2-register" command?
[11:37] <henninge> Is that one of our tools or something from Amazon?
[11:38] <wgrant> henninge: It's part of the 'ec2-api-tools' package.
[11:39] <henninge> wgrant: cheers!
[11:49] <adiroiban> any idea how to get around the ForbiddenAttribute: ('__len__', <storm.sqlobject.SQLObjectResultSet error. Here is my code: http://paste.ubuntu.com/366780/
[11:50] <wgrant> adiroiban: You should use .count() instead.
[11:51] <wgrant> Oh, you're not calling it explicitly. I seeeee.
[11:52] <adiroiban> I guess I have to convert it to a "plain" array ?
[11:52] <salgado> adiroiban, you have to generate a list out of self.context.translators before you can reverse() it
[11:52] <adiroiban> salgado: ok. thanks!
[11:53] <salgado> adiroiban, but that might not be a good idea if context.translators can return an arbitrary number of items -- it might cause timeouts
[11:54] <adiroiban> then just use for statement
[11:55] <adiroiban> iterating using the index ?
[11:59] <salgado> adiroiban, no, in that case it's best to create a new method on the content class which returns the items in the order you want.  or extend the existing one to let you specify the sort order
[12:00] <adiroiban> well, the current one is a property
[12:00] <salgado> it can be turned into a method easily
[12:03] <adiroiban> thanks. I will try this way
[12:30] <asabil> Did anyone think about using bzr-externals with the launchpad code ?
[12:33] <adiroiban> salgado: any hints regarding turning a property into a method ? The property is also used as a schame.Field
[12:34] <salgado> adiroiban, I'm not following you
[12:35] <adiroiban> you said that is easy to turn a property into a method, but I don't know what is the easy way
[12:37] <salgado> adiroiban, you just need to remove the decorator (@property), add the extra arguments you want and update callsites
[12:38] <adiroiban> thanks! and how I change the interface, as the property is defined in the interface using Field(required=true)
[13:31] <noodles775> Hi james_w
[13:32] <noodles775> In your email about the 'trigger' for the buildfrombranch work, were you talking about this branch, or something else:
[13:32] <noodles775> https://code.edge.launchpad.net/~abentley/launchpad/build-recipe
[13:32] <noodles775> (it's approved but not landed - so I wasn't sure if you and abentley had found more work required there).
[13:49] <thekorn> hi, who is the best person to guide my through the process of fixing bug 282178 ?
[13:49] <thekorn> hmm, no bot, https://bugs.edge.launchpad.net/malone/+bug/282178
[13:51] <thekorn> intellectronica, ^^ you maybe, since you put some hints in the title
[15:31] <EdwinGrubbs> mars: ping
[15:31] <mars> hi EdwinGrubbs, want to have that pre-implementation call?
[15:32] <EdwinGrubbs> mars: yes
[15:32] <EdwinGrubbs> mars: skype?
[15:32] <mars> EdwinGrubbs, yes, just a minute
[15:48] <bac> intellectronica: and here?
[15:48] <intellectronica> 1 2 3 test
[15:49] <bac> intellectronica: but i guess we have the larger problem with unregistered users.
[15:49] <intellectronica> yeah :-/
[15:50] <rockstar> Morning
[15:50] <intellectronica> morning, rockstar
[15:50] <rockstar> bac, we shouldn't need voice, just be identified by Freenode.
[15:51] <bac> rockstar: i have no idea what i'm doing.  just discovered that worked to get intellectronica back
[15:51] <intellectronica> i was muted, i guess i'm not registered
[15:51] <bac> intellectronica: i think all unidentified users are muted
[15:51] <intellectronica> but we do want unregsitered users to be able to talk in these channels
[15:52] <rockstar> intellectronica, I think the answer is yes, until we have a problem with it.
[15:53] <rockstar> bac, try /mode -q $~a
[15:53] <rockstar> Then take away intellectronica's voice.
[15:53] <intellectronica> rockstar: plotting against me again? o_O
[15:54] <rockstar> intellectronica, now talk!
[15:54] <intellectronica> 1 2 3 test
[15:54] <rockstar> :)
[15:54] <intellectronica> cool, that worked! :)
[15:54] <rockstar> bac, I think we may need to do that in all our channels.
[15:54] <bac> rockstar: just did #launchpad
[15:55] <bac> rockstar: there seems to be another problem with #launchpad-reviews as it is unregistered
[15:55] <bac> rockstar: i cannot become an op in there
[15:55] <rockstar> bac, cool.  It doesn't look like you have op in launchpad-meeting either.
[15:55] <bac> rockstar: didn't try
[16:14] <asabil> are there any plans to make/help making lp easy to deploy on private servers ?
[16:15] <maxb> Canonical seems to be rather staunchly against that
[16:16] <asabil> maxb, I am aware of that fact, but are there any people interested in making it happen ?
[16:17] <maxb> I'd love it to happen, but I don't really have any time to lend to such an effort for the forseeable future.
[16:18] <asabil> maxb, if you can provide directions, I can work on it
[16:20] <james_w> noodles775_: no, the trigger was the next task we took on, hoping to provide an API call to trigger a recipe build
[16:20] <noodles775_> ok, thanks james_w
[16:32] <bac> abentley: do you know about https://launchpad.net/people ?
[16:32] <bac> abentley: i point it out based on your CHR handover email
[16:33] <abentley> bac, no, I didn't.
[16:33] <abentley> bac, where should I have looked for it?
[16:34] <bac> abentley: it appears a link to that page got dropped from the front page when we went to UI3.0
[16:34] <abentley> I'm glad it's just a navigation issue, not a missing feature.
[16:35] <kfogel> beuno: is http://paste.ubuntu.com/366934/ the right way to incorporate your suggestions to add an "order by: " label (along with getting rid of the word "by" in the selection items)?
[16:36] <kfogel> allenap: (see my above question to beuno; you might know the answer, as this is an easy one)
[16:37] <allenap> kfogel: I don't know that one, sorry :-/
[16:37] <kfogel> allenap: np
[16:41] <beuno> kfogel, looks like it, yes
[16:41] <kfogel> beuno: thanks
[16:46] <kfogel> intellectronica: in your comments on https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/+merge/18181, I didn't quite understand one of them:
[16:46] <kfogel> "Why do you need to read from the request directly? If there's a zope form
[16:46] <kfogel> covering this, you can get the value from self.request.form. If there isn't a
[16:46] <kfogel> form then maybe we should consider having one, since it gives us validation
[16:46] <kfogel> "for free" (here it seems there's no validation at all).
[16:46] <kfogel> "
[16:46] <kfogel> intellectronica: not quite sure what you meant by "a zope form covering this".
[16:48] <intellectronica> what i meant is that you are reading parameters from the reply, but usually we use zope's form machinery, which renders the form using the definition of an interface, renders the form, validates the input (reloading the page with an error message) and finally collects the correct values in self.request.form
[16:48] <intellectronica> if you're not going to use this because it's overkill, then i guess at least you need to make sure it's safe
[16:49]  * kfogel reads carefully
[16:51] <kfogel> intellectronica: I'm not sure how to judge whether it's overkill or not.  This is just the "orderby" dropdown selector on the patches view list.  What's a good example of how to use Zope's form-processing machinery to do this instead?
[16:52] <intellectronica> kfogel: hmmmm ... maybe it's overkill given the time available. ideally this should be a zope form backed by an enum with all the options
[16:52] <kfogel> intellectronica: I grok what you're saying about validation.  Is the idea that, if we don't use Zope's way of doing this, then I will have to violate DRY because I'll have to repeat the valid values in the code, in order to validate them?
[16:53] <intellectronica> so i'd say for now let's just make sure the input is safe and valid, and file a bug (and an XXX?) for the rest of the work
[16:53] <kfogel> intellectronica: I don't mind leaving an XXX, given the time constraints.
[16:53] <kfogel> intellectronica: I'll show you a diff hunk in a moment, just to make sure I'm on the right track.
[16:53] <intellectronica> cool
[16:54] <bac> abentley: https://bugs.edge.launchpad.net/launchpad-registry/+bug/504633
[16:54] <mup> Bug #504633: add a link to /people page from / page <Launchpad Registry:Triaged> <https://launchpad.net/bugs/504633>
[16:54] <abentley> bac, thx.
[16:54] <intellectronica> kfogel: and exactly about how using an enum and a form for both the ui and validation will save us from repeating ourselves
[16:57] <kfogel> intellectronica: http://paste.ubuntu.com/366945/  (you'll see some other stuff in there, also due to your review, but the top of the hunk is what matters right now)
[16:58] <kfogel> intellectronica: I'll put the XXX in there too, of course
[16:58] <intellectronica> kfogel: cool
[17:00] <kfogel> intellectronica: is there a special tag or summary marker we use for XXX bugs, btw?
[17:00] <intellectronica> kfogel: tech-debt?
[17:00] <intellectronica> maybe i'm inventing it, don't know
[17:01] <kfogel> intellectronica: I'll check, thx.
[17:09] <kfogel> intellectronica: https://bugs.edge.launchpad.net/malone/+bug/515584
[17:09] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <Launchpad Bugs:Confirmed for kfogel> <https://launchpad.net/bugs/515584>
[17:09] <intellectronica> cool
[17:25] <didrocks> hey
[17:26] <didrocks> I try to create a serie with Launchpadlib (not a milestone, nor a release, but a serie), but I can't find if the function is exposed. Any idea?
[17:30] <maxb> There doesn't appear to be a relevant method on project at edge/+apidoc, so I would say no
[17:33] <didrocks> maxb: ok, thanks, maybe I should ping jml on that, I don't want to do screenscraping for Quickly :)
[17:44] <kfogel> intellectronica: any hints for example code on how to get the bug icons to color along with importance?  (right now, the bug images stay grey, which is wrong of course)
[17:44] <kfogel> intellectronica: I'm starting at lib/lp/bugs/templates/buglisting-default.pt, but the code to do it apparently isn't in there.
[17:47] <kfogel> adeuring: I'm going to ping Jorge soon and give him an update.  How's the patch-age sorting progress?
[17:47] <intellectronica> kfogel: iirc you need to set their css class using something that contains the importance value. don't remember exactly, but will try to find an example now
[17:47] <adeuring> kfogel: slowly :( I'm still fighting with Storm...
[17:48] <kfogel> adeuring: ugh, sorry.
[17:48] <kfogel> intellectronica: I'll keep looking too.  thanks
[17:49] <intellectronica> hmmm, maybe not
[17:49] <intellectronica> kfogel: are you using bugtask/image:icon to render them?
[17:50] <kfogel> intellectronica: let me see
[17:50] <kfogel>              <td style="padding-right: 1em;"
[17:50] <kfogel>                  tal:content="patch_task/importance/title"
[17:50] <kfogel>                  tal:attributes="class string:importance${patch_task/importance/name}"></td>
[17:50] <kfogel> intellectronica: ^^
[17:50] <intellectronica> this should give the colourful behaviour without anything additional in the template
[17:50] <kfogel> intellectronica: lib/lp/bugs/templates/bugtarget-patches.pt is where this is
[17:51] <intellectronica> kfogel: but that's the importance, which is textual, not the icon
[17:51] <kfogel> intellectronica: right now, patch_task/importance/title is giving the icon too, AFAICT
[17:51] <kfogel> OH
[17:51] <kfogel> intellectronica: no, it's this:
[17:51] <kfogel> <a tal:replace="structure patch_task/bug/fmt:link" />
[17:52] <intellectronica> and that includes both the icon and the bug #?
[17:52] <kfogel> intellectronica: yup.  it includes icon, followed by fully linked text like this:
[17:52] <kfogel> Bug #24: Bug I: six attachments (three patches, three non-patches).
[17:52] <intellectronica> hmmmm ....
[17:52] <mup> Bug #24: uploading language po file causes extra lines to be appended <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/24>
[17:52] <kfogel> intellectronica: (all of that text is a link to the bug)
[17:52] <intellectronica> the problem, of course, is that bugs don't have importance, it's bug tasks that do
[17:52] <kfogel> intellectronica: right :-)
[17:53] <kfogel> intellectronica: but I think we list by task too
[17:53] <kfogel> intellectronica: so it's okay
[17:53] <kfogel> intellectronica: let me make a listing that has the same patch listed multiple times with different task importances, one sec
[17:54] <intellectronica> what happens if you remove the /bug/ and try fmt:link on the task directly? does it do anything sensible?
[17:54] <kfogel> intellectronica: okay, got it (with my sampledata, it's https://bugs.launchpad.dev/ubuntu/hoary/+patches)
[17:54] <kfogel> let's see...
[17:54] <kfogel> intellectronica: hunh.  it still works, but the bug icons are all the same color
[17:55] <kfogel> intellectronica: AH
[17:55] <kfogel> intellectronica: no, it works.  It just happens that the tasks for ubuntu/hoary were "confirmed" and "undecided" or something,
[17:55] <kfogel> so they showed up the same color.
[17:55] <intellectronica> yay
[17:55] <kfogel> confirmed and new, actually
[17:55] <kfogel> oky
[17:55] <kfogel> wow
[17:55] <kfogel> intellectronica: that was the fastest fix ever.  thank you
[17:58] <kfogel> intellectronica: progress, just fyi: all of beuno's suggestions are now incorporated, and about half of yours so far.  I'm pushing branch up as I go.
[17:58] <intellectronica> awesome
[17:59] <intellectronica> kfogel: i'll have to leave shortly, but will be back in ~2-3h for more
[17:59] <kfogel> intellectronica: great.  (Do you always work that late?)
[18:01] <intellectronica> no, but there's still so much to do and i did waste some of the morning and i do have to run out for an appointment, so i don't mind sitting for another hour or two when i'm back
[18:05] <kfogel> intellectronica: gotcha
[18:14] <mrevell> nytol
[19:07] <kfogel> intellectronica: ayt?
[19:08] <kfogel> adeuring: in intellectronica's comment here, http://paste.ubuntu.com/367021/, where do you think a good place to put the new helper function would be?  I'm thinking maybe in lib/lp/testing/factory.py somewhere, but not sure.
[19:20] <jtv> henninge: heyyy, did I see pottery landing there?
[19:21] <henninge> jtv: yes, you did!
[19:21] <jtv> \o/ !
[19:21] <henninge> :-D
[19:21] <henninge> jtv: I got it figured out with mwhudson this morning
[19:21] <jtv> that's great
[19:21] <henninge> jtv: and I created a wiki page about it ...
[19:22] <kfogel> allenap: how's progress on person/team for patches view?
[19:22] <henninge> jtv: https://dev.launchpad.net/EC2Test/Image
[19:22] <jtv> henninge: even better... thanks for that!
[19:23] <mwhudson> good morning by the way
[19:23] <kfogel> mwhudson: good morning.  Kind of early for you, no?
[19:23] <henninge> mwhudson: Hi, thanks for the help!
[19:23] <mwhudson> kfogel: 08:23? not really
[19:24] <mwhudson> henninge: your wiki page misses a step, understandably enough, as i don't think i told you about it :-)
[19:25] <mwhudson> ah, no
[19:25] <henninge> mwhudson: oh, what is it?
[19:25] <mwhudson> henninge: i thought it skipping making the image public
[19:25] <henninge> marking the image as public?
[19:25] <henninge> ;-)
[19:25] <mwhudson> henninge: i think i'll edit the page to include the command to do that
[19:26] <henninge> mwhudson: please do, I did it through the AWS dashboard.
[19:26] <mwhudson> henninge: done
[19:26] <henninge> cool
[19:26] <mwhudson> henninge: something i've gradually learnt is that the command line tools are actually more convenient than any of the other tools for some things :-)
[19:27] <adeuring> kfogel: that helper could go somewhere "close" to the test factory, i think. i.e. lib/lp/testing./factory.py
[19:28] <adeuring> I mean, it could go into that file
[19:29] <kfogel> adeuring: cool.  I'll have another question in a moment; chatting with jcastro right now about his timing.
[20:12] <mwhudson> hm
[20:12] <mwhudson> i wonder where my headset is
[20:24] <kfogel> barry: got a sec to help me figure out why my attempt to use Python's glorious 'with' statement isn't working?
[20:25] <thumper> hi mwhudson
[20:26] <mwhudson> thumper: hello
[20:26] <kfogel> Anyone here successfully used Python's 'with' statement in story tests?
[20:26] <kfogel> http://paste.ubuntu.com/367057/
[20:27] <kfogel> adeuring: ^^
[20:27] <mwhudson> hm, doctests vc future
[20:28] <adeuring> kfogel: mwhudson mihgt be right... sorry for my obviously nonsensical suggestion...
[20:29] <kfogel> mwhudson: "doctests vc future" ?
[20:29] <adeuring> kfogel: also, we haven't yet heard about jtv's reason not to like !iwth" in conjunction with transactions.
[20:29] <kfogel> is that "vs" ?
[20:29] <jtv> "!iwth"?
[20:29] <kfogel> adeuring: hmmmm.  Okay, given this, I'm going to fall back (for now) on just making it a normal meta-factory method, with a user parametere.
[20:29] <kfogel> jtv: Python 'with' statement :-)
[20:30] <jtv> ah :)
[20:30] <mwhudson> kfogel: yeah, was meant to be vs
[20:30] <kfogel> mwhudson: oic
[20:30] <adeuring> jtv: as kfogel said. Barry suggested in the reviewer meeting that we should start to use "with"
[20:30] <adeuring> but he said also that you have some objections
[20:30] <jtv> I think I've already seen it used.
[20:31] <kfogel> mwhudson: Oh well.  Once again, I give up something I used to get 15 years ago in Lisp, so that I can write code in the modern age.  *cough*  *cough*  :-)
[20:31] <mwhudson> kfogel: you could just not use doctests <wink>
[20:31] <jtv> kfogel: My objections against "with" are more from a language design standpoint and database frontend design standpoint; I think it'd be nice to have it apart from some insane over-engineering that luckily is optional.
[20:32] <kfogel> mwhudson: I have a choice? :-)
[20:32] <jtv> kfogel: Although IMHO it also fails to solve the main thing it's almost useful for.
[20:33] <jtv> kfogel: so I'm not objecting to its use per se; but sadly it ends up being a very thin layer of syntactic sugar for "try: ... finally:"
[20:33] <allenap> kfogel: I've been spending some time looking at lp:~thekorn/launchpad/make_iperson_ihasbugs, which intellectronica said was related. It is, but not strongly (I think), so one won't hold up the other. I also discovered what the problem was in thekorn's branch.
[20:34] <kfogel> allenap: excellent (for thekorn, anyway :-) )
[20:36] <allenap> thekorn: If you're around, the problem is that the Person model class does not fulfil IHasBugs. However, IHasBugs is an ugly interface which needs some refactoring. This, I think, will fix IPerson.searchTasks() for the API without too much pain.
[20:36] <thekorn> allenap, I think one problem was that IPersonPublic should not inherit from IHasBugs but IBugTarget
[20:37] <noodles775_> hi mwhudson, have you got time for a brief call when you're finished your standup?
[20:37] <thekorn> allenap, btw, thanks for looking at this branch
[20:37] <mwhudson> noodles775_: yes, and it's just finished
[20:38] <thekorn> allenap, give me one second, let me push what I have changed over the last couple of hours
[20:38] <allenap> thekorn: Well, the relationship is not really right. People can't have bugs targeted to them. But, if we move searchTasks() into a separate interface, say IBugTaskSearchable (argh, but I can't think of anything better right now), then IPersonPublic can inherit from that.
[20:38] <allenap> thekorn: And so can IHasBugs.
[20:41] <thekorn> ok, so IBugTarget means: "there can be bug targetted to this object"
[20:41] <thekorn> this logic is new to me, but makes perfect sense
[20:45] <allenap> thekorn: Yes, that's the idea I think.
[20:45] <thumper> abentley: I've noticed some diffs having a link saying there are conflicts, but there are no conflict markers in the diff shown
[20:45] <allenap> thekorn: But then IBugTarget should be that.
[20:45] <thumper> rockstar: what's the status of the scanner cherry pick?
[20:45] <abentley> thumper, I believe it's all diffs.
[20:46] <thumper> abentley: is it None vs '' ?
[20:46] <rockstar> thumper, failed tests on Friday.
[20:46] <allenap> thekorn: Actually, you know, I'm probably wrong :)
[20:46] <abentley> thumper, I think so.
[20:46] <rockstar> thumper, back in ec2 now.
[20:46] <thekorn> allenap, but there is a good chance you know better than me ;)
[20:46] <thekorn> will change it back to IHasBugs, for now
[20:52] <intellectronica> kfogel: back
[20:53] <kfogel> intellectronica: hey there.  Everything is proceeding okay on my end; no questions yet, though there may be later.  You're here for how long, you think?
[20:54] <intellectronica> kfogel: 2h
[20:54] <kfogel> intellectronica: just fyi, I tried to use the new Python 'with' when rewriting that meta-factory in the story tests, but no dice.  I didn't spend too much time on it (see backscroll), before falling back to a traditional function.
[20:55] <kfogel> intellectronica: *nod*  unfortunately some of that time I'm on a phone call, but I'll try to dig up any questions early, before you're gone.
[20:55] <intellectronica> yeah, we can revisit that later. i never implemented a with thingster, so i don't know what's involved
[20:55] <kfogel> I'll be working on this late tonight, but that doesn't help you EU peeps :-).
[20:56] <kfogel> intellectronica: for now, I changed the name from 'make_thing()' to 'do_as_user()' (and that's pushed up now).  I want to move it into lib/lp/testing/factory.py and make it a helper method in class LaunchpadObjectFactory, named doAsUser().  Does that seem reasonable?
[20:57] <intellectronica> kfogel: yeah, that sounds like a good plan
[20:57] <kfogel> *nod*
[20:57] <kfogel> okay, thanks
[21:02] <allenap> Ahem, where has testtools gone?
[21:06] <thekorn> allenap, intellectronica, what I have is working now. next step is to do the right thing on the web api side: my idea right now is: someperson.searchTasks() should be equal to bugs.lp.net/~someperson
[21:06] <thekorn> and I would also like to add some alias like method like searchCommentedTasks
[21:07] <thekorn> although I don't like the mixture of tasks and bugs here
[21:07] <thekorn> (tasks cannot have comments), but this is a more general problem ;)
[21:08] <allenap> thekorn: Get searchTasks() working first, and landed :)
[21:08] <thekorn> okidoki
[21:09] <henninge> Hi, does anybody know if "combine-css" is broken in any way? It fails like this (make build) http://paste.ubuntu.com/367080/
[21:10] <kfogel> intellectronica: okay, inside that class I've defined doAsUser(self, ...) now.  But the code for do_as_user() in patches-view.txt invoked login() and transaction.commit() and logout().  Where was it getting those functions from?  In the factory.py context, they're not defined, i.e.:
[21:10] <kfogel>     NameError: global name 'login' is not defined
[21:10] <thekorn> allenap, another question: I started working on this some time ago, should I merge recent changes to the main launchpad branch into it, or should I just ignore them (for now)
[21:11] <allenap> thekorn: Ah, that's why I'm missing stuff. Yes, definitely merge devel every so often.
[21:11] <thekorn> ok
[21:12] <intellectronica> kfogel: you can grep for where they're imported from. i don't remember off the top of my head, and they're imported magically into doctests, so i'll try to search for them in python files
[21:13] <kfogel> intellectronica: yeah, I figured it must be magic somewhere :-)
[21:13] <intellectronica> kfogel: from canonical.launchpad.ftests import login, logout
[21:14] <kfogel> intellectronica: what file ar eyou in?  ( I was starting with bin/test)
[21:14] <mwhudson> i think you can import them from lp.testing as well
[21:14] <allenap> thekorn: I just pulled your branch again and you'd added official_bug_tags to Person, the same as I had :) I think official_bug_tags needs to move to another interface. It makes no sense at all for people and teams (at the moment anyway).
[21:15] <kfogel> mwhudson: you were right
[21:22] <thekorn> allenap, so, now I'm confused, official_bug_tags is already in its own interface IOfficialBugTagTargetPublic, but I don't get how this is injected into IHasBugs
[21:23] <allenap> thekorn: It's defined in IHasBugs.
[21:23] <thekorn> oh right
[21:23] <allenap> thekorn: It should be removed from IHasBugs. It was probably an oversight that didn't break anything.
[21:24] <allenap> thekorn: Of course, something will probably rely on it :) Test suite to the rescue!
[21:24] <thekorn> allenap, how do I find relevant tests to such changes?
[21:25] <allenap> thekorn: That's hard. You could just run every test with "bug" in the name for a fair guess. If you have a powerful machine it'll probably take less than an hour.
[21:26] <thekorn> uhh, so no test driven development for me ;)
[21:33] <allenap> kfogel: I /think/ you committed the test data changes to lp:~kfogel/launchpad/506018-patch-report.
[21:35] <kfogel> allenap: aaaaaaaaack.
[21:36] <kfogel> I did.
[21:36] <kfogel> allenap: thank you.  I can easily revert that.
[21:36] <kfogel> allenap: will do after phone call
[21:36] <allenap> kfogel: Cool, it's not bothering me, so no urgency.
[21:38] <thekorn> what is the correct way to merge recent changes from the ../devel branch?
[21:39] <thekorn> just bzr merge, or is there some helper script which does the right thing?
[21:39] <thekorn> (updating dependencies etc)
[21:39] <maxb> I don't think there's any "right thing" that needs doing on top of "bzr merge"
[21:39] <maxb> In some circumstances you might need to run update-sourcecode
[21:40] <maxb> But update-sourcecode takes long enough that I wouldn't want to run it after every merge just in case
[21:41] <allenap> thekorn: It's worth having a local copy of devel (I keep a local copy of devel, db-devel, stable and db-stable).
[21:42] <allenap> thekorn: rocketfuel-get will maintain devel for you.
[21:42] <allenap> thekorn: pulling all source deps, etc.
[21:44] <thekorn> right, that's what I have too
[21:45] <allenap> thekorn: Then I just merge from the local copy of devel. Your branch is old, so it's probably worth doing a make clean && make.
[21:45] <thekorn> ok, trying ...
[21:55] <mwhudson> ground control looks pretty nifty
[22:06] <intellectronica> yeah? does it call major tom?
[22:09] <allenap> kfogel: I have a branch that registers the BugPatchesView for people and teams: lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018. Now I'm off, so cheerio until tomorrow.
[22:11] <james_w> could someone from the bugs team help me work out why we can't edit bugs through the API anymore?
[22:12] <james_w> the new bug heat stuff doesn't edit every bug every few seconds or anything does it?
[22:18] <james_w> it is blocking us doing syncs without a lot of pain
[22:25] <wgrant> abentley: What happened to landing that slave branch?
[22:26] <abentley> wgrant, the test suite is a much bigger pain to run than it was before windmill became mandatory.
[22:26] <abentley> wgrant, my latest attempt has failed with "address in use".
[22:26] <wgrant> abentley: Oooh yes.
[22:27] <wgrant> I gave up on running the whole thing locally, since I couldn't get Windmill to run properly.
[22:32] <intellectronica> wgrant: really? when did you last try? it used to be a nightmare but it works pretty smoothly for me now
[22:34] <wgrant> I haven't tried since around the sprint¸ IIRC.
[22:34] <abentley> intellectronica, so far, running under xvfb has led to lots of spurious errors.  I'm now running under screen, with a vnc session as my DISPLAY.
[22:35] <intellectronica> i never tried running under xvfb locally, i just let it fire up firefox
[22:35] <bigjools> there was a bug in xvfb that was fixed
[22:37] <intellectronica> kfogel: say, in your doctest, why do you use user_browser? shouldn't you be able to view this page as an anonymous user?
[22:37] <intellectronica> sorry for not spotting this earlier, b.t.w
[22:37] <james_w> grr, task_age
[22:37] <james_w> what's that for?
[22:38] <intellectronica> james_w: ask bdmurray - he uses it for something, not sure what
[22:38] <intellectronica> james_w: and why grrr? is it creating any problems for you?
[22:38] <wgrant>         return self.age.seconds
[22:39] <wgrant> Yes, that's going to break everything.
[22:39] <kfogel> intellectronica: very good question.  Not sure; may have just been a cut-and-pasto on our part.  I'll try with anon.
[22:39] <intellectronica> kfogel: cool
[22:39] <intellectronica> wgrant: please elaborate
[22:39] <james_w> intellectronica: you can't edit bugs over the API, as that's changing every second
[22:39] <kfogel> allenap: yay!  Thank you.  I'll check out your branch.
[22:39] <wgrant> intellectronica: That value will change every second, as james_w says.
[22:39] <wgrant> Which is going to mean that holding a bug across a second boundary then saving it will fail with a 412.
[22:40] <james_w> task has date_created, can't task_age just be calculated from that?
[22:40] <james_w> I'm pulling devel to have a look at the code myself
[22:40] <intellectronica> james_w, wgrant: wow, haven't thought about that. can you please file a bug?
[22:40] <james_w> intellectronica: sure, but I think we will want a CP for this
[22:40] <intellectronica> i think it's worth getting rid of that. it's easy to calculate age locally
[22:41] <intellectronica> james_w: maybe. it's easy to use the api from edge. in fact i assume most people do
[22:41] <intellectronica> i'll happily review a branch that kills BugTask.age :)
[22:42] <mwhudson> rockstar: hi
[22:43] <rockstar> mwhudson, hey there.
[22:43] <rockstar> mwhudson, I assume you have some reviews you need from me.
[22:43] <mwhudson> rockstar: actually no
[22:43] <mwhudson> rockstar: i was wondering what the status of your scanner fixes is
[22:44] <mwhudson> rockstar: because i want to land a bzr upgrade, but that will probably conflict with them
[22:44] <james_w> bug 515747
[22:44] <mup> Bug #515747: Exporting task_age breaks editing over the API unless you PATCH within a second of GET <Launchpad Bugs:New> <https://launchpad.net/bugs/515747>
[22:45] <intellectronica> james_w: thanks
[22:46] <rockstar> mwhudson, I got disconnected, so I didn't see what you needed.
 rockstar: actually no
 rockstar: i was wondering what the status of your scanner fixes is
 rockstar: because i want to land a bzr upgrade, but that will probably conflict with them
[22:47] <rockstar> mwhudson, it's in ec2 running against devel right now.
[22:47] <rockstar> mwhudson, it should land in the next few hours.
[22:47] <mwhudson> ok
[22:47] <rockstar> mwhudson, I'll ping you when it lands.
[22:47] <mwhudson> rockstar: what's the url?
[22:47] <rockstar> mwhudson, for what?
[22:47] <mwhudson> rockstar: your branch
[22:47] <rockstar> mwhudson, one sec.
[22:48] <rockstar> mwhudson, bzr lp-open
[22:48] <rockstar> Er...
[22:48] <rockstar> mwhudson, https://code.edge.launchpad.net/~rockstar/launchpad/scanner-events
[22:48] <mwhudson> rockstar: :-D
[22:49] <rockstar> mwhudson, the Ctrl-C and middle click has different behavior in different apps.  :)
[22:49] <mwhudson> yar
[22:49] <mwhudson> rockstar: thanks
[22:50] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/kill-task_age/+merge/18418
[22:50] <intellectronica> james_w: out of curiosity, when first running into this problem, were you using edge or production?
[22:50] <james_w> is that the right target to get it on edge ASAP?
[22:50] <james_w> intellectronica: edge
[22:50] <james_w> it happens on both
[22:50] <intellectronica> james_w: you rock. waiting for the diff
[22:50] <james_w> I'm guessing this change landed in the last week
[22:51] <mwhudson> james_w: yes, that's the right target
[22:51] <intellectronica> james_w: yes, i know it happens on both, i'm just trying to evaluate whether it's worth a CP
[22:51] <james_w> well, edge for a start please so that we can process syncs without a lot of manual work
[22:51] <james_w> then see if anyone complains :-)
[22:52] <james_w> also note that if heat is exposed on IBug it will cause some people headaches if you are using jobs to calculate it
[22:53] <james_w> that's not really fixable, so you should document the way to handle it
[22:54] <intellectronica> james_w: r=me. can you land or would you like me to land this on your behalf?
[22:56] <james_w> please do
[22:56] <james_w> I have no powers :-(
[22:57] <intellectronica> james_w: sure thing
[22:57] <thekorn> what is a CP ?
[22:58] <intellectronica> thekorn: Cherry Pick
[22:58] <mwhudson> rockstar: yes, my branch conflicts with yours
[22:58] <intellectronica> patching the production servers between releases
[22:58] <mwhudson> rockstar: a ping when it's landed would be nice
[22:58] <thekorn> ah ok
[22:58] <mwhudson> or i can just subscribe to the branch i guess
[22:58] <rockstar> mwhudson, sowwy  :(  I'll ping you when it's there.
[22:58] <mwhudson> rockstar: blame bzr!
[22:58] <rockstar> mwhudson, :)
[22:59] <intellectronica> james_w: it's on EC2. with enough luck it'll make it in before the nightly rollout
[22:59] <james_w> thanks intellectronica
[22:59] <intellectronica> james_w: thanks a lot for uncovering and fixing this. sorry for the inconvenience
[23:02] <intellectronica> kfogel: are you aware of your tests not completing successfully?
[23:02] <kfogel> intellectronica: ??
[23:02] <kfogel> intellectronica: no, they succeeded for me.  what are you seeing?
[23:03] <kfogel> intellectronica: you mean patches-view.txt, right?
[23:03] <intellectronica> oh, maybe i'm talking nonsense and it's my fault. let me go through them more thoroughly  before i waste your time
[23:03] <intellectronica> yes, patches-view.txt
[23:04] <kfogel> intellectronica: let me know if there's an issue, I'll be here
[23:04] <kfogel> intellectronica: just ran them again -- success
[23:04] <intellectronica> kfogel: false alarm. stupid me. i've changed the behaviour when there are no patches and added a test, and forgot to amend a few of the existing ones.
[23:05] <kfogel> intellectronica: ah, np
[23:09] <didrocks> intellectronica: btw, I tried to checkout launchpad and I have an error when running "make schema"
[23:09] <kfogel> intellectronica: what's the "proper
[23:09] <kfogel> " way to revert a change to a file in bzr?
[23:09] <kfogel> intellectronica: I could just diff -rNEW..OLD it and commit the change, and it would work.  But is there a best practice here?
[23:10] <kfogel> didrocks: what's your error?  (can you paste at paste.ubuntu.com?)
[23:10] <intellectronica> kfogel: bzr revert -r revno [file_path]
[23:10] <didrocks> kfogel: http://paste.ubuntu.com/367149/
[23:10] <kfogel> intellectronica: that doesn't do anything ugly to mergeinfo in our branches?  We're okay with it?
[23:10] <kfogel> intellectronica: (some recent burns on the emacs devel list have made me very cautious)
[23:11] <intellectronica> kfogel: i'm not sure what exactly you're asking, but i don't think it does anything bad. it forgets all the revisions you rolled back
[23:11] <kfogel> didrocks: you've followed every step at https://dev.launchpad.net/Getting to get to the 'make schema' point?
[23:11] <kfogel> intellectronica: sounds good.  (well, other things changed in that rev, and I'm not reverting them, so I don't want it to forget about the entire rev...)
[23:12] <didrocks> kfogel: right, I've checked twice :)
[23:12] <intellectronica> kfogel: right. i'm not sure how it works if you only revert a single file
[23:12] <intellectronica> i doubt that it will forget the entire revision, but it's worth checking
[23:13] <kfogel> intellectronica: ok, thanks.  I'll read the help and make sure.  I can alwys uncommit if it's bogus.
[23:13] <didrocks> (I didn't notice any error, but let me check back for the last part of the script which should have done lp-branches/devel/utilities/link-external-sourcecode call)
[23:13] <kfogel> didrocks: and you got no errors when you ran rocketfuel-setup?
[23:14] <didrocks> kfogel: oh bad, didn't notice that error first: http://paste.ubuntu.com/367157/
[23:14] <didrocks> I'm on lucid
[23:16] <kfogel> didrocks: ah.  Well, if bzr hiccups, things are probably not going to work :-).  I'm embarrassed to say I'm not on Lucid yet myself.
[23:17] <kfogel> didrocks: is bzr working for you otherwise?
[23:17] <didrocks> kfogel: right, I'm using it more than heavily :)
[23:17] <didrocks> (packaging and Quickly)
[23:17] <wgrant> LP needs a couple of tweaks to work on Lucid, but that isn't one of them.
[23:19] <kfogel> didrocks: I would say google for some unique part of "bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")
[23:19] <kfogel> "
[23:19] <didrocks> kfogel: right, found https://bugs.edge.launchpad.net/bzr/+bug/515325
[23:20] <mup> Bug #515325: 'Inter1and2Helper' object has no attribute 'source_repo' <Bazaar:Confirmed> <https://launchpad.net/bugs/515325>
[23:20] <didrocks> quite fresh bug :)
[23:20] <kfogel> and see if this is solveable.  If you can get Bazaar behaving okay, at least you could then make it to the roadblocks wgrant is thinking of!
[23:24] <kfogel> didrocks: hmmm.  yeah, that's fresh.  I'm not sure what to suggest, except maybe downgrading bzr?
[23:24] <kfogel> for now
[23:26] <didrocks> kfogel: do you think I just can run again just make install?
[23:26] <didrocks> as it seemed to have crashed in that part
[23:29] <didrocks> kfogel: this version of bzr has almost one month. I don't think I can afford to downgrade it
[23:37]  * mwhudson lunches
[23:39] <kfogel> didrocks: well, I would expect it to just crash again, but couldn't hurt to try...
[23:57] <lifeless> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/513432
[23:57] <mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/513432>
[23:57] <lifeless> thumper: this is affecting folk
[23:58] <lifeless> thumper: fixed in bzr, but you need to roll out newer bzr to fix it on lp