[12:33] <kylem> dilinger, thanks.
[01:10] <mjg59> dsafdsafdsarewaoiufdsdsoiufdslk
[01:10] <kylem> mr. garrett?
[01:10] <mjg59> I have what seems to be a moderately critical ACPI patch sitting here
[01:12] <mjg59> It seems that Windows enables GPEs before calling the _WAK method
[01:12] <mjg59> And, uh, Linux currently doesn;t.
[01:12] <kylem> hmm?
[01:13] <mjg59> So if a _WAK method does anything that triggers an event, the event handler never gets called
[01:13] <mjg59> And it all goes pear shaped
[01:13] <kylem> yuck.
[01:17] <mjg59> Jesus. It actually seems to fix it, too.
[01:40] <schweeb> I was told I should talk to you guys about packages that have kernel dependencies in universe that won't build... such as user-mode-linux, which requires kernel-source-2.4.26
[01:42] <schweeb> http://people.ubuntu.com/~lamont/buildLogs/Test/u/user-mode-linux/2.4.26-3um-1/user-mode-linux_2.4.26-3um-1_20050324-0640-i386-failed
[04:05] <zul> mjg59: http://bugme.osdl.org/show_bug.cgi?id=4390 
[04:06] <zul> then there is a whole thread about powersaving and usb devices on linux-usb-devel
[06:16] <dilinger> as soon as someone sends somethign to kernel-team, the gmane newsgroup should get created
[06:18] <dilinger> gmane.linux.ubuntu.devel.kernel.{bugs,general}
[06:21] <fabbione> morning
[06:22] <dilinger> evening
[06:22] <fabbione> mjg59: thanks for the patch but that will be for breezy
[06:22] <fabbione> no more patch for hoary
[06:24] <fabbione> dilinger: what's up?
[06:32] <dilinger> not much.  just thinking about sarge preparations
[06:34] <fabbione> i started squashing xen into the kernel
[06:34] <fabbione> the patch is not too bad, but it has some duplicate files = extremely annoying
[06:35] <fabbione> + it needs me to  add the patch per subarch support
[06:35] <fabbione> btw.. how do you handle the kernel-patch package, given that you have general patches, patches per arch, and patches per subarch?
[06:36] <fabbione> do you create all of these patches?
[06:36] <fabbione> or just the general ones?
[06:37] <fabbione> because right now i create patches only per arch
[06:37] <fabbione> i still do not generate per subarch diffs
[06:41] <fabbione> i think that would give the same problem creating the patched kernel-source-2.6.X package...
[06:41] <fabbione> hmmmm
[06:42] <dilinger> sorry, roommate distracted me
[06:42] <fabbione> no problem :)
[06:42] <dilinger> i haven't had to deal w/ kernel-patch stuff for a while (w/ devmapper patches)
[06:43] <dilinger> or are you talking about kernel-patch-debian?
[06:43] <fabbione> that latter
[06:43] <fabbione> given that you have the three levels of patches
[06:43] <fabbione> which ones are reflected into kernel-patch-debian?
[06:44] <dilinger> the stuff in kernel-patch-debian is just stuff from kernel-source
[06:44] <dilinger> that's for all archs
[06:44] <fabbione> so you lose per arch and per subarch bits
[06:46] <dilinger> ok, kernel-patch-2.6.8-hppa
[06:46] <dilinger> that still does it the old way
[06:46] <dilinger> that's a patch on top of kernel-patch-debian
[06:46] <dilinger> most archs just commit patches directly to kernel-source, though
[06:47] <dilinger> sparc, powerpc, i386, etc, all had their patches merged into k-s
[06:47] <fabbione> ok, so we handle the per arch in a better way :-)
[06:47] <fabbione> since for me it's a Package: any
[06:47] <fabbione> and i create the diff per arch
[06:48] <fabbione> hppa is part of it
[06:48] <fabbione> what about subarches?
[06:48] <fabbione> i know you support it
[06:48] <dilinger> yea, see, the problem w/ doing per-arch patches is, you get other patches that conflict
[06:48] <dilinger> i'm not aware of subarch patches
[06:49] <fabbione> dilinger: yes, and that's why by (our internal) policy the per arch patches must be applied only after the general patches
[06:49] <fabbione> and not mixed in the middle
[06:49] <dilinger> i mean other patches
[06:49] <dilinger> ie, kernel-patch-grsec, kernel-patch-devmapper, etc
[06:50] <dilinger> they must apply to kernel-patch-debian
[06:50] <fabbione> oh well, these are external patches anyway
[06:50] <dilinger> but if you throw misc arch-specific patches in there, it gets messy.  might as well not bother packaging separate patches
[06:50] <fabbione> yes i see, but i am talking about only kernel-source here
[06:51] <fabbione> dilinger: that becomes kernel-patch-foo maintainer problem to get his patch properly integrated instead of maintaining externally
[06:51] <fabbione> external patches = crap
[06:51] <fabbione> imho
[06:51] <dilinger> that's cause you integrate external patches :p
[06:51] <dilinger> we try to do the opposite
[06:52] <dilinger> if they're not upstream, and they're not in the process of being fed upstream, we don't want them in kernel-source (and per-arch kernel packages)
[06:52] <fabbione> we both have valid points in that area
[06:53] <dilinger> otherwise, it becomes a PITA to support
[06:53] <fabbione> but using your approach, you correctly push the external patches responsability to the maintainer :-)
[06:53] <dilinger> yep
[06:53] <fabbione> so if you apply a persubarch/perarch patch
[06:53] <dilinger> and that's why we want to make it as easy as possible for those maintainers
[06:53] <fabbione> it's not your problem to let -grsec to apply
[06:54] <dilinger> if they suddenly have to deal w/ making -grsec apply to not only kernel-patch-debian, but various other per-arch patches..
[06:54] <dilinger> when i maintained kernel-patch-devmapper, hubert's application of a crippled dm patch was a constant source of hassle
[06:55] <dilinger> 'cause what he applied was only useful for basic lvm stuff.  snapshotting, etc, didn't work
[06:55] <dilinger> so i ended up having to have two patches in kernel-patch-devmapper; one for vanilla kernels, and one for debian kernels
[06:55] <dilinger> that totally broke kernel-package, though
[06:55] <dilinger> people had to apply and unapply patches manually.  it was a mess
[06:56] <dilinger> so, having a canonical source for those patches to apply against is valuable
[06:56] <fabbione> that's why i hate external patches :-)
[06:57] <dilinger> thanks for the bluetooth thing, btw
[06:57] <dilinger> did you ever find a fix for the BINDTODEVICE thing?
[06:58] <fabbione> nope
[06:58] <fabbione> i think there is none yet
[06:59] <dilinger> i took a look at netdev-2.6, but didn't see any fixes.  i assume the problem is that the sk_dst_get stuff was returning the sk_dst_cache, which wasn't invalidated?
[07:00] <fabbione> our patch finder is pitti for this stuff
[07:11] <fabbione> i need to remember to put all my clocks one hour in front
[07:11] <fabbione> this daylight saving shit is a royal pain
[07:17] <dilinger> hrm
[07:17] <dilinger> i'm gonna be on a plane then :(
[07:18] <fabbione> um?
[07:18] <fabbione> for the meeting?
[07:19] <fabbione> do you remember if cp -al creates softlinks or hardlinks?
[07:19] <dilinger> actually, no, i take that back.  i'm getting back to albany around 2pm.  so, i'll probably just be getting home
[07:20] <dilinger> soft
[07:20] <dilinger> iirc, of course ;)
[07:20] <fabbione> yeah i need to check that to implement per subarch patching
[07:21] <fabbione> it loks like hardlinks
[07:21] <dilinger> yea
[07:22] <dilinger> cp -as
[07:22] <dilinger> that'll do softlinks
[07:22] <fabbione> rock
[07:54] <Roey> fabbione:  hi
[07:56] <Roey> fabbione:  do you maintain kubuntu kernel stuff?
[07:57] <Roey> I built the wacom-kernel-module 
[07:57] <Roey> er
[07:57] <Roey> enabled the replacement hid, mousedev, evdev, usbmouse drivers in the module's debian/rules
[07:57] <Roey> but when I make a kubuntu package from the sources, it doesn't seem to contain these .ko's
[07:58] <Roey> crimsun and I have been looking at this for the past 45 mins.
[07:58] <Roey> this doesn't make -any- sense.
[07:58] <Roey> this wacom linux kernel package seems to be missing key functionality
[07:58] <crimsun> Roey: I haven't seen the build log from your last attempt
[07:59] <Roey> http://rafb.net/paste/results/8narM137.html
[08:02] <crimsun> Roey: err, that can't be your build log...
[08:03] <Roey> ah
[08:03] <Roey> right
[08:03] <Roey> that's the dpkg -L listing of that package
[08:03] <Roey> showing that only wacom.ko was installed.
[08:03] <crimsun> right, but to troubleshoot, we'd need your build log
[08:05] <Roey> http://rafb.net/paste/results/Dz7HbQ95.html
[08:05] <Roey> crimsun:  http://rafb.net/paste/results/Dz7HbQ95.html
[08:07] <fabbione> Roey: the kernel for ubuntu and kubuntu is the same
[08:07] <fabbione> and i already gave you an answer yesterday about the driver
[08:08] <Roey> "No need to build input.o for kernel 2.6" -- so input.ko is not built.
[08:08] <Roey> fabbione:  did you?
 Roey: i don't want to sound unpolite, but this chan is to discuss
[08:08] <fabbione>            the kernel development. General help should go to #ubuntu please.
 at 15 days from release, i really don't have to see external
[08:08] <fabbione>            modules.. sorry
 + it's eastern :-)
[08:08] <Roey> I meant ubuntu
[08:08] <Roey> not kubuntu
[08:08] <fabbione> it's the same kernel
[08:08] <Roey> kubuntu is just the kde libraries for ubuntu
[08:08] <fabbione> there are no differences
[08:08] <Roey> I know
[08:08] <Roey> I know
[08:08] <Roey> I'm talking about the ubuntu kernel.
 fabbione:  do you maintain kubuntu kernel stuff?
[08:09] <Roey> *ubuntu* then
[08:09] <Roey> sorry, my mistake
[08:09] <fabbione> i was also answering to this one :-)
[08:09] <crimsun> he's our team lead, roey.
[08:09] <Roey> understood!
[08:09] <Roey> fabbione:  so I'll move to #ubuntu then
[08:09] <Roey> sorry
[09:09] <fabbione> i hate Makefiles :-)
[09:10] <bhna> usb 1-1: device descriptor read/64, error -71
[09:11] <bhna>  sorry, dmsg after inserting an usb-stick. usb 1-1: device descriptor read/64, error -71
[09:12] <fabbione> bhna: known bug. it's already reported on bugzilla.u.c
[09:12] <bhna> fabbione: tnx ;-)
[09:52] <fabbione> night lamont
[01:38] <zul> morning
[01:41] <crimsun> morning
[04:11] <zul> gday
[04:22] <zul> mmmm...ketchup
[06:45] <Roey> hi
[06:45] <Roey> anyone here?