[03:06] spm: Code imports are back online, right? [03:35] ola! [03:38] lifeless: You have successfully reached $destination? [03:42] wgrant: yes [03:42] wgrant: no thanks to air nz who rebooked a flight a day later [03:42] lifeless: ... nice. [03:42] *that* I have to sort out still - meant to have an email from the helpdesk supervisor... but no sign. [03:42] time to up fire skype. === henninge changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.11 | PQM is in release-critical mode | firefighting: - | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [08:04] Hi jtv! ;) [08:04] hi henninge [08:59] hello [09:01] Morning bigjools. [09:01] g'day wgrant [09:02] how can so much email be sent over one weekend :'( [09:02] :( [09:03] bigjools: I ran into an issue with the new buildd-manager this morning. [09:04] bigjools: The builder chrootwaited, and then it started dying like this: [09:04] 2010-11-15 10:26:29+1100 [QueryProtocol,client] File "/home/wgrant/launchpad/lp-branches/devel/lib/lp/buildmaster/model/buildfarmjobbehavior.py", line 193, in updateBuild_WAITING [09:04] 2010-11-15 10:26:29+1100 [QueryProtocol,client] build = queueItem.specific_job.build [09:04] 2010-11-15 10:26:29+1100 [QueryProtocol,client] exceptions.AttributeError: 'NoneType' object has no attribute 'build' [09:04] It's possible something was screwy with my system, but I don't think so. [09:04] new as in the one I just fixed but is not rolled out yet? === jelmer is now known as Guest97522 [09:05] bigjools: Yes. [09:05] bigjools: r11926, post-invalidation-fix. [09:05] what were you doing with it to make it do that? [09:06] The slave was under considerable strain, but chrootwaited legitimately, and this was picked up by buildd-manager. It's possible that there was a timeout, but there's nothing in the logs. [09:07] http://paste.ubuntu.com/532214/ [09:08] hmm [09:09] It looks very relevant to that fix :/ [09:10] can you force a chrootwait and see if it happens again? [09:11] I was half-studying at the time, so didn't. But I'll try now. [09:14] Also, buildd-manager seems to put more detailed error messages in the failure notes now, including the URL for failed file retrieval. Does that handle privacy etc. correctly? [09:14] no that's a leak :/ [09:14] and not an easy thing to fix [09:14] No. === Guest97522 is now known as jelmer [09:20] Morning [09:20] Morning. [09:23] bigjools: Plain chrootwait worked fine. [09:23] There must have been a timeout somewhere. [09:23] wgrant: so it might be a loading issue [09:24] The slave was having some issues responding earlier (it's a rather slow ARM device). [10:22] bigjools: Er, it came up on qastaging? [10:22] That's a little concerning. [10:23] wgrant: yes, lifeless is trying to get a publisher working on it [10:23] That still shouldn't happen unless the DB is screwed. [10:23] quite [10:24] nobody asked me so I don't know the details [10:24] Speaking of qastaging, could you time a query on there or staging for me? [10:24] (it's the source domination one) [10:24] sure [10:25] paste me something [10:25] Do you know natty's ID? [10:26] 106 [10:28] bigjools: http://paste.ubuntu.com/532246/ [10:28] Will probably return nothing. [10:28] But I only really care about speed. [10:29] with cold cache, about 10 seconds [10:29] with warm cache, 500ms [10:29] Excellent, thanks. [10:29] you want the query plan? [10:30] I guess that's a good idea. [10:30] But it seems like it should beat the current 3-minuter! [10:30] wgrant: http://pastebin.ubuntu.com/532247/ [10:31] yes :) [10:31] And no temp table required, yay. [10:34] I love performance fixes [10:35] Even if it is only 10% of the publisher :/ [10:35] it will be attritional [10:35] think of the PPA gains though [10:36] It shouldn't be too big there. I think removing the dozens of cache purges per archive might help more. [10:36] But it's hard to say. [10:46] There is so much crap on DistroSeries. [10:46] lazr.restful makes me sad. [11:32] moin [11:37] lifeless: hi [11:37] lifeless: where are you? [11:42] orlando [11:42] caribe royale [11:42] by room [11:42] *my room* [11:43] I can get more specific than that but its probably a little redundant at that point [11:45] lifeless: heh, yeah. [11:45] lifeless: I mostly meant what tz [11:45] flacostes [11:45] AIUI [11:45] lifeless: *nod* [11:45] 6 hours out from my normal [12:04] Uh. [12:04] Where did devel r11926 go? [12:04] Hmmm. Maybe it was caught in the branchChanged timeouts. [12:05] LP doesn't seem to know about it, but it's in the branch, and LP sees it in stable. [12:06] jml: did you get around to updating the derived distros LEP with your thoughts on opening new series early? [12:06] Morning, all. [12:06] bigjools: no, I haven't. [12:06] bigjools: aaaaaaaaaaaaaaaaaa [12:06] bigjools: it's on my list though. [12:07] jml: ok no rush, I'm busy with the b-m changes for now anyway [12:17] wgrant: it was caught in that I suspect [12:17] wgrant: we haven't actiond that follwup - someone needs to write ze script. [12:19] I think I'm at windmill + big honkin' js file fail again, but I have no way to really know this. [12:19] Maybe I need more coffee. === mrevell is now known as mrevell-lunch [12:31] lifeless: How was the escalation a policy violation? [12:31] Does it not permit escalation of issues that make us all look awful? [12:31] wgrant: https://wiki.canonical.com/Launchpad/PolicyandProcess/DefinitionofCriticalPolicy which you can't see [12:31] Hah. [12:31] Soon... [12:32] there is a table [12:32] I'll paste it, hang on [12:32] I think that if we want to be a credible project hosting service, we might want to actually be able to keep it properly functional outside the working week :) [12:33] wiki paste fail [12:33] but I'm sure you'll figure it out [12:33] yes [12:33] thus I'm going to drive a discussion about this with the whole team. [12:33] I think most of us would agree that this was critical. [12:33] So the mismatch isn't cultural its technical in the sense that we've written down something that doesn't match our own expectations. [12:33] Right. [12:33] -> food [12:34] well [12:34] But then there are other things like the person picker being broken for more than a week. [12:34] also, we only have 6x24 coverage from ops. [12:34] jml: the discussion has to be broader than the canonical lp dev team. [12:34] but that's kind of orthogonal to treating probs like these as critical [12:34] jml: but it needs to happen. In this instance - and *every other instance its mattered* we've had the ops support, via IS escalation. [12:35] jml: That may be, but it has to be easy enough to get assistance during that other 24 hours. [12:35] jml: What I'd like is to help get charlieS appropriate resources to not need special escalation. [12:35] wgrant: to me, that seems a separate discussion to "what is critical" [12:35] lifeless: yeah, that'd be awesome [12:35] jml: It's not entirely orthogonal, I don't think. [12:35] jml: at the same time I'd like us to keep reducing incidences of zomg moments [12:36] lifeless: I would very much like that too. [12:36] so it's agreed - let's fix everything [12:36] lifeless: although "keep reducing" implies something about the current situation that I'm not sure I agree with :) [12:37] wgrant: insofar as if we had infinite resources, we wouldn't have to care about whether a thing is critical or not, I guess. [12:38] jml: Right, exactly. You're probably not going to invoke a sparse emergency resource for something that isn't critical. [12:45] jml: I pushed some new stuff to fixtures, testresources, testrepository and mailed you a brain dump for something meeting layers functional behaviours [12:45] lifeless: I saw the email [12:45] lifeless: but not the recent changes [12:46] lifeless: every time I think about testr I get annoyed with myself that my recent changes to it aren't in the binary that my system gives me [12:46] jml: stay away from the dark side [12:46] think positive [12:47] lifeless: if I did that, I doubt I'd ever write any code at all :) [12:47] http://ftp-master.debian.org/new.html - python-fixtures [12:55] jpds: hi [12:56] lifeless: what do you mean by "edge node"? [12:57] jml: layer = Foo [12:58] jml: Foo will be on the edge of the DAG, at least while the tests using it are running. [12:58] lifeless: you mean a leaf node? [12:59] close enough; sleep deprived ravings :) [12:59] lifeless: np. :) [12:59] jml: root node strictly speaking - the pointers go away from it [13:00] lifeless: ahh yes, I see what you mean [13:00] lifeless: "there is nothing in the graph that (depends on|points to) Foo yet" [13:02] yeah [13:06] lifeless: "leaf node" is probably the best name for that, despite the directions of the arrows. e.g. a package that nothing depends on is sometimes called a leaf package. [13:06] sure [13:10] jml: I ran out of puff somewhere around texas, or I think I would have just got it done [13:10] :) [13:10] lifeless: I know the feeling. === mrevell-lunch is now known as mrevell [13:22] yay. [13:22] email, in tray & IRC back log dealt with. I hardly know what to do next. [13:22] I know, lunch and the thirty or so things on my 'launchpad' list. [13:29] jml: reset - did you read the prose in fixtures/NEWS about it ? [13:29] jml: under shared dependencies [14:00] lifeless: no, haven't. can do. [14:35] mars, ping [15:10] deryck, yo [15:10] hi rockstar [15:11] deryck, how goes the lazr-js? [15:11] * deryck wants to drive rockstar's lazr-js branch into the ground like nick fairly on a UGA quarterback. [15:11] deryck, also, war eagle. [15:11] deryck, :) [15:11] war eagle! [15:11] deryck, are the tests still failing? [15:12] rockstar, yup. I'm too the point of creating my own lazr-js branch pre yui 3.2 and back porting the two fixes I need.... [15:12] but that's non-trivial too [15:12] rockstar, my guess is that's it's the size of launchpad.js again that's playing poorly with windmill. 1.3 Mb file now. [15:13] deryck, yeah, that's what I suspected too, but I couldn't get any evidence. [15:13] rockstar, there's lots of thread contention and mars said earlier that this is likely because we're trying to go off-site for resources, but I can't find that happening. [15:14] rockstar, trying another ec2 run now with any yui config option that relates to css or combo loading set to false to see if that helps. [15:14] rockstar, beyond that, I really have no idea what to try next. [15:14] deryck, I think our configs already block going to the net. [15:15] rockstar, right. but if yui is trying to go to the net and being blocked a test could hang, right? Which is some of what seems to be happening.... i.e. windmill test hangs and the test runner kills the run. [15:16] deryck, it could fail the test, because it wouldn't be able to load js or css. I can't imagine it would hang a browser indefinitely. [15:16] Did I tell you that mikael said windmill is dead? No one is working on it anymore. [15:17] rockstar, well not indefinitely, but at least 600 seconds, which is enough to kill the run. [15:17] rockstar, and yeah, I think you mentioned that. [15:18] deryck, okay. I'm rooting for you. [15:19] rockstar, :) thanks. [15:20] deryck, also, fwiw, I'm deleting most of lazr-js, and I think it's sane to require that you have a working use case in an app before moving the feature "upstream" into lazr-js. [15:20] This "trickle down" things causes too many headaches. The wizard widget would have done well to be Launchpad for a bit first... [15:20] rockstar, really? Your deleting stuff that is unused? Is there really that much unused? [15:21] deryck, unused or unneeded, yes. [15:21] wow, ok. [15:21] rockstar, is landscape using a combo loader? [15:22] deryck, I replaced the PrettyOverlay with about 10 lines of javascript and some CSS. [15:22] cool [15:22] deryck, I don't think so. I'm going to try and convince beuno that we need the combo loader for U1. [15:22] rockstar, we have to figure something out. 1.3 Mb is ridiculous for a single js file, if we keep this 3.2 upgrade. [15:23] deryck, yeah, and U1 doesn't combine any of its js. [15:24] rockstar, yeah, in devmode FF goes gray with this 3.2 upgrade because of all the files loaded. ./utilities/yui-deps.py|wc -l == 446 :( [15:25] hmm. [15:25] sinzui: strongly tempted to fix blacklisting. [15:25] I am convinced. [15:25] he just has to do it [15:27] jml, The card is in the registry backlog. EdwinGrubbs and I agree to add a column for the team that can override the constraint [15:27] sinzui: oh cool. [15:27] jml: the editing ui landed on Friday. I used it [15:28] jml: https://launchpad.net/+nameblacklist [15:29] jpds: sorry, lost your paste [15:37] deryck, have you brought this specific issue up on the list (in its own thread, not as a mention on another thread). [15:38] rockstar, which issue (of the numerous I ranted about)? :-) The file size? [15:43] deryck, at this point, I think we seriously need to think about killing windmill. [15:43] It's either windmill goes or we stop adding javascript. That's all there is to it. [15:43] deryck, because the yui 3.2 may not break it (and we can stay on YUI 3.0 forever...) but eventually we're going to hit this again. [15:44] And by "we" I mean "you launchpadders" since beuno owns me for the next six months. [15:45] * beuno saved his reciept [15:45] rockstar, yeah. but I'm not hosting that discussion. I've said my peace about this mess, and no one else seems concerned. [16:01] hanging windmill tests.... :'( [16:02] sinzui: hello [16:03] hi jml [16:05] jkakar: Remember how I solved my getBuilds problem on Friday by using a subselect? Now I've got a resultset where count() == 1 but list() produces a 25-element list. [16:06] abentley: On a call, can't help you just now, will ping in a while. [16:06] jkakar: okay. [16:08] jml: async uploading for b-m works on DF. We now have a fully async b-m. \o/ [16:08] bigjools: sweet :) [16:08] bigjools: Yay! [16:08] bigjools: may I see the branch? [16:09] jml: it's 1k lines of diff - but please be my guest. https://code.launchpad.net/~julian-edwards/launchpad/async-file-uploads-bug-662631 [16:09] abentley: indeed. I got you a login on dogfood BTW. when you're ready we can have a chat. [16:10] bigjools: ta, I won't do a review but I'd like to glance at least. [16:10] I just made a WIP MP [16:10] bigjools: Anytime today is good. [16:10] jml: I added a new method to fetch all the files from the builder in one go [16:11] sinzui: http://mumak.net/lp-bugjam-2010/ btw [17:01] sinzui: bigjools: we still have a [smaller] issue with Archive:+packages https://bugs.launchpad.net/soyuz/+bug/675621 [17:01] <_mup_> Bug #675621: Archive:+packages timeouts [17:09] lifeless: grar, that page is a PITA [17:10] I wonder if we can make our model speed-friendly sometimes [17:12] bigjools: I made the source only version happy [17:12] bigjools: we just need to fix the binary package version [17:12] it's a start [17:12] we have the exact same problem on the queue page [17:13] I optimised the hell out of it a couple of years ago but the custom uploads need sorting out still [17:13] the high python time is a red flag to me [17:13] but I want to get the sql time sane first [17:13] yarp === deryck is now known as deryck[lunch] [17:19] flacoste: fyi rt 42472 [17:21] abentley: Here now, sorry for the delay. [17:21] jkakar: No worries. [17:21] deryck[lunch], I would like your +1 for my data fix for https://bugs.launchpad.net/launchpad-registry/+bug/660475. The last three comment show the sql, the run time, and examples of what is fixed between production and staging. [17:21] <_mup_> Bug #660475: Merged profile listed in the Top contributors <404> [17:21] jkakar: I've tracked down the bug to specifying order_by on a column of a table that's not in the resultset. [17:22] abentley: Cool. [17:23] jkakar: http://pastebin.ubuntu.com/532464/ [17:23] jkakar: The ResultSet used to refer to BuildFarmJob before I introduced the subselect. [17:24] abentley: Ah, interesting. [17:24] jkakar: I guess this is valid, if crazy, SQL? [17:25] abentley: It sounds suspicious... do you know exactly what query is being generated? It'd help to see it. [17:25] jkakar: I don't. If I drop to a debugger, can I see it? [17:29] abentley: If you do a from storm.tracer import debug; debug(True) it'll get printed to the screen when the code path is executed. [17:33] jkakar: http://pastebin.ubuntu.com/532473/ [17:35] abentley: Yeah, so the table is being included, which makes the query valid, but there are no BuildFarmJob columns so the order by is effectively useless. [17:37] jkakar: Hmm, why is BuildFarmJob in the FROM? [17:38] abentley: Because it was specified in the order by. [17:39] abentley: When you don't explicitly define tables (with store.using) Storm does some automatic inspection to make sure all the tables you need in your query are included in the FROM clause. [17:39] jkakar: I see. And in this case, it found the BuildFarmJob in the order_by clause. [17:40] jkakar: But I don't know if that is actually desirable behaviour. Because if a table is only mentioned in the order_by clause, the order_by clause won't be effective. [17:42] abentley: Yeah, in this particular case it is undesirable, but in others, like an implicit join, you want the behaviour. [17:42] abentley: Perhaps we could special-case the logic to check for order by's that don't match any columns and blow up, though. [17:42] jkakar: But if there's an implicit join, the table will be mentioned in the WHERE clause, no? [17:42] abentley: Yes. [17:43] jkakar: So getting the table from the order_by seems like it doesn't help implicit joins. [17:44] abentley: True. [17:45] abentley: It would be good to file a bug about it. [17:52] * jml gone [17:59] jcsackett, I cannot locate the bug that lead me to question why we were querying official_*. I am certain though that we should question the intent of any SQL operation that wants to know the answer. Talk to me if you see something that is not 100% needed. [18:00] sinzui: dig. [18:01] jkakar: https://bugs.edge.launchpad.net/storm/+bug/675667 [18:01] abentley: Thanks. [18:01] <_mup_> Bug #675667: Storm accepts order_by clauses that mention columns not present in the output === benji is now known as benji-lunch === deryck[lunch] is now known as deryck [18:42] sinzui, you have my +1. That's well put together and easy to follow in the comments. I appreciate the before and after shots from lpnet and staging, too. [18:42] thanks [18:46] np [18:52] bac: around? === benji-lunch is now known as benji [19:33] when working with the sqlbase cursor, what's the easiest way to get a look at the actual sql being thrown at the database? [19:51] a storm tracer [19:51] what are you trying to determine/debug/fix/? [19:51] we have some precanned ones [19:54] lifeless: sorry, didn't see the reply. i actually just finished checking it out (with a storm tracer). i just needed to confirm some values being passed in were what i thought they were. [19:58] jcsackett: alternatives [19:59] LP_SQL_DEBUG=1 bin/test or whatever [19:59] OOPS's gather whats being sent [but elide the parameters at the moment] [19:59] QueryCollector (grep for it) gathers it [20:00] lifeless: thanks. the LP_SQL_DEBUG one in particular sounds useful for situations i've hit. the tracer in this instance was perfect since i could flip it on around the one spot i cared about and then turn it back off. [20:09] joey: calling project.lp_refresh() after "project = lp.projects[project_name]" will solve the problem [20:09] in your version of launchpadlib, lp.projects[project_name] is a shim object. it doesn't go over the network until you access one of its properties [20:09] leonardr: ok will try now [20:09] so you won't get a KeyError if it doesn't exist [20:09] that also explains why httplib2 debug wasn't printing anything [20:10] there was no network call [20:10] leonardr: same with team? [20:10] joey: yes, wherever you do lp.object[name] [20:11] lazr.restfulclient.errors.HTTPError: HTTP Error 404: Not Found [20:12] leonardr: so it works for instantiated projects now [20:12] leonardr: but gives me that 404 for non-existent objects that I try to refresh [20:12] leonardr: and that's IN a try [20:13] joey: can you give me an example command line? [20:13] oh, i see what you mean [20:13] leonardr: https://pastebin.canonical.com/39779/ [20:13] try catching NotFound instead of KeyError. KeyError is dictionary semantics [20:13] and in this version of launchpadlib, lp.object[] doesn't have dictionary semantics [20:16] leonardr: NameError: global name 'NotFound' is not defined [20:16] sorry my python skills are showing [20:16] * joey reaches for his python book. [20:17] joey, it's lazr.restfulclient.errors.HTTPError [20:17] the one you had in that paste [20:18] in later versions there is a specific NotFound error, but not in this version [20:18] so try catching HTTPError and checking its .status [20:18] leonardr: yeap that did it [20:19] leonardr: strangly team is now a keyerror [20:19] leonardr: thanks a heap. It's working on staging now [20:19] leonardr: I didn't want to bypass it just in case there were other issues. Thankfully it looks ok [20:20] ok, good [20:35] leonardr: flacoste just informed me about contributes_to in lazr.restful and I just finished reading the documentation, expect a hug for you and salgado next time I see one of you :) [20:36] cr3: i think you can give most of that hug to salgado [20:36] leonardr: ok, I'll only give you half a hug then and 1.5 hugs to salgado [20:37] sounds like a good allotment [20:44] leonardr: by the way, do you happen to know where contributes_to is being used, perhaps ubuntuone or something? I just made sure I had a fresh copy of lp-branches/devel and couldn't find any usage of it [20:45] cr3: i'm fairly sure salgado was using it in launchpad, but it might have been something to do with the openid provider or ubuntu one. you should ask him [20:46] I don't think he actually got to using it, as unfortunately that project got paused due to higher priority work coming in [20:47] ah [20:48] leonardr: i think the KeyError and NotFound error is probably due to a server side change, which means that we broke backward compatibility [20:50] flacoste: i'm pretty sure it's due to a client-side change that we reverted because it caused a lo [20:50] a lot of confusion [20:50] ah ok [21:19] thumper: i've pushed the new code so you can look at the new diff in the mp before we talk [21:19] wallyworld_: ok, ta [21:40] lifeless: hi [21:40] hi [21:49] lifeless, thank you for catching the landing numbers error. That changes things a bit :) [21:50] wgrant: hi [21:50] mars: I'm curious where you got 1/53 minutes :) [21:50] lifeless, https://spreadsheets.google.com/a/canonical.com/ccc?key=0Aq6EjGubW4qydF90TElqaV9CRFR0QndmX0twV3ZDN3c&hl=en [21:51] lifeless, Google docs date calculation insanity. What works in OO Calc does not work when ported. [21:51] lifeless, it came out to 27 branches/day, which is one every 53 minutes [21:52] the total of 127 above that did not click [21:53] fixed [21:53] 27 days, not 27 branches/day [21:55] heh [21:55] hey, adding 99% to that would be nice. [21:55] 100% is 'max', which isn't terribly interesting. [21:55] ? [21:55] your quartile breakdown [21:56] 25th percentile [21:56] etc [21:56] the quartiles - I already had to truncate those [21:56] could you add 99th percentile? [21:56] yeah, I looked for a way to do that, nothing popped out - one of those moments when you say "I must be missing something obvious" [21:56] 3*stdev + avg [21:57] is close enough [21:57] hmm, ok [21:58] thumper: talk now? [21:59] wallyworld_: talk talk, or irc talk? [21:59] maybe talk talk [21:59] ok, let me get set up [22:04] lifeless, not much difference - 343 hours at the 99th percentile vs. 356 for the 100th [22:06] thumper: https://code.launchpad.net/~wallyworld/launchpad/built-packages-listing/+merge/40634 [22:17] mars: thats good to know - thanks for adding it [22:23] sinzui: we can't still add a private team as a member of another private team? [22:23] No [22:24] We certainly cannot do that until we prevent open teams from being members of restricted and moderated teams [22:24] see the team backlog [22:24] We also need to fix lots of TP calls [22:30] jelmer: Hi. [22:36] hi flacoste [22:36] hi lifeless [22:38] sinzui: how is that related? a private team is a private team, no? it can only be restricted [22:38] since you have to be a member to have access [22:39] lifeless: how's Orlando? [22:39] flacoste: good, its been a very interesting day. [22:39] we haven't done a lot of modelling yet, nor tackled things like coexistence. [22:40] will it be useful for us? [22:40] IOError: [Errno 2] No such file or directory: 'logs/thread-140648257480448.request' ??!? [22:40] They relate because that is the path we believe that must be taken to achieve private in private... [22:40] when running a test [22:42] thumper: Looks like nothing creates logs/ yet (except maybe dev appserver startup?) [22:42] wallyworld_: I think that was because your branch removes the logs directory [22:42] wallyworld_: but doesn't add it in make build [22:43] Hm, no, it's in bzr. [22:43] wgrant: wallyworld_ removed it in one of his branches [22:43] ???? [22:43] flacoste ... recall the argument of private in private was muddled by for a year. the real issue is proper constraints, private teams should be members of, or comprised of team that can be trusted. That is what must be fixed to allow use to build a hierarchy. Once we have established trust, we can fix Lp to not leak your trust [22:43] i thought i added it in the branch the consolidated the log files [22:43] It is there in devel. [22:44] sinzui: i think this is the public in a private team issue [22:44] wgrant: thumper: i did have it so that the logs dir was explicitly created but was told in the code review just to add it to bzr [22:44] wallyworld_: but your current branch I'm messing with removes it [22:44] sinzui: which could be solved independantly of private in private [22:45] or private in a public [22:45] thumper: not on my system it doesn't.... [22:46] wallyworld_: line 611 (the last) of https://code.launchpad.net/~wallyworld/launchpad/built-packages-listing/+merge/40634 [22:46] flacoste it is not. We have discussed this many times and I cannot summarise it over IRC. consider this. We all want. It has been tried many times, and all were failures. We have a path to success and I can see this fix happening soon [22:47] flacoste You are hoping that a strict rule of private in private is easier to implement. It is not [22:47] sinzui: your team has put more thoughts than I in this, so I trust your judgement [22:48] thumper: hmmm. can't explain that. the logs dir is still in lp:devel at least [22:49] wallyworld_: yes it is. [22:49] wallyworld_: it is removed in your built-packages-listing branch [22:49] wallyworld_: you may want to revert that removal :-) [22:49] flacoste: perhaps [22:50] flacoste: the modelling is the crucial bit [22:52] thumper: yep. i checked the logs of the branch. i merged from devel trunk after creating the branch and it was removed then for some reason