On Thu, Aug 17, 2006 at 01:19:33PM -0700, [EMAIL PROTECTED] wrote: > On Thu, Aug 17, 2006 at 10:06:44PM +0200, maximilian attems wrote: > > enough time is lost with any of those dfsg firmware wankers, > > that do _zero_ work upstream or on the licensing front. > > I repeat my offer to patch any (well, almost any) of these > drivers to use request_firmware(). I need a volunteer who > has the affected hardware and is willing to test my changes. > It would also be nice if debian kernel developers expressed > interest in incorporating such work (if any) for etch.
I can say that the debian kernel team is interested in incorporating such changes, provided : 1) it is not already too late for it. The RMs will have to judge on that. 2) the proposed patches are well implemented patches of good quality, are well tested and result in no breakage. 3) We are able to solve all those cases for etch, or remove the others. Doing it otherwise would be an injustice, and it would be better to postpone this. 4) The d-i team implement the needed support in d-i to load non-free firmware or even module .udebs, and build non-free flavours of the installer images in an official way. 5) There is seemless integration of these non-free drivers and firmware, and a user will not notice > One alternative sven mentioned is to move these drivers to > non-free. I don't see any existing framework for such > package(s), but that would indeed involve less coding > and debugging. There is, we have prune-non-free in trunk/scripts on the svn repo, as well as the linux-non-free-drivers (or whatever it is called), also in trunk in the svn repo, and which Bastian Blank has been working on since a long time. > I am concerned about etch, and the pipeline from upstream > to Debian is long enough that I think it's too late to > work upstream. long enough ? We inaugurated same-day-uploads with the upstream 2.6.14 release, what do you find long enough about this. But you are right, bringing it upstream will be a long fight, and only be possible post 2.6.18, which is the targeted kernel for etch, so it is out of the question. > At least 12 of the 59 files are probably licensed "free enough" > for upstream, so upstream will have limited interest in those > cases. :) Two of them thanks to previous work of the debian kernel team. Ok. Now that the above was said, my own position still is that it is best to not delay the etch release, to pass a GR to keep the firmware in main for etch, and to immediately actively start working on the solution for etch+1. It is not as if this would come to a surprise to anyone interested in solving this issue the right way, the kernel team has been discussing this over and over since over a year now, and it is back then that help should have come, not now. So, let's not do it in a hurry, but instead do it right for etch+1, which given the release date of the d-i team, is not doable anymore. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
