[00:14] * mwhudson lunches [00:25] i really hope bzr-hg support doesn't involve depending on any more packages [00:29] mwhudson: it will [00:29] mwhudson: mercurial [00:29] 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] jamesh_: g'day [00:52] 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] thumper, you got any storm devs for me? [00:59] jml: so, a new toy for you https://code.edge.launchpad.net/~lifeless/testtools/that/+merge/15070 [01:01] abentley: around ? === abentley1 is now known as abentley [01:28] maxb: fine, let's worry about that again when are targeting lucid? [01:29] the amount of steps involved in depending on a new package in launchpad is fricking insane [01:29] mwhudson: why? [01:29] [as in why is it insane?] [01:30] lifeless: mostly just quantity [01:30] and ec2 makes some of them really annoying [01:30] mwhudson: are any unneeded? can we discard some waste? [01:31] lifeless: having ec2 thingies that did apt-get update on start up would probably help some [01:31] update ++ upgrade [01:31] well obv yes [01:31] :P [01:32] partly here i'm shooting myself in the foot by trying to rush i guess === abentley1 is now known as abentley [01:40] let's see if ec2 update-image wants to work today [01:50] mwhudson, hi! I'm shopping around for a reviewer for therve's storm branch... are you available for that? [01:51] jtv: a storm branch!? [01:51] jtv: i can have a look [01:54] Fixes that memory leak that we found with the help of objgraph === jamesh_ is now known as jamesh [01:55] jtv: still looking for help? [01:56] 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] it's that memory leak where even handlers don't get cleaned up [01:56] jtv: i'll only have a look when you tell me where to look [01:57] 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] jtv: i think i would rather jamesh looked at that unless he's too busy [01:58] mwhudson: fair enough... jamesh, are you? [02:00] jtv: I'll have a look [02:00] jamesh: thanks! It's this one: https://code.edge.launchpad.net/~therve/storm/reference-changed-leak/+merge/14480 [02:00] although more reviews isn't a bad thing [02:00] (well, not when the reviewers aren't bikeshedders) [02:02] oh [02:03] ? [02:04] jtv: something completely different from what we're talking about :) [02:04] * jtv looks puzzled [02:05] jtv: i didn't mean to say it in here, basically [02:05] ah === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley [02:28] thumper, mwhudson: https://code.edge.launchpad.net/~jelmer/launchpad/hg-import-schema/+merge/15061 [02:28] stub: what about it? [02:28] Any reason we don't want a single URL column rather than three, at least two of which will always be NULL? [02:30] 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] stub: no, not really i guess [02:31] stub: perhaps we're at "third time - refactor" [02:31] 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] 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] stub: let's leave cvs along [02:37] alone [02:38] i don't think there is a url for a cvs module is there? [02:38] i would be pretty happy to be wrong about that [02:38] i guess we could invent one, but meeeh [02:39] mwhudson: config-manager invented one [02:39] mwhudson: parsing code is all there, import; reuse, done. [02:40] lifeless: i'm going to pretend you didn't say that until at least the end of my work day :) [02:40] but maybe worth considering at some point i guess [02:40] * lifeless shrugnods [02:41] stub: we couldn't hide it totally from existing code, there are some queries on those columns [02:42] but that's pretty minor [02:46] spm: is staging going to update during my lifetime? [02:49] 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] 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] It should be fixed. Last log I looked at (19) was using old code. [02:50] oki [02:50] (database/replication/Makefile should contain DOGFOOD_DBNAME near the top - not sure of the revno) [02:51] spm, stub: thanks for the update [02:52] If I live to see daylight I might be able to complete testing [02:52] sinzui: the lockfile was still in place from the last fail ; have removed; so hopefully!! the next run will proceed === abentley1 is now known as abentley [02:53] spm: You want to get it to kick off with yesterday's dump? [02:53] no real need - it'll kick itself off in ~ 20 mins. [02:55] no it wont.... [02:59] stub: um, can't really think of where they'd be the same [02:59] There are no conflicts in the production data [03:00] stub: sinzui: new restore kicked off with yesterdays dump; vs waiting another 3-4 hours for 'todays' dump [03:01] fab [03:01] I'll check it in a few mins - it has been failing quickly. [03:02] heh. oh yee of little faith. [03:02] * spm lunches === abentley1 is now known as abentley [04:03] abentley: so, another datapoint on rabbit [04:03] there was a great retrospective mail on the u1 dev list today, about deployment issues [04:03] 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] lifeless: could you forward it to canonical-launchpad maybe? [04:04] whereas pubsub is about broadcasting [04:04] mwhudson: sure [04:04] thanks [04:50] * mwhudson eods [04:52] mwhudson: I forwarded the mail [04:52] lifeless: i read it, thanks [04:54] mwhudson: I don't think you heard the discussion Aaron and I had on the bus though. [04:54] lifeless: this is ture [04:54] true [04:54] which was pubsubhubbub &| rabbitmq [04:55] being ware that rabbitmq eats memory like no tomorrow and needs moderately frequent restarts? [04:55] Ahh Tim mentions that. good. === ursula is now known as Ursinha [05:01] indeed [05:01] it was a very useful mail, I thought [05:05] very [05:35] stub: fyi. that staging restore seems to be proceeding nicely so far. 2.5 hours on? [05:36] looked fine when I checked [05:50] oh poo [05:50] having bzr-svn loaded breaks some of our other tests :( [05:51] because it calls external_url and doesn't catch InProcessTransport [05:57] theres a bug open I think :P [05:57] possibly fixed even [05:58] this is with bzr-svn trunk so i doubt the latter === abentley1 is now known as abentley [07:29] noodles775: hi [07:30] hi thumper [07:30] 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] Nice :) [07:50] thumper: rs? http://pastebin.ubuntu.com/323108/ [07:51] or henninge ^^ (diff for resolving stable->db-devel merge conflict) [07:53] noodles775_: looking [08:02] noodles775_: sorry, distracted. r=me [08:02] Thanks henninge === noodles775_ is now known as noodles775 === mup_ is now known as mup [08:29] good morning [09:21] How do I run just the page tests (stories) for my application (translations) ? [09:21] I know "-t lp.translations" runs all translations tests, but "-t lp.translations.stories" does not work. [09:27] I'm fixing that conflict [09:29] stub: I thought I'd already fixed it? [09:29] * noodles775 checks if there's another... [09:31] noodles775: Did it bounce? I don't see it in there. [09:31] My fix is with pqm now [09:31] stub: http://pastebin.ubuntu.com/323150/ [09:31] stub: ok. [09:32] noodles775: You tried to land it on launchpad/devel [09:33] Right. [09:33] Forgot the submit-branch :/ === matsubara-afk is now known as matsubara [13:45] hi sinzui [13:54] hi bac [13:55] sinzui: it looks to me like person-portlet-emails.pt is no longer used. do you know if that is the case? [13:55] i'd like to whack it [13:57] ha ha [13:57] The only thing that uses it is notfound-traversals.txt [13:57] bac +1 to remove it [13:57] yep [13:57] rt [13:58] bac:I think I recall allenap has some method to identify unused templates [13:58] sinzui: also, i have discovered

causes the sprite to be rendered twice and i don't know why [13:58] sinzui: Do I? [13:58] my current "fix" is to remove the class and put the image in once, unless you have a better idea [14:00] 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

elements, it is bad === henninge_ is now known as henninge [14:00] bac: We removed a lot of thos during UI 3. I fixed a similar problem on the CVE page this week [14:00] bac if you can put it on the object's , all will be well [14:01] ok. i'll try that. we do have specific li.mail rules in style.css [14:01] allenap: maybe I am fantasising. [14:01] 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] 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] morning launchpadders! [14:25] for some reason that term reminds me of "Liverpudlians"... [14:26] lol [14:26] gary_poster: did you notice that the new tags file contains all imports and not only definitions? [14:26] which makes it very inconvenient actually [14:27] flacoste: I did not. I expect that's a change to etags, not our tag machinery [14:27] Maybe we can find a flag to do what we want [14:27] ah, you are right, it might be related to the Karmic upgrade [14:27] since I don't think we upgraded the recipe recently [14:30] barry: bac: stand-up in two minutes [14:52] 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] flacoste: ack thanks [14:53] gary_poster: and can you arbitrate https://code.edge.launchpad.net/~jkakar/launchpadlib/testing-support/+merge/14444 at some point [14:53] flacoste: yup, will do [14:54] thanks [14:54] 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] nothing like config-manager to parse config-manager's syntax :-) === matsubara is now known as matsubara-lunch [14:56] flacoste: ack [15:08] lifeless, thanks. [15:21] just a warning for those who are around [15:21] I'm going to pqm submit a branch that ec2 has been losing [15:21] so the test suite might fail. sorry. [15:26] gmb, around? [15:51] deryck, around? [15:52] hi mars === ursula is now known as Ursinha [16:20] yay buildbot failure [16:20] * jml looks === matsubara-lunch is now known as matsubara [16:51] rockstar: ping [16:52] kfogel, hi. [16:53] kfogel, fair warning, I'm about to go to a UDS session. [16:53] rockstar: hey, have you seen the internal thread "Upgrading bzr branches"? [16:53] rockstar: oh, nm [16:53] rockstar: no problem, I'll send a mail to the public list with the questions [16:53] rockstar: to launchpad-dev@ that is [16:53] rockstar: have a good session [16:54] kfogel, can you CC me when you send the email? launchpad-dev@ is quite noisy. [16:54] rockstar: sure [16:54] kfogel, cheers. === matsubara_ is now known as matsubara [17:21] mwhudson, hi [17:26] jelmer, just so you aren't stuck waiting, he regularly signs on at 21:00UTC, four hours from now. [17:27] mars: ah, thanks === henninge is now known as henninge-afk [18:01] Chex: ping [18:02] sinzui: hello [18:02] Chex: I have a data fix for *production data*: https://pastebin.canonical.com/24936/ [18:03] 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/ === ursula is now known as Ursinha [18:04] 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] sinzui: ok,.. should I run that .py script as it is sitting on asuka? [18:11] did spm leave it there? There are the same [18:13] sinzui: yes he did, copying it over now [18:13] That is best since we know that was the one for staging [18:15] sinzui: https://pastebin.canonical.com/24939/ [18:15] Chex: rock. that looks good. [18:19] sinzui: no problem [19:04] bigjools: ? [19:11] jelmer: hello [19:38] bac: what bug are you working on? [19:46] sinzui: i've sent off 485237 to ec2 after review but haven't grabbed another yet [19:47] sinzui: i was thinking about bug 266890 since it bothers me! [19:47] Bug #266890: Changing default bug visibility of a project to private triggers database constraint [19:48] bac: I was think of doing bug 411686 myself [19:48] Bug #411686: can't merge to oblivion a private team [19:48] sinzui: ok [19:48] I did not want to start a bug you were already working on [19:48] sinzui: i'm about EOD here so i may poke at the above bug some this weekend [19:48] i'll claim it now [20:10] * mwhudson away for a bit === abentley1 is now known as abentley === sidnei_ is now known as sidnei [20:35] mwhudson, hi [20:35] mwhudson, still there? [20:42] jelmer: am back now === matsubara is now known as matsubara-afk === abentley1 is now known as abentley [22:48] jml: is the "[r=jml]" in your recent testfix just a slip of the brain? [23:06] mwhudson, slip of my ethics, actually [23:07] it seems thumper approved the merge proposal