[00:00] elmo: ok [00:00] so we need to discuss with apache a bit more [00:00] leonardr/lifeless: unless we can guarantee the patch will go into upstream or at least ubuntu, I'd need to be convinced the maintenance cost would be justified [00:01] lifeless: in the meantime, would you mind if i applied my lazr.restful-based workaround? [00:02] leonardr: of course; I think I wouldn't have asked these questions though, if you'd had a reference to the upstream state of discussion in the patch. [00:02] e.g. bug is tracking the issue and apache are currently undecided about whether to fix this or not [00:03] lifeless: fair enough. i did link to the apache bug in my lazr.restful branch, but i didn't discuss it in any detail, and also there are two branches [00:04] elmo: I'd like to see it go into Ubuntu regardless; its nuts to do a half-job the way it does. [00:05] lifeless: hey [00:05] lifeless: voice would probably be easier if you have skype [00:29] I do [00:30] popping out to the doctors to register here etc, back soon [00:50] ok [00:55] thumper: so, skype? [00:55] lifeless: in a kiwipycon committee meeting right now [00:55] ok [00:55] this arvo perhaps, then. [00:55] its really just curiosity about what worked/didn't work with the unique stuff for you. [00:56] yep === matsubara-afk is now known as matsubara [01:43] mwhudson: where do we update the rev numbers of the sourcecode dirs? [01:43] thumper: utilities/sourcedeps.conf [01:43] ta [01:52] bzr uncommit; bzr shelve; bzr pull ../db-devel -r ancestor:../production-devel/ --overwrite [01:53] sounds like you wanted rebase? [01:53] probably [01:53] it didn't work anyway [01:53] lifeless: what should I use? [01:55] what are you trying to do ? [01:56] I created the branch from devel -r ancestor:production-devel [01:56] but what I wanted was db-devel -r ancestor:production-devel [01:56] so now I have a branch which I want to replace the history of [01:57] IIRC [01:57] make the new branch [01:57] use replay with a -r selector to replay your revisions from the branch you want to redo [01:57] it is one revision which I could trivially recreate [01:58] I was just thinking there'd be a way [02:00] Yeah, it's easy with rewrite as lifeless says. 'bzr rebase -r-1.. ../production-devel' should do it. [02:01] replay sort of goes the other way. [02:02] wgrant: from the bzr-rebase plugin I take it [02:03] bzr-rewrite [02:06] But the package is bzr-rebase. [02:06] gee that isn't confusing is it [02:07] blame jelmer [02:16] lifeless: call now? [02:17] sure [03:27] mwhudson: going to land https://code.edge.launchpad.net/~mwhudson/launchpad/unregister-bzr-git/+merge/24279 ? [03:37] thumper: it failed tests [03:37] so um, maybe? [03:57] ah === Ursinha is now known as Ursinha-afk [04:51] mwhudson: what fails ? [05:57] * thumper back later tonight to talk to europeans [08:17] god morning [08:38] hi adeuring, bryceh: is it possible to get a typo fixed before https://code.edge.launchpad.net/~bryceharrington/launchpad/api-doc-fixes/+merge/24786 gets merged? [08:38] line 10 of the diff has 'whcih' [08:38] hrm [08:39] thekorn, the ec2 instance to land the change just now completed [08:39] (not sure what that means in terms of being able to make changes) [08:40] bryceh: did you run "ec2 land" or "ec2 test -s"? in that case, your branch should soon appear in PQM [08:40] ah ok [08:41] adeuring, I ran ec2 test earlier today (with no -s), and then did ec2 land [08:42] bryceh: ok; in this case, the branch should be in PQM. Or have passed PQM [08:42] if it's too late to include the spelling fix this time through, I do plan on doing another docs fix and can include that fix with it [08:43] q bryceh [08:43] :) [08:49] Can someone please ec2 land https://code.edge.launchpad.net/~wgrant/launchpad/diffs-in-queue/+merge/25135 and https://code.edge.launchpad.net/~wgrant/launchpad/bug-558905-get-archive/+merge/25300? They both disappeared overnight. [08:50] Although I see that WindmillLayer has been killed off now, so these runs should work! [08:51] wgrant: sure. [08:52] noodles775: Thanks. [08:58] Morning [08:58] wgrant: did you have a third one? The first one wasn't approved yet so I'm guessing it didn't disappear overnight? [08:58] * noodles775 switches it to approved and sends off. [09:00] And 'morning mrevell. [09:06] good morning Launchpadders [09:07] noodles775: Interesting. It was apparently sent off, so maybe neither of them were. [09:09] wgrant: ok, both sent now. [09:09] noodles775: Thanks. === wgrant_ is now known as wgrant === henninge_ is now known as henninge === jtv1 is now known as jtv [10:56] Morning, all. [11:20] hello [11:20] how hard would it be to deploy something like librarian outside of launchpad> [11:27] A bloke's here to change my electricity meter, so I'll be offline for 40 mins or so but working on laptop battery. [11:36] gmb, hi. So I think we need to do something this cycle about calculate-bug-heat runs causing us problems. [11:36] deryck, Agreed. [11:37] gmb, do we know why it hung yesterday? [11:37] deryck, This particular problem is because it didn't run for a while during the rollout [11:37] And whilst we fixed that last week all we ended up doing was deferr the problem for a week. [11:37] So once again it's got too many jobs to deal with. [11:38] deryck, The quick solution is to cancel all the existing jobs and randomize the heat_last_updated dates of all the bugs over, say, a 48 hour period, so that they don't get all bunched up., [11:38] gmb, ah, right. So it's the offline run where we try to decrease heat on bugs that haven't been touched for awhile? We end up with too many bugs needing to be touched, so too many jobs? [11:38] But what we actually need to do is make calculation much more efficient, say with a stored procedure. [11:38] deryck, Yes, exactly. [11:39] gmb, I think we should focus on efficiency, not stop-gaps. Though a band-aid today to get us running again is fine. [11:39] * deryck looks for a bug.... [11:39] deryck, Agreed. I think we're going to have to do the calculation as a stored procedure. [11:40] The Jobs system can't cope with the volume if we stop doing the work for 24 hours. [11:41] gmb, is this bug 521447? Or really we need a new bug about number of jobs created? [11:41] Bug #521447: Uninformative error message [11:41] oops :-) [11:41] gmb, meant bug 557252 [11:41] Bug #557252: Creating CalculateBugHeatJob is very slow [11:41] deryck, I think it's a new bug altogether. I'll file one, and once that bug's fixed it will invalidate 557252. [11:42] deryck, Basically, whilst it's nice that we try to do heat calculation in python, it's just not feasible for large numbers of bugs. [11:42] (Because we do it iteratively). [11:43] If come up with a stored proceedure which does the same job then we can use that for both decay and on-change re-calculations. [11:43] gmb, and this is a trade, right? So we move the calculation out of python and into the db? We won't have to do this in two places, will we? [11:44] deryck, Right. If we're going to do this we need to do it such a way that it completely supersedes the Jobs system work, though there could be a transitional period where we use both for the sake of developer sanity :) [11:44] (Or we could have the Jobs system call the stored procedure rather than use BugHeatCalculator) [11:45] maybe so. But I think just doing it all on trigger is better. [11:46] gmb, if we do this, this would also make bug 571730 invalid, too, right? [11:46] Bug #571730: garbo-daily should prune CalculateBugHeatJobs [11:46] deryck, Yes. [11:46] gmb, ok, so let's do this then... [11:47] gmb, please file a bug about the new work to be done, then mark 571730 and 557252 invalid, citing the new bug. Then add the new bug to the bugs backlog on the board where the card for 571730 currently is. Sound cool? [11:47] deryck, Yep, WFM. [11:48] gmb, thanks! [11:48] np === magcius_ is now known as magcius [11:58] deryck, bug 582195 [12:00] gmb, great, thanks. [12:02] Thanks for nothing, mup. [12:21] noodles775: Any idea what happened to the second branch? The errors look... unrelated. [12:25] Not a set that I've seen before, either. === thekorn_ is now known as thekorn [12:46] * jml off to lunch [13:06] wuu, cafe internet works. [13:07] wgrant: yeah, the failures in the second branch look unrelated. Let me know when you've pushed the fix for the first branch and I'll resend it. [13:07] jml: so enjoy it and read some stuff you've wanted to read ;) (btw: are you using an android irc app? or a computer) [13:08] noodles775, I'm using my computer. [13:08] noodles775, and compiling notes from UDS, which I don't really need to be online for [13:09] jml: how do i use subunit to list all failed tests in a test run (i have a log file from ec2) [13:09] BjornT, pipe them through subunit-filter [13:10] BjornT, there's a bug in subunit-filter where it lets timestamps through [13:10] jml: i've figured so much out, but i can't get it to work. oh, that would explain it.... [13:10] jml: any way to work around it? [13:10] BjornT, grep, I think [13:10] BjornT, as in, grep -v "time: ", or something similar. [13:11] BjornT, https://bugs.edge.launchpad.net/subunit/+bug/567150 [13:11] Bug #567150: subunit-filter doesn't understand time [13:12] jml: right. any way to list only the names of the test, not including the tracebacks? [13:12] BjornT, | subunit-ls [13:16] cool, thanks [13:50] crap. I didn't meet adiroiban while I was at UDS :( [14:04] Hi abentley, I'm just at the point where I'm ready to refactor IBuildFarmJob to refer (and delegate) to IJob, but wanted to run a few things past you... [14:04] noodles775, sure. [14:04] Initially, it will really be only date_create, date_started and date_finished that benefit (and I'll need to add indexes on IJob for these)... [14:04] IJob.log vs. IBuildFarmJob.log is a bit of an issue - the former being Text, the latter a LibraryFileAlias reference [14:05] (we could rename IBuildFarmJob.log to log_file I guess, but we'd probably want to do IBFJ.upload_log -> upload_log_file too then). [14:05] noodles775, we haven't really used the log field yet, AFAIK. [14:06] oh. [14:06] In which case, we *could* rename IJob.log -> log_tail? [14:07] noodles775, I think so. [14:08] abentley: OK, thanks. [14:10] noodles775, any thoughts on status? [14:12] noodles775, I've been thinking that IJob.status maps pretty well to Build.buildstate, except that Build.buildstate describes failures much better. [14:14] abentley: I had planned for the moment to simply override it on IBuildFarmJob.status (as we have a lot of filtering on this field), but if you think it would be better to move them completely to IJob now, I can do that? [14:14] that scares me [14:14] This was the main point that my initial diagrams did not solve. [14:14] I am leaning towards letting each job type have its own failure states. [14:15] But using IJob.status for everything else. [14:15] wgrant, me too. [14:15] Since it covers most of it. [14:15] But, well, it's slightly awkwarded, which is why I didn't propose it initially. [14:15] Woah. Awkward. [14:16] noodles775, were you planning on implementing IJob.status in terms of BuildFarmJob.status ? [14:16] wgrant: how would we filter for all builds where the set of statuses for the filter are on different tables? [14:16] jml: eh. there will be other UDS-es :) I also missed the LP meeting [14:16] (well, ok, it'd be possible, but seems overly complex) [14:16] noodles775: Therein lies the awkwardness. [14:17] Which is why for the moment I wasn't goin to try to merge the statuses, but continue with IBuildFarmJob.status defining all the statuses we need. [14:17] I think job status and build state are somewhat orthogonal [14:17] Everything else is easy. [14:17] bigjools: They only appear to diverage once the build is complete. [14:18] And then only upon failure (at the moment, at least) [14:18] for all of our build types? [14:18] Yes. [14:18] and future types? :) [14:18] I can't think why not, but it is something to think about. [14:18] bigjools, I don't see how they can be orthagonal. They can't disagree about whether the build failed, succeeded, or hasn't been attempted. [14:18] Exactly. [14:19] you're making the mistake that they represent the same thing [14:19] At the moment they do. [14:20] I am playing devil's advocate to some extent, but I'm kinda wary of having a one-size-fits-all status [14:21] There are, I guess, statuses like ABORTING and ABORTED that we probably need. [14:21] I wonder how that would be implemented or map onto this. [14:21] bigjools, Jobs are intended to be general. If there is a state that they can't represent in general terms, we should add it. [14:22] yeah, I want a new build status that represents an admin terminating it [14:22] wgrant: ABORTING and ABORTED would be such new JobStatus items. [14:23] noodles775: I guess they could be. [14:23] Since they are general. [14:23] abentley: should we have a massive list of states, and change the state transitions depending on the job type? [14:23] * jml hates human computer interfaces [14:24] * bigjools hates humans and computer interfaces [14:24] bigjools, I don't think we should. The idea with Jobs was that the general states would be represented by Job.status, and failure modes would be specified in Job.reason [14:25] OK, but that would be a bigger change than I can afford right now for package builds. [14:25] abentley: Is that a string? [14:25] noodles775, sure. [14:25] wgrant, yes, and actually, I may be wrong about that. [14:25] Hmmm. [14:25] Is that another thing that isn't used anywhere yet? [14:26] The comment on reason suggests it's the reason the job was created, not the reason it failed. [14:26] Ah. [14:27] bigjools, I also notice that the comment on Job.status mentions "cancelling" and "cancelled" as possible statuses. [14:27] So, fwiw, the only way forward I can see for the moment is to have all status represented by JobStatus. [14:28] (or leave the IBuildFarmJob is an IJob for later). [14:28] I'd really just shadow IJob.status for now. [14:28] Ah. [14:28] wgrant: yes. [14:28] This change is already massive enough... [14:29] +1, over 7k lines at the moment, that I want to land as soon as we've tested on dogfood. [14:29] Oouch. [14:30] noodles775, yes, I just asked your thoughts on status. Doesn't have to be now. [14:39] danilos, henninge: can anyone help me with understanding a test failure in test_getPOTMsgSetBySequence (lp.translations.tests.test_shared_potemplate.TestTranslationSharingPOTemplate)? === joey` is now known as joey [14:40] BjornT: Show me. ;) [14:41] BjornT, are you, by any chance, changing sampledata? [14:42] henninge, danilos: http://paste.ubuntu.com/435535/ [14:42] danilos: no. i am however changing the sequence number [14:43] BjornT, how are you changing it? [14:43] danilos, henninge: it seems that i get this when if factory.getUniqueInteger() returns 1, but the test doesn't contain any guards against it, so i'm not sure what the right thing to do is [14:43] BjornT, setSequence call doesn't do any checking because it assumes you know what you are doing (for performance reasons) [14:44] danilos: i changed factory.getUniqueString() not use factory.getUniqueInteger() [14:45] BjornT, let me take a look at the test then [14:49] BjornT, I'd have to see the branch to see where the problem is, because test seems sane otherwise [14:50] BjornT, i.e. it depends on what's going on: what the names for self.devel_template and self.stable_template are etc. [14:50] BjornT, the test shouldn't depend on getUniqueString at all [14:51] BjornT, except maybe person creation and such [14:51] danilos: you could apply this patch: http://paste.ubuntu.com/435540/ [14:52] danilos: it doesn't depend on getUniqueString directly, it just depends on getUniqueString() calling getUniqueInteger(), so that getUniqueInteger() won't return 1 [14:52] at least as far as i can see [14:54] jml: is there a standard way of doing diagrams to show chains of Deferreds? [14:56] bigjools: not really. See http://twistedmatrix.com/documents/current/core/howto/defer.html http://twistedmatrix.com/documents/current/core/howto/gendefer.html http://twistedmatrix.com/documents/current/core/howto/deferredindepth.html [14:56] BjornT, yeah, that does sound likely, you can simply fix it by setting the sequence to 2 instead, or, what's probably better, use getUniqueInteger in setUp instead (though, that will needlessly get different sequence ids for each of the tests, but not a big deal) [14:56] bigjools: in general, it's an implementation thing, not an interface thing, so there's rarely a reason to draw such a diagram [14:57] jml: ok, I want to draw the decision tree for the buildd-manager [14:57] rockstar, BjornT, I landed the branch that disables the windmill suite on ec2. ec2test should work again. [14:57] bigjools: then just draw a flowchart [14:57] * jml in a call [14:57] jml: that's what I was doing until I stopped and wondered if there was a Twisted Way :) [14:57] thx [14:57] bigjools: np [14:57] danilos: ok. i think i will hard code it, because it's hard coded in other tests, so using getUniqueInteger() in setUp() might make other tests fail. [14:58] BjornT, sure, makes sense [14:59] bigjools: btw, I looked up the deferred implementation. There's already some code that does "if isinstance(result, failure.Failure)" [15:00] jml: ah precedence is wonderful [15:00] bigjools: no, as in, the check has already been performed by the time it gets to your custom check :) [15:00] bigjools: another diagrammatic tool that people use sometimes is state machines [15:01] yes [15:02] jml: it would be nice to have a state machine internally instead of this mishmash of code [15:03] but I want to re-work it anyway [15:04] bigjools: Are you also planning to rework the internal bits of code that think they are synchronous, but really aren't? [15:04] Or is that out of scope? [15:05] wgrant: which bits do you mean? [15:05] bigjools: dispatchBuildToSlave and other bits and pieces around that where make synchronous calls to RecordingSlave. [15:05] RecordingSlave then forges successful XML-RPC responses, so it can execute the real calls later. [15:06] I think that's just an artefact of RecordingSlave [15:06] So people tend to assume that they will get real results in those methods... when in fact methods will fail without anybody noticing. [15:06] Right. [15:06] that's how it's designed to work [15:06] which is fine for now [15:06] I imagine it was only built that way so slavescanner would continue to function. [15:06] I aim to attack 2 things: [15:06] But slavescanner is dead now. [15:07] 1. make build uploads asychronous by throwing them in a queue and forgetting about them [15:07] \o/ [15:07] 2. throw away the global scan, and have a scan interval on each builder instead [15:07] Right. A separate state machine for each builder. Yay. [15:08] That will fix just about everything. [15:08] at that point we'll have solved most of the scalability issues [15:08] then we can start making the rest of the code nicer [15:08] Yep. [15:09] the design of the b-m was influenced too much by the slave scanner really [15:09] Well, it had to not break slavescanner. [15:09] that's separate [15:09] I mean the global scan [15:09] Ah. [15:09] we could have done separate scans on each builder right from the start [15:10] Mm, yes, I guess so. === leonardr is now known as leonardr-afk [15:46] mars: about your branch to disable windmill tests on ec2. did you land that one through ec2tests? :) [15:47] BjornT, nope, ironically [15:48] mars: maybe you should have :) looking at your patch, it looks like you've now enabled the mailman tests, haven't you? [15:49] BjornT, ? I did not touch that code. [15:49] mars: but you changed which layers are run [15:50] mars: it used to be !MailmanLayer. now it's !WindmillLayer. no? [15:50] BjornT, yes. I added another --layer switch to disable the windmill tests. bin/test adds yet another layer switch on its own to disable mailman. [15:50] mars: i don't think so. the defaults are there, in case no --layer is specified only [15:52] BjornT, ah, so I misread the code in bin/test then. Either way, I doubt I would have noticed the mailman tests running on ec2. [15:52] Well... the mailman tests normally mostly fail. [15:52] So you probably would have. [15:52] mars: well, what wgrant said :) [15:53] :) [15:54] OK, so, yes, it looks like MailmanLayer is running :( [15:54] That explains the odd failures that one of my branches had. [15:54] BjornT, so is there anything that needs to be fixed outside of adding the explicit --layer=!Mailman ? [15:57] mars: nope, adding the explict !Mailman is the right thing to do, i think. i would use --layer=!(MailmanLayer|WindmillLayer) just to be sure, though. i don't think using --layer=!MailmanLayer --layer=!WindmillLayer will work [15:58] BjornT, ok, will do so as soon as rf-get completes === leonardr-afk is now known as leonardr [16:09] noodles775, what is the relationship between BinaryPackageBuild.is_virtualized and BuildQueue.virtualized ? [16:09] noodles775, err, not BuildQueue. SomethingJob.virtualized [16:15] abentley: so currently BinaryPackageBuild.is_virtualized just returns whether the associated archive is virtualised, which isn't great, which is why the new schema adds a virtualized attribute to BuildFarmJob. [16:15] abentley: which I'm guessing you saw yourself... do you have a suggestion? [16:16] wgrant, look at the bright side: at least the ec2 server didn't hang [16:16] mars: True! [16:16] noodles775, I'm just trying to understand the various attributes. Seems like virtualized returns is_virtualized, which returns archive.virtualized. [16:17] noodles775, if we have all these attributes, I would expect them to vary. [16:18] abentley: IBuildFarmJob.virtualized is a Bool db attribute... (and I've not yet removed IBinaryPackageBuild.is_virtualized, but intend to)... or did I miss something? [16:20] noodles775, No, that sounds like a sane plan. [16:33] abentley: great. Let me know if you spot anything else. === Ursinha_ is now known as Ursinha === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === matsubara is now known as matsubara-lunch === Ursinha is now known as Ursinha-lunch === kfogel is now known as kfogel-lunchpad [17:39] flacoste: Hi. Just sent you some request again about presentation @OWF... in case you missed previous emails and could ACK me [17:40] jml: as I didn't get any response from you about presenting @OWF, I just resent a query to Francis, but of course, I'd appreciate if you responded too ;) [17:54] what is the prefered way for naming the Y.namespace variable ? In the current code we have the folowing http://paste.ubuntu.com/435636/ [17:58] does launchpad use storm as the ORM layer or is there some other piece of tech involved? === gary_poster is now known as gary-lunch [18:06] We're in testfix? [18:06] zyga, yes, storm is our preferred ORM. [18:06] rockstar, are you aware of any django-on-storm projects? [18:07] zyga, yes, Ubuntu One uses storm and django. [18:07] rockstar, can I (canonical) get a peek at the code to see how to piece django and storm in a sensible way? [18:07] anything that you might share would be beneficial to me [18:08] zyga, you're asking the wrong person. You should probably ask someone on the U1 team. [18:08] rockstar, #? #ubuntu-one? [18:08] zyga, no idea, actually. [18:08] ok, I'll check, thanks [18:09] zyga, I believe jamesh made a storm mailing list post about using storm and django as well. [18:09] adiroiban, var namespace = Y.namespace('lp..'); is correct. === beuno-lunch is now known as beuno [18:10] rockstar: thanks! === matsubara-lunch is now known as matsubara [18:26] good night Launchpadders [18:26] rockstar, grats on your dementating! [18:27] jml, I had to stop and think about that. [18:27] jml, I thought you knew more about my mental health than I did... :) [18:27] (although that wouldn't surprise me) [18:27] I have orbs. === salgado-lunch is now known as salgado [19:01] rockstar: is this wikipage still valid https://dev.launchpad.net/JavaScriptBuildSystem ? === mup_ is now known as mup [19:08] adiroiban, the part about new script files is correct. Plenty of examples in base-layout-macros.pt [19:08] adiroiban, the CSS story is different. [19:09] adiroiban, look at buildout-templates/bin/combine-css.in to see how the different CSS files are pulled together. === Ursinha-lunch is now known as Ursinha [19:10] mars: there is also utilities/lp-deps.py [19:12] and it looks like in base-layout-macros.pt, the JS files must be manualy added for devmode [19:12] or I am missing something ? [19:13] adiroiban, when you add a file to the devmode block, lp-deps will pick it up as a new dependency. It will be automatically rolled into launchpad.js. [19:14] mars: ok. but what is the recommended way for incliding JS files: in base-layout-macros.pt or in each templates? [19:14] adiroiban, that depends where the JS is used. What did you add? [19:15] mars: I'm moving the translation js files from canonical/launchpad/javascript to lib/lp/translations/javascript [19:16] adiroiban, then they are probably listed in base-layout-macros.pt [19:17] one file is in base-layout-macros.pt while others are in other templates [19:17] but the file included in base-layout-macros.pt is only used in 2 other templates [19:18] adiroiban, how heavy are the other files? Are they all used on only one page? [19:19] mars: yes. they are used on only one page [19:19] but in production, all js files are merged into launchpad.js. right? === kfogel-lunchpad is now known as kfogel [19:20] I believe that is the case if and only if they are listed in base-layout-macros [19:20] lp-deps.py does not scan every template file in launchpad [19:21] adiroiban, to my knowledge the other applications combine everything together into one JS file, then have it all in launchpad.js [19:22] regardless of whether it is used on one page, or on many [19:22] it works because the vast majority of the JavaScript for LP is in the YUI Core. Our apps are very thin on top of that. [19:23] mars: that is correct. and if in production, all js code is merged in launchpad.js, then why not put all js file include statements in base-layout-macros ? [19:23] adiroiban, I do not know why translations chose to do it otherwise. [19:24] also, I can not guarantee that those files are minified [19:24] if they aren't in the JS rollup [19:24] mars: how do I know if a file is minified? [19:25] adiroiban, simplest way is to visit that page on staging.launchpad.net, View Source [19:25] see if it looks like jibberish :) [19:25] adiroiban, if you tell me a URL to check, I can do so for you [19:25] https://translations.edge.launchpad.net/ubuntu/lucid/ [19:26] mars: sorry. https://translations.edge.launchpad.net/ubuntu/lucid/+imports [19:27] lib/lp/translations/templates/translation-import-queue-macros.pt has an javascript include tal condition for devmode [19:28] mars: it should be build/translations/translations.js [19:28] adiroiban, it looks like everything on production has been properly rolled into launchpad.js [19:29] mars: then it would make sense to put the include statements in base-layout-macros. or not? [19:29] It sounds like it, yes. [19:30] mars: and then maybe we can add a note on the wikipage that js includes can be put in base-layout-macros, rather than in templates using tal conditions for devmode [19:30] yes, that would help [19:31] ok. righ now we have „To add a new YUI3 dependency, just add a new