[00:07] gary_poster: ping [00:08] gary_poster: hi [00:13] anyone know where the request.publication is set? [00:14] hi jelmer, thumper [00:14] hi poolie [00:15] poolie: I have an interesting bug for you [00:15] poolie: if I can find [00:15] it [00:16] bug 568740 [00:16] Bug #568740: lp:ubuntu/sun-java6 isn't pulled, apparently due to MemoryError [00:20] ok [00:20] so can you give us any more information about it? [00:20] or do you think pulling it directly should reproduce it? [00:20] i've been meaning to do something about giving better debug info for MemoryError [00:20] so i might try it in that context [00:20] is this one important or just interesting? [00:33] well, I don't know where it is failing apart from MemoryError [00:34] it is important for someone [00:37] thumper, the request.publication stuff is a function of an IRequestPublicationFactory instance. We have a few in c.l.webapp.servers [00:37] mars: thanks, I'm going through the doc test for publication right now [00:37] thumper, the factory produced request/publication pairs, which the Zope machinery puts together, then gives to zope.publisher.publish() [00:39] * thumper nods === matsubara is now known as matsubara-afk [01:04] Hey [01:04] I'm making a field read only and setting up a mutator for it. This causes tests to break because the field is used in forms. How do I get around this? [01:09] Ah, I see branch's privacy field is an example. [02:14] mwhudson: what have we broken? http://launchpadlibrarian.net/45588750/maxb-django-trunk-bzr-svn.log [02:16] thumper: huh [02:16] mwhudson: it is a branch [02:16] mwhudson: for svn [02:16] mwhudson: so I'm wondering if we have broken something else [02:16] bzr log -l 2 svn+http://code.djangoproject.com/svn/django/trunk seems to be doing something [02:24] thumper: however, bzr log -l 2 http://code.djangoproject.com/svn/django/trunk does not work [02:24] thumper: at this point i suggest the usual course of action [02:24] thumper: which is asking jelmer [02:24] mwhudson: bug jelmer? [02:25] perhaps the code import system could prepend svn+ to http urls for svn imports [02:46] I'd like to work on fixing bug 569447 [02:46] Bug #569447: Documentation for searchTask tag is wrong [02:47] Is it something easy to do? [02:48] nigelbabu: should be [02:48] nigelbabu: the documentation for the api doc comes from the docstring in the interface [02:49] mwhudson: I read the docs and it said I should first discusss about it and then start [02:49] if it comes from the interface there is a problem. [02:49] the documention is corrent for the interface and wrong for the api [02:49] nigelbabu: why? [02:50] ah [02:50] i wonder if there's a way of overriding/changing the doc for the api... [02:50] mwhudson, nigelbabu, grep-find? [02:51] since you already know the string you are looking for... [02:51] its not about finding. [02:53] mwhudson: can poke me when you find a way out? I'm ready to work on it if it needs fixing :) [02:57] nigelbabu: i'm not sure that you can override the string used in the api doc [02:58] nigelbabu: so maybe a bug on lazr.restful asking for that is the way to go [02:58] ah, ok :) [03:00] mwhudson: how come the postmortem debugger isn't giving me any content for listings? [03:00] what should I say? "There should be a way to override the interface strings for API docs"? [03:00] mwhudson: I just get [EOF] [03:01] thumper: um, the path in the pyc files might be wrong? [03:01] :( [03:01] doesn't seem to be === lifeless_ is now known as lifeless [06:13] someone has requested a mercurial import of netbeans [06:13] good luck with that === jamesh_ is now known as jamesh [07:21] G'day all. [07:25] yo [07:28] must be time for dinner [08:53] Morning. === almaisan-away is now known as al-maisan [09:12] Is it just me, or have the JS status/importance widgets lost their custom colouring recently? [09:21] baaah [09:21] exactly one failure on no-hosted-area [09:41] mwhudson: :) [09:42] fortunately it's rather trivial [09:44] jml: good morning [09:54] mwhudson: hi [10:14] * mwhudson fires up the ec2 land of doom [10:14] " 96 files changed, 2640 insertions(+), 2916 deletions(-)" [10:25] mwhudson: that's a big change [10:25] mwhudson: are much of those insertions added documentation? [10:31] thumper: still around? [10:35] I'm off out of the house for a bit. Expect to be online shortly. [10:36] bigjools: let's talk today [10:37] jml: grab me when you can [10:37] bigjools: ok. thanks. [10:38] wgrant: you've probably already figured it out by now, but sinzui's recent CSS refactoring broke them. Looks like there's a fix up already. [10:41] jml: Yeah, I thought that would have to be it. [10:50] bigjools: no [10:50] thumper: ok, then I can't tell you about the new PPA for bzr-builder [10:51] bigjools: email still works :) [10:51] thumper: when kmail is not crashing, yes :) [11:00] Morning, all. [11:06] jml: no [11:50] thumper jelmer pong [11:51] ah gary_poster, just the man I need to talk to [11:51] what's up bigjools [11:52] gary_poster: I might have been a bit naieve in expecting a webservice method to work when returning a collection of ITextLine [11:52] there's no adapter to do that by the looks of it [11:52] is there any easy solution to returning a list of strings? [11:53] bigjools: sadly, I'm not sure. Leonard will probably be on soon and I'll ask him to seek you out. [11:53] gary_poster: ok thanks [11:54] Do you actually need to do returns_collection_of there? [11:54] If you omit it, lazr.restfulclient will just treat it as JSON, so they will come out as strings. [11:54] (we already do a similar thing for dicts in a few places) [11:56] wgrant: ah, got an example? [12:00] Are there no CHR people this week? [12:00] bigjools: There are methods like Branch.composePublicURL and BugNomination.canApprove that return single objects without declaring their types (since they are basic JSON types). [12:00] I'm not sure of any that return lists. [12:01] It does just work, but I'm not sure how legal it is. [12:01] yeah it's the list aspect that is problematic [12:01] If you don't tell it otherwise it will just decode the JSON and be done with it. [12:02] * bigjools tries and sees what happens [12:03] Technically it's fine. [12:03] Whether it will make a Leonard appear and attack you, I do not know. [12:03] a Leonard can change its spots [12:04] wgrant: BTW did you check out the sizes of those log files ? [12:04] bigjools: Yes. [12:04] I am scared. [12:04] yes thought so :) [12:05] has anyone done a webservice test using lplib yet? [12:05] People have tried. [12:05] Bugs have been filed. [12:05] I think some of them might have been fixed. [12:06] eg. Bug 569189 [12:06] Bug #569189: Authenticated users in launchpadlib tests have no permissions [12:06] Bug 569101 [12:06] Bug #569101: Protocol Error when calling some launchpadlib methods within the test environment [12:06] So it probably works a bit. [12:06] let's see === mrevell is now known as mrevell-lunch [12:42] wgrant: win! [12:43] bigjools: You have a string collection exported and tested with launchpadlib in the test suite? [12:43] yarp [12:43] Win indeed! [12:43] so now I can land this branch that exports your p3a URLs [12:45] I bet that doesn't respect the OAuth token's privacy setting, though. [12:52] it does [12:53] the new method is on IPerson and it'll throw a 401 unless you've got lp.edit [12:54] But if I tell Launchpad that my token shouldn't be able to access private data, will it let me? [12:54] * bigjools re-reads and sees you were talking about OAuth tokens [12:54] Ah. [12:55] not sure it does respect it, you're right, I'm using WRITE_PUBLIC === salgado-afk is now known as salgado [13:20] bac, refresh my memory [13:21] you were having some problems with the launchpadlib tests in launchpad [13:21] i gave you a little one-line-or-so fix, which you applied and it worked [13:21] is that right?. [13:21] have you landed that? [13:22] bigjools, gary told me of your woe [13:22] an ICollection is only for IEntry objects that have their own urls. you should be able to return an IList of ITextLine === mrevell-lunch is now known as mrevell [13:32] bigjools, hello :) [13:32] bigjools, I pinged you yesterday, but have no idea if you answered because my internet was worse than crap [13:45] Ursinha: hi [13:45] leonardr: yeah I'm just returning the list and it seems to work well, thanks [13:50] allenap, is that test process still going? [13:51] allenap, if so, could you please attach a strace to it and see what it's doing? [13:52] jml: Sorry, I killed it. It was in a tight select() loop though; I did an strace before I killed it. [13:52] allenap, ok. thanks. [13:52] jml: select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) [13:53] * jml raises an eyebrow [14:00] leonardr: yes, i landed the patch that involved uppercasing of the request method [14:07] leonardr: i also discovered this bug: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/569189 [14:07] Bug #569189: Authenticated users in launchpadlib tests have no permissions [14:11] jml: Fwiw, it's in lp:~allenap/launchpad/early-batching-bulk-updates-bug-509223 when run with the test command in the email. If I run with "bin/test -vvc lp.bugs.scripts.checkwatches" it does not hang. This might have something to do with when zope.testing spawns a sub-process when the layer doesn't tear down. [14:29] james_w, i just released a lazr.restfulclient that fixes bug 568301 [14:29] Bug #568301: Invoke a named operation on a collection, and the collection is fetched. [14:29] want to give it a try and see how the performance improves? [14:29] thanks [14:29] I'll try later [14:30] sure [14:43] james_w: when you have time to test things i changed, also take a look at bug 561521 [14:43] Bug #561521: Success of PATCH request dependent on dict iteration order [14:47] deryck: Hi. Are you aware of some horrifyling slow BugJob-related queries caused by status changes? [14:47] They are making some Soyuz things time out. [14:52] wgrant, I have just started to become aware of some BugJob-related timeouts. Didn't realize we had some with status changes, though. [14:52] bigjools, so, ping me when you're not busy, re. my bot and your bugs :) [14:53] deryck: Accepting queue entries can close bugs, and they've recently started timing out with several hundred milliseconds of BugJob query per bug. [14:55] wgrant, ah, that makes sense. Anything that qualifies for a bug change will touch that code. gmb, see wgrant's comments. ^^ [14:55] * gmb looks [14:55] gmb, so we need to look at ways of speeding this up. it's causing timeouts when filing bugs on ubuntu, too. [14:56] wgrant, deryck: Ah, so at a guess this is happening when we're looking at BugJob to see if there's already a CalculateBugHeatJob for that bug, right? [14:56] gmb: So I'm told, although I obviously can't see the full picture. OOPS-1575B227 is an example. [14:56] allenap: If you've still got that hung test run around, could you check whether there actually is a related subprocess hanging around? Otherwise, I'm not sure why it would still be blocked. You could try a 'lsof -p thatpid' to see if there's anything interesting there [14:57] * gmb looks [14:57] * deryck looks at OOPS, too [14:59] Yeah, this is the same as ubuntu filebug timeouts. and yes, as gmb notes, it's the select. [14:59] gmb, See bug 539382, too. [15:00] The query doesn't look like it has to be terrible. [15:00] Unless the indices are. [15:01] wgrant, Yeah, I wonder if we're missing an index somewhere. [15:01] * gmb looks [15:03] wgrant, deryck, I wonder if there should be indices on Job.lease_expires and .scheduled start, since that's what's getting hit in the subquery. [15:03] My DB says seq scans on Job and BugJob. [15:03] ?! [15:03] That would do it. [15:03] So we need indices on both tables then. [15:04] yup [15:04] simple to fix then. :-) [15:04] Indeed. [15:04] ... [15:04] * wgrant looks at BugJob's indices. [15:04] (Well, simple to *say* anyway) [15:04] Or lack thereof. [15:04] gmb, do you think you could find some time today to cowboy a patch to staging to confirm, and if so, get a branch for that? [15:05] deryck, Sure, I'll add a card for it. Should get me away from this endlessly frustrating refactoring, too. [15:05] gmb, thanks! Sorry to sideline you with it, but it is becoming more and more of a problem. You can use bug 539382 to track it, I think. [15:05] wgrant, thanks for pinging me about this. [15:06] deryck, cool [15:06] deryck: Thank you for swiftly investigating. [15:07] np [15:09] Ursinha: HELLEAU [15:11] Hi, are there no CHR people this week? [15:15] Puzzle for the day. Why would Store.of(x) return None, given that x is not None and was retrieved from the database, other than that x has been deleted somehow? [15:16] jtv: Because you are a BranchJobDerived, not a real BranchJob. [15:17] wgrant: brilliant! [15:17] wgrant: for the bonus round, why would BuildQueue, which has no clue WTF I am or am not besides the fact that I implement a particular interface, want to destroy me? [15:18] * bigjools removes the third massive bee from the office today [15:18] Actually, BranchJobDerived delegates to BranchJob, so I'd guess that would include destroySelf. [15:18] jtv: It tries to the destroy the BuildQueue, the Job and the link between the Job and the real object. [15:18] jtv: humanity has a long history of destroying things based on perceived type [15:18] jtv: But this doesn't use destroySelf. [15:18] jml: yes! I thought we were finally getting good at it. [15:18] jtv: And bigjools vetoed my change to use it. [15:19] In favour of noodles' big refactoring. [15:19] arrrr [15:20] Hear that faint drone? That's Baby Jesus crying. [15:20] wgrant: the big refactoring is based on your ideas too :) [15:20] noodles775: that's as may be, but right now, BuildQueue does The Wrong Thing™ with my object and what recourse do I have? [15:21] https://code.edge.launchpad.net/~wgrant/launchpad/bug-549340-fix-buildqueue-destruction was mine, FWIW. [15:23] * noodles775 looks at the branch and jtv's issue. [15:24] jtv's branch is not a storm object is it? [15:24] s/branch/object/ [15:24] bigjools: Right. [15:25] It delegates to one. [15:25] bigjools: if you want to argue over whether there should be a separate TranslationTemplatesBuildJob table, go argue with jml who insisted that I use BranchJob instead. :) [15:25] jtv: citation needed [15:25] lol [15:25] Why not define a method in IBuildFarmJob for "this build is done, do whatever you want for historical purposes, or delete yourself, I don't care which"? [15:26] The Code team in general wants us to use Jobs. [15:26] yeah and that unfortunately hurt us in the buildfarm :( [15:27] Well, there was discussion last week that they were unhappy with the new design, since it doesn't involve Jobs. [15:27] What, we're selling out to Apple? [15:27] * wgrant throws some iPhone shards at jtv. [15:27] Oh, `Job`s. Sorry. [15:28] I'm not removing the jobs at the moment, and I think once the refactoring is finished we'll be in a much better position to see if we want to either (1) talk about removing the links to Job or (2) turn BuildFarmJob into a services Job with the correct job-type. [15:29] I think the new model could pretty trivially be altered to integrate well with Job, without the mess that is the current situation. [15:29] I agree. [15:29] Actually, removing a BranchJob will also destroy the Job. [15:30] Anyway. I do need an interim measure, and fast. How about this idea of delegating "go destroy yourself or something" to the IBuildFarmJob? [15:31] the only reason to use Job is if we intend to use the Job runner [15:31] that will never ever happen [15:31] Code disagrees. [15:31] Feel free to argue with them :) [15:31] they would :) [15:32] I'm not arguing, I'm stating a fact. [15:32] jtv: So you're actually thinking of deploying these jobs in 10.04? [15:33] wgrant: or be damned near ready to. [15:33] Excellent. [15:33] At the very least I want to be able to move on to the next failure, it's been long enough! [15:33] heh [15:34] Well, they worked perfectly for me a little over a month ago. I'm not I had any fixes that remain unmerged, apart from this one. [15:35] So barring the inevitable massive production issues, it probably just about works. [15:35] Nice quote, that. [15:36] jtv: so that would be wgrant's branch above right? (IBuildFarmJob.destroySelf()) [15:36] noodles775: no, bigjools had one strong argument against that—it's SQLObject. My own would be: it's the IBuildFarmJob's own damn business what it wants to do after it retires. It doesn't _have_ to die right there. [15:36] Just call it something different and presto. :) [15:37] Right. [15:38] jtv: I think you're simplifying it too much. We have a BuildQueue, which has generic info, and an associated IBuildFarmJob which has specific info. BuildQueue records are destroyed when done with, which means the IBuildFarmJob must be too. If you want persistence you need a separate table. [15:39] which I'm pretty sure is what I said ages ago :) [15:39] bigjools: why does it mean IBuildFarmJob must be destroyed? All you need is for it to stop referring to the Job. [15:40] * wgrant would really like to delay any persistence changes until after The Refactoring. [15:40] jtv: because that's how it's designed to work, changing it now would be very invasive [15:40] Particularly since it makes the transition much easier if we only have one type of job to migrate... [15:41] bigjools: I can see how the design always assumed it, but where does it actually rely on it? [15:41] jtv, think of it as the difference between data about the job, and data about the build itself [15:42] Yes, I'm thinking of it... go on! [15:44] noodles775, Hey, got five minutes? [15:44] mrevell: sure. [15:45] jtv: so it was designed like that so that we could throw away data that was of no use once the job was done. Deletion is something that doesn't happen enough in LP! [15:46] jtv, bigjools: jfyi, after the refactoring IBuildFarmJob *won't* be destroyed, but all the other queue-related items will be (as they are now - I'm not touching their behavior). That is, BuildPackageJob delegates to IBuildFarmJob... the BuildPackageJob (and related job) will die, but not the BuildFarmJob. [15:46] bigjools: but you don't know what the data _is_. The IBuildFarmJob is not data; it's something abstract that helps you define how to do the job, not a database record. [15:46] jtv: That's about to change. [15:46] It will be, but that doesn't help you now. [15:47] noodles775: So BuildQueue/Job are staying as they are for now, just all the stuff on top of them is being fixed? [15:47] jtv: I didn't mean IBuildFarmJob as such, but the derived tables, but as they say it's going to change [15:48] wgrant: yes, I'm not touching the BuildQueue, just ensuring it still works as it does now. I'm just generalising so that all *Build models have common info in the same place. [15:48] bigjools: that's fine with me, but as an implementer of IBuildFarmJob, I still say it's my own business how I take care of this. [15:48] (basically your diagram minus the queue related attributes) [15:48] jtv: I completely disagree :) [15:48] Well, then fix BuildQueue to do it in a way that works for non-ORM classes! [15:49] making the build-manager work for different job types was fucking hard [15:49] the direction we took solved a lot of problems while not breaking too much of the existing functionality [15:50] kudos for that, and I'm not married to the "the IBuildFarmJob doesn't have to die" idea. Can we at least delegate the deletion somehow? [15:52] you're going to need a separate table that has persistent data on it, for the builder history page [15:53] anyway chat to noodles775, he might be able to help more than me since he's deep in that code at the moment :) [15:54] We've got a ticket open for persistent history. My very immediate concern is this failure that puts the builder into a very bad state. === matsubara is now known as matsubara-lunch [15:56] jtv: I think delegating the deletion would be fine... happy to chat about it, or review an MP :) [15:56] Can I get some help with my branch? lp:~cody-somerville/launchpad/bug-444266/ [15:57] noodles775: great, thanks. Call it cleanUp() or something, put the Store.of(self).remove() in the default implementation, and override it in TranslationTemplatesBuildJob? [15:57] jtv: sounds good. [15:57] noodles775: ok, I can have that waiting for you tomorrow morning. [15:58] assert jtv.eod < time.now() [15:58] I created a IHasBugSupervisorEditSchema class to provide an editable field for bug_supervisor in IHasBugSupervisorEditView since bug_supervisor is defined as readoly in the IHasBugSupervisor interface. [15:58] noodles775: thanks again. [15:58] jtv, noodles775: can we determine if the object is Storm or SQLObject and DTRT? [15:58] cody-somerville: the On Call Reviewer (on #launchpad-reviews) is usually around for that kind of think if no-one here takes you up :) [15:58] bigjools: this one isn't either [15:58] ?! [15:58] but afaic the default implementation could try [15:58] /o\ [15:59] * bigjools -> OTP [15:59] can you believe it's snowing over here! [16:00] yes [16:00] you live in an arctic wasteland [16:00] bigjools: you can (I've had to create the following property on IBuildFarmJob as an intermediate measure: http://pastebin.ubuntu.com/423413/) [16:00] jml clearly fancies those, or he wouldn't have moved so much closer to them [16:01] flacoste, Don't say that. That means its only a matter of time before it starts snowing here :P [16:01] it's hot here [16:01] jtv, no, I just _really_ like grey. [16:01] "the night sky over the planet Krikkit is the least interesting sight in the Universe." [16:03] bigjools: hot here too. Still otp? [16:04] Wow, it's getting so difficult to pick out a T-shirt to wear now that they have mobs in all colours. [16:05] I loved the green ones. Waving identical little flags with fixed, almost hopeful little smiles... Very Pyongyang. [16:19] deryck, wgrant: So, adding indices doesn't seem to solve the seqscan problem with bug 539382. [16:19] (I haven't added indices for *everything* yet, maybe that'll work) [16:20] However, it may be simpler to have CalculateBugHeatJob.create() just create a new job regardless and then have the garbo process make sure that only one update gets run for that bug. [16:21] gmb, are you trying this locally? My experience is that local indexes may not get used when they will on staging. Unless you're working with a bit of BugJob data locally. [16:21] deryck, Ah, good point. I didn't realise that indices might not get used when data volume is low. I'll try and scare up a LOSA. [16:23] gmb, though you're right that ultimately it might be still be better to push the work to CalculateBugHeatJob. But indexes will help regardless of that. [16:26] In fact you'll get _completely_ different plans on realistic data than you will at home. [16:27] * jtv is out. === deryck is now known as deryck[lunch] === flacoste is now known as flacoste_lunch === flacoste_lunch is now known as flacoste === salgado is now known as salgado-lunch [17:27] deryck[lunch], wgrant: So, indices FTW. Will put a DB patch together. === gary_poster is now known as gary-lunch === deryck[lunch] is now known as deryck [17:45] gmb, good news, thanks [18:16] Night all === salgado-lunch is now known as salgado === gary-lunch is now known as gary-poster === al-maisan is now known as almaisan-away === gary-poster is now known as gary_poster [19:38] gary or barry, any suggestions on how to mock up a test for time.sleep? i have a semi-vague idea but it seems like something you'd know well [19:41] leonardr: I've simply used the Grand Hack monkeypatch approach myself. If I control the pertinent module(s) I sometimes use a "from time import sleep" within it so that I can just locally mokeypatch sleep in the module. It's possible that mocker would give you an alternate approach, but then you are adding a dependency [19:42] gary, what you're saying is similar to what i was thinking, but i'm not sure what you mean by 'the module'. do you have time to work this out in person? [19:42] sure [19:42] leonardr, maybe this could be of help: http://labix.org/mocker [19:42] Trivial mocking of any external module (e.g. time.time()) via proxy replacement. [19:43] that was my second suggestion above, yeah. But it's adding a dependency. If you need it (because you don't control the module that uses sleep) it might be a particularly good choice [19:43] gary: it also might be a good choice since lazr.restfulclient already splits out test dependencies from regular dependencies [19:43] true [19:44] gary: also, i now understand what you said originally. i'll try that [19:44] cool === lifeless_ is now known as lifeless [22:07] The size of the diff (9540 lines) is larger than your specified limit of 1000 lines [22:07] woop! [22:14] mwhudson, lol === salgado is now known as salgado-afk === ]reed[ is now known as [reed] [22:24] mars: Hi. Do you know why we still have PlotKit and slimmer in the three? [22:24] AFAICT they have been unused since 3.0 or earlier. [22:24] s/three/tree/ === matsubara is now known as matsubara-afk [22:28] wgrant, sorry, I do not know. I would have to hunt for leftover traces of them in the source. sinzui would know better than I if they are still used. [22:29] mars: I've grepped, there's nothing. [22:29] wgrant, I wanted to remove plotkit a few months ago. I cannot remember what stopped me [22:30] wgrant, I give you an rs=sinzui to remove them. I am certain no tests will break because they predate js tests. [22:30] haha. [22:31] * sinzui thinks a few bug reports after the fact will spur engineers to get rid of cruft [22:31] I have a few other deletions of unused code, but the branch hit 10000 lines (all deletions) so I might split it. [22:32] wgrant, I can look at it. I love reviewing deletes [22:49] sinzui: https://code.edge.launchpad.net/~wgrant/launchpad/remove-obsolete-js-stuff/+merge/24264, if you have a moment. [22:49] * sinzui looks [22:52] wgrant r=me [22:52] wgrant, Do you want me to land this now? [22:52] sinzui: Yes please. [22:59] sinzui: Oops, forgot to delete another copy of PlotKit. [22:59] okay [23:00] I was just looking for an old plotkit bug so I had not pressed enter yet [23:01] Ah. Pushed, and already mirrored. [23:02] bomb away [23:04] sinzui: Were you thinking of your attempt to remove MochiKit, which PlotKit needed? [23:04] yes I was [23:05] there is still some complicated script using mochikit [23:25] mwhudson: talking with flacoste solved my problem for yesterday [23:25] mwhudson: a 2005 XXX comment [23:26] :) [23:26] thumper: woot [23:31] mwhudson: can I move a pipe in a pipeline? [23:31] mwhudson: I forgot to add --before to my add-pipe command [23:32] thumper: not directly afaik, but you can just remove it and add it again? [23:32] nm [23:32] yeah, that's what I did [23:34] sinzui: I'm confused -- what is left to do for bug #44052? [23:34] Bug #44052: Auto-suggest affected project based on affected package

[23:35] It has done so for years. [23:35] any bugs developers here? [23:36] some bugwatch failures in db-devel [23:37] looks like http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10789 conflicts with a database patch in db-devel [23:55] flacoste: I've got the removal of the CustomMachine running through ec2 [23:55] flacoste: with that done, my test_traverse works in the harness now [23:56] sinzui: around?