Re: Bug#353277: ndiswrapper in main
Hello Brian, Only a short comment: Very well sayed. I second your opinion 100%. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Am 2006-03-01 23:48:56, schrieb Peter Samuelson: What possible use would it be to integrate ndiswrapper into debian-installer? Wouldn't the user _still_ have to provide a Windows driver in some format usable by ndiswrapper? Wouldn't that still have to come from some external source, like a web site or a floppy disk? And if so, why would it be a hardship to get ndiswrapper from an external source at the same time? It is sometimes not possibel, specialy if you have no Internet connection or a private Debian mirror. ndiswrapper in the d-i can access easyly the CD-Rom with the firmware provided by the hardware manufacturer. I have created some wrapper and downloader for some customers of me whose migrating from Windows to GNU/Linux systems. Providing no wrapper oder firmware loader let run such Windows switchers run into trouble, because it prevents the migration. I think, (specialy) Debian should think about it. I can understand the appeal of having ndiswrapper on the installer image, but only if the image also has drivers to use with it. Are we talking about CIPE again? Is CIPE useful for an installer? Not realy right, because if someone has the hardware, she/he has probablement the Drivers-CD which can be used. No, package foo can stay in main, because it wouldn't be a hard Depends relationship (or it shouldn't be, anyway), it would be a Suggests or possibly Recommends, depending on how common it is to use foo without ndiswrapper. And if this tool is specialy a development tool, which DEPENDS on ndiswrapper becasue it support the development of such driver? After your opinion this tool must go into contrib. Even if is designed to develop DFSG software because it depends on a package in contrib which depends on a package in non-free. Where later is not true. ndiswrapper should only suggest or maximum recommends to the non-free ndis-stuff. Actually, I'm not certain whether packages in main are allowed to Suggest packages outside main. If not, the usual workaround is for There are many Packages which suggest Packages in contrib and or non-free. openoffice.org is one of those candidates. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Hello Colin, Am 2006-03-02 08:32:46, schrieb Colin Watson: (I have no particular position on ndiswrapper in main per se, and I haven't read all of this enormous thread.) It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Without ndiswrapper integration, the user has to figure out that this thing called ndiswrapper that they've never heard of is needed, then go and get it and prepare a floppy disk with all the right stuff on it. This is a lot more error-prone, may not always be possible (they may not have any access to the Internet other than via the system they're trying to install), and even if possible raises the difficulty bar quite significantly beyond insert the floppy disk provided with your network card. Well explained. (I was not able to write it down correctly because I am not nativ english speaker) I have several commercial/gov. customers and those are running into trouble while switching from Windows to GNU/Linux. I had to create my own Debian-Installer-CD-Images which support wrapper and firmware loader. (works, but do not ask how!) I think, (specialy) Debian should care about such new GNU/Linux users. Of course, it would be possible to prepare a special ndiswrapper driver image that could teach the installer how to do this without having to have it in the core installer; so ndiswrapper doesn't *have* to be in main for this to work, although it would make things easier from the point of view of making this trick work out of the box with Debian CDs. Hmmm, providing a contrib ISO-Image fo some MBytes with wrapers and firmware loaders which can loaded seperatly? This would be nice. Then users of critical hardware should download the Netinstall-ISO and the Contrib-ISOto install there computrs. I think, such solution would be the best. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Hello Wouter, Am 2006-02-28 14:36:52, schrieb Wouter Verhelst: I'm a GNU/Linux consultant. It is my job to help people with installing, configuring, and generally using GNU/Linux. I prefer to use non-free software as little as possible, and most of my own systems currently have no non-free software installed (although not all of them). I am in the same situation... ...but not using any kind of non-free software. On the other hand, I have no say over what a customer would want; and if my choice is to either help them out with non-free software or loose the contract, then I will do the former. That still doesn't mean that I'd like to use non-free software myself, so I'll avoid it if possible. Right, I have the same problem. Commercial and governmental customers switching from Windows to GNU/Linux and it is not possibel to buy for several million Euros new hardware to be supported by Debian GNU/Linux. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michelle Konzack [EMAIL PROTECTED] writes: Am 2006-03-01 23:48:56, schrieb Peter Samuelson: What possible use would it be to integrate ndiswrapper into debian-installer? Wouldn't the user _still_ have to provide a Windows driver in some format usable by ndiswrapper? Wouldn't that still have to come from some external source, like a web site or a floppy disk? And if so, why would it be a hardship to get ndiswrapper from an external source at the same time? It is sometimes not possibel, specialy if you have no Internet connection or a private Debian mirror. ndiswrapper in the d-i can access easyly the CD-Rom with the firmware provided by the hardware manufacturer. There are other firmwares that are non-free that people might need and for that a Debian-Installer-Non-free will be needed. Ndiswrapper support is as good a reason as any to start implementing this if that is all you need it in main for. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
2006/2/28, Henning Makholm [EMAIL PROTECTED]: Personally I favor using a test somebody invented an earlier time we discussed a similar problem: To determine whether A requires B for the purpose of the social contract, assume hypothetically that B was free and packaged, and then ask whether ordinary packaging practice would lead to A a declaring a Depends: relationship on B in that situation. This test would allow us to move the question into the technical realm. Thank you, this has cleared everything up for me. Now I can stop reading this thread :) -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Bug#353277: ndiswrapper in main
On Wed, Mar 01, 2006 at 11:48:56PM -0600, Peter Samuelson wrote: [Brian May] I think these should belong in a separate category then ndiswrapper, because, unlike ndiswrapper, they are not even complete packages without non-free software, and this will never change for the lifetime of the installer package. Never underestimate the Debian universe's collective ability to contrive a justification for something. It could be said that an installer for some random bits that can't even be carried on non-free should actually go in main because, in some hypothetical alternate universe future scenario, somebody _might_ reimplement the non-free component in a free way, and furthermore, it might make sense to install it using the scripts in the wrapper package rather than packaging it natively. Perhaps the developer of the free replacement would like to have the wrapper package on his system in order to facilitate testing. I don't think you've ever seen someone say this; and I don't think you'll ever see someone say so either. There is a world of difference between this package implements an API that just happens to be implemented by non-free software only (which isn't even the case for ndiswrapper, unlike what many contributors to this thread want us to believe) and this package downloads and installs one particular piece of non-free software. If you don't see the difference, you're blind. [...] -- Fun will now commence -- Seven of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Wed, Mar 01, 2006 at 11:48:56PM -0600, Peter Samuelson wrote: [Brian May] Even if nobody does this, it is still possible to integrate ndiswrapper with free software (such as debian-installer)[1]. The same thing cannot be said (IMHO) for an installer package. Eh? Why not? Why wouldn't you be able to integrate an installer package with other free software? It's possibly worth noting that d-i's habit of assembling itself out of component parts at run-time makes it not all that dissimilar to contrib installer packages, except for the nature of the material it acquires. ;-) And, speaking of d-i, here's another thing I've been unable to understand. Someone please enlighten me, because I feel sure I must be missing something: What possible use would it be to integrate ndiswrapper into debian-installer? Wouldn't the user _still_ have to provide a Windows driver in some format usable by ndiswrapper? Wouldn't that still have to come from some external source, like a web site or a floppy disk? And if so, why would it be a hardship to get ndiswrapper from an external source at the same time? (I have no particular position on ndiswrapper in main per se, and I haven't read all of this enormous thread.) It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Without ndiswrapper integration, the user has to figure out that this thing called ndiswrapper that they've never heard of is needed, then go and get it and prepare a floppy disk with all the right stuff on it. This is a lot more error-prone, may not always be possible (they may not have any access to the Internet other than via the system they're trying to install), and even if possible raises the difficulty bar quite significantly beyond insert the floppy disk provided with your network card. Of course, it would be possible to prepare a special ndiswrapper driver image that could teach the installer how to do this without having to have it in the core installer; so ndiswrapper doesn't *have* to be in main for this to work, although it would make things easier from the point of view of making this trick work out of the box with Debian CDs. I can understand the appeal of having ndiswrapper on the installer image, but only if the image also has drivers to use with it. Are we talking about CIPE again? Is CIPE useful for an installer? Not in any way I can imagine. It's true that the trick outlined above is only (AFAIK) useful for getting your hardware to work using non-free software. Actually, I'm not certain whether packages in main are allowed to Suggest packages outside main. If not, the usual workaround is for ndiswrapper to instead declare an Enhances relationship on foo. Traditionally Suggests have been OK, although one of the main reasons why Enhances was invented as a reverse-Suggests was to allow all references to non-free packages to be removed from main's metadata. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 08:32:46AM +, Colin Watson wrote: It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Note though that the code to grab the NDIS driver off the disk/cdrom/network and install it onto the filesystem would fit precisely under the installer package definition and thus belong in contrib, even with ndiswrapper in main... Of course, the d-i support to grab firmware from Debian's non-free or similar would presumably have the same restriction too. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 10:27:48PM +1000, Anthony Towns wrote: On Thu, Mar 02, 2006 at 08:32:46AM +, Colin Watson wrote: It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Note though that the code to grab the NDIS driver off the disk/cdrom/network and install it onto the filesystem would fit precisely under the installer package definition and thus belong in contrib, even with ndiswrapper in main... I suspect any code that handled driver disks would (or at least could, pretty plausibly and sensibly) be focused along the lines of supporting free drivers that didn't ship with the last Debian release. Even with Debian's highly modular kernels, we don't always include support for every single free driver out there, and it would not be at all unreasonable or unlikely for somebody to publish a driver disk that includes some free driver module backported to the kernel in Debian's most recent release so that you could install systems with the corresponding hardware. If somebody then came along and wanted to add a few lines of code to piggyback NDIS or firmware support onto the back of that, I find it surprising that we'd feel it worth punting that off to contrib; all the interesting stuff would be in the generic driver disk handling, and NDIS or firmware support would be an extra entry in a case statement or something like that. In fact, I could well believe that some firmware would fall into the scenario in the previous paragraph, being free but just not supported by the most recent Debian release, or you need a newer version for your card or something. I suppose it *could* be split out, although - insofar as I can make this claim of hypothetical code - it seems to me that it'd complicate things substantially to do so. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Hello, Thomas Bushnell BSG wrote: Please, can we answer the question? If it's not useful then say, Yes, it's not useful, but that's not relevant. If it's useful say, It's useful, which should settle the case. Instead, I hear, Nyaa nyaa nyaa, I'm not goiny to say whether it's useful. My impression is that the question you're asking is not that easy to answer with yes or no - neither in general nor in this special case. I assume you agree that the answer strongly depends on the purpose ndiswrapper is intended to use for. There is the one position saying, yes ndiswrapper is useful and the other saying that it's not. Both positions where supported with arguments and are IMHO *both* eligible. IMHO Henning Makholm did fairly well describe the essential traits of both positions ([EMAIL PROTECTED]). I think it's a question of respecting the opinion of others, of accepting that others say No, ndiswrapper isn't useful. It should go into contrib whereas yourself may think it's useful (independent of it's suitability). And experiencing the nice diversity of opinions in this thread I can't say at all whether it is usefull or not without offending other's opinions. Beside the discussion whether your question is relevant at all for the decision this is perhaps a reason why you get an indifferent answer Nyaa nyaa nyaa, I'm not going to say whether it's usefull. You just can't imagine all possibile applications Debian might be used for - at least I can't (and don't aim to do so). That's why I can't simply say it's useless or not. I am not a Debian developer, but isn't the conflict itself in this thread an argument why you shouldn't consider the criterion of usefulness *at* *all* when deciding about putting a package in main or contrib? To find a consensus about the usefulness of a package is IMHO potentially far to oppositely charged. I wouldn't burden the developers to discuss such tedious questions over and over again in order to decide whether a package belongs into main or contrib. IMHO clearly technical criteria are instead more adequate to decide such questions, as suggested by Henning Makholm ([EMAIL PROTECTED]). Regards Micha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Eduard == Eduard Bloch [EMAIL PROTECTED] writes: Eduard And I have never understood why the apt-setup questions Eduard for contrib and non-free have been put into the same Eduard dialog. The only possible reason is that the users that Eduard have deliberately decided to not use non-free software Eduard (because of political reasons) should never come in Eduard touch with it and therefore all possible ways that may Eduard lead to the dark side should be hidden. OTOH the last Eduard action is already a kind of limiting the freedom of Eduard choice. And if not (eg. is explained as something else, Eduard political correctness or whatever) then it still means Eduard making life or users harder and is a violation of Eduard DSFG. Pushing users for ideological reasons sucks. I believe installer packages for non-free software still go in contrib, because they are considered GPL compliant. So if you want to be sure you won't accidently get confused with non-free software (I have done so from time to time), this can be achieved by eliminating all non-free software from the search results produced by apt-cache search. This requires eliminating contrib as well as nonfree. Example, in sarge: flashplugin-nonfree and quake2-data is in contrib. There are also other suspicious packages in sarge maintained by the GA group, eg. acl-installer, and int-fiction-installer. I think these should belong in a separate category then ndiswrapper, because, unlike ndiswrapper, they are not even complete packages without non-free software, and this will never change for the lifetime of the installer package. On the other hand, the possibility exists that somebody is using ndiswrapper, either now or in the future with entirely DFSG software. Even if nobody does this, it is still possible to integrate ndiswrapper with free software (such as debian-installer)[1]. The same thing cannot be said (IMHO) for an installer package. Whether this means ndiswrapper should go in main, flashplugin-nonfree should go in non-free, or some other solution, I am undecided. Note: [1] One way, I think, of looking at ndiswrapper is that it is a set of DFSG hooks to allow integration with add-on nonfree software. I believe there are similar hooks in the Linux kernel. Some of these hooks can only be used by non-free software (e.g. uploading of nonfree firmware). This doesn't make the kernel contrib. Why should it be any different if you split the hooks out into a separate user space and separate kernel space package? Would kernel code for uploading firmware suddenly become contrib if you split it out from the kernel source and made it a compilable module? Why so/not? Would the situation be any different if there was a package in main that depended on ndiswrapper-utils, but made use of such non-free drivers optional? If ndiswrapper moved to contrib would this package have to move to? I am not providing an opinion here, but I didn't notice these issues being discussed earlier. back to your regular program... -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[Brian May] I think these should belong in a separate category then ndiswrapper, because, unlike ndiswrapper, they are not even complete packages without non-free software, and this will never change for the lifetime of the installer package. Never underestimate the Debian universe's collective ability to contrive a justification for something. It could be said that an installer for some random bits that can't even be carried on non-free should actually go in main because, in some hypothetical alternate universe future scenario, somebody _might_ reimplement the non-free component in a free way, and furthermore, it might make sense to install it using the scripts in the wrapper package rather than packaging it natively. Perhaps the developer of the free replacement would like to have the wrapper package on his system in order to facilitate testing. Even if nobody does this, it is still possible to integrate ndiswrapper with free software (such as debian-installer)[1]. The same thing cannot be said (IMHO) for an installer package. Eh? Why not? Why wouldn't you be able to integrate an installer package with other free software? And, speaking of d-i, here's another thing I've been unable to understand. Someone please enlighten me, because I feel sure I must be missing something: What possible use would it be to integrate ndiswrapper into debian-installer? Wouldn't the user _still_ have to provide a Windows driver in some format usable by ndiswrapper? Wouldn't that still have to come from some external source, like a web site or a floppy disk? And if so, why would it be a hardship to get ndiswrapper from an external source at the same time? I can understand the appeal of having ndiswrapper on the installer image, but only if the image also has drivers to use with it. Are we talking about CIPE again? Is CIPE useful for an installer? Some of these hooks can only be used by non-free software (e.g. uploading of nonfree firmware). This doesn't make the kernel contrib. No, because the kernel as a whole can do a great many things beyond just loading firmware. If the kernel existed only for that one purpose, its status would be just as controversial, for the same reasons. Would kernel code for uploading firmware suddenly become contrib if you split it out from the kernel source and made it a compilable module? Why so/not? Yes, because at that point the separate package isn't useful on its own.[*] The kernel as a whole is useful on its own. [*] Note also that you may have chosen a bad example. Free firmware _does_ exist - see the aic7xxx and sym53c8xx drivers. Actual firmware source code, and miniature assemblers for same, are shipped in the standard kernel. In other words, Adaptec and NCR, _many_ years ago, proved that those who say DFSG-compliant firmware is impossible or impractical are wrong. However ... I don't know whether the aic7xxx and sym53c8xx drivers have been updated to be able to load firmware via the kernel hooks, or whether they still just have it built into the module binaries. The rule here is that if something is useful without non-free software, but _incidentally_ can also make use of non-free software, nobody has a problem with it in main. If the only reason for something to exist is to use it with non-free software, that's where the arguments come in. Remember that main / contrib is not an issue of whether a given package is free. The only issue is whether the package is useful without non-free software. Would the situation be any different if there was a package in main that depended on ndiswrapper-utils, but made use of such non-free drivers optional? If ndiswrapper moved to contrib would this package have to move to? No, package foo can stay in main, because it wouldn't be a hard Depends relationship (or it shouldn't be, anyway), it would be a Suggests or possibly Recommends, depending on how common it is to use foo without ndiswrapper. Actually, I'm not certain whether packages in main are allowed to Suggest packages outside main. If not, the usual workaround is for ndiswrapper to instead declare an Enhances relationship on foo. The semantics are similar. Either way, if foo still does useful things for some users without ndiswrapper or its drivers, it can perfectly well go in main. Peter signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Hamish Moffatt said: flashplugin-nonfree itself contains scripts which I presume meet the DFSG. Do you think we should put it in main? I assume this is a troll, and you have not bothered to read any of the other messages in this tediously long thread. ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. (And do what? Display a usage screen? Anything more?) This has already been answered. Please feel free to read the archives. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: The reason this interests me is that this seems to be the key question; it seems to me that if something is *now* not useful for free-software-only systems, it might be better placed in contrib (and the installer fixed, and perhaps not placed in contrib until after the installer is fixed), and only moved to main if/when there is a reason. I'm guessing this thread reset means you didn't like the answers you were getting? I'm stopping for now, as this is getting tedious. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Tue, Feb 28, 2006 at 10:31:17AM +, Stephen Gran wrote: This one time, at band camp, Hamish Moffatt said: flashplugin-nonfree itself contains scripts which I presume meet the DFSG. Do you think we should put it in main? I assume this is a troll, and you have not bothered to read any of the other messages in this tediously long thread. It's not a troll. In the quote that you trimmed, you said that all dependencies are expressed as Depends: in the control file. I explained why this is not the case. Please acknowledge that you understand this. ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. (And do what? Display a usage screen? Anything more?) This has already been answered. Please feel free to read the archives. I have read the whole thread, and it hasn't been answered adequately. Your argument is simply that an unuseful driver is enough reason to put ndiswrapper in main. You argue that contrib is not enough because then it won't be available in the installer. This must mean that it's needed at install time to use non-free drivers. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[Hamish Moffatt] flashplugin-nonfree itself contains scripts which I presume meet the DFSG. Do you think we should put it in main? [Stephen Gran] I assume this is a troll Your refusal to answer his question is itself an answer. ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. (And do what? Display a usage screen? Anything more?) This has already been answered. Please feel free to read the archives. Hamish, to save you the trouble of reading the archives, I'll tell you the answer. It doesn't display a usage screen. It provides an API for drivers to use. Of course, since it's just an API for drivers, it does nothing if you don't have a driver. Well, it uses some of your kernel memory, and it might print a status line to the kernel log. But It does nothing is obviously not an answer Stephen wanted to give. Much better to imply that a more satisfying answer might exist somewhere else in the thread. (It doesn't.) You know what would be great, though? It would be great if some user who uses ndiswrapper without non-free software, or indeed without any drivers at all, would speak up. Then we could stop arguing about whether he exists. 'Cause, frankly, I don't think he does. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Hamish Moffatt said: On Tue, Feb 28, 2006 at 10:31:17AM +, Stephen Gran wrote: This one time, at band camp, Hamish Moffatt said: flashplugin-nonfree itself contains scripts which I presume meet the DFSG. Do you think we should put it in main? I assume this is a troll, and you have not bothered to read any of the other messages in this tediously long thread. It's not a troll. In the quote that you trimmed, you said that all dependencies are expressed as Depends: in the control file. I explained why this is not the case. Please acknowledge that you understand this. Of course I understand this. In another post I explained that examples of packages that should be in contrib are things like installers for non-free software. Since flashplugin-nonfree is exactly one of these, I have to assume you didn't read the rest of the thread, and were just trolling. Sorry if you just missed it under all the noise. Since ndiswrapper is not an installer for non-free software, I don't actually see what flashplugin-nonfree hass to do with the discussion. OK? ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. (And do what? Display a usage screen? Anything more?) This has already been answered. Please feel free to read the archives. I have read the whole thread, and it hasn't been answered adequately. Your argument is simply that an unuseful driver is enough reason to put ndiswrapper in main. You argue that contrib is not enough because then it won't be available in the installer. This must mean that it's needed at install time to use non-free drivers. No, this was someone else's argument. My argument is that ndiswrapper successfully enables a kernel API to allow drivers that use an NDIS stack to communicate with the linux network stack. It does this, whether or not those drivers are ever used. Non-free drivers need ndiswrapper to execute on linux. ndiswrapper does not need non-free drivers. Does that make my position clear enough? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. The crip driver is actually not made for a specific piece of hardware; it's really an encryption layer. I fail to see whether if something works better is important. Using OpenOffice.org also works better than using Microsoft Office under wine, yet I have seen _many_ people asking whether it is possible to do so. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. I would appreciate hearing why you would think that it should be treated the same. There is a driver, it is free, it works with ndiswrapper, so there is a use case. Why should one perception on its usefulness be relevant? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 03:23:05PM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. All right, who pushed the 'thread reset' button? Unlike some, I do not have a perfect memory. Moreover, I do not appreciate vague we already discussed this references. I've read the damn thread; I ask the question because the previous discussion did not seem to actually *answer* the question. It's been answered a zillion times already, you just didn't accept the answer as valid. That's okay, but re-asking it again and again isn't going to give you a different answer. Can you please agree to disagree already? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote: If there are no uses of it (actual *uses*, where it is *useful*) with free programs, then it sure seems like a wrapper for non-free programs. You want a useful use case of the NDIS CIPE driver? Allright, I'll give you one. I'm a GNU/Linux consultant. It is my job to help people with installing, configuring, and generally using GNU/Linux. I prefer to use non-free software as little as possible, and most of my own systems currently have no non-free software installed (although not all of them). On the other hand, I have no say over what a customer would want; and if my choice is to either help them out with non-free software or loose the contract, then I will do the former. That still doesn't mean that I'd like to use non-free software myself, so I'll avoid it if possible. The CIPE driver doesn't actually need hardware, since it is an encryption layer. As such, I can use it as a test-case for ndiswrapper, to find out how the latter works and to actually be able to test whether I set it up correctly. If a customer should at one point ask me to help them out with setting up ndiswrapper, I can then first experiment on my own with the CIPE driver, and then help them out with their non-free driver. Want another one? Here goes. A kernel hacker might be interested in helping out to hack on ndiswrapper itself, but not be very interested in having their laptop crash every five minutes by loading experimental versions of the driver. An obvious solution would be to use a virtualization environment like qemu, but then you can't use a driver that requires specific hardware. The fact that CIPE exists, which does not have any hardware requirements, can allow you to test stuff without having an unstable computing environment for other things. Right, so there's two examples. But then again, the above two are all based on the assumption that it is impossible to test out ndiswrapper without an NDIS driver -- and that having something in main for testing purposes only would be something some zealot might not accept (for clarity, I'm not claiming you are a zealot of any sort). So let's think of another use case: I don't know about you, but personally, I had never heard about the CIPE driver before, while everyone here seems to know ndiswrapper already. It is conceivable that projects which attract a high level of publicity (such as ndiswrapper) also attract a lot more developers than projects which do not (such as CIPE). Indeed, it would seem that there are currently only a handful of developers working on CIPE. Now consider that there is a change in some future version of the kernel, which is security-related, and which breaks the kernel API wrt network drivers incompatibly. While not incredibly regular, it most certainly is not unlikely, either. Depending on the complexity of the change, it might be that it will take a considerate effort to update drivers to the newer Linux API, which the handful of people working on the CIPE driver will take ages to do. The ndiswrapper folks, however, because of their relatively higher number of developers, might get the job done a lot sooner. People who don't want to be vulnerable (which might be all of them, seen as how this is about crypto intended for use in VPN environments) will want to use the ndiswrapper driver until the native driver has been updated. There, that's three. I'm sure you can come up with more use cases yourself; and I'm sure I can come up with more if you think none of the above are any convincing. In the mean time, I'll tell you that just because you can't come up with any reasonable use case of free software without non-free software, even if the main purpose of that free software is to use that non-free software, that this doesn't mean there isn't any such use case. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 27, 2006 at 10:04:59AM -0800, Adam McKenna wrote: Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. One point that nobody raised so far: _reliable_ working on ndiswrapper depends on the 16k-stack patch that is not available in Debian AFAIK. Without that patch, drivers requiring ndiswrapper (being free or not) only work by pure chance. So whatever the Depends: line says, ndiswrapper for any practical purposes depends on software that is not in main. So the question is: does a piece of software, that is known not to work reliably and will never work reliably with the (Linux) kernels shipped by Debian, have a place in main? There are efforts from time to time to make the 4K stack the default on i386 upstream; if/when that happens, ndiswrapper will stop working with stock Linux kernels. What will be the answer then? Other distributions like Fedora have already switched to 4K stacks... Gabor p.s. I personally still do not care whether ndiswrapper is in main or in contrib... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:21:56PM -0800, Thomas Bushnell BSG wrote: Stephen Gran [EMAIL PROTECTED] writes: In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. Since ndiswrapper's main purpose is to create a kernel API to allow drivers designed for a different API to communicate with the kernel, I don't think this counts as a wrapper. ndiswrapper does what it sets out to do, whether or not any software (free or not) uses that API. That's curious. It's described as a wrapper in the package name, the Debian package description, and the upstream webpage. In both cases, it is specifically documented as being for use with non-free software. It's specifically said that its purpose is to deal with the fact that some vendors refuse to release hardware specifications and that for such hardware, users are stuck with non-free NDIS drivers. While we are trusting the package maintainer, surely we should trust the package maintainer to be correctly documenting the program? However, if the description is incorrect, then perhaps it should be changed. I don't really know, because I'm not an expert on the technical question here. There are a few ways to interpret the word wrapper. Ndiswrapper could certainly be seen as a wrapper of sorts, but not in the way that policy means. A wrapper, as used in policy, is a script or small executable that will set up the environment (LD_PRELOAD, LD_LIBRARY_PATH, PATH, ...) and then run the actual binary. /usr/bin/firefox on a Debian system, for example, is a wrapper in the meaning that policy is talking about. ndiswrapper is not. No, the question is, is ndiswrapper a functionally complete program? Are you saying that ndiswrapper is useful all by itself, without any drivers at all? I have asked this question before, but didn't get an answer; I really don't know. What functions does it provide, in the absence of an NDIS driver? I've given a few answers to that question in another post I just posted; here, I'd like to add that the function anything provides is irrelevant if you are discussing its freeness. If someone gives me a horse, then this is a free horse (as in beer). Yet, since I don't know how to ride a horse, I'll have to find someone who will teach me how to do so, which may well cost money. This will make the adventure be not free (as in beer) to me; but I could of course also just be someone who enjoys watching horses, without riding them. Does that make it a non-free horse? The same reasoning can be applied to ndiswrapper's freeness (as in speech). Ndiswrapper itself is free, and does not require the use of any non-free software to be run. Yet, if you have no free drivers to use ndiswrapper, it could be argued that it is not really useful. But usefulness is something that Debian considers in deciding whether something is free or not (why else do you think we compile KDE, GNOME, mozilla, *and* emacs for m68k?). If it runs, can do something as designed, then it is ok for it to go into main. Ndiswrapper complies with those requirements. [...] -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote: The CIPE driver doesn't actually need hardware, since it is an encryption layer. As such, I can use it as a test-case for ndiswrapper, to find out how the latter works and to actually be able to test whether I set it up correctly. If a customer should at one point ask me to help them out with setting up ndiswrapper, I can then first experiment on my own with the CIPE driver, and then help them out with their non-free driver. In this case I do not want to hire you as a consultant ever, thank you very much. You should know that Windows gives ~16k stack to network drivers, while current Linux+ndiswrapper only gives ~6k if you are lucky, and ~4k if/when the 4K stacks option becomes the default. So even if your test case works it _does not_ give any indication that any other non-free driver will also work. A non-free driver that happens to use 10k stack will work perfectly on Windows but will not work on the kernels shipped by Debian at all. A kernel hacker might be interested in helping out to hack on ndiswrapper itself, but not be very interested in having their laptop crash every five minutes by loading experimental versions of the driver. An obvious solution would be to use a virtualization environment like qemu, but then you can't use a driver that requires specific hardware. The fact that CIPE exists, which does not have any hardware requirements, can allow you to test stuff without having an unstable computing environment for other things. You are not serious that such a developer would be incapable to locate the ndiswrapper source if it was in contrib instead of main, are you? Also, such a developer would be a fool to use the Debian-packaged version of ndiswrapper instead of the latest upstream snapshot, given the long time between stable Debian releases. Now consider that there is a change in some future version of the kernel, which is security-related, and which breaks the kernel API wrt network drivers incompatibly. Unlikely, whoever breaks in-kernel API is responsible for fixing all in-kernel drivers as well. And IMHO there are more Linux network driver maintainers than ndiswrapper maintainers, and they are quite capable of morphing a huge number of drivers at once. On the other hand, the kernel has already broken compatibility with ndiswrapper (16k stacks were never part of the official kernel) and there is effor to break it even more (if you want to look at it from this angle). Just look up the 4k stack flamewars in LKML archives. Fedora already ships it's kernels with 4k stacks. Please stop these excuses. ndiswrapper will remain in main because the sky is blue is a lot more acceptable reasoning than anything that popped up in this thread so far. If you _really_ want to help ndiswrapper, then work on solving the 4k-stack issue; that would help a _lot_ more than this silly thread. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Bug#353277: ndiswrapper in main
On Tue, Feb 28, 2006 at 03:25:37PM +0100, Gabor Gombas wrote: On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote: The CIPE driver doesn't actually need hardware, since it is an encryption layer. As such, I can use it as a test-case for ndiswrapper, to find out how the latter works and to actually be able to test whether I set it up correctly. If a customer should at one point ask me to help them out with setting up ndiswrapper, I can then first experiment on my own with the CIPE driver, and then help them out with their non-free driver. In this case I do not want to hire you as a consultant ever, thank you very much. You should know that Windows gives ~16k stack to network drivers, while current Linux+ndiswrapper only gives ~6k if you are lucky, and ~4k if/when the 4K stacks option becomes the default. So even if your test case works it _does not_ give any indication that any other non-free driver will also work. No, but it will allow me to find out how the bloody thing is _supposed_ to work, even without having direct access to the customer's hardware. There is nothing to prevent me from experimenting a bit more at the customer's site; but at least this can give me a headstart. [...] A kernel hacker might be interested in helping out to hack on ndiswrapper itself, but not be very interested in having their laptop crash every five minutes by loading experimental versions of the driver. An obvious solution would be to use a virtualization environment like qemu, but then you can't use a driver that requires specific hardware. The fact that CIPE exists, which does not have any hardware requirements, can allow you to test stuff without having an unstable computing environment for other things. You are not serious that such a developer would be incapable to locate the ndiswrapper source if it was in contrib instead of main, are you? The question was not whether I developer would be able to locate the source if it were in contrib; the question was whether there is a real use case of the NDIS version of the CIPE driver. I gave you one. Well, three actually. [...] Now consider that there is a change in some future version of the kernel, which is security-related, and which breaks the kernel API wrt network drivers incompatibly. Unlikely, whoever breaks in-kernel API is responsible for fixing all in-kernel drivers as well. CIPE is currently not an in-kernel driver. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote: One point that nobody raised so far: _reliable_ working on ndiswrapper depends on the 16k-stack patch that is not available in Debian AFAIK. Without that patch, drivers requiring ndiswrapper (being free or not) only work by pure chance. So whatever the Depends: line says, ndiswrapper for any practical purposes depends on software that is not in main. I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have never heard of the '16k-stack patch'. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 28, 2006 at 09:36:46AM -0800, Adam McKenna wrote: On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote: One point that nobody raised so far: _reliable_ working on ndiswrapper depends on the 16k-stack patch that is not available in Debian AFAIK. Without that patch, drivers requiring ndiswrapper (being free or not) only work by pure chance. So whatever the Depends: line says, ndiswrapper for any practical purposes depends on software that is not in main. I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have never heard of the '16k-stack patch'. The thing is: Windows has a 16k stack for drivers. The Linux kernel has either a 4k + 4k stack or an 8k stack, depending on what version of the kernel you use. Most drivers don't need 8k stack (some might even work with 4k too), but some do, thus you need to patch the kernel to provide 16k stacks (this is really bad for other reasons). Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: The reason this interests me is that this seems to be the key question; it seems to me that if something is *now* not useful for free-software-only systems, it might be better placed in contrib (and the installer fixed, and perhaps not placed in contrib until after the installer is fixed), and only moved to main if/when there is a reason. I'm guessing this thread reset means you didn't like the answers you were getting? No, it's that people kept on refusing to answer simple questions, and after a bit of that, they said they had already answered them (when they in fact had not), and now they complain that it's a thread reset to continue to ask the questions. Look, if the position is that ndiswrapper is, at present, only useful with non-free software, but it should, even so, be in Debian main, I'm prepared to entertain that possibility. But I can't even figure out what you *are* saying, because everytime I ask, people start getting cagey. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Wouter Verhelst [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. The crip driver is actually not made for a specific piece of hardware; it's really an encryption layer. I fail to see whether if something works better is important. Using OpenOffice.org also works better than using Microsoft Office under wine, yet I have seen _many_ people asking whether it is possible to do so. Actually, I addressed exactly this already. If there is some remote difference to crip-with-ndiswrapper rather than crip-directly-in-linux which makes anyone's life better, than I'm happy to say that ndiswrapper is clearly useful for a piece of free software. But when I ask this question: exactly what are the advantages here to running crip with ndiswrapper instead of directly? nobody will answer me. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. I would appreciate hearing why you would think that it should be treated the same. There is a driver, it is free, it works with ndiswrapper, so there is a use case. Why should one perception on its usefulness be relevant? Please, can we answer the question? If it's not useful then say, Yes, it's not useful, but that's not relevant. If it's useful say, It's useful, which should settle the case. Instead, I hear, Nyaa nyaa nyaa, I'm not goiny to say whether it's useful. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Wouter Verhelst [EMAIL PROTECTED] writes: It's been answered a zillion times already, you just didn't accept the answer as valid. That's okay, but re-asking it again and again isn't going to give you a different answer. My question was not answered. Is ndiswrapper useful on a free-software-only system? That's my question. You insisted that this question is irrelevant, but that's not the same thing as answering it. It simply has not been answered as far as I can tell. I have been told that it's a thread reset to ask it, I have been told that it's irrelevant what the answer is, and so forth. It's frustrating, because I feel as if the answer is right there, on the tip of people's tongues, and they are refusing to just say here is the case where ndiswrapper enables something that would not otherwise be possible or there are no such cases now that I can think of. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Wouter Verhelst [EMAIL PROTECTED] writes: There are a few ways to interpret the word wrapper. Ndiswrapper could certainly be seen as a wrapper of sorts, but not in the way that policy means. A wrapper, as used in policy, is a script or small executable that will set up the environment (LD_PRELOAD, LD_LIBRARY_PATH, PATH, ...) and then run the actual binary. /usr/bin/firefox on a Debian system, for example, is a wrapper in the meaning that policy is talking about. Wow, all that from one sentence. I don't see policy saying anything of the kind. I can see that this is one interpretation of it, but I can't see any reason to think this is the preferred one. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: Look, if the position is that ndiswrapper is, at present, only useful with non-free software, but it should, even so, be in Debian main, I'm prepared to entertain that possibility. But I can't even figure out what you *are* saying, because everytime I ask, people start getting cagey. Looking at the first packages alphabetically in (main/)admin, one could ask the same question of a great many packages. The aboot* packages assume you have DEC/HP's SRM firmware on your machine. acorn-fdisk assumes that you have the Acorn RISC OS. acpid assumes you have an ACPI-compatible BIOS. adtool is for a piece of software written by Microsoft, identified by a trademark registered to Microsoft. What is the difference between ndiswrapper and these tools that assume or require you have non-free software in your system, and are written to let Debian interoperate with that non-free software? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: Looking at the first packages alphabetically in (main/)admin, one could ask the same question of a great many packages. The aboot* packages assume you have DEC/HP's SRM firmware on your machine. acorn-fdisk assumes that you have the Acorn RISC OS. acpid assumes you have an ACPI-compatible BIOS. adtool is for a piece of software written by Microsoft, identified by a trademark registered to Microsoft. What is the difference between ndiswrapper and these tools that assume or require you have non-free software in your system, and are written to let Debian interoperate with that non-free software? I'm not sure there is a difference, but I'm not going to accept as a premise that there are no categorization mistakes, especially when I'm trying to figure out whether there has been one in this case or not. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Scripsit Tom Rauchenwald [EMAIL PROTECTED] I am not a DD, so maybe my opinion is idiotic. But: the thing is free, it allows people to use non-free drivers, but it is entirerly up to the user to use those drivers. I don't know, but for me this discussion is pointless. Does ndiswrapper require non-free packages? no. Well, that's the point of contention. I think it is not meaningful to speak about whether the software, viewed as a bag of bits that live in a vacuum, requires this or that other software. The question only makes sense when we put it in a context and ask: Does ndiswrapper require a non-free software *to do its thing*? Unfortunately the answer depends on what one takes ndiswrapper's thing to be. I think the schism in the current thread is based mostly on differing intitial assumptions about how one views the purpose of ndiswrapper. Case 1: Ndiswrapper is for users who have hardware XYZ; it promises to make this hardware useful with Linux. It cannot keep this promise without also having a driver, and the only existing driver for XYZ is non-free. From this viewpoint it is clear that ndiswrapper should be in contrib. Case 2: Ndiswrapper is for users who already have some driver software written to the NDIS specification, never mind where they got it, and want to run this driver. From this point of view, ndiswrapper is akin to a programming language implementation, or a shared library - it can be in main independently of the freedom of any programs that use it. Thus from this perspective it is clear that ndiswrapper should be in main. The tragedy is that both viewpoints - I want to use this hardware and I want to run this driver - are possible and legitimate and the package descriptions does not clearly invalidate one of them, yet they lead to incompatible conclusions about where the package should be filed. if the user decides to use non-free drivers, then it's his choice, not debian's, so what. The point of the distinction between main and contrib is to support the user in his choice. We want that if a user finds package that promises some functionality in 'main', then he can ideed get that functionality without resorting to software outside main. That is why the differing views of what functionality ndiswrapper promises is important. Personally I favor using a test somebody invented an earlier time we discussed a similar problem: To determine whether A requires B for the purpose of the social contract, assume hypothetically that B was free and packaged, and then ask whether ordinary packaging practice would lead to A a declaring a Depends: relationship on B in that situation. This test would allow us to move the question into the technical realm. I think that according to this test, we would conclude that ndiswrapper does not require the driver it wraps. If we had a handful of prackages that provided free NDIS drivers, the driver packages would depend on ndiswrapper, not the other way around. We don't let libfoo depend on program that uses libfoo, or let ruby depend on package that provides a ruby script, even though we _could_ do this with virtual packages if we thought it would be useful. This is just parallel to the fact that we can have a library in main without having any clients for the library in main. An example is libc5 - it exists in sarge *only* to support old applications, presumably non-free and certainly not in main themselves. Yet I have not heard anybody suggest that it ought to have been in contrib for that reason. -- Henning Makholm ... a specialist in the breakaway oxidation phenomena of certain nuclear reactors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
#include hallo.h * Thomas Bushnell BSG [Mon, Feb 27 2006, 12:53:12PM]: I certainly do not think that the installer should be limited to software in main (and perhaps not even software in main+contrib, provided it still works correctly without non-free things around). Is that the root issue? Are there people who insist that the installer should be limited to things in main? I think this is the worst problem. Contrib never has been a section with strong separation, it is just subjective line that has been drawn between main and contrib. Therefore this whole thread is almost pointless. However, some people like to define Debian just as main and use the main section as the single acceptable set of free software. Which is, of course, wrong, because requirements for contrib are defined by DFSG, exactly as for main. And I have never understood why the apt-setup questions for contrib and non-free have been put into the same dialog. The only possible reason is that the users that have deliberately decided to not use non-free software (because of political reasons) should never come in touch with it and therefore all possible ways that may lead to the dark side should be hidden. OTOH the last action is already a kind of limiting the freedom of choice. And if not (eg. is explained as something else, political correctness or whatever) then it still means making life or users harder and is a violation of DSFG. Pushing users for ideological reasons sucks. Eduard. -- miro ich bin ja auch ein sehr ueberzeugter windoze nutzer miro ja windoze ist toll! miro samba ist scheisse miro ich versteh nicht warum ihr das nicht begreift... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Wed, Mar 01, 2006 at 12:06:51AM +0100, Eduard Bloch wrote: However, some people like to define Debian just as main and use the main section as the single acceptable set of free software. Which is, of course, wrong, because requirements for contrib are defined by DFSG, exactly as for main. According to the SC, contrib is not part of Debian. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-18 13:42:38, schrieb Robert Millan: On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote: Does the lack of a free driver which can be used with ndiswrapper mean that it is impossible to use ndiswrapper with such a free driver, should one eventually be written? If a free driver/datafile/whatever existed, it would be possible to run Foo without requiring non-free stuff, therefore it belongs to main If someone use only main she/he will never install ndiswraper and will not code a free version. Let ndiswraper stay in main will animate developers to code stuff. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Am 2006-02-18 13:58:20, schrieb Jérôme Marant: Robert Millan [EMAIL PROTECTED] writes: Is your point that contrib should therefore be empty and has no reason for existance? If not, please explain me the difference between ndiswrapper and all the other packages that belong to contrib and already are in. Contrib is for free packages that have a real Depends: or Recommends: dependency on a non-free package. If there isn't any reason for ndiswrapper to depends on a non-free package, then there is no reason to move it to contrib. Right, and because it DOES NOT depends on non-free it should stay in main. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 11:13:19, schrieb Daniel Stone: On Sat, Feb 18, 2006 at 06:12:36PM +0200, Lars Wirzenius wrote: la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti: What's the purpose of an assembler without assembly code to use it on? It can be used, for example, to assemble code you write yourself. That is, after all, the primary purpose of programming tools: to help programmers develop programs. Surely ndiswrapper can also run drivers you write yourself. Right and most people will not write a driver, IF ndiswraper is not in main. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 02:11:30, schrieb Peter Samuelson: No, the point of Java is to allow users to run Java software, which they may or may not have written themselves, and which may or may not be free software. Examples of all permutations of the above are really ndiswraper is to allow users to write drivers, which they may or may not have written themselves and which may or may not be free software. So, -- what now? If you give peoples not the chance to do it, OSS has allready lost. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:40:44, schrieb Michael Poole: Again, there is no mention of pointless software in Policy -- if there were, some large fraction of main would be moved because it is duplicative, trivial or otherwise pointless to have. Likewise, there is no mention of Windows driver developers ... who really wish they could conveniently test their Windows drivers on Debian. Policy only says the packages in main must not require a package outside of main for compilation or execution. This mean, IF I HAVE written a driver, it will not go into main even if IS GPLed because ndiswraper is in contrib. In clear: Such driver will never be written. Michael Poole Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 00:44:29, schrieb Josselin Mouette: I wonder why all people go on trying to build up tons of different fallacious reasonings to keep firmwares in main. Non-free is here for a reason, we just have to use it. Technical solutions to have the driver in the kernel or in contrib, and the firmware in non-free, exist. If I have a hardware which comes with a CD/DVD/Floppy with the firmware and there is a free firmware loader but it must stay in contrib it will not realy productiv. It is a big disavantage. I think, programs and packages which help to use firmware and drivers for hardware, where the firmware and drivers can be obtained from the ORIGINAL media shiped with the hardware should stay in main because Debian has nothing to do with shiping of firmware and drivers. It is generaly the responsability of the hardware manufacturers. In general: 1) Debian should provide FREE (GPLed) wraper and firmware (userspace) loader. 2) drop non-free because it stress Debian. Oh yes, I read often that $USER glame the Linux-Community not to ship Drivers!!! - Arghhh!!! I know tonns of Hwardware, where I have NO drivers or software in Winblow and I need the, from the hardware manufactirer provided DriverCD. - So why should Debian care about firmware and drivers? We can provide wraper and loaders and thats is. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 01:52:05, schrieb Marco d'Itri: On Feb 19, Josselin Mouette [EMAIL PROTECTED] wrote: I wonder why all people go on trying to build up tons of different fallacious reasonings to keep firmwares in main. Because it's good for Debian and is good for our users. Sorry Marco, but even under Windows, there are many Drivers missing for Hardware. You need the from the hardware manufacturers DriverCD. Why should Debian care about it? If you like to see $USER using Hardware, you know they have the DriverCD and you can create a wraper or loader for the hardware. I have done this for two enterprises here in Strasbourg and I use cabextract to get the Firmwares out of the Windows-installer. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Hi Thomas, Am 2006-02-18 17:18:37, schrieb Thomas Bushnell BSG: Regardless, we already have a commitment: to remove non-DFSG bits from the main archive. What dou you think about the idea, that because non-free drivers and firmwares are droped from main we write wrapers and loaders which GET the drivrs and firmwares from the manufacturer provided DriverCD's. I have allready done this for two Enterprises here in Strasbourg using cabextract or unzip to get the stuff... I have done this wit an experimental win32codec-graber whichget the windows codecs from the original Win95, Win98, Win2000 and WinXP CD's. This will solv all problems distributing non-free stuff because $USER which want to use non-free stuf must provide a legal licence to use it which is generaly fullfiled if you have the Win-CD's. Just an Idea. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:46:16, schrieb Josselin Mouette: Please stop these lies. I repeat: technical solutions do exist. For hardware unnecessary at installation's first stage, it is only a matter of making non-free available. ACK! For hardware necessary for the first stage, it would be possible to make the installer load udebs from alternate sources, but the people who'd be interested in it are spreading lies on debian-devel instead of working on the code. FullACK! If $USER have such hardware, they have the DriverCD or other media provided by the manufacturers and I think, Debian should only provide FREE wrapers and loaders to get the things running. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:46:42, schrieb Michael Poole: Exactly what is the technical solution for installing drivers for firmware-requiring hardware if you only have Debian proper (i.e. main) available? That is the situation I described, and I really do not see any technical solution for it, no matter how much you call it a lie. This is, WHY ndiswraper should be in main and NOT contrib. ndiswraper is GPLed and if the $USER can provide a DriverCD she/he should be able to load firmware and drivers into Debian. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Hello Peter, Am 2006-02-19 01:51:31, schrieb Peter Samuelson: Good, then we can stop talking about including it in main. We don't ship hardware, so if firmware is part of the hardware, we don't need to ship it either. If it's part of the hardware, then it is the hardware vendor's responsibility, not Debian's, to make sure it is available. (It might be nice, for the convenience of the hardware vendors, to produce some sort of specification for CD layouts and metadata so that they can provide firmware to their customers in a way that's easy to use with Debian.) :-) FullACK! And if some Developers oand/or Maintaines have spare time or the need for such hardware, they can do the Job too. I think, this would be the best idea. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-21 15:36:16, schrieb Anthony Towns: That's a mistaken view; the purpose of contrib is to give us a place to ship free software that we can't ship in Debian proper (ie, main) because it would violate We will never make the system require the use of a non-free component or, historically, ... we will never make the system depend on an item of non-free software. I have read the social contract, developers-reference and much more documentation to Debian and for me it is clear: ndiswraper does NOT depend on non-free software because Debian support the creation of FREE software. So ndiswraper should be in main to give developers the ability to code such stuff. Pushing ndiswraper into contrib prevent such evolution. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. Right, because ndiswraper can run at any time a FREE driver which can be written IF many peoples are naoyed about the Win-NDIS and begin to code one... And ndiswraper should not be in contrib because it CAN BE USED to load non-free Win-NDIS driver in Debian. Cheers, aj Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-20 23:38:53, schrieb Adam McKenna: Practically, it's to avoid shipping things on our CDs that depend on stuff that's not on our CDs. In this case, even in the absence of free NDIS Right, I do not like the Idea, to ship a coupe of CD's with Firmware and drivers in Debian. Insteed we should only provide Wrapers and loaders to get the things from the manufacturers provided DriverCD's What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? I think not. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 25, 2006 at 05:01:25PM +0100, Michelle Konzack wrote: If I have a hardware which comes with a CD/DVD/Floppy with the firmware and there is a free firmware loader but it must stay in contrib it will not realy productiv. It is a big disavantage. Why? I've been using Debian for quite some time but I've never checked that the package I'm about to install is coming from main or from contrib. Yes, I understand that there are technical/legal reasons for putting packages in contrib instead of main, but with my dumb user hat on, I simply _do not care_. I simply can not understand why you all are making such a big fuss about ndiswrapper being in contrib or in main. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
* Michelle Konzack [EMAIL PROTECTED] [2006-02-27 14:21]: ndiswraper is to allow users to write drivers, which they may or may not have written themselves and which may or may not be free software. Wrong, its purpose ist to let them run these drivers. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System yath lol, mein feuermelder ist dausicher yath im batteriefach unter der batterie steht yath WARNUNG: BATTERIE ENTFERNT -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 27, 2006 at 03:33:51PM +0100, Gabor Gombas wrote: I simply can not understand why you all are making such a big fuss about ndiswrapper being in contrib or in main. Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michelle Konzack [EMAIL PROTECTED] writes: If someone use only main she/he will never install ndiswraper and will not code a free version. Let ndiswraper stay in main will animate developers to code stuff. My understanding is that it is currently in main, right? How many people have been animated to write free code for it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. How does putting ndiswrapper in contrib make Debian less usable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michelle Konzack [EMAIL PROTECTED] writes: What dou you think about the idea, that because non-free drivers and firmwares are droped from main we write wrapers and loaders which GET the drivrs and firmwares from the manufacturer provided DriverCD's. This is a very suboptimal solution. Such wrappers are necessarily in contrib, and are a second-best approach. Better we spend our time actually supporting the hardware with free software. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 10:33:47AM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. How does putting ndiswrapper in contrib make Debian less usable? Do you actually read entire threads for context when you reply, or do you just pick particular posts to nitpick and needle people over? Don't answer that, it's rhetorical. As I said earlier, it prevents us from integrating ndiswrapper-supported devices into the installer so that users can enable their wireless devices during install. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: As I said earlier, it prevents us from integrating ndiswrapper-supported devices into the installer so that users can enable their wireless devices during install. I'm afraid I don't see how this works out. Why can't you integrate such things into the installer? What is the technical difficulty here? It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. Not only that, there are obviously other considerations when buying a laptop than whether the wireless card has free drivers or not. Things such as price, combination of features, etc. Our users shouldn't be forced to buy a GNU anointed laptop (if such a thing even exists) in order to get support for their devices. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[EMAIL PROTECTED] (Marco d'Itri) writes: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. The supposition was about people who wanted to use ndiswrapper to write free drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. Not only that, there are obviously other considerations when buying a laptop than whether the wireless card has free drivers or not. Things such as price, combination of features, etc. Our users shouldn't be forced to buy a GNU anointed laptop (if such a thing even exists) in order to get support for their devices. Please keep track of the threads. Marco pruned crucial context. Nobody is talking about forcing people to buy anything. The current criteria for contrib do not make reference to technical convenience as a factor. Perhaps this is a mistake, in which case it should be corrected. I'm still unable to see how the classification of ndiswrapper in contrib somehow causes a major technical inconvenience. It can, for example, be put on the first CD. I certainly do not think that the installer should be limited to software in main (and perhaps not even software in main+contrib, provided it still works correctly without non-free things around). Is that the root issue? Are there people who insist that the installer should be limited to things in main? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote: Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Because ndiswrapper belongs in main. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote: Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Because ndiswrapper belongs in main. So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? People wrongly arguing to move packages from main to contrib. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[EMAIL PROTECTED] (Marco d'Itri) writes: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? People wrongly arguing to move packages from main to contrib. And what bad things happen if a package is miscategorized? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. I'm afraid that's not an answer to my question. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. You are suggesting that there is some mistreatment in putting a package in the wrong category. As in might get the same treatment. Is the idea that you somehow wound the ego of a package by putting it in contrib? That surely isn't right, of course. But I'm stuck for wondering. If a package is wrongly put in lib when it belongs in libdevel, for example, or vice versa, there is no huge flame war, nothing bad happens, we just carry on. Such a state could continue for years without anybody getting upset or much caring. I just *assume* that errors in categorization will be made. That doesn't mean errors are good, of course. But my question is: what *harm* does this particular error (if it is an error) cause? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:14:54PM -0800, Thomas Bushnell BSG wrote: So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Correct. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. In addition, there are other potential issues with having it in contrib, one of which is inaccessibility to the installer. The overall effect is decreased utility for our users. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. Ok, this seems to be a simple factual question, and I have been unable to see the answer despite careful reading of the thread and the bug log. What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. (BTW: I have no problem saying that a thing is in contrib while it can support only non-free software, and as soon as a realistic case of it supporting free software comes along, it moves into main. Some people seemed to have been assuming in this thread that this is a ludicrous possibility, but it seems perfectly natural to me.) In addition, there are other potential issues with having it in contrib, one of which is inaccessibility to the installer. The overall effect is decreased utility for our users. Once again, this is not a real issue. This is a bug in the installer, and not a categorization mistake. If the installer is fixed, there is no decreased utility of this sort for putting the package in contrib. So let's pretend that the installer bug has been fixed. Moreover, the standards for contrib do not (at present) make any reference to utility or convenience. Perhaps this should be changed, but I'm assuming that we keep the standards alone. (I make this presumption only because the argument seems to be that ndiswrapper belongs in main under the *current* standards, and not some hypothetical improved standards.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: Michael Poole [EMAIL PROTECTED] writes: It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. I'm afraid that's not an answer to my question. It wasn't intended to be an answer to your question, just a reminder that actions have consequences. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. You are suggesting that there is some mistreatment in putting a package in the wrong category. As in might get the same treatment. Is the idea that you somehow wound the ego of a package by putting it in contrib? That surely isn't right, of course. But I'm stuck for wondering. If a package is wrongly put in lib when it belongs in libdevel, for example, or vice versa, there is no huge flame war, nothing bad happens, we just carry on. Such a state could continue for years without anybody getting upset or much caring. I just *assume* that errors in categorization will be made. That doesn't mean errors are good, of course. But my question is: what *harm* does this particular error (if it is an error) cause? Under the default configuration the last time I installed Debian, the contrib section is not used; arguing that some future technical change might change that behavior leaves the issue open until that change is actually made. Fixing a main-contrib error is likely to require much greater effort and debate than a libdevel-lib error, since Policy defines the distinction between main and contrib but not the one between libdevel and devel. Personally, the effort to fix the error is why I prefer to decide a grey area sooner rather than later. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. Ok, this seems to be a simple factual question, and I have been unable to see the answer despite careful reading of the thread and the bug log. What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? You read the thread so closely that you missed all the references to CIPE? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote: Help me out then. You seemed to suggest that not putting ndiswrapper in main would be to ignore rules that are very clearly laid out in the SC and DFSG. I suggested that the CTTE overriding the developer's judgement in this instance would be an abuse of power, since the DFSG and SC (not to mention policy) clearly spell out the requirements for main, and ndiswrapper clearly meets them. I think this is clearly incorrect. The DFSG and the SC do not say anything about the requirements for main that I can see. This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. Since require in the technical sense is expressed through dependencies (although I have seen someone assert with explanation that package dependencies don't matter here, for some reason), it is rather clear to me that ndiswrapper meets the criteria for main. I will try to be clear about what I think is so wrong headed about this thread, and what I worry it represents. ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: Under the default configuration the last time I installed Debian, the contrib section is not used; arguing that some future technical change might change that behavior leaves the issue open until that change is actually made. As I have said, we should (in my opinion) fix the installer to allow the use of contrib packages. As I have repeatedly said, however, this is irrelevant to the question of whether ndiswrapper meets the tests for main rather than contrib, because those tests do not refer to such things as convenience for the installer and the like. This may mean that the tests should be changed, of course. Fixing a main-contrib error is likely to require much greater effort and debate than a libdevel-lib error, since Policy defines the distinction between main and contrib but not the one between libdevel and devel. Personally, the effort to fix the error is why I prefer to decide a grey area sooner rather than later. Policy does specify that packages belong in the correct sections, actually. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Um, I actually have no opinion right now about whether ndiswrapper belongs in main or contrib. I haven't got enough facts to understand. I'm trying to understand the question, and one oddity is that some people seem to think it's *extremely important* in a way which is out of kilter with the issues as I understand them. This suggests to me that I must be missing something, so I'd like to know why it's *extremely important*. In other words, if it is pushed into contrib, what bad things happen? If the answer is none, then why the level of anger I've seen in this thread? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? You read the thread so closely that you missed all the references to CIPE? Let's see, maybe you didn't read the paragraph where I said: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. Is this CIPE? Or is that some other case? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. This is, however, irrelevant to the present question. The standards for main/contrib do not make reference to convenience for the installer. Perhaps they should be; if you think such a question should be taken into account, then you should... do some of the work of making that change happen. thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: Policy does specify that packages belong in the correct sections, actually. Where is that? I did not see anything like that in section 2.4 when I looked before, and I do not see anything like it in 5.6.5. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Um, I actually have no opinion right now about whether ndiswrapper belongs in main or contrib. I haven't got enough facts to understand. I'm trying to understand the question, and one oddity is that some people seem to think it's *extremely important* in a way which is out of kilter with the issues as I understand them. This suggests to me that I must be missing something, so I'd like to know why it's *extremely important*. In other words, if it is pushed into contrib, what bad things happen? If the answer is none, then why the level of anger I've seen in this thread? One reason to argue so loudly is if one thinks that this is a specific case of the general question of how hard-line or strict Debian should be about defining main, and that it may be cited as precedent for future decisions. An alternative hypothesis is that since this was argued a year ago, ndiswrapper-in-main advocates think it is a waste of time and want to convey their arguments so that everyone remembers and does not want to argue again in another year. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. If people want the SC to say We will never make the system require the use of a non-free component, and additionally we will not include in our main distribution software that is mostly used for running non-free code, I think they should just say so, rather than trying to advance that agenda in round about manner. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. You used the word stealth and revisionist. These are not contributions to an attitude of openness and trust. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. The tech-ctte is there to address technical disputes. If people want the SC to say We will never make the system require the use of a non-free component, and additionally we will not include in our main distribution software that is mostly used for running non-free code, I think they should just say so, rather than trying to advance that agenda in round about manner. Once more, the SC does not address the main/contrib distinction at all, as far as I can tell. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran writes: I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. Although I think ndiswrapper meets the requirements for main, I think this presentation misrepresents what the other side claims. Policy section 2.2.1: In addition, the packages in main: * must not require a package outside of main for compilation or execution (this, the package must not declare a 'Depends', 'Recommends' or 'Build-Depends' relationship on a non-main package) This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I think that is a too-broad definition of require, but using it does not require changing foundation documents. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. This is, however, irrelevant to the present question. The standards for main/contrib do not make reference to convenience for the installer. Perhaps they should be; if you think such a question should be taken into account, then you should... do some of the work of making that change happen. Well parroted. Since I can see you don't understand the difference between main and contrib, I will point you to it. Please see 2.2.1 and 2.2.2 in policy. If you diff the first set of bullet points that lay out criteria for main and contrib, you'll see that the only differnece is that packages in main : must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) Do you see a Depends, Recommends, or Build-Depends on non-free or contrib software somewhere in the ndiswrapper source or binary packages? I don't. So why is there an argument for changing it? Since there is no foundation in policy, do the benefits or technical merits (of which exactly none have been presented) outweigh ignoring a rather clear statement from policy? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: Well parroted. Since I can see you don't understand the difference between main and contrib, I will point you to it. Please see 2.2.1 and 2.2.2 in policy. If you diff the first set of bullet points that lay out criteria for main and contrib, you'll see that the only differnece is that packages in main : must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) This is not a complete list. It may not require a package outside of main for compilation or execution. One consequence of that, is that it must not Depend on such packages. But this is not the *only* consequence, it is merely the one being spelled out. It is certainly not true that a package in contrib can be moved to main just be removing the package dependencies. The further question is: can it be run without the non-free software? I still am not sure, having not yet received a complete answer to the factual questions I raised. (Adam gave recently a partial answer, but I'm still not clear on the facts to which he was alluding.) Do you see a Depends, Recommends, or Build-Depends on non-free or contrib software somewhere in the ndiswrapper source or binary packages? I don't. So why is there an argument for changing it? Since there is no foundation in policy, do the benefits or technical merits (of which exactly none have been presented) outweigh ignoring a rather clear statement from policy? The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. At first blush, it looks as if the only purpose of the software is to run NDIS drivers. So the question is: are all NDIS drivers non-free software? (Actually, the question is slightly more complex, so please see the previous message in which I gave a more full version of that question.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? I think he addressed this in the first paragraph of that mail: Stephan Gran writes: This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. This part of SC#1 would be redundant if it were just a reference to the main versus non-free sections, since it already says We promise that the Debian system and all its components will be free according to these guidelines. Thus, it requires that the Debian system not include packages that meet Policy's definition of contrib but not main. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: Thomas Bushnell BSG writes: I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? I think he addressed this in the first paragraph of that mail: He said that ndiswrapper is a piece of free software, which is not in doubt, but also not the point. Contrib only includes free software, remember, so saying but it *is* free only proves that it belongs in either main or contrib; it does not establish which. The first paragraph of Stephen's mail said: : ndiswrapper is a piece of free software. It does not need non-free tools : to build, and it will execute as a standalone app without any drivers. : The fact that most people use it to enable non-free drivers to work is : largely irrelevant - most people use wine and various other emulators : for similar purposes. Nothing here, it seems to me, is about the social contract or the DFSG; there is no doubt that ndiswrapper is free software, but the DFSG and the SC do not say anything like all free software can go in main, and indeed, the DFSG and the SC don't seem to say anything about main or contrib anyway. But then, maybe I'm missing it: so please, where in the text of the DFSG or the SC is reference to the main/contrib distinction made? Stephan Gran writes: This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. This part of SC#1 would be redundant if it were just a reference to the main versus non-free sections, since it already says We promise that the Debian system and all its components will be free according to these guidelines. Thus, it requires that the Debian system not include packages that meet Policy's definition of contrib but not main. Ah, I see. So pretend I have no non-free components at all. What do I gain by having ndiswrapper around? What does it let me do that I cannot do without it? Please be specific; don't speak in hypothetical terms about software that might or might not exist. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. Can you point me to the place I should look? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. All right, who pushed the 'thread reset' button? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. Ah, a brief search turns up. CIPE is then the sort of thing I was thinking about when I wrote: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. According to what I've read, the driver is already supported, and better, without the use of ndiswrapper. But perhaps what I've read is inaccurate? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote: The tech-ctte is there to address technical disputes. This isn't a technical dispute, it's an ideological one. The technical details very clearly support keeping ndiswrapper in main. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. All right, who pushed the 'thread reset' button? Unlike some, I do not have a perfect memory. Moreover, I do not appreciate vague we already discussed this references. I've read the damn thread; I ask the question because the previous discussion did not seem to actually *answer* the question. If the answer is so blindingly obvious, then really, it can simply be put down. Or a reference given if that's too much trouble. What I'm worried about is a question that I do not think *has* been answered, and that rather than answer it, we get we already answered that without any answer actually having appeared. So, while this question has been asked before--indeed--it has not been answered AFAICT. I've heard it asserted; you mentione the CIPE case. Is that the only case? Is ndiswrapper useful for CIPE? More to the point, it was said that it should be in main if there was a subset of users who would benefit from its presence there, even without the use of any non-free software. What is this subset of users, exactly? Are they users with CIPE hardware? (But they benefit more from the direct support of cipe anway.) Or what? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote: The tech-ctte is there to address technical disputes. This isn't a technical dispute, it's an ideological one. The technical details very clearly support keeping ndiswrapper in main. Well, all the questions I've asked, which it seems to me could resolve the dispute, have been technical ones. I'm not sure what the ideological positions are that you think are driving the discussion. I haven't got any, since I haven't formed any opinion about the question one way or the other. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote: This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I don't think this is a valid argument, the requirement is that it must not depend on software outside of main, not that it must have software in main on which to depend. There are in fact free NDIS drivers available. There have been various, uncompelling arguments offered so far as to why these free NDIS drivers do not count for satisfying policy. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote: This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I don't think this is a valid argument, the requirement is that it must not depend on software outside of main, not that it must have software in main on which to depend. Oh, your point here is certainly well-taken. I think the point is not so much whether there is an NDIS driver in main, as whether there is a free NDIS driver for use with ndiswrapper, which is not a toy, and which is best-supported by ndiswrapper and not, say, directly. There are in fact free NDIS drivers available. There have been various, uncompelling arguments offered so far as to why these free NDIS drivers do not count for satisfying policy. I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I'm prepared to be pretty liberal, in applying such a test. For example, if there were two free drivers to support a piece of hardware, one used through ndiswrapper and one linked into the kernel, such that everyone thought the in-kernel one was better, but there was some class of users for which the ndiswrapper driver would be better, say, because it has some single weird feature that might help, then I would say that the ndiswrapper version is useful, despite the availibility of a generally better alternative. And the mere hypothetical existence of the alternative wouldn't count either. If there is, here and now, a free driver available through ndiswrapper, and there is not any existing alternative (even though, as free software, there theoretically could be), then I would say that counts as useful, even if in an ideal world the use might vanish. So this comes down, for me, to the simple question: what are the free drivers for use with ndiswrapper, and if they are drivers for which there are already generally better alternatives, what makes the ndiswrapper version better for some class of users? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. I'm not so much interested in the politics, and I'm not asking anyone to remove anything. Rather than argue about the burden of proof, which is something that neither of us really get to decide (since the tech-ctte will presumably make its own decision about who must prove what), I'm interested in understanding the technical facts. So I'm still at a loss; the only use of ndiswrapper, on a free-software-only system, seems to be CIPE. Is that correct, or is there some other? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Adam McKenna said: On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. Additionally, the use of the phrase useful in a system with only free software on it is not something I can find in either 2.2.1 or 2.2.2 (where the difference between main and contrib is spelled out) or anywhere in our foundation documents. Can you point me to where this requirement is mentioned in our policy and/or foundation documents? If it is not currently in policy or our foundation documents, can you explain why this new requirement should be applied for technical reasons? This certainly seems like an ideological problem, rather than a technical one, making the tech ctte a poor choice for conflict resolution. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: Additionally, the use of the phrase useful in a system with only free software on it is not something I can find in either 2.2.1 or 2.2.2 (where the difference between main and contrib is spelled out) or anywhere in our foundation documents. Can you point me to where this requirement is mentioned in our policy and/or foundation documents? It's not in the foundation documents, it's in the definition of contrib. Please remember, the Debian Policy Manual is not a foundation document. In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. So the question is, is ndiswrapper for free programs, or only for non-free programs? If there are no uses of it (actual *uses*, where it is *useful*) with free programs, then it sure seems like a wrapper for non-free programs. But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? CIPE has been mentioned, but it has also been said that ndiswrapper was not useful in this particular case. Moreover, the statements in 2.2.1 and 2.2.2 are *exemplars*, not final absolute standards. Remember, Policy is not a foundation document. It is a *technical* document. There is no statement in 2.2.1 that everything which meets the test there belongs in main; it is a list of requirements, but does not pretend to be exhaustive. There are some examples of things which belong in contrib, and at first blush, ndiswrapper looks like one of those: to use ndiswrapper, you need a driver to wrap, and there are no such drivers in our archive. And, with only one exception (an exception which it has been said is irrelevant since ndiswrapper is not actually *needed* for CIPE), ndiswrapper is only good for wrapping non-free programs (speaking *right now*; if the facts change, it can easily be moved). But rather than argue about what *might* be so, geez, can *somebody* PLEASE, just answer the factual question? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
