[12:25] <sivang> re
[12:29] <sivang> kiko: had a chance to review my patch ?
[12:30] <kiko> sivang, you must have gotten your email by now no?
[12:31] <sivang> kiko: yes, I have, reading it now, damn thunderbird doesn't refresh the mbox if you don't go out of it and reclick the mbox folder.
[12:35] <kiko> cool.
[12:38] <sivang> kiko: okay, so you'd rather I merged the test to one of the existing tests regarding the spec tracker or better, change an existing test that already tests for the status of a spec upon cretion?
[12:38] <sivang> creation, even
[12:38] <kiko> exactly.
[12:50] <sivang> kiko: cool, however before that, running make check still failes and I'd like to know why. just after pagetests/foaf/20-make-team-moderated.txt , it says it was hung for 600 secs, and then got killed mercilessly. How can I drill down to the source of this?
[12:50] <sivang> kiko: (I gotta make sure this is not related to something I've changed)
[12:52] <kiko> sivang, it's not, you can be sure. it's something else (and it's weird)
[12:52] <matsubara> kiko: also note that sivang's branch is outdated
[12:52] <kiko> yeah, I know.
[12:53] <sivang> kiko: okay, good to know.
[12:57] <matsubara> night all, see you tomorrow
[12:57] <sivang> night matsubara 
[01:16] <sivang> kiko: is it okay to merge old style tests with testbrowser stuff?
[01:16] <sivang> kiko: as in, have a pagetest all in the old method, and have one testbrowser action in
[01:17] <kiko> sivang, change the old pagetest to be testbrowsered!
[01:18] <sivang> kiko: I know I know :p bonus points are given even, I was going to, but what if I have a way out of it by just replacing the two occurences you've found with grep -ril , which incidently cater for testing that a sepc by default is statused as 'New' ? :)
[01:19] <sivang> kiko: (although that feels like editing a patch that was created with dpatch, e.g. feels somewhat wrong)
[01:20] <kiko> sivang, you could do that, but then your patch would be less cool!
[01:22] <LarstiQ> hmm, wonder at that google code thing
[01:24] <sivang> kiko: agreed. MOreoer, realizing how ugly the old ones compared to the new test browser makes me wanna turn all the test there to the new format, after I finish with this patch.
[01:28] <sivang> anyway, continue this tomorrow, it's sleep time.
[01:29] <sivang> good night all, thanks kiko.
[01:30] <kiko> night sivan
[03:34] <chaddy_> o/
[04:48] <stub> lifeless: wierd. pqm-submit is choosing the wrong target branch. https://sodium.ubuntu.com/~andrew/paste/file0z53Qp.html
[04:48] <lifeless> I think spiv: had that the other day
[04:49] <stub> I'm about to ensure I'm running the current version of the plugin, as per the wiki
[04:49] <stub> That sourcecode/bzr subtree is always causing trouble. It was also being pushed along with the launchpad tree as well (open bug on that I think...)
[04:50] <lifeless> how are you pushing?
[04:55] <stub> rsyncing the entire repository now. The extraneous sourcecode/bzr push I can't remember.
[04:55] <lifeless> spiv: any input for stub ?
[04:58] <spiv> lifeless: you fixed it for me last time.
[04:59] <spiv> stub: in my case, I think it was that my branches.conf had a section that matched the branch specifically, meaning that bzr didn't read the config for the containing directory (i.e. the config our wiki page tells you to add), so pqm-submit just falls back to assuming you want to submit to bzr.dev.
[05:00] <spiv> stub: deleting the unnecessary specific entry for my branch in branches.conf fixed it.
[05:00] <stub> [/home/stub/.canonical-bzr/launchpad/PostgreSQLSession] 
[05:00] <stub> push_location = sftp://sodium/home/warthogs/archives/stub/launchpad/PostgreSQLSession
[05:02] <stub> That seems to be the trick. So bzr push breaks bzr pqm-submit (at least in our setup)
[05:02] <spiv> It should still figure out the right push_location without that, because of the public_repository setting.
[05:07] <stub> Bug 54161
[05:07] <Ubugtu> Malone bug 54161 in bzr-pqm "If pqm_branch is not configured for branch path, check if it is configured for the repository path" [High,Confirmed]  http://launchpad.net/bugs/54161
[07:49] <stub> lifeless: Can I get pqm rights to merge to rocketfuel/zope/3.2? Or should I just do it manually  on balleny
[08:30] <stub> spiv: Does https://sodium.ubuntu.com/~andrew/paste/fileIAwj0M.html look familiar? Its on my librarian-layer branch, so I probably broke something.
[08:33] <sivang> morning
[08:35] <spiv> stub: is your Twisted up to date?
[08:35] <spiv> stub: because an old Twisted would cause that.
[08:36] <stub> Probably not. Ta.
[08:38] <sivang> stub: not sure if I told ya, but what was failing make schema was dash which is now default in edgy.
[08:40] <sivang> stub: (it's replacing bash)
[08:40] <spiv> Hmm, database/schema/Makefile does do a fair bit of shell stuff.
[08:42] <sivang> spiv: yes, so for edgy either we set up the shell at the top of each snippet or document somewhere to use bash instead of dash
[08:44] <spiv> sivang: or we make our shell usage posixly correct.
[08:51] <sivang> spiv: or that :)
[08:59] <Kamping_Kaiser> does anyone else find LP's karma system to be slightly insane at the moment?
[09:08] <Fujitsu> Kamping_Kaiser, what aspect of it?
[09:08] <spiv> sivang: https://sodium.ubuntu.com/~andrew/paste/filesj6IVH.html seems to make it work with bash and dash for me.
[09:09] <spiv> sivang: there may be a cleaner fix.
[09:10] <sivang> spiv: could forward that to me by email? sivan _AT_ ubuntu dot com?
[09:10] <Kamping_Kaiser> Fujitsu, the number of points going around - i went from 10k -> 110k in ~2 weeks of not doing anything... that means something i've done has recieved *lots* of extra points in the latest scoreshift.
[09:10] <Kamping_Kaiser> the numbers basicly meaningless :)
[09:10] <spiv> sivang: sure.
[09:13] <sivang> spiv: thanks
[10:01] <sivang> ah, good to have X back
[10:03] <bk> Hi, is there anyway to list all the packages contained in https://launchpad.net/distros/ubuntu/dapper/i386
[10:03] <carlos> morning
[10:03] <bk> the option +allpackages is not working
[10:05] <SteveA> good morning
[10:07] <sivang> mornig SteveA 
[10:24] <sivang> hey carlos 
[10:25] <carlos> sivang: hey dude!
[10:25] <carlos> seems like you live on this channel ;-)
[10:26] <sivang> carlos: hehe
[10:31] <Kamping_Kaiser> he does :)
[11:32] <sivang> spiv: are you going to commit that fix to RF btw?
[01:14] <carlos> I'm going to stop Staging for 5 minutes for a code update
[01:14] <carlos> please complain now or I will do it in 5 minutes
[01:22] <carlos> staging is back
[02:02] <sabdfl> is staging getting updated?
[02:02] <sabdfl> i landed a branch that was supposed to hide bounties a day or two ago - but it's not reflected on staging
[02:04] <stub> carlos: Are your staging code updates a private branch or have you merged launchpad/devel in there recently?
[02:05] <carlos> it's a private branch but I think it has also merged launchpad/devel as it was yesterday
[02:05] <carlos> stub: anyway, I did a bzr merge of my branch on whatever staging had
[02:06] <carlos> so any code changes until yesterday night should be there
[02:08] <carlos> hmmm
[02:08] <carlos> stub: seems like there is something wrong:
[02:08] <carlos> revno: 3819
[02:08] <carlos> committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[02:08] <carlos> branch nick: launchpad
[02:08] <carlos> timestamp: Sat 2006-07-22 18:25:33 +0100
[02:08] <carlos> that's the last merge on staging
[02:09] <stub> Hmm... booger.
[02:09] <carlos> sabdfl: anyway, your patch is on my branch
[02:09] <carlos> so it should be on staging atm
[02:11] <carlos> At least, this is latest merge I did from rocketfuel:
[02:11] <carlos>     merged: pqm@pqm.ubuntu.com-20060726101620-1e7c2aff80ab77f0
[02:11] <carlos>     committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[02:11] <carlos>     branch nick: launchpad
[02:11] <carlos>     timestamp: Wed 2006-07-26 11:16:20 +0100
[02:11] <carlos>     message:
[02:11] <carlos>       [trivial]  Hide bounty links till bounty tracker is in beta
[02:11] <stub> carlos, sabdfl: I think it is still updating daily. However, it is using chinstrap instead of sodium.
[02:11] <stub> I'll fix that ;)
[02:11] <sabdfl> thanks much :-)
[02:12] <carlos> stub: please, don't force any code update
[02:12] <carlos> stub: I will do it when I finish my testing session, ok?
[02:13] <stub> carlos: Ok. I'll leave you and Mark to fight over it ;)
[02:13] <sabdfl> i'm easy
[02:13] <sabdfl> in this one, specific case :-)
[02:13] <carlos> sabdfl: isn't your patch already included on my branch ?
[02:15] <stub> carlos: I've updated Makefile.staging anyway
[02:15] <carlos> stub: ok, thanks
[02:15] <SteveA> launchpad sprinters -> lunch
[03:14] <kiko-zzz> man you guys mailbombed me
[03:34] <matsubara> is it a bug that we can't add tags while reporting bugs?
[03:40] <kiko> yeah
[03:40] <kiko> and you can't query for tags either, can you?
[03:42] <niemeyer> kiko: You can, but it's less obvious than it should, IMO
[03:42] <kiko> really? how do you do it?
[03:43] <niemeyer> kiko: In the bugs page there's a list in the bottom left 
[03:44] <niemeyer> ?field.tag=something
[03:44] <kiko> I see
[03:48] <cprov> sorry, was offline for 30 minutes due a power outage in my area.
[04:01] <flacoste> kiko: do you think you'll be able to review tt-search today?
[04:01] <kiko> yes.
[04:01] <flacoste> kiko: great!
[04:02] <kiko> I almost did it last night but was very tired
[04:17] <Seveas> kiko, ping v3 
[04:17] <kiko> Seveas, I'm battling it out on the mailing list, waiting to chat to SteveA 
[04:17] <Seveas> kiko, ok
[04:18] <SteveA> kiko: hi
[04:20] <radix> tsu
[04:20] <radix> man, I never thought of using that as an emoticon.
[04:21] <kiko> hi
[04:21] <SteveA> http://www.inference.phy.cam.ac.uk/cjb/codepoints.html
[04:21] <SteveA> the snowman is pretty cool
[04:21] <SteveA> and I always appreciate calling someone a "dong"
[04:23] <kiko> matsubara, est atualizando?
[04:29] <SteveA> kiko: I'm ready to get ready
[04:29] <niemeyer> SteveA: I wonder how long does it take to write the last "thai character" with a pen..
[04:31] <carlos> sabdfl: I'm updating staging with latest rocketfuel code + my changes
[04:35] <jamesh> niemeyer: probably depends on how obsessive compulsive you are
[04:47] <kiko> matsubara, it's updating. slowly though as there is a lot to update
[04:47] <kiko> jamesh, the CVE thing is just a URL change
[04:47] <kiko> jamesh, willing to r+ a patch?
[04:48] <kiko> see email
[04:48] <matsubara> kiko: thanks.
[04:50] <jamesh> kiko: any reason you chose allcves.xml.gz rather than allitems.xml.gz?
[04:50] <jamesh> kiko: we won't get any of the candidate CVEs with that feed
[04:51] <jamesh> with CVEs, an issue is usually pretty old once it leaves candidate state
[04:52] <kiko> jamesh, uhhh, no.
[04:52] <kiko> you're absolutely right
[04:52] <kiko> I'll change that
[04:53] <jamesh> kiko: okay.  The code changes look trivial and correct.  If you change it to allitems.xml.gz and it still works, merge it.
[04:53] <kiko> will do. thank you.
[04:55] <carlos> staging is down atm because patch-67-04-0.sql (related with shipit) is taking ages to be applied...
[04:59] <ddaa> Znarl: can you have a look at whether pqm looks like it's stuck?
[05:05] <flacoste> kiko: i'm looking at bug 41972
[05:05] <Ubugtu> Malone bug 41972 in launchpad-support-tracker "You can linkbug to answered support request." [Medium,In progress]  http://launchpad.net/bugs/41972
[05:05] <flacoste> kiko: should we allow or disallow linking bugs to answered support requests?
[05:06] <flacoste> bug report is about the fact that the items aren't in the menu but using the +linkbug URL works
[05:06] <kiko> flacoste, I don't see why we shouldn't link a bug to an answered request. restricting that seems arbitrary.
[05:07] <flacoste> kiko: i agree
[05:07] <kiko> that's great.
[05:07] <flacoste> kiko: on a more general note, i see a source of problems between the menu and the views that implement them
[05:08] <kiko> go on?
[05:08] <flacoste> i mean that conditions on menu should really be duplicated in the view that implement the actions
[05:08] <flacoste> otherwise, that kind of bug will always occur
[05:09] <kiko> oh, I see what you mean. the pages accessible because they are registered in zcml may not be consistent with the menu
[05:09] <flacoste> for example, the Change Source Package and Edit Request have the same error 
[05:09] <flacoste> kiko: exactly
[05:10] <flacoste> Edit Request and Change Source Package are not available on Answered requests, but they will work using the URL directly
[05:15] <flacoste> kiko: as part of the 41972 fix, do you think Edit Request and Change Source Package should still be available on 'Answered' tickets?
[05:15] <kiko> well..
[05:16] <flacoste> currently, they are not, but the URL will work
[05:16] <kiko> what does edit request allow?
[05:16] <flacoste> changing the title and description of the tickets
[05:17] <flacoste> and the original description is lost (it's not saved in a comment like for bugs)
[05:17] <kiko> I'd allow changing them.. any reason why not?
[05:18] <flacoste> actually, at the sprint we talked about dropping that possibility entirely
[05:18] <flacoste> the rationale being that a ticket is more like a conversation than a bug report where you might want to consolidate comments in the description
[05:19] <kiko> well, that's orthogonal as to whether we should include that item in the menu or not :)
[05:19] <flacoste> indeed :-)
[05:20] <flacoste> so leave them all on then?
[05:20] <flacoste> makes it easier to fix mistakes
[05:20] <kiko> I'd do that yes. and I'd also bring the larger issue up with SteveA/mailing list
[05:21] <kiko> matsubara, I don't think -devel syncing is getting us anything at the moment
[05:21] <kiko> matsubara, given that it's in a repository now
[05:21] <matsubara> kiko: well, I never use that one anyway. 
[05:21] <kiko> okay, I'll kill it.
[05:22] <kiko> I think the only thing that was missing was for me to ssh in the first time 
[05:22] <kiko> which is kinda weird
[05:23] <elmo> ddaa: yes
[05:24] <elmo> pqm        399  0.0  3.6 210544 74568 ?        S    12:04   0:03              \_ python2.4 -t ./lib/importd/test_all.py
[05:24] <elmo> pqm       2826  0.0  0.0  14112  1048 ?        S    12:05   0:00                  \_ cvs server
[05:24] <elmo> pqm       2976  0.0  0.0  14112  1048 ?        S    12:05   0:00                  \_ cvs server
[05:24] <elmo> pqm       3383  0.0  0.0  14116  1048 ?        S    12:05   0:00                  \_ cvs server
[05:24] <elmo> pqm       3844  0.0  4.3 221992 89664 ?        Sl   12:05   0:02                  \_ /usr/bin/python2.4 -W ignore::DeprecationWarning:: /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/pqm-workdir/home/---devel/launchpad/lib/importd/baz2bzr.pyc 10 /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/pqm-workdir/home/---devel/launchpad/,,job_test/blacklist
[05:25] <flacoste> kiko: will send an email to the list about the menu/view inconsistency
[05:25] <elmo> ddaa: I can kill it if you want, dunno if I'm meant to tho.  that's not one of the known normal hangs
[05:26] <kiko> cool.
[05:26] <ddaa> elmo: I have been actively turning this code upside down in the last days
[05:26] <ddaa> so I think it's safe to add it to your repertoire of known hangs
[05:26] <elmo> ddaa: ok - and kill it?
[05:28] <ddaa> elmo: please do so
[05:28] <elmo> ddaa: done
[05:33] <ddaa> elmo: does pqm look idle again?
[05:35] <elmo> ddaa: it started doing another test and got in the same hang :/  shall I just forcefully kill the top level test runner?
[05:35] <ddaa> that's very weird
[05:35] <ddaa> you just did a third kill?
[05:36] <elmo> yeah, I keep killing them as they hang
[05:36] <ddaa> okay, it's a dead parrot
[05:36] <ddaa> I'll fix that urgently but just nuking away the baz2bzr test suite
[05:36] <elmo> kill the whole lot?
[05:36] <ddaa> elmo: please
[05:37] <elmo> it's really gone now
[05:38] <ddaa> elmo: it's likely to get wedged in the same way for the next merge
[05:38] <ddaa> until I nuke the code away
[05:38] <ddaa> will keep you posted
[05:38] <elmo> ok
[05:43] <elmo> what's with "DASHDASHDASHdevel" anyway?  pqm is so the home of old school tla fan boys
[05:43] <ddaa> elmo: it's robert's code
[05:44] <sivang> hehe
[05:44] <ddaa> write often, cleanup tomorrow
[06:04] <matsubara> ProgrammingError: ERROR:  function ensure_session_client_id("unknown") does not exist
[06:04] <matsubara> HINT:  No function matches the given name and argument types. You may need to add explicit type casts.
[06:04] <kiko> matsubara, make schema?
[06:04] <matsubara> did already
[06:05] <kiko> hmmm
[06:05] <matsubara> make schema && make run and when I tried to access the local instance it gave me that
[06:06] <jamesh> matsubara: try "dropdb session_dev"
[06:07] <jamesh> matsubara: the database/schema/Makefile has a comment "creating session database if necessary"
[06:12] <matsubara> now it works, thanks jamesh 
[06:20] <carlos> so
[06:20] <carlos> staging is broken atm
[06:20] <carlos> and I don't have enough permissions to fix that
[06:20] <jamesh> just so everyone is clear about this, carlos broke staging
[06:20] <ddaa> looks like this merge is going to go in smoothly
[06:20] <carlos> and anyway, tonight will be broken again until stub fixes it
[06:20] <carlos> jamesh: fuck off
[06:21] <ddaa> better let it break on staging, eh!
[06:21] <danilos> carlos didn't break staging, he "just" uploaded some code which broke staging
[06:21] <ddaa> ha right, carlos don't kill people, bullets do
[06:21] <carlos> :-)
[06:23] <ddaa> people, please pay attention for a minute
[06:24] <ddaa> if pqm starts breaking on the baz2bzr tests in importd in a way that becomes a serious problem
[06:24] <ddaa> just merge david/launchpad/nuke-baz2bzr-tests
[06:24] <ddaa> rs=SteveA
[07:07] <kiko> bradb!
[07:08] <bradb> yo :)
[07:08] <kiko-fud> fud but chat to you when I'm back
[07:09] <bradb> sounds good
[08:09] <ddaa> GOOD NEWS
[08:10] <ddaa> the bzr-native back-end for importd is operational
[08:10] <ddaa> rollout will happen early next week
[08:10] <ddaa> now, I have a long evening of celebration in front of me! 
[08:12] <kiko> wooo!
[08:14] <sivang> nice :)
[08:46] <jelmer> ddaa: congratulations!
[08:54] <LarstiQ> so _thats_ the reason the naming was switched to Bazaar? ;)
[08:55] <kiko> bradb!
[08:55] <bradb> kiko!
[08:55] <kiko> how's it going my man
[08:55] <kiko> feeling better?
[08:56] <bradb> pretty much
[08:56] <bradb> i switched to a dentist that uses lasers. he seems pretty cool.
[08:56] <kiko> wow
[08:56] <kiko> lasers
[08:57] <bradb> a root canal still seems in my future.
[08:57] <kiko> you brush those teeth
[08:57] <bradb> but, hard to say when
[08:57] <bradb> i do! twice a day, even.
[08:57] <bradb> and floss
[08:57] <kiko> and floss!
[08:57] <bradb> it's all about flossing at night though, instead of the morning
[08:57] <bradb> and fewer macadamia nuts
[08:57] <kiko> really?
[08:57] <kiko> macadamias are not particularly hard on the teeth are they?
[08:58] <bradb> er, macadamias, i meant
[08:58] <bradb> i.e. sugary cookies
[08:58] <kiko> oh. yeah, sugar is not good.
[09:02] <kiko> bradb, can you check out https://sodium.ubuntu.com/~andrew/paste/fileS7uGTV.html
[09:02] <kiko> it's a small change
[09:03] <kiko> containing one XXX and a few simplifications
[09:20] <kiko> hey stub 
[09:22] <bradb> hmph, i seem to have lost my irc connection 20 minutes ago.
[09:22] <kiko> bradb, did you get my /msg?
[09:22] <bradb> kiko: nope
 bradb, can you check out https://sodium.ubuntu.com/~andrew/paste/fileS7uGTV.html
 it's a small change
 containing one XXX and a few simplifications
[09:22] <kiko> matsubara, did you see stub's latest email to carlos on launchpad-list?
[09:23] <bradb> kiko: ok, just a couple mins while i finish this email
[09:24] <kiko> sure thing.
[09:25] <matsubara> kiko: any particular thing I should pay attention to?
[09:25] <kiko> matsubara, the session database bustage?
 matsubara: try "dropdb session_dev"
 matsubara: the database/schema/Makefile has a comment "creating session database if necessary"
 now it works, thanks jamesh
[09:25] <matsubara> kiko ^^
[09:26] <matsubara> that fixed it.
[09:26] <kiko> aha!
[09:39] <bradb> kiko: maybe that method would be easier to follow if it were like:
[09:39] <bradb> if binarypackagename:
[09:39] <bradb>     ...
[09:39] <bradb> else:
[09:39] <bradb>     ....
[09:40] <kiko> bradb, not really, though I could break it into separate methods.
[09:40] <kiko> bradb, my questioning was more if selectFirst would actually work there, AND if my XXX is relevant.
[09:46] <bradb_> my wireless sucks
[09:46] <bradb_> kiko: presumably you didn't see my comments?
[09:46] <kiko> heh
[09:46] <kiko> I did
[09:46] <kiko> well, only one comment
[09:46] <bradb_> so, to recap
[09:47] <bradb_> i think it would read easier if it were formatted as:
[09:47] <bradb_> if binarypackagename:
[09:47] <bradb_>     ...
[09:47] <bradb_>     return ...
[09:47] <bradb_> else:
[09:47] <bradb_>     ...
[09:47] <bradb_>     return ...
[09:47] <bradb_> and that the variables should be called source_package_publishing and published_package, instead of both being called publishing.
[09:47] <kiko> bradb_, again, else: after return makes no sense..
 bradb, my questioning was more if selectFirst would actually work there, AND if my XXX is relevant.
[09:48] <bradb_> kiko: why doesn't else after a return make sense?
[09:49] <kiko> because it's extra text and indentation that doesn't add any clarity, and because that's not what's confusing about the method
[09:49] <kiko> my question is more if selectFirst could be used there, and if the XXX is relevant.
[09:52] <bradb_> kiko: it's clearer to me anyway, because it makes it easier to see that there's a return in the middle of the method. the distribution.txt test should be able to tell you if .selectFirst will work.
[09:52] <matsubara> bradb_: is there any bug open to implement a milestone command in the email interface?
[09:53] <bradb_> matsubara: doesn't look like it
[09:55] <matsubara> matsubara: ok, thanks.
[09:57] <bradb_> kiko: the first selectFirst is missing an orderBy, btw
[09:58] <kiko> good catch
[09:59] <kiko> bradb_, and it's an actual bug, too!
[09:59] <bradb_> or more, the code around it
[10:01] <Seveas> kiko, have you been able to fight with SteveA?
[10:02] <kiko> Seveas, he said he's fine with it
[10:02] <kiko> I am mustering the guts to go out and do it
[10:02] <Seveas> hehe, good luck ;)
[10:02] <kiko> since I have to change this in multiple places
[10:02] <kiko> sure thing
[10:03] <Seveas> let me know when you did it, it requires some configuration on my side after that to prevent an inital mailflood
[10:03] <kiko> sure
[10:03] <Seveas> (well, it is prevented now by making sure NO new bug reports are sent in here, will have to undo it properly)
[10:03] <bradb_> kiko: it looks to me that non-context is a bug there. it looks like it could happily return a published binary/source package name combo from another distribution, which would be a bug.
[10:05] <kiko> bradb_, so should I restrict to distribution=self?
[10:05] <bradb_> kiko: first, i'd write a test to verify. i /think/ we have enough sample data to even make it work.
[10:05] <bradb_> which is to say, make it break
[10:14] <matsubara> kiko: do you know if salgado was working on something related to this: OOPS-208A141?
[10:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/208A141
[10:18] <kiko> matsubara, hmmm, that's very strange. I don't know.
[10:18] <kiko> it seems to be complaining that the user would have two approved.. well, actually
[10:18] <kiko> salgado's change /would/ modify that
[10:18] <kiko> I'm not sure it would fix the problem though
[10:19] <bradb_> kiko: hm, i don't think we have the test data to write a test for that bug, atm
[10:19] <kiko> bradb_, what are we missing -- packages?
[10:39] <bradb_> lost connection again, even though i'm sitting /beside my router/
[10:39] <bradb_> kiko: in case you missed it, the failure can be reproduced by 1. adding a current release for gentoo, and 2. filing a bug on bp linux-2.6.12
[10:40] <kiko> bradb_, cool.
[11:28] <cprov> kiko: have you seen https://sodium.ubuntu.com/~jamesh/oops.cgi/2006-06-11/A728 about the Build/BuildQueue prejoin hack ? Do have a minute to talk about it ?
[11:29] <kiko> not yet, lemme see
[11:30] <cprov> kiko: check query 17 & 21, for instance.
[11:30] <kiko> cprov, okay, the problem is the following: you need to change the way you grab the data.
[11:30] <cprov> kiko: how ?
[11:31] <kiko> cprov, well...
[11:31] <kiko> currently what you do is grab builds and then for each build you traverse over a join column to buildqueue, right?
[11:31] <cprov> kiko: the query 21 should not be issues since the 17 lready populated the cache with BQ.build=202097 row, isn't it ?
[11:32] <kiko> cprov, the cache is only accessed by id. if you look at that query it is specifying a build id in the where clause..
[11:32] <kiko> cprov, what template is that?
[11:33] <cprov> kiko: ahhh, I see
[11:33] <cprov> builds-list.pt
[11:34] <kiko> mmm, a batch.
[11:34] <cprov> kiko: can't I change BQ.build to be an alternateID or something similar, would it help ?
[11:34] <kiko> it could help, but I doubt it
[11:34] <kiko> cprov, is it a singlejoin?
[11:35] <cprov> kiko: yes, do we have it from upstream sqlobject ?
[11:35] <kiko> yes, but that won't help you here.
[11:35] <cprov> kiko: yeah, I was about to say that ...
[11:35] <kiko> cprov, so what causes those queries to be issued? is it traversing through to buildqueue_record?
[11:36] <cprov> kiko: exactly, a selectOne property
[11:36] <kiko> that's bad.
[11:37] <cprov> singleJoin could make the code saner, even if doesn't help to not issue multiple queries, do you agree ?
[11:38] <kiko> not really
[11:38] <kiko> it wouldn't improve things very much
[11:38] <jordi> kiko: wow I got a weird mail involving you today
[11:38] <kiko> involving ME?
[11:39] <kiko> cprov, one thing you can do which is easy, is caching the buildqueue record so you at least don't fetch it 3 times
[11:39] <kiko> cprov, putting it into a dictionary
[11:39] <jordi> someone who saw pics of us in Montral I assume, and thought you were someone she knew in 1997, in Spain
[11:39] <jordi> german girl who was 17 at the time.
[11:39] <jordi> I told her it wasn't you most probably, but she now has your website url. Maybe I just started something really romantic. :)
[11:40] <cprov> kiko: cached_property ?
[11:42] <cprov> jordi: wow, don't say things like that to him, he just lost the track of my question ;) see ?!
[11:43] <jordi> X)
[11:43] <kiko> cprov, no, putting it in a dictionary
[11:43] <kiko> jordi, what girl?
[11:44] <kiko> I lived in spain in 1998, not 1997.
[11:44] <kiko> cprov, in the view. and then pulling it out using python: 
[11:44] <kiko> cprov, I don't like that very much, though, so...
[11:44] <kiko> cprov, I have another idea :)
[11:44] <jordi> kiko: woa, I had no idea
[11:44] <jordi> kiko: natja?
[11:44] <kiko> hmmmm
[11:45] <jordi> she met you one night in the costa brava. :)
[11:45] <cprov> kiko: okay, other than view.dict  ?
[11:45] <kiko> cprov, yeah. I mean view dictionary is better than nothing, but the /right/ way to do this is to assemble a new object type, I think.
[11:46] <kiko> jordi, hmmm. probably not me. costa brava? you mean figueires, etc?
[11:46] <cprov> kiko: BuildCollection, BuildBatch or so ?
[11:46] <jordi> kiko: yup
[11:46] <kiko> yeah, maybe just CompleteBuild in the view class
[11:46] <kiko> jordi, I don't think I've ever been there. are you sure you're not replying to spam? :)
[11:47] <jordi> no, totally :)
[11:47] <jordi> too bad kiko, she was deeply in love with you!
[11:47] <kiko> cprov, so that build could contain data from the build and from the buildqueue entries. and you'd iterate over /that/
[11:48] <kiko> jordi, hey, tell her to write me :)
[11:48] <cprov> kiko: good point, I'll try to implement something in this direction, thank you :)
[11:48] <kiko> cprov, I just don't know how that would interact with batching
[11:49] <kiko> cprov, because you would need to do this for rendering the batch. basically, you'd need to convert the items in the batch to something else. hmmmm. I think I know how to do that
[11:50] <cprov> kiko: can I extend the batch specially for Builds ?
[11:50] <kiko> cprov, no, instead, don't use view/batchnav/currentBatch.
[11:51] <kiko> cprov, use view/convertedBatch
[11:51] <kiko> which internally converts the items in view/batchnav/currentBatch to these CompleteBuild monsters.
[11:51] <jordi> kiko: I was thinking exactly that :)
[11:52] <kiko> jordi, I guess you don't have pictures or anything of her, eh?
[11:52] <kiko> :)
[11:52] <cprov> kiko: uhm, makes sense ...
[11:52] <kiko> or view/completeBuilds
[11:52] <kiko> anything like that -- the names are less important
[11:53] <kiko> cprov, then, what you do is you do a query on BuildQueue
[11:53] <kiko> and then group BuildQueues by Build
[11:53] <kiko> cprov, this is similar to what I do in browser/bugcomment.py
[11:53] <kiko> cprov, check out that file -- you'll see that I grab all MessageChunks and then group them into BugMessage objects.
[11:53] <kiko> you'll need to do something similar
[11:54] <jordi> kiko: too bad, eh? :)
[11:54] <cprov> kiko: I see, I need to iterate over currentBatch of Builds, find out which BQ I want, fetch them and finaly glue them in the completeBuild list properly
[11:54] <kiko> but it will be less complicated I believe in your case because you don't need to glue message chunks together! just grab a build queue and a build.
[11:54] <kiko> cprov, hmmm, no, come to think of it, that won't work. hmmmm. 
[11:55] <kiko> well, it would work
[11:55] <kiko> it'd just require an extra query
[11:55] <kiko> there is a way to do this using just one query
[11:55] <kiko> but to do that
[11:55] <kiko> you'd need to put CompleteBuilds into your batch
[11:55] <kiko> which probably requires subclassing batchnavigator to be efficient
[11:56] <kiko> gah.
[11:56] <cprov> kiko: yes, what I thought before, but looks too complicated for now, isn't it ?
[11:56] <kiko> cprov, so yes, I think your approach will be an improvement -- two queries in the page instead of 100
[11:56] <kiko> cprov, yes. I think it's worth a try. if we still have perf issues there, we'll deal with them.
[11:57] <cprov> kiko: okay, it's kind of 3 x DEFAULT_BATCH_SIZE queries ...
[11:57] <cprov> kiko: indeed, will comment the bug and start working, thank you again.
[12:02] <kiko> okay, cool.
[12:03] <jordi> kiko: I didn't know you lived in Spain. Where?
[12:06] <kiko> jordi, lleida.
[12:06] <jordi> oh I see.
[12:06] <jordi> don't tell me you worked at lleida.net :)
[12:09] <cprov> kiko: dude, don't forget my review for builder sec adapters, elmo is going to kill me if we don't release it next week :(
[12:09] <kiko> yeah
[12:10] <cprov> good, tks, let's look for some dinner ... see you later, or tomorrow