[07:07] Hi guys [07:09] If I compile a kernel with make uImage, how to flash the new kernel image to the boot partition? What do I need? I see that I must copy vmlinux and generate initrd? How to generate initrd. Thanks === smb` is now known as smb [07:56] fairuz: you can't flash it [07:56] fairuz: you have to do eveyrhing by hand [07:56] fairuz: and besides, you need a couple of specific options to make your vanilla kernel work with an ubuntu userland [07:56] fairuz: hold on [07:56] ppisati: my mistake, What I mean by flashing is to copy the vmlinux to /boot partition [07:57] fairuz: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile [07:57] fairuz: FAQ point 6 [07:57] fairuz: How do i compile a vanilla/upstream arm kernel that works with an Ubuntu userspace? [07:57] fairuz: should help you [07:57] Oh [07:57] I already take a look at that [07:58] So how about initrd and config? We can use the old one? [07:58] fairuz: yes, old one [07:58] fairuz: actually you don't actually need initrd [07:58] fairuz: you don't need to use it [07:58] But I think the one in the /boot is vmlinux, and in the wiki it says to copy uImage. Is that Ok? [07:58] fairuz: but since i overwrite uImage with my own, it'll use the ubuntu one [07:58] So I just re-point the vmlinux to the new uImage? [07:59] fairuz: no no [07:59] fairuz: it doesn't mention /boot [07:59] fairuz: it says [07:59] fairuz: "copy arch/arm/boot/uImage to the sd card first partition overwriting ubuntu stock uImage" [07:59] fairuz: on arm you really don't care what you have in /boot during boot [07:59] Oh. I thought /boot is the boot partition [07:59] fairuz: well, at leat on our omap boards [07:59] Which normally means the first partition [08:00] *least [08:00] fairuz: which board are you using? [08:00] OMAP :) [08:00] * ppisati thinks i should better describe the boot process [08:00] fairuz: beagle? panda? [08:00] panda [08:01] fairuz: ok, then copy uImage to the first partition of your sd card and you are done [08:01] fairuz: actually, if you do a lot of development [08:01] fairuz: try a lot of different kernels etcetc [08:01] fairuz: you should better modify boot.scr or preEnv.txt to boot an alternate uImage [08:02] fairuz: when the board reboot stop at the boot loader prompt [08:02] fairuz: and tell it to use tour alternate boot.scr/preEnv.txt [08:02] fairuz: this way if your new kernel is borked [08:02] Oh ok. Sounds like what I do with u-boot + Android kernel [08:02] fairuz: you just boot with the original boot.scr/preEnv.txt and original uImage [08:02] fairuz: but this is left as an exxrcise to the reader :) [08:02] So just wondering if Ubuntu have additional work for new kernels [08:03] * ppisati will probably describe that too next time [08:03] So it is easy! [08:03] :) [08:03] Thanks ppisati! [08:04] My problem is that I thought /boot is the first partition. [08:04] fairuz: nope, it's not [08:04] fairuz: w just install the kernel there [08:04] fairuz: and flash-kernel pick it up from there to create the uImage [08:05] fairuz: and copy it to the vfat partition at the beginning of the sd card [08:05] Ohh [08:05] fairuz: but after that, /boot is totally useless during the real boot [08:05] it make sense now [08:05] since uImage is a stripped version of vmlinux right? [08:05] not stripped, mangled [08:06] actually it has only 64bytes more than a normal vmlinuz IIRC [08:06] What does mangled means? [08:06] it has an header at the beginning [08:06] It's bigger? [08:07] ok === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix === doko_ is now known as doko [09:34] brendand: hi! do you have any news on bug #1063856? [09:34] Launchpad bug 1063856 in linux "[Dell Studio XPS 13] X in failsafe mode after boot" [Undecided,Confirmed] https://launchpad.net/bugs/1063856 [09:35] henrix, no. the lab is in montreal [09:36] brendand: yeah, but i thought that today you would be able to reboot the box with currently released kernel [09:37] henrix - the problem is i only have ssh access. i tried to reboot the system but it has not come back up. i'll need to get in touch with the engineer in montreal [09:38] brendand: ah, right. :) [09:38] brendand: please let me know when you're able to do that. [10:45] crap, they just cancelled my return flight from barcrelona [10:45] ... [11:40] ppisati, heh was that with lufthansa or something? [11:40] ppisati, this omap3 set for Q, what is the symptoms if we don't apply it for trying to do an install; it is sounding like boot failures? [11:48] bjf, henrix, this is special -- linux-lts-backport-oneiric has released to -updates before its linux in oneiric, and the latter is where we do all the testing no ? [11:49] apw: i believe they are both tested [11:49] apw: at least both tracking bugs have the testing tasks [11:50] henrix, ok that good then [12:00] apw: they sais AZ something, now i've two options: either i'm rerouted around or i take a direct at 20:00 in the evening [12:00] ufff [12:01] direct always sounds better, you may as well sit in a coffee shop beforehand [12:02] yeah [12:02] apw: the bug is not a fatal for boot, but the board is a bit useless later on [12:03] apw: since without usb you loose nic, and every i/o options except for the serial console [12:04] ppisati, suspected as much, ok so its pretty important for release [12:05] apw: well, no one really used that hw since at least July so if we defer it i'm not against it [12:07] ppisati, gotcha [12:11] * henrix -> food [12:16] apw, you gonna fix the bugs in '[PATCH 1/4] efi: Add support for a UEFI variable filesystem' pointed out by Tetsuo ? [12:17] brb [12:30] rtg, looking at them indeed, what a piece of crap code [12:32] apw, :) [12:40] rtg, those seems to be the tip of the iceburg too [12:40] * apw hates efi [12:41] * rtg hates the enforcer syntax. [12:41] rtg, does not supprise me, it does hard things, so it is hard to understand [12:42] apw, ppisati's patch is wrong, but I can't figure out the right syntax. I want something like 'flavour omap & !exists CONFIG_USB_EHCI_HCD_PLATFORM', don't I ? [12:43] ok so this is only on armh and omap [12:45] apw, omap is built for both armel and armhf [12:45] its mean to say just arm there [12:45] apw, But I don't want this rule enforced for all arm flavours, only omap [12:46] indeed , and you only want it if you have the other variabled [12:46] ppisati, which variables are the ones which exist on omap only [12:48] rtg, as in yes you are right it is too liberal [12:49] apw, I'm just gonna NAK the enforcer patch and make him figure it out. [12:49] ack [12:54] rtg, waht i want to say for that enforcer rule is: ((flavour omap &/ value CONFIG_USB_EHCI_HCD_PLATFORM n & value CONFIG_USB_OHCI_HCD_PLATFORM n) | true) [12:54] rtg, but we don't have a true [12:56] back in a bit [13:03] rtg, ppisati, i have replied with a tested snippet [13:03] apw: i'll take a look [13:04] apw, that is a frustratingly obtuse syntax [13:05] rtg, i challenge you to maintain the flexibility and complexity of the rules, and simplify the syntax [13:05] yeah, right. I'll get right on that. [13:05] rtg, i cannot deny you need to be stone cold sober, and have your glasses on, to have a hope of understanding it [13:06] or be well coffeed [13:06] that can nonly help [13:06] i generate mine by testing using genconfigs, its the only way to be sure [13:07] apw, what does '&/' mean ? [13:08] that is & /, and means and primarily, but means if you fail after this, fail everything [13:08] this allows us to say [13:08] (arch armel &/ value FOO 10) | value FOO 20 [13:08] and it mean what you think it means [13:08] ie it does not allow FOO == 20 on armel [13:09] it literally means if you succeed arch armel, then wahtver follows is the result don't try any other paths [13:09] it is known as the cut operator, cutting the search short [13:22] printk("VFS: Busy inodes after unmount of %s. " [13:22] "Self-destruct in 5 seconds. Have a nice day...\n", [13:22] quality error messages === henrix_ is now known as henrix [13:27] rtg, apw, have you guys seen probs with intel wifi not coming back after suspend? This only happens to me when I let the battery run down and it puts itself to sleep. Upon resume no wifi, lspci shows it, but the commandline tools nor NM will see it [13:27] Intel Corporation Centrino Advanced-N 6205 (rev 34) [13:28] pgraner, I've had more problems with DNS resolution not working, but wifi is definitely connected. [13:30] rtg, happens everytime without fail [13:30] pgraner, so normal suspend when the battery is good works OK ? [13:31] rtg, yep, if I suspend from either the indication or by using pm-suspend, wait a few hit the pwer button it works. [13:31] pgraner, I wonder if you lose the EC when it suspends for lack of battery [13:32] pgraner, doesn't user space do a hibernate when the battery dies ? [13:32] rtg, If I let is just sit and have the battery run down it goes to sleep and when I go to wake it up... no wifi, just a blank signal indicator [13:33] rtg, in the "power" prefs, I have "when critically low do" and the drop down is blank [13:33] so I'm not sure what its doing [13:33] neither am I [13:39] pgraner, I assume you are resuming _after_ plugging in the power ? Is there anything in dmesg that indicates wifi hates you ? [13:40] rtg, not that I can see [13:40] pgraner, have you tried rfkill on off cycle [13:40] and have you looked to see if rfkill the command says anything is off ? [13:40] yeah, this feels kind of BIOS like... [13:41] apw, yes and no joy [13:43] apw, no I haven't queried rfkill but I will let me get the box into that state [13:45] ok [13:47] I guess r will use kernel 3.8, right? Seems to line up well with the release? [13:51] diwic: I suspect so, although haven't given it a whole lot of thought yet [13:51] diwic: it does seem to line up nicely, ie likely to come out beginning of march [13:52] ogasawara, thanks [13:52] smb, rtg, ok that linux-meta update got rejected, depending on an transitional package; i will fix === ayan is now known as ayn [13:53] apw, Hm ok... do you then have to depend on both amd64 and the i386 version? [13:54] yeah [13:55] Oh well... :/ Not sure why those need the architecture in the name while grub-pc does not === ayn is now known as ayan [15:02] smb: Ping [15:03] jgriffith, yep? [15:03] smb: Hey ya.. just saw your note [15:03] smb: Yeah, I'd be happy to go through devstack setup with you [15:04] smb: It's pretty straightforward, using virtualbox and a clean 12.04 server install [15:04] jdstrand, I guess what I meant is, is it easy enough to write down in the bug report. Then I also have a place to go back whenever I need my memory refreshed. ;) [15:04] err jgriffith ^ [15:05] smb: Sure, I'll just reference the devstack page probably [15:05] smb: Then mabye a modified script you can loop through [15:05] smb: I'll update it on the bug report [15:05] jgriffith, Sure, sounds good. Anything that saves me the time to dig out things on my own is highly appreciated. :) [15:06] smb: Cool, I'll get it update this morning. Thanks!!! [15:07] jgriffith, Thank you. I hope this will help into getting it reproduced in a way that allows to research it better [15:07] smb: That makes two of us :) [15:08] smb: I really appreciate the effort on this, I know it's a pain to try and repro [15:09] jgriffith, It makes it hard to find out what is wrong when it fails to be wrong on testing. And neither it is very verbose on failing. [15:10] smb: Yeah, even worse when I finally got in the state where it failed consistently it locked the system up so I couldn't get ANY info :( [15:10] Right [15:17] caribou, Are you aware that the crash version in Quantal does not work on a Quantal crashdump? (cannot resolve xtime) Or is that an OPP? [15:18] smb: I thought I had tested it, lemme check [15:19] caribou, I sort of just did (with an updated 64bit machine). So at least on the good news side the crashdump side does work. ;) [15:19] smb: which version of crash did you use ? Quantal has 5.1.6, Debian/Sid has 6.0.6 and upstream is now at 6.1.0 [15:20] smb: I never use our own package, it fails most of the time. I install Sid's version [15:20] caribou, 5.1.6 of course (which is what we ship) [15:20] caribou, You know that dog food thing, do you? :) [15:21] smb: sure does, which is why I'm starting to wonder how I could participate in having a more recent version for us too [15:23] caribou, I guess in the same manner I would have to. Find out who sponsored it last time and coordinate a merge from debian at least... It is sometimes a bit annoying because you have everything prepared and then review takes ages and by that time Debian is on the next version... [15:24] caribou, I mainly asked you right now because I was assuming you might have some relations there already as you were with kdump and that seems all going into the same direction [15:25] smb: I thought there was an 'automagic' import from Sid. [15:25] smb: at least this is what happened for makedumpfile in Quantal that has the version that I packaged (1.4.4) [15:26] smb: but maybe this is because crash is in Universe [15:26] caribou, It seems only if it is really simple. Probably we find it on the list of "those are hard) [15:26] smb: I'll look into this. that would facilitate my work [15:27] smb: I'll create a bug for this [15:28] caribou, I use it a lot too, but I am not sure I would have the time. Thanks, could you subscribe me to it? Then I keep track [15:29] smb: should I assign it to myself ? [15:30] caribou, If you say you want to do work on it, I would say yes [15:32] caribou, btw, there is a section on the merge-o-matic https://merges.ubuntu.com/main.html [15:32] smb: well, everytime I open a bug, it seems to fade into oblivion so I'm having doubts [15:34] caribou, Yeah, that seems to be the fate for the request I made for it (bug 1054200) [15:34] Launchpad bug 1054200 in crash "Pick some upstream patches for Xen" [Wishlist,New] https://launchpad.net/bugs/1054200 [15:35] smb: there is current discussion about Xen/crash on the ML currently [15:36] caribou, Daniel Kieper had submitted some updates which sounded like going into 6.0.9 upstream. At that time I was not aware of the quantal problem [15:36] smb: yeah, they're the ones I'm talking about [15:37] smb: gotta step out for a few minutes, biab [15:37] caribou, Yeah, I just picked them and applied them to our current version. They are not needed if moving to the upstream version, but we normally only go for what is in Debian [15:38] So when only merging for Debian they would be still useful. [15:43] smb: Haha... testing a script I wrote for you to run on this and it hit the problem and hung my system [15:45] jgriffith, Sounds quite successful then :D [15:45] smb: We can only hope :) [15:46] * ppisati goes out for a bit [15:50] smb: Ok, updated https://bugs.launchpad.net/cinder/+bug/1023755 with the info [15:50] Ubuntu bug 1023755 in linux "Precise kernel locks up while dd to /dev/mapper files > 1Gb (was: Unable to delete volume)" [Undecided,Confirmed] [15:50] smb: Let me know if you run into any glitches (other than the one we want [15:51] jgriffith, Sure. Thanks. I will give it a try later (or at least tomorrow morning) [15:52] smb: cool [15:55] I, we are having a problem where we can accidentally DoS a Precise kernel. zcatting a large file (a precise image is good) into /tmp is enough to completely block any mysql or postgres writes for several minutes. We see (e.g.) "INFO: task mysqld:1358 blocked for more than 120 seconds." in the kernel logs. We have even got write DMA error messages and system hangs. This is reproducible on 2 different type of hardware.This is on kernel [15:55] 3.2.9-29-generic. Any ideas what this might be before I go and stick it in lanchpad etc.? I suspect it's a local DoS opportunity at the very least. [15:57] we think zcat to something on disk kills it, but zcat to /dev/null doesn't kill it. Looks like writes starving reads horribly or something. [15:58] And you can do this as an unprivilged user (essentially hang any daemon on the system). A single mysql 'UPDATE' call will hang for the duration of the zcat. Postgres is the same. [15:59] This did not happen on (e.g.) Natty-backports kernel under Lucid. [16:02] alexbligh, what is your ioscheduler on that system? we have seem similar issues on servers using cfq on quantal, which led us to change the elevator there [16:03] apw, it's whatever the default is. Let me check. [16:04] i would think for your use case deadline would be more approprate regardless [16:05] CONFIG_IOSCHED_NOOP=y [16:05] CONFIG_IOSCHED_DEADLINE=y [16:05] CONFIG_IOSCHED_CFQ=y [16:05] CONFIG_CFQ_GROUP_IOSCHED=y [16:05] alexbligh, yeah ask the system which one it is using [16:05] (remind me how I tell what one is actualy running) [16:05] cat /sys/block/sda/queue/scheduler [16:05] root@extility-qa-test:~# cat /sys/block/sda/queue/scheduler [16:05] noop deadline [cfq] [16:06] * apw comes back with the same paste [16:06] :-) [16:06] alexbligh, do try switching it to deadline, and see if it is reproducible any more [16:06] you can echo into that same file [16:07] just testing now. [16:07] alexbligh, when you say you are getting dma errors, is that from VMs hosted on the machine with cfq as its filesystem? [16:08] as its elevator? [16:08] apw, scheduler change makes things much better. [16:08] apw, no this is nothing to do with VMs [16:08] no VMs at all [16:08] control plane machine, running just database, and the occasional zcat [16:09] DMA errors do not seem to be something that a scheduler change could cause or not cause [16:09] apw, that's what I thought, which is why they went to change the hard disk, and then replicated on other systems. [16:09] Let me find you the exact error [16:09] but cirtianly we have seem some cases of writes starving reads with cfq [16:10] Oct 9 09:10:26 extility-qa-test kernel: [69443.840122] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [16:10] Oct 9 09:10:26 extility-qa-test kernel: [69443.840243] ata3.00: failed command: WRITE DMA EXT [16:10] Oct 9 09:10:26 extility-qa-test kernel: [69443.840337] ata3.00: cmd 35/00:00:00:20:d4/00:04:0b:00:00/e0 tag 0 dma 524288 out [16:10] which is contrary to its name [16:10] And then the next time, kernel panic with: [16:10] sd 2: 0: 0 : 0 [sda] Unhandled error code [16:10] Result Host byte=DID_BAD_TARGET driverbyte=DRIVE_OK [16:10] so t [16:10] so those, don't seem likely to be elevator indeed [16:12] apw, actually we've just got it to do the same on the deadline scheduler. Seems to be less bad. [16:12] alexbligh, i would expect deadline to eliminate the 120s delay hangs, but the other stuff i'd expect to be real [16:12] (the same is completely starving mysql so a single update takes an infinite amount of time) [16:13] well if you have lost an IO like that, i'd assume all bets are off on it ever continuing [16:13] it's been rebooted and reinstalled from scratch since then! [16:14] apparently only one of the hardware platforms is producing the write dma errors (multiple times, multiple installs from CD). [16:14] both are showing the 120 second hangs [16:14] ok, then i'd be suspicious of real h/w issues with the DMA error [16:14] The h/w platform that does NOT produce any write DMA errors is the one I'm playing with [16:14] that produces hangs on both deadline and cfq. [16:15] the 120s hangs, did we say deadline eliminated, or only helped with those [16:15] I agree I am sceptical about the platform reporting write errors. [16:15] apw, helps, but does not eliminate. [16:15] local DoS still very possible. [16:15] how much memory has this node, and have you tuned your dirty memory on it? [16:16] apw, 8G RAM. We've done no tuning bar whatever Precise does on a default install [16:17] alexbligh, i would be suspicious your dirty ratio is too high, be worth checking [16:17] as that job is emitting dirty memory at a huge rate and presumably hammering the disk into the ground [16:17] you mean /proc/sys/vm/dirty_ratio [16:17] that or its brother yes [16:18] root@extility-qa-test:~# cat /proc/sys/vm/dirty_ratio [16:18] 20 [16:18] with deadline scheduler running any mysql command takes about 11 seconds, rather than hanging indefinitely. [16:18] root@extility-qa-test:~# cat /proc/sys/vm/dirty_background_ratio [16:18] 10 [16:19] which is pretty much what i would expect with such a huge write load on the disks [16:20] if i am remembering right this is 20% of RAM, so 20% of 8G which essentially can be fulled and then dumped as a group when the next sync hits [16:20] onto the disk queue all at once, probabally that is rather high [16:20] Well the image(s) we pull down are 20G or more. [16:20] So it's always going to fill x% of RAM for any value of X. [16:21] right, so your machine will let you fill 20% of ram before it'll really start doing anything about it, then it will drop the lot on the disk and say "hey deal with this" [16:21] alexbligh, yes, but the point is the cuplprit doesn't get penalised until it hits the 20% of ram mark [16:22] it won't stop till then, after then it becomes synchronous wrt its own backlog [16:22] and cannot make things any worse, but things may be tooo bad by then [16:22] it is normal to tune dirty ratio to your workload, amongst other things [16:22] apw, so I should make them lower? That doesn't make a huge amount of sense as even when zcat has been running for many minutes (and presumably passed this threshold) it's still causing problems. [16:23] no it is only synchronous when there is more than 20% outstanding in your scenario, which is what [16:23] My confusion is that we don't hit this issue on Lucid AT ALL. EVER. with exactly the same values. [16:24] using cfq! [16:24] so it is either broken, or possibly, more efficient such as we can get into these scenarios [16:24] (hardware guys report since they've changed the hard disks out they can't get the DMA error thing so I think that's a bogon). [16:24] but i would also check the dirty ratio on the lucid box, to see if the default is the same ther [16:25] Have done. It is. [16:25] ok so with this kind of write load, what is the average mqsql latency doing the same requests [16:26] It's 3.0.0-15-server #26~lucid1-Ubuntu on the Lucid box, which is I think natty-backports. [16:26] thats and oneiric kernel isn't it? [16:26] With cfq, over 120 seconds for any query. With deadline, between 0 and 11. [16:27] yeah it might be oneiric-backports, sorry. [16:27] ok, and on lucid [16:27] which is likely deadline isn't it ? [16:27] the default used to differ for server kernels [16:27] Let me start again. Everything is CFQ, 20 and 10 in the vm dirty_ things [16:28] so lucid is not a server kernel then [16:28] With lucid OS running Oneiric backports kernel, we have only tested CFQ and we get less than a second latency [16:28] oh i see, its L + O kernel, against P with P kernel [16:28] With Precise OS running the default kernel, we havve tested CFQ and get >120 seconds, and Deadline and get between 0 and 11 seconds. [16:28] Yeah - we moved to O-backports for better h/w compatibility. [16:29] arges, are you on gomeisa ? [16:29] rtg, yes [16:30] Oneiric kernel (working one) is linux-image-3.0.0-15-server 3.0.0-15.26~lucid1 (I suspect -26 works fine and just no one has rebooted the box I'm looking at) [16:31] alexbligh, that sounds bust indeed. i guess we need a bug, and someti [16:31] something we can run to repro it [16:31] Precise is: [16:31] ii linux-image-3.2.0-29-generic 3.2.0-29.46 Linux kernel image for version 3.2.0 on 64 bit x86 SMP [16:31] though I am now wondering why that's not -server (we are just cutting over to Precise). [16:32] OK will put a bug in LP [16:32] Is -server much different scheduler wise? [16:33] -server is an alias for -generic in P [16:33] apw, well it's not that then! [16:34] henrix, i got to reboot with the older kernel and the xorg failsafe log wasn't there [16:34] henrix, then i reinstalled the -proposed kernel and it's also not created [16:34] henrix, trying another test run to reproduce it [16:35] brendand: hmm... so it was some sort of transient thing [16:35] brendand: thanks for the update [16:35] henrix - maybe. let's see if the next test run is clean [16:36] brendand: maybe you can take a look at the /var/log/apt logs, to see if some error occurred during installation. [16:36] * henrix is not sure if these logs are wiped during testing [16:37] ** [16:37] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:37] ** [16:45] apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064521 [16:45] alexbligh: Error: bug 1064521 not found [16:45] I marked it as a security vulnerability because TBH it is I think. [16:45] Which means ubot2 can't find it. [16:45] Was that the right thing to do? [16:49] someone will get it to us when they have reviewed it [16:50] apw, thamks [17:06] * ppisati -> EOD [17:25] I've made bug 1064521 public, since it got described here anyway [17:25] Launchpad bug 1064521 in linux "Kernel I/O scheduling writes starving reads, local DoS" [Undecided,New] https://launchpad.net/bugs/1064521 [17:26] rtg: I probably missed the memo, are the arm chroots for gomeisa being rebuilt? === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 16th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:41] ogasawara, hmm, lemme check. [17:43] ogasawara, they do appear to be missing. perhaps I wrecked them when I was experimenting with the android chroot [17:45] apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064521 [17:45] Ubuntu bug 1064521 in linux "Kernel I/O scheduling writes starving reads, local DoS" [Undecided,New] [17:52] ogasawara, rebuilding chroots on gomeisa. you're happier abusing tangerine anyways. [17:52] * rtg_ -> lunch [18:00] * smb -> EOD [18:36] Does the Ubuntu Kernel PPA also contain source packages? I can't find the linux-source package here http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.7-precise/. Is it somewhere else? [18:36] kkaaj, its built from one of the branches in git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git [18:38] rtg, and only the three patches from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.7-precise/ are applied? [18:38] kkaaj, yep [18:39] Oh, 0001-base-packaging.patch is 7.6M big. :-) [18:40] kkaaj, its all debian packaging [18:40] How big is a clone of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git? [18:41] Or maybe I can directly use https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.3.7.tar.bz2 with the patches from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.7-precise/? [18:41] kkaaj, likely [18:41] rtg, I will try that. Thank you! [18:41] rtg@salmon:~/linux$ du -sh linux-stable/ [18:41] 682M linux-stable/ [18:43] Will precise get a 3.3 kernel? Or will it stick with 3.2? [18:54] kkaaj, there will be an LTS kernel for Precise that is a backported 3.7. You can get linux-lts-quantal from https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport === henrix is now known as henrix_ [19:08] ogasawara, are you happy with Ubuntu-3.5.0-17.28 ? I'm about to fire it up to the LTS PPA. [19:08] rtg: yep, pushed to master and uploaded. still need to rebase master-next. [19:08] ogasawara, ack [19:08] rtg: we've had a request to get ti-omap4 and armadaxp rebased to it as well. [19:09] rtg: I figure we can get ti-omap4 rebased, but might need to nudge ike about armadaxp [19:09] ogasawara, you wanna do ti-omap4 ? I have a guest showing up soon. [19:09] rtg: yep, I can do that [19:10] ogasawara, thanks [19:12] ogasawara, gomeisa arm chroots look like they are back in business. [19:12] rtg: ack, thanks. === rtg is now known as rtg-afk === rtg-afk is now known as rtg [20:34] ogasawara, lowlatency is done and up [20:34] ogasawara, linux-signed is in [20:34] apw: ack, thanks [20:35] still building ti-omap4. [20:35] that is a giant rebase. [21:06] * rtg -> EOD [21:36] ogasawara, about? [21:36] bjf: yep, what's up [21:36] ogasawara, can you mumble? [21:36] bjf: just a sec [22:46] I can haz linux-meta-ti-omap4 to go with that linux-ti-omap4 in proposed? [22:46] ogasawara: ^ [22:49] ogasawara, rtg, apw: can you commit to start r with 3.6 headers? [22:51] infinity: yep, prepping it now and will upload [22:51] ogasawara: Less than three. [22:52] doko: our ubuntu-r repo is already based on 3.6, so we should be able to commit to that. I'll discuss with rt and apw tomorrow so we're all on the same page. [22:57] infinity: uploaded [22:57] ogasawara: Danke. [22:59] doko: oops, I misspoke, our ubuntu-r repo is rebased to v3.7-rc1 already. so you'd prefer if we start with an initial v3.6 upload rather than v3.7 based? [23:09] ogasawara, no, that fine [23:10] doko: ok great