=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [12:35] ugh, out of the frying pan and into the fire. I setup my piped while statement in ()'s and now it won't call the 2 functions contained within on one system, the other works fine. [12:41] dude, bash functions are crack [12:41] good morning [12:41] kiko: at 3 am wtf is wrong is hardly going to be me [12:43] and I'll bet it was stub. [12:44] hey lifeless [12:44] that may be [12:44] it is still derailed [12:44] I just enabled it 30 seconds ago [12:45] you are making tears come out of my eyes [12:46] thats cause I just got up 35 seconds ago === lifeless goes for breakfast === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [01:18] Merge to devel/launchpad/: [r=mark] Use sortkey instead of the dbschema value in sortkey columns for specs (r3386: kiko) [01:19] yes! === Burgwork [n=corey@ubuntu/member/burgundavia] has joined #launchpad [01:34] grumble at the bug email change [01:48] Merge to devel/launchpad/: [trivial] Add 1.0.1 revision of Code of Conduct from Colin Watson. (r3387: James Troup) === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [02:23] Merge to devel/launchpad/: [r=stub] make send-bug-notifications.py connect as a specific db user. (r3388: Bjorn Tillenius) [02:52] Merge to devel/launchpad/: [trivial] Remove some mirror{content,sourcecontent} files that weren't used nor tested. (r3389: Guilherme Salgado) === stub [n=stub@ppp-58.8.3.153.revip2.asianet.co.th] has joined #launchpad [03:13] go jamesh! [03:30] Gooooooooooooooooooooooooooooood afternoon Launchpadders! [03:30] hi mpt [03:34] Merge to devel/launchpad/: [r=bradb] add a bug listing/search for projects (r3390: James Henstridge) === mpt [n=mpt@219-89-136-79.jetstart.xtra.co.nz] has joined #launchpad [03:53] spiv, ping [03:54] mpt: pong [03:55] spiv, I'm about to upgrade to Dapper -- will I have to do anything to my LP development setup? [03:55] mpt: Heh, me too ;) [03:55] AFAIK, no. You're already using postgres 8.1? [03:55] yes [03:56] (tests wouldn't pass if I wasn't) [03:56] Then it should be fine, I think. [03:57] okie dokie [03:57] I'm just going outside into archive.ubuntu.com, I may be some time - [03:59] :) [03:59] mpt: the postgres/dapper upgrade problem I reported earlier has been fixed [04:07] kiko-zzz: please do your reviews [04:07] spiv: you have two reviews queued [04:08] jamesh: theres one in your queue too that is getting old [04:09] lifeless: yeah. I'll do it today [04:09] thanks [04:09] I want us to keep the latency down on reviews, it will keep the queue small and managable. [04:09] to that end I'm adopting kikos nag-had. [04:09] s/had/hat/ === asw [n=asw@karuna.med.harvard.edu] has joined #launchpad === mpt [n=mpt@219-89-145-125.jetstart.xtra.co.nz] has joined #launchpad [06:02] spiv, how's it going? [06:03] mpt: Good, after wrestling with a broken mirror... [06:04] So, I appear to have two problems so far [06:04] (1) everything crashes on launch [06:05] (2) "E: /var/cache/apt/archives/pybaz_1.5pre1-1_all.deb: trying to overwrite `/usr/lib/python2.4/site-packages/pybaz/__init__.py', which is also in package python2.4-bazaar [06:05] " [06:05] I'd say that python2.4-bazaar and pybaz aren't supposed to co-exist. Hmm. [06:06] which to keep? [06:07] (Wow, Opera launches, though Firefox and Epiphany both flame out) [06:07] python2.4-bazaar is probably the right now [06:07] launchpad-dependencies has a suggests for python2.4-bazaar [06:07] And says nothing about pybaz. [06:08] hmm [06:08] pybaz is the one in dapper/universe though [06:08] So I should install launchpad-dependencies? [06:10] I don't actually see a python2.4-bazaar package in dapper anywhere. Regardless, for launchpad we have pybaz in rocketfuel, so you don't need a system version. [06:11] ok [06:11] The only time you'd need pybaz on your system would be to run baz2bzr conversions, I think. [06:12] spiv: python2.4-bazaar is the one we want for baz2bzr [06:12] spiv: python2.4-bazaar is the name used in Keybuk's repo. The copy in dapper is called pybaz and appears to have come from debian [06:12] oh right, I forgot about that little confusion. [06:13] so launchpad-dependencies suggests a package that doesn't exist in the dapper repos === mpt [n=mpt@219-89-145-125.jetstart.xtra.co.nz] has joined #launchpad === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === mpt [n=mpt@219-89-145-125.jetstart.xtra.co.nz] has joined #launchpad [07:23] Well, that all seems to work pretty well [07:23] apart from the icons and scrollbars === _stgraber [i=steph@xeon.stargate-server.com] has joined #launchpad === G0SUB [n=ghoseb@ubuntu/member/g0sub] has joined #launchpad === mpt [n=mpt@219-89-145-125.jetstart.xtra.co.nz] has joined #launchpad === BjornT [n=bjorn@213.226.190.253] has joined #launchpad === carlos [n=carlos@56.Red-88-4-2.staticIP.rima-tde.net] has joined #launchpad [08:43] morning [08:46] hi carlos [08:47] BjornT, ping [08:47] hi mpt [08:47] BjornT, you're awake! great [08:49] BjornT, I had a bug ordering failure with bugtask-search-pages.txt, and bradb proposed fixing it by adding "sorted[...] " to line 30 [08:50] That seems odd to me -- I think maybe the underlying code should be sorting the bugs, rather than the test [08:50] What do you think? [08:50] (this is after merging severity and priority) [08:50] jamesh, available? [08:50] mpt: yeah [08:51] jamesh, bugzilla-import.txt line 368 or thereabouts, the Evolution task for bug 5 has severity MEDIUM. Why is this, since the imported bug was a 'blocker'? [08:51] Malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] http://launchpad.net/bugs/5 [08:51] no, Ubugtu, not *that* bug [08:52] mpt: yeah, i agree, the underlying code should produce a stable ordering. i even made it so once, but it seems to have regressed. [08:53] mpt: because the import doesn't set the status or severity on the upstream task it creates [08:53] mpt: just the "evolution (Ubuntu)" task [08:53] BjornT: obviously you did not write a test ;) [08:53] BjornT, should I leave it as an XXX then? [08:53] BjornT: therefor it is undefined. [08:53] lifeless, there is a test, and it's failing in my branch :-P [08:53] mpt: the bug status synching code would eventually assign the correct status [08:53] but I don't know why [08:53] jamesh, should it be UNKNOWN instead then? [08:53] lifeless: or someone changed the test as well ;) [08:53] mpt: well, are you getting a page test failure or a system test failure ? [08:54] BjornT: true enough :) [08:54] lifeless, both [08:54] mpt: i'll have a quick look, there might be a one-line fix for it. [08:54] mpt: it would be if official_malone was set to False for evolution in the sample data [08:55] mpt: the default for tasks on official_malone=True products is unconfirmed/normal [08:55] ah [08:55] jamesh, so we're adding a watch despite Evolution using Malone officially in sampledata [08:55] That's a bugzilla-import-ism, I guess [08:56] mpt: the Product.official_malone stuff didn't exist back when I wrote those tests [08:56] mpt: perhaps changing the test to use a gnome-terminal bug would do? [08:56] mpt: hmm, the ordering should be stable. what do you order by now? (instead of priority,severity) [08:57] BjornT, -importance [08:57] which is severity renamed, with a couple of value changes [08:57] mpt: and if you look at the importance of each bugtask, does the ordering make sense? [08:59] spiv: pinf [08:59] lifeless: pong [09:00] spiv: I'm here to confirm you heard my nag on reviews [09:00] BjornT, on /people/name16/+reportedbugs for example, the bugs are indeed sorted by descending importance, but within each importance the ordering appears random [09:00] lifeless: I heard :) [09:00] 3, 1, 9, 10, 2 [09:00] spiv: ok, 'nuff said. [09:00] lifeless: I'm half-way through one right now. [09:00] I just hadn't heard, so assumed dropped packets. === mdke_ is now known as mdke [09:02] mpt: what you should look at is the value of bugtask.id, since that is what provides the stable ordering. if you want to order by bug id as well, you have to specify that explicitly. [09:03] hmmm [09:03] ok [09:03] It would be nice if I didn't have to ;-) but ok [09:03] i.e. "no matter what, if everything else I'm sorting by turns out the same, resort to chronological" [09:04] mpt: it is chronological, but with respect to the creation of the bugtask. [09:04] ohhhhhh [09:05] mpt: we could look at the bug as well, but would that be in chronological or reversed chronological order? sometimes you want the former, sometimes the latter. [09:05] sure [09:06] but whichever you want, you don't want 3 1 9 10 2 :-) [09:08] mpt: i guess you could insert the following in BugTaskSet.search(), right before orderby_arg.append('BugTask.id') === ajmitch [n=ajmitch@port169-135.ubs.maxnet.net.nz] has joined #launchpad === G0SUB [n=ghoseb@ubuntu/member/g0sub] has joined #launchpad [09:09] if 'Bug.id' not in orderby_arg and '-Bug.id' not in orderby_arg: [09:09] orderby_arg.append('Bug.id') [09:09] or something like that [09:10] that will probably break a few tests though :) [09:12] jamesh: care to do a small hack to pending reviews for me ? [09:12] jamesh: I'd like two extra columns. Reviewer, and days-old [09:13] BjornT, why not just change the "Make sure that the result always is ordered" line? [09:13] from BugTask.id to Bug.id [09:14] mpt: because the results might include more than one bugtask for each bug, so you have to resort to bugtask.id in order to ensure a stable ordering. [09:14] BjornT, I thought it was a bug whenever that happened anyway [09:14] i.e. returning the same bug twice in any search [09:16] mpt: i wouldn't say it's a bug, but we should present it better in the UI, than simply two rows. [09:16] hmm, fair enough [09:17] we might group them together somehow [09:23] BjornT, that code fixes the pagetest, thanks [09:23] but not the doctest, curiously [09:23] hi [09:25] https://staging.ubuntu.com/projects/launchpad/+bugs <- yay [09:25] jamesh, excellent [09:26] jamesh: what do you think ? [09:26] mbp_: welcome to The Channel [09:26] lifeless: doing the age should be trivial. Adding a reviewer column is a little more effort [09:26] jamesh, if you used product displayname instead of "name", that Product column would get a lot narrower [09:27] jamesh: could we reformat the pending reviews page to make that easier? I'm happy to do so [09:27] but I'd -really- like it if reviewers could go to your page not the wiki page to see what of theirs is pending and old. [09:27] lifeless: the age is trivial because I'm already reading the dates [09:28] lifeless: I just need to add a little more to parse the page headings [09:28] jamesh: yes [09:28] jamesh: if when you write that parser, having the headers different for the reviewers would help, let me know, or just DoIt. [09:29] mpt: are you sure? https://staging.ubuntu.com/products/launchpad-upload-and-queue/ <- name="launchpad-upload-and-queue" while displayname="Launchpad Upload and Queue system" [09:29] jamesh, yes, because the latter will wrap while the former doesn't [09:29] shrug [09:30] mpt: I used Product.name because that's what is used on the bug pages [09:31] mpt: if you want to experiment, the file to edit is lib/canonical/launchpad/templates/batchnavigator-table-view.pt [09:31] hmm, you have a point there === doko_ [n=doko@dslb-088-073-067-221.pools.arcor-ip.net] has joined #launchpad === G0SUB [n=ghoseb@ubuntu/member/g0sub] has joined #launchpad === mpt [n=mpt@219-89-145-125.jetstart.xtra.co.nz] has joined #launchpad [10:24] BjornT, could I bother you for another five minutes? [10:25] sure [10:25] BjornT, https://chinstrap.ubuntu.com/~dsilvers/paste/file5j0KoI.html [10:26] Either my two tests have the same silly mistake in it, such that they're picking up the output of the previous test [10:26] or I don't know Python [10:26] probably both [10:32] I think it's the tests, because it keeps claiming I sent something that I actually sent 3~4 tests previously [10:32] (emailinterface.txt line 738) [10:35] are they in separate .txt files ? [10:36] no, all in emailinterface.txt [10:37] but then there are already half a dozen tests of the same type in that file [10:37] so that shouldn't matter === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad [10:39] mpt: yeah it's strange. i'm not sure what the problem is. what happens if you insert '>>> stub.test_emails = [] ' right before your tests? [10:42] mpt: ah. how did you change PriorityEmailCommand? === frodon_ido [n=patrick@ip-213-49-233-214.dsl.scarlet.be] has joined #launchpad === mpt_ [n=mpt@219-89-157-131.jetstart.xtra.co.nz] has joined #launchpad [10:43] BjornT, that produces "IndexError: list index out of range" [10:44] mpt_: ah. how did you change PriorityEmailCommand? [10:45] Merge to devel/launchpad/: [r=lifeless] Added support to guess the place where the KDE .po files should be imported. Include tests. (r3391: Carlos Perello Marin) [10:45] go, go, go! [10:46] hmm, no stub around... [10:46] BjornT, deleted it [10:46] ohhhh [10:48] hmm, i think i need to look at your changes to mail/*.py [10:49] BjornT, you're probably the most appropriate reviewer for this branch anyway [10:49] are reviewers allowed to fix bugs? :-) [10:50] mpt_: yes [10:50] mpt_: we can always get salgado or spiv or jamesh or kiko or I or steveA to give it one more once over [10:53] ok [10:55] lifeless: I guess I should ask you as stub is not around === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:56] lifeless: I'm going to force a source code update on staging to test the KDE path I just landed [10:56] lifeless: is that ok for you? [10:56] carlos: I'm not aware of anything special being done on staging - go ahead [10:56] ok, thanks === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === Seveaz [n=seveas@ubuntu/member/seveas] has joined #launchpad [11:13] staging is back === stub [n=stub@ppp-58.8.3.153.revip2.asianet.co.th] has joined #launchpad [11:24] spiv: ping [11:24] jamesh: ping === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad [11:26] SteveA: pong [11:26] jamesh: quick call? [11:26] okay. skype or phone? [11:26] skype. i'll get my headset [11:26] or sip (although I had trouble calling lifeless earlier [11:27] hmm, I did the staging update too early, my patch was not yet in place [11:27] i don't have a sip system set up yet [11:27] stub: hi, I did a staging update to test the patchset I just asked you to cherrypick [11:27] i do hope the admins get asterisk set up soon === BjornT [n=bjorn@213.226.190.119] has joined #launchpad === mpt [n=mpt@219-89-157-131.jetstart.xtra.co.nz] has joined #launchpad [11:27] stub: but I will need to do it again because seems like the mirror was missing that revision [11:28] we were using the ekiga.net registration service [11:28] stub: ok? [11:28] but it had issues with us both being behind firewalls [11:29] jamesh: can you try restarting skype? [11:29] okay === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:31] carlos: ok. [11:33] mpt: http://ds21.cc.yamaguchi-u.ac.jp/~eigo/temp/rosetta.jpg [11:33] mpt: have you seen that? [11:34] The bug report seems to be talking about workrave integrated with launchpad!! :-D [11:35] ow [11:36] carlos, I tried to install Internet Explorer today to debug those problems, but the installer crashed [11:36] I reported a bug on it [11:36] mpt: the 'funny' part is that he was able to use the translation form and after some submissions, he got that problem === ajmitch [n=ajmitch@port169-135.ubs.maxnet.net.nz] has joined #launchpad [11:37] oh, interesting [11:37] so normally it isn't like that? [11:37] https://launchpad.net/malone/bugs/37994 [11:37] Malone bug 37994 in rosetta "Centre/Left column overlap in IE6. CSS-y. Screenshot" [Normal,Unconfirmed] [11:37] "I translated about 5 pages and then suddenly the left coloumn overlapped the centre column" [11:38] https://staging.ubuntu.com/projects/launchpad/+bugs [11:39] weird [11:42] staging is back === jinty [n=jinty@135.Red-80-37-34.staticIP.rima-tde.net] has joined #launchpad === carlos hates real world data [11:47] stub: please, ignore the cherry pick request, I found a bug [11:47] ok [11:48] Whatever updates you make though will probably depend on that patch, so if I cherry pick a later fix at some point I'll need to bring in r3391 too. [11:48] carlos: Do you have an ETA? I haven't got any rollouts scheduled this week yet. [11:49] stub: well, the fix is already done [11:49] stub: and I'm going to add the test [11:49] so, I think 30 minutes + PQM + staging update [11:49] it's a trivial fix [11:49] and is easy to test too [11:49] ok [11:53] stub - did you bounce the authserver in your last rollout ? [11:53] nope === mpt_ [n=mpt@219-89-137-113.jetstart.xtra.co.nz] has joined #launchpad [11:56] could you refresh its code and bounce it ? [11:56] then I can finish the conversion of vostok to a standard setup [11:57] stub: I spoke with elmo about us doing ssh from pqm@balleny to the appservers. Hes happy if we use a dedicated key that PQM has to do that === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [11:57] also, was the email I sent you about the layout on vostok sufficiently clear that you can do it yourself from here on out ? [11:58] yay. [11:58] I'll still pull from jubany though [11:58] I'll read it and let you know ;) [11:58] makes sense to me [11:58] hey stub [11:58] jubany is != appservers === stub can't see an email [11:59] stub: I would like if you could handle bzrsyncd@gandwana rollouts from now on [11:59] Ahh... I filed it. [11:59] ddaa: ok. [12:00] I'll keep you posted if I need to make a cherrypick at some point. [12:00] This is all getting a bit heavy weight - time to think about improving and semi-automating rollouts. [12:00] stub: yes [12:01] ddaa: why is bzrsyncd a different user? if it was the same user no extra rollout would be needed [12:02] It was often running a different branch before. If that has settled down we can run it from a central launchpad tree. [12:03] (but no reason to not keep it running as a seperate unix user - we should do more of that) [12:03] just put them all in group launchpad [12:03] ? [12:03] I like the ability to poke it directly. [12:04] That is what is happening on drescher, with different users all members of the lp_archive group so they can access the code (although it is world readable anyway...) [12:04] It's great for fixing problems quickly. [12:04] ddaa: define poke please, so stub and I dont break your poking [12:05] stracing, running manually, rolling out fixes myself [12:05] killing if necessay [12:05] though I will inform you whenever I change the production code, so we know where the buck lies [12:06] rollout is the issue, because if its a central tree, then you really need access to write to that tree [12:06] yup [12:06] and if its a central tree rollout affects all the services [12:06] As long as fixes get rolled out to rocketfuel asap and we are notified to cherry pick them into the production branch we should avoid blatting the fixes. And blatting will happen more now I'm thinking of automating software pushes to some extent [12:07] I'm all for automation. That would make it cheap to keep a separate tree. [12:07] ddaa: when was the last time you needed to write new code to fix a branch scanner bug and roll it out asap ? [12:08] quite some time ago, but "past performance is no indicator of the future" [12:08] the point is that the ability to do it adds some significant robustness to the process [12:08] at the expense of some exceptional communication [12:08] actually, I think it is :). We have a lot of cron job daemons now. But I'll leave this to you and stub, I'm happy either way. [12:09] What I'm not keen on is any non-reviewed-and-committed-to-rocketfuel code running against the production database. [12:09] stub: I just sent the merge request to pqm [12:09] I would hope that by now my reputation for anal retention would precede me in such matters. [12:10] ddaa: the thing is, I don't understand what differentiates what you are asking for from that. [12:11] for example: ability to alter the frequency or the arguments of the cronjob, ability to add debugging code [12:11] ability to run tests (e.g. email tests in the future) as the user the script is running as [12:12] (or db access tests) [12:13] I expect the branch scanner to significantly grow in size and complexity in the future. So it will likely not be always as stable as it is now. [12:15] speaking of cronjobs, we are getting to the stage of needing to migrate to some sort of central scheduler to smooth database load and contention === stub adds it to his wish list [12:15] music to my ears :) [12:16] something resembling a buildd, maybe? [12:17] perhaps. I don't know enough about buildd to make that call. [12:18] I mean in terms of overall architecture [12:18] Thats what I mean too ;) [12:18] 'buildd is like this daemon that builds stuff' [12:19] a master service handing out jobs to any number of slaves, the master centralises the smarts about what to given to who when [12:19] Yup [12:19] the slaves being quite stupid, but doing all the processing [12:19] Although it can be dumber, as we won't need to trigger arbitrary jobs on arbitrary hosts [12:20] that's a theme that is quite recurrent in my work [12:22] stub: do you need any information to handle branch-scanner rollouts? === Arafangion [n=arafangi@220-245-219-42-act-pppoe.tpgi.com.au] has joined #launchpad [12:22] stub: is there a password for launchpad@production-server ? [12:22] Probably - I'll need to have a poke around first [12:22] lifeless: You mean the unix account? I have no idea. [12:22] elmo: ? [12:23] passwords suck [12:24] yes [12:24] but I need to bootstrap the ssh key [12:27] can you ping me when the authserver has been bounced ? [12:30] Merge to devel/launchpad/: [trivial] Fixed a bug raised by real world data after my KDE changes. If the IPOTemplate is not yet imported, we cannot guess the IPOFile. Includes a test (r3392: Carlos Perello Marin) [12:31] and - when you've generated the tree for the rollout, can you leave it around for me ? [12:31] lifeless: do you know when will the branch puller will be rolled out by DBA next? [12:32] ddaa: once the authserver is bounced [12:32] It appears to be dead ATM, but I could not get a sysadmin to pong me back yesterday [12:32] and of course, I was unable to do anything short of seeing that the accumulated CPU does not grow... [12:32] ddaa: the DBA's have access to debug it. it was failing in the weekend due to a production server misconfig [12:33] wonderfish [12:33] I take it DBA have the situation under control. [12:33] * in control [12:35] there was a deadlock or something, I've killed the hung process [12:35] please try elmo, znarl, stub and I when there is a problem, not just the sysadmins. === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:41] you two were in bed [12:42] ???? [12:42] dude [12:42] ddaa: stub has a split day ;0 === ddaa looks at SteveA quizzically [12:43] oops... distracted === stub goes and plays with the authserver [12:45] lifeless: Why do you need the password to setup the ssh key? Need me to add it to authorized_keys or something? [12:45] stub: ssh-copy-id is easiest way [12:45] stub: no, I'm adding it now by hand [12:45] heh... never seen that before [12:48] lifeless: how long takes since a merge is processed by pqm and it's available from rocketfuel-built? [12:48] carlos: 30 minutes [12:48] ddaa: you should say "you two were in your beds", because "you two were in bed" means something different than you intended [12:48] carlos: worst case [12:49] SteveA: ha... thank you. [12:49] stub: its setup on gangotri [12:49] stub: if you want it on other machines, you can copy it around ;) [12:49] stub: I'll be copying it to vostok now. I'm wondering if we should ask the admins to put it in their userdb ? [12:50] I don't know how that works [12:51] ok [12:51] well when users are being authenticated it can get the key from the userldap database [12:51] which means 'any machine with a launchpad user would have this key setup' [12:54] ok, stub, you can ssh from balleny to launchpad@gangotri seamlessly [12:54] rsync too therefore === LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === G0SUB [n=ghoseb@ubuntu/member/g0sub] has joined #launchpad === Panda^ [n=giampaol@217.201.196.55] has joined #launchpad [01:11] stub: when do you think I should come back to do this ? [01:11] eh? Oh... authserver has been done. [01:12] stub: well I'm also going to rollout a new tree to vostok to get spivs sftp bugfixen === stub is having a fuzzy and unproductive day [01:12] stub: so if you are generating a production tree for gangotri and thingy, I'll use that [01:13] I haven't looked at Carlos' cherry pick yet. I just rolled out the current production launchpad branch, the tree of which can be found on chinstrap in ~stub/launchpad [01:14] stub: whats in ~/archives/rocketfuel/launchpad/production/1.56 on balleny? [01:15] r3354 with cherry picks on r3358, r3362, r3373, r3382 [01:15] so the launchpad part of the current production tree ? [01:15] yes [01:15] cool [01:16] gnarh [01:16] I wanted 3364 :p [01:16] when are you planning a new full drop ? [01:17] The vostok rollout docs look file [01:17] great [01:18] I wasn't planning a full drop this week unless somebody bitched. You bitching? [01:18] bitch! [01:18] I'm biatching [01:18] what was that about? [01:19] ok. I can do a rollout tonight if you want [01:21] maybe r3382 with carlos' stuff cherry picked [01:23] stub: r3391 and r3392 (if this one appears....) [01:23] yup [01:24] I'm testing it on staging now (but applied it manually as it's not available on rocketfuel's mirror yet) [01:25] hmm, seems like it's working ;-) [01:25] jordi: https://staging.ubuntu.com/rosetta/imports?status=APPROVED&type=all [01:30] that would be most excellent. I'll === Arafangion [n=arafangi@220-245-219-42-act-pppoe.tpgi.com.au] has joined #launchpad [01:33] I've grabbed a copy of your tree to ~/production/launchpad on balleny [01:39] carlos: good stuff! === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] [01:42] haha, just found out branch-scanner is in need of quick fix! [01:43] just a bit of db poking will do it [01:47] stub: ok, my fix landed on rocketfuel [01:48] and seems like it's working without problems on staging [01:48] stub: I think you can start with the cherrypick when you want [01:51] Merge to devel/launchpad/: [trivial] Make production config usable by authserver instance (r3393: Stuart Bishop) === carlos -> lunch [01:55] stub: do you need anything from me for that cherry pick? [01:55] nope. [01:55] ok, see you later [01:55] stub: thanks === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:00] good morning! [02:00] spiv - around ? [02:01] ddaa: rollout of the branch puller cannot happen today [02:01] ddaa: will try for tomorrow [02:01] thanks for telling me [02:01] hopefully we won't have that much downtime in the future :( [02:02] if you notice it tell someone ;). I mean, email people rather than waiting to say face 2 face [02:02] that will reduce the window immediately. [02:02] lifeless: I told kiko as soon as I noticed something was weird. [02:02] I guess I should have emailed the DBAs [02:04] if you'd like us to do something .. [02:04] BjornT: [02:04] BjornT: ping [02:04] hi matsubara [02:04] hello BjornT, would you have time to review the patch for bug 33978? [02:04] Malone bug 33978 in malone "Advanced search page doesn't do any input validation" [Normal,Confirmed] http://launchpad.net/bugs/33978 [02:06] night all [02:07] night rob [02:07] matsubara: yeah, i should have time to review it either today or tomorrow. add it to my queue on PendingReviews and put the diff somewhere. [02:07] holy cow, revision number is full of dups!!! [02:07] BjornT: ok, thanks. === David_Mills [n=chatzill@d213-103-61-137.cust.tele2.fr] has joined #launchpad [02:09]