[12:32] spiv, BradB: ping? [12:44] yo [12:44] BradB, apart from twisted, what options do we have for good scalable xmlrpc servers in python? [12:44] BradB, or is the question really "why anything but twisted?" :) [12:44] i know nothing about xml rpc. maybe the standard lib one is useful, maybe Twisted's the most supported one out there though. [12:44] I reckon spiv knows but won't tell us. [12:52] Hello. [12:52] kiko: The one that ships with the stanard Python library scales pretty well too (but not as well as twisted). [12:52] I've no idea about good non-Twisted options for XML-RPC :) [12:52] spiv, stub: so it would be twisted, zope and the PSL server? [12:52] Those are the ones I know of, yeah. [12:52] Zope 3 supports XML-RPC. [12:52] yeah, I just don't know how good it is. but thanks! [12:52] it's all about zope 3 [12:52] kiko: I think you will find most of the other toolkits (webware, quixote, albatross etc.) support it all since it is pretty trivial to add if you can do http. [12:52] skunkweb.. [12:52] hmmm [12:52] Ahhh... I thought it was just my working branch that had the batch problem - how did that get past pqm??? [12:52] hmm.... need to debug the test runner... all tests should be running.... :-P [12:52] i think my next checkin will spam root@localhost on chinstrap. oh well. [12:53] BradB: Might be worth setting that to nobody@example.com or something so elmo doesn't beat you up ;) [12:54] i wouldn't have thought it'd be a good idea to spam example.com, but i could be wrong [12:54] spiv: You want I do the db thing now, or in 14 or 15 hours? [12:55] BradB: example.com is in the rfc's as an example domain. You are allowed to use it (unlike nowhere.com, somebody.com, somewhere.com all of which get huge amounts of unwanted mail ;) ) [12:56] yeah, i know [12:56] but i wouldn't have thought delivering mail there was a good idea [12:56] eeeg, this mail'll add up though, [12:57] Oohh... would be fine except our errors-to is still hardcoded to nobody@example.com :-P [12:57] elmo: ping [12:58] in any case, shit, got a failed test [12:59] paste coming up: [12:59] /home/pqm/arch/queue/workdir/rocketfuel@canonical.com/rocketfuel@canonical.com---launchpad--devel--0/launchpad/lib/canonical/database/sqlbase.py:85: UserWarning: Something tried to set a _connection. Ignored. [12:59] warnings.warn("Something tried to set a _connection. Ignored.") [12:59] Exception exceptions.AttributeError: "'ConnectionDescriptor' object has no attribute 'cache'" in > ignored === BradB greps [01:00] That isn't actually a failing test - I suspect that is a succeeding test that happens to be triggering a warning. === stub has been beating his head against unit tests for the last few days [01:00] 6 failures, 1 error, aiieee === BradB star-merges === BradB was semi-beating his head against page tests today, but once this lands, malone will be indestructable [01:02] Make a fresh database instance too - some of the tests are still connecting to launchpad_dev, so might fail if the database has been modified too much or tests run in the wrong order. [01:02] i've got them ordered [01:02] Not the page tests - all the other functional and unit tests gumph. Some very fragile bits in there - fix one and break others ;-( [01:03] the test runner makes a fresh db instance automatically, i thought (e.g. if i do 'python test.py -f' i expect it to reset) [01:03] ah [01:03] Page tests should be fine now. Even have stories so they don't tread on each others toes :-) [01:04] i made a new "story" called malone [01:10] So we need any more work to write sane tests for event notifications? At the moment we can just interrogate canonical.launchpad.mail.stub.test_emails, which I suspect is all we need [01:13] stub: Hmm, now is fine, but not much later or I'll be asleep :) [01:16] spiv: ok. Just killing the server now. Will be down for 5/10 mins tops. [01:17] lifeless: ping. Doing emperor upgrade now. [01:18] great [01:18] stub: Ok. === justdave [~dave@24.236.223.222.gha.mi.chartermi.net] has joined #launchpad [01:27] spiv, lifeless: back up [01:28] Gar. [01:28] justdave: Morning. [01:28] Not fixed :( [01:28] Oh well, at least I can restart it manually in this case. [01:28] Damn. [01:28] stub: ? [01:29] stub: Thanks. [01:29] spiv: We might want to wrap psycopg with something that handles this gracefully. non-twisted we can just block until the db comes back up, but I don't know the best way of handling it in twisted. [01:31] elmo: We need an email address to send bounces of malone email notifications to, which just throws them away until we get a bounce processor. We also need an email address that just throws emails away to use as a 'from' address which may be used in the dogfood environment or testing stuff. [01:31] bounces@canonical.com and nobody@canonical.com? [01:33] stub: Well, Twisted's db access all runs in threads anyway, so it's blocking too. [01:33] (because DB-API 2.0 doesn't give you any other choice...) [01:34] stub: The part that intrigues me is that there's already code in Twisted's adbapi module to cope with this, or so I thought, so I'd like to figure out why it's not working. [01:37] spiv: ok. Sounds like a better option. I don't know what lifeless is doing with the importd processes. Its difficult to see if they have all reconnected due to all the 'missing FROM clause' spam in the logs :-/ [01:37] Heh. [01:38] grep -v is your friend ;) [01:38] that would be the authserver trying to join with the EmailAddress table... [01:39] Heh. I suppose that's a hint ;) [01:40] stub: mm, ok [01:41] Ohh... need to check if the authserver is querying on lower(emailaddress.email) instead of emailaddress.email, since that is what the index is built on and it should be caseinsensitive anyway [01:42] err, WTF [01:42] bradb? [01:42] I don't think it is, but I can fix that while I'm fixing the join warning. [01:42] elmo: sorry about the spam dude. [01:42] it would have been worth it if my changes actually landed though. [01:43] BradB: no, not that, please read your mail - I just sent you something [01:45] elmo: odds are about 99% that it's operator error (or operator-not-understanding), but i'll double-check now, just to be sure. [01:45] I would have written it off, but the guys a DD [01:45] still very happy for it to be anything but what he claims... [01:50] it'd be nice if he gave his username [01:53] anyway, i just signed up as a new user and i don't have mgr rights. the site just permits normal members to do quite a bit, which is why i created the "locked" state for lu, so that she could added pages to the site that were published, and yet not modifiable by non-managers (because just about everything else is) [01:57] ok, thanks for checking, I'll reply and ask him for more info, in case he has discovered some leet back door [01:57] an account with his email address has the roles: ('Member', 'Authenticated') [01:57] (which is normal, of course ) [01:57] does plone have the equvalent of RecentChanges? i.e. can we keep track of what's changing? [01:58] there might be a product that does that, but nothing useful out of the box, and thus nothing in ul.org that i'm aware of. it's been brought up by mark et al. before. [02:05] Merge to rocketfuel@canonical.com/launchpad--devel--0: [authserver] JOIN explicitly, and use lower(EmailAddress.email) (patch-722) === BradB is now known as BradB|away [02:10] stub: I'll update the authserver with that tomorrow, when I'm actually awake :) [02:10] yup. its not urgent. [02:14] spiv: Something is leaking bad names too (which will now generate an SQL error instead of polluting the db). I don't know if this is the authserver or not - possibly it is the code that generates a username from an email address? We can confirm a valid name using canonical/validators/name.py (which is now being used despite the warnings in the comments) [02:15] Hmm. You mean creating bad Person.names? [02:15] Yup [02:16] Which I don't think anything is using yet, apart from traversal stuff, so I suspect the 'generate name from email address' code wherever that lives now. [02:16] Have there been recent changes to the nickname generation code? The authserver might have an old version. [02:16] (The deployed authserver, I mean) [02:17] The authserver uses canonical.foaf.nickname to generate names from email addresses. [02:18] There have been no updates as far as I'm aware - if that is the problem it has always been there. The name constraints did not exist when it was implemented, so I suspect it was just designed to be a bit more flexible than the database allows. [02:18] Ah. [02:18] k. I'll stick in a bugzilla bug to update canonical.foaf.nickname [02:19] erm... or that should be a malone-dogfood bug [02:20] The url to which has completely slipped my mind... :-( === stub found it === kiko is now known as kiko-afk [02:35] BradB|away: yeah, operator-not-understanding error, meh [02:43] Can't add a bug on dogfood :-( [02:46] New bug 2151 for Launchpad/Launchpad: generate nickname failing with sql exceptions [02:46] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2151 [02:48] New bug 2152 for Launchpad/Malone: Missing product-assignment in create-a-bug form [02:48] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2152 [02:52] New bug 2153 for Launchpad/Malone: create-a-bug and too many required fields [02:52] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2153 === doko [doko@dsl-082-082-066-121.arcor-ip.net] has joined #launchpad [05:10] Merge to rocketfuel@canonical.com/launchpad--devel--0: Give warning if running with add_missing_from=true (patch-723) === morgs [~morganc@wblv-249-229.telkomadsl.co.za] has joined #launchpad === morgs [~morganc@wblv-249-229.telkomadsl.co.za] has left #launchpad ["Leaving"] === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [05:48] Merge to rocketfuel@canonical.com/launchpad--devel--0: New schema baseline (patch-724) [06:01] Merge to thelove@canonical.com/bazaar--devo--1.0: tidy up code to build with stricter CFLAGS (patch-57) [06:03] Merge to thelove@canonical.com/hackerlab--devo--1.1: tidy up code to build with stricter CFLAGS (patch-2) [06:13] Merge to thelove@canonical.com/bazaar-debian--debian--1.0: merge stricter build flags (patch-4) [08:28] Merge to thelove@canonical.com/bazaar-debian--debian--1.0: fix borked version number in changelog (patch-5) === morgs [~morganc@wblv-249-229.telkomadsl.co.za] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad [10:44] Marning === Kinnison takes a big fuckoff launchpad merge and glares at it for a bit === Kinnison workraves (already!) :-( [11:22] elmo: what time of day does mawson update the archive? [11:47] Kinnison: err, 'now'? ;-) I still haven't tracked down what's killing the daily sync [11:47] elmo: *grin* okay; thanks dude [12:35] elmo: Will you have a while to talk about package versions and removal of old version etc with me over the next day or two? [12:35] sure === Kinnison wants to make sure he's not running off down a completely fucked route :-) === Kinnison watches gina import samhain [01:40] only a couple of days late :-) === debonzi [~debonzi@200.158.100.251] has joined #launchpad [01:43] hey debonzi [01:44] good news; elmo updated mawson's mirror earlier and gina is chugging through again [01:45] dsilvers@petitemort:~$ hive list [01:45] library-utf : UTF-8 enable the librarian protocol [01:45] Hmm; shall I carry on with that? === Kinnison ponders what would be the most useful use of his time [01:46] Kinnison, yo [01:54] debonzi: hiya! [01:56] debonzi: I wanted to ask you if you have an ubuntu mailing list and/or IRC channel set up in Portugese yet / plans for it? [01:56] hi lulu :) [01:57] debonzi: :o) ^ [01:57] lulu, we have one irc channel for launchpad for cprov, kiko, salgado and me [01:58] lulu, AFAIK there is no plan for ubuntu mail list/IRC channel up to now, but we can set it up :) [01:58] debonzi: there are other portugese users who want to set up a portugese channel - perhaps it would be worth setting up one for public use? [01:59] an IRC channel as a first and then invite people to it, and appoint someone to dot he traffic for it. [02:00] lulu, cool :) how can I help? [02:00] lulu: can you point silbs at her IRC window? [02:01] set up the IRC channel and let me know what it is....! [02:01] kinnison: will do. [02:01] lulu, right.. Ill do === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [02:19] lulu, do you think #ubuntu-br is ok or whould be better a more general name to do not direct the first idea to Brazil? === debonzi back in a minute [02:37] debonzi: what other options are there from your experience? [02:48] lulu, well, #ubuntu-portuguese I think is too long. #ubuntu-pt has the same problem as #ubuntu-br, maybe #ubuntu-pt_br.. but I don't know if it sounds good [02:50] lulu, wich one sounds better to you? [02:58] debonzi: it's important to name it after a language not a country, is there an abbreviation for portugese that's used often? [02:58] ubuntu_portugese_not_portugal [02:59] lulu, yes pt, but it is also an abbreviation for Portugual I think [02:59] lulu, if you think ubuntu_portugese is ok let do in that way === BradB|away is now known as BradB [03:00] morning [03:00] debonzi: would having -pt offend Brazillian Portugese speakers? [03:00] BradB: morning! [03:00] hi lulu :) [03:01] lulu, I don't think so [03:02] lulu, we can also leave on the topic something like (pt=portugese)!= portugal ;-) [03:03] debonzi: ok - let's go for that then. Then you need to get your Brazilian community on there! :o) thanks! [03:03] lulu, right.. ;-) [03:03] debonzi: I'll add it to the local language page. [03:04] cool [03:10] debonzi: we use #ubuntu-es for Spanish not Spain and it's ok for all people [03:11] carlos, right.. thats that I did.. #ubuntu-pt ... I think its not a problem too ;-) [03:12] s/that/what [03:15] nickname.NicknameGenerationError: martin@v.loewis.de is not a valid email address [03:15] frazzle wazzle grumble mumble === Kinnison fixes the regex and restarts gina [03:18] lulu: See; when I'm having a bad time; the words are 'frazzle wazzle' and 'grumble mumble'. Sometimes 'groan' and/or 'complain' [03:30] Are we meant to have two run_launchpad.py instances on mawson? [03:30] aah; one belongs to mr dafydd === debonzi -> lunch [03:31] kinnison: I am so impressed with you :o) === Kinnison takes lulu's temperature [03:32] kinnison: ;) control of words is what I meant! === Kinnison speaks english very good === Kinnison learns her from a booook [03:50] rah; gina completed === Kinnison cleans up [03:52] Can someone with an understanding of the web-app play with it and tell me how that import looks? [03:52] I'll create a report of all the failures next [04:03] !Md:*! Hi everybody. Just wanted to let you know that there will be (friendly) discussion and (hopefully) live coverage on this year's US presidential election in #election2004 [04:03] !Md:*! (another useful information source is http://en.wikipedia.org/wiki/2004_U.S._election_in_progress) [04:07] Kinnison: Looks good judging from some trivial poking around :) [04:07] spiv: rock === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [04:08] spiv: /tmp/gina-postrun.log contains the output of a re-run of gina (theoretically should do nothing because everything should be imported) [04:08] eww, it's poorly formatted, let me re-do that [04:08] "View Binary Packages List (14352 Packages)" [04:08] :) [04:09] does that sound right for hoary? [04:09] I dunno :) [04:09] Glancing at the actual list, it looks sane, I think. [04:09] I presume this includes universe? [04:09] yes [04:09] but not multiverse === spiv nods [04:10] Hmm, the description still doesn't deal with multiple paragraphs well. [04:10] (see e.g. https://launchpad.ubuntu.com/soyuz/distros/ubuntu/src/hoary/bicyclerepair) [04:11] that's up to the app to process and render the description properly [04:12] Yeah. [04:13] blergh; how do I get python to autoflush stdout? [04:14] What's wrong with calling sys.stdout.flush()? [04:15] It's line buffered by default, iirc. [04:15] too many places where "print" is called [04:15] it's not line-buffered if stdout is a pipe [04:15] I need it to be [04:15] Or run python with -u [04:16] hmm; I'll try that; thanks [04:16] hurrah; much better [04:19] now the logs in /tmp should be slightly more temporally correlated [04:23] - Evaluating alcovebook-sgml (main, 0.1.2-5ubuntu1) [04:23] dpkg-source: extracting alcovebook-sgml in alcovebook-sgml-0.1.2 [04:23] ** WML courtesy of Missing Copyrights Ltd. in alcovebook-sgml-0.1.2 [04:23] yum === Kinnison goes grobbling around in gina [04:25] New bug 2154 for Launchpad/Soyuz: Links to versioned builddeps can be broken, even with complete and correct package data [04:25] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2154 [04:25] Kinnison: that's aclovebook-sgml's problem AFAICR [04:27] elmo; yeah, I've worked out what the message means now :-) [04:31] Is there a known issue with kdetoys? === debonzi back in some minutes.. see you [04:41] stub, spiv: Presumably I have to get rid of all this noise: http://paste.husk.org/1903 so that I can merge my changes with pqm, correct? [04:42] Do other people see that output when running the tests with "python test.py -f"? [04:44] You certainly have to fix ProgrammingError: ERROR: database "launchpad_ftest" is being accessed by other users [04:44] probably by not being connected to the db anywhere [04:44] yeah [04:44] I'd have thought so :P [04:45] I'm hoping I'm not the only one seeing that though. [04:45] Kinnison: Can you do a quick "python test.py -f" from $LAUNCHPAD_DIR to confirm that you see it too? [04:45] one tic [04:45] thanks [04:46] +++ Time passes... [04:46] indeed, in. deed. [04:47] s,\,,., [04:47] I get differences [04:47] oddness [04:47] hm, that sucks [04:47] you should still see that db error though [04:49] not yet I haven't [04:49] BradB: The 'being accessed by other users' error is triggered by the proceeding test generally. I've been trying to make it impossible, but it is really painful :-( [04:49] Ran 38 tests in 196.292s [04:49] FAILED (failures=2) [04:49] both of those are the "differences" [04:49] stub: proceeding or preceeding ? [04:50] preceeding === stub is having a bad speling knight [04:50] stub: I would have thought it's because tearDown doesn't disconnect properly. [04:51] The tear down is probably failing (I think it does it silently - had that fixed in a branch), because there are other connections open so it can't drop the db. [04:52] This is the only process talking to the db, and, of course, the first story gets setup fine it appears; it's only the second one that causes the (horribly-named) ProgrammingError. === Kinnison decides that he needs a brain-break === Kinnison goes to dismantle and bathe his new keyboard [04:53] I think it is because the z3 functional test stuff doesn't really tear everything down that it should, so database connections are not being dropped. Not quite sure. Hmm.. === BradB looks into it [04:56] BradB: Yer - tearDown silently fails. You want me to fix it in canonical/ftests/pgsql.py ? [04:58] I think it's in PgTestCase [04:58] it does: con = psycopg.connect('dbname=%s' % self.template) [04:59] instead of using self.connect, which keeps track of connections in self._cons. [04:59] yes, but it is explicitly closing the connection at the end (I hope) [04:59] I'll fix it, because it's what I'm working on anyway (i.e. being able to land my Malone forcefield.) [05:00] stub: It closes down all the self._cons in tearDown :) [05:00] which i expect is empty, due to the reason above. [05:00] ok. Just need to detect if an exception is raised during the last attempt and not to suppress it. [05:01] BradB: Check the finally clause - it is explicitly being closed. No need to keep it around and close it laster. [05:02] stub: that's if an error occurrs during setup though. [05:02] I want an error to *not* *occurr* during setup. :) [05:03] By closing it correctly in tearDown. [05:03] eh? [05:03] this is what i mean: [05:03] > /Users/bradb/launchpad/lp/lib/canonical/ftests/pgsql.py(95)tearDown() [05:03] -> for con in self._cons: [05:03] (Pdb) self._cons [05:03] [] [05:04] self._cons should contain the connections to close, but it's empty, because setUp isn't calling self.connect (but instead calling psycopg directly, and thus not tracking open cons in self._cons.) [05:04] yes, but there is no need to store it in self._cons because setUp is closing it already. [05:05] stub: only if an error occurred. [05:05] The finally: clause will always be called, no matter what happens. [05:05] er, yeah, wait [05:06] i guess self._cons is a dead chicken then [05:07] The issue I am aware of that needs to be fixed in the trunk is if an exception is raised in the 100th attempt at creating or dropping the database, it silently fails. Needs an 'if i == 99: raise' added. [05:07] red herring :) [05:09] how does a functional test connect to the db? [05:09] I want to get all the connections spawned from the Z3 machinery in self._cons, which works, but causes other problems. Wasted way too much time on that :-( [05:10] standard Z3 mechanisms - zapi.getUtility(IZopeDatabaseAdapter, 'launchpad'), sqlos magic to set _connection attributes on the SQLOS classes. [05:10] Some of them seem to be using initZopeless too, which might cause issues. [05:11] I don't get how any checkins are being allowed with this ProgrammingError being raised. === stub wonders why his tests are still running [05:11] Maybe you have an LP instance also running? [05:12] I think I hit ctrl-S in that window ;) [05:14] BradB: got a minute? [05:15] lulu: sure [05:15] BradB: I created a member account on the site [05:16] It isn't giving me an editing option for a published item - https://www.ubuntulinux.org/support/local [05:16] plone help centre "documentation" is fine [05:16] lulu: it wouldn't. you can't edit published content (though /possibly/ managers can, i can't remember.) [05:17] you can retract it to make it visible, and then edit it. [05:17] seems to apply to documents in the ubuntu workflow [05:18] nope - all published and visible pages are editable by the member. [05:18] only locked pages are non-editable. [05:18] it used to work - not anymore. [05:18] published pages aren't editable. [05:18] could you check this for me please? [05:18] you have to retract them first, then edit them. [05:19] yes - once retracted, it's in visible state [05:19] that's what locked prevents. you can't "retract" locked pages. [05:19] lulu: correct, and then you can edit it. [05:19] but in visible state - you still can't edit. [05:19] it a bug :o) [05:19] oh, you were referring to a published doc above, but if you can't edit visible then yeah, that's a problem [05:19] which "visible" doc can't you edit? [05:20] yup! that's what I'm saying :o) [05:20] any published to visible state docs [05:20] Documentation area is fine - the Plone Help Centre workflow. [05:21] something must've changed in the Ubuntu workflow. [05:21] i can't see anything wrong so far, do you have a link/ [05:22] the page you're looking at would be fine, if it isn't working the way you expect. [05:22] https://www.ubuntulinux.org/support/local [05:23] what's not working there? :) [05:23] when you retract it, it goes to visible, but doesn't allow u to edit it, and it should [05:23] you are logged in as a member, not a manager right? [05:24] as a member yep...just verifying something quickly [05:24] tab options are contents, view and sharing. [05:24] missing the vital edit tab! :o) [05:26] hm, that's mildly frightening, particularly since it's been ages since i touched that workflow === BradB checks the security settings [05:31] oh, well, either this wasn't tested thoroughly enough, or somebody changed ubuntu_workflow recently, because it's indeed config'd here to not allow normal members to edit on visible [05:31] lulu: has anyone done anything whatsoever to ubuntu_workflow at all in the last few weeks? [05:32] BradB: not as far as I know, but we have had plone work done on cacheing - I can get hold of Vika and see if she changed anything. Shouldn't have. [05:33] BradB: we did test that exact option thoroughly when we made the change. [05:33] that's what i thought; i'm confused as to why i'm seeing here that it's explicitly turned off. === BradB turns it back on [05:34] mmmm - ok - I'll ask Vika [05:34] thanks :o) [05:36] whew, it's taking a bit of time to publish...:) there we go. should be fine now. === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [05:38] yes - thanks :o) phew [05:38] no prob ;) [05:38] stub: do you have a quick idea for how to not-raise that ProgrammingError? [05:41] stub: It seems to me that setUp isn't smart enough to close all connections opened by instances of classes that derive from it, but it probably should be that smart. [05:42] Hmm. https://launchpad.ubuntu.com/malone/bugs/+new doesn't seem to sort the source package drop-down box? [05:42] spiv: Perhaps not. File the bug! :P [05:42] Ok :) [05:42] In Malone, of course. ;) thanks. [05:42] Of course ): [05:42] :) [05:42] heh [05:44] Hmm. I'm a little confused/overwhelmed by the Title/Summary/Description fields in Malone. [05:44] spiv: They're too much, I know. [05:44] It seems to be asking me to enter the same information three times :) [05:44] BradB: It seems to be the connections created by the Z3 machinery that are the issue. In a branch I was working on, I'd actually overridden psycopg.connect to keep track of all connections being created so I could tear them down. [05:44] It sound just be title and desc, of course, but Mark seemed to like all three. I don't know how long that'll last :) === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [05:44] s/sound/should/ [05:45] stub: Why not have self.connect do that in the test case, like before? [05:45] I'd given up on it on Friday - was hoping to tackle it again with a fresh brain start of this week (which is when I wake up tomorrow, thanks to a double public holiday) [05:45] ah, hehe === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad [05:46] spiv: It probably be worth reporting a bug on the title/summary/desc thing too, IMHO. [05:46] Whee! Ok. [05:47] Hmm. Apparently I'm the "owner" of that bug I just submitted. [05:48] yeah, you would be. I just fixed the code to make it that way. [05:48] There are screens which then allow you to look at all the bugs you reported. [05:48] spiv: owner != assignee [05:50] stub: Sure. But what is it? :) [05:50] spiv: the owner created the bug. the assignee will fix it. [05:51] And why is it worth advertising on the summary page. [05:51] heh [05:51] Why not call the a "creator" or "submitter" then? [05:51] submitter would be the best name, perhaps. [05:52] If I "own" something, particularly so publically (i.e. on the main summary), I feel like I'm apparently responsible to do something for it. [05:52] When in my ideal world I submit a bug and forget about it ;) [05:52] hehe [05:53] The column in the database is 'owner', since that has a meaning similar to all the other owner columns. Should probably be displayed as something a little more user friendly ;) [05:53] the things you own end up owning you! [05:53] stub: Agreed! Shall I file another bug? :) === spiv does [05:54] stub: By the way, I guess the reason why checkins are being allowed to happen in spite of this ProgrammingError, is because *I'm* the one who rebelliously created a new "story". [05:54] And it's only by having more than one story that this bug becomes apparent. [05:54] BradB: You happy playing with the test suite? I'm off to bed. If you want, mirror your branch to chinstrap and I can play with it tomorrow. [05:54] BradB: Yup. [05:55] Actually - nope. [05:55] stub: I might as well do so. I need to grok, fix, and land. [05:55] stub: !? [05:55] I get the same problem with a single story [05:55] eeek [05:55] Which is stoopid, because the tests should be passing or else the checkins fail. [05:55] and they do.... [05:55] i just got a failure email yesterday from test failures [05:56] which is why i couldn't land the malone forcefield [05:57] stuart.bishop@canonical.com/launchpad--fixdbtests--0 might have something useful for you (screwing around with harness.py and pgsql.py trying to bulletproof the harnesses, but just causing more trouble...) [05:57] heh [05:58] ok, i'll take a look if i get stuck [05:59] Night all. Meeting tomorrow! [05:59] yep, later [06:07] ciao === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad [06:07] kiko: Your email about the views missed the 'CREATE VIEW' lines, so I have no idea what names to call them! === debonzi [~debonzi@200.158.100.251] has joined #launchpad [06:13] stub, they did? gosh. [06:13] stub, I'll resend. [06:14] woo, python test.py -vvf rocks === ddaa sees no -f option in man python [06:16] stub, resent :-( [06:16] it's an option to test.py [06:16] what about --vvtf [06:17] and it's a nice pun, too :-) [06:17] Thinking of which... [06:17] Hmm, no new daily wtf yet. [06:18] what's that? [06:19] http://thedailywtf.com/ [06:19] Can I put a vote in for not naming views VFoo [06:19] please? [06:19] ddaa: A recent beauty: http://thedailywtf.com/archive/2004/10/25/2882.aspx [06:19] Kinnison, sure, as long as you have a rationale and a suggestion. [06:20] kiko: rationale: Polish notation sucks; it's clear from usage what is a view and what isn't. Suggestion: Call it Foo instead [06:20] s/Polish/Hungarian/ [06:20] Kinnison, no, it's not clear from the usage. [06:20] Kinnison: I'm not sure about "it's clear from usage what is a view and what isn't." [06:20] I am tired :-) [06:20] it's *not* at all. [06:20] The point of views is that they're used the same. [06:20] it's actually *very* easy to confuse with a real table given SQLObject's transparency === Kinnison hands you the docstring :-) [06:21] That might be an argument in favour of naming them the same, though :) [06:21] look [06:21] Given the FooTable -> IFooTable mapping for the interface, are you doing VFoo -> IVFoo? [06:21] the only place the view name appears is in the _table attribute of the SQLObject class [06:21] it's a little hint [06:22] there is no IVFoo [06:22]