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 (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 (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 (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 (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 (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: Whether CIPE and Windows driver development count isn't a fact, it's an opinion. Since they're both thoroughly pointless, I don't think they do. The fact is it doesn't matter whether they 'count'. They exist, and that is enough to fulfill the requirement. If you have a problem with that, you are free to try to change the rules. --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 Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? The fact that there is free software for one of them, while not for the other? No, doesn't hold; there is free software for both. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. I can easily say that without lying: wine doesn't work on my laptop, and running it inside qemu is so insanely slow that it isn't useful. Honestly, I don't see any difference that you can use as an objective argument to allow one in main, but not the other. If running or building wine or ndiswrapper required the use of non-free software in all cases, _then_ you'd have a case. As it is, you don't. -- 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 Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? -- 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 Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:29:25PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. Furthermore, it's reportedly better than the accounting packages we have. I don't know if it actually runs under Wine though. Hrm, I hadn't thought of that. I wonder if it's worth trying to package with a dependency on wine... Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. But then, I don't know that I'd be that unhappy if emulators were stuck in contrib. There are a few lines you could draw: (1) running non-free drivers in order to use your system (2) a compatability layer to run non-free applications or games you might have (3) a client that allows you to make use of some proprietary servers, for which there's no free server (4) a viewer that allows you to view documents prepared by a proprietary program, for which there's no free writer At present we let all of them into main. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? That's a fair point -- you could reasonably argue that ndiswrapper doesn't depend on non-free drivers, but quite to the contrary, non-free drivers depend on ndiswrapper to operate correctly on Linux. The usual argument that's made to allow (3) into main is to say that it only matters what code's actually running on *your* cpu, not elsewhere; but that seems to indicate ndiswrapper should be in contrib. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. Well, fortunately what you do and don't declare doesn't matter that much, though if you're just going to pontificate like that, this conversation isn't going to get anywhere. If running or building wine or ndiswrapper required the use of non-free software in all cases, _then_ you'd have a case. As it is, you don't. Dude, how about you consider the fact that you'd get more benefit out of convincing me of your arguments, than I would of convincing you, and then realise that saying As it is, you don't have a case. is just irritating? And build time dependencies are completely irrelevent to this discussion. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:05:23AM -0800, Adam McKenna wrote: On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: Whether CIPE and Windows driver development count isn't a fact, it's an opinion. Since they're both thoroughly pointless, I don't think they do. The fact is it doesn't matter whether they 'count'. They exist, and that is enough to fulfill the requirement. If you have a problem with that, you are free to try to change the rules. Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:52:29AM -0800, Steve Langasek wrote: On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. Emulators/games have been moved[1] from contrib to main after someone has done free data files which are essentially proof of concept in nature. I fail to see why availability of a CIPE driver for ndiswrapper doesn't fall into the same category. A requirement for main must be usefull in a free software only enviroinement is the the beginning of the road to madness. Next theill come for free clients for protocols that (currently) only have non-free servers to connect to. Who the hell has the right to define what is usefull anyway? [1] sarien atleast -- 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 Mittwoch, 22. Februar 2006 12:52 schrieb Anthony Towns: Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. Wine reads a different binary format than elf and also provides the libs in the other format. Is the linux kernel on sparc an emulator if it can run solaris applications? However, the wording emulator can have many interpretations. If you refer to wikipedia, wine is an emulator. If you agree to that particular wikipedia article is your free choice. I don't. HS -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org pgpA0UzYYUSBc.pgp Description: PGP signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Because you're wrong. --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 (was: Bug#353277: should be in contrib)
Bug CC dropped. On Wed, Feb 22, 2006 at 02:20:42PM +0200, Riku Voipio wrote: A requirement for main must be usefull in a free software only enviroinement is the the beginning of the road to madness. Next theill come for free clients for protocols that (currently) only have non-free servers to connect to. That's already come up as it happens, debian-policy, May 1999. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[I'm not a developer, just one of Debians users - I hope it is not inappropriate for me to comment on this issue here.] For starters, I'd always thought that contrib was for packages that Depend on a package out of non-free -- basically to ensure that people who have only DFSG-free software in their sources.list or on their CDs don't get broken packages. However, after reading up a bit I gather contrib means something like Packages here need something that is non-free to operate. Policy 2.2.2 has clarifying examples: - free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and - wrapper packages or other sorts of free accessories for non-free programs. If ndiswrapper falls in the first category hinges on the definition of require. Judging from its documentation ndiswrapper doesn't need any non-free binaries, the module can be inserted even if no drivers are installed. It might not be very useful like that, but useful is a very subjective thing in any case and doesn't serve as a good guideline as to what one is to expect to find in contrib. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Maybe a clarification of 'require' as used in Policy 2.2.2 and item 1 of the social contract would be helpful. As it stands I think the first example doesn't apply. The much more interesting question is, is it a wrapper package in the sense of 2.2.2? It certainly acts as a wrapper for (non-free) win32 drivers, on the other hand most wrapper packages are for specific pieces of software, whereas ndiswrapper can (theoretically) encapsulate all NIC drivers that conform to a certain reasonably generic spec. Compare this to java-package which works with 6 specific Java VMs (2 versions each by 3 vendors). So maybe it isn't a wrapper but implements an ABI? I don't know, both viewpoints are certainly valid. An argument I don't agree with however, is that there would have to be a (DFSG-)free NDIS driver for ndiswrapper to rightfully be in main -- mainly on the grounds that it is a very vague and unstable criterion. Should an FPS game with no free texture packs be in main? No. If it has free texture packs but no maps? Probably not. What if there's a free map editor? ... Such reasoning just invites endless discussions until someone writes a small free component and people start to argue whether it is actually useful or just a POC. IMHO that's something for users to decide. Rather, this line of reasoning could be used not to include ndiswrapper at all -- how should the maintainer verify and fix bugs in a package when those bugs only occur and can only be verified in conjunction with non-free components? Yet nobody is asking to remove it, are they? All that said, I don't use ndiswrapper as I'm lucky enough to have hardware that works well with free drivers. On the other hand I have one of those white iBooks with no wireless drivers in sight -- if there were an ndiswrapper for the Mac I'd probably replace OS X with Debian in a heartbeat. I would assume owners of PC laptops feel the same way. From this angle it is certainly in the interest of users to have this functionality in the Debian installer even, which AFAIK can't load modules from contrib. Thanks, Christian
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:20:47AM -0800, Adam McKenna wrote: On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Because you're wrong. And I should add that these arguments have already been fairly soundly refuted and rejected by others who actually took them seriously, including other members of ctte. You don't appear to want to be convinced. --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 (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:52:28PM +1000, Anthony Towns wrote: On Wed, Feb 22, 2006 at 12:29:25PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. Heck, I used to work for a company that wrote accounting software which (also) worked on Linux, so I should know my way around there. Furthermore, it's reportedly better than the accounting packages we have. Many non-free software is reportedly better than some of the software in Debian. OpenOffice.org is reportedly better than MS Office, for example. I tend not to believe third-hand experiences. I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? [...] Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. Sure. Personally, I'd put ndiswrapper there, too. [...] There are a few lines you could draw: (1) running non-free drivers in order to use your system (2) a compatability layer to run non-free applications or games you might have (3) a client that allows you to make use of some proprietary servers, for which there's no free server (4) a viewer that allows you to view documents prepared by a proprietary program, for which there's no free writer These are all categories, but I disagree that the distinction between most of them is that significant. At present we let all of them into main. I'm still not convinced that this is actually a bad thing to do. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? That's a fair point -- you could reasonably argue that ndiswrapper doesn't depend on non-free drivers, but quite to the contrary, non-free drivers depend on ndiswrapper to operate correctly on Linux. Exactly. The usual argument that's made to allow (3) into main is to say that it only matters what code's actually running on *your* cpu, not elsewhere; but that seems to indicate ndiswrapper should be in contrib. Actually, I'd say that the argument to allow (3) in main isn't meant to be used outside its context. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. Well, fortunately what you do and don't declare doesn't matter that much, though if you're just going to pontificate like that, this conversation isn't going to get anywhere. What I meant was, if it's fair to say that CIPE isn't useful at all, then why is it fair to say that free Windows-software is at all useful? Personally, I think that if it doesn't run on Linux, it isn't useful. Honest. I haven't seen an argument in support of CIPE isn't a good example that didn't boil down to actually it is, but because it defeats my point, I'll just claim it isn't useful. -- 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 Wed, Feb 22, 2006 at 07:32:33PM +0100, Wouter Verhelst wrote: The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. You can do accounting in vi if you want. It's not terribly pleasant, but it works well for some circumstances. Of the free accounting programs available, TurboCASH actually looks pretty optimal for a range of circumstances, notably small businesses. It seems to be one of very few free programs that's actually likely to handle Australian accounting requirements reasonably well. Furthermore, it's reportedly better than the accounting packages we have. Many non-free software is reportedly better than some of the software in Debian. OpenOffice.org is reportedly better than MS Office, for example. I tend not to believe third-hand experiences. Then why bother reading a mailing list at all? I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? I'm sorry, I thought we had a chance at an interesting conversation here. But if we're at Are you for real? and Because you're wrong. already, I guess I was mistaken. Your concerns have been noted and will be taken into due account in my considerations. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Thu, Feb 23, 2006 at 04:58:38AM +1000, Anthony Towns wrote: On Wed, Feb 22, 2006 at 07:32:33PM +0100, Wouter Verhelst wrote: The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. You can do accounting in vi if you want. Correct, that's how I keep track of who I need to invoice :-) (though the real accounting is done by an accountant who gets paid for her work) It's not terribly pleasant, but it works well for some circumstances. Of the free accounting programs available, TurboCASH actually looks pretty optimal for a range of circumstances, notably small businesses. Like I said, there are a number of free applications that allow you to natively do accounting on Linux. Since Belgian law is rather strict on those issues, creating free software which would make accounting legal is rather hard[1], but there are a few applications which will run perfectly well on Linux and that allow you to legally do your accounting. [1] one of the requirements is the inability to modify stuff after the fact, which is very hard to meet as a requirement if the source is out for everyone to view. Yes, I agree that such a requirement cannot ever technically be met, but it's still there; and without meeting that requirement according to some committee, you're not allowed to use that software to do accounting -- at least not if you don't want to keep a copy on paper of everything. [...] I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? I'm sorry, I thought we had a chance at an interesting conversation here. [...] Sorry, that was indeed demeaning. It wasn't meant that way, but in hindsight, it was. Apologies. But if we're at Are you for real? and Because you're wrong. already, That second quote was not by me. My point was that I don't think your reasoning follows logic; your example in support of wine is about something that may work with wine, but that you apparently haven't tried yourself; whereas an example in support of ndiswrapper which is given by the people who wrote ndiswrapper (and who could reasonably well guess what will run and what won't) is dismissed because it isn't useful. It feels like applying to standards to me. But perhaps I'm missing something? -- 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)
[Christian Pernegger] Judging from its documentation ndiswrapper doesn't need any non-free binaries, the module can be inserted even if no drivers are installed. It might not be very useful like that, but useful is a very subjective thing in any case Not *that* subjective. I think you'd be pretty hard-pressed to find anyone who would consider it useful to print an init message to the kernel log, use up a bit of memory, and do absolutely nothing else. In some cases you are correct, useful is hard to define, so one has to be lenient. This isn't one of those cases. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Well, until you find out whether the maintainer would have considered ndiswrapper useful enough to create and maintain if it could only be used with free drivers, or if it didn't support any drivers at all, this distinction doesn't help. An argument I don't agree with however, is that there would have to be a (DFSG-)free NDIS driver for ndiswrapper to rightfully be in main -- mainly on the grounds that it is a very vague and unstable criterion. I don't see what's vague about it. It's unstable, sure. Should an FPS game with no free texture packs be in main? No. If it has free texture packs but no maps? Probably not. What if there's a free map editor? ... Moving something from contrib to main, when its status changes due to additional free software becoming available, is NOT HARD. It's been done before, for example with the Doom game engines. You don't need to worry that contrib is forever. I mean, as well worry about all the software we label as Priority: extra. That's another arbitrary line to draw, judging a package by its degree of usefulness to most people. Oh no, you might say, what if it becomes really popular in the future and deserves to be Priority: optional or even Priority: standard? Answer: you cross that bridge when you come to it. So with putting something in contrib or main. Classifications are allowed to change when the change is justified. Rather, this line of reasoning could be used not to include ndiswrapper at all -- how should the maintainer verify and fix bugs in a package when those bugs only occur and can only be verified in conjunction with non-free components? You have discovered one of the reasons Debian advocates free software. One of the reasons we have separate 'main' and 'contrib' sections. What you say is true: it may well be harder to find and fix bugs in software which uses non-free components, even if the bug is in a part of the software which is free. We think our users deserve free software, partly to avoid that very problem, so we use 'contrib' to label the contents of the archive that may suffer from these restrictions. Maintainers who have packages in 'contrib' and 'non-free' have accepted these limitations and are willing to try to do the job regardless. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[I originally sent this to Peter directly, my apologies.] I think you'd be pretty hard-pressed to find anyone who would consider it useful to print an init message to the kernel log, use up a bit of memory, and do absolutely nothing else. I'd find it useful for the functionality to be there when I wanted to load a driver with it. What kind of driver (supplied by me) I chose to load with it should be my decision as a user, not Debian's. Debian's policy should govern things it ships, not the data (executable or not) a user might want to feed to a program. (Others in this thread have come up with examples like open file format viewers with no in-the-wild documents yet, programming languages without code written in them, ...) Even if there was a sentence like All software in Debian main must be useful within a pure free software environment. in a binding document, that still leaves objective criteria for useful to be defined. In some cases you are correct, useful is hard to define, so one has to be lenient. This isn't one of those cases. Something that needs to be decided case-by-case basis, possibly leniently, is subjective. (Except of course you have objective criteria for all cases, but that's a catch-22.) However, the main/contrib distinction should like the free / non-free distinction be as objective and transparent as possible. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Well, until you find out whether the maintainer would have considered ndiswrapper useful enough to create and maintain if it could only be used with free drivers, or if it didn't support any drivers at all, this distinction doesn't help. I'm sorry but I don't understand this sentence. I'll try to explain what I meant. If a developer files an ITP for a package and that doesn't get shot down by heated flames, if that developer then actually prepares a functional package - doesn't that show in itself that the package is useful? When all else is equal, except main or contrib, isn't it a little late to ask if the package is useful? When a package isn't useful, why have it at all? I stand by my opinion that usefulness is in the eye of the beholder. Moving something from contrib to main, when its status changes due to additional free software becoming available, is NOT HARD. No, it's not technically hard, it's just confusing, especially in the other direction. ndiswrapper is in main. Maybe it will be moved to contrib as a result of this discussion or of a decision by the technical committee. Maybe it will be moved back and forth a few times, with a heated discussion each time, who knows? Doing it isn't hard, but doing it in regular intervals for every package thus disputed is surely undesirable. I mean, as well worry about all the software we label as Priority: extra. That's another arbitrary line to draw, judging a package by its degree of usefulness to most people. Yes, that's true. However what I'm saying is just that main vs contrib shouldn't be arbitrary, nor does it say anywhere that main and contrib should be differentiated by the usefulness of their packages. We think our users deserve free software, partly to avoid that very problem, so we use 'contrib' to label the contents of the archive that may suffer from these restrictions. Is the definition of contrib then something like free software that shares some of the undesirable traits of non-free software due to the fact that it closely integrates with a non-free component? Nice, actually, if someone who's better than me with words made proper sentence out of it. Would put ndiswrapper firmly in contrib. I guess im just incredulous that Debian, which has clear and concise rules about almost everything, doesn't use a simple checklist to determine if something goes in main or contrib. Thanks, Christian
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 02:20:42PM +0200, Riku Voipio wrote: On Wed, Feb 22, 2006 at 03:52:29AM -0800, Steve Langasek wrote: On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. Emulators/games have been moved[1] from contrib to main after someone has done free data files which are essentially proof of concept in nature. It was not my understanding that these were proof-of-concept data files; while not necessarily as appealing as some of the non-free offerings, I was led to believe they were still worthwhile in their own right, at least to some subset of users. I fail to see why availability of a CIPE driver for ndiswrapper doesn't fall into the same category. Well, aside from not believing that anyone is going to use CIPE under ndiswrapper (without someone stepping forward and testifying that this is the case for them), I see a distinction between wine is necessary in order for you to run app $foo on Debian and ndiswrapper is necessary in order for you to run Debian on hardware $foo. I realize this isn't a distinction that everyone agrees is relevant here, but it is the one that stands out to me, and I suspect we can at least all agree that the latter is the real reason why people care about having ndiswrapper in main -- *not* to facilitate loading free toy network drivers -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 05:01:21PM -0800, Steve Langasek wrote: Well, aside from not believing that anyone is going to use CIPE under ndiswrapper (without someone stepping forward and testifying that this is the case for them), I see a distinction between wine is necessary in order for you to run app $foo on Debian and ndiswrapper is necessary in order for you to run Debian on hardware $foo. That is a very fine distinction, if it's a distinction at all, considering that the latter statement can easily be rewritten ndiswrapper is necessary in order for you to load drivers for hardware $foo, which is almost identical to the former. Also, the latter statement isn't really 100% valid, since Debian will still run without the ndiswrapper driver. It just won't be able to connect to wireless networks. As far as the second statement being the reason that most of us want ndiswrapper in main, that may be true, but it is no excuse to ignore rules that are very clearly laid out in the SC and DFSG. --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 (was: Bug#353277: should be in contrib)
On Mon, Feb 20, 2006 at 11:38:53PM -0800, Adam McKenna wrote: Practically, [contrib is] to avoid shipping things on our CDs that depend on stuff that's not on our CDs. The reason for contrib isn't practicality at all, it's to distinguish free software that stands on its own and that depends on non-free software. That's why it's specifically talked about in the social contract, rather than only being discussed in policy. In any event, we've historically shipped contrib on our CDs; I've no idea whether we still do or not. In this case, even in the absence of free NDIS drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) One could argue many things, but since we're trying to make a free operating system, maybe we could resist that temptation. I assume, btw, you count me as one of the zealots/fundamentalists you're eager to piss off. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? I doubt it; I think you're just confusing argument that I disagree with with argument that is unsound or irrational. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 07:04:27PM +1000, Anthony Towns wrote: In this case, even in the absence of free NDIS drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) One could argue many things, but since we're trying to make a free operating system, maybe we could resist that temptation. I assume, btw, you count me as one of the zealots/fundamentalists you're eager to piss off. Don't assume things, it can cloud your judgement. Our goal is to make a free *and useful* operating system. If you believe that keeping a piece of completely free software out of main that would allow our users to enable their wireless ethernet cards during installation is the right thing to do, even though the package is completely usable without any non-free code, that makes you sound pretty backwards to me. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? I doubt it; I think you're just confusing argument that I disagree with with argument that is unsound or irrational. So give a reference or Message-ID of (what you consider) a sound argument that is not similar to CIPE, and Windows driver developers who want to test on Linux don't count. --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 (was: Bug#353277: should be in contrib)
On Feb 21, Anthony Towns aj@azure.humbug.org.au wrote: The reason for contrib isn't practicality at all, it's to distinguish free software that stands on its own and that depends on non-free software. That's why it's specifically talked about in the social contract, rather than only being discussed in policy. Indeed. I believe that in origin the main purpose of contrib was to collect applications depending on non-free libraries like Motif and XForms, to make clear to our users that while these packages were free software they needed some non-free components to work, with all the practical and moral implications which follow from this. I think that e.g. emulators like scummvm or ABI adaptation layers like WINE and ndiswrapper are in a different category because they are free software which enables us to use some non-free program with Linux, may it be an old game or the driver for a network card. If we assume that users want/need to use these non-free programs anyway then scummvm and ndiswrapper provide a benefit to users and the free software movement because while they are usually used together with non-free software they have the net effect of allowing users to use *less* non-free software. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 09:57:21AM -0800, Adam McKenna wrote: On Tue, Feb 21, 2006 at 07:04:27PM +1000, Anthony Towns wrote: In this case, even in the absence of free NDIS drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) One could argue many things, but since we're trying to make a free operating system, maybe we could resist that temptation. I assume, btw, you count me as one of the zealots/fundamentalists you're eager to piss off. Don't assume things, it can cloud your judgement. If you don't want people to assume your insults are directed at them, don't throw them around in the first place. Our goal is to make a free *and useful* operating system. If you believe that keeping a piece of completely free software out of main that would allow our users to enable their wireless ethernet cards during installation is the right thing to do, even though the package is completely usable without any non-free code, that makes you sound pretty backwards to me. The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. So either it's not useful to our users, or it requires running non-free code. And that's what contrib's for. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? I doubt it; I think you're just confusing argument that I disagree with with argument that is unsound or irrational. So give a reference or Message-ID of (what you consider) a sound argument that is not similar to CIPE, and Windows driver developers who want to test on Linux don't count. And that's what I mean -- there's nothing unsound about saying those cases don't count; you just disagree with it. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: So give a reference or Message-ID of (what you consider) a sound argument that is not similar to CIPE, and Windows driver developers who want to test on Linux don't count. And that's what I mean -- there's nothing unsound about saying those cases don't count; you just disagree with it. The facts disagree with it. *That* is what makes it unsound, not what I think. The reality is that we can't imagine all the uses our users might have for this software, and since it unambiguously fulfills the requirements, it should stay 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 (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: So give a reference or Message-ID of (what you consider) a sound argument that is not similar to CIPE, and Windows driver developers who want to test on Linux don't count. And that's what I mean -- there's nothing unsound about saying those cases don't count; you just disagree with it. The facts disagree with it. *That* is what makes it unsound, not what I think. Whether CIPE and Windows driver development count isn't a fact, it's an opinion. Since they're both thoroughly pointless, I don't think they do. It's fine that you disagree, but your opinion isn't the only one possible. The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. and since it unambiguously fulfills the requirements, it should stay in main. Saying something is unambiguous doesn't make it so. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Kevin Mark] if a piece of software was initially created to enable the use of non-dfsg software with a dfsg system it is classified as 'ícontri', but then someone creates dfsg-software to use this software, now its classified as 'main'. Would this follow? You're trying to sneak in an unspoken premise: namely, that there is reason to believe ndiswrapper would ever be used with a free driver. I claim that this is ridiculous. As far as I've ever heard, free Linux drivers get written much faster than free Windows drivers. If, as I claim, it's exceedingly unlikely that ndiswrapper would ever be used to run free software, it is pure pedantry to say but, but, but, you *could* use it for that. But it also seems that the dfsg-use is not an absolute condition, it has to be deem non-toy and useful which is not an easily agreed upon idea. You seem to be arguing that the Social Contract doesn't say that our software must be of any use. What you're forgetting is that it also doesn't say we *should* ship useless things. Common sense would seem to indicate that we not do so. I don't see a meaningful distinction between non-functional without non-free software and pointless without non-free software. Either way, that's the primary reason we have contrib. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. I can't think of any free NDIS driver, but if such thing exists, NDIS-wrapper should be allowed in main without any problem. [..] -- 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)
[Peter Samuelson] There's a big difference between enabling someone to install non-free software, and enabling someone to view data. (Some of which is free, some not.) Also, in case this was your point, swf content is sometimes generated with free tools such as ploticus. [Michael Poole] What is the difference? I thought GR 2004-003 was all about recognizing software as software, whether some people call it documentation or programs. I suggest you reread GR 2004-003, if you believe it was about defining the term software. It was actually more to the tune of We'll stop using the term 'software' in certain places because it's ambiguous: not everyone interprets it to mean the same thing. If you were confused by my use of the term software to mean executable code, I apologise; I'll try to be more precise in the future. I thought it was clear enough from context, but perhaps it wasn't. Anyway, that's a minor point; the important distinction here is not really whether something is programs or data. You might be familiar with the Doom video game, of which various implementations and forks exist in Debian. Until a free Doom wad file (the game data) was created, the various Doom engines lived in 'contrib', because they were useless without non-free data. Nowadays, free data exists, so the Doom programs are in main. Of all the data viewer programs I can think of in Debian main, there is ample reason to believe there exists content out there for each which is either (a) free (and not useless), and/or (b) created by a Debian user who would want to use Debian to view it. I find it extremely unlikely that the analogous situation is true of ndiswrapper. SWF may be generated with free tools, but under a strict reading of Policy, that is insufficient to qualify for main. OK so I don't understand why you brought up a SWF viewer as an example. I thought it was because the content is generated with non-free tools like Macromedia Flash. Apparently that's not it, since we are agreed that this is not always so. So how else does SWF differ from, say, HTML? What point were you trying to make about libflash? 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. No document I'm aware of requires that we ship all free software whether or not it is useful. As it happens, I've always been opposed to pointless software in Debian. It's hard, however, to get it kicked out, because nobody wants to make the judgment call (the maintainer obviously thinks the package has a use, even if nobody else does). I'm sorry if you thought Debian was committed to shipping software with no regard to whether it is useful; this has never been true, although considering some of the fringe packages in the archive, I guess I can see why you might get that impression. But I'm sure you can see that Policy doesn't say we can't is not equivalent to Policy backs up my argument that we should. Likewise, there is no mention of Windows driver developers ... who really wish they could conveniently test their Windows drivers on Debian. Without those developers, and without non-free software, I contend that ndiswrapper is useless. And see above for what I think of *that*. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier: [..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. Read again, that's just what I said in the part that you deleted. HS
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le lundi 20 février 2006 à 11:56 +0100, Hendrik Sattler a écrit : Am Montag, 20. Februar 2006 11:11 schrieb Jérôme Warnier: [..] Ndiswrapper probably is better compared to such drivers than to wine or dosemu. I'm sorry, but Wine and Dosemu can run free softwares (respectively for Windows and DOS), so they are not unuseful without proprietary softwares. Read again, that's just what I said in the part that you deleted. Well, I read it again, and I'm sorry to say that I did not understand that from your wording. Also, not breaking lines and having that strange reply format renders it much more difficult to read. But anyway, the essential is that we mean the same. HS
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
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. Exactly. ndiswrapper can be used, for example, to run a driver you write yourself. Software that requires the use of non-free libraries can not ever be used without those non-free libraries. -- 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 Mon, Feb 20, 2006 at 05:10:42PM +1000, Anthony Towns wrote: On Sun, Feb 19, 2006 at 03:14:40AM +0100, Wouter Verhelst wrote: [...] It is already possible to use ndiswrapper without having any non-free software installed. Granted, it doesn't do much useful that way, If you have to differentiate between able to be used and useful, you don't have a point. What if I'm interested in writing such a driver myself, but less interested in having to run Windows? but a) neither the DFSG nor the SC say anything about usefulness, and b) if a free library package exists in main which no other free package uses it, we don't move the free library package to contrib either. If it's only useful for non-free software, we should probably consider it. More likely, it's not useful at all, and we should consider dropping it entirely. How many libraries do we have in this state? apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? It's very easy, really. Requires the use of non-free software is a far cry from only non-free software requires this software. You need wheels to use a car; you don't need a car to use wheels. -- 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 Sun, Feb 19, 2006 at 02:11:30AM -0600, Peter Samuelson wrote: [Michael Poole] If you want to move ndiswrapper to contrib, I expect the next step is to do the same to libflash, for the same reasons. There's a big difference between enabling someone to install non-free software, and enabling someone to view data. Uh, isn't data and software the same thing according to the latest version of the DFSG? -- 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)
[Wouter Verhelst] What if I'm interested in writing such a driver myself, but less interested in having to run Windows? Then you should get busy writing that driver. Without any such drivers in existence, it's hard to take this line of reasoning seriously. I find it absurd that someone would be interested in writing a Windows driver but not interested in running Windows to test it on. If that's really what you want to do, please say so, preferably with some sort of evidence. I hate to have to ask for evidence rather than taking your word for it, but the scenario seems so contrived that I'm afraid only evidence will make it seem less so. apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? No, not really. There's plenty of software, free and otherwise, which one might wish to compile with g++ 2.95. Newer g++ versions get pickier about C++ syntax and semantics, and thus it's reasonable to retain g++ 2.95 so that people don't have to port their old software to modern C++. (Yes, I said their old software. Lots of people have written C++ code that they want to run on Debian, unlike Windows drivers.) Fortunately it seems very few packages in Debian require gcc-2.95 or g++-2.95 anymore. So yes, I agree, at some point we should drop the whole gcc-2.95 source package. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Why on earth would anyone want to run the Windows version of a native Linux app under a Windows emulation under Linux? :-) Because they're a developer of that app and they want to test the Windows port before releasing? Okay, that's a bit of a corner case ;-) but nonetheless valid. Olaf -- 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 20, 2006 at 04:21:44PM -0600, Peter Samuelson wrote: [Wouter Verhelst] apt-cache rdepends libstdc++2.10-glibc2.2 Gee, only -dev, -dbg and gcc packages. Isn't that for non-free software? No, not really. There's plenty of software, free and otherwise, which one might wish to compile with g++ 2.95. Newer g++ versions get [...] Fortunately it seems very few packages in Debian require gcc-2.95 or g++-2.95 anymore. Uhm. How many reasonable and up-to-date free software exists that is not in Debian? Seriously. So yes, I agree, at some point we should drop the whole gcc-2.95 source package. I happen to think this discussion is getting increasingly silly. There's only one free driver which would work with ndiswrapper! there's many many many more Windows applications which are free! What people fail to mention is that there are many many many more Windows applications than there are drivers that use the NDIS environment, and that percentually, one free driver might be a *lot* more than the number of Free applications that are ran under wine. How many have ever used wine to run Free Software? -- 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)
[ObRC: 343781] On Tue, Feb 21, 2006 at 12:16:23AM +0100, Wouter Verhelst wrote: How many have ever used wine to run Free Software? I have. FWIW. I've also used wine in the process of developing and testing non-free software. I think that's a valid rationale for keeping wine in main; we don't require that people demonstrate word processors being used to create free documents before we say they can go in main, because using them to create *non*-free documents is a valid use case, and the Social Contract only talks about whether we *depend* on non-free stuff -- not whether the user chooses to use the program for non-free stuff. The same reasoning potentially applies to ndiswrapper, but I don't think it makes sense to base this on a hypothetical. If people *are* using ndiswrapper for developing drivers -- free or non-free -- then ok. If we're just saying it *could* be used that way, then this is rationalization. I know ndiswrapper wouldn't be useful to me if I didn't have a non-free Windows driver to go with it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: Because it's free software that processes asm input, and there is a significant amount of useful, free i386 asm that makes nasm necessary ? I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. This is beside the point. IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, so there's no reason it can't go in main. In fact, since it would be tremendously useful to be able to activate wireless ethernet devices with non-free drivers (from floppy/cd) during the install process, I'd say that it makes even more sense for ndiswrapper to go into main (and maybe even into base). --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 (was: Bug#353277: should be in contrib)
On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote: IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. 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. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Tue, Feb 21, 2006 at 03:36:16PM +1000, Anthony Towns wrote: On Mon, Feb 20, 2006 at 09:01:40PM -0800, Adam McKenna wrote: IMHO, the main purpose of contrib is to avoid shipping things on CD that depend on programs in non-free. It is not a section that we put programs in in order to 'punish' them for depending on non-free code. 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. 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 drivers, one could argue that the utility of having ndiswrapper in main (especially if it is integrated into the install) outweighs any potential drawbacks (and since the only drawback I can see is pissing off zealots/fundamentalists, I'd be all for it.) Thankfully, there is no need to make that argument, since at least one free NDIS driver exists (the aforementioned CIPE). ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? --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 (was: Bug#353277: should be in contrib)
[Michael Poole] What's the purpose of an assembler without assembly code to use it on? Despite Anthony's claim, I see no packages that can use nasm out of the box If you hadn't already shot your credibility, you just did. Anthony listed a dozen or so packages in Debian which require nasm in order to build. How can you see no packages when he gave you an explicit list of them? If you want to move ndiswrapper to contrib, I expect the next step is to do the same to libflash, for the same reasons. There's a big difference between enabling someone to install non-free software, and enabling someone to view data. (Some of which is free, some not.) Also, in case this was your point, swf content is sometimes generated with free tools such as ploticus. move interpreter and compilers for Java bytecode to contrib. After all, the point of Java is to allow the running of non-free software. Mono and DotGNU would get the same treatment. Right? 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 easy to find. Can you say the same of ndiswrapper? Please be prepared to present the testimonials of all the Windows driver developers you know who really wish they could conveniently test their Windows drivers on Debian, because I find it hard to believe there are any. We've already established that nobody can find any free Windows drivers for use with ndiswrapper, except one which is pointless as it's a port of a driver Debian already has as native code. signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
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. -- 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)
Peter Samuelson writes: [Michael Poole] What's the purpose of an assembler without assembly code to use it on? Despite Anthony's claim, I see no packages that can use nasm out of the box If you hadn't already shot your credibility, you just did. Anthony listed a dozen or so packages in Debian which require nasm in order to build. How can you see no packages when he gave you an explicit list of them? I assumed that the relationship would show up on the binary package pages of pdo.debian.net, or as rdepends on nasm's source package page. They do not. If you want to move ndiswrapper to contrib, I expect the next step is to do the same to libflash, for the same reasons. There's a big difference between enabling someone to install non-free software, and enabling someone to view data. (Some of which is free, some not.) Also, in case this was your point, swf content is sometimes generated with free tools such as ploticus. What is the difference? I thought GR 2004-003 was all about recognizing software as software, whether some people call it documentation or programs. SWF may be generated with free tools, but under a strict reading of Policy, that is insufficient to qualify for main. move interpreter and compilers for Java bytecode to contrib. After all, the point of Java is to allow the running of non-free software. Mono and DotGNU would get the same treatment. Right? 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 easy to find. Can you say the same of ndiswrapper? Please be prepared to present the testimonials of all the Windows driver developers you know who really wish they could conveniently test their Windows drivers on Debian, because I find it hard to believe there are any. We've already established that nobody can find any free Windows drivers for use with ndiswrapper, except one which is pointless as it's a port of a driver Debian already has as native code. 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. Michael Poole -- 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)
Josselin Mouette writes: Le samedi 18 février 2006 à 21:32 -0500, Michael Poole a écrit : 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. Sure. The unfortunate side effect is that some reasonable fraction of people who would use those drivers cannot install from install media that contain only Debian. They require bits of non-free. As is often pointed out, Debian has chosen (twice) to make life hard for those users. I guess the preferred solution for them is to just use some other distribution. 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. 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. 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. If installation media for Debian must include arbitrary bits of non-free, it makes the distinction between main and those bits rather pointless and arbitrary. Michael Poole
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le dimanche 19 février 2006 à 08:46 -0500, Michael Poole a écrit : 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. 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. 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. If installation media for Debian must include arbitrary bits of non-free, it makes the distinction between main and those bits rather pointless and arbitrary. Given how the debian-installer works, it would be possible to make it use optional, alternate sources for udebs. IIRC, it was planned from the beginning but nobody took the time to implement it. That'd be what I call a technical solution. Another possibility would be to setup a non-free alternate debian-installer image, that would include some bits of non-free. A technical issue has technical solutions. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le dimanche 19 février 2006 à 08:40 -0500, Michael Poole a écrit : If you hadn't already shot your credibility, you just did. Anthony listed a dozen or so packages in Debian which require nasm in order to build. How can you see no packages when he gave you an explicit list of them? I assumed that the relationship would show up on the binary package pages of pdo.debian.net, or as rdepends on nasm's source package page. They do not. Indeed. If you don't know what a build-dependency is, may I suggest that you read the basic Debian developer documentation before trying to contribute on that Debian development mailing list? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sun, Feb 19, 2006 at 02:11:30AM -0600, Peter Samuelson wrote: 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 easy to find. Can you say the same of ndiswrapper? Please be prepared to present the testimonials of all the Windows driver developers you know who really wish they could conveniently test their Windows drivers on Debian, because I find it hard to believe there are any. We've already established that nobody can find any free Windows drivers for use with ndiswrapper, except one which is pointless as it's a port of a driver Debian already has as native code. Hi Peter, if a piece of software was initially created to enable the use of non-dfsg software with a dfsg system it is classified as '?contri', but then someone creates dfsg-software to use this software, now its classified as 'main'. Would this follow? And then once in main, if the dfsg-use is abondoned, would it be reclassified as 'contrib'? But it also seems that the dfsg-use is not an absolute condition, it has to be deem non-toy and useful which is not an easily agreed upon idea. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Josselin Mouette writes: Le dimanche 19 février 2006 à 08:46 -0500, Michael Poole a écrit : 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. 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. 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. If installation media for Debian must include arbitrary bits of non-free, it makes the distinction between main and those bits rather pointless and arbitrary. Given how the debian-installer works, it would be possible to make it use optional, alternate sources for udebs. IIRC, it was planned from the beginning but nobody took the time to implement it. That'd be what I call a technical solution. In other words, exactly as I said: if the user only has Debian, the hardware will not be usable. Michael Poole
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Josselin Mouette writes: Le dimanche 19 février 2006 à 08:40 -0500, Michael Poole a écrit : If you hadn't already shot your credibility, you just did. Anthony listed a dozen or so packages in Debian which require nasm in order to build. How can you see no packages when he gave you an explicit list of them? I assumed that the relationship would show up on the binary package pages of pdo.debian.net, or as rdepends on nasm's source package page. They do not. Indeed. If you don't know what a build-dependency is, may I suggest that you read the basic Debian developer documentation before trying to contribute on that Debian development mailing list? I am quite familiar with Build-Depends and what they mean; however, I assumed that a certain web site would have certain basic functionality (similar to what is in aptitude) when it does not. Please note that even though I think you are acting like an idiot in this matter, I do not make insulting suggestions based on the assumption that you are in general an idiot. Could you please return the favor? Michael Poole
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 01:42:38PM +0100, Robert Millan wrote: On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote: On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. 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? You can apply this argument to every single package in contrib. No, that's not true. ndiswrapper is an environment for running software, much in the same way as wine is an environment for running software. Heck, even much in the same way that a PC is an environment for running software. Wine is something that was written to make the use of Windows binary software possible on Linux. The fact that you'd do it this way, rather than recompiling the application for Linux and running such a recompiled version instead is a serious indication that the software you're trying to run is, most likely, not a free application. But does that mean that wine requires the use of non-free software? I say it does not. Because there is a major difference between an application that requires the use of a library that is non-free, and a library that allows or facilitates the use of non-free software. Wine and ndiswrapper are in the latter category; a GPL'ed application which is written in Java that requires the use of a non-free API is not, and is in a completely different ballpark. If a free driver/datafile/whatever existed, it would be possible to run Foo without requiring non-free stuff, therefore it belongs to main Is your point that contrib should therefore be empty and has no reason for existance? No. Please don't put words in my mouth if what I said can't be used to make your point. It is already possible to use ndiswrapper without having any non-free software installed. Granted, it doesn't do much useful that way, but a) neither the DFSG nor the SC say anything about usefulness, and b) if a free library package exists in main which no other free package uses it, we don't move the free library package to contrib either. -- 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)
Bug cc dropped. On Sun, Feb 19, 2006 at 03:14:40AM +0100, Wouter Verhelst wrote: Wine is something that was written to make the use of Windows binary software possible on Linux. Yes, and there's plenty of useful, free software compiled as Windows binaries. Some of which is only available as a Windows binary, such as TurboCASH. It is already possible to use ndiswrapper without having any non-free software installed. Granted, it doesn't do much useful that way, If you have to differentiate between able to be used and useful, you don't have a point. but a) neither the DFSG nor the SC say anything about usefulness, and b) if a free library package exists in main which no other free package uses it, we don't move the free library package to contrib either. If it's only useful for non-free software, we should probably consider it. More likely, it's not useful at all, and we should consider dropping it entirely. How many libraries do we have in this state? Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Fri, Feb 17, 2006 at 08:14:38PM -0500, Michael Poole wrote: Then please work to revise [Removed false premise fallacy] Last time your argument was that free NDIS drivers exist, so the situation is analogous to wine. Nobody bothered to check, but it turns out that only one free driver exists, and it's pretty pointless since it's a port of something we already have. Ok, quoting: Social Contract: We will never make the system require the use of a non-free component. Policy: 2.2.2 The contrib section [...] Examples of packages which would be included in contrib are: * [...] * wrapper packages or other sorts of free accessories for non-free programs. Without something to work on, an assembler is just as useless as ndiswrapper. Which package(s) in main depend on nasm? You can check that yourself. I guess a few dozens. Why not file a bug report against it, demanding that it be moved to contrib? Because it's free software that processes asm input, and there is a significant amount of useful, free i386 asm that makes nasm necessary ? I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. (That is a rhetorical question. Lack of any answer will probably help you understand why contrib exists.) -- Robert Millan -- 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)
El sáb, 18-02-2006 a las 09:40 +0100, Robert Millan escribió: On Fri, Feb 17, 2006 at 08:14:38PM -0500, Michael Poole wrote: Then please work to revise [Removed false premise fallacy] Last time your argument was that free NDIS drivers exist, so the situation is analogous to wine. Nobody bothered to check, but it turns out that only one free driver exists, and it's pretty pointless since it's a port of something we already have. Ok, quoting: Social Contract: We will never make the system require the use of a non-free component. And ndiswrapper does not require it. It will only be useless without a driver, not a non-free driver. At most you could ask for it to be removed as useless piece of software (which is not and we have a lot of that in Debian is some way or other). BTW, if we start being more intregrist than those burning consulates because of some drawings, we should start by removing GPG signatures and md5sums from main, as those are invariant bits. Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. 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 there is a brand shiny new file format of which the spec has been fully disclosed and published in an RFC, though no free editors exist (yet) for the format, does that make the format non-free? -- 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 Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote: On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote: I'll ask again: Is the purpose of ndiswrapper running non-free drivers? If it isn't, show me a free, non-toy, non-POC driver that would prove otherwise. 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? You can apply this argument to every single package in contrib. If a free driver/datafile/whatever existed, it would be possible to run Foo without requiring non-free stuff, therefore it belongs to main 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. -- Robert Millan -- 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)
Robert Millan writes: Policy: 2.2.2 The contrib section [...] Examples of packages which would be included in contrib are: Here's the part that you left out: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. Without something to work on, an assembler is just as useless as ndiswrapper. Which package(s) in main depend on nasm? You can check that yourself. I guess a few dozens. Why not file a bug report against it, demanding that it be moved to contrib? Because it's free software that processes asm input, and there is a significant amount of useful, free i386 asm that makes nasm necessary ? But nasm requires such assembly for useful execution! This is the same situation as ndiswrapper. Neither are very useful unless you use them with software that is not in main. They both *compile* and *execute* without extra software, which is all that policy requires. You are the one who insists that the execution must be free, non-toy, non-POC, and that is why I said that if you want to change the state of things, you should revise the DFSG or policy. Michael Poole -- 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 18, 2006 at 08:46:53AM -0500, Michael Poole wrote: But nasm requires such assembly for useful execution! Dude, you're on crack. First, there's apparently free software in main that you can compile with nasm to your heart's content, namely crystalspace, drip, e3, effectv, extipl, flac, hermes1, libgpeg-mmx, libopenspc, mknbi, motion, pearpc, psemu-video-x11, sbm, scummvm, syslinux, visualboyadvance, vlc, xmms-openspc, zinf, and zsnes. But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. If there aren't any free ones, or the free ones are useless toys, then it belongs in contrib because its purpose is to allow you to run non-free software. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Anthony Towns writes: But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. This apparently means that you object to translation at the binary level but not translation at the source level. I guess that's reasonable in a general sense, it's just not a distinction that policy or the DFSG makes. Michael Poole -- 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)
Le samedi 18 février 2006 à 09:59 -0500, Michael Poole a écrit : Anthony Towns writes: But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. This apparently means that you object to translation at the binary level but not translation at the source level. I guess that's reasonable in a general sense, it's just not a distinction that policy or the DFSG makes. Come on, please stop arguing with random, unsuited comparisons, and use common sense : what's the purpose of ndiswrapper without non-free drivers to use it on? We've always put things of the like in contrib, and if we stop doing it, we can remove contrib entirely. Why are you trying so hard to keep it in main? Putting it in contrib doesn't mean we'd stop supporting it. If this is about availability by default, you'd better work on d-i so that it can load drivers from contrib and non-free if provided, instead of trying to put each and every driver with a firmware or another non-free bit in main. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Josselin Mouette writes: Le samedi 18 février 2006 à 09:59 -0500, Michael Poole a écrit : Anthony Towns writes: But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. This apparently means that you object to translation at the binary level but not translation at the source level. I guess that's reasonable in a general sense, it's just not a distinction that policy or the DFSG makes. Come on, please stop arguing with random, unsuited comparisons, and use common sense : what's the purpose of ndiswrapper without non-free drivers to use it on? We've always put things of the like in contrib, and if we stop doing it, we can remove contrib entirely. What's the purpose of an assembler without assembly code to use it on? Despite Anthony's claim, I see no packages that can use nasm out of the box, which means it needs software not in main to perform its intended use (which seems to be the objection to ndiswrapper). If you want to move ndiswrapper to contrib, I expect the next step is to do the same to libflash, for the same reasons. Next: natively compile all Java packages in main and move interpreter and compilers for Java bytecode to contrib. After all, the point of Java is to allow the running of non-free software. Mono and DotGNU would get the same treatment. Right? Michael Poole
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
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. Despite Anthony's claim, I see no packages that can use nasm out of the box, which means it needs software not in main to perform its intended use (which seems to be the objection to ndiswrapper). Anthony listed a number of packages that require nasm for building. That is a clear case of nasm being used by packages in main. Nasm and ndiswrapper are in not comparable in any way that makes it useful to argue that ndiswrapper should be kept in main. -- Fundamental truth #3: Communication is difficult. -- 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 18, 2006 at 09:59:07AM -0500, Michael Poole wrote: Anthony Towns writes: But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. This apparently means that you object to translation at the binary level but not translation at the source level. I guess that's reasonable in a general sense, it's just not a distinction that policy or the DFSG makes. You have no idea what you're talking about. Which isn't surprising, considering you're apparently not a developer, maintainer, applicant or any other sort of regular contributor to Debian. In future, if you've got questions, please ask, rather than degrading the quality of the lists by doing the Usenet troll thing of posting authoritative statements that are complete wrong in order to get other people to correct you. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Anthony Towns writes: On Sat, Feb 18, 2006 at 09:59:07AM -0500, Michael Poole wrote: Anthony Towns writes: But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. This apparently means that you object to translation at the binary level but not translation at the source level. I guess that's reasonable in a general sense, it's just not a distinction that policy or the DFSG makes. You have no idea what you're talking about. Which isn't surprising, considering you're apparently not a developer, maintainer, applicant or any other sort of regular contributor to Debian. In future, if you've got questions, please ask, rather than degrading the quality of the lists by doing the Usenet troll thing of posting authoritative statements that are complete wrong in order to get other people to correct you. I was dragged into this conversation because someone cited, in a duplicate bug report, an email that I wrote more than a year ago. Please do not confuse that with doing the Usenet troll thing. But if you want to make Debian even more hostile to people on the outside, continue along your current path. Michael Poole -- 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)
First, I couldn't find any reference to a GPLed NDIS driver in ndiswrapper's website, like Michael Poole asserts: http://lists.debian.org/debian-devel/2005/01/msg00381.html I assume he was talking about the CIPE driver; it's linked right from the main ndiswrapper page. Why on earth would anyone want to run the Windows version of a native Linux app under a Windows emulation under Linux? :-) The Windows CIPE is linked from the ndiswrapper home page apparently as a reference to understand NDIS, which makes more sense to me. Olaf -- 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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 18 Feb 2006, Josselin Mouette wrote: Come on, please stop arguing with random, unsuited comparisons, and use common sense : what's the purpose of ndiswrapper without non-free drivers to use it on? We've always put things of the like in contrib, and if we stop doing it, we can remove contrib entirely. The purpose of ndiswrapper is to run non-free Windows drivers on Linux. The same is more or less true for wine and dosemu (otherwise we would probably make a native version of said apps). Would the situation change (contrib-wise) if ndiswrapper were integrated into the kernel? Would we want to split the ndiswrapper part to contrib then? - -- - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD95rRVYan35+NCKcRAk9/AKCz0PEtSLrjUfa2JHUSxFp1GC3yGwCg5gfT S18zHSeAQGSETSaZfkyPmps= =f4Pu -END PGP SIGNATURE- -- 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)
Le samedi 18 février 2006 à 23:08 +0100, Arthur de Jong a écrit : Would the situation change (contrib-wise) if ndiswrapper were integrated into the kernel? Would we want to split the ndiswrapper part to contrib then? In this case, the ndiswrapper functionality would become optional for the kernel package, just like e.g. w32codecs for xine. The same goes for a driver with a firmware. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Feb 18, Josselin Mouette [EMAIL PROTECTED] wrote: The same goes for a driver with a firmware. Drivers do not have a firmware, hardware devices do. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am Samstag, 18. Februar 2006 23:08 schrieb Arthur de Jong: On Sat, 18 Feb 2006, Josselin Mouette wrote: Come on, please stop arguing with random, unsuited comparisons, and use common sense : what's the purpose of ndiswrapper without non-free drivers to use it on? We've always put things of the like in contrib, and if we stop doing it, we can remove contrib entirely. The purpose of ndiswrapper is to run non-free Windows drivers on Linux. The same is more or less true for wine and dosemu (otherwise we would probably make a native version of said apps). An example: Inno Setup for creating self-extracting installers for win32 has a 4-clause BSD style license but needs Borland Delphi to compile. How would you make a native application (the command line utility would suffice)? I let it run with wine to create a distribution of a software for windows (using the very useful mingw32 packages). Same goes for dosemu that can run freedos. Those two do not compare to ndiswrapper. Would the situation change (contrib-wise) if ndiswrapper were integrated into the kernel? Would we want to split the ndiswrapper part to contrib then? Ndiswrapper will never be integrated into the kernel. However, I see drivers in linux that need non-free parts (=firmware) to run. Do those now go to contrib? Ndiswrapper probably is better compared to such drivers than to wine or dosemu. If you have to go by some laws but want mostly firmware driven hardware, you cannot have it all open source with a free license. You wouldn't have the proper compiler anyway. Maybe Debian should take one or two steps back to the point where it only requires source for something that can actually be compiled with something in Debian. For the rest, it should only matter if it's actually distributable. And yes, this is not much related to the ndiswrapper discussion. HS
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le samedi 18 février 2006 à 23:34 +0100, Marco d'Itri a écrit : On Feb 18, Josselin Mouette [EMAIL PROTECTED] wrote: The same goes for a driver with a firmware. Drivers do not have a firmware, hardware devices do. Really? So all these drivers that come with an integrated firmware don't really exist? They are only in my head, right, I have to call the doctor. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le samedi 18 février 2006 à 23:37 +0100, Hendrik Sattler a écrit : Maybe Debian should take one or two steps back to the point where it only requires source for something that can actually be compiled with something in Debian. Ahem... so, to force the trait, you mean we could distribute any kind of shareware that needs Visual C++ to build? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am Samstag, 18. Februar 2006 23:43 schrieb Josselin Mouette: Le samedi 18 février 2006 à 23:37 +0100, Hendrik Sattler a écrit : Maybe Debian should take one or two steps back to the point where it only requires source for something that can actually be compiled with something in Debian. Ahem... so, to force the trait, you mean we could distribute any kind of shareware that needs Visual C++ to build? You definitely didn't get the point! It's about the target architecture, not the system. Even if you actually _have_ the source, you could not compile with _any_ compiler you have at hand. And why would you want to ship programs targetted for Windows with Debian? They don't integrate into the unix directory layout anyway, thus making no sense as a package... And you want to write a compiler for this one chip to compile this single peace of firmware? You must have a lot of time ;) So let me make it more precise: only source for something that can actually be compiled and runs on a system's host CPU. Me just doesn't get the rationale behind differing between firmware in a PROM and firmware that the driver loads into the hardware. There is none. HS
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit : So let me make it more precise: only source for something that can actually be compiled and runs on a system's host CPU. Me just doesn't get the rationale behind differing between firmware in a PROM and firmware that the driver loads into the hardware. There is none. 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. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit : Me just doesn't get the rationale behind differing between firmware in a PROM and firmware that the driver loads into the hardware. There is none. Oh, and please, dear trolls, stop raising the firmwares-in-main banner in each and every single thread. This is getting tiring. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 08:24:32PM +0100, Olaf Titz wrote: First, I couldn't find any reference to a GPLed NDIS driver in ndiswrapper's website, like Michael Poole asserts: http://lists.debian.org/debian-devel/2005/01/msg00381.html I assume he was talking about the CIPE driver; it's linked right from the main ndiswrapper page. Why on earth would anyone want to run the Windows version of a native Linux app under a Windows emulation under Linux? :-) Because they're a developer of that app and they want to test the Windows port before releasing? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
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. Non-free is here for a reason, we just have to use it. Technical solutions to have the driver It would not be Debian anymore then. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Josselin Mouette writes: Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit : So let me make it more precise: only source for something that can actually be compiled and runs on a system's host CPU. Me just doesn't get the rationale behind differing between firmware in a PROM and firmware that the driver loads into the hardware. There is none. 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. Sure. The unfortunate side effect is that some reasonable fraction of people who would use those drivers cannot install from install media that contain only Debian. They require bits of non-free. As is often pointed out, Debian has chosen (twice) to make life hard for those users. I guess the preferred solution for them is to just use some other distribution. Michael Poole
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le dimanche 19 février 2006 à 01:52 +0100, Marco d'Itri a écrit : 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. It is good for our users to lie to them by pretending our operating system full of non-modifiable bits is free? Non-free is here for a reason, we just have to use it. Technical solutions to have the driver It would not be Debian anymore then. The project has chosen to keep non-free, remember? Or are you telling this was a decorative decision and that your fellow developers only want to have non-free without anything in it? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Le samedi 18 février 2006 à 21:32 -0500, Michael Poole a écrit : 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. Sure. The unfortunate side effect is that some reasonable fraction of people who would use those drivers cannot install from install media that contain only Debian. They require bits of non-free. As is often pointed out, Debian has chosen (twice) to make life hard for those users. I guess the preferred solution for them is to just use some other distribution. 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. 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. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Hendrik Sattler] Me just doesn't get the rationale behind differing between firmware in a PROM and firmware that the driver loads into the hardware. There is none. 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.) signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote: [...] First, I couldn't find any reference to a GPLed NDIS driver in ndiswrapper's website, like Michael Poole asserts: http://lists.debian.org/debian-devel/2005/01/msg00381.html I assume he was talking about the CIPE driver; it's linked right from the main ndiswrapper page. -- 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 Fri, Feb 17, 2006 at 12:40:10PM -0500, Andres Salomon wrote: On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote: [...] First, I couldn't find any reference to a GPLed NDIS driver in ndiswrapper's website, like Michael Poole asserts: http://lists.debian.org/debian-devel/2005/01/msg00381.html I assume he was talking about the CIPE driver; it's linked right from the main ndiswrapper page. I see. From http://cipe-win32.sourceforge.net/ : CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT. I think this is the cipe-source package in debian. If this driver is already available, there's no much point in using it via ndiswrapper. Is there any other free ndis driver? -- Robert Millan -- 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 Feb 17, Robert Millan [EMAIL PROTECTED] wrote: I see. From http://cipe-win32.sourceforge.net/ : CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT. I think this is the cipe-source package in debian. If this driver is already available, there's no much point in using it via ndiswrapper. This does not make ndiswrapper more dependent on non-free software, so I can't see why it should be relevant. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Fri, 2006-02-17 at 23:48 +0100, Robert Millan wrote: On Fri, Feb 17, 2006 at 12:40:10PM -0500, Andres Salomon wrote: On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote: [...] First, I couldn't find any reference to a GPLed NDIS driver in ndiswrapper's website, like Michael Poole asserts: http://lists.debian.org/debian-devel/2005/01/msg00381.html I assume he was talking about the CIPE driver; it's linked right from the main ndiswrapper page. I see. From http://cipe-win32.sourceforge.net/ : CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT. I think this is the cipe-source package in debian. If this driver is already available, there's no much point in using it via ndiswrapper. Is there any other free ndis driver? I have no idea; I don't particularly care. I don't see the point of this whole discussion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
