[00:00] <al-maisan> rockstar: http://pastebin.ubuntu.com/355257/ (the UPDATE query)
[00:54] <lifeless> barry: off the phone?
[00:55] <barry> lifeless: yep.  had dinner too :)
[00:55] <lifeless> so
[00:55] <lifeless> 09:48 < lifeless> barry: which one ends up in the rest field in pypi
[00:56] <barry> lifeless: what is "the rest field"?
[00:57] <lifeless> there is a field called description which takes ReST
[00:57] <lifeless> and makes the pypi page pretty - e.g. if you look at http://pypi.python.org/pypi/testresources
[00:58] <barry> wouldn't that be long_description?
[00:58] <lifeless> I don't know... thus my asking ;)
[00:58] <barry> lifeless: i think so
[00:58] <lifeless> I'll try long_description on my next upload.
[00:58] <barry> lifeless: also, do you know about packages.python.org?
[00:58] <lifeless> no, never heard of it
[00:59] <barry> lifeless: http://packages.python.org/munepy/
[00:59] <lifeless> pretty
[00:59] <barry> lifeless: you upload a zip file with an index.html.  nice for uploading a full sphinx documentation tree
[00:59] <lifeless> oh cute
[01:00] <lifeless> can setup.py do that too?
[01:00] <lifeless> or better yet, is there an API for doing all this without setup.py ?
[01:00] <barry> lifeless: if you go to a package you admin, and click on the pkg_edit link, you'll see an upload form.  not sure if it can be uploaded from setup.py
[01:00] <barry> lifeless: that i'm not sure about
[01:01] <lifeless> whats the right place to find out (about setup.py for starters)
[01:01] <barry> lifeless: disutils-sig probably
[01:01] <barry> lifeless: oh also...
[01:02] <barry> http://docs.python.org/distutils/index.html
[01:02] <lifeless> heh
[01:03] <lifeless> I've been reading that
[01:03] <lifeless> but it seems to leave a lot out
[01:03] <barry> lifeless: other than that, it's all magic :)
[01:03] <barry> distutils-sig then probably
[01:08] <lifeless> thanks
[01:09] <barry> np.  will probably be mostly offline for the rest of the evening.  have a good one!
[02:11] <jml> mwhudson, have you added a makeRecipe to the factory?
[02:11] <mwhudson> jml: no
[02:20] <al-maisan> rockstar: http://pastebin.ubuntu.com/355298/
[02:20] <jml> mwhudson, ok if I move makeBuilderRecipe?
[02:20] <mwhudson> jml: go for it
[02:22] <jml> mwhudson, thanks.
[02:22] <al-maisan> rockstar: ./lib/lp/soyuz/tests/test_archive.py
[02:40] <al-maisan> jtv: here you go: http://pastebin.ubuntu.com/355304/
[02:40] <jtv> al-maisan: thanks!
[03:13] <jml> thumper, https://code.edge.launchpad.net/~thumper/launchpad/active-branch-counts/+merge/7440
[03:14] <jml> wgrant, we should get https://code.edge.launchpad.net/~wgrant/launchpad/bpr-ddeb_package-db/+merge/14008 sorted out this week
[03:19] <mwhudson> stub: hello
[03:19] <mwhudson> stub: can you review https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-db-schema/+merge/16268 again please?
[03:19] <stub> yo
[03:19] <mwhudson> ideally after i've pushed the most recent revision...
[03:22] <stub> mwhudson: With comments in comments.sql so this makes more sense to a layperson?
[03:22] <mwhudson> stub: oh right
[03:23] <mwhudson> wow, comments.sql is SO FAR from alphabetical right now
[03:24] <jamesh> run it throught sort?
[03:27] <mwhudson> sadly i don't think that would quite work
[03:27] <stub> mwhudson: SourcePackageRecipeDataInstruction.recipe_data should be NOT NULL?
[03:27] <mwhudson> stub: certainly, yes
[03:27] <stub> Oh... jono mentioned already.
[03:27]  * stub waits for latest diff
[03:30] <mwhudson> stub: diff is up to date now
[03:31] <mwhudson> stub: jml was actually meaning something else :)
[03:46] <jml> noodles775, actually, I think the build behaviour classes should rightly live in lp.SOMETHING.adapters
[03:46] <jml> where something is probably soyuz.
[03:46] <bigjools> buildmaster?
[03:47] <jml> yeah, maybe that too
[03:47] <jml> or in the adapters module of their respective apps
[03:47] <jml> binarypackage in soyuz, recipe in code etc.
[03:47] <noodles775> sounds good.
[03:47] <jml> anyway, that's later.
[03:47] <jml> (we should have a "where do things go" kind of document too)
[03:47] <jml> ((and code to enforce it))
[03:48] <jml> (((and fix all the broken stuff too)))
[03:51] <mwhudson> stub: is stuff like date_last_modified considered sufficiently obvious to not need an entry in comments.sql?
[03:51] <stub> mwhudson: Generally, yeah. If the comment just repeats the column name there isn't much point.
[03:51] <mwhudson> ok
[04:04] <jml> noodles775, you guys aren't working on an interface for the BuildSourcePackageFromRecipeJob table, are you?
[04:04] <noodles775> jml, Nope.
[04:06] <jml> noodles775, thanks.
[04:08] <al-maisan> rockstar, jtv : the XXX bug is #506255
[04:08] <mup> Bug #506255: Refactor BuildQueue unit tests <buildfarm> <Soyuz:Triaged> <https://launchpad.net/bugs/506255>
[04:58]  * thumper EODs
[04:59] <bigjools> Schwarzenegger fan?
[05:08] <jtv> jamesh: got a nice little pickle with Storm... care to do some puzzling?
[05:08] <jamesh> sure
[05:08] <jtv> thanks.  I've got a class that is not orm-backed, but one of its base classes is.
[05:09] <jtv> or actually, one of its base classes _delegates_ to a class that is.
[05:09] <jamesh> that sounds a bit weird ...
[05:09] <jtv> branchjob hierarchy.
[05:09] <jtv> now, some generic code elsewhere goes "what class do you need?  Okay, I'll build a Storm query on that class."
[05:10] <jtv> And when it tries that for my class, things go "boom, there's no __storm_table__ here"
[05:11] <jtv> Changing that generic code could be a bit painful
[05:11] <jamesh> maybe you shouldn't use this class with the generic code then?
[05:11] <jtv> Replacing this class would also be painful.
[05:12] <mwhudson> i am bored of waiting for make schema
[05:12] <jtv> It'd be perfect if Storm were able somehow to deal with the delegation.
[05:12] <jamesh> mwhudson: you should delete some sample data then
[05:12] <jamesh>  iirc, that was one of the big time sinks
[05:12] <mwhudson> security.py seems to be the longest part
[05:13] <jtv> delete some tables
[05:13] <mwhudson> i think it's the usual "we have too many tables"
[05:13] <jamesh> jtv: I'm not exactly certain what you're trying to do with this class, so it is difficult to say.
[05:13] <jamesh> mwhudson: ah.  I seem to recall thinking that could be optimised somewhat
[05:13] <jamesh> perform multiple grants in a single statement
[05:14] <jamesh> jtv: can you point me at the code in question?
[05:15] <jtv> jamesh: it's still in ec2...  the weird construct with the delegation is imposed by existing interfaces though; see lib/lp/code/model/branchjob.py
[05:15] <jtv> There's BranchJob (implementing IBranchJob), with its specialized child classes that are all based on BranchJobDerived.
[05:16] <jtv> BranchJobDerived delegates IBranchJob to BranchJob.
[05:18] <jamesh> jtv: and what code are you passing these instances to?
[05:18] <jtv> jamesh: in lib/lp/soyuz/model/buildqueue.py you'll find a property specific_job.
[05:18] <jtv> That tries to query the class.
[05:19] <jtv> But for my case of course, the wrong class.
[05:19] <jtv> (It ends up there by registration of a utility in zcml)
[05:22] <jamesh> jtv: my suggestion would be to not do what you're doing then.
[05:22] <jtv> jamesh: yes, maybe the way out is to de-generalize the query and move it into the utility.
[05:22]  * mwhudson fights with implicit flushes trying to write half constructed objects to the database
[05:23] <jtv> mwhudson: if that's a non-storm class: storm is a bit less eager to add objects to the store
[05:23] <jamesh> jtv: or try to use adaption
[05:23] <mwhudson> jtv: it's all storm
[05:24] <mwhudson> it adds it to the store as soon as you link it to another database object
[05:24] <mwhudson> i wonder if there's a way around that
[05:24] <jtv> jamesh: I don't think adaptation would help here.  :(
[05:24] <jamesh> jtv: could you adapt (IJob, BuildFarmJobType) to IBuildFarmJob?
[05:25] <mwhudson> jamesh: can you help with this ?
[05:25] <jamesh> basically make the work done by BuildQueue.specific_job the responsibility of an adater?
[05:25] <jamesh> mwhudson: reorder how you set things in the constructor?
[05:26] <mwhudson> jamesh: sadly building related objects requires queries
[05:26] <mwhudson> i can probably fight my way to something
[05:28] <jtv> jamesh: where BuildFarmJobType is the enumeration?  Or my own BuildFarmJob derivative?
[05:28] <jamesh> mwhudson: alternatively, do the queries before setting properties on the new object, so you don't implicitly add it to the store
[05:28] <jamesh> then it can't be implicitly flushed out
[05:28] <mwhudson> jamesh: yes, that's what i have to do i think
[05:28] <jamesh> jtv: I don't know this bit of the code well enough to answer that.
[05:29] <mwhudson> it's all a bit circular though
[05:29] <jtv> jamesh: I think I'll work in the direction of an extra utility interface method tomorrow
[05:33] <jamesh> jtv: alternatively, make the specific_job_classes code look up interfaces rather than utilities, then try to adapt the job to that interface
[05:33] <jamesh> rather than doing multi-adaption
[05:34] <jtv> jamesh: that sounds nice... still means extra zcml for each class of course
[05:37] <jtv> particularly annoying is that the specific_job_classes keeps track of the model classes, not the interfaces
[05:37] <jamesh> anyway.  It is the soyuz code that looks crazier than the codehosting bits
[05:37] <jamesh> so I guess things haven't changed too much in Launchpad
[05:37] <jtv> (and some of these model classes may not need their own interfaces)
[05:39] <jamesh> if you do want to go with adaption, garry or flacoste would be good people to talk to
[05:40] <jamesh> (although they do live on the wrong side of the planet)
[05:40] <jtv> jamesh: I guess tomorrow morning we'll be able to talk to folks on the West Pole
[05:40]  * jamesh curses the sticking keys on his keyboard
[08:01] <wgrant> Oh, goody, buildStatus_OK is completely untested.
[08:09] <mrevell> morning
[08:37] <arnaud__> hi all
[10:58] <mwhudson> stub: can you look at https://code.edge.launchpad.net/~mwhudson/launchpad/recipe-db-schema/+merge/16268 one more time?
[11:06]  * stub looks
[14:08] <kfogel> adeuring: quick question
[14:08] <adeuring> kfogel: yes?
[14:09] <kfogel> adeuring: I had some good help from intellectronica last night; he suggested that putting this functionality (for bug #506018) into HasBugs is the right way to go.  I'm in lib/lp/bugs/browser/bugtarget.py -- should I add a "BugTargetPatchesView" or should this be called just "PatchesView"?
[14:09] <mup> Bug #506018: Need a "+patches" view: report lists patches attached to bugs. <story-patch-report> <Launchpad Bugs:Triaged by kfogel> <https://launchpad.net/bugs/506018>
[14:10] <kfogel> I.e., not sure when to say "BugTarget" and when not, due to slightly fuzzy relationship between BugTarget and HasBugs in my mind.
[14:11] <adeuring> kfogel: without looking into HasBugs, I'd say that BugTargetPatchesView is, let's say, too "narrow". We'll need that view for teams too, and teams are not bug targets, but IIRC implement HasBugs
[14:12] <adeuring> kfogel: so, the simple "PatchesView" looks more reasonable
[14:12] <kfogel> adeuring: but implementing the view in browser/bugtarget.py is still the right place, or should it be bug.py or some other file?
[14:13] <kfogel> adeuring: (oh, btw, how about "BugsPatchesView"?  Seems wrong not to have "Bugs" in there, somehow.)
[14:13] <adeuring> kfogel: hmmm. Since most other "relevant" stuff is in BugTarget, I think we should keep the new class there.
[14:13] <kfogel> adeuring: thanks.
[14:13] <adeuring> kfogel: yeah! that's a good name, i think
[14:14] <kfogel> adeuring: using that then
[14:19] <kfogel> adeuring: should it subclass either BugTargetBugsView or BugTaskSearchListingView?  (Soon I'll just post a patch with lots of questions :-) ).
[14:20] <adeuring> kfogel: good question.... lets me look...
[14:23] <adeuring> I'd opt for BugTaskSearchListingView. I think we can simply call its search() method with "canned parameters" in the new class
[14:26] <kfogel> adeuring: hmm.  okay, thanks.  Remember that a single bug may have multiple patches attached -- i.e., our list lists by patches, not bugs, so conceivable the same bug may appear multiple times.  That'll be okay with BugTaskSearchListingView?  (you can see it on Bryce's example page, actually: http://www2.bryceharrington.org:8080/X/Reports/patches.html)
[14:27] <adeuring> kfogel: good point....
[14:29] <adeuring> kfogel: but even if we need to rebuild the query, we can make more use from helper mthods in BugTaskSearchListingView, I think
[14:30] <kfogel> adeuring: ok
[14:31] <kfogel> adeuring: I'm creating templates/bugtarget-patches.pt right now.  I'm basing it off bugtarget-bugs.pt, and removing things like, e.g., the sidebar.  Who is the "Bob Johnson" hardcoded intothat file?
[14:33] <kfogel> adeuring: (or if there's some better template file to start from, let me know)
[14:33] <adeuring> kfogel: never heard about that guy ;) Just a place holder that's replaced by real supervior's name
[14:33] <kfogel> hunh  okay :-)
[14:33] <adeuring> kfogel: no, i think it'f fine to use that template
[17:31] <leonardr> bac, did you ever resolve the problem you were having with the lplib cache? i remember you saying that you'd made a change to your local launchpadlib
[17:31] <leonardr> and i can't duplicate your transcripts
[17:39] <kfogel> deryck: quick question: in the patch-in-progress at https://pastebin.canonical.com/26445/, search for "###".  See my question there -- what's the right type for this list (or for the objects in the list, or is this the wrong way to go about it?)
[17:41] <kfogel> gmb: you might be able to answer above question I directed at deryck
[17:46] <deryck> kfogel, I'm honestly not sure.  That's a zope thing for the field type for dealing with individual patches in the list...
[17:46] <deryck> kfogel, and I don't know what type patches might be.  Perhaps intellectronica can help, if gmb isn't available.
[17:46] <kfogel> deryck: np.  It's not crucial yet, just will be soon.  I'll ask others when I get to that point.
[17:47] <kfogel> deryck: they're attachments, but formally what to call that, I'm not sure.  I'll bet intellectronica knows, or knows how to find out.
[17:47]  * intellectronica reads back
[17:48] <deryck> kfogel, perhaps looks at "attachments" in lib.lp.bugs.interfaces.bug
[17:48] <intellectronica> kfogel: it's an IBugAttachment
[17:48] <kfogel> intellectronica, deryck: thanks!
[17:48] <deryck> there you go :-)  he's so quick
[17:48] <kfogel> IIntellectronicaWin
[17:49] <deryck> heh
[17:50] <kfogel> hah
[17:50] <kfogel> make run:
[17:50] <kfogel>     ZopeXMLConfigurationError: File "/home/kfogel/private/work/canonical/lp/lp-branches/506018-patch-report/lib/lp/services/openid/configure.zcml", line 11.4
[17:50] <kfogel>     SyntaxError: invalid syntax (bugtarget.py, line 68)
[17:50] <kfogel> make: *** [run] Error 1
[17:50] <kfogel> thanks, Zope.  now to find which of the three files I have open named "bugtarget.py" that is... :-)
[17:50] <kfogel> interfaces
[18:16] <kfogel> intellectronica: a bit of debugging help: this is my current patch: https://pastebin.canonical.com/26448/.  When I do 'make run', launchpad.dev runs, but if I visit (say) https://launchpad.dev/~name12/+patches, I get the no-such-page "Lost something?" error page
[18:16] <kfogel> I think I'm still missing a piece :-).
[18:18] <kfogel> intellectronica: also, I can visit https://launchpad.dev/projects, but visting any actual project page gets an OOPS error.  Is this expected in a dev instance?  I thought there was sample data in the db.
[18:21] <kfogel> deryck: TZ implies you may be the only one around to answer the above questions I directed at intellectronica :-).
[18:22] <intellectronica> kfogel: because you're looking for it on a person and not a has-bugs
[18:22] <kfogel> intellectronica: I thought a person was a has-bugs too??
[18:22] <kfogel> they're not?
[18:22] <intellectronica> kfogel: oh, maybe it is? what happens if you try this of a project?
[18:22] <kfogel> intellectronica: (see above about trying to do it via a particular project)
[18:23] <intellectronica> kfogel: so the oops must be something you introduced. what is the error?
[18:23] <kfogel> intellectronica: let me get it, hold on
[18:24] <kfogel> intellectronica: it certainly looks like something I introduced; see very end of this traceback https://pastebin.canonical.com/26450/
[18:25] <deryck> intellectronica, kfogel -- is browser/configure.zcml right for what karl wants?  Shouldn't this be for IHasBugs and not IBugTarget?
[18:25] <kfogel> intellectronica: wait, let me do that properly on ubuntu's pastebin
[18:26] <intellectronica> kfogel: right, that's because all_bugtasks is a property and not a method. remember we talked about properties and how they're methods but they masquerade as attributes?
[18:26] <kfogel> deryck, intellectronica: http://paste.ubuntu.com/355633/ (just to be conducting things properly -- it's the same paste)
[18:26] <intellectronica> kfogel: remove the () and you should be good
[18:26] <kfogel> intellectronica: yes!  thanks
[18:28] <kfogel> intellectronica: on attachments too (no "()" )
[18:28] <intellectronica> kfogel: yes
[18:29] <kfogel> deryck, intellectronica: oh, duh.  okay, a person is not a has-bugs because you don't file a bug *against* a person.  A person may be subscribed to, or be assigned to, or be the reporter of, a bug, but that's different from being an entity that can actually *have* a bug, as in have a bug reported against it.
[18:29] <kfogel> Is that a fair summary?
[18:32] <intellectronica> kfogel: sort of. do you need this to work for a person?
[18:32] <intellectronica> we can maybe make a person implement IHasBugs fully if necessary. don't remember what's involved
[18:32] <kfogel> intellectronica: mmmm, at some point probably yes, that would be the user-friendly thing to do.  But it's not the most important thing right now, so let's not worry about it.
[18:33] <intellectronica> kfogel: cool. does it work for other IHasBugs implementations like IProduct?
[18:33] <kfogel> intellectronica, deryck: w00t!  thank you: http://www.red-bean.com/kfogel/hello-world.png
[18:34] <kfogel> intellectronica: see above
[18:34] <intellectronica> :)
[18:35] <intellectronica> kfogel: hint for the next step. try <table><tr tal:repeat="patch context/patches"><td tal:content="patch/title"></tr></table>
[18:36] <bac> leonardr: no, the problem is not resolved.  the transcript i sent you is based on the egg as used in launchpad.
[18:36] <bac> leonardr: are you using the launchpad version or another?
[18:36] <leonardr> bac: i'm doing exactly what you're doing
[18:37] <bac> leonardr: that's really weird.  if i get time i can try it on another machine
[18:38] <leonardr> bac: sounds like the best option
[18:38] <bac> leonardr: yep.  i'll let you know what i discover
[18:42] <kfogel> intellectronica: thx
[19:44] <kfogel> intellectronica: I just discovered I don't have to restart if I edit the .pt file.  I think I'm in heaven.
[19:46] <bac> leonardr: in a new VM i did the same experiment and got the same results as seen in http://pastebin.ubuntu.com/352999/
[19:46] <leonardr> bac: the best advice i can give is to put in some debug points and see how the bad cache dir gets built
[19:52] <thumper> morning
[19:55] <kfogel> thumper: morning
[20:00] <EdwinGrubbs> bac: I found out why the merge page was raising an Unauthorized exception, when the other pages with the person picker were not. PersonAccountToMergeVocabulary uses getUtility(IPersonSet) instead of just using the Person db objects like the other vocabs.
[20:01] <bac> EdwinGrubbs: ah, interesting
[20:02] <deryck> Later on, everyone...
[20:02] <kfogel> deryck: l8r
[20:03] <kfogel> intellectronica: I'm trying to understand this (which I just wrote, based on something you said earlier) in bugtarget-patches.pt:
<tr tal:repeat="patch context/patches"><td tal:content="patch/title">Hello, world!</td></tr></table>
[20:03] <mwhudson> morning
[20:03] <kfogel> intellectronica: what do these repeat and content attributes do, exactly?
[20:04] <kfogel> intellectronica: I'm guessing that the first says to make as many <tr>...</tr> elements as there are patches, somehow;
[20:04] <kfogel> and the second says what <td>...</td> elements to put in each tr.
[20:04] <kfogel> But the values of those attributes are a bit mysterious to me.
[20:09] <kfogel> mwhudson: morning!
[20:10]  * mwhudson finds Person.visibilityConsistencyWarning, is scared
[20:26] <EdwinGrubbs> sinzui: ping
[20:45] <mars> beuno, ping, do you have a list of key, most used Launchpad pages by type?  BugtaskIndex, CodeHome, etc. etc.?
[20:46] <mars> PPA would be in there somewhere...
[20:46] <beuno> mars, I don't handy, but I did some grepping through logs with a script that I think flacoste built
[20:46] <beuno> that may of been a year ago  :)
[20:47] <mars> yeah, I remember you can derive the page type from the appserver log output, but I was hoping someone had already done so for me.
[20:47] <beuno> mars, there is a script that does that
[20:47] <beuno> I fixed it when I picked it up
[20:48]  * beuno looks for it
[20:49] <beuno> mars, I *think* it was lp-access-log-analyzer.py
[20:49] <beuno> yes it is
[20:49] <sinzui> hi EdwinGrubbs
[20:50] <wgrant> abentley: lp:~wgrant/launchpad/lp-buildd-sourcepackagerecipe-support
[20:50] <wgrant> abentley: See the XXXs in lib/canonical/buildd/sourcepackagerecipe.py
[20:51] <mars> beuno, I can't find it.  Is it in trunk/?
[20:51] <abentley> wgrant: Thanks.
[20:51] <mars> beuno, ah! in lp-dev-utils/
[20:51] <beuno> mars, it's in lp-dev-utils
[20:51] <beuno> which I though had been merged into trunk?
[20:52] <mars> last revno on lp-dev-utils/trunk is Jan 6th, so it is still active I assume
[20:54] <bac> leonardr: i used the latest version of lplib (still set at 1.5.4 but newer than the released 1.5.4) and the problem goes away
[20:55] <leonardr> bac: so you have the problem with the version packaged with launchpad but not with the version in versio ncontrol?
[20:55] <bac> leonardr: yes, that is correct
[20:56] <bac> leonardr: so when 1.5.5 is released and lp uses it the issue will be resolved
[20:57] <mars> beuno, just wondering, do you have the list of most-visited projects and/or pages from a year ago?  That list may still be valid.
[20:57] <beuno> mars, I don't. awstats may give you some of that information
[20:57] <leonardr> ok, let me try to find the difference bewtween those versions
[20:57] <mars> beuno, ok, thanks
[21:03] <leonardr> bac: i think there may have been a bug having to do with the cache dir and the launchpadlib dir being switched in some method call
[21:04] <leonardr> bac: i'll do a new release of launchpadlib tomorrow
[21:05] <beuno> leonardr, you may have some insight on this:  https://pastebin.canonical.com/26435/
[21:07] <leonardr> beuno: well, the file name's too long...
[21:07] <leonardr> i designed launchpadlib before i knew ext4 was going to impose lengths on filenames
[21:08] <leonardr> i don't know what to do about it (in this case or in general)
[21:09] <wgrant> eCryptFS makes it much worse, too :(
[21:09] <beuno> I am of course, using both
[21:10] <leonardr> i can change launchpadlib to hash the string and use that as the filename
[21:10] <leonardr> that will fix the length problem but will make it extremely difficult to examine the cache
[21:16] <mars> beuno, ok, maybe some good guesses are in order.  The Bzr project homepage is one.  What else?
[21:16] <mars> Some closed/fix-released Bug Index page would be good.
[21:17] <beuno> mars, what is it you're trying to find out?
[21:17] <mars> The launchpad.net homepage is good.
[21:18] <mars> beuno, I've coded a library, pyslow, that automates YSlow stats collection.  I am looking for pages to start collecting with.
[21:19] <mars> code.launchpad.net/bzr might also be good.  code.launchpad.net/launchpad is a bit too large to be representative.
[21:19] <beuno> mars, a bug page
[21:19] <kfogel> wgrant: got time for some debugging help?
[21:19] <beuno> a popular bug
[21:19] <beuno> mars, something other than bug 1  :)
[21:20] <mars> beuno, yep, but a closed bug.  Otherwise new comments may cause stats drift.
[21:20] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:In Progress by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Confirmed for shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubun
[21:20] <beuno> mars, right
[21:20] <beuno> mars, another one is a translations overview page
[21:20] <mars> ah!
[21:20] <mars> good idea
[21:21] <mars> and PersonIndex, of course
[21:21] <beuno> mars, a branch index, and a merge proposal page
[21:22] <mars> ok, both good ideas
[21:23] <mars> beuno, is the translations overview just translations.lp.net/someproject ?  Or is it underneath that?
[21:23] <mars> beuno, the PPA index page would be good as well
[21:23] <kfogel> mars, beuno, or anyone: http://paste.ubuntu.com/355726/ is the result of visiting bugs.launchpad.dev/redfish (a test project) running the code in https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report.  I'm sure the traceback has something to do with my changes, but can't see what.  Any ideas?
[21:24] <bac> leonardr: hey that's great
[21:24] <beuno> mars, https://translations.edge.launchpad.net/ubuntu/karmic/+lang/es
[21:25] <leonardr> i might as well try to do something about the file length while i'm at it
[21:25] <beuno> danilos, btw, that page looks very squished ^^
[21:25] <mars> leonardr, ^ any idea what kfogel is seeing?
[21:26] <mars> leonardr, something to do with the webservice going into his page's LP.client.cache
[21:26] <kfogel> mars: really?
[21:26]  * kfogel looks
[21:27] <kfogel> mars, leonardr: note that if you visit the bugs page for a project that has no bugs (e.g., https://bugs.launchpad.dev/lies) everything works fine.
[21:27] <wgrant> kfogel: Bit busy sprinting at the moment, sorry.
[21:27] <kfogel> wgrant: np, thanks for letting me know
[21:27] <leonardr> mars, kfogel: launchpad is putting a json representation of your test project into LP.client.cache['context'], but it's failing--probably an error is happening when generating the json representation
[21:28] <leonardr> if you try to get that test project through the web service, you'll probably get a better error message.
[21:28] <kfogel> leonardr: thanks
[21:29] <kfogel> leonardr: I understand conceptually what you're suggesting, but have not actually done it in a long time.  Is it visiting a URL like api.launchpad.dev/something?
[21:31] <mars> kfogel, https://api.launchpad.dev/beta/some-project
[21:31] <mars> should work
[21:31] <mars> use curl or wget
[21:31] <mars> or the browser
[21:31] <kfogel> mars: I tried it in my browser and got http://paste.ubuntu.com/355730/
[21:32] <mars> kfogel, argh, my bad.  Try: https://launchpad.dev/api/beta/some-project
[21:32] <kfogel> mars: aaaah
[21:33] <kfogel> one sec
[21:37] <kfogel> mars, leonardr: TERRIFICALLY HELPFUL error from that, thank you!  That is one trick I'm going to remember.  http://paste.ubuntu.com/355734/
[21:37] <kfogel> (and yes, it was my code)
[21:37] <mars> kfogel, maybe add it to http://dev.launchpad.net/Debugging ?
[21:37] <mars> since that is a nasty information-hiding error you uncovered there
[21:38] <kfogel> mars: I am :-)
[21:38] <EdwinGrubbs> sinzui: should a new unit test for vocabularies go in lp.app or lp.coop or just in canonical.launchpad.tests?
[21:38] <kfogel> mars: even better would be to make the web ui error as informative as the web services error...
[21:43] <sinzui> EdwinGrubbs: which vocab is it testing?
[21:43] <EdwinGrubbs> sinzui: all of them
[21:43] <sinzui> lp.services maybe
[21:43] <EdwinGrubbs> ok, cool
[21:44] <sinzui> EdwinGrubbs: We do not want to add the canonical. and I think lp.app is specific to integration code.
[21:44] <sinzui> EdwinGrubbs: If you have doubts, place it in lp.app
[21:45] <EdwinGrubbs> sinzui: all it's doing is checking whether the vocabs are security wrapped, which is sorta integration but not between apps
[21:45] <kfogel> mars: https://dev.launchpad.net/Debugging#Getting%20Better%20Tracebacks
[21:46] <sinzui> EdwinGrubbs: I think services is the best place
[21:48] <mars> kfogel, maybe put it at the bottom, call it "Tracing obscure TAL template errors for mangled webservice objects", and link to your pastebins?
[21:49] <mars> kfogel, my concern is that "Getting Better Tracebacks" is actually a bit vague, whereas you solved a very specific problem (and helpfully posted evidence to help us help you)
[21:49] <kfogel> mars: so I wasn't sure how long Ubuntu pastes live.  (the site doesn't say) are they forever?
[21:50] <kfogel> mars: and, does your advice only apply to TAL template errors of that sort, and not to nasty tracebacks in general?
[21:51] <kfogel> mars: (note that when I encountered it, I didn't know that it fell into that category, and I'm not sure any other newbie would.  so we want the widest category of traceback for which the advice still holds...)
[21:52] <sinzui> flacoste: root-index.pt still has:
[21:52] <sinzui>     <li tal:condition="context/required:launchpad.Admin">
[21:52] <mars> kfogel, I would say your case was pretty specific: writing a new template, looks OK, load it, BOOM
[21:53] <sinzui> flacoste: sorry I meant to paste that into #launchpad-reviews
[21:53] <flacoste> sinzui: that's fine
[21:53] <flacoste> sinzui: i'll fix it
[21:54] <mars> kfogel, leonardr and I knew it was a webservice problem right away, because of the specific template line that went bad.  The advice of checking the webservice was pretty specific.  However, I do not know if other TAL errors mask problems with model objects in a similar way.
[21:54] <kfogel> mars: help me figure out the right title here.  I fear that anyone who knows enough to know that their error is a "TAL template error for a mangled webservice object" is less likely to be in need of this debugging advice...
[21:55] <mars> hmm, true
[21:57] <mars> well, it was specifically an error with a new TAL template, and the error was (and presumably will always be): LocationError: (<lazr.restful.tales.WebLayerAPI object at 0xd932ccc>, 'json')<br />
[21:58] <kfogel> mars: and the web services advice wouldn't necessarily hold under other circumstances?
[22:00] <mars> kfogel, that I do not know.  I can't think of any other circumstances besides "my new code broke the model, my page spat out this weird webservices error"
[22:00] <kfogel> mars: *nod*
[22:01] <kfogel> flacoste: do you know how long pastes at paste.ubuntu.com live?  I.e., can we refer to them from permanent pages in the wiki?
[22:02] <flacoste> kfogel: i don't
[22:02] <kfogel> flacoste: np
[22:06] <kfogel> mars: https://dev.launchpad.net/Debugging#Understanding%20TAL%20template%20tracebacks%20for%20mangled%20webservice%20objects
[22:06] <kfogel> mars: not happy with the title, but not sure what else to call it
[22:08] <mars> kfogel, "Tracing past "LocationError: 'json'" in TAL templates" ?
[22:09] <kfogel> mars: I want to get the word "traceback" in there, since that's what someone will be looking at when they go looking for this advice.
[22:11] <mars> kfogel, up to you.  I find tracebacks to be implicit with any meantion of a "TAL Error".  The two are entwined, forever seared into memory.
[22:12] <kfogel> mars: I don't think that will be the case for many people :-).
[22:13] <kfogel> mars: https://dev.launchpad.net/Debugging#Getting%20past%20%22LocationError:%20%27json%27%22%20in%20TAL%20template%20tracebacks
[22:13] <kfogel> mars: good enough for newbies now, more or less
[22:35] <thumper> bzr-hg imports working in dev branch, up for review \o/
[22:38] <poolie> nice one
[22:46] <bigjools> hi poolie, how's it going
[22:47] <poolie> good thanks, how are you?
[22:48] <bigjools> poolie: enjoying the sprint!
[22:49] <poolie> i'm free to talk any time this week
[22:49] <poolie> though right this moment is not quite so good
[22:49] <bigjools> ditto
[22:50] <bigjools> maybe this afternoon?
[22:54] <barry> sinzui: do you really want me to approve joining gdp-developers to haibunku?
[22:55] <sinzui> barry: no. I forgot you get staging email
[22:55] <sinzui> but...
[22:55] <barry> sinzui: no worries, i had a feeling that was it
[22:55] <sinzui> I think you are the prefect person to verify a invitation to join a super secret team
[22:56]  * barry loves secrets
[22:56] <sinzui> bac: ping
[22:57] <barry> sinzui: i'm about to catch some dinner, but will be back in a bit
[22:57] <sinzui> okay, you'll see the invite in a few minutes
[23:00] <sinzui> barry: you should receive an invite on behalf of haibunku for https://staging.launchpad.net/~private-ufos If you can see and accept the invitation, you will be the first person I know of to allow a public team to be a member of a private team.
[23:08] <sinzui> losa ping
[23:29] <barry> sinzui: hasn't shown up yet
[23:29] <sinzui> hmm
[23:29] <barry> oh wait, staging
[23:29] <sinzui> Yes, and I see two?
[23:30] <sinzui> oh, flacoste is also an admin
[23:30] <barry> as do i
[23:30] <barry> right
[23:30] <barry> accepted!
[23:30] <sinzui> you saw the page?
[23:31] <sinzui> wow this is big. I wonder what the effort is to allow a private team be a member of a private team?
[23:31] <sinzui> thank you very much barry
[23:32] <barry> sinzui: np, and yep, it's way cool.  gotta run.
[23:52] <jml> jtv, https://code.edge.launchpad.net/~jml/launchpad/behavior-refactor