[00:45] <wgrant> Could someone please throw https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 at EC2?
[00:53] <james_w> wgrant, I would, but: ec2: ERROR: Unable to set the commit message in the merge proposal.
[00:55] <wgrant> james_w: Ah, you're not in ~launchpad?
[00:55] <james_w> nope
[01:04] <cody-somerville> wgrant, If you give me the command I need to run, I'll do it for you.
[01:05] <wgrant> cody-somerville: I don't actually know how to do it yet, sorry.
[01:17] <james_w> cody-somerville, ./utilities/ec2 land <url>
[01:18] <james_w> the first will need --force as it isn't set to "Approved"
[06:32] <LPCIBot> Project db-devel build (192): FAILURE in 6 min 21 sec: https://hudson.wedontsleep.org/job/db-devel/192/
[06:46] <LPCIBot> Project db-devel build (193): STILL FAILING in 0.43 sec: https://hudson.wedontsleep.org/job/db-devel/193/
[06:46] <wgrant> StevenK: Are you doing bad things to Hudson?
[07:01] <LPCIBot> Project db-devel build (194): STILL FAILING in 0.46 sec: https://hudson.wedontsleep.org/job/db-devel/194/
[07:16] <LPCIBot> Project db-devel build (195): STILL FAILING in 2 sec: https://hudson.wedontsleep.org/job/db-devel/195/
[07:31] <LPCIBot> Project db-devel build (196): STILL FAILING in 0.44 sec: https://hudson.wedontsleep.org/job/db-devel/196/
[07:46] <LPCIBot> Project db-devel build (197): STILL FAILING in 0.44 sec: https://hudson.wedontsleep.org/job/db-devel/197/
[08:01] <LPCIBot> Project db-devel build (198): STILL FAILING in 0.56 sec: https://hudson.wedontsleep.org/job/db-devel/198/
[08:04] <adeuring> good morning
[08:16] <LPCIBot> Project db-devel build (199): STILL FAILING in 0.45 sec: https://hudson.wedontsleep.org/job/db-devel/199/
[09:14] <mrevell> Greetings
[09:32] <wgrant> bigjools: Since when do we support renaming Ubuntu series?
[09:33] <bigjools> since recently
[10:13] <bigjools> wgrant: so, we still have a few PPAs appearing in every publisher run
[10:13] <bigjools> the ones I caught with the SQL have gone though
[10:15] <wgrant> bigjools: I suspect it's the datepublished IS NULL
[10:15] <wgrant> That constraint was unnecessary.
[10:16] <bigjools> right
[10:16] <bigjools> it was belt and braces
[10:16] <wgrant> Yup.
[10:17] <bigjools> it eats a few minutes in the publisher time for all these :/
[10:17] <wgrant> Are cocoplum and germanium in nodowntime?
[10:17] <bigjools> no
[10:17] <wgrant> :(
[10:17] <wgrant> I understand cesium.
[10:17] <wgrant> But not those two.
[10:17] <wgrant> Oh, poppy?
[10:17] <bigjools> errr yes I meant
[10:18] <bigjools> as in, they don't get rolled out to automatically
[10:18] <bigjools> I hate that tag
[10:18] <wgrant> That means they're *not* in nodowntime.
[10:18] <wgrant> nodowntime means that they don't require downtime for updates. Not that no downtime is allowed.
[10:19] <bigjools> exactly - confused yet?
[10:20] <bigjools> the reason they are in nodowntime is because of the publisher and poppy
[10:20] <bigjools> we're working on load-balancing poppy
[10:24] <bigjools> wgrant: so removing the datepublished is null clause throws up over 900 PPAs.  That's not right :)
[10:25] <wgrant> bigjools: Right, you need to exclude those with other active publications for the source.
[10:26] <bigjools> eh?
[10:27] <wgrant> Hmm. Let me think.
[10:27] <wgrant> What's the query?
[10:28] <bigjools> http://pastebin.ubuntu.com/540956/
[10:32] <wgrant> bigjools: We need to check if there are any other matching sourcepubs in the same series.
[10:33] <wgrant> I think.
[10:33] <wgrant> That's the condition that the dominator users.
[10:33] <bigjools> I can't think straight today, I have got the start of man flu
[10:33] <wgrant> :(
[10:36] <bigjools> wgrant: I can't get my head around what you mean
[10:38] <wgrant> Nevermind, I'm crazy.
[10:38] <wgrant> Can you tell what's wrong with the remaining PPAs?
[10:38] <wgrant> It might not be the same issue.
[10:40] <bigjools> well that's the theory I am working on, I need to debug it
[10:41] <bigjools> self._setScheduledDeletionDate() makes me cry
[10:41] <wgrant> Oh?
[10:42] <bigjools> could really do with a mass-update instead of piecemeal
[10:42] <bigjools> would be an order of magnitude quicker
[10:44] <wgrant> Sure, but that needs the whole thing to be refactored to issue just a couple of queries per archive.
[10:44] <wgrant> Not several per publication.
[10:44] <bigjools> exactly
[10:45] <wgrant> That method is the least of our worries.
[10:45] <bigjools> I'd say it's one of the nightmares of soyuz personally
[10:45] <bigjools> in fact domination.py generally :)
[10:46] <wgrant> Sure.
[10:46] <wgrant> It's better than it used to be. But still pretty horrific.
[10:46] <bigjools> mmm it's nice and warm today, the high is -1
[10:46] <wgrant> :( I want cold.
[10:46] <bigjools> you don't :)
[10:57] <bigjools> wgrant: so I have found an example of one where the source did get published and then deleted before the build finished.  The data looks entirely as expected, so I'm not sure why that other query picks up so many PPAs.
[10:59] <wgrant> bigjools: I need to think about that. Can you investigate one of the other 900 PPAs and work out what's wrong?
[10:59] <bigjools> yeah already looking
[11:07] <bigjools> wgrant: so the other PPAs have packages that are naturally superseded
[11:08] <wgrant> Right.
[11:08] <bigjools> but the binaries are still published, so something is holding up the binaries
[11:08] <wgrant> None Deleted?
[11:08] <wgrant> Oh.
[11:08] <wgrant> Of course.
[11:08] <wgrant> A2...
[11:08] <bigjools> however, they don;t appear in the publisher log!
[11:08] <wgrant> I am stupid.
[11:09] <wgrant> A2 marks pockets with *Deletions* dirty.
[11:09] <wgrant> and Distribution.getPendingPublicationPPAs only looks for Pending and Deleted.
[11:10] <wgrant> So PPAs with Superseded sources like this won't be processed by the publisher.
[11:10] <bigjools> ho ho!
[11:10] <wgrant> So it's plausible that we have 900 of them,.
[11:10] <bigjools> so, how do we fix this ...
[11:11] <wgrant> This is NBS.
[11:11] <bigjools> right
[11:11] <wgrant> It's not critical that we handle this now, since the performance impact should be close to zero.
[11:11] <wgrant> Long-term we probably need UI for NBS.
[11:12] <wgrant> And everyone will handle it themselves then.
[11:12] <wgrant> For now: ignore.
[11:12] <bigjools> it's very hard on PPAs to see that right now
[11:12] <wgrant> Right.
[11:12] <wgrant> So, restrict spph.status to Deleted.
[11:12] <wgrant> And remove datepublished IS NULL
[11:12] <wgrant> And see if that returns a set closer to the remaining PPAs from the publisher log.
[11:13] <bigjools> so I can change the original query to just pick up status=4 and we should be ok
[11:13]  * bigjools crosses with your suggestion
[11:14] <bigjools> 58 PPAs \o/
[11:14] <wgrant> Still large...
[11:14] <bigjools> well this is on staging, it will be the original 23 plus new ones
[11:15] <wgrant> Oh.
[11:15] <wgrant> Is that closer to what we were expecting?
[11:15] <wgrant> I don't have the publisher log at hand.
[11:15] <bigjools> yeah it's about right
[11:17] <bigjools> wgrant: this is what I will run: http://pastebin.ubuntu.com/540962/
[11:17] <wgrant> bigjools: Set datesuperseded! Not scheduleddeletiondate.
[11:17] <bigjools> Imeh
[11:18] <wgrant> Otherwise it looks fine.
[11:20] <wgrant> Then we need to get your fix out to cesium soonish.
[11:20] <wgrant> And that should be the end of that.
[11:21] <bigjools> http://pastebin.ubuntu.com/540963/
[11:22] <wgrant> doit
[11:23] <bigjools> async b-m up and running!
[11:23] <wgrant> Woo.
[11:23] <bigjools> oy, spammy log now
[11:23] <bigjools> "Starting factory" messages for the getPage call :(
[11:24] <bigjools> and corresponding "Stopping factory"
[11:24] <wgrant> :(
[11:33]  * bigjools -> coffee break
[11:55] <bigjools> wgrant: that SQL change has picked up 7k5 rows... need to check it although the PPA count itself seemed sane
[11:57] <wgrant> Hmm.
[12:01] <bigjools> one archive has got 5951 binaries in this state
[12:01]  * bigjools stares at ubuntu langpack
[12:02] <bigjools> schooltool-owners has got 1307
[12:02] <wgrant> schooltool packages hundreds of zope bits and pieces.
[12:02] <wgrant> Both have hundreds of arch-indep packages at a time.
[12:02] <bigjools> yes so langpack is costing us 3 minutes in every publisher run!
[12:02] <wgrant> I wonder if that is relevant.
[12:03] <bigjools> I doubt it
[12:05] <bigjools> hmmm
[12:05] <bigjools> wgrant: yes there's a bug there I think
[12:06] <LPCIBot> Yippie, build fixed!
[12:06] <LPCIBot> Project db-devel build (200): FIXED in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/200/
[12:06] <LPCIBot> Project db-devel build (201): FAILURE in 0.54 sec: https://hudson.wedontsleep.org/job/db-devel/201/
[12:06] <bigjools> binary published 2010-06-08, source deleted 2010-11-24
[12:06] <wgrant> bigjools: Same series?
[12:07] <bigjools> there was a massive upload of langpacks very recently
[12:07] <bigjools> same series what?
[12:07] <wgrant> Are the binary and source in the same series?
[12:08] <bigjools> yup
[12:09] <wgrant> :(
[12:13] <bigjools> wgrant: so there could be a bug in domination of arch-indep :/
[12:13] <bigjools> which is rather concerning to say the least
[12:15] <wgrant> Can you give me some source and binary pub IDs for schooltool?
[12:17] <bigjools> 403127/4325526
[12:18] <bigjools> 1.5 year gap for that one!
[12:21] <wgrant> bigjools: This can't be domination, because it's deletion.
[12:21] <wgrant> Let's see...
[12:21] <wgrant> It may have been done through the API.
[12:21] <bigjools> sorry, I mean condemning
[12:21] <wgrant> Since it was a mass-deletion of everything in Intrepid.
[12:22] <wgrant> No, the binaries are still Published.
[12:22] <bigjools> hrmph
[12:22] <bigjools> right
[12:22] <wgrant> I think someone may have presumed that SPPH.requestDeletion deleted the binaries too.
[12:22] <bigjools> I told you I had man flu
[12:22] <bigjools> yeah
[12:23] <bigjools> nicely spotted
[12:24] <bigjools> oh dear
[12:24] <wgrant> Oh dear/
[12:24] <wgrant> ?
[12:25] <wgrant> What have I destroyed now?
[12:25] <bigjools> nothing, I am just wondering how to fix the API so it's backwardly compatible
[12:26] <wgrant> Does it need to be?
[12:26] <bigjools> it needs to call PublishingSet.requestDeletion
[12:26] <wgrant> Right.
[12:26] <wgrant> Any API users calling SPPH.requestDeletion are broken.
[12:26] <wgrant> I don't know of any regular users.
[12:26] <wgrant> So let's just change it to make it work sanely.
[12:26] <bigjools> however, we don't have a publishing set to work with in the API call
[12:27] <bigjools> in the meantime I am going to run that SQL
[12:27] <wgrant> Unexport ISPPH.requestDeletion, and export as requestDeletion a new SPPH method that calls PS.requestDeletion.
[12:28] <wgrant> And yes, please run that SQL.
[12:28] <bigjools> that won't really work
[12:28] <wgrant> Oh?
[12:28] <bigjools> PS.rD needs a list of sources
[12:28] <bigjools> we can munge it
[12:28] <bigjools> but that's horrible
[12:28] <bigjools> I guess it's the cheapest thing for now
[12:29] <wgrant> We have no other way to do it until the API redesign goes through.
[12:30] <bigjools> yeah :/
[12:30] <bigjools> cock
[12:30] <wgrant> ?
[12:31] <bigjools> the API is frustrating like this
[12:31] <wgrant> Yes. But it will be fixed soon.
[12:31] <wgrant> henninge: Hi.
[12:39] <bigjools> wgrant: can you think of any scenario where SPPH.requestDeletion should not delete the bins too?
[12:39] <wgrant> bigjools: Not through the API, no.
[12:39] <bigjools> I'm going to have to make a new method and export it with the old name
[12:39] <bigjools> yay...
[12:39] <wgrant> Yep.
[12:54] <bigjools> wgrant: yay for factoring.  requestDeletion is in an interface common to both SPPH and BPPH.... *cry*
[12:55] <wgrant> bigjools: Yup :D
[12:56] <bigjools> wgrant: we don't ever want people to delete just the binaries, do we?  I can un-export it from BPPH entirely
[12:57] <wgrant> bigjools: We should probably leave it, for the NBS case.
[12:57] <bigjools> wgrant: I hate it when you point out stuff like that :)
[12:57] <wgrant> As do I.
[12:59] <bigjools> yay, last publisher run was 5 mins
[12:59] <wgrant> Awesome.
[13:00] <wgrant> How many archives were considered?
[13:00] <bigjools> well, 6 mins
[13:00] <bigjools> 21
[13:00] <bigjools> and 8 private ones
[13:00] <wgrant> Hm. still a few.
[13:01] <bigjools> well the trick is to see if they appear repeatedly
[13:01] <bigjools> I shall check after fud
[13:01] <wgrant> True.
[13:01] <bigjools> ttfn
[13:01] <wgrant> And I guess that's quicker now.
[13:05] <StevenK> wgrant: Not that I'm aware of, why?
[13:05] <wgrant> StevenK: db-devel was failing very oddly.
[13:05] <wgrant> StevenK: Complaining that the branch was a repo, not a branch.
[13:05] <wgrant> Among other things.
[13:06] <StevenK> The bzr pull failed, doesn't sound like a hudson issue
[13:07] <wgrant> That was the first one.
[13:07] <StevenK> That's #201, #202 is still building
[13:07] <henninge> wgrant: hi! ;)
[13:08] <wgrant> henninge: Hi. I replaced the doctests as you requested in https://code.launchpad.net/~wgrant/launchpad/bug-680889-arch-wildcards/+merge/42723
[13:08] <StevenK> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/e550d33ce1999c89bbdf2123b7a8c930.pack is redirected to https://launchpad.net
[13:08] <StevenK> Sounds like a production issue
[13:09] <henninge> wgrant: ah cool,looking
[13:09] <StevenK> I suspect the next builds of db-devel were unclean due to the build slave
[13:09] <wgrant> StevenK: Ah, of course.
[13:10] <StevenK> wgrant: Do you use Hudson a lot just because you don't have buildbot access? :-)
[13:10] <wgrant> StevenK: Yes, but it also spammed the channel a lot earlier.
[13:15] <henninge> wgrant: very good! And it is also so much clearer what is happening. ;)
[13:15] <henninge> wgrant: r=me
[13:15] <wgrant> henninge: Oh yes.
[13:15] <wgrant> I wanted to do it.
[13:15] <wgrant> But as I said I'm not a huuuuge fan of mixing them into the same branch.
[13:15] <wgrant> henninge: Could you please throw it at EC2?
[13:16] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 also need EC2ing, if someone has a moment.
[13:16] <henninge> wgrant: Oh, one thing. Shouldn't there be a test for just "foo", i.e. an invalid arch?
[13:16] <henninge> wgrant: sure, I can do that.
[13:17] <henninge> wgrant: or is that the same as "kfreebsd-hppa" ?
[13:17] <wgrant> henninge: It's already covered in a few places, perhaps most directly by testThreeArchitectures
[13:18] <henninge> ok, fine ;)
[13:18] <henninge> wgrant: argh, I just noticed a formal error in the doc test.
[13:18] <henninge> sorry
[13:19] <henninge> (for voicing approval prematurely)
[13:19] <wgrant> What's the issue?
[13:19] <henninge> wgrant: the schema for test method names is "test_methodName_extra_condition"
[13:20] <henninge> so, in this case "test_determineArchitecturesToBuild_single_arch" etc.
[13:20] <wgrant> I like to pretend that that rule doesn't exist, since it is inconsistent with everything else.
[13:20] <henninge> ;-)
[13:21] <wgrant> determineArchitecturesToBuild is redundant there, since it's already in the class. But you have a point about underscores rather than camelCase.
[13:21]  * wgrant fixes.
[13:21] <henninge> wgrant: right, since you are testing just that one method, it's not needed in the method name.
[13:21] <henninge> thanks
[13:23] <henninge> TestStyleGuide says exactly that ;-)
[13:23] <henninge> (method name is not strictly needed)
[13:35] <wgrant> henninge: Names changed.
[13:38] <henninge> wgrant: cool, thanks a lot!
[13:39] <wgrant> henninge: No, thank you.
[13:39] <henninge> ;-)
[13:39] <henninge> wgrant: don't touch the branch anymore, I will land directly from there. ;)
[13:40] <wgrant> henninge: Great.
[13:40] <wgrant> Less great.
[13:41] <henninge> wgrant: don't touch the branch anymore, I will land directly from there. ;)
[14:11] <henninge> wgrant: http://ec2-184-72-77-59.compute-1.amazonaws.com/
[14:12] <wgrant> henninge: Thanks.
[14:12] <wgrant> henninge: Did you end up sending off those other two as well?
[14:12] <henninge> erm
[14:12] <henninge> which other two ... ?
[14:12]  * henninge must have forgotten about those.
[14:13] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-685764/+merge/42814 and https://code.launchpad.net/~wgrant/launchpad/bug-675621-packages-binary-scaling/+merge/42607 also need EC2ing. You didn't review them, but I thought you might be able to throw them at EC2 while you were at it.
[14:13] <henninge> sure, np.
[14:14] <wgrant> Thanks!
[14:36] <henninge> wgrant: http://ec2-50-16-60-12.compute-1.amazonaws.com/
[14:46] <henninge> wgrant: and finally http://ec2-75-101-182-41.compute-1.amazonaws.com/
[14:52] <james_w> testing the API on qastaging is a bit hampered by caching of the wadl
[14:53] <gary_poster> adeuring: do you know enough to answer pitti's question at the bottom of https://bugs.launchpad.net/launchpad-foundations/+bug/395960 (in which he asks if that change was supposed to fix bug 620458)?  I'm pretty sure the answer must be "no," but I don't have context to reply.
[14:53] <_mup_> Bug #395960: proxying user supplied libarian files via the launchpad appserver domain has security and performance issues <librarian> <qa-ok> <Launchpad Foundations:Fix Released by lifeless> <https://launchpad.net/bugs/395960>
[14:53] <_mup_> Bug #620458: cannot access attachments of private bugs any more <qa-ok> <httplib2:Unknown> <Launchpad Bugs:Triaged by adeuring> <OEM Priority Project:New> <https://launchpad.net/bugs/620458>
[14:53]  * adeuring is looking
[14:54] <gary_poster> thanks
[15:00] <bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: meeting reminder
[15:00] <bigjools> ta
[15:00] <gary_poster> thanks
[15:00] <adeuring> ok
[15:00] <jtv> bac: I'm not here, sorry.
[15:28] <LPCIBot> Yippie, build fixed!
[15:28] <LPCIBot> Project db-devel build (202): FIXED in 3 hr 11 min: https://hudson.wedontsleep.org/job/db-devel/202/
[15:28] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12023
[15:28] <LPCIBot> included.
[15:28] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=368600] Store and report database patch
[15:28] <LPCIBot> application times.
[18:30] <bdmurray> james_w: have you done any writing to specifications with the API?  I'm getting a 401
[18:35] <james_w> bdmurray: I haven't. What are you attempting to modify?
[18:36] <bdmurray> james_w: a work item in the whiteboard
[18:39] <james_w> Hmm, I'll take a look after lunch
[18:51] <bdmurray> james_w: Its working for me now
[19:22] <james_w> good
[20:50] <dobey> do launchpad teams end up as unix groups, or as users, on the server?
[20:53] <jelmer> dobey: no, they just exist in the database
[20:54] <mwhudson> mmm do we match revisions to authors by case insensitive email address or case sensitive?
[20:55] <dobey> jelmer: how do permissions get handled on the filesystem for pushing branches and such? is that all done on the client via the xmlrpc check that happens before the actual pushing in bzr?
[21:02] <jelmer> dobey: no, it's done server side
[21:03] <james_w> how does one go about getting a nodowntime deployment?
[21:04] <james_w> There is a set that the deployment report says can be deployed (admittedly containing only a single revision), and it would be spiffy to have that revision available
[21:05] <jelmer> hey james_w
[21:05] <james_w> hey jelmer
[21:06] <dobey> jelmer: hrmm. via the launchpad server bzr plug-in somehow?
[21:06] <jelmer> dobey: a custom ssh server
[21:06] <mwhudson> it's the custom bzr transport really
[21:08] <jelmer> james_w: I think there's a spec for it on the wiki, but IIRC it's basicallt that it it needs to be listed on the production status page and approved by a team lead
[21:08] <jelmer> james_w: and your revision has to be qa-ok/qa-untestable of course
[21:09] <james_w> ok
[21:09] <james_w> it's already qa-ok, so I think I've done my part as the author
[21:10] <jelmer> james_w: I assume there's a particular reason you need it to be rolled out soon ?
[21:14] <james_w> jelmer, it's the final piece of the puzzle before we can make use of https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43136
[21:15] <dobey> mwhudson: hrmm, i'm not really seeing much difference between bzr push lp:foo and bzr push bzr+ssh://foo.com/~user/foo/trunk, in terms of how the ssh bit works on the client side. but i can't really tell what happens on launchpad.net when i push lp: to it. and i'm trying to get an idea of how the filesystem layout works for bzr branch storage (where they get written to on disk, and how the permissions are handled)
[21:16] <mwhudson> dobey: bzr has this abstraction called a transport
[21:16] <dobey> right
[21:16] <mwhudson> dobey: a bzr smart server process interacts with the underlying branch data via a transport
[21:17] <mwhudson> on launchpad, the transport is not the LocalTransport that just read & writes to the obvious places on disk, but a custom thing that (a) checks the access control aspects
[21:17] <mwhudson> and (b) translates the paths to a location based on branch id
[21:17] <jelmer> james_w: If you just want it to go out with the next rollout of revisions, there's nothing you have to do except make sure your revision is landed and qa'ed.
[21:18] <mwhudson> so a request to write to /~dobey/+junk/awesome/.bzr/repository/pack-names say
[21:18] <james_w> jelmer, right, I'd just like it to be sooner rather than later :-)
[21:18] <mwhudson> is mapped, after some checking to something like /srv/bazaar.launchpad.net/mirrors/00/00/43/00/.bzr/repository/pack-names
[21:18] <dobey> ok
[21:19] <dobey> thanks
[21:20] <mwhudson> dobey: the code is in lp.codehosting.vfs if you're _really_ curious :)
[21:21] <dobey> mwhudson: ah ok. yes, i am. i was poking through the server-side bzr plug-in in the launchpad tree, and the client smart/ssh code, and not getting much of anywhere
[21:22] <mwhudson> dobey: so the magic in the server-side plugin you can find by searching for lp_transport and lp_server
[21:24] <dobey> yeah i was looking at the lp-serve command, and figured out that the client was using the same "bzr serve" over ssh anyway, so got a bit confused. i'll look through the vfs bits later though :)
[21:49] <dobey> should i bug you guys about some weirdness with PPA buildd issues, or losas, or what?
[22:04] <mwhudson> dobey: although the client asks the ssh server to run the same command as on any other server, that's not actually the command that gets run
[22:04] <mwhudson> that's in ... er.. lp.codehosting.sshserver.session i think
[22:04] <dobey> hmm, ok
[22:10] <wgrant> Woah, all three branches landed first time.
[22:13] <mwhudson> we must have disabled some tests by mistake
[22:27] <lifeless> wgrant: lies! :P
[22:28] <lifeless> dobey: ask the CHR in #launchpad; if they aren't on, a question on answers.launchpad.net/launchpad
[22:28] <wgrant> Or just ask #launchpad in general, and someone will respond.
[22:28] <wgrant> That will probably be me, but yeah.
[22:31] <lifeless> wgrant: will your work address https://bugs.launchpad.net/soyuz/+bug/687554 already ?
[22:31] <_mup_> Bug #687554: DistributionSourcePackage:+publishinghistory timeout <timeout> <Soyuz:Triaged> <https://launchpad.net/bugs/687554>
[22:31] <wgrant> lifeless: No.
[22:32] <wgrant> That's an interesting one.
[22:32] <wgrant> Since they don't want it batched.
[22:32] <wgrant> But it should be easy enough to get it fast.
[22:32] <lifeless> its only 3.6 seconds of sql
[22:32] <lifeless> lsprof time
[22:32] <wgrant> 10x what it should be, but yeah, not too bad.
[22:33] <wgrant> Gar.
[22:33] <wgrant> I wanted to see how 12031 went on qastaging. But it just missed the last buildbot :(