Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Gunnar Wolf wrote: A PDF _can_ be the source - If it uses OpenOffice's new Hybrid PDF format [1], which embeds an ODF. Of course, that is _very_ seldom the case. (and writing practically anything with OOo is... Bah, I just hate the Office mindset. It is an inefficient as it gets!) You can edit PDF files with Adobe Acrobat too. They don't need to by hybrid documents. I think this is very dodgy and also requires proprietary software to do the editing. I don't know of any DFSG software that will do the same thing. However it is possible. Is there any requirement that says the source code must be editable in a sane manner (e.g. editing a PDF file with a binary hex editor would not be sane) with entirely DFSG compliant tools? Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Wed, Oct 29, 2008 at 11:16 AM, Brian May [EMAIL PROTECTED] wrote: You can edit PDF files with Adobe Acrobat too. They don't need to by hybrid documents. I think this is very dodgy and also requires proprietary software to do the editing. I don't know of any DFSG software that will do the same thing. pdfedit is in main, and works when it doesn't crash. Is there any requirement that says the source code must be editable in a sane manner (e.g. editing a PDF file with a binary hex editor would not be sane) with entirely DFSG compliant tools? That would be a practical matter rather than a DFSG one IMO. We have packages in Debian that are in this situation right now, check the archived bugs on beneath-a-steel-sky for example. #442192 from the nsis package is another example. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
What source is [Re: Bug reports of DFSG violations are tagged ???lenny-ignore????]
On Wed, 29 Oct 2008, Brian May wrote: Is there any requirement that says the source code must be editable in a sane manner (e.g. editing a PDF file with a binary hex editor would not be sane) with entirely DFSG compliant tools? Source code is the (digitally-distributable) form of a work that is (closest to) the prefered form of modification.[0] That is to say, the form of the work that the upstream author would actually use to modify the work. If the upstream author modifies the work using a binary hex editor, then that's what the source is.[1] There may be open questions about whether we need to provide source for everything,[2] and whether source includes the tools necessary to build and/or modify,[3] but those are separate questions, none of which are particularly on topic on this mailing list. [-project is the appropriate place to discuss that.] Don Armstrong 0: The parentheticals deal with cases where the prefered form of modification has been lost or the prefered form of modification is some kind of physical object that can't be distributed. 1: I'd argue against distributing something because it would be impossible to maintain, and the upstream author is likely to be insane, but that's nothing to do with the DFSG. 2: Like firmware or documentation 3: Compilers, editors, etc. -- To steal ideas from one person is plagiarism; to steal from many is research. -- Steven Wright http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Hi Brian! On Wed, 29 Oct 2008 03:16:07 +0100, Brian May wrote: You can edit PDF files with Adobe Acrobat too. They don't need to by hybrid documents. I think this is very dodgy and also requires proprietary software to do the editing. I don't know of any DFSG software that will do the same thing. FYI, Inkscape is supposed to import PDF files [1], but the process is far from perfect. Thx, bye, Gismo / Luca Footnotes: [1] http://wiki.inkscape.org/wiki/index.php/Current_PDF_Support pgp5cJX12O6jL.pgp Description: PGP signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Romain Beauxis [EMAIL PROTECTED] wrote: Do you claim a PDF file is a binary file, or a program object ? Even if PDF was a programming language, as proposed in another anwser, it would fall into the script category, where the executed object is also the source. In most cases, the PDF is not the source. If you want to comply to the ftp-masters' current rules, you could easily extract the text and images from the PDF using the available free tools, and create a LaTeX file from it (or OOwriter if you prefer). It would be some work to re-add the markup, but it would be doable, and you could generate a PDF file from it and ship it in a separate source package, with its LaTeX source. If the PDF is frozen documentation, it's probably worth the effort. If upstream changes the PDF with every new version, you should ask them for their sources instead. Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Hi, On Monday 27 October 2008 19:35, Frank Küster wrote: If the PDF is frozen documentation, it's probably worth the effort. If upstream changes the PDF with every new version, you should ask them for their sources instead. What if they use openoffice.org to edit the pdf and the pdf is the source? regards, Holger pgp7oZ4mwIrJx.pgp Description: PGP signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 01:15:44PM +0200, Thomas Weber wrote: You are missing my point. We[1] got a reject for a documentation PDF without source. So, we contacted upstream who checked the copyright with the company in order to release the source for the documentation. And yes, it's work, painful, whatever and I would have preferred not having to do it. Could you please elaborate here? The DFSG does not require us to have or ship source code for non-program works, and if documentation is being rejected on the basis of a *source* requirement (as distinct from a licensing issue), then I think we have a problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Steve Langasek [EMAIL PROTECTED] writes: Could you please elaborate here? The DFSG does not require us to have or ship source code for non-program works, and if documentation is being rejected on the basis of a *source* requirement (as distinct from a licensing issue), then I think we have a problem. Well, we ftpmasters and assistants routinely REJECT packages containing binary components without source, eg. PDF documentation. We base this policy on the DFSG as explained in http://www.debian.org/vote/2006/vote_001 which very clearly states that documentation needs to comply with the DFSG. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Sat, Oct 25, 2008 at 01:47:15AM -0700, Steve Langasek wrote: On Tue, Oct 21, 2008 at 01:15:44PM +0200, Thomas Weber wrote: You are missing my point. We[1] got a reject for a documentation PDF without source. So, we contacted upstream who checked the copyright with the company in order to release the source for the documentation. And yes, it's work, painful, whatever and I would have preferred not having to do it. Could you please elaborate here? Sure, what do you want to know? Rejection email: http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2008-April/003819.html Upstream tarball: http://downloads.sourceforge.net/octave/fixed-0.7.5.tar.gz?download Copyright of the PDF when uploaded: Copyright C 2004 Motorola Inc Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the same conditions as for modified versions. The C above was a copyright symbol. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Le Saturday 25 October 2008 10:56:56 Kalle Kivimaa, vous avez écrit : Steve Langasek [EMAIL PROTECTED] writes: Could you please elaborate here? The DFSG does not require us to have or ship source code for non-program works, and if documentation is being rejected on the basis of a *source* requirement (as distinct from a licensing issue), then I think we have a problem. Well, we ftpmasters and assistants routinely REJECT packages containing binary components without source, eg. PDF documentation. We base this policy on the DFSG as explained in http://www.debian.org/vote/2006/vote_001 which very clearly states that documentation needs to comply with the DFSG. The resolution states that GFDL licence does not fit for main, mainly because it has invariant sections, which are not *modifiable*. Extending a resolution beyond its original scope does sound broken an dangerous to me. Furthermore, request to have the source is a subjective thing. How would you provide the source of a (free) WAV file then ? Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Sat, Oct 25 2008, Romain Beauxis wrote: Le Saturday 25 October 2008 10:56:56 Kalle Kivimaa, vous avez écrit : Steve Langasek [EMAIL PROTECTED] writes: Could you please elaborate here? The DFSG does not require us to have or ship source code for non-program works, and if documentation is being rejected on the basis of a *source* requirement (as distinct from a licensing issue), then I think we have a problem. Well, we ftpmasters and assistants routinely REJECT packages containing binary components without source, eg. PDF documentation. We base this policy on the DFSG as explained in http://www.debian.org/vote/2006/vote_001 which very clearly states that documentation needs to comply with the DFSG. The resolution states that GFDL licence does not fit for main, mainly because it has invariant sections, which are not *modifiable*. Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. A PDF consists of a turing complete programming language, so any PDF file is really an executable program, interpreted by the pdf interpreter. Seems like asking for the sources would be valid for PDF and postsript programs, een if all the program does is to render things into bitmap formats suitable for readers. manoj -- Fights between cats and dogs are prohibited by statute in Barber, North Carolina. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Hi, I take that back. postscript is a programming language, PDF might not be. Scratch what I said in my previous email. manoj -- The early bird gets the coffee left over from the night before. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Romain Beauxis [EMAIL PROTECTED] writes: Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. Let me quote the GR text: In practice, then, documentation simply isn't different enough to warrant different standards: we still wish to provide source code in the same manner as for programs, we still wish to be able to modify and reuse documentation in other documentation and programs as conveniently as possible, and we wish to be able to provide our users with exactly the documentation they want, without extraneous materials. As we don't accept program object code without source, we are not accepting document binaries without source, either. For the motivation behind the GR, read the various lists for that time, this was discussed extensively back then. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Le Saturday 25 October 2008 18:36:33 Kalle Kivimaa, vous avez écrit : Romain Beauxis [EMAIL PROTECTED] writes: Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. Let me quote the GR text: In practice, then, documentation simply isn't different enough to warrant different standards: we still wish to provide source code in the same manner as for programs, we still wish to be able to modify and reuse documentation in other documentation and programs as conveniently as possible, and we wish to be able to provide our users with exactly the documentation they want, without extraneous materials. As we don't accept program object code without source, we are not accepting document binaries without source, either. For the motivation behind the GR, read the various lists for that time, this was discussed extensively back then. Do you claim a PDF file is a binary file, or a program object ? Even if PDF was a programming language, as proposed in another anwser, it would fall into the script category, where the executed object is also the source. Furthermore, requirement to provide source code is a consequence of the requirement to be able to modify the program. Again, if I provide a manual for blind people consisting in a wav (or a ogg/vorbis) file, what kind of source would you ask for then ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Romain Beauxis [EMAIL PROTECTED] writes: Do you claim a PDF file is a binary file, or a program object ? Even if PDF was a programming language, as proposed in another anwser, it would fall into the script category, where the executed object is also the source. I grant you that it is possible for the upstream to use the PDF file as the preferred form for modifications (if it's not packed/encrypted), and if such a case comes up, I think we'll (grudgingly) accept it. 99.999% of the time the document is in fact modified in some other format and only distributed as PDF. Furthermore, requirement to provide source code is a consequence of the requirement to be able to modify the program. Again, if I provide a manual for blind people consisting in a wav (or a ogg/vorbis) file, what kind of source would you ask for then ? We will ask for whatever is your preferred form for modifications. It might be the actual binary in your case. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Sat, Oct 25, 2008 at 04:36:33PM +, Kalle Kivimaa wrote: Romain Beauxis [EMAIL PROTECTED] writes: Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. Let me quote the GR text: In practice, then, documentation simply isn't different enough to warrant different standards: we still wish to provide source code in the same manner as for programs, we still wish to be able to modify and reuse documentation in other documentation and programs as conveniently as possible, and we wish to be able to provide our users with exactly the documentation they want, without extraneous materials. As we don't accept program object code without source, we are not accepting document binaries without source, either. For the motivation behind the GR, read the various lists for that time, this was discussed extensively back then. The requirement for source code is spelled out in DFSG#2, which explicitly uses the word program. Applying this element of the DFSG to non-program works is a significant change that has *never* been ratified by the project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
[Followup-To: header set to linux.debian.devel.] Thomas Weber [EMAIL PROTECTED]: On Tue, Oct 21, 2008 at 05:06:29PM -0500, William Pitcock wrote: On Wed, 2008-10-22 at 09:03 +1100, Ben Finney wrote: William Pitcock [EMAIL PROTECTED] writes: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. That's news to me. Where is such a dedication required? Is it some special reading of the vague ?our users? commitment, or do you get I worded that rather badly. You should imply within acceptable terms of the DFSG here... in this case, putting stuff in the nonfree firmware May I suggest that people cool down a little bit and don't assume the worst from the other participants of the discussion. I'm just a user, not a DD. I've found this discussion very informative, perhaps because of the passion some have brought to it. All I'd like to add is, to all concerned, the other guy might be at least partly right. Damn. Personally, I try my damnedest to avoid kit that can't be driven by FLOSS, but I also taught myself long ago that Computer Games are Fritterware. I don't care about blistering 3D video performance, nor do I care about wifi. This discussion doesn't affect me (much), but it's very interesting. This thread doesn't begin to approach real flamewar status. :-) -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Ben Hutchings [EMAIL PROTECTED]: I just wrote this: http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware.html Drat, just missed: Intel Corporation 82801DB PRO/100 VM (LOM) Ethernet Controller (rev 81) Thanks for the article. -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Wed, 22 Oct 2008, Manoj Srivastava wrote: On Tue, Oct 21 2008, Henrique de Moraes Holschuh wrote: On Tue, 21 Oct 2008, Manoj Srivastava wrote: acceleration, right? So the box can be installed, and is usable for non-gaming purposes. The drm stuff can possibly be gotten from non You can always use VESA, yes. I don't think the X.org driver can get an ATI GPU to work without the memory management *microcode* (but I didn't know that thing was still non-free). That should be good enough to install, and then add non-free to sources.list and get the firmware required for the driver to work (absent a non-free debian installer that bundles non-free bits). This is no different from what I have had to do already for my nvidia card (degraded X support until I arranged to have non-free nvidia drivers installed). I would think that was an acceptable solution. As someone who only owns ATI GPUs and one legacy nVidia GPU (I don't have any Intel, basically because I couldn't get good enough screens in the Laptops with Intel graphics at the time I bought them and when I got the nVidia, ATI was still as closed as a clamp), I would consider the above solution to be acceptable. I also deem it acceptable if we as a project were to proceed by refusing to add any and every *new* driver that requires non-free components to Debian, adding them to non-free when possible, and removing them completely when we don't have the right to distribute the non-free components at all (i.e. it is not good even for non-free). I can deal with a two-step install process for my video cards, as long as it is properly documented. But I would serioulsy recommend that we produce easy to use non-free installer disks to go along with the Debian installer disks, not because of the GPUs, but because of the network cards. If this would slow down the release too much, make these AFTER the release, there is no reason why we can't release non-free a bit later. Whether ATI microcode still deserves to be in non-free is an orthogonal issue. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Fri, Oct 24, 2008 at 10:20:43AM -0200, Henrique de Moraes Holschuh wrote: I can deal with a two-step install process for my video cards, as long as it is properly documented. But I would serioulsy recommend that we produce easy to use non-free installer disks to go along with the Debian installer disks, not because of the GPUs, but because of the network cards. If this would slow down the release too much, make these AFTER the release, there is no reason why we can't release non-free a bit later. I recently installed a new server with Etch which uses a bnx2 network chip. This requires firmware from non-free. It wasn't particularly hard to install the firmware package on another box, copy the resulting firmware file to a usb stick, and mount it from vt2 and place it in the firmware directory so that the installer could load the network driver. A slight bit of work, but not hard. I do not expect debian to produce an installer with non-free code included. After all non-free is not part of debian as far as I understand things. Documenting the requries steps would be nice of course. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Kalle Kivimaa [EMAIL PROTECTED] wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? The last part of the sentence is unrealistic, because the list would only describe the *known*to*be* non-free bits. There are unknown non-free bits already in the archive[1], and there might be some that slip in by new upstream releases. Regards, Frank [1] Our up-upstream has recently started a license auditing and found several, just look at texlive's most recent RC bugs -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Hi there! On Wed, 22 Oct 2008 15:28:08 +0200, Manoj Srivastava wrote: On Tue, Oct 21 2008, Henrique de Moraes Holschuh wrote: On Tue, 21 Oct 2008, Manoj Srivastava wrote: acceleration, right? So the box can be installed, and is usable for non-gaming purposes. The drm stuff can possibly be gotten from non You can always use VESA, yes. I don't think the X.org driver can get an ATI GPU to work without the memory management *microcode* (but I didn't know that thing was still non-free). That should be good enough to install, and then add non-free to sources.list and get the firmware required for the driver to work (absent a non-free debian installer that bundles non-free bits). This is no different from what I have had to do already for my nvidia card (degraded X support until I arranged to have non-free nvidia drivers installed). I would think that was an acceptable solution. +1. Thx, bye, Gismo / Luca pgp74T5YinD2E.pgp Description: PGP signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote: On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? The Technical Committee is not empowered to override foundation documents. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote:
On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote:
On Tuesday 21 October 2008, you wrote:
But, in fact, fixes are not welcome from the team. They have raised a
major roadblock, allowing only one kind of fix which requires a lot of
work, and rejecting anything simpler.
Ever hear of the Technical Committee?
The Technical Committee is not empowered to override foundation documents.
6.1.4 of the constitution should help you in this case.
Neil
--
int getRandomNumber() {
return 4; // chosen by fair dice roll. guaranteed to be random.
}
// http://xkcd.com/c221.html
signature.asc
Description: Digital signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, Oct 23, 2008 at 05:41:05PM +0100, Neil McGovern wrote: On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote: On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote: On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? The Technical Committee is not empowered to override foundation documents. 6.1.4 of the constitution should help you in this case. I don't see how does 6.1.4 enable the TC to override foundation documents. Did I miss something? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, Oct 23, 2008 at 07:06:14PM +0200, Robert Millan wrote: On Thu, Oct 23, 2008 at 05:41:05PM +0100, Neil McGovern wrote: On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote: On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote: On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? The Technical Committee is not empowered to override foundation documents. 6.1.4 of the constitution should help you in this case. I don't see how does 6.1.4 enable the TC to override foundation documents. Did I miss something? The need for the TC to override a foundation document. If you have what you believe to be a fix that's not welcome from the team, and they want a different one, the TC could use 6.1.4 to rule in your favour (or more precisely, against the team that your course of action should be taken). Perhaps I'm mis-reading the above. Which bit of the foundation documents do you think would need overriding for the tech-ctte to rule on which fix to take? Thanks, Neil -- blarson I use three different operating systems: Sarge, Etch, and Sid. signature.asc Description: Digital signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Luca Capello wrote the following on 23.10.2008 10:53 - *snip* - That should be good enough to install, and then add non-free to sources.list and get the firmware required for the driver to work (absent a non-free debian installer that bundles non-free bits). This is no different from what I have had to do already for my nvidia card (degraded X support until I arranged to have non-free nvidia drivers installed). I would think that was an acceptable solution. +1. Thx, bye, Gismo / Luca What does that mean? Is it: one more *pseudo-freeness-preacher* that is OK with delaying the lenny release *to remove a handful bytes which makes hardware work at all* but then finds it absolutely perfect to install a several *megabytes of CLOSED driver* just to increase performance on an already working device?? Really i can't take you seriously -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, 2008-10-23 at 18:13 +0100, Neil McGovern wrote: Perhaps I'm mis-reading the above. Which bit of the foundation documents do you think would need overriding for the tech-ctte to rule on which fix to take? One might think that this is the situation: two alternative fixes for the DFSG problem, and a dispute about which one is better. But actually, that's not the situation. We have instead an easy trivial fix, all but complete. (Really, just disabling the hardware, or the accelerations, depending on the case.) And maintainers saying that this is an unacceptable fix--and no actual alternative fix sitting around. I think everyone would regard the fix preferred by the maintainers as superior--there is no technical dispute. The dispute is *not* between the two fixes. It is between these two approaches: 1) Install easy fix now; install fancy fix when it's ready, thus complying with the DFSG at all times; 2) Install no fix now; install fancy fix when it's ready, thus violating the DFSG in the meanwhile. This is not a dispute about technical means or which is the best solution to a technical problem; it is a dispute about whether we are actually supposed to be doing our best to comply with the DFSG at all times. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Ben Hutchings wrote: On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote: The iwl4965 firmware changed 2 times incompatible since the driver exists. That makes me wonder just how separate the driver and firmware are. If they are tightly coupled then the firmware may become subject to the GPL as well. Firmware and driver do not run on the same CPU. There is no 'linkage' between them. With a client/server application, a GPL client does not enforce the server to be GPL, even if client and server are tightly coupled. Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Thu, 2008-10-23 at 21:13 +0200, Vincent Danjean wrote: Ben Hutchings wrote: On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote: The iwl4965 firmware changed 2 times incompatible since the driver exists. That makes me wonder just how separate the driver and firmware are. If they are tightly coupled then the firmware may become subject to the GPL as well. Firmware and driver do not run on the same CPU. There is no 'linkage' between them. With a client/server application, a GPL client does not enforce the server to be GPL, even if client and server are tightly coupled. That is not true. It simply depends on whether they are one program or not, which is a human-level concept, and not a technical one. There is no magic boundary at which the GPL would neve cross. For example, if you were to split GCC into two executables, one which parsed and generated intermediate code, and another which did optimization and codegen, the result would still be the one GCC, covered by the GPL. And this is true even if you then write your own version of the first part, implementing your seekrit proprietary language: the GPL on the back end would require that the *whole program* be distributed under the GPL, any separation into different executables notwithstanding. There is nothing in the GPL about running on the same CPU or client/server exceptions. If you use GPLd code, then the *whole program* (whatever that is, it is a human-level concept requiring understanding and not rote following of rigid rules) must be distributable under terms no more restrictive than the GPL itself. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 04:50:23PM -0500, William Pitcock wrote: In the kernel itself, yes. Provided that: * the kernel framework for loading firmware is used for drivers depending on non-free firmware, and * that firmware is available in non-free via firmware-nonfree What if the firmware has a license on it that doesn't permit redistribution in non-free? Then what? Infact, once I have time, I intend to start pushing patches upstream to make this happen. But this is going to take another kernel release cycle... if we intend to release Lenny with 2.6.26, than this is not an option. Well, if 2.6.27 in fact fixes a large amount of the firmware problem, and happens to be a long term support kernel which is going to be used by many distributions, then perhaps releasing Lenny with 2.6.26 is the wrong choice and should be reconsidered. For hardware where this is an unacceptable solution, rewriting the driver to not use the firmware may still be possible. Sometimes. Certainly some hardware doesn't do anything without its firmware. Perhaps alternate firmware could be written, although often there isn't any documentation around to do that. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Thomas Bushnell BSG wrote: On Thu, 2008-10-23 at 21:13 +0200, Vincent Danjean wrote: Firmware and driver do not run on the same CPU. There is no 'linkage' between them. With a client/server application, a GPL client does not enforce the server to be GPL, even if client and server are tightly coupled. That is not true. It simply depends on whether they are one program or not, which is a human-level concept, and not a technical one. There is no magic boundary at which the GPL would neve cross. For example, if you were to split GCC into two executables, one which parsed and generated intermediate code, and another which did optimization and codegen, the result would still be the one GCC, covered by the GPL. And this is true even if you then write your own version of the first part, implementing your seekrit proprietary language: the GPL on the back end would require that the *whole program* be distributed under the GPL, any separation into different executables notwithstanding. The FSF seems to disagree on this[1]: Can I release a non-free program that's designed to load a GPL-covered plug-in? It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. The general idea seems to be that (at least the FSF) only linked modules are considered as a single program and only in this case all parts have to be GPL-compatible (not necessarily released under the GPL itself). Note that the GPL defines a covered work as the unmodified Program or a work based on the Program. In my opinion this does *not* include a program just calling the GPL-covered software (but then I'm neither a lawyer nor particularly familiar with legal English). Trying to extend this to separate executables would open a can of worms: For example, is an IDE that includes the GCC compiler a single work and must thus be released under the GPL? Regards, Ansgar [1] http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins -- PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Thu, 2008-10-23 at 22:08 +0200, Ansgar Burchardt wrote: The FSF seems to disagree on this[1]: Can I release a non-free program that's designed to load a GPL-covered plug-in? It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. The general idea seems to be that (at least the FSF) only linked modules are considered as a single program and only in this case all parts have to be GPL-compatible (not necessarily released under the GPL itself). This is (or when the text was originally written), about programs *as released by the FSF*, but not about the GPL in general. It may be that the older text is now getting used in a broader context. I do not know if this represents a change in the FSF's position. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, 2008-10-23 at 15:51 -0400, Lennart Sorensen wrote: On Tue, Oct 21, 2008 at 04:50:23PM -0500, William Pitcock wrote: In the kernel itself, yes. Provided that: * the kernel framework for loading firmware is used for drivers depending on non-free firmware, and * that firmware is available in non-free via firmware-nonfree What if the firmware has a license on it that doesn't permit redistribution in non-free? Then what? Then we must not distribute it. However, it appears that in most cases where the licence for firmware does not permit redistribution (e.g. GPLv2, where we cannot satisfy clause 3) this is a mistake and the copyright holder did intend to allow redistribution. [...] For hardware where this is an unacceptable solution, rewriting the driver to not use the firmware may still be possible. Sometimes. Certainly some hardware doesn't do anything without its firmware. Perhaps alternate firmware could be written, although often there isn't any documentation around to do that. In many cases firmware runs on an embedded microcontroller which implements a well-known architecture (e.g. 8051 or MIPS), which provides a starting point for reverse-engineering the code. Working out the programming model could be a long job though, depending on just how much functionality is dependent on the firmware. Ben. signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Hi Dne Wed, 22 Oct 2008 07:25:59 +0200 Vincent Danjean [EMAIL PROTECTED] napsal(a): Looking at your packages, I've a question. I see one package per firmware without version number in the package name. Do you think about a way to have different kernels that each requires different firmware versions (for the same hardware) ? It seems to me that this problem is not addressed by current firmware-* package (packages already in Debian and your new ones), unless it is expected that firmware packages will change their name. However, I think this is a problem we must take into account for long term support. At least ipw2100 drivers changed firmware name if they required different version, so I guess this is also used by others... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote: At least ipw2100 drivers changed firmware name if they required different version, so I guess this is also used by others... If they need an incompatible one. Not necessarily if they just need a newer one. Bastian -- Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
* William Pitcock [EMAIL PROTECTED] [081021 22:11]: Luckily very few others do. How can it be lucky that people think it is a good idea to break the law (distributing stuff without license to do so), to trick people into breaking the law (by claiming everyone can copy Debian CD images and mirror then), and making people think something is stable when there are more than thousand people around the globe that could each day enforce their copyright in the kernel an terminate the license for the kernel unless you can provide source for all its parts. Failing to support anything that was infact, supported by Etch, that isn't absolutely positively ancient, is a regression. A very important part of a stable release is actually making it stable. Shipping with unneeded legal risks that can make it necessary any day to remove that support because it was not already legal at shipment time, is not what we promise our users. Sadly, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Am Mittwoch, den 22.10.2008, 08:36 +0200 schrieb Bastian Blank: On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote: At least ipw2100 drivers changed firmware name if they required different version, so I guess this is also used by others... If they need an incompatible one. Not necessarily if they just need a newer one. I'm not really into hardware, but how often does kernel firmware change in an incompatible way? It seems to defeat its purpose (providing a stable interface a driver can talk to). Thanks Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 02:17:37PM -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote: Doing so would be a violation of basic NMU policy. The claim was, hey, nobody is stopping anyone from fixing it, if it's not fixed, it's lame for people to complain, they should have fixed it. There's a difference between randomly charging around without making any effort to work with or coordinate with anyone else and working constructively as part of a large organisation. You appear to only be considering one of these options. You can either blame people for not uploading their own fix or prohibit them from doing so, but you can't do both at the same time. It appears that the rest of the world is meeting you at least half way here by, for example, producing patches which implement a solution that is more acceptable to upstream. Perhaps there are other, similarly low effort, things which you could to to contribute to getting those patches integrated? -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Wed, Oct 22, 2008 at 10:54:41AM +0200, Thomas Weber wrote: Am Mittwoch, den 22.10.2008, 08:36 +0200 schrieb Bastian Blank: On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote: At least ipw2100 drivers changed firmware name if they required different version, so I guess this is also used by others... If they need an incompatible one. Not necessarily if they just need a newer one. I'm not really into hardware, but how often does kernel firmware change in an incompatible way? The iwl4965 firmware changed 2 times incompatible since the driver exists. It seems to defeat its purpose (providing a stable interface a driver can talk to). No. Holding interfaces stable at all cost produces something like Windows. In this case the interface will change, but you still can use the old firmware using the old driver. Bastian -- There are always alternatives. -- Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21 2008, Henrique de Moraes Holschuh wrote: On Tue, 21 Oct 2008, Manoj Srivastava wrote: acceleration, right? So the box can be installed, and is usable for non-gaming purposes. The drm stuff can possibly be gotten from non You can always use VESA, yes. I don't think the X.org driver can get an ATI GPU to work without the memory management *microcode* (but I didn't know that thing was still non-free). That should be good enough to install, and then add non-free to sources.list and get the firmware required for the driver to work (absent a non-free debian installer that bundles non-free bits). This is no different from what I have had to do already for my nvidia card (degraded X support until I arranged to have non-free nvidia drivers installed). I would think that was an acceptable solution. manoj -- There is no fire like desire. There is no hold like anger. There is no net like ignorance. There is no river like craving. 251 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Manoj Srivastava wrote the following on 22.10.2008 15:28 - *snip* - That should be good enough to install, and then add non-free to sources.list now it gets really absurd. Either be free and clearly tell the people that you are not willing to support their hardware or don't blame RMs for the same thing you did above. Everything else is just splitting hairs. - *snip* - manoj -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
- *snip* - That should be good enough to install, and then add non-free to sources.list now it gets really absurd. Either be free and clearly tell the people that you are not willing to support their hardware or don't blame RMs for the same thing you did above. Everything else is just splitting hairs. - *snip* - manoj just to remind you: http://lists.debian.org/debian-devel/2008/08/msg00040.html Lenny is Debian. non-free is not part of Debian. Check the Social Contract. -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
[NO CC, please] Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote: If we waited for a release to be 100% perfect, it will likely take several more years. The good news is that the amount of inline firmware in the kernel is decreasing. So, eventually, all non-DFSG redistributable firmware can belong in firmware-nonfree. Do we have an ironclad commitment to not add any additional non-DFSG firmware, period, no matter what? I would accept a compromise which guaranteed an increasing slope. But not a back-and-forth thing. Your reply focuses on regression issues, so is that really sufficient? We guarantee that, say, there will always be *less* non-DFSG firmware in each release, and we guarantee that there will never be *new* non-DFSG firmware. First of all sorry for mentioning it here. But doesn't 2.6.27 partially solve the issue by moving all that stuff to firmware/? it could easily be stripped from the tarball and moved to some other package. Not that I'm an expert in the field, but I haven't seen anyone mentioning the .27 change before in the thread. Thomas Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Manoj Srivastava wrote: On Tue, Oct 21 2008, Luk Claes wrote: Manoj Srivastava wrote: On Mon, Oct 20 2008, Stefano Zacchiroli wrote: On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote: ... and if it is *not* different, why should be the release managers be considered responsible for it? They just decide (and kudos for all their hard work, BTW) if something which is already in Debian gets released or not. I am not sure that violating a foundation document falls under the powers of a delegate. I wish it did, being a delegate, but it does not. I looked. Stop this nonsense, it's not the release team that is violating a foundation document. It's Debian as a whole and it's happening now, not when we release or not. The only thing we did as a release team is to make clear that we don't want to delay the release if these bugs won't get fixed. As always we don't object that lenny-ignore bugs would get fixed before lenny. Hmm. I am not so sire it is nonsense. Yes, the release team is not alone in this, and, really, all of us are somewhat to blame for not helping the kernel team fix the DFSG violations. But I don't think that the release team is blameless, either, since they decided to release with DFSG violating code. We didn't decide to release yet... Now, if we are all so very eager to have these bugs go away, we have no objections to an NMU with the patches that have been posted on -kernel mailing list, right? (Note: some of these patches have only recently been posted, so NMU's based on these patches have only just becme possible). Not in principle, though I would object an NMU that is not tested properly. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Luk Claes [EMAIL PROTECTED] writes: it's not the release team that is violating a foundation document. It's Debian as a whole and it's happening now, not when we release or not. This is an important distinction, thank you. The only thing we did as a release team is to make clear that we don't want to delay the release if these bugs won't get fixed. Surely the requirement is not to *ignore* a serious bug, but to *remove* the offending package unless the bug is resolved? Yes, I understand we're talking about, in some cases, kernel packages that have these bugs. What I don't see is why these serious bugs, that (as you point out) violate the Debian project's foundation documents, can be ignored for the sake of releasing on a particular date. -- \ “I doubt, therefore I might be.” —anonymous | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Luk Claes [EMAIL PROTECTED] writes: Manoj Srivastava wrote: Hmm. I am not so sire it is nonsense. Yes, the release team is not alone in this, and, really, all of us are somewhat to blame for not helping the kernel team fix the DFSG violations. But I don't think that the release team is blameless, either, since they decided to release with DFSG violating code. We didn't decide to release yet... That's not the point being made: As I understand Manoj's point, it is that tagging a bug ‘lenny-ignore’ is an active decision that a particular bug, even if it represents a DFSG violation, will not be considered in the decision to release. To that extent, it *is* making the decision that it is acceptable to release Debian with DFSG-violating works, in advance of the decision to actually release. -- \ “As the evening sky faded from a salmon color to a sort of | `\ flint gray, I thought back to the salmon I caught that morning, | _o__)and how gray he was, and how I named him Flint.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Tue, Oct 21 2008, Luk Claes wrote: We didn't decide to release yet... Fair enough. Now, if we are all so very eager to have these bugs go away, we have no objections to an NMU with the patches that have been posted on -kernel mailing list, right? (Note: some of these patches have only recently been posted, so NMU's based on these patches have only just becme possible). Not in principle, though I would object an NMU that is not tested properly. What would you call proper testing? I promise to build the kernel images on two architectures I have access to (i386 and amd64), and test the images on the limited set of machines I have (3). If the NMU is uploaded to people.d.o, perhaps people with access to other hardware can test it (though I am no, perhaps, the best candidate to create the NMU, since Ben Hutchings has really been doing some heavy lifting with the patches). If an NMU of the kernel package is acceptable, in absence of the kernel-team themselves accepting the patches and doing an MU, then perhaps the issue has been overblown. My impression had been that the kernel image packages were deemed too important to NMU, especially given their impact on the installer. I'd be happy to be proved wrong. manoj -- What the large print giveth, the small print taketh away. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? You're not seriously thinking that a release without E100 support does make any sense and is any good for Debian, right? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Ben Finney (2008-10-21 17:37 +1100): That's not the point being made: As I understand Manoj's point, it is that tagging a bug ‘lenny-ignore’ is an active decision that a particular bug, even if it represents a DFSG violation, will not be considered in the decision to release. To that extent, it *is* making the decision that it is acceptable to release Debian with DFSG-violating works, in advance of the decision to actually release. OK guys, please. As a random Debian user may I suggest that you stop investigating _who_ is violating DFSG and instead focus on _what_ things are the cause of violating DFSG. I guess we know about the what part already and that part exists in Sid too. So I think you should do apt-get source linux-2.6 and go fix the issues you are concerned about - or help testing the fixes provided by others (I might do some testing too). And perhaps the users whose hardware won't be supported anymore appreciate some help on how to work around their problem. (It looks like this includes me.) Anyway, thanks for all the DDs and Debian community for this mostly-pretty-good operating system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Le mardi 21 octobre 2008 à 00:00 +0100, Ben Hutchings a écrit : The modified linux-2.6 and firmware-nonfree source packages, and the linux-source-2.6.26 and firmware-* binary packages, can be found in: http://people.debian.org/~benh/firmware-removal/ Thanks for the summary. Please test them if you can. I have only been able to test the radeon changes myself. You know where to go now: users. Post to d-d-a, post to planet, search for people with this hardware. Insist on it being critical for the continued support of this hardware. If people show up, you’ve got the tests the kernel team was requesting. If they don’t, that could mean dropping support for this hardware is feasible. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 03:49:40PM -0700, Thomas Bushnell BSG wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: If they were actively stopping people working on these issues then that would be different but I have not seen them doing this. Great, so since there won't be any active attempts to stop, I can just go ahead with the work, right? Providing you work in a constructive fashion I really don't see why this should be a problem. This would involve efforts to work with the kernel maintainers and release team, of course, rather than working with no coordination at all. As it turns out Ben has already been actively working on this within Debian so I'd suggest that the most constructive way forward would be to fill in the bits that are missing there, most of which looked like testing. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Am Dienstag, den 21.10.2008, 08:29 +0200 schrieb Marc Haber: On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? You're not seriously thinking that a release without E100 support does make any sense and is any good for Debian, right? How long do you want to ignore the issue, then? It's software without source, every other package gets a REJECTED in NEW for such stuff. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 09:04:21AM +, Thomas Weber wrote: Am Dienstag, den 21.10.2008, 08:29 +0200 schrieb Marc Haber: On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? You're not seriously thinking that a release without E100 support does make any sense and is any good for Debian, right? How long do you want to ignore the issue, then? It's software without source, every other package gets a REJECTED in NEW for such stuff. If we weren't doing compromises, then: * we would have no glibc (sunrpc code has licensing issues); * until recently we would have no 3d (mesa had licensing issues); * we would have no portmap/nfs/... (the same sunrpc issue as the glibc); * we would have no kernel (it's crippled with tiny offending blobs); * we would have no DRI/DRM for many video cards; * … IOW we would barely be able to use some devices, only in the linux console, and 1 time over 3 without any kind of network connectivity. I don't say it's nothing we should _care_ about, but at some point: * you don't have the source of your BIOS; * you don't have the VHDL source of your CPU and all the chipsets of your computer; * I'm sure your laptop/computer has dozens of patented hardware bits, so you're supporting patents while buying it, you should do a pilgrimage to cleanse yourself from all that filth. To add insult to the injury, the key to my home is patented, and I have to go to special locksmith if I want to have a new one and so on, and behind my door, there is a lot of Open Source. I should get rid of it, it could be tainted, that would be bad wouldn't it ? Firmwares are here because it's cheaper nowadays to have a chip that is versatile and configured to a specific task. Older hardware had less firmwares because the chips were made specifically for the board it was in, and you had no problems with not having the source code of the chip. So really, I see there is a double standard here, and a lot of hypocrisy. But sure, I still have 2 machines that use e100 at home (I think, maybe only one), I will be delighted not to be able to install Debian on it, because fuckwits have decided that less than 512 octets of firmware (inside millions of slocs in the kernel) were not free enough. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmheIWwUyMw.pgp Description: PGP signature
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Am Dienstag, den 21.10.2008, 12:57 +0200 schrieb Pierre Habouzit: On Tue, Oct 21, 2008 at 09:04:21AM +, Thomas Weber wrote: Am Dienstag, den 21.10.2008, 08:29 +0200 schrieb Marc Haber: On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? You're not seriously thinking that a release without E100 support does make any sense and is any good for Debian, right? How long do you want to ignore the issue, then? It's software without source, every other package gets a REJECTED in NEW for such stuff. If we weren't doing compromises, then: You are missing my point. We[1] got a reject for a documentation PDF without source. So, we contacted upstream who checked the copyright with the company in order to release the source for the documentation. And yes, it's work, painful, whatever and I would have preferred not having to do it. The kind of compromise above makes it close to impossible to argue in such cases: Upstream: You are ignoring the issue in case X, why do you bother me about Y? It's not even code, if you want the text, just extract it. What do you expect me to say in such cases: You are not the kernel.? [1] Packages are group-maintained. I don't say it's nothing we should _care_ about, but at some point: * you don't have the source of your BIOS; * you don't have the VHDL source of your CPU and all the chipsets of your computer; * I'm sure your laptop/computer has dozens of patented hardware bits, so you're supporting patents while buying it, you should do a pilgrimage to cleanse yourself from all that filth. Yes, and what of the above is in Debian's archive? Frankly, if binary firmware is okay, just say so in the DFSG. No problem with me. But then please be consistent and stop forbidding uploads for documents without source, too. Because I'm unable to explain the difference between firmware without source and binary documentation without source. Can you explain it? Firmwares are here because it's cheaper nowadays to have a chip that is versatile and configured to a specific task. Older hardware had less firmwares because the chips were made specifically for the board it was in, and you had no problems with not having the source code of the chip. So really, I see there is a double standard here, and a lot of hypocrisy. See above, the same tale about double standards can be told as soon as other packages enter the picture. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote: Interesting; Manoj's post isn't in the -vote archives on master. I wonder why that is? Actually, I think we need a GR on the lines of , | http://www.debian.org/vote/2006/vote_007 | General Resolution: Handling source-less firmware in the Linux kernel ` To get a special dispensation for lenny. I think this would be insane. [...] I object to a second round of this. I was ok with it once, [...] Hrm, were you? Hey, we can check! V: 12tb Thomas Bushnell -- http://www.debian.org/vote/2004/gr_editorial_tally.txt (in favour of editorial amendments GR that made all non-free anything unambiguously unsuitable for main; except maybe license texts) V: 3457216 tb Thomas Bushnell -- http://www.debian.org/vote/2004/gr_sarge_tally.txt (The Debian Project resolves that it will not compromise on freedom, and will never knowingly issue another release (excluding point updates to stable releases) that contains anything in the main or contrib sections which is not free software according to the DFSG.; with the various proposed exceptions for sarge ranged between [2] and [5], further discussion at [6], and reverting the previous GR at [7]) V: 12tb Thomas Bushnell -- http://www.debian.org/vote/2006/vote_004_tally.txt (Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution.; Further Discussion won the day) V: 231 tb Thomas Bushnell -- http://www.debian.org/vote/2006/vote_007_tally.txt (Options were Release etch with DFSG problems, but no regressions compared to sarge, exemptions for images and for firmware while technically needed but with no specific end date, and further discussion; the first option won the day) Seems to me you held pretty much the same opinions then as you do now... The kernel team should *fix the bug* and not just sit on their hands. You know, I haven't been paying any attention, but somehow I don't think the kernel team have really just been sitting on their hands. It just seems like maybe there's a third option, you know? Well, I don't and maybe I'm mistaken, so as a show of good faith, here's a photo of me sitting on my hands [0]. Because, hey, _someone_ must have been doing it, right? We should not release until it's fixed. Why don't we embrace the principle fully, and remove all our old releases too? That's not sarcasm -- I just don't see a reason to reject that idea, but not also to keep compromising until there's no longer anything to compromise with. AFAICS, the idea is to stop Debian users and developers from kidding themselves that they've got a free OS and force them to fix the remaining problems until they do. And if that's really a good idea, why not commit to it? But hey, I never saw the problem with only wanting to distribute free /software/, and we know where that sort of thinking leads! Moreover, at the time, there was an amendment proposed to make it as long as required and it got fewer votes than the one-time thing. Pretty clearly, we *already decided* this issue, and we need no vote. We decided there would be an exception for sarge, and another one for etch. I don't think there's been any decision made via GR on lenny, and even if there had been, another GR could quite reasonably overturn it if enough people felt it was warranted. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. What good do you think that will do? Here, let me try: Thomas: your continued inaction and unwillingness to code an acceptable solution to this issue, in spite of being aware of the problem since at least 2004 -- over four years ago! -- means we will continue to do releases with non-free software. Did it do any good? Is there something different about other maintainers that will make that logic work better on them, than you? I object very strongly to the feeling that I am being held hostage by developers who will not fix the bug, and then protest emergency! we must release! no delay! we'll do it next time! and then sit on their hands again for another go-round. The solution is to refuse to play along, and to say, hey, you had two years; we're just going to wait until you fix the bug. Hey, you've had four years; we're just going to keep releasing until you fix the bug. Hint: you're not being held hostage by anyone, seriously. You know how you can tell? Two words: Stockholm syndrome. Cheers, aj, who knows what completely ignoring the lists is like, and wants a fresh comparison of that to randomly trolling into
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 08:29 +0200, Marc Haber wrote: On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? You're not seriously thinking that a release without E100 support does make any sense and is any good for Debian, right? Yes, I am thinking exactly that. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote: Thomas: your continued inaction and unwillingness to code an acceptable solution to this issue, in spite of being aware of the problem since at least 2004 -- over four years ago! -- means we will continue to do releases with non-free software. I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. I ask simply that the project's standards be *applied*, or that at the very least, we have a resolution as we did before. And yes, I would likely vote against it, as I did before. But in a democratic system, people generally are well advised to accept the result of past votes gracefully and work towards the next one. That's what I did; my vote did not carry the day last time, and I have not objected about that decision since. But I *do* object to the apparent new rule that the ftpmasters and release engineers are now empowered to ignore DFSG violations without any review by anyone else. And now we have people saying, hey, let's exempt firmware from the DFSG! again, even though we have a GR on topic which decided that, no, firmware counts. Hey, you've had four years; we're just going to keep releasing until you fix the bug. Hint: you're not being held hostage by anyone, seriously. You know how you can tell? Two words: Stockholm syndrome. So I can upload an NMU right now that fixes the problem? That will be ok? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?
On Tue, Oct 21 2008, Bastian Blank wrote: On Mon, Oct 20, 2008 at 01:32:51PM -0500, Manoj Srivastava wrote: Seems like there are patches stripping the kernel of these non-free blobs. So, how much would out hardware support be degraded? How many people are affected by these non-free drivers? The drm modules: Anything which includes an ATI or Matrox card and runs X. The network modules: Not that much, it is mostly old hardware. We already removed the bnx2x driver for the new Broadcom 10GE interfaces, which in fact is a really new one. Thanks for the response. The DRM modules are need for 3D acceleration, right? So the box can be installed, and is usable for non-gaming purposes. The drm stuff can possibly be gotten from non free, like we do nvidia accelerated drivers today? If that is the case, the drm drivers should not be an obstacle. manoj who has not yet switched to the free drivers for nvidia cards yet -- Information is the inverse of entropy. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?
On Tue, Oct 21 2008, Aurelien Jarno wrote: On Mon, Oct 20, 2008 at 04:12:25PM +1100, Ben Finney wrote: Howdy all, Have I missed some announcement that DFSG violations don't matter for the release of ‘lenny’? I ask because a whole lot of bug reports of DFSG violations have been tagged ‘lenny-ignore’ without explanation: URL:http://bugs.debian.org/391935 URL:http://bugs.debian.org/498631 URL:http://bugs.debian.org/494308 URL:http://bugs.debian.org/494010 URL:http://bugs.debian.org/494009 URL:http://bugs.debian.org/494007 and probably others I've missed. Should these tags be removed? I would think at least a meaningful justification in the bug report is required if DFSG violations are to be explicitly ignored, but perhaps I'm wrong. As it seems there are a few persons interested by getting those bugs fixed asap, could we create a team of persons willing to deal with users who will get affected by the removal of non-free code? I really don't want to deal with user complaints. The best would be to use a pseudo-package in the BTS for that, so that we can reassign bugs easily. Then I will remove the non-free code with my packages. I'll sign up to be on the maintainers list for such a package. manoj -- Madison's Inquiry: If you have to travel on the Titanic, why not go first class? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Thomas Bushnell BSG wrote: I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. I'm very glad that history has shown most developers disagree with you. So I can upload an NMU right now that fixes the problem? No, it's not OK. See [EMAIL PROTECTED] for a good description of an approach that would be welcome. signature.asc Description: This is a digitally signed message part.
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 10:38 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote: Thomas: your continued inaction and unwillingness to code an acceptable solution to this issue, in spite of being aware of the problem since at least 2004 -- over four years ago! -- means we will continue to do releases with non-free software. I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. Luckily very few others do. Failing to support anything that was infact, supported by Etch, that isn't absolutely positively ancient, is a regression. I ask simply that the project's standards be *applied*, or that at the very least, we have a resolution as we did before. And yes, I would likely vote against it, as I did before. But in a democratic system, people generally are well advised to accept the result of past votes gracefully and work towards the next one. That's what I did; my vote did not carry the day last time, and I have not objected about that decision since. But I *do* object to the apparent new rule that the ftpmasters and release engineers are now empowered to ignore DFSG violations without any review by anyone else. And now we have people saying, hey, let's exempt firmware from the DFSG! again, even though we have a GR on topic which decided that, no, firmware counts. Shipping Lenny within a reasonable timeframe is more important than firmware. If the release managers feel that firmware bugs should be tagged lenny-ignore, than it is because they feel that fixing these bugs would likely delay the Lenny release too long. Note that Debian is already distributing this stuff in sid, so why give Lenny special treatment? If we waited for a release to be 100% perfect, it will likely take several more years. The good news is that the amount of inline firmware in the kernel is decreasing. So, eventually, all non-DFSG redistributable firmware can belong in firmware-nonfree. But that goal will simply not be realized before Lenny is released, if we intend to ship Lenny anytime soon. Hey, you've had four years; we're just going to keep releasing until you fix the bug. Hint: you're not being held hostage by anyone, seriously. You know how you can tell? Two words: Stockholm syndrome. So I can upload an NMU right now that fixes the problem? That will be ok? If the NMU involves removing support for hardware, then no, the NMU's solution would be in my opinion unacceptable, and hopefully enough people agree that it would be rejected. The correct solution here would be to work with the kernel team and derive a list of acceptable goals that still result in Lenny being shipped in a reasonable timeframe. William signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 21:21 +0200, Frans Pop wrote: Thomas Bushnell BSG wrote: I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. I'm very glad that history has shown most developers disagree with you. So I can upload an NMU right now that fixes the problem? No, it's not OK. See [EMAIL PROTECTED] for a good description of an approach that would be welcome. I see. So the previous statement that nobody is standing in the way of a fix is simply not so. People certainly are standing in the way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote: If we waited for a release to be 100% perfect, it will likely take several more years. The good news is that the amount of inline firmware in the kernel is decreasing. So, eventually, all non-DFSG redistributable firmware can belong in firmware-nonfree. Do we have an ironclad commitment to not add any additional non-DFSG firmware, period, no matter what? I would accept a compromise which guaranteed an increasing slope. But not a back-and-forth thing. Your reply focuses on regression issues, so is that really sufficient? We guarantee that, say, there will always be *less* non-DFSG firmware in each release, and we guarantee that there will never be *new* non-DFSG firmware. If the NMU involves removing support for hardware, then no, the NMU's solution would be in my opinion unacceptable, and hopefully enough people agree that it would be rejected. Thought so. So the claim that nobody is standing in the way was simply false. People are standing in the way of a simple fix for a simple bug, and insisting on a more complex fix. I agree completely that the more complex fix is better, but it is simply not true that nobody is standing in the way of a fix. Rather, they have declared that only one sort of fix is tolerable, and mostly refused to discuss the question. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tuesday 21 October 2008, Thomas Bushnell BSG wrote: I see. So the previous statement that nobody is standing in the way of a fix is simply not so. People certainly are standing in the way. That's nonsense. Uncoordinated NMUs are never acceptable for packages that are in general actively maintained (which the kernel is), especially not when it concerns controversial or technically complex changes [1]. Doing so would be a violation of basic NMU policy. [1] This would seem to be both. signature.asc Description: This is a digitally signed message part.
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 13:30 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote: If we waited for a release to be 100% perfect, it will likely take several more years. The good news is that the amount of inline firmware in the kernel is decreasing. So, eventually, all non-DFSG redistributable firmware can belong in firmware-nonfree. Do we have an ironclad commitment to not add any additional non-DFSG firmware, period, no matter what? I would accept a compromise which guaranteed an increasing slope. But not a back-and-forth thing. Your reply focuses on regression issues, so is that really sufficient? We guarantee that, say, there will always be *less* non-DFSG firmware in each release, and we guarantee that there will never be *new* non-DFSG firmware. Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. If those drivers require firmware, then we can work to ensure that they use the kernel's firmware loading framework. This is a cause that is a good idea for many practical reasons excluding ensuring the firmware is segregated to firmware-nonfree. However, not supporting the latest 3ware RAID card due to non-free firmware, as an example, would be unacceptable, considering Debian's strong foundation in being run on servers. Likewise, failing to support the latest 3D hardware or audio hardware when DFSG-free drivers are available, but depend on non-DFSG firmware, will lose Debian users on desktop hardware as well. That said, Debian release cycles are fairly long, so there's time to make sure things are implemented right in the future. If the NMU involves removing support for hardware, then no, the NMU's solution would be in my opinion unacceptable, and hopefully enough people agree that it would be rejected. Thought so. So the claim that nobody is standing in the way was simply false. People are standing in the way of a simple fix for a simple bug, and insisting on a more complex fix. I agree completely that the more complex fix is better, but it is simply not true that nobody is standing in the way of a fix. Rather, they have declared that only one sort of fix is tolerable, and mostly refused to discuss the question. People are not standing in your way as long as it does not cause regressions or break support for current hardware that people may wish to use. William signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Tue, 2008-10-21 at 12:56 -0500, Manoj Srivastava wrote: On Tue, Oct 21 2008, Aurelien Jarno wrote: On Mon, Oct 20, 2008 at 07:30:23PM +0200, Robert Millan wrote: On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote: You cannot ask, so late in the release process, Some of these bugs have been known for *years*. In one of them, I even got a reply saying something along the lines of I was expecting this one. Debian is violating the DFSG by using a non-DFSG license for its website (see bug#238245). As the bug is opened for *years*, I suggest we proceed with the removal of the website. Yes, this is another thing we need to fix. Any volunteer to work on that? First things first: Where do I record the fact that any contribution I have made to the web site or the wiki may be licensed under the GPL? As announced during DC8, the wiki is going to be relicensed, that's on our plan (It's just that some other stuffs have my attention ATM). The first step is to choose the license, so I can't give you an URL. Please, don't remove the wiki yet ! (but we will remove non-free stuffs from the wiki). Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote: On Tuesday 21 October 2008, Thomas Bushnell BSG wrote: I see. So the previous statement that nobody is standing in the way of a fix is simply not so. People certainly are standing in the way. That's nonsense. Uncoordinated NMUs are never acceptable for packages that are in general actively maintained (which the kernel is), especially not when it concerns controversial or technically complex changes [1]. Doing so would be a violation of basic NMU policy. The claim was, hey, nobody is stopping anyone from fixing it, if it's not fixed, it's lame for people to complain, they should have fixed it. But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Yes, certainly the team has the right to make such roadblocks if they think it best, in principle. But then that's what's happening: they are standing in the way of implementing a quicker simpler fix. You can either blame people for not uploading their own fix or prohibit them from doing so, but you can't do both at the same time. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. No matter what our principles are? Wow. Why are we not equally committed to supporting the latest proprietary codecs? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? signature.asc Description: This is a digitally signed message part.
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Do not put words into my mouth. I simply stated that user experience is an important factor, and that if free drivers (*FREE*) which depend on non-free firmware are available, and the firmware is inline, then it should not block Lenny's release. William signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:23 +0200, Frans Pop wrote: On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? This is a technical dispute? Whether your packages need to comply with the DFSG? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote: On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Do not put words into my mouth. I simply stated that user experience is an important factor, and that if free drivers (*FREE*) which depend on non-free firmware are available, and the firmware is inline, then it should not block Lenny's release. Huh? So you would be willing to agree to a rule that we never add anything new to the list of non-free bits? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 14:36 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote: On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Do not put words into my mouth. I simply stated that user experience is an important factor, and that if free drivers (*FREE*) which depend on non-free firmware are available, and the firmware is inline, then it should not block Lenny's release. Huh? So you would be willing to agree to a rule that we never add anything new to the list of non-free bits? In the kernel itself, yes. Provided that: * the kernel framework for loading firmware is used for drivers depending on non-free firmware, and * that firmware is available in non-free via firmware-nonfree Infact, once I have time, I intend to start pushing patches upstream to make this happen. But this is going to take another kernel release cycle... if we intend to release Lenny with 2.6.26, than this is not an option. For hardware where this is an unacceptable solution, rewriting the driver to not use the firmware may still be possible. William signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tuesday 21 October 2008, Thomas Bushnell BSG wrote: This is a technical dispute? Whether your packages need to comply with the DFSG? Isn't a dispute about alternative fixes for a bug a technical dispute? I thought that was your point. The violation itself is not a matter for the TC (although it could be if the maintainer argued that it wasn't a violation at all). But whether your proposed fix is suitable for Debian when the maintainer prefers a different type of fix certainly is. And it would even be a matter for the TC to decide whether the maintainer is right in rejecting your fix as an intermediate solution. And if the TC agrees with the maintainer and you still want (to help get) the bug fixed, your only option will be to code the more complex fix. Anyway, I'm having a very hard time to take you seriously on any policy compliance issues as you are still CCing me on Debian listmail in violation of the Debian list policy despite a request I sent you earlier privately. EOD for me. signature.asc Description: This is a digitally signed message part.
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
- Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. Really do have to disagree there. We should absolutely preferentially support quality hardware that facilitate user control. From a purely practical standpoint, there may come a time (because of evolutions in nanotech or who knows what) where certain type of digital technologies have strong controls that must be honored in order to preserve the safety of the general public. Given that scenerio I think we would have to be 100% free and 100% obey the law. I think we can leave it to others to break the law for us (or, preferrably, secure legal permissions through proper channels). We don't need to distribute binary blobs to have a useful foundation for building other things. If I was going to suggest any kind of change to the Social Contract at this point it would be: 6. Debian will obey the law We acknowledge that our users live in real communities in the real world. We will support the needs of our users to comply with the laws that are applicable in the places where they use their software. We will strive to create the most usable operating system legally possible for our users. Within the boundaries of our resources we will work with our developers to track and adapt the changes necessary for them to comply with the laws and rules of their local authority. In the jurisdiction of authorities which are antagonistic to the cause of Free Software we will work within the boundaries of the law to promote change to a more open system. ... Obviously, we can't be in the position of asking our donors or our users to purposefully break the law. Where law and logistics make it impossible to be completely free we must strive to be as free as legally possible and work to promote positive change. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
William Pitcock [EMAIL PROTECTED] writes: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. That's news to me. Where is such a dedication required? Is it some special reading of the vague “our users” commitment, or do you get this dedication from all Debian contributors some other way? Does that dedication somehow override every DD's explicit commitment to ensuring Debian is 100% DFSG-free in the Social Contract? -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Wed, 2008-10-22 at 09:03 +1100, Ben Finney wrote: William Pitcock [EMAIL PROTECTED] writes: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. That's news to me. Where is such a dedication required? Is it some special reading of the vague “our users” commitment, or do you get this dedication from all Debian contributors some other way? Does that dedication somehow override every DD's explicit commitment to ensuring Debian is 100% DFSG-free in the Social Contract? I worded that rather badly. You should imply within acceptable terms of the DFSG here... in this case, putting stuff in the nonfree firmware package in non-free is an acceptable solution. William signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, Oct 21, 2008 at 05:06:29PM -0500, William Pitcock wrote: On Wed, 2008-10-22 at 09:03 +1100, Ben Finney wrote: William Pitcock [EMAIL PROTECTED] writes: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. That's news to me. Where is such a dedication required? Is it some special reading of the vague “our users” commitment, or do you get this dedication from all Debian contributors some other way? Does that dedication somehow override every DD's explicit commitment to ensuring Debian is 100% DFSG-free in the Social Contract? I worded that rather badly. You should imply within acceptable terms of the DFSG here... in this case, putting stuff in the nonfree firmware package in non-free is an acceptable solution. May I suggest that people cool down a little bit and don't assume the worst from the other participants of the discussion. Shit happens[1], throwing mud doesn't improve the atmosphere at all. [1] That includes, but is not limited to, bugs in packages and suboptimal wording in e-mails. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Ean Schuessler dijo [Tue, Oct 21, 2008 at 04:35:55PM -0500]: If I was going to suggest any kind of change to the Social Contract at this point it would be: 6. Debian will obey the law We acknowledge that our users live in real communities in the real world. We will support the needs of our users to comply with the laws that are applicable in the places where they use their software. We will strive to create the most usable operating system legally possible for our users. Within the boundaries of our resources we will work with our developers to track and adapt the changes necessary for them to comply with the laws and rules of their local authority. In the jurisdiction of authorities which are antagonistic to the cause of Free Software we will work within the boundaries of the law to promote change to a more open system. ... Obviously, we can't be in the position of asking our donors or our users to purposefully break the law. Where law and logistics make it impossible to be completely free we must strive to be as free as legally possible and work to promote positive change. Umh, problem is the myriad of jurisdictions all over the world. This would very easily become unfeasible. In the end, it ends up being each user's responsability to obey the law the best way he can. Debian helps as much as possible by only using valid, free and compatible licensing schemes - but if in West Namibia it becomes illegal to digitally manipulate photographies, we won't stop shipping photo manipulation programs. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 17:06 -0500, William Pitcock wrote: I worded that rather badly. You should imply within acceptable terms of the DFSG here... in this case, putting stuff in the nonfree firmware package in non-free is an acceptable solution. Of course; that's an excellent solution. Right now, the failure to have that solution implemented is being used as an excuse for violating SC#1. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Tue, 2008-10-21 at 11:35 +0200, Michal Čihař wrote: Hi Dne Tue, 21 Oct 2008 00:00:54 +0100 Ben Hutchings [EMAIL PROTECTED] napsal(a): The modified linux-2.6 and firmware-nonfree source packages, and the linux-source-2.6.26 and firmware-* binary packages, can be found in: http://people.debian.org/~benh/firmware-removal/ Please test them if you can. I have only been able to test the radeon changes myself. Please fix permissions: You don't have permission to access /~benh/firmware-removal/firmware-nonfree_0.13.2.dsc on this server. Sorry about that. I've fixed permissions now. Ben. signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Tue, 2008-10-21 at 15:55 -0200, Alexandre Oliva wrote: Hi, Sorry if this breaks threading, I'm not on this list, I was merely referred to the discussion through the archives. If you respond to this e-mail, please address your replies directly to myself as well, so that I can respond without further breaking threading. I applaud Debian's willingness, even if hesitant and heated, to tackle this issue. I'm here to point out that there's some exaggeration and false dilemmas being presented as objections to the liberation of the kernel in Debian main. I saw references to e100 and ATI video cards. Although it is true that linux-libre and other proposed means to remove their blobs might cause some hardware to malfunction or fail, I haven't come across any such hardware myself. I do have computers with e100 network cards and ATI video cards, and they keep on working just fine with linux-libre. Now, I don't know whether the absence of the firmware causes degraded functionality, or whether it is just not necessary for the specific hardware I own. Correct. The e100 driver works with a large family of controllers, some of which need the driver to supply firmware and some which don't (presumably it's built in). The r128 and radeon kernel drivers only deal with 3D functionality and the X server can drive the 2D part without them. But assuming that the removal of these pieces of firmware would break all instances of said hardware is a mistake. Unfortunately that's something we don't really know, and it may take some time to discover just what the impact is. So while I'm continuing to work on separation of firmware, I leave it to the kernel and release teams to judge whether these changes are worth making before lenny. [...] Anyhow, if you do decide to ship a Free kernel in Debian GNU/Linux main, please remember that cleaning up the kernel binaries is only part of the work; if the corresponding sources still contain the non-Free blobs, [...] They don't - there is a script to strip them from the upstream sources. Ben. signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
- Gunnar Wolf [EMAIL PROTECTED] wrote: Umh, problem is the myriad of jurisdictions all over the world. This would very easily become unfeasible. In the end, it ends up being each user's responsability to obey the law the best way he can. Debian helps as much as possible by only using valid, free and compatible licensing schemes - but if in West Namibia it becomes illegal to digitally manipulate photographies, we won't stop shipping photo manipulation programs. I guess the question is, staying in the arena of 100% Free, what if DRM technologies become pervasive in the United States and Europe and it literally becomes illegal to have a computer without some proprietary software in it? What if it becomes impossible to develop on a computer, legally, without compromising? Would it still be better to have a computer that is 99.9% free? Keep in mind that I'm asking this in the scenario where providing the last 0.01% as Free Software would be illegal. With the way cell phones and hosted applications are developing it might not be so far-fetched. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 21 Oct 2008, Manoj Srivastava wrote: acceleration, right? So the box can be installed, and is usable for non-gaming purposes. The drm stuff can possibly be gotten from non You can always use VESA, yes. I don't think the X.org driver can get an ATI GPU to work without the memory management *microcode* (but I didn't know that thing was still non-free). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Tue, 2008-10-21 at 11:00 +0300, Teemu Likonen wrote: Ben Finney (2008-10-21 17:37 +1100): That's not the point being made: As I understand Manoj's point, it is that tagging a bug ‘lenny-ignore’ is an active decision that a particular bug, even if it represents a DFSG violation, will not be considered in the decision to release. To that extent, it *is* making the decision that it is acceptable to release Debian with DFSG-violating works, in advance of the decision to actually release. OK guys, please. As a random Debian user may I suggest that you stop investigating _who_ is violating DFSG and instead focus on _what_ things are the cause of violating DFSG. Already done. I guess we know about the what part already and that part exists in Sid too. So I think you should do apt-get source linux-2.6 and go fix the issues you are concerned about - or help testing the fixes provided by others (I might do some testing too). And perhaps the users whose hardware won't be supported anymore appreciate some help on how to work around their problem. (It looks like this includes me.) I just wrote this: http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware.html Ben. signature.asc Description: This is a digitally signed message part
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Ben Hutchings [EMAIL PROTECTED] writes: I just wrote this: http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware.html Great! Many thanks for this constructive work. -- \ “I was arrested today for scalping low numbers at the deli. | `\ Sold a number 3 for 28 bucks.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 18:45 -0500, Ean Schuessler wrote: I guess the question is, staying in the arena of 100% Free, what if DRM technologies become pervasive in the United States and Europe and it literally becomes illegal to have a computer without some proprietary software in it? What if it becomes impossible to develop on a computer, legally, without compromising? Would it still be better to have a computer that is 99.9% free? Keep in mind that I'm asking this in the scenario where providing the last 0.01% as Free Software would be illegal. If that happens, we will have to make some difficult choices. But we are nowhere near that now. For example, I vote, as a matter of principle. But if I lived in various extreme situations, I would not vote, for example, if I were in a one-party state with no real elections. And then *that* principle might well be one I would compromise on if the state in question enforced serious criminal penalties on non-voters. And so it goes. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
Ben Hutchings wrote: I just wrote this: http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware.html Hi, Thank you for your constructive work in this area. Looking at your packages, I've a question. I see one package per firmware without version number in the package name. Do you think about a way to have different kernels that each requires different firmware versions (for the same hardware) ? It seems to me that this problem is not addressed by current firmware-* package (packages already in Debian and your new ones), unless it is expected that firmware packages will change their name. However, I think this is a problem we must take into account for long term support. Just to clarify, I see your work as an improvement (ie I do not see my question as reason to delay the merge of your work) Regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Ben Finney [EMAIL PROTECTED] writes: Have I missed some announcement that DFSG violations don't matter for the release of ‘lenny’? No, because they generally matter. I ask because a whole lot of bug reports of DFSG violations have been tagged ‘lenny-ignore’ without explanation: [...] and probably others I've missed. The full list of bugs tagged lenny-ignore is available here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=lenny-ignore Should these tags be removed? No. I would think at least a meaningful justification in the bug report is required Well, apply common sense. In all of the bugs I recently tagged, the DFSG violation is usually a formal problem, something that other distributions and upstream don't consider a problem at all. While fixing these issues is and should be a goal of Debian, it's hardly something that can be done in the last few weeks before releasing. The drawbacks of delaying the release indefinitely for these bugs are much greater than releasing with these minor DFSG violations [1]. FWIW, this has also been done for past releases (see, for example, #211765). Marc Footnotes: [1] Yeah, I'm waiting to get toasted for daring to say minor here. -- BOFH #290: The CPU has shifted, and become decentralized. pgp7jRl6NAuzl.pgp Description: PGP signature
Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?
On Mon, Oct 20 2008, Robert Millan wrote: Btw, I'm looking for supporters for a GR to stop this gross violation of the SC. Any DDs who read this, please let me know if you're interested. Actually, I think we need a GR on the lines of , | http://www.debian.org/vote/2006/vote_007 | General Resolution: Handling source-less firmware in the Linux kernel ` To get a special dispensation for lenny. If someone were to propose such a GR, I would second it. If the DPL gives us leave to cut down discussion and voting to a week, we could get the decision in a couple of weeks. I do not think that willfully violating the social contract is a decision for a few delegates to make -- we, as a project, should acknowledge the need for and make a special exception to release Debian with known non-free bits in it. manoj -- If Machiavelli were a programmer, he'd have worked for ATT. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit : On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote: What if, instead of ranting everywhere, you actually contributed code to fix these bugs? I did... And you deserve kudos for that. But that doesn’t make this current thread less of a troll. You cannot ask, so late in the release process, to introduce several thousand-lines patches in the kernel, even if they finally exist. And you can’t say you were ignoring the situation until now. It should have been obvious that, given how they evolved, these bugs would be ignored for lenny. I don’t recall the release team being reluctant to letting bug fixes (especially serious ones) migrate to lenny. ...but you missed the point. They're not wishlist bugs. If they were, I wouldn't care much about them. They are serious bugs. And if we waited to have zero serious bugs before releasing, we’d never release. That’s why lenny-ignore tags are here. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit : On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote: What if, instead of ranting everywhere, you actually contributed code to fix these bugs? I did... And you deserve kudos for that. But still, it is unrealistic to ask, so late in the release process, to introduce several thousand-lines patches in the kernel, even if they finally exist (and AFAIK there are not patches for all these bugs). You cannot say either that you were ignoring the situation until now. It should have been obvious that, given how they evolved, these bugs would be ignored for lenny. It is unfortunate, but people have focused on fixing other kinds of bugs. I don’t recall the release team being reluctant to letting bug fixes (especially serious ones) migrate to lenny. ...but you missed the point. They're not wishlist bugs. If they were, I wouldn't care much about them. They are serious bugs. And if we waited to have zero serious bugs before releasing, we’d never release. That’s why lenny-ignore tags are here. The release team is not trying to lower standards, but simply to mitigate between the issues and obtain the best compromise. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Damnit, sent mail instead of moving to drafts. Sorry for the double sending. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Le lundi 20 octobre 2008 à 19:30 +0200, Robert Millan a écrit : On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote: You cannot ask, so late in the release process, Some of these bugs have been known for *years*. In one of them, I even got a reply saying something along the lines of I was expecting this one. Still, the release team depends on the good will of developers who spend time fixing RC bugs. And they are not the only ones that have been sitting for way too long. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote: On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote: Has the current release team lowered the bar on Debian actually trying to follow the social contract? Yes, they have. Furthermore, the FTP team (which is supposed to be in charge of DFSG enforcement) has decided to look the other way: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823 I had understood that we had passed a GR to allow--ONCE--a past release with these bugs not fixed, with the understanding they would be fixed the next time. Have I missed something? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote: Actually, I think we need a GR on the lines of , | http://www.debian.org/vote/2006/vote_007 | General Resolution: Handling source-less firmware in the Linux kernel ` To get a special dispensation for lenny. I think this would be insane. It smacks of the nonsense of the US Congress extending copyright over and over again, always for a limited term, but such that the terms just never actually expire. I object to a second round of this. I was ok with it once, as a compromise, but the understanding I had then was that it was a one-time thing, to give time to actually *fix* the problem. The kernel team should *fix the bug* and not just sit on their hands. We should not release until it's fixed. But the continued dishonesty of holding out one set of principles and guarantees, while granting ourselves exceptions on every release, is not tolerable to me. I do not think that willfully violating the social contract is a decision for a few delegates to make -- we, as a project, should acknowledge the need for and make a special exception to release Debian with known non-free bits in it. We did that once. With the understanding that we wouldn't do it again--or at least, that was my understanding--it was proffered as a special case, a one-time thing, because of the urgency of the case. Moreover, at the time, there was an amendment proposed to make it as long as required and it got fewer votes than the one-time thing. Pretty clearly, we *already decided* this issue, and we need no vote. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. I object very strongly to the feeling that I am being held hostage by developers who will not fix the bug, and then protest emergency! we must release! no delay! we'll do it next time! and then sit on their hands again for another go-round. The solution is to refuse to play along, and to say, hey, you had two years; we're just going to wait until you fix the bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: I object to a second round of this. I was ok with it once, as a compromise, but the understanding I had then was that it was a one-time thing, to give time to actually *fix* the problem. Note that there is currently active upstream work to allow us to address these issues - some of the patches are present in 2.6.27, others are still in flight. This is a vast step forward on where we were with etch if we do decide to go down the route of releasing with exceptions again. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. I don't think that's a particularly constructive approach to take, especially not in a volunteer project. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
