[12:32] <kiko> spiv, BradB: ping?
[12:44] <BradB> yo
[12:44] <kiko> BradB, apart from twisted, what options do we have for good scalable xmlrpc servers in python?
[12:44] <kiko> BradB, or is the question really "why anything but twisted?" :)
[12:44] <BradB> 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] <kiko> I reckon spiv knows but won't tell us.
[12:52] <spiv> Hello.
[12:52] <stub> kiko: The one that ships with the stanard Python library scales pretty well too (but not as well as twisted).
[12:52] <spiv> I've no idea about good non-Twisted options for XML-RPC :)
[12:52] <kiko> spiv, stub: so it would be twisted, zope and the PSL server?
[12:52] <spiv> Those are the ones I know of, yeah.
[12:52] <BradB> Zope 3 supports XML-RPC.
[12:52] <kiko> yeah, I just don't know how good it is. but thanks!
[12:52] <BradB> it's all about zope 3
[12:52] <stub> 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] <stub> skunkweb..
[12:52] <kiko> hmmm
[12:52] <stub> Ahhh... I thought it was just my working branch that had the batch problem - how did that get past pqm???
[12:52] <stub> hmm.... need to debug the test runner... all tests should be running.... :-P
[12:52] <BradB> i think my next checkin will spam root@localhost on chinstrap. oh well.
[12:53] <stub> BradB: Might be worth setting that to nobody@example.com or something so elmo doesn't beat you up ;)
[12:54] <BradB> i wouldn't have thought it'd be a good idea to spam example.com, but i could be wrong
[12:54] <stub> spiv: You want I do the db thing now, or in 14 or 15 hours?
[12:55] <stub> 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] <BradB> yeah, i know
[12:56] <BradB> but i wouldn't have thought delivering mail there was a good idea
[12:56] <BradB> eeeg, this mail'll add up though,
[12:57] <stub> Oohh... would be fine except our errors-to is still hardcoded to nobody@example.com :-P
[12:57] <stub> elmo: ping
[12:58] <BradB> in any case, shit, got a failed test
[12:59] <BradB> paste coming up:
[12:59] <BradB> /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] <BradB>   warnings.warn("Something tried to set a _connection.  Ignored.")
[12:59] <BradB> Exception exceptions.AttributeError: "'ConnectionDescriptor' object has no attribute 'cache'" in <bound method Transaction.__del__ of <sqlobject.dbconnection.Transaction object at 0x41b60b8c>> ignored
[01:00] <stub> That isn't actually a failing test - I suspect that is a succeeding test that happens to be triggering a warning.
[01:00] <BradB> 6 failures, 1 error, aiieee
[01:02] <stub> 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] <BradB> i've got them ordered
[01:02] <stub> 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] <BradB> 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] <BradB> ah
[01:03] <stub> Page tests should be fine now. Even have stories so they don't tread on each others toes :-)
[01:04] <BradB> i made a new "story" called malone
[01:10] <stub> 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] <spiv> stub: Hmm, now is fine, but not much later or I'll be asleep :)
[01:16] <stub> spiv: ok. Just killing the server now. Will be down for 5/10 mins tops.
[01:17] <stub> lifeless: ping. Doing emperor upgrade now.
[01:18] <lifeless> great
[01:18] <spiv> stub: Ok.
[01:27] <stub> spiv, lifeless: back up
[01:28] <spiv> Gar.
[01:28] <stub> justdave: Morning.
[01:28] <spiv> Not fixed :(
[01:28] <spiv> Oh well, at least I can restart it manually in this case.
[01:28] <spiv> Damn.
[01:28] <elmo> stub: ?
[01:29] <spiv> stub: Thanks.
[01:29] <stub> 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] <stub> 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] <stub> bounces@canonical.com and nobody@canonical.com?
[01:33] <spiv> stub: Well, Twisted's db access all runs in threads anyway, so it's blocking too.
[01:33] <spiv> (because DB-API 2.0 doesn't give you any other choice...)
[01:34] <spiv> 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] <stub> 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] <spiv> Heh.
[01:38] <spiv> grep -v is your friend ;)
[01:38] <stub> that would be the authserver trying to join with the EmailAddress table...
[01:39] <spiv> Heh.  I suppose that's a hint ;)
[01:40] <elmo> stub: mm, ok
[01:41] <stub> 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] <elmo> err, WTF
[01:42] <elmo> bradb?
[01:42] <spiv> I don't think it is, but I can fix that while I'm fixing the join warning.
[01:42] <BradB> elmo: sorry about the spam dude.
[01:42] <BradB> it would have been worth it if my changes actually landed though.
[01:43] <elmo> BradB: no, not that, please read your mail - I just sent you something
[01:45] <BradB> 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] <elmo> I would have written it off, but the guys a DD
[01:45] <elmo> still very happy for it to be anything but what he claims...
[01:50] <BradB> it'd be nice if he gave his username
[01:53] <BradB> 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] <elmo> ok, thanks for checking, I'll reply and ask him for more info, in case he has discovered some leet back door
[01:57] <BradB> an account with his email address has the roles: ('Member', 'Authenticated')
[01:57] <BradB> (which is normal, of course )
[01:57] <elmo> does plone have the equvalent of RecentChanges?  i.e. can we keep track of what's changing?
[01:58] <BradB> 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] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [authserver]  JOIN explicitly, and use lower(EmailAddress.email) (patch-722)
[02:10] <spiv> stub: I'll update the authserver with that tomorrow, when I'm actually awake :)
[02:10] <stub> yup. its not urgent.
[02:14] <stub> 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] <spiv> Hmm.  You mean creating bad Person.names?
[02:15] <stub> Yup
[02:16] <stub> 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] <spiv> Have there been recent changes to the nickname generation code?  The authserver might have an old version.
[02:16] <spiv> (The deployed authserver, I mean)
[02:17] <spiv> The authserver uses canonical.foaf.nickname to generate names from email addresses.
[02:18] <stub> 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] <spiv> Ah.
[02:18] <stub> k. I'll stick in a bugzilla bug to update canonical.foaf.nickname
[02:19] <stub> erm... or that should be a malone-dogfood bug
[02:20] <stub> The url to which has completely slipped my mind... :-(
[02:35] <elmo> BradB|away: yeah, operator-not-understanding error, meh
[02:43] <stub> Can't add a bug on dogfood :-(
[02:46] <dilys> New bug 2151 for Launchpad/Launchpad: generate nickname failing with sql exceptions
[02:46] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2151
[02:48] <dilys> New bug 2152 for Launchpad/Malone: Missing product-assignment in create-a-bug form
[02:48] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2152
[02:52] <dilys> New bug 2153 for Launchpad/Malone: create-a-bug and too many required fields
[02:52] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2153
[05:10] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Give warning if running with add_missing_from=true (patch-723)
[05:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: New schema baseline (patch-724)
[06:01] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: tidy up code to build with stricter CFLAGS (patch-57)
[06:03] <dilys> Merge to thelove@canonical.com/hackerlab--devo--1.1: tidy up code to build with stricter CFLAGS (patch-2)
[06:13] <dilys> Merge to thelove@canonical.com/bazaar-debian--debian--1.0: merge stricter build flags (patch-4)
[08:28] <dilys> Merge to thelove@canonical.com/bazaar-debian--debian--1.0: fix borked version number in changelog (patch-5)
[10:44] <Kinnison> Marning
[11:22] <Kinnison> elmo: what time of day does mawson update the archive?
[11:47] <elmo> Kinnison: err, 'now'? ;-) I still haven't tracked down what's killing the daily sync
[11:47] <Kinnison> elmo: *grin* okay; thanks dude
[12:35] <Kinnison> 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] <elmo> sure
[01:40] <Kinnison> only a couple of days late :-)
[01:43] <Kinnison> hey debonzi
[01:44] <Kinnison> good news; elmo updated mawson's mirror earlier and gina is chugging through again
[01:45] <Kinnison> dsilvers@petitemort:~$ hive list
[01:45] <Kinnison>     library-utf : UTF-8 enable the librarian protocol
[01:45] <Kinnison> Hmm; shall I carry on with that?
[01:46] <debonzi> Kinnison, yo
[01:54] <lulu> debonzi: hiya!
[01:56] <lulu> 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] <debonzi> hi lulu :)
[01:57] <lulu> debonzi: :o)  ^
[01:57] <debonzi> lulu, we have one irc channel for launchpad for cprov, kiko, salgado and me
[01:58] <debonzi> lulu, AFAIK there is no plan for ubuntu mail list/IRC channel up to now, but we can set it up :)
[01:58] <lulu> 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] <lulu> an IRC channel as a first and then invite people to it, and appoint someone to dot he traffic for it.
[02:00] <debonzi> lulu, cool :) how can I help?
[02:00] <Kinnison> lulu: can you point silbs at her IRC window?
[02:01] <lulu> set up the IRC channel and let me know what it is....!
[02:01] <lulu> kinnison: will do.
[02:01] <debonzi> lulu, right.. Ill do
[02:19] <debonzi> 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?
[02:37] <lulu> debonzi: what other options are there from your experience?
[02:48] <debonzi> 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] <debonzi> lulu, wich one sounds better to you?
[02:58] <lulu> 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] <lifeless> ubuntu_portugese_not_portugal
[02:59] <debonzi> lulu, yes pt, but it is also an abbreviation for Portugual I think 
[02:59] <debonzi> lulu, if you think ubuntu_portugese is ok let do in that way
[03:00] <BradB> morning
[03:00] <lulu> debonzi: would having -pt offend Brazillian Portugese speakers?
[03:00] <lulu> BradB: morning!
[03:00] <BradB> hi lulu :)
[03:01] <debonzi> lulu, I don't think so
[03:02] <debonzi> lulu, we can also leave on the topic something like (pt=portugese)!= portugal ;-)
[03:03] <lulu> debonzi: ok - let's go for that then. Then you need to get your Brazilian community on there! :o) thanks!
[03:03] <debonzi> lulu, right.. ;-)
[03:03] <lulu> debonzi: I'll add it to the local language page.
[03:04] <debonzi> cool
[03:10] <carlos> debonzi: we use #ubuntu-es for Spanish not Spain and it's ok for all people
[03:11] <debonzi> carlos, right.. thats that I did.. #ubuntu-pt ... I think its not a problem too ;-)
[03:12] <debonzi> s/that/what
[03:15] <Kinnison> nickname.NicknameGenerationError: martin@v.loewis.de is not a valid email address
[03:15] <Kinnison> frazzle wazzle grumble mumble
[03:18] <Kinnison> lulu: See; when I'm having a bad time; the words are 'frazzle wazzle' and 'grumble mumble'. Sometimes 'groan' and/or 'complain'
[03:30] <Kinnison> Are we meant to have two run_launchpad.py instances on mawson?
[03:30] <Kinnison> aah; one belongs to mr dafydd
[03:31] <lulu> kinnison: I am so impressed with you :o)
[03:32] <lulu> kinnison:  ;)  control of words is what I meant!
[03:50] <Kinnison> rah; gina completed
[03:52] <Kinnison> Can someone with an understanding of the web-app play with it and tell me how that import looks?
[03:52] <Kinnison> 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] <spiv> Kinnison: Looks good judging from some trivial poking around :)
[04:07] <Kinnison> spiv: rock
[04:08] <Kinnison> 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] <Kinnison> eww, it's poorly formatted, let me re-do that
[04:08] <spiv> "View Binary Packages List  (14352 Packages)"
[04:08] <spiv> :)
[04:09] <Kinnison> does that sound right for hoary?
[04:09] <spiv> I dunno :)
[04:09] <spiv> Glancing at the actual list, it looks sane, I think.
[04:09] <spiv> I presume this includes universe?
[04:09] <Kinnison> yes
[04:09] <Kinnison> but not multiverse
[04:10] <spiv> Hmm, the description still doesn't deal with multiple paragraphs well.
[04:10] <spiv> (see e.g. https://launchpad.ubuntu.com/soyuz/distros/ubuntu/src/hoary/bicyclerepair)
[04:11] <Kinnison> that's up to the app to process and render the description properly
[04:12] <spiv> Yeah.
[04:13] <Kinnison> blergh; how do I get python to autoflush stdout?
[04:14] <spiv> What's wrong with calling sys.stdout.flush()?
[04:15] <spiv> It's line buffered by default, iirc.
[04:15] <Kinnison> too many places where "print" is called
[04:15] <Kinnison> it's not line-buffered if stdout is a pipe
[04:15] <Kinnison> I need it to be
[04:15] <spiv> Or run python with -u
[04:16] <Kinnison> hmm; I'll try that; thanks
[04:16] <Kinnison> hurrah; much better
[04:19] <Kinnison> now the logs in /tmp should be slightly more temporally correlated
[04:23] <Kinnison> - Evaluating alcovebook-sgml (main, 0.1.2-5ubuntu1)
[04:23] <Kinnison> dpkg-source: extracting alcovebook-sgml in alcovebook-sgml-0.1.2
[04:23] <Kinnison>         ** WML courtesy of Missing Copyrights Ltd. in alcovebook-sgml-0.1.2
[04:23] <Kinnison> yum
[04:25] <dilys> New bug 2154 for Launchpad/Soyuz: Links to versioned builddeps can be broken, even with complete and correct package data
[04:25] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2154
[04:25] <elmo> Kinnison: that's aclovebook-sgml's problem AFAICR
[04:27] <Kinnison> elmo; yeah, I've worked out what the message means now :-)
[04:31] <Kinnison> Is there a known issue with kdetoys?
[04:41] <BradB> 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] <BradB> Do other people see that output when running the tests with "python test.py -f"?
[04:44] <Kinnison> You certainly have to fix ProgrammingError: ERROR:  database "launchpad_ftest" is being accessed by other users
[04:44] <Kinnison> probably by not being connected to the db anywhere
[04:44] <BradB> yeah
[04:44] <BradB> I'd have thought so :P
[04:45] <BradB> I'm hoping I'm not the only one seeing that though.
[04:45] <BradB> Kinnison: Can you do a quick "python test.py -f" from $LAUNCHPAD_DIR to confirm that you see it too?
[04:45] <Kinnison> one tic
[04:45] <BradB> thanks
[04:46] <Kinnison> +++ Time passes...
[04:46] <BradB> indeed, in. deed.
[04:47] <BradB> s,\,,.,
[04:47] <Kinnison> I get differences
[04:47] <Kinnison> oddness
[04:47] <BradB> hm, that sucks
[04:47] <BradB> you should still see that db error though
[04:49] <Kinnison> not yet I haven't
[04:49] <stub> 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] <Kinnison> Ran 38 tests in 196.292s
[04:49] <Kinnison> FAILED (failures=2)
[04:49] <Kinnison> both of those are the "differences"
[04:49] <Kinnison> stub: proceeding or preceeding ?
[04:50] <stub> preceeding
[04:50] <BradB> stub: I would have thought it's because tearDown doesn't disconnect properly.
[04:51] <stub> 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] <BradB> 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.
[04:53] <stub> 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..
[04:56] <stub> BradB: Yer - tearDown silently fails. You want me to fix it in canonical/ftests/pgsql.py ?
[04:58] <BradB> I think it's in PgTestCase
[04:58] <BradB> it does: con = psycopg.connect('dbname=%s' % self.template)
[04:59] <BradB> instead of using self.connect, which keeps track of connections in self._cons.
[04:59] <stub> yes, but it is explicitly closing the connection at the end (I hope)
[04:59] <BradB> I'll fix it, because it's what I'm working on anyway (i.e. being able to land my Malone forcefield.)
[05:00] <BradB> stub: It closes down all the self._cons in tearDown :)
[05:00] <BradB> which i expect is empty, due to the reason above.
[05:00] <stub> ok. Just need to detect if an exception is raised during the last attempt and not to suppress it.
[05:01] <stub> BradB: Check the finally clause - it is explicitly being closed. No need to keep it around and close it laster.
[05:02] <BradB> stub: that's if an error occurrs during setup though.
[05:02] <BradB> I want an error to *not* *occurr* during setup. :)
[05:03] <BradB> By closing it correctly in tearDown.
[05:03] <stub> eh?
[05:03] <BradB> this is what i mean:
[05:03] <BradB> > /Users/bradb/launchpad/lp/lib/canonical/ftests/pgsql.py(95)tearDown()
[05:03] <BradB> -> for con in self._cons:
[05:03] <BradB> (Pdb) self._cons
[05:03] <BradB> [] 
[05:04] <BradB> 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] <stub> yes, but there is no need to store it in self._cons because setUp is closing it already.
[05:05] <BradB> stub: only if an error occurred.
[05:05] <stub> The finally: clause will always be called, no matter what happens.
[05:05] <BradB> er, yeah, wait
[05:06] <BradB> i guess self._cons is a dead chicken then
[05:07] <stub> 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] <stub> red herring :)
[05:09] <BradB> how does a functional test connect to the db?
[05:09] <stub> 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] <stub> standard Z3 mechanisms - zapi.getUtility(IZopeDatabaseAdapter, 'launchpad'), sqlos magic to set _connection attributes on the SQLOS classes.
[05:10] <stub> Some of them seem to be using initZopeless too, which might cause issues.
[05:11] <BradB> I don't get how any checkins are being allowed with this ProgrammingError being raised.
[05:11] <BradB> Maybe you have an LP instance also running?
[05:12] <stub> I think I hit ctrl-S in that window ;)
[05:14] <lulu> BradB: got a minute?
[05:15] <BradB> lulu: sure
[05:15] <lulu> BradB: I created a member account on the site
[05:16] <lulu> It isn't giving me an editing option for a published item - https://www.ubuntulinux.org/support/local
[05:16] <lulu> plone help centre "documentation" is fine
[05:16] <BradB> lulu: it wouldn't. you can't edit published content (though /possibly/ managers can, i can't remember.)
[05:17] <BradB> you can retract it to make it visible, and then edit it.
[05:17] <lulu> seems to apply to documents in the ubuntu workflow 
[05:18] <lulu> nope - all published and visible pages are editable by the member.
[05:18] <lulu> only locked pages are non-editable.
[05:18] <lulu> it used to work - not anymore.
[05:18] <BradB> published pages aren't editable.
[05:18] <lulu> could you check this for me please?
[05:18] <BradB> you have to retract them first, then edit them.
[05:19] <lulu> yes - once retracted, it's in visible state
[05:19] <BradB> that's what locked prevents. you can't "retract" locked pages.
[05:19] <BradB> lulu: correct, and then you can edit it.
[05:19] <lulu> but in visible state - you still can't edit.
[05:19] <lulu> it a bug :o)
[05:19] <BradB> oh, you were referring to a published doc above, but if you can't edit visible then yeah, that's a problem
[05:19] <BradB> which "visible" doc can't you edit?
[05:20] <lulu> yup! that's what I'm saying :o)
[05:20] <lulu> any published to visible state docs
[05:20] <lulu> Documentation area is fine - the Plone Help Centre workflow.
[05:21] <lulu> something must've changed in the Ubuntu workflow.
[05:21] <BradB> i can't see anything wrong so far, do you have a link/
[05:22] <BradB> the page you're looking at would be fine, if it isn't working the way you expect.
[05:22] <lulu> https://www.ubuntulinux.org/support/local
[05:23] <BradB> what's not working there? :)
[05:23] <lulu> when you retract it, it goes to visible, but doesn't allow u to edit it, and it should
[05:23] <lulu> you are logged in as a member, not a manager right?
[05:24] <BradB> as a member yep...just verifying something quickly
[05:24] <lulu> tab options are contents, view and sharing.
[05:24] <lulu> missing the vital edit tab! :o)
[05:26] <BradB> hm, that's mildly frightening, particularly since it's been ages since i touched that workflow
[05:31] <BradB> 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] <BradB> lulu: has anyone done anything whatsoever to ubuntu_workflow at all in the last few weeks?
[05:32] <lulu> 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] <lulu> BradB: we did test that exact option thoroughly when we made the change.
[05:33] <BradB> that's what i thought; i'm confused as to why i'm seeing here that it's explicitly turned off.
[05:34] <lulu> mmmm - ok - I'll ask Vika
[05:34] <lulu> thanks :o)
[05:36] <BradB> whew, it's taking a bit of time to publish...:) there we go. should be fine now.
[05:38] <lulu> yes - thanks :o) phew 
[05:38] <BradB> no prob ;)
[05:38] <BradB> stub: do you have a quick idea for how to not-raise that ProgrammingError?
[05:41] <BradB> 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] <spiv> Hmm.  https://launchpad.ubuntu.com/malone/bugs/+new doesn't seem to sort the source package drop-down box?
[05:42] <BradB> spiv: Perhaps not. File the bug! :P
[05:42] <spiv> Ok :)
[05:42] <BradB> In Malone, of course. ;) thanks.
[05:42] <spiv> Of course ):
[05:42] <spiv> :)
[05:42] <BradB> heh
[05:44] <spiv> Hmm.  I'm a little confused/overwhelmed by the Title/Summary/Description fields in Malone.
[05:44] <BradB> spiv: They're too much, I know.
[05:44] <spiv> It seems to be asking me to enter the same information three times :)
[05:44] <stub> 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] <BradB> 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 :)
[05:44] <BradB> s/sound/should/
[05:45] <BradB> stub: Why not have self.connect do that in the test case, like before?
[05:45] <stub> 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] <BradB> ah, hehe
[05:46] <BradB> spiv: It probably be worth reporting a bug on the title/summary/desc thing too, IMHO.
[05:46] <spiv> Whee! Ok.
[05:47] <spiv> Hmm.  Apparently I'm the "owner" of that bug I just submitted.
[05:48] <BradB> yeah, you would be. I just fixed the code to make it that way.
[05:48] <BradB> There are screens which then allow you to look at all the bugs you reported.
[05:48] <stub> spiv: owner != assignee
[05:50] <spiv> stub: Sure.  But what is it? :)
[05:50] <BradB> spiv: the owner created the bug. the assignee will fix it.
[05:51] <spiv> And why is it worth advertising on the summary page.
[05:51] <BradB> heh
[05:51] <spiv> Why not call the a "creator" or "submitter" then?
[05:51] <BradB> submitter would be the best name, perhaps.
[05:52] <spiv> 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] <spiv> When in my ideal world I submit a bug and forget about it ;)
[05:52] <BradB> hehe
[05:53] <stub> 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] <BradB> the things you own end up owning you!
[05:53] <spiv> stub: Agreed!  Shall I file another bug? :)
[05:54] <BradB> 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] <BradB> And it's only by having more than one story that this bug becomes apparent.
[05:54] <stub> 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] <stub> BradB: Yup.
[05:55] <stub> Actually - nope.
[05:55] <BradB> stub: I might as well do so. I need to grok, fix, and land.
[05:55] <BradB> stub: !?
[05:55] <stub> I get the same problem with a single story
[05:55] <BradB> eeek
[05:55] <stub> Which is stoopid, because the tests should be passing or else the checkins fail.
[05:55] <BradB> and they do....
[05:55] <BradB> i just got a failure email yesterday from test failures
[05:56] <BradB> which is why i couldn't land the malone forcefield
[05:57] <stub> 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] <BradB> heh
[05:58] <BradB> ok, i'll take a look if i get stuck
[05:59] <stub> Night all. Meeting tomorrow!
[05:59] <BradB> yep, later
[06:07] <kiko> ciao
[06:07] <stub> kiko: Your email about the views missed the 'CREATE VIEW' lines, so I have no idea what names to call them!
[06:13] <kiko> stub, they did? gosh.
[06:13] <kiko> stub, I'll resend.
[06:14] <BradB> woo, python test.py -vvf rocks
[06:16] <kiko> stub, resent :-(
[06:16] <kiko> it's an option to test.py
[06:16] <ddaa> what about --vvtf
[06:17] <ddaa> and it's a nice pun, too :-)
[06:17] <spiv> Thinking of which...
[06:17] <spiv> Hmm, no new daily wtf yet.
[06:18] <ddaa> what's that?
[06:19] <spiv> http://thedailywtf.com/
[06:19] <Kinnison> Can I put a vote in for not naming views VFoo
[06:19] <Kinnison> please?
[06:19] <spiv> ddaa: A recent beauty: http://thedailywtf.com/archive/2004/10/25/2882.aspx
[06:19] <kiko> Kinnison, sure, as long as you have a rationale and a suggestion.
[06:20] <Kinnison> 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] <Kinnison> s/Polish/Hungarian/
[06:20] <kiko> Kinnison, no, it's not clear from the usage.
[06:20] <spiv> Kinnison: I'm not sure about "it's clear from usage what is a view and what isn't."
[06:20] <Kinnison> I am tired :-)
[06:20] <kiko> it's *not* at all.
[06:20] <spiv> The point of views is that they're used the same.
[06:20] <kiko> it's actually *very* easy to confuse with a real table given SQLObject's transparency
[06:21] <spiv> That might be an argument in favour of naming them the same, though :)
[06:21] <kiko> look
[06:21] <Kinnison> Given the FooTable -> IFooTable mapping for the interface, are you doing VFoo -> IVFoo? 
[06:21] <kiko> the only place the view name appears is in the _table attribute of the SQLObject class
[06:21] <kiko> it's a little hint
[06:22] <kiko> there is no IVFoo
[06:22] <kiko> no Python code deals with VFoo
[06:22] <Kinnison> You don't need to give sqlobject an _table attribute if you name your view sensibly :-)
[06:22] <spiv> There's two different issues here... the name in SQL and the name in Python.
[06:22] <kiko> right.
[06:22] <Kinnison> at the sql level they're a view and \d foo can tell you this
[06:23] <ddaa> apparently, sql best practise is to use stupidlylongwindedandabusivelyverbosenames
[06:23] <Kinnison> ddaa: Yep :-)
[06:23] <spiv> I don't feel strongly either way, but I'm leaning slightly towards kiko's position.
[06:23] <Kinnison> ddaa: PublishedSourcePackageRelease.sourcepackagerelease.sourcepackage.sourcepackagename.name
[06:23] <kiko> but at the SQLObject level there is no indication
[06:24] <kiko> and a view is *not* a table, so it would be nice to have that clearly indicated in the SQLObject class
[06:24] <Kinnison> If you remove the indication once you've wrapped it in what programmers deal with from day-to-day; then there's no gain whatsoever in putting it into the database
[06:24] <kiko> huh?
[06:24] <kiko> anyway
[06:24] <kiko> my suggestion is
[06:24] <Kinnison> If you call it 'Foo' in python, then there's no more gain in calling it 'VFoo' in psql than calling it 'Foo' and putting a comment in the class
[06:24] <spiv> Maybe there should be some SQLObject support.  After all, UDPATE doesn't work on views, so SQLObject ideally would disallow assignments to columns on views.
[06:25] <kiko> anyway
[06:25] <kiko> I don't want to be arguing about a single letter for a week
[06:25] <Kinnison> I'm just putting my $0.02 in. Hungarian notation scares and irritates me :-)
[06:25] <kiko> I think it's a nice way to indicate this in a simple way
[06:25] <ddaa> spiv: that wtf is just a public display of what insane lengths VB programmers must go to do stupidly simple things.
[06:25] <spiv> So let's call it FooView, so we're at least arguing about *four* letters ;)
[06:26] <spiv> ddaa: Um, no :)
[06:26] <kiko> we cam
[06:26] <spiv> ddaa: VB has a Round builtin :)
[06:26] <kiko> we can't, spiv, because we already have FooView in our codebase.
[06:26] <spiv> Ah, good point.
[06:26] <kiko> anyway
[06:26] <kiko> as I was saying
[06:27] <kiko> I don't want to argue over a single letter; my suggestion is let it go in and if we decide it is horrible horrible oh my god, a V! then we can remove it. it's two lines.
[06:28] <Kinnison> *sizzle* :-)
[06:28] <kiko> heh
[06:52] <kiko> spiv, what if you implemented these lazy columns?
[06:52] <kiko> I would buy you a DVD of your choice
[06:52] <spiv> kiko: Hmm!
[06:52] <kiko> if you did it by thursday two DVDs
[06:52] <spiv> The thought had occurred, but the DVD of my choice sweetens the deal!
[06:53] <spiv> Hmm.
[06:53] <kiko> bribes are what we need to keep these people moving 
[06:53] <kiko> I mean, the column option is there already..
[06:53] <spiv> I think I'd feel compelled to buy you a beer or two in Spain if you gave me *two* DVDs.  But I'm sure we could both live with that ;)
[06:54] <kiko> a beer in europe costs close to a dvd anyway
[06:54] <kiko> no, that's england.
[06:54] <kiko> anyway, consider my bribe offered
[06:54] <spiv> Ok. :)
[06:55] <spiv> I'm at least convinced now to take a serious look at how hard it would be...
[07:10] <debonzi> Kinnison, do you know who is responsable to merge rocketfuel into launchpad.ubuntu.org ?
[07:13] <Kinnison> debonzi: I think it's anyone; although I think launchpad is current run by BradB so probably him
[07:14] <debonzi> Kinnison, right.. because I can see that it is a little old already
[07:14] <debonzi> Kinnison, Ill ask him when he is back
[07:14] <debonzi> thanks
[07:14] <Kinnison> cool; okay
[07:30] [fg_ubuntu(~fede@82.52.172.47)]  hi! ubuntu guru here
[07:30] [fg_ubuntu(~fede@82.52.172.47)]  ?
[07:32] <lulu> night guys :o)
[07:35] <debonzi> hi BradB, are you the guy merging rocketfuel into launchpad.ubuntu.org?
[07:42] <BradB> debonzi: nope, stub is.
[07:43] <BradB> i just push the big red button
[07:44] <debonzi> BradB, right.. there is some stuff in soyuz that are not available there.. 
[07:44] <BradB> stub would be able to clarify, i think
[07:44] <debonzi> BradB, ok.. thanks
[07:44] <BradB> no prob
[07:47] <kiko> BradB, I still think that spiv's offer is more interesting for this specific need, though yours could be more general and flexible
[07:48] <kiko> it's just simpler -- stuff a lazy=TRUE in the column and that's it
[07:52] <BradB> yeah, that's another way to solve it
[07:52] <BradB> depends on how much time it would take though; my solution is much more general.
[07:52] <BradB> because, for example, what if sometimes you want it lazy, but other times you don't?
[10:21] <spiv> Man, having gnome-terminal crash is annoying.
[10:25] <lifeless> gnome-terminal is annoying, I'm an xterm addict
[10:32] <kiko> I use rxvt.
[10:45] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: This fixes baz ancestry(-graph) --dir DIRNAME (patch-58)
[10:59] <spiv> Ah, seb was able to reproduce my gnomem-terminal crash :)
[11:07] <BradB> when is the app server started for functional page tests?
[11:07] <BradB> (and when is it stopped?)
[11:08] <ddaa> Anyone knows a terminal emulator that's not a painstaking cpu hog, but has tabs and 
[11:08] <ddaa> shiny antialiased fonts?
[11:11] <salgado> ddaa: have you tried konsole?
[11:12] <ddaa> salgado: used to work with kde, before I switched to ubuntu, back in July...
[11:12] <ddaa> I was very much annoyed at konsole too, though I do not remember why.
[11:13] <ddaa> But the general feeling was that gnome-terminal actually was an improvement.
[11:14] <salgado> back in the 2.4 days, it was almost impossible to use the mouse scroll in vim. now it's possible but uses a lot of cpu
[11:15] <salgado> I say, in gnome-terminal
[11:16] <ddaa> Well, I think I'm going to stick with xterm for the few things that need fast scrolling, and gnome-terminal for everything else.
[11:16] <kiko> gnome-terminal takes years to start up :-(
[11:17] <salgado> kiko: but you only need one or two instances of it. each with multiple tabs (wich starts very fast)
[11:18] <kiko> well, you are an ion user..
[11:18] <kiko> but the multiple tabs, gah, I dunno
[11:18] <ddaa> salgado: actually you need only one instance of it.
[11:19] <ddaa> successive runs of the command will use the same process, unless given a specific option, something like --disable-factory
[11:21] <spiv> It's the it's-all-one-instance that makes it so annoying when it crashes :)
[11:21] <lifeless> screen
[11:23] <ddaa> lifeless is the kind of folk that think that the main purpose of a desktop environment is to arrange xterm windows...
[11:25] <lifeless> ddaa: I only use one.
[11:26] <lifeless> which disproves that theory immediately.
[11:26] <lifeless> what I meant was, if you use screen, then when (not if) gnome-terminal crashes, you don't lose anything.
[11:26] <ddaa> lifeless: regarding the taxi weirdness, do you think it would be better keep the current database data for later diagnostic, or would it be better to clean everything and start from a known-sane situation?
[11:26] <ddaa> ha...
[11:26] <ddaa> Good point.
[11:27] <spiv> Well, I've only ever had it crash twice, both the same way, and seb's just reproduced it in a debug build, so I expect upstream will fix it.
[11:27] <lifeless> erm if the logs don't tell you what went on, you won't have much lug diagnosing.
[11:27] <spiv> But yeah, I do use screen for some stuff, which makes the crash a little less painful :)
[11:28] <ddaa> lifeless: okay, then I'll happily trash everything.
[11:41] <carlos> spiv: how do you solve the scroll problem with screen?
[11:41] <carlos> scroll problem == no scroll 
[11:41] <carlos> that's the only problem I have with screen
[11:49] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing is_non_upwards_relative_path so that one can add ..filename files (patch-59)
[11:50] <spiv> carlos: I use screen almost entirely for irc, so irssi does the scrolling :)
[11:50] <spiv> carlos: Aren't there keybindings in screen for scrolling, though?
[11:50] <carlos> spiv: I didn't saw them
[11:50] <spiv> I've seen daf (and others) do it.
[11:50] <carlos> hmm
[11:51] <carlos> I will ask daf then
[11:51] <carlos> our screen's king
[11:51] <carlos> :-D
[11:54] <spiv> carlos: C-a esc starts "copy mode", C-u/C-d will scroll up/down, q will exit copy mode.
[11:54] <spiv> carlos: See the man page for more details :)
[11:54] <carlos> but then you need to activate it explicity
[11:55] <carlos> hmmm
[11:55] <carlos> I will look for a way to activate it by default
[11:55] <carlos> spiv: thanks!
[11:56] <carlos> I'm so stupid sometimes...
[11:56] <carlos> spiv: that does exactly what I need, I don't need to do anything extra
[11:56] <spiv> carlos: The screen man page isn't particularly friendly :)
[11:56] <carlos> thanks
[11:56] <spiv> You're welcome :)
[11:57] <spiv> (I have actually done it before, which helped me look it up this time)
[11:57] <carlos> spiv: I looked at it sometime ago, and I decided that I had better things to do O:-)
[11:57] <spiv> Searching for "scroll" and "page" in the man page doesn't help you very much, unfortunately.
[11:58] <lifeless> spiv: ctrl-A [, then arrows & pgup pgdown
[11:59] <lifeless> oh bah, you knew already. doh
[11:59] <spiv> Heh.
[11:59] <spiv> lifeless: Thanks, though :)