[00:21] * mwhudson lunches [00:58] * thumper lunches [01:36] * thumper frowns [01:37] Kontact has gone awol [01:44] haha [01:44] ec2 test launched an instance with the same ip as another i'd previously launchpad [01:45] so ssh complained about the key changing [01:45] heh [01:46] chalk up another failing git import with submodules [02:00] * mwhudson finds why ec2 instances aren't shutting down, oops [02:31] * mwhudson kills the wrong instance by mistake :( [03:31] bugger [03:46] :((( [03:46] I have a bad feeling about this... [03:48] mwhudson: got a minute for a quick call? [03:49] thumper: sure [04:19] how did it get to be 17:20 ? [05:04] * mwhudson eods [05:32] * thumper EODs [08:35] goodd morning === noodles775_ is now known as noodles775 [09:26] Morning [10:22] mrevell, hi [10:24] hey there jml [10:25] mrevell, the boiler in my house is on the blink [10:25] yay [10:25] I mean, umm, ahem. [10:25] mrevell, how's things? [10:27] jml, Ah, that's no good and explains the "Hot water doesn't work" comment :) Thing ah okay, even if my head is slightly in Dallas still. [10:27] How was your first trans-Atlantic flight jml? [10:28] s/ah/are [10:28] safe :) [10:28] man alive [10:28] jml, heh, that's a fairly minimal commendation of a flight :) [10:28] brb [10:30] hi al-maisan, care to help me out a little bit with orientation w.r.t. the buildd work? [10:30] jtv: of course! How cam I help? [10:31] *can [10:31] al-maisan: great. Well first of all, my understanding is that the build slave writes its output files into a directory, and then process-upload.py finds the files there & does the processing on the "real LP" side. Is that right? [10:33] jtv: yes, after the build slave finishes a job successfully, the buildd master will upload the files to whereever they are needed next [10:33] that "upload" happens in the LP db (librarian etc.)? [10:35] jtv: I was just looking at the code but, yes, I believe the librarian is used as a buffer [10:35] i.e. the files go to the librarian first [10:36] al-maisan: I won't bite if you get the details wrong :-) [10:36] IBuilder.transferSlaveFileToLibrarian() ? [10:36] * al-maisan is relieved ;P [10:36] noodles775: That sounds probable. :-) [10:36] They don't normally go straight to the librarian. [10:36] who calls process-upload.py though? [10:36] jtv: cron? [10:36] I don't see any calls to it, and it's not in cronscripts [10:36] buildd-manager grabs them from the slave, dumps them in a directory. [10:36] * jml back [10:36] It calls process-upload.py (it's in the production configs, so grep won't find it) [10:37] ah, there you go [10:37] process-upload.py looks in the directory, uploads stuff to the librarian, and fiddles with the DB. [10:37] very succinct :-) [10:37] answers pretty much everything. [10:37] wgrant: thank you for explaining the workflow. [10:37] and throws in a free use of "to fiddle with" as well [10:38] I guess transferSlaveFileToLibrarian might be used for the build log. [10:38] jtv: Sorry. [10:38] wgrant: no I wasn't being sarcastic! [10:38] Oh. [10:38] wgrant: it just sums up everything I wanted to ask (for now :) and leaves out the stuff that wouldn't mean anything to me yet. [10:40] There are build ids encoded in the directory names, right? [10:40] Yes, but that's not important for anything. [10:40] (And they're easily faked by malicious users on the buildds) [10:41] The build ID is passed to process-upload.py directly. [10:41] ah! I thought it was the other way around: the build id being kept in the db, and the slave not trusted about things like which ubuntu release it's working for [10:41] * jtv should have waited before talking :) [10:42] There's just a bug or two which means some untrusted values show up in logs and directory names. [10:43] can't check everything all the time I suppose [10:43] so something in a cron job figures out which builds are finished, and invokes process-upload.py on each in turn? [10:44] No. buildd-manager is a daemon, and it polls every five seconds. [10:44] It starts new builds as appropriate, and uploads complete ones. [10:44] oic [10:45] so how does a slave signal completion? write a marker file somewhere? [10:45] wgrant: when you say uploads complete ones - doesn't it just dump the files, and process_upload takes them from there (as you mentioned above)? [10:45] jtv: The daemon running on the slave reports a status of WAITING. [10:45] oh, that's done in xmlrpc? [10:45] jtv: Remember that buildd-manager polls the XML-RPC status() method every five seconds. [10:45] Right. [10:45] noodles775: Well, yes. [10:46] So for generalizing the process, either the daemon could call a different script for other job types, or the process-upload script could diversify to handle them [10:47] The way buildd-manager handles uploads is going to change a lot soon. [10:47] Because at the moment it is synchronous. [10:47] Which really sucks. [10:48] yep, there's a spec for that too (which I'm sure you know ;) ). [10:49] Although I'm not sure it's changing in the right way, since an in-process solution will be necessary for the poppy replacement anyway. [10:49] I didn't want to get too far ahead of things... still exploring the existing system :) [10:49] * noodles775 too :) [10:52] wgrant: I may have known at some point what poppy was (in this context ;-) but if so, I forgot... are you saying it's to be generalized into the same build-job system but needs its processing to happen in the daemon rather than a child process? [10:53] jtv: No, no. poppy is the external FTP source upload processor. The only relation is that it needs to have done to it exactly the opposite of what is proposed be done to buildd-manager's upload processing. [10:54] ah, was it the one that used to have (by far) our longest-running test? [10:54] I do not know. [10:55] But it breaks a lot. [10:55] And confuses users. [10:55] wgrant: never mind the details, you sold me at "FTP" :-) [10:55] Heh. [10:56] Morning. [10:56] hi deryck! [10:57] wgrant: does a slave gets a source deb or a tarball in the filesystem or librarian as its "starting capital"? [10:58] I'm asking because I saw mention of branches as well. The Translations jobs will want to read branches (though afaik no private ones) [10:58] The mention I mention was in the past days' mailing-list discussions [10:59] jtv: It gets a number of SHA1s and filenames that it has to download from the librarian itself. [10:59] so I guess it gets specific access to the librarian and little else [10:59] I imagine you'll pass in a branch URL of some kind, and the slave will check it out of bazaar.launchpad.net itself. [10:59] networking-wise, I mean [10:59] Right. [11:00] librarian, plus the PPA and primary archives. [11:00] I imagine that will have to be adjusted, though. [11:01] probably less fragile than checking out the branch, rolling a tarball, and feeding it into the librarian :) [11:01] Very probably. [11:02] and if we have no private branches to worry about, the auth can be the simplest one of all: anonymous-only [11:02] so a malicious package could subvert its build slave and get... publicly available source code [11:02] Right. [11:02] Which isn't good, but it can be done with the librarian already. [11:06] I think the list of packages installed on the slave also came up... any idea whether that list is explicit somewhere? [11:07] A plain buildd-flavour debootstrap, with some added lamont magic. [11:07] But pretty much just the basic buildd installation. [11:08] * jtv looks intrigued in a mountaineer's "do we really have to climb this thing?" way [11:08] How are dependencies going to be specified in your case? [11:09] that's something I don't know about yet: there'll be some fixed ones I'm sure, and the package's build dependencies may come into it as well [11:10] oh [11:10] I do remember reading that the slave starts by doing an apt-get upgrade [11:10] Right. [11:10] so presumably it can do an apt-get install just as easily [11:11] It can do anything. [11:12] and that's done before any untrusted code runs, so probably not too hard to splice in [11:12] Right. [11:13] actually there's something else _very basic_ that I haven't asked about (and thanks for your patience!) and that is, what about the vms & chroots? Do we kick off vms inside a chroot each? [11:14] you don't know about the VMs. They just appear as normal machines that happen to be reset before a new build is started. [11:14] The slave then starts up inside the VM. [11:14] So everything happens inside the VM. [11:15] oh, and then the package build happens inside a chroot inside the vm? [11:15] Exactly. === matsubara-afk is now known as matsubara [11:16] and the vms run on different archs for the various builds, right? (something we won't have any interest in) [11:16] Right. [11:17] oh, but there must be a provision for this already since there are any/all packages [11:17] arch-indep ('all') packages are built on the i386 builders at the moment. [11:17] that's fine for us, and not having to care is fine as wll [11:17] *well [11:18] The problem there is that it overloads the i386 builders. [11:18] But no point worrying about that now. [11:19] right [11:20] now actually we won't really be building a package, but a branch, so all this stuff won't be present—but maybe it'll make sense to pretend [11:21] "all this stuff"? [11:26] (sorry, distractions elsewhere) [11:26] by "all this stuff" I meant the build dependencies and the "architecture" [11:27] You probably care about build dependencies, since I preusme you're executing untrusted code. [11:30] right; we don't have the deb metadata in the branch though afaik [11:30] * jtv hasn't even looked at deb packaging in a while [11:30] so for those, we don't have them; we care about them; and it may make sense to pretend to some extent that we're working from an uploaded package [11:31] (and dig up the info from elsewhere) [11:31] Right, in most cases you won't have a debian/control to slurp build-dependencies from. [11:31] But you are going to need to get them from somewhere. [11:32] will we need them for building the pot files in the most common intltool setup? [11:33] I know very little about translations. [11:33] the answer may even be something complicated like "technically yes but there's no absolute need to support that off the bat" [11:51] * wgrant sleeps. [11:51] wgrant: g'night and thanks! [11:51] np [11:54] henninge: you had a chance to look into the intltool stuff yet? [11:54] jtv: nope [11:55] henninge: ah ok... I just got a lot of things explained to me... most of it not relevant to the parts you're set to work on, but one thing I don't know yet is whether I'll need to install a package's source dependencies in order to build the templates [11:56] (in the initial case at least; I guess it becomes more and more likely as we support more cases that we'll need them) [11:56] * jtv rests his wrists [11:57] jtv: I wouldn't think that source dependcies are needed [11:58] * jtv hopes not [11:58] but not ruling it out :) [13:20] deryck, rockstar: either of you want to land https://code.edge.launchpad.net/~brian-murray/launchpad/bug-485229/+merge/15040 ? [13:21] jml, i will. [13:21] deryck, thanks. [13:21] jml, ec2 had test failures so need to chase those and then will land. [13:22] deryck, ahh ok. [13:22] deryck, Brian asked me in person what the deal was with landing so I thought I'd chase it up. [13:24] jml, yeah, no worries. === salgado changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 3 of 3.1.11 | PQM is open | I am Zero OOPS and So Can You! http://is.gd/4fkLl | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ [13:50] * jml -> errands [13:55] salgado: ping [13:55] hi sinzui [13:55] salgado: do you own a mirror in production? [13:55] sinzui, yep [13:56] staging is not updating so I cannot test that I fixed the change owner permissions [13:56] I'll test it on edge [13:57] salgado: thanks [13:58] sinzui, it works! [13:58] \o/ [14:27] morning folks === abentley1 is now known as abentley [14:48] EdwinGrubbs: bug 297833 [14:48] Bug #297833: Attempting to invite a private team fails with "Constraint not satisfied" [14:53] beuno, hello [14:53] flacoste, hello [14:53] hello jml! [14:53] call in 5? [14:54] jml, hey [14:54] flacoste, indeed [14:55] beuno, guess what I just bought [14:55] silent headphones! [14:55] jml, PALM PRE! [14:55] beuno, \o/ [14:55] those work in Argentina? [14:55] jml, woooooooooooooo [14:56] jml, and? I can't see your happy face through IRC very well [14:56] beuno, well, I haven't actually got it to do anything yet [14:59] yeah, staging was updated! [15:00] everyone can clear their QA queue! === salgado is now known as salgado-lunch [15:04] beuno, have you seen this sprite problem before? https://translations.edge.launchpad.net/ubuntu/karmic/+source/apturl/+pots/apturl/av/+translate [15:06] jtv, I haven;t [15:06] jtv, the sprite is applieed on the wrong element [15:06] (on the div, on the p) [15:07] or something like that [15:09] beuno: I don't see the sprite class on anything in the dom so far... do you see it? [15:09] beuno: jtv: I still see developers doing that [15:09] jtv: the sprite class just sets the padding, but you are using the sprite TYPE class [15:09] sinzui knows all about it [15:10] btw, sinzui, are you still doing UI reviews? [15:10] ah, this one says "error message" as classes for the div [15:10] I'd like to get us back to the graduation process :) [15:10] jtv: If a CSS class shows an image, it is a sprite that is designed to be on an inline element with the default line-height [15:12] beuno: I have. The only one of interest though I did with noodles775 for henninge. [15:12] sinzui, please continue adding me to the MPs and pinging me [15:13] sinzui: in this case it's the "error" class that produces the sprite—but I think it's there to produce the big red "stop" sign [15:14] jtv: error is the big sign that is used in notifications [15:14] sinzui: that's the one I'm talking about, yes [15:14] I don't really see what this div does differently from other ones, apart from having more text [15:15] e.g. product-purchase-subscription.pt (arbitrary example) seems to do much the same thing [15:16] ahh, p vs div maybe [15:17] jtv: p and div and both block elements [15:17] jtv: we need to copy the notifications markup [15:17] sinzui: copy from where? [15:18] notifcations are global lp/app/template/base-layout-macros.pt [15:19] jtv: Consider that form errors and and information notifications display correctly, so that is the markup we want to copy [15:22] sinzui: thanks, I'll see what I can figure out from there [15:24] filing bug first [15:24] deryck, around? [15:25] mars, hi [15:25] hi deryck, would you have some time to review my one-line CSS change to fix bug #484848? [15:25] Bug #484848: Subscriber icons in the subscribers portlet appear on a separate line from the subscribers' names [15:26] mars, sure [15:26] done [15:27] beuno: jtv: firebug shows each paragraph in that block is inheriting the div's .error .message classes. That is wrong [15:27] right, it's the surrounding div that currently has those classes [15:28] should I use view/notifications instead? [15:28] mars, Looks good. r=me. [15:29] deryck, ok. beuno, ping, care to review my CSS hack? [15:30] mars, sure, just waiting for the diff to come up [15:30] deryck, I think there is a better fix, by applying the correct styles to the surrounding tag [15:30] however, I ran face-first into a limitation of our framework - we can't call something like person/fmt:css-styles-that-should-be-applied [15:30] mars, just one question, why do we need to special-case subscribrers? [15:31] mars, I did add a question to the review for the need for XXX, but will defer to your final judgment on that. [15:31] beuno, the markup in the subscribers portlet is such that the sprite gets assigned a 90% width value [15:32] beuno, an it also gets assigned the inline-block style. Those push the sprite and the text onto different lines. [15:32] This pulls the text back inline. The correct fix is to change the markup, but like I said, our framework doesn't allow for that. === matsubara is now known as matsubara-lunch [15:33] mars, gotcha [15:33] mars, I'm +1, said so on the MP [15:33] Chex: Do you know why staging has not updated in 2 days? [15:34] to be honest, what should be a trivial fix was very difficult. There were a dozen ways to do it, and even when I chose a way to do so, I didn't know if it was right or not. [15:35] and it took a lot of investigation - many hands have touched that code for specific reasons. You can't touch it without worrying about regressing someone else's work. [15:37] sinzui, didn't flacoste say earlier that staging had finally updated? [15:37] It was update friday. and was not updated 1.5 hours ago [15:38] beuno, deryck, thanks for the reviews. [15:38] mars: staging is definitely stale. [15:39] mars, np === salgado-lunch is now known as salgado === jamalta_ is now known as jamalta === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara [17:12] abentley, around? [17:13] mars: Hi. === beuno is now known as beuno-lunch [17:14] hi abentley. We are doing the YUI 3.0.0 upgrade for Launchpad, and it is live on staging. We need help testing the pages for errors. Would you or rockstar be able to give us a hand? [17:15] mars: I guess so. What do you want me to test? [17:15] abentley, well, anywhere that you came up with custom javascript, that windmill may not cover so well. [17:15] mars, I'm unavailable this week. [17:16] mars, why can't you just run the windmill tests? [17:16] rockstar, ok, thanks for the heads up. [17:16] mars, I think if you just pass the staging url to the CodeWindmillLayer tests you should be to use our windmill tests against staging. [17:17] rockstar, if you feel that is sufficient, then OK. I can't be sure what your windmill-to-feature coverage is like. [17:17] mars, we've been pretty strict about making sure that at least the interaction is tested. [17:18] rockstar, abentley, ok. === deryck[lunch] is now known as deryck [17:37] mars: Replying to a code review comment doesn't work because "Error: Y.one("label [for=field.vote]") is null" [17:38] abentley, alright, first question then: did the windmill test catch it? [17:38] mars: No. [17:38] i don't think you can use dots in identifiers in selectors [17:38] bin/test --layer=CodeWindmillLayer --test=??? [17:38] right [17:39] that little issue :( [17:40] abentley, ok, please file a bug, tag it yui-3-upgrade [17:48] intellectronica, mars: you could use a dot in selectors in the previous yui version we used. [17:48] BjornT, ah, but can you do so now? [17:50] mars: iirc bug commenting selects by an id containg a dot [17:52] mars: yes, Y.get('[id="field.comment"]'); works [17:53] abentley, ^ [17:53] maybe it is the quoting? [17:53] mars: Isn't this a Y.one vs Y.get issue? [17:56] abentley, they should be the same function. Y.get() is deprectated. [18:02] beuno-lunch, my palm hard locked during an update [18:04] anyone seen this psycopg error before? http://paste.ubuntu.com/326281/ [18:04] abentley, BjornT, those selectors worked for me, with and without quotes. abentley, I suggest checking that the element is actually in the HTML. [18:05] mars: I did. [18:05] mars: And it works on edge. === beuno-lunch is now known as beuno === abentley is now known as abentley-lunch [18:17] abentley-lunch: where are you seeing this failure? latest devel works for me [18:17] BjornT: On staging [18:18] abentley-lunch: at what url? staging worked for me as well [18:19] abentley-lunch: i tested it here: https://code.staging.launchpad.net/~bjornt/launchpad/form-overlay-render-by-default/+merge/10249 [18:33] EdwinGrubbs: I volunteered your time to help QA https://dev.launchpad.net/LaunchpadTestPlan/3.1.11 lazr-js items in exchange for a a speedy review [18:36] sinzui: yeah, I heard that on the call. Is the only page that I need to look for tests on? I didn't know we were still tracking bugs on "Launchpad itself". [18:37] That page is the failover. testplans are bogus because they claim to test applications, but it is actually team members [18:38] EdwinGrubbs: All my answers and blueprints fixes were wrongly assigned to the the registry app for example. The Launchpad page is for fixes landed by a non-launchpad team member [19:32] intellectronica, I just found an issue with the save/cancel buttons when editing a bug's description. the buttons move to the middle of the screen after clicked: http://people.canonical.com/~salgado/edit-bug-description.png [19:32] is that a known problem or should I report it? [19:34] beuno, but now it's working again, thanks to the very cool people in #webos [19:34] jml: you have a pre? [19:34] jml, wooooo. What happened? [19:34] deryck, maybe you know (^)? [19:35] salgado: i think it's yui3 fallout, you can see on staging but not on edge, not sure if there's a bug though [19:35] beuno, I tried updating to webOS 1.3.1, it failed. [19:35] salgado, I suspect it's the newer version of that widget not playing nicely with the way it's implemented in LP [19:35] beuno, I had to use their firmware fixer thingy, which of course doesn't work with 64 bit linux [19:35] mwhudson, good catch. I'll check with mars to see if he knows about it [19:35] mars, ^ [19:36] reading [19:38] salgado, could be YUI3, or lazr-js changes from the sprint. Difficult to isolate :( [19:39] mars, yeah, as I imagined. I'll see if it affects any other places where we use a multi-line widget and report a bug [19:39] salgado, mars, it is [19:39] salgado, first, try the lazr-js example [19:39] deryck made the widget fixed width or scalable [19:39] it is sort of the same [19:40] my guess is that Launchpad's implementation assume the old implementation of it [19:40] * deryck is on the phone right now, will look shortly [19:43] mars, both the fixed and fluid examples in lazr-js work fine [19:43] so it is an integration issue. good, now we know where the effort must be focused. [19:44] salgado, the widget still works, right? [19:44] on launchpad? [19:44] mars, yes [19:44] also good! so it isn't fallout from another subtle bug. It is a CSS-only fix. [19:50] * deryck looks at what salgado and beuno were saying about description widgets [19:51] morning [19:51] deryck, bug 487263 [19:51] Bug #487263: Save/Cancel buttons move to the middle of the line when editing the description of a bug [19:52] salgado, (and beuno, if interested), I would guess it's the one bit of local CSS on the bug page. The fonts made lining up hard initially, so had to hard code something for that top line. [19:53] I would guess this could be dropped now. [19:53] if it can be dropped, it'd be perfect [19:54] deryck, that would be my guess as well [19:54] gar, landing the bzr-svn code import worker failed again :( [19:55] * deryck pulls db-devel [20:00] ffs it passes locally :( [20:03] morning [20:03] mars: morning [20:03] mars: have you looked at editing a commit message on staging? [20:03] mars: the styles are all fubared [20:03] mars: haven't checked editing a bug description [20:03] mars: but I suspect it may be the same [20:04] thumper, salgado is looking into it [20:04] mars: awesome, ta [20:04] thumper, bug 487263 [20:05] Bug #487263: Save/Cancel buttons move to the middle of the line when editing the description of a bug [20:05] salgado: ta [20:05] morning thumper === bigjools-afk is now known as bigjools [20:06] salgado, I don't think it's the local rule after all. not sure what, though. and I was just about to step out for the day, until later tonight. === abentley-lunch is now known as abentley [20:07] deryck, since it affects editing commit messages as well, I suspect it's something else. I won't be around for long either, so maybe thumper can investigate it [20:07] salgado: do you have anything for me to go on? [20:08] salgado, deryck, I think it's the padding-right on .yui-ieditor [20:08] mars: what is the process for merging yui3 back into devel when we need to fix bits? [20:08] beuno: morning === matsubara is now known as matsubara-afk [20:08] beuno: how long are you around for? I'd like a chat [20:08] beuno: but I'm tied up for about the next hour and a bit [20:09] thumper, hey, I'm around for an hour or two [20:09] thumper, good question. flacoste, were we planning to land yui-3 fixes on db-devel, or should I keep an integration branch? [20:09] ok, got to be out for a bit. catch you all later. [20:09] thumper, nothing, really. I just stumbled upon it but didn't dig any further [20:09] salgado: ok === abentley1 is now known as abentley === salgado is now known as salgado-afk [21:00] who knows zope the most? [21:00] if we have IExtended inheriting from IBase [21:00] and register a utility using IExtended [21:00] and ask for the utility with IBase [21:00] will it get the IExtended object? [21:04] i don't think so [21:05] but try it, i guess [21:11] aargh [21:12] so the reason bzr-svn-imports tests pass locally but fail remotely is that i have python-xdg installed [21:12] preeettty ooobscure [21:25] mwhudson: what is python-xdg? [21:25] thumper: not really sure [21:25] but bzr-svn has a try: except: around it's import [21:26] and the reason ec2 land didn't work on my ec2 test branch was because i hadn't pushed a revision but just ran "ec2 land" and didn't look a the terminal again :( [21:26] mwhudson: I'd file a bug on bzr-svn :) [21:27] thumper: well, it's caused by an underlying bzr bug really [21:27] (which i'm fixing) [21:30] mwhudson: :( [21:30] thumper: python-xdg is a python module which makes using the xdg specs easier for a lot of things (XDG Base Directory spec for example) [21:31] Everyone should use it. [21:31] except for people on !linux [21:32] it doesn't really make a whole lot of sense on windows or osx [21:32] On !freedesktops, you mean. [21:32] no [21:33] i mean /usr/share/ doesn't exist on windows :) [21:33] But it does on other UNIXy systems. [21:33] xdg doesn't take into consideration filesystem layouts which aren't FHS really [21:35] well there are a couple of distros where i don't think it would work well either, that try to simulate the osx layout on top of linux or bsd, for example [21:35] but they also have like 2 users, so not really a worry :) [21:35] beuno: still around? [21:35] thumper, yes [21:36] beuno: skype? [21:37] thumper, sure [21:37] thumper, ready [21:42] wow, launchpad currently prevents non-ascii branch names by having about 7000 bugs in the area [21:42] (and an actual policy somewhere i'm sure) [21:42] lol [21:44]