[12:10] <kiko> [2006-03-16 20:10:04 BRT]  launchpad@launchpad_dev LOG:  statement: SELECT Packaging.id, Packaging.datecreated, Packaging.productseries, Packaging.packaging, Packaging.sourcepackagename, Packaging.distrorelease, Packaging.owner, _prejoin0.id, _prejoin0.name, _prejoin1.id, _prejoin1.lucilleconfig, _prejoin1.owner, _prejoin1.datelastlangpack, _prejoin1.title, _prejoin1.sourcecount, _prejoin1.parentrelease, _prejoin1.version, _prejoin1.nominatedarchindep, _prejo
[12:10] <kiko> in1.datereleased, _prejoin1.displayname, _prejoin1.description, _prejoin1.messagecount, _prejoin1.releasestatus, _prejoin1.binarycount, _prejoin1.changeslist, _prejoin1.name, _prejoin1.summary, _prejoin1.distribution, _prejoin2.id, _prejoin2.importstatus, _prejoin2.datestarted, _prejoin2.displayname, _prejoin2.summary, _prejoin2.cvsroot, _prejoin2.datefinished, _prejoin2.targetarcharchive, _prejoin2.cvsbranch, _prejoin2.branch, _prejoin2.releasefileglob, _pr
[12:10] <kiko> ejoin2.dateprocessapproved, _prejoin2.svnrepository, _prejoin2.product, _prejoin2.rcstype, _prejoin2.releaseroot, _prejoin2.datesyncapproved, _prejoin2.cvsmodule, _prejoin2.datelastsynced, _prejoin2.targetarchversion, _prejoin2.dateautotested, _prejoin2.releaseverstyle, _prejoin2.targetarchbranch, _prejoin2.name, _prejoin2.datecreated, _prejoin2.targetarchcategory, _prejoin2.cvstarfileurl, _prejoin2.syncinterval FROM Packaging, SourcePackageName AS _prejoin0
[12:10] <kiko> , DistroRelease AS _prejoin1, ProductSeries AS _prejoin2, SourcePackageName, DistroRelease WHERE _prejoin0.id = Packaging.sourcepackagename AND _prejoin1.id = Packaging.distrorelease AND _prejoin2.id = Packaging.productseries AND  Packaging.sourcepackagename = SourcePackageName.id AND DistroRelease.id = Packaging.distrorelease AND DistroRelease.id = 3 ORDER BY SourcePackageName.name
[12:10] <kiko> that is a fat-ass one :)
[12:10] <Kinnison> heh
[12:10] <Kinnison> whassat do then?
[12:10] <spiv> Forgive me father, for I have sinned.
[12:11] <kiko> prejoins most of packaging 
[12:11] <Kinnison> hehe
[12:11] <Kinnison>  father forgive you, you tried not to do it. Turned over a new leaf, then prejoined right through it.
[12:12] <ddaa> I large fraction of that appears to be productseries goo nobody cares about
[12:12] <ddaa> and that should be in a vcsimports table anyway
[12:51] <Kinnison> At this rate I need someone to go get me another double amaretto
[12:51] <Kinnison> Soyuz, fueled by almonds and alcohol
[12:51] <Kinnison> kiko: was a conflict in a pagetest, should be okay now
[12:52] <kiko> cool
[12:52] <Kinnison> Was the only "normal" conflict :-)
[12:52] <Kinnison> merge sent
[12:52] <Kinnison> Now for the next error :-)
[12:55] <Kinnison> kiko: Should be around 11 minutes until we know if the merge conflicted
[12:55] <Kinnison> kiko: if it doesn't fail after that, then we have to wait for the tests
[12:56] <kiko> yeah, that'll be nastier
[12:56] <kiko> man, I fixed up some pretty horrible performance bugs using this code of spiv's tonight
[12:56] <kiko> it's beautiful
[12:57] <Kinnison> heh
[01:07] <Kinnison> kiko: great, so now it has failed and I don't know why
[01:07] <Kinnison> no email
[01:08] <kiko> fuck this pqm
[01:10] <Kinnison> Does anyone have access to the box to see what happened?
[01:11] <spiv> Kinnison: Usually, if I get no email back from pqm, I screwed up a URL in my pqm command.
[01:12] <spiv> e.g. chinstrap.ubutnu.com
[01:12] <spiv> Which seems to cause it to silently drop my request on the floor
[01:12] <Kinnison> star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/dsilvers/launchpad/soyuz-mainline/ sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[01:12] <Kinnison> that's what I sent
[01:12] <Kinnison> and the last time I sent that, I got a conflict during merge
[01:12] <Kinnison> I have since fixed that and pushed and re-sent the pqm request
[01:12] <Kinnison> only for it to be dropped
[01:12] <Kinnison> fucking pqm
[01:12] <spiv> I've also heard of it happening if you cause bzrlib to raise an exception pqm doesn't expect.
[01:12] <Kinnison> Yeah
[01:13] <spiv> I suggest, rather than emailing it to PQM, nailing it to lifeless's door.
[01:14] <Kinnison> along with a goats head?
[01:14] <spiv> Title the piece of paper "95 Theses^WFailed Merge Requests".
[01:15] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [r=kiko]  Make alternateIDs method (e.g. byName) only issue one query, rather than two almost identical queries. (r48: Andrew Bennetts)
[01:24] <Kinnison>  My life, my pride is broken. You like to think you're never wrong! You live what you've learned!
[01:24] <Kinnison> I need more CPU on this laptop
[01:24] <Kinnison> this test-merge is CPU bound
[01:28] <carlos> Kinnison: I need more speed on this hardisk
[01:28] <carlos> perhaps we could get a new computer and split it ;-)
[01:28] <Kinnison> and the electricity bill?
[01:29] <carlos> Kinnison: yours, of course :-P
[01:29] <Kinnison> :-(
[01:29] <carlos> I'm just a kid....
[01:29] <carlos> O:-)
[01:29] <Kinnison> I'm the one listening to Linkin Park
[01:29] <carlos> :-P
[01:36] <dilys> Merge to devel/launchpad/: [trivial]  Silence hctapi.py exception on startup (r3276: Christian Reis)
[01:39] <Kinnison> Good night all
[04:41] <dilys> Merge to devel/launchpad/: [trivial]  Bug #35198 - FOAF mbox_sha1sum is incorrect (r3277: Stuart Bishop)
[08:50] <sivang> morning people
[09:37] <Kinnison> Morning
[09:51] <carlos> morning
[10:05] <mpt> Goooooooooooooooooooood morning Launchpadders!
[10:54] <jamesh> carlos: which tests would be best to test that my poparser isn't breaking stuff?
[10:54] <carlos> jamesh: I guess poimport.txt
[10:54] <jamesh> carlos: I found lib/canonical/launchpad/doc/poparser.txt, but it didn't test much
[10:54] <jamesh> okayu
[10:54] <carlos> jamesh: our parser test suite is not the best in the world....
[10:55] <jamesh> carlos: I added a few small tests in my branch
[10:55] <carlos> jamesh: cool, thanks!
[10:56] <jamesh> to check partial writes where you write half a multibyte sequence, and some problem Big5 sequences
[10:58] <bradb> spiv: bug 4700
[10:58] <Ubugtu> malone bug 4700 in bzr "Merge conflict: "2 conflicts encountered" but no "bzr conflicts" output" [Normal,Unconfirmed]  http://launchpad.net/bugs/4700
[11:01] <kiko> hey stub!
[11:01] <kiko> how's it going old man
[11:01] <spiv> bradb: thanks!
[11:02] <stub> kiko: old? Why you wippersnapper!
[11:02] <kiko> cheeky is my middle name
[11:09] <jordi> kiko don't do it
[11:09] <jordi> don't go running
[11:09] <kiko> I run every day
[11:13] <jordi> kiko: I HATE YOU EVERYDAY
[11:13] <kiko> every day I love you less and less
[11:14] <kiko> stub, can you help with a quick analysis of https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-03-15/A106 -- ?
[11:14] <kiko> stub, looks like contention, right?
[11:17] <stub> kiko: yer. The query is real fast when I test it.
[11:19] <kiko> stub, is there any suggestion solution to it?
[11:19] <kiko> it's rather common
[11:20] <kiko> suggested solution
[11:21] <stub> I don't think there is anything we can do from the webapp end. Ideally we could fix the publisher stuff (what I suspect would lock things like that) to not hold things open for so long.
[11:21] <stub> Well.. we could break apart the tables somewhat
[11:21] <stub> There is also the chance that the improved locking in PG 8.1 fixes this for us.
[11:22] <kiko> it happened yesterday though
[11:22] <kiko> do you know who writes to that table?
[11:22] <stub> We haven't upgraded yet
[11:22] <stub> There is only one process that writes to that table I think (?). 
[11:22] <stub> Which isn't the publisher  - is it the statistician?
[11:23] <stub> Yes - the statistician is the only thing that writes to that table.
[11:24] <stub> So we need to fix the statistician. Perhaps writing all the results to a temporary table, and then quickly replacing the values in the real table when all the calculations have been done.
[11:25] <stub> Or just committing more often
[11:25] <stub> Statistician stuff is mainly SQLObject code, so there might be some low hanging fruit that can be fixed by using prejoin.
[11:26] <spiv> stub: Btw, I just submitted a branch to pqm that implements prejoinClauseTables
[11:27] <stub> cool. I thought you were going to hold off to see if it would actually be useful. Just a trivial fix was it?
[11:27] <kiko> stub, spiv has helped me bigtime in nailing the main offenders -- the bug listings now issue O(1) queries!
[11:27] <kiko> stub, spiv is the master of all table joining trickeries
[11:27] <spiv> It turned out to be near-trivial once I had the rest of it working.
[11:27] <jordi> kiko: daf is playing "everyday I love you less and less"
[11:27] <Kinnison> pqm is currently disabled anyway
[11:28] <stub> Cool. Sounds like we need to implement user configurable batching sizes soon, as everyone wants it and we might actually be able to support it!
[11:28] <spiv> kiko has a big shiny branch that makes use of prejoins all over the place, and it certainly reduces the number of queries.
[11:28] <Kinnison> Oh, it might be turned on again actually
[11:28] <spiv> (as does fixing the so-called alternateID support)
[11:28] <Kinnison> ID? Name? ID? Name? ID? Name? (ad infinitum)
[11:29] <spiv> Which was a trivial patch -- although upstream already had that fix, another reason to grit our teeth and upgrade.
[11:29] <bradb> stub: I have a branch that implements that, but I got in trouble for trying to land it during this sprint, instead of doing branch/bug integration.
[11:29] <bradb> I would have landed it before I left, but for pqm troubles
[11:29] <stub> bradb: Storing batch size in the session, or in the db on the person table?
[11:30] <bradb> stub: Wasn't persisting the config yet, but it'd take an extra 10 minutes to do so, if it were on the session.
[11:31] <stub> I think it is a good use of the session, and worth doing if it doesn't screw up the UI
[11:32] <bradb> I think so too.
[11:34] <stub> Yay. Found the Retry bug. Just need to talk to upstream if it should be fixed there too.
[11:36] <kiko> stub, rock!
[11:36] <kiko> stub, can you ping me when you have 5 minutes to suggest how to do an SQL query I am having trouble with?
[11:38] <stub> kiko: ping
[11:40] <kiko> stub, see privmsg
[12:42] <Seveas> stub, thanks for writing pytz - you made Ubugtu a happy camper 
[12:43] <jamesh> Seveas: we're using it inside Launchpad, among other things
[12:44] <Seveas> I'm using it in Ubugtu for localized schedules of #ubuntu-meeting - it's dead-easy with pytz
[12:51] <carlos> stub: hi, yesterday I was not able to update staging as my branch was not merged on rocketfuel...
[12:52] <carlos> stub: All should be fixed now and working but pqm is beeing too slow
[12:52] <carlos> stub: could I merge my branch directly on staging?
[12:52] <carlos> to test it?
[12:52] <carlos> I have a special version of that branch already cheerypicked on a production branch so you can cheery pick it if we confirm that I didn't break anything on staging...
[01:14] <ddaa> collab.net is not reliably enough to let us import subversion
[01:14] <ddaa> Dunno why, but I find that hysterically ironical.
[01:14] <Kinnison> You mean we're not resilient enough
[01:16] <stub> carlos: you need to build a tree on chinstrap and rsync it across
[01:17] <carlos> stub: I have it already on chinstrap
[01:17] <stub> A full tree?
[01:17] <carlos> stub: I guess I should rsync it and then do  bzr merge....
[01:17] <carlos> stub: oh, you mean to run that instead of current staging?
[01:17] <carlos> ok
[01:17] <carlos> not yet done...
[01:17] <carlos> but it's easy to do it.
[01:18] <stub> actually, you probably can just merge it in. I forgot that asuka has a version of bzr around (old, but it was still working)
[01:19] <stub> give me the branch details and I'll do it
[01:19] <stub> carlos: ^^
[01:20] <carlos> give me just a second, I'm finishing another thing that I want to test so we don't need to do the rollout twice...
[01:23] <stub> What is this patch fixing btw? Or is is a cluster of fixes that needs to be landed asap for some reason?
[01:26] <ddaa> Arguably, the svn import should not go dead at the first time out...
[01:27] <kiko> stub, the reason they need to be landed is that we need to process the 13K imports in the queue
[01:27] <kiko> today is really the only day daf, spiv, carlos and I are together to do it
[01:27] <kiko> stub, it only touches the import queue code
[01:27] <kiko> so it should be pretty safe
[01:27] <kiko> but it does affect how imports are processed
[01:28] <carlos> and it has tests
[01:28] <carlos> :-P
[01:28] <kiko> which is why it would be nice to run this on staging first.
[01:28] <kiko> some tests.
[01:28] <stub> the queue is currently stalled, or is it happily importing the stuff it can deal with?
[01:28] <carlos> stub: it's not stalled
[01:28] <carlos> stub: we are implementing some helpers to allow us to handle it faster
[01:32] <stub> I'll be around for another hour anyway
[01:35] <doko> kiko: somebody around you with pt keyboard?
[01:36] <carlos> stub: the changes are done. I'm going to commit and push them now
[01:38] <kiko> not me
[01:43] <cprov> stub: ping
[01:43] <stub> cprov: pong
[01:44] <cprov> stub: do you have the script you ran for rosetta path migration ?
[01:45] <cprov> stub: would you to run it in launchpad_dogfood@mawson ?
[01:45] <stub> cprov: Would you rather just get a fresh dump?
[01:45] <stub> cprov: The script is in database/schema/archive I think
[01:45] <stub> cprov: But there was some manual work needed doing first (removing various potemplates and pofiles that carlos flagged)
[01:46] <cprov> cprov: fresh dump would be nice, but it might take long, or not ?
[01:46] <stub> It will take about 2 hours to build
[01:46] <carlos> stub: cprov has the script already, he just needs the manual work done
[01:47] <cprov> stub: yes, the required manual work that I'm looking for ?
[01:47] <cprov> hey .. i will remove the contraint line from the DB patch for a while, it's dogfood ...
[01:48] <stub> I don't have the details sorry. The tools I used are in chinstrap:/home/warthogs/archives/stub/dbascripts/devel (delete_potemplate.sql, delete_pofile.sql), but I don't have the ids that need to be removed.
[01:49] <stub> chinstrap:/home/warthogs/archives/stub/dbascripts I mean
[01:50] <cprov> stub: I think I can simply do not apply the constraints for a while, then use the fresh DB copy
[01:50] <carlos> stub: cprov has the IDs
[01:50] <cprov> stub: can you start to copy it ?
[01:50] <stub> cprov: Sure
[01:51] <cprov> stub: thanks 
[01:51] <kiko> doko, no, nobody here has abnt, sorry.
[01:55] <dilys> Merge to devel/launchpad/: [r=kiko]  Implemented filtering options for the translation import queue and improved the guessing algorithm to be able to import automatically more entries (r3278: Carlos Perello Marin)
[01:57] <kiko> rock on
[02:00] <cprov> stub: does the dbascripts you mentioned take too long to run ?
[02:01] <stub> cprov: It doesn't take long to use them. Just need to use them one at a time
[02:01] <stub> psql -d launchpad_dogfood
[02:01] <stub> \set potemplate_id 666
[02:01] <stub> \i delete_potemplate.sql
[02:02] <stub> (repeat as necessary)
[02:02] <cprov> stub: right
[02:02] <carlos> stub: could you merge chinstrap.ubuntu.com:/home/warthogs/archives/carlos/launchpad/bug-33020/ on staging?
[02:02] <stub> carlos: ok
[02:02] <carlos> stub: thank you
[02:04] <carlos> stub: I will need to run a script there on staging that uses zopeless and sends email. Kiko suggested me to comment the email sending routine so I can run it without spaming anyone. Is that ok to you?
[02:05] <kiko> I thought staging didn't send email, though, but..
[02:05] <stub> kiko: zopeless stuff send email by a different method that has never been updated to do nothing (or redirect to a different address) on staging.
[02:13] <kiko> stub, scary.
[02:18] <dilys> Merge to devel/launchpad/: [trivial]  Support utilities/pasting without a title (r3279: Christian Reis)
[02:20] <stub> carlos: staging updated with your branch
[02:20] <carlos> stub: cool, thanks
[02:20] <stub> carlos: hack our what you need to to do your testing. Probably just need a return in lib/canonical/launchpad/email/sendmail.py
[02:28] <carlos> stub: I don't see that file...
[02:28] <carlos> it's mail
[02:28] <carlos> I see it now
[02:44] <kiko> stub, we need to skip out for 20m, but will be back in a second -- please don't lose faith
[02:44] <stub> kiko: I'm heading off soon. What am I still needed for?
[02:47] <sabdfl> stub: are you confident on pg 8.1, and when do you plan to deploy it?
[02:47] <sabdfl> can we do that separately from code/hw updates?
[02:48] <stub> I planned to deploy it last Tuesday but had to reschedule
[02:48] <stub> We can do it seperately from code and hw updates.
[02:49] <stub> Just needs a three hour window, and someone with access to shutdown and startup the publishing system.
[03:16] <Oublieuse> d
[03:17] <Oublieuse> /msg nickserv identify twambo
[03:17] <Oublieuse> arf
[03:18] <cprov> afff
[03:20] <carlos> stub: hi, How much time do I have before you pass the point of not return to do a production cherry pick?
[03:22] <stub> There isn't time to do one tonight. If you test it on staging, I can cherry pick it tomorrow (or wait until you are back home to monitor the results if you would rather)
[03:22] <carlos> stub: well.... I did already the cherrypick
[03:23] <carlos> stub: it's a matter of doing a merge into production
[03:23] <carlos> test are passing, no conflicts
[03:23] <carlos> stub: we need it for this afternoon....
[03:24] <carlos> I did the fix on a production branch to prevent any problem doing the cherry pick
[03:24] <stub> It is code only, so Steve may be able to push it out to the two production servers.
[03:24] <carlos> stub: yes, it's code only
[03:25] <carlos> stub: ok, I guess that would work
[03:26] <carlos> stub: ok, kiko gave me the ok to do the cherry pick
[03:26] <carlos> stub: it's at chinstrap.ubuntu.com:/home/warthogs/archives/carlos/launchpad/production-1.53/
[03:27] <carlos> if you cannot do it now, tell me it so I will try to find Steve (he's not around atm)
[03:27] <stub> I can't do it now
[03:28] <carlos> ok
[03:28] <kiko> hey dudes
[03:28] <kiko> mmmm
[03:28] <carlos> kiko: we need SteveA to do the cherry pick
[03:28] <kiko> stub, are you about to be gone?
[03:28] <stub> I'm going right now
[03:29] <kiko> all right
[03:29] <sabdfl> cheers stub
[03:29] <stub> cprov: your fresh database will be an hour or so. 
[03:31] <cprov> stub: right, thank you 
[03:31] <sabdfl> mpt around?
[03:34] <mpt> yo
[03:34] <kiko> look there
[03:40] <mpt> sabdfl, you called?
[03:41] <sabdfl> mpt: what's the way to use the 2col template?
[03:42] <mpt> sabdfl, change "@@main_template" to "@@main_template_2col"
[03:42] <sabdfl> nice
[03:42] <sabdfl> thanks
[03:42] <mpt> yw
[03:42] <sabdfl> will give you feedback shortly
[03:43] <mpt> SteveA said he'd refactor the two templates later so they're sharing code
[03:44] <bradb> ddaa: Hm, your branch page titles branch is one of those prohibitively-long-to-merge ones.
[03:44] <ddaa> long-to-merge with what?
[03:45] <bradb> I just tried merging it into my malone-bzr-integration branch
[03:45] <ddaa> it should not have anything missing, since it's pulled from a shared repository that also contains the rocketfuel branc.
[03:45] <bradb> rsync'd it down, over top of a copy of my launchpad-upstream directory
[03:51] <kiko> ddaa, maybe a bzr reconcile is in order?
[03:52] <ddaa> reconciling might be required by after merge.
[03:52] <ddaa> As it involves fixups that are needed after some missing data is filled in by merging another branch.
[03:52] <ddaa> I'll look into that after I'm done fixing up bzrk for jbailey.
[04:08] <doko> bradb: just discovered the "package maintainance report", nice!
[04:10] <bradb> doko: Glad to hear you like it. That was probably done by cprov or someone else with Soyuz-fu.
[04:12] <doko> bradb: yes, just wanted to know where to file bug reports^W^Wenhancement wishes ;)
[04:12] <salgado> bradb, it was done by me, actually. and kiko did some enhancements recently
[04:13] <doko> salgado: so soyuz should be fine for these?
[04:16] <salgado> doko, I think launchpad would be better
[04:16] <kiko> doko, either soyuz or launchpad, and you can assign to me, I'll do fixes this coming week. note, however, that I have already fixed it to not display superseded entries.
[04:16] <doko> ok
[04:25] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [r=kiko]  Fix prejoins with clauseTables, also add prejoinClauseTables for more efficient prejoining when the select is already doing the desired join. (r49: Andrew Bennetts)
[04:31] <kiko> wooo rock and roll!
[04:31] <jamesh> daf: how does this look? https://chinstrap.ubuntu.com/~jamesh/poparser-encoding.patch
[04:34] <daf> jamesh: +        # Scan for the charset in the same way that 
[04:34] <daf> jamesh: where's the rest of that comment?
[04:35] <jamesh> daf: in my head
[04:35] <jamesh> daf: "the same way that gettext does"
[04:35] <carlos> jamesh: dude, remember to execute jamesh.flush() before pushing your branch :-P
[04:35] <daf> jamesh: ah :)
[04:36] <daf> I wonder if the charset= extraction code would be more readable using a regex
[04:36] <daf> match = re.match('charset=(.*)', kw['msgstr'] )
[04:36] <daf> if match:
[04:36] <daf>     charset = match.group(1)
[04:36] <carlos> daf: regex and readable are not compatible.....
[04:37] <jamesh> carlos: that's not quite true
[04:37] <carlos> at least for me that know nothing about it :-P
[04:37] <daf> well, I have abused them in the past
[04:37] <carlos> daf: that would be why I hate them.... :-P
[05:01] <ddaa> Kinnison: all things considered
[05:02] <ddaa> since I'm the maintainer, I can decide it's not pronounced "bezerkay"...
[05:02] <ddaa> It's _now_ pronounced
[05:07] <ddaa> ignorance is force
[05:12] <sabdfl> steve around?
[05:29] <Kinnison> Well, I think that either PQM has died, the soyuz branch has merged and is testing, or else something altogether more sinister is going on
[05:30] <Kinnison> Since it has been in PQM for a little over 20 minutes now
[05:30] <Kinnison> and it normally crapped out around 11 minutes in
[05:31] <Kinnison> cprov: yo
[05:31] <Kinnison> cprov: If this merge succeeds, you and me have a meeting at the bar
[05:31] <cprov> Kinnison: right
[05:38] <Kinnison> cprov: we have a failure :-(
[05:38] <cprov> Kinnison: uhm ... is that another conflict  ?
[05:38] <kiko> @#!@$!!@#
[05:38] <Kinnison> cprov: mostly related to the ubuntu-team namechange
[05:39] <Kinnison> cprov: want to come over in a minute and we'll go through to fix 'em ?
[05:39] <cprov> Kinnison: sure
[05:43] <lifeless> dunno why I keep getting booted from here.
[05:48] <Kinnison> lifeless: how long for that production update?
[05:48] <Kinnison> lifeless: hours, or many hours?
[05:50] <kiko> shouldn't be too bad
[05:52] <Kinnison> coolio
[06:04] <lakin> Anyone know if there is a plan for a statistics page for malone:  stuff like # of bugs changed/commented or created for certain time periods?
[06:07] <kiko> lakin, it's intended, but not planned on yet.
[06:07] <lakin> k.
[06:14] <jordi> sabdfl: ping
[06:47] <lifeless> Kinnison: just long enough to run the test suite
[07:04] <spiv> they keep playing the same songs in this hotel... time after time...
[07:09] <sabdfl> spiv: any idea why i should be getting an error building pygettextpo?
[07:09] <sabdfl> just tried the rocketfuel-refresh script and it didn't get any new revisions there
[07:09] <elmo> did you guys take out the lp apps processes on gangotri intentionally?
[07:10] <Kinnison> lifeless: So how's the suite?
[07:13] <spiv> elmo: Yes
[07:13] <spiv> elmo: SteveA is doing a production update
[07:14] <spiv> sabdfl: not off the top of my head -- are the various trees in your sourcecode directory all up to date with current rocketfuel?
[07:14] <spiv> sabdfl: pastebin the error if you like
[07:15] <sabdfl> how do i know if my various trees are all up to date? I though rocketfuel-refresh did that
[07:17] <jamesh> sabdfl: what is the error?
[07:19] <spiv> Yeah, rocketfuel-refresh should do that.
[07:20] <sabdfl> it didn't pull any revisions in to that part of the tree
[07:21] <carlos> sabdfl: perhaps you are missing gettext on your system. I think jamesh changed it to use system's gettext
[07:21] <carlos> jamesh: Am I right?
[07:21] <sabdfl> ah
[07:21] <jamesh> yeah
[07:21] <jamesh> but don't you need gettext installed anyway?
[07:21] <jamesh> (for rosetta)
[07:22] <carlos> jamesh: yes, gettext is a launchpad dependency
[07:22] <carlos> to generate .mo files
[07:22] <sabdfl> ah
[07:22] <sabdfl> i removed the launchpad deps, i think
[07:22] <sabdfl> is the package called gettext?
[07:23] <carlos> sabdfl: yes
[07:23] <jamesh> yes
[07:23] <sabdfl> removed it because i'm trying pg 8.1
[07:24] <elmo> spiv: please tell me when it's finished because it looks suspiciously like one apps server didn't die properly
[07:27] <sabdfl> seems to have worked - thanks guys
[07:30] <carlos> sabdfl: you are welcome
[07:36] <sabdfl> can someone ask mpt what happened to class="lesser"
[07:36] <sabdfl> ?
[07:36] <Kinnison> monkeys with lessers for eyes?
[07:36] <Kinnison> frickin' sharks with frickin' lessers on their heads?
[07:37] <mpt> sabdfl, pong
[07:37] <Kinnison> 18:36 < sabdfl> can someone ask mpt what happened to class="lesser"
[07:38] <SteveA> even lesserrer
[07:38] <mpt> sabdfl, it looks to be on line 948 of launchpad.css
[07:39] <dilys> Merge to devel/launchpad/: [trivial, rs=bradb]  Tweaks 'this bug is not recorded as needing to be fixed here' notification, fixing bug 30958 (/products/malone/+bug/nnn says 'Not yet reported in malone'). (r3280: Matthew Paul Thomas)
[07:39] <Kinnison> Cool, one down, two to go
[07:44] <sabdfl> mpt: odd, it doesn't seem to be having the desired effect on a "listing sortable" table
[07:45] <mpt> sabdfl, that's because table.listing already has font-size: 85%
[07:45] <sabdfl> ok
[07:45] <sabdfl> how do i do a compact listing?
[07:46] <mpt> So the font size will either be "smaller" or "85%" depending on which class you put last :-)
[07:46] <sabdfl> ah
[07:46] <mpt> (I think)
[07:46] <sabdfl> tr class="lesser" works nicely
[07:46] <mpt> yeah, I was just going to suggest <td class="lesser">
[07:46] <mpt> but tr would be less repetitious
[07:47] <mpt> <tbody class="lesser"> would be even better than that.
[07:48] <sabdfl> will do! thanks
[08:03] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/malone/+bug/34768 (Unhelpful error message on linking cve) and some validation functions cleanup r=salgado (r3281: Diogo Matsubara)
[08:25] <dilys> Merge to devel/launchpad/: [r=SteveA]  Adds a test for facet support in GeneralFormView, and removes the old workarounds for the lack of that support. (r3282: Matthew Paul Thomas)
[08:27] <sivang> Kinnison: he he he
[08:28] <sivang> Kinnison: caught your Autin Power line :)
[08:28] <sivang> Powers, by reputation
[09:37] <DRAGON^^> hi
[09:38] <DRAGON^^> why i can't receive message on my mail to activate my account on ubuntu.com?
[09:43] <dilys> Merge to devel/launchpad/: [r=jamesh]  Mainline soyuz (r3283: Celso Providelo, Daniel Silverstone, James Troup ...)
[09:49] <Burgwork> what does mainline soyuz mean for me?
[09:50] <mpt> Burgwork, I know very little about what it does, except that it's been about two months work and Kinnison has been trying to land it for the past two days
[09:50] <mpt> It's something to do with letting you create your own derivatives
[09:50] <Burgwork> cool
[09:50] <Burgwork> I might be using that soon enough
[09:52] <mpt> https://launchpad.net/products/soyuz has a little info
[09:54] <Kinnison> dilys: You suck
[09:54] <Kinnison> There were *so* more people than that involved
[09:55] <Burgwork> Kinnison, congrats
[09:55] <Kinnison> Burgwork: Essentially everything that was done since last november to get soyuz' backend going was in that branch
[09:56] <Burgwork> LP is very cool. I just wish the UI didn't suck monkey balls
[09:57] <Kinnison> Well it'll get better over time
[09:57] <carlos> Burgwork: working on it
[09:57] <Kinnison> It's still a very young project
[09:57] <Burgwork> and a fricking huge one
[09:57] <Kinnison> indeed
[09:58] <Kinnison> anyway
[09:58] <Kinnison> the bar beckons
[11:43] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [r=kiko]  Make prejoinClauseTables actually populate the cache (or, if you prefer, actually work). (r50: Andrew Bennetts)