| === ivan\ is now known as root | ||
| === root is now known as Guest49897 | ||
| === Guest49897 is now known as ivan\ | ||
| * apw yawns widely | 08:04 | |
| === yofel_ is now known as yofel | ||
| 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. | 12:29 |
|---|---|---|
| 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:01 |
| 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:26 |
| 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:27 |
| 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:28 |
| apw | rtg, i'd say do that anyhow as it makes the overrides work right | 13:29 |
| rtg | apw, yup. | 13:29 |
| 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:30 |
| rtg | apw, driving to Beaverton this afternoon. 11+ hours. | 13:31 |
| apw | i wish my afternoons were 11 hours long sometime [sic] | 13:31 |
| 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:33 |
| 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:34 |
| apw | rtg you are insane, truly | 13:37 |
| rtg | apw, well, thats not my track in it :) | 13:37 |
| apw | rtg, gads it actually has a ski track down it, *gibber* | 13:38 |
| 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:39 |
| 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:45 |
| apw | rtg, also the only people with it are you and me; and if we can't cope with that ... shoot us now | 13:46 |
| rtg | apw, isn't the CONFIG_FSL_PAMU=n patch for powerpc ? I ain't got one 'o dose. | 13:47 |
| 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:48 |
| 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:49 |
| 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 | 13:50 |
| 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:27 |
| 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:28 |
| jsalisbury | spideyman, 3.2.0-63.94 | 16:29 |
| spideyman | jsalisbury awesome, thx again | 16:30 |
| infinity | zequence: Everything got respun for a 1-line revert. :/ | 18:42 |
| infinity | zequence: Do you have time to do the quick rebase? | 18:42 |
| zequence | infinity: Ah, sure. np | 19:23 |
| infinity | zequence: You rock. | 19:24 |
| 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:18 |
| BenC | infinity: Yep. We’ve actually been running with that on our system since day 1 | 20:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| infinity | \o/ | 20:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| BenC | s/on your system/on your disk image/ | 20:37 |
| 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:38 |
| 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:39 |
| BenC | It requires you to download them from our public archive | 20:40 |
| BenC | Maybe one day we’ll be that clever :) | 20:40 |
| infinity | BenC: I suspect that would tip closer to "awful" than "clever", but certainly shipping your "firmware" in the archive might be nice. | 20:48 |
| infinity | BenC: Probably moot, though, I imagine your customers can figure it out. | 20:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!