[02:13] <spiv> daf: The vegemite?  Please bring it :)
[04:13] <daf> spiv: will do :)
[07:52] <dilys> New bug 2038 for Launchpad/Database: Desirable sqlobject improvements
[10:26] <limi> oh joy, new arch changes ;)
[10:44] <limi> BradB|London :)
[10:45] <daf> limi!
[10:45] <limi> daf!
[10:45] <limi> how's things?
[10:45] <daf> fine!
[10:45] <daf> how are you?
[10:45] <daf> I hear you've been invading mainland Europe
[10:46] <limi> been down with the flu all weekend, so - recovering ;)
[10:46] <limi> only the nasty cough left
[10:46] <daf> ouch
[10:46] <limi> :] 
[10:46] <daf> how was the conference?
[10:46] <limi> and I sound like Tom Waits
[10:46] <limi> conference was excellent
[10:47] <limi> I saw there were some arch changes, anything I need to know, or update as normal?
[10:48] <daf> I'm not sure, actualyl
[10:48] <daf> I need to work out whether they affect me too
[10:48] <spiv> daf: When will we see you? :)
[10:48] <daf> spiv: sometime this afternoon, I expect
[10:49] <spiv> daf: Chances are you just need to merge the latest rocketfuel.
[10:49] <daf> spiv: I'm meeting Dwayne at 5:30
[10:49] <daf> spiv: right, that's what I thought
[10:51] <stub> limi: If you havn't merged for a few days I don't think you have to worry - just merge as normal
[10:51] <limi> ok, great
[10:52] <limi> where in the world is stub these days?
[10:52] <stub> Melbourne
[10:52] <stub> Which is quite possibly straight down ;)
[10:54] <daf> spiv: how did your travels go?
[10:54] <spiv> Ok, a bit rough :)
[10:54] <spiv> The bus from Bridgend was full.
[11:02] <spiv> And then the tube from Paddington had half the lines blocked due to a faulty train.
[11:04] <daf> urg
[11:10] <stub> BradB|London: Hows the launchpad setup on OSX going?
[11:13] <spiv> And I realised I didn't know the address of the hotel, just that it was near Earl's Court station... thankfully a quick map purchase solved that :)
[11:13] <daf> heh :)
[11:13] <daf> I got a call from Steve at about 6 wondering where you were
[11:17] <dilys> New bug 2039 for Launchpad/Rosetta: write a script for creating PO templates in the database
[11:19] <dilys> New bug 2040 for Launchpad/Rosetta: allow searching for messages and translations within templates
[11:26] <dilys> New bug 2041 for Launchpad/Rosetta: paginate Rosetta projects page
[11:41] <carlos> hi
[11:41] <carlos> lifeless: ping
[11:42] <lifeless> carlos: pong
[11:42] <carlos> lifeless: my last patch is 415
[11:42] <carlos> lifeless: could I do  a normal star-merge?
[11:42] <lifeless> yes
[11:43] <carlos> ok
[11:43] <carlos> thank you
[11:46] <daf> spiv: is Steve around?
[11:50] <cprov> daf: hi daf, yes he is here, do you want to talk with him now ?
[11:52] <daf> cprov: actually, never mind
[11:53] <cprov> daf: sorry I was slow !!! we are having a meeting with mark
[11:54] <daf> cprov: no worries
[11:54] <cprov> daf: ok
[11:58] <dilys> New bug 2042 for Launchpad/Rosetta: PO import should update translation statistics
[12:01] <dilys> Bug 1902 resolved: Can't add an assignee to a bug
[12:04] <limi> SteveA :)
[12:05] <daf> limi: you've seen all the bugs we've assigned to you, right? :)
[12:08] <limi> yup
[12:08] <limi> soon done with the mail catch-up :)
[12:10] <daf> :)
[12:14] <SteveA> hi
[12:14] <daf> hi Steve
[12:17] <dilys> New bug 2043 for Launchpad/Launchpad: make Launchpad development servers run under the auspices of the launchpad user
[01:03] <daf> limi: whoops
[01:04] <daf> limi: we changed our minds -- it's going to be rosetta-users, not rosetta-testers
[01:04] <limi> daf: whoops?
[01:04] <limi> aha
[01:04] <daf> lalo: hi
[01:14] <lalo> yay composite.
[01:20] <lalo> actually I don't
[01:24] <lalo> yay London
[01:36] <limi|llunch> ;)
[01:39] <sabdfl> limi|llunch: when you get back, can you fix #1800 please?
[01:43] <BradB|London> limi|llunch: Were you running launchpad on 10.2.8?
[01:48] <lifeless> lalo: around ?
[01:48] <lalo> I am
[01:48] <lifeless> do you know what you need to do to fix your branch ?
[01:49] <lalo> no
[01:49] <lifeless> ok. First I need to know exactly what you did to cause the problem.
[01:49] <lifeless> it looks like you used an =all file - an advanced feature of tla, rarely needed.
[01:49] <lalo> yeah, I would like to know that too
[01:50] <lalo> no, I didn't even know these files exist
[01:50] <lifeless> did you run tla explict-default at all ?
[01:50] <lalo> nope
[01:51] <lifeless> did you run any third party tla scripts ?
[01:51] <lalo> nope
[01:51] <lifeless> that makes it quite a mystery
[01:51] <lalo> I'd much rather start a new version and work from there. It is quite possible that I won't work on Launchpad anymore after next week, so I don't think it's efficient to waste one morning trying to figure out what went wrong in my tree.
[01:51] <lifeless> we won't waste a morning.
[01:51] <lifeless> about 10 minutes.
[01:52] <lifeless> ok, do this:
[01:52] <lalo> sigh.
[01:52] <lifeless> $ cd your-launchpad-dir
[01:52] <lalo> it is *possible* that my revlib went corrupted.
[01:52] <lifeless> no, its not a misbehaviour on tla
[01:53] <lifeless> this is a specific behaviour that has been enabled by a commit in your tree, for some unknown reason.
[01:53] <lalo> let me fill you in on the history of the problem
[01:53] <lalo> Friday I submitted a merge, and it failed
[01:53] <lalo> when I tried the same merge in my local checkout of rocketfuel, it didn't fail
[01:54] <lifeless> probably one of the random-segfault-on-chinstrap problems.
[01:54] <lalo> then I found that my patch-135 was bogus; if I disabled my revlib, the merge *would* fail locally
[01:55] <lifeless> oh, thats interesting.
[01:55] <lifeless> there are string checks to prevent that, I'd love to know how that occured. are you using NFS ?
[01:55] <lalo> I reverted 135, removed it from the revlib, and committed again; this time the merge succeded both locally and in pqm, *but* it had those bogus add/removes
[01:55] <lalo> no
[01:55] <lalo> no nfs
[01:56] <lifeless> what do you mean when you say 'reverted' ?
[01:56] <lalo> (in fact I didn't remove 135 from the revlib - I removed lalo@canonical.com--2004/launchpad--devel--0 entirely from the revlib and let it rebuild)
[01:58] <lifeless> what do you mean when you say 'reverted' ?
[01:58] <lalo> I removed the revision from my archive and the mirror, then replaced my lp tree with a fresh checkout to get rid of bogus patch-logs
[01:59] <lifeless> ok, future reference: thats called altering history, and you should never ever ever do that.
[01:59] <lifeless> it breaks referential integrity on a global basis.
[01:59] <lalo> sorry, but I don't agree. What's the alternative?
[02:00] <lifeless> its not a matter of agreement. Its a fact about how distributed systems interact. 
[02:00] <lifeless> as for alternative, there are many.
[02:00] <lalo> if I know the revision is bogus, either I revert it or I abandon the version
[02:00] <lifeless> a) tag from the good part of that branch into that branch again,
[02:00] <lifeless> b) tag from the good part of that branch into a different branch.
[02:00] <lifeless> c) cacherev a good version of the same patch.
[02:01] <lalo> I tried c too, before reverting
[02:01] <lifeless> did you ask the arch team about this ?
[02:01] <lifeless> or on #arch ?
[02:01] <lalo> and b is what I did now
[02:01] <lifeless> ok, for b, have you tagged before or after those bogus deletes where added ?
[02:02] <lalo> neither. I tagged from rocketfuel and completely abandoned my old version.
[02:02] <lifeless> ok. that will do. what was the bad merge that occured - was it from the now abandoned branch ?
[02:03] <lalo> yes
[02:03] <lifeless> ok, thats good.
[02:04] <lifeless> so, for future reference, I repeat: do not alter revisions in your archive without discussing alternatives (we can even repair 'bogus patches' in all likelyhood) with someone on the arch team!
[02:04] <lifeless> because referential integrity problems raise havoc - for you more than for me.
[02:06] <lalo> I think you're not being pragmatic with this referential integrity thing. If I have control over all places the revision may have ever been referred to, "altering history" may well be the best thing to do.
[02:06] <lalo> I wouldn't have done that, for example, if pqm used a revlib.
[02:06] <lifeless> pqm does have a revlib.
[02:07] <lifeless> if you had not mirror patch-135 to chinstrap, it wouldn't have been nearly as concerning.
[02:07] <lalo> hmm. the reject message I got seems to imply pretty clearly it wasn't getting my tree from a revlib
[02:07] <lifeless> that doesn't mean that it doesn't have one.
[02:07] <lalo> ah well
[02:08] <lalo> I mean, if it was using a greedy revlib to get my tree - is that betrer?
[02:08] <lalo> better
[02:08] <lalo> or even better - if it had my tree on its revlib
[02:08] <lifeless> right, it doesn't auto-add, because we have some tests that do bad things to rev libs.
[02:08] <lifeless> my point is that once that there patch hit chinstrap, you no longer had control.
[02:09] <lalo> in this case I did due to company policy
[02:09] <lifeless> ?!!??!!
[02:09] <lifeless> company policy says no such thing.
[02:09] <lalo> the only legitimate users that *should* have my patch are [me, pqm] 
[02:09] <lalo> am I wrong?
[02:10] <lalo> since I thoroughly checked that pqm didn't have it, then I had control
[02:10] <lifeless> and anyone in the company who hacks on launchpad, who might want to review current status, or have a local mirror. there is nothing in the arch policy against either of those uses.
[02:10] <lifeless> yes, you are wrong.
[02:11] <lifeless> I agree, that in specific circumstances, replacing the revision is the right thing to do, but you have taken the referential integrity concerns far to lightly IMO.
[02:11] <lalo> ok
[02:11] <lifeless> at a bare minimum you should have emailed everyone with potential access to your mirror stating that you've replace the patch so that we can take whatever actions are needed.
[02:12] <lalo> *if* a "bogus rev" situation ever happens again, I'll use "tag from within the same version" and then cacherev just to be sure
[02:12] <lifeless> cool. thats a *safe* solution.
[02:12] <lalo> at least for anything canonical.
[02:12] <lifeless> I'd be happy (and interested) in figuring out the root cause should this ever happen again: its a serious bug.
[02:13] <lalo> ok
[02:13] <lalo> I don't really have much clue, but *maybe* I ran out of space in the revlib partition
[02:14] <lalo> (I did run out of space, but I don't remember if it was in the same day as this happened, or even if I made any LP commit while I was out of space)
[02:14] <lifeless> ah, that would do it.
[02:14] <lifeless> actually, no it wouldn't
[02:14] <lifeless> new revs are built in a ,,foo dir, and renamed to the final name.
[02:15] <lalo> meanwhile, could you tell pqm about my new version? it's lalo@canonical.com--canonical-work-2004/launchpad--devel--0.0
[02:15] <lalo> hmm true.
[02:15] <lifeless> that will work straight off.
[02:15] <lalo> really? funny then
[02:15] <lalo> I submitted the request twice already yesterday and got neither success or failure
[02:16] <lifeless> I disabled pqm temporarily.
[02:16] <lalo> ah, ok
[02:16] <lifeless> until we'd had this chat.
[02:16] <lalo> makes sense.
[02:18] <lalo> it may also be that the revlib has been bogus for quite long, maybe since I had bad ram, and the problem only surfaced last week due to some random coincidence in the commit
[02:20] <lifeless> could be
[02:21] <lalo> btw, when I argue it's because I want to understand your point of view.  In this case, you convinced me.  If I simply believed I knew better than you I'd shut up and not care.
[02:21] <lifeless> heh, I'm glad you wanted to understand.
[02:23] <lalo> well, I know more about arch than about i18n, and if you s/know/care/ the sentence remains true. I wish I had started *working* on it earlier, maybe I would be in the arch team instead of lp.
[02:23] <lalo> now I'll get back to work
[02:34] <limi> sabdfl: fixed that (#1800) earlier this morning
[02:36] <SteveA> that's so confusing.  I looked at https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1800
[02:36] <SteveA> and was confused :-)
[02:40] <limi> of course, the accounts are not in sync
[02:43] <SteveA> well, the counts are not in sync
[03:08] <BradB> Anyone know how to fix the pg_type.h error when trying to build psycopg 1.1.15 on OS X?
[03:08] <BradB> I did this: http://lists.initd.org/pipermail/psycopg/2002-December/001630.html, but it's still telling me it can't find it.
[03:09] <stub> How did you install postgres? You might not have the headers installed?
[03:10] <stub> The includes and libs are also often in /whatever/include/pgsql instead of /whatever/pgsql/include
[03:11] <stub> BradB: btw. darwin ports won't touch your existing Python install so you can give that a go (assuming your python isn't installed in /opt/local), so it still might be worth giving 'port install psycopg' a go to see what happens.
[03:12] <BradB> stub: The fact that it doesn't touch the existing Python install is the problem though, I think.
[03:13] <BradB> http://paste.husk.org/1697
[03:13] <limi> lulu: Amazon portlet added
[03:13] <lulu> limi: thanks I'll have a look
[03:16] <stub> BradB: Try 'env INCLUDES="-I/usr/local/pgsql/include" ./configure --whatever-you-had-before' or 'env CFLAGS="-I/usr/local/pgsql/include" ./configure ...'
[03:17] <BradB> Same error.
[03:18] <stub> What was wrong with trying 'port install psycopg' and letting darwin ports install a fresh postgresql and python in /opt/local for launchpad work?
[03:22] <BradB> We'll find out in a few minutes... :)
[03:27] <stub> If you go back to manually trying psycopg, there should be a confsomethingorother.log which will list the commands it was trying to run to test if pg_type.h exists. It might provide insight to why it failed.
[03:31] <BradB> This'll take a long time yet...presumably I can go ahead with the RocketFuelSetup instructions, right?
[03:32] <stub> Yup. All you need for that is arch and gpg.
[03:32] <BradB> ok
[03:33] <stub> It takes a while the first time if you havn't used arch before, so it might be worth getting someone there to shoulder surf.
[03:33] <BradB> ok
[03:34] <BradB> that tla my-id line: is that literally "tla my-id" or does some value belong in place of my-id? (i.e. the one that james [i think?]  is going to be creating for me.)
[03:36] <dilys> Bug 2031 resolved: PQM success or failure messages being bounced?
[03:40] <stub> BradB: a literal 'tla my-id'
[03:41] <spiv> But the firstname.lastname@canonical.com bit should be different ;)
[03:42] <BradB> heh
[03:44] <stub> BradB, spiv: Do you now if it is possible to do FooTable.select(FooTable.q.foo = 'bar') in a case insensitive manner?
[03:45] <BradB> not that i'm aware of. i did a manual ILIKE hack in a previous project using SQLObject.
[03:47] <BradB> So far things are seeming to go okay with port install.
[03:49] <stub> Mmm... I need to do it with CONTAINSSTRING actually. So I could just subclass CONTAINSSTRING and make it add a lower() in the right spot.
[03:50] <lalo> lifeless: all yay, the merge was successful and doesn't seem to contain any bogosity.
[03:54] <lalo> *now* I'll go to the bakery; the oatmeal seemingly wasn't enough breakfast.
[04:05] <spiv> stub: Yeah, there's no builtin way to do it with sqlobject that I know of.
[04:07] <stub> Should be possible to make Foo.q.bar.lower() work I think
[04:08] <lalo> stub: +1
[04:09] <spiv> stub: Yep.
[04:09] <lalo> in case you *are* looking for opinions, I find that a rather reasonable api for the task.
[04:12] <spiv> (reminds me a little of http://svn.twistedmatrix.com/cvs/trunk/sandbox/cake.py?view=auto&rev=6369&root=Twisted)
[04:54] <lulu> limi:ping
[04:55] <limi> pong
[04:55] <lulu> limi: are you working on the books portlet at themoment?
[04:55] <limi> not at this very second, no
[04:56] <limi> how come?
[04:56] <lulu> ok - the display seems to be broken - only showing the heading, not books.
[04:56] <lulu> also: in Documentation - could you move it to after the wiki link? cheers!
[04:57] <limi> not possible, it lists non-folderish items first
[04:57] <limi> sorry, folderish
[04:57] <limi> anyway, it's probably only showing the heading since it was moved
[04:58] <limi> I will try a re-index and see if that helps
[05:00] <lulu> limi: thanks. let me know when you're done fixing it.
[05:02] <limi> lulu: suddenly the books folder is at the root again - is anybody else moving it around that you know?
[05:02] <limi> I moved it into the docs area an hour ago or so
[05:02] <lulu> nope - only you. It's appearing in the docs area, but not at the bottom
[05:03] <lulu> did it have something to do with the tarball?
[05:03] <limi> no
[05:03] <limi> that is the software itself, not the content
[05:04] <limi> hm, just silly caching, it seems
[05:04] <limi> :)
[05:07] <lulu> limi: let me know when done - I've tried it in IE and Netscape and cleared my cache on Safari and Firefox. Still getting the problem on the books portlet.
[05:07] <limi> yes, it isn't working at the moment
[05:11] <sabdfl> limi: thanks, great
[05:11] <sabdfl> stub: what's table x?
[05:16] <limi> lulu: seems to be a bug in the ATAmazon product, I will report it to the author. moved the books to the top level for now, so the portlet works
[05:16] <limi> will add the "More books" link next
[05:16] <lulu> limi: thanks
[05:17] <lulu> limi: headings and subheadings in Structured Text. I get a main heading with 2 - 4 spaces - can't seem to get a subheading unless I use html. what do you think the problem is?
[05:18] <limi> probably something wrong in the indenting - will try to create an example document for you afterwards
[05:26] <dilys> New bug 2044 for Launchpad/Rosetta: Rosetta should at the LEAST know about browser languages
[05:29] <limi> lulu: http://www.ubuntulinux.org/examples/stx/
[05:32] <lulu> limi: tx for that
[05:32] <lulu> limi: let's keep that there for the moment.
[05:32] <limi> I won't touch it ;)
[05:32] <limi> sent you the URL
[05:44] <lulu> limi: gotcha.
[05:45] <lulu> limi:news item on canonical - can you set it so that they don't appear in the nav portlet....i assume this is the same prob as help centre items appearing in the nav.
[05:45] <lulu> limi: what's happening on this issue?
[05:46] <limi> it's doing what we are asking it to - showing both folderish and non-folderish items in the nav tree
[05:47] <limi> which will cause items like that to show up - which means we will have to explicitly tell it to hide certain types that you don't want to show up
[05:47] <limi> it can't magically guess what types you think should show up ;)
[05:50] <lulu> limi: not asking you to magically guess - we have had emails on it - please refer to FAQ's appearing in the nav portlet - scalability issue. It's the same in news items...
[05:50] <lulu> limi: in the news section
[05:50] <limi> but I can't see your mailbox ;)
[05:51] <limi> any other types than News Items?
[05:51] <lulu> emails between us
[05:51] <lulu> yes - all the help cenre (Documentation)
[05:51] <lulu> centre
[05:51] <limi> haven't seen anybody mention news items specifically
[05:51] <lulu> in news on canonical 
[05:51] <lulu> when u add items
[05:52] <lulu> will they appear as a list (if more than one) on the index page?
[07:16] <lalo> spiv: was it you who suggested that I try commit/abort via fetching the connection object built by InitZopeless?
[07:18] <lalo> hmm, doesn't seem to be around. I'll use the mailing list.
[07:55] <spiv> lalo: Yeah.
[07:55] <spiv>  
[07:55] <spiv> Well, by keeping the connection you pass to initZopeless.
[07:55] <lalo> hello
[07:55] <lalo> yes :-) that doesn't work
[07:55] <spiv> Hmm!
[07:56] <spiv> How are you calling commit/abort?  What's the error (or just silently fails to do so?)?
[07:57] <lalo> give me 2 secs
[07:57] <spiv> Sure.  I'm very curious about this :)
[07:58] <lalo> ok, well
[07:58] <lalo> the default setup of sqlo is "autoCommit" - meaning, it commits after *EACH* query
[07:59] <lalo> so you can, yes, commit or abort at the end of the script - but it will be meaningless :-)
[07:59] <spiv> Oh, right.
[07:59] <lalo> so
[08:00] <lalo> you wrap your connection in a Transaction object, and give *that*m to SQLBase
[08:00] <lalo> then it works. Kinda. There are two or three very simple bugs in the Transaction class.
[08:00] <spiv> What are the bugs?
[08:01] <spiv> The iterSelect one?
[08:01] <lalo> yes
[08:01] <spiv> That's fixed in SQLObject 0.6, which lifeless will apparently sync into our snapshot sometime this week.
[08:02] <lalo> the iterSelect two, actually, if you also consider the fact that a list is not a valid thing to return from an __iter__ method :-)
[08:02] <spiv> Right :)
[08:02] <spiv> Any others?  I already know about those two ;)
[08:02] <lalo> (or if this is the one you know, then the other one is that Iteration has to have a __iter__ method to be passed into list())
[08:03] <spiv> Yep, those are the two I know.
[08:03] <spiv> Need iter(...) in Transaction.iterSelect, and __iter__ in Iteration.
[08:03] <spiv> 0.6 has both of those fixed, and I've attached a patch to a rosetta bug somewhere to do the same thing.
[08:04] <lalo> give me two more secs to check if that's all
[08:04] <lalo> I was trying to commit those to my own sqlobject branch, and got lost in the conflicts :-)
[08:04] <spiv> Heh.
[08:06] <lalo> nay, sir, that's all.
[08:06] <spiv> That's good :)
[08:06] <spiv> Thanks for trying that out.
[08:06] <lalo> yes. If it's known, and it's on the way to fixing, then it's good
[08:07] <lalo> well, I *had* to :-) our import script is kinda broken if we don't have transactions
[08:07] <spiv> Well, thanks for letting me know how it went, then :)
[08:08] <lalo> np
[08:38] <dilys> Bug 2011 resolved: Package browser
[09:16] <SteveA> stub: hello