[00:27] jml: did you land your lib/devtools branch yet? [00:27] mwhudson, not even finished yet, I'm afraid. [00:27] jml: i find myself wanting to move bits of ec2test in there [00:28] mwhudson, heh [00:28] mwhudson, please feel free [00:28] I'll suck up the conflicts. [00:35] jml: i have this feeling i'll almost certainly want to talk to you about libraryizing ec2test in a while, are you going to be mostly online today? [00:35] mwhudson, I am. [00:36] great [00:36] * mwhudson looks at the code again [00:53] heh heh [00:54] Note to self: Never, ever, ever, ever do `easy_install launchpadlib` ever again. [00:54] 'sagi python-launchpadlib' works in karmic [00:54] (finally!) [00:55] very happy today because of that. [00:56] rockstar: s/launchpadlib// [00:56] mwhudson, virtualenv [00:56] rockstar: ah, ok [01:11] mwhudson, you mentioned last night that we only look in 'lp' and 'canonical' [01:11] mwhudson, I guess I ought to add 'devscripts' to that, if I can figure out how. [01:12] jml: i think it's going to be pretty easy if you find the relevant part of the code [01:13] buildout-templates/bin/test.in looks promising. [01:14] wuu. [01:15] compare and contrast: http://paste.ubuntu.com/268282/ [01:17] jml: ugh [01:18] mwhudson, that's right, 2 seconds of zopey waiting. [01:20] mwhudson, actually, when you call me re the ec2test stuff, I'd like to talk with you a little about this branch. [01:20] jml: would in about an hour work for you? [01:21] mwhudson, yeah. [01:21] cool [01:21] * mwhudson lunches [01:32] * mwhudson sings the "someone broke the buildbot" song [01:40] the blame list is surprisingly empty === Ursinha is now known as Ursinha-afk === bac changed the topic of #launchpad-dev to: is Launchpad Development Channel | Week 2 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call reviewers available, see https://dev.launchpad.net/ReviewerSchedule | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html [02:26] mwhudson, yo [02:28] jml: hi [02:29] jml: life's throwing me a curve ball, biab [02:29] mwhudson, np [02:38] cprov, I've done a bunch of stuff with nascentupload [02:38] cprov, I'd like to hook branches up to it now [02:38] cprov, which involves inferring an archive [02:38] jml: you sound scary sometimes. [02:38] I'm not scary. [02:39] jml: most of the time. [02:39] cprov, not branches up to nascentupload itself, but rather up to verify_upload. [02:40] jml: right, calculating branch push perms with verify_upload, that was the original plan, wasn't it ? [02:40] cprov, that's right [02:40] cprov, but I can't seem to recall how we figured out the archive based on the SuiteSourcePackage [02:41] there are two choices I can see. ssp.distribution.main_archive [02:41] or something handwavey that looks at the publishing history [02:41] jml: defaulting Primary, IIRC [02:41] cprov, that's ssp.distribution.main_archive, right? [02:41] jml: the current SPBranch url doesn't support PPAs [02:42] jml: yes, that's it. [02:42] cool. [02:42] easy as. [02:42] cprov, thanks. [02:42] jml: but it may change on partner uploads [02:42] jml: 'partner' component == PARTNER archive [02:42] hmm. [02:43] cprov, how do we get the component from a SuiteSourcePackage? [02:43] jml: the component of the latest publication [02:44] cprov, is there already a function or method that knows that parter component implies partner archive? [02:44] jml: there is a hack in nascentupload [02:45] jml: NU.overrideArchive() [02:45] cprov, you owe me sooo many caipirinhas [02:46] jml: countless. [03:12] cprov: When is that cesium ensurePerson CP happening? [03:13] wgrant: it won't be released until 3.0 rollout, AFAICT [03:13] cprov: Oh, damn. [03:13] wgrant: iron.cc (debian-imports) is fixed. [03:14] cprov: But Karmic is out of luck? [03:14] (as well as the rebuild -- I guess I'll get my script to ignore upload failures for now) [03:15] wgrant: sort of, maybe the 'me too' in the bug report can help to make a point. [03:16] wgrant: it's actually very simple, since the revision was already CPed. [03:16] cprov: I suppose. I will me-too. [03:28] wgrant: CP requested, easier than I thought. [03:28] cprov: Thanks! [03:28] What sort of process is involved in that? [03:34] wgrant: rolling the current production branch to a new set of machines [03:34] cprov: Well, obviously, but I imagine there's a fair bit of preparation and approval paperwork. [03:35] wgrant: in this case all soyuz upload frontends (ppa, builddmaster and ubuntu) [03:35] wgrant: the paperwork was already done for the CP on the debian-imports machine [03:35] cprov: Ah, right. [03:36] wgrant: from the developer PoV it is: 1) get it reviewed and landed on lp:devel 2) talk to the release-manager and convince him the CP is needed. [03:39] * mwhudson is still a bit unconvinced of the benefit of targeted fixes vs the downside of having different services running different code [03:39] not my field though i guess [03:40] That has caused confusion in the past. [03:41] cprov: Why are the stats on /builders down the side rather than along the top? [03:42] If they were along the top, the builder listing would be much more readable as status lines would wrap less. [03:50] wgrant: but OTOH to access the builder list you would have to always scroll down [03:51] wgrant: also the official summary is bigger than the ppa summary, so an ugly whitespace would appear if they were in the same grid row. [03:51] cprov: Some of it would fit, and the builder list is always multiple screenfuls now. [03:51] cprov: Hm, damn, true. [03:51] It seems like such a waste. [03:52] And it's hard to scan the table. [03:52] But I can't now see where else to put it. [03:52] wgrant: I still have to submit a change to fix the 'status' column content [03:53] cprov: What's wrong with it? [03:53] doesn't show 'MANUAL' mode properly neither private-builds [03:53] cprov: Works OK for private builds, AFAICT. (or at least as well as HiddenBuilder makes it...) [03:54] wgrant: but uses the NOT-OK icon, which is NOT-GOOD :) [03:54] cprov: Well, I'd say HiddenBuilder is really ungood! [03:55] wgrant: the concept itself or the implementation ? [03:55] cprov: Concept. [03:56] wgrant: the other alternative is to user an IBuilder macro, which seems much clearer conceptually, since IBuilder.status belongs to the view domain. [03:57] cprov: IBuilder.status makes me sad, yes. [03:57] If that goes into the view, and builder.logtail gets properly secured, I don't see any reason for HiddenBuilder to exist. [03:57] wgrant: being on the view means we can't use it in zopeless mode (easily) but that's not a problem anymore. [03:57] It had me very confused when I first looked around that area of code. [03:59] cprov: Why was it used in Zopeless stuff? [04:00] wgrant: when we had scripts/ftpmaster/buildd-monitor.py (a shell-like debug tool for the buildfarm) [04:00] for instance. [04:01] cprov: Ah, right. [04:01] wgrant: but as I said, not a problem anymore, it's gone. [04:02] wgrant: getting rid of HiddenBuilder and IBuilder.status looks like a nice weekend task. [04:04] cprov: I'd not object to killing it myself. [04:05] wgrant: if you have time, that would be great! [04:05] cprov: I will have ample time after finishing exams tomorrow. [04:06] I guess then the archive and sometimes source can be linked to from the status, too. [04:06] wgrant: yes, once it's done in the view domain it becomes much easier. [04:08] okay, bed-time over here. G'night all! [04:08] cprov: Night. Thanks. [04:09] wgrant: good luck with your tests and we can talk more about the IBuilder changes tomorrow. === cprov is now known as cprov-zzz [04:25] mwhudson, https://code.edge.launchpad.net/~jml/launchpad/better-sourcecode-update [05:21] argh [05:22] hm [05:22] * mwhudson fixes, but wonders how that ever worked [05:36] mwhudson, what are you fixing? [05:36] jml: i think i figured it out [05:36] jml: ec2test imports plugins without enabling plugins [05:37] mwhudson, oh yeah. [05:37] mwhudson, I saw that behaviour in the pasnt. [05:37] I'm not a huge fan of ec2test's plugin dependencies, tbh. [05:38] one thing at a time :) [05:39] heh [05:52] * jml does some scienc [05:52] e [06:10] mwhudson, interestingly, pulling each branch one after the other with no actual changes takes substantially longer than rsyncing with no changes. [06:11] jml: multiple ssh negotiations? [06:11] mwhudson, quite possibly. [06:11] 5m4s vs 12s [06:13] I find that SSH negotations to bazaar.lp.net can take up to 10 seconds at bad times. [06:13] jml: if you're using bzrlib you can probably get it to reuse the transport [06:13] jml: is your branch on lp up to date? [06:15] mwhudson, not quite [06:15] jml: give it a push and i'll see if i can give you a hint :) [06:18] mwhudson, now that I can commit safely (and thus be allowed to push again!), sure [06:20] done. [06:23] jml: oh [06:23] mwhudson, what? [06:24] cmd_pull().run_argv_aliases(['-d', destination, branch_url]) [06:24] bit hard to jam transport sharing in there [06:24] mwhudson, yeah. it was only a stop-gap. [06:25] figuring out the actual API for pulling required deciphering cmd_pull, which I'm not really up for right now. [06:25] branch.pull(otherbranch) [06:25] does that update the working tree? [06:25] jml: basically have a list around for the duration of the script [06:26] jml: pass it as possible_transports when you open the branch [06:26] jml: not sure actually [06:26] jml: so you're probably right to be cautious [06:33] :( [06:33] because the config uses lp: URLs, sharing transports isn't as easy as all that. [06:36] not sure i get the point [06:38] oh never mind. [06:38] * mwhudson EODs [06:38] it's because an edge server is having a hissy fit :) [06:38] mwhudson, ciao [06:39] jml: i think bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/libraryize-ec2test is probably good to land, ish at least btw [06:39] jml: maybe you could take a look? [06:39] jml: it's pretty boring so far [06:42] mwhudson, sure [06:45] mwhudson, fwiw, sharing the transports makes it substantially faster, but still slower than rsync. I think the extra time is lp: resolution. === jml changed the topic of #launchpad-dev to: Launchpad is having issues | is Launchpad Development Channel | Week 2 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call reviewers available, see https://dev.launchpad.net/ReviewerSchedule | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html [08:19] good morning [08:52] jml: Hi, how did we leave things w.r.t you fixing the broken stack-on location for the meta-lp-deps branches? [08:52] * maxb wonders if maybe they should be owned by a team that lets me write to them :-) === spm changed the topic of #launchpad-dev to: is Launchpad Development Channel | Week 2 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call reviewers available, see https://dev.launchpad.net/ReviewerSchedule | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html [09:03] How do you trigger the default branch stacking? Is it necessary to have a development focus? [09:13] Does anyone fancy fixing some broken stacked_on locations for me or shall I mail the list? [09:20] Now we have mad, should I assume diff-output in merge cover letters is redundant? === thekorn_ is now known as thekorn [09:38] maxb: It's not because of mad, but yes. [09:38] maxb: LP will generate the diff and email it out. [09:42] Perhaps we should update the template cover letters on the wiki? [09:54] maxb: Certainly a good idea. [11:01] Morning, all. [11:03] hi deryck [11:04] barry, ping === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:09] Hmm. Pulling devel is taking a while. Maybe I've just got a shonky connection. === matsubara-afk is now known as matsubara === Ursinha-afk is now known as Ursinha [14:28] OMG! I just got autoresponder from feedback@...I do exist [14:28] * sinzui wonders if his email will show up [14:30] heh [14:37] I would like to take this opportunity to say AAAAAAAAAAAH. [14:37] (Because primal screaming in Starbucks is generally frowned upon) [14:41] no wonder everyone looked at me strange last time I worked in Starbucks [14:41] flacoste, ping === kfogel changed the topic of #launchpad-dev to: is is Launchpad Development Channel | Week 2 of 3.0 | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html [14:49] hi deryck [14:52] bac: no karmic goodness yet. it took all night just to get windows updated. this morning wubi wouldn't work for either karmic or jaunty, but i booted to the live cd and was very happy that unlike vista, jaunty had no problem with my kvm switching. i'll hack on this more tonight [14:54] deryck: WRT bugtask-index.pt, I think there's some mileage in converting it to 3.0 and landing that before working on the redesign. It (should) only be a couple of minor tweaks to get it up to spec, AFAICT. That okay with you? [14:54] gmb, of course. [14:55] Cool. [14:56] deryck: Of course, if I'm wrong and it ends up being more painful than I expected, I'll just go straight for the redesign since we're not really losing anything in that case. [14:56] gmb, right, makes sense. [14:57] gmb, you might just consider the questions of what actions go in the portlet, etc. based on the conversion rules. That is a large part of the redesign idea anyway. [14:57] deryck: Right. I'll look at that. After I get the portlets to appear in the right place, that is... [14:57] heh. understood. === cprov-zzz is now known as cprov [15:11] * gmb -> afk for a bit to pick the car up; back later on [15:12] Oh, wait. Might be an idea to make sure there's a train to catch before buggering off. [15:12] * gmb stays put [15:18] barry: finally it seems zope will check-in your doctest fix!!! [15:32] flacoste: wow === salgado_ is now known as salgado [15:38] Right, *now* i'm going to go get my car. Back later, people. [15:40] stub, Chex, gary_poster, rockstar, bigjools, henninge_, sinzui, intellectronica, Ursinha: LP production meeting in 20 @ #launchpad-meeting [15:40] matsubara: thanks for the reminder [15:41] ty [15:41] I love all-day meetings and phone calls [15:41] matsubara: thanks, danilos will sit in for me today again. [15:48] cprov, hi [15:48] Ursinha: yo! [15:48] :) [15:49] cprov, have you seen this problem before? OOPS-1347F129 [15:49] https://devpad.canonical.com/~jamesh/oops.cgi/1347F129 [15:49] hmm bad link? [15:49] https://lp-oops.canonical.com/oops.py/?oopsid=1347F129 [15:50] Ursinha: let me check. [15:51] sure [15:54] Ursinha: I never seen it before, let me investigate, I will report back in a bit. [15:55] sure cprov, thanks! === kiko__ is now known as kiko [16:15] abentley, Could this issue be caused by mad and some preview diff changes: https://lp-oops.canonical.com/oops.py/?oopsid=1348EA292 === Ursinha is now known as Urshina === Urshina is now known as Ursinha === deryck is now known as deryck[lunch] === cprov is now known as cprov-lunch [16:41] rockstar: Yes, it could. We may need to blank existing diffstats. === salgado is now known as salgado-lunch === matsubara is now known as matsubara-lunch === deryck[lunch] is now known as deryck [17:43] flacoste: Thanks! And that version of launchpad-dependencies is good to be copied to jaunty too [17:45] maxb: good point, doing that right now [17:46] I'm assuming that at this point in time we're just ignoring intrepid completely, and hardy mostly unless something urgent comes up [17:46] yes [18:03] Ursinha: re. https://lp-oops.canonical.com/oops.py/?oopsid=1347F129, that's an *insane* URL (probably create with a double copy & paste). I don't really know what to do to prevent it. [18:04] Ursinha: please file a bug on soyuz, I will find out how to generate a proper 404 for it. [18:04] sure cprov-lunch, thanks === cprov-lunch is now known as cprov === matsubara-lunch is now known as matsubara [18:09] bac: only 100 failures to go! === salgado-lunch is now known as salgado [18:40] barry: i thought you only started with 70 [18:41] bac: i merged rf :( [19:08] Soyuz is DONE!!! [19:08] Congratulations to cprov, noodles775, bigjools! [19:09] flacoste: thanks, and AFAIK the prize is 'now, convert blueprints' :) [19:09] part of the prize :-) [19:09] but i won't bug anybody with that until Monday [19:09] And registry has converted their 100th template [19:09] congratz to soyuz! [19:12] flacoste: I'm not complain, it's fair enough we've pushed most of the complex templates (distribution, distroseries) to foundations. [19:13] err, registry [19:13] foundations are the 3.0 UI slacker [19:14] don't forget I did some of registry's templates already :) [19:47] gary_poster, around? [19:48] salgado: yes [19:49] gary_poster, hi there. quick question... is it possible to go up from a subview to the view that originally called it? [19:49] * salgado realizes this may not be a very clear question, but knowing how smart gary_poster is, it might not be a problem. :) [19:51] salgado: heh. hey. in depends on how the subview was instantiated. If the view used itself as a context then the subview might have stashed it away. If that's not the case (and it very well might not be) the effective answer is "no". [19:51] You could actually do it by climbing the stack to find the frame of the parent view maybe, but I don't think anybody wants to see that code. :-/ [19:53] salgado: ...there might possibly be something stashed on the request you could use, though I doubt it. Well, maybe. Looking... [19:53] gary_poster, in this case the subview was called from the template ('context/@@+foo') [19:53] yeah, that would not include the parent view as context, just the usual (context, request). [19:53] I was afraid climbing the stack was the only option, but if there's something in the request, it'd be great [19:58] salgado: still looking, because I thought there was something more likely to help and without the underline, but request._last_obj_traversed might be the top view... [19:59] that'd be just perfect [20:03] (Pdb) p self.request._last_obj_traversed.__class__ [20:03] [20:04] it is, indeed, the top view, but wrapped in this SimpleViewClass thing which prevents me from doing anything useful with it, it seems [20:04] salgado: no [20:05] salgado: views are generated class that have the actual view class as parent [20:05] salgado: if that object seems to be what you want, I think we can make it accessible without the underline with just a small adjustment. We already override the publication object, and it gets notice of the last traversed object, and the publication object is available off the request. [20:05] Therefore we could make publication.afterTraversal, or even publication.callObject, stash the terminal bit of the traversal in a more "official" way. [20:05] and then you could get the object from wherever you stashed it (the publication or the request or whatever) [20:05] gary_poster, salgado: we already have an array saving all traversed objects [20:06] although the view wouldn't be there [20:06] since it's updated by Navigation and not the request/publication [20:06] but salgado wanted to fix that [20:06] flacoste: ah, I thought I remembered that. That must be Launchpad-specific, rather than Zope? [20:06] so many things I wanted to fix [20:06] yes [20:06] request.traversed_objects [20:06] yeah, but that's updated by Navigation [20:06] not the request itself [20:07] which is dumb [20:07] and should be fixed [20:07] right, but these are different problems [20:07] yeah, if that were updated by the request then you'd have what you want. If you want a hack, then you can do what I suggested, and have one of those hooks stash the last traversed object in the same list. [20:08] then when you fix it to do the right thing, the code you write now will still work [20:08] salgado: as far as the SimpleViewClass not being what you want, flacoste is right of course--it is a generated base class, not a wrapper. You should still be able to get what you expect off of the instance. [20:09] yeah, /me gotta learn how to read the output of print statements. it clearly says it is a class [20:10] salgado: maybe already clear, but I'd say that fixing the traversed_objects generation is not quite a different problem. If the request updated that list of traversed objects, the last one would be the view to which the URL had traversed (as opposed to any traversal done within a page template) so it would probably be what you want [20:11] so yes different, but if it were fixed, there would be a clear relatively easy answer here [20:11] oh, right, I see what you mean now [20:13] for some reason I assumed request.traversed_objects should only have the content objects that we traverse and completely ignored the fact that we could append the top view there too [20:13] flacoste, do you see a problem with that? [20:14] salgado: i don't mind either way [20:14] right. it is in fact always traversed, so it is theoretically very reasonable. practically, it might throw a monkey wrench in code using that list already, but you'd be looking for that. [20:14] right, there will probably fallout from such a change [20:14] although i think the only thing that use it is the breadcrumbs code [20:14] so not a big fallout [20:14] since that's the primary reason to make this change [20:15] because you are rewriting that now, essentially, salgado? [20:15] gary_poster, I don't understand your question [20:16] I was asking if this effort--the thing you are working on that made you ask me about how to get the top-level view--is for a project of rewriting the breadcrumb code [20:17] salgado: if the fallout is big, the other approach I talked about would be less elegant but could be easily made to be less invasive. [20:17] gary_poster, not really -- all I want now is to use the title of the current page in the breadcrumbs [20:17] I see [20:17] Well, sounds like your call to me. :-) [20:23] I've already spent a lot more time than I should on this, so I'd rather go with whatever is quicker now [20:24] gary_poster, what should I do to get the actual view from that SimpleViewClass? [20:24] I've tried self.request._last_obj_traversed.__parent__, but that gives me the actual view's context [20:26] salgado: the SimpleViewClass is the view [20:27] salgado: if you look in __class__.__bases__ (maybe you will have to walk up a bit) you will see the mix in that you expect, or if you do an isinstance(view, ClassYouExpect) you should see what you expect [20:28] gary_poster, could that be security proxied? [20:28] salgado: could be yes [20:28] salgado: type(obj) should tell you [20:29] that's it [20:35] gary_poster, would it be ok if I use request._last_obj_traversed for now and file a bug to fix it right after 3.0? I really need to land this so that I can get back to work on page conversions [20:36] salgado: I don't like it, but I understand. I don't want it to get lost, if that's what you do. [20:36] salgado: but if it is fixed right after 3.0, that would be cool [20:37] cprov, salgado: Fyi, I've forced a build in devel. [20:37] cprov, salgado: Ah, and it's just fallen over again for a different reason. === gary_poster is now known as gary-away [20:38] cprov, salgado: It's because LP is fubar'ed. [20:39] allenap: yup, bzr smartserver is affected too [20:40] gary-away, I'll give bug 423898 a go, then, but if it's tricky to fix I'll resort to request._last_obj_traversed for now. thanks a lot for the help [20:40] Malone bug 423898 in launchpad-foundations "Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects" [Undecided,Triaged] https://launchpad.net/bugs/423898 [20:40] Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects [20:40] Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects [20:40] Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects [20:40] flacoste, do you have a couple minutes to talk about ^? [20:42] sure [20:42] skype or IRC? [20:42] flacoste, whatever works best for you [20:43] I just want some pointers so that I can try and fix it [20:43] ok [20:43] I had a quick look before filing it and it was not clear to me where I'd do what is currently done by Navigation [20:46] salgado: i'd suggest afterTraversal in the publication, do you agree gary-away? [20:47] good morning === cprov is now known as cprov-afk [20:53] bac: canonical.launchpad.helpers.backslashreplace() [20:54] barry: nice [20:54] barry: your way is shorter [20:54] yeah, i wish i'd known about it like 72 hours ago ;/ waaaayyy too late to go back now [20:54] yeah [20:57] abentley, rockstar: i need to be away at the stand up time, would you be ok with having it earlier? [20:58] mwhudson, sure. === gary-away is now known as gary_poster [21:02] flacoste, that didn't work -- now only the view is added to traversed_objects [21:03] flacoste, salgado: I was thinking of afterTraversal as a hack solution. It would not replace the current code, only add to it [21:03] flacoste: therefore it might be an ok interim step [21:04] that's one of the approaches I mentioned earlier [21:04] you could leave the current behavior of the navigation [21:04] but add this other behavior [21:04] and then when you did it "right" (by overriding the publication's traverse methods, and unfortunately maybe having to copy-n-paste code, because you would want to inject something in a loop) [21:04] yhe code that gets the object for titles would still be looking in the same place [21:05] salgado: did that make some sense? [21:05] I see [21:05] ??? [21:05] ah, ok [21:05] afterTraversal is called only once [21:05] not on every step [21:05] salgado: callTraversalHooks would be the one to use then [21:05] or traverseName [21:05] salgado, gary_poster^^^ === mup_ is now known as mup [21:06] flacoste, traversalHooks maybe. traverseName would make me nervous, but maybe. I'd look into it if desired, but want to get to some other tasks ATM. Well, I'll look at the publication again...argh [21:07] ok looking [21:07] gary_poster, I don't understand why I'd want a loop? I thought it'd be just a matter of moving the "request.traversed_objects.append(ob)" from one place to another [21:08] from Navigation to traversalHooks(), that is [21:08] salgado: traversalHooks might work yes. Didn't have code open, so working from memory, and have other things going on simultaneously :-) . Going to look at code now... [21:09] gary_poster, it works. :) [21:10] salgado: yes, cool. The loop I was talking about was the one in zope/publisher/base.py, in the traverse method. Since we have the hook we don't need to rewrite the loop, yes. [21:12] cool, let me run some more tests now to see if this is really what we need [21:12] thanks a lot, gary_poster and flacoste [21:13] cool, np [21:24] abentley: have you seen https://bugs.edge.launchpad.net/launchpad-code/+bug/427383 ? [21:24] Malone bug 427383 in launchpad-code "ValueError: No JSON object could be decoded in merge through the API" [Undecided,New] [21:28] has launchpad switcehd to python 2.5 yet? [21:30] jelmer: no [21:31] jelmer: talk to gary_poster about that :) === ajmitch_ is now known as ajmitch [21:35] ah, pity === kiko is now known as kiko-afk === salgado is now known as salgado-afk [22:01] * mwhudson afk for a bit [22:02] rockstar: you talk to abentley and i'll talk to you when i get back? [22:02] mwhudson, oh crap, I forgot he's off today. [22:02] You and I will chat when you get back. [22:05] bac: good news: i'm down to 22 failures. bad news: these are the ugliest ones :/ [22:05] go go go [22:05] jelmer: Ideally for LP 3.0 (this release), definitely for subsequent release. [22:05] barry, sounds like you and I are in a similar boat. [22:06] rockstar: i'm paddlin' hard :) what branch are you working on? [22:07] barry, I'm working on the branch index page. [22:08] barry, so when I ran the tests to see which failed after my changes, the answer was "all" [22:08] rockstar: heh, sounds like me. my branch changes page so every story broke [22:14] rockstar: oh yeah! [22:14] * mwhudson still not ere [22:21] mwhudson: "changes are propagated to the mirrored side" - when? [22:31] * barry fixes 2 more. 20 to go === matsubara is now known as matsubara-afk [22:42] hi, I"m getting a badsig on the lp-dev ppa [22:52] kfogel, I'm getting a badsig on the lP dev ppa [22:52] LP [22:52] micahg: Which distroseries? [22:53] And are you sure there's no proxy? [22:53] jaunty [22:53] well, I imported the key already [22:53] BADSIG means you have the key, but the signature is bad, doesn't it? [22:54] And the signature is good, so it's probably a proxy between you and LP. [22:54] micahg: I'm no sig expert, but don't install till this is resolved, obviously [22:54] ok [22:54] well, there is a proxy [22:54] but it doesn't happen for any other ppa [22:54] A bad, evil proxy. [22:54] wgrant: how could a proxy do this? The proxy shouldn't interfere with data transfer like that, should it? [22:55] A sig is just a file. [22:55] ah [22:55] kfogel: Happens all the time with bzr. It caches one version of one file, another version of another. [22:55]