[00:25] <jjohansen> back in a bit
[00:31] <kees> rock.  Yama is in security-testing-2.6#next
[00:35] <ogasawara> kees: nice, congrats!
[00:35] <kees> thanks, now for the next set of crazy patches...
[00:36] <ogasawara> kees: I saw your pull request, will try to get it applied after I upload the 2.6.35-6.9 kernel
[00:37] <kees> ogasawara: cool; no big rush, but I wanted to get it in so the /proc/sys paths can get normalized in other packages for when it does appear (I assume next week due to milestone)
[01:22] <jcrigby> cnd: around?
[01:22] <cnd> jcrigby: yep
[01:22] <cnd> what's up?
[01:22] <jcrigby> I have a dumb question
[01:23] <jcrigby> got assigned to do kernel packaging for linaro some time ago
[01:23] <jcrigby> just started looking into it today
[01:23] <cnd> heh
[01:23] <jcrigby> the dumb question is what crank to a turn to create the debian source pkg from a checked out kernel git tree
[01:24] <cnd> yeah...
[01:24] <jcrigby> I just want to understand how the ubuntu kernel works before tweaking for linaro
[01:24] <cnd> our packaging can seem rather obtuse from the outset :)
[01:24] <cnd> we're trying to document stuff on our wiki
[01:24] <cnd> let me find the right page
[01:24] <jcrigby> I did search the wiki but not much success
[01:25] <jcrigby> I did try do_source_package=true do_full_source=true full_build=true fakeroot ./debian/rules printenv install-source
[01:25] <jcrigby> but that just made the kernel source tarball
[01:26] <cnd> jcrigby: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
[01:26] <jcrigby> ahh
[01:26] <jcrigby> thanks
[01:26] <cnd> oh, do you just need to know how to create the src package?
[01:26] <cnd> that you can upload to a ppa or archive?
[01:27] <cnd> if so, check out: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Preparing an upload
[01:27] <cnd> (note the spaces in the url)
[01:27] <cnd> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Preparing%20an%20upload
[01:27] <jcrigby> thats what I happen to be looking into right now yes
[01:28] <jcrigby> thanks again
[01:32] <cnd> sure
[07:39] <LLStarks> yo
[07:39] <LLStarks> ndiswrapper isn't playing nice with 2.6.35 on ubuntu
[07:39] <LLStarks> dkms loops
[07:41] <LLStarks> ogasawara, apw. you around?
[07:59] <lag> LLStarks: apw is not around
[08:00] <lag> LLStarks: And I would have thought that ogasawara would still be in bed :)
[09:48] <RAOF> Gah!  Go *away* vga16fb!
[09:49] <RAOF> I've got a perfectly cromulent inteldrmfb providing fb0!  Your services are not required!
[09:51] <RAOF> Weren't we going to stop binding vga16fb to everything?  Is that still happening?
[10:06] <smb> RAOF, Depends on how quick the other fb driver is. I got an older system where it unfortunately is not
[10:57] <cooloney> smb: how to compile a -pae kernel. there is no such target in fdr, binary-generic-pae
[10:58] <cooloney> smb: thanks in advance
[10:59] <smb> cooloney, Hm, must admit i have not selectively tried that. But it get produced with binary as a target on i386
[11:00] <smb> cooloney, And the binary-generic-pae works here. Just tried
[11:00] <smb> cooloney, Are you calling it on amd64?
[11:01]  * smb pokes cooloney 
[11:01] <cooloney> oh, it is i386
[11:01] <smb> It is
[11:02] <cooloney> let me try
[11:02] <smb> On 64bit you don't need PAE 
[11:02] <cooloney> $ fdr binary-generic-pae
[11:02] <cooloney> make: *** No rule to make target `binary-generic-pae'.  Stop.
[11:02] <smb> cooloney, uname -m ?
[11:03] <cooloney> oh, need i build it in chroot?
[11:03]  * smb slaps cooloney 
[11:03] <smb> Always
[11:03] <cooloney> smb: my bad. sorry man
[11:03] <smb> No problem :)
[11:04] <cooloney> smb: thanks man, building now. 
[11:05] <smb> cooloney, You are welcome. just never tell me you are not using a chroot to build again. ;-P
[11:07] <cooloney> smb: i remember. hehe, I play cross compiling for a long time
[13:24]  * smb cries over the concept of history in bzr
[13:25] <tgardner> smb, whats the story with the ext4 patchset that bjf proposed last week? Is it gonna make it into pre-proposed anytime soon?
[13:28] <smb> tgardner, Though proposed is about to be moved kees was asking for security and guess what will win
[13:28] <tgardner> smb, hmm, lets work with kees on that. is there a real kitten killer out there?
[13:28] <smb> tgardner, Unfortunately there is the point release sort of soon and I fear time will run out
[13:29] <smb> tgardner, I have not looked at the cves itself yet. They seem medium to low
[13:29] <smb> tgardner, Actually there is another scary series which potentially should go into the point release
[13:30] <tgardner> smb, scary series of CVEs ?
[13:30] <smb> tgardner, I just prepared test kernels that got the writeback patch series (12patches)
[13:30] <smb> tgardner, No not cve
[13:30] <smb> Thats about our long time on sync or unmount
[13:31] <tgardner> smb, ok. then I think you should ask kees about deferring these CVEs until after the point release so we can get some bug fixes in.
[13:32] <smb> tgardner, I try to look at the complexity of the cves. If there is change to release them next week, this would be enough time for another proposed baking
[13:33] <tgardner> smb, I'd sure like to see your writeback and bjf's ext4 fixes get into a pre-proposed kernel soon. it needs some exposure
[13:34] <smb> tgardner, Steve and Brad did some test runs which sounded quite promising (no seen regression, against some fails before)
[13:35] <tgardner> smb, are they running that XFS test suite? I think that is how some of the issues were originally found.
[13:35] <smb> And I hope to get feedback on the writeback stuff from kees and some reporters with the test kernels
[13:35] <smb> tgardner, yes they do
[13:57] <cking> is "relatime" a defaulted mount option with Lucid? 
[13:57] <tgardner> cking, I think you have to specifically turn it off.
[13:58] <cking> tgardner, that came in when? Karmic, Lucid?
[13:58] <tgardner> cking, I just remember seeing it as an install option, but don't remember exactly when. I think its been there since at least Hardy
[13:59] <cooloney> tgardner: sorry for the confusing. i just assume wanna review the patch from TI's tree. -:)
[13:59] <tgardner> cooloney, nope, I want 'em prequalified from you.
[13:59] <cooloney> tgardner: as soon as i got updates from sebjan,  i will pull them into my tree after i reviewed them.
[14:00] <cooloney> tgardner: yeah, understood
[14:02] <bullgard4> What is the filename of the source code file associated with the driver file /lib/modules/2.6.32-22-generic/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko for the loadable kernel module ath5k?
[14:03] <bullgard4> Has ath5ko been compiled from several source code files? 
[14:04] <bullgard4> s/ath5ko/ath5k.ko/
[15:46]  * bjf is off to the dentist
[15:53] <salvarane> hello
[15:55] <ogasawara> LLStarks: I'm guessing you're seeing bug 590090
[15:55] <ubot2> Launchpad bug 590090 in ndiswrapper (Ubuntu) "package ndiswrapper-dkms 1.56-1 failed to install/upgrade: ndiswrapper kernel module failed to build (affects: 8) (dups: 2) (heat: 181)" [Medium,Confirmed] https://launchpad.net/bugs/590090
[15:55] <ogasawara> LLStarks: which is due to the upstream commit:
[15:56] <ogasawara>   commit 22bedad3ce112d5ca1eaf043d4990fa2ed698c87
[15:56] <ogasawara>   Author: Jiri Pirko <jpirko@redhat.com>
[15:56] <ogasawara>   Date: Thu Apr 1 21:22:57 2010 +0000
[15:56] <ogasawara>     net: convert multicast list to list_head
[15:57] <salvarane> I have followed this guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but , in the record "skipabi=true skipmodule=true fakeroot debian/rules binary-core2" I receved this "make: ** Nessuna regola per creare l'obbiettivo <<binary-rtai>>. Arresto "
[15:58] <ogasawara> cnd: ddebs should be trickling in according to pitti
[15:58] <cnd> ogasawara: cool, thanks!
[15:59] <ogasawara> LLStarks: I'm curious as to why you're installing the dkms package for ndiswrapper though, we already roll it in the Ubuntu kernel
[16:02] <salvarane>  hello
[16:03] <salvarane>  I have followed this guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but , in the record "skipabi=true skipmodule=true fakeroot debian/rules binary-core2" I receved this "make: ** Nessuna regola per creare l'obbiettivo <<binary-rtai>>. Arresto "
[16:05] <vanhoof> salvarane: what did you name your flavor
[16:05] <vanhoof> salvarane: did you name it core2 as well?
[16:08] <salvarane> config.flavour.rtai
[16:09] <vanhoof> salvarane: skipabi=true skipmodule=true fakeroot debian/rules binary-rtai
[16:09] <salvarane> not found
[16:09] <salvarane> I change the name for you
[16:09] <salvarane> the real name is skipabi=true skipmodule=true fakeroot debian/rules binary-rtai
[16:10] <vanhoof> salvarane: i followed those instructions this morning, and everything is building happily
[16:10] <vanhoof> salvarane: maybe pastebin everything you did to compare
[16:11] <salvarane> ok
[16:11] <salvarane> I have followed this guide http://wiki.linuxcnc.org/emcinfo.pl?Ubuntu10.04Notes
[16:12] <salvarane> step by step
[16:20] <tgardner> salvarane, that looks basically correct. I would have run 'fdr updateconfigs' after 'fdr editconfigs'
[16:20] <tgardner> there is lots of good stuff at https://wiki.ubuntu.com/Kernel
[16:21] <salvarane> ok
[16:22] <salvarane> I followed the guide http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ but I changed the name core2 into rtai
[16:23] <salvarane> I following your link  https://wiki.ubuntu.com/Kernel thanks
[16:24] <LLStarks> ogasawara, ndiswrapper-common is pulling in the dkms package
[16:26] <ogasawara> who's the maintainer of that dkms package?  I actually didn't even know it existed till yesterday.
[16:27] <salvarane> can I  use kernel vanilia into ubuntu lucid ?
[16:30] <kaushal> hi
[16:32] <kaushal> I am running a Ubuntu generic kernel on all the hosts running 8.04 server. is there a way to install server kernel on this host ?
[16:32] <kaushal> We have found a bug on the automated install 
[16:33] <kaushal> Please suggest/guide
[16:33] <tgardner> kaushal, there should be a meta package called linux-image-server
[16:35] <kaushal> tgardner, ok
[16:36] <kaushal> so if i install it i should be having server kernel ?
[16:36] <tgardner> yep
[16:36] <kaushal> also do i need to reboot it ?
[16:36] <kaushal> i think yes
[16:36] <tgardner> i think yes
[16:37] <kaushal> the issue is that we have this issue on all the 300 production servers
[16:37] <kaushal> is there a easy way to do it ?
[16:38] <tgardner> kaushal, I suggest you consult with your IT guys.
[16:40] <kaushal> tgardner, Thanks
[16:53]  * bjf is back
[17:49] <jjohansen> rebooting
[17:58] <Azoff> Hello folks
[17:59] <Azoff> Just talked to NthDegree in #ubuntu about some strange lockups on one of our servers with raid5 and xfs as the fs.
[18:00] <Azoff> I found a thread on the xfs ML about an race window in the xfs code.
[18:01] <Azoff> From what I can tell, the Ubuntu Lucid kernel source is based on 2.6.32.11 and I think those xfs fixes were introduced in 2.6.32.12
[18:02] <Azoff> atleast there's a hole bunch of xfs commits there.
[18:03] <Azoff> NthDegree told me that there were a PPA for the mainline kernel, however he didn't know if any of the >.11 kerneles were stable enought to give a try.
[18:03] <Azoff> What's you oppinion on this?
[18:04] <Azoff> The only info I could get from the tech on site (server co-located) were this: Kernel Panic - not syncing: xfs_fs_destroy_inode: cannot reclaim 0xdc50efe4
[18:04] <tgardner> Azoff, the kernel in -proposed is based on 2.6.32.14
[18:04] <smb> Azoff, just today a Lucid update went out which brings in ... as tgardner says
[18:04] <Azoff> oki, great!
[18:05] <Azoff> Sorry, I'm kinda unfamiliar with Ubuntu pakages. How does this -propused package get into main tree?
[18:06] <Azoff> Or can I try it without it being in the tree?
[18:06] <smb> Azoff, Proposed is just an archive pocket which you have to opt in
[18:06] <Azoff> ah, I see.
[18:06] <smb> Packages go there before they are moved to the place where you will get them normally
[18:07] <Azoff> how long before it will be moved (approx)?
[18:07] <smb> Aprox -3 hours
[18:07] <smb> IOW it has been done
[18:08] <smb> You should see kernel updates when you check now
[18:08] <tgardner> Azoff,  http://launchpad.net/ubuntu/+source/linux tells you the current status
[18:08] <Azoff> no, I won't :(
[18:10] <Azoff> I guess I have to wait a couple of hours... thanks for your help!
[18:51] <sconklin> http://news.bbc.co.uk/2/hi/technology/10466317.stm Half a million Vaios 'recalled' for overheating - "But Sony said that this is "not a recall" and that the problem can be rectified with a software patch."
[19:00]  * tgardner lunches
[19:22] <kees> ogasawara: I just made a small update to my yama pull-request commits, so if you pulled already I can prepare a separate commit. otherwise, pretend nothing happened, and pull normally whenever you're ready.  :)
[19:22] <ogasawara> kees: I haven't pulled yet, so I'm good
[19:53] <LLStarks> ogasawara,  Julian Andres Klode <jak@debian.org>
[20:16]  * ogasawara lunch
[20:16] <jjohansen> lunch
[22:03] <ogasawara> kees: for the yama pull request, should the following also be reverted?
[22:03] <ogasawara> commit 066cf0cf62729b6107d9b6bda195f4346b1607e7
[22:03] <ogasawara> Author: John Johansen <john.johansen@canonical.com>
[22:03] <ogasawara> Date:   Thu Jun 24 08:12:55 2010 -0700
[22:03] <ogasawara>     UBUNTU: SAUCE: fs: block hardlinks to non-accessible sources AppArmor portio
[22:03] <ogasawara>     
[22:03] <ogasawara>     This is the AppArmor portion of
[22:03] <ogasawara>     commit 069cb89e17c6dc5b2a1de2469746bc42935850fb
[22:03] <ogasawara>     Author: Kees Cook <kees@ubuntu.com>
[22:03] <ogasawara>     Date:   Wed May 12 09:03:08 2010 -0700
[22:03] <ogasawara>     
[22:03] <ogasawara>         UBUNTU: SAUCE: fs: block hardlinks to non-accessible sources
[22:03] <ogasawara>     
[22:03] <ogasawara>     Applied on top of the current upstreaming version of AppArmor
[22:05] <kees> ogasawara: if you're doing the reverts manually, yes.  if you're just pulling from my repo, no.  (I had to handle the "conflict" of that patch already)
[22:05] <ogasawara> kees: ok cool
[22:06] <kees> Yama and AppArmor should only be running into eachother in security/Kconfig and security/Makefile now, but I dealt with that in the first Yama commit.  everything else should be separate.
[22:11] <kees> ogasawara: just to make sure we're on the same page, the top of my tree is 9578dd34c5949d41a1237d2ad080bcf438d963e7
[22:11] <ogasawara> kees: yep, that's what I have
[22:11] <kees> okay, rockin'
[23:17] <kees> ogasawara: do you want me to re-organize my commit messages to include the cherry pick comments, or have you already pulled?
[23:18] <ogasawara> kees: I haven't pulled yet, will probably do it tomorrow
[23:20] <ogasawara> kees: I'm too lazy to build across all archs to get the abi's so I'm just gonna wait till I upload within the hour and then grab the abi's in the morning
[23:21] <kees> ogasawara: okay, so should I re-do all the commit messages to include the cherry pick comment syntax you recommended?
[23:22] <ogasawara> kees: that'd probably be best
[23:22] <ogasawara> kees: just for tracking purposes
[23:26] <kees> ogasawara: okay, I'll do that
[23:38] <kees> ogasawara: since Yama adds a new CONFIG option, how should I record that in the git tree?
[23:40] <ogasawara> kees: usually I just do something like "UBUNTU: [Config] Enable CONFIG_FOO=y" or something similar
[23:45] <kees> ogasawara: if this is good, it'll be waiting for you tomorrow too: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=12c65e02eed1309d24f6288e6bc7914857942af3
[23:45] <ogasawara> kees: yep, looks good
[23:52] <LLStarks> ogasawara, i'm still waiting for juliank to expain the required ndiswrapper dkms package.
[23:52] <LLStarks> it doesn't work on the current maverick kernel
[23:54] <ogasawara> LLStarks: ok thanks, keep me posted
[23:57] <ogasawara> LLStarks: it actually might be preferred to go the dkms route rather than us maintaining it in the kernel
[23:57] <ogasawara> LLStarks: we do the same for the broadcom drivers, ie use DKMS
[23:58] <ogasawara> LLStarks: but that's something I can raise on the kernel-team ml
[23:59] <LLStarks> would the module installation loops be a kernel problem or ndiswrapper problem?