[02:04] <MAbeeTT> hi I recently updated to oneric (3.0.0-16-generic x86_64 x86_64 x86_64 ) I tought that suspend problems will desapear with 3.0 kernel
[02:04] <MAbeeTT> but I've been wrong :(
[02:04] <MAbeeTT> How could I help to solve the suspend problems? 
[02:05] <MAbeeTT> I suspend, when I start again the system, the keybard doesn't work, there is no screen, or it stars "from zero".
[02:05] <MAbeeTT> thanks
[05:44] <bullgard4_> When booting, Ubuntu 11.10 performs: " * Starting Mount network filesystems. [OK]". But why does it immediately therafter perform the opposite:" * Stopping Mount network filesystems. [OK]" ?
[07:05]  * smb mornings
[07:35] <apw> smb, morning
[07:36] <smb> apw, A very good morning back :)
[08:07] <apw> cking, henrix, morning
[08:08] <cking> morning apw
[08:08] <apw> sunny where you are?  i am being blinded :)
[08:08] <smb> cking, henrix morning
[08:08] <henrix> apw: morning!
[08:09] <henrix> smb: morning for you too
[08:10]  * apw hands out liberal ammounts of vitamin-D harvested from the blinding rays
[08:13]  * smb fails to catch them... too bright here...
[08:16] <apw> heheheh
[08:22]  * diwic notices ppa-pre-proposed is about to run out of 16 GB of disk space
[08:25]  * smb grabs a shovel and pitch fork
[08:26]  * diwic forks the shovel for a new pitch
[08:39] <smb> Removed all superseded packages. Though it takes some time for the actual removal to happen...
[09:01] <snadge> the more you drink moonshine mixed with dr pepper.. the better it tastes
[09:39] <sashal> Hello all
[09:39] <sashal> A question to the security team: It looks like only half of the CVE-2011-4347 fix was pulled into the tree, was the 2nd part skipped on purpose?
[09:39] <ubot2> sashal: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4347)
[09:54] <apw> sashal, that number is familiar
[09:54] <sashal> apw, It's the KVM device assignment problem
[09:56] <apw> sashal, the second fix was added to the CVE late (after it was USNd I suspect) and I beleive it is being released (the second part) in this round of SRU updates.
[09:56] <sashal> apw, It was done in the same patch series as the original fix, that's why I thought it's weird in the first place
[09:57] <apw> sashal, yep, somehow the original security report only had one, the second was added some days later and we'd already spun the security update
[09:57] <sashal> Ah, Cool
[09:57] <sashal> Thanks!
[09:57] <apw> anyhow, its being done for sure if its not already out for testing
[10:00] <apw> no idea how they will handle the USN given it went out once already
[10:03] <sashal> btw, is there a timeframe in which the USN comes out after the release? Some times it takes couple of days after the kernel was moved into the production repository for the USN to come out
[10:04] <apw> sashal, i am unsure, thats handled by the ubuntu-security team, they have some manual process to ensure eyes are on things; probabally how the error was spotted in the first place
[11:39] <apw> ppisati, are you planning a further rebase for precise/ti-omap4, or waiting till leanns next upload??
[11:56] <ppisati> apw: more stuff to come, don't upload yet 
[11:57] <ppisati> apw: i just found out there's a critical still open for P/omap4 (i was lost in perf land till yesterday)
[11:57] <ppisati> apw: so either i fix it by tonight or i'll ask for a revert to the previous TI BSP + stuff we have on top of HEAD now
[11:57] <ppisati> tgardner: FYI - ^^
[11:58] <tgardner> ppisati, ack
[12:02] <apw> ppisati, ok thanks
[12:03] <apw> ppisati, i assume you are saying that will occur as a quick fix for B2 and then you'll fix it properly sort of thing ?
[12:03] <apw> cking, did i hear rumours you were talking to people about the aspm-1.1 issues ?
[12:04] <cking> yep
[12:05] <apw> tgardner, i see that ericm said that they were sending out that ath5k thing with a new version number, but i recall you applying the firware with the current name, are we going to be broken in the future by that ?
[12:05] <tgardner> apw, only if the firmware _isn't_ backward compatible, though Atheros says it is.
[12:06] <tgardner> apw, besides, I assume that'll be 3.4 material
[12:08] <apw> tgardner, does this mod_probe stuff have a CVE associated with it, i have a vague feeling it might
[12:08] <tgardner> apw, not that I could find. jdstrand stumbled across it this weekend, so I picked it up myself
[12:09] <apw> tgardner, i could swear i have read a cve for it, but cannot find it in our list ... sigh
[12:10] <ppisati> apw: yes, if i can't make HDMI output to work by tonight, i'll take latest master + previous TI BSP (where hdmi output was working) + latest patch on top of P/omap4 (cross compile fixes + pperf revert) just for beta2
[12:10] <Teduardo> howdy, does anyone know if there will be a new version of the kernel for lts 10 installer so that we can install it on Dell 12 Gen servers?
[12:10] <ppisati> apw: in the meantime i'll keep trying to find the root cause of the breakage with the new TI BSP code
[12:10] <tgardner> Teduardo, by Tuesday.
[12:11] <Teduardo> oh thats good news i read somewhere that 10.04.4 was going to be the "FINAL" release
[12:11] <tgardner> Teduardo, oh, lts 10. I'm thinking 12.04.
[12:11] <Teduardo> and that made me want to curl up in a ball and cry
[12:11] <tgardner> Teduardo, 10.04.4 _is_ the last release
[12:12] <Teduardo> ack
[12:12] <tgardner> Teduardo, you can't get an install to work from the 10.04.4 DVD ? Every kernel through Oneiric is available on it
[12:13] <Teduardo> ah, we can't do dvd installs, everything we use is pxe =(
[12:13] <tgardner> Teduardo, well, you could craft your PXE boot _from_ the DVD
[12:14] <Teduardo> all I really need is a kernel and initrd that supports the new NIC and new LSI controller
[12:14] <tgardner> Teduardo, which is why I pointed you at the DVD. the installer supports multiple kernels.
[12:18] <bullgard4> When booting, Ubuntu 11.10 performs: " * Starting Mount network filesystems. [OK]". But why does it immediately therafter perform the opposite:" * Stopping Mount network filesystems. [OK]" ?
[12:18] <Teduardo> tgardner: okay, I think currently the only one that works on this platform is 11.10, I'll have to just use that it seems
[12:19] <tgardner> Teduardo, well, you'll have 12.04 soon
[12:19] <tgardner> Teduardo, in fact, you should be testing it now
[12:19] <Teduardo> hopefully the installer works in the first release, usually there is almost always some kind of LVM menu loop that breaks kickstart
[12:20] <Teduardo> or it tells me it can't find a disk to install on even though fdisk -l shows /dev/sda... etc
[12:20] <tgardner> Teduardo, I've been doing 12.04 PXE installs on a variety of platforms.
[12:20] <Teduardo> ah i'm talking about my experience with 11.10
[12:21] <tgardner> Teduardo, have you filed a bug ?
[12:23] <tgardner> apw, are you gonna ACK the kmod patches ?
[12:43] <apw> tgardner, working through them now
[12:43] <apw> b smb
[13:05] <apw> tgardner, ok ... i think as much as a huge pile like that can be, they are ok.  acks in your inbox
[13:06] <tgardner> apw, I've been through them pretty thoroughly myself. I've also booted each kernel.
[13:07] <smb> I mumble broken only for me?
[13:07] <jsalisbury> smb, no mine is bouncing
[13:07] <smb> Meh, no
[13:07] <ppisati> yep
[13:07] <tgardner> apw, has your mumble connection just bailed ? 
[13:07] <ppisati> "serve connectio failed: connection refused"
[13:07] <tgardner> how annoying
[13:07] <smb> #is is already buggered
[13:08] <apw> tgardner, not on it, without headset for a few hours
[13:08]  * tgardner kills mumble
[13:37] <apw> tgardner, look like is think it is back now
[13:37] <tgardner> apw, huh?
[13:37] <tgardner> -ENOPARSE
[13:38] <Nafallo> s/is/IS/
[13:38] <apw> IS think m,umble is back
[13:38] <tgardner> apw, yes
[13:55] <apw> right ... /me makes a run for home .. back in 1.5
[13:56] <cking> mjg59, for these PCIe ASPM hangs on boot it seems we could be hitting a BUG_ON in pcie_aspm_configure_common_clock() because the child isn't apparently pcie capable.
[13:57] <mjg59> Just. What?
[13:58] <cking> mjg59, it makes no sense, but we got a user to get a full stack dump and it seems (I may be wrong!) that BUG_ON is being called
[13:58] <mjg59> cking: Oh right I see. Argh.
[13:58] <mjg59> Yes, this is just about possible.
[13:58] <cking> I suspect the BUG_ON is being a bit harsh
[14:00] <cking> for the life of me I can't see why this is biting us now
[14:00] <mjg59> cking: http://fpaste.org/bOQm/
[14:02]  * cking mulls on that for a moment
[14:02] <mjg59> cking: Prevously we'd bail if any children weren't pcie. Now we won't.
[14:03] <mjg59> We need to continue to do so in order to avoid the BUG_ON
[14:03] <cking> ah, that's we are being caught out
[14:03] <cking> got it
[14:04]  * cking will give it a spin
[14:06] <cking> methinks mjg59 is always at least 24 hours ahead of me 
[14:07] <mjg59> cking: Thanks for that - I don't think there's any way I'd have figured it out otherwise
[14:08] <cking> mjg59, no problem, getting a full stack dump and walking it through was the easy bit, I got stumped at why the BUG_ON was happening
[14:10] <mjg59> cking: I think I'll just send that - it's Obviously Correct(tm)
[14:10] <cking> heh, I can also get the users to verify it to sanity check that, but it normally takes ~24 hours 
[14:41] <ogasawara> cking: let me know when you get confirmation on the patch, there may be time to squeeze it in for Beta-2
[14:41] <cking> ogasawara, yep, will do
[14:41]  * ogasawara back in 20
[14:41] <tgardner> ogasawara, I just plucked it from the stable mailing list and applied it.
[14:42] <cking> we cross our fingers ;-)
[14:42] <tgardner> cking, you should build current master-next and post it as a test kernel to your various testers
[14:43] <cking> tgardner, ack
[14:45] <ogra_> ppisati, any idea about bug 963512 ? the release team just asked about it 
[14:45] <ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
[14:45] <ppisati> ogra_: i'm on it
[14:45] <ppisati> ogra_: will upload a new kernel with working hdmi by tonight
[14:50] <ogra_> ppisati, how late is "tonight" we would like to have working images for the beta release 
[14:51] <ppisati> ogra_: in a couple of hours
[14:51] <ppisati> ogra_: is it soon enough?
[14:52] <ogra_> ppisati, couple of hours should be fine
[15:11] <MAbeeTT> hi I recently updated to oneric (3.0.0-16-generic x86_64 x86_64 x86_64 ) I tought that suspend problems will desapear with 3.0 kernel
[15:11] <MAbeeTT> but I've been wrong :(
[15:11] <MAbeeTT> How could I help to solve the suspend problems? 
[15:11] <MAbeeTT> I suspend, when I start again the system, the keybard doesn't work, there is no screen, or it stars "from zero".
[15:12] <MAbeeTT> of course, I didn't found logs with interesting info about suspend.
[15:13] <MAbeeTT> the problem existis via pm-suspend command or "suspend option in unity/gnome"
[15:13] <MAbeeTT> thanks
[15:15] <ogasawara> tgardner: I'm inclined to upload it
[15:16] <tgardner> ogasawara, I was gonna ask if you were willing to.
[15:16] <ogasawara> tgardner: I am, as I think that bug is going to affect a few systems if we don't
[15:17] <tgardner> absolutely
[15:17] <cking> yep
[15:18] <tgardner> ogasawara, I've smoked tested it, but not on an affected platform. cking should get one via fedex yet today perhaps
[15:18] <ogasawara> cking: Ooo, you're sure you'll get a system today?
[15:18] <ogasawara> cking: if that's the case, I'd maybe wait to upload to get confirmation of the fix
[15:18] <cking> ogasawara, normally they arrive after lunch, now it's past 4pm, so it's looking slim
[15:20] <tgardner> ogasawara, I still think its worth it. besides, there are abunch of other patches that need to get into the pipeline
[15:20] <ogasawara> cking: my thoughts are I'd upload even without test verification.  we've already rendered the machines unbootable, it can't get too much worse.
[15:20] <cking> indeed
[15:21] <ogasawara> tgardner: I was only planning to pick this single patch, are there other's you wanted in?  as I'd need to justify them to the release team.
[15:21] <tgardner> ogasawara, seccomp ?
[15:21] <tgardner> ogasawara, bunch of AA fixes as well.
[15:22] <tgardner> I forgot we're still awaiting B2
[15:24] <ogasawara> tgardner: right, seccomp should already be uploaded as I squeezed it in before beta-2 freeze.  the latest AA patches I didn't think were critical for Beta-2 and could wait till after.
[15:25] <tgardner> ogasawara, ah right. I missed the Ubuntu-3.2.0-20.32 patch in master-next. 
[15:25] <tgardner> ogasawara, how about the AMD KVM pacthes ?
[15:26] <ogasawara> vanhoof: ^^ bug 960466 how critical is that for you guys to land in Beta-2
[15:26] <ubot2> Launchpad bug 960466 in linux "Provide correct reporting of BMI1/AVX2/BMI2 support" [Medium,Fix committed] https://launchpad.net/bugs/960466
[15:27] <ogasawara> vanhoof: or can it wait till first upload post Beta-2
[15:27] <vanhoof> ogasawara: can wait for first upload post b2
[15:27] <ogasawara> vanhoof: ack, thanks
[15:27] <vanhoof> ogasawara: critical for release, but not for b2
[15:30] <vanhoof> ogasawara: is there any chance of them missing the release if we dont land it for beta 2?
[15:30] <ogasawara> vanhoof: nope.  kernel doesn't freeze until next thurs Apr 5.  I'll make sure they make it before kernel freeze.
[15:31] <tgardner> vanhoof, no, they are in the pipeline
[15:31] <vanhoof> ogasawara: cool, that works
[15:32] <tgardner> jsalisbury, top 10 mumble ?
[15:33] <jsalisbury> tgardner, we started having it an hour from now, to keep it 30 minutes before the IRC meeting.
[15:33] <arges> jsalisbury, did the invite not get moved in the calendar?
[15:33] <tgardner> jsalisbury, well then, I'll just fix the calendar
[15:34] <jsalisbury> arges, I don't think so, but it sounds like tgardner will do it :-)
[15:35] <cking> stupid summer time clock changes
[15:43] <cking> ogasawara, so the box I need to test it with was last seen in MEMPHIS, TN, so it's unlikely to arrive today
[15:44] <ogasawara> cking: ack, thanks.  I'll prep the upload anyways.
[15:45] <cking> stymied by fexex this time
[15:45] <cking> fedex
[15:46] <jsalisbury> **
[15:46] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:46] <jsalisbury> **
[15:49] <ppisati> tgardner: ok, pull sent
[15:49] <tgardner> ppisati, ack
[15:50] <tgardner> ppisati, you're wanting this uploaded for B2 ?
[15:50] <ppisati> tgardner: yep
[15:58] <adam_g> win 15
[15:59] <tgardner> ppisati, so that is some seriously bizarre shit you did with the ti-omap4 branch. are you gonna work on what regressed ? might have been something in the 3.2.13 stable updates.
[15:59] <ppisati> tgardner: yes, it came with latest rebase
[16:00] <ppisati> tgardner: i'll figure out but i want beta2 to be safe
[16:00] <ppisati> tgardner: TI BSP is the same, so there's something from upstream that kills hdmi output
[16:01] <tgardner> ppisati, ok, I'm packaging....
[16:01] <ppisati> tgardner: cool, thanks
[16:04] <tgardner> ppisati, do you not have the right HW to have detected the HDMI regression ?
[16:05] <ppisati> tgardner: no, it's just that the bug was opened on friday and i saw it this morning
[16:05] <ppisati> tgardner: i was working with the server install
[16:05] <tgardner> ah, ok
[16:05] <ppisati> for the perf bug
[16:09] <apw> tgardner, are you looking for acks for that pre-stable patch ?
[16:09] <tgardner> apw, nope, just advertising that I applied it.
[16:10] <apw> tgardner, wfm
[16:11] <tgardner> apw, I am, however, looking for ACKs on the Oneiric tsc stabilization patch
[16:11] <tgardner> ppisati, your kernel is in the queue awaiting approval. go bang on the release team to get it through
[16:12] <ppisati> tgardner: k, thanks
[16:12] <ppisati> tgardner: what's the channel?
[16:13] <tgardner> ogasawara, can you help out ppisati ?
[16:13] <ogasawara> ppetraki: #ubuntu-release
[16:13]  * tgardner hasn't requested a freeze exception in awhile
[16:13] <ogasawara> bah ppisati ^^
[16:13] <ppisati> k
[16:13] <ppisati> will do
[16:13] <ogasawara> ppisati: ping skaet in there
[16:14] <ogasawara> ppisati: or I can just do it, just a sec
[16:23] <tgardner> ppisati, [ubuntu/precise] linux-ti-omap4 3.2.0-1411.14 (Accepted)
[16:24] <ppisati> cool, thanks everyone
[16:24] <tgardner> ogra_, ^^
[16:24] <ppisati> next time i won'd do any upload around FF, i swear...
[16:25] <apw> ppisati, is building on both armel and hf
[16:26]  * ogra_ hugs the kernel team
[16:27] <tgardner> ogra_, we prefer beers
[16:28] <apw> or a glass of fine red wine
[16:28] <ogra_> non virtualized i guess ... so that has to wait until UDS :)
[16:33] <cking> mjg59, user has given positive feedback - that patch works fine.
[16:36] <mjg59> cking: Great
[16:36] <mjg59> cking: I've posted it to LKML and linux-pci - would be great if you could follow up with confirmation it works
[16:37] <cking> ack, 
[17:08] <jsalisbury> bug 961482
[17:08] <ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix released] https://launchpad.net/bugs/961482
[17:08] <smb> bjf, Just fyi, I did a spring cleaning on the kernel-ppa pre-proposed ppa and sent all superseded packages away. It was reaching its limit
[17:10] <bjf> smb, thanks, last time i tried, LP just kept timing out
[17:10] <smb> bjf, Yes it did that to me as well when I tried them all at once. It seems ok when slecting only 10 at a time
[17:30]  * ppisati goes for some groceries, back in a bit
[18:03]  * apw reboots ...
[18:33] <apw> abogani, about ?
[18:39] <infinity> apw: You probably want TheMuso. :P
[18:42] <infinity> apw: Oh, while I'm being annoying, though, could you have a poke at bug #965840 for precise and possibly SRUs?
[18:42] <ubot2> Launchpad bug 965840 in linux "Need to apply patch: "ARM: Do not call flush_cache_user_range with mmap_sem held"" [Undecided,Confirmed] https://launchpad.net/bugs/965840
[18:43] <apw> ppetraki, ^^ more arm fun :)
[18:43] <infinity> ppisati: ^ You too. :P
[18:44] <infinity> apw: I poked you since we'd want it applied to omap as well (and then wouldn't paolo get it for free when he rebases?)
[18:46] <apw> infinity, bah you slave driver you
[18:46] <infinity> Hahaha.
[18:46] <apw> TheMuso, we need to get some SOPs for the lowlatency kernel when we need to do emergency updates such as was desired today
[18:46] <infinity> apw: AIUI, the patch will break pre-v6 (which is why it's not yet upstream), but we don't give a hoot about anything pre-v7, so it seems sane to me to carry the fix.
[18:47] <apw> infinity, assuming you've tested it on some of the affected kit that seems fine
[18:47] <apw> infinity, have we ?
[18:47] <infinity> The user who reported it has.  I can certainly spin something up "later", FSVO "later".
[18:48] <infinity> (If it's any comfort, it's also in 95% of the v7 Android trees out there)
[18:48] <apw> heh no comfort at _all_ frnakly
[18:48] <infinity> Hahaha.
[18:49] <infinity> Yeah, that's a fair point. :P
[18:49] <infinity> Well, once I get this grub bug nailed to a wall, I'll see if I can do some local testing of this patch.
[18:50] <infinity> Unfortunately, there's no particularly sane way to test it beyond smoketesting that it boots and doesn't crash.
[18:50] <infinity> Since the condition required to reproduce the bug it's fixing is "lots of random luck".
[18:50] <apw> i more care that the boards we care about continue to boot with it
[18:50]  * apw spins a kernel with it
[18:51] <infinity> Yeah.  That's almost certainly true just from eyeballing the patch, but I can test to confirm.
[18:51] <ppisati> apw: do you want me to take care of 965840?
[18:51] <apw> ppisati, s'ok for now as i have the patch and its likely master material
[18:51] <apw> infinity, that reminds me where are all the other deviant kernels on that bug, the source trees ?
[18:52] <infinity> apw: mx5 is a linaro kernel, and ac100 is jani's baby, not sure where he keeps the tree.
[18:52] <ppisati> apw: ok
[18:52] <infinity> apw: In both cases, I'll probably just update the precise kernels myself, and let the respective maintainers sort out their gits later.
[18:52] <infinity> apw: (And I'm not wildly concerned about SRUs for the weird kernels, just for omap/omap4, since we use them as buildds)
[18:53] <apw> infinity, which random old crap are you wanting this on
[18:55] <apw> infinity, ^^
[18:56] <infinity> apw: omap4 natty and newer, and for master, everything you're still doing SRU napalm runs for, I guess.
[18:57] <apw> infinity, can we not get those buildds onto one release, at least to reduce the exposure when we have something real bad
[18:57] <infinity> apw: My hope is that all the buildds will be precise "soon".  But it's not really up to me. :/
[18:57] <infinity> apw: If I still had root on them, they'd all be 3.2.x right now. :P
[18:58] <apw> infinity, a plan indeed.  anyhow, i'll get you a P binary-omap to test out and if that sails i'll commit it for the next P after B2
[19:00] <apw> smb, what colour are your osb backgrounds ... ?
[19:04] <cking> unity 3d feels really much snappier nowadays even on my old crate of a laptop
[19:28]  * tgardner relocates
[19:29]  * cking -> EOD
[20:18]  * tgardner -> EOD
[20:40] <lamont> can I reshape a raid1 into raid5?
[20:46] <infinity> lamont: If you drop a disk, and call it a degreaded raid5 with 1 disk, then add more, possibly.
[20:46] <infinity> apw, ppisati: Do I get a new meta for that omap4?
[20:46] <lamont> infinity: hrm
[20:47] <lamont> given that I'm actually trying to take a 3-drive raid5 and make it a different 3-drive raid5, that could be interesting
[20:47] <infinity> lamont: I wouldn't hold my breath though, as raid0,5,6 all use clever striping algorithms and do fancy things with superblocks.
[20:48] <infinity> lamont: raid1 isn't really terribly clever at all, in comparison.
[20:48] <infinity> lamont: Oh, for 5->5, my home upgrade strategy is "never upgrade the array until the largest disk on the market is bigger than my entire array".
[20:49] <infinity> lamont: So I can drop a disk, run degraded, backup to one of the new disks, create new degraded array, profit.
[21:50] <TheMuso> apw: SOP?
[22:04] <apw> 'standard operation proceedures'
[22:04] <apw> TheMuso, ^^
[22:04] <TheMuso> ok
[22:05] <apw> TheMuso, so we know where the master branch is, how to get you an update when we've had to step on your toes, that sort of thing
[22:05] <apw> something to think about after the freeze is lifted probabally, as you arn't the only outside tree, and there are only becoming more
[22:05] <TheMuso> apw: Right well the plan is to get the studio guys to do the majority of the work, and I just review/upload, but we're not there yet, and we still need to devide where the kernel tree will eventually be hosted such that we all have access.
[22:06] <TheMuso> decide
[22:06] <apw> TheMuso, right and its unlikely all the trees will work quite the same, so likely there will be some common wiki page or something with the 'how, who, where' bits of information etc... and you get to help work out the game
[22:07] <TheMuso> Yep gotcha.
[22:07]  * apw heads for the couch
[22:07] <TheMuso> apw: BTW when I've tried to rebase recently, apparmor stuff has seemed to be applied on top of the most recent Ubuntu-x-y-z commit... Am I doing something wrong? I am just using "git fetch precise master" git rebase refs/remotes/precise/master
[22:08] <TheMuso> ...or is anybody else able to answer?