[01:25] <zeroprog> hey guys i keep getting invalid module format and ive recompiled the kernel...turned loadable module support on...downloaded a new kernel and tried the same thing but nothing works
[01:25] <zeroprog> the module is in .ko format
[01:30] <lifeless> zeroprog: is it for the same arch?
[01:36] <mjg59> You'll get "invalid module format" if it's built for a different kernel version or configuration
[01:36] <mjg59> Check dmesg for the actual error
[01:42] <zeroprog> hello: disagrees about version of symbol struct_module
[01:43] <zeroprog> and my kernel v is 2.6.28-11 and the kernel source is 2.6.28
[04:32] <TheMuso> C
[07:10] <zeroprog> alright on kernel.org they dont have 2.6.28.11 so what linux source can i use 
[08:08] <apw> Keybuk, i had a conversation with the vfs union mount peeps last night and they sent me a rebase to 2.6.30 with a couple of race fixes, so i've make you a new kernel (again): https://edge.launchpad.net/~apw/+archive/green
[09:20] <apw> cking, you had a machine (a dell i think) which had a problem with halt and reboot which only exhibited itself when splash was enabled but i think turned out to be like reboot=b was required and we added a quirk, can you remember?
[09:21] <cking> apw, reboot=b forced it to work OK. Not sure about the quirk being added for the Dell Inspiron 6400 though. I cannot recall that (too much water under the bridge, or old age :-)
[09:22] <apw> your memory matches mine
[09:33] <haitao0826> 请教大家个问题，编译内核之前要怎么配置才能在编译时把不需要的东西排除
[09:34] <haitao0826> 怎么没人说话阿？
[09:37] <amitk> haitao0826: The language of this IRC channel is English. I'm afraid most people here don't read Japanese.
[09:38] <haitao0826> ok,sorry
[09:38] <haitao0826> bey
[09:38] <smb> amitk, Its chinese 
[09:38] <apw> google says it says "Question to ask you, how to compile the kernel before the compile-time configuration in order to rule out things that do not need no one how to speak Albanian?"
[09:41] <_ruben> all i saw was a bunch of ?'s ;)
[09:43] <smb> _ruben, Iterestingly we saw the chinese letters, but the translation is still a bit weird :)
[09:44] <_ruben> true ;)
[09:49] <amitk> smb: oh well. I thought 'tao' was more Japanese. I need to figure out how to tell Chinese, Korean and Japanese apart
[09:50] <ikepanhc> eh, just someone speak in chinese?
[09:52] <cooloney> apw, you are close
[09:52] <apw> cooloney, google was close :)
[09:54] <amitk> apw: its quite compact (chinese) to encode all that information in such few 'characters'
[09:55] <apw> yeah its very compact thats for sure
[09:58] <xivulon> apw hi, would you have some time to investigate a swapon freeze during ubuntu install?
[09:58] <xivulon> this happens when a swpa file is created and used within a fat fs
[09:58] <apw> that sounds like a bad idea :)
[09:58] <apw> (putting swap in fat)
[09:59] <apw> do you get any panic output?
[09:59] <xivulon> the alternative is swap at all
[09:59] <xivulon> davmor2 has set up a machine with ssh access
[09:59] <xivulon> one sec
[10:07] <apw> xivulon, ok, so this swap file is it directly on the fat, or inside your ext4 loopback into a file crack ?
[10:09] <apw> xivulon, is there a bug filed for this one?  so i have somewhere to record stuff?
[10:11] <xivulon> directly on fat
[10:11] <xivulon> I guess 376120 is the same issue
[10:11] <xivulon> the file is in /host/ubuntu/disks/swap.disk 
[10:11] <xivulon> where /host is the fat partition
[10:12] <xivulon> davmor2 should provide you with instructions to ssh in
[10:13] <apw> thaks
[10:13] <apw> thanks
[10:14] <xivulon> there should be a swapon and a couple of mkswap processes (from tests I assume) that cannot be killed 
[10:23] <apw> xivulon, yeah i think i know waht this might be
[10:23] <apw> are we sure this bug# 376120 is the same bug or should i make a new one
[10:24] <apw> and get that one dupped against it should it be the same cause, its not clear from the bug
[10:26] <xivulon> apw I think it is the same bug, but feel free to open a new one with a more explicit title
[10:27] <apw> thats ok, if you are pretty sure then i am happy
[10:28] <apw> xivulon, if i get you a fixed kernel are you able to test it ?
[10:32] <davmor2> apw: check with xivulon, but as far as I am aware wubi on windows side creates the drives and imports the cd image and then runs an automated install against that image on first run.
[10:33] <davmor2> if it's a case of following instructions in this current environment I can test it.  But only use little words :D   I'm going to be away for a couple of hours so it would need to be after that, if that is okay
[10:34] <apw> davmor2, i suspect it is complex as we need to replace the kernel somewhere in here, i'll let xivulon talk to that
[10:36] <davmor2> apw: np's
[10:42] <apw> xivulon, ?
[10:50] <xivulon> hi apw
[10:51] <apw> xivulon, hi ... i am building you some test kernels with what i believe is the fix for the issue applied
[10:51] <apw> will let you know when they are built and pushed, and will update the bug also
[10:51] <xivulon> apw thanks a lot
[10:51] <apw> i am assuming you will be able to wave your hands over them and see if they fix things
[10:52] <xivulon> hmm deployment would be complex though, as it will have no effect unless a new ISO is shipped
[10:52] <xivulon> although users could replace the kernel inside of windows before rebooting
[10:52] <apw> yeah indeed.  but i am hoping you can at least frig it into a test install
[10:52] <apw> to at least confirm this is the right fix
[10:53] <apw> then we can make up some way to handle that
[10:53] <xivulon> no module/initrd are involved correct?
[10:54] <xivulon> hmm actually they are I guess
[10:54] <apw> its actually the fat module which is updated, so yes
[10:54] <xivulon> well vmlinuz/initrd is still ok
[10:55] <apw> you build initrds on the machine normally
[10:55] <xivulon> users can simply drop them into a directory, easy enough
[10:56] <apw> as in the installation of an updated kernel image builds an initrd them
[10:56] <apw> then
[10:56] <xivulon> the initrd must be a live CD one (with casper and lupin-casper)
[10:56] <apw> hrm, no idea how those get generated
[10:57] <xivulon> once you have the patch ready I'll see to have one built
[10:58] <apw> i'll let this test build run and then push up the patch and images, and you can use whichever works best for you :)
[11:02] <xivulon> apw thanks a lot
[11:02] <apw> np
[11:04] <cjwatson> apw: FYI I have cdimage/livecd-rootfs changes now to support using lzma compression for the live CD initramfs, once the next kernel lands; it saves 3MB so seems well worth it
[11:05] <apw> cjwatson, nice.  the size constraint in that context more than justifies any performance risk
[11:05] <cjwatson> xivulon: could you make wubi try each of /casper/initrd.gz, /casper/initrd.bz2, and /casper/initrd.lz? I see that it currently hardcodes initrd.gz
[11:06] <cjwatson> oh, and I'd better fix ubiquity too
[11:06]  * apw notes cjwatson is making much work for himself
[11:06] <cjwatson> oh, no, I don't need to fix ubiquity, never mind that
[11:07] <cjwatson> I did think about making it just initrd.img but I sort of like having the extension there
[11:07] <cjwatson> if it turns out to be a real hassle somewhere I'll reverse that choice
[11:08] <apw> yeah ... its kinda nice to know what it is, just by the name as shell can do that check nice and easy
[11:09] <apw> cjwatson, you might have some clever ideas on this, we have found what appears to be a kernel bug which affects the wubi installer and hangs it.  the fix is likely a replacement kernel but it needs to be in a cdimage to be useful to wubi as i understand it
[11:10] <cjwatson> I don't have direct access to the buildds that produce the live filesystems
[11:10] <cjwatson> you could build updated initrd/filesystem combinations using the livecd-rootfs package though
[11:10] <cjwatson> xivulon: ^-
[11:12] <xivulon> cjwatson, sure that is easy enough
[11:13] <xivulon> but is that required for this jaunty update, or is it for karmic?
[11:14] <apw> the lzma initrd would presumably be karmic onwards
[11:14] <xivulon> in karmic I will try not to have an external boot  dir at all and use grub2 loop module if possible
[11:15] <apw> sounds sexy
[11:15] <xivulon> will still need to edit the menu.lst (or whatever is called these days)
[11:17] <apw> xivulon, things in /etc/grub.d/* which then make /boot/grub/grub.cfg
[11:19] <cjwatson> xivulon: what apw said
[11:20]  * apw muses that grub2 seems to have some kind of splash/background support
[11:23] <xivulon> yep, will need to edit grub.cfg directly though, but should be easy
[11:24] <xivulon> I will have to find partitions UUID from windows though
[11:24] <Keybuk> apw: weird, I can't even chroot into the union mount
[11:24] <Keybuk> bash just segfaults
[11:24] <Keybuk> in fact, now it just hangs
[11:25] <apw> Keybuk, poop, so thats worse
[11:25] <apw> which one you got? 7?
[11:25] <Keybuk> -8
[11:25] <Keybuk> vfsunion6
[11:26] <Keybuk> in fact, this looks like a very old one ;)
[11:26] <Keybuk> linux (2.6.30-8.10~vfsunion6) karmic; urgency=low
[11:26] <Keybuk>   [ Andy Whitcroft ]
[11:26] <Keybuk>   * forward port of the VFS union-mount patch set.
[11:26] <Keybuk>  -- Andy Whitcroft < apw@canonical.com>   Fri, 05 Jun 2009 11:42:53 +0100
[11:27] <Keybuk> are you sure you uploaded a new one? <g>
[11:27] <apw> hrm
[11:27] <apw> yeah ... one sec
[11:28] <Keybuk> there's a vfsunion7 in your "staging" PPA ;)
[11:28] <apw> Keybuk, yeah forgot to copy it over, spanner
[11:28] <apw> its copying now, take that one
[11:28] <Keybuk> ok
[11:28] <apw> that was an update i got last night from val
[11:28] <apw> and it is meant to fix a locking issue
[11:29] <apw> so it might even fix what you are seeing
[11:29] <Keybuk> right, that sounds just like what I'm seeing ;)
[11:29] <apw> they are being pretty responsive so far, keen to get some testing i suspect
[11:30] <apw> i have tooo many ppas and no delete button, grrr
[11:30] <Ng> who would be a good person to pester about getting one of the kernel/ubuntu/misc/ modules updated for bug #387756 ? :)
[11:30] <ubot3> Malone bug 387756 in linux "[karmic] please update tp_smapi" [Undecided,New] https://launchpad.net/bugs/387756
[11:31] <apw> isn't that tp_smapi thing the driver of questionable provenance?
[11:32] <Ng> apw: afaik it's been refused a merge into the vanilla kernel because the author insists on remaining anonymous
[11:33] <apw> right, the definition of questionable provenance
[11:33] <Ng> apw: but we've been shipping it for ages, so pragmatic precedent wins the day and we can update it ;)
[11:33] <apw> so lawyers may decide we remove it too :/
[11:33] <Ng> lawyers schmawyers
[11:33] <apw> easy [sic] for you to say
[11:34] <apw> there is a blueprint for reviewing all those drivers
[11:35] <Ng> dammit
[11:35] <apw> ?
[11:35] <Ng> oh, do you mean reviewing as in "with a view to removing anything we can't square away legally"? or "so we can get them all spruced up and fresh"?
[11:36] <apw> a combination of the two, a review and decide what to do with each, with the result being either drop or update
[11:36] <Ng> would dropping mean entirely removing all trace from the archive, or demoting to a DKMS/modass package?
[11:37] <apw> removing from a kernel point of view would be 'washing hands of'
[11:37] <apw> i have no idea which way any particular item is going, or more specifically that item is marked RESEARCH, so its not been decided as yet
[11:38] <apw> added links to both bug and spec (to the other)
[11:39] <Ng> ta
[11:40] <Ng> if I were a petulant person, I'd suggest that an anonymous driver is a drop in the ocean of legal questionability that pours forth from multiverse, but I'm not, so I'll just wait quietly and hope that I don't lose the excellent tp_smapi driver ;)
[11:40] <apw> it is a worry that they won't tell people why they won't tell people who they are
[11:41] <apw> probabally means they do not have the right to release the code, as it belongs to their employer or something
[11:41] <Ng> yeah I've always assumed it means they or someone they know works for ibm/lenovo and obtained the specs without permission
[11:41] <Ng> which is clearly not cool
[11:42] <Ng> and balanced against that obvious legal situation is the longevity of my battery ;)
[11:42] <Ng> anyway, thanks for the linkage :)
[11:42] <lifeless> http://lkml.org/lkml/2008/11/17/355
[11:43] <apw> yep, if they had simply made up a believeable name and submitted it they would have gotten by
[11:43] <apw> by showing they are anon and making it clear there is a _reason_ they cannot tell us
[11:43] <apw> they taint the code
[11:43] <apw> by implication
[11:44] <apw> and the law sadly expects you to be reasonable, and not ignore hints like that
[11:44] <lifeless> well they've said they are willing to show trustworthy people
[11:44] <lifeless> which is why I linked that particular mail
[11:44] <apw> no they are willing to prove they are a person
[11:44] <apw> not explain why they cannot tell everyone who they are
[11:45] <apw> which is the rub, its likely they have done something questionable
[11:45] <lifeless> "willing to disclose is identity to
[11:45] <lifeless> "
[11:45] <lifeless> Assuming thats a typo of 'his'
[11:45] <apw> that is just their identity
[11:45] <apw> their need to hide their identity implies something about them or their working practice
[11:45] <lifeless> or where they live
[11:45] <apw> and one has to assume the worst, or open self to pain
[11:46] <lifeless> well, thats clearly false.
[11:46] <apw> right, there is a possibility its cause they live in china or north korea or something
[11:46] <lifeless> everything is patented, so why do we write code at all?
[11:46] <apw> the law tends to be kinder if you had no way to know in advance
[11:46] <apw> this situation creates a reasonable expectation we s
[11:46] <apw> should be suspicious, that is the issue
[11:47] <apw> if they had called themselves something sane and we'd never known
[11:47] <apw> life would have been fine
[11:47] <Daviey> Could it not be that they work for am employeer that is competition to the Linux kernel, and no exclusive code clause in contract - but would appear bad if they were known.
[11:47] <lifeless> I'd be much more suspicious of someone trying to pretend they didn't want to be anonymous
[11:47] <lifeless> Daviey: ecactly.
[11:48] <apw> its pretty unusual for an employer to not have the rights to everything one produces
[11:48] <apw> its a standard clause in all contracts i have seen and worked under
[11:48] <lifeless> There are many reasons that being known as the author of that code *without it being tainted* could be problematic.
[11:48] <apw> yes, but the point is that the law is full of 'could reasonably expect to have assumed' type stuff in it
[11:49] <lifeless> apw: works in both directions.
[11:49] <apw> you don't get the benefit of the doubt most of the time
[11:49] <Daviey> apw: Well i've avoided such contracts, but if that is the case - a HUGE amount of code in the Linux stack is therefore non-free, as the authors may not have had permission to release under a free licence
[11:49] <apw> indeed so, and lawyers are notoriously 'assuming the worst' kind of people
[11:49] <apw> Daviey, not necessarily i am employed, the code belongs to my work, i am specifically allowed to contribute it
[11:50] <lifeless> lawyers are often extremely risk averse. You have to take that into consideration.
[11:50] <Daviey> yes.. because you have your employeers permisson.  I would imagine that a great deal of patches are written by pure hobbyists, away from dayjob
[11:50] <Ng> I wonder what our relationship with lenovo is like
[11:51] <Ng> they don't have to do anything further than agree not to sue anyone because of us distributing a driver that makes their hardware look better
[11:51] <apw> in a previous job i had the right to do 'non-compete' things outside work in my own name
[11:52] <apw> anyhow, its not my decision to accept it into or not into mainline, they made their reasons felt, and i can understand them
[11:53] <lifeless> seemed rather inconclusive in the things I found, given Linus being willing to accept it :P
[11:53] <apw> and if he does then we get it for free and all is well
[12:09] <cjwatson> and http://lkml.org/lkml/2008/11/18/272 says "SuSE asked, Lenovo said no"
[12:09] <cjwatson> (in the same thread lifeless linked to)
[12:19] <Ng> one does have to wonder exactly what suse asked though
[12:20] <Keybuk> apw: still a segfault with vfsunion7
[12:20] <Keybuk> is weird
[12:20] <Keybuk> it's not even a segfault, the kernel seems to kill bash
[12:20] <apw> hrm, well that might make sense
[12:20] <apw> did you get any kernel stack traces on it
[12:21] <apw> if not, what does strace say happened
[12:21] <Keybuk> strace just hangs
[12:21] <Keybuk> in the execve()
[12:22] <apw> hrm
[12:22] <apw> setuid perhaps?
[12:22] <Keybuk> just going to fire up upstart and see why it thinks bash exits ;)
[12:23] <apw> heh nice
[12:24] <apw> did you say there was nothing in dmesg at the time, most hard kills are reported
[12:25] <Keybuk> didn't look tbh
[12:26] <apw> worth checking then after it happens
[12:27] <Keybuk> got one
[12:28] <Keybuk> BUG: unable to handle kernel NULL pointer deference at (null)
[12:28] <apw> pastebin?
[12:28] <apw> ouch
[12:28] <apw> i'll have a look see if i can see what casues it if you paste the whole thing
[12:28] <apw> somewhere
[12:28] <Keybuk> sure
[12:28] <Keybuk> one moment
[12:28] <Keybuk> it's inside inode permission things ;)
[12:29] <apw> yeeks :(
[12:31]  * apw waits impatiently for the trace
[12:33] <apw> Keybuk, poke
[12:33] <Keybuk> rebooting
[12:33] <apw> ouch
[12:33] <Keybuk> got stuck in kernel and wouldn't shut down :p
[12:33] <apw> it has that tendancy :/
[12:36] <Keybuk> apw: http://pastebin.ubuntu.com/197021/
[12:37] <apw> eip == 0 ouch
[12:47] <Keybuk> useful stack trace?
[12:55] <apw> Keybuk, i think its valid, an trying figure it out... what was your union of?
[13:02] <apw> Keybuk, ??
[13:18] <apw> Keybuk, think its worth writing up what you did and sending that with the panic to val and jblunk, cc: me
[14:00] <Keybuk> apw: back
[14:00] <Keybuk> had to run David to physio
[14:00] <Keybuk> it was a union of the filesystem.squashfs from today's daily-live
[14:00] <Keybuk> and a tmpfs
[14:00] <Keybuk> I ran chroot /mnt /bin/bash
[15:23] <apw> smb, heads up i just pushed a patch to jaunty-lrm, looks like you are working in there too
[15:24] <smb> apw, Thanks, though I must refresh my memory what I might do there
[15:25] <smb> uh oh
[15:27] <smb> apw, any chance you might kill that again for a sec? What version did you base on?
[15:28] <apw> smb, ?  i fetched origin and put it on the top
[15:28] <smb> apw, Hm, yeah. It just looks to me I forgot to push a release
[15:28] <apw> smb, then force it and i'll re do it
[15:29] <smb> ok. thanks
[15:29] <smb> done
[15:30] <Keybuk> aww, nobody's picked up my LKML patch :'(
[15:30] <rtg> Keybuk: you should have sent it to a more specific audience
[15:30] <Keybuk> rtg: there isn't one that I can tell
[15:31] <Keybuk> nothing in MAINTAINERS for cn_proc or connectors in general
[15:31] <rtg> Keybuk: I'm can;t remember who was involved in the last round of syscall discussions, but they'd bea good starting point
[15:32] <Keybuk> it isn't syscall though, no?
[15:32] <rtg> Keybuk: not really, but its up in the process control layer. Perhaps Ingo?
[15:33] <apw> Keybuk, if all else fails always send it to akpm he knows everyone
[15:33] <Keybuk> true
[15:33] <Keybuk> will give it a few days ;)
[15:34] <Keybuk> Ingo, Andrew, Oleg, etc. tend to pick up things from LKML anyway
[15:34] <rtg> Keybuk: he might have missed it in the merge window storm
[15:34] <smb> apw, Just for info, the patch for jaunty lrm is for whch bug?
[15:35] <apw>     BugLink: http://bugs.launchpad.net/bugs/305587
[15:35] <ubot3> Malone bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Medium,Fix committed] 
[15:55] <rtg> apw, jjohansen: is there a reason LGUEST_GUEST isn't enabled for i386?
[15:56] <rtg> in karmic, that is
[15:56]  * apw looks
[15:59] <apw> LGUEST_GUEST implies we are building a paravirtualised kernel
[15:59] <apw> so i'd not expect it to be on for a primary i386 kernel i don't think
[15:59] <apw> rtg, ^^
[15:59] <rtg> apw: right, it allows the 32 bit lguest kernel to boot under an lguest hyper visor. why wouldn't we enable it?
[16:00] <apw> well it would depend on whether it is independant of being a real kernel at the same time
[16:00] <apw> i would expect it enabled in a special kernel like the server virtual flavour
[16:01] <rtg> apw: all of the paravirt-op stuff is dynamic anyway.
[16:01] <apw> i'll see if it is enableable in parallel
[16:01] <apw> rtg then it should be fine. note it is only non-pae so we'd only get it in the new i386_nonpae flavour
[16:01] <soren> LGUEST and PAE don't like each other.
[16:01] <soren> I forget why.
[16:02] <rtg> apw: I think I remember someone at UDS requested it
[16:02] <soren> Oh, apw already said that.
[16:02] <soren> Never mind me.
[16:02] <apw> shall i put it on the config review and spin a patch for it?
[16:03] <rtg> apw, soren: I'll get back to lguest in a bit. I'm currently making sure PAE works.
[16:03] <apw> ack
[16:03] <rtg> apw: wait until I have the legacy flavour implemented
[16:03] <apw> i was about to respin that config merge patch
[16:03] <apw> if you are mid flavour mangle then it should wait
[16:04] <apw> rtg ^^
[16:04] <rtg> apw: it should be independent of the flavours, right? 
[16:04] <apw> yeah the code change is, but there is an associated fdr updateconfigs which isn't
[16:05] <rtg> apw: we could do them independently since the build process would pick up the config changes anyways
[16:05] <rtg> i.e., just the script patch with out the config file updates
[16:05] <apw> yeah we can do that for sure
[16:06] <rtg> I can collapse them later
[16:06] <apw> i'll send out the patch with a sample patch for the config change so peple can see what it does
[16:06] <apw> but with a view to merging only the code change 
[16:06] <rtg> right
[16:06] <apw> ok plan
[17:04] <mohan_> hi.. i am building kernel..
[17:04] <mohan_> how to make deb file out of it?
[17:09] <mohan_> hi.. any body pls help..
[17:13] <rtg> mohan_: start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[17:15] <mohan_> rtg: ok.. thanx..
[17:18] <mohan_> rtg: fully confused .. :(
[17:18] <mohan_> i am right now done with make modules..
[17:19] <rtg> mohan_: then you are doing the wrong thing. see 'https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Normal full build'
[17:19] <rtg> mohan_: you must use debian commands to build the kernel
[17:19] <rtg> the best way is to install devscripts and run 'debuild -b'
[17:19] <mohan_> hmm,.. but before it worked..
[17:19] <mohan_> i installed RT kernel before in this way..
[17:20] <rtg> mohan_: you may have installed it, but you didn't build it that way
[17:20] <mohan_> oh.. ok..
[17:20] <mohan_> i didn't build a deb package though..
[17:20] <mohan_> but now i want..
[17:20] <mohan_> but doing this : fakeroot debian/rules binary-generic
[17:21] <rtg> mohan_: then do as I've indicated. plod through the steps
[17:21] <mohan_> gave error: /usr/bin/fakeroot: line 176: debian/rules: No such file or directory
[17:21] <mohan_> ok sir..
[17:21] <rtg> mohan_: sudo apt-get install build-essential fakeroot devscripts
[17:22] <mohan_> ok.. sir.. its installing..
[17:22] <mohan_> takes one min..
[17:23] <mohan_> i have done passing menu config and make and make modules command..
[17:23] <mohan_> opened package configuration..
[17:23] <rtg> mohan_: then you've made a mess. do 'git checkout -f master;git clean -f -d'
[17:23] <rtg> thern 'debuild -b'
[17:23] <mohan_> ok..
[17:24] <mohan_> now what should i set in this package configuration?
[17:24] <mohan_> no mail?
[17:24] <rtg> huh?
[17:24] <mohan_> postfix configuration dialogue box is asking
[17:25] <rtg> use the default
[17:25] <mohan_> ok..
[17:25] <mohan_> what does git checkout do?
[17:26] <rtg> mohan_: uh, you must not be using the Ubuntu git repo?
[17:26] <mohan_> no..
[17:26] <mohan_> i downloaded kernel manually from kernel.org and patched RT kernel to it..
[17:27] <rtg> mohan_: then go back to https://wiki.ubuntu.com/KernelTeam/KernelMaintenance and read
[17:55] <jjohansen> The kernel team weekly meeting will start in #ubuntu-meeting in 5 min
[21:21] <zeroprog_>  hey guys how do u check MTU size in ubuntu
[21:28] <dtchen> ip(8), ifconfig(8)
[21:28] <dtchen> (same as in other Linux distributions)
[22:53] <maxb> Does anyone know if the lack of provision of a linux-image-debug package is deliberate?
[22:54] <maxb> Or is it just an accident of someone thinking that it's redundant now we have ddebs..... except ddebs are effectively only available for the current development release of Ubuntu
[22:59] <dtchen> maxb: rtg answered that some time last week
[23:01] <dtchen> maxb: briefly, the omission is intentional, as they can be built on the servers but result in gigantic binary packages
[23:10] <maxb> It would be nice to have an official comment in LP 289087
[23:10] <maxb> ubot3: ?
[23:10] <maxb> ubot3: bug 289087
[23:10] <maxb> hrm
[23:10] <ubot3> Malone bug 289087 in linux "Missing linux-image-debug packages and metapackages since Intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/289087
[23:10] <ubot3> Factoid bug 289087 not found
[23:12] <dtchen> maxb: feel free. https://lists.ubuntu.com/archives/kernel-team/2009-June/005931.html
[23:20] <maxb> "How to build them" is not the same question as "Why are they no longer downloadable"
[23:22] <dtchen> maxb: a deliberate attempt to avoid bloating the archive has been raised. i actually asked this question some time ago at the most recent UDS Mtn View.
[23:23] <dtchen> maxb: if you feel it is necessary to have the rationale written precisely in response to why the large debug packages are unavailable from cc.archive.ubuntu.com, then by all means, go for it.
[23:32] <maxb> Well, I feel it necessary that the users legitimately noting that a feature present in Hardy is no longer available have some sort of explanation why that is the  case.