[03:38] <TomJaeger> Hi.  Is there somebody here who I can talk to about Bug #152187?
[03:38] <ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] https://launchpad.net/bugs/152187
[04:25] <cjb> TomJaeger: I think it's an X bug; X doesn't rescan input devices on coming out of suspend, because it doesn't know we went to suspend.
[04:30] <TomJaeger> cjb, it's a kernel bug and there is a fix for it.  My question is more along the lines of what needs to happen for this fix to be applied to the hardy kernel.
[04:32] <cjb> TomJaeger: Neat, thanks for doing that work.  I have an M200 too.
[04:38] <TomJaeger> The problem is that on the upstream side, there are two parties involved: the ACPICA and linux-acpi. This seems to delay things quite a bit.  I've been trying to get their attention, but it doesn't seem like upstream is going to fix that anytime soon.
[04:39] <TomJaeger> Which is a shame since everyone pretty much agrees on what the correct thing to do is.
[04:39] <cjb> That's frustrating.
[04:39] <TomJaeger> yup
[05:03] <TomJaeger> So the question is if it's possible to apply the fix to the ubuntu kernel even though the problem hasn't been fixed in upstream yet.  I think I can make a pretty strong case because (a) a fair amount of useres seems to be affected (any Toshiba tablet pc) and (b) for typical use patterns of a tablet pc, the problem is pretty severe (I, for one, would prefer Windows over linux any day of the week if the latter didn't support p
[05:03] <TomJaeger> roper suspend).
[08:03] <tjaalton> should the 'linux-restricted-modules-virtual' metapackage be removed, since there is no lrm for virtual, nor would it be useful
[08:41] <soren> tjaalton: I'm surprised such a thing exists?
[08:41] <tjaalton> soren: me too :)
[08:41] <soren> tjaalton: linux-virtual doesn't depend on it, so I never noticed it.
[08:42] <tjaalton> soren: hmm? looking at the linux-meta package seems like it _does_ depend on it
[08:42] <tjaalton> oh wait
[08:43] <tjaalton> soren: do you mean linux-image-virtual? the control-file does have linux-virtual that Depends on lrm
[08:44] <tjaalton> but they exist only on i386
[08:44] <tjaalton> *for
[08:45] <soren> tjaalton: That's odd.
[08:45] <soren> tjaalton: I distinctly remember installing linux-virtual in a vm with only main enabled and it worked.
[08:45] <soren> tjaalton: This was a while ago, though.
[08:46] <tjaalton> hum, the virtual machine can only be i386?
[08:47] <tjaalton> and the descriptions are b0rked
[08:47] <tjaalton> "Real time Linux kernel image"
[08:47] <tjaalton> copy-paste ftw :)
[08:48] <soren> :(
[09:19] <kraut> moin
[10:27] <eradicus> hi why do I get a file not found error module.h
[10:27] <eradicus> here's the code
[10:27] <eradicus> http://pastebin.stonekeep.com/1663
[10:28] <eradicus> i already have build-essentials linux-source and linux-headers-generic and they have the same kernel version of my current
[10:30] <eradicus> anyone who can help me please?
[10:34] <amitk> eradicus: does your Makefile point to /lib/modules/<kernel-version>/build for the includes?
[10:42] <eradicus> amitk, i have these in my Makefile
[10:42] <eradicus> obj-m           := hellodriver.o
[10:42] <eradicus> KDIR            := /lib/modules/$(shell uname -r)/build
[10:42] <eradicus> PWD             := $(shell pwd)
[10:42] <eradicus> default:
[10:42] <eradicus>         $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
[10:43] <eradicus> amitk, it compiles fine.
[10:43] <eradicus> but when I do an insmod hellodriver.ko
[10:44] <eradicus> it says file exists
[10:48] <amitk> eradicus: what is the exact error?
[10:48] <eradicus> insmod: error inserting 'hellodriver.ko': -1 File exists
[10:49] <amitk> eradicus: ohh and what does 'lsmod | grep hello' return?
[10:49] <eradicus> hellodriver             2432  0
[10:50] <eradicus> amitk, it was loaded already :D
[10:50] <amitk> eradicus: you already have a module loaded. Try 'rmmod hellodriver'
[10:50] <eradicus> saw the message in dmesg
[10:50] <eradicus> amitk, thanks 
[10:51] <amitk> eradicus: no problems, good luck
[10:51] <eradicus> amitk, ;)
[12:59] <arcticpenguin380> does the kernel use 4k stacks?
[13:08] <cking_> It depends, 4K or 8K
[13:37] <BenC> Good morning kernelites
[13:38] <abogani> BenC: Good morning.
[13:55] <zul> morning
[13:57] <smb_l> morning
[14:54] <BenC> mdomsch: good morning
[14:55] <mdomsch> BenC, good morning
[15:12] <tseliot> BenC: did you have a look at EnvyNG?
[15:14] <tseliot> tseliot: I really need your opinion on it. Let me know if there's something I can do to avoid waisting your time when you check it.
[15:21] <abogani> ogasawara: Are you around?
[15:22] <abogani> ogasawara:  Could you set #193659 on 'Won't Fix", please?
[16:00] <gan> i am following the ubuntu doc of creating the live cd , but not supporting , it is coming upto mounting the filesystem 
[16:01] <BenC> gan: That's more of a #ubuntu question
[16:01] <gan> BenC, i feel its a pronb in kernel
[16:01] <gan> BenC, i feel its a problem in kernel
[16:02] <BenC> gan: does the actual livecd work for you?
[16:02] <BenC> gan: not one you created
[16:02] <gan> BenC, yeah 
[16:02] <ogasawara> abogani: done
[16:02] <BenC> gan: then it isn't a kernel problem
[16:03] <BenC> gan: unless you compiled your own kernel, in which case we can't help you
[16:03] <gan> BenC, i created the live cd , it is booting upto mounting the filesystem , then it got stop 
[16:03] <gan> BenC, i compiled  a kernel for to create the live cd
[16:04] <BenC> gan: then you are on your own basically...we can't debug the kernel you compiled
[16:04] <BenC> gan: sounds like you are missing drivers, but other than that, you'll have to figure things out
[16:05] <BenC> gan: why not just use a normal livecd for install...and if you want a custom kernel, do it on the installed system...why would you use a custom livecd like that?
[16:05] <gan> BenC, the thing is booting propely when i boot from hardisk , the same is not working for live cd
[16:05] <gan> yeah i cahnged the kernel of ubuntu then also i am facing the problem
[16:06] <gan> yeah i changed the compiled kernel to ubuntu then also i am facing the problem
[16:06] <BenC> gan: this is something you'll have to figure out on your own, or ask in #ubuntu
[16:07] <BenC> gan: this isn't a kernel issue (and more specifically, isn't an issue with a kernel we provide)
[16:08] <gan> BenC, thanks
[16:09] <abogani> ogasawara: Leann sorry to bother you again! ;-)
[16:09] <abogani> ogasawara: Bug #129542 was a confirmed bug that don't meet SRU requirements so it should be set "Won't Fix" (and not "Incomplete" that in IMHO is a wrong status). 
[16:09] <ubotu> Launchpad bug 129542 in linux-source-2.6.20 "trouble accessing directory with quotes in read-only mode" [Undecided,Incomplete] https://launchpad.net/bugs/129542
[16:09] <abogani> ogasawara: Thanks.
[16:10] <ogasawara> abogani: I'll fix it up, thanks
[16:13] <tseliot> BenC: if you're too busy, maybe someone else from the kernel team can have a look at EnvyNG so that mvo can upload it ASAP
[16:14] <tseliot> BenC: I mean no disrespect
[16:14] <tseliot> ;)
[16:15] <tseliot> BenC: I appreciate your work
[16:16] <BenC> tseliot: none taken...sorry I've been slow...the rest of the guys are busy as well, but I will get a look at it
[16:16] <xivulon> There used to be problem with suspend-to-ram in loopinstallations related to fuse use (root inside file inside ntfs host). I just received some report from users that it now works!
[16:16] <tseliot> BenC: ok, thanks
[16:16] <xivulon> not sure what happened there, but I am quite pleased!
[16:17] <BenC> xivulon: good to hear, even if it's unexpected :)
[16:18] <xivulon> I will try to confirm that tonight and in case close the related bug report(s)
[16:24] <xivulon> wanted to pass the news to mjg59 that had been looking at that some time ago'
[16:24] <TomJaeger> ogasawara, hi, what are the chances of the fix for bug #152187 making it into hardy?
[16:24] <ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress] https://launchpad.net/bugs/152187
[16:27] <ogasawara> TomJaeger: I think smb and I are still monitoring the upstream progress so it's unlikely to hit Hardy at the moment
[16:28] <TomJaeger> so we have to wait for upstream to fix this first?
[16:29] <TomJaeger> fwiw, our upstream's upstream has fixed this already
[16:29] <ogasawara> TomJaeger: what do you mean by "out upstream's upstream"?
[16:29] <ogasawara> s/out/our
[16:29] <TomJaeger> acpica
[16:30] <ogasawara> TomJaeger: care to point me to a git commit id if you have it?
[16:31] <ogasawara> TomJaeger: and has the patch been submitted to the upstream mainline kernel?
[16:32] <TomJaeger> i don't know how they do their revision control, I'm not even sure it's public.
[16:32] <TomJaeger> But it's in the changelog of the latest acpica release:
[16:33] <TomJaeger> http://www.acpica.org/downloads/unix_source_code_cont.php
[16:34] <TomJaeger> i've attached a hand-linuxified version of the patch to the linux bugzilla report, but apparently they have a conversion tool
[16:38] <ogasawara> TomJaeger: have you submitted that patch to any other upstream mailing lists for review or just in the bugzilla?
[16:39] <TomJaeger> for this to hit linux git, from what I gather, a few things need to happen first:  there was a typo in Robert Moore's patch, that needs to be corrected, then they need to linuxify the latest acpica and then there are some trivial changes in pnpacpi that need to be made.
[16:39] <TomJaeger> ogasawara, just bugzilla, but I think they want to do it their way anyway.
[16:41] <ogasawara> TomJaeger:  any idea when that will happen?
[16:42] <TomJaeger> well, I'm new to all of this, so no
[16:43] <ogasawara> TomJaeger: so basically to answer your original question, until upstream is happy with how the patch is the ubuntu kernel team most likely won't pull in any half-baked patches.  especially since Hardy is an LTS release.
[16:44] <ogasawara> smb: care to comment here? ^^^
[16:45] <TomJaeger> the thing is, everybody agrees on what needs to be done
[16:48] <TomJaeger> okay, so how long before the hardy release date does this need to be fixed in upstream in order to make it into hardy?
[16:49] <ogasawara> TomJaeger: anytime between now and Hardy kernel feature freeze which I believe is April 10.  otherwise it'll get pushed to Hardy+1 (Intrepid Ibex).
[16:50] <TomJaeger> this is all very frustrating
[16:52] <xivulon> BenC did you follow up on loop.c fastfs (http://lkml.org/lkml/2008/1/9/50) by any chance?
[16:53] <xivulon> http://lkml.org/lkml/2008/1/9/50
[16:54] <TomJaeger> ogasawara, does upstream mean linux-2.6 or acpi-test?
[16:55] <ogasawara> TomJaeger: usually linux-2.6
[17:07] <evenit> Hi all. I'm looking for help to compile a custom kernel. I have an this error message "/usr/src/linux-2.6.24 is not clean, please run 'make mrproper'"
[17:07] <evenit> when building with "DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic "
[17:07] <evenit> Can anyone help ?
[17:19] <smb_l> ogasawara: Hi, sorry for the delay. Yes, I still am watching the original bugzilla for a final version, which then has to make its way upstream
[17:29] <TomJaeger> ogasawara, smb_l, to give you an idea how slowly things are moving when it comes to acpica: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=acpica
[17:30] <TomJaeger> this ain't gonna happen before April 10
[17:36] <BenC> smb_l: it doesn't need to get into the kernel proper before we can take it, if it gets in acpica, we can review it on kernel-team@ for inclusion
[17:39] <smb_l> BenC: ok, so I see what is there and post it on the list
[18:10] <evenit> hi again.
[18:11] <evenit> i'm still stuck with my "unclean" source tree and make requiring mrproper, even though  it will erase my debian directory... HELP!
[18:14] <smb_l> evenit: How about mv debian <somewhere safe> then do mrproper and mv debian back?
 I believe I'm becoming dumb...
 You were right and compilation has started. Thanks.
[18:19] <smb_l> evenit: np
[18:28] <smb_l> philosophical question: given the option of either having acpi ac_adapter built into the kernel or loaded in the initramfs (so an fsck can check whether running on battery). Which would be the better choice?
[18:45] <BenC> smb_l: init scripts...initramfs doesn't perform the fsck anyway
[18:47] <smb_l> BenC: Not even for /? But right, for the rest its there.