Re: Bug#353277: ndiswrapper in main
On Tue, Mar 07, 2006 at 01:41:58PM +1000, Anthony Towns wrote: Okay, so here's the alternate proposal. I understand Raul at least disagrees with paragraph (3) (and obviously the conclusions based on that), but I'm not sure we have any good way of noting that difference of opinion -- perhaps we should include the previous draft in the vote? Courts and parliamentary committees include minority views (and the arguments for them) in their final reports; something like that might be worth doing here too. Given that the constitution does specify the use of the standard resolution procedure, I think the right answer here is to have a single ballot with both proposals on it, so that we have an opportunity to rank the options in glorious Condorcet fashion. ;) I certainly think devotee is overkill, though; with seven eligible voters, I'm content to tally the votes by hand. Given that there's been no formal call for votes on either Raul's proposal or on this one, then, I think we should take another day for any further input (additional resolutions, editorial corrections, etc), then put these on a ballot and call for votes. Either way, I propose the following, call for a vote on it, and vote in favour: If you agree with the above, I think we should suspend voting on this proposal alone in the interest of clarity. Also, FWIW I believe this should be s/compatability/compatibility/g on the draft. Cheers, -- 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/ WHEREAS 1. The committee has been asked by Robert Millan, the submitter of Bug#353278 and a former developer, to overrule the decision by the maintainer of the ndiswrapper package, Andres Salomon, to include that package in the main component of the archive, and for it to be moved to the contrib component; and 2. The committee is empowered under section 6.1(4) of the constitution to overrule a maintainer by a 3:1 majority vote, and empowered under section 6.1(1) to decide on any matter of technical policy; and 3. The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for Windows NDIS drivers, and that in order to provide this compatability layer, no non-free software is required; and 4. The primary use for this compatability layer is to run non-free Windows drivers for hardware not directly supported by Linux, though a very limited number of free drivers using the NDIS format also exist; and 5. The technical policy in this matter states that: (debian-policy 3.6.2.2, section 2.2.1) [...] packages in _main_ * must not require a package outside of _main_ for compilation or execution and: (debian-policy 3.6.2.2, section 2.2.2) Examples of packages which would be included in _contrib_ are: * 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. THE COMMITTEE CONCLUDES THAT 6. It is appropriate for the committee to consider this request; and 7. The current ndiswrapper package does not require any non-free software at either compilation time or installation time to fulfill its designated purpose; and 8. As such the ndiswrapper package complies with current technical policy as regards to its suitability for main; and 9. If the ndiswrapper package come to depend on non-free software at compilation time or installation time, such as by prompting the user for a Windows driver CD, at that time the ndiswrapper package would be required to be moved to contrib. IN ADDITION 10. The committee endorses the decisions of the maintainer of ndiswrapper and the ftpmaster team in including the package in the main component as being in compliance with Debian technical policy; and 11. The committee endorses the existing policy on the suitability of packages for the main and contrib components; and 12. The committee offers its thanks to Robert Millan for raising the issue; to Wouter Verhelst and others for their input on the topic; and to Andres Salomon for his ongoing efforts in maintaining the ndiswrapper packages. signature.asc Description: Digital signature
Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.
Processing commands for [EMAIL PROTECTED]: reassign 345067 tech-ctte Bug#345067: [powerpc] ide-generic is not built on powerpc, yaird tries to include it and fails Bug#343427: linux-image-2.6.14-2-powerpc: Installation fails Bug reassigned from package `yaird' to `tech-ctte'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.
On Tue, Mar 07, 2006 at 02:03:17AM -0800, Debian Bug Tracking System wrote: Subject: Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this. reassign 345067 tech-ctte Bug#345067: [powerpc] ide-generic is not built on powerpc, yaird tries to include it and fails Bug#343427: linux-image-2.6.14-2-powerpc: Installation fails Bug reassigned from package `yaird' to `tech-ctte'. I can see there's some sort of dispute over this bug, but I can't see a precise explanation of exactly what it breaks. Jonas Smedegaard's comment in #343427, in response to Sven Luther: The ide-generic module is not built on powerpc, In the _current_ _official_ kernel package in Debian, or in any sysfs-supporting powerpc Linux kernel ever, locally built or not? seems to be the important question; and I gather the answer is that the official kernel packages don't use it, but that some can. Contents-powerpc seems to bear this out, as does my config-2.6.15-1-powerpc: # CONFIG_IDE_GENERIC is not set Has anyone at all spoken to the via82cxxx upstream about getting the dependency information fixed so that this hack isn't needed in the first place? Cheers, aj signature.asc Description: Digital signature
Re: Bug#345067: jonas, you are being dishonest.
On Tue, Mar 07, 2006 at 02:15:56PM +0100, Sven Luther wrote: I am severly disapointed with you, and you are a liar by claiming that i Sven, there is no need to call anyone a liar. Cheers, aj signature.asc Description: Digital signature
Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.
On Tue, Mar 07, 2006 at 11:43:34PM +1000, Anthony Towns wrote: On Tue, Mar 07, 2006 at 02:03:17AM -0800, Debian Bug Tracking System wrote: Subject: Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this. reassign 345067 tech-ctte Bug#345067: [powerpc] ide-generic is not built on powerpc, yaird tries to include it and fails Bug#343427: linux-image-2.6.14-2-powerpc: Installation fails Bug reassigned from package `yaird' to `tech-ctte'. I can see there's some sort of dispute over this bug, but I can't see a precise explanation of exactly what it breaks. ide-generic is not built on powerpc, yaird will inconditionally try to include ide-generic into the ramdisk if via82cxxx is present (while the real hacky workaround was not to load it always, but only to load it after via82cxxx). As a resuly, any powerpc machine using the via82cxxx module has a kernel which is uninstallable with yaird, and as yaird used to be the default, this means upgrade to newer kernel are uninstallable without hand-hacking yaird. Jonas Smedegaard's comment in #343427, in response to Sven Luther: The ide-generic module is not built on powerpc, In the _current_ _official_ kernel package in Debian, or in any sysfs-supporting powerpc Linux kernel ever, locally built or not? seems to be the important question; and I gather the answer is that the official kernel packages don't use it, but that some can. Contents-powerpc Well, even if some *can* use it, that is no reason enough to force it down the throat of everyone, and in any case, it is not enough to claim it is *needed*. In fact i claim that the fact that the official kernel work without ide-generic is proof enough that it *cannot* be *needed* on powerpc. (at this point jonas simply refused to pursue the discussion, and there is no other issue apart fro mthe tech comittee or an hostile takeover). seems to bear this out, as does my config-2.6.15-1-powerpc: # CONFIG_IDE_GENERIC is not set Has anyone at all spoken to the via82cxxx upstream about getting the dependency information fixed so that this hack isn't needed in the first place? Well, it is not really a dependency as far as i see. The real problem is that some x86 machines exhibited strange behavior with regard to DMA, when ide-generic was loaded before via82cxxx, which is logical since it seems ide-generic cannot do DMA without a real driver, and thus the solution was to force ide-generic loading after via82cxx always, on all arches, without even checking if ide-generic was built or not. My patch may not be the best, it just reverted that previous hack on powerpc only, but all i got in return was silence, and then plain refusal to even hear the argumentation exposed here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345067: jonas, you are being dishonest.
On Wed, Mar 08, 2006 at 12:14:38AM +1000, Anthony Towns wrote: On Tue, Mar 07, 2006 at 02:15:56PM +0100, Sven Luther wrote: I am severly disapointed with you, and you are a liar by claiming that i Sven, there is no need to call anyone a liar. Well, he is lying about this, he refused to discuss it with me in real life in erkelenz, i heard him give out his arguments, but then he refused to hear mine. And now he claims the contrary happened. Sorry, but that is the definition of a lie to me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of resolutions about TC tweaks
Andreas Barth writes (Re: Status of resolutions about TC tweaks): We establish a rule that we won't make decisions on issues that are ready. This means, - for overruling a package maintainer's decision, an appropriate package for an NMU exists, and if we overrule, we upload that NMU; - for other overrulings, an appropriate patch exists, and if we overrule and someone from the tech ctte can apply that patch, we apply it; - for other decisions, we make sure a similar state of readiness exists. I agree with these principles. But I think the answer is for the individual committee members to apply them and to say if they think the issue isn't ready. There is no need for the committee to pass a resolution formally setting a policy (since the committee could choose to ignore it anyway); and if we can't quite agree on the policy then we'll just end up arguing about it when we should be arguing about actual cases and issues instead. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345067: [Yaird-devel] Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.
On 3/7/06, Sven Luther [EMAIL PROTECTED] wrote: On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote: Please see http://wiki.debian.org/LinuxKernelIdeProblem that I created today and have invited the kernel team and udev developers to improve on. An assembly of patent ... It looks to me like that's a wiki page. In other words, you can fix problems on it directly without needing to ask for help or permission. Though, obviously, including references to supporting information will probably be a good thing in the context of future changes. I think posting corrections there might be a useful approach. -- Raul
Re: Bug#353277: ndiswrapper in main
Steve Langasek writes (Re: Bug#353277: ndiswrapper in main): Given that the constitution does specify the use of the standard resolution procedure, I think the right answer here is to have a single ballot with both proposals on it, so that we have an opportunity to rank the options in glorious Condorcet fashion. ;) Quite so. I certainly think devotee is overkill, though; with seven eligible voters, I'm content to tally the votes by hand. Indeed. Given that there's been no formal call for votes on either Raul's proposal or on this one, then, I think we should take another day for any further input (additional resolutions, editorial corrections, etc), then put these on a ballot and call for votes. I would like to draft a version of Anthony's answer that makes it a recommendation rather than a mandatory decision. In fact, we probably need four versions: * We think it's our decision and we decide (insisting iff 3:1) that it should go into main * We think it's our decision and we decide (insisting iff 3:1) that it should go into contrib * We think it's not our decision formally but we conclude that it should go into main * We think it's not our decision formally but we conclude that it should go into contrib It will be easier to draft those four alternatives than to have everyone write round and say which ones they prefer. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Here is a version of Anthony's `put it in main' resolution made into a suggestion rather than an instruction. Below you'll find a diff for your comfort and convenience. WHEREAS 1. The committee has been asked by Robert Millan, the submitter of Bug#353278 and a former developer, to overrule the decision by the maintainer of the ndiswrapper package, Andres Salomon, to include that package in the main component of the archive, and for it to be moved to the contrib component; and 2. This question is a mixture of political and technical questions and the Committee's power to decide it is unclear; however, in the absence of a decision by the committee it is likely that no decision at all will be made. 3. The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for Windows NDIS drivers, and that in order to provide this compatability layer, no non-free software is required; and 4. The primary use for this compatability layer is to run non-free Windows drivers for hardware not directly supported by Linux, though a very limited number of free drivers using the NDIS format also exist; and 5. The policy in this matter states that: (debian-policy 3.6.2.2, section 2.2.1) [...] packages in _main_ * must not require a package outside of _main_ for compilation or execution and: (debian-policy 3.6.2.2, section 2.2.2) Examples of packages which would be included in _contrib_ are: * 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. THE COMMITTEE CONCLUDES THAT 6. It is appropriate for the committee to consider this request but not by itself to overturn established political policy; and 7. The current ndiswrapper package does not require any non-free software at either compilation time or installation time to fulfill its designated purpose; and 8. As such the committee believes the ndiswrapper package complies with current policy as regards to its suitability for main; and 9. If the ndiswrapper package comes to depend on non-free software at compilation time or installation time, such as by prompting the user for a Windows driver CD, at that time the ndiswrapper package would be required to be moved to contrib. IN ADDITION 10. The committee notes its approval of the decisions of the maintainer of ndiswrapper and the ftpmaster team in including the package in the main component as being in compliance with current Debian policy; and 11. The committee notes its approval of the existing policy on the suitability of packages for the main and contrib components; and 12. The committee offers its thanks to Robert Millan for raising the issue; to Wouter Verhelst and others for their input on the topic; and to Andres Salomon for his ongoing efforts in maintaining the ndiswrapper packages. 13. The committee believes this is not a wholly technical issue, and that the general policy decisions in question are largely political, so this does not fall into our explicit remit. This decision is therefore advisory. However, we recommend that all parties concerned follow our advice unless and until a contrary statement is issued by the Project Leader or an appropriate Delegate. Ian. --- 1 2006-03-08 00:33:30.0 + +++ 2 2006-03-08 00:33:01.0 + @@ -6,9 +6,10 @@ that package in the main component of the archive, and for it to be moved to the contrib component; and -2. The committee is empowered under section 6.1(4) of the constitution to -overrule a maintainer by a 3:1 majority vote, and empowered under section -6.1(1) to decide on any matter of technical policy; and +2. This question is a mixture of political and technical questions +and the Committee's power to decide it is unclear; however, in the +absence of a decision by the committee it is likely that no +decision at all will be made. 3. The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for @@ -20,7 +21,7 @@ a very limited number of free drivers using the NDIS format also exist; and -5. The technical policy in this matter states that: (debian-policy +5. The policy in this matter states that: (debian-policy 3.6.2.2, section 2.2.1) [...] packages in _main_ @@ -38,30 +39,40 @@ THE COMMITTEE CONCLUDES THAT -6. It is appropriate for the committee to consider this request; and +6. It is appropriate for the committee to consider this request +but not by itself to overturn established political policy; and 7. The
Re: Bug#345067: jonas, you are being dishonest.
On Tue, Mar 07, 2006 at 02:15:56PM +0100, Sven Luther wrote: I am severly disapointed with you, and you are a liar by claiming that i didn't hear your arguments, i did hear them, and when i tried to give mines, you refused to continue the conversation. I remember well your arguments, and they where nothing to be proud of, you basically claimed that : This kind of petty bickering has no place in the technical committee (or, for that matter, in the BTS at all). You have submitted a technical issue to the TC, and we will consider it; personal attacks on the package maintainer are irrelevant, and a waste of both your time and ours which will only delay the process of the tech ctte reaching a decision as we are forced to sift through this nonsense. If you can't limit yourself to civilly presenting relevant technical information, then I would recommend that you keep quiet altogether until the committee asks for your input. -- 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
Raul Miller writes (Re: Bug#353277: ndiswrapper in main): On 3/7/06, Ian Jackson [EMAIL PROTECTED] wrote: Here is a version of Anthony's `put it in main' resolution made into a suggestion rather than an instruction. Below you'll find a diff for your comfort and convenience. I vote against this proposal for the same reasons I voted against the original. Err, I wasn't proposing it for voting on. I should be clearer. Alternatively, if we're going to have a proper ballot listing several different options, I'll be voting further discussion ahead of both this proposal and Aj's original. Indeed so. Ina. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
