[00:00] <mwhudson> i was thinking of devel r9693
[00:00] <wgrant> harness is the only place that uses script.zcml directly, so I think it's the right fix.
[00:01] <mwhudson> so what was i doing?
[00:01] <mwhudson> ah yes, creating a bug with zillions of duplicates
[00:02] <wgrant> 9693 looks innocent enough.
[00:11] <thumper> wgrant: I have a bug for you :)
[00:12] <thumper> wgrant: SourcePackage needs to be renamed to something like DistroSeriesSourcePackage
[00:12] <wgrant> thumper: It does. Everyone knows that :(
[00:12] <thumper> :)
[00:12] <thumper> and no-one wants to do it
[00:13] <thumper> my JFDI juice is all used elsewhere I'm afraid
[00:13]  * thumper signs off for a while
[00:13] <wgrant> mwhudson: My 300-dupe bug only takes a couple of seconds to render locally :(
[00:14] <mwhudson> wgrant: same here!
[00:14]  * wgrant checks subscriber counts on all of 417842's dupes.
[00:15]  * mwhudson adds a couple hundred subscribers to the bug too
[00:16] <mwhudson> wgrant: do you want to submit a branch that comments out the script.zcml from harness?
[00:17] <wgrant> mwhudson: I will, once I work out if there are any tests.
[00:17] <wgrant> I presume not.
[00:19] <mwhudson> i think you're probably right
[00:19] <mwhudson> thanks
[00:20] <mwhudson> still <4s
[00:21] <wgrant> There are only 454 (public) subscribers on the dupes.
[00:22] <wgrant> And 254 on the master.
[00:24] <mwhudson> well, i guess i'm going to apply my SEP field now
[00:24] <mwhudson> wgrant: do you know if a bug is filed?
[00:24] <wgrant> That sounds wise.
[00:24] <wgrant> I haven't seen one.
[00:25] <wgrant> Alright.
[00:25] <wgrant> Why, exactly, has my query count jumped from 140 to 215 to 426.
[00:25] <wgrant> The only change I made was unsubscribing from the master between the first two.
[00:25] <wgrant> And now down to 294 again.
[00:30] <mwhudson> frikking wifi
[00:30] <mwhudson> wgrant: have you filed such a bug or shall i?
[00:31] <wgrant> mwhudson: Please do. I can't see the details of the OOPS.
[00:31] <mwhudson> ok
[00:32] <mwhudson> huh wow the bug loaded on prod
[00:32] <wgrant> How quickly?
[00:32] <mwhudson> now was that because i'm not logged in on that machine, or because it's prod...
[00:32] <mwhudson> heh
[00:33] <mwhudson> aaadh
[00:33] <mwhudson>     At least 116 queries issued in 19.42 seconds
[00:33] <mwhudson> so it just sneaked in :-)
[00:33] <wgrant> ++oops++ it!
[00:33] <mwhudson> yeah, it timed out the second time
[00:33] <wgrant>     At least 241 queries issued in 14.22 seconds
[00:35] <mwhudson> i suspect the edge appservers are more loaded than the lpnet ones right now
[00:35] <wgrant> lpnet got some more added recently, didn't it?
[00:35] <mwhudson> yar
[00:36] <mwhudson> hm now it loaded for me on edge
[00:36] <mwhudson> still not logged in
[00:36] <wgrant> My lpnet time was logged in.
[00:46] <mwhudson> wgrant: https://bugs.edge.launchpad.net/malone/+bug/471974 fwiw
[00:46] <mup> Bug #471974: bug timing out without much sql time <timeout> <Launchpad Bugs:New> <https://launchpad.net/bugs/471974>
[01:09] <wgrant> Hmmm. I cannot branch devel locally; it fails with obscure bzr errors. I wonder if the FS corruption last night was more extensive than I suspected...
[01:15]  * wgrant is amused that even UX people don't like indicator-applet.
[01:46] <Ursinha> anyone online up to explain me a difference between zope.schema.Datetime and canonical.database.datetimecol.UtcDateTimeCol?
[01:46] <Ursinha> can I make the first timezone aware? os is it already?
[01:47] <Ursinha> s/a difference/the difference/
[01:54] <wgrant> The first is an interface field, the second is a Storm/SQLObject type?
[01:55] <wgrant> IIRC z.s.Datetime knows about timezones.
[01:56] <wgrant> Actually, I guess it doesn't really have to care.
[01:58] <Ursinha> wgrant, I thought that was the inverse
[01:58] <Ursinha> UtcDateTimeCol aware of tz and Datetime not
[01:58] <Ursinha> ?
[01:59] <wgrant> Ursinha: They are not the same sort of thing,
[01:59] <Ursinha> wgrant, I'm trying to understand this error: TypeError: can't compare offset-naive and offset-aware datetimes
[02:00] <wgrant> Ursinha: Where does the z.s.Datetime come from?
[02:01] <Ursinha> a field declared in an interface
[02:01] <wgrant> But the data comes from a form?
[02:01] <Ursinha> wgrant, no, it's calculated
[02:02] <wgrant> Ursinha: I think your calculation is just returning a naive datetime.
[02:03] <Ursinha> wgrant, let me see
[02:10] <Ursinha> wgrant, my calculation is Max(POFile.date_changed)
[02:13] <wgrant> Ursinha: And what are you comparing it against?
[02:14] <Ursinha> wgrant, POFile.date_changed
[02:14] <wgrant> Huh.
[02:15] <wgrant> They should both be tz-aware! pastebin the code?
[02:15] <Ursinha> hehe
[02:16] <Ursinha> I'd have to paste a lot of code :) I'm doing a change in translations that adds a last changed column to the +translations list
[02:17] <Ursinha> so I added a last_changed_date = Datetime in an interface and it carries that Max(foobar) later in the code
[02:19] <wgrant> Unless you're doing something pretty strange, the interface will not matter.
[02:19] <wgrant> ('strange' including using form infrastructure or lazr.restful)
[02:39] <Ursinha> wgrant, self.assertEquals(type(psl.last_changed_date.tzinfo), type(pofile2.date_changed.tzinfo)) returned AssertionError: <type 'NoneType'> != <class 'pytz.UTC'>
[02:40] <Ursinha> wgrant, mission now is understand why
[02:40] <wgrant> Ursinha: What is this psl?
[02:40] <Ursinha> wgrant, productserieslanguage
[02:41] <wgrant> Ursinha: is last_changed_date a new property, or a new direct DB column?
[02:41] <Ursinha> wgrant, a new property
[02:43] <wgrant> Ursinha: What's the code behind it?
[02:43] <wgrant> (timezones suck. hate hate hate)
[02:47] <Ursinha> wgrant, the changes I did in interface/productserieslanguage.py: http://paste.ubuntu.com/308142/
[02:48] <wgrant> Ursinha: In non-Zopey Python, the interface does not matter except for security.
[03:04] <Ursinha> wgrant, this is the bit I've changed that calculates that property: http://paste.ubuntu.com/308148/
[03:06] <Ursinha> wgrant, weird thing is that for one template, the first case, it doesn't fail, for the second it does, so Max modifies or returns something different of what's stored? I'm trying to figure out where I am losing that bit of timezone
[03:32] <wgrant> Ursinha: Sorry, had to run off for a while. If you look at UtcDateTimeCol, you can see it injecting the timezone manually. I'm not sure how much of that class will be used when you're not actually retrieving an object, just a field.
[03:33] <Ursinha> wgrant, I could see here that max returns the datetime without tz set
[03:36] <Ursinha> wgrant, actually I thought that the tz info was stored in the database, but that in fact wouldn't make much sense, since the whole system is UTC
[03:37] <wgrant> Ursinha: Right, they are all just stored timezoneless as UTC.
[03:37] <wgrant> Ursinha: Aha. Have a look at lp.code.model.branch.BranchCloud.getProductsWithInfo
[03:37]  * Ursinha looking
[03:38] <wgrant> (particularly the XXX at the end)
[03:39] <wgrant> That suggests that you're not doing anything wrong.
[03:39] <Ursinha> wgrant, that was exactly what I thought I was doing
[03:39] <Ursinha> wgrant, thank you muchly
[03:39] <Ursinha> wgrant, are you going to uds?
[03:40] <wgrant> Ursinha: I'm not.
[03:40] <Ursinha> wgrant, I'll never meet you in person
[03:40] <Ursinha> :/
[03:40] <wgrant> Ursinha: I guess what I would do here is just set tzinfo to UTC before I use it.
[03:40] <wgrant> Ursinha: Maybe another UDS, I suppose.
[03:45] <Ursinha> wgrant, I wonder if setting this is needed to what I'm doing
[03:47] <wgrant> Ursinha: If you want to compare two datetimes, you need them to be either both naive or both not.
[03:48] <Ursinha> wgrant, I only do this in the tests
[03:48] <Ursinha> wgrant, with the assert
[05:09] <wgrant> stub: Around for a re-review?
[05:23] <stub> wgrant: yes
[05:24] <stub> wgrant: I'll need some details - don't see anything on my review list.
[05:25] <wgrant> stub: I'm finding a link. I haven't worked out how I'm meant to request your review yet.
[05:25] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection-db/+merge/14304
[05:26] <stub> wgrant: You click on 'request another review', type my name (so it appears on my list) and type 'db' (although that doesn't really matter)
[05:26] <stub> And again for jml
[05:27] <wgrant> stub: Ah, thanks. Done.
[05:27] <stub> So integer enum was ok or better than text for format?
[05:27] <wgrant> Yes.
[05:28] <wgrant> There are only three possible values, and it seems neater.
[05:28] <stub> Table name discussed with soyuz  and SourcePackageFormatSelection seems best?
[05:29] <wgrant> Yes.
[05:29] <wgrant> There is an existing SourcePackageFormat enum which will be renamed to SourcePackageType soon.
[05:29] <wgrant> (it's DPKG vs. RPM, which is obviously not particularly useful at this point)
[05:32] <stub> wgrant: All fine & reviewed. Need jml's approval too.
[05:33] <wgrant> stub: Great. I should renumber the patch now?
[05:33] <stub> Any time before landing is fine.
[05:33] <stub> It won't worry jml's review
[05:33] <wgrant> Thanks.
[06:52] <noodles775> Morning
[08:27] <adeuring> good moring
[09:06] <jml> good morning
[09:22] <jml> wgrant, patch reviewed.
[09:24] <noodles775> yay, thanks jml.
[09:25] <noodles775> (and thanks wgrant *again* for your work!)
[10:02] <wgrant> Thanks jml.
[10:14] <bigjools> wgrant: did you by any chance check to see if my fix for the security hole worked?  no worries if not, I am doing some Q/A anyway
[10:16] <wgrant> bigjools: I didn't. I might as well try now.
[10:19] <wgrant> bigjools: You didn't mark the fields readonly, then?
[10:22] <bigjools> wgrant: no, just fixed the zope permissions
[10:24] <wgrant> bigjools: Still an insufficient fix in my opinion, as I can cause OOPSes.
[10:26] <wgrant> bigjools: staging is still broken, but I presume that's because db_lp is borked.
[10:27] <bigjools> it's not an oops though is it?
[10:27] <wgrant> https://staging.launchpad.net/ubuntu/+source/e2fsprogs/1.41.9-1ubuntu3/+build/1307119
[10:27] <wgrant> It is.
[10:27] <bigjools> permission failures should not be oops, they're routine
[10:27] <wgrant> If I set the status to something bad, I can make my builds OOPS.
[10:27] <wgrant> It's not a permission failure.
[10:28] <wgrant> It's just that normal users have launchpad.Edit over their builds.
[10:28] <bigjools> oh you can set your own builds
[10:28] <bigjools> right
[10:28] <wgrant> Which means they can corrupt internal LP state.
[10:28] <bigjools> hmmm
[10:28] <bigjools> ok it can be fixed next cycle
[10:28] <wgrant> Yup.
[10:28] <wgrant> The big issue is fixed now, at least.
[10:28] <bigjools> thanks for checking!
[10:29] <wgrant> np
[10:29] <wgrant> Thanks for fixing.
[10:30] <wgrant> bigjools: Thanks for the review. Are you going to land it?
[10:30] <bigjools> wgrant: stub will
[10:30] <wgrant> bigjools: Ah, great.
[10:30] <bigjools> he sometimes does a mega-landing of loads of patches
[10:31] <bigjools> actually that was before we had db-devel, so he's just being kind to you this time :)
[10:32] <wgrant> I see.
[10:32] <wgrant> noodles775: Thanks.
[10:33] <noodles775> wgrant: ... to you too :)
[10:34] <stub> What am I landing?
[10:35] <stub> I've got nothing pending to land so no point blocking on me.
[10:47] <bigjools> stub: wgrant's db patch
[10:47] <bigjools> you said you'd land it in the MP ...
[10:48] <wgrant> Presumably "[it] Can land", not "[I] Can land"
[10:51]  * noodles775 lands it on db-devel.
[10:51] <stub> Anyone can land. I'll do it since ...
[10:51] <stub> or maybe someone will beat me too it while I'm typing ;)
[10:51] <noodles775> stub: oh, I hadn't started, but can continue... :)
[10:52] <bigjools> stub: I am too used to you landing db patches for us :)
[10:54] <deryck> Morning, all.
[10:55] <noodles775> Morning deryck
[10:55] <wgrant> Thanks $LANDER!
[10:55] <noodles775> heh
[13:00] <jtv> What classes that we use are not in the lp or canonical modules but contain DBEnumVariable instances?
[13:04] <Ursinha> hi noodles775 :)
[13:04] <noodles775> Hi Ursinha!
[13:05] <stub> jtv: Storm stuff
[13:05] <stub> jtv: https://pastebin.canonical.com/24251/
[13:05] <stub> Doen't seem that helpful :-P
[13:06] <jtv> stub: because it strikes me that we simply don't have enough LP objects in memory to reference all those DBEnumVariables
[13:06] <Ursinha> noodles775, I tagged the bugs that are rollout blockers properly, so we can check all status doing a lp search
[13:06] <Ursinha> noodles775, do you think this is useful?
[13:07] <Ursinha> noodles775, it's an old idea from matsubara and I
[13:07] <jtv> stub: it does eliminate a lot, I guess.
[13:07] <Ursinha> noodles775, I've added the search url to the wiki page
[13:07] <noodles775> Ursinha: yeah, definitely - I've been using it since you updated the CRB page with the link. It's great for an overview, but doesn't allow me to annotate things (so I'm currently still finding the CRB page helpful)
[13:08] <noodles775> s/helpful/helpful too
[13:08] <Ursinha> noodles775, right, I thought so
[13:08] <Ursinha> noodles775, so you think it's worthy doing?
[13:09] <noodles775> Ursinha: yes definitely. It showed me which bugs I wasn't tracking! (the registry ones... :) ).
[13:10] <jtv> stub: it's as if we're cleaning up the orm-backed objects but keeping their contents
[13:13] <Ursinha> noodles775, cool :)
[13:13] <Ursinha> noodles775, are you taking care of talking to people about their outstanding QA items, or do I still have to do that? :)
[13:15] <noodles775> Ursinha: I'm trying, but there have been lots of other issues happening, so I would welcome any help, thanks!
[13:16] <mars> salgado, around?
[13:16] <Ursinha> noodles775, all right, I'll put a branch of mine for review and get to help you :)
[13:16] <salgado> mars, yep
[13:16] <noodles775> Ursinha: thanks!
[13:16] <Ursinha> noodles775, np :)
[13:18] <mars> hi salgado, my YUI3 branch fixes up client.js so most of the launchpad functionality works again: lp:~mars/launchpad/yui-3final-upgrade
[13:18] <salgado> mars, cool.  what was the problem that we were seeing last week?
[13:18] <mars> salgado, I've found that windmill works well in this case
[13:19] <mars> the problem last week was a change to an object, from Object() to an object literal has.  Y.extend() didn't know how to deal with it
[13:20] <mars> Y.Plugin became Y.Plugin.Base - passing Y.Plugin to extend() didn't work any more.
[13:21] <noodles775> Ursinha: bigjools said that bug 293106 isn't a crb (just the related landing that you noticed).
[13:21] <mup> Bug #293106: does not support debian v3 source formats <current-rollout-blocker> <feature> <motu> <ppa> <soyuz-upload> <Soyuz:In Progress by wgrant> <https://launchpad.net/bugs/293106>
[13:21] <Ursinha> noodles775, I just saw that
[13:22] <salgado> mars, oh, I see.  glad you've figured it out
[13:22] <Ursinha> noodles775, a true case where we still need that page :)
[13:23] <Ursinha> noodles775, I've removed the tag
[13:23] <noodles775> :)
[13:23] <noodles775> Ursinha: thanks.
[13:41] <jml> allenap, pushed to lp:~jml/launchpad/ec2-parry
[13:41] <allenap> jml: Thanks :)
[13:44] <gmb> Dammit, why is the "m" key so close to the "e" key?
[13:46] <mars> BjornT, just checking the jscheck buildbout output: there appear to be two errors, but they weren't picked up by the test runner?  https://lpbuildbot.canonical.com/builders/jscheck/builds/91/steps/shell_7/logs/stdio
[13:56] <BjornT> mars: are you thinking of the 'test_results: ERROR' messages?
[13:57] <mars> BjornT, yes, one ERROR and one INFO
[13:57] <mars> BjornT, make that two ERROR messages
[13:57] <mars> ah, three
[13:58] <BjornT> mars: right. the ERROR ones aren't really errors. we need to find some way of surpressing those log messages. they happen when you do an assert, and tell windmill not to really assert, just to return the result
[13:59] <mars> BjornT, ok, I understand.  Not straight-forward to fix though.  I was just looking at the code.
[14:29] <leonardr> bac, you're in luck. i had to upgrade the lazr.restfulclient in launchpad to test my new launchpadlib branch. so i'll be able to at least run the test before i go on vacation. once pqm opens back up you should be able to just submit my branch that changes the required version
[14:30] <bac> leonardr: great
[14:30] <mars> BjornT, is there any way to control the options passed to the bin/test windmill test runner?
[14:32] <BjornT> mars: what do you mean? how do you want to control them? and which options are you talking about?
[14:33] <mars> BjornT, the '-e' option tells windmill to not exit at the end of the test run, allowing you to poke around in the test suite.  Can I simulate that with bin/test?
[14:35] <BjornT> mars: no, you can't. so far i've been using -D, or using import pdb; pdb.set_trace(), but it'd would be nice to add a way to tell windmill not to shut down
[14:36] <BjornT> mars: why do you need to poke around, btw?
[14:37] <mars> BjornT, some tests are failing as a result of the YUI upgrade.  I can run individual tests, but they just die.  I need to jump through many hoops to recreate the windmill test fixture.
[14:38] <mars> test running works fine - test authoring is a royal pain
[14:39] <BjornT> mars: ok. the easiest atm is passing in -D, so that it breaks on the first failure
[14:39] <mars> right
[14:39] <mars> thanks BjornT
[14:40] <BjornT> mars: it shouldn't be too hard to hack BaseWindmillLayer to do what you want, though, like checking for an environment variable, and not call windmill_teardown() if the variable is there
[14:42] <mars> BjornT, ah, cool idea
[14:48] <bac> sinzui: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1402EB656
[14:58] <bac> EdwinGrubbs: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1402EB656
[14:59] <mars> salgado, hit a problem, looks like the 3.0final JS doesn't build for production?  So windmill doesn't run properly.
[14:59] <mars> something is off in launchpad.js itself
[15:00] <salgado> mars, what do you mean by doesn't build for production?
[15:01] <mars> salgado, we combine all the JS together into one big launchpad.js for production and testing.  That file is messed up right now, so windmill won't run.
[15:02] <salgado> mars, oh, I see. and we don't do that with the default config?
[15:02] <mars> nope, the test config uses launchpad.js
[15:02] <mars> the dev config uses individual JS files
[15:06] <salgado> right
[15:07] <mars> it uses either testrunner or testrunner-appserver
[15:07] <mars> not sure which
[15:08] <BjornT> mars: have you tried removing the lazr-js directory, and then run 'make' again?
[15:09] <sinzui> bac: Edwin: I still think bug 458169 is a dup of bug 455812. the root cause is the view/portlet that is working with the milestones. Should we mark the one as a dup?
[15:09] <mup> Bug #458169: Distroseries:+index page timing out <current-rollout-blocker> <timeout> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/458169>
[15:09] <mup> Bug #455812: distroseries milestone timeout <current-rollout-blocker> <timeout> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/455812>
[15:09] <mars> BjornT, trying now
[15:10] <bac> sinzui: i'm not sure what that buys us.  if one fix covers them both then that's great.  but it might be better to leave them both open to ensure any fix works for both scenarios.
[15:10] <EdwinGrubbs> sinzui: that's fine
[15:10] <sinzui> bac: okay
[15:10] <mars> BjornT, did not work
[15:12] <mars> BjornT, looks like YUI 3.0.0 is in launchpad.js, but none of the on-page javascript is getting activated
[15:13] <mars> so, why would it work in dev, but not in testing?
[15:13] <mars> launchpad.js vs. individual files is the only major difference I can think of
[15:13] <BjornT> mars: are there any js error messages in the browser?
[15:14] <mars> no
[15:14] <mars> that would prevent processing the remainder of the file, true
[15:14] <mars> but nothing in the console
[15:15] <BjornT> that's odd
[15:15] <mars> it is
[15:15] <mars> another subtle API change?
[15:16] <mars> I'll hack in on-page JS debug logging, might turn up something
[15:16] <noodles775> Hi EdwinGrubbs and sinzui: can you guys pls take a look at the three registry bugs listed as In progress at https://dev.launchpad.net/CurrentRolloutBlockers and update the status?
[15:16] <noodles775> or let me know and I'll update it - whichever.
[15:17]  * sinzui updates
[15:17]  * noodles775 just sees the scrollback...
[15:17] <noodles775> thanks sinzui
[15:21] <Ursinha> hey bigjools :)
[15:21] <sinzui> noodles775: in summary, we are asking for an RC for the CSS that fixed some links in the side portlets. The entire team is working on the distroseries timeouts. The root cause relates to summarising milestones. there may be one  bug here.
[15:22] <sinzui> barry: We are meeting to discuss the software center in 16:00 UTC
[15:22] <sinzui> barry: see the standup notes
[15:22] <barry> sinzui: +1  just saw that (email is starting to trickle in again)
[15:25] <noodles775> sinzui: um, the MP there is targeted to devel? (and has a diff of 2600 lines)
[15:25] <noodles775> https://code.edge.launchpad.net/~edwin-grubbs/launchpad/all-downloads-link-sprite/+merge/14333
[15:25] <sinzui> barry, bac, EdwinGrubbs: Fixing the distroseries is our top priority. I think the milestone status summaries are the cause of the 90% python processing time. There may be gross inefficiencies in counting the status/assginees for bugs and blueprints. The caching of the bugs and blueprints in the view may not be good enough. Maybe we want to adapt the objects that are being counted into a simpler object that does less indire
[15:26] <sinzui> noodles775: read the comment
[15:26] <noodles775> yeah, just did...
[15:28] <barry> sinzui: +1
[15:28] <noodles775> sinzui: but that doesn't explain why it's targeted to devel... I'd expect it to still be targeted to db-devel?
[15:28]  * sinzui struggle to organise two simultaneous meetings
[15:29] <sinzui> noodles775: I am too busy, talk the the people involved
[15:29] <noodles775> EdwinGrubbs: ^^^
[15:29] <bigjools> Ursinha: hi
[15:29] <Ursinha> bigjools, guess you know what I'll ask :)
[15:30] <EdwinGrubbs> noodles775: what is targeted to devel instead of db-devel? BTW, have all the devel revisions finally been merged into db-devel?
[15:30] <mars> BjornT, does the lpwindmill.py script still work?
[15:31] <mars> I should say, is it supposed to work?
[15:31] <Ursinha> bigjools, all untested items are from al-maisan, is he testing that or you split?
[15:32] <al-maisan> Ursinha: I am about to finish a LP API test script that tests all the open items.
[15:32] <Ursinha> al-maisan, that's cool! :)
[15:32] <Ursinha> thanks al-maisan
[15:33] <al-maisan> Ursinha: you are welcome.
[15:33] <BjornT> mars: no, it's not. do want it to debug the js problems?
[15:33] <bigjools> Ursinha: what he said :)
[15:33] <noodles775> EdwinGrubbs: the above MP. And no they haven't, waiting for the next stable->db-devel.
[15:33]  * noodles775 checks stable
[15:34] <mars> BjornT, it used to be the way to start the windmill environment so you could author tests.  It would start a server and set up the windmill test layer.
[15:34] <mars> BjornT, for some reason JS is not executing at all in firefox under windmill.  Great :(
[15:34] <mars> that would explain why there are no errors!
[15:35] <BjornT> mars: you're the first one i know that would actually author a test using the windmill gui :)
[15:36] <BjornT> mars: does it work if you start the normal app server, with devmode turned off?
[15:36] <EdwinGrubbs> noodles775: it just says devel instead of db-devel since I used the "bzr send" to submit the mp, and I was apparently missing an option.
[15:36] <sinzui> barry: I have checked that db-devel does show teams. Staging is broken and it did not get a code update in the last 24 hours. Other than forcing an update we need to wait
[15:36] <mars> BjornT, how do you turn off devmode?  I tried setting LPCONFIG, but that did not work.
[15:38] <noodles775> EdwinGrubbs: yep, it just leaves me nervous seeing such a large diff ;), but r-c=me for the real diff that you've listed. Updating now.
[15:39] <barry> sinzui, noodles775 don't you think it's too risky to roll out to production without a stable staging environment to do testing on?  i know my comfort level with the mailman upgrade will go way up if i have a chance to test it on staging first
[15:39] <EdwinGrubbs> noodles775: I would like to land it after devel gets merge into db-devel. How long do I have before pqm is closed on db-devel?
[15:40] <BjornT> mars: edit configs/development/launchpad.conf
[15:40] <BjornT> mars: although setting LPCONFIG=testrunner-appserver should work as well
[15:41] <noodles775> EdwinGrubbs: just over 8hrs (00:00 UTC). and the current devel should be landing in db-devel any minute now (lp is currently updating the branch).
[15:41] <mars> testrunner-appserver dies complaining about the missing ftest db
[15:43] <mars> BjornT, shutting off devmode did the trick - now I can do "make run", and see that the JS is not loading
[15:43] <mars> still no errors though
[15:48] <mars> BjornT, salgado-lunch, something broken in the module machinery again.  This could take a while.
[15:48] <mars> salgado-lunch, for now you can just use devmode to test features by hand, should work fine.
[15:53] <barry> bac: is it insane to run your script with arg1 == 500?
[15:56] <bac> barry: no, why?
[15:56] <barry> bac: just in an effort to get it to timeout
[15:57] <sinzui> barry: bac: EdwinGrubbs: noodles775: I propose that we timebox the fix for distroseries. If we do not have a branch in the next 6 hours, we add an exception the the milestone logic to not count IBaseDistribution.
[15:57] <barry> bac: locally
[15:57] <bac> barry: yes, using 500 should be very snappy.  i ran with 1000.  it did not cause a timeout, though
[15:57] <noodles775> flacoste: ^^^ as I'll not be around, I'll leave that in flacoste's hands.
[15:58] <barry> bac: ah
[15:58] <bac> sinzui: are we using the regular conf number?
[15:58] <barry> bac: that's interesting
[15:58] <bac> barry: which part?
[15:58] <sinzui> bac: yes
[15:59] <barry> bac: that it didn't timeout locally
[15:59] <flacoste> sinzui: the branch need to be reviewed and QAed on staging, and if you land it through ec2 test, you haver less time than that
[16:00] <sinzui> flacoste: okay, we make the hack now, If we solve it later this week we can ask for CP
[16:00] <flacoste> sinzui: that's even better!
[16:01] <kiko_work> hey there!
[16:01] <kiko_work> flacoste, yo
[16:02] <bac> sinzui: i'm in the call.   it is now, right?
[16:02] <sinzui> yes
[16:05] <flacoste> kiko_work: hi there (on the phone)
[16:05] <kiko_work> flacoste, cool, ping me when you are free
[16:12] <Ursinha> sinzui, is bug https://bugs.edge.launchpad.net/launchpad-registry/+bug/462742 supposed to be fixed?
[16:12] <mup> Bug #462742: OOPS getting a project index page as an anonymous user <oops> <Launchpad Registry:Fix Committed by intellectronica> <https://launchpad.net/bugs/462742>
[16:13] <Ursinha> sinzui, I've noticed several occurrences of the oops you mentioned in your comment in the last days, but none yesterday
[16:20] <sinzui> Ursinha: I think you need to talk to intellectronica. The bug affects the registry, but the origin that I understand is bugs
[16:22] <Ursinha> sinzui, ok, I'll talk to him
[16:24] <Ursinha> thanks sinzui
[16:46] <mars> sinzui, ping re: base-layout JS macros
[16:47] <sinzui> hi mars
[16:48] <mars> hi sinzui, I assume you wrote base-layout.pt?
[16:48] <sinzui> I did
[16:48] <mars> cool
[16:48] <mars> first, nice job, it is a beautifully clean file :)
[16:48] <Ursinha> bigjools, there are two items from wgrant that are soyuz
[16:48] <Ursinha> bigjools, I've moved them from lp general testplan to soyuz one
[16:49] <mars> sinzui, just wondering which macros, if any, that sub pages should use to put their own JS files onto the page
[16:49] <sinzui> hmm
[16:49] <mars> I see you have load-javascript
[16:49] <mars> and page-javascript
[16:50] <mars> (which calls load-javascript)
[16:50] <sinzui> The first is for fragemetns/iframes, the later if for a full page
[16:50] <sinzui> The latter does the extra work to activate common UI behaviours for classes
[16:51] <sinzui> mars: I wonder if we could simplify that if we removed the old maintemplate
[16:51] <mars> sinzui, is there a converted page in registry that loads it's own JS that I could look at?
[16:51] <sinzui> The timeline is an example
[16:51] <mars> ok
[16:53] <mars> sinzui, so object-timeline-graph and timeline-macros?
[16:54] <sinzui> Yes, those should like the two items
[16:54] <sinzui> mars: The design permits users to embed the timeline on their site
[16:54] <mars> right, I see that.  Nice.
[16:55] <sinzui> The credit goes to EdwinGrubbs
[16:55] <mars> sinzui, I see that productseries-index still uses the header-epilogue
[16:56] <mars> to add the unique JavaScript files
[16:56] <sinzui> Does the distroseries-index?
[16:56] <mars> head_epilogue
[16:56] <sinzui> oh no, because the there is no timeline for that
[16:57] <sinzui> It would be nice to factor the epilogue out
[16:57] <mars> hmm
[16:57] <sinzui> It would be nice if I did not need to register the calendar widget on som many pages
[16:57] <mars> My "nice to have" front-end list is growing quickly... :)
[16:58] <mars> sinzui, I bet there is a nice general solution here, just need to think about it
[16:59] <mars> and I wish it was easy to create custom TAL elements!  <lp:calendar>
[16:59] <mars> or <tal:use-js src="blah/blah"/>
[17:00] <sinzui> My reason for nice to have is that we will have fewer bugs about calendars not activating if we have a unified solution. If the calendar were in the compressed JS, it could connect itself every time time a calendar class is used
[17:00] <mars> sinzui, or we could use our own loader.  That would work too
[17:00] <sinzui> yes
[17:01] <flacoste> kiko_work: i'm free
[17:01] <mars> src="loader?launchpad.js=3.0&calendar.js=2.0" or something
[17:03] <sinzui> mars: we had (maybe still have) a flag on the view that states if the calendar is required. We use the same solution for gmap. Maybe we could have a property on a view that base-layout knows to set the JS requirements
[17:04] <sinzui> EdwinGrubbs: barry: one of us needs to create a branch to stop loading the summaries on IBaseDistribution. Can either of you do that in the next two hours? I can try, but I have only 90 minutes.
[17:06] <EdwinGrubbs> sinzui: I can start on that as soon as I get my branch into pqm.
[17:06] <mars> sinzui, I see, you store the "I need this JS" flags on the request object.  Works, but could be better.
[17:07] <sinzui> Yes, the old calendar did that
[17:07] <sinzui> I copied the approach for gmap
[17:07] <sinzui> gmap is at the request level, I do not think the calendar is
[17:08] <mars> nope, gmap and json are though
[17:08] <sinzui> Let me restate that. gmap is *currently* at the request level because there are no cases where one fragment needs the gmap and another say it does not
[17:09] <sinzui> OSM might be easier
[17:09] <mars> OSM?
[17:09] <sinzui> OpenStreamMaps. That would permit us to test the script in the test runner
[17:10] <mars> ah
[17:10] <sinzui> That would also be cheaper (secure gmap costs money)
[17:10] <mars> I seems the JS-to-template component glue needs some work
[17:10] <kiko_work> flacoste, you are so nice!
[17:10] <kiko_work> how are you?
[17:12] <mars> sinzui, ok, thanks for the overview.  Now I can try to figure out why the JS rollup is not loading.
[17:14] <sinzui> EdwinGrubbs: I just realised that we have MilestoneView.is_distroseries_milestone. The template/portlet could use that attribute to know that it should not get the status counts.
[17:15] <EdwinGrubbs> sinzui: ok, I'll use that
[17:30] <flacoste> kiko_work: i'm great, now that the buildbot has started working again
[17:31] <kiko_work> flacoste, what was the issue
[17:31] <kiko_work> I am working on business papers
[17:31] <flacoste> kiko_work: we don't know
[17:32] <Ursinha> deryck[lunch], when you return, do you intend to fix bug 394097 for the rollout?
[17:32] <mup> Bug #394097: accessing message 0 of bug 371281 gives wrong return type of IMessage <api> <bug-page> <oops> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/394097>
[17:32] <flacoste> kiko_work: well, one of the issue is that the time it took to checkout the branch was longer than the timeout
[17:32] <kiko_work> flacoste, sounds like a bzr optim issue!
[17:32] <flacoste> kiko_work: sounds like a missing repo, yeah
[17:36] <kiko_work> heh
[17:41] <deryck> Ursinha, no, I hadn't thought about trying to get something for that in the rollout.  Let me look into it more and see what would take to fix it.
[17:44] <Ursinha> thanks deryck
[17:44] <bigjools> Ursinha: those two outstanding needstest are done
[17:44] <Ursinha> bigjools, ice_cream++
[17:44]  * bigjools eat++
[17:45] <Ursinha> thanks bigjools :)
[17:45] <bigjools> Ursinha: there will be one more later when al-maisan gets something landed
[17:45] <Ursinha> bigjools, right
[17:46] <Ursinha> deryck, there's also bug 453203 happening quite frequently, guess because of ubuntu release and people filing more bugs through apport
[17:46] <mup> Bug #453203: UnicodeDecodeError in +filebug: unexpected code byte <oops> <Launchpad Bugs:New> <apport (Ubuntu):New> <https://launchpad.net/bugs/453203>
[17:47] <deryck> Ursinha, ok, will look
[17:49] <Ursinha> deryck, thanks
[17:56] <deryck> Ursinha, for your second one, bug 453203, is there anything for us to do?  I thought allenap was going to talk to pitti about that as it was on apport's end.
[17:56] <mup> Bug #453203: UnicodeDecodeError in +filebug: unexpected code byte <oops> <Launchpad Bugs:New> <apport (Ubuntu):New> <https://launchpad.net/bugs/453203>
[17:56] <deryck> maybe I'm recalling wrong though.  allenap ?
[17:56] <Ursinha> deryck, well, I don't know, that's what I asked in the bug :)
[17:57] <allenap> deryck: Yes, I need to talk to pitti.
[17:57] <deryck> Ursinha, oh, sorry. :)  Didn't look down that far.
[17:57] <Ursinha> deryck, :)
[17:58] <deryck> allenap, is there anything we can do on our end, or that's what is to be learned from chat with pitti?
[17:59] <allenap> deryck: To be honest, I just need to ask him if he recognises the problem. Perhaps it rings a bell, or perhaps he can help me trace where it might be happening.
[18:00] <deryck> allenap, ok, cool.
[18:00] <deryck> Ursinha, so given that, I don't see us getting anything on that one today.
[18:00] <allenap> deryck: I'm not sure that the problem is with apport, or that he'll be able to help, but it's a next step.
[18:01] <deryck> gotcha
[18:02] <Ursinha> ok deryck, thanks
[18:08] <Ursinha> deryck, one last question :) who's testing the last item in bugs' testplan?
[18:08] <deryck> Ursinha, I thought we were green. :)  Let me look.
[18:09] <deryck> oh that's me :)
[18:09]  * deryck draws the lucky short straw
[18:09] <deryck> Ursinha, I'll catch that here in a minute.
[18:10] <Ursinha> thanks deryck!
[18:11] <deryck> leonardr, ping
[18:12] <leonardr> hi deryck
[18:12] <deryck> leonardr, trying a little api test script on .dev server locally.  I get this:  http://pastebin.ubuntu.com/308693/
[18:12] <deryck> I see a bug that this should be fixed, right?
[18:12] <leonardr> deryck: you need to update lazr.restfulclient to 0.9.10
[18:13] <deryck> leonardr, ok, cool.  thanks.
[18:14] <deryck> leonardr, there's no 0.9.10 in download-cache.  Should there be?
[18:14] <leonardr> deryck: i'm working on that now
[18:15] <deryck> ah, ok.
[18:16] <leonardr> i'll probably commit it on monday when i come back from vacation and pqm is ope
[18:22] <thumper> rockstar, abentley, mwhudson: I'll be a little late for the standup today as I'm going to watch Jessie present her project to the class (will go on for 2 minutes).
[18:22] <thumper> I shouldn't be too late, but just a heads up
[18:27] <rockstar> thumper, ack.
[18:27] <rockstar> thumper, it's really odd to see you around in my AM.
[18:27] <thumper> :)
[18:30] <rockstar> mars, what is the python in lazr-js for?
[18:33] <jml> g'night all
[18:34]  * rockstar lunches
[18:35] <mars> rockstar, the Python scripts?  Those are our build system.
[18:35] <mars> And some useful utilities.
[18:38] <sinzui> EdwinGrubbs: barry: bac: I just noticed that Specification.milestone is not indexed in the DB. Did anyone investigate this as a cause for the distroseries timeouts?
[18:38]  * sinzui still thinks the issue is the counts in the python code
[18:40] <EdwinGrubbs> sinzui: I was working on getting some explains for that query. There is an index for (distribution, milestone), so as long as the query specifies both of those columns in the WHERE clause, it will use that index.
[18:40] <sinzui> Thanks for the explanation
[18:44] <sinzui> EdwinGrubbs: bac: looking carefully at the oops that bac provided, I believe only 2 milestones were iterated through before the timeout. We have a long way to go to improve performance
[18:58] <barry> EdwinGrubbs, sinzui how odd: 2 milestones?  this is not reproducible on launchpad.dev
[19:00] <sinzui> barry: That is a lot of processing time for about 1000 bugs!
[19:00] <sinzui> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1402EB656
[19:01] <barry> sinzui: it sure is
[19:01] <sinzui> barry: we are iterating over the bugs about 8 times each milestone. We are doing the same for blueprints, but on a lesser scale
[19:02] <sinzui> I assume a lesser scale, I do not see how many blueprints are involved.
[19:10] <bac> sinzui: i setup a test locally with 1 milestone and 100 bugs and 100 blueprints for that milestone.  i saw get_status_counts called twice, once for bugs and once for blueprints.
[19:11] <barry> bac: that would make some sense given productseries-milestone-table-row.pt
[19:11] <sinzui> bac: yes the calls are correct, what about the times? were some of the bugs private?
[19:12] <bac> sinzui: no private bugs
[19:12] <bac> sinzui: but your earlier statement made it sound like that method was called more often.
[19:12] <bac> sinzui, barry: might be worth setting up multiple milestones to see while throwing in some private bugs
[19:14] <barry> bac: your setup script doesn't create any bugs.  that might be interesting to add
[19:14] <bac> barry: the one i shared on U1 does.  can you see it?
[19:15] <barry> bac: only in my browser
[19:15] <barry> bac: i'll run that one
[19:15] <sinzui> bac: the get_status_counts is a loop oer all items passed.
[19:15] <bac> you mean "o'er"
[19:16] <bac> sinzui: right, but i saw it called only once for bugs and once for blueprints.  perhaps i misunderstood your earlier comment.
[19:18] <sinzui> I think so. Iterating over all the bugs to get the status.
[19:20] <deryck> Ursinha-food, when you're back, just an FYI, I don't think we'll get a fix for the message 0 bug today either.  I think there's more to it that just IMessage vs. IBugMessage.
[19:21] <mars> sidnei, around?
[19:21] <sidnei> mars: iam
[19:21] <mars> hi sidnei, just wondering if you helped with the yui-patch.js file in lazr-js?
[19:21] <barry> bac: just fyi: you should add "import _pythonpath" to the top of your script
[19:22] <mars> sidnei, I'd like like to know if it does anything beyond simply short-circuiting the file download process
[19:22] <sidnei> mars: i didn't help. but that's all it does (you can diff against loader.js)
[19:22] <bac> barry: i was just invoking with 'bin/py'
[19:22] <barry> ah
[19:22] <barry> the #! threw me off
[19:23] <bac> barry: sorry...
[19:23] <bac> bad form
[19:25] <barry> bac: TypeError: makeSpecification() got an unexpected keyword argument 'owner'
[19:25] <barry> that makes no sense
[19:25] <bac> barry: the version U1 worked for me.  don't know.
[19:25] <mars> sidnei, you are right, thanks for the info
[19:27] <mwhudson> good morning
[19:27] <barry> bac: i'm not doubting you but that seems impossible ;)
[19:28] <bac> barry: perhaps i put up the wrong version.  tweak at will.
[19:28] <barry> bac: k
[19:28] <mars> sidnei, ah, do you know if that patch is used directly by jsTestDriver in some way?  I can't find any string occurances of the yui-patch.js fine in lazr-js itself.
[19:28] <mars> morning mwhudson
[19:29] <sidnei> mars: yes, through widgets.conf, which loads all the javascript needed for the tests.
[19:30] <mars> sidnei, and is that in JSTestDriver?  Such a file is also not in lazr-js :/
[19:30] <mars> wait, maybe I have the wrong branch here....
[19:30] <mars> this is Bjorn's buildout branch
[19:34] <sidnei> mars: right. i added it to lazr-js in my branch
[19:40] <rockstar> mars, is it really necessary to have our lazr-js build system given its own setup.py
[19:44] <barry> losa ping
[19:44] <barry> losa unping
[19:45]  * mbarnett runs in then back out very quickly
[19:48] <mars> rockstar, in order to use it via buildout, yes
[19:48] <rockstar> mars, sad.
[19:48] <mars> rockstar, we are kind of pretending that it is a python dependency instead of using some tarball or something
[19:48] <abentley> thumper: ack.
[19:48] <mars> rockstar, I don't know why
[19:49] <mars> rockstar, may a been the simplest path to taking advantage of the buildout versioning capabilities?
[19:50] <rockstar> mars, well, it just seems to clutter things up I guess.  It's not in my way or anything.
[19:50] <mars> think about it this way: if it was a requirement of launchpad-developer-dependencies, we would be layering some debian/ stuff on top
[19:50] <mars> instead, we are layering the Python eggs+zc.buildout stuff on top
[19:50] <mars> they both serve the same role
[19:51] <mars> rockstar, after hanging out for a few years on distutils-sig, I've come to the conclusion that there is no good solution to this stuff.  Only pragmatic ones.
[19:52] <rockstar> mars, yeah, but it seems odd that a javascript library would be using a python specific build system.  Maybe that's not wrong, just odd.
[19:54] <mars> rockstar, kind of odd - we are not used to thinking of Python as build system glue.  Maybe it would be more normal to have a wrapper that takes the lazr-js tarball and builds that into an egg instead.
[19:55] <mars> instead of putting the egg guts into the lazr-js source tree
[19:55] <rockstar> mars, well, that would require work. I prefer complaining.
[19:55] <rockstar> :)
[19:55] <mars> lol
[19:57] <mars> you know, that would be pretty clean, put everything zc.buildout and setuptools related under a pdist/ directory, just like apt packages have a debian/ directory.
[19:59] <mars> would hide setup.py, setup.cfg, .egg-info...
[20:18] <mwhudson> abentley: hi
[20:18] <abentley> mwhudson: Hi.
[20:19] <rockstar> mwhudson, did you see that the puller blew up again?
[20:19] <mwhudson> abentley: am i going blind, or is BranchMergeProposalJobDerived.iterReady missing a join like BranchMergeProposalJob.branch_merge_proposal = BranchMergProposal.id ?
[20:19] <mwhudson> rockstar: yeah :/
[20:20] <mwhudson> abentley: i guess the distinct=True on the results means this doesn't actually give the wrong results...
[20:23] <abentley> mwhudson: I think you might be right.
[20:24] <abentley> mwhudson: We can't be sure that the Branch is the source_branch of the BranchMergeProposal for the job using this query, right?
[20:24] <mwhudson> abentley: right
[20:25] <mwhudson> abentley: i think it's a cross join (is that the word)?  you'll get every ready branchmergeproposaljob of the right type for every branch that's up to date with mirroring
[20:26] <mwhudson> *every branch that's the source of a merge proposal
[20:26] <mwhudson> of course the reason i'm looking at this is that in my branch is that it doesn't return a job it should be returning
[20:27] <mwhudson> oh, that's easy
[20:27] <abentley> mwhudson: That might explain why sometimes the merge proposal creation job dies with NotBranchError.
[20:27] <mwhudson> abentley: yes it might
[20:28]  * mwhudson makes a new branch
[20:28] <thumper> mwhudson: if it is getting it wrong, could be rc candidate
[20:28] <thumper> abentley, rockstar: one of you want to host the conf call?
[20:28] <abentley> thumper: I'll do it.
[20:29] <mwhudson> thumper: i think it will be getting it wrong some of the time, will write some tests after the calls
[20:29] <mwhudson> -s
[20:35] <mars> sidnei, since it looks like JSTestDriver wants to load everything and completely ignore the YUI loader, it may be better to bypass it entirely.
[20:35] <mars> sidnei, I've checked the source: in 3.0final you can unbundle the loader, and the module dependencies should still work
[20:35]  * mars heads over to #yui to ask
[20:35] <sidnei> mars: interesting.
[20:36] <sidnei> mars: if you figure that out let me know, i haven't merged my yui3 branch of lazr-js yet.
[21:15] <mars> sidnei, when you have some time, could you try out this patch against your JSTestDriver branch?  It should remove the YUI loader
[21:16] <mars> sidnei, http://pastebin.ubuntu.com/308823/
[21:17] <sidnei> mars: awesome. will do.
[21:17] <sidnei> mars: also need to figure out how to submit my branches to pqm, they failed on friday.
[21:30] <mwhudson> abentley: is there a bug for "sometimes the merge proposal creation job dies with NotBranchError" ?
[21:30] <abentley> mwhudson: Yes, and I've linked your branch to it.
[21:30] <mwhudson> abentley: oh right :)
[22:09] <sinzui> Chex: ping
[22:10] <Chex> sinzui: hello
[22:10] <sinzui> Chex: can you run the cronsripts/product-release-finder on staging ?
[22:15] <sinzui> barry, did you remove then recreate the Ubuntu Haiku list?
[22:15] <barry> sinzui: nope
[22:16] <Chex> sinzui: sure
[22:21] <barry> sinzui, flacoste, mbarnett email to ~haibunku on staging looks great.  i feel good about the mailman upgrade
[22:22] <mbarnett> barry: yay
[22:22] <sinzui> barry: and new team members will get an email telling them *how* to subscribe to the list. Best update ever
[22:22] <barry> \o/
[23:01] <jml> barry, please fix the moderation link in emails.
[23:28] <wgrant> elmo: Don't worry, Soyuz isn't as insane as you seem to have assumed.
[23:28] <elmo> wgrant: well
[23:29] <elmo> wgrant: it's not so much an assumption but history/experience; I'd be happy to be wrong about it
[23:29] <wgrant> elmo: See my comment in bug #471076
[23:29] <mup> Bug #471076: filecache-default corruption should not happen <Launchpad Auto Build System:New> <https://launchpad.net/bugs/471076>
[23:31] <elmo> blah
[23:31] <wgrant> Heh. Yes.
[23:31] <elmo> fine, fine
[23:31] <elmo> well I can't hardly diagnose it now since launchpad helpfully removed the "bad" version from the cache
[23:32] <wgrant> Oops.
[23:33] <wgrant> elmo: Are all the buildds on >= Hardy at the moment, or are the PPC ones still Dapper?
[23:33] <wgrant> Because they are all going to need a dpkg backport very soon.
[23:33] <elmo> wgrant: ppc are dapper still
[23:34] <elmo> is dpkg-source run outside the chroot?
[23:34] <wgrant> :(
[23:34] <wgrant> It is.
[23:34] <wgrant> Easiest might be to move it inside, then.
[23:34] <elmo> well that's freedom hating
[23:34] <elmo> I'm only running dapper because hardy epically fails on that hardware
[23:35] <elmo> if karmic works, I'd run that
[23:35] <wgrant> I'd really like to minimise the patches required against sbuild and run a less ancient unmaintained fork...
[23:35] <elmo> so would I :)
[23:38] <wgrant> I've just remembered that lp-buildd's ancient sbuild needs fixes to work with >= karmic dpkg-source, anyway. So it needs patching either way.