[12:35] <sabdfl> damn this stuff is well thought out
[12:35] <sabdfl> hairy and poorly documented but nonetheless well thought out
[01:21] <sabdfl> whoot! phear my phorms
[01:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: good looking autogenerated edit and add forms for bugs (patch-679)
[02:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: good looks for ALL  autogenerated add and edit forms (patch-680)
[04:45] <stub> Morning
[06:17] <jblack> Any zope guys around? 
[07:02] <stub> jblack: Yo
[07:03] <jblack> stub: I'm finally starting to get zope.
[07:03] <stub> You should see a doctor
[07:03] <jblack> Heh. Yeah. It took being sick to do it. :) 
[07:04] <jblack> But anyways.... I've setup an object, and I can refer to attributes in the interface. That's fine and all.
[07:04] <jblack> But I don't seem to be able to include just an object. 
[07:05] <stub> I don't get that second sentence.
[07:05] <jblack> I.E. I can do <div tal:content="context/James/name">A name</div>, but I can't do <div tal:content="context/James">Showing a whole object</div>  
[07:05] <stub> oic. 
[07:05] <lifeless> __str__ ?
[07:05] <lifeless> in the interface.
[07:05] <lifeless> *is*
[07:06] <jblack> Well, if I point at localhost:8080/James/ I get a nice html layout of the information (thanks to info.pt)
[07:06] <stub> I don't think it even needs to be in the interface - it just needs one.
[07:06] <jblack> I'd like to include that.
[07:06] <lifeless> stub: surely thats a whole in the interfaces implementation? 
[07:06] <jblack> stub: So what? Its "ok" to put html in an interface? 
[07:07] <stub> jblack: No - ignore the __str__ -- that isn't what we want in this case. That would be if you just wanted context/James to render 'James' or something.
[07:08] <stub> What is the name of the view that uses info.py? (The name in the page directive most likely)
[07:09] <jblack> No clue. The only place I referenced info.pt was in configure.zcml
[07:09] <stub> If it was 'index' for example, you should be able to do this as tal:content="structure context/James/index" or tal:content="structure context/James/@@index"
[07:10] <jblack> Oh, you mean the page I'm trying to do this? yeah, index.html
[07:11] <stub> ok. So first try context/James/index.html or context/James/@@index.html (the second one is more explicity - 'the index.html View on the James object')
[07:12] <stub> lifeless: I would have to test to be sure. I suspect some methods are exposed by default (and should not include protected information), because otherwise things like tracebacks become impossible. Not sure what the current status is though.
[07:13] <lifeless> stub: hmm.
[07:13] <jblack> nope. system error for contex/James/@@index, context/James/index and context/James/@@index.html, ...@@info.pt, ...info.pt
[07:14] <jblack> Oh yeah. I get a security error when I just use "context/James" 
[07:16] <stub> What is context btw? A container of some kind?
[07:17] <jblack> Just something I seem to need. If I don't have that, I get "Path element may not be empty in u'/James/name' 
[07:19] <stub> Zope publishes a tree of objects. These objects are generally your context. You attach Views to them.
[07:21] <stub> So you have a page foo.pt which you register as a view named 'foo.html' on an object. In this case 'context' is object. 'context/James' would be a child named 'James' of that object.
[07:22] <jblack> What's the difference between a view and an interface? 
[07:22] <jblack> I see that according to the graph, a view calls the interface, which defines the interface for a class.
[07:22] <stub> An interface is an interface, like a Java interface. It just specifies a contract that object that implement the interface has to adhire to.
[07:23] <stub> Calling an interface doesn't make sense. If you see syntax like IFoo(someobject), that is actually Adaption which is something different.
[07:24] <jblack> Ok. the view definitions go in configure.zcml.
[07:24] <stub> Yes
[07:24] <jblack> such as <browser:page \n for=".interfaces.IBuddy" \n name="index.html" \n template="info.pt"  \n permission="zope.View" \n />
[07:24] <jblack> Ahhhaaa
[07:25] <stub> A View provides a, well, view of an object. You define an object that defines data, behaviour etc. However, it shouldn't have to know how to render itself as HTML. To do that, we attach a View to it. These views are traversable, thanks to Zope, so that 'localhost:8080/James/foo.html' means 'show me the foo.html view of the James object'
[07:25] <jblack> So why doesn't <div tal:replace="context/James/index.html"></div> work? 
[07:26] <jblack> according to my log, I get: 
[07:26] <jblack> NotFoundError: (<buddydemo.buddy.Buddy object at 0x4392d56c>, 'index.html')
[07:26] <stub> Can you tell me the URL you used to view 'index.html of James' and the URL you are trying to use for this example?
[07:27] <stub> ok... buddy demo..
[07:27] <jblack> lynx localhost:8080
[07:27] <jblack> and in index.html, I have in the body, the div tal:replace I mentioned.
[07:29] <stub> So we have IBuddy, and an object instance that implements IBuddy called 'James'.
[07:29] <stub> We have attached a view named 'index.html' to all objects that implement the IBuddy interface (the <browser:page directive from before)
[07:29] <jblack> yes, and yes
[07:30] <stub> You have created a page template in the root of your Z3 tree called something, which is trying to include the index.html view of the James object
[07:30] <jblack> Incorrect.
[07:31] <jblack> Actually ,yes. That's correct.
[07:32] <stub> So in this case context should be 'the root folder', and 'context/James' should refer to the James object stored in the root folder.
[07:32] <jblack> correct.
[07:32] <jblack> but if I do that, I get a security error.
[07:33] <jblack>    <security proxied buddydemo.buddy.Buddy instance at 0x4392892c>
[07:33] <jblack> That shows up in the browser. The log looks fine.
[07:33] <stub> First thing, before I forget, is you will need to use tal:content="structure blahblahblah" instead of tal:content="blahblahblah", or else all your HTML will be quoted.
[07:34] <jblack> Changed
[07:35] <stub> You should get <security proxied buddydemo blah blah> if you do tal:content="context/James". Zope is trying its best to render the James object, and the best it can do is use the __repr__ method of its security proxy. This is correct.
[07:36] <jblack> Ok. so it should be context/James/index.html.
[07:36] <stub> What do you get if you have tal:content="structure context/James/@@index.html" 
[07:36] <stub> Yes
[07:37] <jblack> Hmmm. I must have a typo then, because that gives me: NotFoundError: (<zope.app.security.principalregistry.UnauthenticatedPrincipal objectat 0x4167806c>, 'title')
[07:37] <stub> You can fix the class definition of the James object to allow the syntax you want by defining the __call__ method I think
[07:38] <stub> Looks like something is trying to do tal:content="user/title" and this is failing.
[07:39] <stub> Does anything look like that in info.pt ?
[07:39] <jblack> Nothing that references title, no
[07:41] <jblack> btw, if I go to http://localhost:8080/James, the object represents correctly.
[07:41] <jblack> If it would help, I'm more than willing to tarball this for you.
[07:42] <stub> So the name= attribute of the browser:page element in configure.zcml is definitly name="index.html" ?
[07:42] <stub> Sure - tarball it and email to stuart@stuartbishop.net
[07:43] <jblack> On its way.
[07:45] <jblack> btw, thanks. I appreciate the help
[07:55] <stub> jblack: And the source of the document that is trying to do tal:content="context/James/index.html" ?
[07:56] <jblack>  /index.html
[07:56] <jblack> Its in the zobdb
[07:56] <stub> You will have to cut'n'paste it
[07:57] <jblack> oh, that didn't come with the tarball? 
[07:57] <jblack> http://www.pastebin.com/113455
[07:59] <stub> Nice PHP tags in there :)
[08:00] <jblack> that's done by pastebin. its not in my script. ;) 
[08:04] <stub> Are you able to turn off View permissions on the /index.html page tempate to unauthenticated users? (I can't remember if that can be done atm in Z3)
[08:05] <jblack> I have no idea how to do that.
[08:13] <stub> Doesn't matter - I've remembered how that works. What I'm trying to work out is why the log is saying the URL is 'localhost:8080/index.html/index.html'
[08:20] <jblack> I don't get it. Isn't this a pretty basic fundamental property of zope?
[08:20] <jblack> To be able to do stuff like this? 
[08:23] <stub> Yes. I need to trace down what is trying to access the unauthenticatedprincipal, which is what is raising the exception.
[08:24] <stub> At first glance it looks like a bug, either in the error reporting or in one of the templates that is being included
[08:25] <stub> Z3 is not focused on the TTW stuff though at the moment, so the TTW page templates could have problems.
[08:25] <stub> Goddammit I can't drive svn anymore :-(
[08:25] <stub> (Not that I ever could...)
[08:27] <jblack> I take it you mean a z3 builtin template? I haven't gotten to doing templates and metal just yet.
[08:30] <stub> Yes - something builtin.
[08:40] <jblack> should I try changing the view name from index.html to something else? 
[09:22] <stub> jblack: The syntax is correct and everything should be working. I suspect the problem is in the TTW page templates implementation. I tried it with your code with a SVN checkout of the Z3 trunk and am getting exceptions. However, I can happily add views which do the equivalent.
[09:22] <jblack> I'm confused. Other views work fine, but mine is hosed/ 
[09:24] <stub> Are you running the beta tarball or a svn checkout btw?
[09:25] <jblack> I'm running the release candidate
[09:25] <stub> What is happening (I think) is the TTW page templates implementation is unable to include the view inside itself - it trips over its own security implementation
[09:25] <jblack> ZopeX3-3.0.0c2
[09:25] <stub> (which would be a bug)
[09:26] <jblack> how do I work around it? 
[09:28] <stub> I'm attaching views to the interface '*' (ie. every damn object), which is not exactly an optimal work around :-)
[09:28] <stub> <browser:page for="*" name="includer.html" template="includer.pt" permission="zope.View" />
[09:31] <jblack> With that change, I get NotFoundError: (<buddydemo.buddy.Buddy object at 0x4392d56c>, 'includer.html')
[09:32] <jblack> (yes, I renamed info.pt to includer.pt)
[09:33] <jblack> and my [top]  / index.html has the following pertinant line: <div tal:replace="structure context/James/@@includer.html"></div>
[09:34] <stub> Erm... you would need to create includer, not use info.pt
[09:34] <stub> (where includer.pt contains the same code as in your TTW page template)
[09:35] <stub> I'll see if anyone bites on #zope3-dev. You are probably one of the first people to try doing this with TTW page templates. Most of the people involved don't use any of the TTW stuff so it needs lovin'.
[09:35] <jblack> What do people normally do instead? 
[09:36] <jblack> They use slots instead or something? 
[09:37] <stub> We would create a BuddyContainer object designed to hold Buddy's. Then attach Views to the Buddy container. What you have is similar, except replace ZODB root folder with Buddy container and View with TTW page template.
[09:37] <stub> What you are doing should work fine though
[09:51] <stub> Its being looked into by bigger brains than mine
[09:59] <jblack> Thanks for digging into this, stub
[10:02] <jblack> so, when a new version of zope comes out, how do I upgrade an instance? 
[10:02] <carlos> morning
[10:05] <jblack> Ok. So make a folder, put buddies in there instead.
[10:25] <stub> jblack: You just install the new Z3 code and it all happily keeps working (well... if it doesn't it is a major bug :-) )
[10:26] <jblack> Oh, didn't realize instances depended on the install
[10:40] <stub> jblack: Your code works just fine on a checkout of the Z3X branch (so it has either been fixed in rc3 or later). It is still broken in the Z3 trunk though, so it was a good catch.
[10:41] <jblack> doesn't c1 postdate rc3? 
[10:41] <stub>  svn co svn://svn.zope.org/repos/main/Zope3/branches/ZopeX3-3.0
[10:41] <stub> Hmm...
[10:42] <stub> I though you said rc2 before
[10:57] <SteveA> lifeless, stub: __repr__ is public by default.  __str__ generally is not.
[11:00] <SteveA> If your application depends on particular behaviour from __str__, then it should be in the interface.  The case with __repr__ is arguable either way, but I think that if your application depends on a *particular* __repr__ representation, it is broken, and it should be in the interface.
[11:02] <stub> jblack: Your code works just fine on my ZopeX3-3.0c2 installation
[11:03] <jblack> Huh. That's what I'm using. ZopeX3--3.0.0c2
[11:03] <stub> Yup. So I don't know what is wrong at your end :-)
[11:05] <sabdfl> morning all
[11:07] <sabdfl> stub: i've got the pretty-forms stuff working in a shoddy way, will clean it up today
[11:07] <SteveA> our forms are pretty shoddy
[11:07] <sabdfl> bug-addform is as it should be?
[11:08] <sabdfl> sorry, no ? required
[11:08] <sabdfl> SteveA: why?
[11:08] <stub> Yup. So how did you go with the form machinery stuff? PITA or did it grow on you?
[11:08] <SteveA> sabdfl: bad pun.  you said "i've got the pretty-forms stuff working in a shoddy way"
[11:08] <sabdfl> stub: there was no documentation to do what i wanted to do, so it was a weekend of groping in the dark
[11:08] <sabdfl> ah :-)
[11:09] <sabdfl> stub: found what i think was your work (default-addform, default-editform) and built on that
[11:10] <sabdfl> i think we can get it relatively pretty for relatively little work now
[11:10] <sabdfl> but eventually we are going to need qute a few custom widget classes
[11:10] <sabdfl> still, should be doable
[11:11] <stub> Yup. We can also fix the Z3 stuff if it gets in the way. I think it is the right tool to use, but others might not agree ;)
[11:17] <stub> I'm having flashbacks from my last job with all that informative text included inline in the form ;)
[11:43] <carlos> sabdfl: I need to add a Rosetta specific attribute to the Person interface and class, should I create a RosettaPerson for that or could I use the main object directly?
[11:44] <sabdfl> carlos: what's the attribute
[11:46] <carlos> well, at this moment it's already inside person.py implementation, it's its move from Schema/Label to a real table (PersonLanguage)
[11:46] <carlos> but the interface does not have it
[11:47] <carlos> Person.languages
[11:47] <carlos> Person.addLanguage
[11:47] <carlos> and the needed RelatedJoin attribute
[11:48] <sabdfl> carlos: absolutely, add that to the person class
[11:49] <carlos> ok
[11:49] <sabdfl> we want to avoid local copies of the classes as much as possible
[11:49] <sabdfl> later on, maybe we can split functionality up but for the moment put everything you need into Person directly
[11:49] <carlos> ok
[11:50] <carlos> later this week, I will add the License object, where should It be stored?
[11:50] <dilys> Merge to rocketfuel@canonical.com/sqlos--test--3.0: Workaround for 'destroySelf breaks commits' problem (patch-3)
[11:52] <SteveA> in our database, the fundamental unit of licensing is the source package.
[11:55] <sabdfl> carlos: it's a new table so it gets database/license.py, zcml/license.zcml, interfaces/license.py etc
[12:04] <carlos> ok
[12:11] <Kinnison> sabdfl: Are we coding in american or in english? (I ask because currently there's an amusing mix of the two in the codebase)
[12:12] <SteveA> zope3 standard is us english
[12:12] <SteveA> (point of information)
[12:13] <SteveA> I think python is in us english too.  seeing as we're using the zope3 and python apis, we should use us english.
[12:14] <Kinnison> Well; the binarypackage table has a 'licence' column which is clearly en_GB
[12:14] <Kinnison> This is why I'm asking y'see :-)
[12:15] <Kinnison> Or at least; en_US always seems to use 'license'
[12:17] <dilys> Merge to rocketfuel@canonical.com/buildbot--devel--0: Make taxi work again (patch-63)
[12:27] <carlos> spiv: ping
[12:29] <spiv> carlos: pong
[12:29] <carlos> spiv: I'm using a RelatedJoin that will give me addLanguage and removeLanguage methods for free
[12:30] <carlos> I suppose that I should add them to the interface file, right?
[12:30] <spiv> If they're part of the interface, yes ;)
[12:30] <carlos> yes, I will need them
[12:30] <spiv> Yep, then do it.
[12:30] <carlos> will it give any problem with the interface tests?
[12:31] <spiv> Nope.
[12:31] <carlos> perfect, thanks
[12:31] <spiv> The interface tests look at the object, rather than trying to read the source code directly :)
[12:31] <carlos> makes sense :-)
[12:43] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Make the librarian optional for gina (patch-681)
[01:24] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: SourcePackage bugs counter. (patch-682)
[01:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Merge lalo's zopeless transactions work and other changes needed for importd (patch-683)
[01:39] <cprov> Kinnison: morning, can you give me a briefly explanation about "optional librarian dependency on gina" ? How to proceed ?
[01:42] <Kinnison> cprov: theres a line in grabber.py you comment out. the attachLibrarian() call
[01:43] <Kinnison> cprov: then the changes I made in classes.py should notice when the librarian isn't in use and not try and create the entries in the file tables
[01:45] <cprov> Kinnison: I'll try in that way, tks 
[01:47] <Kinnison> cprov: You're welcome
[01:47] <Kinnison> cprov: If you can patch the rest of gina to get her able to import again; that'd be doubly fantastic
[02:05] <cprov> Kinnison: it is working now, but I need to comment out some lines in classes.py (getLibraryAlias)
[02:06] <cprov> Kinnison: do you think we can have a FLAG (!!!) ?
[02:07] <stub> We really want a stub Librarian for a real fix
[02:10] <cprov> stub: sorry, what do you mean with "stub librarian" ? 
[02:12] <stub> Something that fakes the API we use to communicate with the Librarian which we can use for development etc. 
[02:12] <SteveA> it is an animated stu to help you find your files -- our answer to "clippy"
[02:12] <stub> But I might be solving a different problem :-)
[02:13] <debonzi> hi stub... the page malone/sourcepackage/mozilla-firefox-dummy/ seems to be broken for me.. do you know about it?
[02:13] <Kinnison> cprov: You could if you wanted. I was just going on the 'if librarian is None:' bit in getLibraryAlias in library.py
[02:16] <cprov> Kinnison: I see :)
[02:16] <stub> debonzi: Ta. I think Malone is obviously lacking on the page tests, which I should get onto tomorrow :-)
[02:16] <stub> SteveA: Bad Steve!
[02:17] <SteveA> it's almost like being a move star!
[02:18] <debonzi> stub, right.. just to check because I'm linking sourcepackage for its bugs and I saw it.. thanks :)
[02:30] <stud> debonzi: The URL is currently configured to be malone/package/mozilla-firefox-dummy, but the URL's being generated don't point to that. I'm not sure which is supposed to be correct atm (was the missing 'source' a typo in malone/configure.zcml, or did it get changed but the templates not modified?)
[02:33] <stud> Of course, neither is probably correct as Soyuz appears to be using 'src' :-(
[02:33] <debonzi> stud, You are right.. but I saw it working friday with sourcepackage.. 
[02:34] <debonzi> stud, maybe it was a proposital modification
[02:37] <stud> Nope - my dictionary doesn't know that word either :-)
[02:37] <debonzi> stud, AFAICS mark was the last one to play with  malone/configure.zcml
[02:38] <debonzi> stud, ops.. sorry :)
[02:39] <debonzi> s/proposital/intentional
[02:39] <stud> I suspect he wants the URL changed because hitting '6x' in vim at the right time is a rather improbable typo
[02:40] <stud> I'm just wondering if we should consider rationalizing the URL naming with soyuz (use src) since it is currently broken anyway before the dependancies start creeping in again.
[02:41] <stud> Or maybe we have more important things to worry about :)
[02:42] <debonzi> stud, yes probably so :)
[02:44] <stud> If I can find which template it is in that haystack :-(
[03:06] <sabdfl> Kinnison: i think that was "architecturetag" or something similar... check the soyuz.dia which will be out of date but should have that details
[03:09] <sabdfl> stud: yes, was me that changed the url to "malone/package/", sorry if i didn't catch it everywhere
[03:10] <sabdfl> my rationale for that one is that we *only* track assignment to *source*package so the source is redundant
[03:10] <stud> sabdfl: Only the one spot once that I have found
[03:11] <Kinnison> sabdfl: If architecturetag was meant to be for that; then that is broken too
[03:11] <sabdfl> in soyuz, we need the distinction between sourcepackage and binarypackage much more
[03:11] <Kinnison> sabdfl: What with the test-data having 'warty--x86--devel--0'
[03:11] <stud> sabdfl: We need some consistency and structure in the launchpad/templates directory but I have no idea what it is supposed to look like btw. I don't know if we can mimic the URL space in a directory structure or not.
[03:12] <sabdfl> Kinnison: i think that was a flying guess from someone that went off in the wrong direction :-)
[03:12] <cprov> sabdfl: me ??
[03:12] <sabdfl> stud: agreed
[03:12] <Kinnison> sabdfl: 'stud' again?
[03:12] <sabdfl> cprov: maybe, no big deal
[03:13] <sabdfl> stub's been working out again, hey stud
[03:13] <sabdfl> stud: quick update on the add/edit for situation
[03:13] <Kinnison> sabdfl: Should I put an UPDATE statement in my SQL patch which is pending then, to update the test-data ?
[03:14] <cprov> Kinnison: isn't it repaired in sampledata, yet ? if not, please replace it with 'i386' or something simple like that ...
[03:14] <sabdfl> Kinnison: probably easier to follow the normal process for test data: (a) build clean db, (b) make the changes, (c) cd database/schema; make newsampledata
[03:14] <stud> Kinnison: Yes please.
[03:14] <sabdfl> then check it out, if happy copy the newsampledata.sql it created over current.sql
[03:14] <sabdfl> stud: is that right?
[03:14] <Kinnison> glerp
[03:16] <stud> sabdfl: The sample data needs to be updated at the same time the database patch is move to the 'live' area, so generally I need to run the updates and generate the sample data
[03:16] <cprov> Kinnison: AFAIKS, current current.sql contains the right archtagrelease 'i386'
[03:16] <Kinnison> cprov: aah yes it does
[03:16] <Kinnison> you're a star
[03:17] <stud> (Assuming the sample data changes relate to the schema mods...)
[03:17] <Kinnison> Okay, I'll go back to sleep now :-)
[03:17] <sabdfl> stud: i don't think this is a structural change
[03:17] <Kinnison> (Well; actually I'll update my test db and carry on)
[03:18] <sabdfl> just that there's a bad bit of data: 'i386' is 'warty-x86--devel--0' or something
[03:18] <stud> sabdfl: oic. i just read pending patch :-)
[03:18] <sabdfl> stud: so, about the add/edit forms
[03:18] <sabdfl> i'm creating launchpad-addofmr and launchpad-editform
[03:19] <sabdfl> based on your default-addform and default-editform
[03:19] <sabdfl> but with a few tweaks
[03:19] <sabdfl> morning BradB!
[03:19] <BradB> hi :)
[03:20] <Kinnison> stud: speaking of pending patches; I'm *almost* ready for you to merge my pending patch :-)
[03:20] <Kinnison> stud: Just got another two views to finalise :-)
[03:24] <stud> sabdfl: Which were a hacked up version of the Z3 default ones. It might get a bit 'icky in there -- if anything about the form machinery is badly documented it is customizing the templates. This is somewhere we might find we need to fix stuff and feed changes back into Z3.
[03:25] <sabdfl> stud: ok, so here's what i'm heading towards
[03:25] <BradB> elmo: why does launchpad.ubuntu.com say "Nothing to see here" instead of showing the devel version of launchpad?
[03:25] <sabdfl> for each add or edit form, we will create a very small template
[03:25] <sabdfl> this template will just really host things that are unique to that specific form
[03:25] <sabdfl> but it does allow us to customise, say, the decoration around the form
[03:25] <sabdfl> and put a paragraph at the top, etc
[03:26] <sabdfl> it in turn uses launchpad-addform or launchpad-editform which is what holds the general form structure that is common across launchpad
[03:27] <sabdfl> and that in turn uses launchpad-widget-macros.pt which defines the layout of a given widget's decoration
[03:27] <sabdfl> bug-addform is basically correct already
[03:27] <sabdfl> i'll keep tweaking it today
[03:28] <stud> That sounds good. Most of them will just be boilerplate, and any structural changes to widget layout can still be made in one place
[03:29] <sabdfl> yes
[03:29] <sabdfl> one place to affect the way widgets are decorated (name, description, required or not, and the widget itself)
[03:30] <sabdfl> one place to govern the general form layout (title position, top paragraph, closing paragraph, and buttons)
[03:30] <sabdfl> and then each actual form gets to tweak the content of title and description etc
[03:30] <elmo> BradB: https, not http
[03:30] <BradB> ah
[03:30] <BradB> thanks
[03:31] <Kinnison> see you all later
[03:35] <dilys> Bug 2134 resolved: Create and migrate the user languages preferences to a table PersonLanguage
[03:35] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2134
[03:44] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix sourcepackage link broken due to renaming (patch-684)
[03:45] <carlos> When did we moved from launchapd_test to launchpad_dev?
[03:46] <carlos> I did not saw any mail announcing the change, only a thread talking about it and it was not using launchpad_dev but launchpad_devel
[03:53] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Moved from Schema/Label to its own table to store the Person's languages (Closes: #2134) (patch-685)
[03:59] <sabdfl> carlos: what does the PersonLanguage table look like?
[03:59] <carlos> sabdfl: id, person, language
[03:59] <carlos> in the future it could be updated to store the knowledge level
[04:00] <carlos> as Daf suggested in the thread
[04:00] <sabdfl> UNIQUE (person, language) ?
[04:00] <sabdfl> hey morgs
[04:00] <carlos> yes
[04:01] <morgs> hey mark
[04:01] <carlos> CREATE TABLE PersonLanguage (
[04:01] <carlos>      id serial CONSTRAINT personlanguage_pkey PRIMARY KEY,
[04:01] <carlos>      person integer NOT NULL
[04:01] <carlos>         CONSTRAINT personlanguage_person_fk REFERENCES Person(id),
[04:01] <carlos>      language integer NOT NULL
[04:01] <carlos>         CONSTRAINT personlanguage_language_fk REFERENCES Language(id),
[04:01] <carlos>      CONSTRAINT personlanguage_person_key UNIQUE (person, language)
[04:01] <carlos> );
[04:01] <morgs> I'm trying RocketFuelSetup, but I think I'm missing a tla register-archive line...
[04:02] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: SourcePackage and BinaryPackage bugs counter links to malone. (patch-686)
[04:02] <sabdfl> morgs: what error are you seeing?
[04:03] <kiko> elmo, are you around?
[04:03] <morgs> sabdfl: this command line: $ tla tag -S rocketfuel@canonical.com/launchpad--devel--0 morgan.collett@canonical.com/launchpad--devel--0
[04:03] <morgs> sabdfl: this error: archive not registered: morgan.collett@canonical.com  (see register-archive)
[04:03] <kiko> elmo, cprov and I want to get some "Gina-setup" information going -- even if just a README -- so people that want to install/run it can actually do so without melting their eyes out
[04:05] <sabdfl> morgs: did you do this step:
[04:05] <sabdfl> # create your own archive tla make-archive --signed $myarchive ~/archives/$myarchive  # mirror your own archive onto chinstrap, where PQM and others can easily find it tla make-archive --signed --mirror $myarchive sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/$myarchive  # register the canonical rocketfuel archive tla register-archive sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/rocketfuel@canonical.com
[04:05] <cprov> kiko: it should be more than a README anyway, essentially gina/nicole/etc are not target to end-users
[04:05] <sabdfl> about 1/3rd down the page
[04:05] <kiko> cprov, well, a README is a good start, just a basic list of steps to run. the main problem with gina is the debian archive mirror..
[04:06] <morgs> sabdfl: might have missed that step, I'll just check back and see.
[04:07] <cprov> kiko: keyrings, katieDB and so on ...
[04:07] <kiko> those are easy to solve
[04:07] <kiko> well katiedb less so
[04:08] <kiko> but the archive mirror is the bitch
[04:12] <morgs> sabdfl: I missed the first line: tla make-archive --signed $myarchive ~/archives/$myarchive
[04:12] <morgs> sabdfl: now it works...
[04:12] <kiko> yeah, if you don't have an archive it gets really complicated. :)
[04:12] <sabdfl> yeah that would  be the critical one :-)
[04:13] <morgs> lots of "Good Signatures" now :-)
[04:15] <sabdfl> morgs: go make some coffee
[04:15] <sabdfl> it will take a few minutes to fetch all of our changes
[04:27] <sabdfl> stud: do you have a handy python implementation of the contraints on a "name" field?
[04:40] <stud> database/schema/trusted.sql
[04:41] <stud> sabdfl: Just need to change the \' to ' and \\ to \
[04:41] <kiko> stub the stud?
[04:42] <stud> sabdfl: or lib/canonical/launchpad/validators/name.py has it (but don't rely on that staying there - it is an experiment I havn't done much on yet)
[04:42] <stud> kiko: Hit the nail on the head
[04:46] <sabdfl> stud: i'm going to use the python one, pagetests should break if you move it :-)
[04:47] <kiko> oy
[04:48] <stud> sabdfl: ok. 
[04:51] <carlos> stud: I'm getting an error with the doctests:
[04:51] <carlos> DocTestTestFailure: Failed doctest test for canonical.database.sqlbase.ZopelessT ransactionManager
[04:51] <carlos>   File "/home/carlos/Work/dists/launchpad/lib/canonical/database/sqlbase.py", li ne 181 (or above), in ZopelessTransactionManager
[04:52] <carlos> because it's trying to connect to launchpad_devel
[04:52] <sabdfl> stud: name = args[0] 
[04:52] <sabdfl> wtf is args?
[04:52] <carlos> and that database does not exists anymore
[04:53] <carlos> is it safe if I fix ti pointing to _dev ?
[04:53] <stud> sabdfl: Change that so it works for you - like I said, it is an experiment. args is the arguments that an embedded plpythonu function gets given :-)
[04:53] <sabdfl> ah. do you depend on the one there at all?
[04:55] <stud> carlos: That is weird, because I have never had a launchpad_devel database on my box, ever. launchpad_dev is the current correct name which changed on Friday and I helpfully neglected to tell anyone about on the mailing list
[04:55] <carlos> stud: sorry, launchpad_test
[04:55] <stud> sabdfl: No - it was just somewhere I was playing in.
[04:55] <sabdfl> stud: ok, it's going to be used now :-)
[04:56] <carlos> stud: I noticed it after several dabatase reloads today to change the sample data :-)
[04:57] <stud> carlos: Any launchpad_test's need to be fixed to refer to canonical.lp.dbname and canonical.lp.dbhost, or preferably just use canonical.lp.initZopeless
[04:57] <sabdfl> SteveA: how's the wikiwikiBANGBANG coming along?
[04:58] <BradB> Is there any way to see what gpg commands tla changes runs?
[04:58] <SteveA> it's okay.  I'll be firing a bunch of pages into ubuntulinux.org soon
[04:59] <BradB> i.e. I want a -v for tla changes that's really verbose.
[04:59] <stud> carlos: I don't have that in my copy on sqlbase.py btw.
[04:59] <spiv> BradB: Isn't that what ~/.arch-params/signing/* specifies?
[04:59] <spiv> (or just use strace ;)
[05:00] <carlos> stud: it's inside the doctest
[05:00] <carlos> Quick & dirty doctest:
[05:00] <carlos>     >>> ztm = ZopelessTransactionManager('postgres:///launchpad_test')
[05:00] <spiv> carlos: Oh!
[05:00] <carlos> class ZopelessTransactionManager(object):
[05:00] <spiv> That's my bad.
[05:00] <stud> BradB: Hack your script in the signing directory to output stuff to /tmp
[05:00] <carlos> ok
[05:00] <carlos> spiv: thanks
[05:00] <spiv> It passed the PQM, though ;)
[05:01] <carlos> spiv: I think it's normal, we still have some tests failing 
[05:01] <stud> spiv: Hmm... there is probably still a launchpad_test database on chinstrap that needs removing :-(
[05:02] <BradB> It'd be nice if -v would tell me these things.
[05:02] <spiv> carlos: Well, PQM rejected other merges until I made the tests pass...
[05:05] <carlos> which command should be executed to run all tests?
[05:05] <stud> BradB: Yup, although difficult to implement because the signing is done by a script rather than driving gpg. I think this is the real problem (I bet we have half a dozen different signing scripts on the team, half of them subtly broken).
[05:05] <carlos> I'm using at this moment python test.py -u canonical from the main directory
[05:05] <stud> carlos: make test, or make check
[05:05] <carlos> (to run only unittest)
[05:05] <carlos> ok
[05:06] <stud> carlos: But I use python test.py too because it is easier to control
[05:07] <carlos> stud: the problem with it is that it does not update the tests created automatically from daf's script to test the interfaces
[05:07] <stud> carlos: Oh - I wasn't aware of that. It could be updated to do so (I think our test.py is already subtly customized away from the z3 one).
[05:08] <stud> Where can I find the auto generated tests?
[05:08] <carlos> inside rosetta/tests
[05:08] <carlos> but you are free to move it outside Rosetta
[05:08] <carlos> it's inside daf's todo list
[05:08] <carlos> the script to generate them is:
[05:09] <carlos> generate_sql_tests.py
[05:09] <carlos> from launchpad/lib/canonical/rosetta/scripts
[05:10] <carlos> see you later!
[05:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Remove hard-coded dbname from doctest (patch-687)
[05:17] <daf> mornin'
[05:33] <BradB> http://paste.husk.org/1863 # why is tla telling me it's an invalid sig?
[05:35] <BradB> I've copied my stuff from my other PB to this one, and I'm fairly sure I've taken everything I've needed, relative to tla.
[05:41] <BradB> gah, n/m, i think i know why
[05:41] <ddaa> tell me, please
[05:42] <BradB> i don't have a program named tla-gpg-check on this machine. i'm not yet sure why this is, but I would have been able to find this in 1h, 29m, and 58s sooner if tla told me "tla-gpg-check: command not found"
[05:43] <ddaa> mh... that program is included in the .deb, but not in tla's source distribution iirc.
[05:43] <ddaa> Man... tla's signature checking ui is totally insane.
[05:44] <daf> BradB: http://wiki.canonical.com/ArchGripes, or file a bug at https://bugzilla.warthogs.hbd.com/bugzilla/enter_bug.cgi?product=Arch
[05:44] <BradB> daf: I will definitely do that before I go for lunch. :)
[05:45] <BradB> *def* *in* *it* *lee*
[05:45] <daf> groovy :)
[05:45] <ddaa> well, maybe it is in the distribution...
[05:45] <BradB> ddaa: nope, the bug is in tla.
[05:46] <BradB> ddaa: The error was "tla-gpg-check: command not found" but instead tla told me that the signature was invalid.
[05:46] <ddaa> but I remember having the same problem. A basic tla install from source won't install the script.
[05:46] <BradB> I installed it from darwinports
[05:46] <BradB> But, no matter, the problem is the same.
[05:46] <ddaa> BradB: yeah. That would be a correct bug report.
[06:21] <BradB> oxygen:~/launchpad/lp bradb$ tla changes
[06:21] <BradB> gpg: Good signature from "Brad Bollenbach <bradb@bbnet.ca>"
[06:21] <BradB> * looking for brad.bollenbach@canonical.com/launchpad--devel--0--patch-59 to compare with
[06:21] <BradB> corrupt library (failed inode signature validation)
[06:21] <BradB> looks like another bug (i.e. not being able to copy from one machine to another)
[07:53] <ddaa> BradB: that one is a feature of revision libraries
[07:53] <ddaa> Revisions libraries are not meant to be copied around.
[07:54] <BradB> how is it a feature that when i copy my working dir and rev-libs from my powerbook g4 to my powerbook g4 that it breaks?
[07:54] <ddaa> It will break the inode signatures which are used to detect corruption.
[07:54] <BradB> ...and cause corruption :)
[07:54] <ddaa> It's not actually causing corruption in any harmful way.
[07:54] <BradB> there are other ways to detect corruption surely
[07:54] <ddaa> A revision library 
[07:55] <ddaa> is a cache, and a cache is something that you should share, should you?
[07:55] <ddaa> *should not share
[07:55] <ddaa> BradB: inode sigs is the most efficient way.
[07:55] <BradB> it's a revision library, and yes. :)
[07:55] <BradB> i shouldn't share my safari cache, but i should be able to share a revision library.
[07:56] <ddaa> I'm pretty sure that if tla ran md5sums on all files of a tree of the revlib before using it, we would get many more complaints about performance...
[07:58] <ddaa> BradB: if you can come up with a way to provide copyable revlibs that have similar performance to the current revlibs, we would all be very interested.
[07:58] <ddaa> And something that is not massively complex, of course.
[07:58] <BradB> ddaa: if you can come up for the time for me to do that, i'd be very interested. ;) i'm just trying to write code.
[07:59] <ddaa> BradB: seriously, you cannot copy revlibs and that's a feature. And I believe that's actually a sane feature.
[07:59] <ddaa> There might be other forms of cache which could be copyable, but not revlibs.
[08:08] <daf> ddaa: I don't think an inability to copy is a feature: speed is a feature, and the method used to gain speed precludes copyability
[08:08] <BradB> ddaa: So, I want to write some code. I've copied over (what I think are) all the relevant files from my other powerbook to this one. Then I moved aside all my old rev-libs (because, due to the thousands (?) of small files a sparse, greedy revlib creates, rm -rf'ing takes hours. Literally.) Then I wanted to find out what I've changed. Now I get this: http://paste.husk.org/1864. Why doesn't it just list the files I've changed since
[08:08] <BradB>  my last commit?
[08:09] <BradB> daf: Exactly. :)
[08:10] <daf> BradB: those look like permissions changes
[08:10] <ddaa> -- is "permission change on file" and -/ is "permission change on directory"
[08:10] <ddaa> Your copying was a bit sloppy...
[08:10] <daf> BradB: how did you do the copy?
[08:11] <BradB> ddaa: How was my copying sloppy? I've had to recreate the revlibs.
[08:11] <BradB> Because of the inode sigs.
[08:11] <daf> this isn't a revlib problem
[08:11] <daf> it's something to do with how you copied the code over
[08:11] <BradB> Isn't that what it's comparing to?
[08:11] <ddaa> Your copied tree does not have the permission bits set the same as the original tree.
[08:12] <ddaa> And that shows in the changes.
[08:13] <BradB> To copy I just tarball'd up my old working dir (which took easily over an hour), scp'd it down then untarred it, which also took easily over an hour, heh.
[08:15] <ddaa> The simplest way to fix the things would be to generate a patch for your changes, "tla changes --diffs" should do it, undo your tree to reset the permissions, and apply the patch. Alternatively, I believe fai has some features to apply only parts of a chargeset (e.g. everything but the permission changes).
[08:16] <ddaa> Since you only have content changes, and no inventory changes, the patch approach works well.
[08:16] <ddaa> You can also investigate what options of tar can be used to preserve permissions.
[08:18] <ddaa> Maybe there should be an option in arch to disable the versioning of all permission bits except an executable bit. Versioning all permission  bits is not useful in the common case.
[08:20] <ddaa> BradB: I'm sorry that it takes so much time to do anything i/o intensive on your machine. You should really buy some more RAM.
[08:21] <BradB> ddaa: heh, I've got a 1.5 GHz, 512 MB RAM. :)
[08:21] <ddaa> Last time I heard about it it was 128MB...
[08:22] <BradB> ddaa: notice how i keep referring to how i'm transferring everything over to my new powerbook :)
[08:22] <BradB> but it was never 128
[08:22] <BradB> (though, if i need more than 128 MB RAM to run an RCS, there's a bug in the RCS.)
[08:23] <ddaa> I agree that there are issues. jblack should do some more profiling on what are the specific bottlenecks in star-merge so we can take a decision.
[08:24] <ddaa> It's probably related to the way patchlogs are represented.
[08:24] <BradB> The speed has greatly improved with the new hardware/OS X upgrade, but the architecture of a bunch of small files is always going to be a major bottleneck, I think.
[08:25] <ddaa> Good to hear that you got a setup where you can actually do some work...
[08:26] <ddaa> It's not a major bottleneck here. But tla is one of the reasons why I am using reiserfs...
[08:26] <ddaa> The performance should not be that much dependent on the performance of the filesystem.
[08:28] <daf> BradB: untarring took over an hour?
[08:28] <daf> duude!
[08:28] <BradB> rm -rf'ing the reflibs wasn't even close to being done after 1h 20m
[08:29] <BradB> i hadn't done any exact profiling of the situation though. 1h 20m and still rm rf'in is pretty discouraging.
[08:29] <BradB> ddaa: Nope, tla/arch was the first time I've seen such a preformance problem.
[08:29] <ddaa> It's not tla, it's tar you are talking about.
[08:29] <daf> BradB: you could have moved them out of the way and deleted them in the background
[08:30] <BradB> ddaa: It's thousands of small files I'm talking about.
[08:30] <BradB> That much disk throughput is always going to be a bottleneck.
[08:30] <BradB> daf: I did :)
[08:30] <ddaa> BradB: It would not be taking near that much time on anybody's else machine.
[08:31] <BradB> ddaa: Relatively speaking, surely no, HFS+ is crap. But it's always going to be much slower to work with dir hiearchies full of thousands of small files.
[08:31] <daf> BradB: ah, ok
[08:31] <daf> BradB: it was an hour in parallel rather than in serial -- that's not so bad
[08:31] <ddaa> BradB: We are very concerned by your performance problems... but still it looks like tla is not the only software at fault.
[08:32] <BradB> ddaa: I would argue that it definitely is, but then, I don't have time to put into arch development (I just want to write code), so I'm just bikeshedding.
[08:36] <daf> I don't think this qualifies as bikeshedding
[10:56] <BradB> sabdfl: The changes to the Malone interface look amazing, but where do I go to modify a bug product assignment?
[11:23] <dilys> New bug 2136 for Launchpad/Rosetta: Translation of new pofiles is broken since the table split
[11:23] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2136
[11:24] <ddaa> daf: I heard that you had some evidence that the buildbot hangs are caused by pyarch.
[11:25] <daf> :D
[11:25] <daf> where did you hear that?
[11:25] <ddaa> I believe that's what lifeless told me.
[11:25] <daf> I believe you are mistaken
[11:25] <lifeless> ddaa: 'spiv'. dude 'spiv'/
[11:25] <ddaa> Or maybe it's what I believe lifeless told me spiv told him.
[11:25] <lifeless> spiv is not daf. daf is not spiv.
[11:26] <lifeless> daf, please ignore the frenchman.
[11:26] <lifeless> s/ignore/forgive/
[11:26] <ddaa> lifeless: your gratuitous bashing of the french is sometimes slightly annoying.
[11:26] <ddaa> lifeless: btw, while you are here...
[11:27] <lifeless> ddaa: I'm sorry, bad habit I picked up from a colleague.
[11:27] <ddaa> I have not tested the new taxi yet.
[11:27] <ddaa> I'm not in a configuration which lends itself very well to it atm.
[11:27] <spiv> ddaa: Hello.
[11:28] <ddaa> I have found that w3c-libwww is using a backup~ file at a point. What's the proper way to handle those cases?
[11:29] <ddaa> spiv: hello
[11:29] <lifeless> ddaa: ah, I was just about to commit a fix for a related issue.
[11:29] <lifeless> let me do that.
[11:30] <ddaa> I'm going to bed very soon, but I would be glad if you could mail me a message with the debugging technique you used and your findings.
[11:30] <lifeless> oh, id with no file is a dead giveaway
[11:30] <spiv> Oh, that reminds me...
[11:30] <lifeless> I go straight to the tagging method overrides
[11:30] <ddaa> lifeless: ? yes that's the symptom.
[11:31] <lifeless> which I was doing per package, but I think its symptomatic, so am just doing in JobStrategy these days
[11:31] <ddaa> "blah/.arch-ids/yadda~.id has not associated file"
[11:31] <lifeless> yeah, that means 'the default taggging rules blow chunks'
[11:32] <ddaa> imho, that tends to means "cvs let you commit any stupid crap"
[11:32] <ddaa> Note that the twos are not mutually exclusive in the context of cscvs.
[11:32] <lifeless> it does, and our job is to represent CVS in tla.
[11:32] <ddaa> *the two
[11:32] <lifeless> arch is revision control. tagging methods are policy.
[11:33] <ddaa> (23:31:47) lifeless: yeah, that means 'the default taggging rules blow chunks'
[11:33] <ddaa> I must have misunderstood what you mean.
[11:33] <ddaa> Whatever...
[11:33] <lifeless> the former is a must, the latter frustrates folk that haven't bought into it.
[11:33] <ddaa> spiv: still reminding?
[11:33] <lifeless> spiv: here
[11:33] <spiv> ddaa: Sending mail now :)
[11:34] <ddaa> lifeless: I'm not resolving your "former" and "later" references.
[11:34] <lifeless> rev ctl & policy
[11:34] <ddaa> But my brain is on emergency power atm...
[11:36] <ddaa> the workrave cvstarfile download fails 4 out of 5 times...
[11:37] <ddaa> Mh... finished sync of w3m (import from cvstarfile)... still nothing new... that's becoming a bit disturbing.
[11:54] <ddaa> and again
[12:00] <ddaa> midnight... kick it once more and -> bed