[05:36] <ozysimpson> sorry for cross posting: Could some one please point me to a document or help me in Setting up RAID on an existing Ubuntu Machine, the machine only had 2TB hard drive, i saw my friends machine just die last week and lost most of his data, I am being little cautious here went and brought another disk 2TB now my ubuntu is able to see the disk, could some one tell me how to setup as RAID 1 mirror please
[07:56] <czajkowski> ozysimpson: this isn't the channel to ask that kinda question, perhaps #ubuntu
[11:36] <smartboyhw> wgrant, weird, https://launchpad.net/builders/chindi02 takes 2 days to build a translation template-.-
[11:37] <cjwatson> It's obviously dead, but I wonder how to cancel it ...
[11:37] <wgrant> Done
[11:38] <wgrant> un-ok, wait for scan to rescue the DB job, re-ok, next scan will rescue slave
[11:38] <cjwatson> Ugh
[11:38] <cjwatson> We should expose a builder's current build on the API
[11:38] <wgrant> 2013-09-16 11:37:58+0000 [QueryProtocol,client] Builder 'chindi02' rescued from 'TRANSLATIONTEMPLATESBUILD-43563': 'Slave building when should be idle.'
[11:38] <wgrant> cjwatson: TTBs can't be cancelled normally anyway.
[11:39] <cjwatson> How come?  The process-reaping bits in lp-buildd are hooked up for them.
[11:39] <wgrant> I mean on the DB model side
[11:39] <wgrant> They have no concept of cancellation, in either the model object or the BFJB
[11:40] <cjwatson> Ah, ugh
[11:42] <cjwatson> Incidentally "Builder 'chindi02' rescued from 'TRANSLATIONTEMPLATESBUILD-43563': 'Slave building when should be idle.'" repeats a lot in the buildd-manager log - is something wrong there or does it just take a while?
[11:42] <wgrant> The slave isn't cancelling, quite possibly because it's hung beyond repair.
[11:42] <wgrant> We should probably immediately reset if there's no job to send the log back to
[11:43] <wgrant> In fact I think I have a bug for that.
[11:43] <wgrant> https://bugs.launchpad.net/launchpad/+bug/1041701
[11:45] <cjwatson> Mm, I think I didn't touch that because I don't sufficiently understand the fake-virtual armhf builders.
[11:45] <wgrant> That's obsolete now; the virtual builders are all virtual.
[11:45] <wgrant> I might look at it this week.
[11:46] <wgrant> When I filed that bug, the armhf builders were pandaboards with a no-op reset trigger
[11:46] <wgrant> So resetting for cleanup purposes wouldn't be immensely effective.
[15:45] <Akiva-Mobile> Greetings, I am on windows, using the bazaar gui, and I am trying to make my own branch to a project. This is the code I am using:  bzr+ssh://bazaar.launchpad.net/~lord-high-exchequer/dominion.linux/trunk/
[15:46] <Akiva-Mobile> unfortunately it is saying in response "Permission denied (publickey).
[15:46] <Akiva-Mobile> ConnectionReset reading response for 'BzrDir.open_2.1', retrying"
[15:46] <Akiva-Mobile> im new to launchpad and bazaar; is there something I am doing wrong?
[15:48] <mgz> Akiva-Mobile: what do you get from `ssh -vv lord-high-exchequer@bazaar.launchpad.net`? you have some ssh keys on that account, but you need the private key accessible locally to connect
[15:49] <Akiva-Mobile> thanks
[15:50] <Akiva-Mobile> mgz from a terminal, right?
[15:50] <Akiva-Mobile> or from the gui?
[15:50] <Akiva-Mobile> < graphics designer, not a programmer :/
[15:51] <mgz> Akiva-Mobile: from a terminal, it will give more details before the "Permission denied (publickey)" from the underlying program, which might be helpful
[15:51] <mgz> !pastebin
[15:52] <Akiva-Mobile> thanks
[15:56] <Akiva-Mobile> okay, so I was lying, winterfrost was the guy having the issues;
[16:06] <mgz> Akiva-Mobile: so, he needs his own account and ssh key, is the answer
[16:07] <mgz> get him to read the setting up ssh page on help.launchpad.net
[16:07] <Akiva-Mobile> mgz: your script actually apparently worked for him
[16:07] <Akiva-Mobile> he had that setup
[16:07] <winterfrost> Yeah, I had the ssh key done. It seems to be working now though.
[16:08] <Akiva-Mobile> mgz: +1 internet points for you
[16:09] <shadeslayer> could someone look at this recipe failiure https://launchpadlibrarian.net/150406874/buildlog.txt.gz
[16:24] <shadeslayer> wgrant: czajkowski ^^
[16:24] <shadeslayer> can be reproduced everytime
[16:25] <shadeslayer> https://code.launchpad.net/~blue-shell/+recipe/milou-daily > for all failiures
[18:01] <czajkowski> shadeslayer: I don't work for canonical any more
[18:02] <shadeslayer> oh ....
[18:03] <dobey> shadeslayer: eh. looks like it works now?
[18:04] <shadeslayer> dobey: I changed the version
[18:04] <shadeslayer> so that it doesn't use git-commit and doesn't use version 0.4
[18:05] <shadeslayer> dobey: the weird thing is that it works in another project
[18:05] <shadeslayer> but that project uses nest instead of merge for the packaging brancjh
[18:05] <shadeslayer> actually, that might make sense, because if you merge 2 branches the git commit might change or sth
[18:06] <shadeslayer> since you're modifying the bzr history
[18:06] <shadeslayer> yofel: ^^
[18:06] <shadeslayer> while in nesting you're not
[18:06] <shadeslayer> but then why does it work locally ...
[18:06] <yofel> what does merging have to do with *git*-commit? If anything it would change revno
[18:07] <dobey> i'd say more likely git-commit would fail because with merge you'd have uncommitted changes in the tree
[18:09] <shadeslayer> dobey: so why does it work locally
[18:09] <dobey> shadeslayer: you're not running on hardy?
[18:10] <shadeslayer> heh true, but I thought the buildd's had the latest bzr?
[18:10] <dobey> maybe it's not a bzr issue, but python?
[18:10] <dobey> there are plenty of issues that only happen on the build servers, unfortunately :-/
[18:10] <shadeslayer> hm, yeah, the traceback does indicate that it doesn't have a python method split
[18:11] <shadeslayer> someone should document these quirks in the launchpad help page
[18:11] <yofel> well, the buildd's use python2.5, which indeed is far too old
[18:11] <yofel> this is bug 915505 btw.
[18:14] <shadeslayer> yep, nesting works
[18:14] <shadeslayer> silly launchpad
[18:59] <cjwatson> yofel: builderstack (which will involve them running precise instead of hardy) is supposed to be RSN
[19:00] <cjwatson> (though we've been hearing that for a while)
[19:01] <yofel> yeah, I'll be happy once it gets fixed, but I'm not holding my breath ^^
[21:28] <alesage> I'm having some trouble getting through to the LP API, does it need kicking?
[21:38] <dobey> trouble in what sense?
[21:39] <alesage> dobey, let me paste one sec
[21:40] <alesage> dobey, here's me in ipython: http://paste.ubuntu.com/6116795/
[21:48] <dobey> oh, that is the staging server
[21:49] <cjwatson> Yeah, staging was having a (long) DB restore last I checked
[21:49] <dobey> appears to still be going as the OOPS is a DB issue on the server
[21:52] <cjwatson> It's a many-hour job
[21:52] <cjwatson> wgrant estimated 12-24 hours about 7.5 hours ago
[21:55] <alesage> dobey, cjwatson ok yes I'm able to get on the production service, thanks
[22:16] <alesage> can someone instruct on how to use the LP API to get all bugs reported by a specific user?
[22:21] <cjwatson> alesage: person.searchTasks(bug_reporter=person)
[22:21] <cjwatson> should do it
[22:21] <alesage> cjwatson, thanks :)