[00:30] <pabelanger> howdy!  I'm looking for any tutorials on having a custom kernel within Launchpad PPA?  Move of the actually packaging, I was hoping to maintain my over version for some embedded hardware
[01:28] <milli> is there any chance of getting commit 68f194e0 pulled into 2.6.32 before rc ?
[01:31] <RAOF> What does it do?  What bug does it fix?
[01:31] <milli> 8 line patch to support isight cameras on latest Macbook Pro's in uvcvideo driver
[01:32] <milli> some cameras report 0x00 in one field, others 0xaa, but both are YUV2 cameras
[01:33] <RAOF> It's still possible to get patches into the kernel; file a bug (and for bonus points, attach a proper kernel-team formatted patch).
[01:34] <milli> RAOF: k, ty
[02:22] <crimsun> pabelanger: the kernel team has decent documentation there; see kernel.ubuntu.com
[04:25] <Sarvatt> smb: are you around by any chance? It looks like we dropped a patch we really need during the 2.6.33 drm merge
[04:25] <Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070
[04:25] <Sarvatt> https://launchpad.net/bugs/535640 all of those are because thats gone in -16, was fixed in -15 when that was added
[04:25] <ubot3> Malone bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] 
[04:29] <Sarvatt> apw told me to bug you while he's on vacation :)
[05:04] <jjohansen> Sarvatt: smb should be on in about 2 hours
[06:04] <mrec> BenC: Hi
[06:04] <mrec> BenC: can you have a look at https://bugs.launchpad.net/ubuntu/+source/tvtime/+bug/544527 please?
[06:04] <ubot3> Malone bug 544527 in tvtime "usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)" [Undecided,Confirmed] 
[06:05] <mrec> I wonder who to contact that this issue will be resolved asap :/
[08:52] <lool> amitk: Hey, I see apw is on leave, do you know who cares for linux-ti-omap in lucid in the mean time?
[08:53] <lool> amitk: First upload built, but was held in NEW (and still is?!), second upload failed to build
[08:53] <lool> (I have the d-i changes to publish netboot images ready and would like to test them  ;-)
[08:54] <amitk> lool: I'm just pushing a fix for the FTBFS
[08:56] <amitk> lool: and I care for omap in lucid
[08:56] <smb> amitk, Oh, when you are around. Can you give your blessings to the changes lool posted?
[09:01] <ogra> lool, first upload didnt boot so there was no point in wasting admin time on it, second one boots and amitk is shaking out bugs found in the testkernel atm
[09:03] <smb> lool, amitk Where does that armel/versatile patchset belong anyways? (which branch?)
[09:03] <amitk> smb: master
[09:04] <smb> amitk, arm patches on master?
[09:04] <amitk> smb: will push the d-i change for netboot (who uses it?) and also include the ubuntu drivers directory for ti-omap for ogra
[09:05] <ogra> amitk, netboot will be our fallback image if everything else goes wrong (its the easiest to create image)
[09:06] <amitk> smb: versatile is all upstream, so we just create a kernel for it out of master
[09:06] <smb> amitk, Ah, ok
[09:07] <amitk> smb: infact, can you handle that patch from Loic? I'll ack it.
[09:07] <amitk> smb: the first one is just a revert I think
[09:07] <smb> amitk, And for the netboot change and whatever else needs to be in ti-omap, please put pull requests on kt ml
[09:08] <smb> amitk, I'll review them as well, then I can pull it in. I just won't immediately upload a kernel on the master
[09:09] <smb> for that I think of kernel-ppa
[09:09] <amitk> smb: ack
[09:14] <lool> (Sorry had to disappear for a while)
[09:14] <lool> amitk: omap maintenance > noted; thanks
[09:15] <lool> smb: I'd love if you could upload whatever amitk pushes to fix the FTBFS so that we can clear new and push at least one d-i image out this week  :-)
[09:15] <smb> lool, I just wait for all things that should go in to be on the mailing-list
[09:15] <lool> smb: As amitk explained, my patches are for master and are just config tweaks; versatile is a single patch on top of mainline IIRC (setting it to armv7 instead of its CPU) and a flavour + config
[09:16] <smb> lool, Just trying to understand #2. Why is that changing config.common.ubuntu ?
[09:16] <lool> smb: The versatile changes are to revert a previous chanve, but it's not a "revert" because the commit with the change updated another config *and* config changes probably are best not reverted but recomputed across configs
[09:17] <lool> the second versatile change is an arm-specific config update because the defconfig value made no sense and was harmful
[09:17] <lool> smb: See my followup: CONFIG_CMDLINE is disabled on x86 because it depends on CMDLINE_BOOL which is unset on x86
[09:17] <lool> (in our config at least)
[09:18] <lool> There's no CMDLINE_BOOL on arm, so CONFIG_CMDLINE is always enabled, but the value made no sense
[09:18] <smb> Hm, ok. Understand. So that never took effect for x86
[09:21] <lool> Yup
[09:29] <ogra> amitk, oh, one think thats essential to get a live image booting on the beagle revC is also compcache, can you make sure thats enabled ? 
[09:29] <ogra> *thing
[09:30] <amitk> ogra: enabled
[09:30] <ogra> merci :)
[09:31]  * ogra is still not sure what to do about the requirement for an omapfb cmdline option
[09:31] <ogra> if anyone has an idea for that, any suggestion is appreciated 
[09:33] <ogra> apparently the drive has no builtin default so the cmdline option is needed ... imho it would be good to have a default like 1024x768 and only use the cmdline option to override so we dont forcefully need an entry all the time
[09:33] <ogra> *driver
[09:33] <ogra> amitk, do you think something like the above would be possible without much hacking ? 
[09:34] <amitk> ogra: will need some thinking, postponing for later... :)
[09:35] <ogra> how late :)
[09:35] <amitk> i need to get you a kernel with aufs first
[09:35] <ogra> (it surely doesnt need to be in the current one)
[09:35] <ogra> but having some sane default for release would rock 
[10:54] <amitk> smb: there have been changes in 2.6.33 that make it hard for aufs to compile anymore.
[10:54] <amitk> basically, we'll need to make some in-kernel symbols non-static
[10:55] <amitk> http://ftp.riken.go.jp/pub/pub/Linux/gentoo/sys-fs/aufs2/files/aufs2-base-33.patch
[10:55] <amitk> ogra: ^^
[10:57] <amitk> This isn't a GPL vs. non-GPL war, but more like upstream fs devel
[10:57] <amitk> I wonder if we should stick to unionfs for ti-omap
[10:58] <smb> amitk, If that works and needs less changes. I guess its late to make quick porting efforts
[10:59] <amitk> smb: the patch or unionfs?
[11:00] <Keybuk> it's a shame that Val's writable overlays patches are going so slowly
[11:01] <smb> amitk, Well the patch to get aufs compiling. Ok, we are not so restricted in what we take into that branch, but as ogra was wanting things fast it seems the most simple and workable solution should be preferred
[11:02] <amitk> smb: AFAIK, unionfs is a drop-in replacement, it just works (TM) by using the kernel cmdline union=unionfs (or something close enough)
[11:03] <amitk> Keybuk: if it isn't ready for the next cycle we might want to go back to unionfs
[11:03] <Keybuk> wasn't there a huge reason we switched away from unionfs in the first place?
[11:04] <amitk> apparently there have been several stability fixes since
[11:04] <amitk> no qualitative opinion though, it is for foundations to decide
[11:05] <smb> amitk, I have not been looking there as much as Andy did but I thought the were some issues why we did not change away from aufs2. Probably the same thinking line as Keybuk. In the end someone else needs to decide what they want / need in there.
[11:31] <JohnFlux> Hey all
[11:32] <JohnFlux> The rt3070sta driver needs a small change to support my hardware
[11:32] <jjohansen> early 2.x line of unionfs was a mess and had all kinds of bugs, that made a last minute revert to unionfs 1.4 necessary (I think this was on hardy)
[11:32] <JohnFlux> how do I get such a change put in?
[11:33] <jjohansen> JohnFlux: send an email with the patch to kernel-team@lists.ubuntu.com
[11:34] <jjohansen> after that the switch to aufs2 was made, aufs stagnated for a while and unionfs has gotten better.  I don't know which is currently best
[11:36] <JohnFlux> jjohansen: thanks
[12:15] <amitk> ogra: so what do you want to do for union?
[12:15] <ogra> i need to do some testing, i think casper still supports union, but its a lot slower than aufs
[12:16] <ogra> and union requires additional hacks to the cmdline 
[12:16] <ogra> to make casper use it
[12:19] <amitk> ogra: I can add the aufs patch for now, so you can get something going, let's discuss it later this week.
[12:19] <ogra> ok
[12:25] <smoser> hey all. could I get someone kernel-team or otherwise capable to take a read of bug 458201 ?
[12:25] <ubot3> Malone bug 458201 in qemu-kvm "kernel stacktrace on volume detach in kvm guest" [Low,Confirmed] https://launchpad.net/bugs/458201
[12:26] <smoser> the final comment there has a dmesg that might mean something.
[12:26] <smoser> (this should probably be moved to kernel, not qemu-kvm, if you agree, then go ahead and do so)
[12:58] <JohnFlux> jjohansen: how do I get the kernel source, include staging, that will be used for lucid?
[13:01] <JohnFlux> jjohansen: is there a git repository?
[13:03] <jjohansen> JohnFlux: https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
[13:15] <rackerhacker> jjohansen: have time for a quick /msg?
[13:16] <jjohansen> rackerhacker: sure
[14:15] <pabelanger> morning
[14:43] <bjf> ##
[14:43] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:43] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:43] <bjf> ##
[15:04] <amitk> smb: Can you have a look at our Makefile and tell me if this line makes sense
[15:04] <amitk> LINUXINCLUDE    += -Iubuntu/include $(if $(KBUILD_SRC),-I$(srctree)/ubuntu/include)
[15:04] <amitk> smb: top-level makefile
[15:06] <smb> amitk, That is the way it is right now, right?
[15:07] <amitk> smb: right
[15:07] <amitk> smb: I'm wondering if the same include is there twice
[15:08] <smb> It seems makeing sense. Well the first is the source and the second is the source in the O= dir
[15:08] <smb> or the other way round
[15:08] <amitk> smb: you're right! I was missing the O= angle
[15:27]  * smb looks for a volunteer for a (I think) well triaged bug with upstream and maybe stable potential. But probably it needs some discussion.
[15:38] <bdmurray> cnd: there is an interesting comment in bug 516772, number 8, that works for me
[15:38] <ubot3> Malone bug 516772 in linux "HP Touchsmart tm2 brightness level not changing" [Low,In progress] https://launchpad.net/bugs/516772
[15:49] <amitk> smb: ti-omap pull request sent to list
[15:49] <smb> amitk, ok, lets see
[16:45] <bjf> ##
[16:45] <bjf> ## Kernel team meeting in 15 minutes
[16:45] <bjf> ##
[16:46] <amitk> smb: got a chance to look at omap?
[16:46] <smb> amitk, Got a chance to read kernel-team mailing list? :)
[16:46]  * amitk doesn't see the reply yet, kicks his cron job
[16:47] <JFo> heh
[16:48] <smb> Funny, usually its the other way round. I see my replies last
[16:49] <amitk> smb: I'll reorder the commits and fix the commit messages
[16:49] <smb> amitk, But basically I would reorder one commit and change the comment on another. Otherwise it seems ok. Hopefully the ubuntu gets dropped on future M rebases
[16:50] <smb> amitk, I can do that just her, if you say ok with me
[16:50] <smb> here I mean
[16:51] <amitk> smb: ok, if you want, I already fixed and pushed it to my tree
[16:51] <amitk> so you can just do a new pull
[16:53] <smb> I can do, but I usually export and import them (to add acks and signed-offs)... *shrug* But I can pull it again 
[16:54] <amitk> smb: do you think you'll be able to do an upload today?
[16:55] <smb> amitk, I will pull that in, then do a quick cross compile test and then upload, so it should be there soon
[16:56] <amitk> smb: Besten Dank!
[16:57] <smb> amitk, Keine Ursache
[16:57]  * ogra hugs smb 
[16:59] <amitk> smb: I suggest a complete build so we catch any other failures
[16:59] <bjf> ##
[16:59] <bjf> ## Meeting starting now
[16:59] <bjf> ##
[17:03] <smb> amitk, btw. Have any of these reported as a bug
[17:03] <smb> ogra, ^
[17:04] <amitk> smb: no
[17:04] <ogra> smb, nope
[17:04] <smb> k
[18:04] <Keybuk> apw: you know how you build efifb into the kernel, but don't build fbcon in, just sayin' ;P
[18:15] <smb> Keybuk, You would need to should loud this week to make him hear you. :)
[18:15] <smb> shout I mean
[18:16] <Keybuk> on holiday is he? despicable!
[18:16] <Keybuk> :p
[18:21] <smb> Keybuk, He is indeed. Trying not to break anything while standing on two waxed pieces of wood
[18:22] <Keybuk> he's doomed
[18:22] <Keybuk> not for the skiing
[18:22] <Keybuk> but he'll say something drunk in the bar after
[18:23] <Keybuk> a husband will object, there will be a fight
[18:23] <smb> Especially in _that_ country. :-P
[18:27] <Keybuk> smb: so, #2, the same question ;-)
[18:27] <smb> Keybuk, Why we don't build it fbcon?
[18:27] <Keybuk> yeah
[18:27] <smb> Because we missed it I'd guess
[18:28] <Keybuk> it's always been a module, obviously
[18:28] <Keybuk> at least on x86
[18:28] <Keybuk> I think we probably do build it in on platforms that have never had VGA
[18:29] <smb> Hm, maybe. And the question would be whether some could have side-effects when built in. Like "stealing" ressources
[18:29] <Keybuk> OTOH, the side-effect of not building it in means that EFI has no console ;-)
[18:29] <Keybuk> at least not until relatively late in the boot when userspace loads it
[18:30] <MTecknology> what's the drm33 kernel for?
[18:30] <smb> MTecknology, Is that in some package name
[18:30] <amitk> Keybuk: should disks be owned by root:root or root:disk?
[18:31] <MTecknology> smb: git version
[18:31] <smb> MTecknology, We have drm from 2.6.33
[18:31] <MTecknology> what's that mean?
[18:32] <smb> MTecknology, That it is a 2.6.32 based kernel with everything in drivers/gpu/drm and include/drm from 2.6.33
[18:32] <Keybuk> amitk: root:disk usually
[18:32] <MTecknology> smb: oh.. thanks
[18:34] <smb> Keybuk, It (fbcon) seems to be loaded on all my systems, too. So it might be worth thinking on that. 
[18:35] <Keybuk> smb: it is loaded by userspace
[18:35] <Keybuk> as I said
[18:35] <MTecknology> smb: I just didn't ever remember seeing a .xx-drmxx.x version on the kernel, maybe just didn't notice it
[18:36] <smb> MTecknology, No that got added recently, so it is clear which versions are in. As we will be picking stable updates from 2.6.32.y and 33.y
[18:37] <smb> Well and the drm backport was just started with -16 iirc
[18:38] <smb> Keybuk, Right, just arguing to myself about any "dangers" of building it in
[18:38] <Keybuk> smb: lucid+1 btw
[18:38] <Keybuk> but vaguely thinking
[18:39] <Keybuk> if we build in fbcon
[18:39] <Keybuk> then we can set the graphics mode in grub to something sensible (ie. last used mode in X)
[18:39] <Keybuk> and tell grub to tell the kernel all about the mode
[18:39] <Keybuk> which makes the kernel use efifb
[18:39] <Keybuk> (fbcon being built in means you have a console straight away, so no "black screen during boot issue")
[18:39] <smb> and hopefully have something in kms that would honor that too
[18:39] <Keybuk> right, nouveau kms got fixed recently to handover properly
[18:40] <Keybuk> intel kms hands over already
[18:40] <Keybuk> so when the real kms driver loads, it hands over the framebuffer and fbcon to them
[18:40] <Keybuk> (and adjusts the mode to a better one if needs be)
[18:40] <Keybuk> then X comes up
[18:40] <Keybuk> ...
[18:40] <Keybuk> this means we always have a framebuffer (yay pretty)
[18:40] <Keybuk> ideally only ever have one mode set (grub)
[18:40] <smb> and locks ... err didn't say that aloud
[18:40] <Keybuk> and the X fallback case is nice too (X falls back to fbdev, no need for VESA)
[18:41] <smb> but yeah. sound like a neat boot 
[18:42]  * smb still looks at the five star steady screen
[18:43] <smb> Keybuk, Btw, when I look at that with ftrace it seems both plymouth and X do more grabs than release.
[18:44] <Keybuk> heh
[20:33] <Sarvatt> smb: sorry to bug you but did you get my message earlier about the patch that got lost with the drm merge?
[20:35] <Sarvatt> we're getting a huge number of bug reports on intel that are all because that commit was dropped in 2.6.32-16
 [00:26:28] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070
 [00:27:06] https://launchpad.net/bugs/535640 all of those are because thats gone in -16, was fixed in -15 when that was added
[20:35] <ubot3> Malone bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] 
[21:49] <ali1234> does the karmic default kernel have kgdb enabled?