=== ivan\ is now known as root
=== root is now known as Guest49897
=== Guest49897 is now known as ivan\
[08:04]  * apw yawns widely
=== yofel_ is now known as yofel
[12:29] <rtg> tseliot, how are nvidia and fglrx dkms packages coming along for 3.15 support ? It is time to get 3.15 into the wild.
[13:01] <apw> henrix, the cve tracker may be in a heap right now, quantal just got zapped, so ignore it for the near term, will let you know when its all happy
[13:01] <henrix> apw: ack, thanks
[13:26] <tseliot> rtg: I fixed nvidia-304. the other nvidia drivers (except for 173) should work. fglrx should also work (although I haven't tested it yet)
[13:27] <rtg> tseliot, cool, then I'll get it uploaded to the utopic archive
[13:27] <tseliot> good
[13:27] <rtg> apw, ^^ do you agree ?
[13:27] <apw> rtg, if the nvidia, fgrlx, wl and iscsitarget are there, i think we have our "core set"
[13:28] <apw> (and i beleive that we do indeed)
[13:28] <rtg> apw, I believe infinity said we should upload the first time as opposed to doing a pocket copy.
[13:29] <apw> rtg, i'd say do that anyhow as it makes the overrides work right
[13:29] <rtg> apw, yup.
[13:30] <apw> assuming it has a release tracker in it :)
[13:30] <rtg> apw, :) yeah, I'll get it wrapped and uploaded, then babysit it all weekend.
[13:30] <apw> heh :)  no snow then ?
[13:31] <rtg> apw, driving to Beaverton this afternoon. 11+ hours.
[13:31] <apw> i wish my afternoons were 11 hours long sometime [sic]
[13:33] <rtg> apw, I might get another day or so of back country in before mid-July. There are some north facing steep gnarly chutes that hold snow until late in the summer.
[13:33] <apw> snow in july, does-not-compute, i am used to the kind which is "no snow by mid afternoon" kind
[13:34] <rtg> One called "pencil dick" is truly terrifying. thats this one: linux.tpi.com/~rtg/bridger-bowl-Apr-29-2014/IMGP0021.JPG_index.html
[13:37] <apw> rtg you are insane, truly
[13:37] <rtg> apw, well, thats not my track in it :)
[13:38] <apw> rtg, gads it actually has a ski track down it, *gibber*
[13:39] <rtg> apw, we'd likely have done it that day, but its a fair walk/climb and we were getting short on time.
[13:39] <rtg> it had an unusual amount of snow, but we are at 150% of snow pack for the year.
[13:45] <rtg> apw, pushed utopic master-next, starting test build. I didn't bump the ABI since everything was packaging except for CONFIG_FSL_PAMU=n 
[13:46] <apw> rtg, also the only people with it are you and me; and if we can't cope with that ... shoot us now
[13:47] <rtg> apw, isn't the CONFIG_FSL_PAMU=n patch for powerpc ? I ain't got one 'o dose.
[13:48] <apw> rtg, yeah i think so, i meant to say, we don't care if it is a bumper or not, noone has the old -1 in the wild so a new -1 is just fine; though it prolly isn't a bumper anyhow
[13:49] <apw> might be nice to bump the upload number so we get upgraded
[13:49] <apw> (but i am sure you were going to do that anyhoo)
[13:49] <rtg> apw, Ubuntu-3.15.0-1.3 is an upload number bump
[13:50] <apw> henrix, ok the cve tracker seems to have healed itself
[13:50] <apw> rtg, cool, that'll do it in deed
[13:50] <henrix> apw: indeed! thanks
[16:27] <spideyman> jsalisbury Hi, for CVE-2014-0196, which precise kernel will contain the fix? I want to be sure I have the right one
[16:28] <jsalisbury> spideyman, let me double check
[16:28] <spideyman> jsalisbury thanks so much
[16:28] <rtg> apw, fire in the hole
[16:28] <apw> rtg, ack ... will keep a weather eye out for it migrating :)
[16:29] <jsalisbury> spideyman, 3.2.0-63.94
[16:30] <spideyman> jsalisbury awesome, thx again
[18:42] <infinity> zequence: Everything got respun for a 1-line revert. :/
[18:42] <infinity> zequence: Do you have time to do the quick rebase?
[19:23] <zequence> infinity: Ah, sure. np
[19:24] <infinity> zequence: You rock.
[20:18] <infinity> BenC: Out of curiosity, did you verify that pulling in grub-ieee1275 on your systems doesn't flip out due to the lack of a PReP partition?
[20:27] <BenC> infinity: Yep. We’ve actually been running with that on our system since day 1
[20:28] <infinity> BenC: Ahh, cool.  Just wanted to make sure.  So, grub-install is basically just a no-op on your systems?
[20:28] <BenC> Just to generate grub.cfg. grub-common could do it alone, but we don’t get all the snazzy “Ubuntu XXX” naming, it would just say “Linux xxx”
[20:29] <BenC> infinity: Well, grub-install wouldn’t work…if it makes more sense, then at the least, grub-common is needed, but grub-ieee1275 includes all the extra naming (we just need update-grub run to generate grub-cfg)
[20:29] <BenC> *grub.cfg
[20:29] <infinity> Though, there could be an argument for wasting a few MB for a useless PReP partition anyway, so your filesystem is also bootable (well, with a different kernel) in qemu/slof.
[20:30] <BenC> Well, grub-ieee1275 has zz-update-grub for kernel post inst/rm
[20:30] <infinity> BenC: I'm sure grub-install won't work, my point was that I hope it doesn't also FAIL, cause then you've just broken the kernel upgrade. :)
[20:30] <BenC> infinity: If we’re just talking about installing kernels, then no problems there at all
[20:31] <infinity> But hopefully the platform detection stuff just sees yours as one it knows nothing about and skips along.
[20:31] <BenC> grub-install doesn’t run for that
[20:32] <BenC> Installed-Size: 186
[20:32] <BenC> It’s pretty small
[20:32] <infinity> BenC: It runs in grub-ieee1275.postinst and you've made the kernels depend on that.  That's what I'm driving at.
[20:32] <infinity> BenC: But if you've not seen it explode, then we must have (accidentally?) gotten the detection, or lack thereof, right. ;)
[20:32] <BenC> grub-ieee1275 has never failed to install or upgrade on our system, so I suspect it’s all fine :)
[20:33] <infinity> \o/
[20:34] <infinity> BenC: On a not entirely related matter, when you do qemu/kvm on your machines, do you emulate pSeries with SLOF and, confusingly, an FSL CPU, or do you emulate some sort of FSL platform?
[20:34] <infinity> (And, if the latter, how does that boot?)
[20:34] <BenC> FLS platform (e500-generic, uses host cpu detection)
[20:35] <infinity> BenC: Maybe I should get you to send me one of your 64-bit systems sometime, so I can ask these questions from the hardware. :P
[20:35] <BenC> You can either boot a vmlinux/initrd directly, or use our platform kernel+initrd to boot the same way the native hardware boots (with grub)
[20:36] <BenC> We suggest the later and it works just like the grub on kvm x86 systems
[20:36] <BenC> *latter
[20:36] <BenC> IOW, you can boot the kernel+initrd on your system rather than a hard passed one on the command line
[20:37] <BenC> s/on your system/on your disk image/
[20:38] <infinity> Righto.  That's what I prefer too.  Was just curious where the firmware comes from.  I guess you ship that outside the archive.
[20:38] <infinity> (For pSeries, it uses qemu-slof, which is in the archive, though qemu doesn't currently depend on it, which is a mistake)
[20:39] <infinity> Or does it pull some tricks to actually read it from the host system's firmware and reuse it without needing a copy in the filesystem?
[20:39] <infinity> Which would be somewhere between clever and awful, and probably both.
[20:40] <BenC> It requires you to download them from our public archive
[20:40] <BenC> Maybe one day we’ll be that clever :)
[20:48] <infinity> BenC: I suspect that would tip closer to "awful" than "clever", but certainly shipping your "firmware" in the archive might be nice.
[20:49] <infinity> BenC: Probably moot, though, I imagine your customers can figure it out.