[03:36] <Kano> hi, anybody here who creates the restricted driver package
[03:37] <Kano> grep pci_module_init -Rs *
[03:37] <Kano> is still there in the avm drivers, must be pci_register_driver
[03:38] <Kano> also a nice addon would be: ftp://ftp.avm.de/cardware/fritzwlanusb.stick/linux/suse.10.2/fwlanusb-1.00.00.tar.gz
[03:39] <Kano> and
[03:39] <Kano> fxusb_cz
[03:39] <Kano> which is a tiny mod of fxusb, apply just
[03:40] <Kano> http://kanotix.com/files/fix/avm/fxusb_cz.patch
[03:40] <Kano> and rename the binary part
[03:41] <Kano> in lib dir
[03:41] <Kano> rest is same as fxusb
[03:41] <Kano> suse has that patch for years
[03:42] <Kano> you also lack: fcpcmcia fcusb2
[03:45] <infinity> You might want to mail all of this to kernel-team@lists.ubuntu.com ... I suspect no one's going to bother picking it out of their backscroll
[04:07] <Kano> http://kanotix.com/files/fix/gutsy/gutsy-problems.txt
[04:08] <Kano> will add more problems soon
[04:15] <Kano> i dont like to write to mailinglist for every little issue , please look there, you can ask me on that server or via mail
[04:22] <ScottK> Kano: File bugs.  Those get looked at.
[04:23] <Kano> whats the problem to look into a text file?
[04:23] <Kano> added fuse-utils now too
[04:24] <infinity> Kano: The problem is with expecting people to wake up, check IRC scrollback, and notice or care that there is a text file to look at.
[04:24] <mjg59> Kano: If you want this to happen, please file a bug. If it can't be tracked, it won't be done.
[04:24] <infinity> Kano: The ideal would be bugs, the minimum would be to at least mail the list.  IRC is a horrible way to inform sleeping people about anything.
[04:24] <ScottK> There is a workflow for how people get stuff done.  Looking at bugs in stuff they care about is in that workflow.  Reading someone's complaints on other web sites is not.
[04:25] <ScottK> Kano: After I upgraded my test machine to gutsy I spent several hours filing bugs.  It's labor intensive, but gets the best results.
[04:30] <Kano> i currently test only kernels recomplied on etch + kubuntu live images
[04:30] <Kano> no hd install
[04:38] <Kano> bye
[09:12] <kraut> moin
[04:34] (BenC/#ubuntu-kernel) and when you say "required" just remember you really mean "required for 3d graphics"
[04:34] (BenC/#ubuntu-kernel) because you can definitely use ubuntu on those cards with the free 2d xorg driver
[04:35] <Kano> that package contains 3d drivers which i dont need in there. i need networkdrivers
[04:35] <Kano> these usually do not change
[04:35] <BenC> the flow of this conversation isn't making much sense
[04:35] <BenC> first you say we need 100.x series nvidia, then you complain that you don't need them
[04:36] <Kano> i dont need it packaged
[04:36] <Kano> i have a script for it
[04:36] <Kano> same for fglrx
[04:36] <BenC> ok, then why are you complaining?
[04:36] <BenC> is the few megs of disk space for a module that isn't even linked really that much of an issue?
[04:36] <Kano> because these drivers make the package very huge
[04:37] <BenC> 5.9M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia
[04:37] <BenC> 4.8M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia_legacy
[04:37] <BenC> 7.9M    /lib/linux-restricted-modules/2.6.22-8-generic/nvidia_new
[04:37] <BenC> 1.1M    /lib/linux-restricted-modules/2.6.22-8-generic/fglrx/
[04:38] <BenC> compressed, it's probably about half that size...it's not small, but not a problem for other people
[04:38] <Kano> it is no problem for you because you dont like at add other things...
[04:39] <BenC> the network drivers account for half the size of lrm
[04:39] <BenC> add what other things?
[04:39] <Kano> these are the most important ones. as soon as you can go online you can download the rest
[04:40] <BenC> To you maybe
[04:40] <BenC> the usage of the fc* drivers is very limited
[04:40] <BenC> important, yes, but still very limited compared to fglrx/nvidia
[04:40] <Kano> fwlan is very heavyly used
[04:40] <Kano> at least in germany
[04:40] <BenC> that's interesting because I don't know anyone (except you) that does use it
[04:41] <BenC> see, that's what I mean by scope
[04:41] <Kano> because nobody else has the hardware to try
[04:41] <Kano> they dont work
[04:41] <Kano> without the mentioned patch
[04:41] <BenC> you want to remove nvidia/fglrx, which is used EVERYWHERE so people in germany don't have to install it
[04:41] <Kano> no split it
[04:41] <Kano> restricted-network + rest
[04:42] <BenC> Kano: it will get installed by default anyway
[04:42] <Kano> not when i can change these defaults ;)
[04:42] <BenC> Look, I have no intention of splitting the package up
[04:42] <Kano> ok, then add the missing ones, how about that
[04:42] <BenC> you have not provided a single good reason for it
[04:43] <BenC> Kano: Ok, then add the bugs to launchpad, how about that?
[04:43] <BenC> we have a workflow, which revolves around this product that Canonical has spent years on, and it's called launchpad
[04:43] <Kano> thats the difference to tell it to you or to add em to lauchpad?
[04:43] <BenC> we use it a lot
[04:44] <BenC> Kano: because I'm not going to do it right this second, and my todo list comes from bugs in launchpad
[04:44] <BenC> adding a special note somewhere to check your pet problem will most likely get lost in my work flow
[04:44] <BenC> Kano: all this effort you've spent here, would have been better spent just following our requests instead of actively working against them
[04:45] <BenC> Hell, even Dell and Intel use launchpad exclusively for working with us
[04:45] <BenC> In fact, they prefer it because they know it increases our attention and response to problems
[04:48] <BenC> Kano: then there's the fact that if I say, "ok, I got your request", I may not have time to do it, and no other people on the kernel team or in the community would now about it
[04:49] <BenC> if it's in launchpad, hundreds of people know about it, and chances are better one of them will do the work
[04:54] <Kano> how to attach files?
[04:54] <BenC> There's a link in the left panel for attachments
[04:55] <IntuitiveNipple> BenC:  I can see you have other things on your mind, but could I ask a question about the kernel-build process?
[04:55] <BenC> Kano: also, scrolling to the bottom, there is a "Add a comment/attachment" link
[04:55] <BenC> IntuitiveNipple: that's part of this channels purpose :)
[04:56] <Kano> BenC: i dont see that only
[04:56] <Kano> Further information, steps to reproduce, version information, etc.:
[04:56] <BenC> Kano: you have to file the bug first, then you can attach files
[04:57] <IntuitiveNipple> Thanks... I'm building from git, successfully now (thanks!) but wondered if there is a way, when building a kernel-package to have the changes to source on one or two files included. Doing binary-debs seems to rebuild from a separate source-tree and doesn't pick-up source changes unless I do a clean first, which of course then means the package build takes a long time.
[04:58] <IntuitiveNipple> I'm making test packages to install on another machine, so I move the generated debs to it to install
[04:58] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
[05:03] <Kano> that way or do you need more info?
[05:21] <Serge378> Hello, can someone please answer my question: I am going to upgrade from an old 2.6.15 kernel to the latest 2.6 one with smp support, however the package 'coreutils' needs to be upgraded. If the new kernel does not work(for whatever reason), and I have to revert to the old kernel, would the old kernel work ok with the new andupgraded coreutils?
[05:23] <BenC> IntuitiveNipple: your problem is because you are clearing the hard link in the build tree from the source tree...that's probably the fault of your editor
[05:24] <BenC> IntuitiveNipple: gutsy build system is better about that since it uses the kernels O= out-of-build feature
[05:24] <BenC> Serge378: wrong channel for that question
[05:25] <Serge378> BenC: why is it the wrong channel? And which channel is more approptiate?
[05:26] <BenC> Serge378: because this is specific to Ubuntu kernels and is specific to kernel development...your quick answer is "probably yes", but I'm not sure who to ask about it
[05:26] <Serge378> ok thanks 
[05:27] <BenC> Kano: in regards to via quirks, did you write this patch, and if so, have you bothered to send it to upstream linux-kernel?
[05:27] <BenC> ...and if not, do you have any context on where the patch came from
[05:28] <Kano> i fixed another patch, that did only apply to kernel below 2.6.20. the first patch made locsmif
[05:28] <Kano> as he has that specific problem
[05:29] <BenC> Kano: I wonder about patches like this that are against a 2.6.20 kernel, but not in 2.6.22 by now
[05:29] <Kano> thats only the name
[05:29] <Kano> it is against 2.6.20+
[05:30] <IntuitiveNipple> BenC: Hmmm... I did set up an out-of-tree build directory and built to that (as per the Kernel Wiki), but the debian build scripts are an acquired art-form and I got lost trying to figure out what was required to create the linux-image/linux-header debs :) So to save time I just switched back to doing complete fresh binary-debs builds. Did I miss something obvious?
[05:30] <BenC> That's not my point, my point is that it's been around, obviously more than 6 months now, and is not upstream
[05:30] <Kano> it has been out for years that patch, locsmif posted it even on lkml, but noone saw it
[05:31] <BenC> IntuitiveNipple: the build tree for pre-gutsy kernel builds does a hard link tree of the sources...if you use an editor on the source files that unlinks/writes, then the hard link is then broken and you are left with a modified source in your main tree, and an original source in the build tree
[05:32] <IntuitiveNipple> oh i see! I've been using Anjuta to pop in and out as needed... what you've said now makes sense since the other day I noticed it alters the permissions of a shell script I was testing! Thanks for that... I'll investigate
[05:33] <IntuitiveNipple> I've not done too bad - using CONCURRENCY_LEVEL an NOEXTRAS speeds things up :)
[05:33] <Kano> BenC: for more info ask locsmif on that server, he is online
[05:33] <BenC> Kano: the issue I have with patches like that is divergence from upstream...I don't like carrying around patches that are not going to be upstream soon (like next release)
[05:34] <Kano> BenC: is the hostap-cs patch going upstream?
[05:34] <BenC> what hostap-cs patch?
[05:34] <Kano> the 2nd that i need, zul said he has it already?
[05:34] <zul> BenC: its a hostap-cs patch that i pulled from a bug in linux-meta seems innocent enough its in my git tree right now
[05:35] <Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/t-sinus_111card-2.6.16.diff
[05:36] <Kano> that patch works since 2.6.16
[05:36] <BenC> Kano: I haven't pulled that into the Ubuntu tree yet, but it needs to go upstream as well
[05:36] <zul> BenC: http://kernel.ubuntu.com/git?p=zul/ubuntu-gutsy.git;a=commit;h=d3ad468775b97d222817fc02e75aa3bd9629a093
[05:36] <BenC> see, why are things like that around for basically 2 years without being pushed upstream?
[05:36] <BenC> We as distros shouldn't be held accountable for pulling in all these patches...we should be getting them from usptream
[05:37] <BenC> Kano: If you are as interested in these patches as you seem to be, I think your best bet in the long run is to get them upstream
[05:38] <Kano> seems to be not that easy when they are just ignored, both have been posted by the original authors
[05:38] <BenC> we can get them in Ubuntu, but in the long run, we risk becoming over loaded with maintaining them, and also add to the problem because people think it isn't important to get these things into the mainline kernel
[05:38] <BenC> Kano: to the proper lists?
[05:39] <BenC> posting to lkml is not the proper list in most cases
[05:39] <Kano> to which one then
[05:39] <BenC> there's a nice file called MAINTAINERS
[05:39] <BenC> HOST AP DRIVER
[05:39] <BenC> pkl_:      Jouni Malinen
[05:39] <BenC> macd:      j@w1.fi
[05:39] <BenC> lamont:      hostap@shmoo.com (subscribers-only)
[05:39] <BenC> lamont:      linux-wireless@vger.kernel.org
[05:39] <BenC> W:      http://hostap.epitest.fi/
[05:40] <BenC> damn nick completion
[05:40] <Kano> i mailed the author even years before...
[05:40] <BenC> do the list
[05:41] <Kano> should i report one bug for restricted modules or serveral?
[05:41] <BenC> generally, email the list for the driver/subsystem and Cc lkml
[05:41] <BenC> Kano: one for each instance of problem, please
[05:42] <Kano> like: fix for existing avm drivers + need for others?
[05:42] <BenC> Kano: for hostap, wireless-dev list may be a good Cc as well
[05:42] <BenC> Kano: one per driver is good
[05:42] <BenC> one bug per driver I mean, as long as it's a cohesive bug
[05:42] <Kano> but it is the same package?
[05:43] <BenC> in that sense, all the bugs in lrm can be lumped together
[05:43] <BenC> each bug should have one task in order to complete it
[05:43] <BenC> not a checklist of items to mark off
[05:46] <zul> BenC: for #127461 (suspend2) should we just out and right reject it?
[05:46] <IntuitiveNipple> BenC:  you're a star!! I just checked the inode # after an edit and it changes, which means I now understand the problem... many thanks!
[05:47] <BenC> IntuitiveNipple: np
[05:47] <IntuitiveNipple> Now to post a 'bug' report aka feature request for Anjuta!
[05:47] <BenC> zul: yeah, but direct them to blueprints
[05:48] <BenC> IntuitiveNipple: IMO, an editor using unlink/write is a bug...it's not a feature to make it work correctly :)
[05:48] <IntuitiveNipple> BenC:  I entirely agree, but sometimes you have to be diplomatic to get things done :)
[05:48] <IntuitiveNipple> I don't fancy having to fix that myself! I've got other things to do!
[05:48] <BenC> IntuitiveNipple: good point
[05:50] <zul> BenC: done
[05:50] <BenC> zul: thanks
[05:51] <zul> np
[05:51] <IntuitiveNipple> BTW, for your information... I'm working extensively on/around ACPI and suspend/resume this past couple of months, and writing a new kernel driver (sony-notebook-control) that implements 100% of the Sony notebook Windows driver functionality... so if there's anything needs doing around ACPI suspend/resume let me know. On Launchpad my id is "intuitive-nipple" and my display-name (and real-name) is TJ.
[05:53] <BenC> IntuitiveNipple: excellent...ACPI is one of our hotspots
[05:53] <BenC> IntuitiveNipple: if you would, please, join the ubuntu-acpi team
[05:53] <BenC> kernel bugs relating to it are assigned to that team
[05:54] <IntuitiveNipple> BenC: ok, I'll go do that now... as a celebration that my debug-messages on resume have just given me a clue as to why the problem-PC is resuming immediately it S3 suspends :)
[05:57] <IntuitiveNipple> Well, I got lost in launchpad for while there! Found it in the end though
[05:59] <IntuitiveNipple> BenC: as you're the team owner, can I tax your ACPI brains on a specific issue?
[06:06] <Kano> so can i put 3 drivers to one bug...