[00:21]  * mwhudson lunches
[00:58]  * thumper lunches
[01:36]  * thumper frowns
[01:37] <thumper> Kontact has gone awol
[01:44] <mwhudson> haha
[01:44] <mwhudson> ec2 test launched an instance with the same ip as another i'd previously launchpad
[01:45] <mwhudson> so ssh complained about the key changing
[01:45] <thumper> heh
[01:46] <thumper> 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] <thumper> bugger
[03:46] <thumper> :(((
[03:46] <thumper> I have a bad feeling about this...
[03:48] <thumper> mwhudson: got a minute for a quick call?
[03:49] <mwhudson> thumper: sure
[04:19] <mwhudson> how did it get to be 17:20 ?
[05:04]  * mwhudson eods
[05:32]  * thumper EODs
[08:35] <adeuring> goodd morning
[09:26] <mrevell> Morning
[10:22] <jml> mrevell, hi
[10:24] <mrevell> hey there jml
[10:25] <jml> mrevell, the boiler in my house is on the blink
[10:25] <jml> yay
[10:25] <jml> I mean, umm, ahem.
[10:25] <jml> mrevell, how's things?
[10:27] <mrevell> 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] <mrevell> How was your first trans-Atlantic flight jml?
[10:28] <mrevell> s/ah/are
[10:28] <jml> safe :)
[10:28] <mrevell> man alive
[10:28] <mrevell> jml, heh, that's a fairly minimal commendation of a flight :)
[10:28] <jml> brb
[10:30] <jtv> hi al-maisan, care to help me out a little bit with orientation w.r.t. the buildd work?
[10:30] <al-maisan> jtv: of course! How cam I help?
[10:31] <al-maisan> *can
[10:31] <jtv> 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] <al-maisan> 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] <jtv> that "upload" happens in the LP db (librarian etc.)?
[10:35] <al-maisan> jtv: I was just looking at the code but, yes, I believe the librarian is used as a buffer
[10:35] <al-maisan> i.e. the files go to the librarian first
[10:36] <jtv> al-maisan: I won't bite if you get the details wrong :-)
[10:36] <noodles775> IBuilder.transferSlaveFileToLibrarian() ?
[10:36]  * al-maisan is relieved ;P
[10:36] <jtv> noodles775: That sounds probable.  :-)
[10:36] <wgrant> They don't normally go straight to the librarian.
[10:36] <jtv> who calls process-upload.py though?
[10:36] <al-maisan> jtv: cron?
[10:36] <jtv> I don't see any calls to it, and it's not in cronscripts
[10:36] <wgrant> buildd-manager grabs them from the slave, dumps them in a directory.
[10:36]  * jml back
[10:36] <wgrant> It calls process-upload.py (it's in the production configs, so grep won't find it)
[10:37] <al-maisan> ah, there you go
[10:37] <wgrant> process-upload.py looks in the directory, uploads stuff to the librarian, and fiddles with the DB.
[10:37] <jtv> very succinct :-)
[10:37] <jtv> answers pretty much everything.
[10:37] <al-maisan> wgrant: thank you for explaining the workflow.
[10:37] <jtv> and throws in a free use of "to fiddle with" as well
[10:38] <wgrant> I guess transferSlaveFileToLibrarian might be used for the build log.
[10:38] <wgrant> jtv: Sorry.
[10:38] <jtv> wgrant: no I wasn't being sarcastic!
[10:38] <wgrant> Oh.
[10:38] <jtv> 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] <jtv> There are build ids encoded in the directory names, right?
[10:40] <wgrant> Yes, but that's not important for anything.
[10:40] <wgrant> (And they're easily faked by malicious users on the buildds)
[10:41] <wgrant> The build ID is passed to process-upload.py directly.
[10:41] <jtv> 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] <wgrant> There's just a bug or two which means some untrusted values show up in logs and directory names.
[10:43] <jtv> can't check everything all the time I suppose
[10:43] <jtv> so something in a cron job figures out which builds are finished, and invokes process-upload.py on each in turn?
[10:44] <wgrant> No. buildd-manager is a daemon, and it polls every five seconds.
[10:44] <wgrant> It starts new builds as appropriate, and uploads complete ones.
[10:44] <jtv> oic
[10:45] <jtv> so how does a slave signal completion?  write a marker file somewhere?
[10:45] <noodles775> 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] <wgrant> jtv: The daemon running on the slave reports a status of WAITING.
[10:45] <jtv> oh, that's done in xmlrpc?
[10:45] <wgrant> jtv: Remember that buildd-manager polls the XML-RPC status() method every five seconds.
[10:45] <wgrant> Right.
[10:45] <wgrant> noodles775: Well, yes.
[10:46] <jtv> 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] <wgrant> The way buildd-manager handles uploads is going to change a lot soon.
[10:47] <wgrant> Because at the moment it is synchronous.
[10:47] <wgrant> Which really sucks.
[10:48] <noodles775> yep, there's a spec for that too (which I'm sure you know ;) ).
[10:49] <wgrant> 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] <jtv> I didn't want to get too far ahead of things...  still exploring the existing system :)
[10:49]  * noodles775 too :)
[10:52] <jtv> 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] <wgrant> 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] <jtv> ah, was it the one that used to have (by far) our longest-running test?
[10:54] <wgrant> I do not know.
[10:55] <wgrant> But it breaks a lot.
[10:55] <wgrant> And confuses users.
[10:55] <jtv> wgrant: never mind the details, you sold me at "FTP" :-)
[10:55] <wgrant> Heh.
[10:56] <deryck> Morning.
[10:56] <jtv> hi deryck!
[10:57] <jtv> wgrant: does a slave gets a source deb or a tarball in the filesystem or librarian as its "starting capital"?
[10:58] <jtv> 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] <jtv> The mention I mention was in the past days' mailing-list discussions
[10:59] <wgrant> jtv: It gets a number of SHA1s and filenames that it has to download from the librarian itself.
[10:59] <jtv> so I guess it gets specific access to the librarian and little else
[10:59] <wgrant> 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] <jtv> networking-wise, I mean
[10:59] <wgrant> Right.
[11:00] <wgrant> librarian, plus the PPA and primary archives.
[11:00] <wgrant> I imagine that will have to be adjusted, though.
[11:01] <jtv> probably less fragile than checking out the branch, rolling a tarball, and feeding it into the librarian :)
[11:01] <wgrant> Very probably.
[11:02] <jtv> and if we have no private branches to worry about, the auth can be the simplest one of all: anonymous-only
[11:02] <jtv> so a malicious package could subvert its build slave and get... publicly available source code
[11:02] <wgrant> Right.
[11:02] <wgrant> Which isn't good, but it can be done with the librarian already.
[11:06] <jtv> I think the list of packages installed on the slave also came up... any idea whether that list is explicit somewhere?
[11:07] <wgrant> A plain buildd-flavour debootstrap, with some added lamont magic.
[11:07] <wgrant> 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] <wgrant> How are dependencies going to be specified in your case?
[11:09] <jtv> 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] <jtv> oh
[11:10] <jtv> I do remember reading that the slave starts by doing an apt-get upgrade
[11:10] <wgrant> Right.
[11:10] <jtv> so presumably it can do an apt-get install just as easily
[11:11] <wgrant> It can do anything.
[11:12] <jtv> and that's done before any untrusted code runs, so probably not too hard to splice in
[11:12] <wgrant> Right.
[11:13] <jtv> 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] <wgrant> 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] <wgrant> The slave then starts up inside the VM.
[11:14] <wgrant> So everything happens inside the VM.
[11:15] <jtv> oh, and then the package build happens inside a chroot inside the vm?
[11:15] <wgrant> Exactly.
[11:16] <jtv> and the vms run on different archs for the various builds, right?  (something we won't have any interest in)
[11:16] <wgrant> Right.
[11:17] <jtv> oh, but there must be a provision for this already since there are any/all packages
[11:17] <wgrant> arch-indep ('all') packages are built on the i386 builders at the moment.
[11:17] <jtv> that's fine for us, and not having to care is fine as wll
[11:17] <jtv> *well
[11:18] <wgrant> The problem there is that it overloads the i386 builders.
[11:18] <wgrant> But no point worrying about that now.
[11:19] <jtv> right
[11:20] <jtv> 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] <wgrant> "all this stuff"?
[11:26] <jtv> (sorry, distractions elsewhere)
[11:26] <jtv> by "all this stuff" I meant the build dependencies and the "architecture"
[11:27] <wgrant> You probably care about build dependencies, since I preusme you're executing untrusted code.
[11:30] <jtv> 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] <jtv> 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] <jtv> (and dig up the info from elsewhere)
[11:31] <wgrant> Right, in most cases you won't have a debian/control to slurp build-dependencies from.
[11:31] <wgrant> But you are going to need to get them from somewhere.
[11:32] <jtv> will we need them for building the pot files in the most common intltool setup?
[11:33] <wgrant> I know very little about translations.
[11:33] <jtv> 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] <jtv> wgrant: g'night and thanks!
[11:51] <wgrant> np
[11:54] <jtv> henninge: you had a chance to look into the intltool stuff yet?
[11:54] <henninge> jtv: nope
[11:55] <jtv> 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] <jtv> (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] <henninge> jtv: I wouldn't think that source dependcies are needed
[11:58]  * jtv hopes not
[11:58] <jtv> but not ruling it out :)
[13:20] <jml> deryck, rockstar: either of you want to land https://code.edge.launchpad.net/~brian-murray/launchpad/bug-485229/+merge/15040 ?
[13:21] <deryck> jml, i will.
[13:21] <jml> deryck, thanks.
[13:21] <deryck> jml, ec2 had test failures so need to chase those and then will land.
[13:22] <jml> deryck, ahh ok.
[13:22] <jml> deryck, Brian asked me in person what the deal was with landing so I thought I'd chase it up.
[13:24] <deryck> jml, yeah, no worries.
[13:50]  * jml -> errands
[13:55] <sinzui> salgado: ping
[13:55] <salgado> hi sinzui
[13:55] <sinzui> salgado: do you own a mirror in production?
[13:55] <salgado> sinzui, yep
[13:56] <sinzui> staging is not updating so I cannot test that I fixed the change owner permissions
[13:56] <salgado> I'll test it on edge
[13:57] <sinzui> salgado: thanks
[13:58] <salgado> sinzui, it works!
[13:58] <sinzui> \o/
[14:27] <flacoste> morning folks
[14:48] <sinzui> EdwinGrubbs: bug 297833
[14:48] <mup> Bug #297833: Attempting to invite a private team fails with "Constraint not satisfied" <oem-services> <oops> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/297833>
[14:53] <jml> beuno, hello
[14:53] <jml> flacoste, hello
[14:53] <flacoste> hello jml!
[14:53] <flacoste> call in 5?
[14:54] <beuno> jml, hey
[14:54] <jml> flacoste, indeed
[14:55] <jml> beuno, guess what I just bought
[14:55] <flacoste> silent headphones!
[14:55] <beuno> jml, PALM PRE!
[14:55] <jml> beuno, \o/
[14:55] <mars> those work in Argentina?
[14:55] <beuno> jml, woooooooooooooo
[14:56] <beuno> jml, and?  I can't see your happy face through IRC very well
[14:56] <jml> beuno, well, I haven't actually got it to do anything yet
[14:59] <flacoste> yeah, staging was updated!
[15:00] <flacoste> everyone can clear their QA queue!
[15:04] <jtv> beuno, have you seen this sprite problem before? https://translations.edge.launchpad.net/ubuntu/karmic/+source/apturl/+pots/apturl/av/+translate
[15:06] <beuno> jtv, I haven;t
[15:06] <beuno> jtv, the sprite is applieed on the wrong element
[15:06] <beuno> (on the div, on the p)
[15:07] <beuno> or something like that
[15:09] <jtv> beuno: I don't see the sprite class on anything in the dom so far... do you see it?
[15:09] <sinzui> beuno: jtv: I still see developers doing that
[15:09] <sinzui> jtv: the sprite class just sets the padding, but you are using the sprite TYPE class
[15:09] <beuno> sinzui knows all about it
[15:10] <beuno> btw, sinzui, are you still doing UI reviews?
[15:10] <jtv> ah, this one says "error message" as classes for the div
[15:10] <beuno> I'd like to get us back to the graduation process  :)
[15:10] <sinzui> 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] <sinzui> beuno: I have. The only one of interest though I did with noodles775 for henninge.
[15:12] <beuno> sinzui, please continue adding me to the MPs and pinging me
[15:13] <jtv> 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] <sinzui> jtv: error is the big sign that is used in notifications
[15:14] <jtv> sinzui: that's the one I'm talking about, yes
[15:14] <jtv> I don't really see what this div does differently from other ones, apart from having more text
[15:15] <jtv> e.g. product-purchase-subscription.pt (arbitrary example) seems to do much the same thing
[15:16] <jtv> ahh, p vs div maybe
[15:17] <sinzui> jtv: p and div and both block elements
[15:17] <sinzui> jtv: we need to copy the notifications markup
[15:17] <jtv> sinzui: copy from where?
[15:18] <sinzui> notifcations are global lp/app/template/base-layout-macros.pt
[15:19] <sinzui> jtv: Consider that form errors and and information notifications display correctly, so that is the markup we want to copy
[15:22] <jtv> sinzui: thanks, I'll see what I can figure out from there
[15:24] <jtv> filing bug first
[15:24] <mars> deryck, around?
[15:25] <deryck> mars, hi
[15:25] <mars> hi deryck, would you have some time to review my one-line CSS change to fix bug #484848?
[15:25] <mup> Bug #484848: Subscriber icons in the subscribers portlet appear on a separate line from the subscribers' names <bug-page> <ui> <Launchpad Bugs:In Progress by mars> <https://launchpad.net/bugs/484848>
[15:26] <deryck> mars, sure
[15:26] <mars> done
[15:27] <sinzui> beuno: jtv: firebug shows each paragraph in that block is inheriting the div's .error .message classes. That is wrong
[15:27] <jtv> right, it's the surrounding div that currently has those classes
[15:28] <jtv> should I use view/notifications instead?
[15:28] <deryck> mars, Looks good.  r=me.
[15:29] <mars> deryck, ok.  beuno, ping, care to review my CSS hack?
[15:30] <beuno> mars, sure, just waiting for the diff to come up
[15:30] <mars> deryck, I think there is a better fix, by applying the correct styles to the surrounding <a> tag
[15:30] <mars> 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] <beuno> mars, just one question, why do we need to special-case subscribrers?
[15:31] <deryck> 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] <mars> beuno, the markup in the subscribers portlet is such that the sprite gets assigned a 90% width value
[15:32] <mars> beuno, an it also gets assigned the inline-block style.  Those push the sprite and the text onto different lines.
[15:32] <mars> 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.
[15:33] <beuno> mars, gotcha
[15:33] <beuno> mars, I'm +1, said so on the MP
[15:33] <sinzui> Chex: Do you know why staging has not updated in 2 days?
[15:34] <mars> 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] <mars> 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] <mars> sinzui, didn't flacoste say earlier that staging had finally updated?
[15:37] <sinzui> It was update friday. and was not updated 1.5 hours ago
[15:38] <mars> beuno, deryck, thanks for the reviews.
[15:38] <sinzui> mars: staging is definitely stale.
[15:39] <deryck> mars, np
[17:12] <mars> abentley, around?
[17:13] <abentley> mars: Hi.
[17:14] <mars> 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] <abentley> mars: I guess so.  What do you want me to test?
[17:15] <mars> abentley, well, anywhere that you came up with custom javascript, that windmill may not cover so well.
[17:15] <rockstar> mars, I'm unavailable this week.
[17:16] <rockstar> mars, why can't you just run the windmill tests?
[17:16] <mars> rockstar, ok, thanks for the heads up.
[17:16] <rockstar> 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] <mars> rockstar, if you feel that is sufficient, then OK.  I can't be sure what your windmill-to-feature coverage is like.
[17:17] <rockstar> mars, we've been pretty strict about making sure that at least the interaction is tested.
[17:18] <mars> rockstar, abentley, ok.
[17:37] <abentley> mars: Replying to a code review comment doesn't work because "Error: Y.one("label [for=field.vote]") is null"
[17:38] <mars> abentley, alright, first question then: did the windmill test catch it?
[17:38] <abentley> mars: No.
[17:38] <intellectronica> i don't think you can use dots in identifiers in selectors
[17:38] <mars> bin/test --layer=CodeWindmillLayer --test=???
[17:38] <mars> right
[17:39] <mars> that little issue :(
[17:40] <mars> abentley, ok, please file a bug, tag it yui-3-upgrade
[17:48] <BjornT> intellectronica, mars: you could use a dot in selectors in the previous yui version we used.
[17:48] <mars> BjornT, ah, but can you do so now?
[17:50] <BjornT> mars: iirc bug commenting selects by an id containg a dot
[17:52] <BjornT> mars: yes, Y.get('[id="field.comment"]'); works
[17:53] <mars> abentley, ^
[17:53] <mars> maybe it is the quoting?
[17:53] <abentley> mars: Isn't this a Y.one vs Y.get issue?
[17:56] <mars> abentley, they should be the same function.  Y.get() is deprectated.
[18:02] <jml> beuno-lunch, my palm hard locked during an update
[18:04] <BjornT> anyone seen this psycopg error before? http://paste.ubuntu.com/326281/
[18:04] <mars> 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] <abentley> mars: I did.
[18:05] <abentley> mars: And it works on edge.
[18:17] <BjornT> abentley-lunch: where are you seeing this failure? latest devel works for me
[18:17] <abentley-lunch> BjornT: On staging
[18:18] <BjornT> abentley-lunch: at what url? staging worked for me as well
[18:19] <BjornT> abentley-lunch: i tested it here: https://code.staging.launchpad.net/~bjornt/launchpad/form-overlay-render-by-default/+merge/10249
[18:33] <sinzui> 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] <EdwinGrubbs> 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] <sinzui> That page is the failover. testplans are bogus because they claim to test applications, but it is actually team members
[18:38] <sinzui> 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] <salgado> 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] <salgado> is that a known problem or should I report it?
[19:34] <jml> beuno, but now it's working again, thanks to the very cool people in #webos
[19:34] <mwhudson> jml: you have a pre?
[19:34] <beuno> jml, wooooo. What happened?
[19:34] <salgado> deryck, maybe you know (^)?
[19:35] <mwhudson> 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] <jml> beuno, I tried updating to webOS 1.3.1, it failed.
[19:35] <beuno> salgado, I suspect it's the newer version of that widget not playing nicely with the way it's implemented in LP
[19:35] <jml> beuno, I had to use their firmware fixer thingy, which of course doesn't work with 64 bit linux
[19:35] <salgado> mwhudson, good catch.  I'll check with mars to see if he knows about it
[19:35] <salgado> mars, ^
[19:36] <mars> reading
[19:38] <mars> salgado, could be YUI3, or lazr-js changes from the sprint.  Difficult to isolate :(
[19:39] <salgado> 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] <beuno> salgado, mars, it is
[19:39] <mars> salgado, first, try the lazr-js example
[19:39] <beuno> deryck made the widget fixed width or scalable
[19:39] <mars> it is sort of the same
[19:40] <beuno> 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] <salgado> mars, both the fixed and fluid examples in lazr-js work fine
[19:43] <mars> so it is an integration issue.  good, now we know where the effort must be focused.
[19:44] <mars> salgado, the widget still works, right?
[19:44] <mars> on launchpad?
[19:44] <salgado> mars, yes
[19:44] <mars> 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] <mwhudson> morning
[19:51] <salgado> deryck, bug 487263
[19:51] <mup> Bug #487263: Save/Cancel buttons move to the middle of the line when editing the description of a bug <Launchpad Bugs:New> <https://launchpad.net/bugs/487263>
[19:52] <deryck> 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] <deryck> I would guess this could be dropped now.
[19:53] <salgado> if it can be dropped, it'd be perfect
[19:54] <beuno> deryck, that would be my guess as well
[19:54] <mwhudson> gar, landing the bzr-svn code import worker failed again :(
[19:55]  * deryck pulls db-devel
[20:00] <mwhudson> ffs it passes locally :(
[20:03] <thumper> morning
[20:03] <thumper> mars: morning
[20:03] <thumper> mars: have you looked at editing a commit message on staging?
[20:03] <thumper> mars: the styles are all fubared
[20:03] <thumper> mars: haven't checked editing a bug description
[20:03] <thumper> mars: but I suspect it may be the same
[20:04] <mars> thumper, salgado is looking into it
[20:04] <thumper> mars: awesome, ta
[20:04] <salgado> thumper, bug 487263
[20:05] <mup> Bug #487263: Save/Cancel buttons move to the middle of the line when editing the description of a bug <bug-page> <js> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/487263>
[20:05] <thumper> salgado: ta
[20:05] <bigjools-afk> morning thumper
[20:06] <deryck> 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.
[20:07] <salgado> 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] <thumper> salgado: do you have anything for me to go on?
[20:08] <beuno> salgado, deryck, I think it's the padding-right on .yui-ieditor
[20:08] <thumper> mars: what is the process for merging yui3 back into devel when we need to fix bits?
[20:08] <thumper> beuno: morning
[20:08] <thumper> beuno: how long are you around for?  I'd like a chat
[20:08] <thumper> beuno: but I'm tied up for about the next hour and a bit
[20:09] <beuno> thumper, hey, I'm around for an hour or two
[20:09] <mars> thumper, good question.  flacoste, were we planning to land yui-3 fixes on db-devel, or should I keep an integration branch?
[20:09] <deryck> ok, got to be out for a bit.  catch you all later.
[20:09] <salgado> thumper, nothing, really.  I just stumbled upon it but didn't dig any further
[20:09] <thumper> salgado: ok
[21:00] <thumper> who knows zope the most?
[21:00] <thumper> if we have IExtended inheriting from IBase
[21:00] <thumper> and register a utility using IExtended
[21:00] <thumper> and ask for the utility with IBase
[21:00] <thumper> will it get the IExtended object?
[21:04] <mwhudson> i don't think so
[21:05] <mwhudson> but try it, i guess
[21:11] <mwhudson> aargh
[21:12] <mwhudson> so the reason bzr-svn-imports tests pass locally but fail remotely is that i have python-xdg installed
[21:12] <mwhudson> preeettty ooobscure
[21:25] <thumper> mwhudson: what is python-xdg?
[21:25] <mwhudson> thumper: not really sure
[21:25] <mwhudson> but bzr-svn has a try: except: around it's import
[21:26] <mwhudson> 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] <thumper> mwhudson: I'd file a bug on bzr-svn :)
[21:27] <mwhudson> thumper: well, it's caused by an underlying bzr bug really
[21:27] <mwhudson> (which i'm fixing)
[21:30] <thumper> mwhudson: :(
[21:30] <dobey> 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] <wgrant> Everyone should use it.
[21:31] <dobey> except for people on !linux
[21:32] <dobey> it doesn't really make a whole lot of sense on windows or osx
[21:32] <wgrant> On !freedesktops, you mean.
[21:32] <dobey> no
[21:33] <dobey> i mean /usr/share/ doesn't exist on windows :)
[21:33] <wgrant> But it does on other UNIXy systems.
[21:33] <dobey> xdg doesn't take into consideration filesystem layouts which aren't FHS really
[21:35] <dobey> 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] <dobey> but they also have like 2 users, so not really a worry :)
[21:35] <thumper> beuno: still around?
[21:35] <beuno> thumper, yes
[21:36] <thumper> beuno: skype?
[21:37] <beuno> thumper, sure
[21:37] <beuno> thumper, ready
[21:42] <mwhudson> wow, launchpad currently prevents non-ascii branch names by having about 7000 bugs in the area
[21:42] <mwhudson> (and an actual policy somewhere i'm sure)
[21:42] <mars> lol
[21:44] <dobey> mwhudson: yeah, i tried to name a branch ♥ once, but it wasn't happy
[21:58] <mwhudson> argh, one of these problems would be fixed in python 2.6 :)
[22:00] <dobey> heh
[22:00] <dobey> it will be nice in 10 years when we're all finally using python 3 :)
[22:02] <mwhudson> now bzr crashes on the client side \o/
[22:03] <mwhudson> oh maybe not
[22:03] <mwhudson> falling over in the smart server now i think
[22:07] <mwhudson> lawl
[22:07] <mwhudson> bzr: ERROR: Permission denied: "~mark/gnome-terminal/ddé/": : Invalid%20branch%20name%20%27dd%C3%A9%27.%20Branch%20names%20must%20start%20with%20a%20number%20or%20letter.%20%20The%20characters%20%2B%2C%20-%2C%20_%2C%20.%20and%20%40%20are%20also%20allowed%20after%20the%20first%20character.
[22:11] <wgrant> Nice.
[22:28]  * mwhudson is tempted to just give up
[22:28] <mwhudson> mwh@grond:unicod-branch-names-bug-449528$ bzr push  lp://dev/~mark/gnome-terminal/dé -d ~/tmp/german/
[22:28] <mwhudson> bzr: ERROR: Received bad protocol version marker: 'u"Invalid branch name \'d\\xe9'
[22:29] <mwhudson> oh
[22:29] <mwhudson> my stupid fault
[22:41] <mwhudson> i wonder if it would be practical to use a different xmlrpc lib for python
[22:50] <bigjools-afk> hey wgrant, still not got to your branch, sorry.  I will do it tomorrow, promise (I am still in Texas BTW)
[23:05] <wgrant> bigjools-afk: Ahh, I was wondering why you didn't appear last night.
[23:05]  * bigjools-afk wonders why I am -afk
[23:06] <wgrant> bigjools: So, yeah, I think jdong would hunt me down and shoot me if I asked for a dpkg backport.
[23:06] <bigjools> hmm :/
[23:06] <bigjools> I wonder if we can get someone in the distro team to do it
[23:06] <wgrant> Indeed.
[23:07] <bigjools> after all, it would unblock them, so you'd think they'd have a vested interest
[23:07] <wgrant> Yes.
[23:07] <bigjools> I wll poke someone tomorrow
[23:07] <wgrant> And it's a simple merge, so it wouldn't take much of their time.
[23:07] <wgrant> Thanks.
[23:07] <bigjools> nay wurries
[23:08] <wgrant> 3.0 penetration will exceed 1% later today. Debian is actually moving quickly for once.
[23:08] <bigjools> eek
[23:08] <bigjools> ok
[23:09] <lifeless> dpkg changed its default behaviour
[23:09] <wgrant> Er, when?
[23:09] <lifeless> at least, thats what I thought ;)
[23:09] <wgrant> I see no mail to d-d-a about that, and it wasn't the case a couple of days ago.
[23:10] <lifeless> wgrant: I must have gotten the wrong idea from an irc conversation
[23:10] <wgrant> They were going to do it.
[23:10] <wgrant> But then an #ubuntu-devel conversation suggested that it wasn't such a good idea.
[23:13] <wgrant> bigjools: I also fixed gina a couple of days ago, so I think all the Soyuz end of things is done.
[23:14] <wgrant> And exams are done tooooo.
[23:22] <bigjools> woo
[23:22] <bigjools> excellent, with any luck we'll get everything landed this week so we're ready for release next week
[23:23] <wgrant> Yep.
[23:23] <wgrant> As long as lamont is on the buildd side of things.
[23:25] <spm> wgrant: I believe he is; had a chat with him yesterday arvo; he seemed cool and froody with it all
[23:25] <wgrant> spm: Great.
[23:25] <wgrant> Although powerpc will be Fun.
[23:25] <bigjools> spm: froody?
[23:26] <spm> bigjools: you don't know your hitchhikers. for shame. :-) http://www.urbandictionary.com/define.php?term=froody
[23:26] <bigjools> indeed I never read/watched that
[23:26] <wgrant> O_O
[23:27] <bigjools> it's not my bag, baby
[23:27]  * wgrant prefers the original radio series.
[23:27] <spm> wgrant: I'll have a chat with the powers that be; see if we can get bigjools suspended until he's forcibly watched, read and listened to the lot
[23:28] <wgrant> spm: Excellent idea.
[23:29]  * spm is fond the radio series as well - but prefer the books. the pictures are better.
[23:29]  * bigjools goes to monster.com
[23:29] <spm> heh
[23:30]  * wgrant quickly adds "Hitchhiker's Guide expertise a must" to all the descriptions.
[23:30] <spm> my superb wife actually bought me the hardcover of the 6th book in the trilogy for my birthday. Not written by DA aiui, but a fan with assist.
[23:31] <wgrant> Well, yes, he's not awfully good at writing any more.
[23:31] <spm> no. :-(
[23:31] <thumper> anyone know where some inpage help that works is in LP?
[23:31] <wgrant> thumper: Check a PPA page.
[23:32] <wgrant> thumper: 'Help with installing'
[23:32] <wgrant> Although "works" isn't quite true.
[23:32] <wgrant> It has an AJAX spinner stuck in the middle for some reason that I cannot fathom.
[23:32] <mwhudson> bah, postgres doesn't have "median"
[23:33] <thumper> hew
[23:34] <bigjools> wgrant: yui3 borked it
[23:34] <bigjools> noodles is on the case
[23:34] <thumper> bigjools: yui3 isn't on devel
[23:34] <wgrant> bigjools: It has been like that for a few weeks now.
[23:34] <bigjools> oh this is edge?
[23:34] <thumper> bigjools: so that isn't it
[23:34] <bigjools> hmmm
[23:35] <wgrant> And prod, IIRC.
[23:35] <bigjools> hmm x2
[23:35] <wgrant> Yeah, prod as well.
[23:37] <bigjools> isn't that something to do with the missing styles as well?
[23:37] <wgrant> Possibly. Something isn't unsetting the background image.
[23:38] <wgrant> Which could conceivably be another style, I guess.
[23:38] <bigjools> it sounds like a corrupted icing dir location
[23:39]  * bigjools EODs
[23:39] <wgrant> Night.
[23:41] <bigjools> cheers, night all
[23:49] <mwhudson> spm: what's your R magic qqplot oneliner?
[23:50] <spm> mwhudson: something like: qqplot(c(seq(0,1, by=0.001)), y2, main="Page Responsiveness", xlab="Percentiles", ylab="Time in Microseconds", type="p",tck=-0.01,col="blue", lab=c(20,20,20), sub="2006 Week 27")
[23:50] <spm> where y2 is the data being analysed
[23:51] <spm> fiddle around with by=0.001 to get finer/coarser views
[23:51] <spm> the rest is mostly fluff
[23:51] <mwhudson> ta
[23:53] <spm> mwhudson: I find using quantile() helps show where the points of interest are, and thus can fiddle to that; eg quantile(y2, seq(0, 1, by=0.05))
[23:54] <wgrant> lifeless: Looks like we're safe from the default format changing for now; a GR to prevent it has even been threatened. Yay Debian.
[23:55] <mwhudson> spm: tanks
[23:55] <mwhudson> spm: 90% of successful code import runs complete in 90s
[23:55] <mwhudson> 50% in about 30
[23:56] <spm> sweet!
[23:56] <wgrant> And linux in two months.
[23:56] <mwhudson> well, most import runs are just updates
[23:56] <mwhudson> i guess i could filter in/out the initial runs
[23:57] <mwhudson> probably a fairly expensive bit of sql though