[00:14]  * mwhudson lunches
[00:25] <mwhudson> i really hope bzr-hg support doesn't involve depending on any more packages
[00:29] <lifeless> mwhudson: it will
[00:29] <lifeless> mwhudson: mercurial
[00:29] <maxb> mwhudson: We depend on python2.X-support to ensure we have our modified version of python-support in place. Granted this happens to no longer be required in hardy...karmic, but we'll need that again in lucid
[00:51] <jtv> jamesh_: g'day
[00:52] <jtv> oh, probably early for him... mwhudson, you're further ahead on the daylight merry-go-round; maybe you're the one to talk to
[00:56] <jtv> thumper, you got any storm devs for me?
[00:59] <lifeless> jml: so, a new toy for you https://code.edge.launchpad.net/~lifeless/testtools/that/+merge/15070
[01:01] <lifeless> abentley: around ?
[01:28] <mwhudson> maxb: fine, let's worry about that again when are targeting lucid?
[01:29] <mwhudson> the amount of steps involved in depending on a new package in launchpad is fricking insane
[01:29] <lifeless> mwhudson: why?
[01:29] <lifeless> [as in why is it insane?]
[01:30] <mwhudson> lifeless: mostly just quantity
[01:30] <mwhudson> and ec2 makes some of them really annoying
[01:30] <lifeless> mwhudson: are any unneeded? can we discard some waste?
[01:31] <mwhudson> lifeless: having ec2 thingies that did apt-get update on start up would probably help some
[01:31] <lifeless> update ++ upgrade
[01:31] <mwhudson> well obv yes
[01:31] <lifeless> :P
[01:32] <mwhudson> partly here i'm shooting myself in the foot by trying to rush i guess
[01:40] <mwhudson> let's see if ec2 update-image wants to work today
[01:50] <jtv> mwhudson, hi!  I'm shopping around for a reviewer for therve's storm branch... are you available for that?
[01:51] <mwhudson> jtv: a storm branch!?
[01:51] <mwhudson> jtv: i can have a look
[01:54] <jtv> Fixes that memory leak that we found with the help of objgraph
[01:55] <jamesh> jtv: still looking for help?
[01:56] <jtv> jamesh: good morning!  mwhudson is having a look, though a Storm branch review is probably not a fair thing for me to ask him for :)
[01:56] <jtv> it's that memory leak where even handlers don't get cleaned up
[01:56] <mwhudson> jtv: i'll only have a look when you tell me where to look
[01:57] <jtv> mwhudson: ah so that did get caught in my connection outage... sorry, it's this one: https://code.edge.launchpad.net/~therve/storm/reference-changed-leak/+merge/14480
[01:58] <mwhudson> jtv: i think i would rather jamesh looked at that unless he's too busy
[01:58] <jtv> mwhudson: fair enough... jamesh, are you?
[02:00] <jamesh> jtv: I'll have a look
[02:00] <jtv> jamesh: thanks!  It's this one: https://code.edge.launchpad.net/~therve/storm/reference-changed-leak/+merge/14480
[02:00] <jamesh> although more reviews isn't a bad thing
[02:00] <jtv> (well, not when the reviewers aren't bikeshedders)
[02:02] <mwhudson> oh
[02:03] <jtv> ?
[02:04] <mwhudson> jtv: something completely different from what we're talking about :)
[02:04]  * jtv looks puzzled
[02:05] <mwhudson> jtv: i didn't mean to say it in here, basically
[02:05] <jtv> ah
[02:28] <stub> thumper, mwhudson: https://code.edge.launchpad.net/~jelmer/launchpad/hg-import-schema/+merge/15061
[02:28] <mwhudson> stub: what about it?
[02:28] <stub> Any reason we don't want a single URL column rather than three, at least two of which will always be NULL?
[02:30] <stub> If we collapsed them into a single URL column, we could even hide that from existing code using properties in the DB class.
[02:30] <mwhudson> stub: no, not really i guess
[02:31] <thumper> stub: perhaps we're at "third time - refactor"
[02:31] <stub> I think so. I don't recall a justification when we added git_url either - maybe there was one, or maybe I was out of coffee.
[02:32] <stub> Could the cvs columns be left alone for now? There might be code that likes things split into two rather than having to parse the information from a URI.
[02:37] <mwhudson> stub: let's leave cvs along
[02:37] <mwhudson> alone
[02:38] <mwhudson> i don't think there is a url for a cvs module is there?
[02:38] <mwhudson> i would be pretty happy to be wrong about that
[02:38] <mwhudson> i guess we could invent one, but meeeh
[02:39] <lifeless> mwhudson: config-manager invented one
[02:39] <lifeless> mwhudson: parsing code is all there, import; reuse, done.
[02:40] <mwhudson> lifeless: i'm going to pretend you didn't say that until at least the end of my work day :)
[02:40] <mwhudson> but maybe worth considering at some point i guess
[02:40]  * lifeless shrugnods
[02:41] <mwhudson> stub: we couldn't hide it totally from existing code, there are some queries on those columns
[02:42] <mwhudson> but that's pretty minor
[02:46] <sinzui> spm: is staging going to update during my lifetime?
[02:49] <stub> mwhudson, thumper: One weird edge case. At the moment, it is possible to have in the a git_url identical to a svn_url. Is there some use case for this, or is it a win enforcing uniqueness over all of them?
[02:49] <spm> sinzui: I'm assuming that wasn't a challenge?? :-) at this stage the postgres restore is busticated. I understand stubs aware of and working on it.
[02:49] <stub> It should be fixed. Last log I looked at (19) was using old code.
[02:50] <spm> oki
[02:50] <stub> (database/replication/Makefile should contain DOGFOOD_DBNAME near the top - not sure of the revno)
[02:51] <sinzui> spm, stub: thanks for the update
[02:52] <sinzui> If I live to see daylight I might be able to complete testing
[02:52] <spm> sinzui: the lockfile was still in place from the last fail ; have removed; so hopefully!! the next run will proceed
[02:53] <stub> spm: You want to get it to kick off with yesterday's dump?
[02:53] <spm> no real need - it'll kick itself off in ~ 20 mins.
[02:55] <spm> no it wont....
[02:59] <mwhudson> stub: um, can't really think of where they'd be the same
[02:59] <stub> There are no conflicts in the production data
[03:00] <spm> stub: sinzui: new restore kicked off with yesterdays dump; vs waiting another 3-4 hours for 'todays' dump
[03:01] <sinzui> fab
[03:01] <stub> I'll check it in a few mins - it has been failing quickly.
[03:02] <spm> heh. oh yee of little faith.
[03:02]  * spm lunches
[04:03] <lifeless> abentley: so, another datapoint on rabbit
[04:03] <lifeless> there was a great retrospective mail on the u1 dev list today, about deployment issues
[04:03] <lifeless> one in particular that stood out was that the server backs up if clients don't ack getting messages - mq is all about guaranteed delivery
[04:03] <mwhudson> lifeless: could you forward it to canonical-launchpad maybe?
[04:04] <lifeless> whereas pubsub is about broadcasting
[04:04] <lifeless> mwhudson: sure
[04:04] <mwhudson> thanks
[04:50]  * mwhudson eods
[04:52] <lifeless> mwhudson: I forwarded the mail
[04:52] <mwhudson> lifeless: i read it, thanks
[04:54] <lifeless> mwhudson: I don't think you heard the discussion Aaron and I had on the bus though.
[04:54] <mwhudson> lifeless: this is ture
[04:54] <mwhudson> true
[04:54] <lifeless> which was pubsubhubbub &| rabbitmq
[04:55] <spm> being ware that rabbitmq eats memory like no tomorrow and needs moderately frequent restarts?
[04:55] <spm> Ahh Tim mentions that. good.
[05:01] <lifeless> indeed
[05:01] <lifeless> it was a very useful mail, I thought
[05:05] <spm> very
[05:35] <spm> stub: fyi. that staging restore seems to be proceeding nicely so far. 2.5 hours on?
[05:36] <stub> looked fine when I checked
[05:50] <mwhudson> oh poo
[05:50] <mwhudson> having bzr-svn loaded breaks some of our other tests :(
[05:51] <mwhudson> because it calls external_url and doesn't catch InProcessTransport
[05:57] <lifeless> theres a bug open I think :P
[05:57] <lifeless> possibly fixed even
[05:58] <mwhudson> this is with bzr-svn trunk so i doubt the latter
[07:29] <thumper> noodles775: hi
[07:30] <noodles775> hi thumper
[07:30] <thumper> noodles775: I'm pleased there is someone at the start of their day to look at the merge conflict for devel -> db-devel :)
[07:30] <noodles775> Nice :)
[07:50] <noodles775_> thumper: rs? http://pastebin.ubuntu.com/323108/
[07:51] <noodles775_> or henninge ^^ (diff for resolving stable->db-devel merge conflict)
[07:53] <henninge> noodles775_: looking
[08:02] <henninge> noodles775_: sorry, distracted. r=me
[08:02] <noodles775_> Thanks henninge
[08:29] <adeuring> good morning
[09:21] <henninge> How do I run just the page tests (stories) for my application (translations) ?
[09:21] <henninge> I know "-t lp.translations" runs all translations tests, but "-t lp.translations.stories" does not work.
[09:27] <stub> I'm fixing that conflict
[09:29] <noodles775> stub: I thought I'd already fixed it?
[09:29]  * noodles775 checks if there's another...
[09:31] <stub> noodles775: Did it bounce? I don't see it in there.
[09:31] <stub> My fix is with pqm now
[09:31] <noodles775> stub: http://pastebin.ubuntu.com/323150/
[09:31] <noodles775> stub: ok.
[09:32] <stub> noodles775: You tried to land it on launchpad/devel
[09:33] <noodles775> Right.
[09:33] <noodles775> Forgot the submit-branch :/
[13:45] <bac> hi sinzui
[13:54] <sinzui> hi bac
[13:55] <bac> sinzui: it looks to me like person-portlet-emails.pt is no longer used.  do you know if that is the case?
[13:55] <bac> i'd like to whack it
[13:57] <sinzui> ha ha
[13:57] <sinzui> The only thing that uses it is notfound-traversals.txt
[13:57] <sinzui> bac +1 to remove it
[13:57] <bac> yep
[13:57] <bac> rt
[13:58] <sinzui> bac:I think I recall allenap has some method to identify unused templates
[13:58] <bac> sinzui: also, i have discovered <li class="mail"> causes the sprite to be rendered twice and i don't know why
[13:58] <allenap> sinzui: Do I?
[13:58] <bac> my current "fix" is to remove the class and put the image in once, unless you have a better idea
[14:00] <sinzui> bac: It can the the icon is designed for a specific line height. It can never be used on an element that is not a line. Since there is margine and padding on <li> elements, it is bad
[14:00] <sinzui> bac: We removed a lot of thos during UI 3. I fixed a similar problem on the CVE page this week
[14:00] <sinzui> bac if you can put it on the object's <a>, all will be well
[14:01] <bac> ok.  i'll try that.  we do have specific li.mail rules in style.css
[14:01] <sinzui> allenap: maybe I am fantasising.
[14:01] <allenap> sinzui: I vaguely remember thinking about that problem. I might have written code for it, but I don't know where it is now. I would just use grep now.
[14:02] <sinzui> bac: allenap: I think every lifecycle portlet should be removed. If something is using one, it should not.
[14:03]  * sinzui has investigated how to remove all the dead 1.0/2.0 portlets
[14:15] <flacoste> morning launchpadders!
[14:25] <gary_poster> for some reason that term reminds me of "Liverpudlians"...
[14:26] <flacoste> lol
[14:26] <flacoste> gary_poster: did you notice that the new tags file contains all imports and not only definitions?
[14:26] <flacoste> which makes it very inconvenient actually
[14:27] <gary_poster> flacoste: I did not.  I expect that's a change to etags, not our tag machinery
[14:27] <gary_poster> Maybe we can find a flag to do what we want
[14:27] <flacoste> ah, you are right, it might be related to the Karmic upgrade
[14:27] <flacoste> since I don't think we upgraded the recipe recently
[14:30] <sinzui> barry: bac: stand-up in two minutes
[14:52] <flacoste> gary_poster: there is an outside contributions to launchpadlib at https://code.launchpad.net/~kees/launchpadlib/safe-cred-dir/+merge/15011 waiting for a review
[14:52] <gary_poster> flacoste: ack thanks
[14:53] <flacoste> gary_poster: and can you arbitrate https://code.edge.launchpad.net/~jkakar/launchpadlib/testing-support/+merge/14444 at some point
[14:53] <gary_poster> flacoste: yup, will do
[14:54] <flacoste> thanks
[14:54] <flacoste> gary_poster: and regarding the sourcecodedeps.conf parsing, you might want considering simply adding config-manager to the list of deps and using the parsing code from there
[14:55] <flacoste> nothing like config-manager to parse config-manager's syntax :-)
[14:56] <gary_poster> flacoste: ack
[15:08] <jml> lifeless, thanks.
[15:21] <jml> just a warning for those who are around
[15:21] <jml> I'm going to pqm submit a branch that ec2 has been losing
[15:21] <jml> so the test suite might fail. sorry.
[15:26] <mars> gmb, around?
[15:51] <mars> deryck, around?
[15:52] <deryck> hi mars
[16:20] <jml> yay buildbot failure
[16:20]  * jml looks
[16:51] <kfogel> rockstar: ping
[16:52] <rockstar> kfogel, hi.
[16:53] <rockstar> kfogel, fair warning, I'm about to go to a UDS session.
[16:53] <kfogel> rockstar: hey, have you seen the internal thread "Upgrading bzr branches"?
[16:53] <kfogel> rockstar: oh, nm
[16:53] <kfogel> rockstar: no problem, I'll send a mail to the public list with the questions
[16:53] <kfogel> rockstar: to launchpad-dev@ that is
[16:53] <kfogel> rockstar: have a good session
[16:54] <rockstar> kfogel, can you CC me when you send the email?  launchpad-dev@ is quite noisy.
[16:54] <kfogel> rockstar: sure
[16:54] <rockstar> kfogel, cheers.
[17:21] <jelmer> mwhudson, hi
[17:26] <mars> jelmer, just so you aren't stuck waiting, he regularly signs on at 21:00UTC, four hours from now.
[17:27] <jelmer> mars: ah, thanks
[18:01] <sinzui> Chex: ping
[18:02] <Chex> sinzui: hello
[18:02] <sinzui> Chex: I have a data fix for *production data*: https://pastebin.canonical.com/24936/
[18:03] <sinzui> Chex: We ran the script on staging two days ago, and we see no reason to not run it in production now: https://pastebin.canonical.com/24861/
[18:04] <sinzui> Chex: ^ The numbers will not match since we know users has had two days to add ad remove links, but they should be similar
[18:11] <Chex> sinzui: ok,.. should I run that .py script as it is sitting on asuka?
[18:11] <sinzui> did spm leave it there? There are the same
[18:13] <Chex> sinzui: yes he did, copying it over now
[18:13] <sinzui> That is best since we know that was the one for staging
[18:15] <Chex> sinzui: https://pastebin.canonical.com/24939/
[18:15] <sinzui> Chex: rock. that looks good.
[18:19] <Chex> sinzui: no problem
[19:04] <lifeless> bigjools: ?
[19:11] <mwhudson> jelmer: hello
[19:38] <sinzui> bac: what bug are you working on?
[19:46] <bac> sinzui: i've sent off 485237 to ec2 after review but haven't grabbed another yet
[19:47] <bac> sinzui: i was thinking about bug 266890 since it bothers me!
[19:47] <mup> Bug #266890: Changing default bug visibility of a project to private triggers database constraint <oops> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/266890>
[19:48] <sinzui> bac: I was think of doing bug 411686 myself
[19:48] <mup> Bug #411686: can't merge to oblivion a private team <oops> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/411686>
[19:48] <bac> sinzui: ok
[19:48] <sinzui> I did not want to start a bug you were already working on
[19:48] <bac> sinzui: i'm about EOD here so i may poke at the above bug some this weekend
[19:48] <bac> i'll claim it now
[20:10]  * mwhudson away for a bit
[20:35] <jelmer> mwhudson, hi
[20:35] <jelmer> mwhudson, still there?
[20:42] <mwhudson> jelmer: am back now
[22:48] <mwhudson> jml: is the "[r=jml]" in your recent testfix just a slip of the brain?
[23:06] <jml> mwhudson, slip of my ethics, actually
[23:07] <mwhudson> it seems thumper approved the merge proposal