[00:08] <jml> mwhudson, when would be a good time for a call?
[00:09] <mwhudson> jml: now would be pretty good
[00:09] <jml> mwhudson, ok. I'll grab my headset
[00:10] <mwhudson> me too
[00:11] <mwhudson> jml: what tech do you want to try today?
[00:11] <jml> mwhudson, let's give skype a chance
[00:11] <mwhudson> ok
[00:11] <mwhudson> maybe i'll try it with pasuspender today
[00:14] <mwhudson> ffs
[00:14] <mwhudson> not working at all
[00:15] <jml> mwhudson, I can call your landline, maybe.
[00:15] <mwhudson> jml: hm, can i call you on one?
[00:15] <mwhudson> i'd rather use my cell
[00:15] <jml> mwhudson, sure.
[00:15] <jml> gimme a sec to get the number
[00:16] <wgrant> Have you guys tried Empathy's voice chat?
[00:26] <jml> wgrant, no, I haven't.
[00:32] <wgrant> I found that it worked pretty well.
[00:44] <mwhudson> jml: http://pastebin.ubuntu.com/345035/
[00:53] <mwhudson> jml: oh heh
[00:53] <mwhudson> jml: i have a branch that upgrades us to bzr 2.1b4
[00:53] <mwhudson> jml: and removes some cruft
[00:53] <mwhudson> jml: want to review that?
[00:53] <jml> mwhudson, yes please
[00:54] <mwhudson> jml: ok, my ec2test of -vv codehosting just came back with 35 errors so i should fix that first :-)
[00:54] <mwhudson> and also have lunch
[00:54]  * mwhudson noms
[00:54] <jml> mwhudson, ok. :)
[01:33] <mars> clever code:  print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32']
[02:19] <mwhudson> mars: that's the pejorative use of the word 'clever'
[02:42] <jml> I'm reminded of Alan Perlis' thing about debugging
[02:43] <jml> also, pretty much all of the K&R book :)
[02:43] <jml> oh wait
[02:44] <jml> that wasn't Perlis, that was Kernighan
[02:44] <jml> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan
[02:44] <jml> that means it's lunch time.
[03:24] <jtv> Did PQM break overnight?
[03:25] <wgrant> Can someone please ec2land https://code.edge.launchpad.net/~wgrant/launchpad/less-crackful-ddeb-tests/+merge/16393 for me?
[03:26] <jtv> wgrant: I'll try that
[03:26] <wgrant> jtv: Thanks.
[03:27] <jtv> wgrant: that's on the way in.
[03:52]  * mwhudson EOYs, more or less
[03:52] <mwhudson> will be around for a bit, otherwise see you in 2010
[03:57] <jtv> mwhudson: happy holidays, see you on the other side
[07:14] <jml> good night all
[08:57] <wgrant> buildbot hates either me or stub :(
[08:57] <wgrant> It also stutters.
[09:15] <wgrant> Ah, thanks.
[09:15] <wgrant> stub: ^^
[09:21] <stub> ?
[09:21]  * stub was offline and doesn't have scrollback
[09:22] <wgrant> stub: Just thanking you for the explanation of the buildbot explosion.
[10:02] <jtv> wgrant: your less-crackful-ddeb-tests branch has landed
[10:03] <wgrant> jtv: I saw that. Thanks.
[10:08] <wgrant> bazaar.launchpad.net could do with a more informative downtime page.
[10:10] <jtv> wgrant: they wouldn't let me add a link to sourceforge as an alternative, sorry
[10:44] <jtv> stub: tests log into the db as "launchpad" by default, right?
[10:44] <stub> jtv: Yes
[10:45] <jtv> Gah.  I just created a table in my branch; I granted select/insert on it to "launchpad" in security.cfg and the _template dbs, and yet my test gets a permissions failure on an insert to that table.
[10:51] <jtv> stub, any ideas on what I'm missing?
[10:52] <stub> make schema?
[10:52] <stub> Oh - you manually granted
[10:52] <stub> Did you manually grant access to the sequence too? make schema is easier.
[10:54] <jtv> head -> keyboard
[10:55] <jtv> would it be possible for me to get a db patch number assigned now, before review?  that way I can have it run as part of the make schema
[10:57] <jtv> stub: (I could just pick one for now, but somewhere down the line I'd cause myself trouble)
[10:57] <stub> Usually people use -99 or something
[10:58] <stub> I could give you -22 now, but you would have to tell me what you are doing for my notes.
[10:59] <jtv> stub: np.  I'm creating a IBuildFarmJob implementation so we can dispatch jobs (generation of translation templates based on branch changes) to the build farm.
[10:59] <jtv> stub: it's a sibling to BuildPackageJob
[10:59] <stub> We are building farms in addition to packages?
[11:00] <jtv> moooo
[11:00] <jtv> the build farm is being generalised to do other jobs than just building packages, and one of them is this re-generating of translation templates business
[11:00] <stub> 2207-22-0.sql
[11:01] <jtv> thanks
[11:08] <Aim_> maxb, elmo: i find apache a horrible pig ^^
[11:24] <elmo> Aim_: then you're going to be horrified by launchpad itself.  apache will be the least of your problems.  *shrug*
[12:18] <Aim_> elmo: i know :(
[12:18] <Aim_> dont get me wrong, i like python
[12:18] <Aim_> but zope... something a bit painfull
[12:18] <Aim_> somethimes*
[12:18] <Aim_> sigh
[12:19] <Aim_> s/th/t/
[13:59] <jtv> al-maisan: when you're done with what you're doing, will I need to implement pendingJobsQuery in my own buildfarmjob type?
[14:29] <al-maisan> jtv: yes
[14:29] <al-maisan> that's the idea
[14:30] <jtv> al-maisan: I had a similar approach to yours in mind for the specific_job_classes...  Weren't you also playing with gathering those automatically earlier?
[14:32] <al-maisan> jtv: yes and noodles775 also had some ideas, see lines 25-38 in http://pastebin.ubuntu.com/345305/
[14:33] <jtv> al-maisan: thanks, more to read.  Probably for tomorrow.  :-)
[14:35] <al-maisan> jtv: yeah .. the upshot is that the current "job dispatch time estimation" branch is too big and needs to be split in manageable chunks
[14:38] <jtv> al-maisan: which reminds me.  I can now create my own buildfarmjob objects (with associated buildqueue & job entries).  I can unit-test my new classes, as well as navigation between those 3 types of records... anything else you can think of that I could start testing now that I have that?
[14:41] <al-maisan> jtv: nothing immediate comes to mind .. once I have the branch that introduces the pendingJobsQuery() interface method you could implement that and unit test it?
[14:41] <jtv> al-maisan: definitely, yes
[14:41] <al-maisan> it will probably take me another 90 minutes to put up the merge proposal
[14:42] <al-maisan> .. and then it needs to be reviewed
[14:50] <jtv> al-maisan: nice... that could be something useful for me tomorrow then.
[14:51] <al-maisan> yup
[14:57] <aleksander_m> In the Launchpad Development webpage, section "Getting", it is said that in order to get the source of Launchpad you need to get the rocketfuel-setup script from a bazaar branch, and then execute it
[14:57] <aleksander_m> unfortunately, the given URL for the branch is not found...
[14:58] <aleksander_m> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup
[14:58] <aleksander_m> any idea?
[15:03] <jtv> aleksander_m: ouch, you're right...  and the person I'd normally ask isn't here at the moment
[15:04] <aleksander_m> jtv: I see
[15:04] <jtv> salgado-lunch: as an arbitrary victim in a more suitable timezone, I am hereby notifying you that aleksander_m just discovered that the link to rocketfuel-setup on the "Getting" page is broken
[15:36] <aleksander_m> jtv: salgado is back
[15:36] <salgado> not really, I just need to sort out some stuff but I didn't have lunch yet
[15:36] <jtv> aleksander_m: too late, looks like he read my message :-)
[15:37] <aleksander_m> ah ;-)
[15:42] <salgado> aleksander_m, but I'll fix the link once I come back
[15:43] <aleksander_m> salgado: thanks!
[16:00] <mars> anyone else notice that the bzr 2.1b4 upgrade broke 'make' in new branches?  Apparently it needs Pyrex
[16:09] <mars> and 'make schema' now depends on libapr1-dev, which I also do not have installed.  When did that happen?
[16:37] <mars> It appears our development environment may be broken on Jaunty.  That explains all of the 'make' errors I was getting.
[16:38] <mars> launchpad-soyuz-dependencies: Depends: dpkg (>= 1.15.4) but 1.14.24ubuntu1 is installed.
[16:40] <mars> I assume that means launchpad-developer-dependencies is only installable on Jaunty if we backport dpkg.
[21:18] <wgrant> mars: Argh.You can fix that by just copying dpkg, debhelper and devscripts from Hardy to Jaunty.
[21:19] <mars> wgrant, Hardy to Jaunty?
[21:20] <wgrant> mars: Yes. We backported the necessary versions from Karmic to Hardy.
[21:20] <wgrant> They'll work fine on Jaunty too.
[21:21] <mars> wgrant, cool, thanks for the tip
[21:59] <maxb> I guess there aren't any library issues that could make it need a rebuild for jaunty?
[22:02] <wgrant> maxb: dpkg doesn't have a huge number of binary dependencies.
[22:31] <maxb> Think I should just go ahead and copy the debsrc3.0 backports to jaunty then?
[22:33] <wgrant> maxb: I would say so.