[12:35] damn this stuff is well thought out [12:35] hairy and poorly documented but nonetheless well thought out [01:21] whoot! phear my phorms [01:27] Merge to rocketfuel@canonical.com/launchpad--devel--0: good looking autogenerated edit and add forms for bugs (patch-679) [02:07] Merge to rocketfuel@canonical.com/launchpad--devel--0: good looks for ALL autogenerated add and edit forms (patch-680) === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === BradB|out is now known as BradB [04:45] Morning === mdz_ [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === mdz_ is now known as mdz === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has left #launchpad ["Client] === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad [06:17] Any zope guys around? [07:02] jblack: Yo [07:03] stub: I'm finally starting to get zope. [07:03] You should see a doctor [07:03] Heh. Yeah. It took being sick to do it. :) [07:04] But anyways.... I've setup an object, and I can refer to attributes in the interface. That's fine and all. [07:04] But I don't seem to be able to include just an object. [07:05] I don't get that second sentence. [07:05] I.E. I can do

A name

, but I can't do

Showing a whole object

[07:05] oic. [07:05] __str__ ? [07:05] in the interface. === lifeless us guessing [07:05] *is* [07:06] Well, if I point at localhost:8080/James/ I get a nice html layout of the information (thanks to info.pt) [07:06] I don't think it even needs to be in the interface - it just needs one. [07:06] I'd like to include that. [07:06] stub: surely thats a whole in the interfaces implementation? [07:06] stub: So what? Its "ok" to put html in an interface? [07:07] 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] What is the name of the view that uses info.py? (The name in the page directive most likely) [07:09] No clue. The only place I referenced info.pt was in configure.zcml [07:09] 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] Oh, you mean the page I'm trying to do this? yeah, index.html [07:11] 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] 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] stub: hmm. === lifeless thinks that is crack [07:13] nope. system error for contex/James/@@index, context/James/index and context/James/@@index.html, ...@@info.pt, ...info.pt [07:14] Oh yeah. I get a security error when I just use "context/James" [07:16] What is context btw? A container of some kind? [07:17] 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] Zope publishes a tree of objects. These objects are generally your context. You attach Views to them. [07:21] 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] What's the difference between a view and an interface? [07:22] I see that according to the graph, a view calls the interface, which defines the interface for a class. [07:22] 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] Calling an interface doesn't make sense. If you see syntax like IFoo(someobject), that is actually Adaption which is something different. [07:24] Ok. the view definitions go in configure.zcml. [07:24] Yes [07:24] such as [07:24] Ahhhaaa [07:25] 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] So why doesn't

work? [07:26] according to my log, I get: [07:26] NotFoundError: (, 'index.html') [07:26] 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] ok... buddy demo.. [07:27] lynx localhost:8080 [07:27] and in index.html, I have in the body, the div tal:replace I mentioned. [07:29] So we have IBuddy, and an object instance that implements IBuddy called 'James'. [07:29] We have attached a view named 'index.html' to all objects that implement the IBuddy interface (the yes, and yes [07:30] 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] Incorrect. [07:31] Actually ,yes. That's correct. [07:32] 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] correct. [07:32] but if I do that, I get a security error. [07:33] [07:33] That shows up in the browser. The log looks fine. [07:33] 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] Changed [07:35] You should get 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] Ok. so it should be context/James/index.html. [07:36] What do you get if you have tal:content="structure context/James/@@index.html" [07:36] Yes [07:37] Hmmm. I must have a typo then, because that gives me: NotFoundError: (, 'title') [07:37] 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] Looks like something is trying to do tal:content="user/title" and this is failing. [07:39] Does anything look like that in info.pt ? [07:39] Nothing that references title, no [07:41] btw, if I go to http://localhost:8080/James, the object represents correctly. [07:41] If it would help, I'm more than willing to tarball this for you. [07:42] So the name= attribute of the browser:page element in configure.zcml is definitly name="index.html" ? [07:42] Sure - tarball it and email to stuart@stuartbishop.net [07:43] On its way. [07:45] btw, thanks. I appreciate the help === BradB is now known as BradB|zzz [07:55] jblack: And the source of the document that is trying to do tal:content="context/James/index.html" ? [07:56] /index.html [07:56] Its in the zobdb [07:56] You will have to cut'n'paste it [07:57] oh, that didn't come with the tarball? [07:57] http://www.pastebin.com/113455 [07:59] Nice PHP tags in there :) [08:00] that's done by pastebin. its not in my script. ;) [08:04] 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] I have no idea how to do that. [08:13] 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] I don't get it. Isn't this a pretty basic fundamental property of zope? [08:20] To be able to do stuff like this? [08:23] Yes. I need to trace down what is trying to access the unauthenticatedprincipal, which is what is raising the exception. [08:24] 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] Z3 is not focused on the TTW stuff though at the moment, so the TTW page templates could have problems. [08:25] Goddammit I can't drive svn anymore :-( [08:25] (Not that I ever could...) === jblack laughs evilly [08:27] I take it you mean a z3 builtin template? I haven't gotten to doing templates and metal just yet. [08:30] Yes - something builtin. [08:40] should I try changing the view name from index.html to something else? [09:22] 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] I'm confused. Other views work fine, but mine is hosed/ [09:24] Are you running the beta tarball or a svn checkout btw? [09:25] I'm running the release candidate [09:25] 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] ZopeX3-3.0.0c2 [09:25] (which would be a bug) [09:26] how do I work around it? [09:28] I'm attaching views to the interface '*' (ie. every damn object), which is not exactly an optimal work around :-) [09:28] [09:31] With that change, I get NotFoundError: (, 'includer.html') [09:32] (yes, I renamed info.pt to includer.pt) [09:33] and my [top] / index.html has the following pertinant line:

[09:34] Erm... you would need to create includer, not use info.pt [09:34] (where includer.pt contains the same code as in your TTW page template) [09:35] 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] What do people normally do instead? [09:36] They use slots instead or something? [09:37] 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] What you are doing should work fine though [09:51] Its being looked into by bigger brains than mine [09:59] Thanks for digging into this, stub === stub hands jblack a badge with the label 'Successful Z3 beta tester' === jblack cries === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [10:02] so, when a new version of zope comes out, how do I upgrade an instance? [10:02] morning [10:05] Ok. So make a folder, put buddies in there instead. [10:25] 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] Oh, didn't realize instances depended on the install === Kinnison [~dsilvers@81-178-251-195.dsl.pipex.com] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:40] 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] doesn't c1 postdate rc3? [10:41] svn co svn://svn.zope.org/repos/main/Zope3/branches/ZopeX3-3.0 [10:41] Hmm... [10:42] I though you said rc2 before === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:57] lifeless, stub: __repr__ is public by default. __str__ generally is not. [11:00] 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] jblack: Your code works just fine on my ZopeX3-3.0c2 installation [11:03] Huh. That's what I'm using. ZopeX3--3.0.0c2 [11:03] Yup. So I don't know what is wrong at your end :-) [11:05] morning all [11:07] stub: i've got the pretty-forms stuff working in a shoddy way, will clean it up today [11:07] our forms are pretty shoddy [11:07] bug-addform is as it should be? [11:08] sorry, no ? required [11:08] SteveA: why? [11:08] Yup. So how did you go with the form machinery stuff? PITA or did it grow on you? [11:08] sabdfl: bad pun. you said "i've got the pretty-forms stuff working in a shoddy way" [11:08] stub: there was no documentation to do what i wanted to do, so it was a weekend of groping in the dark [11:08] ah :-) [11:09] stub: found what i think was your work (default-addform, default-editform) and built on that [11:10] i think we can get it relatively pretty for relatively little work now [11:10] but eventually we are going to need qute a few custom widget classes [11:10] still, should be doable [11:11] 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] I'm having flashbacks from my last job with all that informative text included inline in the form ;) [11:43] 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] carlos: what's the attribute [11:46] 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] but the interface does not have it [11:47] Person.languages [11:47] Person.addLanguage [11:47] and the needed RelatedJoin attribute [11:48] carlos: absolutely, add that to the person class [11:49] ok [11:49] we want to avoid local copies of the classes as much as possible [11:49] later on, maybe we can split functionality up but for the moment put everything you need into Person directly [11:49] ok [11:50] later this week, I will add the License object, where should It be stored? [11:50] Merge to rocketfuel@canonical.com/sqlos--test--3.0: Workaround for 'destroySelf breaks commits' problem (patch-3) [11:52] in our database, the fundamental unit of licensing is the source package. [11:55] carlos: it's a new table so it gets database/license.py, zcml/license.zcml, interfaces/license.py etc === Kinnison discovers that someone has been adding constraints to the db in such a way that gina no longer works [12:04] ok [12:11] 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] zope3 standard is us english [12:12] (point of information) [12:13] 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] Well; the binarypackage table has a 'licence' column which is clearly en_GB [12:14] This is why I'm asking y'see :-) [12:15] Or at least; en_US always seems to use 'license' [12:17] Merge to rocketfuel@canonical.com/buildbot--devel--0: Make taxi work again (patch-63) [12:27] spiv: ping [12:29] carlos: pong [12:29] spiv: I'm using a RelatedJoin that will give me addLanguage and removeLanguage methods for free [12:30] I suppose that I should add them to the interface file, right? [12:30] If they're part of the interface, yes ;) [12:30] yes, I will need them [12:30] Yep, then do it. [12:30] will it give any problem with the interface tests? [12:31] Nope. [12:31] perfect, thanks [12:31] The interface tests look at the object, rather than trying to read the source code directly :) [12:31] makes sense :-) === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [12:43] Merge to rocketfuel@canonical.com/launchpad--devel--0: Make the librarian optional for gina (patch-681) === Kinnison discovers that he can't work out how to get from a distroarchrelease to the architecture name as used by dpkg/apt-ftparchive/etc === debonzi [~debonzi@200.158.100.251] has joined #launchpad === cprov [~cprov@200.158.100.251] has joined #launchpad [01:24] Merge to rocketfuel@canonical.com/launchpad--devel--0: SourcePackage bugs counter. (patch-682) [01:31] Merge to rocketfuel@canonical.com/launchpad--devel--0: Merge lalo's zopeless transactions work and other changes needed for importd (patch-683) [01:39] Kinnison: morning, can you give me a briefly explanation about "optional librarian dependency on gina" ? How to proceed ? [01:42] cprov: theres a line in grabber.py you comment out. the attachLibrarian() call [01:43] 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] Kinnison: I'll try in that way, tks [01:47] cprov: You're welcome [01:47] cprov: If you can patch the rest of gina to get her able to import again; that'd be doubly fantastic [02:05] Kinnison: it is working now, but I need to comment out some lines in classes.py (getLibraryAlias) [02:06] Kinnison: do you think we can have a FLAG (!!!) ? [02:07] We really want a stub Librarian for a real fix [02:10] stub: sorry, what do you mean with "stub librarian" ? [02:12] Something that fakes the API we use to communicate with the Librarian which we can use for development etc. [02:12] it is an animated stu to help you find your files -- our answer to "clippy" [02:12] But I might be solving a different problem :-) [02:13] hi stub... the page malone/sourcepackage/mozilla-firefox-dummy/ seems to be broken for me.. do you know about it? [02:13] cprov: You could if you wanted. I was just going on the 'if librarian is None:' bit in getLibraryAlias in library.py [02:16] Kinnison: I see :) [02:16] debonzi: Ta. I think Malone is obviously lacking on the page tests, which I should get onto tomorrow :-) [02:16] SteveA: Bad Steve! [02:17] it's almost like being a move star! === stub is now known as stud [02:18] stub, right.. just to check because I'm linking sourcepackage for its bugs and I saw it.. thanks :) [02:30] 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?) === Kinnison -> Lunch [02:33] Of course, neither is probably correct as Soyuz appears to be using 'src' :-( [02:33] stud, You are right.. but I saw it working friday with sourcepackage.. [02:34] stud, maybe it was a proposital modification [02:37] Nope - my dictionary doesn't know that word either :-) [02:37] stud, AFAICS mark was the last one to play with malone/configure.zcml [02:38] stud, ops.. sorry :) [02:39] s/proposital/intentional [02:39] I suspect he wants the URL changed because hitting '6x' in vim at the right time is a rather improbable typo [02:40] 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] Or maybe we have more important things to worry about :) [02:42] stud, yes probably so :) === stud goes and fixes the broken package search screen === debonzi wishs stub a happy hacking [02:44] If I can find which template it is in that haystack :-( [03:06] 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] stud: yes, was me that changed the url to "malone/package/", sorry if i didn't catch it everywhere [03:10] my rationale for that one is that we *only* track assignment to *source*package so the source is redundant [03:10] sabdfl: Only the one spot once that I have found [03:11] sabdfl: If architecturetag was meant to be for that; then that is broken too [03:11] in soyuz, we need the distinction between sourcepackage and binarypackage much more [03:11] sabdfl: What with the test-data having 'warty--x86--devel--0' [03:11] 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] Kinnison: i think that was a flying guess from someone that went off in the wrong direction :-) [03:12] sabdfl: me ?? [03:12] stud: agreed [03:12] sabdfl: 'stud' again? [03:12] cprov: maybe, no big deal === Kinnison tuts sabdfl [03:13] stub's been working out again, hey stud [03:13] stud: quick update on the add/edit for situation [03:13] sabdfl: Should I put an UPDATE statement in my SQL patch which is pending then, to update the test-data ? [03:14] Kinnison: isn't it repaired in sampledata, yet ? if not, please replace it with 'i386' or something simple like that ... [03:14] 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] Kinnison: Yes please. [03:14] then check it out, if happy copy the newsampledata.sql it created over current.sql [03:14] stud: is that right? [03:14] glerp [03:16] 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] Kinnison: AFAIKS, current current.sql contains the right archtagrelease 'i386' [03:16] cprov: aah yes it does === Kinnison spanks hisself for being too dumb to spot that [03:16] you're a star [03:17] (Assuming the sample data changes relate to the schema mods...) [03:17] Okay, I'll go back to sleep now :-) [03:17] stud: i don't think this is a structural change [03:17] (Well; actually I'll update my test db and carry on) [03:18] just that there's a bad bit of data: 'i386' is 'warty-x86--devel--0' or something [03:18] sabdfl: oic. i just read pending patch :-) [03:18] stud: so, about the add/edit forms [03:18] i'm creating launchpad-addofmr and launchpad-editform === BradB|zzz is now known as BradB [03:19] based on your default-addform and default-editform [03:19] but with a few tweaks [03:19] morning BradB! [03:19] hi :) [03:20] stud: speaking of pending patches; I'm *almost* ready for you to merge my pending patch :-) [03:20] stud: Just got another two views to finalise :-) [03:24] 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] stud: ok, so here's what i'm heading towards [03:25] elmo: why does launchpad.ubuntu.com say "Nothing to see here" instead of showing the devel version of launchpad? [03:25] for each add or edit form, we will create a very small template [03:25] this template will just really host things that are unique to that specific form [03:25] but it does allow us to customise, say, the decoration around the form [03:25] and put a paragraph at the top, etc [03:26] it in turn uses launchpad-addform or launchpad-editform which is what holds the general form structure that is common across launchpad [03:27] and that in turn uses launchpad-widget-macros.pt which defines the layout of a given widget's decoration [03:27] bug-addform is basically correct already [03:27] i'll keep tweaking it today [03:28] 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] yes [03:29] one place to affect the way widgets are decorated (name, description, required or not, and the widget itself) [03:30] one place to govern the general form layout (title position, top paragraph, closing paragraph, and buttons) [03:30] and then each actual form gets to tweak the content of title and description etc [03:30] BradB: https, not http [03:30] ah [03:30] thanks === Kinnison heads home so he can work from his desk once more [03:31] see you all later [03:35] Bug 2134 resolved: Create and migrate the user languages preferences to a table PersonLanguage [03:35] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2134 [03:44] Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix sourcepackage link broken due to renaming (patch-684) [03:45] When did we moved from launchapd_test to launchpad_dev? [03:46] 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 === kiko [kiko@200-206-134-238.async.com.br] has joined #launchpad [03:53] 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] carlos: what does the PersonLanguage table look like? === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [03:59] sabdfl: id, person, language [03:59] in the future it could be updated to store the knowledge level [04:00] as Daf suggested in the thread [04:00] UNIQUE (person, language) ? === morgs [~morganc@wblv-234-32.telkomadsl.co.za] has joined #launchpad [04:00] hey morgs [04:00] yes [04:01] hey mark [04:01] CREATE TABLE PersonLanguage ( [04:01] id serial CONSTRAINT personlanguage_pkey PRIMARY KEY, [04:01] person integer NOT NULL [04:01] CONSTRAINT personlanguage_person_fk REFERENCES Person(id), [04:01] language integer NOT NULL [04:01] CONSTRAINT personlanguage_language_fk REFERENCES Language(id), [04:01] CONSTRAINT personlanguage_person_key UNIQUE (person, language) [04:01] ); [04:01] I'm trying RocketFuelSetup, but I think I'm missing a tla register-archive line... [04:02] Merge to rocketfuel@canonical.com/launchpad--devel--0: SourcePackage and BinaryPackage bugs counter links to malone. (patch-686) [04:02] morgs: what error are you seeing? [04:03] elmo, are you around? [04:03] sabdfl: this command line: $ tla tag -S rocketfuel@canonical.com/launchpad--devel--0 morgan.collett@canonical.com/launchpad--devel--0 [04:03] sabdfl: this error: archive not registered: morgan.collett@canonical.com (see register-archive) [04:03] 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] morgs: did you do this step: [04:05] # 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] kiko: it should be more than a README anyway, essentially gina/nicole/etc are not target to end-users [04:05] about 1/3rd down the page [04:05] 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] sabdfl: might have missed that step, I'll just check back and see. [04:07] kiko: keyrings, katieDB and so on ... [04:07] those are easy to solve [04:07] well katiedb less so [04:08] but the archive mirror is the bitch [04:12] sabdfl: I missed the first line: tla make-archive --signed $myarchive ~/archives/$myarchive [04:12] sabdfl: now it works... [04:12] yeah, if you don't have an archive it gets really complicated. :) [04:12] yeah that would be the critical one :-) [04:13] lots of "Good Signatures" now :-) [04:15] morgs: go make some coffee [04:15] it will take a few minutes to fetch all of our changes [04:27] stud: do you have a handy python implementation of the contraints on a "name" field? [04:40] database/schema/trusted.sql [04:41] sabdfl: Just need to change the \' to ' and \\ to \ [04:41] stub the stud? [04:42] 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] kiko: Hit the nail on the head [04:46] stud: i'm going to use the python one, pagetests should break if you move it :-) [04:47] oy [04:48] sabdfl: ok. [04:51] stud: I'm getting an error with the doctests: [04:51] DocTestTestFailure: Failed doctest test for canonical.database.sqlbase.ZopelessT ransactionManager [04:51] File "/home/carlos/Work/dists/launchpad/lib/canonical/database/sqlbase.py", li ne 181 (or above), in ZopelessTransactionManager [04:52] because it's trying to connect to launchpad_devel [04:52] stud: name = args[0] [04:52] wtf is args? [04:52] and that database does not exists anymore [04:53] is it safe if I fix ti pointing to _dev ? [04:53] 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] ah. do you depend on the one there at all? [04:55] 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] stud: sorry, launchpad_test [04:55] sabdfl: No - it was just somewhere I was playing in. [04:55] stud: ok, it's going to be used now :-) [04:56] stud: I noticed it after several dabatase reloads today to change the sample data :-) [04:57] 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] SteveA: how's the wikiwikiBANGBANG coming along? [04:58] Is there any way to see what gpg commands tla changes runs? [04:58] it's okay. I'll be firing a bunch of pages into ubuntulinux.org soon [04:59] i.e. I want a -v for tla changes that's really verbose. [04:59] carlos: I don't have that in my copy on sqlbase.py btw. [04:59] BradB: Isn't that what ~/.arch-params/signing/* specifies? [04:59] (or just use strace ;) [05:00] stud: it's inside the doctest [05:00] Quick & dirty doctest: [05:00] >>> ztm = ZopelessTransactionManager('postgres:///launchpad_test') [05:00] carlos: Oh! [05:00] class ZopelessTransactionManager(object): [05:00] That's my bad. === spiv fixes [05:00] BradB: Hack your script in the signing directory to output stuff to /tmp [05:00] ok [05:00] spiv: thanks [05:00] It passed the PQM, though ;) [05:01] spiv: I think it's normal, we still have some tests failing [05:01] spiv: Hmm... there is probably still a launchpad_test database on chinstrap that needs removing :-( === carlos was trying to fix some of them because he broke also someones... [05:02] It'd be nice if -v would tell me these things. [05:02] carlos: Well, PQM rejected other merges until I made the tests pass... [05:05] which command should be executed to run all tests? [05:05] 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] I'm using at this moment python test.py -u canonical from the main directory [05:05] carlos: make test, or make check [05:05] (to run only unittest) [05:05] ok [05:06] carlos: But I use python test.py too because it is easier to control [05:07] 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] 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] Where can I find the auto generated tests? [05:08] inside rosetta/tests [05:08] but you are free to move it outside Rosetta [05:08]