[00:08] <lifeless> garh
[00:08] <lifeless> this search stuff is so frustratsing
[00:15] <wgrant> Hm. Is loggerhead running?
[00:35] <thumper> \o/ my conflict resolution branch just landed
[00:52] <james_w> there's a lot of confusion between tests in lp.archiveuploader and some of those in soyuz
[00:53] <wgrant> I moved a whole lot a couple of days ag.
[00:53] <wgrant> But yes.
[00:53] <wgrant> It's pretty bad.
[00:53] <james_w> which way did you move them?
[00:53] <wgrant> I moved doctests from soyuz to archiveuploader.
[00:53] <spm> wgrant: seems to be working for me? no alerts, and a test looked good. ??
[00:53] <wgrant> I left soyuz-upload.txt alone, though, since it's not clear where it should live.
[00:54] <wgrant> spm: Odd, was 502ing for me almost immediately.
[00:54] <james_w> wgrant: can you see http://ec2-75-101-196-90.compute-1.amazonaws.com/summary.log?
[00:54] <wgrant> james_w: No.
[00:55] <lifeless> james_w: you need to open the firewall more, manually.
[00:55] <james_w> wgrant: http://paste.ubuntu.com/472006/
[00:55] <james_w> that confused me for a while, the second isn't actually at the path that it says it is
[00:55] <james_w> it's in soyuz, and it appears to test exactly the same thing
[00:56] <wgrant> That's one I just moved.
[00:56] <wgrant> Sure you're up to date?
[00:56] <james_w> plus I just wrote a bunch of tests for checkUpload, and it now turns out that it is tested in archiveuploader
[00:56] <james_w> ah, that's probably why, I'm probably based of an older devel
[00:56] <wgrant> Right. It used to live in archiveuploader.
[00:56] <wgrant> Then it was factored out.
[00:57] <james_w> ah
[00:57] <james_w> the tests were changed but not moved I guess
[00:57] <james_w> how frustrating
[00:58] <wgrant> Have you seen some of those doctests?
[00:59] <james_w> yes
[00:59] <james_w> these were unit tests though
[01:00] <wgrant> Ah.
[01:05] <jelmer> james_w: Sorry, that must be my fault.
[01:07] <jelmer> The way that code worked was a bit messy, where an Archive method called out to a plain function and then function then called out to the Archive's methods again. I cleaned that up (by merging the logic into Archive) but never got around to moving the tests along.
[01:07] <james_w> jelmer: I think I can move all of lp.archiveuploader.tests.test_permission in to lp.soyuz.tests.test_archive?
[01:08]  * jelmer looks
[01:09] <jelmer> james_w: yep
[01:09] <james_w> great
[01:43] <lifeless> I have renewed my hate relationship with doctests
[01:43] <lifeless> also with layering, fragile tests and DB's.
[04:17] <lifeless> wgrant: so, on this private librarian issue
[04:17] <lifeless> wgrant: I think we are, today, completely insecure.
[04:17] <lifeless> wgrant: by which I mean many things that are on private objects are on the public librarian
[04:18] <wgrant> lifeless: Right. Only P3As really use the restricted librarian.
[04:18] <wgrant> Oh, and MP diffs.
[04:19] <lifeless> I'm wondering how risky it is, to do it without C-D, and add C-D in later
[04:19] <lifeless> oh, other angle
[04:19] <lifeless> all restricted librarian content can attack all othe restricted librarian content at the moment too
[04:19] <lifeless> in that it can get project names, urls, do same-site scripting.
[04:20] <lifeless> thumper: ping (private librarian usage)
[04:21] <lifeless> thumper: can we make the stuff we put in the librarian for private MP's be totally preformatted ? then the client could access it directly.
[04:22] <wgrant> lifeless: Restricted librarian is purely proxied.
[04:22] <wgrant> And the proxied stuff is always C-D'd if dangerous.
[04:23] <wgrant> In fact, it may always be.
[04:23] <wgrant> I forget.
[04:23] <lifeless> wgrant: I'm pretty sure that that is a porky
[04:23] <wgrant> The restricted librarian is not accessible from the outside.
[04:23] <wgrant> Only via the webapp.
[04:23] <lifeless> yes
[04:23] <lifeless> thats rather my point
[04:23] <lifeless> its in the LP domain
[04:24] <lifeless> lib/canonical/launchpad/browser/librarian.py
[04:24] <lifeless> like 141
[04:24] <lifeless> we set C-E
[04:24] <lifeless> and C-T
[04:24] <lifeless> and thats it.
[04:24] <wgrant> Yes, I just found that.
[04:24] <wgrant> That's broken.
[04:25] <lifeless> so
[04:25] <lifeless> I'm saying:
[04:25] <lifeless>  - do we add C-D:attachment now
[04:25] <lifeless>  - or get direct access now and add it later
[04:25] <lifeless> I'd rather not do both direct access *and* add C-D, because of the potential for interactions and confusion.
[04:26] <lifeless> though clearly, we want to end up doing both (or doing something crazy like uuid DNS names to isolate content more.
[04:26] <wgrant> I guess that it's no worse than now as long as it's served separate from the public librarian.
[04:26] <lifeless> wgrant: yes, we'll want a new hostname for sure.
[04:26] <lifeless> is private.launchpadlibrarian.net going to be good enough ?
[04:27] <lifeless> or will it need to be yet-another-sibling ?
[04:27] <wgrant> No.
[04:27] <wgrant> launchpadlibrarian.net is full of untrusted content.
[04:27] <wgrant> Wait.
[04:27] <wgrant> That might be safe, then.
[04:33] <thumper> lifeless: re private librarian, we use the same diff for both email and web usage
[04:33] <thumper> lifeless: so, no, not easily
[04:34] <lifeless> thumper: so to fix your timeout you have two choices.
[04:34] <lifeless> fix the librarian client bug that it doesn't set/use a timeout
[04:34] <lifeless> or make the content you store immediately deliverable
[04:45] <thumper> ✁☹
[04:45] <thumper> WTF!
[04:45] <thumper> bzr is lying
[04:46] <lifeless> spm: hey
[04:46] <lifeless> spm: nevermind
[04:46] <thumper> or should I say ec2 test is lying
[04:46]  * thumper wonders how...
[04:48] <wgrant> I have a success mail from EC2 from two hours ago.
[04:48] <wgrant> No sign of it in PQM yet, though...
[04:48] <thumper> wgrant: I have a branch that it "merged" into devel
[04:48] <thumper> wgrant: but failed the build step
[04:48] <thumper> wgrant: on a line that isn't in the resulting branch
[04:48] <wgrant> Nice.
[04:49]  * thumper tries again
[04:56] <lifeless> poolie: ping
[04:58] <lifeless> spm: how is rt 39643 ?
[04:58] <poolie> hi lifeless
[04:58] <poolie> what's up?
[04:58] <lifeless> poolie: how is the featureflags stuff ? Can I encourage folk to use it, or is there more needed before it can be adopted ?
[04:58] <thumper> :(
[04:58] <thumper> buildbot all read
[04:58] <thumper> red
[04:58] <lifeless> poolie: I realise its not-all-finished
[04:59] <poolie> they can use it now
[04:59] <poolie> i don't expect to pull anything out
[04:59] <poolie> it will be easier when i land the thing currently rated tweak
[04:59] <poolie> oh, i think it's only in db-devel at the moment
[04:59] <poolie> so that may limit things a bit
[04:59] <poolie> (this would incidentally have been a pretty safe change to apply onto the live db
[04:59] <poolie> since it's just creating a new empty table
[05:00] <lifeless> I think the table exists
[05:00] <lifeless> if it doesn't, you can ask stub to do it, and then merge your code to devel
[05:01] <poolie> so next up is:
[05:01] <poolie> add some scope detection for beta users etc
[05:01] <poolie> web api to tweak it
[05:02] <poolie> logging
[05:02] <poolie> better way to test things tat depend on features
[05:02] <thumper> lifeless: how to I merge in the reverse of the last revision?
[05:02] <poolie> but none of these should block use now
[05:02] <thumper> lifeless: to back out a change
[05:02] <lifeless> thumper: merge -r X..X-1 .
[05:04] <thumper> lifeless: ta
[05:05] <spm> lifeless: a place of suffering and pain is where it's at, unf. am hoping to grab Mr K shortly for some thoughts and guidance on reducing the pain
[05:06] <lifeless> spm: cause, I'm told that getting that done is blocking my two fav lp rt's
[05:06] <lifeless> 40477 and 40480
[05:06] <lifeless> which in turn are blocking making *everyone* a lot happier.
[05:06] <spm> that happens
[05:07] <StevenK> spm: Moi?
[05:07] <spm> indeedily; but shoo - lunch. grab you after.
[05:07] <StevenK> Hehe
[05:16] <lifeless> spm: when you get back, I would like 5-10 minutes to talk roadmap of deployments etc
[05:16] <lifeless> not to change anything, just to get me on the same page
[05:17] <spm> lifeless: sure. I'm back, it was SK heading lunchwardly.
[05:17] <lifeless> oh
[05:17]  * lifeless checks the clock :)
[05:17] <lifeless> spm: so, whats in the losa pipeline for lp
[05:17] <spm> pain, misery suffereing. the usual.
[05:18] <lifeless> spm: have you seen - https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[05:19] <spm> not in a final form like that; but was aware of the broad outline
[05:19] <lifeless> ok
[05:20] <lifeless> this is going to be a pretty big shift, I want to tie it in nicely with your workload
[05:20] <lifeless> AIUI the main thing on your plates is the lucid migration, which involves pg8.4 too
[05:21] <spm> for LP, yeah pretty much
[05:22] <lifeless> how deep is that pipeline, realistically ?
[05:22] <spm> in terms of?
[05:22] <spm> just LP or everything?
[05:23] <lifeless> are we there yet :)
[05:23] <lifeless> hmm
[05:23] <lifeless> I'm trying to assess the following:
[05:23] <spm> heh, I wish. we haven't even done staging as a trial run
[05:24] <lifeless>  - are we blocked on manpower on the operations side to effect the changes desired
[05:24] <spm> tho we have done LS successfully; some gotchas in that; and at least one issue that may (I stress may in the unknown sense) be a blocker for LP/U1 et al
[05:24] <lifeless>  - is there *anything* the developers need to do that isn't yet done, for the pg8.4, lucid, and RFWTAD changes
[05:24] <spm> RFWTAD ?
[05:24] <lifeless> https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[05:25] <spm> oh right, of course.
[05:25] <lifeless>  - if there is nothing developers can do, and we're not blocked on manpower, then I can start asking folk to use the new process; otherwise I need to rally something on one side or the other.
[05:26] <lifeless> or if we're blocked on decisions, technical input, etc
[05:26] <spm> for pg8.4/lucid - no idea. I have no visibility into what has been done/tested there. so NFI if it'll work or not. ??
[05:26] <spm> that we don't have a working test setup for lucid doesn't bode well in the first instance
[05:26] <lifeless> I think there is a certain swings-and-roundabouts aspect there
[05:26] <lifeless> it's been made critical though, AIUI
[05:27] <lifeless> ok, so thats 10 minutes - thanks, we're cooked for now :)
[05:27] <spm> yeah, so's everythingelse (critical) tho. :-(
[05:27] <lifeless> critical on the dev side
[05:28]  * poolie off to lunch
[05:28] <poolie> lifeless: happy to talk about flags later if you like
[05:28] <lifeless> coolio
[05:28] <poolie> i wasn't planning to work on it for the next couple of days other than to tweak & land what's already there
[05:29] <lifeless> we're about to enter freeze, I think
[05:29] <poolie> i wanted to work out how to make  the docs visible
[05:29] <lifeless> go have tood
[05:29] <poolie> perhaps putting them in a module docstring would be best
[05:29] <lifeless> *food*
[05:29] <lifeless> we can talk when you return
[05:29] <poolie> late food
[05:29] <poolie> :)
[05:29] <poolie> ok
[05:37] <lifeless> spm: also, is there an RT for daily-staging ? I think that that may have slipped through the cracks.
[05:38] <spm> lifeless: ? we already update staging every day; several times a day infact
[05:38] <lifeless> yeah, names are terrible.
[05:38] <lifeless> this is staging-with-production-schema
[05:38] <spm> there's no difference. ??
[05:38] <lifeless> yes there is
[05:39] <lifeless> rt 40482
[05:39] <spm> as in; if we just rollout code to staging without coresponding DB schema changes; staging simply won't start.
[05:39] <wgrant> Isn't staging with production schema just edge?
[05:40] <lifeless> wgrant: can't do destructive testing on edg.e
[05:40] <wgrant> Oh, right.
[05:40] <lifeless> wgrant: there is /no/ place that you can QA edge properly.
[05:40] <lifeless> wgrant: and thus, edge does not get QA'd.
[05:40] <spm> oh! right. sorry - my bad. Prod schema. not prod+1 schema.
[05:41] <spm> lifeless: given how little used staging is atm; is there any value in having another QA env? edge has the advantage of at least being used by lots?
[05:51] <lifeless> spm: QA != users using it.
[05:51] <lifeless> spm: see the RT - same hardware.
[05:52] <lifeless> and we do, until we delete db-devel, require two environments because we have two revisions that can be deployed: db-stable:tip and stable:tip
[05:53] <spm> lifeless: one minor ~ish nitpick. the staging db only restores once a week. it takes something like 20+ hours to happen.
[05:53] <lifeless> hah
[05:53] <lifeless> well, $same-schedule-please
[05:53] <spm> yup :-)
[05:53] <wgrant> But you can surely upgrade the schema without restoring it fully.
[05:54] <lifeless> wgrant: we don't want to upgrade the schema
[05:54] <wgrant> Um, yes, ignore me.
[06:13] <lifeless> thumper:  File "/var/launchpad/test/lib/canonical/shipit/browser/shipit.py", line 73,
[06:13] <lifeless>                                                        ^^^
[06:13] <lifeless> bah
[06:13] <lifeless>                                                                      ^^^
[06:13] <lifeless> better
[06:14] <lifeless> thumper: shipit is out of tree now, so you probably need to import the errors from the old location, fix shipit, and then do a three-branch landing dance.
[06:14]  * lifeless takes a break
[06:14] <wgrant> Can't we just stop rolling out LP to shipit?
[06:16] <wgrant> I don't see why we still do it.
[06:19] <lifeless> does it have any data in common now ?
[06:19] <wgrant> It doesn't use Person any more.
[06:19] <wgrant> So I don't think so.
[06:19] <wgrant> Except for Account, which is what we want to destroy.
[06:22] <wgrant> Oh, no.
[06:23] <wgrant> Looks like it does still use Person: for checking shipit-admins membership, and confirming karma.
[06:35] <poolie> lifeless: oh i meant to ask, is there going to be an architectural overview, and if so where?
[06:35] <poolie> are yougonig to build on the one bjorn started?
[06:36] <lifeless> poolie: no
[06:36] <poolie> (i'm not assuming it needs to be all your work)
[06:36] <poolie> uh
[06:36] <lifeless> I think we want to improve the docs
[06:36] <poolie> so things people should/might want to know before hacking on launchpad will go where?
[06:37] <lifeless> for now, where they go at the moment - the launchpad.dev wiki
[06:37] <lifeless> having many different places to look would add confusion, not reduce it.
[06:37] <lifeless> I rather like what bzr has, and a low-pri task would be to start working towards that
[06:38] <lifeless> right now its sufficiently far down the problem-scale that its unprioritised, at least from my perspective.
[06:40] <poolie> wiki is fine with me
[06:41] <poolie> i think it's just good to have a centre of gravity
[06:41] <lifeless> for your flags stuff, I would like the following written up somewhere.
[06:41] <lifeless> what should LOSA's know
[06:41] <poolie> so you can say "that should go in X" and gradually get the habit
[06:41] <lifeless> what should developers writing code know/think of
[06:41] <lifeless> what should maintainers-of-the-module know/think of
[06:42] <lifeless> and possibly, what should users know (we might want users to see their active flags?)
[06:42] <poolie> mm
[06:42] <poolie> advanced users perhaps
[06:42] <lifeless> I think having a good module docstring is really nice.
[06:42] <poolie> right, especially if that's built onto the web somewhere
[06:42] <poolie> then the wiki can point to that
[06:42] <lifeless> I think it is on the apidocs
[06:42] <poolie> right
[06:43] <lifeless> but not https://launchpad.net/+apidoc/devel.html - thats different again.
[06:43] <lifeless> there is a zope thing
[06:43] <lifeless> anyhow, if someone can do 'pydoc lp.services.flags', I think thats pretty cool, but it doesn't really help with discoverability.
[06:44] <lifeless> https://dev.launchpad.net/Hacking is the centre of gravity for 'getting started doing something in LP'
[06:46] <poolie> i'll put something on the wiki and link to the api docs
[06:46] <poolie> i'm glad someone built them to html
[06:46] <poolie> (gary?)
[06:46] <poolie> we just need to make that public to non-canonical people
[06:47] <wgrant> poolie: You mean pydoctor output?
[06:47] <poolie> mm
[06:47] <poolie> i thought it was on chinstrap or similar
[06:48] <wgrant> http://people.canonical.com/~mwh/canonicalapi/
[06:49] <poolie> that's great
[06:50] <poolie> http://people.canonical.com/~mwh/canonicalapi/lp.services.features.html ! :-)
[06:50] <poolie> wgrant: has that always been there?
[06:50] <lifeless> poolie: since mwh put it together 3-4 years back :)
[06:51] <poolie> ok so salgado said about gary's
[06:51] <poolie> > Unlike the other docs we have, these ones know about interfaces and the classes
[06:51] <poolie> which implement them, adapters, views, global utilities, zcml directives
[06:51] <poolie> and a few other things, so go check it out.
[06:52] <wgrant> Oh, Zope apidoc?
[06:52] <wgrant> Yeah.
[06:52] <poolie> it would still be nice to move that
[06:52] <wgrant> That's on devpad.
[06:52] <wgrant> But accessible easily from a local instance.
[06:52] <poolie> which is private?
[06:52] <wgrant> devpad's private, yes.
[06:57] <thumper> lifeless: ah... I've been fixing something in a symlink :(
[07:19]  * wgrant wonders what lp.soyuz.xmlrpc is about.
[07:19] <wgrant> It's empty, and Soyuz has never done XML-RPC.
[07:19] <lifeless> thumper: is your git-test fixing fix landed ?
[07:19] <thumper> lifeless: yes
[07:19] <lifeless> \o/.
[07:20]  * lifeless tries to land his malone patch AGAIN
[07:22]  * wgrant ponders a massive c.l.i extermination branch.
[07:27] <StevenK> I wonder if apidoc.launchpad.net is on the cards
[07:27] <wgrant> Unlikely. It provides source access.
[07:28] <StevenK> So does launchpad.net/~launchpad-pqm/devel ?
[07:28] <wgrant> They like to pretend that we don't have access to shipit.
[07:29] <wgrant> Apparently giving away free CDs is a risk?
[07:30]  * thumper EODs
[07:33] <lifeless> wgrant: huh ?
[07:35] <wgrant> lifeless: Well, it's somewhat irritating that I have to revert to devel r8967 to see if I can safely delete something. That's when shipit was removed -- which I really don't see the benefit of.
[07:35] <wgrant> "Oh no, we can't have them giving away free CDs."
[07:36] <lifeless> wgrant: was it perhaps back in the 'not all will be open sourced' period ?
[07:38] <wgrant> lifeless: It was at the same time SSO was (somewhat less inexplicably) removed.
[07:38] <wgrant> And around the time they were considering omitting most of Soyuz.
[07:38] <lifeless> so
[07:38] <lifeless> you could propose a merge back in :P
[07:38] <wgrant> Well, I'd prefer that the split was finished.
[07:39] <wgrant> The only benefit at the moment is that it can see karma.
[07:39] <lifeless> sadly the split is along fairly nuts lines
[07:39] <lifeless> if you wanted to make it use the API to do what it does, that would be great.
[07:39] <wgrant> Apart from that, it could live in an entirely separate DB with a static copy of LP.
[07:41] <wgrant> lifeless: How is the split 'along fairly nuts lines'?
[07:41] <lifeless> vertically rather than front/back end
[07:41] <wgrant> Well, ShipIt could sanely be a separate application.
[07:41] <wgrant> SSO not so much.
[07:42] <lifeless> ok, -> awol for a while
[08:29] <adeuring> good morning
[08:40] <jkakar> lifeless: Hi!
[08:41] <jkakar> lifeless: If I remember correctly __nonzero__ was explicitly not added to ResultSet because it can cause performance problems (though, right now I can't remember what those exact reasons are).
[08:42] <lifeless> it is equivalent to try: memo = self.any() except IsEmpty: return False, isn't it ?
[08:42] <lifeless> (mumble details)
[08:45] <wgrant> lifeless, stub: Thanks for the reviews.
[09:15] <mrevell> Hello
[09:32] <wgrant> bigjools: Hi. Should I get the last ddeb DB change landed this cycle (the checkbox on Archive:+admin to enable ddeb building)? Although it works OK for PPAs, it won't really be safe to turn it on anywhere until 10.09, I suspect, since the primary archive handling isn't done yet.
[09:33] <bigjools> wgrant: yes that's fine as long as the feature is turned off
[09:33] <bigjools> wgrant: we should consider moving that checkbox to +edit though?
[09:34] <wgrant> OTOH I could make the copier reject DDEB copies to primary, then it would be fine for PPAs.
[09:34] <bigjools> there's only one team that can copy from a PPA to primary
[09:34] <wgrant> bigjools: Probably, yes. But we might need to work out expiration policies and the like before we make it widely available.
[09:34] <wgrant> Moving the checkbox can be done at any time; adding the DB column can't.
[09:37] <wgrant> Although PPA binaries are expired really quickly anyway.
[09:37] <bigjools> yes, it should not be enabled until everything works :)
[09:37]  * bigjools -> OTP
[09:37] <wgrant> k
[09:39] <wgrant> lifeless: I've seen .count() == 0 around. But that's probably far less efficient than .any().
[09:40] <bigjools> ResultSet needs __nonzero__ then we can use bool(blah)
[09:43] <wgrant> But it's possible that it's omitted for the same reason __len__ is.
[09:43] <wgrant> Callers assume it's cheap.
[09:52] <bigjools> __nonzero__ lives on SQLObjectResult though
[09:53] <bigjools> I've learned not to assume anything when dealing with Storm code now :)
[10:12] <wgrant> Hm.
[10:12] <wgrant> http://blog.ganneff.de/blog/2010/08/02/removalstxt---removals822.html might make it easy enough to implement relibale deletion support in gina.
[10:21] <lifeless> StevenK: hi
[10:21] <lifeless> StevenK: why do you propose things then move them to WIP immediately ?
[10:23] <wgrant> bigjools: https://code.edge.launchpad.net/~wgrant/launchpad/multi-arch-builders will let us switch amd64 builders to i386 through the LP UI, letting admins easily alleviate situations like the current crisis... it removes the master's arch check, sends the build architecture to the slave, and the slave respects that.
[10:24] <wgrant> Any objections?
[10:24] <wgrant> (also handy for when LP learns about processor compatibility...)
[10:26] <bigjools> wgrant: yes I object - until lamont looks at it, because I know it needs work on the slave.
[10:26] <wgrant> bigjools: Well, of course.
[10:27] <bigjools> but yes I'm sure he'll enjoy any branch that makes his life easier
[10:28] <wgrant> Although the i386 builders have been gone for nearly four days now.
[10:28] <wgrant> Is something up with them?
[10:28] <wgrant> Unless alpha 3 is, uh, reallllly slow...
[10:37] <lifeless> thumper: I still see <ImportError: No module named shamap> from ec2
[10:37] <thumper> lifeless: which revision of devel did your testrun use?
[10:38] <wgrant> jelmer: Hi. Do you have a PQM email for that branch you ec2'd for me earlier? I got an ec2 success email, but it never made it through PQM...
[10:40] <lifeless> bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/, revision 11272
[10:40] <lifeless> thumper: ^
[10:40] <thumper> lifeless: hmm... that should have the reverted sourcecode change
[10:40] <thumper> lifeless: not sure what is going on there
[10:41] <lifeless> me neither
[10:41] <lifeless> oh
[10:42] <lifeless> I see, my bad, I had some overlapping stuff going on
[10:42] <lifeless> thumper: sorry for the noise.
[10:42] <thumper> ack
[10:48] <StevenK> lifeless: Because bigjools is lazy and wants to look at my branch
[10:48] <bigjools> oxymoron
[10:48] <StevenK> lifeless: So rather than pulling down my branch, he likes me to use a WIP MP
[10:49] <lifeless> StevenK: you can tell lp-propose to start it in WIP
[10:49] <bigjools> can you create them as WIP, I think he means
[10:49] <StevenK> Oh, right
[10:49] <lifeless> you *will* get reviews from me otherwise
[10:49] <StevenK> I use the web UI to create them
[10:49] <bigjools> lol
[10:49] <lifeless> and from anyone else tracking the feed
[10:49] <lifeless> StevenK: try clicking on advanced
[10:50] <StevenK> lifeless: Yes, so noted
[10:50] <wgrant> It'd be nice if everything had a WIP MP.
[10:51] <lifeless> wgrant: its call 'a branch'
[10:52] <wgrant> lifeless: Yes, but I can't get a diff unless I grab it or sacrifice some goats to loggerhead.
[10:52] <bigjools> guffaw
[10:52] <wgrant> It never works the first time.
[10:53] <wgrant> I don't know why.
[10:53] <wgrant> It sometimes works on the second refresh. And normally on the third.
[10:58] <StevenK> lifeless: Actually, you should look at that MP
[10:59] <StevenK> lifeless: *Why* is dsilvers effectively running SQL by hand, and surely there is a better way?
[10:59] <lifeless> storm :)
[10:59] <lifeless> and collections
[11:00] <StevenK> lifeless: Mind looking at the code before you say so? ;-)
[11:00] <lifeless> sure, I'll look tomorrow am
[11:01] <bigjools> lifeless: this was before Storm days, I'm not sure if the same methods are needed any more
[11:01] <wgrant> I don't know a way of doing such mass inserts in Storm, though.
[11:02] <bigjools> there isn't - store.execute() FTW :)
[11:02] <wgrant> Well, except for just doing a direct SQL -> Storm conversion.
[11:18]  * lifeless hates on the testfix glue
[11:19] <jml> lifeless, yeah, we should do something about that :)
[11:19] <thumper> jml: hi
[11:19] <jml> thumper, hello
[11:19] <thumper> jml: big branch today moving errors
[11:20] <thumper> running through ec2 now
[11:20] <lifeless> jml: check my kanban
[11:20] <jml> thumper, yay
[11:20] <lifeless> why is PQM rejecting non-testfix when its also building ?
[11:20] <thumper> jml: most of the bigness however was changing imports :-|
[11:20] <lifeless> losa ^ ?
[11:21] <jml> lifeless, https://dev.launchpad.net/Trunk/Glue might have a hint
[11:21] <mthaddon> lifeless: I think there needs to be a successful build again to get it out of testfix
[11:21] <jml> thumper, why's that bad?
[11:21] <thumper> jml: not bad, just a lot of boring changes
[11:21] <lifeless> mthaddon: I thought it was 'branch started' was all that was needed.
[11:21] <lifeless> thumper: https://lpbuildbot.canonical.com/builders/db_lp/builds/977/steps/shell_7/logs/summary
[11:21] <jml> thumper, *nod*
[11:22] <mthaddon> lifeless: I don't think so - I'm not sure how it would be aware of that
[11:22] <lifeless> mthaddon: its what the wiki page said
[11:22] <jml> thumper, I've been meaning to challenge someone to write an emacs equivalent to that neat vim import statement thing EdwinGrubbs showed at the epic
[11:22] <jml> thumper, that'd make it less boring.
[11:22] <jml> (or, you know, write it myself).
[11:23] <lifeless> mthaddon: 'PQM is put in testfix mode if either branch is unclean, where "unclean" means "the last test run failed and we haven't had a testfix revision or a forced build yet".'
[11:23] <lifeless> thumper: do those failures look related to the merge conflict you fixed ?
[11:23] <thumper> lifeless: could be
[11:23] <thumper> lifeless: but I don't think so
[11:23] <lifeless> so, could be spurious
[11:23]  * lifeless kicks it
[11:23] <thumper> lifeless: the conflict I fixed was source package recipe build related
[11:23] <mthaddon> lifeless: so has someone sent in a testfix branch?
[11:24] <lifeless> thumper: the only change in the blamelist is yours though
[11:24] <lifeless> mthaddon: yes
[11:24] <lifeless> mthaddon: I think the machinery is probably working
[11:24] <thumper> lifeless: there may have been other db commits before mine
[11:24] <thumper> lifeless: that would have been skipped in blaming
[11:24] <lifeless> will be -so- glad when db-stable is no longer used.
[11:25] <thumper> lifeless: like https://lpbuildbot.canonical.com/builders/db_lp/builds/977/steps/shell_7/logs/summary
[11:25] <thumper> oh
[11:25] <thumper> that failure is from before my merge
[11:25] <jml> lifeless, I'm still hanging out for mandatory pre-merge testing, like in the good ol' days
[11:25] <lifeless> jml: thats planned too
[11:26] <lifeless> jml: I was very happy when gary suggested it
[11:26] <lifeless> In fact, now that my search branch passes all tests
[11:26] <lifeless> if I can just get the damn thing landed, I'll be hacking towards premerge testing
[11:27] <lifeless> thumper: so, what does this mean ?
[11:28] <thumper> lp.buildmaster.tests.test_buildqueue.TestBuildQueueDuration.test_current_build_duration is almost certainly soyuz commit related
[11:29] <thumper> nothing in the sprb related to that
[11:29] <thumper> lp.code.browser.tests.test_sourcepackagerecipe.TestSourcePackageRecipeBuildView.test_eta is probably related, but missed due to changes in both branches
[11:29] <thumper> lib/lp/buildmaster/tests/../doc/builder.txt, no idea, but I'd look at soyuz
[11:30] <lifeless> thumper: so, is it worth kicking it, or does it definitely need a further patch ?
[11:30] <thumper> lifeless: it'll need fixing
[11:30] <thumper> they aren't spurious
[11:30] <lifeless> bigjools: ^
[11:30] <bigjools> what?
[11:30] <lifeless> bigjools: can you, or your nominee, fix db-devel :)
[11:31] <lifeless> it appears to be fallout from some soyuz changes
[11:31] <bigjools> have you got a buildbot log?
[11:31] <lifeless> yes, up above
[11:31] <bigjools> ta
[11:31] <lifeless> https://lpbuildbot.canonical.com/builders/db_lp/builds/977
[11:32] <lifeless> https://lpbuildbot.canonical.com/builders/db_lp/builds/977/steps/shell_7/logs/stdio
[11:32] <bigjools> this smells of abentley
[11:33] <bigjools> did it pass devel and fail on db-devel?
[11:33] <lifeless> there was a merge conflict on db-devel, which thumper fixed this morning
[11:34] <lifeless> when it finished chewing on it, we got the above.
[11:34] <bigjools> hmm
[11:35] <lifeless> thumper reckons it wasn't the merge made it go boom
[11:35] <thumper> boom happened before conflict resolution
[11:35] <bigjools> ok
[11:35] <thumper> but I didn't notice
[11:35] <thumper> otherwise I would have fixorated it too
[11:35] <thumper> and now I'm not working
[11:35] <lifeless> indeed
[11:35] <thumper> trying to get a proposal in for kiwipycon
[11:36] <lifeless> and I have a call tomorrow morning
[11:36] <lifeless> thumper: when is the deadline
[11:36] <thumper> 1.5 hours
[11:36] <lifeless> hah
[11:36] <thumper> 1 hour 24 minutes
[11:36] <thumper> to be precise
[11:36] <bigjools> wgrant: the failing code is yours
[11:36] <lifeless> well, you can tell them 'sorry but I need to sleep'
[11:36] <wgrant> bigjools: Icanhaslog?
[11:36] <bigjools> https://lpbuildbot.canonical.com/builders/db_lp/builds/977/steps/shell_7/logs/stdio
[11:37] <wgrant> EPERM
[11:37] <bigjools> shut
[11:37] <lifeless> thumper: ^ :P - I can try to put something together tomorrow am if they are interested.
[11:37] <bigjools> shit, even
[11:37] <bigjools> hang on
[11:37] <lifeless> gnight y'all
[11:37] <bigjools> wgranthttp://pastebin.ubuntu.com/472143/:
[11:37] <bigjools> sigh
[11:38] <bigjools> http://pastebin.ubuntu.com/472143/
[11:38] <bigjools> nn lifeless
[11:38] <wgrant> bigjools: Um.
[11:38] <wgrant> Interesting.
[11:38] <bigjools> recipe_bq.processor = i386_family.processors[0]
[11:38] <bigjools> failing
[11:39] <bigjools> processor is not in set_attributes
[11:39] <bigjools> so either the layer is wrong or the zcml is wrong
[11:39] <wgrant> Or somebody started proxying them recently.
[11:39] <bigjools> ha
[11:39] <bigjools> right
[11:39] <bigjools> that's it
[11:40] <wgrant> I haven't touched that code lately.
[11:40] <bigjools> it should be in the set_attributes
[11:40] <wgrant> Why?
[11:40] <wgrant> It's immutable.
[11:40] <bigjools> hmmm good point
[11:40] <wgrant> rSP ftw.
[11:41] <bigjools> sigh
[11:41] <bigjools> that stuff should not be proxied in that test
[11:41] <bigjools> it runs zopeless ffs
[11:42] <wgrant> Zopeless is not Zopeless :(
[11:42] <bigjools> well, you know what I mean
[11:43]  * bigjools fixx0ors
[11:43] <bigjools> I'd like to know how it passed tests to get in there like this
[11:44] <wgrant> I don't know what the incompatible db-devel change could be.
[11:45] <bigjools> me neither
[11:46] <bigjools> factory returning proxied objects but why only on db-devel
[11:47] <wgrant> Exactly.
[11:51] <wgrant> bigjools:
[11:51] <wgrant> -        return bq
[11:51] <wgrant> +        return ProxyFactory(bq)
[11:51] <wgrant> Ahem.
[11:53] <wgrant> (it was the merge)
[11:55] <bigjools> whut
[11:55] <bigjools> which merge?
[11:55] <wgrant> thumper's conflict resolution.
[11:55] <wgrant> db-devel r9603.1.2, in particular.
[11:56] <bigjools> presumably that came from devel
[11:56] <wgrant> 9603.1.1 was the merge and conflict resolution
[11:56] <wgrant> .2 was "Fix the failing tests"
[11:56] <wgrant> So it suggests not, but I haven't looked closely.
[11:56] <bigjools> hmm
[12:00] <thumper> oops
[12:00] <thumper> that was just to shut the warnings up
[12:01] <bigjools> oops
[12:02] <bigjools> your fix is ok, it's exposed a bug in the test
[12:02] <bigjools> but I think we should revert that fix and file a bug about the bug
[12:02] <bigjools> thumper: sound ok?
[12:03] <deryck> Morning, all.
[12:03] <bigjools> wotcha deryck
[12:06]  * bigjools can't fathom why someone would run builder.txt in LaunchpadFunctionalLayer
[12:08]  * bigjools submits testfix
[12:08] <bigjools> thanks for spotting that wgrant
[12:09] <wgrant> np
[12:10] <bigjools> errm, why am I getting a warning about converting from 2a to KnitPack5 when pushing a branch...
[12:10] <wgrant> Can someone please land https://code.edge.launchpad.net/~wgrant/launchpad/refactor-nuf-creation/+merge/30851? I believe it was rejected in the testfix this morning.
[12:11] <jelmer> wgrant: Sure
[12:11] <jelmer> wgrant, it was indeed
[12:11] <wgrant> jelmer: Thanks.
[12:13] <bigjools> Using saved push location: lp:~julian-edwards/launchpad/db-devel-testfix
[12:13] <bigjools> Doing on-the-fly conversion from RepositoryFormat2a() to RemoteRepositoryFormat(_network_name='Bazaar RepositoryFormatKnitPack5 (bzr 1.6)\n').
[12:13] <bigjools> wth
[12:13] <wgrant> bigjools: You had an old branch sitting around.
[12:14] <bigjools> grar
[12:14] <wgrant> Yeah, it's private, so it's nice and old.
[12:15] <bigjools> not any more it's nto
[12:15] <wgrant> That's one way to fix it.
[12:16]  * bigjools would really love it if we could have an alias for the submit-branch value
[12:19] <jml> bigjools, thumper has a db-submit bzr alias
[12:20] <bigjools> aliases are great, until you don't have them on a different machine
[12:21] <maxb> This is why your home directory should be in version control :-)
[12:21] <jml> or, you know, Ubuntu One
[12:24] <wgrant> Maybe OneConf will happen at some point.
[12:25] <jelmer> a gconf backend for ubuntu one would be awesome
[12:26] <bigjools> when there's a U! client for KDE, I'll use it
[12:26] <bigjools> U1, even
[12:26] <wgrant> It'd need to be an overlay or something equivalent, but yes.
[13:55] <sinzui> hi jcsackett
[13:55] <jcsackett> hi sinzui.
[13:56] <jcsackett> and hello bac and hello EdwinGrubbs
[13:56] <bac> hi jcsackett!
[14:21] <danilos> losa ping: I don't see any emails explaining the status of our buildbots, can someone please clarify why's db-lp offline
[14:22] <danilos> and does anyone else know why's xvfb failing to start on lucid builder: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/57/steps/shell_7/logs/summary
[14:22] <mthaddon> danilos: I've been reconfiguring things in preparation for lucid switch (we now have a lucid-devel builder) - I suspect it just needs a restart
[14:22] <mthaddon> danilos: if a "force" fails, that is
[14:23] <danilos> mthaddon, I've already tried a force on the lucid-db-lp builder
[14:23] <danilos> mthaddon, the previous one failed in the same way: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/56/steps/shell_7/logs/summary
[14:23] <maxb> If you have a moment, mthaddon, could you append the missing letter 'l' to https://edge.launchpad.net/squirrelmai ? :-)
[14:23] <mthaddon> danilos: ok, can we wait til lucid-devel and lp are finished, then we'll do a restart
[14:24] <danilos> mthaddon, certainly
[14:24] <mthaddon> maxb: done
[14:24] <maxb> thanks :-)
[14:24] <mthaddon> np
[14:37] <james_w> bigjools: the bug in checkUpload would be that it would never tell you that you had no permissions for the archive, just that you didn't have enough permissions. (No-one would ever see the "Did you mean to upload to a PPA?" error)
[14:44] <bigjools> james_w: ah!!!
[14:44] <bigjools> that's, errr, interesting
[14:44] <james_w> could have been a lot, lot worse
[14:44] <bigjools> and explains a lot
[14:44] <bigjools> yeah
[15:46] <jml> hmm.
[15:46] <jml> I guess poolie's DKIM thing hasn't landed yet?
[19:43] <james_w> what layer should I use for tests that don't need anything at all really?
[19:43] <james_w> no database, just running python code
[19:44] <salgado> james_w, no layer. :)
[19:44] <james_w> perfect :-)
[20:06] <maxb> i386  	3  	 1139 jobs (five days)
[20:06] <maxb> *sob*
[20:12] <beuno> maxb, the rumour is that there are a few more build slaves on their way
[20:13] <maxb> We can only hope rumours materialize soon :-/
[20:22] <lifeless> moin
[20:23] <jam> Ursinha: didn't you want to submit something to bzr-pqm a while back? I haven't seen any merge proposals
[20:23] <jam> morning lifeless
[20:28] <lifeless> hi jam
[20:29] <Ursinha> jam, I'm working on it today, just busy with other lp duties
[20:30] <jam> Ursinha: no problem. I just thought you already had something and I just didn't see the submission
[20:30] <Ursinha> jam, ah, you can be sure I'll poke you when that happens :)
[21:04] <lifeless> flacoste: https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone
[21:12] <deryck> Later on, all...
[21:22] <lifeless> https://lpstats.canonical.com/graphs/OopsLpnetHourly/
[21:27] <lifeless> flacoste: lpnet - 1177927, edge - 94787
[21:51] <jelmer> sinzui, hi
[21:51] <sinzui> hi jelmer
[21:52] <jelmer> sinzui: It looks like python-pocket-lint still isn't installable on hardy - in its current form it needs python2.6 and a recent version of python-support
[21:53] <sinzui> yuck
[21:53] <jelmer> sinzui: I'd like to fix the package and reupload - do you have the source for the previous revision in a branch somewhere?
[21:53] <sinzui> I think I can make some quick changes to make it python 2.5 compatible
[21:53] <sinzui> jelmer, https://bugs.edge.launchpad.net/pocket-lint
[21:54] <sinzui> jelmer, the packaging branch has the debian dir
[21:54] <jelmer> sinzui: ah, thanks
[21:55] <sinzui> There is a 5.1 release expected to build in the next 9 hours
[22:03] <jelmer> sinzui: Is there a particular reason gnulog is shipped with pocket-lint, or just because it's convenient?
[22:04] <sinzui> I like gnulog for generating logs. It is a habit from by gnome
[22:13] <lifeless> losa ping
[22:16] <lifeless> losa unping
[22:28] <jelmer> sinzui: I've pushed a branch with a few packaging improvements and a fix to support installation for all system-provided pythons that are 2.5 or newer.
[22:28] <sinzui> I see
[22:30] <jelmer> sinzui: Would it be ok if I pushed a build of this to the Launchpad PPA with a version number lower than what you're building at the moment? That way I can still attempt to build a new EC2 image but my build will be gone once you copy the packages in from your PPA.
[22:31] <sinzui> jelmer, your mp just disappeared
[22:32] <sinzui> I was going to approve it. Yes you can change the version to keep working
[22:32] <jelmer> sinzui: Sorry - https://code.edge.launchpad.net/~jelmer/pocket-lint/packaging/+merge/31587
[22:32] <poolie> hi sinzui, jelmer
[22:32] <jelmer> 'morning Martin
[22:33] <sinzui> hi poolie
[22:38] <wgrant> OMG BUILDERS!
[22:40] <sinzui> jelmer, your branch is now tip
[22:42] <jelmer> sinzui: Thanks!
[22:47] <jelmer> wgrant: 'morning!
[22:49] <wgrant> Morning jelmer. Thanks for landing that.
[22:50] <jelmer> You're welcome. I see you have more branches in store for us though.
[22:50] <wgrant> Yeah, a few.
[22:50] <jelmer> thumper: 'morning
[22:51] <thumper> jelmer: hey, your branch yesterday had failing git import tests
[22:52] <jelmer> thumper: Hmm, that's odd :-/ I'll see if I can fix that here.
[23:04] <wgrant> Ahem.
[23:05] <wgrant> Did Bugs really just start streaming arbitrary user files through the webapp?
[23:05] <wgrant> Yes, yes they did.
[23:06] <elmo> wgrant: err, what?
[23:06] <wgrant> elmo: Around an hour ago, a rev landed on db-devel to stream private bug attachments through the webapp.
[23:06] <wgrant> With no C-D.
[23:06] <elmo> only private bugs?
[23:07] <elmo> not that it helps much
[23:07] <wgrant> It's reusing existing code which should probably be sending C-D anyway, but it's previously only really been used for LP-generated files or .debs.
[23:07] <wgrant> Only private bugs at the moment, it seems, yes.
[23:10] <lifeless> so
[23:11] <lifeless> C-D should be added
[23:11] <lifeless> wgrant: care to put up a trivial branch? rs=me
[23:11] <wgrant> It's going to change some Soyuz behaviour (no more inline build log viewing for private archives).
[23:12] <lifeless> I've run my crazy dns idea past flacoste and he didn't cry
[23:12] <lifeless> so we might head towards that
[23:12] <lifeless> wgrant: you could add a variant class that does C-D
[23:22] <lifeless> wgrant: ^ hi?
[23:25] <wgrant> lifeless: Hi.
[23:25] <wgrant> Hmm, maybe.
[23:50] <jelmer> thumper: Hmm, I can reproduce the git import test failure. I'm at a loss as to what's happening though and what my changes could have to do with it. Do you have any clues?
[23:51] <thumper> jelmer: was it the import failure?
[23:51] <jelmer> thumper: yeah, I'm getting two test failures in the git import tests
[23:51] <jelmer> thumper: LINE 1: ...ccount = Account.id AND LOWER(EmailAddress.email) = E'no-pri...
[23:52] <jelmer> ProgrammingError: operator does not exist: text = bytea
[23:52] <jelmer> is that the same error you saw?
[23:52]  * thumper is looking for the errors
[23:53] <lifeless> jelmer: I saw 'shamap' import errors
[23:53] <thumper> jelmer: https://lpbuildbot.canonical.com/builders/lp/builds/1119/steps/shell_7/logs/summary
[23:53] <thumper> jelmer: the 6 errors are all shamap import failures
[23:54] <thumper> File "/srv/buildbot/slaves/launchpad/devel/build/lib/lp/codehosting/codeimport/tests/test_worker.py", line 1018, in tearDown
[23:54] <thumper>     from bzrlib.plugins.git.shamap import mapdbs
[23:54] <thumper> jelmer: did you remove that module?
[23:55] <jelmer> thumper: yeah, I renamed it.
[23:55] <thumper> jelmer: so fix the tear down and it should be good
[23:55] <thumper> jelmer: I'm not sure what your other failures are from
[23:56] <jelmer> I might see if I can reproduce that one on my work laptop.
[23:56] <jelmer> Anyway, I'll have a look at the tearDown failure first and get that fix through ec2.
[23:57] <thumper> jelmer: I did a reverse merge of your change to devel
[23:57] <thumper> jelmer: so you'll need to reverse my reverse :)